Cómo evaluar una plataforma de prevención de lavado de dinero impulsada por IA

Última actualización: octubre de 2026

Una plataforma de prevención de lavado de dinero (AML) basada en IA tiene que superar todas las pruebas que le exigirías a cualquier sistema de AML tradicional, lo que incluye cobertura, gestión de casos, datos y costes. Pero además, debe superar cuatro pruebas que las evaluaciones basadas en reglas suelen pasar por alto: la evidencia detrás de cada resultado, la confirmación humana por diseño, el control de cambios en modelos y agentes, y la claridad de los resultados para que un inspector pueda entenderlos. Realiza estas cuatro pruebas con tus propios datos antes de firmar.

Resumen rápido

• Una plataforma de AML con IA necesita pasar cuatro pruebas adicionales a una evaluación de AML general: la evidencia detrás de cada resultado, la confirmación humana por diseño, el control de cambios en modelos y agentes, y la generación de resultados legibles para un inspector.

• Solicita por escrito los datos, la fuente y el razonamiento detrás de cada recomendación. Un resumen muy fluido pero sin un camino claro de vuelta a las transacciones de origen no supera la primera prueba.

• Identifica cada punto en el que una persona decide cerrar, derivar o reportar un caso, y pregunta quién fijó esos límites y bajo qué evidencias.

• La guía interinstitucional sobre gestión de riesgos de modelos de abril de 2026 (SR 26-2) cubre los modelos de aprendizaje automático (machine learning), pero deja fuera de su alcance a la IA generativa y agentil. Aun así, los inspectores y compradores siguen exigiendo pruebas y validación.

• Realiza las pruebas con tus propias alertas históricas y, después, pon el sistema a trabajar en paralelo con tus analistas antes de dejar que la plataforma tome decisiones en producción.

¿Qué deberías probar en una plataforma de AML con IA?

Prueba cuatro aspectos que una evaluación de AML basada en reglas suele subestimar: si la plataforma muestra la evidencia detrás de cada resultado, si una persona confirma cada recomendación por diseño, si los cambios en modelos y agentes se aprueban y registran, y si un inspector puede entender lo que genera. Luego, pon a prueba estos cuatro puntos con tus propios datos.

1. Evidencia detrás de cada resultado. Cada recomendación incluye los datos utilizados, su origen y el razonamiento aplicado, y permite que un analista acceda a las transacciones subyacentes.

2. Confirmación humana por diseño. La plataforma muestra claramente dónde deciden las personas; nada se cierra, deriva o reporta sin una decisión que la institución haya configurado y pueda defender.

3. Control de cambios en modelos y agentes. Cada cambio en un modelo, instrucción (prompt) o configuración se registra por versiones, se prueba y se aprueba antes de aplicarse a las alertas reales.

4. Resultados legibles para un inspector. La lógica y los registros de los casos son perfectamente comprensibles para alguien ajeno al equipo de AML.

La pregunta de fondo de estas cuatro pruebas es la primera que se hacen los compradores. El director de cumplimiento normativo de una empresa de pagos, al diseñar un programa desde cero, lo expresó así: "¿Cómo voy a saber si los sistemas están funcionando como se espera? ¿Cómo sé que los sistemas de IA realmente funcionan?"

Un motor de reglas responde a esto en parte por su propia naturaleza: ante una misma entrada se activa la misma regla, y esa regla se puede leer. Un modelo de lenguaje no funciona así.

Un responsable de operaciones de cumplimiento para el alta de clientes en un banco comentó que los modelos de lenguaje parecen tener días buenos y días malos, por lo que su equipo eliminó de los procesos tanta subjetividad como pudo. Por otro lado, un gestor de proyectos de TI en una gestora de activos describió una prueba piloto anterior que clasificaba alertas de delitos financieros usando una instrucción general para un modelo de lenguaje. Nada en ese proceso era auditable ni explicable, los resultados fueron incorrectos y el proyecto se canceló tras un breve periodo de prueba.

Estas cuatro pruebas complementan una evaluación general. Para analizar cobertura, gestión de casos, datos y costes, consulta primero la guía general para compradores de software de AML y un marco de evaluación para plataformas de monitorización de transacciones. Para entender la diferencia entre una simple instrucción y un agente que trabaja bajo límites definidos, consulta qué es un agente de IA autónomo en la gestión de riesgos.

