MCP, A2A y ACP en la práctica: cómo un banco conecta herramientas y agentes entre sí.

Una serie de lanzamientos de modelos en los últimos años ha seguido un patrón similar. Primero aparece un modelo más avanzado, que escribe código de mejor calidad, razona de manera más clara y puede manejar contextos más extensos. Sin embargo, en cuestión de semanas la emoción disminuye, ya que un modelo inteligente por sí solo, dentro de una ventana de chat, aún no puede consultar el saldo de un cliente, detener una transacción sospechosa ni obtener el historial crediticio de un solicitante. La inteligencia nunca fue el verdadero cuello de botella; lo fue la conexión.

El esfuerzo de ingeniería ha pasado de centrarse en el tamaño bruto de los modelos a enfocarse en el diseño de protocolos. Tres especificaciones abordan el problema de la conexión: MCP (Model Context Protocol), A2A (Agent-to-Agent) y ACP (Agent Communication Protocol). Juntas determinan cómo un modelo accede a las herramientas, cómo un agente se comunica con otro y cuántos agentes pueden compartir tareas sin caer en el caos.

Un ejemplo ilustra todo lo que se menciona a continuación: un banco que desarrolla un asistente de IA capaz de detectar fraudes, evaluar solicitudes de préstamo y comunicarse con los sistemas bancarios principales, al tiempo que mantiene un nivel de auditoría suficiente para satisfacer a las autoridades reguladoras.

Por qué un modelo básico necesita protocolos

Dejado por sí solo, un modelo de lenguaje solo puede predecir texto. Si se le pregunta si la cuenta de un cliente muestra actividad sospechosa este mes, o bien rechazará la consulta o dará una respuesta correcta pero errónea, ya que el registro real de transacciones está fuera de su alcance.

Las primeras soluciones conectaban directamente los modelos a APIs REST, uno tras otro. Un asistente contra fraudes requería código personalizado para la API bancaria, más código para el CRM y aún más para la gestión de casos. Las implementaciones pequeñas funcionaban bien, pero las más grandes se enfrentaron a tres problemas:

• Nada era reutilizable. El conector de banca central del equipo de fraude no servía de nada para el equipo de préstamos, aunque ambos necesitaban datos de transacciones idénticos, por lo que cada proyecto tenía que comenzar desde cero.
• El estado desaparecía entre las solicitudes. Las APIs están diseñadas sin estado. Un analista que obtuvo las transacciones de un cliente y, dos preguntas después, preguntó por algo inusual en “esos datos” descubrió que una integración API simple no mantenía ningún vínculo entre las dos solicitudes, a menos que los ingenieros crearan manualmente una capa de memoria.
• Los permisos se añadían de forma ad hoc. Cada acción bancaria requiere una verificación de permisos y un registro para los auditores. Un analista junior de fraude puede leer el historial de transacciones, pero no puede aprobar la reversión de una transferencia. Integrar cada API de forma individual hacía que tales reglas detalladas fueran fáciles de error y difíciles de demostrar a un auditor.

Un protocolo cierra el contrato una sola vez. Ningún banco necesita diseñar su propio método para que un modelo invoque el motor de detección de fraudes, ya que MCP proporciona una única interfaz. Ningún equipo tiene que crear su propio sistema para transferir un caso de un agente de fraudes a un agente de cumplimiento, porque A2A ofrece otro. HTTP lo hizo para las aplicaciones en red y SQL lo hizo para las bases de datos: un lenguaje compartido que permite que sistemas desarrollados de forma independiente trabajen juntos.

Cinco etapas del diseño

El diseño de sistemas ha pasado por cinco etapas, tanto en la banca como en otros campos.

