La infraestructura invisible que hace que todo funcione

En la nota anterior escribí que el Estado que viene ya empezó a construirse. Hablé de GDE, TAD, Mi Argentina, identidad digital, firma, interoperabilidad, credenciales y agentes, y dejé deliberadamente afuera una capa que merecía una discusión propia: centros de datos, nube, capacidad de cómputo, dependencias entre sistemas y ciberseguridad.

Es la capa que casi nadie ve. Y es la que define la calidad de todo lo demás.

Una persona abre una aplicación, presenta una credencial o inicia un trámite y espera que funcione. Eso es lo correcto: la complejidad tiene que quedar atrás. Pero para que esa experiencia sea simple, detrás tiene que existir una infraestructura cada vez más ordenada, disponible, segura y resiliente.

Creo que ese es uno de los próximos grandes desafíos de la transformación digital del Estado argentino.

Lo que el ciudadano no ve

Pensemos en algo aparentemente sencillo. Una persona abre Mi Argentina y consulta una credencial.

Para ella la operación es una sola. Tecnológicamente pueden estar pasando muchas cosas: Mi Argentina la identifica, consulta un servicio que pertenece a otro organismo, ese organismo consulta una base que puede estar alojada en otra infraestructura, la información vuelve, se valida, se transforma y aparece en el teléfono. Todo eso puede ocurrir en segundos.

Cuando funciona, parece simple. Ese es exactamente el objetivo.

Pero detrás de esa simplicidad hay algo importante: la calidad del servicio final depende de todos los componentes de la cadena. Mi Argentina puede estar funcionando perfectamente y aun así no mostrar una credencial porque el servicio que la provee no está disponible.

Desde el punto de vista técnico, Mi Argentina no se cayó. Desde el punto de vista del ciudadano, sí.

Porque el ciudadano no ve arquitecturas. No ve APIs. No ve contratos. No ve organismos.

Ve al Estado.

Y ahí aparece un problema que no es técnico. Una credencial que se muestra en una aplicación puede tener su fuente en otro organismo, con su propia infraestructura, sus prioridades y sus tiempos. Cada uno responde por su parte. Nadie responde por la cadena completa, que es exactamente la que experimenta la persona.

Durante años fue lógico administrar la tecnología organismo por organismo. Pero la transformación digital fue conectando esas piezas, y hoy hay una red de servicios públicos digitales interdependientes administrada con la lógica anterior. Medimos si un sistema está funcionando. Deberíamos medir si el servicio que recibe la persona funciona de punta a punta.

Antes de construir más, saber qué tenemos

Argentina ya tiene muchísima infraestructura tecnológica. Centros de datos, redes, equipamiento, capacidad de cómputo, servicios de nube, plataformas comunes, infraestructura propia de cada organismo y sistemas nuevos conviviendo con otros que llevan décadas funcionando.

El caso más claro es el Centro Nacional de Datos de ARSAT, en Benavídez: alrededor de 4.500 metros cuadrados, cuatro salas de servidores y una sala cofre de máxima seguridad, capacidad para más de 700 racks y certificaciones Tier III del Uptime Institute tanto por diseño como por construcción. Ahí corren sistemas de organismos nacionales, provinciales y municipales, y está creciendo: la Sala IV y la ampliación de la sala cofre, financiadas con un préstamo del Banco Mundial.

Es una capacidad estatal concreta, y bastante mejor que la que se suele suponer. Pero tener un datacenter no es tener una estrategia. Tier III describe la mantenibilidad concurrente de una instalación: se puede sacar de servicio cualquier componente para mantenerlo sin cortar la operación. No dice nada sobre qué pasa si esa instalación completa deja de estar disponible. Para eso hacen falta dos sitios, replicación y pruebas reales de recuperación.

Un centro de datos excelente sigue siendo un solo lugar.

La primera reacción frente a eso no debería ser reemplazar todo. Debería ser algo más básico: tener un mapa de lo que existe.

Qué corre en cada lugar, qué servicios dependen de eso, qué criticidad tienen, cuánto cuesta sostenerlo, de qué infraestructura de terceros dependemos y qué conviene consolidar, modernizar o dejar distribuido.

Parece una tarea técnica. En una organización del tamaño del Estado, construir ese mapa ya es una política tecnológica. Porque sin conocer la infraestructura es muy difícil planificarla.

