Agentes de IA para cumplimiento normativo: ¿Tu piloto es real o solo una muy buena demostración?

Al inicio de nuestro reciente seminario web sobre "desarrollar frente a comprar", le hicimos una pregunta sencilla a la audiencia: ¿En qué punto se encuentra su organización con los agentes de IA? 

La mayoría (62%) respondió que está probando uno o dos pilotos.

Jonathan Awad, cofundador y director ejecutivo de Baselayer, no dejó pasar eso por alto. "Probar uno o dos agentes es una respuesta un poco evasiva", comentó en directo ante una sala llena de personas que acababan de elegir esa opción. 

Tenía razón, y el resto del panel respaldó su postura durante toda la sesión. Se sumaron Jason Chorlins (Asesoría en Servicios Financieros, Kaufman Rossin) y nuestro director de producto, Saurabh Bajaj, con la moderación de Phil Goldfeder (American Fintech Council).

En resumen: la mayoría de los pilotos de agentes superan la prueba de la demostración, pero fallan en la práctica operativa. A continuación, presentamos cinco mitos que los equipos de cumplimiento suelen creer sobre sus pilotos y las respuestas del panel. Considere este artículo como su dosis de cazadores de mitos sobre IA agéntica para octubre. 

En pocas palabras: ¿Qué diferencia a un piloto de agente de IA que funciona de uno que se estanca?

Un agente que funciona transforma el día a día de su equipo, mejora las métricas clave de la dirección de cumplimiento y se adapta cuando sus procedimientos cambian. Un piloto estancado genera resultados atractivos en una demostración, pero no cambia nada en una jornada habitual. Los cinco mitos, en breve:

• Decir "estamos haciendo pilotos" dice muy poco. La verdadera prueba es si el equipo notaría la ausencia del agente si este desapareciera.

• Un resultado con buen aspecto no es una prueba concluyente. Pida a un investigador experimentado que revise y reproduzca una muestra de las decisiones del agente.

• Los analistas no suelen ser el cuello de botella. El verdadero problema radica en los datos y los flujos de trabajo.

• Desarrollarlo internamente solo es más barato si se hace a la perfección. Para la mayoría de los equipos, comprar primero y desarrollar después es la opción más segura.

• El primer agente funcional no es la meta final. Las normativas, las listas y los productos cambian continuamente, y el agente debe mantenerse al día.

¿Cuál es la diferencia entre el nivel de demostración y el nivel operativo?

El nivel de demostración evalúa si un agente parece impresionante en una presentación. El nivel operativo evalúa si responde eficazmente en su flujo de trabajo habitual y con su volumen diario. Saurabh ilustró con cifras la frecuencia con la que los equipos confunden ambos conceptos.

"Nueve de cada diez proyectos de agentes superan el nivel de demostración, pero no alcanzan el nivel operativo." Saurabh Bajaj, director de producto, Oscilar

¿Cómo saber de qué lado de la línea está su proyecto piloto?

Cada uno de los cinco mitos siguientes refleja una confusión entre el nivel de demostración y el operativo, y concluye con una comprobación rápida que puede aplicar a su propio piloto.

Mito 1: "Estamos probando un par de agentes".

La objeción de Jonathan apuntaba a la sinceridad. Realizar un piloto puede significar que el agente hace un trabajo real y de confianza, o simplemente "tareas muy sencillas y rápidas que no tienen impacto real". Casi siempre, afirmó, se trata de lo segundo.

Describió la adopción de la IA agéntica en la banca como una distribución polarizada. La mayoría de las instituciones financieras no la tocan en absoluto, mientras que un grupo reducido, con grandes equipos especializados, la utiliza prácticamente para todo. Citó el ejemplo de JPMorgan, que recientemente bloqueó el acceso de agentes externos a sus cuentas mientras desarrolla los suyos propios.

Saurabh observa que el punto medio de esa distribución empieza a consolidarse. Hace un año, la mayoría de los clientes potenciales con los que hablaba no sabían por dónde empezar. Hoy, esas conversaciones difusas sobre pruebas de concepto se están transformando en uno o dos agentes en los que los equipos confían plenamente.

