Si el atacante usa IA, tu motor estático ya perdió

La pelea cambió de cancha

Prácticamente todas las semanas escuchas que vulneraron alguna empresa. El fraude hoy es más rápido, más potente, más inteligente y mucho más capaz que hace dos años. Los defraudadores dejaron de operar manualmente: alquilan GPUs por hora — GPUs cuyo poder para IA se duplica cada año (la Ley de Huang, según NVIDIA), corriendo modelos cuya densidad de capacidad se duplica cada ~3.5 meses (la Densing Law de Xiao et al., publicada en Nature Machine Intelligence en 2025). Lo que hace un año requería un clúster dedicado, hoy lo corre cualquiera en una portátil. Generan variantes de patrones que tu modelo nunca vio en su conjunto de entrenamiento, las prueban contra tu API en paralelo, miden qué pasa, y al día siguiente cambian la jugada.

Tu modelo, mientras tanto, sigue siendo el mismo que entrenaste hace ocho meses. Para estar al día hay que jugar el mismo juego que ellos: en su mundo, a su velocidad. Si no, te quedas con los patrones del año pasado, que hoy son los básicos que cualquier sistema medio decente detecta.

"Modelo entrenado" no es lo mismo que "modelo actualizado"

Hay una confusión común en equipos de fraude que están empezando con ML: pensar que tener un modelo entrenado es tener un sistema de defensa.

No lo es. Tener un modelo entrenado es tener una foto de cómo se veía el fraude el día que cerraste el conjunto de datos. El fraude del mes que viene no está en esa foto.

Hay tres formas en que el modelo pierde vigencia:

1. Deriva de concepto. La definición de "fraude" cambia. Un patrón que era anomalía hoy es ruido legítimo (Black Friday, lanzamiento de un producto nuevo, cambio de geografía).
2. Deriva adversaria. Los atacantes aprenden qué dispara el modelo y se mueven al espacio que el modelo no cubre.
3. Deriva de etiquetas. Los contracargos tardan 30-90 días en llegar. Tu modelo cree que está rindiendo bien hasta que entran los contracargos del trimestre.

La trampa de "tenemos muchos datos"

Durante años escuché lo mismo en todas las reuniones: "necesitamos más datos, datos reales, millones de registros". Es un mito. Lo que realmente importa no es el volumen — es la calidad de los datos y la calidad de los patrones que contienen.

En 500 mil registros puedes tener 20 patrones de fraude claros y aprovechables. En 10 millones puedes tener solo 10. El número grande impresiona en una reunión; los 20 patrones es lo que te baja contracargos.

Y la otra cara: hay empresas con años de datos en su lago de datos, de los cuales solo aprovechan el último año. Por falta de herramientas, falta de conocimiento, falta de experiencia, conformismo. Después arman un discurso sobre "tenemos terabytes de datos" como si el volumen solo significara algo. No significa nada.

El valor real está en los patrones, los ataques, los comportamientos del defraudador impregnados en los datos. Sacar eso afuera requiere herramientas que casi nadie tiene y experiencia que casi nadie quiere construir.

Y el detalle que más duele: incluso si tienes buenos datos y muchos patrones identificados, sin saber qué hacer con ellos son inservibles. Patrones colgando en una presentación no detienen fraude. Patrones convertidos en reglas, listas, características de modelo y límites operativos sí.

Qué significa "evolucionar con el atacante"

Un motor que evoluciona no es solo "reentrenar el modelo más seguido". Eso ayuda pero no alcanza.

Lo que sí funciona:

• Etiquetado continuo, no por lotes. Cada fricción nueva (contracargo, disputa, reversa, queja de cliente) entra al flujo como etiqueta dentro de horas, no de meses.
• Características que cambian de comportamiento, no solo de valor. Si tu característica es "número de transacciones en última hora", está bien. Si tu característica es "velocidad de aceleración de transacciones comparada con la línea base del usuario", mucho mejor — esa estructura aguanta más patrones nuevos.
• Modelos en cascada con tiempos distintos. Un modelo grande, lento, profundo que se reentrena semanalmente. Más reglas y micro-modelos que reaccionan en horas. La cascada permite responder rápido sin esperar al reentrenamiento pesado.
• Pruebas adversarias internas. Tu equipo simula lo que el atacante va a probar. Si nadie en el equipo está pensando "cómo evadiría yo este modelo", el modelo va a quedar viejo solo.

El error clásico: confiar en el puntaje

Cuando un equipo se enamora del puntaje, deja de mirar lo que el puntaje no captura. Y los atacantes operan justamente ahí: en el punto ciego.

He visto sistemas donde la transacción más fraudulenta del trimestre pasó con puntaje bajo porque era estructuralmente nueva: tipo de comercio que el modelo nunca había visto, geografía rara, monto normal. El puntaje dijo OK. Lo único que la habría detectado era un humano mirando, o una regla simple de "si país_origen != país_destino && es_primera_transacción → marcar".

La lección: el puntaje es una herramienta de priorización, no un veredicto. El motor que evoluciona tiene múltiples capas porque sabe que cada capa tiene puntos ciegos distintos.

Lo que sí escala

Si tu equipo es chico y quieres que el motor evolucione sin contratar a 5 científicos de datos:

• Flujo de retroalimentación corto. Que cada decisión humana (el analista marca como fraude, marca como falso positivo) vuelva al modelo en menos de 24h.
• Reglas + ML, no reglas vs ML. Las reglas capturan lo que el modelo no vio. El modelo captura lo que las reglas no codifican. Pelearlos es perder.
• Un tablero semanal de deriva. No necesitas una plataforma de MLOps como la de Google. Necesitas saber cada lunes si la distribución de puntajes se movió, si la tasa de detección bajó, si hay patrones nuevos saliendo.

El estándar mínimo

Para que digas que tu antifraude "evoluciona con el atacante", como mínimo:

• Modelos reentrenándose con datos frescos en ciclos < 30 días.
• Reglas actualizables en minutos, no en semanas (ver Parte 1).
• Pruebas adversarias como práctica del equipo, no como auditoría externa anual.
• Métricas de velocidad de deriva en un tablero que alguien mira a diario — no solo "hay deriva", sino qué tan rápido se rompe.

Cuando hablo con equipos de operaciones de riesgo, la queja se repite: "el puntaje se nos rompe cada vez más rápido". Eso es velocidad de deriva, y la mayoría no la mide. Cuando esa queja aparece como número en un tablero y no como sensación en una reunión, recién ahí estás corriendo a la par del adversario.

Si te falta más de uno de esos, no estás corriendo: el atacante te va a alcanzar antes del próximo trimestre.

Cierre

El motor antifraude no es un modelo. Es un sistema que aprende del adversario tan rápido como el adversario aprende de ti. Cualquier cosa menos que eso, es un sistema que se ve bien hasta el día que se rompe.

En Frauddi estamos construyendo exactamente eso: un motor entrenado contra ataques de IA, no contra un conjunto de datos estático. Si quieres ver cómo funciona, agendá una demo.

Próximo en la serie: Reglas, listas, velocidades, ML, grafos: el problema no es elegir, es combinarlos (Parte 3/8) — el puntaje compuesto como meta-modelo y por qué tu antifraude no debería ser una colección de herramientas sueltas.