Compliance legacy vs AI-native: cómo pasamos de 35 personas a 5 + agentes

La versión corta: reconstruimos nuestro stack de compliance alrededor de agentes de IA. Pasamos de 35 personas revisando alertas a mano a 5 personas más agentes haciendo el mismo output. La misma cobertura, la misma postura regulatoria, una fracción del headcount. Este es un post de ingeniería, no de ventas. Quiero explicar cómo está cableado el stack, qué es realmente el compliance legacy, y qué aprendimos en el camino.

Escribo esto desde la silla de CTO en Gu1. Construimos infraestructura de compliance AI-native para fintechs de LatAm. KYC, AML y KYT en una sola API. 54 clientes activos entre Brasil, México, Argentina y Colombia. Nuestro equipo de compliance antes se parecía al de cualquier otra fintech. Ya no.

Qué es realmente el compliance legacy#

Si nunca trabajaste dentro de un banco o de una fintech, "compliance" puede sonar abstracto. No es abstracto. Es un modelo operativo muy específico. Sacá el jargon y queda así.

Un equipo de analistas sentado frente a una cola. La cola la llena un motor de reglas. El motor de reglas lee cada transacción, cada usuario nuevo, cada documento, y hace una serie de preguntas que alguien escribió en un doc de especificaciones. Preguntas como:

• Si el monto de la transacción > X y el país = Y y el patrón = Z, marcala.
• Si el score del documento del usuario < umbral, frená el onboarding.
• Si el nombre de la contraparte tiene fuzzy-match con una lista de sanciones, escalá.

Las reglas son estáticas. Las escribió un humano. Las mantiene un humano. Aparece un nuevo patrón de fraude, alguien abre un ticket, ingeniería empuja una regla nueva, QA la revisa, deploy, y la cola empieza a agarrarlo. O no. El loop es lento porque hay humanos en cada paso.

Cada analista limpia entre 50 y 100 alertas por día. Si el negocio crece, contratás más analistas. La matemática es lineal. Duplicás el tráfico, duplicás el equipo. No hay palanca en este modelo.

Las tasas de falsos positivos en sistemas legacy de compliance llegan hasta el 98% en varios estudios publicados de la industria.

Leé eso de nuevo. 98 de cada 100 alertas que levanta un sistema legacy son ruido. El analista clickea 98 falsos positivos para atrapar 2 reales. Esto no es rumor. Está documentado en múltiples encuestas de compliance-tech entre 2024 y 2025. El impuesto a la productividad es enorme y se acumula.

El onboarding bajo este modelo tarda entre 3 y 7 días para los tiers de mayor riesgo. No es porque la verificación tarde días. Es porque la alerta se queda en la cola esperando que un humano la mire. Al usuario no le importa tu cola. Se va.

Qué significa realmente "AI-native" (no marketing)#

"AI-native" es una frase cargada. Cada vendor legacy en el espacio hoy tiene una página de IA en su sitio. Quiero ser específico con lo que queremos decir nosotros.

AI-native, para nosotros, significa cuatro cosas.

Primero, los modelos aprenden patrones en vez de que los humanos escriban reglas. No mantenemos un libro de reglas de 4.000 líneas. Entrenamos y reentrenamos modelos sobre data regional etiquetada. Cuando la distribución se mueve, el modelo se mueve. Cuando se desvía demasiado, lo agarramos en monitoreo y reentrenamos.

Segundo, la inferencia corre sobre cada transacción en tiempo real. No batch. No un reporte nocturno. La decisión vuelve en el mismo request que la disparó. Si un usuario manda plata a las 2:03 AM desde un dispositivo nuevo en un país nuevo, la decisión aterriza antes de que la UI termine el loading spinner.

Tercero, los falsos positivos viven por debajo del 5%. Es nuestro target empírico, no un claim de marketing. Cuando lo superamos con un cliente específico, es un incidente y lo tratamos como tal. Un modelo que llora lobo no es más barato que las reglas. Es solo más rápido para hacerle perder tiempo al analista.

Cuarto, y este es el que importa para la unit economics: el stack escala con cómputo, no con headcount. Agregamos capacidad aprovisionando GPUs y tuneando batch sizes, no publicando avisos de laburo. Si un cliente multiplica por 10 su tráfico en un trimestre, no cambia nada en nuestro equipo.

El onboarding, bajo este modelo, tarda segundos o minutos. La mayoría de los flujos terminan antes de que el usuario agarre el teléfono para ver qué está tardando.

El costo real del compliance legacy#

Antes de recorrer nuestro stack, quiero ser honesto sobre por qué importa. Compliance no es un costo del que se habla en la cena, pero los números son grandes.

