Volver a proyectos

OpusAstraArgon

Seguridad

Abrir aplicaciónVer presentaciónVer repositorio en GitHub

PhoneWard

Un asistente de IA atiende primero las llamadas de números desconocidos, detecta estafas y extorsiones mientras ocurren y convierte cada intento en inteligencia compartida para la organización que protege a esas personas.

El problema

En Perú, el fraude por teléfono crece más rápido de lo que se denuncia.

  • 42 161 denuncias por delitos informáticos en 2024, más del doble que en 2021 (Ministerio Público). La cifra incluye llamadas, mensajes y redes; no hay una estadística oficial solo de estafas telefónicas.
  • S/ 90 millones robados por medios digitales solo en Lima Metropolitana en 2024 (Sidpol, PNP).
  • Una denuncia por extorsión cada 19 minutos: 22 348 en 2024 y 20 705 entre enero y septiembre de 2025, un 28,8 % más (Sidpol, PNP).
  • Solo 1 de cada 4 víctimas denuncia (INEI, 2024–2025). Las cifras oficiales son el piso, no el total.

Las modalidades se repiten: «familiar detenido», falso operador del banco, falso funcionario de SUNAT, pedidos de códigos o de pagos por Yape. El estafador cambia de número, pero no de libreto ni de voz.

El hueco: quienes hoy responden lo hacen después del delito. OSIPTEL da de baja líneas, la SBS emite alertas, la PNP investiga lo que se denuncia y las apps identificadoras solo reconocen números ya marcados como spam. Nadie protege a la persona durante la llamada, y cada intento queda como un caso aislado que no le sirve a nadie más.

Validación con la Policía

Entrevistamos a un efectivo de la Policía Nacional del Perú para contrastar el problema y la propuesta con quienes reciben las denuncias.

Para quién es (B2B)

PhoneWard se vende a organizaciones que tienen la responsabilidad o el interés de proteger a un grupo de personas. La organización entrega la app a su gente y recibe un panel con lo que pasa en su red.

| Cliente | Qué protege | Qué gana | |---|---|---| | Municipalidades y juntas vecinales | Vecinos, especialmente adultos mayores | Alertas en tiempo real para su comunidad y casos armados para la PNP | | Bancos, cajas y fintech | Sus clientes, antes de que transfieran | Menos fraude por suplantación y señales tempranas de cuentas mula | | Empresas y gremios | Trabajadores y comercios expuestos a extorsión | Evidencia ordenada y números o voces reincidentes identificados | | Operadoras y autoridades | Las líneas de la red | Una base de números, cuentas y voces vinculados para actuar con datos |

Usuario final: la persona que recibe la llamada. No tiene que configurar nada técnico: instala la app, la elige como teléfono y queda protegida.

El valor está en la red, no en un solo usuario. Cada llamada analizada alimenta una base compartida: si un número o una voz ya participó en una estafa, el siguiente usuario de cualquier organización recibe el aviso, aunque el estafador llame desde otro número.

Cómo funciona

1. Atención de la llamada

  1. Entra una llamada de un número que no está en los contactos. Los contactos suenan normal.
  2. PhoneWard (la app de teléfono predeterminada en Android) contesta, pone la llamada en espera, llama al número del agente y une las dos llamadas en una conferencia. El micrófono del usuario queda silenciado.
  3. El agente de voz conversa con quien llama como una persona cualquiera de la casa («¿Aló?»), sin decir que es un asistente. Si le preguntan en serio si es una IA, no lo niega.
  4. Mientras tanto, el usuario solo ve una notificación con el estado: Analizando, Puedes entrar, Posible estafa o Número reportado.

2. Análisis en tiempo real: dos agentes

