Cómo escalar agentes de IA en la banca

Estimated reading time: 12 minutos

Escalar agentes de IA en financial services se convirtió en una decisión que empieza en la arquitectura y se sostiene en la gobernanza y en la operación. Cuando un agente pasa a consultar datos sensibles, activar APIs, resumir eventos o apoyar decisiones en atención, fraude, crédito y compliance, pasa a formar parte de una capa crítica de la operación.

La conversación cambia de tono: lo que importa es la previsibilidad en producción, con traza de auditoría, control de acceso, costo visible e integración confiable con el entorno que la empresa ya necesita mantener en operación.

Gartner proyecta que el 40% de las iniciativas agénticas serán canceladas antes de 2027 por falla de control y ROI indefinido. Es la misma brecha que el AI Index 2026 de Stanford mide en 88% de adopción de IA frente a menos del 10% de uso escalado de agentes: todos adoptaron, pocos sostienen en producción.

Los riesgos que crecen con la escala

Esa escala no amplía solo capacidad de procesamiento. Amplía, en la misma proporción, riesgos específicos:

• Exposición regulatoria: cuando una decisión del agente no tiene traza auditable;
• Riesgo de modelo: cuando responde con datos desactualizados, lineage incompleto o permisos más allá de lo necesario;
• Riesgo de tercero: cuando el integrador, gateway o modelo externo se vuelve una dependencia opaca;
• Riesgo de costo: cuando la cuenta crece más rápido que la gobernanza sobre ella.

Un caso fuera del sector financiero da la medida del problema en otra escala. En una presentación en el Databricks Data and AI Summit, Vikas Ranjan, de T-Mobile, describió una operación que procesa cerca de 700 TB de datos en bruto por día, con picos de 2 millones de registros por segundo.

En servicios financieros, los agentes no operan sobre datos neutros. Tocan procesos con consecuencia material: atención, onboarding, prevención de fraude, análisis documental, soporte a equipos internos, observabilidad operativa y acceso a conocimiento regulatorio. Cada uno de estos frentes depende de contexto confiable y de límites claros sobre lo que el agente puede consultar, inferir y accionar.

La arquitectura de agentes necesita nacer con gobernanza

No toda tarea de un agente exige razonamiento abierto. En bancos, tres patrones de ejecución cubren la mayoría de los casos, y cada uno responde a un perfil de riesgo diferente.

• Workflow determinístico: sin decisión del modelo en el camino, aplicado a sanitización de texto, extracción estructurada y formato de salida. Riesgo bajo, repetición alta: lo que sostiene el patrón es la previsibilidad.
• Orquestación secuencial: una etapa depende de la anterior, con un punto de revisión humana antes de la acción crítica. Un agente reúne contexto, otro estructura la respuesta, un tercero aplica política de compliance antes de liberar. Es el patrón correcto cuando el costo de errar es alto y la etapa final no puede quedar solo en manos de la máquina.
• Ejecución concurrente: tareas independientes corriendo al mismo tiempo sobre el mismo caso, por ejemplo validación documental, verificación de política interna, consolidación de contexto operativo y clasificación de prioridad de atención. Reduce el tiempo total sin renunciar a la estructura.

Los tres necesitan operar dentro de la infraestructura corporativa, heredando identidad, auditoría y observabilidad del entorno, en lugar de reconstruir esas capas para el agente.

Anthropic documenta el mismo criterio para arquitectura de agentes: se suma complejidad solo cuando mejora el resultado de forma comprobable, porque la autonomía plena cambia previsibilidad por latencia, costo y riesgo de error en cadena. En banca, ese cambio exige una decisión explícita de arquitectura.

Buenas prácticas para poner agentes en producción con menos fricción

Una de las recomendaciones más fuertes del caso T-Mobile es diseñar para escala desde el día 1. Este principio gana aún más relevancia en servicios financieros, donde los cambios estructurales después del crecimiento aumentan costo, complejidad y exposición a riesgo.

Poner agentes en producción, por lo tanto, exige decisiones que van más allá de la elección del modelo. Es necesario definir dónde el uso de LLM realmente agrega valor, cómo los agentes acceden a los datos, qué controles valen durante la ejecución y cómo se observará y operará todo el sistema.

Un camino pragmático incluye:

1. Definir dónde usar LLM: separar flujos determinísticos de aquellos que realmente exigen interpretación o generación por parte del modelo.
2. Elegir la estrategia de orquestación: usar ejecución secuencial cuando una etapa depende de la anterior y concurrente cuando tareas independientes pueden ocurrir en paralelo.
3. Conectar agentes a datos gobernados: centralizar catálogo, linaje y control de acceso para definir qué información puede recuperar cada agente.
4. Crear observabilidad desde el inicio: instrumentar logs, alertas, monitoreo y runbooks antes de entrar en producción.
5. Tratar el costo como requisito de arquitectura: considerar consumo de modelo, recuperación, almacenamiento y procesamiento durante el diseño de la solución, y no solo después del aumento de uso.
6. Distribuir conocimiento operativo: reservar tiempo de sprint para documentación, base de conocimiento y transferencia de ownership.

Este último punto es especialmente importante para la escala. Los equipos que operan agentes necesitan reducir la dependencia de especialistas aislados y permitir que nuevos ingenieros entiendan rápidamente la arquitectura, los flujos críticos y los procedimientos de operación.

RAG como capa de conocimiento