El gasto en compliance se ubica entre el 15% y el 20% del presupuesto operativo de una fintech en 2026.

Es un quinto de tu costo operativo yendo a una actividad que no diferencia tu producto. Ningún usuario se abre una cuenta en tu banco porque tu sanctions screening sea minucioso. Se abre una cuenta porque el onboarding es rápido y la app no lo rechaza por nada.

El throughput del analista es el cuello de botella. Las colas se acumulan. Los SLAs se escapan. Los usuarios se van. Soporte escala casos. El costo no es solo la línea de salarios del equipo de analistas. También es el churn de los usuarios que nunca terminaron de registrarse. Es el costo de oportunidad de los ingenieros manteniendo el motor de reglas en vez de shippear producto.

A escala, la economía deja de cerrar. Una fintech mediana de LatAm corriendo compliance legacy sobre un volumen serio de transacciones está perdiendo plata por usuario. Lo vimos en clientes antes de que migraran a nosotros.

Cómo está estructurado el stack de Gu1#

Te cuento qué shippeamos. Tres capas, con agentes arriba de las tres.

1. Capa KYC#

Esta es la puerta de entrada. Verificación de identidad, liveness, OCR de documentos, biometría, lookup de UBO.

La parte de identidad tiene que estar tuneada para documentos de LatAm. No es un detalle menor. CPF en Brasil, CURP en México, DNI en Argentina, Cédula en Colombia. Cada uno tiene su formato, sus dígitos verificadores, su autoridad emisora, sus modos de falla. Un modelo entrenado con licencias de conducir de EE.UU. se va a equivocar de maneras que no vas a notar hasta que tu tasa de fraude se dispare.

Nuestro pipeline de OCR está entrenado sobre distribuciones regionales de documentos. Recolectamos y etiquetamos a escala, validamos sobre hold-out sets por país, y mantenemos cabezales específicos por país en el modelo. El liveness check es un check activo 3D que atrapa la generación actual de ataques con deepfakes. No es un fix para siempre. Es un fix para lo que se está intentando en 2026.

El flujo de KYC es tiered. Los usuarios de bajo riesgo pasan un check básico en segundos. Los de mayor riesgo entran a verificación reforzada, con documentos adicionales, fuentes adicionales, y un path ponderado por riesgo. El tiering lo maneja un score de riesgo, y ese score lo manejan las señales que recogemos en el mismo momento del onboarding. Dispositivo, IP, comportamiento, hora del día, fuente de referral, velocity.

2. Capa AML#

La capa AML hace monitoreo de transacciones, detección de patrones, y screening de sanciones.

La detección de patrones es donde el ML realmente se gana el lugar. El AML clásico se construyó con umbrales. "Más de X dólares en 24 horas a través de más de Y contrapartes." Esas reglas existen por una razón, y seguimos corriendo algunas como guardrails. Pero se pierden casi todo lo que importa. El lavado sofisticado estructura el dinero específicamente para quedarse debajo de los umbrales.

Los modelos que entrenamos miran estructura de grafo, patrones temporales, clústers de contrapartes, antigüedad de la cuenta, y decenas de features derivadas. Atrapan estructuración y layering que una regla de umbral no puede atrapar por definición.

El screening cubre OFAC, ONU, UE y listas de PEP y sanciones específicas por país. El fuzzy matching es language-aware, lo cual importa en LatAm porque un nombre en español o portugués puede confundir a un matcher construido para convenciones en inglés.

3. Capa KYT#

KYT (Know Your Transaction) es el análisis en tiempo real de cada transacción mientras sucede.

El scoring de riesgo pasa por transacción, no por usuario. Esta es una distinción importante. Un usuario de bajo riesgo puede hacer una transacción de alto riesgo. Un usuario de alto riesgo puede hacer una transacción de bajo riesgo. Puntuar al usuario una sola vez en el onboarding y confiar en ese score por un año es la forma de perder los account takeovers.

El contexto comportamental alimenta el scoring: el dispositivo desde el que viene la transacción, la red, la velocity de actividad reciente, la hora del día, si se parece o no al baseline del usuario. La decisión vuelve en decenas de milisegundos.

Agentes arriba#

Esta es la parte que cambió nuestras operaciones.

Los agentes leen cada alerta que producen las tres capas. Triajean. Resuelven los casos claros. Escalan los ambiguos a un humano con un paquete de contexto completo: qué disparó la alerta, cómo se ve el baseline del usuario, cómo resolvieron casos parecidos en los últimos 30 días. El humano no tiene que reconstruir la situación. Lee un brief, toma la decisión, y sigue.