1. Un LLM simple. El modelo responde únicamente con datos de entrenamiento. Puede explicar qué es el KYC, pero no puede determinar si el perfil de un cliente en particular cumple con las reglas de KYC del banco, ya que nunca ve los registros de ese cliente.
2. Generación reforzada por recuperación de información. El modelo se conecta a un almacén de documentos como el manual de cumplimiento y las guías regulatorias anteriores, de modo que las respuestas se basan en contenido actual, privado y específico de la organización, y no en conocimientos generales adquiridos durante el entrenamiento.
3. Agentes. El modelo puede no solo recuperar información, sino también actuar. Un asistente de cumplimiento ahora puede citar la política KYC y, además, verificar los documentos del cliente archivados en relación con ella, marcando cualquier discrepancia.
4. Sistemas multiagente. Cuando un solo agente se encarga simultáneamente de la detección de fraudes, la aprobación de créditos y la comunicación con los clientes, se vuelve poco fiable y difícil de gestionar. La tarea se divide entre especialistas, como un agente de fraudes, un agente de préstamos y un agente de comunicación con clientes, cada uno experto en un área específica.
5. Protocolos. Cuando hay muchos agentes y muchos sistemas, se necesita una forma estándar para que puedan descubrirse mutuamente, compartir contexto y comunicarse de manera segura. MCP, A2A y ACP satisfacen esa necesidad.

Hoy en día, la mayoría de los bancos se encuentran entre la tercera y la cuarta etapa. Existen agentes individuales, a menudo uno por caso de uso, pero al no haber un protocolo compartido entre ellos, cada nuevo agente sigue requiriendo una integración personalizada adicional. Ese es el propósito de los protocolos: cerrar esa brecha.

Llamadas a herramientas, la capa subyacente a MCP

Antes de MCP existían las llamadas a herramientas, también conocidas como llamadas a funciones. Estas permiten que un modelo solicite una acción externa en lugar de solo generar texto, y MCP se construye sobre esta base.

La mecánica es sencilla. Para cada herramienta disponible, un desarrollador escribe un JSON Schema que incluye un nombre, una descripción y parámetros de tipo, y lo envía al modelo junto con la instrucción. Cuando el modelo determina que se necesita una herramienta, no ejecuta nada. Su salida es un objeto JSON estructurado que indica el nombre de la herramienta y proporciona los argumentos, y la aplicación que lo rodea ejecuta la función y devuelve el resultado al modelo. Un esquema bancario se ve así:

{
  "name": "get_customer_transactions",
  "description": "Returns transactions for a customer above a given amount, within a date range",
  "parameters": {
    "type": "object",
    "properties": {
      "customer_id": {"type": "string"},
      "min_amount": {"type": "number"},
      "start_date": {"type": "string", "format": "date"},
      "end_date": {"type": "string", "format": "date"}
    },
    "required": ["customer_id", "start_date", "end_date"]
  }
}

Supongamos que un analista de fraudes solicita ver las transacciones recientes y de gran valor de un cliente, superiores a cinco mil dólares en el último mes. Para responder, no se utiliza la memoria. En su lugar, el modelo emite una llamada a get_customer_transactions con el ID del cliente, el umbral de monto y el rango de fechas. La aplicación luego consulta la base de datos de banca central en busca de los datos reales, los devuelve y el modelo los convierte en un resumen legible.

Las herramientas simples que realizan llamadas manejan bien un único modelo con unas pocas herramientas predefinidas. Los problemas surgen cuando hay decenas de herramientas dispersas entre sistemas de banca central, detección de fraudes, CRM y gestión de documentos, herramientas que deben añadirse sin tener que volver a desplegar cada cliente, o cuando existe una herramienta que los asistentes de fraudes y préstamos deben compartir de forma segura. MCP aborda precisamente esos problemas.

MCP en detalle

MCP llegó de Anthropic a finales de 2024 como un estándar abierto para conectar aplicaciones de IA con sistemas externos. Piénselo como un adaptador universal. Anteriormente, conectar un asistente bancario con el sistema bancario principal, el motor de detección de fraudes y el CRM requería tres integraciones incompatibles. Ahora, cualquier cliente compatible con MCP puede comunicarse con cualquier servidor compatible con MCP, de la misma manera que cualquier dispositivo USB se adapta a cualquier puerto USB.

La aritmética de M por N

