La soberanía de los datos depende de quién tiene el control

Si le preguntas a la mayoría de los ejecutivos dónde vive su información confidencial, pueden nombrar una región. Si preguntas quién puede leerla, copiarla o apagarla, la respuesta se vuelve más vaga. Esa distancia es el verdadero tema de la soberanía de los datos, y los reguladores han empezado a decirlo claramente. El 5 de noviembre de 2026, la autoridad española de protección de datos, la AEPD, y su homóloga griega publicaron una guía conjunta sobre entornos de procesamiento seguro que trata el control como un hecho técnico y no como una cláusula contractual.

Esa misma semana hubo dos recordatorios de lo que ocurre cuando el control existe solo en el papel. Una coalición de cuatro fiscales generales estatales anunció un acuerdo con una empresa cuyo software de monitoreo grabó a un intruso y no avisó a nadie. Y un caso en el Reino Unido mostró cómo una hoja de cálculo publicada de buena fe sacó datos ocultos sobre unos 8.000 empleados fuera de la organización.

Este artículo sostiene que los fallos de soberanía, privacidad y seguridad comparten una raíz común. Alguien creyó que había un control implementado, y nadie comprobó si realmente funcionaba. Las secciones siguientes explican lo que esperan ahora los reguladores, por qué ubicación y control son preguntas diferentes, cómo la concentración de proveedores erosiona ambos aspectos, qué revelan los casos recientes de cumplimiento y divulgación, cómo los asistentes de IA heredan todos estos problemas y cómo revisar los controles periódicamente para que la creencia se reemplace por una verificación real.

Conclusiones clave

1. Los reguladores definen soberanía como control.

La guía de la AEPD y la autoridad helénica indica que el proveedor debe mantener un control real y efectivo incluso cuando un tercero suministra la infraestructura, lo que traslada la cuestión de un contrato a un hecho técnico.

2. La ubicación responde al dónde, el control responde al quién.

Un servidor dentro de la frontera correcta sigue dejando abierto quién tiene las llaves, quién administra el sistema y qué subcontratistas pueden acceder a los datos.

3. Los controles que nunca se activan son peores que no tener ninguno.

Un acuerdo sobre 13,3 millones de personas afectadas giró en torno a la ausencia de autenticación multifactor, archivos sin cifrar y software de monitoreo que nunca se configuró para alertar.

4. Los datos salen por canales en los que la gente confía.

Una publicación rutinaria de registros públicos expuso datos ocultos de ausencias por enfermedad de unos 8.000 empleados porque nadie comprobó el contenido de la hoja de cálculo.

5. Los asistentes de IA heredan las mismas brechas.

La nueva guía de un regulador bancario mantiene a los bancos responsables por la IA de terceros, así que los asistentes deben actuar dentro de los derechos del usuario y bajo la misma política que las personas.

Una guía europea dice en voz alta lo que antes era implícito

La AEPD y la Autoridad Helénica de Protección de Datos elaboraron su guía con aportes de Eurostat, la Dirección General de Datos de España, el Garante de Italia y la Oficina del Comisionado de Información del Reino Unido. Es una lista relevante de colaboradores para un documento sobre infraestructura. Señala que los supervisores de varias jurisdicciones están de acuerdo en el punto clave.

El punto es que una organización responsable de datos personales debe mantener control real y efectivo sobre el entorno de procesamiento, incluso cuando un tercero suministra la infraestructura. Un certificado en la web de un proveedor no basta. Tampoco una cláusula en un contrato. La guía también advierte contra depender de un solo proveedor y señala que normalmente será obligatoria una evaluación de impacto de protección de datos para este tipo de procesamiento.

Léelo como un cambio de responsabilidad. Durante años, muchas organizaciones gestionaron la soberanía comprando garantías. Recopilaban certificaciones, firmaban la documentación estándar y archivaban la declaración del proveedor en el programa de privacidad. La guía implica una prueba diferente. ¿Puedes, como organización responsable, demostrar que tienes los mandos? ¿Puedes decidir quién accede, cambiar la configuración y mover o eliminar los datos sin pedir permiso a nadie más?