¿Cómo es un agente que realmente funciona? La respuesta de Jonathan fue sencilla: se integra en la rutina diaria, ayuda al equipo a gestionar el volumen de trabajo pendiente y facilita la formación del personal nuevo. Funciona cuando, en sus palabras, "ya no puedes imaginar tu vida sin él".

También mencionó la brecha de confianza. Muy pocos equipos permiten que un agente resuelva casos de forma autónoma, ni siquiera falsos positivos evidentes. El objetivo que describió es contar con una cola de trabajo matutina ordenada según el nivel de certeza del agente, para que los analistas sepan exactamente dónde concentrar primero su atención.

"Probar uno o dos agentes es una respuesta un poco evasiva." Jonathan Awad, cofundador y director ejecutivo, Baselayer

Comprobación clave: Si desconectara a su agente el viernes, ¿alguien lo notaría el lunes?

Mito 2: "Los resultados se ven geniales".

Este es el ejemplo clásico del nivel de demostración. La advertencia de Saurabh fue contundente: "Muchas empresas lanzan lo que yo llamo un modelo de lenguaje integrado superficialmente y lo llaman agente". Puede redactar un resumen impecable y lucirse en la demostración, pero no cambia en absoluto el trabajo del equipo.

También destacó que generar contenido vistoso con IA hoy en día es muy fácil. Cualquiera puede redactar páginas de informes y recomendaciones, y gran parte de ese material termina en documentos que nadie lee (y que probablemente otros pedirán a su propia IA que resuma). Esto eleva el estándar de lo que realmente aporta valor.

Dicho de otra forma: un director de cumplimiento no evalúa un agente por su redacción. Saurabh enumeró lo que realmente importa:

• Tiempo de gestión de alertas

• Precisión en la toma de decisiones

• Tiempo de adaptación a nuevas estrategias y tipologías

• Aumento de productividad del equipo gracias al agente

Lo ilustró con claridad: si un analista tarda unos 60 minutos en redactar un informe de actividad sospechosa (SAR), o unos 50 minutos en la revisión inicial de una alerta, la cuestión es si un agente puede reducir ese tiempo a una quinta parte. Jason añadió la prueba más fiable: tome una muestra de resoluciones reales del agente, entrégueselas a un investigador experimentado y pídale que reproduzca las decisiones. Si discrepan, ajuste el agente y vuelva a probarlo.

"Esta es una prueba de preparación mucho mejor que fijarse en si los resúmenes tienen buen aspecto." Jason Chorlins, Kaufman Rossin

En Kaufman Rossin aplican el mismo criterio a sus propios agentes. Jason explicó que su equipo utiliza tres o más agentes para tareas de revisión de primer nivel y que, antes de confiar en ellos, definieron con exactitud el formato y los estándares mínimos que debe cumplir cada entrega. 

El agente de revisión de alertas de PBC de Oscilar parte del mismo principio: propone una resolución fundamentada y el analista toma la decisión final.

Comprobación clave: Entregue 25 decisiones recientes a su investigador principal. ¿Cuántas de ellas modificaría?

Mito 3: "Nuestros analistas son el cuello de botella".

Comentarios del chat: Un asistente lo resumió de forma directa: cuando un analista debe comprobar 15 puntos en sistemas desorganizados, se culpa a la persona por la lentitud en lugar de señalar al sistema. Añadió que la mayoría de los equipos no son conscientes de lo complejos que pueden llegar a ser sus propios flujos de trabajo.

Saurabh respaldó esta idea durante la sesión. Un procedimiento operativo estándar típico para la monitorización de transacciones o el control de sanciones suele requerir "verificar estos 15 puntos". Cumplir con eso implica consultar distintos sistemas y comprobar si es factible extraer la información. Es un problema de integración de datos, y los datos bancarios suelen estar fragmentados. Un agente implementado sobre esa base hereda todo ese desorden.

