Última actualización: marzo de 2026
La detección de fraudes en tiempo real es, fundamentalmente, un problema de datos. Cada transacción activa una decisión que requiere sintetizar docenas de señales simultáneamente: historial de comportamiento, huellas digitales de dispositivos, patrones de transacciones y relaciones de red. Esa decisión debe tomarse antes de que se liquide la transacción.
Las herramientas utilizadas para tomar esa decisión han evolucionado significativamente. Los sistemas basados en reglas fueron el primer enfoque. Luego siguió el aprendizaje automático (ML). Hoy en día, los programas de fraude más eficaces combinan ambos métodos, aplicándolos en una secuencia deliberada que se adapta a las características específicas de cada señal de riesgo.
Según el Informe Global de Delitos Financieros Nasdaq Verafin 2026, las pérdidas por fraudes, estafas y fraudes bancarios sumaron 579 400 millones de dólares a nivel mundial en 2025, con un crecimiento anual compuesto de las pérdidas por estafas del 19.3% en los últimos dos años. El 90% de los profesionales de delitos financieros reportaron un aumento de los ataques impulsados por IA en sus instituciones durante ese período. Mantenerse a la vanguardia requiere una lógica de detección que se adapte más rápido que los patrones de los atacantes.
Este artículo explica las ventajas y desventajas entre las reglas y el aprendizaje automático, describe las tres etapas por las que pasan la mayoría de los programas de fraude a medida que maduran y detalla lo que una plataforma eficaz necesita para respaldar cada etapa.
Resumen rápido
Las pérdidas por fraudes, estafas y fraudes bancarios alcanzaron los 579 400 millones de dólares a nivel mundial en 2025, con un crecimiento anual de las pérdidas por estafas del 19.3%, según el Informe Global de Delitos Financieros Nasdaq Verafin 2026
Las reglas responden rápidamente a patrones conocidos, pero pierden eficacia a medida que los atacantes se adaptan a los límites establecidos
El aprendizaje automático detecta patrones multidimensionales complejos, pero tarda más en adaptarse y es más difícil de explicar
El enfoque más eficaz combina ambos: ML para identificar patrones que las reglas no pueden expresar, y reglas para respaldar al ML cuando el nivel de confianza es dudoso
La mayoría de los programas maduran a través de tres etapas: reemplazar reglas seleccionadas por modelos de ML, respaldar el ML con reglas e integrar puntuaciones de múltiples modelos de ML
La toma de decisiones de fraude en tiempo real requiere que todas estas funciones operen en el mismo canal de datos a la velocidad de la transacción
El panorama del fraude hoy en día
Tanto la escala como la velocidad del fraude han aumentado considerablemente. El Informe Global de Delitos Financieros Nasdaq Verafin 2026 reveló que la actividad financiera ilícita global aumentó a 4.4 billones de dólares en 2025, frente a los 3.1 billones de dólares de 2023. Las pérdidas por fraudes, estafas y fraudes bancarios sumaron por sí solas 579 400 millones de dólares. Las pérdidas por estafas están creciendo a un ritmo dos veces mayor que el fraude bancario tradicional, impulsadas por el uso generalizado de la IA por parte de redes delictivas.
Una detección tardía amplifica los daños. Las pérdidas que se identifican después de ocurridas son mucho más difíciles de recuperar, y el impacto en la reputación de las instituciones que no protegen a sus clientes se acumula con el tiempo.
El principal desafío es la velocidad. Las redes de pago en tiempo real y los canales digitales siempre activos han eliminado el margen de tiempo que antes permitía que funcionara la detección posterior al evento. Ahora, la mitigación eficaz del fraude requiere una toma de decisiones instantánea: evaluar cientos de señales de la transacción entrante y del historial de comportamiento, para devolver una decisión antes de que se liquide la transacción.
Por qué no basta con un enfoque basado únicamente en reglas
Las reglas funcionan marcando las transacciones que superan ciertos límites predefinidos. Si una dirección de facturación no coincide con la dirección registrada de la tarjeta, o si los fallos de inicio de sesión superan un número determinado dentro de un límite de tiempo, se activa una regla y se toma una medida.
Este enfoque tiene claras ventajas: las reglas son transparentes, rápidas de escribir y fáciles de actualizar cuando surge un nuevo patrón de fraude. Sin embargo, tienen una limitación fundamental: solo son tan eficaces como la capacidad de análisis humano que las respalda.
A medida que los atacantes aprenden a operar dentro de los límites de las reglas, las tasas de detección disminuyen. Mantener la precisión exige un ajuste continuo: modificar límites, añadir casos excepcionales y superponer condiciones. Esto genera un conjunto de reglas cada vez más frágil y difícil de gestionar con el tiempo.
A nivel más profundo, las reglas no pueden detectar patrones que abarcan múltiples dimensiones a la vez. Una discrepancia en la dirección de facturación es una señal fuerte de una sola variable. Pero el fraude que solo aparece cuando se evalúan juntos el monto de la transacción, el historial del dispositivo, la ubicación, la antigüedad de la cuenta y la frecuencia de las operaciones requiere un enfoque diferente.
Por qué tampoco basta con un enfoque basado únicamente en aprendizaje automático
El aprendizaje automático resuelve el problema de los patrones multidimensionales. Un modelo bien entrenado puede sintetizar el monto de la transacción, el historial del dispositivo, los datos de ubicación, la antigüedad de la cuenta y docenas de otras señales en una puntuación de probabilidad que ningún conjunto de reglas podría replicar.
Sin embargo, el ML tiene sus propias limitaciones. En primer lugar, no es ágil. Entrenar un nuevo modelo lleva tiempo, por lo que el ML no es ideal para responder a patrones de fraude que surgen de la noche a la mañana. Para cuando un modelo se vuelve a entrenar y se implementa, es posible que los atacantes ya se hayan adaptado.
En segundo lugar, los modelos de ML son opacos. La puntuación de probabilidad que devuelve un modelo es el resultado de ponderaciones y variables que la mayoría de los analistas no pueden revisar directamente. Esto limita quién puede ajustar el modelo y complica la explicación de las decisiones ante notificaciones de medidas adversas o revisiones regulatorias.
En tercer lugar, los modelos de ML con alta sensibilidad tienden a generar tasas elevadas de falsos positivos. Encontrar el punto de operación adecuado (suficiente sensibilidad para detectar fraudes sin bloquear a usuarios legítimos) requiere una calibración cuidadosa y un monitoreo continuo.
Adaptar el enfoque a la decisión
La elección entre reglas y ML no es excluyente. Depende de dos variables: qué tan compleja es la lógica de decisión y con qué frecuencia debe cambiar.

