(3/3) Cómo le daría a cada agente de IA una identidad responsable y privada

Los dos primeros posts de esta serie terminaban en el mismo nudo. Los agentes rompen el stack de identidad porque ya no hay un humano al teclado, y la mejor investigación sobre el problema nombra la parte más dura y la deja abierta: para hacer responsable a un agente le adjuntas una identidad real, y en el momento en que lo haces has construido vigilancia. Responsabilidad o privacidad. Elige una.

No creo que eso sea una ley de la naturaleza. Creo que hemos estado cogiendo el problema por el lado equivocado. Con este post quiero darte una idea de alto nivel de cómo le daría la vuelta, y un esbozo —también de alto nivel— del enfoque hacia el que llevo días construyendo de verdad.

Quiero ser honesto de entrada sobre qué es esto, porque la retórica en este terreno se calienta rápido. Es un concepto en el que confío, no algo terminado. Hay partes que tocan terreno regulado —custodiar dinero en nombre de otro no es algo que se despache con la mano— y voy a ir señalando los límites sobre la marcha, no al final. La credibilidad en identidad no se gana con afirmaciones vacías.

El error es adjuntar identidad al agente, para empezar

Este es el movimiento que hace todo el mundo, porque es el obvio. Tienes un agente. Lo quieres responsable. Así que vinculas una identidad real y conocida al agente — cada acción que ejecuta se remonta a un humano con nombre. El agujero negro se cierra. Y al cerrarlo creas un vínculo permanente y consultable entre una persona y todo lo que hace su flota de agentes, todo el día, en cada servicio. Resolviste la responsabilidad gastando privacidad, y la gastaste por agente, para siempre.

Ahora dale la vuelta. Haz la verificación una sola vez, sobre el humano — y deja que solo el hecho de esa verificación fluya hacia cada agente que despliegue, nunca la identidad que hay detrás.

En el KYC clásico, te identificas ante la parte con la que tratas. En la versión invertida, un humano hace KYC una vez con un emisor, y luego acuña tantas credenciales de agente como quiera —una por agente—, cada una capaz de demostrar una afirmación y nada más: «Me opera un humano real, verificado por KYC, exigible, con grado de verificación ≥ G, actuando dentro del alcance S, y no estoy revocado.» No qué humano. Solo que hay uno, que es real y responde, y que está detrás de este agente. El agente demuestra respaldo. Nunca demuestra identidad, porque nunca la tiene.

El conocimiento cero es la bisagra que el paper señalaba

Esta es exactamente la puerta que el paper de OpenID marcó y no cruzó: divulgación selectiva con pruebas de conocimiento cero y credenciales anónimas, «un camino a seguir». Todo el enfoque vive o muere en hacer eso concreto.

El agente presenta una prueba criptográfica corta que responde solo a los predicados que una contraparte necesita de verdad —¿respaldado por un humano? sí; ¿verificado con grado A2 o superior? sí; ¿autorizado a iniciar pagos? sí; ¿activo y no revocado? sí— y no revela nada más. Ningún nombre. Ningún documento. Ningún enlace entre dos agentes que opera la misma persona, de modo que una contraparte no puede correlacionar en silencio toda una flota hasta reconstruir un perfil. La verificación que el humano hizo una vez es reutilizable por todos sus agentes y, a la vez, ilegible para todos los servicios con los que esos agentes hablan.

Tres propiedades sostienen esto, y las trataría como invariantes — las cosas que nunca tienes permitido romper por comodidad:

• El respaldo es demostrable; la identidad no. Un verificador puede confirmar que un humano real y exigible está detrás del agente, y no puede averiguar quién.
• Los agentes de un mismo operador son no enlazables. Las personas con las que tratan no pueden atar dos agentes del mismo principal entre sí.
• El único hilo de vuelta a la persona vive en depósito en garantía, abrible solo bajo el debido proceso. Ni en un token, ni en un cable, ni en un log que una brecha pueda volcar.

Una responsabilidad que puedes cobrar, no solo demostrar

Demostrar que existe un humano exigible es necesario y, por sí solo, no basta para el comercio real. Lo aprendí mirando cómo se resuelven de verdad las disputas: una contraparte agraviada no quiere un nombre meses después de un pleito transfronterizo. Quiere su dinero de vuelta, rápido. Una responsabilidad que es demostrable pero no cobrable no desbloquea nada de valor.

Así que el respaldo tiene que estar financiado. Junto a la prueba de humano-verificado, un agente puede llevar la prueba de que detrás de él hay una cantidad real y acotada de compensación disponible — capital que el principal ha depositado, demostrable como un tramo acotado («al menos esto es recuperable») sin exponer nunca el saldo exacto ni la cuenta. Esta es la versión financiada por adelantado y respetuosa con la privacidad de aquello hacia lo que el mercado ya tantea con los tokens de pago de «Know Your Agent» — con la diferencia de que aquí el dinero es real y el humano sigue sin quedar expuesto.