Y desde hace unos meses, además, es una obligación. En mayo de 2026 el Centro Nacional de Ciberseguridad aprobó, mediante la Disposición 1/2026, un reglamento técnico de cumplimiento obligatorio para todo el Sector Público Nacional que utilice centros de datos o infraestructura de tecnologías de la información. Exige un inventario de sistemas con sus dependencias —aplicaciones, datos, infraestructura y proveedores—, su clasificación por criticidad en tres niveles, objetivos de tiempo y de punto de recuperación (RTO y RPO) definidos para cada sistema, un centro de procesamiento de datos de respaldo y pruebas de conmutación con periodicidad mínima anual.

El plazo de adecuación vence en noviembre, y cada organismo alcanzado tiene que presentar un informe con la ubicación de su sitio alternativo, sus parámetros de recuperación y el resultado de al menos una prueba real de conmutación. Es, probablemente, la exigencia de continuidad más concreta que el Estado argentino se puso a sí mismo.

La criticidad ya no se mide por usuarios

El 27 de agosto de 2020, un ransomware cifró los sistemas de la Dirección Nacional de Migraciones. Los pasos fronterizos del país quedaron sin acceso a la base que registra entradas y salidas durante alrededor de cuatro horas.

El sistema afectado no era el más visible del Estado. Era uno del que dependía una operación soberana.

La criticidad de un sistema ya no depende solamente de cuánta gente lo usa. Depende de cuántos otros sistemas dependen de él. Una API aparentemente menor puede sostener diez servicios ciudadanos. Una base casi invisible para el ciudadano puede ser la fuente de media docena de credenciales.

Eso cambia la forma de priorizar inversión, mantenimiento, redundancia, seguridad y monitoreo.

Y obliga a otra métrica. Supongamos un trámite de siete pasos: identificar a la persona, consultar una credencial, validar un domicilio, verificar una condición, generar un documento, firmarlo e incorporarlo a un expediente. Cada paso puede depender de una plataforma distinta. Si seis funcionan y uno no, la operación no termina. Desde una lógica tradicional tenemos seis sistemas en verde y uno en rojo. Desde la experiencia de la persona, el servicio está rojo.

Por eso hay que avanzar hacia la disponibilidad de punta a punta: no solo saber si cada componente está activo, sino observar el recorrido completo. Dónde aparece latencia, qué dependencia externa está degradada, cuántas personas están afectadas y cuánto tarda el sistema completo en recuperarse.

Eso se llama observabilidad. Parece una palabra estrictamente técnica. Aplicada al Estado es una herramienta para medir calidad de servicio público.

Datacenter o nube es la pregunta equivocada

No existe una única respuesta para todos los sistemas. La pregunta correcta es otra: ¿qué arquitectura necesita este servicio para cumplir con el nivel de disponibilidad, seguridad, resiliencia, autonomía y costo que esperamos de él?

Para un Estado moderno, la respuesta va a ser cada vez más una arquitectura híbrida: parte en centros de datos estatales, parte en nube pública, capacidad bajo demanda, redundancia entre ubicaciones o entre proveedores, y un mismo servicio usando distintas capas según la criticidad de cada componente.

Y hay una razón de fondo, que conviene decir sin vueltas: en la capa de infraestructura, el Estado siempre va a ir por detrás de los grandes proveedores. La inversión anual de cualquiera de ellos supera con holgura todo lo que un Estado como el nuestro puede destinar a tecnología, y lo que hoy es un diferencial, en dieciocho meses es un servicio de catálogo. No es una falla de gestión, es una diferencia de escala que no se revierte.

Por eso el híbrido no es un punto medio ni una rendición: es reconocer que hay dos curvas distintas. Una es la capacidad que conviene tener y sostener. La otra es la que conviene alquilar, porque tenerla significaría estar permanentemente atrasado.

Y eso define qué hay que conservar: lo que no envejece. La identidad, los registros autoritativos, los datos, las interfaces y la capacidad de mudarse. Ahí el Estado no compite con ningún proveedor, porque eso no lo tiene nadie más.