Lo que dice quien llama se transcribe (solo su canal; la voz del asistente nunca se analiza) y se envía en paralelo a dos agentes:

  • Agente de comprensión (gpt-4.1-mini): elige citas literales de la conversación y las clasifica (petición, amenaza, condición, negación, contexto). No reescribe palabras ni atribuye identidades.
  • Agente de detección (gpt-6-luna, OpenAI Decisions): devuelve una probabilidad, y el código la convierte en alerta sí o no según un umbral. Está ajustado al contexto peruano: distingue un pedido cotidiano de presión o de una amenaza directa, y un relato de amenaza de una amenaza real.

Una política de orientación combina ambos resultados de la misma revisión y decide: observar (ya puedes entrar), verificar o alertar. Un fallo del análisis nunca se interpreta como «llamada segura».

3. Qué pasa después

  • Segura: «Puedes entrar». El usuario se une a la conversación cuando quiere.
  • Riesgo: «Posible estafa · te recomendamos no entrar». Con permiso del usuario, el sistema corta las dos partes de la conferencia automáticamente.
  • Pedido peligroso (por ejemplo, un código o una clave): alerta roja inmediata con la frase exacta, también si el usuario ya está en la llamada.

4. Inteligencia compartida

  • Reputación del número: al sonar, la app consulta si ese número ya participó en estafas en cualquier organización y lo marca como Reportado.
  • Huella de voz: cuando la estafa ya es casi segura, el agente alarga la conversación para juntar voz, guarda una huella vocal (un vector, nunca el audio) y corta. En las llamadas siguientes, a cualquier usuario, la voz se compara con las guardadas: si coincide, avisa «voz parecida a un estafador reportado», aunque llame desde otro número.
  • Panel de la organización: llamadas analizadas, números bloqueados por los usuarios, vínculos entre casos por número, cuenta o voz, registro de presuntos responsables, voces de estafadores con revisión humana e informes en PDF para la autoridad.

Arquitectura

| Pieza | Tecnología | |---|---| | App | Android nativa (Kotlin, Jetpack Compose), app de teléfono predeterminada | | Voz del agente | Vapi: Soniox stt-rt-v5 (transcripción) → GPT-4.1 mini → ElevenLabs Flash v2.5 | | Agentes y orquestación | Servidor Node.js en Maritime: webhooks de Vapi, eventos por WebSocket a la app, corte de llamada | | Huella de voz | sherpa-onnx con WeSpeaker ResNet34 (vectores de 256 dimensiones) | | Panel y API | Next.js en Vercel, Postgres con pgvector en Supabase |

Qué está construido y probado

  • Atención automática por conferencia, notificaciones por etapa y corte de las dos partes de la llamada, observado en llamadas reales en Android (el corte llega a Android en unos 45 ms).
  • Los dos agentes, la política de orientación y los eventos a la app, probados de punta a punta con audio sintético por la línea de Vapi.
  • Detector ajustado a Perú: en el set de desarrollo detectó los 8 casos de riesgo y no alertó en ninguno de los 10 legítimos.
  • Reputación de números entre organizaciones y panel con casos, vínculos, bloqueados, sospechosos y voces.
  • Huella de voz: motor, búsqueda y guardado probados en local; con voces sintéticas, la misma voz dio 0,96 de similitud y una voz distinta 0,37.

Limitaciones reales

Telefonía

  • El número del agente es de EE. UU. (+1 209…). Cada llamada protegida es una llamada internacional desde la SIM del usuario y depende de que la operadora permita espera y conferencia sin costo extra. Falta un número peruano o un enlace SIP local.
  • Solo Android, y solo como app de teléfono predeterminada. Android no deja a una app capturar el audio de una llamada normal; por eso usamos la conferencia. En iPhone este enfoque no es posible.
  • Capas de fabricante. HyperOS (Xiaomi) puede pasar la llamada al marcador del sistema si la app no tiene una ventana activa; lo resolvimos con una ventana invisible, pero cada marca de teléfono puede tener sus propias restricciones.
  • No está configurado el desvío directo de la operadora (por ejemplo, Entel): el modelo sin conferencia requiere un acuerdo con la operadora.

