Por qué la soberanía de las plataformas se ha convertido en un imperativo estratégico para el Gobierno japonés
El sector público de Japón se encuentra en una encrucijada. Décadas de dependencia de sistemas propietarios de proveedores han dejado a muchos organismos con software que no pueden modificar, datos que no pueden migrar libremente y contratos que se renuevan automáticamente porque los costes de cambiar de proveedor son prohibitivos. El debate sobre las plataformas tecnológicas soberanas para el Gobierno de Japón ha pasado del ámbito académico de las políticas públicas a las políticas activas de contratación, y organismos de todos los niveles están reconsiderando qué significa ser dueños de la tecnología que sustenta servicios públicos esenciales.
En este contexto, la soberanía no es simplemente una preferencia en materia de contratación. Es una postura operativa y de seguridad. Cuando una entidad gubernamental no puede inspeccionar el código fuente en el que se ejecuta un sistema de atención al ciudadano, no puede exportar sus propios datos sin la cooperación del proveedor o no puede modificar un flujo de trabajo sin contratar servicios profesionales, ha cedido el control operativo. Recuperar ese control es el desafío analítico y práctico que aborda esta guía.
Definir qué significa realmente la tecnología soberana para una agencia gubernamental
Cargando artículos…
La palabra «soberana» tiene un significado técnico específico cuando se aplica al software gubernamental. Una plataforma soberana es aquella en la que la entidad propietaria posee el código fuente completo, controla el entorno de despliegue, conserva todos los datos sin que terceros tengan derechos de acceso y puede transferir o reconstruir el sistema sin penalizaciones contractuales ni impedimentos técnicos.
Esta definición excluye a la mayoría del software gubernamental comercial listo para usar tal como está estructurado actualmente. Los modelos de suscripción, los despliegues exclusivamente en la nube sin una vía de exportación y los esquemas de datos propietarios quedan fuera de los límites de la soberanía. Una agencia que paga por acceder a una plataforma en lugar de ser propietaria de un sistema está alquilando una capacidad, no construyendo infraestructura institucional.
La distinción importa cuando un proveedor abandona un mercado, eleva los precios por encima de lo que permiten los ciclos presupuestarios o no cumple nuevos requisitos normativos. Una plataforma soberana puede bifurcarse, modificarse o entregarse a un nuevo equipo técnico. Una plataforma controlada por un proveedor solo puede renegociarse o abandonarse.
El contexto normativo y de políticas públicas de Japón
Japón ha desarrollado un conjunto de directrices de políticas públicas en torno a la transformación digital de la Administración, incluidas las políticas impulsadas a través de la Agencia Digital establecida en 2021. Estos marcos hacen hincapié en la interoperabilidad, la portabilidad de los datos y la reducción de la dependencia sistémica de proveedores únicos, principios que respaldan directamente la soberanía de las plataformas.
Las normas de contratación pública de Japón también exigen que los contratos gubernamentales tengan en cuenta el coste total del ciclo de vida, no solo el precio inicial de adquisición. Esto brinda a las agencias la oportunidad de argumentar que las plataformas soberanas, pese a tener a veces costes iniciales de desarrollo más elevados, conllevan un menor riesgo y coste total a largo plazo cuando la dependencia de un proveedor, las tarifas de renovación y los costes de migración se modelizan a lo largo de una década.
Las consideraciones de seguridad añaden otra dimensión. Las agencias que gestionan datos de la ciudadanía, datos de gestión de infraestructuras o información relacionada con la defensa afrontan presiones tanto nacionales como internacionales para garantizar que los datos no transiten por jurisdicciones extranjeras a través de la infraestructura de un proveedor. El despliegue soberano —es decir, infraestructura que la agencia gestiona directamente o en virtud de un contrato con plenas garantías de localización de los datos— es la respuesta arquitectónica a esa presión.
Cómo realizar una auditoría de soberanía de plataformas
El primer paso para cualquier agencia es realizar una auditoría estructurada de la soberanía de sus recursos tecnológicos actuales. No se trata de un inventario rutinario de activos de TI. Es una evaluación específica que plantea cuatro preguntas para cada sistema: ¿Quién posee el código fuente? ¿Dónde residen los datos y quién puede acceder a ellos? ¿Qué ocurre con las operaciones si el proveedor deja de ofrecer este producto? ¿Y cuánto costaría la migración en tiempo y dinero?
Por lo general, las agencias descubren que su cartera se divide en tres categorías. Algunos sistemas ya son soberanos en la práctica: se desarrollan internamente, se alojan en infraestructura gubernamental y el código es de plena propiedad de la agencia. Otros son parcialmente soberanos y quizá garanticen la localización de los datos, pero no el acceso al código fuente ni derechos de modificación. Para la mayoría de las agencias consolidadas, la categoría más amplia es la de los sistemas con dependencia total, en los que el proveedor controla todo y la agencia solo tiene acceso a través de una API o una interfaz web.
El resultado de la auditoría debe ser un registro de riesgos por niveles. Los sistemas de la categoría de dependencia total que sustentan servicios críticos —gestión de la identidad ciudadana, procesamiento de pagos, coordinación de emergencias y datos sanitarios— pasan a encabezar la lista de reconstrucción. Las herramientas administrativas de menor trascendencia pueden ser candidatas a acuerdos negociados de depósito en custodia del código fuente mientras se diseña un reemplazo a más largo plazo.
Diseño de la arquitectura de plataformas gubernamentales soberanas
Una vez completada la auditoría, comienza el trabajo de diseño. El principio arquitectónico de las plataformas gubernamentales soberanas es priorizar la componibilidad frente a la sustitución monolítica. Intentar sustituir un gran sistema heredado por otro sistema de gran tamaño no hace más que recrear el problema de la dependencia más adelante y con un proveedor diferente. La arquitectura componible divide el sistema en módulos que pueden desplegarse de manera independiente y cuya propiedad, auditoría y sustitución pueden gestionarse por separado.
Cargando artículos…