El auditor que ve el fraude antes del cierre: cómo construimos un detector anti-fraude con IA

Llevo diez años auditando nóminas, ventas, cuentas por pagar y procesos de control interno. En todas las empresas en las que entré, el fraude se descubre el día 12 del mes siguiente — cuando los libros ya están cerrados, las decisiones de tesorería ya se tomaron y los responsables políticos ya están en otra reunión. Este artículo es sobre qué pasa cuando llegamos al día 0.

El dolor que encontramos al llegar

Una corporación de servicios financieros con operación en Chile y Argentina, ~1.200 colaboradores, facturación anual cercana a los $180M USD. Estructura típica de holding: una matriz, tres filiales operativas y dos vehículos de inversión. El equipo de auditoría interna era de cuatro personas reportando al directorio.

El problema no era nuevo y no era exclusivo de ellos. Los fraudes y desvíos se detectaban entre 30 y 90 días después de ocurridos. Cuando llegaba la evidencia al comité de auditoría, el dinero ya se había movido, los responsables habían rotado, y el caso terminaba en una nota al pie del informe trimestral con la frase más cara del idioma corporativo: “se están reforzando los controles”.

Algunos datos del baseline antes de empezar:

• $1.8M USD anuales en pérdidas confirmadas por fraude interno, proveedores fantasma y duplicidad de gastos.
• ~37% adicional estimado en pérdidas no detectadas (estimación conservadora basada en benchmarks ACFE para el sector).
• El auditor externo levantaba 4–6 observaciones materiales por cierre anual — todas reactivas, ninguna anticipativa.
• El equipo de auditoría interna dedicaba el 70% de su tiempo a producir evidencia post-hoc para casos ya ocurridos, en lugar de detectar nuevos.

“Cada cierre mensual es como abrir un sobre. Nunca sé qué voy a encontrar, y siempre encuentro algo. Pero ya pasó. El dinero ya salió. Lo único que puedo hacer es escribir un informe que el directorio leerá la próxima semana.”

Por dónde empezamos a destripar el control interno

La tentación habitual al recibir este encargo es proponer un sistema de monitoreo continuo con reglas duras: “si la factura es mayor a X, alertar; si el proveedor es nuevo, alertar; si el pago se autoriza fuera de horario, alertar”. Es lo que vende el 90% de la consultoría tradicional, y es exactamente lo que el cliente había intentado durante seis años — sin éxito.

El problema es estructural. Las reglas duras producen falsos positivos por cientos cada semana, el equipo las apaga después del primer mes, y los fraudes reales se cuelan porque nadie comete fraudes que disparen reglas obvias. Los fraudes reales se ven normales — esa es justamente su característica principal.

Mi primera semana en el cliente la pasé leyendo los últimos cuatro informes de auditoría interna y los últimos dos de auditoría externa. Después me senté con tres personas distintas: el jefe de cuentas por pagar, la analista de tesorería, y una funcionaria con quince años en la empresa que conocía a todos los proveedores por su nombre. Encontré cuatro patrones que ninguna herramienta tradicional jamás iba a detectar sola:

1. Los fraudes vivían en la combinación de fuentes, no en una sola. Una factura sospechosa en cuentas por pagar parece normal. Una transferencia bancaria a un proveedor nuevo parece normal. Un colaborador con bono inusualmente alto parece normal. El fraude aparece cuando los tres ocurren en la misma semana, entre las mismas personas.
2. Los proveedores fantasma se creaban con datos plausibles (RUT válido, dirección real, giro coherente con el rubro) pero tenían patrones de pago que solo alguien con experiencia auditando reconocería: facturas siempre por debajo del umbral de aprobación gerencial, montos redondos, frecuencia muy regular.
3. Los desvíos en remuneraciones se camuflaban en bonos discrecionales aprobados por mandos medios. Nunca eran montos escandalosos individuales; eran 15 colaboradores recibiendo $400 USD extra cada mes durante 8 meses.
4. Los reportes ejecutivos no mostraban lo que había que ver. El CFO recibía dashboards con KPIs financieros consolidados. Para ver lo que importaba habría que mirar desagregado, cruzado, con contexto — y eso es lo que ningún humano tiene tiempo de hacer cada mes.

