El modo paranoico de Vitalik Buterin pone a prueba la promesa de privacidad de IA de Ethereum
Vitalik Buterin ha situado su agente de IA detrás de cuatro capas de privacidad, aunque reconoce que esta configuración experimental sigue siendo más lenta y vulnerable al análisis de tráfico. El modo paranoico de Vitalik Buterin combina enrutamiento mediante Tor, tráfico de cobertura, pagos anónimos y reescritura local de prompts. Su objetivo es impedir que un proveedor de IA pueda vincular fácilmente una conversación con la persona que la inició.
El prototipo llega dos semanas después de que la Ethereum Foundation y Open Anonymity Project lanzaran zkAPI en la red principal de Ethereum. Ese sistema separa los pagos de API medidos de la identidad de facturación de un usuario mediante pruebas de conocimiento cero. El envoltorio de Buterin intenta abordar la información que la privacidad de los pagos por sí sola no puede ocultar, incluidas las direcciones de red, los patrones temporales y los hábitos de escritura reconocibles.
Esta distinción importa para las instituciones que consideran agentes autónomos para finanzas, investigación u operaciones internas. Ethereum puede proporcionar un mecanismo de pago privado, pero no puede hacer que un modelo externo olvide el prompt que debe procesar. Por tanto, el experimento pone a prueba una propuesta más difícil: si varias protecciones incompletas pueden formar un entorno operativo lo bastante privado para agentes de IA útiles.
El modo paranoico de Vitalik Buterin añade cuatro capas de privacidad
El experimento de Buterin trata la privacidad de la IA como una cadena de filtraciones separadas, en lugar de como un único problema de cifrado.
El 16 de octubre de 2026, Buterin describió un demonio compatible con OpenAI construido en torno a su arnés personal para agentes de IA. Un demonio es un programa en segundo plano que gestiona las solicitudes entre el agente y proveedores externos de modelos.
La configuración asigna un circuito Tor independiente a cada conversación. Tor enruta el tráfico a través de múltiples relés, lo que impide que el destino vea directamente la dirección original de internet del usuario.
Cada conversación conserva el circuito asignado mientras la sesión permanece activa. Una nueva sesión recibe un circuito diferente y una nueva autorización de pago. Este diseño limita los vínculos directos entre conversaciones separadas sin asumir el coste de rendimiento en cada mensaje.
Buterin también mezcla solicitudes genuinas con tráfico de cobertura aleatorio. El tráfico de cobertura consiste en comunicaciones señuelo enviadas para dificultar que un observador identifique la actividad real. Este enfoque oculta picos evidentes de solicitudes frente a la supervisión pasiva, aunque no neutraliza todas las formas de análisis temporal.
Un modelo de lenguaje local reescribe los prompts antes de que salgan del ordenador del usuario. Este paso intenta eliminar huellas estilísticas, expresiones recurrentes y otros patrones lingüísticos que podrían identificar al autor.
El modelo local no vuelve invisible el contenido del prompt. Cambia la presentación mientras conserva suficiente significado para que el modelo remoto responda. Los nombres, documentos, detalles de transacciones o hechos inusuales aún pueden revelar al usuario.
Buterin ejecuta después el agente dentro de una zona aislada de bubblewrap. Una zona aislada restringe los archivos, dispositivos y recursos de red a los que puede acceder un programa. Las llamadas de red pasan por torsocks, que dirige las conexiones compatibles a la red Tor.
La capa de pagos procede de zkAPI. En lugar de presentar una clave de API convencional vinculada a una cuenta, el software obtiene credenciales de corta duración mediante pruebas criptográficas de pago.
Buterin probó el sistema combinado con una solicitud de restaurantes veganos en Tallinn. La tarea era deliberadamente común, pero puso a prueba todo el recorrido, desde la reescritura local hasta la inferencia remota.
Describió la pila como “bastante utilizable”, aunque señaló una latencia considerable al iniciar nuevas conversaciones. Esa admisión define el experimento con mayor precisión que su nombre. El modo paranoico es un prototipo funcional con concesiones explícitas, no un producto de privacidad terminado.
El código público también incluye advertencias importantes. El repositorio de zkAPI describe su rama con privacidad habilitada como una versión no destinada a producción. Algunos manifiestos de red siguen sin desplegarse y el material de prueba para producción está incompleto.
Estas salvedades hacen que el evento sea más que un anuncio de funcionalidades. Buterin ha reunido un modelo de amenazas concreto y ha expuesto dónde fallan los componentes. El resultado invita al escrutinio de organizaciones que necesitan garantías, auditorías y responsabilidad operativa.
Por qué el impulso de Ethereum en seguridad de IA importa ahora
Los agentes de IA convierten las debilidades habituales de privacidad en riesgos operativos porque combinan contexto sensible, herramientas externas y autoridad para actuar.
Un chatbot estándar recibe texto y devuelve texto. Un agente puede mantener memoria, examinar documentos, llamar a API, ejecutar código e interactuar con cuentas financieras. Estas capacidades adicionales crean sistemas más útiles, pero también amplían las consecuencias de las filtraciones de identidad.
Un agente de inversión podría recibir detalles de cartera, operaciones previstas, direcciones de billeteras, preguntas fiscales e investigación privada. Un agente corporativo podría procesar registros de clientes, código fuente, planes de productos o documentos legales.
Incluso cuando un proveedor no exige un nombre real, varias señales pueden reconstruir la identidad. Una dirección de internet revela el origen de la red. Un método de pago vincula el uso a una cuenta. El estilo de escritura y los hechos repetidos pueden relacionar sesiones separadas.
El lanzamiento de zkAPI de la Ethereum Foundation aborda la parte de facturación de ese problema. Los usuarios depositan créditos en una bóveda de Ethereum y reciben una nota privada que representa su saldo.
Cuando el software necesita acceso a una API, genera una prueba de conocimiento cero. Esta prueba confirma que existe crédito suficiente sin identificar el depósito original ni a su propietario.
El servicio emite entonces una clave de corta duración con un límite de gasto restringido. Los prompts viajan al proveedor del modelo, mientras que la autorización de pago recorre una ruta separada. El proveedor ve el contenido y el uso, pero no debería recibir la identidad de facturación del pagador.
El diseño actual utiliza pruebas Groth16 sobre la curva BN254. Los compromisos y los nulificadores impiden que los observadores conecten simplemente cada solicitud con el mismo saldo depositado. Un nulificador es un identificador unidireccional que bloquea la reutilización sin revelar el secreto subyacente.
Este enfoque difiere de pagar cada solicitud mediante una transacción visible en blockchain. Los pagos directos en cadena pueden exponer la temporalidad, el historial de billeteras y las relaciones entre servicios. También pueden añadir una demora inaceptable a un agente interactivo.
zkAPI autoriza una sesión en su lugar. Eso reduce el trabajo repetido de prueba y liquidación, al tiempo que preserva una separación entre la financiación y las solicitudes individuales.
El sistema se extiende más allá de la inferencia de IA. Su arquitectura puede admitir otros servicios medidos, incluidas llamadas de datos de blockchain, generación de medios, ancho de banda o tareas de máquina a máquina. La IA sigue siendo la prueba más clara porque los prompts suelen contener información íntima o comercialmente sensible.
Las instituciones juzgarán el sistema de forma distinta a los desarrolladores individuales. Un prototipo puede tolerar configuración manual e interfaces cambiantes. Un banco, laboratorio de investigación o equipo de seguridad empresarial necesita controles estables, modos de fallo documentados y revisión independiente.
Estos compradores también necesitan saber qué parte puede observar cada etapa. El servidor de pagos ve una autorización válida y el uso total. El proveedor del modelo ve el prompt y la respuesta. Ethereum registra depósitos y retiradas, pero no la conversación en sí.
Esta separación puede reducir la recopilación concentrada de datos. No elimina la exposición de datos. Para los usuarios institucionales, esa diferencia determina si el sistema admite cargas de trabajo reguladas o solo experimentos de menor riesgo.
El momento también refleja un cambio más amplio en la seguridad de IA. Las organizaciones están pasando de promesas generales de privacidad a controles técnicos que dividen la confianza entre dispositivos, sistemas de pago, redes y proveedores de inferencia.
El prototipo de Buterin presiona esa tendencia al preguntar si la privacidad debería construirse alrededor del propio agente. Si el agente controla el enrutamiento, la reescritura, el pago y los permisos, los usuarios dependen menos de las políticas de cuenta de un proveedor.
Los pagos anónimos no crean IA anónima
La concesión central es sencilla: Ethereum puede ocultar quién paga, mientras que el modelo sigue necesitando suficiente información para realizar el trabajo solicitado.
El diseño de uso privado expone esta limitación de forma directa. zkAPI no proporciona anonimato de red ni evita las filtraciones de privacidad a través del contenido de los prompts.
Ese límite es crucial. Las pruebas de conocimiento cero pueden confirmar el pago sin exponer una relación de financiación. No pueden impedir que un proveedor de inferencia lea el texto enviado para su procesamiento.
La reescritura local de prompts intenta reducir esa exposición. Un modelo pequeño puede eliminar formulaciones habituales, sustituir frases identificativas o generalizar determinados detalles antes de la transmisión.
Sin embargo, la reescritura se vuelve menos útil a medida que un agente recibe trabajo más específico. Una solicitud para resumir un documento público es fácil de sanear. Una solicitud que involucra un contrato privado, un historial médico o un repositorio propietario es mucho más difícil.
Eliminar demasiado contexto reduce la calidad de la respuesta. Conservar el contexto necesario puede revelar precisamente la información que el usuario quería proteger. Ninguna técnica de enrutamiento resuelve ese conflicto entre contenido y utilidad.
El historial de conversación crea otra debilidad. Un prompt aislado podría revelar poco, pero una secuencia puede formar un perfil distintivo. Ubicaciones, proyectos, preferencias y vocabulario repetidos proporcionan puntos de correlación entre sesiones.
Los circuitos Tor separados no impiden la correlación basada en contenido. Tampoco lo hacen las credenciales de pago separadas. Limitan determinados identificadores mientras dejan identificadores semánticos disponibles para el proveedor del modelo.
Las herramientas del agente también generan información. Las consultas de búsqueda, los documentos recuperados, las llamadas de transacción y los mensajes de error pueden exponer la intención. Un prompt de usuario reescrito ofrece poca protección si una herramienta envía después un archivo sin modificar.
La zona aislada aborda una amenaza diferente. Limita a qué puede acceder un agente comprometido o mal dirigido en la máquina local. Esta protección importa porque un agente puede seguir instrucciones hostiles incrustadas en sitios web o documentos.
Sin embargo, una zona aislada solo aplica los permisos que recibe. Si el agente necesita legítimamente acceso a una carpeta sensible, el contenido de esa carpeta aún puede entrar en su contexto de trabajo.
Por tanto, el despliegue institucional requiere límites de datos explícitos. Los equipos de seguridad deben definir qué archivos puede examinar el agente, qué herramientas puede llamar y qué destinos pueden recibir resultados.
También necesitan registros para investigar incidentes. Ese requisito puede entrar en conflicto con la imposibilidad de vinculación. Un sistema diseñado para borrar conexiones entre identidad y uso puede dificultar la responsabilidad interna, salvo que la auditoría se gestione localmente.
La promesa no es el anonimato completo. Es la compartimentación, con distintas partes conociendo diferentes fragmentos de la transacción.
Eso aún puede ser valioso. Un proveedor de modelos puede procesar un prompt sin recibir un perfil de facturación persistente. Un sistema de pagos puede liquidar el uso sin ver la conversación. Un relé de red puede reenviar tráfico sin conocer ambos extremos.
Las instituciones ya aplican principios de separación similares en la custodia financiera y la gestión de accesos. Ningún operador individual debería poseer todas las credenciales, aprobaciones y registros necesarios para abusar de un sistema.
Pero la inferencia de IA añade un destinatario inevitable. El modelo remoto debe recibir contenido útil, a menos que el cálculo se realice localmente o dentro de hardware confidencial. El modo paranoico reduce los metadatos circundantes, pero no elimina esta dependencia básica.
Tor y el tráfico de cobertura dejan una brecha temporal
El modo paranoico eleva el coste de la vigilancia, pero el propio modelo de amenazas de Buterin muestra por qué el tráfico señuelo aleatorio no puede garantizar la imposibilidad de vinculación.
Tor funciona bien frente a muchos observadores pasivos. Oculta la conexión directa entre un usuario y un destino al retransmitir el tráfico a través de múltiples nodos.
Sin embargo, el tráfico de IA presenta un patrón reconocible. Un usuario envía un prompt, el proveedor recibe una solicitud y devuelve una respuesta. La sincronización y el volumen de los paquetes pueden crear firmas coincidentes incluso cuando el contenido sigue cifrado.
El tráfico de cobertura aleatorio dificulta esa correlación. Las solicitudes falsas rodean la actividad genuina, ofreciendo a un observador más eventos posibles que comparar.
Un atacante activo dispone de más opciones. Un proveedor de modelos podría retrasar o variar intencionadamente el tráfico de respuesta. Si ese proveedor cooperara con un relay de entrada, ambas partes podrían buscar el mismo patrón manipulado.
Buterin identificó esta posibilidad al hablar de su implementación. Su respuesta preferida a largo plazo es una mixnet especializada con tráfico de cobertura constante.
Una mixnet envía mensajes a través de múltiples intermediarios que retrasan, reordenan y combinan el tráfico. El tráfico de cobertura constante mantiene un flujo regular incluso cuando el usuario no tiene una solicitud genuina.
Los mensajes reales sustituyen entonces a los paquetes señuelo sin cambiar la tasa de transmisión visible. Un observador ve el mismo patrón antes, durante y después de la actividad del agente.
Ese diseño más sólido implica costes directos. El tráfico constante consume ancho de banda mientras el usuario está inactivo. La mezcla añade latencia, y los relays distribuidos globalmente aumentan la complejidad operativa.
El sistema también necesita suficientes operadores de relays independientes. Si una organización controla todos los relays de una ruta seleccionada, puede reconstruir una mayor parte del recorrido.
Los incentivos económicos no resuelven automáticamente este problema. El staking puede penalizar fallos medibles, pero no puede demostrar que operadores nominalmente separados carecen de un propietario común.
Un proyecto lanzado recientemente que utiliza el nombre Paranoid Mode propone rutas de tres saltos y relays con staking. Su sitio web afirma que es independiente de Buterin y de la Ethereum Foundation. Esta distinción importa porque la existencia de una implementación no constituye un respaldo.
La red independiente también ilustra otro desafío: los incentivos basados en tokens pueden distraer de la evaluación de seguridad. Las recompensas para relays, las reglas de gobernanza y los parámetros de slashing no sustituyen una revisión criptográfica.
El análisis de las limitaciones de Tor también señala que los proveedores siguen recibiendo prompts reescritos. Por tanto, la protección del tráfico y la protección del contenido deben evaluarse por separado.
La latencia sigue siendo el coste más visible para el usuario. Buterin informó de un inicio más lento en las conversaciones nuevas porque cada sesión establece un estado de red y pago nuevo.
Las organizaciones podrían aceptar ese retraso para investigaciones sensibles o transacciones de alto valor. Es menos probable que lo acepten para tareas interactivas rutinarias que requieren llamadas rápidas a herramientas.
El tráfico de cobertura plantea una cuestión financiera adicional. Las llamadas al modelo utilizadas como señuelos resultarían costosas si llegaran a un proveedor de pago. Los paquetes a nivel de red son más baratos, pero requieren infraestructura especializada que reconozca y descarte de forma segura los mensajes de cobertura.
Un diseño viable debe decidir dónde terminan los señuelos y quién paga su transporte. También debe impedir que los relays finjan enviar el tráfico requerido mientras ahorran ancho de banda.
Estas cuestiones no invalidan el prototipo. Aclaran la brecha entre reducir los metadatos evidentes y ofrecer una garantía de anonimato defendible.
Esa distinción determinará si el modo paranoico sigue siendo una configuración personal o se convierte en una arquitectura de referencia para la IA institucional.
La adopción institucional necesita auditorías, controles y una responsabilidad clara
Las instituciones evaluarán la pila como una colección de dependencias de seguridad, no como una única función de privacidad asociada a Ethereum.
La primera dependencia es zkAPI en sí. Su repositorio público califica el protocolo como experimental y advierte que las interfaces pueden cambiar antes de una versión estable.
Los sistemas criptográficos requieren más que código funcional. Las instituciones buscarán auditorías independientes, compilaciones reproducibles, generación segura de parámetros y respuestas claras ante vulnerabilidades descubiertas.
El riesgo de los contratos inteligentes también permanece. Los fondos depositados en una bóveda dependen de la lógica del contrato, la verificación de pruebas y los mecanismos de retiro. Un beneficio de privacidad no compensa un fallo que pueda bloquear o desviar activos.
La segunda dependencia es el cliente local. Gestiona el material de la cartera, las credenciales de sesión, la reescritura de prompts y las decisiones de enrutamiento. Una vulneración en ese punto puede eludir todas las capas de privacidad posteriores.
Por ello, la distribución de software pasa a formar parte del modelo de amenazas. Los usuarios deben verificar binarios, actualizaciones, dependencias y archivos de configuración. Los equipos empresariales también exigirán despliegue gestionado y aplicación de políticas.
La tercera dependencia es el modelo local utilizado para la reescritura. Su resultado debe preservar el significado de la tarea a la vez que elimina identificadores. No existe una puntuación simple que demuestre que logró ambos objetivos.
Una reescritura podría cambiar una cláusula contractual crucial o una restricción técnica. También podría preservar un detalle distintivo porque eliminarlo haría inutilizable el prompt.
Las organizaciones necesitan pruebas que cubran tanto la privacidad como la precisión semántica. Esas evaluaciones deberían usar cargas de trabajo representativas en lugar de ejemplos genéricos de chat.
La cuarta dependencia es el proveedor del modelo. El modo paranoico reduce el acceso del proveedor a metadatos de identidad y pago, pero el proveedor sigue controlando la inferencia.
Puede conservar el contenido según sus ajustes técnicos y obligaciones contractuales. También puede cambiar modelos, sistemas de registro o controles contra abusos de formas que el cliente local no puede verificar.
La informática confidencial ofrece una posible vía de apoyo. Un entorno de ejecución de confianza aísla código y datos dentro de hardware protegido, al tiempo que proporciona evidencia sobre el software en ejecución.
Sin embargo, la inferencia respaldada por hardware introduce sus propios proveedores, sistemas de atestación e historial de vulnerabilidades. Desplaza la confianza en lugar de eliminarla.
Las instituciones también deben decidir cómo gestionar solicitudes legales e investigaciones internas. Los sistemas de privacidad diseñados para impedir la correlación pueden complicar el cumplimiento normativo, la revisión de fraudes y la rendición de cuentas de los empleados.
Una versión empresarial práctica podría necesitar una identidad controlada por la organización fuera del proveedor. El empleador podría saber qué empleado inició una sesión, mientras que el proveedor del modelo recibiría únicamente una autorización imposible de vincular.
Ese acuerdo preservaría la gobernanza interna sin proporcionar a la empresa de inferencia un perfil completo del usuario. También requeriría una separación cuidadosa entre los registros de auditoría y el contenido de los prompts.
El enfoque original de AMBCrypto vinculó el experimento con el interés institucional en Ethereum. Esa conclusión sigue siendo especulativa. Buterin no anunció un producto institucional, un despliegue para clientes ni un cambio formal en el protocolo de Ethereum.
El informe de pagos en mainnet confirma que zkAPI está operativo, pero el despliegue no demuestra adopción. Los datos de uso, las integraciones de proveedores y las revisiones de seguridad independientes aportarán pruebas más sólidas.
Las instituciones también se preocupan por la continuidad. Necesitan operadores creíbles, procesos de soporte, expectativas de nivel de servicio y planes de migración. Un prototipo de código abierto puede aportar componentes sin ofrecer esas garantías.
El caso más sólido a corto plazo podría involucrar a desarrolladores que ya operan infraestructura de Ethereum y comprenden sus riesgos. Pueden probar pagos privados de API sin tratar toda la pila como lista para producción.
Las organizaciones más grandes pueden estudiar la arquitectura como un patrón. Separar la identidad de pago, el origen de la red, la preparación de prompts y los permisos locales. Después, evaluar cada control frente al modelo de amenazas real de la organización.
Qué sigue para la privacidad de la IA en Ethereum
Tres señales mostrarán si el modo paranoico de Vitalik Buterin se está convirtiendo en infraestructura o sigue siendo un experimento influyente.
La primera señal es una versión de zkAPI revisada de forma independiente, con artefactos de producción estables. Las auditorías deberían examinar los contratos de la bóveda, el sistema de pruebas, la cartera del cliente y las rutas de retiro.
Una versión estable reforzaría la idea de que el pago anónimo de API puede sustentar aplicaciones reales. Las advertencias continuadas sobre componentes no desplegados mantendrían el sistema dentro del uso experimental.
La segunda señal es la adopción por proveedores de modelos o pasarelas de API. La capa de pagos se vuelve más útil cuando los desarrolladores pueden acceder a varios servicios de inferencia sin reconstruir las integraciones para cada uno.
El respaldo de los proveedores también pondría a prueba si el pago anónimo puede coexistir con la prevención del abuso. Los servicios necesitan límites de tasa, controles antifraude y cumplimiento legal incluso cuando no pueden identificar a todos los pagadores.
Un equilibrio funcional respaldaría la afirmación más amplia de Buterin de que las API no requieren cuentas vinculadas permanentemente a una identidad. El rechazo por parte de proveedores importantes debilitaría el alcance práctico de la arquitectura.
La tercera señal es una capa creíble de privacidad de red diseñada específicamente para el tráfico de agentes. Debe proporcionar tráfico de cobertura constante sin hacer inaceptables la latencia y el ancho de banda.
Esa capa también necesita diversidad independiente de relays y un modelo de seguridad medible. Una lista de relays tokenizada por sí sola no respondería a las preguntas sobre concentración de operadores o ataques activos.
Un desarrollo exitoso cerraría la debilidad de red más importante identificada por Buterin. El fracaso dejaría a Tor y al tráfico de cobertura aleatorio como defensas útiles, pero incompletas.
Los lectores no deberían tratar el movimiento del mercado de ETH como una métrica de validación. El prototipo no tiene una relación demostrada con los ingresos de la red, la demanda institucional ni el precio del activo.
Los indicadores relevantes son técnicos y operativos. Conviene observar los resultados de auditorías, las versiones estables, las integraciones reales de proveedores y el uso sostenido por desarrolladores que manejan trabajo sensible.
Para los creadores de IA, la lección inmediata es arquitectónica. La identidad se filtra por varios canales, por lo que una única función de privacidad no puede proteger a un agente por sí sola.
Los equipos deberían mapear qué pueden observar el sistema de pagos, la red, el proveedor, el cliente local y las herramientas del agente. También deberían mantener un registro consultable de modelos de amenazas y decisiones dentro de su base de conocimiento técnico.
El modo paranoico de Vitalik Buterin hace visible ese riesgo fragmentado. No establece una IA privada de nivel institucional, pero ofrece a los equipos de seguridad una pila concreta que cuestionar.
La siguiente cuestión es si los revisores independientes y los proveedores de servicios pueden convertir sus protecciones en capas en infraestructura fiable. Hasta entonces, el modo paranoico debería tratarse como un experimento serio con limitaciones inusualmente sinceras.
