Saltar al contenido principal

ERC-8220 y el Sello Inmutable: La capa de gobernanza de IA on-chain que le faltaba a Ethereum

· 14 min de lectura
Dora Noda
Dora Noda
Software Engineer

El noventa y dos por ciento de los profesionales de seguridad están preocupados por los agentes de IA dentro de sus organizaciones. El treinta y siete por ciento de esas mismas organizaciones tienen una política formal de IA. Esa brecha de 55 puntos es la frase de apertura de cada presentación de junta directiva en 2026 — y es exactamente el problema que el ERC-8220 intenta resolver on-chain.

El 7 de abril de 2026, una propuesta preliminar llegó al foro Ethereum Magicians proponiendo el ERC-8220: Interfaz estándar para la gobernanza de IA on-chain con el patrón de sello inmutable. Es el cuarto ladrillo de lo que un pequeño grupo de desarrolladores principales ha comenzado a llamar el stack de Ethereum agéntico: identidad (ERC-8004), comercio (ERC-8183), ejecución (ERC-8211) y ahora gobernanza. Si alcanza el estado Final antes del fork de Glamsterdam, podría hacer por los agentes autónomos lo que el ERC-20 hizo por los tokens fungibles — convertir un espacio de diseño desordenado en una primitiva composable.

La idea central de la propuesta es el "sello inmutable". Todo lo demás en el ERC-8220 fluye de él. Si se logra el sello correctamente, los otros tres estándares de repente tienen una base sobre la cual apoyarse. Si se hace mal, todo el stack agéntico hereda un modo de falla silencioso.

Por qué los "Agentes Trustless" necesitan siquiera una capa de gobernanza​

El ERC-8004 entró en funcionamiento en la mainnet de Ethereum el 29 de enero de 2026, otorgando a los agentes de IA identidad on-chain, reputación y registros de validación. El ERC-8183 le siguió con el depósito en garantía (escrow) programable, permitiendo a los agentes contratar, trabajar y recibir pagos a través de fondos bloqueados en contratos inteligentes liberados al finalizar la tarea. Biconomy y la Fundación Ethereum anunciaron conjuntamente el ERC-8211 poco después — un estándar de ejecución que permite a los agentes llevar a cabo estrategias DeFi de varios pasos ("smart batching") sin codificar previamente cada parámetro al momento de la firma.

Juntos, esos tres estándares resuelven tres problemas concretos: ¿quién es este agente?, ¿cómo se le paga? y ¿cómo transacciona? Pero dejan una cuarta pregunta estructuralmente sin respuesta: ¿qué se le permite hacer exactamente al agente, y cómo sé que el agente que se ejecuta hoy es el mismo que audité ayer?

Un artículo de 2025 sobre agentes descentralizados soberanos llama a esto la paradoja de lo trustless frente a lo confiable. Una vez que un agente autónomo se sella en un sustrato inmutable — con sus claves no extraíbles y su identidad on-chain persistente — los desplegadores humanos ganan resistencia a la manipulación pero pierden los controles fáciles para la supervisión, la responsabilidad y la reparación. El ERC-8004 te da una entrada en el registro. No te dice si los pesos y las políticas detrás de esa entrada cambiaron a las 3 a.m. del martes pasado.

Esta no es una brecha teórica. Un estudio de abril de 2026 de la Cloud Security Alliance encontró que más de la mitad de las organizaciones que ejecutan agentes ya han experimentado "violaciones de alcance" — agentes que realizan acciones fuera de su límite de autorización previsto. Un agente comprometido con una identidad ERC-8004 válida y un escrow ERC-8183 financiado es indistinguible on-chain de su gemelo honesto. Hasta que lees sus resultados. Para entonces, el depósito en garantía ya se ha liberado.

El Sello Inmutable, explicado​

El ERC-8220 propone una estructura de compromiso única on-chain — el sello — que vincula la identidad registrada de un agente a tres afirmaciones inmutables:

  1. Hash de los pesos del modelo. Un compromiso criptográfico con el conjunto exacto de parámetros que producen las inferencias del agente.
  2. Huella digital de los datos de entrenamiento. Un hash sobre el manifiesto del conjunto de datos (no los datos en sí), opcionalmente Merkle-izado para que sea posible una divulgación parcial para los reguladores.
  3. Restricciones de inferencia. Un documento de política legible por máquina — listas permitidas de llamadas a herramientas, techos de gasto, exclusiones jurisdiccionales — hasheado y comprometido junto con los pesos.

Fundamentalmente, el sello es irrevocable. Una vez que un agente registra su sello y comienza a operar, esos tres hashes no pueden mutarse sin emitir una nueva identidad de agente. La reputación, el historial de escrow y las autorizaciones de ejecución de la identidad anterior no se transfieren. Desde la perspectiva de la cadena, la versión 2 es un extraño.

