El stack tecnológico de datos se ha convertido en una de las decisiones estratégicas más determinantes para cualquier organización que aspire a competir en un mercado orientado por la información. Ya no se trata solo de elegir qué base de datos utilizar o en qué infraestructura desplegarla: hablamos de diseñar el ecosistema que sostendrá la capacidad de una empresa para capturar, procesar, gobernar y monetizar sus datos a lo largo del tiempo.

En los comités de dirección, esta elección se suele reducir a una pregunta aparentemente simple: ¿cloud u on-premise?. Pero la realidad es mucho más compleja. La nube ofrece elasticidad, velocidad de innovación y acceso inmediato a servicios avanzados de inteligencia artificial y machine learning. El on-premise garantiza control, seguridad y cumplimiento en sectores regulados. Y en la práctica, la mayoría de organizaciones se mueven en un territorio intermedio: entornos híbridos o estrategias multicloud que buscan equilibrar agilidad con soberanía.

El gran reto no es solo elegir dónde ejecutar cargas de trabajo, sino cómo evitar quedar atrapados en decisiones irreversibles. El temido vendor lock-in no siempre se manifiesta de manera evidente: puede aparecer en forma de dependencias contractuales, APIs propietarias o formatos cerrados que hacen extremadamente costoso migrar de proveedor. El CIO y el arquitecto de datos deben anticipar este riesgo desde el diseño inicial de la arquitectura.

En este capítulo exploraremos con una mirada crítica y práctica:

• Cuándo conviene mantener cargas on-premise y cuándo migrarlas a la nube.

• Qué significa realmente operar en un entorno multicloud y cuáles son sus beneficios y trampas.

• Qué estrategias permiten minimizar el vendor lock-in sin renunciar a la innovación.

Además, presentaremos un checklist operativo con preguntas clave para CIOs y arquitectos, y un caso práctico que ilustra cómo una aseguradora tradicional migró hacia un modelo híbrido-multicloud, aprendiendo de sus errores y maximizando sus ventajas competitivas.

La tesis central es clara: el stack tecnológico de datos no es un proyecto de IT, es una decisión de negocio. Afecta al coste, a la velocidad de respuesta frente a oportunidades, a la resiliencia frente a incidentes y, en última instancia, a la capacidad de la empresa para competir en un mercado donde los datos ya no son un subproducto, sino el activo principal.

Por qué importa el stack tecnológico en datos

El stack tecnológico de datos es mucho más que un conjunto de herramientas. Es el esqueleto sobre el que se articula toda la estrategia digital de una organización. Cuando hablamos de stack, hablamos de las bases de datos, plataformas de integración, motores analíticos y servicios cloud que definen la forma en que los datos fluyen, se transforman y se convierten en conocimiento accionable. En otras palabras: es la columna vertebral de la empresa data-driven.

Un error frecuente entre directivos es ver el stack como un tema exclusivamente técnico, delegado al área de IT. Sin embargo, cada decisión tecnológica tiene repercusiones directas en el negocio: en la rapidez con la que se pueden lanzar nuevos productos, en la agilidad para adaptarse a normativas cambiantes, en la resiliencia frente a ciberataques o desastres, e incluso en la capacidad de atraer y retener talento. Un CIO que subestima este impacto puede encontrarse con una organización atrapada en la obsolescencia o con costes desbordados que erosionan la competitividad.

El stack como generador (o destructor) de valor

La calidad de un stack no se mide únicamente en benchmarks de rendimiento. Se mide en términos de ROI:

• ¿Cuánto reduce el time-to-market de una iniciativa de datos?

• ¿Cuánto mejora la toma de decisiones en los equipos de negocio?

• ¿Qué margen de maniobra deja para experimentar con IA, analítica avanzada o nuevos canales digitales?

Una compañía con un stack flexible puede lanzar un dashboard ejecutivo en semanas, mientras otra, atrapada en una arquitectura rígida, tarda meses en entregar la misma funcionalidad. Ese diferencial de velocidad se traduce en oportunidades perdidas o capturadas.

Ejemplos de errores comunes

