La soberanía digital de cualquier administración pública se juega mucho antes de decidir dónde colocar los servidores. Se juega en algo que parece menor pero no lo es en absoluto: el formato ODF en el que se redactan los documentos. Y aquí conviene detenerse, porque el Open Document Format se está perfilando como el único estándar realmente abierto frente a las alternativas propietarias, y de esa elección depende que el acceso a la información pública quede o no en manos de un proveedor externo.
Conviene recordar algo básico. Un archivo no es un papel. No contiene nada por sí solo hasta que un programa interpreta sus instrucciones. Quien haya abierto alguna vez un documento en una aplicación distinta de la que lo creó sabe de qué hablamos: los márgenes cambian, las tablas se descuadran y todo parece haberse movido solo. El formato es la especificación que le dice al software cómo leer esas instrucciones. Y quien controla esa especificación decide, en el fondo, cuánto tiempo seguirá siendo legible un documento.
Qué convierte a un formato en abierto de verdad
Para no perderse entre promesas de marketing, hay una referencia útil. Los criterios del European Interoperability Framework, el marco que muchas administraciones usan para evaluar formatos en sus compras públicas. La lógica es sencilla. La especificación debe publicarse entera y gratis, sin licencias ni pagos de por medio. Cualquiera debe poder usarla sin que se discrimine entre aplicaciones. Y su gobierno tiene que recaer en un organismo independiente de cualquier fabricante.
El ODF cumple con todo esto. Se desarrolló dentro de OASIS y alcanzó ese estatus en 2005. Superó la votación de Draft International Standard en el comité ISO/IEC JTC 1/SC 34 en mayo de 2006 con aprobación unánime, y en noviembre de ese mismo año se publicó como ISO/IEC 26300. Un comité técnico mantiene la especificación de forma pública, y la versión 1.4 se aprobó en OASIS en diciembre de 2025. Quien trabaje con LibreOffice lo usa de forma nativa, aunque el formato no pertenece a nadie: cualquier desarrollador puede implementarlo sin pedir permiso a nadie.
Por qué OOXML no funciona como un estándar real
Aquí llega la parte incómoda, porque muchísima gente usa a diario archivos DOCX, XLSX o PPTX sin pensarlo dos veces. Detrás de todos ellos está OOXML, que tiene número ISO desde 2008, conseguido mediante un procedimiento fast track. El problema es que ese número nunca ha producido los efectos que se esperan de un estándar de verdad. La especificación ocupa varios miles de páginas, algo que desanima a cualquiera que quiera implementarla desde cero.
Y hay más. Existen dos variantes de conformidad. La Strict, que otros desarrolladores podrían soportar sin grandes complicaciones, y la Transitional, que arrastra comportamientos heredados y es la que Microsoft Office escribe por defecto. Dicho de otra forma, la variante que usan cientos de millones de personas cada día es la única que su propio creador implementa por completo. La más limpia apenas se usa y ha llegado a desaparecer en algunas versiones. Un estándar que solo una implementación logra satisfacer es, en la práctica, un formato propietario con un certificado de normalización encima. No se trata de una intención deliberada, sino de un comportamiento estructural.
La elección del formato va antes que cualquier contrato de nube
Y aquí está el punto que muchas veces se pasa por alto. Una administración puede elegir un proveedor de nube europeo, negociar cláusulas contractuales sólidas y alojarlo todo dentro de su propia jurisdicción. Y aun así no habrá ganado nada real en soberanía digital si sus documentos siguen guardados en un formato que solo un proveedor extranjero sabe leer con fidelidad. La ubicación del servidor termina dependiendo del formato elegido, y no al revés.
Fuente
Imagen: softzone.es
