La IA en compliance financiero: lo que funciona, lo que falla y lo que el regulador ya está preguntando

La industria financiera lleva décadas automatizando procesos. Pero hay una diferencia fundamental entre automatizar un proceso que produce el mismo resultado cada vez y usar un sistema que razona, infiere y puede estar equivocado de forma convincente. Esa diferencia es la IA generativa. Y su adopción en compliance, verificación de contratos y screening de sanciones está acelerando mucho más rápido que el marco regulatorio para gobernarla.

Dónde está la IA en compliance hoy

Los casos de uso actuales son claros y en muchos casos funcionan bien.

En screening de sanciones y AML, los grandes vendors han integrado modelos de clasificación para reducir falsos positivos en el matching de nombres. Los resultados son reales: la tasa de alertas procesables ha subido y el ruido ha bajado en la mayoría de los deployments. En revisión de contratos, para instrumentos estándar como ISDA Master Agreements o contratos EFET de energía, los modelos de lenguaje son capaces de identificar cláusulas no estándar, detectar asimetrías en eventos de resolución temprana y marcar gaps de jurisdicción en minutos. Lo que antes tardaba dos horas a un analista junior, hoy tarda dos minutos. En análisis de riesgo de contraparte, RAG sobre filings regulatorios, informes de crédito y bases de datos de exposición sectorial permite sintetizar señales que un analista humano tardaría días en agregar.

Hasta aquí, bien. El problema no es que la IA no aporte valor. Es que aportando valor, siembra una confianza que a veces no está justificada.

Dónde están los riesgos reales

El riesgo más inmediato no es la alucinación flagrante. Es la alucinación plausible.

Un modelo puede decirte que una contraparte no aparece en listas OFAC vigentes y estar equivocado, no porque invente de la nada, sino porque su base de conocimiento tiene un corte de fecha, o porque el identificador que usaste no coincide exactamente con el que aparece en la lista. El analista que recibe esa respuesta, en un flujo de trabajo de alta presión, rara vez la cuestiona. La confianza en el sistema es el riesgo.

El segundo riesgo es la opacidad de la decisión. La mayoría de los deployments de IA que se ven en compliance producen un output: riesgo alto / medio / bajo, con un párrafo de justificación. Pero si el regulador pregunta en tres años por qué se aprobó una transacción con esa contraparte, ¿qué le muestras? ¿El PDF del informe? ¿El email donde el analista dijo «el sistema dijo que sí»? MAS en Singapur, ESMA en Europa y la futura autoridad AMLA están empezando a hacer exactamente esa pregunta. Y «usamos una herramienta de IA» no es una respuesta que satisfaga a un supervisor.

El tercer riesgo es estructural: la segregación de funciones. En muchos deployments actuales, el mismo sistema que analiza el riesgo también genera la recomendación que el analista firma. Esto viola el principio básico de maker/checker que existe en compliance desde antes que existiera la IA. El analista pasa a ser un validador de lo que dice la máquina, no un evaluador independiente. La responsabilidad queda flotando entre el humano y el algoritmo, y cuando hay un incidente regulatorio, ninguno de los dos la asume del todo.

El cuarto riesgo es el drift. Los modelos que se reentrenan, que cambian de versión, o cuyos proveedores ajustan parámetros de seguridad pueden producir outputs radicalmente distintos sobre la misma entrada sin que nadie en la institución lo detecte hasta que hay un problema real.

El quinto, que es del que menos se habla: la dependencia del vendor. Si tu proceso de compliance depende de un modelo cuya lógica interna no controlas, tienes un riesgo de continuidad operativa que ningún BCP tradicional contempla.

Lo que hay que construir

La buena noticia es que estos riesgos son gobernables. La mala es que requieren trabajo de arquitectura, no solo de prompting.

Lo primero es el audit trail de inferencia. No el log de que «se usó IA», sino el registro a prueba de manipulaciones y solo-anexable de qué prompt exacto se ejecutó, con qué modelo, en qué versión, con qué parámetros y cuál fue el output literal. Sellado con hash criptográfico y timestamp RFC 3161. Eso es lo que le puedes mostrar a un supervisor tres años después. El IMDA Model AI Governance Framework for Agentic AI de Singapur ya lo exige de forma explícita. El EU AI Act lo implica para sistemas de alto riesgo en servicios financieros. Es cuestión de tiempo que se convierta en estándar regulatorio global.

Lo segundo es la verificación adversarial. Un solo modelo no debería ser árbitro de una decisión de compliance. La práctica que se está consolidando en los deployments más maduros es el consenso multi-modelo: ejecutas el mismo análisis en tres modelos distintos, de proveedores distintos, y solo confías en el resultado cuando convergen. Cuando divergen, el caso va a revisión humana. Esto no elimina el error, pero lo hace detectable antes de que se convierta en un incidente.

Lo tercero es separar el análisis de la validación. El maker es el sistema, o el analista apoyado en el sistema. El checker es un humano distinto que revisa con acceso al trail completo, no solo al output. Esto es lo que transforma la IA de un sustituto del juicio humano en un amplificador del juicio humano. La diferencia no es semántica. Tiene implicaciones directas en cómo el regulador atribuye responsabilidad cuando algo falla.

Lo cuarto es la granularidad del control jurisdiccional. Los requerimientos de MAS Notice 626, EMIR, REMIT y AMLA no son idénticos. La capacidad de fijar, por jurisdicción, qué modelos están permitidos, qué fuentes se usan y qué nivel de confianza mínimo requiere la validación humana es lo que hace que un deployment sea escalable sin convertir cada mercado en un fork de código independiente.

El principio que no debería ser negociable

Hay una formulación que resume la postura correcta ante la IA en compliance: el objetivo no es eliminar el error. Es hacer que el error sea detectable y auditable.

La IA no va a ser infalible. Ningún sistema humano lo es tampoco. La pregunta relevante no es si la IA puede equivocarse. Evidentemente puede. La pregunta es: cuando se equivoca, ¿alguien puede detectarlo, entender por qué ocurrió y corregirlo sin que el regulador se entere en la peor circunstancia posible?

Si la respuesta es sí, tienes un sistema de compliance apoyado en IA que es genuinamente más robusto que el proceso manual que reemplaza. Si la respuesta es no, tienes un riesgo nuevo disfrazado de eficiencia operativa.

El trabajo que queda por hacer en la industria es mayoritariamente ese: pasar de «tenemos IA en compliance» a «tenemos IA en compliance que podemos demostrar, ante el regulador y ante nosotros mismos, que funciona como dijimos que funcionaba». La diferencia entre esas dos afirmaciones es la diferencia entre adopción responsable y exposición regulatoria latente.

Eso es lo que el regulador está empezando a preguntar. Y más vale que la industria tenga las respuestas preparadas antes de que la pregunta llegue en forma de multa.