Cómo integrar agentes de IA en su sistema de gestión de riesgos

Última actualización: septiembre de 2026

Usted cuenta con un stack de riesgo. Llevó años armarlo, está bajo contrato y funciona lo suficientemente bien como para que nadie quiera plantearse reemplazarlo. Al mismo tiempo, le están preguntando —probablemente alguien del directorio— cuál es su plan respecto a los agentes de IA.

Ambos hechos no se contradicen, pero la mayor parte de lo que se escribe sobre agentes de IA asume que sí. La pregunta útil no es a cuál de sus sistemas reemplaza un agente. Es qué necesita un agente de los sistemas que ya utiliza y si su stack actual puede proporcionárselo.

Eso demuestra ser un problema de integración y de responsabilidad antes que un problema de modelos. Las entidades que están obteniendo valor de los agentes no son las que reemplazaron más software. Son las que pudieron darle al agente suficiente contexto para decidir, un espacio delimitado para actuar y una persona responsable del resultado.

En resumen

• Incorporar agentes es, ante todo, un problema de integración. El modelo rara vez es la limitación.

• Un agente necesita cinco cosas de su stack: contexto, un límite claro, un lugar donde actuar, una forma de ser evaluado y un responsable humano directo.

• Los agentes añadidos de forma aislada generan automatizaciones desconectadas. El contexto compartido es una propiedad de la capa inferior, no de un agente individual.

• No necesita reemplazar su plataforma. Los agentes pueden funcionar como una capa independiente sobre la infraestructura existente o como parte de una plataforma unificada.

• Un agente se gana el paso a producción operando primero en paralelo con sus analistas. Esa fase paralela no es una formalidad: es lo único que genera evidencia de que el agente funciona con su portafolio.

• La confianza es el factor determinante, no la capacidad técnica. Si una decisión no puede reconstruirse más adelante y ser validada por una persona, la integración no está terminada.

• Tener «todo en Excel» es un punto de partida habitual y no es un motivo de descarte.

Qué significa realmente la integración de agentes de IA para un equipo de riesgo

Integrar un agente de IA implica conectarlo a los datos, al flujo de trabajo y a la supervisión de los sistemas que la entidad ya utiliza, de modo que tenga la visibilidad necesaria para decidir, actuar donde realmente se realiza el trabajo y responder por lo decidido.

Se trata de una definición más acotada y exigente que la habitual. La mayoría de los textos sobre integración de agentes se centran en conectores: enlazar un agente a aplicaciones de negocio mediante APIs para leer registros y activar acciones. Esa es una labor de ingeniería real, pero no es la parte difícil aquí.

Para un equipo de riesgo, lo complejo es que una decisión debe ser explicable, no solo generada. Un agente que accede a sus datos pero no puede registrar información en su gestor de casos es solo una demo. Un agente que puede actuar pero no puede mostrar qué analizó es un riesgo. En este contexto, la integración implica resolver ambas carencias a la vez.

Por qué fallan los agentes cuando se incorporan de forma aislada

El fallo más común no suele ser un modelo deficiente, sino un conjunto de agentes que no pueden ver el trabajo de los demás.

Las entidades que desarrollan sus propios agentes suelen crearlos caso de uso por caso de uso: un agente para clasificar alertas aquí, otro para extraer datos de documentos allá, cada uno con sus propios accesos y su propia visión del cliente. Cada uno trabaja de forma aislada. Juntos reproducen con exactitud el problema que intentaban resolver: que ninguna parte de la organización tiene el panorama completo.

Un responsable de cumplimiento BSA lo resumió así: «El área de préstamos no lo sabía y nos quedamos con el crédito asignado». No es un problema de la IA. Es el problema que la IA debía resolver, y un agente añadido de forma aislada lo hereda en lugar de corregirlo.

Existe un segundo fallo a destacar. El director de riesgos de un equipo que había creado agentes con un modelo de propósito general nos comentó que este «se confunde y alucina». La reacción instintiva es atribuirlo a la calidad del modelo. A menudo es un problema de contexto: un modelo competente que razona sobre datos combinados de cuatro proveedores distintos, sin una visión uniforme del cliente, generará respuestas erróneas con total seguridad.