Esto suena pedante hasta que se contrasta con cómo funcionan las plataformas de agentes hoy en día. La mayoría de los frameworks de agentes alojados permiten a los operadores intercambiar un modelo en caliente, ampliar silenciosamente una lista permitida de herramientas o aplicar un parche de plantilla de prompt — todo sin romper la identidad en la que confía la contraparte. Un sello rompe ese patrón por diseño. Un agente que quiera cambiar es libre de hacerlo; simplemente no puede pretender ser el agente en el que confiaste previamente.

Tres primitivas en competencia para "Probar que el agente es lo que afirma ser"​

El sello es una estructura de compromiso. No es, por sí mismo, una prueba. Aún necesitas un mecanismo para demostrar que el agente realmente ejecuta el modelo sellado bajo las restricciones selladas en el momento de la inferencia. Aquí es donde el ERC-8220 alcanza la frontera de tres primitivas de atestación competidoras, cada una con compensaciones muy diferentes:

1. Atestación basada en TEE (AWS Nitro, Intel TDX, AMD SEV-SNP)​

Los entornos de ejecución confiables de segunda generación admiten VMs completas con suficiente margen de memoria para albergar cargas de trabajo reales de ML. Al arrancar, el enclave produce una atestación firmada — una cadena de mediciones sobre el firmware y la imagen cargada, firmada por una clave de hardware no extraíble. Un verificador compara la medición con el compromiso sellado. Si coinciden, el modelo que el enclave está ejecutando es el modelo que el sello afirmaba.

Un patrón de producción común combina la atestación con un Servicio de Intermediación de Claves (KMS): el enclave presenta su atestación a un KMS, que libera la clave de descifrado para los pesos sellados solo si la medición coincide con la política. Esto te brinda garantías sólidas a velocidad de hardware — la inferencia se ejecuta con rendimiento nativo. La desventaja es que estás confiando en las claves raíz de Amazon, Intel o AMD y su microcódigo. El historial de canales laterales no es alentador.

2. ZKML (Zero-Knowledge Machine Learning)​

Los sistemas ZKML como DeepProve de Lagrange generan SNARKs para la inferencia, produciendo una prueba sucinta de que el resultado Y provino de la entrada X bajo el modelo comprometido. La verificación es económica y minimiza la confianza: no hay proveedores de hardware involucrados. El costo recae en el lado del probador (prover), donde el ZKML sigue siendo órdenes de magnitud más lento que la inferencia nativa. Para un modelo de 72 mil millones de parámetros que atienda consultas de agentes en tiempo real, el ZKML en 2026 es algo aspiracional.

3. Compromisos de Hash Criptográficos (El sistema de honor con slashing)​

La opción más ligera: comprometer el hash de los pesos en la cadena (on-chain), publicar los pesos fuera de la cadena (off-chain) (IPFS, Arweave, S3) y permitir que cualquiera realice verificaciones puntuales mediante el re-hasheo. Se combina con una capa de seguridad económica — validadores en staking que pueden ser penalizados (slashed) por firmar atestaciones de un archivo de pesos que no coincida. Es barato, rápido y auditable a posteriori. Es vulnerable a la sustitución en el momento de la inferencia que nadie note dentro de la ventana de desafío.

El movimiento más inteligente del ERC-8220 es que no elige. El sello es agnóstico al método de atestación — se compromete con qué es el agente, mientras permite que el cómo verificamos se declare como un campo en el propio sello. Un agente puede sellarse bajo una atestación TEE hoy y migrar a ZKML cuando el rendimiento lo permita, sin acuñar una nueva identidad, siempre que el hash de los pesos subyacente permanezca sin cambios.

Composición con el resto del stack​

El stack de agentes de cuatro capas solo funciona porque cada estándar asume que los demás existen. El ERC-8220 es lo que permite que los otros tres se utilicen de forma segura:

  • La identidad ERC-8004 adquiere significado solo cuando está vinculada a un sello. Sin él, el "agente 0x742…" es un nombre sin referente. Con el sello, el nombre hace referencia a un artefacto específico y auditable.
  • El depósito en garantía (escrow) ERC-8183 libera fondos basándose en un "asesor neutral" que confirma la finalización. Un agente sellado le da al asesor algo concreto contra lo cual evaluar — ¿el resultado se ajustó al documento de política cuyo hash está en el sello?
  • El agrupamiento inteligente (smart batching) ERC-8211 permite que los agentes ejecuten estrategias DeFi de múltiples pasos. Las restricciones de inferencia del sello definen el límite exterior: este agente puede agrupar hasta N operaciones en las cadenas A, B, C, con límites de gas X, Y, Z.

Este es también el argumento de por qué la gobernanza llegó al final y no al principio. No se puede gobernar de manera significativa a un agente que no tiene identidad, ni intereses económicos, ni un entorno de ejecución. Los tres primeros estándares crearon el área de superficie que el ERC-8220 ahora propone regular.

El viento de cola regulatorio​