El problema subyacente es combinatorio. Conectar M herramientas con N aplicaciones genera una matriz que se vuelve inmanejable a medida que ambos números aumentan. Un banco con cinco sistemas internos y cuatro asistentes (detección de fraudes, préstamos, servicio al cliente, cumplimiento) necesitaría hasta veinte conectores personalizados. Un protocolo estándar reduce esa cantidad a cinco más cuatro, ya que cada sistema y cada asistente implementan MCP una sola vez.

Tres roles

• Host: la aplicación de IA que ve realmente el usuario, por ejemplo, la interfaz de asistente de un analista de fraudes.
• Client: un componente dentro del host que gestiona una conexión a un servidor MCP y se encarga de la comunicación a nivel de protocolo.
• Server: la parte que expone capacidades, es decir, datos o acciones. Un banco podría tener un servidor frente al sistema bancario principal, otro frente al motor de detección de fraudes y un tercero frente al repositorio de documentos, cada uno mantenido por el equipo responsable del sistema subyacente.

Tres primitivas que puede ofrecer un servidor

• Resources contienen datos de solo lectura que el modelo puede incorporar al contexto, como un estado de cuenta o el estado de los documentos de verificación de identidad. Al igual que una solicitud GET, sirven para informar sin modificar nada.
• Herramientas realizan acciones como congelar parte de una cuenta o enviar un caso a un oficial de cumplimiento. Al igual que una solicitud POST, modifican el estado, lo que las convierte en las primitivas que más necesitan controles de aprobación humana en un banco.
• Plantillas son modelos parametrizados reutilizables que guían al modelo hacia una solicitud bien formada. Un ejemplo es una plantilla estándar de escalación de fraudes que todos los asistentes de analista utilizan de la misma manera, de modo que ningún equipo mantiene su propia versión ligeramente diferente.

Muestreo, descubrimiento y transporte

El muestreo permite a un servidor solicitar al LLM del host una completación, aprovechando el razonamiento del modelo para una subtarea. Un servidor de almacenamiento de documentos podría usarlo para que el modelo resuma un largo acuerdo de préstamo antes de devolverlo, y un analista humano revisaría aún ese resumen antes de tomar acción.

El descubrimiento ocurre cuando un cliente se conecta y pregunta al servidor qué recursos, herramientas e instrucciones ofrece, lo que mantiene a MCP dinámico. Una vez que el equipo de fraude publica una nueva herramienta para verificar el historial del dispositivo de un cliente, cada asistente conectado puede utilizarla de inmediato, sin necesidad de modificar el código del cliente.

El formato de comunicación es JSON-RPC 2.0, a través de uno de dos transportes comunes. Stdio es adecuado para servidores que operan en la propia máquina del cliente. HTTP con Server-Sent Events, o HTTP transmisible por secuencias, es adecuado para servidores remotos. Un servidor de banca central dentro del centro de datos y detrás del firewall se accedería mediante HTTP remoto con autenticación adecuada, y no mediante Stdio.

Seguridad

Las industrias reguladas son donde MCP obtiene sus ingresos, aunque no proporciona controles de forma automática. Ofrece a los ingenieros un lugar único y consistente para crearlos y aplicarlos, en lugar de tener que reinventar la seguridad en cada integración. Una implementación bancaria en producción debe:

• exigir OAuth 2.1 cuando los clientes se autentican en los servidores;
• otorgar a cada herramienta solo los permisos que necesita, de modo que el token de un analista junior no pueda acceder a funciones como approve_wire_transfer;
• mantener un registro de cada llamada a una herramienta;
• exigir una confirmación explícita por parte de un humano antes de realizar una llamada que cambie el estado, como congelar una cuenta o eliminar una restricción.

Así es una implementación de MCP

Tres capas componen una implementación bancaria típica. El host es la interfaz de chat o el entorno de ejecución del agente que ve el usuario, como por ejemplo un asistente de investigación. Un cliente MCP dentro del host abre sesiones con los servidores, envía solicitudes de detección y transmite las llamadas a las herramientas de un lado a otro. Cada servidor gestiona un único sistema de registro, como la banca central, el motor de detección de fraudes y el almacén de documentos, y cada uno es mantenido y protegido por el equipo responsable de él.

Una investigación de fraude muestra la ruta de la solicitud:

1. Un analista desea obtener todas las transacciones superiores a diez mil dólares de un cliente en los últimos treinta días, además de verificar si la huella del dispositivo ha cambiado recientemente.
2. El LLM del host determina que se necesitan dos llamadas a herramientas y le indica al cliente que ejecute get_transactions en el servidor de banca central y get_device_history en el servidor del motor de detección de fraudes.

El cliente envía solicitudes JSON-RPC a ambos servidores a través de HTTPS.

Cada servidor verifica el alcance OAuth del analista y su derecho a acceder a los datos de ese cliente, consulta su propio sistema de respaldo y responde.

El cliente pasa ambas respuestas al modelo, el cual las combina en un único resumen.

Todo, tanto las llamadas como las respuestas y la identidad del analista, se registra en el registro de auditoría.

Un servidor mínimo en Python que utiliza el patrón oficial del SDK muestra cuán poco código necesita una herramienta:

from mcp.server.fastmcp import FastMCP

mcp = FastMCP("core-banking-server")
@mcp.tool()
def get_transactions(customer_id: str, min_amount: float, days: int) -> list:
    """Fetch transactions above a threshold for a customer, scoped to the caller's authorization."""
    # In production this calls the real core banking API,
    # scoped and logged, never queried directly by the model.
    return query_core_banking(customer_id, min_amount, days)
@mcp.tool()
def place_transaction_hold(transaction_id: str, reason: str) -> dict:
    """Places a temporary hold on a transaction pending review. Requires human confirmation before execution."""
    return execute_hold(transaction_id, reason)
if __name__ == "__main__":
    mcp.run(transport="stdio")

Las dos herramientas que contiene merecen un manejo diferente en la práctica. get_transactions es de tipo lectura, similar a un recurso, y puede ejecutarse sin necesidad de paso de confirmación. place_transaction_hold modifica el estado en un sistema financiero real, por lo que nunca debe ejecutarse simplemente porque el modelo lo solicite. La capa de aplicación debe enrutarla primero a través de la confirmación explícita de un analista.

Algunas costumbres mantienen sanos a los servidores de producción:

• Asignar a cada servidor un sistema específico para gestionar, en lugar de un monolito que abarque banca central, fraude y CRM.
• Escribir descripciones de las herramientas de la misma manera en que se redactaría la documentación para un nuevo analista, ya que el modelo decide cuándo se aplica una herramienta únicamente a partir de ese texto.
• Versionar los esquemas de las herramientas. Modificar un parámetro requerido en get_transactions sin previo aviso daña a todos los asistentes que dependen de él, incluidos aquellos fuera del equipo de fraude.

Considere que cada llamada a una herramienta es una entrada no confiable para el sistema posterior y válidela, ya que un resultado del modelo manipulado podría intentar realizar una llamada no autorizada.

A2A, agentes que se comunican entre sí

MCP se encarga de los enlaces de modelo a herramienta. A2A, introducido por Google en 2025 y actualmente mantenido por la Linux Foundation, gestiona un tipo diferente de enlace: un agente autónomo que hace una llamada a otro, especialmente cuando fueron desarrollados por equipos o proveedores diferentes.

Un solo agente no es suficiente, ya que un agente único encargado de detectar fraudes, aprobar solicitudes y gestionar la comunicación se convierte en un sistema complejo y difícil de administrar, y resulta muy complicado demostrarle a un auditor qué lógica tomó las decisiones. Los especialistas que se delegan tareas entre sí ofrecen un enfoque más ordenado y seguro.

Delegación funciona a través de la tarjeta del agente, una descripción legible por máquinas de las capacidades de dicho agente. Se asemeja a la lista de herramientas de un servidor MCP, pero describe las habilidades de todo un agente, no de funciones individuales. Un agente asistente al cliente que coordina lee la tarjeta del agente de fraude y se entera de que puede analizar transacciones disputadas; lee la tarjeta del agente de préstamos y se da cuenta de que puede determinar si existe elegibilidad para refinanciamiento, y luego elige al delegado adecuado para atender la solicitud del cliente.