Prueba 1: la evidencia detrás de cada resultado

La pregunta clave: para cualquier recomendación, muéstrame por escrito los datos que utilizó el sistema, de dónde salió cada dato y el razonamiento que los conecta.

Un inspector preguntará cómo llegó la institución a una conclusión, y limitarse a señalar al sistema no es una respuesta válida. El director de cumplimiento y BSA de un banco comunitario describió el problema con total claridad: "si no lo tengo por escrito, no podré defenderlo". Un responsable de control de calidad de AML en una fintech pedía lo mismo desde el punto de vista de la revisión: documentación que pudiera mostrar a un inspector para justificar de dónde obtuvo el sistema cada dato.

Además, el analista debe poder acceder a esa evidencia. El mismo director señaló que, por mucho que les guste la IA, no confían plenamente en ella y necesitan poder investigar una alerta por sí mismos. Una plataforma que muestra un resumen pero no las transacciones que lo sustentan deja al analista sin herramientas para verificar el trabajo.

Pon a prueba dos fallos críticos a propósito:

• Datos inventados en textos redactados. Un director de estrategia de producto en una empresa de pagos señaló que si una herramienta de redacción sufre una "alucinación" y envía un informe a la FinCEN con apenas unas pocas palabras incorrectas, el problema sería mayúsculo.

• Evidencia del lugar equivocado. Un vicepresidente de suscripción, riesgo y cumplimiento de pagos en un banco preguntó cómo evitaría un proveedor que el resumen de una investigación cite actividad que pertenece a una cartera de clientes totalmente diferente.

Una respuesta débil en este punto es una redacción impecable pero sin enlaces a los registros reales, o un hilo de razonamiento que cita datos que el analista no puede abrir. Los auditores ya exigen pruebas que respalden los hallazgos documentados: un responsable de cumplimiento de una entidad de crédito al consumo comentó que esa fue la principal pregunta tras su auditoría de BSA/AML más reciente. Para comprobarlo en una demostración, elige un caso cerrado que conozcas bien, pide a la plataforma que muestre sus evidencias y verifica cada dato citado con tus propios sistemas.

Prueba 2: confirmación humana por diseño

La pregunta clave: muéstrame cada punto donde una persona confirma, deriva o reporta un caso, y qué puede llegar a pasar (si es que pasa algo) sin esa intervención humana.

Los reguladores esperan que la institución demuestre que mantiene el control. Un MLRO de una empresa de pagos explicó que, al presentar un sistema de IA a un regulador, necesitaría explicar detalladamente dónde toman las personas las decisiones de derivación y de presentación de reportes de actividad sospechosa (SAR), y poder demostrar esos puntos de decisión. La plataforma debería facilitar la generación de ese mapa de decisiones.

Después, pregunta qué casos se pueden cerrar sin revisión, quién configuró esa opción y bajo qué evidencias. Un responsable de IA de cumplimiento en un banco describió los pasos lógicos que seguiría antes de permitir cualquier cierre automático sin revisión: acumular un histórico de alertas, realizar pruebas en paralelo para demostrar que el agente funciona como se espera y, solo entonces, dar el paso, alineándose con el ciclo de vida de revisión interna de modelos del banco. Esa decisión corresponde a la institución, y la plataforma debe registrarla como tal.

Pregunta también si el sistema cambia su comportamiento por sí solo. Un miembro del equipo de BSA en una cooperativa de crédito comentó que daban por hecho que el sistema aprendería de una alerta que su equipo cerraba constantemente y empezaría a cerrarla de forma automática. El comportamiento del sistema solo debe cambiar mediante una modificación aprobada y registrada, que es justamente lo que aborda la Prueba 3.

Los límites de control (guardrails) alrededor del modelo son tan importantes como el modelo mismo. El gestor de proyectos de TI de la gestora de activos lo resumió claramente: "necesitas límites deterministas al principio, el modelo de lenguaje en el medio y límites deterministas al final". Pregunta qué pasos son reglas fijas, cuáles son resultados del modelo y en qué punto firma una persona.

