Soberanía de Datos en IA: Por Qué las Industrias Reguladas No Pueden Usar Herramientas de Preparación de Datos en la Nube

La soberanía de datos ha pasado de ser una preocupación gubernamental a un requisito empresarial mainstream. En 2026, es una barrera práctica para la adopción de IA para un número creciente de organizaciones reguladas — no porque carezcan de la capacidad técnica para usar herramientas en la nube, sino porque usarlas las pondría en violación de obligaciones legales, regulatorias o contractuales.

Este artículo explica qué significa realmente la soberanía de datos en términos operacionales, cómo difiere de la residencia de datos, por qué las herramientas de preparación de datos en la nube violan los requisitos de soberanía por diseño, y qué debe significar "on-premise" para satisfacer genuinamente estos requisitos.

---

Qué Significa la Soberanía de Datos — y Qué No

Soberanía de datos se refiere al principio de que los datos están sujetos a las leyes, regulaciones y marcos de gobernanza de la jurisdicción en la que fueron recopilados o en la que reside el sujeto. Más ampliamente, ha llegado a significar el derecho y la capacidad de una organización de controlar qué sucede con sus datos — incluyendo las jurisdicciones legales que pueden obligar el acceso.

Residencia de datos es un concepto más estrecho: el requisito de que los datos se almacenen físicamente dentro de una ubicación geográfica particular (un país, una región o una instalación específica).

Estos frecuentemente se confunden, pero son requisitos diferentes con implicaciones diferentes:

• La residencia de datos puede satisfacerse eligiendo el centro de datos EU de un proveedor de nube
• La soberanía de datos no puede, porque los datos almacenados en un centro de datos EU propiedad de una empresa estadounidense siguen sujetos a la ley de EE.UU. (el CLOUD Act permite al gobierno de EE.UU. obligar a empresas estadounidenses a producir datos almacenados en el extranjero)

Una empresa europea que almacena datos de entrenamiento en AWS Frankfurt satisface la residencia de datos (los datos están en la UE). No satisface la soberanía de datos si no puede garantizar que las autoridades estadounidenses no puedan obligar a AWS a producir esos datos.

---

Cómo las Herramientas en la Nube Violan la Soberanía por Diseño

Las herramientas de preparación de datos en la nube — plataformas SaaS de anotación, APIs de OCR en la nube, endpoints de LLM alojados para aumento — violan la soberanía de datos a través de varios mecanismos:

Exposición Legal del Proveedor

Cualquier proveedor SaaS con sede en EE.UU. está sujeto al CLOUD Act (2018), que permite a las fuerzas del orden de EE.UU. obligar a empresas estadounidenses a proporcionar comunicaciones almacenadas y datos sin importar dónde estén físicamente ubicados. La Sección 702 de FISA permite a las agencias de inteligencia acceso similar. Una empresa europea usando una plataforma SaaS estadounidense para preparación de datos no tiene forma de garantizar que sus datos de entrenamiento no sean accesibles a las autoridades estadounidenses — y el proveedor puede tener prohibición legal de revelar que se hizo una solicitud de acceso.

La guía del European Data Protection Board tras Schrems II (C-311/18, 2020) estableció que la ley de vigilancia de EE.UU. crea incompatibilidad con los requisitos de adecuación de la UE. Las autoridades supervisoras en Francia (CNIL), Austria y otros estados miembros han emitido decisiones de aplicación contra herramientas específicas sobre esta base.

Cadenas de Subprocesadores

Las plataformas SaaS en la nube no operan en aislamiento. Usan subprocesadores: proveedores de CDN para entrega de activos, servicios de logging para monitoreo operacional, plataformas de soporte para servicio al cliente, plataformas de analítica para telemetría del producto. Cada subprocesador representa una organización adicional con acceso potencial a los datos procesados en la plataforma.

La cadena controlador-procesador del GDPR (Artículos 28-29) requiere que los procesadores de datos solo contraten subprocesadores con autorización previa por escrito del controlador, y que los subprocesadores estén sujetos a obligaciones de protección de datos equivalentes. En la práctica, las listas de subprocesadores de la mayoría de las plataformas SaaS son extensas, globales y difíciles de auditar.

Opacidad del Procesamiento