Pero conviene decir lo que casi nunca se dice: el híbrido es la arquitectura más cara y más difícil de operar. Exige más disciplina, más automatización y, sobre todo, más y mejor gente, que es exactamente lo que al Estado más le cuesta conseguir y retener. Y la portabilidad también se paga: una arquitectura pensada para correr en dos nubes suele terminar usando el mínimo común denominador de las dos, resignando servicios que harían el sistema más simple y más barato.

Por eso la portabilidad no es un principio para aplicar en todos lados. Es una inversión, y se justifica donde la criticidad la justifica. Un sistema de identidad no se trata igual que una aplicación interna de gestión. Decidir esa diferencia, servicio por servicio, es buena parte del trabajo.

El problema de las posiciones es que se aplican igual a todos los sistemas. Y ahí está el verdadero atractivo de las doctrinas: una doctrina es barata, porque ahorra el trabajo de clasificar servicio por servicio. Decidir caso por caso es más lento, más incómodo y mucho más difícil de comunicar. También es lo único que funciona.

La nube tiene dirección postal

Durante algunos años, hablar de nube transmitió la idea de que la infraestructura había dejado de tener ubicación. No es así: la nube también es territorio, energía, empresas, contratos y jurisdicciones. Y es distancia, porque cada kilómetro se paga en latencia y la latencia decide qué se puede hacer en tiempo real y qué no. Soberanía de datos no es solo dónde está el servidor: es también bajo qué ley queda lo que hay adentro, qué autoridad puede pedir esa información, con qué orden y con qué garantías. De ahí la lógica de las jurisdicciones reconocidas como adecuadas en materia de protección de datos, a las que puede transferirse información con reglas y garantías conocidas de antemano.

Argentina tiene su propia lista de países adecuados, que mantiene la Agencia de Acceso a la Información Pública, y es a la vez uno de los pocos países fuera de Europa reconocido como adecuado por la Unión Europea. Es una capacidad que hay que sostener.

Sobre la infraestructura ya tomamos una posición: la Disposición 1/2026 exige que el centro de datos de respaldo esté dentro del territorio nacional y a no menos de 1.500 kilómetros del principal. A esa distancia de Benavídez, donde está el Centro Nacional de Datos de ARSAT, ya estamos en la Patagonia o en el extremo norte, y ahí la distancia vuelve a cobrar: solo la propagación física agrega unos quince milisegundos de ida y vuelta, y en una red real es más. Para muchos sistemas eso vuelve cara o directamente inconveniente la replicación sincrónica, y obliga a trabajar con replicación asincrónica y un RPO explícitamente aceptado. La norma lo contempla.

Mantener el respaldo adentro protege la jurisdicción y simplifica el control, y a la vez concentra el riesgo geográfico. Nada de eso es gratis: conviene que sea una decisión tomada a conciencia y no un default.

Porque autonomía tecnológica no significa aislamiento. Significa poder elegir, cambiar y seguir funcionando: estándares abiertos, arquitecturas desacopladas, contratos que contemplen la salida y capacidad propia en lo que se considere estratégico. La pregunta deja de ser cuánto cuesta y empieza a ser qué capacidad estamos poniendo en manos de un tercero, bajo qué ley, y qué nos queda si desaparece.

Autonomía no es producir todo lo que usamos. Es poder dejar de usarlo.

La seguridad no se agrega al final

Una infraestructura más conectada amplía la superficie que hay que proteger: cada API, cada identidad, cada integración y cada proveedor suma posibilidades y también riesgos. Por eso la ciberseguridad no puede agregarse cuando el sistema ya está terminado, y por eso importa tanto conocer las dependencias: una vulnerabilidad en un sistema poco relevante puede ser el camino hacia otro crítico.

Hay un caso cotidiano que muestra el problema entero: la gente que se va.

Alguien renuncia, termina su contrato, cambia de organismo o se va con un cambio de gestión, y sus accesos siguen vivos. Usuarios que nadie dio de baja, credenciales compartidas entre varias personas, cuentas de administrador que no están a nombre de nadie, claves anotadas en un documento, accesos de proveedores cuyo contrato terminó hace dos años. En una arquitectura integrada, un acceso olvidado en un sistema menor puede ser la puerta de entrada a uno crítico.

Y acá lo importante es dónde ponemos la responsabilidad. No puede recaer en la persona que se va. No puede depender de que alguien devuelva algo, avise o se acuerde. Tiene que estar resuelto en la arquitectura: identidades con ciclo de vida, altas y bajas atadas al mismo proceso que la relación laboral o contractual, accesos con vencimiento, privilegio mínimo, sin cuentas compartidas y con revisión periódica de quién tiene acceso a qué.