Coordinación define cómo los agentes transfieren tareas, envían resultados parciales y comunican el éxito o el fracaso a través de un canal de transporte estándar. Cada parte trata a la otra como una caja negra. El agente asistente al cliente no necesita saber cómo se construyó el agente contra fraudes, si utiliza herramientas MCP en la banca central, qué modelo lo impulsa o cuántos pasos sigue. Solo necesita conocer las capacidades del agente y una forma de enviarle trabajo.

Dos casos bancarios ilustran esto. Primero, un cliente informa de un cargo desconocido de quinientos dólares en su tarjeta y también pregunta por una tasa de hipoteca más favorable. El asistente no maneja ninguno de estos casos por sí mismo. Envía la disputa al agente contra fraudes y la pregunta sobre la hipoteca al agente de préstamos, ejecuta ambas tareas simultáneamente y luego combina las respuestas en una sola respuesta.

En segundo lugar, el Agente de Fraudes examina ese cargo, solicitando a los servidores MCP para la banca central y al motor de detección de fraudes que obtengan los registros de transacciones y dispositivos. Cuando su confianza en un veredicto de fraude es baja, evita hacer conjeturas y transfiere el caso a través de A2A a un Agente de Revisión de Cumplimiento, quien aplica reglas regulatorias más estrictas y, si es necesario, lo pasa a un oficial de cumplimiento humano. Asistente al cliente, Agente de Fraudes, Agente de Revisión de Cumplimiento, humano: esa es la delegación estructurada para la cual está diseñado A2A.

ACP, la capa de mensajería

Mientras A2A se concentra en delegar tareas, ACP se enfoca en la mensajería que sustenta las conversaciones entre múltiples agentes, especialmente en el manejo de estados, memoria y errores durante interacciones más prolongadas.

• Arquitectura. Las conversaciones se convierten en secuencias de mensajes escritos. Cada mensaje contiene contenido además de metadatos sobre su remitente, su hilo de conversación y el tipo de respuesta que se espera. Por lo tanto, una escalada de un caso de fraude a uno de cumplimiento incluirá más que el caso en sí: campos estructurados para el ID del caso, el agente que solicita, el nivel de urgencia y el tipo de respuesta esperada.
• Envío de mensajes. La estructura reemplaza al texto sin formato, de la misma manera que un correo electrónico tiene asunto, remitente y cuerpo, y no es un único bloque de caracteres. Con una docena de agentes trabajando en un mismo flujo de trabajo de préstamos, cada mensaje debe llegar al agente correcto y al responsable adecuado dentro de él.

Estado. La suscripción que pasa por un Agente de Elegibilidad, un Agente de Riesgo y un Agente de Aprobación debe mantener el estado a lo largo de numerosos intercambios. ACP establece convenciones para adjuntar y actualizar el estado compartido, como las verificaciones realizadas y los documentos pendientes, de modo que ningún agente pierda de vista la solicitud, incluso cuando el proceso dura días.

Memoria. La memoria de conversación a corto plazo, vinculada a la solicitud actual, se mantiene separada de la memoria a largo plazo que se conserva entre sesiones; por ejemplo, la preferencia conocida de un cliente por una hipoteca a tasa fija, lo cual debe guiar la conversación evitando preguntas repetidas.

Manejo de errores. Una llamada fallida a un agente en el sector bancario no puede simplemente desaparecer. Supongamos que el agente de riesgo no puede obtener un informe crediticio debido a una interrupción en el sistema. ACP especifica errores estructurados, lo que permite al agente de elegibilidad coordinador decidir entre intentar nuevamente, transferir la tarea a un underwriter humano o hacer una pausa, evitando así que una decisión parcial o defectuosa pase desapercibida.

Comparación de las cinco opciones

Al compararlas lado a lado, las opciones difieren en varios aspectos:

• Qué conectan. Una API simple conecta una aplicación con otra. La llamada a herramientas conecta un modelo con una función. MCP conecta un modelo o aplicación con herramientas, datos y comandos. A2A conecta agente con agente. ACP conecta agente con agente en la capa de mensajes.
• Estándarización entre proveedores. Las APIs simples, no. La llamada a herramientas, parcialmente. MCP, A2A y ACP, sí.
• Descubrimiento de capacidades. Ninguno para APIs simples y llamadas a herramientas. Dinámico en MCP, a través de tarjetas de agente para A2A, y limitado en ACP.
• Convenciones integradas de estado y memoria. Ninguna para APIs simples y llamadas a herramientas, parcial en MCP y A2A, y el foco principal en ACP.
• Ejemplo bancario. Banca central que se comunica con un CRM; un asistente que llama a una función de saldo predefinida; un asistente que descubre y llama de forma uniforme a herramientas de banca central, fraude y documentos; un Agente de Fraude que delega tareas a un Agente de Revisión de Cumplimiento; seguimiento del estado de aprobación de préstamos de varios días entre tres agentes.

Estas opciones son complementarias, no rivales. Un asistente bancario de producción probablemente combinará MCP para conectar a los agentes con los sistemas centrales, A2A para la delegación entre especialistas, y las convenciones ACP para gestionar flujos de trabajo largos con múltiples agentes, como los procesos de aprobación de créditos, de principio a fin.

Un mensaje del cliente, de principio a fin

Tomemos un único mensaje: el cliente no reconoce un cargo de quinientos dólares y también desea saber sobre una tasa de hipoteca más favorable. Todo el sistema responde paso a paso.

1. El cliente envía el mensaje al Asistente de IA, la aplicación anfitriona dentro de la aplicación bancaria.
2. A través de A2A, el asistente transfiere la pregunta sobre fraude al Agente de Fraude y la pregunta sobre la hipoteca al Agente de Préstamos, y ambos trabajan al mismo tiempo.
3. El agente de fraude llama al servidor CRM a través de MCP para obtener el historial de contactos y quejas, y al servidor de banca central para consultar la transacción en disputa. Después de aplicar sus reglas de detección de fraude, invoca la herramienta place_transaction_hold del servidor de banca central, nuevamente mediante MCP. Esa solicitud es enviada a un analista humano para su confirmación antes de ser ejecutada, ya que modifica el estado de la transacción.
4. El agente de préstamos obtiene los términos actuales de la hipoteca y el perfil crediticio del servidor de banca central a través de MCP, los compara con las tablas de tasas actuales y elabora una recomendación. Dado que ofrecer una tasa de refinanciamiento requiere la aprobación de un evaluador, no se ejecuta ninguna acción y se envía la recomendación junto con los datos de apoyo a un resumen destinado a personas.
5. Ambos agentes informan al asistente a través de A2A, utilizando mensajes estructurados al estilo ACP que contienen el estado del caso, las aprobaciones humanas pendientes y los hallazgos.
6. El asistente utiliza MCP para enviar al cliente un correo electrónico confirmando la suspensión, y registra cada llamada a una herramienta, transferencia de tareas y límite de decisión en el sistema de auditoría, ya que los reguladores esperarán exactamente ese registro si se revisa el caso.

Por lo tanto, la interoperabilidad en un banco se presenta de esta manera: no hay un modelo gigante único que intente hacerlo todo, sino agentes especializados con acceso controlado a herramientas, cada uno realizando bien su tarea, respaldados por un registro de auditoría claro.

Seguridad entre agentes y protocolos

• Inyección de comandos. Una instrucción maliciosa oculta en un documento, correo electrónico o archivo subido puede intentar controlar el siguiente movimiento de un agente. Imagine una disputa fraudulenta que contiene texto oculto que ordena al agente encargado de detectar fraudes que apruebe la reclamación sin realizar verificaciones. Las herramientas MCP modifican el estado real de las cosas, por lo que el peligro es real. Contramedidas: trate todo el contenido recuperado como no fiable, nunca permita que la salida del modelo active una herramienta de alto riesgo como place_transaction_hold sin una verificación de políticas, y limite las herramientas que el modelo puede ver en un contexto dado.
• Autenticación. Cada conexión cliente-servidor MCP y cada transferencia A2A requiere autenticación, generalmente mediante OAuth 2.1, de modo que un usuario anónimo no pueda utilizar herramientas bancarias esenciales ni asignar tareas al agente encargado de la revisión de cumplimiento.

