Detección de fraude: aprendizaje automático frente a reglas

Última actualización: septiembre de 2026

La detección de fraude mediante aprendizaje automático califica una transacción o un cliente comparándolos con patrones aprendidos de resultados históricos etiquetados, y devuelve una probabilidad en lugar de un veredicto. Esa única propiedad es lo que la diferencia de una regla, y también es la razón por la que la pregunta que los equipos de fraude siguen debatiendo (¿reglas o modelos?) es la pregunta equivocada. Las reglas y los modelos responden a preguntas diferentes. Cualquier programa que opere a gran escala ya utiliza ambos.

La pregunta verdaderamente útil es más acotada y mucho más fácil de responder: ante una decisión de fraude específica, ¿qué mecanismo debería gestionarla? Este artículo responde a eso, y también a lo que le debes a un regulador y a un cliente rechazado cuando un modelo ha tomado la decisión.

Resumen rápido

• La detección de fraude mediante aprendizaje automático aprende de resultados etiquetados y genera una probabilidad. Una regla establece una decisión tomada por la institución. Son herramientas distintas, no versiones que compiten entre sí.

• Los modelos no pueden aprender de fraudes que nunca se detectaron ni se etiquetaron. Este límite es estructural, y es la razón por la que las nuevas tipologías y las obligaciones regulatorias siguen perteneciendo a las reglas.

• El verdadero punto de comparación no es la precisión. Es la explicabilidad, la latencia, la disponibilidad de etiquetas y quién puede cambiar la lógica sin tener que esperar a un ingeniero.

• La explicabilidad no es una propiedad del modelo que se declara en una ficha técnica. Es una propiedad operativa, y el lugar para medirla es la cola de revisión.

• Los modelos se degradan de forma silenciosa. Las reglas se degradan de forma visible. Esa asimetría, y no la precisión, es el argumento para monitorear la desviación por segmentos.

Qué es la detección de fraude mediante aprendizaje automático

La detección de fraude mediante aprendizaje automático es un método que califica un evento (una transacción, un inicio de sesión, una solicitud) comparando sus atributos con patrones aprendidos de resultados históricos que fueron etiquetados como fraude o legítimos. El resultado es un número: la probabilidad de que este evento se parezca al fraude con el que se entrenó el modelo.

Ese resultado es una probabilidad, no un veredicto, y esta distinción importa más que cualquier otra cosa en esta comparación. Una regla devuelve una decisión. Un modelo devuelve un nivel de certeza. De todos modos, otro componente tiene que decidir qué hacer con eso: aprobar, rechazar, solicitar verificación adicional o derivar a un analista humano.

Por eso, preguntar "¿deberíamos usar reglas o modelos?" no tiene sentido. Un modelo no toma decisiones. Produce una señal que consume una capa de decisión. Los modelos y las reglas de detección de fraude ocupan posiciones diferentes en el mismo proceso.

Cómo decide realmente un modelo

Ocurren cuatro cosas entre la llegada de un evento y la recepción de una puntuación.

Variables (Features). El modelo no ve una transacción. Ve variables: atributos derivados del evento y de su contexto. El monto, la hora del día y la categoría del comercio son los más obvios. Los que realmente importan suelen ser relacionales y temporales: cómo se compara este monto con el historial de este cliente, cuántos intentos lo precedieron, cuánto tiempo lleva activa la cuenta o cómo se comportó el dispositivo antes de llegar a la página de pago. El diseño de variables es donde se concentra la mayor parte del trabajo real de aprendizaje automático para la detección de fraude, y es la parte que se suele omitir en las discusiones generales sobre modelos.

Entrenamiento con resultados etiquetados. El modelo aprende al mostrarle eventos históricos junto con lo que resultó ser cierto sobre ellos. El aprendizaje supervisado a partir de casos de fraude etiquetados requiere que alguien, en algún momento, haya marcado correctamente un caso como fraude. El límite del modelo es la calidad y la cobertura de esas etiquetas.

Calificación en tiempo real. En producción, el mismo conjunto de variables se procesa en vivo y el modelo devuelve una puntuación en los milisegundos disponibles antes de que se autorice un pago. La detección de fraude en tiempo real es una limitación de latencia para toda la infraestructura tecnológica, no solo una propiedad del modelo en sí; las variables deben poder calcularse a tiempo, lo que con frecuencia es el límite restrictivo.

El problema de las etiquetas. Aquí está el límite real. Un modelo solo puede aprender del fraude que ya fue detectado y etiquetado. El fraude que pasó sin ser detectado es invisible para el modelo, porque nada en los datos de entrenamiento indica que ocurrió. Esto no es un fallo de un modelo en particular. Es una propiedad estructural de aprender a partir de resultados pasados, y limita lo que se puede esperar razonablemente que cubra un modelo.

