Cuatro plataformas, cuatro sistemas de identidad. ¿Quién escribe el registro compartido?

El panorama ahora mismo

A lo largo de unas pocas semanas de la primavera de 2026, varios de los mayores proveedores de IA empresarial anunciaron lo mismo desde ángulos distintos.

Cada uno lanzó un plano de gobernanza para los agentes que corren dentro de su propia nube. Cada uno introdujo alguna forma de identidad criptográfica por agente. Cada uno prometió la capacidad de rastrear qué hizo un agente, cuándo y con qué alcance. Cada uno habló de auditoría, detección de anomalías, puertas de aprobación y acciones ligadas a una política.

La formulación variaba. La estructura, no.

Uno bautizó la suya «Agent Identity», acompañada de un «Agent Gateway» y un registro de agentes. Otro incorporó a su producto estrella de conversación agentes de espacio de trabajo compartidos por equipos, con controles del lado del administrador sobre qué herramientas pueden tocar los agentes y un paso de aprobación humana para cualquier asunto delicado. Otros ya habían desplegado su versión antes ese mismo año: en un caso, un entorno de ejecución de agentes a nivel de base; en otro, una pila de orquestación con nombre de fundición.

Para quien construye sobre una de estas pilas, el valor es real. Se obtiene un relato coherente de cómo se comportan los agentes dentro del límite de esa nube. Se obtienen registros que un equipo de cumplimiento puede señalar. Se obtiene una primitiva de identidad que no existía hace dieciocho meses.

Para quien construye a través de estas pilas —o cuyo agente algún día habrá de interactuar con un agente que vive en otra—, acaba de heredarse un problema nuevo. Varios sistemas de identidad que no se hablan entre sí. Varios formatos de registro que no se pueden cotejar. Varias pistas de auditoría, cada una presentada como autoridad sobre los agentes que están dentro de sus propios muros.

La forma estructural del asunto

La forma resulta familiar. Es la misma que tuvo el correo electrónico antes de SMTP, la que tuvieron los pagos antes de las normas de liquidación interbancaria, la que tuvo la web antes de las autoridades de certificación compartidas. Cada plataforma se vuelve coherente hacia dentro y opaca hacia fuera. La coherencia interna es un logro real. La opacidad externa es lo que la capa siguiente tiene por delante resolver.

En esta etapa, el argumento de todos los grandes proveedores es una variante de esto: «Podemos decirle qué hicieron sus agentes dentro de nuestro sistema». Es cierto y es útil.

Lo que ninguno puede decir —por razones estructurales, no por carencias de producto— es esto: «Podemos decirle qué acordaron su agente y el otro agente, cuando el otro agente estaba en un sistema que nosotros no operamos».

Ningún proveedor puede afirmarlo con credibilidad, porque hacerlo exigiría hablar en nombre de algo situado fuera de su propio ámbito operativo. Supondría formular afirmaciones sobre la infraestructura de otra empresa. Sus abogados no lo permitirían, y harían bien en no permitirlo.

La identidad interna no es el acuerdo externo

Conviene precisar qué establece realmente una «Agent Identity».

Una identidad criptográfica emitida por una plataforma establece unas cuantas cosas: que este agente fue aprovisionado dentro de esta plataforma; que sus acciones, tal como las observó la capa de registro de esta plataforma, quedaron consignadas; y que su alcance fue configurado en un momento determinado por un administrador determinado.

Son hechos reales. Importan para el cumplimiento normativo, para la informática forense interna, para la pregunta ¿configuró mal este agente alguien de mi equipo?

No establecen nada de lo siguiente: que la contraparte del agente, que corre en otra plataforma, aceptó los mismos términos; que dos agentes de dos plataformas distintas compartieron un límite común antes de ejecutar; ni que una disputa humana entre dos organizaciones cuente con un registro neutral al que remitirse.

Para esas preguntas, la capa de identidad de cada plataforma es estructuralmente unilateral. La contraparte está en el sistema de otro, y la primitiva de identidad de ese sistema no interopera con esta.

Los anuncios están afilando la identidad interna. No están haciendo —ni pueden hacer— que el acuerdo entre identidades sea verificable.

La brecha se ensancha a medida que la gobernanza interna se estrecha

Está ocurriendo algo contraintuitivo. Cuanto más invierte cada gran proveedor en gobernanza interna, más visible se vuelve la brecha externa, no menos.