La mayoría de las organizaciones no puede responder sí a las tres preguntas. Los mandos suelen estar en manos de los administradores del proveedor de nube, los ingenieros del proveedor de servicios gestionados o un subcontratista a tres eslabones de distancia. No es un fallo de intención. Es el resultado natural de comprar infraestructura como servicio y luego tratar la compra como si fuera el control.

Hay una advertencia justa. La guía es una publicación supervisora sobre entornos de procesamiento seguro y no crea nueva legislación por sí sola. Pero los supervisores escriben guías para describir cómo interpretarán la ley existente, y la dirección es clara. La parte responsable debe poder demostrar el control, y la promesa de un proveedor no es una demostración.

La ubicación responde al dónde, el control responde al quién

En las salas de juntas se confunden tres términos. Residencia de datos describe dónde se almacenan los datos. Localización de datos describe las leyes que exigen que los datos permanezcan dentro de un territorio. Soberanía describe quién tiene autoridad sobre los datos, incluyendo quién puede exigir acceso a ellos. Un sistema puede cumplir los dos primeros y fallar en el tercero.

Pensemos en una organización hipotética que almacena registros de clientes en un centro de datos dentro de su país, gestionado por una filial de un proveedor extranjero. La residencia está cubierta y la regla de localización se cumple. Pero si el gobierno del país del proveedor puede exigirle que entregue los datos de sus filiales, el control de la organización es condicional. Ese es el trasfondo del debate sobre la Ley de Clarificación del Uso Legal de Datos en el Extranjero de Estados Unidos (CLOUD Act), y por eso un código postal en un contrato prueba menos de lo que parece.

Tres preguntas convierten una afirmación de ubicación en una de control. ¿Quién tiene las llaves de cifrado? Si las tiene el proveedor, entonces su personal o una orden judicial pueden desbloquear los datos, sin importar la geografía. Las llaves de cifrado controladas por el cliente trasladan ese poder a la organización, y el cifrado doble añade una segunda capa para que ninguna credencial de una sola parte desbloquee todo.

¿Quién administra el entorno? Los administradores pueden ver y cambiar casi todo, así que la ubicación de los administradores importa tanto como la de los discos. Una organización que mantiene los datos en la región pero permite la administración remota desde otro lugar solo ha cambiado la pregunta, no la ha respondido.

¿Qué subcontratistas tocan los datos? Las garantías de un proveedor rara vez se extienden a sus propios proveedores. La cadena es donde la soberanía se filtra sin ruido, y un programa honesto de administración de riesgos de terceros la mapea hasta el último eslabón.

Nada de esto hace imposibles las transferencias transfronterizas. Mecanismos como las cláusulas contractuales estándar siguen siendo parte legítima del cumplimiento GDPR. Pero una cláusula solo es tan fuerte como la capacidad de la organización para verificar que se cumplen las condiciones que describe, lo que vuelve a poner el foco en el control.

Un solo proveedor es un único punto de fallo

La guía de la AEPD advierte contra la dependencia de un solo proveedor, y la investigación de Kiteworks sobre la región donde la presión por la soberanía crece más rápido muestra por qué la advertencia es práctica y no teórica. En el informe Kiteworks 2026 Data Security and Compliance Risk: Data Sovereignty in the Middle East, el 44% de los encuestados de Oriente Medio reportó un incidente relacionado con la soberanía, frente al 32% en Europa y el 23% en Canadá.

La variedad de incidentes es instructiva. Las investigaciones regulatorias representaron el 22%, las brechas relacionadas con la soberanía el 20%, los fallos de terceros el 19%, las solicitudes de acceso gubernamental el 15% y las transferencias no autorizadas el 13%. El nivel de conciencia era alto, con un 74%, y el 93% afirmó que los marcos de soberanía afectan sus operaciones. Saber del problema no ha impedido que ocurra.

Observa cuántas de esas categorías se remontan a un proveedor. Los fallos de terceros son el caso más claro, pero las solicitudes de acceso gubernamental, las transferencias no autorizadas e incluso algunas brechas dependen de lo que un proveedor puede alcanzar y quién puede obligarlo. La concentración multiplica el efecto. Si un proveedor tiene los datos, las llaves y la administración, un solo fallo, una orden legal o una caída afecta todo.