En el Estado, además, esto pasa a escala y en fecha conocida: cada cambio de gestión mueve miles de personas a la vez. Es justamente el momento en que habría que poder responder una pregunta sencilla —quién tiene acceso a esto hoy— y muchas veces no se puede.

Y va a importar todavía más dentro de poco, cuando quien tenga credenciales no sea una persona sino un agente.

La confianza no es una elección

Hay además una dimensión menos técnica y probablemente más importante. Una persona sale de su casa sin la licencia de conducir, sin la cédula del auto y muchas veces sin el DNI de plástico, porque el Estado le dijo que con la credencial digital alcanza. Y alcanza. Hasta que el sistema no responde.

En ese momento no falló una aplicación. Falló la palabra de quien le dijo que podía dejar el documento en casa.

Y la consecuencia no la paga el sistema: la paga la persona. Una multa por no poder acreditar algo que efectivamente tiene. Un turno perdido. Un plazo que vence. Un día de trabajo gastado en volver a una oficina. Y encima la carga de explicar algo que no puede probar, porque nadie le va a dar un comprobante de que el servicio estaba caído.

El Estado registra un incidente. El ciudadano registra un perjuicio. Y entre las dos cosas no hay ninguna compensación.

Además, cada falla enseña. La próxima vez esa persona va a llevar el plástico por las dudas, y va a tener razón. Una caída no cuesta solamente el día que ocurre: se lleva puesta la adopción que costó años construir.

Eso es lo que hay detrás de cada uso de una plataforma pública: alguien depositó confianza en el Estado. Confía en que el dato que ve es correcto, en que la credencial que muestra va a ser reconocida del otro lado y en que el servicio va a estar cuando lo necesite, que casi nunca es en horario de oficina.

Y esa confianza tiene una particularidad: no es una elección. Si una aplicación privada falla, se cambia de aplicación. Otro Estado no hay. El ciudadano no eligió este proveedor, no puede irse a otro y, cada vez más, tampoco tiene un mostrador alternativo al que volver. Cuando el canal digital es el único camino, que el sistema no esté disponible no es una molestia técnica: es una oficina cerrada.

Por eso la disponibilidad, la integridad del dato y la seguridad no son atributos de calidad del servicio. Son el servicio.

Y no se construyen con una campaña de comunicación. Se construyen cada vez que alguien presenta una credencial y del otro lado la aceptan.

Los datos también son infraestructura

Cada sistema generaba información como consecuencia de su operación: una aplicación tenía su base, otro organismo tenía otra, y cada uno administraba ese universo. La próxima etapa requiere saber cuál es la fuente autoritativa de cada dato, quién responde por su calidad, con qué frecuencia se actualiza, quién puede acceder y cómo queda registrado ese acceso.

Un modelo puede ser extraordinario. Pero si consulta tres bases con información distinta sobre la misma persona, el problema no está en la inteligencia artificial. Está antes.

En sistemas hace décadas que se dice garbage in, garbage out: si entra basura, sale basura. Con la inteligencia artificial esa vieja regla cambia de escala, porque los modelos son muy buenos produciendo respuestas convincentes incluso cuando los datos que las sostienen no lo son. Y con agentes cambia de naturaleza: ya no sale una respuesta equivocada, se ejecuta una acción equivocada. Un dato desactualizado deja de ser un error en una pantalla y pasa a ser un trámite rechazado o un beneficio que no llega.

Queda afuera de esta nota un capítulo entero: los datos públicos como servicio, con nivel de servicio comprometido, versionado y consumo por API, para que otros sistemas —y pronto otros agentes— construyan sobre ellos sin pedir permiso cada vez. El marco que ordena eso, la Infraestructura Nacional de Datos Públicos, está en revisión. Merece una nota propia.

La inteligencia artificial empieza antes del modelo

La conversación de los últimos años estuvo muy concentrada en qué modelo usar. Todo eso importa. Pero para el Estado hay una pregunta previa: ¿sobre qué infraestructura va a trabajar esa inteligencia artificial?

