Por Gerardo Pazos, Country Manager México, SUSE
Cuando un consejo de administración discute soberanía digital, la conversación tiende hacia lo abstracto: jurisdicciones, regulación, geopolítica. Es comprensible, pero es incompleto. La soberanía de una organización no se decide en esos foros; se decide en reuniones mucho menos visibles, donde alguien elige qué sistema operativo correrá en los servidores, qué capa de virtualización sostendrá las aplicaciones, quién controlará la orquestación de contenedores y sobre qué plataforma se ejecutarán los modelos de inteligencia artificial. Son decisiones de arquitectura. Y la arquitectura es donde la soberanía se gana o se pierde.
Cinco capas, una misma pregunta
Una forma útil de pensarlo es recorrer la infraestructura de abajo hacia arriba y hacer, en cada capa, la misma pregunta: ¿quién controla esto?
- El sistema operativo es la primera capa. Todo lo demás corre sobre él; si su código no es auditable, nada de lo que está encima lo es del todo.
- La virtualización es la segunda. Quien haya seguido de cerca los cambios recientes en ese mercado sabe que las condiciones de una licencia pueden transformarse de un ciclo a otro sin que el cliente tenga voz en la decisión, y que el costo de esa transformación rara vez estaba presupuestado.
- La orquestación de contenedores es la tercera. El plano de control de Kubernetes decide qué se despliega, dónde y bajo qué políticas; si ese plano es opaco o depende de un solo proveedor, la portabilidad que promete la nube se vuelve teórica.
- La seguridad y la cadena de suministro del software son la cuarta. Una organización que no puede rastrear el origen de cada componente que corre en producción no puede afirmar, ante un regulador o ante su propio consejo, que controla su infraestructura.
- Y la plataforma de inteligencia artificial es la quinta: la que más rápido está creciendo y la que menos se está examinando con este lente.
En cada una de esas capas caben tres preguntas: ¿podemos auditarlo?, ¿podemos modificarlo o reemplazarlo?, ¿quién, fuera de nosotros, puede acceder a ello o interrumpirlo? Donde la respuesta es incómoda, ahí está la dependencia.
¿Por qué una base cerrada no alcanza?
La respuesta honesta es que no se puede ser soberano sobre infraestructura propietaria. No por una objeción de principio, sino por una limitación práctica: una plataforma cerrada no puede auditarse a fondo, no puede bifurcarse si el proveedor cambia de rumbo y no puede migrarse sin que el costo de salida lo fije la otra parte. A eso se suma la dimensión jurisdiccional: un proveedor sujeto a las leyes de otro país, puede verse obligado a entregar acceso a datos o a modificar su servicio bajo reglas que la organización mexicana nunca aceptó ni negoció.
El mercado ya lo está registrando. En una investigación de SUSE entre cerca de 600 líderes tecnológicos de cinco países, el 39% de las empresas de Estados Unidos expresa preocupación por reducir el vendor lock-in, la proporción más alta de todos los países, frente a un promedio global del 25%. Es un dato revelador: el país con el ecosistema tecnológico más maduro es también el que con mayor claridad ha entendido lo que cuesta quedar atado.
Lo que sí permite el open source empresarial
El open source empresarial ofrece exactamente lo que una base cerrada niega: auditabilidad completa del código, capacidad de bifurcar si hace falta, transparencia sobre la cadena de suministro y libertad para operar con varios proveedores a la vez. Conviene precisar el adjetivo. No se trata de software comunitario sin gobierno ni soporte; se trata de plataformas abiertas con respaldo empresarial, ciclos de vida definidos y responsabilidad contractual. Esa combinación es la que permite negociar en condiciones de igualdad, y la que convierte una convicción sobre la soberanía en una capacidad operativa.
Convivir con los hyperscalers, sin depender de ellos
Nada de esto implica renunciar a la nube pública. En el estudio de resiliencia digital de SUSE, el 65% de las organizaciones encuestadas reconoce que los hyperscalers seguirán siendo relevantes para sus cargas de trabajo soberanas, y tienen razón: su escala y su ritmo de innovación son difíciles de replicar. La diferencia está en el diseño. Una organización puede usar intensamente un gran proveedor y seguir siendo soberana si la capa que gobierna sus cargas de trabajo es abierta y portable, es decir, si puede salir. Lo que compromete la soberanía no es usar la nube, sino haber construido sobre ella de una manera que hace impensable dejarla.
Para un director de tecnología en México, con presupuestos que hoy se examinan con más cuidado que hace unos años, la pregunta es concreta: si mañana un proveedor cambiara sus condiciones, ¿cuánto tiempo y cuánto dinero nos costaría migrar? Si la respuesta no existe, o si nadie quiere decirla en voz alta, ya se sabe en qué capa está el problema.
Compartir nota:
