Finlandia ha reforzado las salvaguardas contractuales relacionadas con protección de datos en el uso de servicios Microsoft por parte del sector público.
Interoperable Europe recoge en su actualización de septiembre de 2026 que el Gobierno finlandés ha clarificado obligaciones de protección de datos y requisitos de tratamiento en sus acuerdos.
Qué se ha publicado
El movimiento pone el foco en cómo las condiciones contractuales pueden utilizarse para reforzar control público sobre datos y responsabilidades de proveedores tecnológicos.
La novedad es relevante para las Administraciones porque afecta a protección de datos, contratación tecnológica y soberanía en servicios cloud. El valor real dependerá de cómo se integre con procesos, datos, seguridad, contratación y operación cotidiana.
Una iniciativa digital pública madura necesita usuarios reales, responsables, soporte, documentación y presupuesto recurrente. La tecnología por sí sola no garantiza un servicio sostenible.
Qué problema intenta resolver
Los grandes servicios cloud procesan información pública a través de cadenas complejas de tratamiento y subcontratación que deben quedar claramente gobernadas.
La implantación debería partir de una línea base: tiempos, errores, costes, nivel de digitalización y experiencia actual. Esa referencia permitirá comparar resultados después del cambio.
El objetivo debería formularse con métricas observables, como reducción de carga, mejora de calidad, aumento de disponibilidad o mayor reutilización.
Arquitectura y diseño
La arquitectura contractual y técnica debe definir dónde se procesan datos, qué servicios intervienen y cómo se controla el acceso.
Una arquitectura pública sostenible separa datos, integración, lógica, analítica y presentación. Esta división permite sustituir componentes con menor impacto y evita que una única herramienta concentre todo el conocimiento.
La organización debería conservar identificadores, modelos de datos, reglas de negocio, credenciales y documentación de interfaces. Desarrollo, pruebas y producción deberían estar separados.
Gobierno del dato
Inventario, clasificación, ubicación, finalidades y periodos de conservación son elementos básicos para gobernar datos públicos.
Cada fuente necesita propietario, periodicidad, calidad, finalidad, licencia y reglas de acceso. El linaje —origen, transformaciones y fecha— permite explicar resultados y reconstruir incidencias.
También conviene distinguir datos de producción, pruebas y entrenamiento cuando exista IA para evitar usos inadecuados.
Interoperabilidad
La portabilidad y los formatos de exportación son importantes para evitar una dependencia difícil de revertir.
APIs documentadas, formatos abiertos e identificadores estables reducen integraciones exclusivas. La interoperabilidad semántica es igualmente importante: los sistemas deben interpretar de forma coherente los conceptos compartidos.
Los contratos de interfaz deberían describir estructura, errores, autenticación y versiones, con periodos de transición cuando cambien.
Seguridad y privacidad
Las obligaciones deben cubrir identidad, cifrado, registros, incidentes, subprocesadores y mecanismos de control.
Identidades, mínimo privilegio, segmentación, registros, actualización, copias y respuesta ante incidentes deben incorporarse desde el diseño. Las cuentas técnicas y certificados necesitan propietarios, fechas de renovación y revocación.
Cuando existen datos personales o sensibles, la minimización debe aplicarse como regla práctica.
IA y automatización
Los servicios cloud incorporan cada vez más funciones de IA, lo que obliga a revisar si los datos pueden utilizarse para entrenamiento o funciones adicionales.
La IA debería utilizarse cuando aporta una ventaja medible frente a reglas o análisis convencionales. Cuando se emplean modelos, conviene registrar versión, fuentes, métricas, limitaciones y supervisión humana.
Las pruebas deben incluir casos límite y escenarios adversos. También debe existir un criterio para retirar o actualizar un modelo cuando se degrade.
Contratación y reversibilidad
El caso muestra la importancia de convertir protección de datos y responsabilidades en cláusulas verificables.
Los pliegos deberían exigir exportación de datos y configuraciones, documentación de arquitectura, inventario de componentes y condiciones de salida. La reversibilidad debe probarse durante el contrato.
La dependencia también puede ser de conocimiento; la Administración necesita capacidad para entender y supervisar el sistema.
Pruebas antes de escalar
Las pruebas deberían incluir datos incompletos, servicios caídos, credenciales caducadas, errores de formato y cambios de versión. Automatizar parte de la batería facilita detectar regresiones y aceptar entregas con criterios objetivos.
También conviene ensayar restauración de copias y reconstrucción de integraciones para validar continuidad.
Operación y soporte
Los contratos necesitan seguimiento, revisiones y mecanismos para comprobar cambios de servicio o subprocesadores.
Los cuadros operativos deberían medir disponibilidad, latencia, errores, calidad y consumo. Cada indicador necesita umbral y responsable. El soporte debería diferenciar problemas funcionales, de datos, integración, infraestructura y seguridad.
Los niveles de servicio deben adaptarse a criticidad.
Capacitación y transferencia
Compras, jurídico, protección de datos y TIC deben trabajar conjuntamente para evaluar servicios cloud.
Los usuarios funcionales necesitan comprender límites y excepciones; los técnicos, arquitectura y seguridad; y contratación, costes, dependencia y criterios de aceptación.
La documentación debe mantenerse junto con las versiones y formar parte de los entregables.
Coste total y sostenibilidad
La decisión no debe considerar solo precio por usuario, sino también migración, controles, soporte y capacidad de salida.
Infraestructura, almacenamiento, conectividad, soporte, licencias, personal, monitorización, auditorías y futuras migraciones forman parte del ciclo de vida. Conviene modelar escenarios de crecimiento.
La sostenibilidad también implica poder retirar funciones con poco uso.
Cómo medir resultados
Incidentes, cumplimiento contractual, auditorías y tiempo de respuesta del proveedor pueden formar parte del seguimiento.
Las métricas de actividad no demuestran por sí solas impacto. Deben relacionarse con tiempo ahorrado, errores evitados, calidad, satisfacción, disponibilidad o coste.
Seis meses después del despliegue conviene comparar resultados con la línea base.
Gobernanza del cambio
Las tecnologías y necesidades evolucionan. Debe existir un proceso para aprobar cambios de versión, nuevas integraciones o sustitución de componentes. Cada cambio relevante necesita responsable, pruebas y capacidad de reversión.
Documentar decisiones técnicas reduce dependencia de personas concretas.
Reutilización
Las cláusulas y criterios de evaluación pueden inspirar compras públicas en otros países.
El conocimiento público genera más valor cuando produce activos reutilizables: modelos de datos, APIs, cláusulas, pruebas, guías o software.
Para que la reutilización sea real, los activos necesitan documentación y licencias adecuadas.
Aplicación en España
Las Administraciones españolas pueden revisar contratos cloud desde la misma perspectiva: datos, subprocesadores, portabilidad, auditoría y cambios de servicio.
La adopción no tiene por qué consistir en copiar una solución completa. Puede reutilizarse un patrón de arquitectura, un conjunto de controles o una metodología.
Antes de adoptar conviene comparar volumen, usuarios, normativa, infraestructura y capacidad operativa.
Riesgos y límites
Una cláusula sólida pierde valor si no existe capacidad para verificarla o actuar cuando el proveedor cambia condiciones.
Otro riesgo es convertir una solución común en un nuevo punto de dependencia. La arquitectura necesita documentación, mecanismos de salida y, cuando corresponda, redundancia.
La estandarización puede admitir extensiones justificadas manteniendo compatibilidad en el núcleo.
Hoja de ruta
Una entidad interesada puede comenzar con un caso de uso delimitado, describiendo proceso, datos, usuarios y métricas. Después puede probar en un entorno separado y ampliar gradualmente si demuestra valor.
La fase estable debe formalizar operación, soporte, financiación recurrente y revisión periódica.
Checklist antes de adoptar
- Definir problema y línea base.
- Inventariar sistemas y datos.
- Asignar responsables.
- Documentar interfaces y versiones.
- Aplicar seguridad por diseño.
- Exigir portabilidad y reversibilidad.
- Probar fallos y recuperación.
- Calcular coste total.
- Formar a usuarios y técnicos.
- Definir métricas.
Qué habrá que observar
Habrá que observar cómo se aplican las salvaguardas y si generan modelos contractuales reutilizables.
La utilidad se comprobará con adopción real, calidad, incidencias y evolución. Será importante observar cuánto tarda una nueva integración y qué capacidad permanece en la organización cuando cambian proveedores o versiones.
Preguntas frecuentes
¿Quién impulsa la iniciativa?
Gobierno de Finlandia, según la actualización recogida por Interoperable Europe.
¿Cuál es su principal utilidad?
Reforzar control y claridad sobre protección de datos en servicios tecnológicos contratados por el sector público.
¿Puede reutilizarse?
Sí, especialmente como referencia de gobernanza contractual y evaluación de servicios cloud.
¿Qué debe comprobarse primero?
Compatibilidad, seguridad, responsabilidades, documentación, coste y capacidad de salida.
Fuentes
La información principal procede de Interoperable Europe.
Lecturas relacionadas
Más contexto sobre código abierto, gobierno del dato, interoperabilidad semántica y IA pública europea.
Qué cambia cuando la protección de datos entra en los contratos tecnológicos
La experiencia finlandesa resulta especialmente relevante porque sitúa las garantías de privacidad dentro de la relación contractual con un proveedor tecnológico de gran escala. Para una Administración, el contrato no debería limitarse a precio, licencias y soporte: también debe definir qué datos procesa el proveedor, desde qué jurisdicciones, con qué subencargados y bajo qué mecanismos de auditoría.
Este enfoque reduce la distancia entre cumplimiento jurídico y operación técnica. Si una plataforma cambia su arquitectura, incorpora nuevos servicios o modifica condiciones de telemetría, la Administración necesita saber si ese cambio afecta a las garantías acordadas.
Inventario de tratamientos y servicios realmente utilizados
Las suites empresariales incluyen decenas de servicios, pero no todos se utilizan de la misma forma. Antes de negociar garantías conviene identificar qué módulos están activos, qué datos manejan y qué perfiles de usuarios los utilizan.
Un inventario detallado facilita aplicar minimización y evita aceptar condiciones amplias para capacidades que el organismo no necesita. También permite distinguir servicios críticos de herramientas accesorias y priorizar controles.
Telemetría, diagnósticos y metadatos
La protección de datos no afecta únicamente al contenido de documentos y correos. Metadatos, registros de actividad, identificadores de dispositivo y telemetría pueden ofrecer información relevante sobre empleados y operaciones.
Las Administraciones deberían revisar qué datos de diagnóstico son obligatorios, cuáles pueden reducirse y cuánto tiempo se conservan. La configuración técnica debe alinearse con las condiciones jurídicas acordadas.
Subencargados y cadena internacional de proveedores
Los grandes servicios cloud dependen de una cadena de centros de datos, proveedores y subencargados. El organismo necesita visibilidad sobre esa cadena y mecanismos para conocer cambios relevantes.
La contratación debería prever qué ocurre si aparece un nuevo subencargado o una transferencia internacional que modifica el análisis inicial. La capacidad de oponerse, migrar o ajustar el servicio forma parte de la gestión de riesgo.
Portabilidad y salida
Las garantías de privacidad son más sólidas cuando la Administración también dispone de capacidad real para cambiar de proveedor. Exportar documentos no siempre es suficiente: deben considerarse configuraciones, permisos, históricos, metadatos y automatizaciones.
Una prueba de salida durante la vigencia del contrato puede revelar dependencias antes de que exista presión por migrar.
Qué puede trasladar una Administración española
El aprendizaje principal es integrar privacidad, arquitectura y contratación en un mismo proceso. Delegado de protección de datos, TIC, seguridad, contratación y áreas usuarias deberían revisar conjuntamente servicios cloud de gran alcance.
También conviene conservar una matriz de controles que pueda reutilizarse en futuras renovaciones, evitando empezar de cero en cada expediente.
Conclusión operativa
Las salvaguardas contractuales tienen valor cuando pueden comprobarse técnicamente. Configuración, telemetría, subencargados, ubicación, registros y capacidad de salida deben formar parte del seguimiento ordinario del servicio.
Qué debería auditar un organismo antes de renovar una suite cloud
Antes de una renovación contractual conviene revisar qué servicios se utilizan de verdad, qué datos han terminado almacenándose en la plataforma y qué integraciones se han creado durante los últimos años. Muchas dependencias aparecen de forma gradual mediante automatizaciones, complementos o flujos que no existían cuando se firmó el contrato inicial.
La auditoría debería identificar además qué configuraciones se apartan de los valores recomendados, qué permisos se han acumulado y qué cuentas siguen activas sin una necesidad clara. Este trabajo permite negociar desde una fotografía real del servicio y no desde la descripción comercial del producto.
También es útil comprobar si existen alternativas para los componentes más críticos. No se trata de planificar una migración inmediata, sino de conocer qué esfuerzo requeriría una salida y qué datos o formatos podrían dificultarla.
Privacidad como criterio de diseño continuo
Las garantías contractuales necesitan revisiones periódicas porque los servicios evolucionan. Nuevas funciones de IA, análisis o colaboración pueden introducir tratamientos diferentes sin que el organismo cambie aparentemente de producto.
Un comité periódico entre TIC, seguridad, protección de datos y contratación puede revisar cambios de servicio, subencargados, transferencias y configuraciones relevantes. Esta gobernanza reduce la probabilidad de descubrir un problema solo cuando aparece una auditoría o una incidencia.
La revisión contractual debería documentar además qué decisiones se tomaron, qué riesgos se aceptaron y qué medidas compensatorias siguen activas. Mantener ese historial evita repetir discusiones y facilita la siguiente renovación. También permite comprobar si una garantía jurídica tiene un reflejo técnico verificable en configuración, permisos, ubicación del dato y operación cotidiana.
La política interna debería incluir una revisión anual de configuraciones, telemetría, subencargados y mecanismos de exportación. Esa revisión permite comprobar que las salvaguardas pactadas siguen siendo suficientes cuando la plataforma incorpora nuevas funciones, especialmente capacidades de inteligencia artificial o analítica.
La revisión deberá repetirse cuando cambien funciones relevantes, subencargados o condiciones técnicas del servicio cloud.
El seguimiento continuo será imprescindible para mantener las garantías alineadas con la evolución técnica del servicio contratado.
La revisión debe quedar documentada.
Fotografía: Dan Nelson / Pexels.