Optimizar costes en la nube: de dónde sale la factura que nadie esperaba

Optimizar costes en la nube se convierte en prioridad siempre del mismo modo: alguien de dirección mira la factura del mes, la compara con la de hace un año, ve que se ha duplicado sin que nadie haya aprobado nada, y pide explicaciones. Entonces se descubre que no hay una sola persona en la empresa capaz de decir qué parte de ese importe corresponde al cuadro de mando, qué parte al asistente que se probó en marzo y qué parte a una máquina que un proveedor encendió hace catorce meses para una prueba.

La nube no sube el precio: sube el consumo. Y sube porque encender recursos es un clic y apagarlos no es tarea de nadie. En un servidor propio el gasto era una decisión anual con una firma detrás; en la nube es la suma de miles de decisiones pequeñas que nadie registró. Esa es la diferencia que hay que gestionar, y no se arregla cambiando de proveedor.

Esta guía recorre de dónde sale el gasto real en proyectos de datos e inteligencia artificial, qué se puede apagar esta misma semana sin romper nada, qué palancas bajan la factura de verdad y cómo presupuestar para que el mes que viene no haya otra sorpresa.

¿Por qué sube sola la factura de la nube?

No sube sola. Sube por cinco causas que se repiten en casi todas las empresas:

• Nadie apaga nada. El entorno de pruebas de un proyecto cerrado sigue encendido. La máquina de la demo de hace un año sigue facturando. Crear tiene dueño; destruir, no.
• Se dimensiona por miedo. Ante la duda de cuánta máquina hace falta, se pide el doble. Funciona, nadie se queja, y ese doble se queda para siempre porque bajarlo da respeto.
• El almacenamiento no se revisa nunca. Los datos entran y no salen. Copias de copias, volcados intermedios de procesos que ya no existen, histórico que nadie ha vuelto a consultar desde 2019.
• Se paga por movimiento, no solo por volumen. Sacar datos de la nube, moverlos entre regiones o consultarlos mil veces al día cuesta dinero aparte del que cuesta guardarlos. Es la partida que más sorprende.
• La factura llega sin desglose útil. Un importe total y doscientas líneas de servicios técnicos. Nadie puede contestar «¿cuánto nos cuesta el proyecto de previsión de demanda?» porque la factura no está organizada por proyectos, sino por servicios.

El patrón de fondo: el coste de la nube es variable y la organización lo trata como si fuera fijo. Nadie revisa mensualmente el alquiler de la oficina porque no cambia. La nube cambia cada día y sigue sin revisarse.

¿De dónde sale el gasto real en un proyecto de datos e IA?

Conviene separar las partidas, porque las palancas para bajarlas son distintas. Esto es lo que compone la factura típica de una plataforma de datos con algo de IA encima:

| Partida | Qué es | Qué la dispara | Palanca principal | |---|---|---|---| | Cómputo | Máquinas y procesos que ejecutan algo | Entornos encendidos sin uso, sobredimensionado | Apagar fuera de horario, ajustar tamaño | | Almacenamiento | Datos en reposo | Histórico sin política, copias duplicadas | Capas por antigüedad, borrado con criterio | | Consultas / procesamiento | Lo que cuesta leer y transformar | Cuadros de mando que refrescan cada 5 min, consultas sin filtrar | Caché, particionado, menos frecuencia | | Tráfico de salida | Sacar datos fuera o entre regiones | Integraciones que mueven todo cada noche | Mover solo lo cambiado, una sola región | | Licencias de plataforma | Herramientas por usuario o por capacidad | Usuarios dados de alta que no entran | Revisión trimestral de altas | | Inferencia de IA | Llamadas a modelos | Volumen, contexto largo, modelo sobredimensionado | Modelo más pequeño, menos contexto |

La primera sorpresa habitual es que el cómputo no suele ser la partida más grande en proyectos de datos maduros: lo es el procesamiento de consultas, porque se paga por cada lectura y los cuadros de mando leen mucho más de lo que nadie imagina. Un panel que refresca cada cinco minutos durante el horario laboral lanza más de cien ejecuciones diarias de las mismas consultas pesadas. Si el dato de origen se actualiza una vez al día, ciento y pico de esas ejecuciones están pagando por devolver exactamente lo mismo.

