Soberanía digital en la infraestructura documental: qué significa y por qué importa
“Alojado en la UE” no es lo mismo que “soberano en la UE”. Esta distinción es el origen de la mayoría de los problemas de cumplimiento que las organizaciones descubren cuando ya es demasiado tarde: después de una evaluación de impacto de transferencia de datos, después de una consulta regulatoria o después de que un proveedor cambia sus condiciones.
Para los documentos con peso legal, la cuestión de la soberanía no es académica. Determina si tu organización controla sus propias evidencias o si ese control se delega a un proveedor en condiciones que pueden cambiar.
Qué significa la soberanía para la infraestructura documental
La soberanía sobre la infraestructura documental implica:
Residencia de datos: los documentos se almacenan en infraestructura ubicada físicamente en una jurisdicción donde se aplica la ley de protección de datos pertinente, y ninguna copia se conserva ni se procesa fuera de esa jurisdicción sin consentimiento explícito.
Control de acceso sin excepciones del proveedor: el proveedor no puede acceder a tus documentos salvo en los términos que acordaste explícitamente. Esto excluye el acceso de mantenimiento del proveedor, las solicitudes de las fuerzas del orden bajo legislación extranjera y el acceso por parte de empresas matrices en otras jurisdicciones.
Portabilidad de la evidencia: puedes exportar todos tus documentos, pistas de auditoría, sellos de tiempo y paquetes de evidencia en un formato que sea verificable sin la participación del proveedor. Si el proveedor cierra mañana, tu evidencia sigue siendo válida.
Sin exposición a jurisdicciones extranjeras: el proveedor no está sujeto a leyes que obliguen a revelar información a gobiernos o agencias extranjeras, como la Ley CLOUD de EE. UU. o legislación equivalente en otras jurisdicciones.
Por qué “alojado en la UE” no es suficiente
Un servicio en la nube puede alojar datos en centros de datos de la UE y al mismo tiempo estar sujeto a jurisdicciones no pertenecientes a la UE. Si la empresa operadora está constituida en Estados Unidos, su empresa matriz tiene sede en EE. UU. o está sujeta a la legislación estadounidense por otros medios, puede verse obligada en virtud de la Ley CLOUD (Clarifying Lawful Overseas Use of Data Act, 2018) a entregar datos almacenados en instalaciones de la UE a las autoridades policiales estadounidenses, sin el conocimiento ni el consentimiento del titular de los datos.
El Tribunal de Justicia de la UE (TJUE) invalidó el Escudo de Privacidad UE-EE. UU. en 2020 (Schrems II) precisamente porque la legislación de vigilancia estadounidense hace imposible una protección adecuada para los datos personales transferidos a entidades bajo control estadounidense o accesibles por ellas. El posterior Marco de Privacidad de Datos UE-EE. UU. se ha encontrado en incertidumbre jurídica desde su adopción.
Para documentos que contienen datos personales (lo que incluye facturas, registros de RRHH, contratos y documentos médicos), un proveedor sujeto a la jurisdicción estadounidense que almacena datos en centros de datos de la UE no es una solución soberana. La residencia de los datos es en la UE; la exposición legal no lo es.
El problema del bloqueo de proveedor específico para la evidencia documental
La mayoría de las plataformas documentales crean dependencias que son invisibles hasta que intentas salir. Para documentos sin peso legal, esto es una molestia. Para documentos que sirven como evidencia legal, es un riesgo estructural.
Los mecanismos de bloqueo específicos que hay que vigilar:
Formatos de pista de auditoría propietarios: si la pista de auditoría del proveedor no es exportable en un formato verificable, tu cadena de custodia depende de que el sistema del proveedor esté operativo y su API siga siendo accesible. Si el proveedor es adquirido, cierra o cambia su API, tu cadena de custodia puede volverse inverificable.
Sellos de tiempo de autoridades controladas por el proveedor: si los sellos de tiempo RFC 3161 de tus documentos son emitidos por una TSA operada por el proveedor, verificar esos sellos de tiempo tras el final de la relación con el proveedor requiere la cooperación continuada de este. Esto es una contradicción: el sello de tiempo supone ser verificable de forma independiente.
Registros de validación opacos: si los informes de validación de tu paquete de evidencia son HTML legible por humanos en lugar de datos estructurados parseables por máquina, un futuro auditor puede no ser capaz de reproducir la validación sin volver a ejecutarla, lo que no le dice nada sobre si el documento era válido en el momento del archivo.
La prueba de la soberanía genuina: ¿puedes llevar tus documentos y paquetes de evidencia a un tercero técnicamente competente que nunca haya interactuado con tu proveedor, y que pueda verificar la integridad y procedencia de cada documento usando únicamente estándares abiertos e infraestructura de clave pública?
Si la respuesta es no, tu infraestructura de evidencia no es soberana.
RGPD y obligaciones de conservación de documentos
El RGPD crea tensiones específicas con la conservación de documentos a largo plazo. El artículo 5(1)(e) exige la minimización de datos: los datos personales no deben conservarse más tiempo del necesario. El artículo 17 establece el derecho de supresión. Pero las leyes fiscales nacionales exigen conservar las facturas (que contienen datos personales) durante siete a diez años.
La solución es la excepción de conservación del artículo 17(3)(b) del RGPD: las obligaciones de supresión no se aplican cuando el tratamiento es necesario para el cumplimiento de una obligación legal. La conservación de facturas en virtud de los GoBD, el código fiscal francés o la ley belga del IVA está cualificada.
La implicación práctica para la soberanía: debes poder demostrar, para cada documento conservado, que la conservación está amparada por una obligación legal específica, y que el período y el alcance de la conservación no son más amplios de lo que requiere esa obligación. Esto es un requisito de documentación y pista de auditoría, no solo de almacenamiento.
Cómo es una infraestructura documental soberana
Una infraestructura documental soberana cumple estos criterios:
- Operada por una entidad constituida y que opera exclusivamente en una jurisdicción con protección de datos adecuada (los estados miembros de la UE cumplen este baremo para datos de la UE)
- Sin empresa matriz, estructura de inversión ni acuerdo contractual que cree exposición a jurisdicciones no pertenecientes a la UE
- Paquetes de evidencia exportables en formatos abiertos y verificables (PDF/A-3, tokens de sello de tiempo CMS, pistas de auditoría JSON)
- Sellos de tiempo RFC 3161 de TSAs listadas en la Lista de Confianza de la UE, no TSAs operadas por el proveedor
- Cadenas de hashes verificables con herramientas de código abierto sin participación del proveedor
- Opción de autoalojamiento para organizaciones que requieren control total de la infraestructura
El punto 6 es especialmente relevante para organismos gubernamentales, entidades financieras reguladas y operadores de infraestructuras críticas, que pueden tener requisitos que impidan el uso de cualquier servicio alojado por terceros independientemente de la jurisdicción.
SealDoc y la soberanía en la UE
SealDoc opera exclusivamente en infraestructura con sede en la UE bajo jurisdicción de la UE. No existe relación con ninguna empresa matriz que cree exposición a jurisdicciones extranjeras.
Los paquetes de evidencia producidos por SealDoc son verificables de forma independiente: sellos de tiempo RFC 3161 de TSAs de la Lista de Confianza de la UE, cadenas de hashes verificables con SHA-256 y pistas de auditoría exportadas como JSON estructurado. La verificación no requiere ninguna llamada a la API de SealDoc ni ninguna relación continuada con SealDoc.
Para organizaciones que requieren despliegue local o en nube privada, SealDoc admite el despliegue autoalojado en tu propia infraestructura. El formato de evidencia es idéntico al de la versión alojada, por lo que migrar de alojado a autoalojado o viceversa no afecta a la verificabilidad de los paquetes de evidencia emitidos anteriormente.
El principio subyacente es que la evidencia debe sobrevivir a cualquier relación particular con un proveedor. Si SealDoc deja de existir en 2038, cada paquete de evidencia emitido hoy debe seguir siendo verificable por un auditor con una implementación de SHA-256 y el certificado público de la TSA.