La conclusión técnica era clara: no necesitábamos reglas duras adicionales, ni un nuevo ERP, ni más auditores. Necesitábamos un modelo de detección de anomalías capaz de aprender el comportamiento normal de la operación y alertar sobre desviaciones, combinado con una capa de explicación que le dijera al comité de auditoría por qué esto era una anomalía y no un falso positivo — en lenguaje humano, no en p-values.

El blueprint del nuevo mecanismo

Diseñé la arquitectura en una hoja, sin jerga técnica, para que la gerenta de auditoría pudiera defenderla frente al directorio y al auditor externo sin un traductor. El sistema tiene tres capas:

┌────────────────────────────────────────────────────────────┐
│  CAPA 1 — INGESTA EN TIEMPO REAL                           │
│  • Facturación electrónica vía SII (cada hora)             │
│  • Movimientos bancarios vía API de banco corporativo      │
│  • Sistema de remuneraciones (lectura nocturna)            │
│  • Contabilidad: libros mayores y subdiarios               │
│  • Maestro de proveedores y empleados                      │
└────────────────────────────────────────────────────────────┘
                          │
                          ▼
┌────────────────────────────────────────────────────────────┐
│  CAPA 2 — DETECCIÓN DE ANOMALÍAS                           │
│  • Isolation Forest sobre el behavior de pagos             │
│  • Modelo supervisado entrenado con casos históricos       │
│  • Reglas heurísticas como guardrail (umbrales conocidos)  │
│  • Cruces multi-fuente cada noche (proveedor × pago × RH)  │
└────────────────────────────────────────────────────────────┘
                          │
                          ▼
┌────────────────────────────────────────────────────────────┐
│  CAPA 3 — EXPLICACIÓN (LLM + RAG)                          │
│  • GPT-4 sobre el reglamento interno + manuales            │
│  • Genera nota explicativa por cada alerta                 │
│  • Lenguaje no técnico, citando reglas o casos históricos  │
│  • Salida: nota lista para directorio (no para data team)  │
└────────────────────────────────────────────────────────────┘
                          │
                          ▼
┌────────────────────────────────────────────────────────────┐
│  SALIDAS                                                   │
│  ─ Dashboard del comité (live, prioridad por riesgo)       │
│  ─ Alertas en Slack al jefe de auditoría (alta prioridad)  │
│  ─ Reporte semanal automático al directorio                │
│  ─ Carpeta de evidencia armada sola por alerta             │
└────────────────────────────────────────────────────────────┘

El stack: Python para los modelos (scikit-learn, PyOD para el Isolation Forest), Postgres en Supabase como base auditable inmutable, GPT-4 con RAG sobre el reglamento interno y el histórico de casos del último cuatrienio, n8n para la orquestación, y Slack más un dashboard custom para las alertas. Nada exótico, todo explicable.

La construcción semana a semana

El proyecto se entregó en diez semanas, con sprints semanales y demo en vivo cada viernes ante el equipo de auditoría y, una vez al mes, ante el comité de directorio. Esta es la línea de tiempo exacta:

Semanas 1–2 — Ingesta y normalización

Conexión a las cinco fuentes principales con n8n: SII (facturación electrónica recibida y emitida), API del banco corporativo, sistema de remuneraciones, contabilidad y maestros. Todos los datos aterrizan en una capa cruda inmutable en Postgres. Cero intervención en los sistemas operativos del cliente — solo lectura, ningún riesgo de afectar producción.

Semanas 3–4 — Entrenamiento del modelo de anomalías

Tomamos veinticuatro meses de histórico (incluyendo los fraudes confirmados que el cliente ya conocía) y entrenamos un Isolation Forest para detectar comportamientos atípicos en pagos. Lo importante: no se buscan reglas, se aprende el comportamiento normal y se marca lo que se desvía. En paralelo, un modelo supervisado clasificó los casos históricos para que el sistema priorizara alertas similares a fraudes ya confirmados.

Semanas 5–6 — Cruces multi-fuente

Esta es la fase que ningún modelo ML puro detecta sola y donde históricamente la auditoría humana fallaba por volumen. Reglas cruzadas como: “proveedor creado hace menos de 60 días, con pagos en aumento mes a mes, cuyo contacto comparte dominio de correo con un colaborador activo”. El sistema no decide nada; sube una alerta con todas las piezas pre-armadas para revisión humana.

