Tu agente puede ser nuevo. Tus sistemas no: el desafío de integrar Agentic AI con la arquitectura financiera existente

El agente puede haberse desarrollado en semanas. Los sistemas con los que debe operar llevan años —a veces décadas— formando parte del negocio. Por eso, cuando Agentic AI pasa de una demo a producción, el problema deja de estar solamente en el modelo: aparece la arquitectura enterprise que lo rodea.

Un agente puede funcionar perfectamente dentro de un entorno controlado.

• ✓ Consulta determinada información.
  
• ✓ Utiliza una API.
  
• ✓ Ejecuta una tarea.
  
• ✓ Devuelve un resultado convincente.

Pero llevar ese mismo caso a una entidad financiera real cambia la conversación. La información puede estar distribuida entre core, sistemas satélite, data warehouses, documentos y aplicaciones legacy. Algunas capacidades están expuestas mediante APIs, otras no. Hay procesos batch, eventos en tiempo real, integraciones históricas, permisos, reglas de negocio y dependencias entre sistemas. El agente es nuevo. El ecosistema que necesita utilizar no. Y ese suele ser uno de los puntos donde un MVP técnicamente exitoso empieza a encontrar dificultades para escalar.

Un agente no genera valor por estar conectado a un modelo

El valor aparece cuando puede participar de un proceso real. Eso puede implicar:

• consultar información
  
• combinar fuentes
  
• recuperar documentación
  
• crear o modificar registros
  
• activar workflows
  
• utilizar herramientas
  
• interactuar con APIs
  
• o coordinar acciones entre distintas aplicaciones.

Por eso, la arquitectura de Agentic AI no termina en el LLM. Necesita una capa que conecte la inteligencia con el lugar donde efectivamente ocurre el negocio. En servicios financieros, esa capa puede incluir:

• Core bancario.
  
• APIs internas y externas.
  
• CRM.
  
• Sistemas de fraude y riesgo.
  
• Data Warehouse y Data Lake.
  
• Documentos y repositorios de conocimiento.
  
• Aplicaciones legacy.
  
• Cloud y on-premise.
  
• Workflows operativos.

La calidad del agente no elimina ninguna de esas dependencias.

Integrar un agente no es simplemente darle acceso a una API

Las APIs son fundamentales, pero la discusión es más amplia. Una integración necesita resolver qué información expone, quién puede utilizarla, qué operaciones habilita y qué ocurre cuando algo falla. Un agente que opera sobre sistemas reales necesita comprenderse dentro de esas mismas reglas. Por ejemplo:

• ¿La API permite únicamente lectura o también escritura?
  
• ¿La acción es síncrona o asíncrona?
  
• ¿Qué ocurre si el sistema destino no responde?
  
• ¿Puede repetirse una operación sin duplicar una transacción?
  
• ¿Cómo se maneja una excepción?
  
• ¿Qué versión de la API utiliza?
  
• ¿Quién es responsable de ese contrato?
  
• ¿Qué queda registrado?
  
• ¿Cómo se autentica el agente?

La integración deja de ser simplemente conectividad. Se convierte en parte del modelo de control.

Cuanto más autónomo es el agente, más importante se vuelve la integración

Un copiloto puede ayudar a una persona a encontrar información sin modificar ningún sistema. Un agente operativo es diferente, porque puede leer una situación, decidir qué herramienta utilizar y ejecutar una acción. Cada uno de esos pasos depende de que exista una integración confiable. Si el dato llega tarde, el agente decide sobre información desactualizada. Si una API responde de forma inesperada, el workflow puede quedar incompleto. Si dos sistemas utilizan definiciones distintas, el agente puede combinar información que semánticamente no significa lo mismo. Si una acción no es idempotente, un reintento puede generar consecuencias duplicadas.
La inteligencia del agente no corrige automáticamente esos problemas. En algunos casos incluso los amplifica, porque el agente puede utilizar esas integraciones de manera más dinámica que una aplicación tradicional.

