El Estado se vuelve usuario

RESPUESTA EJECUTIVA

Los Estados ya utilizan servicios de nube, software como servicio, plataformas de datos, infraestructura tercerizada y herramientas privadas para sostener funciones públicas.

La contratación no implica por sí sola pérdida de soberanía. Puede mejorar capacidad, seguridad, velocidad, resiliencia y acceso a tecnología que sería costosa de desarrollar internamente.

El problema aparece cuando la relación deja de ser reversible.

Si cambiar de proveedor exige rehacer aplicaciones, mover grandes volúmenes de datos, reemplazar servicios propietarios, reconstruir conocimiento perdido o interrumpir funciones críticas, una decisión de compra empieza a convertirse en una condición de operación.

En ese punto conviene distinguir dos cosas:

• autoridad formal: quién puede decidir;
• autonomía operativa: quién puede ejecutar, sostener, auditar o modificar esa decisión.

Un Estado puede conservar leyes, presupuesto, organismos, funcionarios y responsabilidad jurídica mientras reduce su capacidad material para actuar sin una infraestructura contratada.

La pregunta de este expediente no es si la nube privada es buena o mala.

Es otra:

¿puede el Estado dejar de usarla sin dejar de funcionar?

LA REVERSIBILIDAD COMO MEDIDA DE SOBERANÍA

La propiedad de los servidores no alcanza para medir soberanía técnica.

Un organismo puede utilizar infraestructura de terceros y conservar márgenes importantes de autonomía si dispone de:

• datos exportables;
• formatos interoperables;
• documentación suficiente;
• copias y respaldos independientes;
• personal propio capacitado;
• conocimiento de sus dependencias;
• alternativas técnicas;
• contratos con condiciones de salida;
• y migraciones ensayadas antes de una emergencia.

También puede ocurrir lo contrario: poseer parte de la infraestructura y depender, sin embargo, de licencias, componentes, servicios gestionados, personal externo o tecnologías que no puede sustituir.

Por eso la cuestión central no es solamente quién posee la máquina.

Es quién conserva la capacidad de cambiarla.

La soberanía técnica no consiste en no contratar. Consiste también en conservar una salida practicable.

CONCLUSIÓN PRINCIPAL

Un Estado empieza a volverse usuario cuando la infraestructura que contrata deja de ampliar sus opciones y comienza a definir cuáles opciones siguen siendo posibles.

La dependencia tecnológica no equivale automáticamente a subordinación política.

Pero puede reducir el margen efectivo de una institución cuando coinciden:

• servicios críticos;
• concentración de proveedores;
• altos costos de migración;
• datos difíciles de trasladar;
• tecnologías propietarias;
• escasez de personal especializado;
• contratos complejos;
• falta de alternativas probadas;
• y ausencia de procedimientos de salida.

Ese conjunto —no una empresa aislada— es el antecedente material que interesa a Crónicas de la Intemperie.

EL ESTADO TAMBIÉN CONTRATA NUBE

La adopción de nube en el sector público responde a razones concretas.

Puede ofrecer:

• elasticidad;
• despliegue rápido;
• capacidad de procesamiento;
• respaldo;
• acceso a servicios especializados;
• continuidad;
• actualización tecnológica;
• reducción de infraestructura física propia;
• y economías de escala.

El Banco Mundial señala que la computación en nube puede mejorar eficiencia, escalabilidad, inclusión y sostenibilidad en la administración pública, aunque obliga a gestionar riesgos vinculados con privacidad, soberanía de datos, ciberseguridad y bloqueo de proveedor.

Por lo tanto, este expediente no parte de una condena de la tercerización.

Parte de una distinción:

contratar capacidad no es lo mismo que renunciar a la capacidad de sustituirla.

Estado

OPERATIVO / EN EXPANSIÓN.

DEL SERVICIO A LA DEPENDENCIA

El bloqueo de proveedor —vendor lock-in— aparece cuando abandonar una plataforma resulta difícil por razones combinadas.

Puede deberse a:

• formatos propietarios;
• APIs específicas;
• servicios gestionados sin equivalentes directos;
• dependencias entre aplicaciones;
• grandes volúmenes de datos;
• costos de egreso o migración;
• plazos contractuales;
• falta de proveedores alternativos;
• necesidad de reentrenar personal;
• o riesgo de interrupción durante el cambio.