El contexto compartido no es algo que se le pueda añadir a un agente. Es una propiedad de la capa que está debajo: una estructura de datos en tiempo real, inteligencia sobre dispositivos y comportamiento, reglas y una gestión de casos que ya concuerdan entre sí. Para eso sirve una capa de toma de decisiones de riesgo con IA, y es la razón por la que la elección de la plataforma y la adopción de agentes son, en realidad, la misma cuestión.

Las cinco cosas que un agente necesita de su stack actual

Esta es la guía práctica. Compruébela con su propio entorno antes de evaluar el agente de cualquier proveedor.

La mayoría de las entidades cuentan con tres de estos puntos y carecen de los mismos dos: un lugar donde actuar y una forma de ser evaluado. Esos dos son también los más económicos de resolver, ya que requieren trabajo de integración y no de reestructuración de datos.

Cómo pasa realmente un agente a producción

El cumplimiento normativo no es un botón mágico. Un agente no pasa de una demo convincente a tomar decisiones por sí solo, y cualquier proceso que se salte los pasos intermedios no es algo que le interese justificar más adelante.

En su lugar, se trabaja en paralelo. El agente y sus analistas gestionan la misma lista de tareas. El analista toma su decisión habitual y luego dedica un par de minutos a revisar la conclusión del agente y valorar si está de acuerdo. Esa carga de trabajo parece excesiva al principio, pero ese es precisamente el objetivo.

Esa comparación constituye la evidencia. No se trata de una prueba de rendimiento de un proveedor ni de una cifra de precisión teórica: son sus analistas, con sus tipologías y su portafolio, aprobando o discrepando de una decisión específica por razones comprobables. Solo cuando esa concordancia es constante y se entienden las discrepancias, se empieza a delegar parte del trabajo al agente.

Esto lleva semanas en lugar de meses y ofrece resultados tangibles. MoneyGram opera con agentes en producción bajo este esquema: las revisiones de alertas AML de nivel 1, que antes tomaban más de 30 minutos, ahora se cierran en menos de dos, con el mismo equipo y cerca de un 45% menos de falsos positivos.

El cambio de enfoque fundamental es que complementar la labor humana no es una concesión ante partes interesadas cautelosas. Es el único mecanismo que genera la evidencia exigida para una decisión regulada. Nadie pondría un modelo en producción sin validarlo con sus propios datos; con un agente ocurre lo mismo, solo que el conjunto de validación es el criterio de sus analistas en lugar de un archivo de datos etiquetados.

Condiciones indispensables antes de delegar una decisión en un agente

La confianza es el factor decisivo, no la capacidad técnica. En conversaciones con líderes de riesgo, la pregunta que surge de forma espontánea nunca es «¿puede hacer esto?», sino «¿por qué debería confiar en él?».

Deben cumplirse tres requisitos que responden a necesidades de integración, no a cuestiones teóricas:

Muestra su trabajo. Cada decisión incluye las pruebas utilizadas y el razonamiento aplicado, guardados junto con la decisión y no reconstruidos a posteriori.

La decisión se puede reconstruir en el futuro. No resumir, sino reconstruir. Si un auditor pregunta dentro de nueve meses por qué se cerró una alerta específica, necesitará los datos tal y como estaban en ese momento.

Una persona da su visto bueno. Alguien con nombre y cargo formaliza la aprobación, y esa validación queda registrada.

Como señaló un responsable de cumplimiento: «Tiene que ser defendible ante un auditor». Si su función de riesgo de modelos se evalúa bajo la guía SR 11-7, aplican los mismos principios para un agente, y la información requerida será la citada anteriormente.

Conviene saber que esto es actualmente una cuestión de criterio y no una norma fija. Cuando la OCC, la Reserva Federal y la FDIC actualizaron la guía de gestión de riesgo de modelos en abril de 2026, dejaron a la IA generativa y basada en agentes expresamente fuera de su alcance, argumentando que estos modelos son «novedosos y evolucionan con rapidez», y prometieron una solicitud conjunta de información sobre el uso de IA en los bancos. Dicha solicitud aún no se ha publicado.

Por tanto, todavía no existe una pauta establecida. Lo que sí encontrará es un auditor que preguntará cómo prueba el agente, cómo lo monitoriza y dónde reside la supervisión humana, sin un marco oficial al que remitirse. Definir esos tres aspectos antes del despliegue le permitirá responder con seguridad en lugar de improvisar. El gobierno de los agentes es un tema más amplio de lo que este artículo puede abarcar; se analiza en detalle en seguridad, gobierno y auditabilidad para agentes de riesgo basados en IA, incluyendo los cinco límites habituales de una revisión de seguridad y la documentación que responde a cada uno.