La IMDA de Singapur publicó el primer marco de gobernanza gubernamental del mundo específicamente para agentes de IA autónomos en enero de 2026, estructurado en torno a cuatro dimensiones: delimitación de riesgos, responsabilidad humana, controles técnicos y responsabilidad del usuario final. La adenda de agentes de la Ley de IA de la UE, que se espera ampliamente antes de fin de año, parece seguir la misma forma. Ambos marcos piden a los implementadores que demuestren — ante un regulador, una contraparte o un tribunal — exactamente qué se le permitió hacer a un agente y qué hizo realmente.

El sello está diseñado a medida para esa solicitud. El documento de política comprometido es el artefacto de "riesgos delimitados". El vínculo inmutable entre la identidad y los pesos es el artefacto de "responsabilidad humana". El método de atestación es el artefacto de "controles técnicos". Un implementador que posee un agente sellado tiene una narrativa de defensa que no requiere una investigación forense de los registros del host del modelo.

Esta es la verdadera razón por la que el ERC-8220 importa más allá del mundo cripto-nativo. Si se implementa, ofrece a cualquier implementador de IA — no solo a los de la Web3 — una forma de publicar evidencia criptográfica de lo que su agente es y lo que no es. Eso es una primitiva regulatoria, no solo una de blockchain.

¿Se lanzará antes de Glamsterdam?​

La respuesta honesta: probablemente no en su forma Final, pero sí probablemente en una forma de borrador tardío que los equipos de clientes puedan comenzar a implementar. El proceso de estándares de Ethereum es notoriamente multicliente — el mismo problema de coordinación que retrasó el ePBS se aplica aquí. El ERC-8220 no requiere un hard fork (es una interfaz a nivel de contrato, no un cambio de protocolo), por lo que no compite por espacio de slots en Glamsterdam mismo. Por lo que sí compite es por la atención de los desarrolladores, y la infraestructura de agentes es la narrativa individual más ruidosa de 2026.

Los sectores que presionan por una pronta ratificación son aliados inusuales: proveedores de modelos (que quieren una forma estandarizada de anunciar lo que están entregando), implementadores empresariales (que quieren una historia de defensa en profundidad para las juntas directivas y reguladores) y protocolos DeFi (que enfrentan cada vez más tráfico impulsado por agentes y quieren valorar el riesgo por sello en lugar de por heurística).

Los sectores que se oponen son más pequeños pero sustanciales: equipos cuyo modelo de negocio depende de la capacidad de actualizar modelos silenciosamente a mitad del proceso, y proveedores de TEE que preferirían que su atestación fuera el único camino hacia un sello válido.

Qué vigilar de aquí a Glamsterdam​

  • Implementaciones de referencia. La primera implementación seria del ERC-8220 nos dirá qué primitiva de atestación trata el mercado como predeterminada. Mi apuesta es que inicialmente se base en TEE, y que el ZKML sea opcional para 2027.
  • Semántica de revocación de sellos. El borrador actual no dice nada sobre qué sucede cuando un sello es invalidado voluntariamente por el operador (retiro del modelo, error descubierto). La ruta de revocación es la parte más difícil del estándar y es donde aún podría fragmentarse.
  • Interoperabilidad con la reputación ERC-8004. Si la reputación de un agente sellado se transfiere limpiamente a un nuevo sello tras una actualización menor de la política, la propiedad de cambio de identidad por mutación se debilita. Si no se transfiere en absoluto, los operadores se resistirán a sellar.
  • Ecosistemas de auditores fuera de la cadena (off-chain). El sello es tan útil como los auditores neutrales que atestigüen contra él. Se espera una disputa histórica en 2026 que aclare la responsabilidad de los auditores.

El patrón a observar, en última instancia, es si la gobernanza se convierte en un producto en lugar de un costo de cumplimiento. El ERC-20 hizo eso por los tokens: los emisores dejaron de discutir sobre las primitivas de fungibilidad y comenzaron a competir en las cosas construidas encima del estándar. Si el ERC-8220 tiene éxito, la frase "nuestro agente está sellado bajo la política X, atestado mediante el método Y, auditable por cualquier poseedor del sello" se convertirá en marketing de requisitos básicos para 2027 — y la competencia interesante se desplazará hacia arriba en el stack, al diseño de políticas, la selección de auditores y los patrones de composición de sellos.

Ese sería el resultado más limpio posible: un estándar técnico tan aburrido que nadie hable de él, y un ecosistema de agentes sustancialmente más responsable porque simplemente existe de manera silenciosa.

BlockEden.xyz proporciona infraestructura de indexación y RPC de grado empresarial en todas las cadenas donde se construyen aplicaciones de agentes — Ethereum, Sui, Aptos y más. A medida que el volumen de consultas de agentes crece 10 veces más rápido que el volumen de consultas humanas, la infraestructura subyacente debe escalar sin cambiar silenciosamente. Explore nuestros servicios para construir sobre bases diseñadas para durar.

Fuentes​

Share on Twitter