> ## Content Index > Fetch the complete content index at: https://blog.ifirestone.dev/llms.txt > Use this file to discover other available public pages before exploring further. # Soberanía de datos y arquitectura abierta en plataformas gubernamentales: principios de diseño - URL: https://blog.ifirestone.dev/soberania-de-datos-y-arquitectura-abierta-en-plataformas-gubernamentales-principios-de-diseno/ - Published: 2026-10-23T16:32:43.000Z - Updated: 2026-10-23T16:32:43.000Z - Description: Qué significa diseñar sistemas del Estado que sean neutrales en tecnología, interoperables y que conserven el control de los datos. Principios, costos y preguntas para evaluar cualquier solución. - Author: Ivan Firestone - Tags: government, architecture, security, api, #spanish > Qué significa diseñar sistemas del Estado que sean neutrales en tecnología, interoperables y que conserven el control de los datos. Principios, costos y preguntas para evaluar cualquier solución. Imagina una institución que adoptó una plataforma hace años. Fue rápida de desplegar, resolvió el problema y todos quedaron contentos. Un día, una nueva ley obliga a la institución a trasladar sus registros a otro sistema, o el proveedor cambia sus precios, o el producto simplemente se descontinúa. Alguien hace la pregunta que nadie hizo a la hora de firmar: *¿cómo sacamos nuestros datos?* En el sector privado, una mala respuesta a esa pregunta es una migración costosa. Para un Estado es algo más pesado, porque **las decisiones técnicas de hoy moldean la soberanía y el margen de maniobra de las instituciones durante décadas.** Trabajé en la arquitectura de sistemas transversales del Estado dominicano. Este artículo no describe sistemas específicos. Describe los **principios** que me parecen más útiles al diseñar este tipo de plataformas, junto con sus costos reales. Empezaremos definiendo qué debería significar "soberanía" en términos técnicos, luego repasaremos cinco principios y después veremos cuánto cuesta todo esto. ## Qué entiendo por "soberanía de datos" No es un eslogan ni un único requisito técnico. Es la capacidad de responder "sí" a estas preguntas: - ¿Sabemos **dónde** viven los datos y bajo qué jurisdicción? - ¿Podemos **sacar** nuestros datos y migrarlos a otra solución sin permiso del proveedor ni un costo desproporcionado? - ¿Podemos **reemplazar** un componente sin reescribir el resto? - ¿Quién decide **quién** accede a qué, y existe un registro auditable? Si la respuesta a alguna es "depende del proveedor", hay una dependencia que vale la pena hacer explícita. Volviendo a nuestra institución imaginaria, ahí fue justo donde todo falló: nadie había hecho explícita la dependencia. Entonces, ¿cómo se diseña para poder hacerlo? ## Principio 1: neutralidad tecnológica La primera defensa es describir **qué** debe hacer el sistema y **bajo qué contratos**, no **qué producto** lo hace. Ejemplos: - Especifica "autenticación mediante OpenID Connect" en lugar de "usar el producto X". - Especifica "almacenamiento de objetos compatible con S3" en lugar de atarte a un servicio concreto. - Exige formatos abiertos para los datos que se intercambian. Neutralidad no significa evitar los productos comerciales. Significa que **el producto es reemplazable** porque el contrato es un estándar. Pero un sistema rara vez vive solo. ¿Qué pasa cuando muchas instituciones necesitan hablar entre sí? ## Principio 2: interoperabilidad por contrato, no por base de datos compartida En un ecosistema con muchas instituciones, la tentación es integrar "leyendo directamente la base de datos del otro". Es rápido, y es una trampa: - Acopla los sistemas al esquema interno de cada institución. - Impide que cada una evolucione su propio sistema. - Hace imposible auditar quién consume qué. La alternativa es **API-first**: cada institución expone contratos versionados (por ejemplo, con OpenAPI), documentados y con control de acceso. El esquema interno permanece privado y puede cambiar sin romper a nadie. Cuando las instituciones hablan mediante contratos, la siguiente pregunta es sobre los datos mismos: ¿quién es dueño de la verdad? ## Principio 3: la fuente de verdad es única y está identificada Cuando el mismo dato (una persona, un territorio, una empresa) vive copiado en diez sistemas, aparecen inconsistencias. Todo dato crítico debería tener: - Una **institución custodia** responsable de su calidad. - Una **fuente de verdad** consultable por API. - Una **política de copias** clara: qué se puede replicar, con qué frecuencia y cómo se sincroniza. Esto reduce la duplicación y deja claro quién responde cuando un dato está mal. ## Principio 4: estrategia de salida desde el primer día Este es el principio que nuestra institución imaginaria pasó por alto. Antes de adoptar cualquier solución, pregunta: **¿cómo salgo de ella?** - ¿Los datos se exportan en formatos completos y abiertos? - ¿Los contratos de integración son estándar o propietarios? - ¿Existe una copia del código, o acceso a él, si el proveedor desaparece? - ¿Cuánto costaría migrar y cuánto tiempo tomaría? La respuesta no tiene que ser "gratis y rápido". Tiene que estar **estimada** antes de firmar, no después. ## Principio 5: clasifica los datos antes de decidir dónde viven De todo esto podrías concluir que todo debería vivir en infraestructura propia del Estado. Sería otro error, porque no todos los datos exigen el mismo nivel de control. Una clasificación simple ayuda a evitar tanto el exceso (todo en infraestructura propia, a un costo inmanejable) como el defecto (todo en la nube pública sin análisis): | Clase | Ejemplo | Implicación típica | | -------- | -------------------------------------------- | ------------------------------------------------------------- | | Pública | Datos abiertos, catálogos | Se puede publicar mediante APIs abiertas | | Interna | Datos operativos sin riesgo especial | Es viable la nube pública con controles estándar | | Sensible | Datos personales y financieros | Controles reforzados, residencia definida y cifrado | | Crítica | Datos con impacto en la seguridad del Estado | Infraestructura bajo control directo con requisitos estrictos | La clasificación específica la define el marco legal y la política de cada institución. Lo que importa es que **exista y se aplique antes de elegir la infraestructura**. ## Lo que cuesta Un diseño abierto y soberano **no es gratis**, y conviene decirlo: - **Más trabajo de diseño al inicio.** Definir contratos, estándares y límites toma un tiempo que una solución "llave en mano" se ahorra. - **Posiblemente una entrega más lenta al principio.** Integrar por contrato toma más que el atajo de la base de datos compartida. - **Más responsabilidad operativa.** Si controlas más, operas más. Necesitas capacidad técnica interna o contratada. - **Costos de mantener los estándares.** Versionar contratos y mantener la documentación es trabajo continuo. El beneficio aparece en el mediano y largo plazo: menos dependencia, mejor poder de negociación y la capacidad de evolucionar sin empezar de cero. ## Preguntas para evaluar cualquier solución Cuando una propuesta llega a tu escritorio, esta es la lista corta que uso para revisarla: 1. ¿Qué estándares abiertos usa para autenticación, integración y datos? 2. ¿Podemos exportar todos nuestros datos, en un formato abierto, en cualquier momento? 3. ¿Dónde se almacenan y procesan los datos, y bajo qué jurisdicción? 4. ¿Qué componentes son reemplazables y cuáles no? ¿Cuánto costaría reemplazarlos? 5. ¿Qué pasa si el proveedor cambia los precios o las condiciones, o desaparece? 6. ¿Cómo se audita el acceso a los datos? 7. ¿Cuál es el modelo operativo y quién lo sostiene? Si una propuesta no puede responder estas preguntas, es señal de que la dependencia está escondida. ## Preguntar antes de firmar Vuelve a esa institución una vez más. Si alguien hubiera hecho esas siete preguntas a la hora de firmar, la respuesta a "¿cómo sacamos nuestros datos?" ya estaría en papel, con un costo y un plazo asociados. Esa es la idea detrás de todo lo anterior: - La soberanía de datos se logra con decisiones concretas de arquitectura, no con declaraciones. - Los contratos abiertos y versionados son la base de la interoperabilidad y de la capacidad de cambiar de proveedor. - La estrategia de salida se diseña antes de adoptar una solución, no después. - Un diseño abierto cuesta más al inicio y protege más a largo plazo. Esa decisión debe tomarse de forma consciente. Si trabajas en plataformas públicas o en sistemas de larga vida, me gustaría saber qué principios te han funcionado y cuáles has tenido que ajustar.