El Financial Stability Board define el lock-in precisamente por la dificultad para cambiar de proveedor debido al contrato, la falta de alternativas viables o características técnicas.

NIST, por su parte, coloca interoperabilidad y portabilidad entre los requisitos centrales para mover aplicaciones y datos entre nubes o entre nube e infraestructura propia a un costo aceptable.

La dependencia no necesita ser absoluta para producir efectos.

Alcanza con que el costo de salir sea suficientemente alto para volver improbable la salida.

Estado

OPERATIVO / DISCUTIDO EN SU ALCANCE Y GESTIÓN.

NO TODO LOCK-IN ES UN FRACASO

La discusión contemporánea es más matizada que la consigna “evitar todo bloqueo”.

En la auditoría de contratación de nube publicada por la U.S. Government Accountability Office en junio/2026, el Departamento de Defensa estadounidense cuestionó que el lock-in sea presentado siempre como una condición negativa.

Su argumento es relevante: utilizar capacidades específicas de un proveedor puede ser una decisión estratégica válida si la institución:

• conoce las dependencias que está creando;
• comprende sus costos;
• conserva arquitectura y documentación suficientes;
• y dispone de una estrategia de salida para cargas críticas.

La pregunta, entonces, deja de ser:

¿existe dependencia?

Y pasa a ser:

¿la dependencia es conocida, gobernable y reversible?

Esto evita una lectura simplista del problema.

Una tecnología propietaria puede resolver mejor una función.

El riesgo aparece cuando su sustitución deja de ser una decisión y se convierte en una imposibilidad práctica.

PORTABILIDAD, INTEROPERABILIDAD Y SALIDA

La portabilidad permite trasladar datos y aplicaciones.

La interoperabilidad permite que sistemas distintos intercambien información y servicios mediante especificaciones compatibles.

No son sinónimos, pero ambas reducen dependencia cuando están diseñadas desde el comienzo.

NIST sostiene que los sistemas de nube deberían permitir mover datos de forma segura y eficiente hacia, desde y entre proveedores, y portar aplicaciones entre plataformas a un costo aceptable.

Las medidas más frecuentes incluyen:

• formatos abiertos;
• interfaces estandarizadas;
• documentación independiente del proveedor;
• infraestructura como código;
• contenedores cuando resultan apropiados;
• copias recuperables;
• separación entre aplicación y servicios exclusivos;
• inventario de dependencias;
• pruebas periódicas de migración;
• y procedimientos de retorno o rollback.

El diseño de la salida empieza antes de necesitarla.

Una migración que solo existe en un contrato y nunca fue ensayada todavía no es una capacidad operativa.

MULTICLOUD NO GARANTIZA REVERSIBILIDAD

Utilizar más de un proveedor puede reducir concentración y ofrecer redundancia.

También puede aumentar:

• complejidad;
• costos;
• superficie de seguridad;
• necesidad de personal especializado;
• diferencias entre servicios;
• y dependencia de herramientas que coordinan varias nubes.

La propia auditoría de GAO/2026 registra esta tensión: una estrategia multicloud puede disminuir algunos riesgos de concentración o interrupción, pero no elimina automáticamente los problemas de portabilidad.

Además, ciertas dependencias aparecen en capas que los contenedores no resuelven por sí solos:

• bases gestionadas;
• servicios de identidad;
• almacenamiento;
• transferencia de grandes volúmenes de datos;
• APIs propietarias;
• y servicios específicos de cada plataforma.

Tener dos proveedores no equivale necesariamente a poder abandonar cualquiera de ellos.

Estado

OPERATIVO / EN EXPANSIÓN / DISCUTIDO SEGÚN ARQUITECTURA.

ARGENTINA — LA RESPONSABILIDAD NO SE TERCERIZA

Los lineamientos tecnológicos de la Administración Pública Nacional argentina contienen una distinción especialmente importante para este expediente.

Al contratar servicios de nube, el organismo transfiere la ejecución de determinadas tareas al adjudicatario.

No transfiere la responsabilidad sobre:

• continuidad;
• disponibilidad;
• y resultados esperados del servicio.

La norma obliga, además, a definir alcance, niveles de disponibilidad, soporte, penalidades y condiciones técnicas de la prestación.

Este principio produce una paradoja útil para leer la dependencia estatal:

la operación puede salir del organismo; la responsabilidad pública se queda.

