A principios de abril, Vitalik Buterin publicó un artículo que movió agua en círculos técnicos: "My self-sovereign / local / private / secure LLM setup, April 2026". No es un manifiesto ni marketing: es un informe sobrio sobre cómo usa él personalmente la IA y por qué la mantiene local, aislada y desconectada de la nube.
El texto nos importa en Freshlab por una razón concreta. Buterin argumenta en las mismas coordenadas en las que llevamos años construyendo infraestructura: soberanía del dato primero, inferencia en el hardware del propio usuario, superficie de ataque mínima. Él llega desde el mundo cripto y la investigación en seguridad de sistemas; nosotros desde la consultoría para PYMES europeas. Las conclusiones son casi idénticas. El artículo original: vitalik.eth.limo — securellms.html.
Para una PYME española que hoy intenta cuadrar el RGPD, la Ley Europea de IA y un uso productivo de la IA, la publicación aporta una confirmación independiente de la dirección técnica que ejecutamos desde hace más de un año.
La tesis central
Buterin abre con un inventario que él mismo trata como señal de alarma. Su ejemplo es "OpenClaw" — representativo de la nueva generación de sistemas de agentes que actúan en el navegador, en el escritorio o directamente al nivel del sistema operativo. Estos agentes cambian ajustes críticos sin pedir confirmación. Un contenido web manipulado puede bastar para provocar ejecución de código arbitrario. La inyección de prompts no es un caso extremo, es el comportamiento por defecto.
Su diagnóstico es claro: el ecosistema en su conjunto es negligente con la seguridad y la privacidad. La comodidad manda, la telemetría por defecto se acepta y "no guardamos nada salvo para fines de entrenamiento" se ha convertido en la excusa estándar.
Frente a eso, Buterin plantea tres requisitos no negociables:
- Privacidad — ningún dato sale del dispositivo a menos que el usuario lo quiera explícitamente.
- Seguridad — las operaciones peligrosas están aisladas por defecto, no por opción.
- Auto-soberanía — sin bloqueo de proveedor, sin kill switch, sin cuenta obligatoria en la nube.
No es una postura ideológica, es un requisito de ingeniería. Describe las condiciones bajo las cuales un sistema de IA puede considerarse siquiera parte de una infraestructura seria, ya sea para un individuo o para una empresa con obligaciones de confidencialidad.
Qué recomienda
La parte práctica del artículo es una caja de herramientas detallada. Buterin enumera las opciones de hardware que él mismo ha probado:
- Portátil NVIDIA RTX 5090 — unos 90 tokens/s, la opción móvil de alta gama.
- AMD Ryzen AI Max con 128 GB de memoria unificada — unos 51 tokens/s, interesante por la gran reserva de memoria.
- NVIDIA DGX Spark — decepcionante para su precio, no la recomienda.
- Compartir hardware — sugiere explícitamente unirse con personas de confianza tras una IP estática cuando la inversión individual resulta inasumible.
En software, Buterin corre NixOS como sistema operativo reproducible y declarativo. Para la inferencia utiliza llama-server detrás de llama-swap, cargando distintos modelos bajo demanda. Para lo multimodal usa ComfyUI, probado con Qwen-Image y Hunyuan Video 1.5. Su modelo caballo de batalla: Qwen 3.5:35B, que en su práctica ofrece el mejor equilibrio entre velocidad y capacidad.
Cuatro mecanismos atraviesan su arquitectura:
- Local primero — la inferencia se queda en el hardware del usuario.
- Sandboxing completo — las operaciones peligrosas están aisladas para que el contenido malicioso no pueda comprometer el anfitrión.
- Sustitución de dependencias — la IA local reemplaza bibliotecas de terceros cuando es posible, reduciendo la superficie de ataque.
- Capacidad air-gap — el funcionamiento sin red está contemplado.
El propio Buterin lo resume sin adornos: "un punto de partida para un espacio que necesita existir con urgencia, no la descripción de un producto terminado." También es explícito sobre su distancia respecto a la investigación en seguridad tradicional, que tolera el acceso corporativo a los datos: se declara "profundamente opuesto a normalizar 'alimentar toda tu vida a una IA en la nube'."
Dónde difiere el enfoque de Freshlab
Desde 2024 construimos el mismo principio sobre hardware distinto. Nuestra configuración estándar para PYMES es el Mac Studio M3 Ultra, no la RTX 5090. Como runtime de inferencia usamos Ollama (y MLX directamente para cargas específicas), no llama-server/llama-swap. Como sistema operativo corre macOS, no NixOS.
Son diferencias reales, no cosméticas — y cada una tiene su razón:
- Una caja, no un rack. El Mac Studio es un único equipo. Sin caja ATX, sin torre, sin fuente separada de 1000 W. Para una oficina en Palma o en Valencia, esa diferencia decide si el sistema se adopta o no.
- Ruido y calor. La refrigeración del Mac Studio es prácticamente silenciosa. Un sistema con RTX 5090 bajo carga se oye y calienta la habitación.
- Menos fragilidad de drivers. La cadena de herramientas de Apple para Apple Silicon está muy integrada. Un stack CUDA más una configuración NixOS más actualizaciones de módulos de kernel es un entorno dependiente de competencias que muchas PYMES simplemente no tienen en casa.
- Memoria unificada hasta 192 GB. El Mac Studio M3 Ultra se configura hasta 192 GB por unos 5.800 euros sólo de hardware. Es margen suficiente para correr modelos de 70B–120B en local sin la complejidad de configuraciones multi-GPU.
- Ciclo de vida. El horizonte de 5–7 años de actualizaciones de seguridad de Apple y su cadena cerrada de firmware son más fáciles de documentar en una auditoría de cumplimiento que una compilación NixOS hecha a medida.
Consideramos que el stack de Buterin es técnicamente excelente — pero está pensado para alguien que lee configuraciones de NixOS como otros leen el periódico. Nuestro stack está pensado para el director general de una empresa de 40 personas que quiere deslizar un equipo en el rack y que funcione.
La coincidencia real
Las diferencias de detalle — RTX frente a M3 Ultra, NixOS frente a macOS, llama-server frente a Ollama — pueden tapar fácilmente lo que las dos arquitecturas comparten de verdad. Y eso es lo importante:
- La inferencia se queda local. Ningún prompt, documento ni embedding sale del dispositivo.
- El sandboxing es obligatorio, no opcional. Las acciones del agente se ejecutan en entornos aislados, no con permisos plenos sobre el anfitrión.
- Sin exfiltración a la nube. Ni durante la operación ni "para fines de entrenamiento futuros".
- Cumplimiento por diseño. RGPD, Ley Europea de IA, reguladores sectoriales — todos estos regímenes se simplifican cuando el dato nunca abandona el control de la empresa.
Para una PYME española la consecuencia práctica es concreta: la infraestructura de IA vive en la propia sala de servidores o en un centro de datos local de confianza. Los contratos de encargado del tratamiento se acortan. La respuesta a "¿dónde se procesa mi entrada?" es: aquí, en el edificio. Programas de financiación como el Kit Digital encajan mejor con este tipo de inversión, porque hay una partida real de capex — hardware, instalación, formación — y no una fuga recurrente hacia la nube.
El artículo de Buterin nos resulta valioso precisamente porque es una segunda voz independiente. Alguien que llega desde una dirección completamente distinta — Ethereum, criptografía, investigación de sistemas — aterriza en la misma arquitectura. Eso es convergencia, no casualidad. La inferencia local, el sandboxing y la minimización de confianza ya no son un nicho, son el valor por defecto razonable para un uso serio de la IA.
Más sobre soberanía del dato en detalle en /data-sovereignty.html. Una visión técnica de los modelos locales, en /local-ai.html.
Siguiente paso
Si ha leído el artículo de Buterin y ahora se pregunta cómo implementar la misma arquitectura en una PYME española de 20 a 200 personas — hardware, instalación, formación y documentación de cumplimiento incluidos — empiece por nuestro paquete piloto: solicitar proyecto piloto.