Eso convierte la responsabilidad en una escalera en lugar de un único precipicio. La mayoría de disputas se resuelven en el peldaño de abajo: una reclamación fundada se paga con la compensación depositada bajo un proceso publicado, se carga al principal y se le notifica, y a nadie se le revela ninguna identidad. Solo los casos genuinos de último recurso —daño por encima de los fondos depositados, presunto fraude, requerimiento legal— escalan hasta desenmascarar de verdad al humano, bajo el debido proceso. La responsabilidad financiada acaba siendo más protectora de la persona, no menos, porque resuelve los casos ordinarios con dinero en lugar de con un nombre.

Seré claro con las aristas duras de esto, porque es la parte regulada. Custodiar fondos de otras personas implica un custodio con licencia y avalado, cuentas segregadas, comprobaciones antiblanqueo sobre el origen de los fondos, y un tratamiento honesto de la reversibilidad — el dinero depositado con un instrumento de pago cotidiano se puede reclamar de vuelta durante meses, así que la compensación que respalda no se puede tratar como definitiva desde el primer día. Cualquier vía de baja fricción para dar de alta a un humano rápido es, por definición, de baja garantía, y hay que graduarla como tal en lugar de disfrazarla de más. Nada de eso es razón para no construirlo. Es la razón por la que hay que construirlo con cuidado, con el marco legal al lado del protocolo y no arrastrándose por detrás.

Solo funciona si nadie es dueño de la raíz

Hay una restricción del segundo post con la que no voy a transigir, porque descarta el dinero fácil: no debe convertirse en un jardín vallado. La versión con mucho capital de esta idea es un servicio centralizado de identidad de agentes que alquilas a un único proveedor, y para una economía de agentes abierta y entre organizaciones eso es inviable de salida. Una contraparte en otra empresa, sobre otro stack, tiene que poder verificar la prueba sin llamar a la API privada del emisor y sin confiar en que una corporación no extraiga renta, no censure ni sufra una brecha.

Eso empuja el ancla de confianza hacia una raíz neutral de la que ningún actor sea dueño — un sitio donde un verificador pueda comprobar, contra el estado actual del emisor, que una credencial es real y no está revocada, sin ninguna visibilidad de quién hay detrás. Una raíz neutral compra además dos cosas que el paper marcó como sin resolver: revocación rápida y global —una señal de estado refrescada con frecuencia para que una credencial anulada deje de verificar en segundos, en todas partes— y un kill-switch por agente, de modo que un agente comprometido se pueda tirar sin tumbar al principal ni a sus hermanos.

La propiedad que hace que esto escale es casi aburrida, y es la que más importa: un agente no es más que otro portador de credenciales. No hay un registro por agente sentado en algún repositorio central a la espera de ser enumerado, vulnerado o inflado. La capa de confianza guarda un puñado de raíces de estado de los emisores, refrescadas con cadencia corta; los agentes —y el dinero que hay detrás— viven a un lado, demostrados contra esas raíces, nunca inscritos en ellas. Eso es lo que permite que el diseño se estire hasta una población de agentes mayor que la humana sin la explosión de estado que mata a todo enfoque de «registra cada agente centralmente».

El hilo conductor

Quita la criptografía y la restricción es simple, y es la misma que llevo rondando desde el primer post: el agente es autónomo, pero la responsabilidad no puede serlo. Detrás de cada flota hay un humano real y exigible, y todo el juego consiste en demostrar ese hecho a quien lo necesite mientras no expones a la persona ante nadie. Verifica al humano una vez. Deja que la responsabilidad —financiada, revocable y privada— viaje hacia todo lo que despliegue. Mantén el único hilo de vuelta a su identidad encerrado tras el debido proceso, donde una brecha no pueda alcanzarlo y un comercial no pueda comprarlo.

He enmarcado toda esta serie en torno a la necesidad técnica a propósito, porque la necesidad es real tanto si mi respuesta concreta es la acertada como si no, y prefiero que juzgues el problema antes de enseñarte la herramienta. Esa parte viene a continuación, fuera de esta serie: he estado construyendo esto, no solo esbozándolo, y pronto te enseñaré qué aspecto tiene de verdad.

Si ahora mismo te estás peleando con la identidad o la responsabilidad de los agentes dentro de tus propios sistemas y quieres un segundo par de ojos de gente que construye esto para ganarse la vida, habla con un CTO. El mapa es difícil. Lo es mucho menos en compañía.