El problema que nadie había resuelto en 15 años
El banco llevaba 15 años sabiendo que el proceso de scoring para PYMEs era un cuello de botella. Tres a cinco días hábiles. Ocho fuentes de datos distintas. Analistas que copiaban datos a mano entre sistemas. Un 35% de operaciones que subían a comité no porque fueran complejas, sino porque el analista no tenía tiempo de completar el análisis.
Habían probado un modelo de ML clásico. Mejoró marginalmente la velocidad. No resolvió el problema real: la integración de fuentes heterogéneas y la explicabilidad de la decisión ante el auditor. Cuando el inspector del Banco de España pregunta "¿por qué aprobasteis esta operación que resultó en impago?", necesitas una respuesta concreta, no "el modelo lo dijo".
La arquitectura: cuatro agentes especializados + un supervisor
El diseño parte de una pregunta simple: ¿qué haría un analista de riesgo experto si pudiera consultar todas las fuentes simultáneamente y en tiempo real? La respuesta no es un agente monolítico que "hace todo". Es especialización y orquestación.
Cuatro agentes especializados coordinados por un agente supervisor con el patrón ReAct (Reasoning + Acting):
- Agente de Datos Internos: conectado al core T24 vía API REST. Extrae posición completa, historial de productos e incidencias.
- Agente de Datos Externos: CIRBE, Registro Mercantil, Informa/D&B y noticias recientes del solicitante.
- Agente de Análisis Sectorial: base vectorial con ratios medios por sector y CNAE de los últimos tres ejercicios (datos BdE, actualización trimestral).
- Agente de Síntesis: recibe el output de los tres anteriores, aplica la política de crédito y emite la recomendación con justificación explícita.
Las cuatro consultas iniciales se lanzan en paralelo. De ~24 segundos (secuencial) a ~7 segundos (paralelo). El prompt caching sobre la política de crédito de 180 páginas redujo los tokens facturados y la latencia ~85% en las partes estáticas del contexto.
Los tres errores que cometimos (y lo que aprendimos)
Error 1 — CIRBE sin API
El servicio de riesgos del Banco de España no tiene API pública. Construimos un conector con Selenium serverless en Lambda. Tres semanas más de lo previsto, y el conector se rompía cada vez que el BdE actualizaba la web. La solución a largo plazo fue que el banco negociara acceso al fichero batch de CIRBE para actualización nocturna. El Browser de AgentCore habría resuelto esto de forma más robusta.
Error 2 — Los LLMs no hacen bien los cálculos numéricos
El agente pasaba las cuentas anuales al modelo para calcular ratios. El modelo generaba ratios incorrectos cuando los estados financieros tenían formatos no estándar o notas que redefinían partidas. La regla que aprendimos: nunca delegar cálculos numéricos al LLM. Amazon Textract extrae las tablas; Python calcula los ratios con tipo NUMERIC (aritmética decimal exacta, equivalente al COMP-3 de COBOL). El LLM solo interpreta y contextualiza.
Error 3 — El comité de riesgos bloqueó tres meses
La primera demo técnicamente fue perfecta. La sala hizo una pregunta que no habíamos preparado: "Si el agente recomienda aprobar una operación que resulta en impago, ¿quién asume la responsabilidad?" No teníamos respuesta para el equipo legal. Tres meses parado hasta obtener dictamen de un despacho especializado en regulación financiera. Ese dictamen fue lo que desbloqueó la aprobación. La gobernanza es tan crítica como el código.
Los números reales
Tiempo de decisión: de 3-5 días a 4 horas para operaciones hasta 250.000€. Capacidad por analista: de 6-8 expedientes/día a 18-22. Escalado a comité: del 35% al 12% del volumen. ROI primer año: 2,1M€ sobre una inversión de 380K€.
El impacto más valorado por el cliente no fue el ahorro en FTEs — fue el expediente de auditoría automático. El inspector del Banco de España ya no pide documentación manual. Accede directamente al repositorio de expedientes del sistema con el tracing ReAct completo de cada decisión.
Lo que esto significa para los CTOs de banca española
Los proyectos de IA agéntica en banca española no fallan por la tecnología. Fallan porque llegan al comité de riesgos sin un pack de gobernanza: ¿quién es responsable de cada decisión? ¿cómo se audita el ciclo ReAct? ¿cómo se revierte una decisión incorrecta? Ese pack es tan crítico como el código. Prepáralo desde la fase de diseño, no después de la primera demo.