El costo de la nube en el sector público: necesaria, pero con más cautela que en la empresa privada
Los servicios públicos necesitan herramientas de IA y nube para servir mejor a los ciudadanos. Pero el gasto en infraestructura cloud tiene una dinámica que las instituciones del Estado no pueden ignorar: los costos escalan sin aviso, y los presupuestos fiscales no.
Hay una conversación que el sector público necesita tener con urgencia, pero que muchas veces se posterga porque incomoda: las herramientas de IA y cloud son valiosas, son necesarias, y también pueden volverse un problema fiscal serio si no se gestionan con disciplina.
Esta no es una postura tecnófoba. Todo lo contrario. La razón para hablar de costos es precisamente que queremos que estas herramientas sobrevivan dentro del Estado — que no sean adoptadas con entusiasmo y abandonadas cuando llega la factura de AWS, que no sean bloqueadas por Hacienda después del primer año, que no generen un pasivo presupuestario que justifique un retroceso.
El problema no es la nube — es la dinámica del gasto cloud
La nube tiene un modelo de cobro que funciona muy bien en el sector privado porque las empresas pueden ajustar gasto según ingresos: si el negocio crece, se gasta más; si cae, se reduce. Esa elasticidad es parte del valor. Pero el sector público no funciona así. Los presupuestos se asignan anualmente, se aprueban con meses de anticipación, y los ajustes requieren procesos formales que no están diseñados para responder a una factura que escaló en el trimestre.
Los tokens de un LLM se cobran por uso. El almacenamiento se cobra por gigabyte almacenado. Las llamadas a APIs se cobran por volumen. Si el servicio crece en demanda — porque funciona bien, porque más funcionarios lo adoptan, porque se integra con más sistemas — el costo crece también. En el sector privado eso es una buena señal. En el sector público puede convertirse en un problema presupuestario para el que nadie tiene respuesta inmediata.
En la empresa privada, escalar cuesta más pero también genera más. En el Estado, escalar puede costar más sin ninguna fuente de ingreso adicional que lo compense.
Por qué en el sector público el riesgo es mayor
El sector privado lleva más de una década aprendiendo a gestionar costos cloud. Hay toda una disciplina llamada FinOps —Financial Operations for Cloud— con herramientas, métricas y roles dedicados. Las empresas miden cost-per-unit, optimizan instancias inactivas, negocian reservas de capacidad, y tienen equipos que revisan la factura línea a línea cada semana.
El sector público, en general, no tiene nada de eso. No porque los equipos sean menos capaces, sino porque las estructuras institucionales no estaban diseñadas para este tipo de gasto. El presupuesto público se piensa en grandes partidas anuales, no en costos variables por milisegundo de cómputo.
Los presupuestos institucionales se aprueban en la Ley de Presupuestos con meses de anticipación. Si el uso de una plataforma cloud supera lo proyectado, no hay mecanismo ágil para ajustar. La consecuencia es deuda presupuestaria, recortes en otras áreas, o abandono del servicio justo cuando ya tiene usuarios.
Cuando una empresa privada queda atrapada en un proveedor cloud que encarece sus precios, puede traspasar parte del costo al cliente final o renegociar con margen de flexibilidad. El Estado no puede traspasar costos a los ciudadanos. Un lock-in con fondos públicos es especialmente grave porque los datos, los procesos y los contratos suelen estar estructurados para dificultar la salida.
Según datos del sector, el 72% de las agencias públicas no tiene una política formal de optimización de costos cloud. Los recursos se provisionan por proyecto, se olvidan al terminar el plazo, y nadie tiene visibilidad consolidada del gasto total en infraestructura digital.
En el sector privado, un sobrecosto se reporta en el P&L y los responsables responden ante el directorio. En el sector público, el gasto mal gestionado puede terminar en una auditoría de Contraloría, en una interpelación parlamentaria, o en titulares de prensa. El costo político del error presupuestario en tecnología es desproporcionadamente alto.
Esto no quiere decir que no hay que usar la nube
La conclusión correcta de todo lo anterior no es "el sector público no debería estar en la nube". Esa postura sería igualmente equivocada — y probablemente más cara a largo plazo si se contabilizan los costos de mantener infraestructura on-premise obsoleta.
La conclusión es otra: los servicios públicos necesitan estas herramientas, y por eso mismo deben gestionarlas con más rigor que el sector privado, no con menos. El estándar de gobernanza del gasto cloud en el Estado debería ser más alto, no más bajo. Porque los fondos son públicos, los errores son más difíciles de corregir, y los ciudadanos no tienen alternativa si el servicio falla.
Hay sectores específicos donde la adopción cloud ya es inevitable y urgente: salud pública, gestión de emergencias, atención ciudadana, educación. En todos esos casos, la pregunta no es si usar la nube — es cómo hacerlo con control.
Qué se puede hacer diferente
Presupuestar con rangos, no con cifras fijas
El gasto cloud es variable por naturaleza. Las instituciones deben aprender a presupuestar con techo y con piso, incluyendo escenarios de crecimiento. DIPRES ya tiene mecanismos de provisión de fondos para imprevistos — usar esa lógica para proyectos tech no es una excepción, es una necesidad.
Medir costo por servicio ciudadano
La métrica útil no es "cuánto gastamos en AWS este mes" sino "cuánto cuesta por trámite atendido, por consulta respondida, por documento procesado". Esa granularidad permite identificar qué es eficiente y qué no, y justificar el gasto en términos que tienen sentido para autoridades y ciudadanos.
Acordar límites de gasto antes de lanzar
Antes de poner un servicio en producción que consume recursos cloud, definir un techo mensual de gasto con alarma automática al 70% y 90%. Si se llega al límite, el servicio se degrada graciosamente en lugar de seguir acumulando costos. En AWS, GCP y Azure esto es posible desde el primer día — la mayoría de los equipos públicos simplemente no lo activa.
Evitar el lock-in desde el diseño
Usar estándares abiertos, contenedores portables, y APIs que no dependan de servicios propietarios específicos de un proveedor. Esto no siempre es posible ni siempre vale el trade-off, pero la decisión debe tomarse conscientemente — no por omisión. Los datos del Estado deben poder moverse con el Estado.
Construir capacidad interna de FinOps
El conocimiento de costos cloud no puede quedar solo en la empresa proveedora. Debe haber alguien dentro de la institución — o del área de gobierno digital — con la capacidad de revisar, entender y cuestionar una factura cloud. Esa persona vale más que cualquier consultoría externa que solo aparece cuando el problema ya escaló.
El caso chileno: optimismo razonable, cautela necesaria
Chile tiene una infraestructura de gobierno digital relativamente madura en el contexto de América Latina. ChileAtiende, la red de trámites en línea, y el avance en interoperabilidad entre servicios son logros reales. La Agencia Digital de Gobierno ha impulsado estándares que antes no existían.
Pero el salto hacia herramientas de IA generativa y plataformas cloud de alta demanda es cualitativamente distinto a digitalizar formularios. Los costos son más volátiles, las dependencias más profundas, y los riesgos de sobrecompromiso son reales. Un GORE que adopta Azure OpenAI para atención ciudadana sin una política de costos puede quedar con un servicio que funciona en el piloto y no tiene presupuesto para el año siguiente.
Eso no es un argumento contra el piloto. Es un argumento para hacer el piloto bien: con métricas de costo desde el día uno, con un techo explícito, con un plan de sostenibilidad, y con la honestidad de reportar lo que realmente cuesta — no solo lo que cuesta cuando todo va bien.
La ambición tecnológica del Estado debe estar acompañada de madurez presupuestaria. Sin ella, cada proyecto exitoso lleva en su interior la semilla de su propio abandono.
Una nota sobre la IA en particular
Los modelos de lenguaje (LLMs) tienen una estructura de costos especialmente desafiante para el sector público. El cobro por token — por cada fragmento de texto generado o procesado — significa que el costo escala directamente con el uso, y el uso escala con la demanda ciudadana, que es exactamente lo que quieres que ocurra si el servicio funciona bien.
Un asistente de atención ciudadana que recibe 10.000 consultas al día cuesta diez veces más que uno que recibe 1.000. Si el servicio es bueno, habrá más consultas. Si hay más consultas, habrá más costo. Este ciclo es virtuoso solo si la planificación presupuestaria lo anticipó.
Todo servicio público que use IA debe tener definido, antes de salir a producción, su costo por transacción, su límite mensual de gasto, y su plan de degradación gradual si se supera ese límite. No es burocracia — es la única forma de que el servicio sobreviva más allá del piloto.
Conclusión
La nube y la IA no son un lujo para el sector público — son infraestructura del siglo XXI, tan necesaria como el agua potable o el transporte público en su momento. Negar eso es un error. Pero adoptarlas sin gestión de costos es otro error, y en el sector público ese segundo error tiene consecuencias que van mucho más allá de una pérdida empresarial: afecta la confianza ciudadana en el Estado digital, compromete presupuestos que podrían ir a prestaciones sociales, y puede justificar retrocesos tecnológicos que cuestan años.
El estándar correcto no es el del startup que quema capital de riesgo explorando el mercado. Es el del servicio público que tiene la obligación de ser sostenible con recursos que no le pertenecen, sino que administra.
Más cautela, no menos. Más rigurosidad, no más timidez. Esa es la diferencia.
Referencias