• El banco con base de datos propietaria: una entidad financiera decidió en los 2000 estandarizar toda su analítica en un motor propietario. Una década después, migrar a cloud y modernizar sus modelos de riesgo resultaba casi imposible: cada pipeline estaba escrito en SQL dialectal exclusivo, sin portabilidad. El coste de migración se estimaba en decenas de millones, lo que obligó a convivir con un stack obsoleto durante años.

• La startup que apostó sin gobernanza por el cloud: un retailer digital levantó toda su plataforma de datos en la nube, aprovechando la elasticidad para crecer rápidamente. Pero nunca implementaron políticas de cost governance. El resultado: una factura de infraestructura que crecía más rápido que sus ingresos. El stack, en lugar de habilitador, se convirtió en lastre financiero.

• La empresa industrial que ignoró la escalabilidad: un fabricante apostó por un stack on-premise para gestionar datos IoT de su maquinaria. El volumen de datos creció exponencialmente y, en tres años, la infraestructura quedó saturada. Ampliarla suponía una inversión en CAPEX millonaria, mientras sus competidores cloud-native avanzaban con agilidad.

Stack y resiliencia empresarial

El stack tecnológico también condiciona la capacidad de una empresa para responder ante crisis. Una plataforma con observabilidad avanzada, mecanismos de recuperación ante desastres y redundancia multicloud puede absorber incidentes sin interrumpir el negocio. En cambio, una arquitectura centralizada y sin planes de contingencia convierte cualquier caída en un riesgo reputacional.

El COVID-19 fue un gran test: empresas con stacks elásticos pudieron escalar rápidamente sus canales digitales, mientras otras quedaron bloqueadas porque su infraestructura no podía absorber el cambio en patrones de consumo.

On-premise vs cloud: más allá de la dicotomía

Durante años, el debate sobre dónde alojar la infraestructura de datos se resumía en una pregunta simplista: ¿on-premise o cloud?. Pero hoy, con la madurez de la tecnología y la diversidad de escenarios de negocio, esa dicotomía se ha quedado corta. La realidad no es blanco o negro, sino una paleta de grises que combina entornos propios, servicios cloud y modelos híbridos.

Para tomar decisiones inteligentes, CIOs y arquitectos necesitan ir más allá de los tópicos y comprender las ventajas, limitaciones y riesgos reales de cada modelo.

La herencia on-premise

El modelo on-premise —infraestructura propia en centros de datos corporativos— ha sido durante décadas el estándar. Para muchas empresas, sigue siendo sinónimo de control absoluto: servidores bajo custodia física, sistemas diseñados a medida, costes predecibles y, sobre todo, soberanía sobre los datos.

Los sectores regulados son su territorio natural:

• Banca y seguros: la regulación exige control sobre datos sensibles, auditorías detalladas y cumplimiento estricto de normativas como Basilea III o Solvencia II.

• Sanidad: en muchos países, las leyes de protección de datos de salud limitan la transferencia de información a entornos cloud.

• Defensa y sector público: la seguridad nacional impone mantener ciertos datos en infraestructuras controladas directamente.

Ventajas principales:

• Control total: desde la capa física hasta la lógica.

• Cumplimiento más directo: sin depender de contratos de terceros.

• Previsibilidad de costes: tras la inversión inicial, los gastos se estabilizan en OPEX reducido.

Limitaciones:

• Elasticidad nula: si necesitas duplicar capacidad, debes comprar y desplegar hardware, con meses de demora.

• Ciclos de innovación lentos: cada nueva tecnología requiere adquisiciones, licencias y pruebas in-house.

• Altos costes de mantenimiento: energía, personal de soporte, renovaciones de hardware.

Un ejemplo ilustrativo: una entidad bancaria española que en 2015 quiso experimentar con modelos de credit scoring basados en machine learning. El despliegue de un entorno de pruebas on-premise tardó ocho meses. En ese tiempo, fintechs nacidas en la nube ya ofrecían scoring instantáneo a clientes, robando cuota de mercado.

La promesa (y la trampa) del cloud

El cloud computing revolucionó la arquitectura de datos al ofrecer capacidades bajo demanda: elasticidad, servicios gestionados y despliegues en cuestión de horas. Para startups y sectores dinámicos (retail, medios, e-commerce) fue un acelerador natural.