Cuando envías datos a una API en la nube, no sabes exactamente qué pasa con ellos. Pueden registrarse para aseguramiento de calidad. Pueden usarse para entrenar los propios modelos del proveedor (revisa los términos cuidadosamente). Pueden cachearse en ubicaciones geográficas que no puedes especificar. Los términos del proveedor pueden cambiar. Incluso con garantías contractuales, la realidad técnica es opaca.

La soberanía requiere no solo acuerdos legales sino control operacional. No tienes control operacional sobre datos procesados por un tercero.

---

Marcos Regulatorios que Impulsan Requisitos de Soberanía

GDPR (UE/EEA)

Los Artículos 44-49 restringen las transferencias internacionales de datos personales. La transferencia a países sin una decisión de adecuación de la UE requiere uno de los mecanismos del Artículo 46 (Cláusulas Contractuales Estándar, Normas Corporativas Vinculantes) más una Evaluación de Impacto de Transferencia. La TIA debe evaluar si el marco legal del país de destino proporciona protección efectiva — una prueba que EE.UU., India, China y muchos otros actualmente no pasan para categorías de datos sensibles.

HIPAA (Salud en EE.UU.)

El marco de entidades cubiertas de HIPAA significa que cualquier PHI procesada por un asociado de negocio requiere un Acuerdo de Asociado de Negocio, y la entidad cubierta sigue siendo responsable de las prácticas de seguridad del asociado. El estándar de "mínimo necesario" aplica a las divulgaciones. Para muchas organizaciones de salud, la combinación de estos requisitos con la dificultad de auditar la seguridad de plataformas en la nube crea una prohibición práctica de usar herramientas en la nube para datos de entrenamiento que contienen PHI.

PPIA (Pakistán — Ley de Protección de Datos Personales)

El marco de protección de datos de Pakistán, como otros en el Sur Global, restringe la transferencia de datos personales fuera de las fronteras nacionales. Para empresas que operan en Pakistán o procesan datos de ciudadanos pakistaníes, enviar datos a una plataforma en la nube fuera de Pakistán desencadena requisitos de transferencia transfronteriza. Una empresa constructora que construye sistemas de IA para operaciones pakistaníes describió un proceso de aprobación de datos que toma hasta un año para cualquier uso externo de datos — impulsado por la necesidad de obtener autorización formal para cada transferencia externa bajo el marco PPIA.

La implicación: mantener el procesamiento enteramente dentro de la infraestructura de la organización elimina la transferencia, elimina el requisito de aprobación y elimina el retraso de un año.

Ley de Privacidad de Australia / Esquema de Brechas de Datos Notificables

La Ley de Privacidad de Australia requiere que las entidades tomen pasos razonables para asegurar que la información personal esté protegida contra uso indebido, interferencia, pérdida y acceso no autorizado. La Australian Prudential Regulation Authority (APRA) impone requisitos adicionales a las instituciones financieras, incluyendo requisitos para gestión y gobernanza de datos. Algunos sectores australianos tienen requisitos formales de onshoring de datos.

Requisitos Específicos por Sector

Más allá de la ley general de protección de datos, sectores específicos imponen restricciones adicionales:

• Defensa y contratistas gubernamentales: La información clasificada y sensible típicamente no puede procesarse en infraestructura de nube operada comercialmente, sin importar la ubicación geográfica
• Servicios financieros: Los reguladores en múltiples jurisdicciones requieren que las instituciones financieras mantengan control sobre sus datos y procesamiento de datos, con provisiones de derecho de auditoría difíciles de cumplir con proveedores de nube
• Legal: El privilegio abogado-cliente y el privilegio profesional legal crean prohibiciones prácticas de procesar documentos privilegiados a través de servicios en la nube
• Infraestructura crítica: Los datos operacionales de redes eléctricas, tratamiento de agua, sistemas de transporte frecuentemente están sujetos a requisitos de manejo de datos específicos del sector

---

Qué Debe Significar "On-Premise" para Realmente Satisfacer la Soberanía

"On-premise" se usa en marketing de proveedores para significar casi cualquier cosa desde "auto-hospedado en AWS" hasta "corre en un laptop sin internet." Para propósitos de soberanía de datos, solo un extremo de ese espectro satisface el requisito.

Para satisfacer genuinamente la soberanía de datos:

1. Hardware bajo tu control físico Los servidores, estaciones de trabajo o dispositivos que procesan los datos deben ser propiedad o estar operados por tu organización, en una instalación que controlas, no en un centro de datos compartido o instalación de un proveedor de nube. El espacio alquilado en un centro de datos en tu jurisdicción puede satisfacer el requisito geográfico, pero si la instalación es operada por un tercero con acceso potencial a tu hardware, no eres el único soberano.

2. Sin conexiones de red salientes en tiempo de ejecución Si el software puede hacer conexiones salientes, puede exfiltrar datos — intencionalmente (por un componente comprometido) o no intencionalmente (telemetría, analítica, verificaciones de actualización). El software en un entorno crítico de soberanía debe no tener conectividad de red, o debe operar con políticas de conexión saliente documentadas y auditadas.

3. Sin acceso del proveedor a datos procesados El soporte, mantenimiento y solución de problemas no debe requerir que el proveedor acceda a tus datos o sistemas. Las licencias de software no deben requerir verificaciones regulares con un servidor del proveedor. Los modelos de licenciamiento offline satisfacen esto; el SaaS por suscripción no.

4. Hosting local de modelos para componentes de IA Los componentes de IA del pipeline — OCR, NER, aumento con LLM — deben usar modelos que estén alojados localmente con pesos en tu almacenamiento, no accedidos vía endpoints de inferencia en la nube. Una herramienta que usa orquestación "on-premise" pero llama a APIs de modelos en la nube para el trabajo pesado no es on-premise en ningún sentido relevante para la soberanía.

---

El Problema del Ciclo de Aprobación — y la Única Solución Real

Para empresas reguladas que actualmente usan herramientas en la nube, agregar un nuevo proveedor SaaS para preparación de datos de IA típicamente requiere:

• Revisión legal de términos del proveedor y DPA
• Evaluación de Impacto en la Protección de Datos (si aplica el Artículo 35 del GDPR)
• Consulta al comité de empresa (en Alemania, Países Bajos y otras jurisdicciones con requisitos de co-determinación)
• Aprobación del DPO
• Revisión de seguridad de la infraestructura del proveedor
• Negociación contractual de BAA (HIPAA) o SCCs (GDPR)
• Aprobación ejecutiva para excepciones de clasificación de datos

Este proceso rutinariamente toma de seis a doce meses. El ciclo de aprobación de un año descrito por empresas reguladas no es inusual — refleja una carga de cumplimiento genuina que no puede acortarse.

La única forma de eliminar este ciclo para herramientas de preparación de datos es eliminar la relación con el proveedor. Una herramienta on-premise instalada en tu hardware, sin egreso de datos, no requiere nada de lo anterior. Tus datos nunca salen de tu control, por lo que tu equipo de cumplimiento no tiene nada que aprobar.

---

Cómo Ertas Data Suite Aborda los Requisitos de Soberanía

Ertas Data Suite se instala como una aplicación de escritorio nativa en hardware que controlas. No hace conexiones de red salientes en tiempo de ejecución. Todo el parseo de documentos, OCR, detección de PII/PHI, anotación y aumento con LLM corren localmente. Los pesos de los modelos se incluyen con la aplicación o se cargan desde almacenamiento local. La exportación escribe a rutas de archivos locales.

No hay componente de nube del proveedor. No hay relación SaaS. No hay transferencia de datos que revisar, no hay DPA que negociar, no hay lista de subprocesadores que auditar.

Para empresas en sectores donde cada herramienta de datos de terceros requiere un año de revisión de cumplimiento, la decisión arquitectónica de mantener todo on-premise no es una preferencia técnica. Es el único camino operacional para construir sistemas de IA en un plazo razonable.

---

Lectura Relacionada

• On-Premise AI Data Preparation: The Compliance Guide for Regulated Industries — Guía completa de requisitos de GDPR, HIPAA, EU AI Act y soberanía de datos para IA empresarial.
• Air-Gapped Machine Learning: How to Build AI Data Pipelines Without Internet Access — Para entornos que requieren verdadero aislamiento de red, no solo despliegue on-premise.
• GDPR and AI Training Data: What European Enterprises Must Do Before They Fine-Tune — Obligaciones específicas del GDPR que impulsan los requisitos europeos de soberanía para pipelines de entrenamiento de IA.