Jason describió la transformación cuando esa infraestructura funciona bien: invertir la proporción de trabajo. Antes, los analistas dedicaban cerca del 80% de su tiempo a preparar la alerta para su revisión y solo el 20% a investigarla. Al delegar la recopilación en los agentes, esa relación se invierte y el analista puede centrarse en evaluar si la actividad es coherente para ese cliente.

También enumeró los problemas más comunes en los pilotos con dificultades:

• Datos de clientes incompletos

• Criterios de investigación poco claros

• Informes que los analistas no pueden contrastar con los registros de origen

Ninguno de estos fallos es atribuible a los analistas. Tampoco lo es otra cuestión planteada en el chat: muchos proveedores están incorporando agentes de IA, pero estos agentes no comparten el contexto. El fraude, la admisión de clientes, la prevención del blanqueo de capitales y la atención al cliente se influyen mutuamente; por tanto, los agentes aislados ofrecen una visión incompleta a cada equipo.

"Contratar a 100 personas más no solucionará el problema. La clave está en lograr que el equipo actual de 100 rinda como si fueran mil. ¿Cómo podemos dotarlos de herramientas que multipliquen su capacidad?" Saurabh Bajaj, Oscilar

Comprobación clave: Analice 10 alertas de principio a fin. ¿Cuánto tiempo dedicó el analista a recopilar información y cuánto a tomar la decisión?

Mito 4: "Lo construiremos nosotros mismos".

Phil preguntó a Jonathan si "desarrollar frente a comprar" era el enfoque adecuado para el panel. Su respuesta fue que la primera decisión es determinar cómo, dónde y cuándo conviene usar agentes. La elección entre desarrollar o comprar viene después y depende de dos factores: contar con la cultura adecuada y disponer del equipo técnico necesario.

Si todavía se busca el respaldo interno de la organización, advirtió, el desarrollo propio conlleva riesgos. Generar grandes expectativas sobre los agentes y entregar algo apresurado o con fallos "podría suponer un retroceso considerable". En cambio, con un equipo técnico sólido y una cultura propicia, desarrollar ciertas herramientas internamente puede tener sentido.

Saurabh propuso un método sencillo de evaluación: situar el problema en dos ejes, según su velocidad de cambio y la cantidad de fuentes de datos que consulta. Las herramientas sencillas, autónomas y estables son buenas candidatas para el desarrollo interno. Cualquier proceso que cambie con rapidez o integre múltiples fuentes es preferible confiarlo a un proveedor especializado.

Solo un cuadrante se presta al desarrollo interno. Todo lo que cambia con rapidez o integra múltiples fuentes corresponde a un proveedor externo.

Los costes también se trataron en el turno de preguntas. Un asistente consultó sobre los principales riesgos del desarrollo interno, desde la seguridad de los datos hasta la estabilidad de los resultados. Jonathan señaló que un proveedor especializado absorbe gran parte de ese riesgo, ya que ese es su negocio principal y no un proyecto secundario. ¿Es más barato desarrollarlo internamente? "Si se hace a la perfección, sin duda. Si surgen complicaciones, en absoluto; termina saliendo mucho más caro".

Jason añadió que muchos bancos medianos y comunitarios carecen de esa experiencia técnica interna, lo que hace aún más importante elegir al colaborador adecuado.

¿Dudas sobre el origen de su próximo agente? Nuestra evaluación de 2 minutos sobre desarrollar vs. comprar analiza la preparación de su equipo a partir de las cuestiones planteadas por el panel.

Mito 5: "Una vez implementado, ya está todo hecho".

Jason ha visto proyectos triunfar y estancarse, y observa siempre la misma pauta. Los que triunfan conocen a fondo sus propios flujos de trabajo: qué se considera una alerta rutinaria frente a una escalación, qué datos son fiables y quién tiene la autoridad para resolver. Además, cuentan con la capacidad de mantener integraciones, probar cambios y supervisar el rendimiento tras el despliegue.

Los que se estancan asumen que lograr el primer agente operativo es el final del camino. Pero cuando cambia una norma de PBC, se actualiza una lista de sanciones o un nuevo producto de pagos introduce nuevos patrones, el agente se queda obsoleto. "Nunca hay que considerarlo una meta final", afirmó Jason.