Si la capacidad interna disminuye mientras la obligación jurídica permanece, el problema no es que el Estado deje de ser responsable.

Es que puede resultar cada vez más difícil ejercer materialmente esa responsabilidad sin el contratista.

Qué demuestra

Que la normativa argentina reconoce explícitamente la diferencia entre tercerizar ejecución y conservar responsabilidad institucional.

Qué no demuestra

Que los organismos públicos argentinos hayan perdido de manera generalizada la capacidad de operar sus servicios.

Estado

OPERATIVO COMO MARCO NORMATIVO.

CONTINUIDAD: EL CONTRATO NO REEMPLAZA LA CAPACIDAD

Los mismos lineamientos argentinos tratan la disponibilidad como un aspecto crítico de los servicios de nube y exigen condiciones específicas para los servicios que sostienen funciones públicas.

La continuidad depende de más que un porcentaje contractual.

También requiere:

• conocer qué sistemas dependen de qué servicio;
• saber cómo recuperar datos;
• conservar credenciales y claves;
• documentar configuraciones;
• establecer responsables;
• disponer de mecanismos humanos de recuperación;
• y probar los procedimientos antes de una falla real.

Una cláusula puede asignar obligaciones.

No reconstruye por sí sola el conocimiento que una institución dejó de conservar.

ARGENTINA — LA NUBE PÚBLICA COMO CONTRAEJEMPLO

La dependencia de grandes proveedores privados no es la única arquitectura posible.

Argentina desarrolló una Nube Pública Nacional operada por ARSAT como parte de una estrategia destinada a fortalecer capacidades tecnológicas del sector público.

En 2026 aparece un caso especialmente pertinente para esta investigación: el Ente Regulador de Agua y Saneamiento (ERAS) adjudicó a ARSAT un servicio de Hosting Virtual, modalidad IaaS, sobre la Nube Pública Nacional para desplegar sus aplicaciones.

La coincidencia es significativa para el universo de este dossier:

• un organismo regulador del agua;
• infraestructura digital;
• nube estatal;
• soporte y mantenimiento;
• y contratación pública.

No porque ese caso se parezca al régimen de CDLI.

Precisamente porque muestra lo contrario: existen decisiones institucionales orientadas a conservar infraestructura y capacidad dentro del sector público.

La Nube Pública Nacional funciona, entonces, como contraejemplo útil frente a cualquier lectura determinista.

CDLI no imagina el único futuro técnicamente posible.

Imagina uno en el que alternativas de esa clase resultan insuficientes, se degradan o pierden terreno frente a sistemas más concentrados.

Estado

OPERATIVO.

UNA NUBE ESTATAL NO GARANTIZA SOBERANÍA TOTAL

Que una infraestructura sea operada por una empresa pública no elimina todas las dependencias.

Puede seguir necesitando:

• hardware importado;
• firmware;
• redes;
• energía;
• software de terceros;
• servicios de soporte;
• componentes propietarios;
• cadenas globales de suministro;
• y personal especializado.

Por eso “nube estatal” y “soberanía total” no deben usarse como sinónimos.

Su importancia reside en otra parte:

amplía el repertorio de opciones públicas y demuestra que la arquitectura de dependencia también es una decisión política.

BRASIL — EL ANTILOCK-IN COMO POLÍTICA TÉCNICA

El Gobierno Digital de Brasil actualizó en junio/2026 una guía de buenas prácticas destinada específicamente a minimizar el aprisionamiento tecnológico en nube.

Las recomendaciones promueven:

• tecnologías abiertas;
• plataformas no propietarias cuando resulte viable;
• portabilidad entre proveedores y entornos locales;
• documentación actualizada;
• infraestructura como código;
• protocolos abiertos;
• copias independientes;
• pruebas de migración;
• simulaciones de recuperación;
• y reducción de dependencias exclusivas del proveedor.

La importancia del documento no está en una herramienta determinada.

Está en que convierte la posibilidad de abandonar una plataforma en un requisito de arquitectura y auditoría.

La salida deja de ser una esperanza contractual.

Empieza a ser algo que debe diseñarse, documentarse y probarse.

Estado

OPERATIVO COMO POLÍTICA Y GUÍA TÉCNICA.

BRASIL — NUVEM DE GOVERNO

Brasil también define una Nuvem de Governo como infraestructura de nube privada o comunitaria gestionada exclusivamente por organismos o empresas públicas.