Los agentes redactan SAR y reportes regulatorios automáticamente. Un humano revisa y submitea. Redactar era históricamente la parte más tediosa del día de un analista, y es la parte en la que los LLMs son genuinamente buenos.

El split termina siendo más o menos 90/10. Los agentes manejan el 90% del trabajo de rutina. Los humanos manejan el 10% de edge cases donde el juicio importa de verdad. Ese 10% no es poco. Es donde al regulador más le importa, y lo cubrimos con gente que sabe leer una regulación y tomar una decisión.

Qué cambió para el equipo#

No echamos gente y le dijimos productividad a eso. La forma del equipo cambió.

El equipo de ingeniería creció. Invertimos fuerte en la plataforma, el pipeline de training, la observabilidad, la detección de drift. El equipo de ops se achicó. Son skill sets distintos. Movimos el hiring en consecuencia.

La descripción de puesto de "analista de compliance" cambió en Gu1. No revisan alertas una por una. Corren agentes, tunean políticas, revisan escalamientos, y son dueños de la relación con el regulador. Es un rol de más palanca, y la gente que se quedó dio un paso adelante en lo que hacía día a día.

La proporción de ingenieros a gente de ops se invirtió. Si dibujabas nuestro organigrama hace dos años, veías un equipo de compliance ancho con un equipo de plataforma chico al lado. Ahora es un equipo de plataforma más ancho con un grupo de compliance más chico y más senior. El trabajo se volvió más difícil y más interesante para todos los que se quedaron.

Sacando el costo, creo que este es el cambio más importante. El trabajo de compliance era históricamente el puesto donde la gente brillante se quemaba clickeando colas. No es un buen uso del tiempo de nadie.

Qué sigue siendo difícil#

No quiero dar la impresión de que algo de esto está terminado.

Las regulaciones cambian en cada país. El BCB de Brasil publica reglas nuevas. La CNBV de México actualiza su guía. El BCRA de Argentina se mueve. La SFC de Colombia se mueve. Los agentes tienen que adaptarse. Mantenemos policy packs por país y los versionamos. Cuando cambia una regla, es un evento de ingeniería, no de compliance.

Los edge cases en flujos de economía informal no se ven como los modelos entrenados en Europa esperan. Mucha actividad de pagos de LatAm corre por canales que un modelo entrenado sobre data SEPA europea va a puntuar como sospechosos porque nunca vio nada parecido. Entrenamos regionalmente. Tenemos que hacerlo. Los modelos off-the-shelf de proveedores internacionales fallan acá de maneras predecibles. No es una queja sobre ellos. Es una declaración sobre qué pasa cuando desplegás un modelo fuera de su distribución de training.

El drift del modelo es la otra parte difícil. Los patrones de fraude cambian. El comportamiento del usuario cambia. El modelo que funcionaba hace seis meses no es el modelo que queremos corriendo en producción hoy. Reentrenamos con cadencia mensual, y tenemos monitores de drift que nos avisan si la distribución se mueve más rápido que eso. La detección de drift es todo un sub-problema. Tenemos un equipo interno dueño de eso.

Y después está el punto obvio. El 50% del fraude hoy usa IA del lado del atacante, según el trabajo de Feedzai de 2025. El piso está subiendo. Las herramientas que se usan contra nosotros mejoran. La defensa tiene que seguir moviéndose, y tiene que ser AI-native porque no podés pelear ataques en tiempo de inferencia con un batch job nocturno.

Por qué compartimos esto#

Hay más de 2.800 fintechs en LatAm operando en la región ahora mismo, según el último conteo de Finnovista. Muchas están corriendo stacks de compliance legacy que las están desangrando por usuario. Se proyecta que el mercado de detección de fraude en LatAm pase de USD 1,74B en 2025 a USD 9,14B en 2034, un CAGR del 20,2%. La presión sobre compliance va a aumentar, no a bajar.

Si estás construyendo en este espacio, no necesitás ser nosotros. Sí necesitás ser honesto sobre si tu stack actual está pattern-matcheando contra el modelo de amenazas de 2020 o el de 2026. La respuesta, para la mayoría de los equipos, es 2020. Eso se arregla.

Si querés el panorama completo sobre cómo manejamos KYC específicamente, la Guía Completa de KYC en LatAm recorre la realidad país por país. Si estás hasta las manos con problemas de AML, Desafíos de AML en Fintechs de LatAm tiene los detalles. Para patrones de fraude más amplios, mirá Prevención de Fraude en Mercados Emergentes. Y si querés la intro a qué hacemos acá, arrancá por Bienvenido a Gu1.

Shippeamos una API. La podés probar. Ese es el pitch.