Ventajas evidentes:

• Elasticidad inmediata: crecer o reducir capacidad con unos clics.

• Acceso a innovación constante: servicios avanzados de IA, machine learning, integración o seguridad gestionada.

• Globalización: presencia en múltiples regiones con baja latencia.

• Menor CAPEX inicial: se convierte en gasto operativo, evitando grandes inversiones upfront.

Limitaciones reales:

• Costes impredecibles: un workload constante en cloud puede costar más que mantenerlo on-premise a medio plazo.

• Vendor lock-in: la dependencia de APIs y servicios propietarios complica migraciones.

• Compliance complejo: sectores regulados necesitan demostrar controles de seguridad compartidos.

• Networking y egress: mover datos fuera del cloud tiene costes ocultos.

Un retailer global es buen ejemplo: durante Black Friday, escalaron en AWS para atender picos de tráfico masivo. La elasticidad fue crítica. Pero tras el evento, la factura de red superó el presupuesto anual estimado en infraestructura. La nube les dio ventaja, pero también una lección de cloud cost governance.

Coste total vs coste de oportunidad

La comparación más repetida —costes on-premise frente a cloud— es engañosa. Si se miran únicamente los euros invertidos en hardware frente a facturación mensual, el análisis queda incompleto.

El verdadero diferencial está en el coste de oportunidad.

• ¿Qué negocio pierdo si tardo seis meses en desplegar una nueva plataforma analítica por falta de elasticidad?

• ¿Cuánto me cuesta no poder experimentar rápido con IA porque montar un laboratorio interno es lento y caro?

Una pyme industrial que adoptó un stack cloud-first logró desplegar su primer sistema de predicción de fallos en maquinaria en tres semanas. Su competidor, con infraestructura on-premise, tardó nueve meses en poner en marcha un piloto. El primero ganó contratos porque pudo demostrar valor de inmediato, aunque su factura cloud inicial fuera superior.

Seguridad y cumplimiento: mito vs realidad

Existe el mito de que “el cloud es menos seguro”. En realidad, los hyperscalers invierten miles de millones en seguridad: cifrado, segmentación, control de accesos, certificaciones. Ninguna empresa individual puede igualar esa escala.

El reto no es la seguridad de la nube, sino el modelo de responsabilidad compartida. El proveedor asegura la infraestructura, pero la configuración, gestión de identidades, cifrado de datos en tránsito y políticas de acceso recaen en la empresa.

En on-premise ocurre lo contrario: tienes control total, pero también toda la responsabilidad. Y si no cuentas con el talento y presupuesto adecuados, la seguridad puede ser inferior a la que te ofrece un proveedor cloud.

¿Un escenario ganador?

La respuesta, como siempre, depende del contexto:

• Organizaciones con datos altamente sensibles o normativas estrictas → on-premise o híbrido con mínima nube pública.

• Startups y empresas de rápido crecimiento → cloud-first con estrategia de gobernanza de costes.

• Empresas consolidadas con cargas mixtas → híbrido progresivo, priorizando migrar workloads con mayor beneficio en la nube.

El CIO debe evitar caer en discursos dogmáticos. No se trata de cloud vs on-premise, sino de optimizar cada carga de trabajo en el entorno que maximiza valor y minimiza riesgo.

El escenario multicloud y cloud híbrido

Si en la primera década del cloud la pregunta era “¿migramos o no migramos?”, hoy la pregunta es otra: ¿cómo combinamos distintos entornos sin perder control ni eficiencia?. Muy pocas empresas son 100% on-premise, y muy pocas son 100% cloud. La realidad de los equipos de datos es mucho más matizada: infraestructuras heredadas que conviven con servicios en la nube, departamentos que han contratado proveedores distintos según sus necesidades, o directivas corporativas que buscan diversificación para no depender de un único vendor.

Aquí nacen dos conceptos clave en la arquitectura moderna de datos: cloud híbrido y multicloud. Aunque a menudo se usan como sinónimos en conferencias o marketing, no son lo mismo.

Cloud híbrido: lo mejor de dos mundos

El cloud híbrido se refiere a una arquitectura en la que coexisten recursos on-premise y cloud público, integrados de manera intencional.