Calidad de voz y conversación

  • El audio telefónico llega degradado (8 kHz y varias recodificaciones). La transcripción todavía se equivoca en palabras críticas, como montos o nombres.
  • Latencia de 1,6 a 1,9 s por respuesta en la línea telefónica; el objetivo es menos de 1,5 s.
  • Un estafador atento puede notar que habla con una IA y colgar. Eso protege al usuario, pero reduce la información que se recoge.

Precisión

  • El detector no está calibrado con llamadas reales. Sus resultados vienen de un set de desarrollo con casos sintéticos; el porcentaje es una estimación del modelo, no una probabilidad validada de estafa.
  • La huella de voz solo está validada con voces sintéticas. Los umbrales (0,70 para avisar, 0,80 para considerar fuerte la coincidencia) hay que calibrarlos con voces humanas y audio de conferencia, donde además puede haber eco del usuario.
  • Una coincidencia de número o de voz es una pista, no una identificación. El sistema no afirma quién es nadie; las huellas quedan en revisión humana en el panel.

Operación

  • Un solo servidor en un plan gratuito. Si la máquina está dormida o falla un despliegue, las llamadas se atienden sin protección (la app avisa «Sin protección»). Durante el hackathon tuvimos una caída por un despliegue fallido.
  • La configuración del equipo va dentro de la APK de la demo. Para producción hace falta emitir credenciales por organización y por dispositivo.
  • Costo por llamada: la voz consume saldo de Vapi y los análisis consumen créditos de IA; falta medir el costo real por minuto protegido.

Legal y privacidad

  • La huella de voz es un dato biométrico sensible (Ley 29733 de Protección de Datos Personales). Hoy el permiso lo da el dueño del teléfono; para producción se necesita un análisis legal sobre el tratamiento de la voz de quien llama, plazos de conservación y acuerdos con la autoridad.
  • No se guardan grabaciones ni transcripciones en el teléfono, pero el audio y el texto pasan por proveedores externos (Vapi, Soniox, OpenAI, ElevenLabs).

Próximos pasos

  1. Número peruano o enlace SIP local, para eliminar la llamada internacional y mejorar el audio.
  2. Calibrar el detector y la huella de voz con llamadas reales autorizadas.
  3. Piloto con una organización (una junta vecinal o una caja municipal) y sus usuarios.
  4. Integración con bancos para frenar transferencias durante o después de una llamada de riesgo.
  5. Infraestructura de producción: servidores redundantes, credenciales por organización y marco legal para los datos biométricos.

Última edición:

Bitácora del equipo