Adaptación del enfoque de detección a la complejidad de la decisión y la frecuencia de cambio
El código de la aplicación funciona para lógicas simples que rara vez cambian. Un motor de reglas maneja lógicas que cambian con frecuencia pero que siguen siendo relativamente sencillas. El aprendizaje automático se adapta a patrones complejos donde el ritmo de cambio es menor y existen suficientes datos de entrenamiento. Cuando tanto la complejidad como el ritmo de cambio son altos, lo más eficaz es combinar ML y reglas.
Más allá de la complejidad y el ritmo de cambio, la elección también implica la explicabilidad, la precisión del resultado y el origen de la lógica de decisión. Las reglas producen una lógica explícita y auditable. Los modelos de ML generan puntuaciones probabilísticas que requieren interpretación y un monitoreo continuo del rendimiento.
Las tres etapas para combinar ML y reglas
La mayoría de las organizaciones no adoptan un enfoque integrado de ML y reglas de la noche a la mañana. Pasan por una secuencia de etapas, donde cada una se apoya en la anterior.
Etapa 1: Reemplazar un subconjunto de reglas con modelos de ML
La primera etapa consiste en identificar las reglas que han acumulado límites complejos ajustados manualmente y reemplazarlas con modelos de ML entrenados con esas mismas variables.
Pensemos en dos reglas: una que bloquea solicitudes cuando un usuario falla el inicio de sesión tres veces en 30 minutos y su cuenta tiene menos de dos días de antigüedad, y otra que solicita una autenticación adicional cuando el código postal de facturación de la transacción no coincide con el perfil del cliente. Las variables detrás de estas reglas (número de inicios de sesión fallidos, antigüedad de la cuenta, código postal) se convierten en datos de entrenamiento para un modelo de ML de fraude transaccional que devuelve una puntuación de probabilidad. Luego, un analista de fraudes define el límite para actuar.

Etapa 1: Las reglas y sus variables se convierten en entradas para un modelo de ML
Este enfoque mejora la detección de fraudes y reduce la carga de mantener una lógica de reglas frágil. El modelo de ML puede detectar combinaciones de señales que las reglas habrían pasado por alto de forma individual.
Etapa 2: Respaldar los modelos de ML con reglas
La segunda etapa aplica reglas bien ajustadas junto con las puntuaciones de los modelos de ML. Esto es especialmente eficaz durante el periodo de calibración de un nuevo modelo, o cuando una señal clave no estaba disponible durante el entrenamiento.
Por ejemplo: bloquear la transacción si la puntuación del modelo de ML de transacciones con tarjeta de crédito supera 0.81 y la antigüedad de la cuenta es mayor de 10 días, o si la puntuación está entre 0.55 y 0.81 y la antigüedad de la cuenta es de 10 días o menos. Este patrón define mejor el límite de decisión en la zona gris, donde las puntuaciones de probabilidad por sí solas generan demasiados falsos positivos.

