Daniel y la Capa sobre el Core

Prólogo

Un martes, a las ocho de la mañana, tres salas distintas esperaban a Daniel al mismo tiempo.

En una, el vicepresidente de negocio quería saber cuándo estaría lista la siguiente capacidad del banco. En otra, un equipo de desarrollo llevaba dos días detenido, esperando que él tradujera una regla que solo él sabía traducir. En la tercera, el comité directivo revisaba el mapa que él había dibujado y que nadie más sabía leer del todo. El teléfono no paraba. Todos lo buscaban. No por su cargo: por lo que sabía hacer.

Y esa era la grieta que no lo dejaba dormir. Cada capacidad nueva del banco pasaba por él: cada mapa, cada traducción entre el negocio y la tecnología, cada taller donde se estructuraban las reglas y los criterios de aceptación. Él era el orquestador. Y un orquestador humano, por bueno que sea, es uno solo, y no se puede clonar.

En quince años se había vuelto la persona que traducía: se sentaba con el vicepresidente, entendía qué capacidad quería habilitar, y media hora después les explicaba a los desarrolladores qué construir y por qué. Había dibujado los mapas que todos usaban: uno de alto nivel para el comité, donde cada caja era una capacidad de negocio; y otro debajo, donde cada caja se descomponía en servicios, eventos y dependencias ejecutables.

El banco era de primera línea. Un core de depósitos con décadas de operación que, como casi todos los de su generación, había crecido hasta volverse un monolito donde nadie se atrevía a tocar nada por miedo a romper algo más. Daniel había liderado la primera grieta: empezaron por captación, un contexto acotado de fronteras limpias, el candidato natural para la primera extracción. La desacoplaron y la levantaron como un disaster recovery: un respaldo que corría en paralelo sin tomar el control, listo para responder si el monolito caía. Funcionó tan bien que el banco dejó de preguntar si se podía desacoplar el core. Ahora preguntaba qué más, y qué tan rápido.

Era el mayor éxito de su carrera. Y aun así, el cuello de botella no lo dejaba tranquilo. Entendía la arquitectura mejor que nadie en el banco. Pero quedaba una pregunta sin resolver: si los agentes podían hacer parte de lo que él hacía, coordinar, traducir, estructurar, ¿en qué se convertía su rol?

No era miedo. Era la misma curiosidad que lo había hecho bueno en lo suyo. Estaba a punto de encontrar la respuesta.

Capítulo 1 — El Diagnóstico

La consultora externa que el banco contrató para acelerar la modernización envió a alguien a hablar con Daniel. La reunión empezó distinta a las que él esperaba.

"No le voy a explicar qué es un monolito", dijo el consultor. "Usted desacopló el core de captación de un banco de primera línea y lo levantó como disaster recovery. Sabe de arquitectura más que yo. Vine a conectar lo que ya sabe con algo que todavía no encaja en su mapa."

Preguntó directo:

"¿Dónde encajan los agentes en una arquitectura de capacidades? Hoy son una caja más que no sé dónde poner."

El consultor dibujó una línea en el tiempo, no de sistemas, sino de generaciones de inteligencia. La IA simbólica de los ochenta: reglas que un humano escribía. El Machine Learning: modelos que aprendían patrones de datos históricos para predecir, como el scoring de riesgo del banco. El Deep Learning: redes que procesaban señales no estructuradas, voz, imágenes, texto libre. La GenAI: modelos que generaban lenguaje. Y los Agentes: software que no solo razona, sino que percibe el contexto, planifica y ejecuta acciones dentro de parámetros definidos.

"El banco ya usa las primeras cuatro", dijo Daniel. "Tenemos modelos de riesgo, un piloto de GenAI para atención. ¿Por qué no vemos resultados que muevan la aguja?"

"Porque compraron capacidades de IA sin arquitectura que las conecte a su operación. Eso tiene nombre: el Gen AI Paradox. La mayoría de los bancos de la región tienen IA. Pocos la vuelven operación. No porque la IA falle, sino porque la dejaron como un piloto al lado del core, no como una capa dentro del ecosistema."

Daniel reconoció el error: el mismo de los equipos que parchaban un microservicio nuevo contra el monolito en vez de definir el contrato y el evento.

"Hay algo más que un arquitecto necesita entender desde el principio", dijo el consultor. "Cada vez que un agente razona, consume Tokens: la unidad mínima de procesamiento de un modelo, y también la de costo. Aquí el costo se mide en tokens por decisión. Un agente bien diseñado no es el que razona más, sino el que razona lo justo."

Toda su carrera había optimizado llamados, latencia, acoplamiento. Ahora había una unidad más que gobernar.