La misma encuesta reveló que el 48% planea aumentar el uso de la nube regional, y el 33% cita la inestabilidad geopolítica como motivo. Migrar cargas a un proveedor regional puede reducir cierta exposición, pero también puede crear una nueva concentración si la organización simplemente cambia una dependencia por otra. El alojamiento regional cambia la dirección del riesgo, pero no elimina la necesidad de mantener el control.

La resiliencia debe formar parte de la conversación. Un plan de salida que nunca se ha ensayado es solo una esperanza. La prueba es si la organización podría mover sus datos, llaves y políticas a otro entorno en un plazo aceptable, y si alguna vez lo ha intentado. Los supervisores que preguntan sobre la dependencia de un solo proveedor están preguntando por ese ensayo.

Un control que existe pero no se activa

Si el primer modo de fallo es confiar en la garantía de un proveedor, el segundo es confiar en tus propias herramientas sin probarlas. El 6 de noviembre de 2026, la Fiscal General de Nueva York anunció un acuerdo alcanzado con una coalición que incluye también a Connecticut, Michigan y Nueva Jersey, con Perry Johnson & Associates y cuatro empresas relacionadas. La cifra principal es de hasta 10 millones de dólares, de los cuales al menos 300.000 están garantizados y 9,7 millones son contingentes. El incidente afectó a unas 13,3 millones de personas, incluidas unas 4,2 millones en Nueva York.

Los hechos son claros. En marzo de 2023, un intruso accedió usando las credenciales de un empleado. El acceso remoto no tenía autenticación multifactor. Los archivos con información de salud protegida no estaban cifrados. El software de una de las empresas registró la actividad del intruso pero no estaba configurado para alertar a nadie, y la intrusión se descubrió unos dos meses después, cuando los hackers se pusieron en contacto.

Cada control en esa historia existía de alguna forma. La empresa tenía software de registro. Tenía acceso remoto. Tenía archivos. Lo que faltaba era la configuración que habría hecho que cada control cumpliera su función. La autenticación multifactor no estaba en la puerta por la que entró el intruso. El cifrado no estaba en los archivos a los que accedió el intruso. Y la alerta no existía en la única herramienta que vigilaba.

Este es el fallo que rara vez aparece en una lista de verificación de cumplimiento, porque una lista pregunta si el control está presente. Los términos del acuerdo apuntan a una pregunta diferente: si cada control está configurado para actuar. Las reformas requeridas incluyen un programa de seguridad y protocolo de respuesta a incidentes, autenticación multifactor, gestión de contraseñas, cifrado y gestión de activos, evaluaciones anuales de riesgos HIPAA y políticas para la recopilación, uso, retención y eliminación de datos. Varias de ellas se refieren a la operación, no a la propiedad. Exigen que alguien compruebe periódicamente que las medidas siguen funcionando.

Para los datos regulados, el riesgo está en la Regla de Seguridad HIPAA y su expectativa de análisis de riesgos continuo. La lección práctica va más allá del sector salud. Un registro de auditoría que lo graba todo y no alerta de nada es solo un diario. Una herramienta de monitoreo es un control solo cuando una persona designada recibe su salida y se espera que actúe.

Los datos pueden salir por una puerta que nadie vigiló

No toda pérdida implica un atacante. Un caso reportado en un análisis de Jackson Lewis el 9 de diciembre de 2025, describió cómo Royal Cornwall publicó una hoja de cálculo en respuesta a una solicitud de acceso a la información en 2023. El archivo contenía datos ocultos sobre ausencias por enfermedad de unos 8.000 empleados actuales y anteriores. Tras detectarse el problema, se retiró el archivo, se suspendió el registro de divulgaciones y la organización adoptó una regla para que las hojas de cálculo deban estar completamente deshabilitadas antes de su publicación.

El detalle relevante es lo común que era el canal. Una publicación de registros públicos es una vía aprobada, rutinaria y de confianza para que los datos salgan. Nadie intentaba robar nada. La organización simplemente no sabía lo que contenía su propio archivo, porque el material sensible estaba en hojas ocultas que la persona que publicó nunca vio.