Etapa 2: Puntuaciones del modelo de ML combinadas con condiciones basadas en reglas
Las reglas también sirven como capa correctiva cuando el rendimiento del modelo disminuye debido a la desactualización de los datos. Si los patrones de fraude influenciados por la antigüedad de la cuenta comienzan a cambiar más rápido de lo que el modelo ha aprendido, una regla que incorpore esa señal mantendrá la precisión hasta que se complete el reentrenamiento.
Etapa 3: Integrar puntuaciones de múltiples modelos de ML
En la etapa más madura, las puntuaciones de probabilidad de múltiples modelos especializados (algunos internos y otros de proveedores externos) se combinan en un único flujo de toma de decisiones.
Una organización podría operar un modelo de fraude de cuentas y un modelo de fraude de transacciones junto con una puntuación externa de reputación del dispositivo. Estos resultados se integran en un flujo de trabajo que los combina mediante reglas al principio y, finalmente, a través de un metamodelo entrenado con los resultados de los modelos individuales. Esto genera una evaluación de riesgo integral que ningún modelo por sí solo podría producir.

Etapa 3: Múltiples puntuaciones de modelos de ML integradas en un flujo unificado de toma de decisiones
Lo que necesita una plataforma para respaldar esta evolución
Operar con eficacia en estas tres etapas requiere una plataforma con funciones específicas que trabajen en conjunto:
Un repositorio de variables compartido para que las reglas y los modelos de ML utilicen los mismos datos al mismo tiempo
Un motor de reglas personalizable que pueda incorporar puntuaciones de modelos de ML junto con señales de transacciones en tiempo real
Herramientas para entrenar, implementar y monitorear modelos de ML sin necesidad de una infraestructura de ciencia de datos independiente para cada cambio
Pruebas retrospectivas con datos históricos para validar la nueva lógica antes de que afecte a las decisiones en producción
Herramientas sin código para que los analistas de fraude puedan escribir y ajustar reglas sin depender de ingeniería
Canales de datos en tiempo real que pongan las variables a disposición tanto de las reglas como de los modelos a la velocidad de la transacción
La plataforma de toma de decisiones de riesgo con IA de Oscilar está diseñada para respaldar esta combinación. Los equipos pueden ejecutar modelos de ML personalizados junto con un motor de reglas sin código, compartiendo los mismos datos de variables en ambos. La nueva lógica se puede probar en minutos e implementar en modo oculto (shadow mode) antes de su lanzamiento definitivo. La plataforma ejecuta más de 700 000 decisiones en tiempo real al día, cada una completada en menos de 800 milisegundos.
Coast redujo el tiempo de revisión manual en un 75 por ciento tras implementar la gestión de casos integrada de Oscilar, gracias a la visualización automatizada de datos que permite a los revisores principiantes trabajar de forma independiente de los analistas principales. Una investigación más rápida completa el ciclo: la detección solo es eficaz si se actúa con rapidez sobre el fraude identificado.
Preguntas frecuentes: Aprendizaje automático frente a motores basados en reglas
¿Cuándo debo usar reglas y cuándo aprendizaje automático?
Usa reglas para señales de alta confianza y claramente definidas que necesitan responder rápidamente a nuevos patrones. Usa ML para comportamientos complejos y multidimensionales donde existan suficientes datos de entrenamiento y el patrón sea relativamente estable. En la mayoría de los programas de fraude reales, se necesitan ambos y el equilibrio va cambiando con el tiempo.
¿Cómo sé si mi modelo de ML está perdiendo eficacia?
Monitorea las tasas de detección, de falsos positivos y el volumen de alertas a lo largo del tiempo. Cualquier desviación significativa en estas métricas respecto al rendimiento inicial suele indicar cambios en los datos o en los comportamientos de fraude que el modelo aún no ha aprendido.
¿Pueden las reglas y los modelos de ML compartir los mismos datos?
Sí, y de hecho deberían hacerlo. Separar los datos de variables que usan las reglas de los que usan los modelos de ML es una de las fuentes más comunes de problemas de precisión en los programas de fraude. Las plataformas que mantienen un repositorio de variables compartido eliminan esta desconexión y mejoran la coherencia en las decisiones.
¿Cómo ayuda Oscilar con el enfoque combinado de ML y reglas?
La plataforma de Oscilar permite a los equipos combinar modelos de ML personalizados con un motor de reglas sin código utilizando variables compartidas. Las nuevas reglas y modelos se pueden probar con datos históricos e implementarse gradualmente. Conoce todas las funciones en la página de la plataforma de Oscilar.
Mira a Oscilar en acción
Una toma de decisiones precisa y en tiempo real contra el fraude requiere tanto de ML como de reglas: aplicados en la etapa correcta, operando con los mismos datos y listos para implementarse sin retrasos técnicos. Explora cómo la plataforma de Oscilar respalda este enfoque o solicita una demostración para verlo en práctica.








