Puntos clave
- La soberanía del dato en IA no es una sola cosa: hay tres arquitecturas distintas —on-premise, cloud soberano europeo e híbrida— con implicaciones muy diferentes de coste operativo, control y esfuerzo.
- El impulso no es ideológico, es regulatorio y contractual: RGPD, AI Act por fases y Data Act europeo restringen cómo y dónde se procesan determinados datos. El 70% de los directivos globales considera que necesita una plataforma soberana de datos e IA para seguir siendo competitivo.
- La tendencia técnica que lo hace viable es el auge de los small language models (SLM): modelos pequeños y especializados que corren en hardware asumible y rinden como un generalista grande en tareas acotadas.
- Nuestra recomendación pragmática: no despliegues on-premise por defecto. Clasifica tus datos primero. La mayoría de las empresas necesitan soberanía para una fracción de sus casos, no para todos.
La IA on-premise consiste en ejecutar modelos de lenguaje en infraestructura propia, sin que los datos salgan de tu entorno. Se diferencia del cloud soberano —servidor dedicado en territorio europeo— en que el on-premise no requiere conexión externa. Ambas responden a la misma exigencia: cumplir RGPD, AI Act y Data Act manteniendo el control sobre dónde se procesa el dato sensible.
Las tres arquitecturas, sin confusión
El término "soberanía del dato" se usa para tres cosas distintas. Distinguirlas es lo primero, porque el esfuerzo y el control cambian mucho:
1. On-premise puro. Los modelos corren en tu propio hardware, dentro de tu red. Los datos nunca salen del edificio y el sistema puede funcionar sin conexión a internet. Herramientas habituales: Ollama, vLLM, LM Studio. Control máximo, y también responsabilidad operativa máxima: actualizaciones, GPU, disponibilidad y seguridad son tuyas.
2. Cloud soberano europeo. El modelo se ejecuta en un servidor dedicado en territorio europeo (Fráncfort, Madrid, París) bajo garantías contractuales de no transferencia y residencia del dato. Hay conexión, pero el servidor es exclusivo. Menos control absoluto, mucho menos esfuerzo operativo.
3. Híbrida. El dato sensible se procesa en local o en cloud soberano; el resto va al mejor modelo disponible, sea cual sea. Requiere una capa de enrutado que clasifique cada petición. Es la arquitectura que más recomendamos, porque casi ninguna empresa necesita soberanía en el 100% de sus casos.
| Criterio | On-premise | Cloud soberano | Híbrida |
|---|---|---|---|
| El dato sale de tu red | No | Sí, a servidor dedicado UE | Según clasificación |
| Funciona sin internet | Sí | No | Parcialmente |
| Esfuerzo operativo | Alto | Bajo | Medio |
| Acceso a modelos punteros | Limitado a abiertos | Amplio | Completo |
| Tiempo de puesta en marcha | Semanas-meses | Días-semanas | Semanas |
| Complejidad de gobierno | Media | Baja | Alta (enrutado) |
Lo que NO es soberanía del dato: no es usar un proveedor estadounidense con una cláusula de residencia europea sin verificar la cadena de subencargados. Y no es autoalojar un modelo pequeño y seguir enviando los prompts sensibles a una API externa para "los casos difíciles". Eso es soberanía decorativa.
Por qué esto ha dejado de ser una discusión teórica
Tres marcos normativos convergen sobre la misma pregunta —dónde se procesa el dato— y ninguno es opcional:
- RGPD. Base legal para el tratamiento, minimización, y garantías para transferencias internacionales. Aplicable desde hace años y con criterio ya asentado.
- AI Act. Aplicación por fases desde 2025, con las obligaciones de transparencia del artículo 50 en vigor desde el 2 de agosto de 2026 y el calendario de alto riesgo desplazado por el Reglamento Ómnibus.
- Data Act europeo. Restringe cómo los datos generados en Europa pueden transferirse y procesarse fuera, e introduce obligaciones de portabilidad entre proveedores cloud.
A esto se suma un factor que rara vez aparece en los análisis regulatorios pero que decide muchos proyectos: los contratos con tus propios clientes. En sectores como legal, sanitario, financiero o industrial, es cada vez más frecuente que el cliente prohíba contractualmente que su información pase por un modelo de terceros. Eso convierte la soberanía en un requisito comercial, no en una preferencia técnica.
Datos clave del mercado
- El 70% de los ejecutivos globales cree que necesita una plataforma soberana de datos e IA para seguir siendo competitivo, según MIT Technology Review.
- La IA empresarial está virando hacia modelos especializados, soberanía del dato y confianza regulatoria, en lugar de hacia el modelo generalista más grande disponible. Entre las tendencias dominantes destacan el crecimiento de los small language models (SLM) y las arquitecturas de RAG soberano (La Ecuación Digital, 2026).
- Los modelos locales de referencia en 2026 incluyen Llama 3.3 70B (uso general), Qwen 2.5 72B (código y razonamiento), Mistral Large 2 (soberanía europea) y Gemma 2 27B (hardware limitado).
Nuestra lectura: la brecha de calidad entre el mejor modelo cerrado y el mejor modelo abierto se ha estrechado lo suficiente como para que, en tareas acotadas y bien definidas, la diferencia deje de ser el factor decisivo. Eso es lo que ha hecho viable el despliegue local, mucho más que cualquier cambio regulatorio.
Los small language models: lo que cambia la ecuación
Un small language model (SLM, modelo de lenguaje pequeño) es un modelo con un número de parámetros mucho menor que un generalista de frontera, entrenado o ajustado para un dominio o una tarea concreta. La clave no es que sea peor: es que en su tarea específica rinde de forma comparable con una fracción del hardware.
Esto importa porque cambia la viabilidad práctica del on-premise. Ejecutar un modelo de frontera en local exige una inversión de infraestructura que la mayoría de empresas medianas no va a hacer. Ejecutar un modelo de 7B a 30B parámetros, ajustado con LoRA para tu clasificación, tu extracción documental o tu asistente interno, es perfectamente asumible.
El patrón que funciona: modelo pequeño especializado + RAG soberano sobre tu conocimiento interno. El modelo aporta el comportamiento; la base vectorial, que vive en tu infraestructura, aporta el conocimiento. Es la misma lógica que explicamos en fine-tuning vs RAG vs context engineering, aplicada a un entorno donde el dato no puede salir.
Cuándo tiene sentido (y cuándo no)
Señales de que necesitas soberanía del dato:
- Tratas categorías especiales de datos personales: salud, datos biométricos, información judicial.
- Tus contratos con clientes prohíben que su información pase por modelos de terceros.
- Operas en un sector regulado con requisitos explícitos de residencia (financiero, sanitario, defensa, administración pública).
- Manejas secreto industrial o propiedad intelectual cuyo valor competitivo depende de que no se filtre.
- Necesitas funcionamiento sin conexión por el entorno físico: planta industrial, buque, instalación aislada.
- Tienes volumen alto y estable de inferencia, donde el coste variable por token deja de compensar frente a infraestructura propia.
Cuándo NO tiene sentido todavía:
- Cuando el caso de uso no toca dato sensible. Un asistente sobre documentación pública no necesita soberanía, necesita funcionar bien.
- Cuando no tienes equipo capaz de operar la infraestructura. Un modelo local mal mantenido, sin actualizaciones ni monitorización, es peor opción —también en seguridad— que un cloud soberano bien contratado.
- Cuando aún estás en fase de validación del caso. Valida en cloud, y migra después si el caso lo justifica. Es mucho más rápido y no compromete nada.
Esta última recomendación es la que más discusiones nos ahorra: valida primero, soberaniza después. Montar infraestructura para un caso que aún no sabes si funciona es la forma más cara de aprender que no funcionaba.
Casos de uso habituales
Caso 1 — Asistente documental en despacho profesional.
- Problema: consultas sobre expedientes de clientes, con información sujeta a secreto profesional que no puede salir del despacho.
- Solución: SLM desplegado en servidor local + RAG sobre el archivo documental, sin conexión externa para las consultas sobre expedientes.
- Stack: modelo abierto autoalojado + base vectorial local + control de acceso por usuario.
- Resultado: búsqueda semántica sobre el archivo sin que ningún dato salga de la red del despacho.
Caso 2 — Arquitectura híbrida con enrutado por clasificación.
- Problema: la empresa quiere aprovechar los mejores modelos disponibles pero tiene una fracción de casos con dato regulado.
- Solución: capa de enrutado que clasifica cada petición y decide destino: modelo local para dato sensible, modelo cloud para el resto, con registro de la decisión.
- Stack: clasificador + modelo local + API externa + trazabilidad de enrutado.
- Resultado: cumplimiento en lo que lo requiere, sin renunciar a la calidad en el resto.
Caso 3 — Extracción documental en planta industrial sin conexión estable.
- Problema: procesamiento de documentación en un entorno con conectividad intermitente donde una API externa no es fiable.
- Solución: modelo pequeño local que procesa en el borde y sincroniza resultados cuando hay conexión.
- Stack: SLM local + cola de sincronización + validación centralizada.
- Resultado: el proceso deja de depender de la conectividad.
Cómo implementarlo paso a paso
- Clasifica tus datos antes de elegir arquitectura. Qué es dato personal, qué es categoría especial, qué está sujeto a contrato con cliente y qué es público. Sin esta clasificación, cualquier decisión de arquitectura es arbitraria.
- Decide el nivel por caso de uso, no para toda la empresa. La soberanía se aplica donde hace falta. Aplicarla en bloque encarece y ralentiza todo sin beneficio proporcional.
- Valida el caso en cloud antes de invertir en infraestructura. Comprueba que el caso funciona y aporta valor. La migración a local después es mucho más barata que descubrir que el caso no servía.
- Elige el modelo por tarea, no por ranking general. Para clasificación y extracción, un modelo pequeño ajustado gana a un generalista grande en latencia y coste operativo, con calidad equivalente.
- Monta el RAG con la base vectorial dentro de tu perímetro. De poco sirve el modelo local si los embeddings de tus documentos confidenciales viven en un servicio externo.
- Resuelve la operativa antes del despliegue: monitorización, actualizaciones de modelo, plan de capacidad y respaldo. Un modelo local sin mantenimiento envejece mal y rápido.
- Documenta la decisión de arquitectura. Qué dato va dónde y por qué. Es lo que te pedirá una auditoría, y es lo que evita que el enrutado se degrade con el tiempo.
Errores comunes (y cómo evitarlos)
Error: desplegar on-premise por defecto "por seguridad". → La realidad: un modelo local mal operado —sin parches, sin monitorización, sin control de acceso— es menos seguro que un cloud soberano bien contratado. La soberanía es una decisión de gobierno del dato, no un talismán.
Error: modelo local pero base vectorial en un servicio externo. → La realidad: los embeddings de tus documentos confidenciales están en la nube. Es exactamente el problema que pretendías evitar, con un paso intermedio.
Error: confundir residencia de datos con soberanía. → La realidad: que el servidor esté en Fráncfort no basta si la cadena de subencargados o la jurisdicción del proveedor permiten el acceso. Revisa el contrato completo, no la ubicación del centro de datos.
Error: subestimar el coste operativo continuo. → La realidad: el esfuerzo no termina con el despliegue. Actualizaciones de modelo, gestión de capacidad, monitorización de calidad y seguridad son trabajo permanente. Sin equipo para asumirlo, el cloud soberano es mejor decisión.
Error: elegir el modelo abierto más grande que quepa en el hardware. → La realidad: para tareas acotadas, un modelo pequeño ajustado da mejor latencia y mejor coste operativo con calidad comparable. El tamaño no es la métrica.
Error: montar infraestructura antes de validar el caso. → La realidad: es la forma más cara de descubrir que el caso de uso no aportaba valor. Valida en cloud con datos anonimizados o sintéticos, y migra después.
Tiempos y esfuerzo realistas
- Clasificación de datos y decisión de arquitectura: 1-3 semanas. Es un trabajo de negocio y cumplimiento, no técnico, y condiciona todo lo demás.
- Despliegue en cloud soberano europeo: días o pocas semanas. Es la vía rápida y, para la mayoría de casos regulados, suficiente.
- Despliegue on-premise con SLM y RAG local: 6-12 semanas, incluyendo aprovisionamiento de hardware, despliegue del modelo, base vectorial y control de acceso.
- Arquitectura híbrida con enrutado por clasificación: 8-14 semanas, porque el clasificador de sensibilidad y su trazabilidad son la parte delicada del diseño.
- Dónde está el esfuerzo oculto: en la operación continua, no en el despliegue. Y en el aprovisionamiento de GPU, cuyos plazos han sido históricamente el cuello de botella menos anticipado.
Métricas que medir desde el día 1: porcentaje de peticiones que requieren realmente soberanía (suele sorprender lo bajo que es), latencia p95 local frente a cloud, calidad medida sobre tu dataset de evaluación en ambos entornos, disponibilidad del servicio local y coste operativo por tarea completada. Si el porcentaje del primer indicador es bajo, la arquitectura híbrida es casi siempre la respuesta correcta.
Preguntas frecuentes
¿Qué es la soberanía del dato aplicada a la IA?
Es el control efectivo sobre dónde y bajo qué jurisdicción se procesan los datos que consume un modelo de IA. Se materializa en tres arquitecturas: on-premise (el dato no sale de tu red), cloud soberano europeo (servidor dedicado en la UE con garantías contractuales) e híbrida (enrutado según sensibilidad del dato).
¿Cuándo conviene desplegar un modelo de IA on-premise?
Cuando tratas categorías especiales de datos personales, cuando tus contratos con clientes prohíben el uso de modelos de terceros, cuando operas en un sector con requisitos explícitos de residencia, o cuando necesitas funcionamiento sin conexión. Si el caso no toca dato sensible, el on-premise añade esfuerzo sin beneficio.
¿Qué modelos abiertos se usan para despliegue local en 2026?
Los de referencia son Llama 3.3 70B para uso general, Qwen 2.5 72B para código y razonamiento, Mistral Large 2 como opción de soberanía europea y Gemma 2 27B para hardware más limitado. Para tareas acotadas, modelos más pequeños ajustados con LoRA suelen ser mejor elección.
¿Qué es un small language model y por qué importa?
Es un modelo con muchos menos parámetros que un generalista de frontera, especializado en un dominio o tarea. Importa porque hace viable el despliegue local: en su tarea específica rinde de forma comparable a un modelo grande con una fracción de los requisitos de hardware.
¿Basta con que el servidor esté en Europa para cumplir el RGPD?
No necesariamente. La ubicación física es una condición, pero hay que revisar la cadena completa de subencargados, la jurisdicción a la que está sujeto el proveedor y las garantías contractuales de no transferencia. La residencia de datos y la soberanía no son sinónimos.
¿Cuál es la diferencia entre on-premise y cloud privado europeo?
On-premise significa que el modelo corre en tu propio hardware, dentro de tu red, sin necesidad de conexión externa. Cloud privado europeo significa servidor dedicado en territorio de la UE con conexión, bajo garantías contractuales. El primero da más control y exige más operativa; el segundo, al revés.
¿Se pierde calidad al usar modelos locales?
Depende de la tarea. En tareas acotadas y bien definidas —clasificación, extracción documental, asistentes sobre conocimiento propio— la diferencia con un modelo de frontera es pequeña o nula, especialmente con ajuste fino. En razonamiento complejo abierto, los modelos de frontera siguen por delante.
¿Puedo empezar en cloud y migrar a local después?
Sí, y es lo que recomendamos. Valida el caso en cloud con datos anonimizados o sintéticos, comprueba que aporta valor y migra a local si el dato real lo exige. Montar infraestructura antes de validar es la forma más cara de descubrir que el caso no funcionaba.
¿No sabes si tu caso necesita on-premise, cloud soberano o ninguno de los dos?
En Naxia empezamos por clasificar el dato, no por elegir infraestructura. Diseñamos arquitecturas híbridas con enrutado por sensibilidad, desplegamos modelos abiertos y RAG dentro de tu perímetro cuando hace falta, y decimos claramente cuándo el on-premise no compensa.
Si quieres saber qué porcentaje de tus casos requiere realmente soberanía del dato —normalmente es menor de lo que se supone— habla con nosotros. Sin compromiso y sin powerpoints de 40 páginas.
O si prefieres, explora primero nuestro proceso de implementación.