• En sectores regulados, esto permite mantener datos sensibles en on-premise y usar la nube para cargas experimentales o de escala variable.

• En empresas industriales, lo híbrido facilita procesar datos de sensores en plantas (edge + on-premise) y consolidarlos en cloud para analítica avanzada.

Un buen ejemplo lo encontramos en farmacéuticas globales. La información clínica, por regulación, debe mantenerse bajo custodia directa. Sin embargo, los modelos de simulación y análisis genómico, altamente intensivos en cómputo, corren en clusters cloud. Esta combinación optimiza seguridad y capacidad de innovación.

Ventajas:

• Flexibilidad para balancear cargas según criticidad.

• Optimización de costes (usar cloud para picos, on-premise para cargas estables).

• Cumplimiento normativo más sencillo.

Riesgos:

• Complejidad de integración entre entornos.

• Necesidad de observabilidad unificada: métricas y logs dispersos.

• Riesgo de silos si no se gobierna bien la arquitectura.

Multicloud: estrategia o accidente

El término multicloud describe el uso de más de un proveedor de nube pública en la misma organización. Aquí conviene diferenciar dos realidades:

• Multicloud accidental: ocurre cuando distintas áreas contratan diferentes proveedores sin coordinación. Un equipo de marketing usa GCP, finanzas contrata Azure, IT tiene cargas en AWS. Esto suele generar caos: duplicación de costes, falta de skills, y complejidad innecesaria.

• Multicloud estratégico: se planifica intencionalmente para capturar beneficios específicos.

Motivaciones estratégicas para multicloud

1. Best-of-breed: elegir el mejor servicio de cada proveedor. Ejemplo: BigQuery (GCP) para analítica masiva, AWS para cargas transaccionales y Azure para integración con Office 365.

2. Resiliencia y continuidad: mitigar el riesgo de caída de un proveedor. Aunque raro, las interrupciones masivas de AWS o Azure han demostrado que incluso los gigantes tienen vulnerabilidades.

3. Negociación y costes: diversificar proveedores da más poder de negociación en contratos y precios.

Retos reales del multicloud

Aunque suene bien sobre el papel, multicloud introduce una complejidad nada trivial:

• Networking y latencia: mover datos entre clouds implica costes de egress y posibles retardos.

• Gestión de identidades: distintos IAMs (Identity and Access Management) obligan a duplicar políticas.

• Observabilidad fragmentada: logs y métricas en plataformas diferentes, sin un punto único de visibilidad.

• Talento y skills: formar equipos capaces de dominar tres nubes es caro y poco realista.

Un caso real: una telco europea decidió apostar por AWS para core transaccional y GCP para analítica. El proyecto arrancó con entusiasmo, pero pronto descubrieron que su equipo de datos no tenía la capacidad para operar dos ecosistemas a la vez. Terminaron creando un “equipo de integración multicloud” dedicado exclusivamente a resolver inconsistencias entre plataformas, un coste que no habían anticipado.

En contraste, un e-commerce global adoptó multicloud de forma más selectiva: su core de pedidos en AWS y su analítica en BigQuery (GCP). No intentaron replicar servicios entre clouds, sino aprovechar lo mejor de cada uno. El resultado: un stack más eficiente y resiliente, con costes controlados.

Multicloud no es para todos

Un error común es ver multicloud como un fin en sí mismo, cuando debería ser un medio. Muchas compañías medianas que intentan imitar a gigantes digitales terminan atrapadas en una maraña de contratos, pipelines redundantes y facturas incontrolables.

La recomendación de consultoría es clara:

• Multicloud solo tiene sentido con madurez organizativa suficiente y cuando el beneficio concreto (resiliencia, servicio diferencial, negociación) supera el coste de complejidad.

• Para la mayoría de empresas, un modelo híbrido con un proveedor cloud principal y on-premise estratégico es más eficiente.

En definitiva

Híbrido y multicloud no son mutuamente excluyentes. De hecho, muchas organizaciones acabarán operando ambos: híbridas por necesidad regulatoria y multicloud por estrategia de diversificación. Lo importante es que la elección no sea accidental ni impulsada por la moda, sino el resultado de un diseño arquitectónico consciente, soportado por gobernanza sólida y métricas claras.