Saurabh explicó por qué mantenerse al día es más difícil de lo que parece. Los procedimientos de PBC y prevención del fraude cambian constantemente. Si cada modificación exige recurrir a un programador o abrir una incidencia con el proveedor, se vuelve a depender de terceros para cada actualización. Además, las respuestas del agente requieren reglas claras para los pasos siguientes, como solicitar más datos o escalar el caso; no se puede improvisar en un flujo de cumplimiento normativo.

"Los programas que veo estancarse son los que consideran que el primer agente funcional ya es prácticamente la meta final." Jason Chorlins, Kaufman Rossin

Otros dos factores cambian una vez que el agente está activo: es necesario verificar que siga tomando decisiones correctas en cientos de alertas, no solo caso por caso. Y cuando un auditor pregunte el motivo de una decisión, debe ser posible reproducirla con toda la documentación que la respalda. Saurabh destacó que realizar esto de forma manual puede llevarle a un equipo de uno a dos meses.

Comprobación clave: Tome el último cambio en sus procedimientos. ¿Cuánto tardó en aplicarse al agente y quién realizó la modificación?

¿Cómo saber si un agente de IA para cumplimiento normativo está funcionando?

Hágase las cinco preguntas siguientes. Si sus respuestas sinceras coinciden con la columna central, su proyecto piloto aún se encuentra en el nivel de demostración.

Llevar su piloto de IA agéntica más allá de la demostración

Ninguno de los ponentes propuso frenar el avance, sino avanzar con rapidez y con los pies en la tierra. En definitiva: elija un flujo de trabajo de gran volumen que domine bien, mida las métricas clave de su dirección de cumplimiento y asigne a alguien de confianza la revisión del trabajo del agente. Solo entonces sabrá si cuenta con un piloto viable o simplemente con una demostración vistosa.

¿Desea ver el debate completo? Acceda a la grabación bajo demanda.

Preguntas frecuentes

¿Cómo saber si un agente de IA para cumplimiento normativo está funcionando?

Compruebe si transforma el trabajo diario, no solo si genera buenos resultados a simple vista. Un agente operativo está integrado en la rutina del equipo, influye en métricas medibles como el tiempo de resolución y la precisión, y mantiene el nivel cuando un investigador experimentado reproduce una muestra de sus decisiones.

¿Los equipos de cumplimiento deben desarrollar o comprar agentes de IA?

Depende de su cultura corporativa, su capacidad técnica y la naturaleza del problema. Las herramientas sencillas y estables, como un asistente de consulta de políticas o un generador de resúmenes, se prestan al desarrollo interno. Los casos que evolucionan con rapidez o requieren múltiples fuentes aconsejan recurrir a un proveedor. Muchas entidades optan por comprar al principio y desarrollar más adelante.

¿Qué métricas deben utilizarse para evaluar un agente de IA en cumplimiento?

Comience por las prioridades de la dirección de cumplimiento: tiempo de gestión de alertas, precisión en las resoluciones, agilidad para adaptarse a nuevas estrategias o tipologías y aumento de productividad del equipo. Combine esto con revisiones periódicas de muestras por parte de investigadores experimentados.

¿Por qué se estancan los proyectos piloto de agentes de IA?

Por lo general, debido a la base sobre la que se sustentan. Los pilotos con problemas suelen arrastrar datos de clientes incompletos, criterios de investigación ambiguos y explicaciones difíciles de contrastar con los registros. También se estancan cuando se considera que el primer agente funcional es la meta definitiva y este pierde vigencia ante cambios normativos o de producto.

¿Pueden los agentes de IA resolver alertas de cumplimiento de manera autónoma?

Hoy en día muy pocos equipos lo permiten, incluso ante sanciones claras o falsos positivos evidentes. La práctica habitual es que el agente recopile la información, sugiera una resolución razonada y clasifique las alertas según su nivel de certeza, dejando la decisión final en manos del analista. El equipo de cumplimiento mantiene en todo momento la responsabilidad de la investigación y del reporte formal.