Arquitectura de referencia
para agentes IA en banca
Una arquitectura de referencia construida a partir del análisis de patrones observables en casos públicos de banca europea y adaptada al contexto latinoamericano.
Introducción
En el artículo anterior analizamos cómo algunas de las principales entidades financieras europeas están incorporando agentes de inteligencia artificial en procesos reales de negocio. Durante esa investigación esperaba encontrar arquitecturas completamente diferentes. Encontré exactamente lo contrario.
Las tecnologías cambian. Los proveedores cambian. Los modelos evolucionan. Sin embargo, en los casos públicos analizados se observa que las decisiones arquitectónicas fundamentales son similares. Ese fue, probablemente, el hallazgo más importante de toda la investigación.
Este artículo no pretende reconstruir la arquitectura interna de ninguna organización. Su objetivo es identificar patrones arquitectónicos que aparecen de forma consistente cuando una organización construye agentes preparados para producción y, a partir de ellos, proponer una arquitectura de referencia adaptada al contexto latinoamericano.
Disclaimer. Propuesta basada en información pública. Identifica patrones arquitectónicos recurrentes, no las arquitecturas internas de ninguna organización. Las tecnologías citadas son ejemplos habituales del mercado.
Alcance del análisis
Este artículo se centra en agentes de IA empresariales orientados a procesos bancarios y financieros. No pretende cubrir otros escenarios como asistentes personales, copilotos de productividad o aplicaciones puramente conversacionales.
Una arquitectura no es un diagrama
Cuando hablamos de arquitectura solemos pensar en cajas, flechas y componentes tecnológicos. Sin embargo, el verdadero valor de una arquitectura no está en el dibujo. Está en las decisiones que representa.
Una arquitectura de referencia no existe para indicar qué proveedor cloud utilizar o qué modelo de lenguaje elegir. Su propósito es ayudar a responder las preguntas correctas antes de comenzar a construir.
Más que un conjunto de tecnologías, esta propuesta representa un conjunto de decisiones arquitectónicas.
Arquitectura de referencia
Ingestión y comprensión documental
Transformar documentos no estructurados en texto y datos estructurados.
- Imágenes
- Escaneos
- Emails
- Oficios
- Formularios
- OCR
- Document Intelligence
- LLM-as-Structurer
- Tablas
- Campos clave
- Clasificación
- Validación
- Data Lake
- Blob Storage
Conocimiento y Recuperación (RAG)
Organizar y recuperar conocimiento confiable y contextual.
- Chunking
- Embeddings
- Enriquecimiento
- Vectorial
- Léxica
- Híbrida
- Mejorar precisión
- Relevancia
- Vector Database
- Índices de búsqueda
Orquestación y ejecución
Coordinar el razonamiento, la planificación, el uso de herramientas y la ejecución de acciones.
- Orquestación
- Planeación
- Memoria
- Gestión de contexto
- Workflow
- Agente único
- Multiagente especializado
- APIs
- Functions
- MCP
- OpenAPI
- Core bancario
- CRM
- ERP
- Gestión documental
- Fraude
- Canales transaccionales
Aplicación y experiencia
Entregar inteligencia en los canales donde trabajan los usuarios.
- Web
- Mobile
- Teams
- Portal
- API
- Conversacional
- Asistida
- Streaming
- Confirmaciones
- Analistas
- Ejecutivos
- Clientes
- Colaboradores
- Evaluaciones
- Métricas
- Iteraciones
Seguridad y Compliance
- Identidad y acceso
- Cifrado
- Auditoría
- Trazabilidad
- Cumplimiento regulatorio
Observabilidad y AgentOps
- Logs
- Trazas
- Métricas
- Evaluaciones automáticas
- Alertas
- Costos
IA Responsable y Gobierno
- Guardrails
- Moderación
- Evaluaciones
- Human-in-the-Loop
- Gestión de riesgos
- Gobierno de datos y modelos
Figura 1. Arquitectura de referencia para agentes IA empresariales.
La arquitectura se organiza en cuatro capas verticales y tres responsabilidades transversales. Las cuatro capas representan el flujo de información y decisión dentro del sistema: desde la comprensión documental hasta la interacción con el usuario.
Las responsabilidades transversales, seguridad, observabilidad y gobierno responsable, atraviesan toda la solución porque ninguna de ellas pertenece a una única capa. Las capas describen el recorrido de la información; las responsabilidades transversales garantizan que ese recorrido sea seguro, observable y gobernable.
Patrones observados en los casos públicos
En los casos públicos analizados se observa que, aunque las implementaciones tecnológicas son diferentes, las decisiones arquitectónicas convergen alrededor de un conjunto de capacidades comunes. Las tecnologías evolucionan. Los principios arquitectónicos permanecen.
La siguiente tabla resume esos patrones e incluye algunos ejemplos habituales del mercado, sin representar implementaciones específicas de ninguna organización.
| Decisión arquitectónica | Patrón observado en casos públicos | Ejemplos habituales del mercado |
|---|---|---|
| 1. Ingestión documental | En los casos públicos analizados se observa una etapa explícita de extracción y estructuración documental previa al razonamiento del agente. |
|
| 2. Gestión del conocimiento | Se observa el uso de mecanismos para recuperar conocimiento corporativo relevante y reducir alucinaciones antes de responder. |
|
| 3. Orquestación de agentes | Los agentes coordinan herramientas, modelos y procesos mediante una capa de planificación y ejecución. |
|
| 4. Integración con sistemas | Los agentes consumen capacidades del negocio mediante APIs y herramientas para ejecutar acciones y consultar sistemas corporativos. |
|
| 5. Gobierno y confianza | Los casos públicos incorporan controles de identidad, trazabilidad, observabilidad y prácticas de IA responsable durante todo el ciclo de vida del agente. |
|
Figura 2. Patrones arquitectónicos observados y ejemplos habituales del mercado.
Disclaimer. Propuesta basada en información pública. Identifica patrones arquitectónicos recurrentes, no las arquitecturas internas de ninguna organización. Las tecnologías citadas son ejemplos habituales del mercado.
Esa convergencia es precisamente la que inspira la arquitectura de referencia propuesta en este artículo.
Las 12 decisiones arquitectónicas que todo líder tecnológico debería responder antes del primer sprint
Después de analizar distintos casos públicos encontré algo interesante. Los bancos no construyen exactamente las mismas soluciones. Pero sí responden prácticamente las mismas preguntas antes de llevar un agente a producción.
No importa quién participe en la conversación, arquitectos, Product Owners, líderes técnicos, Project Managers o responsables de seguridad. Lo importante es que estas decisiones se tomen desde el inicio.
Capa 1 · Ingestión documental
¿Cómo transformarás documentos en conocimiento utilizable?
La estrategia de ingestión condiciona la calidad del conocimiento disponible para todo el sistema.
¿El procesamiento será síncrono o asíncrono?
La respuesta impacta directamente en la experiencia del usuario, la latencia y la capacidad de escalar.
Capa 2 · Conocimiento
¿Qué estrategia de embeddings utilizarás?
No toda búsqueda comienza cuando el usuario hace una pregunta; empieza cuando decides cómo representar el conocimiento.
¿Dónde almacenarás el conocimiento recuperable?
La elección del mecanismo de recuperación influye en rendimiento, mantenimiento y costo total de propiedad.
¿Cómo garantizarás que el agente recupere el contexto correcto?
La calidad de una respuesta depende tanto del modelo como de la información que recibe.
Capa 3 · Orquestación
¿Qué plataforma coordinará el comportamiento del sistema?
Esta decisión combina dos elecciones relacionadas: con qué desarrollarás la lógica del agente y sobre qué plataforma la ejecutarás en producción. Primero debes elegir el framework de desarrollo, que define cómo el agente razona, planifica y utiliza herramientas (por ejemplo, Semantic Kernel, LangGraph o CrewAI). Después, la plataforma de ejecución, donde el agente operará en producción y que aporta capacidades como escalabilidad, identidad y observabilidad (por ejemplo, Azure AI Foundry Agent Service, Amazon Bedrock Agents o Vertex AI Agent Builder). Aunque ambas decisiones están relacionadas, no son equivalentes: es posible desarrollar con un framework y desplegar sobre una plataforma distinta, siempre que sean compatibles.
¿Realmente necesitas un agente?
No todos los problemas requieren una arquitectura basada en agentes. Antes de decidir entre un agente único o varios especializados, conviene preguntarse si el caso de uso puede resolverse mediante un workflow determinístico, automatización tradicional o reglas de negocio. Los agentes aportan valor cuando deben razonar, planificar, utilizar herramientas o adaptarse a contextos cambiantes. Cuando el proceso siempre sigue los mismos pasos, un workflow suele ser más simple, más económico y más fácil de gobernar.
Si necesitas un agente, ¿será suficiente uno o requerirás varios especializados?
La respuesta depende del dominio, del nivel de autonomía esperado y de la complejidad del proceso. Las arquitecturas multiagente permiten distribuir responsabilidades y especializar capacidades, pero también incrementan la complejidad de coordinación, observabilidad y gobierno.
¿Cómo integrarás el agente con las capacidades del negocio?
En arquitecturas modernas es habitual utilizar APIs, funciones, flujos de integración y protocolos estandarizados como MCP para conectar los agentes con sistemas corporativos sin acoplarlos a una implementación específica.
Capa 4 · Aplicación e interacción
¿Cómo llegará el agente al usuario y cuándo deberá intervenir un humano?
La mejor experiencia suele ser aquella en la que el agente potencia las herramientas que las personas ya utilizan, incorporando mecanismos de Human-in-the-Loop cuando el contexto lo requiere.
Responsabilidades transversales
¿Cómo gestionarás identidad, permisos y observabilidad?
Toda acción ejecutada por un agente debe ser atribuible, autorizada y auditable. La observabilidad permite comprender el comportamiento del sistema, detectar desviaciones y mantener el control operativo.
¿Cómo garantizarás respuestas confiables mediante gobierno, evaluación y trazabilidad?
La IA responsable no es una capa adicional; es una responsabilidad presente durante todo el ciclo de vida del agente. Debe contemplar evaluación continua, trazabilidad, políticas de uso y mecanismos que permitan justificar las decisiones del sistema.
Idea clave
No todo caso de uso necesita un agente, muchos workflows determinísticos son más simples, baratos y fáciles de gobernar. Y no todo agente necesita convertirse en un sistema multiagente.
Insight del arquitecto
Si no defines tu estrategia de observabilidad antes del primer sprint, tu agente llegará a producción siendo una caja negra.
Cuando empiece a producir resultados inesperados, porque ocurrirá, no podrás explicar por qué. En banca, esa respuesta simplemente no es suficiente ante un regulador.
Adaptación al contexto latinoamericano
La arquitectura es la misma. El contexto no. Aunque los principios arquitectónicos convergen, las condiciones de implementación en Latinoamérica presentan desafíos propios.
Regulación
Cada país mantiene requisitos distintos en materia de supervisión, trazabilidad y gestión del riesgo.
Infraestructura
Muchas organizaciones deben integrar soluciones de IA con sistemas core, plataformas on-premise y aplicaciones heredadas.
Talento
La disponibilidad de perfiles especializados influye directamente en las decisiones tecnológicas y en la complejidad operativa que una organización puede sostener.
Costo total de propiedad
Una buena arquitectura no solo debe ser técnicamente sólida; también debe ser sostenible desde el punto de vista financiero.
La arquitectura puede ser la misma. La forma de implementarla dependerá del contexto de cada organización.
Conclusiones
Elegir un modelo de lenguaje es una decisión importante. Diseñar la arquitectura sobre la que ese modelo operará es una decisión que condicionará el proyecto durante años.
Las tecnologías evolucionarán. Nuevos modelos aparecerán. Nuevos proveedores aparecerán y las capacidades seguirán evolucionando. Pero una arquitectura bien diseñada permitirá incorporar esos cambios sin reconstruir toda la solución.
Los modelos cambiarán cada pocos meses. Una buena arquitectura puede acompañar a una organización durante muchos años.
Próximo artículo
OCR tradicional vs. Document Intelligence vs. LLM-as-Structurer
La primera decisión arquitectónica suele ser también una de las más costosas de revertir.
En el próximo artículo analizaremos cuándo utilizar cada enfoque, sus principales trade-offs y cómo elegir la estrategia adecuada según el tipo de documento, el volumen y el costo operativo.
Referencias
- Microsoft Cloud Adoption Framework for AI Agents
- Microsoft Learn — Azure AI Foundry
- Azure AI Architecture Center
- Documentación pública de Deutsche Bank
- Documentación pública de ING
- Documentación pública de BBVA
- Gartner
- McKinsey
- MIT Project NANDA
¿Te gustó este artículo? ¡Compártelo!
Karen Flores R.
Product Owner IA · SAFe® Agilist · CSM®
· Kanban System Design · Azure AI
Inspirada por el potencial de la IA generativa para impulsar la innovación y generar valor en los negocios.