Un agente puede ser muy sofisticado. Si no existe una API, no puede consultar el dato. Si el servicio no tiene disponibilidad, no puede usarlo. Si los datos están desactualizados, va a decidir mal. Si no existe identidad digital, no sabe en nombre de quién actúa. Si no existen permisos, no sabemos qué puede hacer. Si no existe trazabilidad, no podemos auditarlo.

Hay una secuencia que deberíamos tener presente:

infraestructura → datos → interoperabilidad → identidad → seguridad → inteligencia artificial → agentes.

La inteligencia artificial es una capa superior. No reemplaza a las anteriores: las vuelve más importantes.

Y un agente multiplica dependencias. Volvamos al trámite de siete pasos: una persona le dice "quiero renovar esta habilitación" y el agente tiene que recorrerlos todos, y además pagar y notificar. Eso no es una interfaz, es una orquestación de servicios. Cada dependencia adicional aumenta la necesidad de disponibilidad, observabilidad, seguridad y gobierno, y agrega una pregunta nueva: en nombre de quién actuó, y cómo lo demostramos después.

Qué se le puede delegar a la inteligencia artificial en el Estado, con qué mandato y con qué control, es otra discusión. Lo que importa acá es que todo eso empieza mucho antes del modelo.

Ordenar no es centralizar

No creo que el Estado necesite una única base de datos, ni un único datacenter, ni una única nube, ni una única tecnología. Eso sería confundir arquitectura con centralización.

Lo que sí necesita es una visión común: estándares, clasificación de criticidad, niveles mínimos de servicio, reglas de interoperabilidad, identidad, observabilidad y claridad sobre quién responde por cada componente. Puede haber infraestructura distribuida, distintos proveedores y capacidades propias y contratadas, siempre que formen parte de una estrategia común.

Y ese trabajo ya tiene quién lo haga, aunque casi nadie lo vea. La Oficina Nacional de Tecnologías de Información (ONTI) viene sosteniendo desde hace años los estándares tecnológicos del Sector Público Nacional, emite el dictamen técnico previo sobre los proyectos de tecnología de los organismos y trabaja con las áreas de sistemas de todo el Estado. Es, en ese sentido, tan invisible como la infraestructura de la que habla esta nota, y por el mismo motivo: cuando el trabajo está bien hecho, no se nota.

Tiene los equipos y tiene la experiencia. Lo que hay que darle es la posibilidad de ser el gran ordenador: mandato para fijar criterios, capacidad de decir que no y presupuesto propio para sostener lo que es común a todos.

Centralizar significa poner todo en el mismo lugar. Ordenar significa conseguir que todo pueda funcionar como un sistema.

Cuanto mejor funciona, menos se nota

Hay una paradoja en la transformación digital: cuanto mejor funciona la infraestructura, menos la percibe el ciudadano. Nadie debería tener que pensar en un datacenter cuando abre una credencial, ni en un esquema de redundancia cuando firma un documento. Pero para que esa complejidad desaparezca de la experiencia, primero tiene que estar administrada.

Y ahí hay una trampa. Cuando un área de infraestructura funciona bien, hay menos incidentes, menos intervenciones y menos urgencias. Visto desde afuera, eso se parece mucho a que hay menos trabajo, y a veces a que hacen falta menos recursos. Es el error de medir a un equipo por las acciones correctivas que ejecuta en lugar de por los incidentes que evita, y termina castigando justamente a los que mejor operan.

La infraestructura debería ser invisible para el ciudadano. Nunca para quien tiene que sostenerla, ni para quien decide su presupuesto.

Argentina ya tiene buena parte de esta infraestructura construida. No hace falta empezar de nuevo: hace falta conocerla, ordenarla, entender sus dependencias y medirla de punta a punta.

La paradoja es que hoy incluso existe una norma que obliga a hacerlo. Pero que algo sea técnicamente necesario y normativamente obligatorio no significa que ocurra.

Porque el próximo problema ya no es tecnológico. Es de gobernanza: quién decide, quién paga, quién cede, quién coordina y, sobre todo, quién responde por el servicio completo cuando cada organismo administra solo una parte.

De esto hablaremos en una próxima nota.

Mientras tanto, las aplicaciones, las credenciales, las billeteras y los agentes son la parte visible. Su calidad depende de una infraestructura que casi nadie ve.

Y los ciudadanos ya empezaron a confiar en esa infraestructura, aunque no sepan que existe.