Entre sus objetivos declara:

• mayor seguridad;
• privacidad de datos;
• almacenamiento bajo condiciones de soberanía;
• y autonomía tecnológica nacional.

La iniciativa incorpora a empresas públicas como SERPRO y DATAPREV y establece criterios específicos para determinadas cargas de trabajo sensibles.

Otra vez, el valor documental del caso es doble.

Demuestra que:

1. los Estados ya utilizan nube de manera estructural;
2. y algunos Estados diseñan mecanismos específicos para reducir dependencia tecnológica y jurisdiccional.

La soberanía digital no aparece solamente como discurso político.

También empieza a convertirse en arquitectura.

UNIÓN EUROPEA — LA SOBERANÍA SE VUELVE CRITERIO DE COMPRA

En abril/2026, la Comisión Europea adjudicó un contrato de hasta 180 millones de euros para servicios de nube soberana destinados a instituciones, organismos y agencias de la Unión.

La contratación fue distribuida entre cuatro proveedores.

Para evaluarlos, la Comisión desarrolló un Cloud Sovereignty Framework.

En junio/2026 explicó que el sistema utiliza:

• niveles de garantía de soberanía —SEAL—;
• y una puntuación general basada en 48 criterios.

Esos criterios se agrupan en ocho dimensiones:

1. estratégica;
2. legal y jurisdiccional;
3. datos e inteligencia artificial;
4. operativa;
5. cadena de suministro;
6. tecnológica;
7. seguridad y cumplimiento;
8. sostenibilidad ambiental.

La importancia conceptual para este expediente es clara.

La soberanía tecnológica deja de ser una abstracción y entra en el pliego.

Puede ser discutida, puntuada y utilizada para comparar ofertas.

Qué demuestra

Que una gran administración pública ya incorpora explícitamente criterios de soberanía y autonomía en compras de nube.

Qué no demuestra

Que esos criterios eliminen las dependencias tecnológicas, comerciales o geopolíticas.

Estado

OPERATIVO COMO MARCO DE CONTRATACIÓN / EN DESARROLLO COMO POLÍTICA.

CONCENTRACIÓN Y TERCEROS CRÍTICOS

El riesgo no depende solamente de una relación bilateral entre organismo y proveedor.

También importa la concentración del mercado.

El Financial Stability Board estudia desde hace años la dependencia del sector financiero respecto de proveedores de nube y servicios digitales de terceros.

Entre los riesgos identifica:

• concentración;
• dificultad de sustitución;
• pérdida de conocimiento;
• dependencia de terceros;
• y propagación de fallas entre instituciones que comparten infraestructura.

Una gran plataforma puede ofrecer más redundancia que una infraestructura pequeña.

Al mismo tiempo, si muchas organizaciones dependen de ella, una falla, restricción o cambio puede afectar a numerosos usuarios simultáneamente.

La concentración, por lo tanto, tiene una doble naturaleza:

• puede aumentar resiliencia dentro de la plataforma;
• y aumentar dependencia sistémica alrededor de la plataforma.

Estado

OPERATIVO COMO CONCENTRACIÓN / RIESGO SISTÉMICO EN EVALUACIÓN.

SEGURIDAD DELEGADA Y VISIBILIDAD

Tercerizar infraestructura tampoco equivale a tercerizar la obligación de comprender su seguridad.

GAO informó en junio/2026 que organismos federales estadounidenses seleccionados presentaban diferencias en la forma de verificar que sus contratistas de nube cumplieran prácticas de seguridad y en la documentación de respuesta y recuperación.

El problema no demuestra que un proveedor externo sea menos seguro.

Puede ocurrir exactamente lo contrario.

La cuestión es de supervisión:

• qué puede auditar el organismo;
• qué depende de declaraciones del proveedor;
• qué subcontratistas intervienen;
• dónde están los datos;
• cómo se notifican incidentes;
• y quién conserva capacidad de recuperación.

Una infraestructura puede ser técnicamente robusta y, aun así, reducir la visibilidad institucional sobre algunas de sus capas.

Estado

OPERATIVO COMO PROBLEMA DE GOBERNANZA Y SUPERVISIÓN.

CUANDO SE TERCERIZA TAMBIÉN LA LÓGICA

Existe un umbral distinto al de alojar datos o ejecutar aplicaciones en infraestructura ajena.

