El 12 de junio, miles de organizaciones se enfrentaron a una realidad incómoda sobre las herramientas de inteligencia artificial que habían empezado a integrar en sus operaciones: no tenían control sobre ellas.
El Gobierno de Estados Unidos emitió una directiva de control de exportaciones que afectaba a dos modelos de Anthropic. La compañía respondió desactivándolos para todos sus clientes. Aunque las restricciones se levantaron después, el episodio dejó una pregunta inquietante: ¿qué ocurre cuando el acceso a una herramienta crítica depende de decisiones que tu organización no toma ni controla?
La situación recordó a otros episodios recientes: caídas de servicios en la nube, interrupciones de plataformas y fallos tecnológicos que afectaron a empresas de todo el mundo. Cada incidente se presenta como una llamada de atención, pero la industria sigue sorprendida cuando vuelve a ocurrir. En parte, porque aún cuesta abordar con franqueza una cuestión fundamental: la soberanía digital.
Durante años, hemos hablado de centros de datos, disponibilidad regional y certificados de cumplimiento. Nos hemos preguntado si los servidores están en París o en Nueva York y, al confirmar que se encuentran en la ubicación deseada, hemos dado por hecha una decisión soberana.
Pero si un gobierno extranjero puede interrumpir un servicio, una caída puede paralizar toda la empresa, un proveedor puede alterar el modelo operativo o una API propietaria hace que migrar resulte económicamente inviable, la ubicación del servidor es apenas una parte de la historia.
## La residencia de los datos puede dar una falsa sensación de seguridad
Instalar un servidor en París no convierte automáticamente una arquitectura en francesa. El servidor es solo un componente del sistema, y quizá no sea el más decisivo. La soberanía implica controlar la cadena operativa completa: la infraestructura, las herramientas para aprovisionarla y protegerla, los mecanismos de acceso, los procesos de despliegue y los sistemas necesarios para mantenerla en funcionamiento.
Una empresa puede cumplir los requisitos de residencia de datos y, aun así, depender por completo de tecnología extranjera. Puede marcar una casilla de cumplimiento y creer que ha reducido sus riesgos porque los datos están en una región determinada, mientras que las decisiones que gobiernan esos datos siguen en manos de terceros.
El plano de control importa. También importan las herramientas de desarrollo, la plataforma de código fuente, el proveedor de identidad, el orquestador y el asistente de IA. Si cualquiera de ellos se convierte en una dependencia de la que no es posible prescindir, la organización tiene menos autonomía de la que cree.
Como sector, nos hemos centrado en la ubicación física de los servidores porque es fácil de comprender. La autonomía técnica es más compleja y exige revisar dependencias que muchas organizaciones han preferido considerar responsabilidad de otros.
## Las empresas, atrapadas entre marcos legales
El bloqueo tecnológico no es el único problema. La situación legal puede complicarlo aún más. Las empresas actuales pueden encontrarse sujetas a normas que se aplican al mismo tiempo, pero que no siempre apuntan en la misma dirección.
Un ejemplo es la tensión entre la Ley CLOUD de Estados Unidos y el Reglamento General de Protección de Datos (RGPD) de la Unión Europea. La Ley CLOUD puede obligar a empresas tecnológicas estadounidenses a entregar datos bajo su control, aunque estén almacenados fuera de Estados Unidos. El RGPD, por su parte, establece condiciones estrictas para transferir datos personales europeos a terceros países y para permitir el acceso de autoridades extranjeras.
Esto plantea un desafío para una empresa europea que utiliza los servicios de un proveedor tecnológico estadounidense. Los datos pueden estar almacenados en Fráncfort, pero la compañía que presta el servicio puede estar sujeta a la legislación de Estados Unidos. Si recibe una solicitud válida de las autoridades estadounidenses, el proveedor podría afrontar obligaciones en una jurisdicción que generan riesgos legales y regulatorios en otra.
No se trata únicamente de una cuestión entre Estados Unidos y Europa. Es un ejemplo de cómo la residencia de los datos puede ser menos determinante que las complejas reglas sobre control y acceso. Las empresas no pueden resolver las tensiones del derecho internacional mediante la arquitectura, pero sí pueden evitar agravarlas: por ejemplo, no haciendo que todos sus procesos esenciales dependan de un único proveedor, una sola jurisdicción o un conjunto de servicios propietarios.
La situación se vuelve mucho más difícil cuando no existe una forma realista de cambiar lo que hay en medio.
## Si no puedes irte, no tienes soberanía
La soberanía digital significa conservar la capacidad práctica de cambiar de proveedor, jurisdicción o modelo de despliegue sin paralizar el negocio.
Los servicios gestionados permiten a los equipos avanzar con rapidez sin encargarse de cada detalle de la infraestructura. Sin embargo, cada servicio específico de un proveedor añade una dependencia y reduce un poco más las opciones de salida. Esa flexibilidad inicial es una de las grandes ventajas de los proveedores de nube a gran escala; también tiene un coste que conviene reconocer.
La prueba es sencilla: si mañana desapareciera tu proveedor, ¿podrían tus equipos seguir desarrollando y operando software?
Si la respuesta solo existe en un documento de estrategia de salida de 40 páginas que nadie ha puesto a prueba, la respuesta es no. Una estrategia real debe poder ejecutarse. La empresa tiene que ser capaz de trasladar cargas de trabajo, cambiar de proveedor o asumir internamente capacidades críticas sin obligar a todos los equipos de desarrollo a rediseñar su forma de trabajar.
## Controla la capa entre los desarrolladores y la infraestructura
Para alcanzar una autonomía técnica genuina, las organizaciones deben separar la entrega de software de la infraestructura que hay debajo. Ahí es donde una plataforma interna para desarrolladores —o IDP, por sus siglas en inglés— puede desempeñar un papel estratégico.
Una IDP proporciona una capa coherente entre los equipos de desarrollo y los distintos entornos en los que se ejecuta el software. Los desarrolladores pueden seguir los mismos flujos de trabajo estandarizados para crear, probar y desplegar aplicaciones, tanto si el destino es una nube local, un proveedor global a gran escala o un entorno propio.
La infraestructura puede cambiar sin obligar a cada desarrollador a cambiar su manera de trabajar. Además, la organización conserva el control de los procesos que permiten entregar software. La lógica de despliegue, las políticas, las configuraciones y el conocimiento operativo no quedan ligados a un único proveedor.
Así, la portabilidad deja de ser una frase en un documento de riesgos y se convierte en una capacidad que puede ejercitarse y probarse. Las organizaciones pueden trasladar cargas de trabajo entre entornos como parte de sus operaciones habituales, detectar las dependencias que persisten y resolverlas antes de que llegue una crisis.
## Deja de afirmar que tienes soberanía: demuéstralo
La soberanía real debe diseñarse, probarse y mantenerse. Las organizaciones deberían trasladar cargas de trabajo entre entornos de forma periódica, comprobar si las herramientas críticas pueden funcionar de manera independiente e identificar las dependencias ocultas tras los diagramas de arquitectura.
La primera prueba de soberanía no debería hacerse durante una caída del servicio, una disputa legal o una crisis geopolítica. Para entonces, ya es tarde para descubrir qué partes del negocio no puedes controlar.
from Latest from TechRadar https://ift.tt/DucPdZg
via IFTTT IA