El problema de las etiquetas afecta más donde las pérdidas tardan en aparecer o nunca se atribuyen correctamente. El fraude de primera persona es el caso clásico: el cliente es el perpetrador, los reclamos llegan meses después y muchos casos se registran como pérdida crediticia en lugar de etiquetarse como fraude. Un modelo entrenado con esas etiquetas aprende una imagen distorsionada de la realidad.

Qué siguen haciendo mejor las reglas

Las reglas no son una tecnología obsoleta que los modelos están reemplazando gradualmente. Hay cuatro tareas que les pertenecen y seguirán perteneciendo a ellas.

Obligaciones deterministas. Un límite regulatorio no es una probabilidad. Un requisito de sanciones no es una probabilidad. Cuando una institución está obligada a actuar ante un límite específico, ese límite debe establecerse de forma categórica. Intentar modelarlo sería un error y resultaría inexplicable.

Nuevas tipologías sin etiquetas previas. Un nuevo patrón de ataque aparece un martes por la mañana. Se puede escribir una regla esa misma mañana. No se puede entrenar un modelo para ello, porque los ejemplos etiquetados aún no existen y tardarán semanas en aparecer. Las reglas son la forma en que un programa responde durante el periodo en que los modelos no tienen datos de los que aprender.

Intención auditable. Una regla define lo que la institución decidió hacer, en un lenguaje que un regulador puede leer directamente. Esto es un recurso muy diferente a una puntuación con un umbral asociado. Cuando la pregunta es "cuál era su política", una regla es la respuesta en el formato que se espera.

Velocidad de cambio bajo control humano. El responsable de riesgo puede ajustar una regla sin necesidad de pasar por un ciclo de reentrenamiento del modelo ni de abrir un ticket de desarrollo para ingeniería. Cuando la respuesta a "quién tiene que cambiar esto y para cuándo" es "el equipo de riesgo, para el viernes", esa decisión debe implementarse mediante una regla.

Nada de esto requiere profundizar en la creación de reglas, su ciclo de vida o cómo se construye un motor de reglas. El punto aquí es más concreto: las reglas son una de las dos partes de una estructura de decisión, y estas cuatro tareas son la razón por la que esa parte es permanente.

La comparación que nadie está haciendo en realidad

El dilema entre reglas o aprendizaje automático describe un debate que las instituciones operativas en realidad no están teniendo.

En una conversación reciente, una empresa de pagos de EE. UU. describió su arquitectura actual de manera sencilla: un motor de reglas interno que se ejecuta en producción, junto con capas de socios y proveedores que aportan modelos de aprendizaje automático. Ambos a la vez. No se describió como una migración en curso ni como una solución temporal de compromiso. Se describió como el diseño habitual del sistema.

Este es el caso común, no la excepción. También es la razón por la que los equipos que evalúan software de detección de fraude se dan cuenta de que el debate entre reglas o modelos ya está resuelto cuando llegan a su lista de opciones preseleccionadas; lo que realmente comparan es qué tan bien funciona cada plataforma con ambos sistemas. Lo que significa que el argumento principal de los proveedores (cuál es más preciso) no es el factor decisivo. Los criterios reales son cuatro:

• Explicabilidad. ¿Qué explicaciones debes dar, a quién y con qué rapidez?

• Latencia. ¿De cuánto tiempo se dispone para tomar la decisión y se pueden calcular los datos necesarios dentro de ese plazo?

• Disponibilidad de etiquetas. ¿Existen resultados etiquetados suficientes para esta decisión?

• Gestión del cambio. ¿Quién debe poder cambiar la lógica y requiere esto la intervención de un ingeniero?

El enfoque más maduro que surge de estos criterios es utilizar las reglas como límites de seguridad en torno a los resultados probabilísticos. El modelo califica. Las reglas limitan lo que se puede hacer con esa calificación: qué puede autorizar por sí misma, qué debe derivar a revisión y qué no puede ignorar bajo ninguna circunstancia.

Un modelo para ubicar cada decisión

Toma una decisión de fraude específica y hazte estas cuatro preguntas en orden. La primera respuesta que resuelva el caso cierra el proceso.

1. ¿Es una obligación o un criterio de evaluación? Las obligaciones son reglas. Siempre. Si una regulación, un requisito de la red de pago o un compromiso contractual especifica la acción ante cierto límite, se establece como una regla y no se modela.

2. ¿Existen resultados etiquetados suficientes para ello? Sin etiquetas no hay modelo, por muy buena que sea la intención. Si las pérdidas en esta categoría aparecen tarde, se atribuyen a otra causa o nunca se revisaron, los datos de entrenamiento no reflejarán el problema y el modelo se equivocará con total seguridad.