Aparece cuando una administración utiliza sistemas automatizados o modelos para asistir decisiones sobre personas: acceso a prestaciones, elegibilidad, riesgo, fraude, prioridad o continuidad de un servicio.

El Reglamento de Inteligencia Artificial de la Unión Europea considera de alto riesgo determinados sistemas utilizados por autoridades para decidir si prestaciones y servicios públicos esenciales deben concederse, denegarse, reducirse, revocarse o reclamarse. La razón no es que toda automatización pública sea ilegítima, sino que esas decisiones pueden afectar de manera significativa derechos y condiciones materiales de vida.

Este antecedente requiere una distinción importante.

Una cosa es tercerizar infraestructura.

Otra es depender también de una lógica de clasificación que el organismo debe poder comprender, supervisar, impugnar y explicar.

Cuando esa capacidad disminuye, el problema deja de ser solamente dónde funciona el sistema.

Empieza a ser quién puede dar razones por lo que el sistema decide.

Qué demuestra

Que la regulación contemporánea reconoce riesgos específicos cuando sistemas automatizados intervienen en decisiones públicas capaces de afectar derechos o prestaciones esenciales.

Qué no demuestra

Que todos los algoritmos utilizados por gobiernos sean opacos, privados, ilegales o discriminatorios. Tampoco demuestra que el Estado actual haya delegado de manera generalizada su capacidad de decisión a proveedores externos.

Estado

OPERATIVO COMO PROBLEMA REGULATORIO / EN EXPANSIÓN COMO CAPACIDAD ADMINISTRATIVA.

Continuidad del dossier

Este expediente registra solamente el umbral. La conversión de personas en perfiles, puntajes y categorías de elegibilidad continúa en IDLI-AAN-009 — El cuerpo convertido en perfil.

LA DEPENDENCIA TAMBIÉN PUEDE SER COGNITIVA

El lock-in no vive solamente en una licencia.

También puede instalarse en el conocimiento.

Cuando durante años se tercerizan:

• desarrollo;
• mantenimiento;
• redes;
• respaldo;
• recuperación;
• bases de datos;
• análisis;
• identidad;
• ciberseguridad;
• y operación cotidiana,

la institución puede reducir su experiencia interna para reconstruir, auditar o sustituir esos servicios.

Esta dimensión no debe exagerarse: contratar especialistas externos no implica necesariamente perder conocimiento. La dependencia cognitiva aparece cuando la organización deja de conservar suficiente capacidad propia para comprender aquello de lo que depende.

La OCDE viene tratando este problema como una cuestión de capacidad estatal. Su revisión de gobierno digital para América Latina y el Caribe señaló la necesidad de atraer, desarrollar y retener talento digital en el sector público y advirtió que varios países de la región carecían de enfoques integrados para hacerlo. El Digital Government Outlook 2026 mantiene el talento y las capacidades digitales como una condición para que los gobiernos puedan diseñar, comprar y gobernar tecnología a escala.

CUANDO LA INSTITUCIÓN DEJA DE SABER

El riesgo, entonces, no es que el personal público sea intrínsecamente menos capaz.

Es que una institución que deja de formar, atraer o retener especialistas puede terminar dependiendo de terceros incluso para evaluar a los terceros de los que depende.

El problema se vuelve visible cuando el organismo ya no conserva personal capaz de:

• comprender la arquitectura;
• evaluar al proveedor;
• auditar configuraciones y dependencias;
• reproducir procedimientos;
• recuperar información;
• migrar servicios;
• o diseñar una alternativa.

Brasil incluye explícitamente documentación, procedimientos reproducibles y capacidades técnicas dentro de sus medidas antilock-in. La discusión internacional sobre multicloud también muestra que diversificar proveedores sin disponer de conocimientos suficientes puede aumentar la complejidad en lugar de reducir la dependencia.

Una institución puede conservar los datos y perder la memoria de cómo hacerlos funcionar.

La licencia puede renovarse en minutos.

La memoria institucional no.

Estado

RIESGO ORGANIZACIONAL DOCUMENTADO / MAGNITUD VARIABLE SEGÚN INSTITUCIÓN.

LECTURA DE LOS ESTADOS

LA CADENA MATERIAL

LA DEPENDENCIA NO ES UN DESTINO

