soberanIA@localhost: IA privada en local para PYMEs, del hierro al modelo en producción
El pasado mes de junio tuve el placer de cerrar el Hack & Beers Gijón Vol. 5 con una charla que llevaba tiempo queriendo dar: «soberanIA@localhost». La idea de fondo es tan simple como provocadora: con alrededor de 1.000 € de hardware y tu tiempo, puedes montar una IA privada de nivel profesional que no manda ni un solo dato fuera de tu máquina.
Como quienes me seguís desde hace años ya sabéis, en mis charlas siempre me mojo y esta no iba a ser menos. Os comparto aquí el recorrido completo, diapositiva a diapositiva, porque me habéis preguntado varios por el contenido. Aviso desde ya: esto NO es un tutorial de instalación paso a paso ni una lista de comandos para copiar y pegar. Es lo que funcionó, lo que no, y el criterio para decidir en cada caso, con datos medidos en mi propio hardware. Los errores incluidos, que de esos se aprende más que de los éxitos maquillados. Tenéis la presentación adjunta al final del post y abajo os explico cada diapo.
1. Portada: soberanIA@localhost
El título no es casual. soberanIA@localhost es un guiño al prompt de una terminal: el usuario «soberanía» conectado a «localhost», a tu propia máquina. Todo gira alrededor de esa idea, la de recuperar el control de tu IA y de tus datos. Va de terminal, de control y de hacértelo tú.
2. De qué va (y de qué no va) esta charla
Antes de nada, gestionar expectativas. Esto NO es un tutorial de instalación, ni humo de vendedor, ni la promesa de que la IA local sustituye al cloud en todo, porque no es verdad.
Lo que SÍ es: experiencia real medida en mi hardware, números reproducibles, los errores incluidos (el eGPU que se me cae, modelos que se inventan herramientas) y, sobre todo, criterio para decidir caso por caso. Meter los fallos no es debilidad, es lo que da credibilidad ante un público técnico, así de claro. El que solo enseña lo que salió bien, algo os está vendiendo.
3. ¿Por qué IA local AHORA?
Porque lo que hace 18 meses era impensable, hoy cabe en una GPU de consumo. Cuatro cosas cambiaron entre 2025 y 2026: la cuantización avanzada (modelos grandes en poca VRAM), las arquitecturas MoE eficientes, los modelos open source que ya compiten de tú a tú, y el hardware de consumo con GPU asequible.
La PYME ya quiere IA. La pregunta no es si la va a usar, sino a qué precio para sus datos. Y ese precio, en el cloud, se paga en soberanía.
4. Privacidad en IA cloud: ¿qué recogen?
Datos del estudio de Surfshark sobre cuántos puntos de datos recoge cada servicio (sobre 35 posibles). Gemini es el más intrusivo con 22, y es el único que se lleva tu lista de contactos del móvil. Le siguen Claude y Copilot con 13, DeepSeek con 11, ChatGPT con 10 y Grok con 7.
El dato que más me interesa remarcar: Anthropic cambió su política en septiembre de 2025. Antes era el único que no entrenaba con datos de consumidor por defecto. Ahora sí lo hace salvo que hagas «opt-out», con retención de cinco años si tienes el training activado. Ojo, que Surfshark mide cantidad de datos recogidos, que es UNA métrica de varias, no el veredicto absoluto. Pero da una foto bastante clara.
5. Los modelos chinos: el matiz que importa
Esta diapo la metí a conciencia, porque el discurso fácil («es chino, es malo») es un prejuicio, no un análisis. DeepSeek, MiniMax, GLM, Qwen… lideran el uso mundial. Son buenísimos. ¿Dónde está entonces el problema real?
El problema NO es el modelo. Son open-weight. Si los corres en tu hardware, como hago yo en la charla, la preocupación de datos desaparece. El modelo es legítimo.
El problema SÍ es el servicio hospedado. La web y la API oficial mandan tus datos a servidores en China. Y ahí entra la Ley de Inteligencia Nacional china de 2017, que obliga a las empresas a ceder datos a las autoridades sin avisar al usuario. Sumadle la ausencia de decisión de adecuación de la UE, la transferencia transfronteriza sin garantías y la retención sin límite claro. Por eso la Garante italiana bloqueó DeepSeek, y Berlín y Bélgica abrieron investigaciones.
Y lo honesto, que es como me gusta contarlo: esto es un gradiente, no un blanco o negro. Estados Unidos tiene su «Cloud Act», que también permite acceso gubernamental. La diferencia está en el grado de garantías y de recurso legal. Por eso lo verdaderamente soberano es lo local. El truco con los modelos chinos es sencillo: úsalos en local o en cloud occidental, no en su servicio oficial.
6. Las trampas que nadie cuenta
La letra pequeña de la privacidad en el cloud. Cuatro trampas que conviene tener claras:
El pulgar arriba entrena el modelo, aunque tengas la privacidad desactivada. Ese botón de feedback envía la conversación al training pese al «opt-out». Los GPTs de terceros traen su propia opción de entrenamiento activada por defecto, que ignora tu configuración global. El sello de «cumple RGPD» no significa datos en Europa: muchos usan el certificado DPF y operan desde EEUU. Y el DPA (el contrato de encargo del tratamiento, art. 28 RGPD) solo está en los planes Enterprise: los planes consumer no te dan protección legal completa.
La conclusión: ningún plan consumer da protección legal completa. Solo el local te da control total.
7. Mi setup
El hierro, sin postureo. Un Slimbook EVO (Ryzen Phoenix, 64 GB de RAM) como portátil de trabajo y cliente. Una RTX 5060 Ti de 16 GB (ASUS DUAL OC, Blackwell) por 599 €. Un dock eGPU USB4 de Slimbook por 199 €. Y un HP Z440 (Xeon E5-1660v4, 64 GB ECC) como host dedicado 24/7.
Coste total del proyecto: alrededor de 1.020 € para una IA local profesional completa. El Slimbook es el que me llevo con la eGPU; el Z440 se queda en casa sirviéndonos a mí y a Sheila por LAN. Elegí mono-Xeon a propósito: menos consumo y ruido que un bi-Xeon, y para Ollama la CPU casi no trabaja.
8. El cuello de botella oculto: el bus
Esta es de las lecciones que más me gusta contar, porque desmonta una suposición muy extendida. USB4 mueve unos 3,5 GB/s; un PCIe x16 mueve 32 GB/s. Con la misma GPU, lo que cambia el rendimiento no es lo que os imagináis.
Medido en mi equipo: modelo entero en VRAM (0% de «offload»), 86 tokens/s. Con un 15% en CPU, 34 t/s. Con un 25% en CPU, 17 t/s. ¿Y sabéis cuánto se gana poniendo la CPU en modo «performance»? Un mísero 10%. El cuello de botella era el bus, no la CPU. Por eso el host dedicado lleva la GPU en PCIe x16 directo. La diferencia entre una demo usable y una lamentable puede estar ahí. Lección de consultor: mide cada variable, no des nada por supuesto.
9. El stack: 100% open source
Nada de cajas negras, como no podía ser de otra forma viniendo de mí y de mis Debian ;). Ubuntu Server 24.04 LTS gestionado por SSH. El driver NVIDIA 595-open, obligatorio por ser Blackwell. Docker con el NVIDIA Container Toolkit para dar acceso a la GPU a los contenedores. Ollama como runtime de los modelos. Open WebUI como frontend accesible por LAN. Y bge-m3 para los embeddings locales del RAG.
Todo open source, sin telemetría externa. Cero dependencia de servicios cloud para el núcleo. bge-m3 es la pieza invisible: es lo que hace posible el RAG sin enviar tus documentos fuera.
10. Concepto: cuantización
Cuantizar es comprimir el modelo bajando la precisión de los pesos, de 16 bits a 4. La escala va de FP16 (más grande y preciso) a Q8, Q4, IQ4_XS (más pequeño y rápido).
La analogía que uso: es como un MP3 frente a un WAV. Técnicamente pierdes información, pero el oído apenas lo nota. El modelo ocupa la cuarta parte y va más rápido. IQ4_XS usa una matriz de importancia para dar más bits a los pesos que más importan; MXFP4 es la cuantización nativa de OpenAI en gpt-oss. Esto es lo que permite meter un 26B en una GPU de 16 GB. Sin cuantización, ese mismo modelo necesitaría hardware de unos 50.000 €.
Un apunte para no liarse: un Modelfile con num_ctx NO cuantiza, solo cambia el contexto. Cuantizar es procesar todos los pesos con llama.cpp. Son cosas distintas.
11. Dense vs Mixture of Experts (MoE)
Dos arquitecturas. Un modelo «dense» activa todos sus parámetros en cada token: más coherente en razonamiento largo, más pesado de computar, bueno para código, matemáticas y traducción. Un modelo «MoE» solo activa unos pocos «expertos» por token: velocidad de modelo pequeño con calidad de grande, ideal para chat, RAG y asistentes versátiles.
La pista está en el nombre: si veis «A4B», significa 4B activos (A de Active). gpt-oss, por ejemplo, tiene 21B totales pero solo 3,6B activos, y por eso vuela. De mi stack, gpt-oss y gemma4-26b son MoE; el resto, dense. En 2026 la línea se difumina cada vez más: los MoE modernos razonan casi como los dense. Dense para profundidad sostenida, MoE para velocidad versátil.
12. El torneo de modelos
Aquí viene lo divertido. Cogí tres modelos y los enfrenté con los mismos prompts, en mi hardware, usando el multi-model chat de Open WebUI. Nada de benchmarks sintéticos: cinco tareas reales de consultoría.
Los contendientes: glm-4.7-flash (de Zhipu AI, China, rápido), mistral-small3.2:24b (Mistral, Francia, 24B dense) y gemma4-26b (Google, MoE 25B/3.8B). Las cinco pruebas: redacción profesional para PYME, auditoría de ciberseguridad, script bash de monitorización, títulos SEO para Asturias y arquitectura FastAPI (esta última la hice aparte con qwen3.6-35b).
13. Cómo respondió cada modelo
13. Cómo respondió cada modeloEl detalle, sacado de mis chats reales. En redacción, gemma4-26b tuvo el enfoque más estratégico y persuasivo (planteó el dilema «¿nube o soberanía?»); Mistral, correcto pero plano. En ciberseguridad, gemma4-26b fue el único que citó el Artículo 9 del RGPD (datos de categoría especial) junto con la DPIA y los niveles del ENS: el más preciso legalmente. En el script bash, otra vez gemma4 fue el único con gestión de estados, es decir, no reenvía la alerta hasta que el sistema se recupera, evitando una tormenta de correos. En SEO ganó glm-4.7-flash: keyword en primera posición e intención clara, mientras que gemma4 contó los caracteres pero se fue de tema. Y en FastAPI, qwen3.6-35b entregó una arquitectura async completa y código listo para producción, aunque tardó unos tres minutos (lento, 25B en IQ4).
14. Veredicto del torneo
Ganador general claro: gemma4-26b, que se llevó 3 de las 4 pruebas directas. El más preciso en lo legal, el más fino en lo técnico y el más persuasivo en redacción. glm-4.7-flash ganó en SEO, conciso y con la keyword bien colocada, aunque con menos profundidad técnica. Y mistral-small3.2 fue exhaustivo y estructurado, pero el más lento (dense de 24B, 21 t/s) y a veces verboso.
La moraleja conecta con todo lo anterior: arquitectura por encima de tamaño. Un MoE con solo 3,8B activos le gana a un dense de 24B, y encima va cuatro veces más rápido. La arquitectura y la cuantización pesan más que el tamaño bruto.
15. Hallazgos no obvios
Cinco cosas que aprendí y que no esperaba del todo: una, la arquitectura gana al tamaño. Dos, la cuantización inteligente (IQ4_XS, MXFP4) mete un 26B en 16 GB sin offload. Tres, el bus manda: USB4 penaliza el offload brutalmente, y no era la CPU. Cuatro, los modelos heredan los vicios de su origen: gpt-oss llega a alucinar el «sandbox» de ChatGPT. Y cinco, verifica siempre las IAs: ChatGPT me juró que DeepSeek no era MoE. Falso de toda falsedad.
16. La IA alucina. Verifica siempre.
Esta es, para mí, la diapositiva más importante de toda la charla, y os la cuento con dos casos reales que me pasaron preparándola.
Caso 1, DeepSeek. Le pregunté a ChatGPT si DeepSeek usaba MoE. Me juró tres veces que no, que era «solo eficiencia organizativa». El paper oficial (arXiv 2412.19437) dice lo contrario: DeepSeek-V3 es MoE, 671B totales con 37B activos, con arquitectura DeepSeekMoE propia. Categóricamente falso, verificado con la fuente.
Caso 2, análisis de logs. Un modelo local me analizó los logs del sistema y me señaló un dominio sospechoso, gmail.ya.ru (Yandex), con «intentos de autenticación fallidos». Fui a los logs reales. No existía. Cogió un fallo de DNS real y trivial de Signal y le montó un disfraz alarmante encima. Esta es la alucinación peligrosa: no la que dice tonterías evidentes, sino la que parte de un hecho real y lo adorna con detalles falsos verosímiles. Si eso acaba en un informe a un cliente, quedas retratado, así de claro.
Cuando él me planteó entrar en 
Al igual que sucedió 
