Todo responsable de TI que ejecuta analítica sobre Redshift, BigQuery o Azure Synapse ha tenido alguna versión de la misma conversación: ¿qué nos costaría realmente salir? La respuesta honesta rara vez resulta cómoda. La dependencia de un proveedor cloud en BI no es principalmente un problema contractual, sino arquitectónico: está integrada en los motores de consulta, los formatos de almacenamiento y la gravedad del dato, y la factura solo se hace visible cuando salir ya no es opcional.
Con un gasto mundial en nube pública de 679 000 millones de dólares en 2024, los grandes proveedores han tenido todos los incentivos para profundizar esa gravedad. La pregunta para tu equipo de infraestructura no es si existe dependencia, sino si tu arquitectura actual te ofrece una salida realista y a qué coste.
El problema de los formatos que nadie menciona en el pitch de ventas
BigQuery almacena sus tablas nativas en Capacitor, el formato columnar propietario de Google. No tienes acceso directo a esos archivos. Exportar a Parquet, el formato que necesitarías para migrar a cualquier otro destino, requiere un trabajo de exportación explícito con tarifas de egreso adicionales. Redshift acopla estrechamente cómputo y almacenamiento dentro de AWS y, aunque su dialecto SQL deriva de PostgreSQL, diverge lo suficiente en funciones de ventana y tipos de datos como para que una migración directa a otro almacén rara vez sea limpia. Azure Synapse desacopla cómputo y almacenamiento e integra profundamente el ecosistema Azure, lo que representa una ventaja arquitectónica genuina dentro de Azure y una dependencia significativa fuera de él.
La migración de datos es, en realidad, la parte más sencilla de cualquier estrategia de migración de business intelligence. El trabajo más duro consiste en reescribir las diferencias de dialecto SQL, especialmente en funciones de fecha, manejo de arrays y tipos STRUCT; migrar procedimientos almacenados y UDFs; actualizar los pipelines de ETL; y reconfigurar los controles de acceso. Nada de eso aparece en ninguna calculadora de costes.
Lo que el egreso cuesta realmente
El llamado «impuesto de salida» sobre los datos en la nube es real, aunque el panorama cambió en 2024. AWS cobra aproximadamente 0,09 $/GB para los primeros 10 TB de egreso, Azure aproximadamente 0,087 $/GB, y el nivel Premium de GCP se sitúa en 0,12 $/GB. En un entorno analítico de gran tamaño, las tarifas de egreso suponen habitualmente entre el 6 y el 12 % de la factura cloud total. Sincronizar datos entre proveedores lo agrava: pagas egreso en ambos lados de cada transferencia, lo que hace que las arquitecturas multicloud sean económicamente inviables sin un diseño deliberado que mantenga al mínimo los flujos de datos entre proveedores.
En enero de 2024, GCP anunció que eximiría de las tarifas de egreso a los clientes que migraran completamente fuera de su plataforma. AWS y Azure siguieron el mismo camino en menos de dos meses. Las condiciones importan: Azure exige la cancelación de todas las suscripciones, y AWS excluye servicios como CloudFront y Direct Connect. El egreso operativo habitual, el que sirve datos a los usuarios desde la nube día a día, no queda abolido. La exención cubre el cambio de proveedor, no los costes de tráfico continuo. Es una señal bienvenida, pero no elimina la reescritura de formatos, el trabajo sobre los pipelines ni el riesgo de tiempo de inactividad.
Lo que cambia realmente el Reglamento de Datos de la UE
El Reglamento (UE) 2023/2854, conocido como Reglamento de Datos de la UE, entró en vigor el 11 de enero de 2024 y es aplicable desde el 12 de septiembre de 2025. Su Capítulo VI está diseñado específicamente para contrarrestar la dependencia de proveedor en los servicios de tratamiento de datos, abarcando IaaS, SaaS, PaaS y computación en el edge. Obliga a los proveedores a eliminar los obstáculos para el cambio efectivo, incluidos los de naturaleza comercial, contractual, técnica y organizativa, con las tarifas de egreso explícitamente en su ámbito de aplicación.
El Reglamento introduce una abolición gradual de las tarifas de cambio. Desde la fecha de entrada en vigor hasta el 12 de enero de 2027, dichas tarifas podrán seguir cobrándose, pero deberán limitarse a los costes directos reales y comunicarse antes de firmar cualquier acuerdo. A partir del 12 de enero de 2027, cobrar tarifas de cambio quedará completamente prohibido. Los proveedores también deberán facilitar a los clientes información detallada sobre los procedimientos de cambio y portabilidad, y mantener un registro actualizado de estructuras de datos, formatos y especificaciones de interoperabilidad.
La portabilidad sobre el papel no es portabilidad en la práctica. El Reglamento de Datos puede imponer la eliminación de barreras económicas, pero no puede obligar a que los dialectos SQL sean compatibles, a que los UDFs se traduzcan sin fricciones, ni a que los pipelines de ETL sobrevivan al traslado.
La supervisión recae en las autoridades competentes conforme al artículo 40, no en los clientes empresariales individuales. Los Estados miembros deben establecer sus marcos sancionadores antes del 12 de septiembre de 2025, aunque las cifras concretas para cada jurisdicción aún no están disponibles. El reglamento supone un cambio significativo en el marco legal, pero no sustituye el trabajo técnico de construir un stack de BI con portabilidad real en la nube.
Los formatos de tabla abiertos como cobertura práctica
La respuesta más sólida a la dependencia de proveedor cloud en BI es arquitectónica, no contractual. Los formatos de tabla abiertos, concretamente Apache Iceberg, Delta Lake y Apache Hudi, añaden transacciones ACID, evolución de esquemas y viaje en el tiempo sobre Parquet, lo que permite arquitecturas lakehouse portables que no pertenecen a ningún proveedor concreto. Gartner calificó los formatos de tabla abiertos, como Apache Iceberg, con un beneficio «Transformacional» en su Hype Cycle for Data Management de 2025, la valoración de impacto más alta que asigna la firma.
Iceberg es leído y escrito actualmente por Spark, Flink, Trino, Presto y Hive. AWS Athena y Glue se integran con él; Snowflake también. En 2024, Databricks adquirió Tabular, fundada por los creadores originales de Iceberg, e introdujo funciones de interoperabilidad entre Iceberg, Delta Lake y Hudi. El sector ha convergido en los formatos abiertos como capa de intercambio de facto. Si tu estrategia de almacén de datos no incluye un plan para que tus datos residan en un formato abierto en reposo, estás construyendo la próxima generación de dependencia.
Cómo es realmente una arquitectura de almacén de datos portable
Una arquitectura genuinamente portable separa el almacenamiento del cómputo, guarda los datos en formatos abiertos sobre un almacenamiento de objetos que tú controlas, y trata el motor de consulta como una capa reemplazable. Eso implica usar Iceberg o Delta Lake sobre almacenamiento de objetos en lugar de tablas nativas del almacén siempre que sea posible, mantener la lógica de transformación en SQL agnóstico al motor o en un framework como dbt que soporte múltiples backends, y validar tu ruta de egreso antes de necesitarla, no después.
La región donde residen físicamente tus datos también tiene peso legal. Para las tablas analíticas que puedan contener datos personales, la región del almacén determina tu exposición al RGPD. No es una nota a pie de página de cumplimiento; es una restricción arquitectónica que debe orientar dónde sitúas tus datos en reposo.
Operamos la infraestructura analítica de DIVERSITY bajo estándares Tier III, certificación ISO 27001 y un SLA contractual del 99,9 % de disponibilidad en instalaciones carrier-neutral. La soberanía aquí no es un argumento de marketing; es una garantía a nivel contractual, auditable y ejecutable bajo legislación europea, no sujeta a jurisdicción extranjera. Cuando los clientes utilizan nuestra infraestructura como zona de aterrizaje para una migración de stack de BI, no están cambiando un conjunto de dependencias propietarias por otro. Aterrizan sobre almacenamiento de objetos en formato abierto, con peering directo a los grandes proveedores de los que se alejan, lo que significa que la ruta de transferencia de datos es predecible y la arquitectura que construyen sobre ella les pertenece.
Poner a prueba la portabilidad antes de que se convierta en una crisis
La prueba práctica no es teórica. Toma uno de tus pipelines de reporting principales y mapea todas sus dependencias: las características de dialecto SQL que utiliza, los UDFs que invoca, los trabajos de ETL que lo alimentan, los controles de acceso que lo protegen. Luego estima cuánto costaría en tiempo de ingeniería y tarifas de egreso mover ese pipeline a un motor de consulta diferente sobre almacenamiento de objetos neutral. Si no puedes responder esa pregunta para tu pipeline más crítico, aún no tienes una arquitectura de almacén de datos portable; tienes un riesgo de migración que todavía no ha sido valorado.
Los grandes proveedores cloud han construido productos excelentes. La pregunta es si la salida de esos productos, si alguna vez llega a ser necesaria, será una operación planificada o una emergencia. Construir sobre formatos abiertos, separar el almacenamiento del cómputo y validar tu ruta de egreso sobre infraestructura neutral es la forma de mantener esa elección en tus manos.
