El nuevo Reglamento de Datos de la UE (Data Act) introduce un régimen inédito para facilitar el cambio de proveedor en la nube. Su objetivo: eliminar las trabas técnicas y contractuales que han mantenido cautivos a muchos usuarios. A partir de septiembre de 2025, la portabilidad será un derecho exigible con obligaciones concretas para los proveedores.
El Data Act (Reglamento (UE) 2023/2854) establece un nuevo marco para facilitar el cambio de proveedor de servicios en la nube, conocido como cloud switching. Este conjunto de obligaciones, contenidas principalmente en los artículos 23 a 31 (Capítulo VI), busca eliminar barreras técnicas y contractuales que dificultan la portabilidad de datos y servicios entre distintos proveedores. El reglamento entró en vigor el 11 de enero de 2024 y es de aplicación desde el 12 de septiembre de 2025. Los proveedores deberán adaptar progresivamente sus contratos y procedimientos internos para alinearse con el nuevo marco de portabilidad previsto en el Data Act. En este contexto, analizamos las principales características de este régimen, sus posibles riesgos y lo que implica para las compañías.
¿Qué es el ‘cloud switching’ según el Data Act?
El Data Act concibe el cloud switching como la posibilidad de que un cliente de servicios de tratamiento de datos cambie de un proveedor a otro con el mínimo de fricciones. Esto incluye migrar de un servicio en la nube a otro de tipo equivalente ofrecido por un proveedor distinto, o retornar los datos y aplicaciones a una infraestructura local (on-premise) de la propia empresa. Además, contempla escenarios de uso simultáneo de varios proveedores (multicloud), imponiendo a los proveedores la obligación de no impedir que sus clientes distribuyan sus servicios entre distintas nubes a la vez.
Con este fin, el Capítulo VI exige a los proveedores “eliminar y no poner obstáculos (…) precomerciales, comerciales, técnicos, contractuales y organizativos” que disuadan a los clientes de cambiar de servicio, migrar a una infraestructura TIC propia o utilizar varios proveedores en paralelo (art. 23). El objetivo operativo es que la transferencia sea “segura y oportuna”, en formatos de uso común y mediante “interfaces abiertas”, manteniendo la “continuidad del servicio” durante el proceso de cambio (Cdo. 97). El objetivo estratégico es evitar el vendor lock-in.
Obligaciones para los proveedores de servicios en la nube
El nuevo régimen impone obligaciones técnicas, contractuales y organizativas para facilitar la portabilidad y la interoperabilidad entre servicios. A grandes rasgos, estas son las implicaciones prácticas más relevantes:
1. Obligaciones contractuales
El Data Act prevé que los contratos incorporen de forma expresa el derecho del cliente a cambiar de proveedor, detallando un procedimiento claro de migración. Debe preverse un período transitorio máximo de 30 días durante el cual el proveedor saliente seguirá prestando el servicio mientras asiste al cliente en la migración. Durante ese período, el proveedor mantendrá la continuidad del servicio con la diligencia debida, proporcionará asistencia técnica razonable al cliente y, en su caso, al nuevo proveedor, informará de riesgos para la continuidad y garantizará altos niveles de seguridad en la transferencia. Asimismo, los contratos deben incluir la colaboración en el plan de salida (exit strategy) del cliente, proporcionando la información necesaria para planificar la migración.
Otros aspectos contractuales relevantes son: un plazo máximo de preaviso por el cliente para iniciar el proceso de cambio (no más de 2 meses); la especificación de qué datos y activos digitales del cliente pueden exportarse (como mínimo, todos los datos de entrada y salida generados por el uso del servicio) y cuáles quedan excluidos por ser internos del proveedor (p. ej., secretos comerciales, siempre que no se entorpezca la migración); una ventana mínima de recuperación de 30 días tras la terminación del servicio, durante la cual el cliente podrá seguir recuperando sus datos; y la garantía de borrado completo de los datos del cliente una vez culminado el proceso. Además, una vez finalizado con éxito el cambio o expirado el plazo de preaviso (si el cliente opta por no migrar sus datos), el contrato se considerará resuelto de pleno derecho.
Interacción con el Reglamento de IA
La interacción con el Reglamento de IA (Reglamento (UE) 2024/1689, en adelante, “RIA”) cobra especial relevancia en relación con la obligación de borrado de datos. En proyectos con sistemas de IA de alto riesgo sobre nube, el switching cruza dos marcos: el Data Act exige la supresión de datos y activos del cliente al cerrar el proceso, tras la ventana de recuperación (art. 25.2, letra h); el RIA impone registro automático de eventos y conservación de logs y documentación, con deber de cooperación con autoridades (arts. 12, 16, 18, 21 y 26). La cuestión práctica en una migración es qué se exporta y borra, qué se conserva, quién lo hace y por cuánto tiempo. Además, un cambio de plataforma que modifique elementos técnicos esenciales podría considerarse “modificación sustancial” y exigir una nueva evaluación de conformidad (art. 43.4 del RIA).
Por ejemplo, si una entidad financiera migra un SaaS de evaluación de solvencia a otro proveedor, el Data Act ampara la terminación, regula la exportación y exige la supresión de datos exportables y activos digitales al cierre. Por su parte, el RIA obliga a mantener los logs del sistema durante un plazo mínimo cuando están bajo control del obligado y a facilitarlos a la autoridad si se requiere (arts. 12 y 21). En este caso debería identificarse qué registros están sujetos a conservación, delimitar quién los custodia y verificar si el cambio afecta a la conformidad.
2. Obligaciones técnicas y de interoperabilidad
Los proveedores deben facilitar la portabilidad de los datos y la interoperabilidad de sus servicios para que el cliente pueda operar sus datos y aplicaciones en el servicio de destino con el menor esfuerzo posible. Esto exige proporcionar interfaces abiertas (APIs) y formatos estándar para la exportación de datos, accesibles en igualdad de condiciones por todos los clientes y por los proveedores de destino, y sin coste adicional. La información técnica necesaria (p.ej., estructuras de datos, formatos, metadatos, etc.) debe ponerse a disposición en un registro en línea actualizado, de forma que terceros puedan desarrollar herramientas de conversión o migración compatibles.
Las obligaciones dependen del tipo de servicio: si se trata de infraestructura como servicio (IaaS) o recursos de computación básicos, el proveedor de origen debe adoptar medidas razonables que faciliten que el cliente alcance una equivalencia funcional en el servicio de destino, siempre dentro de los límites de lo técnicamente viable y sin comprometer la seguridad o la integridad de sus sistemas. Esto implica que, al cambiar a otra infraestructura equivalente, las aplicaciones del cliente funcionen de forma comparable, obteniendo resultados materialmente similares ante las mismas entradas, siempre para las funcionalidades comunes. El reglamento aclara que el proveedor saliente no está obligado a recrear todo su servicio en la infraestructura del competidor, pero sí a proporcionar capacidades, documentación, asistencia técnica y herramientas necesarias para que la transición sea efectiva (Cdo. 92). Un ejemplo es el uso de herramientas de conversión de máquinas virtuales o contenedores para trasladar cargas de trabajo a otro entorno. En los servicios de plataforma (PaaS) o software (SaaS), la prioridad es la apertura de interfaces y la estandarización para migrar datos entre aplicaciones distintas.
Los pormenores de la estandarización se articulan en el art. 35. En síntesis: el Capítulo VI fija el “qué” y el art. 35 el “cómo”. Cuando la Comisión publique en el repositorio una norma armonizada o una especificación común aplicable, el proveedor dispondrá de doce meses para asegurar la compatibilidad; todo ello sin exigir desarrollar tecnologías nuevas, revelar activos protegidos (por ejemplo, su código fuente o algoritmos) ni comprometer la seguridad o la integridad de sus sistemas como condición para la migración.
Según la última versión de las FAQs de la Comisión (12 de septiembre), la pregunta 57 indica que el repositorio adoptará la forma de una plataforma en línea de ventanilla única por tipo de servicio; como primer paso, en septiembre de 2025 la Comisión ha concluido un mapeo de normas armonizadas y especificaciones abiertas que cualifican para su reconocimiento y, antes de publicar una referencia, consultará a las partes interesadas y adoptará un acto de ejecución; la primera versión del repositorio se publicará en europa.eu y se irá completando progresivamente por tipo de servicio. Por el momento, y en ausencia de estándares aplicables, los clientes al menos deberán poder exportar todos sus datos en formato estructurado, de uso común y lectura mecánica, si así lo solicitan. Conviene recordar que todavía no hay una taxonomía cerrada del “mismo tipo de servicio”, lo que condiciona cuándo procede exigir equivalencia funcional o compatibilidad.
3. Deber de cooperación y buena fe
El proceso de cloud switching involucra al cliente, al proveedor saliente y, en su caso, al proveedor entrante. El Data Act impone a todos ellos un deber general de colaboración de buena fe para que la migración sea efectiva, rápida y segura. Esto incluye que el proveedor de destino también coopere técnicamente con el cliente (y, si fuera necesario, con el proveedor original) para lograr la continuidad del servicio en el nuevo entorno. Se trata de evitar que cualquiera de las partes —por acción u omisión— entorpezca el cambio. Esta obligación complementa las medidas específicas impuestas al proveedor saliente y refuerza la idea de que el switching debe ser un esfuerzo conjunto en beneficio del cliente.
4. Transparencia sobre localización de datos y acceso gubernamental
Como parte del Capítulo VI, los proveedores también deben informar públicamente sobre la jurisdicción donde se encuentran sus infraestructuras y sobre las medidas que adoptan para impedir accesos gubernamentales extrajudiciales a datos no personales en la UE. Esta obligación (art. 28.1, letras a) y b)) busca dar confianza a los clientes respecto a dónde se encuentran sus datos y cómo se protegen frente a órdenes de terceros países que pudieran entrar en conflicto con el Derecho de la Unión o con el Derecho nacional correspondiente. La información debe estar disponible en la web del proveedor y referenciada en los contratos (art. 28.2). Si bien esto no afecta directamente a la portabilidad, sí forma parte del marco de confianza en la nube que establece el Data Act, complementando el derecho al cambio de proveedor con garantías en materia de soberanía del dato.
5. La cláusula sobre costes de cambio: “charges… strictly limited to the costs incurred”
Un aspecto crucial de la portabilidad es el relativo a los costes que un proveedor puede cobrar a un cliente que desea cambiar de servicio. Históricamente, muchos proveedores imponían tarifas elevadas por la extracción de datos (tasas de salida de datos, egress) u otros cargos al terminar anticipadamente un contrato, con fuerte efecto disuasorio. El Data Act aborda este problema con una retirada progresiva de los costes de cambio (art. 29).
En términos prácticos, a partir del 12 de enero de 2027 estará prohibido cobrar al cliente por el proceso de cambio. Hasta entonces, solo cabe imponer “costes por cambio reducidos”, que no podrán exceder de los costes soportados por el proveedor directamente relacionados con el proceso de cambio (“charges imposed by the provider strictly limited to the costs incurred”, art. 29.3). Esto incluye gastos objetivamente atribuibles a la migración (p. ej., ancho de banda para transferir datos, tiempo de asistencia técnica, uso de herramientas específicas de exportación), pero excluye márgenes de beneficio y costes no relacionados (p. ej., costes generales de infraestructura o penalizaciones).
El cdo. 89 advierte que ciertos costes no podrán repercutirse al cliente, como los derivados de subcontratación elegida por el proveedor. Solo si el cliente solicita servicios adicionales más allá de lo exigido por la norma (p. ej., asistencia extraordinaria o personalizada) podría cobrarse por ese servicio extra, con acuerdo previo sobre el precio. En definitiva, la regla de costes del art. 29 pretende que, durante el periodo transitorio, el cliente pague como mucho el coste real de llevarse sus datos. Y, desde 2027, el cambio deberá ser gratuito para el cliente, asumiendo el proveedor los gastos internos que conlleve. Quedará por ver cómo se verifica que los costes cobrados hasta 2027 se ajustan a esta limitación, lo que podría requerir transparencia contable. La Comisión, consciente de ello, dispone de facultades de seguimiento durante el periodo transitorio (art. 49.1, letra i)).
6. Microempresas y pymes: ¿exentas del ‘cloud switching’?
El Data Act introduce en el art. 7 una exención para microempresas y pequeñas empresas respecto de algunas obligaciones. En concreto, las del Capítulo II no se aplicarán a los datos generados por productos o servicios de una micro o pequeña empresa, siempre que no forme parte de un grupo empresarial más grande ni actúe bajo subcontratación de otra empresa. Esta exención se incluyó para no cargar a pequeños fabricantes de dispositivos o proveedores de servicios con las obligaciones de compartir datos del ámbito IoT. Ahora bien, ¿se extiende esa exención a las obligaciones de cloud switching del Capítulo VI?
La respuesta, según la letra de la norma, es no. La excepción del art. 7 se circunscribe al Capítulo II y no menciona ninguna dispensa respecto de las reglas de cambio de proveedor en la nube. Por tanto, incluso las micro y pequeñas empresas que ofrezcan servicios de tratamiento de datos en la nube estarán sujetas al régimen de cloud switching. Esto puede plantear retos para estos actores, pues implementar estándares de interoperabilidad, herramientas de exportación de datos o soportar económicamente migraciones gratuitas puede suponer un esfuerzo proporcionalmente mayor.
El legislador es consciente de este posible impacto: el art. 49.2 ordena a la Comisión evaluar, a más tardar el 12 de septiembre de 2028, los efectos de las obligaciones de cloud switching (arts. 23 a 31) en el mercado, con especial atención a las pymes proveedoras. También conviene recordar que el art. 31 prevé un régimen específico para ciertos servicios de tratamiento de datos, como software desarrollado a medida para un solo cliente (soluciones muy personalizadas, no ofrecidas a escala) o versiones de prueba no productivas, donde algunas obligaciones de cambio no aplican. Esta es una excepción por naturaleza del servicio, no por tamaño de empresa.
En conclusión, el régimen de cloud switching del Reglamento de Datos marca un antes y un después en la relación entre clientes y proveedores de la nube. A partir de septiembre de 2025, se facilita el cambio de proveedor al establecer un derecho con pasos, plazos y límites más claros. Las empresas usuarias ganarán en libertad para elegir la solución que más les convenga en cada momento lo que, como consecuencia lógica, conlleva una mayor competitividad en la calidad de los servicios. El escenario es el de un mercado más abierto y dinámico, donde la capacidad de switching y la interoperabilidad serán factores centrales para la innovación y la competencia. Como toda transformación, traerá desafíos de adaptación, pero también oportunidades para quienes sepan anticiparse.
‘Checklist’: pasos clave ante el nuevo régimen de ‘cloud switching’
Para proveedores de servicios en la nube:
- Actualizar contratos y modelos: incorporar preaviso, transición, recuperación, terminación y borrado; suprimir prácticas obstáculo; política de costes conforme a “costes incurridos” hasta 2027 y cero después.
- Habilitar herramientas: exportación en formatos estructurados y de uso común, APIs abiertas e información técnica en registro en línea; en IaaS, medidas para equivalencia funcional; en PaaS/SaaS, foco en interfaces abiertas.
- Operativa de switching: playbook interno con responsables, SLA para el período transitorio, asistencia razonable al cliente y, en su caso, al entrante; seguridad durante la transferencia y borrado seguro al cierre.
- Identificar y ajustar políticas técnicas y contractuales que pudieran considerarse obstáculos al cambio, como limitaciones de rendimiento (throttling), exclusividades o penalizaciones, adaptándolas progresivamente al nuevo marco de portabilidad; reducir costes por cambio hasta 2027 y eliminarlos después; permitir uso en paralelo conforme al régimen legal.
- Gobernanza y estándares: mantener la sección pública de transparencia; vigilar el repositorio del art. 35 y activar el plazo de 12 meses de compatibilidad cuando se publiquen referencias.
Para clientes (usuarios empresariales):
- Revisar contratos vigentes: preaviso de cambio (≤ 2 meses), período transitorio (30 días), recuperación (≥ 30 días), terminación y borrado; eliminar penalizaciones y obstáculos incompatibles.
- Diseñar un plan de salida: inventario de datos y activos exportables, dependencias técnicas, formatos y APIs disponibles; tiempos y responsables internos.
- Usar la transparencia del proveedor: consultar procedimientos de switching, formatos soportados, limitaciones y jurisdicciones publicadas.
- Valorar alternativas y 'multicloud': comparar ofertas y costes, incluida la regla de costes hasta 2027 y el egress a coste en uso en paralelo.
- Hacer valer derechos: documentar avisos y solicitudes; si hay obstáculos o dilaciones, escalar por los cauces previstos.
- Si hay IA de alto riesgo: identificar logs sujetos a conservación y roles de custodia antes de exportar o borrar.