Autenticación y autorización. La autenticación indica quién está realizando la llamada, mientras que la autorización determina qué puede hacer ese interlocutor. Incluso un agente contra el fraude autenticado debe verse denegada la posibilidad de usar herramientas que aprueben cambios en las tasas de hipoteca, ya que eso está fuera de su ámbito de competencia, por más convincente que parezca su razonamiento.

Cero confianza. Por defecto, no se confía en ningún eslabón de la cadena, ni en el modelo, ni en otro agente, ni en un servidor posterior. La política se verifica en el momento en que se ejecuta cada llamada, y no se pasa por alto simplemente porque proviene del propio sistema de IA del banco.

Aprobación humana. Las acciones de importancia financiera, de seguridad o regulatoria, como congelar una cuenta, levantar una restricción o aprobar un préstamo, requieren confirmación humana. Se trata de una decisión de diseño acorde a la gravedad de la situación, y no de una deficiencia de la tecnología.

Rastros de auditoría. Registre cada llamada a la herramienta, delegación y cambio de estado con suficiente detalle como para reconstruir lo que ocurrió y por qué. Si un regulador pregunta por qué una cuenta se mantuvo bloqueada durante seis horas, el banco debe poder mostrar la cadena exacta de decisiones de los agentes y llamadas a las herramientas, y no una estimación.

¿Hacia dónde se dirige?

La dirección del flujo de datos es fácil de interpretar. Protocolos como MCP se están convirtiendo en la capa de controladores de dispositivos para la IA, ofreciendo una vía estándar desde cualquier modelo hasta cualquier herramienta, sin necesidad de soluciones personalizadas. Es de esperar que los sistemas operativos para IA se conviertan en una categoría real, donde los servidores de estilo MCP funcionen como infraestructura de primera categoría, al igual que las bases de datos y las colas de mensajes, y donde un servidor bancario central sea algo al que todo proyecto interno de IA se conecte directamente sin tener que reconstruirlo. También se prevén mercados de servidores ya verificados y auditados, de modo que un banco pueda adoptar un servidor de verificación KYC aprobado para cumplir con las normativas en lugar de crear uno propio. Además, es probable que surjan herramientas de gobernanza para auditar las llamadas MCP y las delegaciones A2A, ya que los equipos de cumplimiento y riesgo necesitarán esa visibilidad antes de que todo esto entre en contacto con dinero real. Finalmente, se espera que estos mismos patrones se extiendan más allá del sector bancario, a cualquier área donde un sistema de razonamiento necesite una forma estándar y auditable de actuar en el mundo.

La versión breve

Un modelo por sí solo no puede verificar un saldo, colocar una retención ni evaluar una hipoteca. MCP estandariza la forma en que accede a herramientas, datos e instrucciones, lo que permite que un asistente contra fraudes y un asistente de préstamos compartan un mismo servidor de banca central sin integraciones duplicadas. A2A estandariza la forma en que los agentes especializados transfieren tareas entre sí sin necesidad de conocer los detalles internos del otro. ACP estandariza la comunicación, el manejo de estados y los errores en procesos extensos como la aprobación de préstamos que duran varios días. En un banco, estos protocolos no son meras conveniencias; son lo que hace que la autorización, los registros de auditoría y la aprobación humana sean aplicables a gran escala.

De esto se derivan dos reglas de diseño. MCP separa los recursos de solo lectura de las herramientas que modifican el estado, y el diseño de autorización debe seguir esa separación, ya que verificar un saldo y enviar una transacción conllevan riesgos muy diferentes. Además, las barreras de aprobación humana y los registros de auditoría para cada llamada al protocolo son requisitos esenciales, por lo que deben incluirse en la primera línea de código y no en un parche posterior.