Una respuesta débil define la revisión humana simplemente como una opción que el cliente puede desactivar, o es incapaz de explicar quién definió los umbrales de decisión. Para ver cómo encaja la firma humana en todo un programa, consulta qué cambia la IA en un programa de AML.

Prueba 3: control de cambios en modelos y agentes

La pregunta clave: muéstrame el historial de cada cambio en modelos, instrucciones (prompts) y configuraciones, quién lo aprobó y cómo eran los resultados antes y después del cambio.

Una plataforma de AML con IA cambia en muchos más puntos que un motor de reglas: los modelos se vuelven a entrenar, las instrucciones se editan y las directrices de los agentes se actualizan. Cada modificación puede alterar qué alertas reciben atención y qué se detalla en el expediente del caso. El responsable de IA de cumplimiento del banco afirmó que el proceso de extremo a extremo debe ser defendible bajo una auditoría interna de riesgo de modelos, lo que implica poder mostrar "el historial de las instrucciones o el historial de los resultados, y qué ha cambiado a lo largo del tiempo".

Los equipos de BSA ya trabajan así con las reglas tradicionales. Un oficial de BSA de un banco comparó ambas áreas: los equipos de prevención de fraude cambian las reglas primero y las envían a revisión de riesgo de modelos después, mientras que los cambios de reglas de BSA pasan por revisión antes de aplicarse. Un responsable de un programa de BSA en una cooperativa de crédito describió la misma responsabilidad: explicar cómo genera alertas el sistema y, si hubo cambios en el periodo, cómo aseguraron que dicho cambio fuera sólido.

Tres elementos clave que debes solicitar:

• Aprobación antes de producción. Cada cambio en un modelo, instrucción o configuración que afecte a las alertas de AML debe ser aprobado por la institución antes de que llegue a producción.

• Pistas de auditoría para pruebas de ensayo. Durante una prueba de concepto en un banco, el equipo evaluador preguntó si existían pistas de auditoría para los ensayos de prueba, y no solo para las decisiones en producción. Deberían existir.

• Documentación del modelo que detalle sus fuentes. Un líder de cumplimiento y riesgo de un banco preguntó cómo sería la documentación del modelo; por ejemplo, un registro que demuestre que el agente se configuró a partir de los propios procedimientos del banco y que se mantuvieron las reglas de su sistema anterior.

La situación actual de las guías de riesgo de modelos

El 17 de abril de 2026, la Reserva Federal (SR 26-2), la OCC (Boletín 2026-13) y la FDIC (FIL-15-2026) publicaron una guía interinstitucional revisada sobre la gestión de riesgos de modelos. Esta sustituye a la SR 11-7 y a la declaración interinstitucional de 2021 sobre la gestión de riesgos de modelos para sistemas de BSA/AML. Los modelos de aprendizaje automático utilizados en AML quedan cubiertos por ella. Sin embargo, el boletín de la OCC es muy explícito sobre dónde se detiene: "Los modelos de IA generativa y de IA agentil son novedosos y evolucionan rápidamente. Como tales, no entran en el alcance de esta guía".

Las agencias han indicado que planean publicar una solicitud de información sobre la gestión de riesgos de modelos, analizando en especial el uso que hacen los bancos de la IA. Hasta octubre de 2026, esta solicitud no se ha publicado.

Aun así, los inspectores siguen esperando pruebas. Un especialista senior en cumplimiento de sanciones de un banco comentó que todos los sistemas pasan por una validación según su política de riesgo de modelos, y que la IA, al ser más nueva, requiere pruebas exhaustivas para demostrar al regulador que están seguros con ella. El responsable del programa de BSA de la cooperativa de crédito añadió que la validación independiente de modelos es una recomendación y no una ley, pero que ahora se percibe como un requisito que los inspectores señalarán si llega a faltar.

Una respuesta débil es un calendario de actualizaciones del proveedor donde las notas de la versión son el único registro, y donde nadie en la institución aprueba formalmente los cambios que alteran las alertas.

Prueba 4: resultados legibles para un inspector

La pregunta clave: exporta tu lógica de decisión y un expediente de caso completo, y entrégaselos a alguien ajeno al equipo de AML. ¿Puede entender ambos documentos con facilidad?