Hace un año, la pregunta ¿quién responde de lo que hizo este agente? era turbia en todas partes. Los registros internos eran magros. La identidad del agente era implícita. La interacción entre plataformas apenas existía, porque los agentes rara vez salían del edificio.

Ahora los registros internos están engrosando. La identidad del agente es explícita. Y el crecimiento del tráfico de agentes se ha desplazado de «dentro de una nube» a «a través de nubes». Un agente minorista registrado en la plataforma de un proveedor negocia con un agente de suministro registrado en la de otro. Un agente de investigación que corre en el entorno de ejecución gestionado de un laboratorio de frontera invoca una herramienta alojada por una empresa que usa una nube completamente distinta. Un modelo local que corre en la máquina de la oficina doméstica de alguien interactúa con un agente alojado a través de una API de pago.

En cada uno de estos casos, cada parte dispone de un registro interno cada vez más detallado. Cada parte puede presentar, sobre lo ocurrido en su propio sistema, una relación con el nivel de detalle que exige el cumplimiento normativo. Y la cuestión de qué acordaron realmente ambas partes —cuál era el límite compartido— no tiene dónde alojarse.

Las inversiones en gobernanza interna hacen esta brecha más perceptible, porque la calidad de los registros internos deja en evidencia el momento en que esos registros se contradicen.

Un pequeño ejemplo concreto

Piense en dos agentes. El agente A es un agente de aprovisionamiento que corre en la plataforma de agentes de una gran nube. Esa plataforma le ha emitido una Agent Identity, tiene un alcance que le permite ejecutar compras hasta cierto valor, y cada una de sus acciones queda consignada en la pista de auditoría de esa plataforma. El agente B es un agente de cumplimiento de pedidos que corre en la plataforma de otra gran nube. La misma historia, distinto proveedor.

Acuerdan un pedido al por mayor. La liquidación se produce por un raíl de micropagos. La entrega se produce. Algo de la entrega no encaja con lo que esperaba el operador de A.

El operador de A abre el registro de A. Ahí consta un acuerdo nítido a un precio, firmado criptográficamente por la plataforma de A, con la Agent Identity adjunta. Del lado de A todo cuadra. El operador de B abre el registro de B. Ahí consta un acuerdo nítido a otro precio, firmado por la plataforma de B, con la Agent Identity adjunta. Del lado de B todo cuadra también.

Ambos registros son coherentes consigo mismos. Ambos son de alta calidad. Ambos tienen autoridad dentro de sus respectivas plataformas. Ninguno es un registro neutral de lo que los dos agentes acordaron antes de ejecutar.

Que ambas plataformas tengan mejor gobernanza interna que hace un año no vuelve más fácil zanjar esta disputa. En cierto modo la vuelve más difícil, porque ahora ambas partes pueden esgrimir pruebas más pulidas de su propia versión.

Qué significa «externo», con precisión

A estas alturas, la palabra «externo» carga más peso que antes. Tiene un sentido estructural específico: no operado por ninguna de las contrapartes; no operado por la plataforma de ninguna de ellas; sin conceder acceso privilegiado a ningún proveedor; que consigna la existencia y el alcance de una decisión, no su contenido; y que, cuando ambas partes participan, reconduce los registros de ambos lados a una misma referencia.

«Externo» no significa «almacenado en otro sitio». Unos registros pueden estar almacenados en una segunda nube y seguir bajo el control de quien los escribió. «Externo» significa operativamente independiente de ambos lados de una decisión.

En el ejemplo de aprovisionamiento y cumplimiento de pedidos, un registro externo tiene este aspecto: en el momento en que el agente A y el agente B declararon un límite compartido —el ámbito de responsabilidad del acuerdo, como un techo de gasto que una parte estaba autorizada a no rebasar, una ventana de entrega o la identidad de la contraparte—, esa declaración quedó fijada fuera de ambas plataformas. Se trata del límite de la decisión, no de la sustancia de la negociación; el anclaje no guarda las partidas con precio ni las cláusulas mismas. Ninguna de las partes podía después alterar unilateralmente esa declaración sin que el cambio quedara a la vista. Ambas partes remiten al mismo identificador de registro. Ambas presentan sus indicios locales junto a ese identificador si surge una disputa.

El registro externo no dice quién tenía razón. Dice: a esta hora, bajo este alcance, con esta contraparte, se declaró un límite compartido y —allí donde ambas partes participaron— ambas lo reconocieron.

Ése es el artefacto que falta. La gobernanza interna no lo produce. No puede. Su cometido es ser interna.

Lo que esto no es