El riesgo del vendor lock-in

Pocas expresiones generan tanta incomodidad en un comité de dirección como vendor lock-in. La dependencia excesiva de un único proveedor tecnológico se percibe como una amenaza directa a la soberanía de la empresa. Y, sin embargo, es una realidad con la que conviven la mayoría de organizaciones en algún grado. La cuestión no es tanto si habrá lock-in, sino qué nivel de dependencia es aceptable y cómo mitigarlo para que no se convierta en un lastre estratégico.

Qué entendemos por lock-in

El término se usa de manera amplia, pero conviene diferenciar los tipos más comunes:

1. Lock-in tecnológico:
   Ocurre cuando se adoptan servicios o APIs propietarias sin alternativa estándar. Ejemplo clásico: bases de datos en cloud con SQL dialectal exclusivo, funciones serverless que solo funcionan en un ecosistema concreto o motores de mensajería cerrados. Migrar implica reescribir código y pipelines completos.

2. Lock-in de datos:
   Los datos son el activo central. Si se almacenan en formatos cerrados o con costes de salida prohibitivos (egress fees), moverlos a otra plataforma se vuelve inviable. Aquí el problema no es técnico, sino económico.

3. Lock-in contractual:
   Menos visible, pero igual de importante. Algunos contratos incluyen cláusulas de permanencia, costes desproporcionados por rescindir antes de tiempo o limitaciones en la portabilidad de servicios.

Señales tempranas de dependencia

El lock-in raramente aparece de golpe. Suele instalarse de manera gradual, casi imperceptible, hasta que es demasiado tarde. Algunas señales de alerta para CIOs y arquitectos son:

• Cada nuevo servicio que se quiere desplegar requiere integrarse con APIs propietarias del proveedor.

• Los equipos de datos empiezan a usar funciones específicas que no existen en ningún otro stack.

• Migrar datasets implica reescribir transformaciones enteras porque los formatos no son estándar.

• Los costes de salida (egress) superan el presupuesto anual de IT.

• La empresa no tiene runbooks de contingencia ni métricas de portabilidad.

Casos reales de lock-in costoso

• La fintech atrapada en BigQuery: una startup europea construyó toda su capa analítica sobre BigQuery por su facilidad y velocidad. Tres años después, al intentar negociar mejores condiciones, descubrieron que migrar sus 400 TB de datos era económicamente prohibitivo por costes de egress y dependencia de funciones propietarias. El lock-in les restó poder de negociación y los obligó a aceptar precios al alza.

• La telco y el CRM en la nube: una compañía de telecomunicaciones integró todos sus procesos de facturación y atención al cliente en un CRM cloud líder. Al intentar cambiar de proveedor, descubrieron que gran parte de los flujos de integración estaban escritos con APIs exclusivas. La migración se presupuestó en 18 meses de trabajo y 12 millones de euros.

Estrategias de mitigación

Evitar el lock-in total es imposible. Usar un servicio implica cierto grado de dependencia. La clave está en diseñar arquitecturas resilientes, donde el coste de salida sea asumible y la organización mantenga poder de negociación.

Algunas prácticas recomendadas:

• Arquitecturas desacopladas: separar la lógica de negocio de los servicios cloud mediante capas intermedias (ej. usar Kafka o un middleware para eventos en lugar de APIs nativas exclusivas).

• Estándares abiertos: almacenar datos en formatos portables (Parquet, ORC, Avro), usar SQL estándar en lugar de dialectos propietarios, adoptar APIs REST/GraphQL documentadas.

• Infraestructura como código: definir despliegues en Terraform u otras herramientas que permitan replicar entornos en distintos proveedores.

• Política contractual activa: negociar desde el inicio cláusulas de salida razonables, soporte extendido para migraciones y transparencia en costes de transferencia.

• Estrategia de data gravity: mantener los datasets más críticos en entornos donde se pueda migrar con menor fricción, y reservar servicios altamente propietarios para cargas menos críticas.

El coste de salirse: una verdad incómoda

Migrar nunca es gratis. Incluso con todas las precauciones, mover una plataforma de datos completa implica:

• Reescritura de pipelines de ETL/ELT.