El director de cumplimiento de esa misma fintech explicó que traducen las reglas del sistema a un documento de política que detalla cada regla y su función, de modo que un inspector con conocimientos generales de negocios y sin especialización en AML pueda entenderlo perfectamente. Ese es el estándar que se debe exigir a una plataforma de AML con IA: lógica y expedientes redactados para un lector que no utiliza el producto.

Los resultados legibles también protegen la comprensión interna de la propia institución. El director de cumplimiento y BSA del banco comunitario señaló que un sistema que el propio equipo no entienda sería muy difícil de defender, ya que "a los reguladores les gusta comprobar que entiendes cómo funciona tu tecnología".

La integridad de la información es parte fundamental de la legibilidad. El MLRO de la empresa de pagos comentó que los aspectos que los reguladores suelen señalar son la falta de información y las cifras que no cuadran: si una alerta abarca un conjunto de transacciones, el informe escrito debe cubrir cada una de ellas. Verifica que el expediente de la plataforma coincida exactamente con la alerta generada.

Por último, pregunta al proveedor qué observaciones han hecho los inspectores en otras instituciones que ya usan su plataforma. El líder de cumplimiento y riesgo de un banco hizo exactamente esa pregunta, incluyendo si se había solicitado la documentación de validación. Una respuesta débil es aquella en la que la lógica solo se puede leer dentro del propio software o cuando las explicaciones se redactan con términos técnicos del modelo que un inspector no puede contrastar con el caso real.

Las cuatro pruebas de un vistazo

Utiliza esta tabla como plantilla de puntuación durante tu prueba de concepto, evaluando una fila por cada prueba.

Cómo realizar las pruebas con tus propios datos

Una demostración con datos del proveedor siempre mostrará el mejor escenario posible para este. El director de cumplimiento y BSA del banco comunitario señaló que, dado que los flujos de trabajo se personalizan y adaptan a cada institución, realizar una prueba de concepto con datos propios era un requisito imprescindible antes de la compra.

1. Define los criterios de aceptación primero. Decide qué se considerará un aprobado para cada una de las cuatro pruebas antes de mover cualquier dato.

2. Realiza pruebas retrospectivas (backtesting) con alertas históricas. Ejecuta la plataforma con alertas ya cerradas y con resultados conocidos, y compara las recomendaciones del sistema con lo que decidieron tus analistas en su momento.

3. Trabaja en modo paralelo (shadow running). Pon a funcionar la herramienta junto con tus analistas en alertas reales, sin que esto afecte a las decisiones finales, y analiza el nivel de coincidencia a lo largo del tiempo. Analiza tanto los desacuerdos individuales como la tasa general de coincidencia.

4. Pregunta quién ajusta y quién prueba el sistema. El director de cumplimiento de la empresa de pagos describió la monitorización y las pruebas desde una perspectiva de cumplimiento normativo como una tarea tediosa pero crucial, y quería saber si es la institución o el proveedor quien se encarga de ajustar las reglas.

5. Pregunta cómo se prueban el sesgo, las alucinaciones y la desviación de datos (drift). Un responsable de cumplimiento senior de la misma entidad de crédito al consumo preguntó cómo evita el proveedor el sesgo, las alucinaciones y la desviación para que la entidad no acabe con un problema de prácticas desleales, engañosas o abusivas (UDAP). El líder de cumplimiento del banco preguntó cómo valida el proveedor su gobernanza de IA, incluido el control de sesgos. Solicita ver los resultados reales de esas pruebas.

6. Involucra a tu regulador en el proceso. Un responsable de gestión de riesgos de un banco patrocinador explicó que utilizar la IA en paralelo con los procesos actuales es la mejor manera de que los reguladores se vayan familiarizando y sintiendo cómodos con la tecnología con el paso del tiempo.

Errores comunes al evaluar una plataforma de AML con IA:

• Hacer las pruebas con datos de ejemplo del proveedor en lugar de usar tus propias alertas.

• Aceptar un simple resumen redactado como si fuera una evidencia sólida.

• Dar por buena la promesa de que el sistema "aprende solo" sin preguntar quién aprueba formalmente cada cambio.

• Definir los criterios de aceptación una vez iniciada la prueba de concepto.

Si supervisas programas de fintechs socios