La cadena no es inevitable.
Tampoco necesita una conspiración para producirse.
Puede surgir de decisiones que, consideradas por separado, resultan razonables: ahorrar costos, acelerar una migración, contratar capacidad especializada, resolver una emergencia, evitar mantener infraestructura propia o aprovechar una tecnología mejor.
El problema aparece cuando esas decisiones se acumulan sin preservar capacidad de salida.

La cadena puede interrumpirse mediante:

• redundancia;
• estándares;
• nubes públicas;
• personal propio;
• interoperabilidad;
• regulación;
• auditabilidad;
• documentación;
• diversificación;
• y estrategias de salida ensayadas.

Ese dato es central.

El antecedente material no describe un destino.

Describe una tensión administrable.

LA MUTACIÓN EN CDLI

Crónicas de la Intemperie no imagina un Estado conquistado de una vez por una empresa.

Imagina algo más administrativo y, por eso mismo, más incómodo: una sucesión de decisiones técnicamente defendibles que termina haciendo impracticable la salida.

La novela elimina progresivamente los frenos de la cadena material.

LA MUTACIÓN EN CDLI

La novela realiza seis operaciones principales:

1. generaliza la tercerización hasta volverla estructural;
2. reduce la capacidad de reemplazo, auditoría y reconstrucción interna;
3. integra servicios públicos bajo infraestructuras comunes;
4. automatiza decisiones que antes requerían deliberación política o humana;
5. convierte contratos y niveles de servicio en constitución material;
6. y permite que la interfaz delimite aquello que el gobierno puede autorizar.

El Estado no desaparece.

Conserva ministerios, sellos, discursos y responsabilidad.

Lo que pierde es la posibilidad práctica de ejecutar algunas decisiones fuera del sistema que debía servirlo.

El Estado conserva la autoridad. Pierde la autonomía operativa.

RELACIÓN CON CRÓNICAS DE LA INTEMPERIE

PROCESO

Los gobiernos ya contratan infraestructura digital, nube, software, análisis y servicios especializados a terceros.

La portabilidad, la concentración, la seguridad, la soberanía de datos y las estrategias de salida forman parte de debates técnicos y regulatorios reales.

También existen respuestas destinadas a conservar mayor autonomía: nube pública, infraestructura gubernamental, estándares abiertos, diversificación y criterios de soberanía en contratación.

MUTACIÓN

CDLI combina esas dependencias y las lleva hasta un régimen en el que:

• los sistemas críticos quedan fuertemente acoplados;
• la capacidad pública de reemplazo casi desaparece;
• la emergencia vuelve permanentes contratos y excepciones;
• la infraestructura privada participa de la asignación de recursos;
• y la interfaz deja de ejecutar decisiones para empezar a definirlas.

LÍMITE

Estas fuentes no demuestran que:

• contratar nube implique perder soberanía;
• los proveedores privados gobiernen actualmente a los Estados;
• exista una conspiración consciente o coordinada para vaciar la capacidad estatal;
• los funcionarios públicos actúen necesariamente con mala fe al tercerizar;
• una nube pública garantice autonomía tecnológica completa;
• multicloud elimine por sí solo el lock-in;
• la concentración produzca necesariamente una falla sistémica;
• contratar sistemas automatizados equivalga a renunciar a la decisión pública;
• ni la búsqueda de eficiencia conduzca inevitablemente al régimen de Crónicas de la Intemperie.

Lo que las fuentes permiten observar es otra cosa: decisiones localmente razonables pueden acumular dependencias técnicas, contractuales y cognitivas si no se preservan sustitución, auditabilidad, conocimiento interno y capacidad de salida.

Ahí aparece el vínculo con el accidente normal: no hace falta un plan único para producir una arquitectura que, con el tiempo, resulte difícil de desarmar.

La novela no inventa la dependencia. Inventa un mundo donde la dependencia deja de tener salida.

RELACIÓN CON CAPÍTULOS Y ESCENAS

Prólogo — Breve crónica del cielo privatizado

Formula directamente la tesis institucional:

El Estado no cayó. Se volvió usuario de su propia infraestructura.

Y lleva el proceso hasta su síntesis política: la política no desaparece; se vuelve interfaz.

Capítulo 4 — El primer accidente normal

Concentra la acumulación de decisiones técnicas y administrativas: licitaciones, prórrogas, mantenimiento abandonado, infraestructura degradada y lenguaje de gestión que distribuye responsabilidades sin hacer desaparecer las decisiones.