Avances, decisiones y dificultades que el equipo compartió con mentores y jurados.

  1. Gael Rs

    Actualmente decidimos ya el track c: , pero estamos en fase de reconocimiento de problema, un problema real que suceda en el Peru para luego poder enfocarnos en la real solucion jeje

  2. Alejo Oroncoy

    Primer avance de la propuesta: Asistente contra estafas y extorsiones

    Primer avance — definición de la propuesta y plan de trabajo
    Track: Seguridad: extorsión, estafas, suplantación y desinformación.
    Estado: propuesta en definición; nombre comercial pendiente.
    Fecha: 17 de octubre de 2026.

    Este avance presenta el problema elegido, la solución que se propone construir, el alcance de la demostración y los próximos pasos técnicos. Describe funcionalidades planificadas; todavía no se reportan resultados de implementación.

    1. Problema

    Las personas pueden enfrentar conversaciones fraudulentas o amenazantes sin contar con apoyo inmediato para reconocer señales de riesgo, verificar lo que les solicitan y pedir ayuda a tiempo. La presión, la urgencia y la aparente familiaridad del interlocutor pueden dificultar la evaluación de una situación.

    Después del incidente, la información puede quedar dispersa entre grabaciones, números mostrados, mensajes y recuerdos. Esto dificulta revisar lo sucedido y encontrar posibles vínculos con otros casos.

    El proyecto busca apoyar la prevención durante la conversación y organizar información para su revisión posterior. El foco inicial son estafas y extorsiones mediante conversaciones; la prevención de robos o secuestros queda fuera del prototipo.

    2. Solución propuesta

    Una aplicación móvil con IA que analiza audio autorizado, muestra señales de posible engaño y permite al usuario controlar las acciones de protección. Al finalizar, prepara un reporte revisable.

    Un panel para analistas permite revisar los incidentes compartidos con una organización y explorar posibles relaciones entre ellos mediante el contenido de las conversaciones, los datos observados y la similitud entre muestras de voz.

    El componente IoT es un pin que captura audio y lo transmite por Wi-Fi. Los controles y las alertas están en la aplicación: el pin no incluye pulsador ni vibrador.

    3. Usuarios y roles

    | Rol | Funciones principales | | --- | --- | | Usuario de la aplicación | Activar o detener la captura, consultar señales de riesgo, configurar acciones de protección, revisar reportes y decidir qué información comparte. | | Analista autorizado de una organización | Revisar casos compartidos, comparar señales, aceptar o descartar vínculos propuestos y documentar conclusiones. |

    La organización accede únicamente a los casos y datos que le corresponden. El permiso para analizar una conversación y el permiso para compartir información con una organización son controles separados.

    4. Funcionalidades principales

    4.1. Análisis de la conversación

    La IA transcribe el audio y analiza señales como presión para actuar rápidamente, solicitudes de dinero o datos sensibles, exigencia de secreto y amenazas. La aplicación muestra el motivo de la alerta y permite revisar el fragmento relacionado.

    Una señal aislada no confirma una estafa. Por ejemplo, una petición urgente de dinero de un familiar justifica una verificación adicional, pero no demuestra un engaño.

    El resultado se presenta como riesgo estimado y señales observadas, evitando afirmaciones categóricas de culpabilidad.

    4.2. Controles del usuario

    Desde la aplicación, el usuario puede activar o desactivar la captura y el análisis, revisar el estado de conexión y decidir si conserva o comparte el incidente.

    La intervención de un asistente y el corte automático de una llamada se contemplan como acciones configurables y autorizadas. Su implementación depende del canal de llamada disponible; no se asume que una aplicación común pueda controlar cualquier llamada telefónica de Android.

    Si se demuestra el relevo de la conversación, el asistente se identifica como tal y actúa con autorización. No se plantea clonar la voz del usuario ni suplantarlo.

    4.3. Comparación entre muestras de voz

    Se contempla obtener representaciones numéricas de muestras de voz —vectores o embeddings— y compararlas con muestras anteriores autorizadas para señalar similitudes que ameriten revisión.

    La similitud de voz es una pista adicional, no una identificación confirmada. La duración del audio, el ruido, los dispositivos y el uso de grabaciones o voces sintéticas pueden alterar los resultados.

    Una primera alerta no incorpora automáticamente a una persona a una lista de estafadores. Los casos conservan su estado provisional y los vínculos requieren revisión. Los vectores se tratan como datos biométricos sensibles, con acceso restringido, conservación definida y posibilidad de borrado.

    4.4. Reporte del incidente

    El reporte organiza, cuando estén disponibles y autorizados:

    • Fecha, hora y canal de captura.
    • Grabación original y fragmentos relevantes.
    • Transcripción, indicando que puede contener errores.
    • Señales de riesgo y segmentos que las sustentan.
    • Números mostrados o reportados, nombres mencionados y otros datos presentes en el incidente, con su procedencia.
    • Acciones ejecutadas y permisos otorgados.
    • Posibles vínculos con otros casos y motivos de esos vínculos.
    • Observaciones y correcciones del usuario o del analista.

    El reporte separa datos observados, inferencias de la IA y conclusiones revisadas. Puede apoyar la preparación de una denuncia; no constituye por sí solo una denuncia presentada ni una atribución verificada de identidad.

    El pin captura sonido: no obtiene automáticamente el número de una llamada. Además, el número mostrado y un nombre pronunciado pueden ser falsos y no acreditan quién está detrás.

    4.5. Panel de análisis

    El panel presenta casos relacionados, cronologías y coincidencias de contenido, datos mencionados y muestras de voz. El analista puede confirmar o descartar relaciones y dejar constancia de su revisión.

    El objetivo es encontrar incidentes posiblemente vinculados o campañas similares. Atribuirlos a una persona concreta exige corroboración independiente.

    5. Componente IoT: pin de audio

    Alcance del hardware

    El pin captura audio y lo transmite al servidor. El análisis de IA se ejecuta en el servidor y sus resultados se muestran en la aplicación.

    | Elemento | Decisión actual | | --- | --- | | Microcontrolador | ESP32 disponible del equipo, identificado con Wi-Fi ISM 2,4 GHz, 802.11 b/g/n. Falta confirmar el modelo exacto para definir el cableado. | | Micrófono | Módulo INMP441 con salida digital I²S, alimentado a 3,3 V. Comprar el módulo con placa y pines, no el componente suelto. | | Conectividad | Wi-Fi de 2,4 GHz mediante router o punto de acceso del celular. | | Alimentación inicial | USB; la autonomía con batería no forma parte de la primera prueba. | | Montaje | Cables y placa de montaje; carcasa con clip para presentar el formato de pin. | | Controles y avisos | En la aplicación móvil. Pulsador y vibrador fuera del alcance. |

    El micrófono registra sonido ambiental. En el prototipo puede utilizarse para conversaciones presenciales y llamadas de prueba en altavoz. Con auriculares o con el teléfono al oído, no se garantiza la captura de la voz remota.

    Si se pierde la conexión, la aplicación debe mostrarlo claramente. El análisis y los avisos que dependan del servidor no estarán disponibles durante esa interrupción.

    6. Arquitectura propuesta

    Micrófono INMP441
       |
       v