La IA hereda la arquitectura existente

Una de las promesas alrededor de Agentic AI es que puede simplificar la interacción con sistemas complejos, y puede hacerlo. Pero simplificar la experiencia del usuario no significa simplificar automáticamente la arquitectura debajo. El agente sigue necesitando acceder a la información correcta, los permisos siguen existiendo, los contratos de integración siguen existiendo, las reglas de negocio siguen existiendo, los sistemas legacy siguen existiendo.

Por eso, intentar “poner IA arriba” de una arquitectura fragmentada puede generar una nueva capa de complejidad en lugar de resolver la anterior. El agente no elimina la deuda de integración, la encuentra.

¿Hace falta modernizar todo antes de incorporar agentes?

No, y esperar una modernización completa probablemente haría inviable muchos casos de uso. La pregunta más útil es otra: ¿Qué capacidades de la arquitectura actual necesitan exponerse de forma segura y controlada para que este caso pueda operar?
En algunos escenarios alcanzará con utilizar APIs existentes, en otros será necesario construir una nueva capa de servicios, puede ser necesario desacoplar determinada información del core, crear un mecanismo de eventos, construir una capa de conocimiento mediante RAG, o encapsular funciones legacy detrás de interfaces controladas. La estrategia no debería ser reemplazar todo. Debería ser crear una arquitectura que permita a los agentes utilizar lo que ya existe sin quedar atados directamente a su complejidad.

Tools: la nueva superficie de integración

Los agentes no interactúan con sistemas solamente mediante APIs tradicionales.
Utilizan herramientas o tools que representan capacidades disponibles para completar una tarea.
Una tool puede:

• consultar una base
  
• buscar un documento
  
• llamar una API
  
• actualizar un caso
  
• iniciar un workflow
  
• enviar una comunicación
  
• o invocar a otro agente.

Esto genera una nueva capa que también necesita gobierno.

• ¿Qué herramientas están disponibles?
  
• ¿Quién las publica?
  
• ¿Qué agente puede utilizarlas?
  
• ¿Qué versión está activa?
  
• ¿Qué permisos requieren?
  
• ¿Qué pasa si cambia el sistema que existe detrás?

A medida que aumenta el número de agentes, administrar tools de manera aislada para cada caso puede convertirse rápidamente en otra forma de deuda tecnológica.

Integración e identidad tienen que viajar juntas

Supongamos que un agente puede utilizar una herramienta para consultar información de clientes. La integración funciona, pero todavía falta responder:

• ¿bajo qué identidad realiza la consulta?
  
• ¿qué clientes puede ver?
  
• ¿hereda permisos del usuario?
  
• ¿utiliza una identidad propia?
  
• ¿puede solamente consultar o también modificar?
  
• ¿queda registrado quién inició la acción?

Por eso, integrar Agentic AI sin diseñar identidad y autorización deja una parte crítica del problema sin resolver. La integración define cómo llega, la identidad y los permisos definen hasta dónde puede llegar.

Open Finance vuelve esta conversación todavía más relevante

Para bancos, fintechs, cajas y otras organizaciones financieras en Perú, la evolución hacia ecosistemas más abiertos incrementa la cantidad de APIs, terceros, flujos de información e interacciones que deben gestionarse.
Agentic AI agrega otra capa a ese escenario.
Un agente puede convertirse en consumidor de APIs, en orquestador de servicios o incluso en iniciador de determinadas acciones. Eso aumenta la necesidad de diseñar claramente:

• autenticación
  
• autorización
  
• consentimiento
  
• trazabilidad
  
• límites de ejecución
  
• y responsabilidades.

No porque Agentic AI sea incompatible con arquitecturas abiertas, al contrario, cuanto mayor es la interoperabilidad, más importante se vuelve gobernar quién puede utilizarla y para qué.

Un ejemplo: un agente para gestión de reclamos

Imaginemos un agente capaz de analizar un reclamo y ayudar a resolverlo.
Para completar el proceso podría necesitar:

1. consultar información del cliente
   
2. recuperar movimientos desde el core
   
3. buscar procedimientos internos
   
4. consultar un CRM
   
5. verificar una operación
   
6. crear o actualizar un ticket
   
7. y eventualmente disparar un workflow.

El modelo puede comprender perfectamente el reclamo, pero el valor del caso depende de todo lo demás. Si la información está fragmentada, el agente no tiene contexto, si los sistemas no exponen las capacidades necesarias, no puede actuar, si las herramientas no tienen permisos correctamente diseñados, aumenta el riesgo, y si no existe trazabilidad, después resulta difícil reconstruir lo ocurrido.
El caso de IA termina siendo, en gran medida, un caso de integración.

Qué conviene revisar antes de conectar un agente

Antes de llevar una iniciativa a producción, conviene mapear:

• Sistemas: ¿Con qué aplicaciones necesita interactuar?
  
• Datos: ¿Qué información necesita y dónde reside?
  
• Interfaces: ¿Existen APIs, eventos, servicios o conectores adecuados?
  
• Identidad: ¿Bajo qué autoridad utiliza esas interfaces?
  
• Acciones: ¿Qué operaciones puede ejecutar?
  
• Fallas: ¿Qué sucede ante timeout, indisponibilidad o resultados inesperados?
  
• Observabilidad: ¿Podemos reconstruir toda la secuencia?
  
• Ownership: ¿Quién administra cada integración y cada herramienta?

La respuesta a estas preguntas permite detectar si la dificultad está realmente en el agente o en el ecosistema que necesita utilizar.

Agentic AI necesita una arquitectura de integración preparada para cambiar

El objetivo no debería ser construir una integración perfecta para un único agente. Tampoco crear una gigantesca plataforma genérica antes de demostrar valor. El punto intermedio consiste en identificar qué capacidades conviene desacoplar y reutilizar.

• APIs.
  
• Conectores.
  
• Identidad.
  
• Tools.
  
• Acceso a conocimiento.
  
• Logging.
  
• Políticas.

De esa forma, el próximo caso no tiene que reconstruir necesariamente todas las piezas desde cero.

El verdadero desafío no es conectar IA con sistemas

Es lograr que pueda operar sobre ellos de manera confiable, controlada y repetible. Ahí está la diferencia entre una integración para una demo y una arquitectura preparada para producción. En COA abordamos ese desafío combinando experiencia en Data + Integration + AI + Governance, especialmente en organizaciones financieras donde los nuevos agentes tienen que convivir con cores, APIs, arquitecturas híbridas y sistemas legacy.

¿Qué tan preparada está tu arquitectura para escalar IA?

Realizá la Evaluación de Madurez de IA de COA y obtené una visión de las capacidades y brechas que pueden condicionar tus próximas iniciativas.

Si ya estás trabajando en un caso que necesita integrarse con core, datos, APIs o procesos existentes:

Preguntas frecuentes

¿Agentic AI requiere reemplazar los sistemas legacy?

No. Muchos casos pueden integrarse con sistemas existentes mediante APIs, servicios, conectores y capas de integración adecuadas. El objetivo es evitar que el agente dependa directamente de la complejidad interna de cada sistema.

¿Por qué las APIs son importantes para agentes de IA?

Porque permiten exponer capacidades y datos de forma estructurada. Pero una API por sí sola no resuelve identidad, autorización, manejo de errores, observabilidad ni gobierno.

¿Qué son las tools en Agentic AI?

Son capacidades que el agente puede invocar para interactuar con sistemas externos, por ejemplo consultar una base, utilizar una API, actualizar un workflow o llamar a otro agente.

¿Qué relación existe entre integración y Agent Governance?

La integración define qué sistemas y capacidades puede utilizar el agente. Governance establece quién puede utilizarlas, bajo qué condiciones, con qué límites y cómo queda registrada cada acción.

Leé también: El MVP de IA funciona. ¿Qué falta para llevarlo a producción?