Capítulo 2 — La Arquitectura

La segunda reunión fue la que cambió el mapa de Daniel.

"Usted construyó la inteligencia de negocio del banco a punta de talleres", dijo el consultor. "Cada regla, cada criterio de aceptación, cada dependencia entre capacidades vive en documentos, en wikis internas, en la cabeza de la gente. Un agente no puede operar sobre eso si no puede leerlo."

"¿Y cómo lo lee?"

"Con RAG. El agente no opera con conocimiento genérico de banca, sino con el propio del banco: sus reglas monetarias, sus políticas de producto, sus artefactos funcionales, su modelo de capacidades. Sin RAG, sería un consultor brillante con amnesia institucional. Con RAG, recupera del archivo del banco los fragmentos que esa decisión necesita: quince años de conocimiento, a la medida de cada pregunta."

Daniel pensó en su propia memoria, no los documentos sueltos, sino la red de significados: por qué una capacidad depende de otra, qué regla gobierna a cuál. "¿Y eso? El significado, no solo el dato."

"Eso es Memoria Semántica. El agente retiene el dato, el significado y las relaciones: que la causación de intereses depende del saldo, que el saldo depende de la transaccionalidad, que la contabilidad es consecuencia de esos hechos económicos. La red que usted dibuja en sus mapas, el agente la mantiene viva."

"¿Y el motor? ¿Importa cuál usemos?"

"Menos de lo que cree. El Modelo Fundacional es el motor de razonamiento: potente pero genérico, intercambiable, siempre que corra bajo el régimen de soberanía del banco, sin retención ni reentrenamiento sobre sus datos. Es el core del ecosistema: importa que esté, pero su ventaja competitiva está en sus datos y su arquitectura propia. Eso no se compra."

"¿Y cómo se conecta el agente a mis sistemas? Tengo el core, los servicios desacoplados, el bus de eventos, los canales."

"Con MCP, que se apoya en lo que usted ya construyó, su arquitectura orientada a eventos incluida. Es el protocolo que convierte un agente que razona en un sistema que opera dentro del banco, sin el enredo de integraciones punto a punto."

"Y cuando tenga varios agentes, el de capacidades, el de cumplimiento, el de riesgo, necesitan hablar entre ellos. Para eso existe el A2A Protocol: el estándar que permite que agentes de distintos dominios colaboren de par a par, como dos microservicios que se llaman por contrato, y, donde el gobierno de identidad lo permita, incluso entre proveedores distintos, sin exponer su lógica interna."

Daniel se quedó en silencio. Luego dijo, casi para sí mismo:

"Es exactamente lo que hicimos con los microservicios. Cada servicio expone un contrato, no su implementación. Lo mismo, pero entre agentes."

Capítulo 3 — El Primer Agente

Tres meses después, Daniel tenía su primer agente en producción acotada.

No automatizaba un proceso del cliente. Automatizaba parte de lo que hacía Daniel. Lo llamaron internamente "el Arquitecto de Capacidades": cuando un área de negocio pedía habilitar una capacidad nueva, digamos una modificación en la causación de rendimientos de un producto de ahorro, el agente tomaba la solicitud y producía el primer borrador de los artefactos que antes salían de tres semanas de talleres: los casos de uso, las reglas monetarias afectadas, los criterios de aceptación y, lo más valioso, el mapa de dependencias con las otras capacidades del ecosistema.

No decidía. Proponía. Daniel y los analistas funcionales revisaban, corregían y aprobaban. Pero el punto de partida ya no era una hoja en blanco y una sala llena de calendarios incompatibles, sino un borrador estructurado generado en minutos.

Lo probaron primero donde era seguro: en un entorno aislado, sin alcance sobre la operación viva.

"Eso es un Sandbox", explicó el consultor. "El mismo principio del disaster recovery que usted domina: un entorno que replica lo real sin poder afectarlo. Ahí el agente puede equivocarse sin consecuencias, y usted mide su comportamiento antes de darle alcance sobre capacidades vivas."

El agente tenía Skills específicas: estructurar artefactos, mapear dependencias, traducir requerimientos de negocio a reglas verificables. Y Tools precisas: lectura del repositorio de arquitectura, consulta del modelo de capacidades, acceso al catálogo de servicios desacoplados. Nada más.

Daniel pidió la precisión: "¿Cuál es la diferencia entre lo que el agente sabe, lo que usa y lo que se le agrega?"

"Pregunta de arquitecto. Las Skills son lo que el agente sabe hacer, sus competencias. Las Tools son los sistemas a los que puede acceder, sus permisos. Y los Plugins son capacidades empaquetadas que usted le conecta o le retira sin rediseñarlo. Tres planos distintos, y gobernar un agente es gobernar los tres por separado."