Cuando el agente necesita trabajar con conocimiento corporativo, Retrieval-Augmented Generation (RAG) es una de las estrategias para proporcionar información actualizada al large language model (LLM) en el momento de la consulta.

En lugar de incorporar todo el conocimiento a los parámetros del modelo, la arquitectura recupera información relevante de una base y agrega ese contexto al prompt usado para generar la respuesta.

El flujo se divide en tres etapas:

1. Ingesta e indexación: documentos, bases de conocimiento y datos operativos se dividen en bloques, o chunks. Cada fragmento se convierte en una representación vectorial mediante modelos de embeddings y se almacena en un índice de búsqueda.
2. Recuperación y reordenamiento: la consulta combina búsqueda vectorial semántica con búsqueda léxica, como BM25. Modelos de reordenamiento, como cross-encoders, priorizan los fragmentos más relevantes antes de enviarlos al LLM.
3. Generación fundamentada: el LLM recibe los contenidos recuperados como contexto para generar la respuesta y cita las fuentes o los fragmentos usados como referencia.

RAG o fine-tuning para conocimiento corporativo

Evaluamos el fine-tuning como alternativa para incorporar conocimiento corporativo en entornos bancarios, pero lo descartamos en la mayoría de los escenarios analizados.

Esta elección también tiene trade-offs. La etapa de recuperación agrega latencia y amplía la arquitectura que debe operarse. Índices, pipelines de actualización, permisos, estrategias de recuperación, evaluación y monitoreo pasan a formar parte del producto.

Dónde la arquitectura suele perder calidad

Chunking sin considerar el contexto

Dividir documentos solo por una cantidad fija de caracteres o tokens separa información que debería permanecer junta. Cuando esto ocurre, la recuperación pierde contexto y la calidad de la respuesta cae.

Estrategias como semantic chunking o estructuras parent-child preservan las relaciones entre los fragmentos y mejoran la calidad del material enviado al modelo.

Control de acceso solo en la aplicación

Proteger solo la interfaz deja un vacío en la arquitectura. Las reglas de autorización también deben valer en la capa de recuperación.

Role-Based Access Control (RBAC) y Access Control Lists (ACLs) aplicados durante la búsqueda restringen los documentos recuperados según los permisos de quien hace la consulta.

En un banco, por ejemplo, una persona con acceso a informes operativos no debería recuperar fragmentos de documentos restringidos a la dirección.

El contenido sin autorización no debe entrar en el contexto enviado al LLM.

Índice vectorial desactualizado

La calidad de las respuestas también depende de la actualización de la base consultada. Cuando un documento cambia y el índice mantiene una versión anterior, el agente trabaja con información desactualizada.

Reindexar toda la base con cada cambio aumenta el costo y el procesamiento. Una estrategia de sincronización incremental con el Lakehouse actualiza solo los datos modificados y reduce la necesidad de reprocesar todo el conjunto.

Operación en la stack Databricks

En la stack Databricks, estas responsabilidades se distribuyen entre diferentes componentes:

• Mosaic AI Vector Search: búsqueda y recuperación sobre el índice vectorial
• Unity Catalog: gobernanza, permisos y linaje de los datos
• MLflow: evaluación de fidelidad y relevancia de las respuestas
• Lakehouse Monitoring: seguimiento de drift y calidad a lo largo del tiempo

Los agentes y el RAG funcionan como sistemas de producción, no como una llamada de LLM conectada a un prompt.

La calidad final depende de toda la cadena: datos, permisos, recuperación, orquestación, generación, evaluación, observabilidad y operación.

Diseñar estas capas desde el inicio reduce el retrabajo cuando el volumen crece y transforma un experimento con LLM en una arquitectura capaz de operar a escala.

Madurez antes de autonomía

Según el estudio Unlocking Enterprise AI, de Economist Impact con Databricks (2024), el 85% de las empresas globales ya usa IA generativa y la proyección llega al 99% hacia 2027. En el mismo estudio, el 22% considera su infraestructura lista para IA y el 37% evalúa que sus modelos están preparados para producción. La adopción corrió más rápido que la capacidad de sostenerla.

TreeID desarrolló una autoevaluación de madurez para la adopción de agentes de IA en producción. El cuestionario identifica brechas de gobernanza, dependencias técnicas y puntos de riesgo operativo en cuatro capas: datos, integraciones, aplicaciones y observabilidad. Con el resultado, la organización define qué priorizar antes de ampliar la autonomía de los agentes.

Preguntas frecuentes

Conclusión

Escalar agentes de IA empieza antes de elegir el agente. La autonomía solo se sostiene cuando los datos, las integraciones, las aplicaciones y la observabilidad ofrecen gobernanza, trazabilidad y mecanismos claros de intervención.

Cuanto mayor la autonomía, mayor necesita ser la capacidad de controlar lo que el agente accede, seguir cómo opera e intervenir cuando sea necesario. En producción, la escala depende menos de modelos más capaces y más de una arquitectura preparada para operar con seguridad, previsibilidad de costo y control.

Fuentes

• Stanford HAI. «The 2026 AI Index Report». Universidad de Stanford, 2026.
• Gartner. «Gartner Predicts Over 40% of Agentic AI Projects Will Be Canceled by End of 2027». Junio de 2025.
• Anthropic. «Building Effective AI Agents». Diciembre de 2024.
• Economist Impact y Databricks. «Unlocking Enterprise AI». Noviembre de 2024.
• Vikas Ranjan (T-Mobile). «Managing Databricks at Scale». Databricks Data and AI Summit, 2025.