Identidad de agentes de IA y blockchain: qué aporta y qué no
Contenido revisado el 17 de septiembre de 2026 · Equipo editorial NextAI
Qué funciona ya sin blockchain, qué añadirá el anclaje en Base con EAS y ERC-8004, y qué problemas no resuelve ninguna de las dos capas.
La identidad verificable de un agente de IA no necesita blockchain para funcionar: una credencial W3C firmada, publicada en un dominio y con revocación en lista firmada ya permite que cualquiera compruebe quién opera el agente y con qué alcance. Lo que el anclaje en blockchain añadirá es otra cosa, más estrecha y más útil de lo que suele venderse: un historial de emisiones y revocaciones comprobable por terceros sin depender del emisor.
Este artículo separa lo que ya funciona, lo que llegará y lo que no va a resolverse con ninguna de las dos capas.
Lo que ya funciona hoy, sin blockchain
El DNI digital para agentes de IA se apoya en estándares abiertos del W3C y en infraestructura web convencional:
- Un identificador
did:web:digitalcortex.tech:agents:<slug>publicado en el dominio del emisor. - Una credencial W3C Verifiable Credentials 2.0 en formato
vc+jwt, firmada con ES256, con la clave privada en Google Cloud KMS. - Una huella de la configuración: el hash SHA-256 del manifiesto del agente.
- Caducidad a 90 días y revocación mediante W3C Bitstring Status List v1.0.
- Ocho comprobaciones públicas en vivo, sin registrarse, en el verificador de Argos.
La credencial vincula una declaración de identidad con el hash del manifiesto registrado. El alcance se firma en la emisión. Para detectar un cambio de prompt, modelo o permisos fuera de ese registro hay que contrastar la configuración efectiva: el hash no observa automáticamente los sistemas externos. Todo cambio de alcance aprobado requiere revisar y reemitir la declaración.
El hueco que queda
Hay un punto débil, y conviene nombrarlo sin rodeos: el historial depende del emisor. Si mañana quisiéramos hacer desaparecer el rastro de una credencial que estuvo vigente en agosto, tendríamos capacidad técnica de reescribir lo que publicamos en nuestro propio dominio.
Un tercero puede comprobar el estado actual, pero no puede demostrar por sí mismo qué decía la credencial hace tres meses ni cuándo exactamente se revocó. Para la mayoría de usos cotidianos eso es suficiente. Para una disputa, no.
La firma protege el origen y la integridad de una declaración. Un registro externo puede añadir evidencia temporal. Ninguna de esas dos cosas, por sí sola, demuestra cómo se ejecuta el agente.
Qué añadirá el anclaje en Base
La capa actual no necesita blockchain. La hoja de ruta contempla estudiar un anclaje en Base con EAS y ERC-8004, sin fecha comprometida ni despliegue acreditado. Antes de anunciarlo como operativo deberán publicarse contratos, transacciones y pruebas. Un registro externo puede aportar evidencia temporal; no demuestra la verdad de una declaración ni el cumplimiento de sus límites.
En concreto, el plan contempla tres piezas:
Atestaciones EAS. Cada emisión y cada revocación dejará una atestación con marca de tiempo y una referencia al contenido de la credencial. No se publicará la credencial completa ni datos personales: lo que se ancla es la prueba de que algo se emitió o se anuló en un momento determinado.
Registro ERC-8004. El agente quedará inscrito en un registro on-chain pensado para identidad de agentes, de modo que la referencia sea legible por sistemas de terceros y no solo por nuestro verificador.
Una novena comprobación. El verificador público pasará de ocho a nueve comprobaciones: se añadirá la validación del anclaje, es decir, que el estado que afirma el emisor coincide con el historial anclado en cadena.
No habrá token asociado, ni mecanismo especulativo, ni coste para quien verifica.
Por qué Base
Por tres razones prácticas: coste por transacción bajo, lo que permite anclar cada emisión y cada revocación sin que el gasto condicione la política de renovación a 90 días; herramientas de atestación ya maduras, con EAS ampliamente usado; y liquidación en Ethereum, que aporta un anclaje de seguridad reconocido.
Si las condiciones cambiaran, la arquitectura no obliga a quedarse: la credencial sigue siendo una credencial W3C estándar, y el anclaje es una capa adicional, no un requisito de funcionamiento.
Problema por problema: qué capa lo resuelve
| Pregunta | Evidencia | Estado de referencia |
|---|---|---|
| ¿Qué emisor declara la identidad? | Credencial firmada y DID | Público |
| ¿Qué alcance declara? | Campos firmados de la emisión | Público |
| ¿Coincide el manifiesto registrado? | Comparación de hashes | Consultable |
| ¿Sigue aceptándose la credencial? | Vigencia y estado | Consultable con su política de caché |
| ¿Se bloquea una acción en el conector? | Prueba de ejecución y rechazo | Debe probarse por integración |
| ¿Queda historial on-chain? | Contratos y transacciones | Hoja de ruta |
| ¿Es correcto o seguro el razonamiento? | Evaluaciones y controles adicionales | No lo demuestra la identidad |
Qué NO resuelve el blockchain aquí
Esta es la parte donde el sector suele estirar el lenguaje, así que conviene ser explícito.
El anclaje resolverá atribución, alcance y no repudio: quién emitió qué, cuándo, con qué límites y sin posibilidad de negarlo después. No resolverá la alineación del modelo ni su seguridad. Un agente puede estar perfectamente identificado, con su historial anclado al milisegundo, y aun así comportarse de forma indeseada porque el objetivo estaba mal especificado.
Una autodeclaración anclada sigue siendo una afirmación del emisor. El anclaje puede dificultar la alteración posterior del registro; no acredita que la afirmación sea cierta. Un cambio de permisos externo al manifiesto puede pasar inadvertido si no existe una comprobación operativa adicional.
Esa distinción entre identidad y control operativo es la misma que planteamos en gobernanza de agentes autónomos, y el límite de la credencial como herramienta de incidente está en cómo revocar la credencial y detener un agente.
Cómo leer las promesas del mercado
Cuando un proveedor mencione blockchain aplicado a agentes de IA, conviene preguntar tres cosas: qué se ancla exactamente, si hay datos personales en cadena y qué se puede comprobar hoy frente a lo que está previsto. Con esas tres respuestas, la mayoría de las propuestas se ordenan solas.
Nuestra política y nuestros formatos están publicados en la política de identidad agéntica y en la documentación técnica. Lo que está en producción se puede comprobar; lo que está previsto lo indicamos como previsto.
Preguntas frecuentes
¿Hace falta blockchain para tener identidad verificable de agentes?
No. La credencial firmada, el DID publicado, el hash del manifiesto y la lista de revocación ya permiten verificar quién opera un agente y con qué alcance. El anclaje añade una garantía adicional sobre el historial.
¿Qué son las atestaciones EAS?
EAS es un estándar de atestaciones sobre cadena que permite registrar afirmaciones firmadas con marca de tiempo. Aplicado aquí, servirá para dejar constancia de cuándo se emitió o se revocó una credencial sin publicar su contenido completo.
¿Se publicarán datos personales en la cadena?
No. Las credenciales no contienen datos personales de personas físicas, y lo que se anclará serán referencias y marcas de tiempo, no el contenido completo de la credencial ni información de clientes.
¿Habrá algún token o coste para quien verifique?
No. No hay token asociado ni mecanismo especulativo, y la verificación pública seguirá siendo gratuita y sin registro.
Qué hacer con esto
- Distingue lo que se puede comprobar hoy de lo que un proveedor anuncia para el futuro, incluidos nosotros.
- Empieza por la capa que ya funciona: credencial firmada, alcance publicado y revocación. El anclaje es mejora, no cimiento.
- Pregunta qué se ancla exactamente cuando alguien mencione blockchain, y si hay datos personales implicados.
- No confundas inmutable con cierto. Un registro inmutable protege el historial, no la veracidad de la afirmación.
- Separa identidad de seguridad. Ninguna de estas capas sustituye a los controles de acceso ni a la evaluación del modelo.
¿Quieres entender qué parte de esto tiene sentido para tu caso concreto? Habla con nosotros.
Actualización editorial del 17 de septiembre de 2026 realizada con apoyo de IA y contraste de documentación pública. No se presenta como una auditoría externa.
Identidad y ejecución: alcance de esta explicación
Las comprobaciones públicas describen la credencial y su relación con el manifiesto registrado. No prueban la autenticación de quien la presenta, el estado de cada permiso externo ni el bloqueo real de acciones. Consulta las evidencias y límites publicados.