Estas mismas cuatro pruebas aplican a cada programa que supervisas, sumando una pregunta más: ¿puedes ver las alertas, evidencias y cambios de cada socio en un único lugar, y demostrar a un inspector qué lógica de programa cambió y en qué momento exacto? El director de riesgos y estrategia digital de un banco patrocinador comentó que, en una institución anterior, un inspector había hecho mucho hincapié en la validación de datos, la validación de IA y la validación de modelos, razón por la cual ahora esas preguntas son prioritarias.

Un responsable de tecnología de BSA/AML y aseguramiento de programas en un banco patrocinador describió la incorporación de una capa de pruebas independiente entre operaciones y auditoría, permitiendo al banco mostrar a los inspectores las pruebas temáticas y dirigidas que ya se han completado. Para conocer cómo un banco patrocinador estructura esa supervisión, consulta la supervisión de AML del banco patrocinador en programas de fintechs.

Preguntas frecuentes

¿Es una plataforma de AML con IA diferente de un software de AML que utiliza machine learning?

Sí, por lo general una plataforma de AML con IA abarca más que un modelo de machine learning que clasifica transacciones. La monitorización de transacciones con IA, donde un modelo prioriza o califica las alertas, es solo una parte. El resto es la IA aplicada a la propia investigación: recopilar evidencias, resumir actividades y redactar recomendaciones o informes para que un analista los revise. Es en esta segunda parte donde la evidencia, la confirmación humana y el control de cambios necesitan sus propias pruebas específicas.

¿Qué tipo de pista de auditoría debe guardar una plataforma de AML con IA para los inspectores?

Para cada decisión, la pista de auditoría debe mostrar los datos utilizados y su origen, el razonamiento aplicado, la recomendación final, la persona que la confirmó o rechazó, y la versión exacta del modelo, de la instrucción o de la configuración que la generó. También debe registrar los ensayos de prueba y cada cambio junto con su aprobación correspondiente. Un inspector debería poder reconstruir cualquier decisión basándose únicamente en ese registro.

¿Aplica la guía de gestión de riesgos de modelos a las plataformas de AML con IA?

En parte. La guía interinstitucional revisada y publicada el 17 de abril de 2026 (SR 26-2, Boletín OCC 2026-13, FIL-15-2026) cubre los modelos de aprendizaje automático y sustituye a la SR 11-7 y a la declaración de riesgo de modelos BSA/AML de 2021. La OCC señala que los modelos de IA generativa y de agentes autónomos quedan fuera de su alcance, y la solicitud de información que las agencias planean lanzar sobre riesgo de modelos y el uso de IA aún no se había publicado hasta octubre de 2026. No obstante, las instituciones siguen validando y probando estos sistemas porque los inspectores así lo esperan.

¿Cómo puede una plataforma de AML con IA reducir el trabajo manual y mantener la aprobación humana?

La plataforma se encarga de recopilar las evidencias en todos los sistemas y redactar una propuesta de recomendación; después, el analista la revisa y toma la decisión final. Cualquier cambio sobre qué elementos requieren revisión es decisión exclusiva de la institución, tomada tras realizar pruebas retrospectivas y trabajar en paralelo, y debe quedar registrada como un cambio aprobado. El tiempo se ahorra en la tarea de recopilación de información, mientras que la responsabilidad de la firma final sigue estando en manos de las personas.

Dónde encaja Oscilar

Los agentes de Oscilar pueden funcionar como una capa independiente sobre la infraestructura tecnológica que ya tengas, o bien como parte de nuestra plataforma unificada. Están desarrollados para que siempre sea una persona quien confirme cada recomendación: el agente reúne las evidencias y propone, y el analista decide. Oscilar mantiene una pista de auditoría completa por cada decisión con el razonamiento almacenado, integrando la intervención humana en el proceso por diseño.

La plataforma está diseñada para alinearse con la guía interinstitucional de gestión de riesgos de modelos. Dado que dicha guía deja la IA generativa y agentil fuera de su alcance, ninguna declaración de conformidad se extiende de forma automática a los agentes: te invitamos a someter la capa de agentes a las cuatro pruebas explicadas anteriormente utilizando tus propios datos.

Para ver cómo se aplica esto al programa de AML de un banco, consulta la solución de AML de Oscilar para bancos.