team_0x1718
Seguridad
El problema
En Perú, 47% de los usuarios de finanzas digitales estuvo expuesto a fraude o estafas en el último año (encuesta SBS + CGAP 2025). El banco suele detectar la operación rara, pero espera a que el cliente reaccione. Y el cliente está bajo presión, manipulado o sin señal. Del otro lado, el analista de fraude reconstruye a mano, días después, el caso de la cuenta mula que recibió el dinero. Lo que aprende ese equipo no llega a tiempo para proteger a la siguiente víctima.
Para quién
- Clientes de bancos y billeteras: personas a las que estafan, suplantan o que se quedan sin señal.
- Analistas de fraude y AML: reciben un expediente con evidencia en vez de investigar desde cero.
La solución: pausar, preguntar, investigar, aprender
- Pausar. Reglas sin IA y un motor de políticas determinista retienen la operación riesgosa sin bloquear todo. Los pagos habituales pasan al instante.
- Preguntar. El agente Guardián verifica por un canal seguro. Nunca pide claves, y que el cliente no responda no libera el dinero.
- Investigar. El agente Detective analiza la cuenta que recibe el dinero (remitentes nuevos, reenvío rápido, cadena de cuentas). El Auditor arma el expediente con la evidencia citada.
- Aprender. Cuando el analista confirma una mula, la Memoria la recuerda. El siguiente intento contra esa cuenta se frena al instante y sin gastar IA.
La IA recomienda, una política determinista decide y una persona confirma. Ningún agente mueve dinero.
Qué se puede probar
/play: el juego «Te están robando», desde el celular.- Historias: juegas el mismo tipo de estafa dos veces, primero con un aviso genérico y después con nuestra capa.
- La banda: atacas el sistema real.
- 4 arcades: ¿REAL O ESTAFA?, ATRAPA LA MULA, ¿PAUSA O PASA? y SIGUE EL DINERO.
- EN VIVO: salas multijugador por QR, donde toda la sala ataca la capa a la vez.
/monitor: el feed en vivo con los agentes, los expedientes, la encuesta y el ranking.- Cada partida deja datos anónimos de en qué estafas cae la gente y si activaría la protección.
Limitaciones conocidas
- Todos los datos son 100% sintéticos. El banco y la billetera son ficticios. Los resultados del juego son simulaciones con participantes del evento, no datos de producción.
- En el despliegue público los agentes corren en modo simulado, sin un modelo de lenguaje conectado.
- Corre en un solo proceso: los casos y la Memoria viven en RAM, así que un redeploy los borra. El ranking y la encuesta sí persisten.
- Una web no puede saber si estás en una llamada: esa señal se simula en el juego.
Última edición:
Bitácora del equipo
Avances, decisiones y dificultades que el equipo compartió con mentores y jurados.
Anthony Lopez Yrribarren
Definicion de problema y contexto de solucion
Anthony Lopez Yrribarren
Avance: los 4 agentes ya funcionan end-to-end (con mocks)
Qué cambió desde el último update
- Definimos la arquitectura de decisión de los 4 agentes (Guardián, Detective, Auditor, Coordinador) y sus playbooks.
- Construimos el runtime de agentes: adaptadores, prompts, esquemas validados con zod y mocks, para correr sin API key.
- Agregamos el orquestador con una cadena de 2 saltos (investiga la cuenta destino y sigue hacia la siguiente mula), más un set de evals (
npm run evals). - Dejamos lista la integración con la infraestructura backend (contratos compartidos,
ToolContext, señales de Nivel 0).
Por qué La IA recomienda, una política determinista decide y el humano confirma. Ningún agente mueve dinero. Separar así las decisiones nos permite probar cada agente por separado.
Qué funciona (verificado)
- 108 tests pasando en 8 archivos (contratos, decisiones, adaptadores, runtime, mocks, orquestador y evals).
- Los agentes corren completos con
AGENTS_MOCK=1.
Pendiente / bloqueos
- Datos semilla y analytics de la cuenta destino (en curso, lado backend).
- Endpoints de API y pipeline completo conectados a los agentes.
- Deploy con URL pública todavía no hecho.
- UI de la demo.
Qué sigue Conectar el pipeline con los agentes, cargar el caso demo (víctima → cuenta mula → siguiente cuenta) y desplegar.
AlejandraCV01
Avance: el sistema completo corre de punta a punta, y lo auditamos antes del demo
Qué cambió desde el último update
- Backend completo y conectado a los 4 agentes: datos semilla, reglas de nivel 0, Policy Engine determinista (P1–P10), Memoria de riesgo, ledger de evidencia y la API HTTP.
- Pantalla de demo con dos paneles: el celular del cliente y la consola del analista.
- Métricas medidas, no supuestas (
/api/stats): tiempo hasta la acción protectora, % de afirmaciones del expediente con evidencia citada, llamadas de IA que ahorra la Memoria. - Backend del demo jugable: feed en vivo, partidas anónimas y su resumen.
- La laptop como servidor (
npm run servidor): sin serverless, porque el estado vive en memoria y la Memoria tiene que sobrevivir todo el demo.
Por qué La IA recomienda, una política determinista decide y un humano confirma. Ningún agente mueve dinero, y cada decisión guarda su regla para que sea explicable.
Qué funciona (verificado)
- 410 tests pasando, y el demo de los 5 casos de uso da 8/8 comprobaciones.
- CU-03: la segunda víctima de una mula ya confirmada queda protegida con 0 llamadas de IA.
- CU-05 (falso positivo): la bodega legítima recibe de muchas personas igual que la mula, pero no reenvía el dinero, así que su pago pasa.
- En el demo, el 100% de las afirmaciones del expediente cita evidencia que existe (12/12).
Lo que encontramos al auditar Antes del demo probamos 750 combinaciones de ataque (táctica × víctima × destino × monto × respuesta), no solo el guion. Encontramos que, mientras el sistema esperaba la respuesta del cliente, una estafa de "falso banco" hacia una cuenta sin antecedentes se liberaba, y que "no sé" se leía como "no". Lo corregimos, y esa matriz quedó como test permanente.
Pendiente / bloqueos
- Probar con un modelo real: hoy corre en modo simulado y determinista, sin API key.
- Las pantallas del juego (celular y monitor).
- Límite conocido: si la cuenta destino es de otro banco, no vemos a dónde reenvía el dinero.
Qué sigue Correr el demo con el modelo real, ensayarlo completo de corrido y cerrar las pantallas del juego.
Todos los datos son sintéticos y no corresponden a ninguna persona ni cuenta real.
Anthony Lopez Yrribarren
Avance: demo jugable en línea, con juego, monitor y agentes integrados
Demo público: https://web-production-be4c9.up.railway.app (rutas
/playy/monitor)Qué cambió desde el último update
- Integramos los agentes reales con el pipeline del backend: reglas, Policy Engine, Memoria y Auditor. El Guardián conversa en varios turnos.
- Construimos un demo jugable con casos reales de Perú, en el que se juega como víctima o como atacante. Pasó de ser una pantalla simple a un juego 2D de pantalla completa, con toques, música y transiciones, optimizado para móvil.
- Agregamos rutas con desenlaces, intro en video, la sección "LOS DATOS" con contexto por país, los minijuegos arcade "¿REAL O ESTAFA?" y "SIGUE EL DINERO", ranking, estrellas, rangos y logros.
- Hay un panel
/monitorpara ver las partidas y los casos en vivo. - Persistimos jugadores, partidas y ranking en Supabase.
- Desplegamos en Railway con URL pública y volumen persistente.
- Hicimos una auditoría de los agentes antes del demo y corregimos errores de lógica que podían liberar dinero.
Por qué Queremos que el jurado y el público vivan el problema: una estafa en el momento en que ocurre, y cómo pausar, preguntar, investigar y aprender protege a la siguiente víctima.
Qué funciona (verificado hoy)
- El demo responde en producción (
/playy/api/healthdevuelven 200). - 435 de 436 tests pasan.
Limitaciones conocidas
- El test
partidas.test.ts(reciclaje de IDs de caso tras un reset del demo) falla; lo vamos a corregir. - En producción los agentes corren en modo simulado, porque no hay clave de API configurada.
- Los casos y la Memoria viven en RAM, así que un redeploy los borra.
Qué sigue Arreglar el test, probar con gente real, pulir la demo y preparar la presentación y el envío del proyecto.