"¿Por qué tan restringido?" preguntó un desarrollador del equipo.

"Least Privilege", respondió Daniel antes que el consultor. "El Arquitecto de Capacidades no necesita tocar datos de clientes, ni el core productivo, ni los canales. Menos acceso es menos superficie de riesgo. En un banco supervisado por la SFC, eso no se negocia."

Y había un detalle que, para él, cerraba el círculo: todo, los agentes, sus skills, las integraciones, vivía en los repos del banco desde el día uno. Si el banco cambiaba de proveedor, se llevaba la inteligencia consigo; no la dejaba atrás.

Capítulo 4 — La Capacidad que Nadie Mapeó

Cuatro meses después de ese primer agente, el Arquitecto de Capacidades cometió un error que a Daniel le enseñó más que cualquier acierto.

Un área de negocio pidió habilitar una nueva modalidad de retiro para un producto de captación. El agente generó los artefactos: casos de uso impecables, reglas monetarias correctas, criterios de aceptación claros. El borrador se veía completo. Un equipo lo tomó y empezó a construir.

Lo que el agente no incluyó, porque no estaba explícito en la solicitud, fue la dependencia con la capacidad de reporte regulatorio y con las reglas de SARLAFT. Por ciertos montos y frecuencias, la nueva modalidad podía superar umbrales de monitoreo y marcar la operación como inusual y, de confirmarse, escalar a sospechosa con reporte a la UIAF. Obligaciones que nadie había mapeado. No era un error visible: era una omisión que se veía correcta.

"Esto es Alucinación en su forma más traicionera para un arquitecto", dijo el consultor en la revisión. "No es inventar un dato falso, es omitir con confianza una dependencia que nadie le dio en el contexto. El agente respondió dentro de lo que tenía, y no levantó la mano para decir 'me falta algo'."

Era el equivalente a un servicio que pasa todas sus pruebas unitarias y aun así rompe el sistema, porque la falla estaba en una dependencia que nadie modeló.

"¿Cómo lo gobernamos?"

Tres capas para impedir la delegación indebida, que el agente decidiera solo donde solo un humano puede responder. Primera: Human-on-the-Loop real. El agente no debía aprobar artefactos que tocaran capacidades de cumplimiento sin que un arquitecto humano validara las dependencias regulatorias. Daniel no desaparecía: evolucionaba de redactor de artefactos a gobernador de los límites del agente.

Segunda: LOA, Niveles de Automatización. Cada tipo de capacidad necesitaba su nivel definido. Capacidades operativas de bajo riesgo: el agente proponía y un analista aprobaba. Capacidades que tocaran reglas monetarias, cumplimiento o reporte regulatorio: revisión obligatoria de un arquitecto antes de construir. Era la diferencia entre barreras y peajes: el agente corría libre dentro de un perímetro de bajo riesgo, y solo se detenía a pedir permiso en el borde regulatorio. El mapa de LOA se volvió, en palabras de Daniel, la constitución del ecosistema.

Y una tercera, la más profunda: Explicabilidad. No bastaba con que el agente propusiera: tenía que explicar por qué, qué reglas y dependencias había considerado. Una recomendación que no se puede explicar no se puede validar; y en un banco, una decisión que afecta a un cliente y que nadie puede justificar no es admisible ante el regulador.

Y durante la investigación apareció algo más. Dos analistas habían estado pegando fragmentos del modelo de capacidades del banco, diagramas, reglas, nombres de sistemas internos, en una herramienta pública de IA para acelerar su trabajo.

"Shadow AI", dijo el consultor. "En un banco, la arquitectura interna es información confidencial; y si en uno de esos pegados viaja un dato de cliente, deja de ser un problema de propiedad intelectual y pasa a ser una violación de Habeas Data. No se prohíbe, se gobierna. La prohibición empuja el uso a la sombra. La arquitectura lo trae a la luz."

"Y ahí está la diferencia de fondo", añadió. "Una IA pública, la que cualquiera abre en un navegador, es un modelo compartido por millones, que no conoce su banco y donde lo que usted escribe puede quedar retenido, fuera de su jurisdicción. El ecosistema que están construyendo es lo contrario: un despliegue soberano, gobernado dentro del perímetro del banco, único para ustedes, con su propio contexto, sin que ningún dato salga de la jurisdicción y el control del banco. Eso es Soberanía de Datos; y en una entidad supervisada por la SFC, donde el tratamiento de datos de clientes se rige por el Habeas Data, no es una preferencia, es un requisito."

