Mashreq da a los agentes de código sus estándares de integración, no sus rieles de pagos. Piloto de IBM Bob
Mashreq informa hasta un 60 a 70% menos de tiempo en diseño y resolución de incidencias de integración en un piloto de IBM Bob, con agentes que usan un gateway MCP. ¿Qué controla?
Escuche este artículo · 5 min
Narración completa del artículo, generada con IA.
Un asistente de código que sabe Java es fácil de encontrar. Uno que sabe cómo un banco concreto nombra sus colas de mensajes, qué estándares de API exige su equipo de pagos y cómo se resolvió la incidencia de integración del último trimestre es raro. Y es el único tipo que ayuda de verdad al equipo de integración de un banco.
Esa es la apuesta de un piloto que IBM anunció el 12 de octubre. Mashreq, un banco con sede en Emiratos Árabes Unidos, está probando IBM Bob en todo el ciclo de ingeniería de integración: diseño y planificación de soluciones, desarrollo, revisión de código y resolución de incidencias en producción. Los primeros resultados, en palabras del banco y de IBM, mostraron “hasta un 60-70% de reducción del tiempo dedicado a actividades de diseño y resolución de incidencias de integración”, con algunas tareas que exigían dos o tres horas de trabajo manual completadas en minutos.
Las cifras son iniciales, anunciadas por el proveedor y limitadas a esas dos actividades. La arquitectura es lo más interesante.
El contexto es el producto
Los agentes no trabajan solo con conocimiento general. IBM Context Forge, una capa de orquestación basada en el Model Context Protocol, les da acceso al conocimiento de integración del banco, a las especificaciones de API, a los estándares de arquitectura y al contexto operativo. Un gateway seguro gestiona unas 4.000 solicitudes al mes de agentes de IA hacia sistemas conectados de banca digital, pagos y sistemas empresariales.
Detrás hay una plataforma de integración en producción construida sobre IBM Cloud Pak for Integration, IBM MQ, App Connect, API Connect, Red Hat OpenShift y Confluent, que procesa de media 650 transacciones por segundo entre canales digitales, pagos y sistemas empresariales. Esa cifra describe el tráfico de la plataforma, no algo que hagan los agentes.
Los dos lados del piloto
Ingeniería donde se pilota Bob
- Diseño y planificación de soluciones
- Desarrollo
- Revisión de código
- Resolución de incidencias en producción
Los agentes obtienen contexto mediante Context Forge
Plataforma de integración en producción
- MQ, App Connect, API Connect
- Confluent sobre OpenShift
- Unas 650 transacciones por segundo
Los sistemas que la ingeniería modifica
Un gateway todavía no es un modelo de permisos
El anuncio habla de “acceso seguro” a través del gateway. No dice qué aplica el gateway: si el acceso de los agentes a los sistemas conectados es de solo lectura, qué identidad lleva cada solicitud, qué sistemas entran en el alcance de la resolución de incidencias ni cómo se registran y revisan las solicitudes. Son esos detalles los que deciden si se trata de un acceso controlado o simplemente cómodo, y conviene preguntar por ellos antes de copiar el diseño.
Para un banco, la diferencia importa. Un agente que lee especificaciones de API y estándares de arquitectura para redactar una integración es de bajo riesgo. Un agente que consulta un sistema de pagos para diagnosticar una incidencia en producción está leyendo datos vivos y sensibles, bajo la identidad de alguien o de algo. Como argumentamos en el MCP empresarial empieza por la identidad, cada llamada a una herramienta necesita un nombre detrás, y el gateway es donde debe verificarse ese nombre.
Lo mismo vale para lo que sale. Nada en el anuncio sugiere que los agentes modifiquen por su cuenta sistemas de producción, y el lector no debería deducirlo. Cuando un agente redacta un cambio de integración, ese cambio sigue teniendo que pasar por el proceso de cambios del banco, que es donde la autoría del agente debe registrarse y aprobarse.
Modelos locales, lo siguiente
Mashreq también estudia un futuro despliegue on-premises de IBM Bob para casos de uso críticos, con modelos alojados localmente para atender requisitos de residencia de datos y regulatorios. Es una evaluación, no un compromiso, pero sigue la lógica que describimos cuando IBM Bob pasó a ser autoalojado: en cargas reguladas, dónde se ejecuta el agente forma parte de la decisión de producto.
Quitando los nombres de los proveedores, el piloto ofrece un patrón útil para cualquier institución regulada. Proporcione a los agentes de código los estándares y especificaciones de la propia organización a través de una interfaz gobernada, mida el efecto en actividades de ingeniería concretas en lugar de en “productividad”, y mantenga el camino entre lo que produce el agente y la producción pasando por los controles que ya existen. Son las reglas del gateway las que convierten esto de piloto en diseño.