3. ¿Qué debes explicar y a quién? Explicar un rechazo a un agente de atención al cliente, a un regulador o a un comité interno de riesgo de modelos son tres niveles de exigencia muy distintos. Esto determina el nivel de interpretabilidad que debe tener el mecanismo, y si la explicación debe llegar al analista que gestiona el caso o si basta con que quede registrada en un archivo.

4. ¿Quién debe cambiarlo y con qué rapidez? Si el equipo de riesgo necesita ajustarlo esta semana sin depender de un desarrollo de ingeniería, debe ser una regla, independientemente de que un modelo pudiera, en teoría, calificarlo mejor.

Una vez aplicado, el modelo distribuye las decisiones de esta manera:

Cada fila responde a las mismas cuatro preguntas en orden. La tercera columna es la que los equipos suelen pasar por alto con más frecuencia, y suele ser la que cambia por completo la respuesta.

Una vez asignada la decisión, el siguiente reto es ajustar el umbral en el que se apoya (hasta qué punto ajustar una puntuación antes de que se sature la cola de revisión). Esa es una tarea distinta a la asignación de decisiones y merece su propio análisis.

Cómo funcionan ambos sistemas juntos en la práctica

La detección y la toma de decisiones son procesos independientes. Lo que genera una señal no tiene por qué ser lo que decida el resultado, una distinción que un consultor de cumplimiento de delitos financieros planteó claramente al separar la gestión de alertas del motor que las genera. Una vez aceptada esta separación, los patrones de integración son muy sencillos.

Las reglas limitan los resultados del modelo. Mínimos, máximos, rangos de revisión obligatorios y bloqueos absolutos que una puntuación nunca puede ignorar. Un modelo puede sugerir la aprobación de un caso; una regla decide que este cliente, en esta jurisdicción y por este monto, requiere revisión humana de todos modos.

Los modelos enriquecen las variables de las reglas. Una regla no tiene por qué activarse únicamente con un dato bruto. Puede activarse utilizando una puntuación de riesgo calculada como una de sus condiciones; así es como una política determinista aprovecha el valor de una señal probabilística sin perder su naturaleza objetiva.

Ambos pertenecen a la misma plataforma tecnológica. Oscilar es una plataforma unificada: procesamiento de datos en tiempo real, inteligencia de dispositivos y comportamiento, reglas y gestión de casos en una sola plataforma, con agentes integrados de forma nativa. La importancia de esto no es la integración por sí misma, sino que separar la detección de la toma de decisiones en sistemas distintos genera ineficiencias: un analista lee una puntuación en una herramienta y aplica la política en otra, teniendo que conciliarlas de forma manual. Mantener la capa de decisión y la de señal en el mismo lugar es también lo que permite que los agentes de riesgo actúen sobre un caso con la justificación correspondiente ya integrada.

Este mismo argumento de diseño se aplica al siguiente nivel: ejecutar una capa compartida de modelos y reglas para fraude y prevención de lavado de dinero (AML), en lugar de mantener dos sistemas paralelos. Pero ese es otro tema.

Lo que le debes a un regulador y a un cliente rechazado

Esta es la parte que los artículos comparativos suelen omitir, y es donde realmente se decide en la práctica el dilema de reglas frente a modelos.

La explicabilidad no es una propiedad del modelo que se declara en una ficha técnica. Es una propiedad operativa, y el lugar para medirla es la cola de revisión.

La prueba práctica es muy concreta: ¿puede el analista que gestiona este caso ver por qué se tomó la decisión, sin tener que descifrarla desde cero? No se trata de si "la categoría del modelo es interpretable en teoría" o de si "documentamos la metodología". Se trata de si la persona que tiene el caso abierto frente a ella puede entender el motivo. Esto requiere que la decisión traslade códigos de explicabilidad y atributos al sistema de gestión de casos, de modo que la justificación llegue junto con el caso, en lugar de que alguien con acceso a la base de datos tenga que armarla después.

Por debajo de los códigos se encuentra la atribución de variables. Una explicación sólida detalla qué factores de riesgo en este comportamiento específico influyeron en esta puntuación; por ejemplo, la rapidez de una serie de transacciones, en lugar de una declaración abstracta de que las variables de frecuencia forman parte del modelo. Una puntuación sin justificación no es una explicación, independientemente de lo que afirme la documentación que la acompaña.

Vale la pena responder a una objeción común: que los modelos más avanzados implican necesariamente perder interpretabilidad. No tiene por qué ser así. El mismo estándar de explicabilidad se puede aplicar a distintos tipos de modelos, y asumir que se debe renunciar a la interpretabilidad a medida que los modelos mejoran es una decisión sobre cómo se construye el sistema, no una regla fija de la industria.

