Cada pocos años, surge una nueva tecnología para la prevención del fraude que promete facilitar el trabajo. Primero fueron las reglas, luego el análisis por lotes y después el aprendizaje automático: cada avance hace que las plataformas antifraude sean más potentes, pero también exige más de las personas que las gestionan.
Inevitablemente, el resultado es una brecha cada vez mayor entre quienes desarrollan plataformas de prevención del fraude y los equipos que las utilizan. Ahora que la IA ha impulsado una nueva ola tecnológica en el sector, cabe preguntarse: ¿ampliará aún más esa brecha?
Conclusiones clave: por qué la plataforma está ganando y tu equipo no
- Cada gran ola tecnológica en las plataformas antifraude, desde los sistemas basados en reglas hasta el aprendizaje automático, amplió la brecha entre los equipos que desarrollan estas plataformas y los que las utilizan, porque los proveedores restringen el acceso a sus datos y al conocimiento sobre la plataforma.
- La brecha entre quienes desarrollan plataformas antifraude y quienes las utilizan tiene dos causas fundamentales. La primera es la falta de acceso directo a la plataforma antifraude, incluido el acceso mediante SQL y al almacén de datos. La segunda es la falta de conocimiento sobre la plataforma del proveedor de soluciones antifraude, incluidos los esquemas de datos, las definiciones de las características y el funcionamiento de los modelos.
- Los agentes de IA que actúan como middleware de IA para la detección del fraude revierten esta tendencia al traducir las solicitudes de los analistas expresadas en lenguaje natural a las definiciones exactas de la plataforma, realizar comprobaciones de sensibilidad de las puntuaciones de fraude y crear reglas directamente a partir de los patrones observados, sin la intervención del proveedor.
- La prueba práctica en cualquier evaluación de una plataforma antifraude consiste en preguntar al proveedor qué parte de la plataforma podría gestionar su equipo sin la ayuda del personal del proveedor. La respuesta le indicará si está ante una herramienta o una dependencia.
La brecha entre quienes desarrollan plataformas antifraude y quienes las utilizan
Toda plataforma antifraude implica a dos grupos de personas. Los desarrolladores diseñan los datos, las funcionalidades, el motor de reglas y los modelos. Los profesionales son los analistas y responsables de fraude que la utilizan a diario para supervisar, investigar y ejecutar decisiones.
Cuando los desarrolladores y los profesionales trabajan en la misma empresa, un analista que no entiende cómo calcula la plataforma un dato puede preguntárselo al ingeniero que la creó y, por lo general, recibir una respuesta ese mismo día.
Pero cuando la plataforma procede de un proveedor, el analista es un cliente de pago. No puede sentarse junto al equipo de ingeniería del proveedor, y este tiene buenas razones para reservarse algunos detalles sobre sus datos y modelos. Es su fórmula secreta.
Así que, en muchos casos, las empresas pagan por la plataforma completa, pero terminan utilizando solo las partes que su equipo realmente entiende. Y si observamos cómo ha evolucionado el sector de la prevención del fraude, podemos ver que esto no ha hecho más que empeorar con el tiempo.
Las primeras herramientas contra el fraude eran pantallas de revisión. Mostraban al investigador quién estaba detrás de una transacción o solicitud de alta y qué intentaba hacer esa persona, y registraban la decisión de aprobarla o rechazarla. El software mostraba información, y el investigador se basaba en su propio criterio para relacionar los datos y analizarlos antes de decidir qué hacer con el evento.
Más adelante, los equipos de fraude convirtieron ese criterio en reglas, que un motor de reglas ejecuta en tiempo real para cada evento. Para detener un patrón mediante una regla, el analista debía saber cómo se manifiesta ese patrón en los datos de la plataforma. Esto implica conocer qué variables existen (una variable es un dato individual que calcula la plataforma, como el número de cuentas vinculadas a un mismo dispositivo), qué significa cada una y cómo combinarlas.
Con la analítica avanzada, los analistas podían programar tareas que se ejecutaban por lotes al final del día o de la semana. Entre ellas se incluían la detección de anomalías, la agrupación de cuentas en redes y la elaboración de informes sobre patrones demasiado complejos para calcularlos mientras una transacción esperaba una decisión. Quienes quisieran ejecutar estas tareas internamente se enfrentaban a requisitos aún mayores. Tenían que comprender el esquema de datos (la forma en que la plataforma organiza y almacena sus datos). También debían escribir las tareas en SQL, el lenguaje estándar para consultar bases de datos, o mediante código que se ejecutara de forma programada.
Después, los proveedores incorporaron modelos de aprendizaje automático que asignan una puntuación de riesgo a cada evento. Entender por qué un evento concreto obtuvo una puntuación alta es la parte fácil, pero decidir qué hacer con esa puntuación es más difícil. Alguien tiene que establecer un umbral, es decir, la puntuación a partir de la cual la plataforma rechaza o somete a revisión un evento. Como un único umbral rara vez se adapta a todos los productos, regiones y tipos de usuario, la mayoría de los equipos necesitan varios.
Establecer umbrales para cada segmento requiere acceso a los datos y las habilidades necesarias para consultarlos. También exige saber en qué variables se basa el modelo y realizar análisis de sensibilidad, que permiten comprobar cuántos usuarios legítimos se rechazan y cuánto fraude se detecta al modificar el umbral. Para ello se necesitan conocimientos especializados del sector, capacidad técnica y acceso a los datos.
Pero un análisis realista del sector lleva a concluir que la mayoría de los equipos de prevención del fraude no cuentan con estas capacidades, a menos que hayan desarrollado su propia plataforma.
Generación | Qué hace la herramienta | Lo que exige al equipo de fraude |
Revisar pantallas | Muestre al investigador quién está detrás de una transacción o solicitud y qué intenta hacer; a continuación, registre la decisión de aprobarla o rechazarla. | Criterio. El investigador coteja los datos y analiza manualmente cada evento |
Reglas | Aplique el criterio del equipo como reglas a cada evento en tiempo real | Saber qué funciones existen, qué significa cada una y cómo combinarlas |
Analítica avanzada | Ejecutar trabajos por lotes programados para la detección de anomalías, la agrupación de cuentas y la generación de informes demasiado complejos para procesarlos en tiempo real | Comprender el esquema de datos y escribir los procesos en SQL o en código programado |
Aprendizaje automático | Asigna una puntuación de riesgo a cada evento | Elegir umbrales para cada segmento, lo que requiere acceso a los datos, habilidades para realizar consultas, conocer qué características utiliza el modelo y hacer análisis de sensibilidad |
El proveedor restringe el acceso a conocimientos esenciales sobre la plataforma
Cuando pensamos en las carencias de los equipos de fraude, solemos centrarnos en habilidades técnicas como SQL y programación. Sin embargo, una empresa puede capacitar a su personal en esas áreas o contratar a personas que ya las dominen. Hay otros dos requisitos mucho más difíciles de cumplir para un equipo de fraude: acceso sin restricciones a los datos del proveedor y conocimiento del funcionamiento interno de la plataforma.
La mayor ironía en la lucha contra el fraude es que gran parte de aquello por lo que una empresa paga a un proveedor de soluciones antifraude son datos que su propio equipo no puede consultar. Esto incluye variables que el propio proveedor calcula, señales que obtiene de proveedores especializados en ámbitos como el correo electrónico o la inteligencia de dispositivos, y datos compartidos por consorcios que recopila de sus otros clientes.
Al mismo tiempo, los equipos de prevención del fraude suelen carecer de conocimientos esenciales sobre cómo operar la propia plataforma. Conocer la plataforma implica entender cómo organiza el proveedor sus datos y crea sus variables, cómo calculan sus modelos las puntuaciones de riesgo y cómo se ejecutan sus reglas. Sin estos conocimientos, incluso un equipo con acceso completo a los datos se queda bloqueado.
Velocidad es un buen ejemplo de este tipo de funciones. Estas contabilizan cuántas veces ocurre algo dentro de un intervalo de tiempo, como los intentos de pago con tarjeta desde un mismo dispositivo durante la última hora. El hecho de que el intervalo sea móvil (siempre los últimos 60 minutos) o fijo (se reinicia al comienzo de cada hora) cambia la forma en que se debe redactar una regla. Una ráfaga de 10 intentos que se produce justo antes y después del cambio de hora se contabiliza como dos ráfagas más pequeñas en un intervalo fijo, por lo que una regla diseñada pensando en un intervalo móvil podría no detectarla.
O pensemos en un patrón que un analista detecta en nuevos registros: direcciones de correo electrónico formadas por un nombre, la primera letra de un apellido y dos dígitos, como johnd42 y sarahk17. El analista debe determinar si alguna funcionalidad permite detectar este patrón, si se necesita una sola o una combinación de varias y si estas requieren una definición específica para funcionar en el motor de reglas. Cada respuesta depende de cómo haya diseñado la plataforma el proveedor.
Se podría argumentar que los buenos proveedores ofrecen a sus usuarios documentación exhaustiva, sesiones de formación y asistencia en directo para responder a preguntas puntuales. Y sería cierto. Pero la documentación y la formación sencillamente no bastan en sistemas tan complejos.
De hecho, durante años los proveedores han intentado poner este conocimiento al alcance de sus usuarios mediante paneles de control, informes, documentación, formación y equipos de éxito del cliente. Pero cada uno de estos esfuerzos se enfrenta a la misma disyuntiva: ofrecer demasiado poco o demasiado.
Las herramientas que dan acceso a los datos no pueden seguir el ritmo de la demanda. El fraude varía de una empresa a otra y cambia de una semana a otra, por lo que los equipos de prevención del fraude necesitan constantemente una nueva vista, segmento o filtro que los paneles existentes no ofrecen. Cada empresa tiene una larga lista de preguntas que quiere plantear, y ningún proveedor puede crear un informe para cada pregunta, y mucho menos para cada cliente.
La documentación tiene el problema opuesto. Un proveedor puede documentar sus 2.000 puntos de datos, pero un analista que está redactando una regla solo necesita uno de ellos, y encontrarlo y entenderlo resulta difícil incluso con buenas funciones de búsqueda y filtrado.
Como resultado, los equipos de prevención del fraude reciben abundantes instrucciones y formación, pero tienen muy poco acceso directo a los datos o ayuda para interpretarlos, que es precisamente lo que más necesitan para tomar decisiones claras.
El middleware de IA agéntica invierte la tendencia
Dada la brecha cada vez mayor entre quienes crean la tecnología y quienes la utilizan, cabría esperar que la IA añadiera otra capa de complejidad y empeorara aún más la situación. Sin embargo, en realidad, la IA agéntica invierte esta tendencia.
Los proveedores desarrollaron las primeras funciones de IA de las plataformas antifraude a partir de su propia documentación, en forma de asistentes a los que los usuarios podían preguntar cómo funcionaba la plataforma. Los usuarios obtuvieron mejores respuestas con mayor rapidez, y los proveedores comprobaron que la IA podía actuar como una capa de «middleware» entre la plataforma y quienes la utilizaban.
Pero los agentes de IA también pueden facilitar a los usuarios el acceso a áreas que hasta ahora les estaban completamente vedadas. Al asumir una función ampliada de «middleware» dentro de una plataforma, permiten a los usuarios comunicarse con ella y utilizarla de forma más eficaz. Los agentes traducen una pregunta o necesidad expresada en lenguaje sencillo a las definiciones exactas que requiere la plataforma y, a continuación, devuelven una decisión, un informe o los datos necesarios. También pueden atender solicitudes puntuales y específicas de cada empresa para las que ningún equipo de producto podría crear un panel de control.
Ejemplo A: creación de reglas antifraude mediante IA a partir de un patrón de registro
Pensemos en la analista que detectó registros con direcciones de correo electrónico como johnd42 y sarahk17. Ha encontrado varias cuentas de este tipo y quiere impedir que se creen más.
Un agente de análisis de datos toma las cuentas que ella marcó y hace dos cosas con ellas. Busca más cuentas que coincidan con el mismo patrón, lo que le proporciona más datos con los que trabajar y un conjunto más amplio de cuentas sobre las que actuar. También examina el esquema de datos para encontrar las características y los valores exactos que describen el patrón, de modo que su descripción informal (nombre, inicial del apellido y dos dígitos) se convierte en una definición precisa en el «vocabulario» propio de la plataforma.
A continuación, un agente de creación de reglas convierte esos hallazgos en una regla para el motor de reglas en tiempo real de la plataforma. Esta tarea es distinta de escribir una consulta de base de datos, ya que, en tiempo real, estas características tendrían convenciones de nomenclatura diferentes y algunas podrían no estar disponibles. El agente también puede ayudar a ajustar la regla para detectar el mayor número posible de fraudes y rechazar al menor número posible de usuarios legítimos, lo que permite mantener un nivel bajo de falsos positivos.
La IA proporciona las dos cosas que el analista no puede obtener por sí solo: acceso a los datos del proveedor y conocimiento de cómo los representa la plataforma.
En Sardine, el Agente Asistente de Reglas y el Agente Analista de Datos realizan este trabajo dentro de la plataforma. Descubre cómo nuestros agentes de IA ayudan a los equipos de prevención del fraude.
Ejemplo B: Configuración del umbral de puntuación de fraude por segmento
El mismo enfoque sirve para aprovechar el aprendizaje automático de forma más eficaz. Supongamos que un responsable de fraude quiere saber cómo establecer los umbrales de rechazo de su modelo. Puede pedirle a un agente analista de datos que divida la base de usuarios en sus principales segmentos, como el flujo del producto (registro, pago, retirada), la región, el método de pago y el tipo de cuenta.
Para cada segmento, el agente realiza un análisis de sensibilidad y determina el umbral que mejor se ajusta al objetivo elegido por el responsable. Ese objetivo puede ser una tasa de rechazo determinada, un nivel de precisión o un nivel de exhaustividad. También se puede solicitar el mismo análisis para tres niveles de tolerancia al riesgo, desde conservador hasta agresivo, y obtener una tabla de umbrales recomendados para compararlos en paralelo.
Antes, este análisis requería conocer el esquema de datos, tener experiencia en la realización de análisis de sensibilidad y, sobre todo, disponer de acceso al almacén de datos del proveedor de soluciones contra el fraude, algo que la mayoría de los equipos sencillamente no tiene. Por tanto, o bien estaba fuera de su alcance o bien tenían que solicitárselo al proveedor, normalmente con un coste asociado. Sin embargo, con un agente, el equipo de fraude puede realizar el análisis, tomar la decisión y repetirlo cada mes a medida que cambian los patrones de fraude, sin tener que esperar al proveedor.
Qué capacidades de IA buscar
Cada ola tecnológica anterior aumentó la distancia entre las plataformas de prevención del fraude y los equipos que las utilizan. Ahora, los agentes están empezando a reducirla, y su mayor impacto hasta la fecha consiste en ayudar a las empresas a sacar mucho más partido de las plataformas por las que ya pagan.
Eso también cambia lo que los desarrolladores pueden ofrecer, ya que pueden incorporar sistemas de detección más sofisticados sin exigir más a las personas encargadas de operarlos.
Hay mucho en juego. La encuesta de Trustpair sobre las tendencias del fraude en 2026 reveló que el 58 % de los altos responsables de la toma de decisiones financieras cree que los estafadores evolucionan ahora más rápido de lo que las personas pueden reaccionar.
Para cualquiera que esté eligiendo una plataforma contra el fraude, comprobar que cuenta con IA es el punto de partida obvio, pero también resulta demasiado genérico. La siguiente pregunta es si esas capacidades ayudan a su equipo a sacar más partido de la plataforma o si esta sigue siendo una caja negra: cuando su equipo no puede acceder a los datos, no puede ver cómo funciona ni convertir esa información en decisiones claras.
Según esa definición, muchas plataformas antifraude con modelos bien explicados siguen siendo cajas negras.
Uno de los principales aspectos que hay que buscar es una IA que permita a su equipo acceder a los datos y al funcionamiento interno de la plataforma. Una forma sencilla de comprobarlo en una reunión con un proveedor es preguntar qué parte de la plataforma podría gestionar su equipo sin ayuda del personal del proveedor.
La respuesta te dirá si estás comprando la plataforma completa o solo el 10 % al que tu equipo puede acceder.
Profundiza en Cómo implementar agentes de IA confiables para combatir los delitos financieros que permitan a tu equipo antifraude trabajar con independencia de la plataforma.
Preguntas frecuentes
¿En qué consiste el problema de la caja negra en las plataformas antifraude?
Una plataforma antifraude es una caja negra cuando el equipo que paga por ella no puede acceder a sus datos, no puede entender cómo sus modelos puntúan los eventos ni puede convertir ese conocimiento en reglas o decisiones operativas sin la ayuda del proveedor. El problema se agrava con el tiempo porque cada nueva capa tecnológica, desde las reglas y el análisis por lotes hasta el aprendizaje automático, exige más conocimientos técnicos y un mayor dominio específico de la plataforma para utilizarla eficazmente.
¿Qué es el middleware de IA para la prevención del fraude y cómo ayuda?
El middleware de IA para la prevención del fraude es una capa de agentes de IA que se sitúa entre el equipo antifraude y la plataforma del proveedor. Traduce solicitudes formuladas en lenguaje natural a las definiciones internas de la plataforma, consulta directamente los datos del proveedor y genera reglas operativas, informes o recomendaciones de umbrales. De este modo, los equipos antifraude pueden acceder a funciones de la plataforma que antes solo estaban disponibles a través del personal del propio proveedor.
¿Cómo funciona en la práctica la creación de reglas antifraude con IA a partir de patrones?
Un analista de fraude identifica un patrón sospechoso, como direcciones de correo electrónico creadas a partir de una fórmula predecible, y se lo describe en lenguaje natural a un agente de análisis de datos. El agente busca en los datos de la plataforma otras cuentas que coincidan con el patrón, identifica las características y los valores exactos que lo definen en el esquema de la plataforma y transmite sus hallazgos a un agente de creación de reglas, que genera una regla funcional para el motor de reglas en tiempo real e incluye el ajuste de falsos positivos de la regla de fraude para minimizar el impacto en los usuarios legítimos.
¿Qué es la configuración del umbral de puntuación de fraude y por qué requiere acceso a los datos?
Establecer un umbral de puntuación de fraude implica elegir la puntuación a partir de la cual la plataforma rechaza o somete a revisión un evento. Dado que un único umbral rara vez resulta adecuado para todos los productos, regiones y tipos de usuario, la mayoría de los equipos necesitan varios, cada uno de los cuales requiere un análisis de sensibilidad de la puntuación de fraude que muestre cuántos usuarios legítimos se rechazan y cuánto fraude se detecta a medida que cambia el umbral. Este análisis requiere acceso al almacén de datos del proveedor y conocimiento del esquema de datos de la plataforma, precisamente aquello de lo que carecen la mayoría de los equipos antifraude si no cuentan con la colaboración del proveedor.
¿Cómo puedo evaluar si una plataforma antifraude le dará a mi equipo una autonomía real?
Pregunte directamente al proveedor qué parte de la plataforma podría gestionar su equipo sin la intervención del personal del proveedor. Una plataforma que depende del proveedor para realizar consultas de datos, ajustar reglas, establecer umbrales e interpretar funcionalidades supone un riesgo de dependencia del proveedor, no es una herramienta. En cambio, una plataforma en la que los agentes de IA proporcionan a su equipo acceso directo a la plataforma antifraude, acceso a SQL y conocimiento a nivel de esquema es una plataforma que su equipo realmente puede operar a la velocidad que exige la lucha contra el fraude.
Ponte en contacto con el equipo de Sardine para saber qué parte de tu configuración actual podría funcionar sin que el proveedor estuviera presente.
