Proyecto de portafolio · IA aplicada a cumplimiento

Triage de alertas AML con agentes de IA, decisión humana y auditoría inmutable

Hace el primer análisis de las alertas de lavado de dinero: evalúa el riesgo, un agente redacta el borrador con citas a los datos y solo descarta lo claramente benigno. Todo lo dudoso lo decide un analista.

Cómo funcionaVer el código
localhost:5173
Detalle de una alerta: evidencia a la izquierda y decisión del analista a la derecha
falsos negativos
0
ningún caso sospechoso descartado (gate bloqueante)
falsos positivos descartados
90,9 %
con evidencia, en 56 casos etiquetados
alucinaciones
0 %
cada afirmación verificada contra los datos
robustez a prompt injection
100 %
en 6 casos adversarios

El problema

Muchas alertas, pocos casos reales y un costo enorme si se escapa uno

Cumplimiento revisa a mano cientos de alertas al mes; la mayoría son falsos positivos. Pero omitir un caso real tiene un costo regulatorio y reputacional que no se compensa con velocidad.

Volumen

Horas de analista en alertas que terminan descartadas, en lugar de en los casos que importan.

Costo asimétrico

Un falso negativo vale mucho más que un falso positivo: por eso "cero falsos negativos" es un gate que bloquea, no una métrica más.

Regulación

Cada decisión tiene que poder explicarse y probarse ante un auditor, años después.

Cómo funciona

Una saga de seis pasos, con compensación si algo falla

Cada alerta recorre cuatro servicios en segundos. Si un paso falla, los anteriores se compensan y el caso va a investigación manual.

  1. 01

    Ingesta

    La alerta del monitoreo entra por el gateway, con idempotencia.

  2. 02

    Normalización

    Se completan cliente y transacciones desde el core bancario.

  3. 03

    Riesgo

    Reglas deterministas y un grafo de tipologías dan un puntaje explicable.

  4. 04

    Agente

    Redacta el borrador de investigación citando cada dato que usa.

  5. 05

    Cumplimiento

    Guardrails y política: lo claro se descarta, lo dudoso va al analista.

  6. 06

    Cierre

    La decisión queda registrada y auditada de punta a punta.

Principios

Diseñada para un proceso regulado

La IA asiste, no decide

Solo se descarta sola una alerta de riesgo bajo, sin PEP y con todos los controles en verde. Un reporte a la UIF siempre lo decide una persona, con justificación.

Una falla nunca descarta

Si un servicio o el modelo falla, la saga compensa y deriva el caso a investigación manual. Un error técnico no hace menos sospechosa una alerta.

Todo es trazable

El agente solo ve una hoja de hechos y debe citarla. Un control determinista verifica cada cita, monto e identificador antes de mostrar el borrador.

La bandeja del analista

Hecha para usarse toda la jornada

React 19 con shadcn/ui: evidencia y decisión lado a lado, tema claro y oscuro, y vista móvil.

localhost:5173
Bandeja de alertas con filtros rápidos, riesgo y estado de cada revisión

Bandeja. Filtros rápidos, pendientes marcadas y SLA en rojo si venció.

localhost:5173/sagas/…
Línea de tiempo de una saga en tema oscuro

Saga en vivo. Cada paso con su estado y sus compensaciones.

localhost:5173/alerts/…/audit
Visor de auditoría: hash-chain válida, eslabón por eslabón

Auditoría. La cadena de hashes de cada alerta, verificada por el servidor.

Auditoría inmutable

Tres capas, pensadas contra el administrador, no solo contra un bug

En auditoría regulatoria, el actor del que hay que proteger la evidencia es quien tiene acceso privilegiado.

capa 1

Hash-chain por alerta

Cada evento se encadena con SHA-256 al anterior: alterar, insertar o borrar uno rompe la cadena.

capa 2

Anclas en almacenamiento WORM

Cada 5 minutos se sella la cabeza de todas las cadenas en S3 Object Lock (modo COMPLIANCE): ni el root lo puede borrar.

capa 3

Sello de tiempo RFC 3161

Una autoridad externa certifica cuándo existía cada ancla: un sello retrofechado se detecta.

Arquitectura

Microservicios hexagonales con patrones distribuidos

En un banco empezaría con un monolito modular sobre un solo PostgreSQL; aquí se demuestran los patrones a propósito, y cada ADR dice cuál sería la opción pragmática.

Servicios

  • alert-ingestion

    Ingesta e inicio de la saga

  • risk-assessment

    Reglas + grafo Neo4j

  • investigation

    Agentes LangGraph

  • compliance

    Guardrails, HITL y CQRS

  • audit

    Event store inmutable

  • saga-orchestrator

    Máquina de estados

  • api-gateway

    Auth, roles y agregación

Patrones

  • Saga (coreografía y orquestación)
  • Transactional Outbox
  • CQRS
  • Arquitectura hexagonal
  • DDD
  • Human-in-the-loop
  • Circuit breaker

Stack

  • Python 3.12
  • FastAPI
  • LangGraph
  • PostgreSQL
  • MongoDB
  • Elasticsearch
  • Neo4j
  • RabbitMQ
  • React 19
  • shadcn/ui
  • Docker
  • GitHub Actions

Calidad

Verificado contra el sistema real, no solo con tests unitarios

Cada criterio de aceptación se probó contra la plataforma levantada, y esa verificación encontró bugs que ningún test unitario veía.

26
jobs de CI en verde
lint, mypy strict, fronteras, tests, imágenes, E2E
8/8
escenarios de falla
en coreografía y en orquestación
21
decisiones de arquitectura
documentadas como ADR, con alternativas
0
vulnerabilidades HIGH/CRITICAL
trivy sobre código e imágenes

Con honestidad

Lo que este proyecto no es

  • Datos sintéticos: los parámetros de detección no están calibrados con casos reales; es lo primero que mediría.
  • No presenta reportes a la UIF: prepara el caso y deja la decisión a cumplimiento.
  • Autenticación de desarrollo (JWT de prueba); en producción sería el proveedor de identidad del banco.
  • La autoridad de sellado de la demo la genera la propia plataforma: prueba el mecanismo, no la independencia.