ESP32 con Wi-Fi
       |
       v
Router o punto de acceso del celular
       |
       v
Servidor: recepción de audio, transcripción y análisis
       |
       +--> Aplicación móvil: controles, estado, alertas y reporte
       |
       +--> Almacenamiento autorizado de incidentes y muestras
                       |
                       v
              Panel del analista autorizado

    El servidor recibe las órdenes de la aplicación y coordina la captura con el pin. El transporte del audio requiere autenticación del dispositivo y cifrado. La versión inicial no necesita una conexión celular propia dentro del pin.

    7. Flujo del usuario

    1. El usuario vincula el dispositivo y configura permisos y acciones de protección.
    2. Activa la captura desde la aplicación y ve el estado del pin.
    3. El pin transmite el audio autorizado al servidor.
    4. La IA transcribe y presenta señales de posible riesgo durante la conversación, con una latencia que debe medirse.
    5. El usuario revisa la alerta y utiliza los controles disponibles.
    6. La aplicación prepara un reporte que el usuario puede revisar y corregir.
    7. Si autoriza compartirlo, un analista puede revisarlo y explorar relaciones con otros incidentes autorizados.

    8. Alcance del hackathon

    Demostración principal

    • Captura de audio desde el ESP32 y el micrófono.
    • Envío por Wi-Fi a un servidor.
    • Aplicación con inicio y detención de captura, estado de conexión y señales de riesgo explicadas.
    • Generación de un reporte revisable.
    • Panel de analista con dos o más incidentes de prueba y una posible relación entre ellos.
    • Comparación de muestras de voz de participantes voluntarios, presentada como similitud.

    Función avanzada, sujeta al tiempo disponible

    Intervención de un asistente identificado y control de terminación en llamadas realizadas dentro de una aplicación de voz propia o entorno de prueba controlado.

    Esta demostración sería un canal distinto de la captura ambiental del pin: capturar audio con el pin no concede control sobre una llamada telefónica.

    Fuera del alcance inicial

    • Pulsador y motor vibrador en el pin.
    • Identificación concluyente de personas por su voz.
    • Listas públicas de supuestos estafadores o publicación de grabaciones.
    • Grabación y control universal de llamadas telefónicas o de aplicaciones de terceros.
    • Predicción de robos o secuestros.
    • Denuncias policiales automáticas o garantía de validez probatoria.
    • Miniaturización final, autonomía de larga duración y conectividad celular propia.

    9. Guion de demostración

    1. Conversación legítima: un participante solicita ayuda económica en un contexto normal. Se observa si el sistema evita conclusiones categóricas y qué señales presenta.
    2. Escenario de riesgo simulado: aparecen señales de presión y una solicitud sospechosa. La aplicación explica la alerta y prepara el reporte.
    3. Segundo incidente: el mismo participante utiliza otro identificador de prueba. El panel muestra similitud de voz y otras coincidencias como un vínculo pendiente de revisión.
    4. Caso de contraste: otra voz o una conversación legítima con palabras parecidas permite evaluar y descartar una relación equivocada.

    Todas las muestras de la demostración se obtienen de participantes voluntarios informados. Los incidentes son ficticios y no se atribuyen a personas reales como autores de delitos.

    10. Qué medir

    | Aspecto | Verificación | | --- | --- | | Captura | Inteligibilidad del audio en diferentes posiciones, distancias y niveles de ruido. | | Transcripción | Errores en frases relevantes, especialmente negaciones, nombres y cantidades. | | Detección de riesgo | Alertas en escenarios simulados y falsas alarmas en conversaciones legítimas parecidas. | | Comparación de voz | Coincidencias acertadas, coincidencias falsas y casos sin información suficiente. | | Experiencia | Tiempo entre una señal conversacional y la alerta; claridad de la explicación. | | Conectividad | Comportamiento al perder y recuperar Wi-Fi; estado mostrado al usuario. | | Reporte | Correspondencia entre lo registrado, lo transcrito y lo inferido; correcciones humanas. |

    Una demo pequeña muestra el funcionamiento del flujo. No permite afirmar precisión general ni identificar personas con certeza.

    11. Diferencial y propuesta de valor

    Para la persona: apoyo durante una conversación de riesgo, controles visibles y un registro organizado del incidente.

    Para la organización: revisión de casos autorizados y exploración de conexiones que puedan orientar una investigación.

    La combinación propuesta reúne protección durante la conversación, documentación posterior y revisión de posibles vínculos, manteniendo explícitos los límites de cada resultado.

    12. Próximo paso técnico

    Confirmar el modelo exacto del ESP32 y definir el cableado del INMP441. Después, construir la primera prueba de extremo a extremo: capturar una frase, enviarla por Wi-Fi y reproducir el archivo recibido. La IA se integra una vez comprobada la calidad del audio y la transmisión.

    Referencias técnicas

  3. Gael Rs

    Ya encontramos la solucion, EPICOOOOOO, y ahor aestamos plantenado las bases de nuestros repos y sistemas, Con fe

  4. Gael Rs

    Problema y Solucion Encontrada jeje

  5. Gael Rs

    Notita corta, hay un mentor colombiano que es un capi, buenos tips y recomendaciones, un grande!

  6. Gael Rs

    Vinieron 2 mentores a mentorearnos :D , entonces nos comentaron varios putnos como friccion, si tenia uso de iPhone, Dinamismo por persona, tambine nos comentaron que si era como tu Secretaria estaria buenaso, a nosotros nos gusto esa idea y de hecho la teniamos planeada pero considerabamos que se salio un poco del scope del track jaja pero igual es buena idea!

  7. Gael Rs

    Un resumen de que es nuestra solucion :D , proponeoms un sistema que Hable nuestro agente por nosotros, inicia la llamada, para contrarestar la clonacion de voz que es un problema que esta en creciente en esta anio

  8. Gael Rs

    #PANIC mi agente no quiere hablar... D:

  9. Gael Rs

    #AnthonyQuieroPizza

  10. Gael Rs

    Terminamos :D

  11. Gael Rs

    Anthony God dando buena retro!