• Adaptación de modelos analíticos.

• Rediseño de seguridad e identidades.

• Nuevos acuerdos contractuales y auditorías.

El coste puede ser de millones y el plazo de años. Por eso, la recomendación práctica no es obsesionarse con evitar cualquier lock-in, sino aceptar que habrá cierto nivel y asegurarse de que es gestionable. El lock-in puede ser tolerable si el valor que se extrae (innovación, velocidad, eficiencia) compensa y si la empresa mantiene vías de salida razonables.

Lock-in como herramienta de negociación

Un enfoque más pragmático que se observa en empresas maduras es usar el lock-in a favor propio. Es decir:

• Reconocer la dependencia que se genera.

• Calcular el coste de salida realista.

• Usar ese coste como palanca en la negociación de precios y servicios.

Algunas compañías incluso hacen simulaciones de migración parciales como estrategia de presión: si AWS sabe que puedes mover tus cargas críticas a Azure en seis meses, tu poder de negociación crece.

Conclusión sobre el lock-in

El lock-in no es un enemigo absoluto, sino un riesgo que debe ser gestionado con madurez. El CIO y el arquitecto deben encontrar el equilibrio entre aprovechar la innovación propietaria de un proveedor y mantener la soberanía estratégica sobre los datos y la arquitectura. Ignorar el lock-in lleva a dependencia asfixiante; obsesionarse con evitarlo conduce a parálisis e ineficiencia. La clave está en el diseño consciente, las decisiones informadas y la gobernanza continua.

Checklist operativo para CIOs y arquitectos

Una guía estratégica está incompleta si no se traduce en acciones concretas. Este checklist está diseñado para que un CIO o un arquitecto de datos pueda evaluar de manera rápida y periódica la solidez de sus decisiones respecto al stack tecnológico y la elección de proveedores.

1. Evaluación inicial de cargas

• ¿Qué cargas de trabajo son críticas para el negocio y requieren control estricto (ej. compliance, core transaccional)?

• ¿Qué cargas son variables, experimentales o de menor criticidad (ej. analítica exploratoria, pruebas de AI)?

• ¿Existen cargas “legacy” que convenga mantener on-premise por coste de migración o estabilidad?

2. Estrategia cloud / on-premise

• ¿La decisión de mantener algo on-premise responde a criterios regulatorios, técnicos o simplemente inercia?

• ¿Existe un plan de transición gradual hacia cloud híbrido o multicloud, con hitos claros?

• ¿Se han definido SLOs (Service Level Objectives) y SLIs (Service Level Indicators) específicos para cada entorno?

3. Gestión del vendor lock-in

• ¿Los datos se almacenan en formatos estándar y portables (Parquet, ORC, Avro)?

• ¿Se ha calculado el coste de salida (migración + egress) para los datasets más críticos?

• ¿Las integraciones dependen de APIs propietarias exclusivas o existen capas de abstracción?

• ¿Se ha negociado explícitamente cláusulas contractuales de salida y soporte para migración?

4. Multicloud y complejidad operativa

• ¿El multicloud es accidental (por compras dispersas) o intencional (por estrategia)?

• ¿Existe un inventario actualizado de qué servicios están desplegados en qué proveedor?

• ¿Hay políticas unificadas de IAM (Identity and Access Management) y seguridad?

• ¿Se dispone de observabilidad transversal (logs, métricas, alertas) en todos los entornos?

5. Costes y FinOps de datos

• ¿Se monitorean en tiempo real los costes por proveedor, incluyendo egress y almacenamiento frío?

• ¿Existe un modelo de showback o chargeback para imputar costes a departamentos?

• ¿Se revisan anualmente las condiciones contractuales y descuentos por volumen?

6. Plan de contingencia y resiliencia

• ¿Hay un plan documentado de continuidad operativa en caso de caída del proveedor principal?

• ¿Se han hecho pruebas de migración parcial o fire drills de recuperación en otro entorno?

• ¿Se dispone de runbooks y automatizaciones para mover cargas críticas en caso de emergencia?

7. Talento y capacidades

• ¿El equipo tiene las competencias necesarias para operar la complejidad híbrida o multicloud?

• ¿Se ha definido un plan de capacitación continua en servicios cloud y gestión de datos distribuidos?

