El problema: el fraude se decide en milisegundos
Un equipo de pagos que detecta una anomalía a fin de mes ya perdió. El fraude moderno no es un hacker atacando un servidor: son miles de decisiones diminutas, una por transacción, donde cada segundo de espera abre la puerta para que el atacante pruebe con otro método.
El problema real no es solo detectar el fraude. Es el costo invisible del otro lado: los clientes legítimos que tu sistema bloquea. Un retiro bloqueado por error no es un falso positivo en una planilla, es un cliente que llama a tu mesa de ayuda, que pierde la confianza y que no vuelve. Y mientras tanto, el modelo que aprendió de ese bloqueo sigue bloqueando clientes parecidos.
En el sector chileno esto no es un caso teórico. La Comisión para el Mercado Financiero (CMF) publica una serie trimestral de "Fraudes asociados a medios de pago (Ley 20.009)", con la información que reportan bancos, cooperativas de ahorro y crédito, sociedades de apoyo al giro y emisoras de tarjetas de pago, conforme al artículo 11° de la Ley N° 21.234 y la NCG N° 487 (fuente primaria: CMF Chile, https://www.cmfchile.cl/portal/estadisticas/626/w4-propertyvalue-48099.html). Es decir: el regulador exige que el sector reporte el fraude de medios de pago y lo publica trimestralmente. Si quieres el dato vigente del país, ese es el lugar: no un comunicado de prensa ni un artículo de opinión.
Cómo funciona un motor de riesgo con IA
La forma más clara de entenderlo es mirar cómo lo documenta un producto que opera a escala real. Stripe describe su Radar así: "Use el Stripe Radar para evaluar transacciones, cuentas y clientes en tiempo real, usando algoritmos de IA para evaluar el riesgo de fraude" (fuente primaria: documentación oficial de Stripe, https://docs.stripe.com/radar).
Eso resume el flujo completo en tres pasos:
- Recojo de señales. El motor mira la transacción, la cuenta y el cliente: medio de pago, historial, comportamiento, ubicación, dispositivo.
- Puntaje de riesgo. Stripe documenta que la puntuación de riesgo permite evaluar, en tiempo real, el nivel de riesgo de los pagos: la IA devuelve un puntaje, no un veredicto cerrado.
- Decisión. Según reglas y umbrales, el sistema permite, bloquea, revisa o pide autenticación 3DS. Y, clave para el lado humano, existe un paso explícito de análisis manual de pagos sospechosos que requieren una decisión humana, además de alertas cuando se detectan patrones de fraude inusuales.
Lo relevante para tu equipo no es que el producto se llame Stripe. Es el diseño del flujo: puntuar, decidir según umbral, y mandar a revisión humana lo dudoso. Ese es el patrón que se puede replicar con tu propio modelo y tus propias reglas.
Por qué las reglas fijas se quedan cortas
Un motor de reglas puro hace esto: "si la transacción supera X, bloquea". Funciona hasta que el atacante cambia de patrón. Cada regla nueva que agregas endurece la puerta y estrecha la base de clientes legítimos que pasan.
Un modelo entrenado con datos ve la combinación. Puede aprender que "este cliente compra siempre desde este dispositivo, pero hoy la transacción es de otra persona a las 3 AM en otro país" no es lo mismo que "cliente nuevo, primera compra, tarjeta virtual, monto alto". Esa diferencia es exactamente lo que las reglas no alcanzan a expresar.
La otra diferencia es el mantenimiento. Un modelo se reentrena con los casos resueltos: los que el equipo de riesgo marcó como fraude real y los que marcó como falso positivo. Cada revisión humana se convierte en señal de entrenamiento. Sin esa retroalimentación, el modelo envejece y el equipo termina compensando a mano.
El punto que casi nadie implementa: la revisión humana con contexto
El error típico al automatizar fraude es tratar la revisión humana como una molestia. No lo es: es la parte del sistema que produce el mejor dato.
Para que la revisión humana sea útil, el agente que recibe el caso necesita llegar con el contexto ya armado. Stripe lo resuelve con dos mecanismos distintos: alertas de fraude en transacciones (notificaciones cuando detecta patrones inusuales) y análisis manuales de pagos sospechosos. Si tu equipo abre cada caso desde cero —buscando el historial del cliente, el ticket anterior, los otros intentos de la misma tarjeta— estás pagando la lentitud que la IA debía eliminar.
En la práctica, el agente de revisión debería recibir, mínimo: los datos de la transacción que dispararon la alerta, el puntaje de riesgo, el motivo por el que se superó el umbral, las transacciones anteriores del cliente y los casos similares que un analista ya resolvió. Con eso, la persona decide en minutos; sin eso, decide en horas y el cliente se va.
Datos, privacidad y el marco que hay que mirar antes de automatizar
Detectar fraude significa trabajar con datos personales y con datos de pago. Hay dos marcos que conviene tener claros desde el día uno.
Riesgo de IA. El NIST publicó su AI Risk Management Framework 1.0 el 26 de enero de 2023, un marco voluntario que organiza el trabajo en cuatro funciones: Govern, Map, Measure y Manage (fuente primaria: NIST AI RMF Playbook, https://www.nist.gov/itl/ai-risk-management-framework/nist-ai-rmf-playbook). La misma página aclara que el Playbook ofrece acciones sugeridas y que las organizaciones pueden tomar "as many – or as few – suggestions as apply". Para un motor de fraude, el orden importa: antes de medir precisión necesitas mapear qué puede pasar si el sistema falla; antes de mapear, necesitas gobierno (quién decide, quién aprueba umbrales, quién responde).
Regulación sectorial. En Chile, el reporte de fraude en medios de pago no es opcional: es una obligación del sector supervisado por la CMF (art. 11° Ley N° 21.234 y NCG N° 487, fuente primaria: CMF Chile). Si tu solución va a decidir sobre pagos de una institución supervisada, el reporte y la trazabilidad de las decisiones son parte del diseño, no un anexo.
Datos y propiedad intelectual. Cada decisión de riesgo se apoya en datos del cliente. Si esos datos salen de tu infraestructura hacia un proveedor externo, cambian tu perfil de riesgo y tu relación con el cliente. Por eso el flujo de despliegue —dónde vive el modelo, dónde se registran las decisiones y quién puede auditar una decisión de hace seis meses— se decide antes de escribir el primer clasificador.
Lo que hay que medir (y lo que no)
Un motor de fraude se juzga por cuatro indicadores, no por "qué tan moderno" se ve el modelo:
| Indicador | Qué responde | Por qué importa |
|---|---|---|
| Tasa de bloqueo indebido | ¿Cuántos clientes legítimos bloqueé? | Es el costo que tu equipo paga en llamados y en clientes perdidos |
| Pérdida por fraude | ¿Cuánto perdí realmente? | Es el objetivo del negocio, no el del modelo |
| Cobertura por tipo de fraude | ¿Detecto el fraude que me toca? | Un motor que solo detecta tarjetas clonadas no sirve contra la toma de cuentas |
| Deriva del modelo | ¿El puntaje sigue distribuyéndose igual? | La deriva aparece antes que la caída del score |
El error más común es optimizar la precisión sobre el conjunto de entrenamiento y descubrir meses después que el costo real estaba en los bloqueos indebidos. El segundo error más común es no medir la deriva: los patrones de fraude cambian, y un modelo que no se revisa deja de servir.
Un plan de 90 días, en orden
- Semana 1-2: línea base. Mide tu tasa de bloqueo indebido y tu pérdida por fraude hoy, con los datos que ya tienes. Sin línea base no hay forma de demostrar que el modelo sirvió.
- Semana 3-4: motor en modo sombra. El modelo puntúa, pero nadie bloquea. Se compara el puntaje contra las decisiones humanas. Aquí aparecen los falsos positivos que no habías visto.
- Semana 5-8: umbrales y revisión. Activa el flujo de puntuar y decidir con umbral bajo: primero análisis manual, después 3DS, y solo al final bloqueo automático.
- Semana 9-12: retroalimentación. Cada caso resuelto por un analista vuelve al conjunto de entrenamiento. Con eso el modelo deja de envejecer y el equipo deja de compensar a mano.
- Todo el tiempo: auditoría. Registra con qué datos, qué puntaje y qué regla se decidió cada caso. Cuando el cliente pregunte por qué fue bloqueado, la respuesta tiene que existir.
Nota sobre fuentes y cifras
Las afirmaciones técnicas de este artículo (el flujo puntuar → decidir por umbral → revisión humana, la existencia y contenido del AI RMF 1.0 y la obligación de reporte de la CMF) están verificadas en fuente primaria, con las URL citadas arriba. Este artículo no incluye cifras de monto de fraude en Chile: la página de la CMF con los archivos de datos vigentes no pudo descargarse al momento de redactar este texto, y prefiero dejar el dato fuera antes que citar una cifra de prensa sin respaldo primario. La serie trimestral de la CMF es la fuente correcta para ese número.
Próximo paso
Si tu equipo ya tiene volumen de transacciones y un historial de casos resueltos, el siguiente paso no es comprar una plataforma: es revisar si esos datos alcanzan para entrenar un modelo vertical propio.
- Conoce ModelForge: cómo se entrena un modelo con los datos de tu operación, en tu infraestructura.
- Crea tu cuenta: parte con el diagnóstico de tu caso de uso.
- Habla con el equipo: revisamos tus datos, tu objetivo de fraude y te decimos si tiene sentido, o qué te falta.
