La compra de Wiz por parte de Google confirmó una tendencia que ya estaba en marcha: los grandes proveedores de nube a gran escala, los hyperscalers, quieren que la seguridad forme parte del núcleo de la plataforma y deje de ser un complemento externo. Esta transacción, que se realizó por 32 mil millones de dólares, se presentó como una apuesta para acelerar la protección de cloud y multicloud.
Esto no representa solo una novedad corporativa. Implica un cambio en el equilibrio entre la eficiencia operativa de hoy y el margen de maniobra de mañana. La integración nativa puede simplificar procesos y reducir costos. Sin embargo, también puede profundizar el vendor lock-in, es decir, una dependencia difícil de revertir, con costos ocultos y una menor capacidad de negociación.
La conclusión práctica apunta a evitar decisiones tajantes. En 2026, la estrategia más sólida para una empresa con alcance global suele apoyarse en un modelo híbrido con “derecho de salida”. Esto implica aprovechar las herramientas nativas cuando aportan velocidad y control y, al mismo tiempo, mantener independencia en áreas que necesitan flexibilidad.
Índice de temas
¿Qué es la seguridad cloud integrada y por qué está desplazando a los complementos externos?
Durante años, muchas empresas trataron la seguridad cloud como una capa adicional mediante la utilización de herramientas especializadas de terceros que intentaban cubrir el ecosistema. El problema, que cualquier director de TI conoce de primera mano, resultó evidente. Más instrumentos no implicaron más control, sino más integraciones y, por ende, una mayor fricción operativa.
El caso de Wiz ayuda a entender por qué el mercado avanzó hacia una lógica de plataforma. La Comisión Europea definió a esta compañía como una CNAPP (Cloud-Native Application Protection Platform), es decir, una plataforma única para proteger aplicaciones a través de distintos entornos cloud.
La lectura estratégica para la dirección es clara. Cuando un hyperscaler internaliza las capacidades best-in-class, como una CNAPP, apunta a controlar toda la experiencia de punta a punta, desde la gestión de identidades y la configuración hasta la detección y la respuesta ante incidentes. Esa integración puede elevar el estándar de seguridad para el cliente y simplificar la operación diaria.
Sin embargo, también incrementa la gravedad del proveedor, es decir, el peso que adquiere dentro de la arquitectura tecnológica y la dificultad de reemplazarlo sin tener que hacer una erogación económica importante.
¿Cuáles son las ventajas de la seguridad cloud nativa frente a otros modelos?
La seguridad nativa del hyperscaler suele imponerse en tres frentes que cualquier CIO identifica de inmediato:
- Velocidad de despliegue
- Simplificación operativa
- Alineación con el ritmo de innovación del proveedor
Rentabilidad y simplificación como primer driver de adopción
En primer lugar, el incentivo económico y de simplificación pesa en la decisión. Forrester, al comparar distintos modelos de CNAPP, planteó un trade-off útil para la mesa ejecutiva:
- Las soluciones cloud-native tienden a ser más rentables, aunque pueden presentar brechas en entornos multicloud.
- En el otro extremo, un esquema con múltiples herramientas puntuales puede resultar más agnóstico, pero también más costoso.
El crecimiento del gasto confirma que la seguridad cloud es prioridad estratégica
En segundo término, el volumen de inversión confirma que la seguridad cloud dejó de ser un tema marginal. Gartner proyectó que el gasto mundial en seguridad alcanzará los 240 mil millones de dólares en 2026.
Además, señaló que el software de protección registrará el mayor crecimiento a partir del avance hacia la nube, con especial impulso de soluciones como:
- CSPM (Cloud Security Posture Management, gestión de postura y configuración)
- CASB (Cloud Access Security Broker, control de acceso y uso de servicios cloud).
La automatización y la IA llevan la seguridad al centro del desarrollo
En tercer lugar, la inteligencia artificial empujó la seguridad hacia el corazón del desarrollo y la operación. IDC indicó que la automatización será indispensable para acompañar prácticas de desarrollo más exigentes y que la GenAI actuará como capa de abstracción entre usuarios y herramientas de seguridad.
En esa línea, estimó que para 2027 el 40% de las empresas habilitará esquemas para desarrolladores y dueños de aplicaciones mediante automatización con IA, incluida la generación de políticas a partir de instrucciones en lenguaje natural.
La complejidad híbrida acelera la adopción de controles nativos
Por último, hay un factor humano que vuelve atractivo lo nativo: la realidad híbrida y multicloud. En este sentido, Cloud Security Alliance reportó que:
Los controles nativos permiten acelerar mejoras concretas, ya que operan cerca del plano de control del proveedor y facilitan una respuesta más directa ante los riesgos.
¿El vendor lock-in en cloud es un riesgo estratégico o un costo asumible?
El riesgo ya no pasa por usar cloud. El verdadero problema aparece cuando tu compañía queda atrapada en una combinación de tecnología, contratos, datos, habilidades internas y estructura de costos que dificulta cualquier cambio.
Satisfacción con el proveedor, pero prioridad por mantener las opciones
Boston Consulting Group le puso números a esa ambivalencia:
El mensaje es claro. Incluso cuando existe satisfacción con el proveedor, la opcionalidad se mantiene como prioridad, porque la dependencia se percibe como un riesgo estratégico.
Además, salir no representa un proceso sencillo. El informe señaló que, ante un cambio de plataforma, las empresas expresaron alta preocupación por:
- La migración técnica (75%)
- La pérdida de productividad (64%)
- Y el downtime (63%)
En términos ejecutivos, la dependencia se transforma en costo de oportunidad y en riesgo operativo concreto.
Egress fees, interfaces propietarias y habilidades no transferibles como frenos estructurales
El regulador británico llevó el debate al terreno específico del cloud. En su decisión final resumida, la CMA indicó que menos del 1% de los clientes cambia de proveedor por año y atribuyó esa baja movilidad a barreras comerciales y técnicas.
- Entre las barreras comerciales destacó las egress fees, es decir, los cargos por transferir datos fuera del proveedor.
- Entre las técnicas, mencionó la diferenciación de interfaces y funcionalidades, además de la latencia y la falta de habilidades transferibles.
El riesgo no desaparece con competencia: cambia de forma
Por otro lado, el caso Google–Wiz mostró que incluso los reguladores analizaron el riesgo de empaquetamiento. La Comisión Europea evaluó la posibilidad de bundling y concluyó que existirían competidores creíbles a los que los clientes podrían migrar si Google integrara Wiz con su oferta o si Wiz dejara de operar con otras nubes.
Esto no elimina el riesgo. Lo cambia. Aunque la salida resulte posible en teoría, la pregunta pasa por determinar si esa salida es viable en términos de costo, tiempo y exposición operativa.
¿Cómo elegir el modelo de seguridad cloud según el escenario y evitar dependencia excesiva?
Para evitar discusiones abstractas, conviene ordenar la decisión según escenarios operativos concretos. Por eso, desde Innovación Digital 360 les presentamos la siguiente tabla que resume dichos puntos:
| Escenario | Elección recomendada | Condición de éxito (no negociable) |
|---|---|---|
| Single-cloud | Seguridad nativa del hyperscaler | Plan de salida probado + portabilidad de evidencia |
| Multicloud | Herramientas independientes (CNAPP/controles transversales) | Gobierno unificado de identidades y políticas entre nubes |
| Mixto (core en 1 nube + satélites) | Modelo híbrido (nativo + capa común) | Evitar duplicación: definir “qué controla cada capa” |
Acciones concretas para preservar la capacidad real de salida
Sin tecnicismos y con foco en dirección, estos puntos ayudan a mantener margen de maniobra:
- Convertir el exit en un entregable concreto: definir un plan de salida con tiempos e impacto estimado. Si no está modelado, se debe dejar explícito. Además, se deben realizar pruebas periódicas de migración parcial para validar supuestos.
- Negociar la exportación de datos y evidencia: asegurarse por contrato la posibilidad de extraer hallazgos, logs y evidencias de cumplimiento en formatos comunes y legibles por máquina.
- Medir y gobernar el costo de egress y switching: la CMA identificó las egress fees como barrera central para cambiar de proveedor o sostener estrategias multicloud. Si no lo medís, no lo podés gestionar.
- Separar el control de reporting: utilizar herramientas nativas donde el proveedor tiene ventaja clara, pero también garantizar la visibilidad transversal cuando se opera en multicloud o bajo presión regulatoria.
- Evitar que la automatización quede cautiva: de integrar seguridad en DevOps con IA, se debe exigir la portabilidad de políticas y procesos para no reconstruir todo ante un eventual cambio de proveedor.
- Establecer un gobierno interáreas: Gartner recomendó formalizar la coordinación entre legal, negocio y compras ante mayor exigencia regulatoria y riesgo de incumplimiento. La nube dejó de ser solo un tema técnico.
- Exigir transparencia de costos: un esquema sólido de FinOps y control de consumo reduce sorpresas y mejora la posición negociadora.
Más allá de la arquitectura elegida, la importante pasa por preservar la capacidad real de salida. Porque la pregunta estratégica es si podés cambiar de proveedor sin poner en riesgo la operación ni el presupuesto.
¿Cuáles son las recomendaciones ejecutivas clave para gestionar seguridad cloud y lock-in?
La consolidación no responde a una moda pasajera. Refleja un escenario en el que la seguridad dejó de funcionar como un silo aislado. Con ese diagnóstico sobre la mesa, la discusión ya no pasa por sumar herramientas, sino por definir cómo se gobierna la seguridad dentro de la estrategia tecnológica.
| Eje estratégico | Qué implica | Acción clave |
|---|---|---|
| Seguridad como plataforma | Deja de ser un silo y se integra a la estrategia tecnológica | Gobernanza alineada a negocio, no suma de herramientas |
| Decidir por portafolio | Priorizar velocidad sin perder portabilidad | Definir desde el inicio qué debe poder migrarse |
| Lock-in como KPI | Medir dependencia y costos de salida | Gestionar el riesgo de forma consciente |
| Derecho de salida | Salida técnica y contractual viable | Documentar, negociar y probar planes de migración |
En otras palabras, la integración de seguridad dentro de los hyperscalers puede aportar eficiencia y elevar el estándar operativo. Pero también se debe equilibrar esa eficiencia con libertad estratégica. Porque la ventaja real radica en preservar opciones para el futuro.