• ¿Existe un modelo de gobierno que asigne roles claros (data owners, stewards, arquitectos)?

Recomendación final del checklist

No se trata de responder sí a todas las preguntas, sino de identificar dónde están los puntos ciegos y diseñar una hoja de ruta de mejora. Un CIO debería repetir esta evaluación cada trimestre y usarla como insumo para conversaciones con proveedores, comité ejecutivo y equipo de datos.

Caso práctico: la aseguradora que migró a un modelo híbrido-multicloud

En 2017, una de las principales aseguradoras de salud en España se enfrentaba a un dilema. Su infraestructura de datos, construida durante más de una década sobre sistemas on-premise en dos data centers propios, empezaba a mostrar claros signos de agotamiento. Las consultas de clientes tardaban minutos en lugar de segundos, los procesos batch de facturación se prolongaban durante la noche con riesgo de incumplir SLA, y el equipo de IT pasaba más tiempo “apagando fuegos” que impulsando innovación.

La dirección sabía que debía actuar. Al mismo tiempo, la empresa estaba sometida a una estricta regulación de la CNMV y la Agencia Española de Protección de Datos, lo que impedía un movimiento directo a un modelo 100% cloud. La decisión no era trivial: había que encontrar el equilibrio entre cumplimiento normativo, agilidad tecnológica y sostenibilidad económica.

La hoja de ruta inicial: “cloud-first, pero con cautela”

El CIO impulsó un programa llamado Data 2020, cuyo objetivo era transformar la plataforma de datos en tres años. La estrategia se resumía en una frase: cloud-first, pero con cautela. Esto significaba que:

• Las cargas críticas de clientes y pólizas permanecerían on-premise.

• Los sistemas de analítica avanzada y data science se desplegarían en la nube para ganar elasticidad.

• Se evaluaría un modelo multicloud para evitar dependencia de un solo proveedor.

El plan sonaba sólido sobre el papel, pero pronto se evidenciaron los retos de llevarlo a la práctica.

Primeros pasos: mover lo no regulado

El primer movimiento fue migrar la plataforma de business intelligence. Hasta entonces, los dashboards ejecutivos se generaban en un sistema de reporting heredado que tardaba horas en consolidar información. La aseguradora optó por BigQuery en Google Cloud, integrando allí los datasets de operaciones, marketing y ventas.

La mejora fue inmediata: consultas en segundos, autoservicio para analistas y capacidad de escalar sin preocuparse por servidores físicos. El impacto en negocio se notó rápidamente: los equipos comerciales podían lanzar campañas más segmentadas y medir resultados casi en tiempo real.

El giro hacia multicloud: presión regulatoria y negociación

El verdadero desafío llegó un año después, cuando la CNMV reforzó los requisitos de supervisión sobre proveedores de servicios cloud. La normativa obligaba a demostrar que existía un plan de contingencia en caso de caída del proveedor principal. En otras palabras: la aseguradora debía tener una estrategia multicloud, aunque no estuviera en sus planes iniciales.

El CIO decidió entonces diversificar.

• AWS se convirtió en la plataforma principal para cargas de data science, aprovechando SageMaker y su ecosistema de ML.

• GCP se mantuvo como entorno de analítica y BI.

• El core de clientes siguió en on-premise.

De este modo, la empresa configuró un entorno híbrido-multicloud, no tanto por ambición tecnológica, sino por imperativo regulatorio.

Los retos operativos: donde se paga el precio

El movimiento no estuvo exento de costes. Entre los principales obstáculos:

• Gestión de identidades: el equipo debía mantener políticas IAM en dos nubes distintas, además de on-premise. La solución fue desplegar un sistema centralizado de federación de identidades (Okta), pero no sin meses de fricción.

• Costes de egress: al mover datos entre AWS y GCP, las facturas de transferencia crecieron un 20% más de lo presupuestado. La aseguradora tuvo que rediseñar pipelines para minimizar movimientos innecesarios.

• Capacitación del equipo: muchos ingenieros estaban familiarizados con Oracle y entornos legacy, pero no con Terraform ni Kubernetes. Se invirtió en un plan intensivo de reskilling.