La segunda sorpresa es el tráfico de salida. Guardar datos es barato; sacarlos, no. Una integración que vuelca cada noche la tabla entera a un sistema externo —cuando podría mover solo las filas que cambiaron— puede costar más que la base de datos que la alimenta.

¿Qué se puede apagar esta semana sin romper nada?

Antes de cualquier rediseño, hay una ronda de limpieza que no requiere proyecto ni aprobación de arquitectura. Por orden de retorno sobre esfuerzo:

1. Recursos huérfanos. Discos que no están conectados a ninguna máquina, direcciones IP reservadas sin uso, copias de seguridad de sistemas que ya no existen. Se identifican en una tarde y se borran sin consecuencias. 2. Entornos de no producción fuera de horario. Desarrollo y pruebas encendidos 24×7 cuando se usan de 8 a 19 de lunes a viernes. Apagarlos por la noche y el fin de semana elimina aproximadamente dos tercios de sus horas. 3. Proyectos terminados. Cualquier cosa levantada «para probar» hace más de seis meses y a la que no ha entrado nadie. Si da miedo borrar, apaga y espera treinta días: si nadie reclama, no hacía falta. 4. Usuarios de licencias. Personas que salieron de la empresa o que nunca llegaron a entrar en la herramienta. Es la línea más fácil de reducir y la que menos se mira. 5. Instantáneas y copias antiguas. Políticas de copia que guardan cada día desde hace tres años porque nadie definió cuánto tiempo hay que conservar.

Si la primera ronda de limpieza no recorta nada, es que alguien ya está haciendo este trabajo. Lo normal es que recorte bastante, y eso dice más del gobierno del gasto que de la tecnología.

Importante: esta ronda es higiene, no estrategia. Baja la factura una vez. Si no se cambia quién vigila el gasto, en doce meses vuelve a estar donde estaba.

¿Cómo optimizar costes en la nube sin frenar el proyecto?

Pasada la limpieza, las palancas estructurales son cuatro. Van de menos a más esfuerzo:

Dimensionar por medición, no por intuición. Mira el uso real de CPU y memoria de las últimas cuatro semanas. Lo habitual es encontrar máquinas al 5-10 % de uso sostenido. Bajar un escalón de tamaño y observar una semana es reversible y suele no notarse. Hazlo de una en una para saber qué cambió si algo va mal.

Comprometer capacidad para lo que es estable. Los proveedores descuentan de forma apreciable a cambio de un compromiso de uno o tres años. La regla es simple: compromete solo la base que sabes que vas a consumir pase lo que pase, y deja a precio normal el pico variable. Comprometer de más es cambiar una factura alta por una factura alta e inamovible.

Poner capas al almacenamiento. No todos los datos necesitan responder en milisegundos. El histórico de más de dos años que se consulta en auditorías puede vivir en almacenamiento frío, que cuesta una fracción. Requiere una decisión de negocio —¿cuánto tardamos en recuperarlo si hace falta?— más que una decisión técnica.

Reducir lo que se lee. Es la palanca de mayor efecto en plataformas de datos y la que más se ignora. Tres medidas concretas: bajar la frecuencia de refresco de los paneles a la frecuencia real de actualización del dato; particionar las tablas grandes por fecha para que una consulta de este mes no barra cinco años; y guardar resultados agregados precalculados en vez de recalcularlos en cada visita. Si estás montando ahora la plataforma, este punto se decide antes en el diseño: es buena parte de lo que separa una ingeniería de datos cara de una barata.

Un apunte sobre arquitectura: la decisión de ETL o ELT tiene consecuencias directas en la factura, porque mueve el trabajo de transformación a sitios que se facturan de forma distinta. No es solo una preferencia de equipo.

¿Cuánto cuesta la parte de IA y cómo se controla?

La inferencia —cada llamada a un modelo— tiene una mecánica de coste propia que conviene entender antes de desplegar nada a toda la empresa:

