[Costo Real del Fraude] Si el atacante usa IA, tu motor estático ya perdió (Parte 2/10)

[Costo Real del Fraude] Si el atacante usa IA, tu motor estático ya perdió (Parte 2/10)

---

La pelea cambió de cancha

Prácticamente todas las semanas escuchás 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 fraudsters 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 cluster dedicado, hoy lo corre cualquiera en una laptop. Generan variantes de patrones que tu modelo nunca vio en su training set, 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 quedás 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 dataset. El fraude del mes que viene no está en esa foto.

Hay tres formas en que el modelo pierde vigencia:

1. Concept drift. 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. Adversarial drift. Los atacantes aprenden qué dispara el modelo y se mueven al espacio que el modelo no cubre.
3. Label drift. Los chargebacks tardan 30-90 días en llegar. Tu modelo cree que está rindiendo bien hasta que entran los chargebacks del trimestre.

La trampa de “tenemos mucha data”

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 podés tener 20 patrones de fraude claros y aprovechables. En 10 millones podés tener solo 10. El número grande impresiona en una reunión; los 20 patrones es lo que te baja chargebacks.

Y la otra cara: hay empresas con años de datos en su datalake, de los cuales solo aprovechan el último año. Por falta de herramientas, falta de conocimiento, falta de experiencia, conformismo. Después arman pitch 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 fraudster 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 tenés 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, features 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 (chargeback, disputa, reversa, queja de cliente) entra al pipeline como etiqueta dentro de horas, no de meses.
• Features que cambian de comportamiento, no solo de valor. Si tu feature es “número de transacciones en última hora”, está bien. Si tu feature 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.
• Adversarial testing interno. 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 score

Cuando un equipo se enamora del score, deja de mirar lo que el score 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 score bajo porque era estructuralmente nueva: tipo de comercio que el modelo nunca había visto, geografía rara, monto normal. El score 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 → flag”.

La lección: el score 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 querés que el motor evolucione sin contratar 5 data scientists:

• Pipeline de feedback corto. Que cada decisión humana (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 dashboard semanal de drift. No necesitás MLOps de Google. Necesitás saber cada lunes si la distribución de scores se movió, si el recall 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).
• Adversarial testing como práctica del equipo, no como auditoría externa anual.
• Métricas de velocidad de drift en un dashboard que alguien mira a diario — no solo “hay drift”, sino qué tan rápido se rompe.

Cuando hablo con equipos de operaciones de riesgo, la queja se repite: “el score se nos rompe cada vez más rápido”. Eso es velocidad de drift, y la mayoría no la mide. Cuando esa queja aparece como número en un dashboard 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 vos. 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 dataset estático. Si querés ver cómo funciona, agendá una demo en frauddi.com.

---

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