Eso es un problema de soberanía tanto como de privacidad. Una organización que no puede decir qué contiene un archivo no puede decir a dónde han ido sus contenidos, quién puede leerlos o qué ley aplica. La clasificación de datos es el control que responde a esas preguntas, y la prevención de pérdida de datos es cómo se aplica la clasificación en el momento en que un archivo está a punto de salir. Ambas parecen irrelevantes hasta el día en que faltan.

La solución en este caso fue un cambio de proceso, y fue acertada. Pero la mejor pregunta es por qué una regla sobre hojas de cálculo ocultas tuvo que aprenderse tras un incidente. Cualquier organización que publique documentos, comparta archivos con socios o envíe datos a reguladores enfrenta el mismo riesgo. La prueba es fácil de enunciar y rara vez se realiza: toma una muestra representativa de archivos salientes y pregunta qué contiene cada uno que su remitente no pretendía compartir.

Para datos personales y de salud, la respuesta tiene peso bajo las normas de PII y PHI. Un control que solo funciona cuando la persona que libera el archivo recuerda mirar es un hábito, y los hábitos fallan en días ocupados.

Los asistentes de IA heredan todos estos problemas

Todo lo anterior aplica a los asistentes de IA, y los supervisores bancarios lo han notado. El 5 de noviembre de 2026, American Banker informó que la OCC emitió una guía no vinculante sobre la delegación de tareas a agentes de IA, organizada en seis pilares: propósito, riesgos potenciales, controles, supervisión humana, resiliencia y pruebas. Se espera que los bancos documenten el propósito de cada sistema de IA, usuarios autorizados, permisos de datos y autoridad. Los bancos siguen siendo responsables por la IA de terceros, y la intensidad de los controles aumenta con la autonomía que se le otorga al sistema.

Tradúcelo al marco de la soberanía. Un asistente que lee documentos y toma acciones es una nueva vía por la que se mueven los datos, y hereda los problemas de control de todo lo que toca. Si funciona en la infraestructura de un proveedor, aplica la pregunta sobre el proveedor. Si accede a archivos nunca clasificados, aplica la brecha de clasificación. Si su actividad se registra en una herramienta que nadie revisa, aplica la brecha de alertas.

La respuesta es la paridad, no un programa separado. Los asistentes deben actuar dentro de los derechos de la persona a la que sirven y regirse bajo la misma política y registro que las personas. Una organización que crea un conjunto de reglas separado para la IA verá que sus dos conjuntos de controles divergen, y la brecha entre ambos será donde aterrizan las preguntas del regulador. Los bancos siguen siendo responsables por la IA de terceros, así que la pregunta práctica es si el banco puede hacer cumplir su propia política en un asistente que no construyó.

Por eso el enfoque de intercambio de datos de confianza cero encaja. La verificación ocurre en el punto donde se mueven los datos, para cada actor, ya sea empleado, socio o asistente, y la organización mantiene la política en vez de alquilarla. El mismo principio que responde a la pregunta de la AEPD sobre el control responde a la de la OCC sobre la delegación.

Dos respuestas erróneas sobre la soberanía

La primera respuesta equivocada es llevarlo todo a casa. Parece la forma más fuerte de control, y para un pequeño grupo de cargas de trabajo es adecuada. Para la mayoría de las organizaciones, cambia una debilidad por otra, porque construir y operar cada entorno exige habilidades y recursos que pocos pueden sostener, y unas operaciones débiles producen exactamente las alertas ausentes y archivos sin cifrar que describe el acuerdo. Controlar no es lo mismo que poseer cada servidor.

La segunda respuesta errónea es comprar garantías y darlo por hecho. Las certificaciones, declaraciones y cláusulas contractuales tienen valor, pero la guía de la AEPD es clara en que no sustituyen el control real y efectivo. Una organización que se queda en el papeleo tiene un registro de intención, y el regulador pedirá más.

La variable es si la organización tiene los mandos que importan, donde sea que esté la infraestructura. Eso significa tener las llaves, establecer la política, ver el registro y poder mover los datos. Una organización puede cumplir esas cuatro pruebas en la infraestructura de un proveedor, y puede fallar en las propias.

