Cinco agentes que investigan las alertas de fraude en lugar de simplemente asignarles una puntuación.
Vea cómo un sistema de fraude con cinco agentes combina una puntuación de XGBoost con la recopilación de pruebas deterministas, la correlación de registros de inicio de sesión y explicaciones de Gemini que nunca modifican la puntuación.
Fuentes: FraudLens AI: Building AI Agents That Investigate Fraud Like a Human Analyst
Un modelo de fraude es bueno en una cosa: indicarte que una transacción parece sospechosa. Es mucho peor para responder a las preguntas que realmente necesita un analista para cerrar el caso. ¿Qué sucedió aquí? ¿Por qué parece sospechoso? ¿Qué debería hacer alguien al respecto ahora mismo?
FraudLens AI, un proyecto de hackathon para el Google Cloud Hackathon de 2026, está diseñado en torno a ese segundo conjunto de preguntas. No intenta generar una puntuación de fraude más precisa. En su lugar, envuelve una puntuación existente en cinco agentes que colaboran entre sí para llevar a cabo la investigación: recopilan evidencia de comportamiento, alinean los eventos de autenticación, redactan un resumen del caso y permiten que los analistas consulten los datos en un lenguaje sencillo.
Una puntuación no es una explicación
Muchos sistemas de detección de fraudes se detienen en un número como 0.87. El modelo detrás de ellos puede ser excelente para identificar comportamientos sospechosos, pero un investigador que ve ese número aún no tiene idea de qué ocurrió ni por qué le importó al modelo.
Hoy en día, una persona llena ese vacío: abre la cuenta, revisa el historial de transacciones, verifica si el dispositivo ya había aparecido antes, lee los registros de autenticación, compara la actividad reciente con patrones anteriores y, finalmente, redacta una nota del caso que justifique la decisión.
Todo eso es lento y repetitivo, y falla cuando aumenta el volumen de alertas. La idea detrás de FraudLens es mantener el modelo de detección de fraudes tal como está y automatizar la investigación que comienza una vez que el modelo emite una alerta.
Cinco agentes, cinco tareas
La plataforma distribuye la evaluación de riesgos y las investigaciones entre cinco agentes. Cada uno tiene una responsabilidad específica, al igual que los especialistas que dividen el trabajo dentro de un equipo de operaciones contra el fraude.
Agente de detección
La evaluación se realiza mediante un clasificador XGBoost. Fue validado en el conjunto de datos público Kaggle Credit Card Fraud Detection, que cuenta con 284,807 transacciones y 492 casos de fraude confirmados. Los resultados de la validación son los siguientes:
| Métrica | Valor | Interpretación sencilla |
|---|---|---|
| ROC-AUC | 0.985 | clasifica casi siempre el fraude como tal y no como legítimo |
| Precisión en fraude | 82.8% | aproximadamente 1 de cada 6 alertas es falsa |
| Recall en fraude | 82.1% | aproximadamente 4 de cada 5 casos de fraude son detectados |
| F1 en fraude | 82.5% | equilibrio entre las dos métricas anteriores |
Ese conjunto de datos del mundo real se utiliza únicamente para validar el modelo de detección, una distinción que se mencionará nuevamente más adelante.
Agente de investigación
Cuando una transacción supera el umbral de investigación, este agente crea el contexto relacionado con ella. Analiza:
- el comportamiento de la cuenta y el historial de transacciones
- montos que no coinciden con el perfil de la cuenta
- el comportamiento del país y el contexto de la IP
- qué dispositivos están vinculados a qué cuentas
- desviaciones de los patrones históricos
En lugar de presentar Puntuación de riesgo: 0.92, el sistema genera hallazgos sobre los cuales se puede actuar, como por ejemplo “este monto está muy por encima del promedio histórico de la cuenta” o “este dispositivo ha sido utilizado por varias cuentas diferentes”. Dichos hallazgos se incluyen en un archivo estructurado que son utilizados por los siguientes agentes.
Agente de análisis de registros
La actividad de inicio de sesión suele ser la evidencia más sólida que se tiene, especialmente cuando existe la posibilidad de un secuestro de cuenta. El proyecto utiliza un registro de autenticación sintético con eventos como LOGIN_FAILED, LOGIN_SUCCESS, OTP_FAILED, NEW_DEVICE_REGISTERED y PASSWORD_RESET, y este agente compara esos eventos con las transacciones sospechosas.
LOGIN_FAILED (Multiple) ──> OTP_FAILED ──> NEW_DEVICE_REGISTERED ──> SUSPICIOUS_TRANSACTION
Una secuencia como esa le dice mucho más que la transacción por sí sola. Revela señales de intento de apropiación que un modelo que solo analiza los pagos nunca detectaría.
Dónde encaja Gemini y dónde no
Agente de explicación
Google Gemini solo interviene en esta etapa. Los agentes de detección e investigación generan primero pruebas estructuradas, y el agente de explicación entrega esas pruebas a Gemini para que las convierta en una narrativa legible, algo como: esta transacción se marca como CRITICAL porque está muy por encima del comportamiento normal de la cuenta y coincide con actividades inusuales del dispositivo y de inicio de sesión, por lo que necesita una revisión inmediata.
La decisión de diseño importante es que Gemini nunca establece la puntuación de fraude. Esto explica las pruebas de que ya se ha generado código determinista. Eso mantiene la decisión central fiable y significa que una alucinación no puede cambiar si un pago es marcado como sospechoso.
Agente de consultas
Los analistas pueden escribir preguntas como “muéstrame transacciones críticas de Nigeria”. Al modelo no se le permite ejecutar código arbitrario ni SQL en bruto. En su lugar, las llamadas a funciones de Gemini extraen la intención y la convierten en parámetros validados, que luego el código ordinario utiliza para obtener los datos.
Natural Language Request
│
▼
Gemini Function Calling (Intent Extraction)
│
▼
Structured Filters (risk_tier = CRITICAL, country = Nigeria)
│
▼
Application Parameter Validation
│
▼
Controlled Pandas Filtering Layer
│
▼
Filtered Transaction Results
La recuperación de datos se mantiene segura, predecible y fácil de auditar.
Arquitectura y datos
Todo el sistema se entrega como una aplicación Flask en Docker, alojada en Render para la demostración en vivo, con un diseño de contenedores que también funciona en Google Cloud Run.
Una decisión deliberada fue separar las afirmaciones basadas en pruebas de rendimiento de las capacidades de demostración. Los datos de Kaggle se utilizan únicamente para validar la detección, de donde proviene un valor de ROC-AUC de 0.985. Los flujos de investigación en vivo se ejecutan con datos empresariales sintéticos, ya que las pruebas de rendimiento anonimizadas no incluyen campos relacionales como el historial del dispositivo, los registros de inicio de sesión o los enlaces entre cuentas.
┌───────────────────────────────────────┐ ┌───────────────────────────────────────┐
│ REAL KAGGLE DATA │ │ SYNTHETIC ENTERPRISE │
│ 284,807 Transactions │ │ 50,000 Transactions + Logs │
└───────────────────┬───────────────────┘ └───────────────────┬───────────────────┘
│ │
▼ ▼
┌───────────────────────────────────────┐ ┌───────────────────────────────────────┐
│ XGBoost Validation │ │ Live Investigation │
│ ROC-AUC 0.985 | Precision/Recall 82% │ │ Accounts + Devices + Auth Logs │
└───────────────────────────────────────┘ └───────────────────┬───────────────────┘
│
▼
┌───────────────────────────────────────┐
│ Interactive Dashboard │
│ Evidence + Gemini Narrative │
└───────────────────────────────────────┘
Flujo de extremo a extremo
Cuando un analista inicia una investigación, el pipeline se ejecuta en orden: el agente de detección califica la transacción, el agente de investigación reúne pruebas de comportamiento, el agente de análisis de registros agrega contexto de autenticación, el agente de explicación escribe la narrativa, y el resultado se muestra en el panel de control del caso donde el agente de consultas puede investigar más a fondo.
Diseñado para fallar de manera controlada
Las APIs de IA enfrentan límites de tasa de solicitudes y errores de red. Para evitar que esto haga caer la aplicación, el servicio de narrativas de Gemini está completamente separado del pipeline determinista.
Si la llamada a Gemini falla sin esa separación, la página muestra un error 500 y deja de funcionar. Con ella, la aplicación sigue devolviendo todas las métricas de riesgo clave, las marcas de dispositivo, las desviaciones de comportamiento y los detalles de los registros, además de un aviso que no interrumpe el funcionamiento y indica que la explicación está temporalmente fuera de servicio. En el peor de los casos, se obtiene un panel de investigación normal que, aun así, cumple con su función.
Lecciones obtenidas durante el desarrollo
- Sé transparente respecto a los datos. Mantener la validación de puntos de referencia separada de la demostración sintética genera confianza en los revisores técnicos, quienes de lo contrario cuestionarían cada número.
- Reúne pruebas en el código y razona con el LLM. Las reglas y la agregación deben estar en código determinista. La tarea del modelo es transformar esa salida en una explicación natural.
- Pruebe las partes que no necesitan una API en tiempo real. El conjunto incluye 53 pruebas dirigidas al proceso determinista, lo que mantiene una alta fiabilidad sin gastar tokens de API en cada ejecución.
Qué viene a continuación
- ingestión por streaming con Google Cloud Pub/Sub y Dataflow en lugar de procesamiento por lotes
- persistencia nativa en Google Cloud con BigQuery y Firestore
- redes neuronales gráficas para detectar redes de fraude distribuidas en múltiples cuentas
- evidencias multimodales, integrando PDFs de disputas, documentos de identidad y transcripciones de chats en el contexto de Gemini
El principio detrás de ello
El trabajo relacionado con el fraude no termina cuando un modelo imprime una puntuación. Lo importante es determinar qué evidencias explican la alerta y qué debe hacer a continuación el analista. FraudLens lo divide de manera clara: el modelo detecta, el código determinista recopila evidencias, los agentes especializados investigan, y el LLM solo explica.
Leer más
- Sandbox remotos con estado y agentes gestionados antigravedad junto con el GenAI SDK — Dirigir agentes multietapa desde un script: mantener activo un sandbox remoto de Ubuntu, volver a conectarlo mediante el ID del entorno y descargar la instantánea del espacio de trabajo, con dos ejemplos prácticos.
- Por qué los agentes que impresionan en las demostraciones fallan en producción y qué construir en su lugar — Puntos de fallo, el equilibrio entre agente único y múltiples agentes, prácticas de diseño como las reintentos y soluciones alternativas, y el costo total de operar un agente de IA más allá de las tarifas por tokens.