Lecciones aprendidas

Después de tres años, la aseguradora completó la transición y compartió internamente un documento de aprendizajes que resulta muy revelador:

1. El multicloud impuesto por regulación es más complejo de lo que parece. No basta con replicar cargas, hay que diseñar pipelines que respeten latencia, costes y gobernanza.

2. El lock-in nunca desaparece, solo cambia de forma. Ahora dependen de GCP para analítica y de AWS para ML, pero mitigaron el riesgo contractual al negociar cláusulas de salida más flexibles.

3. El talento es el factor limitante. La tecnología estaba disponible, pero sin arquitectos capaces de entender tres ecosistemas a la vez, el programa habría fracasado.

4. La observabilidad es crítica. Unificar métricas, logs y alertas en una sola capa (con Datadog como solución transversal) fue la clave para mantener control operativo.

El balance final

¿Valió la pena? Sí, aunque con matices.

• Resultados positivos: dashboards en segundos, modelos de predicción de fraude más precisos y capacidad de escalar sin límites físicos. El negocio ganó agilidad real.

• Costes añadidos: un sobrecoste operativo del 15% en el primer año por duplicidad de proveedores y falta de experiencia.

• Madurez organizativa: el mayor logro fue cultural. La compañía pasó de ser una aseguradora con sistemas legacy a convertirse en un jugador que maneja un stack híbrido-multicloud con visión estratégica.

Conclusión del caso

El viaje de esta aseguradora ilustra un punto esencial: las decisiones sobre stack tecnológico no ocurren en el vacío. Están condicionadas por regulación, talento interno, costes reales de operación y presiones de negocio. Adoptar un modelo híbrido-multicloud no fue su primera opción, pero terminó siendo la única viable para equilibrar innovación y cumplimiento.

Su historia refleja la lección que todo CIO debería grabar en piedra: la arquitectura de datos no es solo tecnología, es estrategia de negocio en acción.

Conclusión final

La elección del stack tecnológico de datos es una de esas decisiones que marcan el rumbo de la empresa durante años. No es comparable a escoger una herramienta puntual o un proveedor de soporte: se trata de definir el terreno sobre el que se construirán las capacidades de análisis, inteligencia artificial, automatización y toma de decisiones que diferenciarán a la organización en su sector.

Hemos visto que la dicotomía on-premise vs cloud es simplista. La mayoría de organizaciones terminan adoptando modelos híbridos, y cada vez más, estrategias multicloud que responden a presiones regulatorias, necesidades de resiliencia o búsqueda de competitividad en costes. Sin embargo, este movimiento no es gratis: implica mayor complejidad técnica, nuevos retos de gobernanza y la necesidad de talento especializado capaz de operar en ecosistemas distribuidos.

El vendor lock-in aparece como el gran riesgo de fondo. No se trata de demonizarlo, porque cierto grado de dependencia es inevitable y, en muchos casos, incluso deseable si a cambio se gana velocidad y capacidad de innovación. La clave está en diseñar arquitecturas con salidas razonables, negociar contratos pensando en el largo plazo y mantener siempre la soberanía sobre los datos como principio irrenunciable.

El caso de la aseguradora ilustra algo fundamental: estas decisiones no se toman en un laboratorio, sino en el campo de batalla de la regulación, la presión por innovar y la necesidad de controlar costes. La arquitectura de datos no es una fotografía estática, sino un sistema vivo que evoluciona junto con el negocio.

Por eso, la verdadera responsabilidad del CIO y del arquitecto de datos no es perseguir cada nueva tecnología, sino construir un ecosistema robusto, flexible y gobernado, capaz de adaptarse al cambio. La pregunta que deberían hacerse no es “¿qué stack nos conviene hoy?”, sino “¿qué decisiones nos darán libertad de maniobra y sostenibilidad en los próximos cinco años?”.

En última instancia, el stack tecnológico de datos es el lenguaje en el que la empresa conversa con sus propios datos. Elegirlo bien no significa simplemente ahorrar costes o mejorar métricas de latencia: significa garantizar que la organización puede transformar datos en conocimiento, conocimiento en decisiones y decisiones en valor tangible. Esa es la esencia de la ventaja competitiva en la era digital.