Luego está el registro. Lo que hace que un rechazo basado en modelos sea defendible meses después es un historial de auditoría completo por decisión con justificaciones guardadas, diseñado con supervisión humana y adaptado a la norma SR 11-7. Esa es una expectativa para la que la plataforma está diseñada, no una certificación que cualquiera posea; y es importante tener clara esta diferencia, porque el regulador la tendrá muy en cuenta.

Cómo se degradan los modelos y a qué prestar atención

Las reglas también pierden vigencia. La diferencia es que una regla se degrada de forma visible: alguien nota que se activa sin motivo, o que se activa con todo. Un modelo se degrada silenciosamente, y esa asimetría es el argumento más sólido para no dejar los modelos sin supervisión.

Desviación de concepto (Concept drift). El fraude cambia. El patrón que aprendió el modelo deja de describir el comportamiento actual. No se generan errores en el sistema. La distribución de las puntuaciones cambia ligeramente y el índice de pérdida varía meses más tarde.

Desviación de datos y de variables. Un cambio en los sistemas de origen altera un dato de entrada de manera silenciosa: un campo empieza a llegar vacío, un proveedor cambia una codificación o una marca de tiempo cambia de zona horaria. Las variables pierden calidad, el modelo se degrada con ellas y ningún componente del proceso reporta un fallo porque, técnicamente, nada falló.

La solución es un monitoreo que vigile ambos aspectos. Oscilar monitorea la desviación de datos, de variables y de concepto, junto con los indicadores clave de rendimiento (KPI) de resultados por segmento. El análisis por segmentos es fundamental: un promedio general que parece estable suele ocultar un segmento que ya está fallando, y depender solo de análisis generales hace que detectes los problemas por las pérdidas financieras en lugar de detectarlos con tus herramientas de control.

Preguntas frecuentes

¿Qué es la detección de fraude mediante aprendizaje automático?

La detección de fraude mediante aprendizaje automático califica una transacción, un inicio de sesión o una solicitud comparando sus atributos con patrones aprendidos de resultados históricos etiquetados. Devuelve la probabilidad de que el evento se parezca a un fraude conocido, no una decisión final. Una capa de decisión independiente (generalmente reglas) determina qué se hace con esa calificación.

¿Cómo detecta el fraude el aprendizaje automático?

Un modelo se entrena con eventos históricos etiquetados como fraude o legítimos. Aprende qué combinaciones de variables (monto en relación con el historial del cliente, frecuencia de transacciones, comportamiento del dispositivo, antigüedad de la cuenta) diferenciaban ambos casos. En producción, estas variables se calculan en vivo para cada nuevo evento y el modelo devuelve una puntuación de riesgo en milisegundos.

¿Es mejor el aprendizaje automático que las reglas para la detección de fraude?

Ninguno es mejor, porque responden a preguntas diferentes. Un modelo calcula la probabilidad de que un evento sea fraude. Una regla establece lo que la institución ha decidido hacer al respecto. Los programas avanzados utilizan ambos sistemas, donde las reglas sirven de protección en torno a los resultados del modelo, en lugar de intentar eliminar las reglas gradualmente.

¿Cómo se decide si una decisión de fraude debe gestionarse con una regla o con un modelo?

Hazte estas cuatro preguntas en orden. ¿Es una obligación o una valoración? Las obligaciones siempre son reglas. ¿Existen resultados etiquetados suficientes? Si no hay etiquetas, no hay modelo. ¿Qué debes explicar y a quién? ¿Quién tiene que cambiarlo y con qué rapidez? Si el equipo de riesgo necesita cambiarlo esta semana, debe ser una regla.

¿Cómo se explica un rechazo por fraude basado en aprendizaje automático a un regulador o a un cliente?

Haciendo que la explicación sea operativa y no meramente documental. La decisión debe transferir códigos de explicabilidad y atribución de variables al gestor de casos, de modo que el analista vea qué factores de riesgo de ese comportamiento específico generaron la puntuación. Detrás de eso debe haber un historial de auditoría por decisión con justificaciones guardadas, lo que permite reconstruir la explicación meses después.

El camino a seguir

Deja de ver el debate entre reglas y aprendizaje automático como una cuestión de identidad corporativa y empieza a verlo como una pregunta para cada decisión en particular. Las obligaciones, los patrones sin etiquetar y cualquier cambio que el equipo de riesgo deba implementar de forma autónoma pertenecen a las reglas. Los análisis que cuentan con un amplio historial etiquetado corresponden a los modelos, delimitados por reglas. Y sin importar qué mecanismo tome la decisión, la explicación debe llegar de forma clara al analista en su cola de revisión, o de lo contrario no servirá de nada.

Si estás analizando cómo implementar esto en tu propia infraestructura tecnológica, nuestra propuesta para la toma de decisiones de fraude en transacciones en tiempo real es la aplicación práctica de estos argumentos.