Recién salida de una semana en ACFE Global en Boston (que incluyó muchas más partidas de Uno de las que uno imaginaría), Hailey Windham se sentó con Chen Zamir (Head of Fraud Strategy), Tom Todd (Applied AI Lead) y Ryan McCormack (Director of Engineering) para profundizar en las operaciones de fraude agéntico. Estos Sardines hablaron de todo, desde el ataque de ATO de un cliente que utilizaba sus propios bloques como señal de mutación hasta las brechas de infraestructura que solo se hicieron visibles una vez que la implementación ya se había automatizado.
Te recomendamos encarecidamente que le eches un vistazo a el webinar completo por tu cuenta, pero mientras tanto, aquí tienes un breve resumen de lo que nos pareció más interesante.
Ataques de fraude a velocidad de máquina: un ataque de toma de control de cuenta que aprendió de cada bloqueo
Chen comenzó con la historia de un cliente que estaba lidiando con la toma de control de cuentas. Cada vez que el cliente ajustaba una regla, el ataque regresaba ligeramente diferente, y la respuesta era tan rápida que el equipo empezó a analizar los tiempos.
"Cada vez que se bloqueaba el ataque, la denegación era en realidad una señal que el atacante utilizaba para mutar y cambiar su comportamiento. Literalmente vimos estos cambios ocurrir en milisegundos, y claramente no había un humano detrás de ello."
Se apresuró a decir que esto sigue siendo una pequeña minoría de lo que vemos. Pero la dirección está clara, y fue totalmente sincero: "Ojalá tuviera buenas noticias, solo compren Sardine e intégrennos, y ya está. Nunca es así". Llevar un programa antifraude a la velocidad de las máquinas implica replantearse la organización y los procesos, no solo las herramientas.
El KPI del ciclo de reacción: dónde se esconde realmente una semana de tiempo de respuesta
Si los ataques se adaptan en milisegundos, la pregunta pasa a ser qué tipo de "velocidad" estás midiendo realmente. Una regla se activa en tiempo real, pero el proceso que hay detrás de cambiar esa regla (detectar el problema, delimitar su alcance, diseñar una solución, probarla y finalmente ponerla en producción) puede fácilmente llevar una semana. Chen llama a esto el ciclo de reacción, y ha escrito sobre ello en nuestro blog como el KPI al que la mayoría de los equipos de fraude deberían prestar atención.
Nuestro equipo de ingeniería había pasado años comprimiendo el extremo de despliegue de ese ciclo: un motor de reglas desde el que los analistas pueden desplegar directamente, canalizaciones de modelos automatizadas y pruebas integradas. Ese trabajo dio sus frutos y lo volveríamos a hacer. Pero una vez que el despliegue fue rápido, el tiempo total del ciclo apenas se redujo, lo que significaba que esa semana se estaba escondiendo en alguna parte anterior del proceso.
"En realidad, el cuello de botella que encontramos, y que es un problema mucho más desafiante, está en la intersección entre las investigaciones y las pruebas, quizá no necesariamente en el despliegue y la detección."
A veces, los datos que necesitas nunca se capturaron, o una integración con un proveedor dejó de funcionar silenciosamente hace meses y nadie se dio cuenta. Las etiquetas son otro problema completamente distinto: las devoluciones de cargo tardan semanas, los reportes de fraude pueden no llegar nunca, y tus propias decisiones de bloqueo censuran el historial porque una transacción bloqueada no genera ningún resultado del que aprender. Y luego está la fuga, cuando una regla se comporta bien en las pruebas retrospectivas, se lanza y se desmorona en producción. "Esos problemas pueden volverse bastante grandes y problemáticos, y en algunos casos son difíciles de revertir e incluso de detectar."
Investigación de fraude a escala: huella digital de dispositivos y la red de 150.000 cuentas
Tom mostró cómo se ve el otro lado de esto cuando la infraestructura está en su lugar. Agentes ejecutando búsquedas de patrones en segundo plano, un analista comenzando su día con una regla propuesta que ya incluye el razonamiento adjunto, y la posibilidad de chatear con el agente y objetar antes de que nada se implemente.
Luego explicó paso a paso la investigación sobre la que ya hemos escrito antes: un cliente señaló algunos registros sospechosos, obtuvimos la huella digital del dispositivo compartido, notamos que la IP indicaba EE. UU. mientras que los usuarios estaban realmente en Alemania y en los EAU, y le pasamos todo a nuestro agente analista de datos. El agente trazó las cuentas conectadas y sacó a la luz las señales en común, y el alcance no dejó de crecer. 150.000 cuentas, una red coordinada, y la investigación, desde la primera alerta hasta tener el panorama completo, tomó solo unos minutos.
El siguiente clip muestra a Tom explicándolo paso a paso.
Cuatro escollos en la implementación de agentes de IA en operaciones contra el fraude
Esa investigación funcionó porque la infraestructura de datos que la respaldaba ya estaba en su lugar. Aprendimos lo que ocurre cuando no lo está desde el principio en nuestro propio trabajo agentivo.
Le entregamos a un agente nuestro campo de ID de dispositivo sin explicarle que los ID de dispositivo dependen del almacenamiento del navegador que se puede borrar, que la gente borra sus cookies con frecuencia y que algunos navegadores lo hacen automáticamente. El agente no tenía forma de saberlo: "Estaba marcando constantemente: este es un actor malicioso, tiene 10 dispositivos; este es un actor malicioso, tiene 10 dispositivos". Un solo campo, una sola pieza de contexto que falta. Escálalo a 10.000 características sin semántica asociada y el agente estará produciendo ruido a gran escala.
Los LLMs también vienen con intuiciones incorporadas sobre qué países parecen sospechosos, y una empresa que opera a nivel global tiene que contrarrestarlas con evidencia de sus propios datos en lugar de basarse en los supuestos previos del modelo.
Las decisiones de los analistas humanos parecen ofrecer una base sólida de precisión hasta que realmente auditas qué tan coherentes son esas decisiones de un caso a otro y con respecto al SOP. No pudimos alcanzar los objetivos de precisión que queríamos hasta que depuramos la propia línea de base.
Y darle a un agente acceso sin restricciones a toda tu base de conocimiento puede parecer eficiente, pero esa base de conocimiento contiene suposiciones que antes eran ciertas y ya no lo son, de forma silenciosa, y esas suposiciones orientan las recomendaciones del agente sin que nadie se dé cuenta.
Gobernanza de agentes de IA: habilidad, confianza y secuencia
Chen presentó un marco de implementación durante el seminario web que vale la pena desarrollar aquí.
La competencia de tu equipo con la IA lleva tiempo real en desarrollarse y no se puede acelerar con atajos. Los cronogramas de implementación deben contemplar ese periodo de adaptación, no solo la integración técnica. Chen dijo que sabe con certeza que ahora es un mejor usuario de IA que hace un año, y esa curva de aprendizaje también se aplica a cada analista de un equipo de fraude.
Surgió la pregunta sobre la plantilla, como siempre pasa. Los equipos adoptan la IA y la plantilla se mantiene estable. Eso no es necesariamente un fracaso, pero sí sugiere una brecha de confianza. La solución no es imponer la adopción, sino la transparencia: objetivos claros, supervisión visible e informes que muestren lo que los agentes están haciendo realmente. Sin eso, los equipos siguen haciendo el trabajo manualmente junto al agente en lugar de redirigir su esfuerzo.
El argumento de Chen es que los agentes se gobiernan mediante datos y monitoreo, lo cual es trabajo de analítica, y la mayoría de las organizaciones de fraude aún no tienen esos equipos dimensionados para ello. Esos roles tienen que crecer antes de que nadie hable de reducir operaciones.
El orden en que construyes también importa. Implementar agentes para redactar reglas más rápido no ayuda mucho si tus etiquetas están desactualizadas, porque las reglas se entrenan con una verdad de base deficiente. Si no puedes etiquetar los eventos casi en tiempo real primero, los agentes que escriben reglas más rápido estarán construyendo sobre una base débil.
Por dónde empezar: un marco de auditoría de operaciones contra el fraude
Hailey pidió a cada panelista una cosa para que te llevaras a tu escritorio.
La recomendación de Tom fue la más fundamental: antes de comprar o construir nada, documenta los procedimientos operativos estándar (SOP) de tus operaciones antifraude para cada tarea que realiza tu equipo. Cuando revisas contracargos, ¿cuáles son los pasos concretos? ¿En qué se va la mayor parte del tiempo? Los clientes llegan a Sardine queriendo agentes de IA antes de haber definido qué quieren que haga ese agente, y ese mapeo es gratuito.
Lo de Ryan trataba sobre lo que viene después: decide cómo evaluarás y auditarás el sistema antes de construirlo. ¿Cómo juzgarías si está funcionando? ¿Cómo detectarías los problemas? Esa capacidad de auditoría es más fácil de diseñar desde el principio que intentar añadirla después.
Lo de Chen era sencillo: tu entorno de datos tiene que estar preparado. Suponer que tus datos ya están ordenados y listos para ser consumidos por la IA casi siempre es un error si es solo una suposición y no algo que hayas verificado. Y además de eso, asumir que los agentes pueden manejar datos fragmentados por sí solos es igual de peligroso.
La grabación completa está disponible bajo demanda, y el documento técnico al que el panel hacía referencia constantemente, la “lectura ligera antes de dormir” recomendada por Chen, está aquí.