Capa independiente o plataforma unificada

Ambas son opciones reales de implementación, y es importante plantear el balance con franqueza.

Los agentes de Oscilar pueden operar como una capa independiente sobre la infraestructura existente. Esto permite incorporarlos a mitad de un contrato: no es necesario reemplazar nada y los agentes se integran en sus reglas, flujos de trabajo y gestor de casos actuales.

Implementarlos en la plataforma unificada cambia un factor clave, que es el tema central de este artículo: en un único stack, el contexto compartido es automático y no requiere configurarse por cada agente. Los agentes visualizan alertas, casos, decisiones previas e historial como un conjunto integrado, simplemente porque existe una única fuente de información.

Empiece de forma independiente si sus contratos así lo exigen. Lo esencial es tener claro cuál de los dos enfoques está priorizando.

Por dónde empezar si su stack no está listo

La mayoría de los stacks no están listos, y eso es una situación de partida normal, no un impedimento. Trabajar con «todo en Excel» es algo que escuchamos a diario de equipos competentes en instituciones consolidadas.

Cuatro pasos, en orden:

1. Elija una tarea con límites claros y una referencia humana con la que contrastar resultados. La clasificación de alertas suele ser la primera opción, ya que las decisiones son frecuentes y ya quedan registradas.

2. Asegúrese de poder reconstruir una decisión antes de permitir que un sistema automatizado tome alguna. Si hoy no puede hacerlo con una decisión humana, un agente no lo resolverá.

3. Opere en paralelo antes de delegar cualquier flujo de trabajo.

4. Designe al responsable antes de la puesta en marcha, no tras la primera discrepancia.

Nada de esto requiere una compra inmediata y vale la pena realizarlo con independencia de los agentes que elija implementar más adelante. Si desea ver cómo operan los agentes una vez sentadas las bases técnicas, consulte la demostración guiada del Centro de Agentes.

Preguntas frecuentes

¿Qué es la integración de agentes de IA?

La integración de agentes de IA consiste en conectar un agente a los datos, al flujo de trabajo y a la supervisión de los sistemas que una entidad ya utiliza, para que cuente con la información necesaria para decidir, actuar donde se realiza el trabajo y responder por el resultado. En el ámbito del riesgo, se distingue de una simple conexión a aplicaciones mediante APIs, ya que las decisiones de riesgo deben ser explicables y reconstruibles, no solo generadas de forma automática.

¿Se pueden integrar agentes de IA con los sistemas de riesgo existentes?

Sí. Los agentes pueden operar como una capa independiente sobre la infraestructura actual, integrándose en las reglas, flujos de trabajo y gestores de casos ya existentes. No se requiere nuevo software, sino accesos adecuados: el agente necesita contexto para decidir, un límite claro de acción, un lugar donde registrar sus conclusiones, una forma de contrastarse con decisiones humanas y un responsable asignado.

¿Cómo integran los bancos los agentes de IA con sus plataformas core heredadas?

Normalmente, sin modificar el core. El agente consulta la capa de datos que ya reúne la información del sistema principal y registra los resultados en el gestor de casos o en el flujo de trabajo de los analistas. Así, el core se mantiene como fuente de consulta y no como objetivo directo de integración, lo que minimiza el impacto del cambio y facilita la aprobación del proyecto.

¿Es necesario sustituir la plataforma de riesgo para utilizar agentes de IA?

No. Los agentes pueden desplegarse sobre lo que ya utiliza, lo que hace viable su adopción en mitad de un contrato vigente. Ejecutarlos en una plataforma unificada les otorga un contexto compartido de forma automática sin necesidad de configurarlo por agente, pero esto supone una optimización, no un requisito indispensable.

¿Cómo se regulan la revisión humana, la auditabilidad y el rendimiento de los agentes?

Mediante tres mecanismos: un registro de auditoría que guarda las pruebas y el razonamiento de cada decisión, una validación humana que queda registrada documentalmente y una comparación continua entre las decisiones del agente y las del equipo humano. Las entidades sujetas a marcos de gestión de riesgo de modelos deben gestionar un agente como cualquier otro modelo en producción: validándolo antes de su despliegue y supervisándolo de forma continua.