Qué es soberanía digital

Como adelanté en el post sobre cloud-first, para mí la soberanía digital consiste en que podamos decidir sobre datos, infraestructura y modelos de IA, sin que un proveedor, una decisión pasada o la inercia del mercado lo hagan por nosotros.

No pretendo escribir un manifiesto anti-nube. Me interesa algo mucho más práctico: entender qué partes de nuestro stack controlamos realmente, cuáles hemos delegado y, sobre todo, si esa delegación tiene marcha atrás.

A menudo el debate sobre soberanía digital se centra en la jurisdicción de los datos, la regulación o la dependencia tecnológica entre países. Pero aquí quiero hablar de un aspecto más cercano al día a día de quienes desarrollamos software: la capacidad de revisar una decisión cuando las circunstancias cambian.

Me gusta pensar la soberanía digital como tres capas complementarias. Dos de ellas, datos e infraestructura, las conocemos de sobra desde siempre:

• Datos. Dónde se almacenan, quién puede acceder a ellos y si puedes exportarlos o eliminarlos sin depender de un tercero.

• Infraestructura. Quién ejecuta el software, con qué herramientas y cuánto costaría migrarlo a otro lugar.

Pero ahora, ante el auge de la IA generativa, hay una tercera capa:

• Cognición. Qué modelos de IA procesan tu información y hasta qué punto puedes cambiar de modelo, de proveedor o incluso ejecutarlo tú mismo. Puedes tener un VPS propio, ejecutar software libre y administrar tus propios servicios. Pero si cada documento, cada conversación y cada fragmento de código termina procesándose exclusivamente por un modelo cerrado, tu soberanía sigue siendo parcial.

En los artículos anteriores (presentación y cloud-first) el software libre, los formatos abiertos y el self-hosting constituyen la base.

Pero autoalojar un servicio no garantiza soberanía si, por ejemplo, tu servicio requiere una API de terceros que no controlas y que te costaría cambiar si mañana dejara de estar disponible en tu país o cambiara de precio.

Como comentaba al hablar del principio RPS, las decisiones que preservan la capacidad de cambiar son puentes; las que dificultan abandonar una tecnología son anclas. El software libre y el self-hosting suelen construir puentes en la infraestructura. Los modelos de pesos abiertos pueden hacer exactamente lo mismo en la capa cognitiva.

Soberanía cognitiva

La llegada de la IA añade una nueva pregunta: ¿quién ejecuta realmente el modelo que procesa tu información?

Los modelos cerrados como GPT, Claude o Gemini ofrecen capacidades muy potentes, pero el usuario depende completamente del proveedor: no es posible ejecutar esos mismos modelos por cuenta propia ni trasladarlos a otro operador independiente. Los modelos de pesos abiertos funcionan de otra manera. Si trabajas con familias como Qwen, Gemma, DeepSeek o Kimi, puedes utilizar la API del desarrollador original, recurrir a distintos proveedores de inferencia o, si tu hardware lo permite, ejecutar exactamente el mismo modelo en tu propia infraestructura. El modelo permanece; cambia quién lo ejecuta.

Elegir un modelo de pesos abiertos mantiene abiertas más opciones para el futuro: hoy puedes consumir una API externa y mañana decidir mover esa misma carga a un servidor propio sin tener que rehacer toda tu integración.

Un pequeño inciso: algunas licencias de modelos de pesos abiertos incluyen restricciones comerciales, pero suelen apuntar a uso a escala (un SaaS, una empresa con cientos de usuarios) más que al uso personal. Aun así, conviene revisar cada licencia: no todas siguen ese patrón.

La soberanía cognitiva no exige montar un servidor con varias GPUs desde el primer día. Existe un espectro razonable de decisiones:

1. API de un modelo cerrado.
2. API de un modelo de pesos abiertos.
3. Inferencia local (modelo de pesos abiertos).

El punto uno nos ancla a un modelo concreto que no controlamos. El dos mantiene el mismo modelo, pero permite cambiar de proveedor o llevarlo a casa. El tres ofrece el máximo control, a cambio de más coste operativo.

Cuando evaluamos una tecnología solemos fijarnos en el coste de entrada: cuánto tardaremos en ponerla en marcha, cuánto cuesta al mes o qué curva de aprendizaje tiene. Sin embargo, pocas veces pensamos en el coste de abandonarla.

Migrar una base de datos, sustituir un proveedor de correo o reemplazar un modelo de IA puede requerir semanas o meses de trabajo. Cuanto mayor sea ese coste, menor será nuestra capacidad real para decidir en el futuro.

En cualquier caso, siempre podemos optar por soluciones híbridas, como por ejemplo usar un modelo local para la mayoría de las peticiones y reservar los modelos frontera para casos puntuales donde se necesite potencia extra.

Mi experiencia con la inferencia local

Mi experiencia en inferencia local es limitada, pero me ha servido para calibrar expectativas. Con Gemma 4 (4B) y SmolLM3 (3B) sobre CPU vía Ollama, los modelos pequeños son usables, aunque lentos; una GPU cambia por completo la experiencia. No hace falta hardware potente para empezar: sin GPU ya puedes experimentar y construir herramientas personales; con una de gama media muchos modelos abiertos bastan para desarrollo, redacción o automatización.

Para tareas más exigentes (especialmente flujos agénticos) he optado por un punto intermedio del espectro: modelos de pesos abiertos consumidos vía API, concretamente glm-4.7-flash y deepseek-v4-flash a través de Ollama Cloud. Son modelos que, en principio, podría ejecutar en hardware propio tipo Mac Mini si tuviera el equipo. Hoy no lo tengo, así que uso la API: sigo delegando la inferencia a un tercero. El puente no es la soberanía del uso actual, sino la puerta de salida: si mañana tengo acceso a una máquina con suficiente memoria unificada (o con una GPU de 24 GB de VRAM), puedo descargar los mismos pesos y migrar la inferencia casi sin tocar la integración. Esa es la diferencia entre un puente y una ancla.

Cuándo tiene sentido un modelo cerrado

La soberanía digital no implica rechazar los modelos cerrados. Siguen siendo la mejor opción cuando ofrecen capacidades que todavía no existen en el ecosistema de pesos abiertos, cuando el coste de equivocarse es elevado o cuando se trata de un uso puntual.

El problema no es utilizarlos, sino que se conviertan en la opción por defecto sin haber evaluado si una alternativa más abierta sería suficiente. La misma crítica que puede hacerse al cloud-first puede hacerse también al LLM-first: delegar por costumbre en lugar de hacerlo por necesidad.

No se trata de autoalojarlo todo, ni de evitar cualquier servicio comercial, sino de conservar la capacidad de elegir. El software libre, el self-hosting y los modelos de pesos abiertos reducen el coste de cambiar; los modelos cerrados y la nube grande seguirán resolviendo muchos problemas mejor que una infraestructura doméstica. La cuestión no es prohibirse usarlos, sino evitar que la comodidad inicial termine convirtiéndose en una dependencia permanente.

Si te ha gustado el post (o discrepas en algo), no dudes en comentar.