Nombrar el fallo ayuda. Llama al patrón basado solo en papeleo «teatro de garantías», un programa que busca comodidad en vez de probar el control. Llama al control no probado un control dormido, presente y silencioso. Ambos son comunes y ninguno aparece en una auditoría basada en la presencia.

Cómo Kiteworks pone el control donde viven los datos

El Kiteworks Control Plane se basa en las cuatro pruebas anteriores. Funciona en tenencia única, así que los datos y las llaves de cada cliente no se mezclan con los de otros. Aplica cifrado doble, e incluye geovallado y controles de soberanía de datos que permiten a una organización decidir dónde se puede acceder e intercambiar contenido. Un solo motor de políticas y un solo registro de auditoría cubren cómo se mueve el contenido confidencial, ya sea que el actor sea un empleado, un socio o un agente de IA.

Ese último punto responde la pregunta de paridad. El servidor Kiteworks Secure MCP permite que asistentes de IA como Claude y Copilot trabajen con contenido empresarial heredando los permisos del usuario al que sirven, con controles basados en roles y atributos aplicados a cada operación de IA. Las credenciales se mantienen en el llavero del sistema operativo y nunca se exponen al modelo, y el registro de auditoría alimenta el SIEM de la organización. Kiteworks Compliant AI aplica esta gobernanza para organizaciones que deben mostrar a los reguladores cómo la IA toca datos regulados.

Para las organizaciones que trabajan en requisitos de soberanía, las capacidades de cumplimiento de soberanía de datos y un solo motor de políticas de datos dan a la parte responsable algo concreto que mostrar a un supervisor. Personas y agentes están bajo un mismo plano, así que un cambio en una regla aplica a todos los actores y aparece en un solo registro.

Ningún producto elimina la necesidad de la revisión que se describe a continuación. Pero una plataforma que pone las llaves, la política y el registro bajo la autoridad del cliente hace que la revisión sea comprobable.

Revisa el control cada trimestre

Una revisión trimestral puede hacerse en media jornada y responde a las preguntas que reguladores y acuerdos siguen repitiendo. Empieza por las llaves. Enumera cada sistema que contenga información confidencial y registra quién tiene las llaves de cifrado de cada uno. Cualquier respuesta que diga «el proveedor» es un hallazgo.

Luego, prueba las alertas. Elige tres controles que tus herramientas afirmen proporcionar, como un intento fallido de autenticación multifactor, una descarga masiva o un inicio de sesión desde un país nuevo, y dispara cada uno en un entorno de prueba. Registra si una persona designada recibió una notificación y cuán rápido. Un control que se activa en una bandeja de entrada sin supervisión no se ha activado realmente.

Después, revisa archivos salientes. Toma veinte documentos que hayan salido de la organización en el último trimestre, ya sea por correo electrónico, uso compartido de archivos, registros públicos o portales de socios, e inspecciona cada uno en busca de hojas ocultas, metadatos e información personal que el remitente no pretendía compartir.

Mapea la cadena para tus dos proveedores más críticos, hasta subcontratistas y administradores, y anota dónde cada uno tiene acceso. Pregunta si podrías salir en un plazo determinado y, si la respuesta es desconocida, programa el ensayo.

Por último, revisa los asistentes de IA. Para cada uno, apunta de quién usa los permisos, a qué sistemas accede y dónde se registra su actividad. Si las respuestas difieren de lo que dirías sobre un usuario humano con el mismo puesto, cierra la diferencia.

Escribe los resultados en una página y envíala a quienes lideran privacidad, seguridad y compras. Repite en noventa días y compara. Un hallazgo que se repite es señal de que la organización está documentando un problema en vez de solucionarlo.

Para ver cómo tener llaves, políticas y registros bajo tu propia autoridad puede hacer que la soberanía sea comprobable, solicita una demo personalizada hoy.

Recursos adicionales

• Artículo del Blog  
  Soberanía de los datos: ¿mejor práctica o requisito normativo?
• eBook  
  Soberanía de los datos y GDPR
• Artículo del Blog  
  Evita estos errores comunes en la soberanía de los datos
• Artículo del Blog  
  Mejores prácticas para la soberanía de los datos
• Artículo del Blog  
  Soberanía de los datos y GDPR [Entendiendo la seguridad de los datos]