Por qué la soberanía de datos importa para la IA empresarial
Las cifras hablan por sí solas
de los principales proveedores de LLM de EE. UU. entrenan con datos de usuarios por defecto
King et al., 2025de los CIO europeos planean aumentar su dependencia de proveedores de IA locales
Gartner, 2025oportunidad anual de IA soberana en Europa para 2030
McKinseyEl problema: sus datos se utilizan para entrenar modelos de IA
Cada vez que un empleado pega una cláusula de contrato en ChatGPT, carga un historial médico en un asistente de IA en la nube o le pide a un LLM que resuma un memorando del consejo de administración, esos datos entran en un flujo que la organización no controla. La pregunta ya no es si los proveedores de IA utilizan sus datos, sino cuánto, durante cuánto tiempo y con qué consecuencias.
Un estudio fundamental de King et al. (2025), publicado bajo el título «User Privacy and Large Language Models», examinó las prácticas de privacidad de seis proveedores dominantes de LLM: OpenAI, Google, Anthropic, Meta, Mistral y Cohere. Las conclusiones son contundentes. Los seis entrenan con los datos de los chats de los usuarios de forma predeterminada. Los usuarios deben descubrir activamente y activar los mecanismos de exclusión voluntaria, que están enterrados en páginas de configuración, descritos en un lenguaje ambiguo o sujetos a cambios sin previo aviso.
La situación en cuanto a la retención de datos es igualmente preocupante. Varios proveedores conservan los datos de las conversaciones indefinidamente, sin caducidad automática ni calendario de eliminación. Incluso cuando los plazos de retención están documentados, las políticas rara vez especifican si los datos retenidos ya han sido incorporados a los pesos del modelo, un proceso que, a todos los efectos prácticos, es irreversible.
King et al. descubrieron que las categorías especiales de datos —información sanitaria, identificadores biométricos, datos financieros— revelados durante las conversaciones no quedan excluidos de los flujos de entrenamiento. No existe ningún filtro basado en el contenido que intercepte un diagnóstico médico o un número de seguridad social antes de que llegue al corpus de entrenamiento. Los usuarios son el filtro, y nadie se lo comunica en términos claros.
Quizás lo más inquietante es que cuatro de los seis proveedores incluyen datos de menores en sus conjuntos de entrenamiento. A pesar de las verificaciones de edad y las restricciones en las condiciones de servicio, la realidad técnica es que ningún mecanismo sólido impide que las conversaciones de menores entren en el flujo de entrenamiento. Las implicaciones normativas en virtud de las protecciones específicas del RGPD para menores (artículo 8) y de la Ley de Protección de la Privacidad en Línea de los Niños de Estados Unidos (COPPA) son significativas y están en gran medida sin abordar.
El estudio también reveló lagunas sistemáticas en la transparencia de las políticas de privacidad. La información crítica —qué datos se recopilan, cómo se utilizan, con quién se comparten y durante cuánto tiempo se conservan— se omite con frecuencia o se describe en términos tan amplios que carecen de significado. La política de un proveedor se otorga a sí mismo el derecho de utilizar el «contenido» de «todos los productos y servicios» para mejorar el modelo, borrando la frontera entre una conversación de chat y los datos de productos completamente ajenos.
Los datos de clientes procedentes de productos complementarios también se incorporan a los flujos de entrenamiento. Si utiliza el servicio de correo electrónico, el almacenamiento en la nube o la suite de productividad de un proveedor junto con su oferta de IA, la frontera entre esos productos puede ser más difusa de lo que usted supone. Las cláusulas de uso de datos entre productos son habituales y rara vez se destacan durante el proceso de incorporación.
La conclusión es clara: cuando utiliza un LLM alojado en la nube, no es solo un cliente. Es un contribuidor de datos al modelo de otra persona, y tiene un control casi nulo sobre cómo se utiliza, almacena o comparte esa contribución.
El marco regulatorio
Los reguladores europeos han respondido al problema de la soberanía de los datos en la IA con tres marcos normativos interrelacionados. En conjunto, crean obligaciones que resultan difíciles —y en algunos casos imposibles— de cumplir cuando se depende de proveedores de LLM alojados en Estados Unidos.
Reglamento Europeo de IA (2024)
El Reglamento Europeo de IA establece un sistema de clasificación basado en el riesgo para los despliegues de IA. Los sistemas que procesan datos personales para tomar decisiones que afectan a personas físicas —herramientas de selección de personal, evaluación crediticia, diagnóstico médico— se encuadran en la categoría de alto riesgo conforme al artículo 6. Los sistemas de alto riesgo están sujetos a requisitos obligatorios: documentación técnica, evaluaciones de conformidad, supervisión poscomercialización y obligaciones de transparencia según el artículo 13.
Para las organizaciones que utilizan LLM alojados en la nube, el problema es estructural. No es posible elaborar la documentación técnica exigida por el artículo 9 (gestión de riesgos) ni por el artículo 10 (gobernanza de datos) cuando la arquitectura del modelo, los datos de entrenamiento y la lógica de toma de decisiones son propietarios. Se está desplegando un sistema que no puede describirse plenamente, en un entorno regulatorio que exige una descripción completa.
El artículo 52 impone obligaciones de transparencia a todos los sistemas de IA que interactúen con personas físicas. Los usuarios deben ser informados de que interactúan con una IA, y el responsable del despliegue debe ser capaz de explicar qué hace el sistema y cómo. Con una API de caja negra, «cómo» es una pregunta que no puede responderse.
RGPD
El Reglamento General de Protección de Datos genera una tensión fundamental con el entrenamiento de LLM en la nube. El artículo 17 otorga a los interesados el derecho de supresión, pero una vez que los datos personales han sido incorporados a los pesos del modelo mediante el entrenamiento, no pueden eliminarse de forma selectiva. Esto crea una brecha de cumplimiento que ninguna formulación jurídica puede subsanar.
La limitación de la finalidad (artículo 5) exige que los datos recopilados para un fin no se reutilicen sin una base jurídica compatible. Cuando un empleado utiliza un LLM en la nube para redactar un correo electrónico, la finalidad es la redacción del correo, no el entrenamiento del modelo. Sin embargo, las condiciones del proveedor redefinen esa interacción como una contribución al entrenamiento, llevando la limitación de la finalidad más allá de lo reconocible.
Las organizaciones deben identificar una base jurídica para el tratamiento conforme al artículo 6, y para los sistemas de IA que traten datos personales a gran escala, es obligatoria una Evaluación de Impacto relativa a la Protección de Datos (EIPD) conforme al artículo 35. Completar una EIPD para un sistema cuyos aspectos internos no pueden inspeccionarse es un ejercicio de suposiciones.
Directiva NIS2
La Directiva NIS2, aplicable a entidades esenciales e importantes de toda la UE, añade una tercera capa. Las organizaciones que operan infraestructuras críticas —energía, transporte, salud, finanzas— que incorporan la IA a sus operaciones se enfrentan a requisitos de seguridad reforzados: notificación de incidentes en un plazo de 24 horas, gestión de riesgos de la cadena de suministro y responsabilidad a nivel de consejo de administración en materia de ciberseguridad.
Cuando la inferencia de IA se realiza a través de la API de un proveedor estadounidense, ese proveedor se convierte en un eslabón crítico de su cadena de suministro. Su interrupción es su interrupción. Su brecha de seguridad es su brecha de seguridad. La NIS2 le hace responsable de los riesgos en sistemas que usted no controla.
La brecha de cumplimiento no es teórica. Es estructural, y crece con cada nueva regulación.
Residencia de datos no es soberanía de datos
| Aspecto | Residencia de datos | Soberanía de datos | Control real |
|---|---|---|---|
| Definición | Los datos se almacenan físicamente en un país concreto | Los datos están sujetos a una jurisdicción legal específica | Todo el procesamiento, metadatos y copias de seguridad bajo su jurisdicción |
| Protección legal | La ley del país anfitrión se aplica al almacenamiento, pero el proveedor puede estar sujeto a legislación extranjera (p. ej. CLOUD Act de EE. UU.) | Ningún gobierno extranjero puede exigir acceso a los datos | Ningún gobierno extranjero puede exigir acceso y ningún tercero procesa sus datos |
| Entrenamiento del modelo | El proveedor puede seguir entrenando con sus datos | El proveedor no puede entrenar con sus datos sin consentimiento | Sus datos nunca salen de su infraestructura |
| Ejemplo | ChatGPT con centro de datos en la UE | Proveedor cloud de la UE con DPA conforme al RGPD | LLM open-source auto-alojado en su propio clúster |
La oportunidad de la IA soberana
El giro hacia la IA soberana no es solo un ejercicio de cumplimiento normativo: es una oportunidad económica de proporciones históricas. Según el análisis de McKinsey, la infraestructura de IA soberana podría desbloquear 480.000 millones de euros en valor anual en la UE de aquí a 2030, impulsada por organizaciones que incorporan las capacidades de IA internamente en lugar de arrendarlas a proveedores extranjeros.
El apetito empresarial ya es medible. Según la Encuesta de CIO y Directivos Tecnológicos 2025 de Gartner, el 61 % de los CIO de Europa Occidental están aumentando la inversión en infraestructura de IA local, y para 2027, el 33 % de las empresas europeas ejecutarán la IA en plataformas localizadas, frente al escaso 5 % actual. Eso supone un incremento de seis veces en tres años, que representa una de las transiciones de infraestructura más rápidas en la historia de las TI empresariales.
Los sectores que lideran este cambio son los que más tienen que perder con la exposición de datos: organizaciones del sector público que gestionan datos de ciudadanos, proveedores de atención sanitaria sujetos a la confidencialidad del paciente, entidades financieras sometidas a auditorías regulatorias y contratistas de defensa que operan bajo restricciones de seguridad nacional. Para estos sectores, la soberanía no es una preferencia: es una condición previa para la adopción de la IA.
La iniciativa EuroStack —el programa estratégico de la UE para construir infraestructura digital soberana— señala un compromiso político al más alto nivel, dirigiendo la financiación hacia infraestructura cloud europea, modelos de IA de código abierto y capacidad de cómputo soberana. No se trata de un programa de investigación, sino de política industrial diseñada para reducir la dependencia de los grandes proveedores de nube estadounidenses en las cargas de trabajo de IA.
Los vientos regulatorios de cola son inequívocos. El Reglamento Europeo de IA, el RGPD y la NIS2 crean en conjunto un entorno en el que el despliegue soberano no solo es deseable, sino que resulta cada vez más obligatorio. Las organizaciones que actúen con anticipación incorporarán el cumplimiento normativo a su arquitectura desde el primer día. Las que se demoren se enfrentarán a costes de adaptación, exposición a auditorías y desventaja competitiva a medida que las regulaciones se endurezcan.
La ventana de la ventaja del pionero está abierta ahora. Cuando entre en plena vigor la aplicación del Reglamento Europeo de IA, las organizaciones que ya hayan desarrollado capacidad de IA soberana estarán desplegando mientras sus competidores aún están migrando.
Las organizaciones que traten la soberanía como una capacidad —un activo que poseen y controlan— descubrirán que el cumplimiento normativo, el rendimiento y la eficiencia en costes se alinean en lugar de entrar en conflicto.
¿Cómo es una pila de IA soberana?
Un despliegue de IA soberana no significa construir todo desde cero. Significa ensamblar componentes de código abierto contrastados en una arquitectura que usted posee y controla completamente.
Los modelos de código abierto han alcanzado la paridad con las alternativas propietarias. Las familias de modelos Llama, Mistral y Qwen ofrecen un rendimiento comparable al de GPT-4 y Claude en los benchmarks que importan para los casos de uso empresarial: resumen, clasificación, generación de código y extracción estructurada. Dado que estos modelos son de pesos abiertos, sus arquitecturas y la documentación de entrenamiento pueden auditarse de forma independiente con independencia de su origen. Muchos utilizan arquitecturas de Mezcla de Expertos que ofrecen rendimiento de vanguardia a una fracción del coste computacional. Ya no hay que sacrificar la capacidad en aras de la soberanía.
La capa de inferencia se ejecuta sobre infraestructura nativa de Kubernetes. Los servidores de modelos en contenedores —como llama.cpp, un motor de inferencia C++ de alto rendimiento— proporcionan despliegues escalables y reproducibles que pueden versionarse, revertirse y auditarse como cualquier otra carga de trabajo. Cada cambio de configuración queda registrado en un Helm chart. Cada despliegue es declarativo y reproducible.
Las opciones de infraestructura permanecen bajo jurisdicción europea. El metal desnudo en las instalaciones propias ofrece el máximo control para cargas de trabajo clasificadas o altamente reguladas. Los proveedores de nube con sede en la UE —OVHcloud, Hetzner, Scaleway, entre otros— ofrecen máquinas virtuales equipadas con GPU bajo legislación europea, sin el alcance jurisdiccional de la Ley CLOUD estadounidense. Usted elige el nivel de control adecuado a su perfil de riesgo.
El modelo operativo cambia de forma fundamental. Cada solicitud de inferencia queda registrada localmente. Cada versión del modelo está trazada. Cada acceso es auditable. No hay ninguna llamada opaca a una API en un centro de datos extranjero, solo una solicitud a su propia infraestructura, gobernada por sus propias políticas, almacenada en sus propios registros.
Esta arquitectura elimina toda una categoría de sobrecarga jurídica. No se necesitan acuerdos de procesamiento de datos con terceros porque no hay terceros. No hay Cláusulas Contractuales Tipo que negociar. No hay Evaluaciones de Impacto de la Transferencia que realizar. No hay dependencia de decisiones de adecuación que pueden invalidarse de la noche a la mañana, como demostró el caso Schrems II.
La madurez operativa de esta pila ya no está en entredicho. Miles de organizaciones ya ejecutan Kubernetes en producción. Los LLM de código abierto están desplegados a gran escala por empresas de todos los sectores. La pieza que faltaba no era la tecnología, sino la integración. Una pila de IA soberana necesita a alguien que ensamble los componentes, pruebe las configuraciones y publique la automatización. Eso es lo que proporciona Prositronic.
Cómo resuelve esto Prositronic
Prositronic es una pila de IA soberana de código abierto y lista para producción que se corresponde directamente con los requisitos de cumplimiento que afrontan las organizaciones europeas. No es un concepto ni una hoja de ruta: es infraestructura desplegable.
El cumplimiento del RGPD es arquitectónico, no contractual. Los datos nunca abandonan su infraestructura. No hay procesador de terceros, no hay transferencia transfronteriza, no hay cláusula ambigua de intercambio de datos. Cuando un usuario interactúa con su IA, la conversación permanece en sus servidores, bajo su jurisdicción, sujeta a sus políticas de retención. El derecho de supresión es una operación de base de datos, no una negociación jurídica.
La transparencia exigida por el Reglamento Europeo de IA está integrada. Prositronic despliega modelos de código abierto —Llama, Mistral, Qwen— cuyas arquitecturas, documentación de datos de entrenamiento y capacidades son auditables públicamente. No hay caja negra. Cuando un regulador pregunta cómo funciona su sistema de IA, puede señalar la ficha del modelo, el código fuente y la configuración del despliegue. Los artículos 9, 10 y 13 se convierten en ejercicios de documentación, no en desafíos de ingeniería inversa.
El riesgo en la cadena de suministro de NIS2 queda eliminado. La inferencia autoalojada significa que no hay dependencia del tiempo de actividad, la postura de seguridad ni los cambios de política de un proveedor estadounidense. La disponibilidad de su IA es su responsabilidad, y eso es exactamente lo que exige la NIS2. Ningún SLA de terceros se interpone entre usted y sus obligaciones.
El modelo de despliegue es nativo de Kubernetes. Prositronic se ejecuta en cualquier clúster de Kubernetes: metal desnudo en las instalaciones propias, máquinas virtuales en la nube de la UE o configuraciones híbridas. Los Helm charts y la automatización con Ansible hacen que un despliegue en producción lleve semanas, no trimestres. La infraestructura como código garantiza que cada entorno sea reproducible y auditable.
El soporte multi-modelo le permite elegir el modelo adecuado para cada caso de uso. Un modelo ligero de 8.000 millones de parámetros para el chat interno. Un modelo de 70.000 millones de parámetros para el análisis de documentos complejos. Un modelo especializado en código para las herramientas de desarrollo. Consulte los perfiles de hardware disponibles para orientación sobre el dimensionamiento de GPU. Todo ejecutándose en la misma infraestructura, gestionado a través de la misma interfaz, gobernado por las mismas políticas.
El coste total de propiedad evoluciona a su favor a medida que aumenta el uso. No hay tarifas de API por token, no hay sorpresas en la facturación por uso, no hay bloqueo de proveedor. Invierte en infraestructura que posee, ejecutando modelos que controla, con cada mejora de eficiencia revertiendo en su organización en lugar de en un proveedor externo.
Obtenga la guía regulatoria completa
Descargue el análisis completo de 20 páginas con un estudio regulatorio en profundidad, lista de verificación de implementación y marco de evaluación de riesgos.