Capítulo 11 — El hombre que repara fantasmas

Tomás trabaja sobre residuos de sistemas superpuestos y dependencias históricas que ya nadie puede reconstruir por completo. La infraestructura conserva funciones después de perder una memoria institucional clara sobre su arquitectura. Su oficio vuelve visible la dimensión cognitiva del expediente: no alcanza con encontrar una máquina si ya no queda quién recuerde cómo fue construida.

Capítulo 12 — Todo había sido previsto

El archivo muestra que parte de los riesgos había sido identificada antes del Colapso. El problema no era solamente ausencia de conocimiento, sino la distancia entre prevención técnica y decisión política. La acumulación de decisiones parciales importa más que una voluntad conspirativa única: el accidente se vuelve normal porque cada pieza puede parecer razonable mientras el conjunto pierde reversibilidad.

Capítulo 13 — Población residual

La infraestructura deja de ser soporte neutral y participa en decisiones sobre territorios, cobertura y continuidad.

Capítulo 14 — El rostro verdadero

Los contratos hacen visible la sustitución progresiva de responsabilidad pública por arquitectura económica y operativa.

Capítulo 22 — El Archivo Madre

La interoperabilidad alcanza la mutación extrema: sistemas que originalmente administraban funciones diferentes pueden leerse y operar como una sola capacidad de clasificación.

MATRIZ DE FUENTES

MATRIZ DE FUENTES

ARGENTINA Y REGIÓN

Oficina Nacional de Tecnologías de Información / Jefatura de Gabinete

Estándares Tecnológicos para la Administración Pública Nacional — Anexo III, Lineamientos — Lineamientos para contratación de servicios de nube, continuidad, disponibilidad y responsabilidad institucional. — 🔗

Ente Regulador de Agua y Saneamiento — ERAS

Resolución 15/2026 — 30/abril/2026 / publicada 4/mayo/2026. — Contratación de Hosting Virtual, modalidad IaaS, en la Nube Pública Nacional de ARSAT para aplicaciones del ERAS. — 🔗

Argentina.gob.ar / ARSAT

Avanza el desarrollo de la Nube Pública Nacional — 23/diciembre/2020. — 🔗

Gobierno Digital — Brasil

Boas práticas para minimizar aprisionamento (lock-in) em nuvem — Actualizado 19/junio/2026. — 🔗

Gobierno Digital — Brasil

Nuvem de Governo — Infraestructura de nube gestionada exclusivamente por organismos o empresas públicas. — 🔗

SOBERANÍA, CONTRATACIÓN Y PORTABILIDAD

Comisión Europea

Sovereign Cloud Framework explained — 1/junio/2026. — 🔗

U.S. Government Accountability Office

Cloud Computing: Federal Government Needs to Address Procurement Challenges — GAO-26-107530 — 23/junio/2026. — 🔗

National Institute of Standards and Technology

NIST Cloud Computing Standards Roadmap — SP 500-291 Rev. 2 — 🔗

World Bank — GovTech

Cloud Computing Working Group — 🔗

CONCENTRACIÓN, TERCEROS Y SEGURIDAD

U.S. Government Accountability Office

Cybersecurity: Selected Agencies Need to Better Protect Cloud Data — GAO-26-108443 — 25/junio/2026. — 🔗

Financial Stability Board

Third-party dependencies in cloud services: Considerations on financial stability implications — 9/diciembre/2019. — 🔗

CAPACIDAD DIGITAL Y DECISIÓN AUTOMATIZADA

OECD — América Latina y el Caribe

Digital Government Review of Latin America and the Caribbean — Establish and maintain a digital workforce in the public sector — 2023. — Revisa la necesidad de atraer, desarrollar, asignar y retener talento digital en gobiernos de la región y señala carencias en enfoques integrados de contratación y retención. — 🔗

OECD

Digital Government Outlook 2026 — Governing digital investment and capabilities to deliver at scale — 2026. — Analiza capacidades institucionales y medidas para atraer talento digital al sector público. — 🔗

Unión Europea — EUR-Lex

Reglamento (UE) 2024/1689 — Reglamento de Inteligencia Artificial — Clasifica como de alto riesgo determinados sistemas utilizados para decidir sobre acceso, reducción, revocación o recuperación de prestaciones y servicios públicos esenciales.🔗