• Se paga por texto procesado, de entrada y de salida. El contexto que mandas en cada llamada cuenta. Un asistente que adjunta diez documentos completos en cada pregunta paga diez documentos en cada pregunta, aunque la respuesta sean dos líneas.
• El modelo grande no siempre hace falta. Clasificar un correo en cuatro categorías no necesita el modelo más potente del catálogo. Probar con uno pequeño y medir si la calidad aguanta es la optimización de mayor retorno que existe en IA.
• El volumen escala con la adopción, y eso es bueno. Si el coste sube porque la gente lo usa, el problema no es el coste: es que nadie midió el ahorro del otro lado. Para eso está medir el ROI con línea base.
• La recuperación de documentos tiene coste propio. En un sistema RAG, además del modelo pagas por indexar y por consultar el índice. Reindexar el repositorio entero cada noche cuando cambian cuarenta documentos es la versión moderna del volcado nocturno innecesario.

La regla práctica: antes de abrir un asistente a 200 personas, calcula el coste por conversación con una muestra real y multiplícalo por el uso esperado. Sale un número. Si ese número asusta, el momento de saberlo es ahora, no en la factura de dentro de dos meses.

¿Cómo presupuestar la nube sin sorpresas?

Controlar el gasto no es un proyecto de ahorro: es un hábito con tres piezas.

Etiquetar todo lo que se crea. Cada recurso lleva al menos tres etiquetas: proyecto, responsable y entorno. Sin esto no hay forma de contestar cuánto cuesta cada cosa, y sin esa respuesta no hay conversación posible con dirección. Es trabajo aburrido y es el que lo sostiene todo.

Devolver el coste a quien lo genera. Que cada responsable de área vea mensualmente lo que consumen sus proyectos cambia el comportamiento más que cualquier política. No hace falta facturar internamente; basta con que el número sea visible y tenga nombre y apellidos al lado.

Alertas por desvío, no por importe. Una alerta a final de mes cuando se ha superado el presupuesto llega tarde. La útil avisa cuando el ritmo de gasto diario se desvía del esperado, que es cuando todavía se puede apagar lo que se encendió por error.

A eso se suma una revisión mensual de treinta minutos con tres preguntas: qué ha subido respecto al mes pasado y por qué, qué recursos nuevos se crearon y quién los pidió, y qué se puede apagar. Es poco tiempo y es lo único que impide volver al punto de partida. Si estás además en mitad de una migración a la nube, esta revisión debe empezar el primer mes, no cuando termine el proyecto.

Preguntas frecuentes

¿Es más barato volver a servidores propios?

Depende del perfil de consumo. Para cargas muy estables, grandes y previsibles, el servidor propio puede salir a cuenta si se cuenta todo: hardware, sala, electricidad, personal y renovación cada cinco años. Para cargas variables o proyectos que crecen y decrecen, la nube sigue ganando porque pagas el pico solo cuando ocurre.

¿Cuánto se puede recortar en una primera revisión?

No hay un porcentaje honesto que aplicar a ciegas, porque depende de cuánto descontrol haya acumulado. Lo que sí es constante es dónde está el recorte: entornos de no producción encendidos sin uso, almacenamiento sin política de retención y consultas que se repiten sin necesidad.

¿Quién debe responsabilizarse del coste de la nube?

Alguien con nombre, y no puede ser únicamente el equipo técnico. Funciona bien un responsable técnico que vigila el consumo y un responsable de negocio que aprueba el presupuesto por proyecto. Si el coste no tiene dueño en el lado del negocio, se queda sin control real.

¿Optimizar costes puede dejar el sistema lento o inestable?

Puede, si se hace a ciegas. Por eso los cambios se hacen de uno en uno, con una semana de observación y con la posibilidad de deshacerlos. Apagar recursos huérfanos y limpiar copias antiguas es seguro; redimensionar producción sin medir antes, no.

---

La factura de la nube no es un problema técnico: es un problema de gobierno del gasto que se manifiesta en una factura. Si no sabes decir cuánto cuesta cada proyecto, el primer paso no es apagar máquinas, es etiquetar y mirar. En la auditoría revisamos de dónde sale el gasto de tu plataforma de datos y qué parte es recortable sin tocar lo que funciona; si prefieres contarlo en una conversación antes de nada, hablemos.