Semanas 7–8 — Capa de explicación con RAG

Cada alerta pasa por un agente con GPT-4 alimentado con el manual de controles internos del cliente, el reglamento interno, la jurisprudencia administrativa de la Contraloría y los últimos 200 casos resueltos por el equipo. El agente genera una nota de 4–6 líneas explicando, en lenguaje humano y con citas, por qué este caso merece atención. Es la diferencia entre “score: 0.92” y “este proveedor recibió tres pagos por debajo del umbral gerencial en los últimos 14 días, todos aprobados por el mismo mando medio, lo que coincide con el patrón histórico del caso #34 de 2024”.

Semanas 9–10 — Dashboard ejecutivo y handoff

Dashboard live para la gerenta de auditoría y el comité, con alertas priorizadas por nivel de riesgo y por monto en juego. Reporte semanal automático al directorio cada lunes a las 7 a.m., en formato ejecutivo. Carpeta de evidencia por alerta armada sola, con todos los documentos relevantes ya descargados y indexados. Y capacitación al equipo: tres días con el equipo de auditoría interna, dos sesiones con el comité de directorio.

Lo que cambió en la empresa

Pero la métrica que más le importó al comité de directorio no fue ninguna de esas. Fue esta, dicha por la gerenta de auditoría seis meses después de la implementación:

“Por primera vez en quince años de carrera, llego a las reuniones del comité con hallazgos en tiempo real y propuestas de acción, no con autopsias. Mi equipo dejó de ser el área que escribe informes sobre lo que ya pasó. Ahora somos el área que impide que pase.”

Lo que aprendimos (y que vas a necesitar si quieres replicarlo)

Si estás en una operación con riesgo de fraude relevante — servicios financieros, retail con alta rotación de proveedores, manufactura con compras descentralizadas, sector público — estos son los cinco puntos que distinguen un sistema anti-fraude que funciona de uno que se vuelve ruido apagado en seis meses:

1. El ML solo no basta. Los Isolation Forest y los autoencoders detectan anomalías, pero el 80% de las anomalías que detectan son falsas alarmas operativas (un proveedor legítimo que cambió de banco, un bono extraordinario justificado). La capa de explicación con LLM es lo que filtra ese ruido en algo accionable.
2. Los datos buenos son más importantes que el modelo sofisticado. Pasamos más tiempo limpiando el maestro de proveedores y el plan de cuentas que entrenando modelos. Un Isolation Forest sobre datos limpios derrota a una red neuronal sobre datos sucios, todos los días de la semana.
3. El sistema debe explicar en idioma del directorio, no del data scientist.Si la alerta dice “score: 0.92”, nadie la accionará. Si dice “este proveedor recibió tres pagos por debajo del umbral gerencial en los últimos 14 días, todos aprobados por el mismo mando medio”, el comité reacciona.
4. El compliance regulatorio se diseña desde el día uno. Postgres como base inmutable con timestamps, logs firmados, trazabilidad completa por alerta, evidencia descargable en formato auditor externo. No es opcional. Es lo que hace que la herramienta sirva en una causa judicial, no solo en una reunión interna.
5. El humano sigue siendo necesario, pero su trabajo cambia. El equipo de auditoría no desaparece. Deja de producir autopsias y empieza a producir intervenciones. Su valor sube — el del proceso, no el del puesto. Esto es lo que el directorio entiende inmediatamente y lo que el equipo agradece al mes seis.

¿Tu cierre mensual te sigue sorprendiendo?

Si tu operación tiene entre $20M y $500M USD anuales de facturación, y tu equipo de auditoría interna pasa más tiempo escribiendo informes sobre lo que ya pasó que detectando lo que está por pasar, hay una probabilidad muy alta de que un sistema como este aplique a tu caso. La arquitectura es la misma; lo que cambia son las fuentes de datos y el contexto regulatorio.

Aplica para Chile, México, Colombia, Perú y cualquier marco normativo de LATAM. La mecánica es la misma — solo cambian las autoridades regulatorias y los formularios de declaración.