Todo apuntaba a lo mismo: la inteligencia del banco tenía que vivir dentro del banco.

Los riesgos del ecosistema agéntico tenían nombre. Y lo que tiene nombre, se gobierna.

Capítulo 5 — La Arquitectura de Inteligencia

Un año después, el banco no tenía un agente. Tenía un ecosistema, y Daniel reconocía su forma, porque era la misma que había estado dibujando toda su carrera.

El Arquitecto de Capacidades había sido el primero. Después vino el Agente de Cumplimiento, que verificaba en tiempo real que cada capacidad nueva respetara las obligaciones de SARLAFT y el reporte regulatorio, y señalaba el impacto en los requerimientos de capital de Basilea cuando una capacidad afectaba la ponderación de riesgo. Después el Agente de Datos, que mantenía la coherencia entre los hechos económicos, los saldos, la causación y la contabilidad cuando una capacidad cambiaba. Y el Agente de Migración, que asistía el desacoplamiento de nuevos dominios del monolito, proponiendo el orden, las dependencias y los riesgos de cada extracción.

No eran sistemas independientes. Era Orquestación: se coordinaban entre dominios con A2A Protocol, cada agente exponiendo lo que sabía hacer sin exponer cómo. La colaboración que antes dependía de que Daniel convocara a todos a una sala, ahora ocurría entre agentes, con Daniel gobernando, no convocando.

No era una plantilla de bots. Era una Silicon-based Workforce: colaboradores digitales con roles definidos, Skills especializadas y contratos explícitos entre ellos. Los analistas funcionales seguían ahí, pero su perfil había evolucionado: de redactar artefactos a curar los que el agente proponía, de perseguir dependencias a auditar las que el ecosistema ya había mapeado. No era supervisión: era un equipo humano-autonomía, el agente en el volumen y la consistencia, el humano en el juicio y el arbitraje.

Toda su carrera había consistido en una cosa: lograr que el negocio y la tecnología compartieran el mismo modelo mental del banco, que el vicepresidente y el desarrollador entendieran lo mismo al decir 'capacidad de captación'. Ahora los agentes compartían ese modelo: los Shared Mental Models que él pasaba años construyendo entre humanos, el ecosistema los mantenía coherentes entre agentes, en tiempo real, sin degradarse en cada traducción.

En el comité de modernización, el patrocinador del proyecto hizo la pregunta de siempre:

"¿Cómo medimos que esto funciona?"

Daniel respondió:

"Con CLASSic Metrics: costo por capacidad estructurada, latencia entre la solicitud y el artefacto listo, exactitud de las dependencias mapeadas, nivel de seguridad sobre la arquitectura interna y estabilidad del ecosistema bajo carga. El ROI Agéntico es auditable porque la línea base se midió antes del primer agente: el tiempo para estructurar una capacidad nueva bajó de tres semanas a tres días, y las omisiones de dependencias regulatorias que alcanzaban a construirse cayeron trimestre a trimestre."

Un directivo preguntó lo que Daniel esperaba que alguien preguntara:

"¿Y qué cambió de fondo en cómo trabajamos?"

Daniel lo dijo con la frase que se había vuelto su brújula:

"Dejamos de preguntar '¿Dónde está esto en el core?' y empezamos a preguntar '¿Qué capacidad del ecosistema debe resolver esto?'. Los agentes son exactamente esa capa de capacidades, la que trasciende el core. Yo llevaba años dibujándola en mapas. Ahora opera."

Epílogo

El Ecosistema Agéntico no reemplazó al arquitecto. No reemplazó a los analistas que conocen las reglas monetarias del banco. No reemplazó la modernización del core que Daniel había liderado grieta a grieta.

La terminó de explicar.

Durante años, Daniel había sido el puente entre el negocio y la tecnología — el único punto por donde pasaba la traducción, el orquestador insustituible y, por eso mismo, el cuello de botella. La arquitectura agéntica no lo sacó del centro. Lo movió de operar el puente a diseñar el sistema que ahora cruzaba solo.

La diferencia entre los bancos que modernizan de verdad y los que solo cambian de plataforma no es el presupuesto, ni el tamaño, ni el proveedor del core. Es si el arquitecto entiende que las capacidades de negocio que él pasó la carrera dibujando son, en la Era Agéntica, agentes que las ejecutan — y que sin esa arquitectura, el conocimiento del banco seguirá viviendo en talleres, documentos y en la cabeza de la gente que algún día se va.

Daniel lo entendió el día que su primer agente le entregó, en minutos, el borrador que a él le había tomado quince años aprender a escribir.