Vale la pena atajar una lectura errónea.

El anclaje externo no es un sistema de identidad rival. No sustituye la Agent Identity de ninguna plataforma. No pretende unificarlas. No aspira a ser la identidad canónica de agente alguno en entorno de ejecución alguno.

Tampoco juzga. Un anclaje externo no dice «este agente se comportó bien» ni «este agente era de fiar». Consigna que un límite de decisión fue declarado y quedó fijado en un momento determinado, y nada más allá de eso.

No ve el contenido de las decisiones. No ve las indicaciones, ni las salidas de herramientas, ni las trazas de inferencia, ni los pesos de los modelos, ni ninguna de las cosas que la gobernanza interna de una plataforma legítimamente necesita ver para hacer su trabajo. Consigna que un agente declaró un límite en un momento dado bajo un alcance dado y —allí donde el otro agente está presente en el mismo entorno externo— que ese otro agente lo reconoció.

La relación entre gobernanza interna y anclaje externo es complementaria, no rival. La gobernanza interna hace que el agente se comporte bien dentro de su propio límite. El anclaje externo hace comprobables los acuerdos que cruzan límites. Cada uno necesita al otro para componer un cuadro completo.

Por qué ahora, en concreto

Hay una ventana estrecha en la que esta brecha merece atención.

Las plataformas que anunciaron sus capas de identidad no van a detenerse a esperar que emerja una norma entre plataformas. Seguirán endureciendo su oferta interna. Es lo racional para ellas y bueno para sus clientes.

El tráfico de agentes que cruza entre estas plataformas crece más deprisa de lo que los organismos de normalización alcanzan a responder. Para cuando exista una capa de interoperabilidad de identidad entre plataformas —suponiendo que llegue a existir—, el volumen de disputas entre plataformas ya será considerable.

Para quien opera agentes en más de una de estas plataformas, la pregunta no es ¿qué sistema de identidad de proveedor debería elegir?, sino ¿qué punto de referencia externo existe para los acuerdos que un agente cierra fuera de su plataforma de origen?

Si la respuesta es «los registros de la plataforma de la contraparte más los nuestros», ése es el problema del testimonio propio con un traje más elegante. Ambas partes tendrán registros preciosos. Ninguna tendrá uno neutral.

Cómo encaja un anclaje externo

La forma del encaje no exige cambiar la plataforma en la que corre un agente. Un anclaje externo se sitúa al lado del sistema de identidad que la plataforma provea, sea cual sea.

Antes de ejecutar un acuerdo con una contraparte, el agente declara el alcance de ese acuerdo a un entorno externo: cuál es el ámbito de responsabilidad y, opcionalmente, si se trata de una declaración bilateral con otro agente designado por su nombre. El entorno consigna la marca de tiempo, el alcance y una referencia de integridad, y devuelve un identificador.

Si la contraparte también usa el mismo entorno externo, puede consignarse un reconocimiento bilateral y ambas partes se reconducen a un único registro compartido. Si no, el registro es unilateral pero sigue siendo externo: queda fijado fuera de la plataforma del propio agente, y ambas partes pueden remitirse al identificador si surge una disputa, aunque sólo una de ellas lo haya declarado.

Tras la ejecución, el agente confirma. El registro queda entonces fijado y en modo de sólo adición: cualquier alteración posterior quedaría a la vista frente a la referencia de integridad, de modo que ninguna de las partes, ni ninguna de sus plataformas, puede modificarlo sin que se advierta. La Agent Identity de la plataforma sigue dando cuenta del comportamiento interno del agente; el anclaje externo da cuenta de la existencia del acuerdo y de su alcance en un momento preciso.

La versión corta

Los grandes proveedores están convergiendo hacia una identidad interna sólida para los agentes que están dentro de sus nubes. Eso es bueno y seguirá mejorando. La brecha que crea —acuerdos entre plataformas sin un registro neutral— es la forma del problema siguiente, y ya está aquí para cualquiera que opere agentes en más de una plataforma.

La pregunta que vale la pena hacerse, para quien construye agentes que hablarán con agentes de fuera de su plataforma de origen: cuando dos de esos agentes discrepan sobre lo que se acordó, ¿dónde vive el registro compartido?

Si la respuesta es «en los registros de mi plataforma y en los suyos, ambos controlados por la parte que los escribió», ése es el problema del testimonio propio a escala institucional. Varias plataformas con registros internos excelentes no es lo mismo que un único registro compartido entre plataformas.