El fraude transaccional ya no se combate revisando reglas estáticas en una hoja de cálculo. Una pasarela de pagos europea procesa millones de operaciones al día y dispone de milisegundos para decidir si una transacción es legítima, sospechosa o claramente fraudulenta. En ese intervalo, los modelos de aprendizaje automático evalúan cientos de variables, comparan el comportamiento actual con el historial del titular y devuelven una puntuación de riesgo. Este artículo explica cómo funcionan esos sistemas, qué arquitecturas de detección de anomalías y de malware se utilizan, y qué marco normativo —RGPD, PSD2 y el Reglamento Europeo de Inteligencia Artificial— condiciona su despliegue.
Detección de anomalías: la base estadística del fraude
La detección de fraude es, en su núcleo, un problema de detección de anomalías sobre datos muy desbalanceados: el fraude representa habitualmente entre el 0,1 % y el 2 % de las transacciones. Esa rareza condiciona toda la arquitectura del modelo.
Las técnicas se agrupan en tres familias. La primera es el aprendizaje supervisado, que entrena clasificadores —gradient boosting con XGBoost o LightGBM, regresión logística regularizada o redes neuronales— sobre etiquetas históricas de fraude confirmado. Funciona muy bien con patrones conocidos, pero es ciego ante esquemas nuevos. La segunda familia es la no supervisada, que no necesita etiquetas: el algoritmo Isolation Forest aísla observaciones raras dividiendo el espacio de atributos de forma aleatoria, mientras que los autoencoders aprenden a reconstruir transacciones normales y marcan como anómala toda operación cuyo error de reconstrucción supere un umbral. La tercera, semisupervisada, combina ambas: se entrena con datos mayoritariamente legítimos y se detectan desviaciones.
Un sistema maduro no elige una sola familia. Una entidad financiera típica encadena un Isolation Forest para el cribado rápido, un modelo supervisado para puntuar el riesgo y un motor de reglas auditable para los casos límite que exigen explicación regulatoria.
Ingeniería de variables y aprendizaje en tiempo real
El rendimiento de un detector de fraude depende menos del algoritmo que de las variables que recibe. Las más predictivas son agregaciones temporales: número de transacciones del mismo tarjetahabiente en la última hora, distancia geográfica entre dos compras consecutivas, desviación del importe respecto a la media de los últimos 90 días o frecuencia de uso de un dispositivo nuevo. Calcular estas variables en tiempo real exige una arquitectura de streaming con un almacén de características (feature store) que sirva valores precalculados con latencias inferiores a 50 milisegundos.
Los errores comunes en esta fase son tres. Primero, la fuga de datos (data leakage): incluir como variable información que solo se conoce después de etiquetar el fraude, lo que infla artificialmente la precisión en pruebas. Segundo, no respetar el orden temporal al validar, evaluando con transacciones anteriores a las de entrenamiento. Tercero, ignorar la deriva del modelo (concept drift): los defraudadores adaptan sus tácticas, por lo que un modelo congelado pierde eficacia en semanas y necesita reentrenamiento periódico con monitorización de la distribución de entradas.
Detección de malware con aprendizaje automático
La inteligencia artificial aplicada al malware opera en dos planos. El análisis estático examina el binario sin ejecutarlo: extrae cabeceras del fichero, secuencias de bytes (n-grams), entropía de las secciones —el código empaquetado o cifrado tiene entropía elevada— y llamadas a funciones de la API del sistema. El análisis dinámico ejecuta la muestra en un entorno aislado (sandbox) y registra su comportamiento: conexiones de red, escrituras en el registro, procesos que intenta inyectar. Sobre esas trazas, los clasificadores distinguen comportamiento benigno de malicioso.
La frontera actual es el ataque adversario: pequeñas modificaciones del binario que no alteran su funcionalidad pero evaden al clasificador. Defenderse exige entrenamiento adversario, conjuntos de modelos diversos y, sobre todo, no depender de una única capa de detección. El marco europeo de ciberseguridad ENISA insiste en este principio de defensa en profundidad.
Respuesta automática a incidentes y orquestación
Detectar es solo la mitad. Las plataformas SOAR (orquestación, automatización y respuesta de seguridad) toman la salida del modelo y ejecutan acciones: bloquear una tarjeta, exigir autenticación reforzada, aislar un equipo de la red o abrir un ticket en el centro de operaciones de seguridad. La clave está en calibrar el umbral. Un umbral demasiado bajo genera falsos positivos que bloquean clientes legítimos y disparan llamadas al servicio de atención; demasiado alto deja pasar fraude. La métrica relevante no es la exactitud global —inútil con clases desbalanceadas— sino la precisión y la exhaustividad en la clase fraude, resumidas en la curva precisión-exhaustividad y el área bajo ella.
Un detalle de diseño que distingue a los sistemas maduros es la realimentación. Cada caso revisado por un analista —confirmado como fraude o descartado como legítimo— vuelve al conjunto de entrenamiento como nueva etiqueta. Ese bucle cerrado de aprendizaje permite que el modelo se adapte a las tácticas emergentes sin esperar a un reentrenamiento masivo, pero exige gobernar la calidad de las etiquetas: un analista que marca por inercia degrada el modelo tanto como lo mejora uno que revisa con criterio. Por eso conviene auditar periódicamente la concordancia entre analistas y medir el tiempo medio de resolución como indicador de salud del proceso.
Grafos de relaciones: detectar redes de fraude organizado
El fraude más costoso rara vez es obra de un actor aislado. Las redes de fraude organizado comparten dispositivos, direcciones, cuentas mula o patrones de comportamiento que un modelo transaccional individual no ve, porque analiza cada operación por separado. El análisis de grafos cambia la unidad de observación: modela clientes, dispositivos, cuentas y comercios como nodos, y las transacciones o atributos compartidos como aristas. Sobre ese grafo, los algoritmos de detección de comunidades revelan agrupaciones sospechosas —decenas de cuentas que comparten un mismo dispositivo o canalizan fondos hacia un punto común— que serían invisibles transacción a transacción. Las redes neuronales de grafos llevan esta idea más lejos al propagar señales de riesgo entre nodos vecinos, de modo que la cercanía a un fraude conocido eleva la sospecha sobre los nodos conectados.
| Enfoque | Necesita etiquetas | Detecta fraude nuevo | Explicabilidad | Coste de mantenimiento |
|---|---|---|---|---|
| Reglas estáticas | No | No | Alta | Bajo, pero rígido |
| Supervisado (XGBoost) | Sí | Limitado | Media (con SHAP) | Medio |
| No supervisado (Isolation Forest) | No | Sí | Baja | Medio |
| Autoencoder | No | Sí | Baja | Alto |
Marco normativo: RGPD, PSD2 y AI Act
Cualquier sistema antifraude trata datos personales y decisiones que afectan a personas, por lo que el Reglamento General de Protección de Datos exige base jurídica, minimización de datos y transparencia. El artículo 22 del RGPD limita las decisiones totalmente automatizadas con efectos jurídicos significativos: bloquear un pago lo es, de modo que debe existir intervención humana revisable y el derecho del afectado a obtener explicación. La Directiva PSD2 impone autenticación reforzada de cliente y reconoce explícitamente el análisis de riesgo transaccional como vía para eximir de ese segundo factor cuando el riesgo es bajo, lo que convierte la calidad del modelo en una palanca de experiencia de usuario.
Desde 2024, el Reglamento Europeo de Inteligencia Artificial añade obligaciones de gestión de riesgos, gobernanza de datos y registro de actividad a los sistemas de IA de alto riesgo, categoría en la que pueden caer ciertos usos de evaluación crediticia. La Agencia Española de Protección de Datos publica orientaciones concretas sobre cómo conciliar perfilado y derechos de los interesados.
Pasos para implantar un sistema antifraude con IA
Una implantación realista sigue una secuencia ordenada. Se parte de un inventario de datos y una evaluación de impacto en protección de datos. Después se construye el feature store y una línea base con reglas auditables que sirva de referencia. Sobre esa base se entrena el modelo respetando el orden temporal en la validación, se calibran los umbrales con datos de negocio reales y se despliega en modo sombra —puntuando sin actuar— para medir el impacto antes de activar bloqueos. Finalmente se monitoriza la deriva y se documenta la trazabilidad de cada decisión para auditoría.
Preguntas frecuentes
¿Cuántos datos de fraude se necesitan para entrenar un modelo fiable?
No hay un número fijo, pero con clases muy desbalanceadas importan más los casos positivos que el volumen total. Con unos pocos miles de fraudes confirmados y técnicas de remuestreo o ponderación de clase se obtienen modelos útiles; por debajo de eso conviene apoyarse en métodos no supervisados.
¿La IA sustituye a los analistas antifraude?
No. El modelo prioriza y filtra para que los analistas dediquen su tiempo a los casos ambiguos y de alto importe. La intervención humana, además, es una exigencia legal para decisiones con efecto significativo según el artículo 22 del RGPD.
¿Qué diferencia hay entre falso positivo y falso negativo aquí?
Un falso positivo bloquea a un cliente legítimo y genera fricción y coste de atención; un falso negativo deja pasar fraude real y genera pérdida directa. El equilibrio entre ambos se fija con el umbral, en función del coste relativo que el negocio asigne a cada error.
¿Es obligatorio explicar por qué se bloqueó una transacción?
Cuando la decisión es automatizada y tiene efectos significativos, el afectado tiene derecho a información sobre la lógica aplicada. Por eso conviene usar técnicas de interpretabilidad como SHAP y conservar un motor de reglas auditable junto al modelo.
Conclusión
La detección automática de fraude no consiste en sustituir reglas por un modelo opaco, sino en combinar varias capas —cribado no supervisado, puntuación supervisada y reglas auditables— sobre variables calculadas en tiempo real, y en aceptar que el adversario evoluciona y obliga a reentrenar. El verdadero diferenciador competitivo está en calibrar bien el umbral para minimizar la fricción del cliente legítimo sin abrir la puerta al defraudador, y en hacerlo dentro del marco que imponen el RGPD, la PSD2 y el Reglamento de IA. En Summum acompañamos a entidades financieras y comercios en ese diseño: del inventario de datos al despliegue en modo sombra, siempre con la trazabilidad que exige la auditoría regulatoria.