La gobernanza de agentes ha sido hasta ahora un ejercicio interno. Usted decidía qué herramientas podía invocar su agente, qué credenciales tenía en su poder y qué acciones necesitaban a una persona. Todo ocurría dentro de su perímetro, bajo un solo conjunto de políticas y con una sola entidad legal como responsable. Ese supuesto está a punto de romperse. Lo siguiente con lo que hable su agente no será una herramienta suya. Será el agente de otra empresa, sobre la infraestructura de otra empresa, representando los intereses de otra empresa.
Los protocolos que lo hacen posible son reales y ya están en producción. El protocolo Agent2Agent de Google se lanzó en abril de 2025 con más de 50 socios, entre ellos Salesforce, ServiceNow y MongoDB, y en junio de ese mismo año Google lo donó a la Linux Foundation. Hoy está en la versión 1.0, bajo un comité directivo técnico que reúne a AWS, Cisco, Google, IBM Research, Microsoft, Salesforce, SAP y ServiceNow. Cuando tantos competidores se ponen de acuerdo en un formato de transmisión, ese formato gana. En lo que ninguno se puso de acuerdo fue en quién responde cuando la conversación sale mal.
Los protocolos de interoperabilidad estandarizan cómo los agentes se encuentran, describen sus capacidades e intercambian mensajes. No estandarizan la autoridad, la responsabilidad legal, la resolución de disputas ni la evidencia. Un protocolo transporta un mensaje, no una garantía. Antes de que un agente suyo transaccione con un agente que no es suyo, la capa de rendición de cuentas la tiene que construir usted, en el contrato y en la arquitectura.
Conviene ser preciso, porque las presentaciones de los proveedores no lo son. A2A le entrega cuatro cosas. Descubrimiento: un agente remoto publica un Agent Card legible por máquina en una URL conocida, donde describe sus habilidades, sus endpoints y los esquemas de autenticación que acepta. Intercambio de capacidades: su cliente lee esa tarjeta y decide qué pedir. Mensajería estructurada: originalmente JSON-RPC 2.0 sobre HTTPS, con enlaces de gRPC y HTTP+JSON/REST incorporados para la v1.0, usando autenticación empresarial convencional como OAuth 2.0, tokens de portador o claves de API. Ciclo de vida de la tarea: entrega del trabajo, consulta de estado y recuperación de resultados para tareas que toman minutos o días. Además es opaco por diseño, de modo que los agentes colaboran sin exponer sus herramientas, su memoria ni su razonamiento internos. Usted obtiene un resultado y un estado, no una vista de cómo llegó la otra parte hasta ahí.
Note lo que falta. Ninguna noción de cuánta autoridad tiene el agente remoto de parte de su dueño. Ninguna manera de expresar que un compromiso por encima de cierto valor necesita a una persona del lado de ellos. Ningún canal de objeción, ninguna primitiva de escalamiento, ningún registro de auditoría compartido. Es una capa de transporte cuidadosamente construida que nunca pretendió ser una capa de gobernanza.
El panorama de protocolos se ordenó más rápido de lo previsto, y se consolidó en lugar de fragmentarse. El Model Context Protocol de Anthropic gobierna el acceso a herramientas y datos. A2A gobierna la colaboración entre agentes. El Agent Communication Protocol de IBM Research, que aportó un modelo de mensajería multimodal de estilo RESTful, se fusionó con A2A bajo la Linux Foundation en agosto de 2025, precisamente para evitar una división de estándares, e IBM tomó un asiento en el comité directivo técnico de A2A. Eso deja al Agent Network Protocol, impulsado por la comunidad, como la principal alternativa restante, construido sobre un enfoque más descentralizado de la identidad y el descubrimiento.
Vale la pena detenerse un momento aquí, porque agudiza el problema en lugar de resolverlo. La industria miró la fragmentación, decidió que era el riesgo que valía la pena eliminar y fusionó los formatos de transmisión. Nadie hizo el ejercicio equivalente con la rendición de cuentas. El transporte convergió. El modelo de responsabilidad no.
La distinción útil no es cuál es técnicamente mejor. Es cuáles se quedan dentro de su perímetro. Los servidores MCP suelen ser cosas que usted ejecuta o aprueba, tema que cubrimos en nuestro artículo sobre la gobernanza de la capa de acceso a herramientas. Los marcos de orquestación coordinan agentes que usted posee, tema de la gobernanza de la orquestación multiagente. A2A es distinto en naturaleza. Es la capa donde la contraparte es otra empresa.
Esto no es solo una queja de quienes trabajamos en el terreno. Un artículo de junio de 2026 de Richard Kang y Yudho Diponegoro, Governance Gaps in Agent Interoperability Protocols, evaluó cinco protocolos de interoperabilidad, entre ellos MCP, A2A, ACP y ANP, frente a seis dimensiones de gobernanza: membresía, deliberación, votación, preservación del disenso, escalamiento humano y auditoría o repetición. La votación y la preservación del disenso están universalmente ausentes en todos los protocolos examinados, y la deliberación está ausente o solo parcialmente soportada.
Los autores separan las brechas extensibles, que una versión futura de la especificación podría cerrar, de las brechas estructurales, que necesitan una nueva capa arquitectónica por encima del protocolo. Su conclusión es que las comunidades gobernadas de agentes son una capa faltante, no una función faltante. Si usted está esperando que A2A 2.0 le resuelva la rendición de cuentas, va a seguir esperando mientras corren las transacciones que ya está ejecutando.
Dentro de sus muros, la identidad es un problema suficientemente resuelto: usted la emite, la acota y la revoca, como explicamos en nuestro artículo sobre la delegación de credenciales para agentes de IA. Al cruzar una frontera, usted confía en la afirmación de una organización cuyas prácticas de emisión no ha auditado. TLS prueba que llegó al host al que quería llegar. No prueba que el agente que está detrás sea el agente que describe su contrato, ni que no haya sido reconfigurado desde el martes. Decida qué identidades de contraparte acepta, fíjelas y exija aviso ante cualquier cambio.
El descubrimiento automático es el argumento de venta y el riesgo en la misma frase. Cualquier servidor A2A puede publicar un Agent Card en /.well-known/agent-card.json, y esa tarjeta es una autodeclaración escrita por su propio autor. Nada en el protocolo valida que el agente ejecute esas habilidades de forma competente, segura ni dentro de las restricciones regulatorias bajo las que usted opera. El descubrimiento puede ocurrir de forma automática. Nada de lo descubierto entra a producción de forma automática. Mantenga una lista de permitidos anclada a las URL específicas de Agent Card que usted haya revisado de verdad, fije la versión de la tarjeta que aprobó y rechace las habilidades descubiertas en tiempo de ejecución que nadie autorizó.
Su agente delega en el agente de un socio, que a su vez delega una subtarea en un tercer agente que usa como subprocesador. Usted tiene contrato con la segunda parte, ninguna relación con la tercera y, bajo el modelo de opacidad de A2A, puede que ni siquiera sepa que la tercera existe. Si sus datos viajaron hasta allá, sus obligaciones viajaron con ellos. Este es el problema de los subprocesadores que su equipo de privacidad conoce de los contratos de nube, ahora moviéndose a velocidad de máquina y sin generar un solo ticket de compras.
Muy poco por sí solo. Un mensaje de protocolo capturado muestra que un endpoint envió una carga útil en un momento dado. No muestra que el emisor estuviera autorizado a comprometer a su principal, que una persona lo haya revisado, ni que el contenido sea cierto. Un auditor que pregunta por qué cambió una dirección de remesa quiere una base de autoridad, y un mensaje legible por máquina no lo es. La verificación independiente contra su propio sistema de registro es lo que convierte una afirmación en evidencia.
Dos agentes realizan una transacción y el resultado es incorrecto: una cantidad, un precio, un compromiso de entrega. Ambos se comportaron según su diseño. El personal de ninguna de las dos empresas vio el intercambio. No hay registro compartido, ni procedimiento de conciliación acordado, ni primitiva de protocolo para que alguno de los agentes objete formalmente. Usted queda entonces en una disputa comercial donde ambas partes tienen registros parciales y no sincronizados de un evento que ninguna presenció. Escriba el procedimiento de reversión antes de necesitarlo.
Maneje esto como un anexo de interoperabilidad al contrato marco de servicios, no como un apéndice de un documento de integración. Seis cláusulas hacen la mayor parte del trabajo.
Los agentes que vienen dentro de productos que usted ya licencia plantean un conjunto de preguntas relacionado, que cubrimos en agentes de IA integrados por el proveedor. La diferencia es que un agente integrado actúa dentro de su tenant, mientras que un agente de contraparte actúa al otro lado de la línea, para alguien cuyos incentivos no son los suyos.
Los contratos asignan la pérdida después del hecho. La arquitectura la previene. Cuatro requisitos pertenecen a cualquier diseño de agentes que cruce fronteras.
El registro de los intercambios que cruzan fronteras tiene un estándar más alto que el registro interno, porque la constancia tiene que sostenerse cuando la versión de la otra parte no coincide con la suya. Para cada intercambio, capture la identidad verificada de la contraparte y la credencial presentada, un identificador de correlación compartido que viaje a lo largo del ciclo de vida de la tarea, las cargas útiles exactas de solicitud y respuesta en lugar de un resumen, la versión del Agent Card vigente, la base de autoridad en la que se apoyó, el resultado de la validación interna, la constancia de aprobación humana y la disposición final, incluida cualquier reversión. Conectar eso a su canalización de entrega es trabajo ordinario de AI DevOps, y sale mucho más barato antes del primer intercambio en disputa que después.
La presión por adoptar es real y la tasa de fracaso está documentada. La Encuesta 2026 de CIO y Ejecutivos de Tecnología de Gartner encontró que solo el 17 por ciento de las organizaciones ha desplegado agentes de IA, mientras que más del 60 por ciento espera hacerlo dentro de dos años, y Gartner proyecta que más del 40 por ciento de los proyectos de IA agéntica se cancelará antes de que termine 2027 por costos crecientes, valor de negocio poco claro y controles de riesgo inadecuados. También espera que el 40 por ciento de las aplicaciones empresariales incorpore agentes específicos por tarea para el cierre de 2026. Los agentes de contraparte van a existir exista o no su gobernanza.
Una secuencia viable empieza con una sola contraparte identificada y no con una red abierta, sobre un flujo de trabajo donde los errores sean visibles y baratos: consultas de estado, verificaciones de disponibilidad, recuperación de documentos. Ejecútelo primero en modo sombra, donde su agente pregunta y registra pero su proceso actual sigue decidiendo. Después pase a un techo de valor duro con aprobación humana por encima de él, y suba ese techo solo para los tipos de transacción sobre los que ya tenga evidencia. Escalonar a las contrapartes por identidad verificada, términos contractuales y confiabilidad observada, en lugar de tratar a todos los agentes externos como una sola clase de confianza, mantiene esto manejable a medida que crece la lista.
Vale la pena nombrar la parte incómoda. Todos los que están del otro lado de estos intercambios hacen los mismos supuestos optimistas que usted, incluido el supuesto de que la contraparte gobierna bien a sus agentes. La interoperabilidad vuelve transitivos esos supuestos, y la confianza transitiva en una red de agentes es la forma en que un error local se convierte en un incidente de industria.
Haga una sola pregunta en su próxima revisión de arquitectura: ¿cuáles de nuestros agentes pueden hoy recibir un mensaje de un agente ajeno a esta empresa, y qué pueden hacer como resultado? Para la mayoría de las organizaciones en 2026 la respuesta honesta es ninguno todavía, lo que convierte a este en el raro problema de gobernanza al que usted puede adelantarse. Escriba ahora la lista de contrapartes permitidas, el techo de valor, el esquema de registro y el anexo contractual, mientras el costo son unas cuantas reuniones.
Infonaligy diseña agentes de IA a medida y los controles de frontera a su alrededor, y nuestro trabajo de consultoría de IA y de seguridad de IA arranca cada vez más en esta línea exacta: qué puede aceptar su agente de un agente que no es suyo, y qué evidencia sobrevive al intercambio. Estamos en Dallas–Fort Worth y entregamos de forma remota en todo el país, lo que le sienta bien a un trabajo que es sobre todo revisión de arquitectura, redacción contractual y diseño de registros.
Los protocolos resolvieron el problema difícil de ingeniería: lograr que agentes de distintas empresas hablen entre sí. Dejaron intacto el problema organizacional, deliberadamente. Esa parte le toca a usted.
Agent2Agent (A2A) es un estándar abierto, desarrollado originalmente por Google y donado a la Linux Foundation, que permite que agentes de IA construidos sobre marcos distintos y pertenecientes a organizaciones distintas se descubran entre sí, intercambien descripciones de capacidades, envíen mensajes estructurados y gestionen tareas delegadas de larga duración. Los agentes remotos publican un Agent Card legible por máquina que anuncia sus habilidades, sus endpoints y los esquemas de autenticación que requieren, y el protocolo es deliberadamente opaco, lo que significa que los agentes colaboran sin exponer sus herramientas, su memoria ni su lógica internas.
Lo que A2A no cubre es la rendición de cuentas. La especificación estandariza el transporte, el descubrimiento y el ciclo de vida de la tarea. No define quién es responsable cuando el agente de una contraparte da una respuesta equivocada, cuánto vale como evidencia la afirmación del agente de otra empresa, cómo se resuelven las disputas ni qué ocurre cuando un error se propaga a través de una frontera organizacional. Eso sigue siendo un problema de contrato y de arquitectura, no un problema de protocolo.
Trátelo como un anexo de interoperabilidad al contrato marco de servicios y exija seis cosas por escrito.
Primero, una identidad autoritativa: qué identidad criptográfica o credencial representa al agente de la contraparte, y cómo se le avisa a usted de una rotación o una revocación. Segundo, una declaración de autoridad: qué compromisos está facultado ese agente para asumir en nombre de su principal, y por encima de qué umbral de valor o de riesgo debe aprobar una persona del lado de ellos. Tercero, aviso de cambio de capacidades: aviso previo por escrito antes de que cambien materialmente las habilidades anunciadas del agente, su modelo o sus subprocesadores subyacentes. Cuarto, registro mutuo y retención de evidencia: ambas partes conservan registros de transacción correlacionados durante un periodo definido y los entregan a solicitud durante una disputa. Quinto, un procedimiento de error y reversión con una ventana de respuesta establecida y una vía definida para deshacer una transacción errónea. Sexto, una declaración explícita de que la salida de su agente no se garantiza como exacta salvo que el contrato diga lo contrario, para que usted sepa si se está apoyando en una garantía o en su propia verificación.
Por sí solo, no. Un mensaje de protocolo prueba que una parte situada en un endpoint determinado envió una carga útil determinada en un momento determinado, suponiendo que usted capturó y conservó la evidencia de la capa de transporte. No prueba que el agente emisor estuviera autorizado a asumir ese compromiso, que una persona de la contraparte lo haya revisado alguna vez, ni que la afirmación que contiene sea cierta. Los auditores y los reguladores siguen preguntando quién autorizó la transacción y con qué base.
Para que la actividad de agentes que cruza fronteras sea defendible, registre la identidad verificada y la credencial de la contraparte, las cargas útiles exactas de solicitud y respuesta, la base de autoridad en la que se apoyó, como una cláusula contractual o una aserción de autoridad firmada, el control interno que validó la afirmación de forma independiente y la constancia de aprobación humana en los casos en que el valor o el riesgo cruzó su umbral. Si la única respuesta a por qué cambió un pago es que lo dijo el agente de la otra parte, usted no tiene un control, tiene un cuento.
Mapeamos cada ruta por la que un agente externo podría alcanzar sus sistemas, definimos la lista de contrapartes permitidas y los techos de valor, diseñamos el intermediario de frontera y el registro de evidencia, y le entregamos a su equipo legal las cláusulas de interoperabilidad para poner frente a un proveedor. Usted recibe una arquitectura y una posición contractual, no una clase sobre protocolos.
Infonaligy