Actualizado: 2026-07-07

Cuando Microsoft y ThoughtWorks presentaron la Green Software Foundation en 2021, el cómputo consciente de carbono era un concepto de nicho que sonaba bonito en presentaciones de sostenibilidad pero tenía poca tracción operativa. Cuatro años después, en septiembre de 2025, la situación ha cambiado de forma silenciosa pero profunda: planificar cargas no interactivas por intensidad de carbono de la red eléctrica se ha convertido en el comportamiento por defecto en buena parte de la pila moderna.

Puntos clave

  • La electricidad tiene huella de carbono variable durante el día: el ratio entre el mejor y el peor momento puede superar 3× en muchas regiones europeas, y esa variabilidad es lo que el cómputo consciente de carbono explota.

  • En septiembre de 2025, Kepler sigue en Sandbox de CNCF (no graduado), el operador de KEDA para intensidad de carbono existe pero todavía como propuesta abierta, y servicios de terceros como CarbonRunner enrutan jobs de CI hacia regiones con menos carbono.

  • Hay dos métricas de emisiones muy distintas: intensidad media de la red (fácil, inflada) versus intensidad marginal (más difícil, económicamente correcta).

  • El patrón que mejor funciona es retrasar cargas por lotes con ventana de tolerancia amplia (entrenamientos, indexaciones, backups), con un ahorro del 30 al 50 % y casi ningún impacto funcional.

  • El riesgo de teatro ambiental es real: flipping a checkbox no descarboniza una empresa. La transparencia en las cifras es la única vacuna.

Qué significa exactamente consciente de carbono

La idea central es simple. La electricidad que alimenta un centro de datos no tiene siempre la misma huella de carbono. A las 14:00 de un día soleado en el sur de España, la red está llena de solar y la intensidad puede estar en 80 gramos de CO₂ por kilovatio-hora. A las 20:00 del mismo día, cuando cae el sol y entran ciclos combinados de gas, la intensidad sube a 220 gramos. El ratio entre el mejor y el peor momento del día puede ser superior a 3 en muchas regiones europeas.

El cómputo consciente de carbono explota esta variabilidad para ejecutar cargas flexibles en el tiempo (entrenamientos de modelos, compilaciones de CI, copias de seguridad, procesos por lotes de datos) en los momentos de menor intensidad. Si una tarea puede esperar cuatro horas sin consecuencias, y en esas cuatro horas la intensidad va a bajar a la mitad, ejecutarla en la ventana más limpia reduce emisiones de forma proporcional.

También hay una versión espacial del mismo principio: si tu carga puede correr en cualquiera de tres regiones geográficas de tu proveedor cloud y una de ellas tiene ahora mismo una red más limpia, ejecutar ahí tiene el mismo efecto. Ninguno de los tres grandes lo automatiza todavía sin que el equipo lo pida: Azure Carbon Optimization[1], en vista previa pública desde agosto de 2024, es un panel de emisiones para decidir con datos, no un ajuste silencioso; Google Cloud publica un porcentaje de energía libre de carbono (CFE %) por región y hora; AWS publica su propio dato de intensidad, pero sin política de desplazamiento automático equivalente.

Lo que cambió en dos años

En 2023 el ecosistema de herramientas era un conjunto de proyectos experimentales sueltos. El Carbon Aware SDK de la Green Software Foundation[2] era útil pero requería bastante integración manual. Kepler, el exportador de métricas de consumo a Prometheus para cargas de Kubernetes, acababa de entrar en Sandbox de CNCF.

En septiembre de 2025 el conjunto de piezas encaja mejor, aunque con matices que conviene precisar en lugar de dar por buena la versión de marketing de cada proveedor:

  • Kepler sigue en Sandbox de CNCF[3], aceptado en mayo de 2023, sin graduar todavía. En 2026 pasó por una re-arquitectura para dejar de depender de los privilegios eBPF amplios que dificultaban su despliegue en clústeres de producción con políticas de seguridad estrictas.

  • Microsoft mantiene un operador de KEDA consciente de carbono[4] que frena el autoescalado según la intensidad de la red sin tocar código de aplicación, pero la propuesta para integrarlo en el núcleo de KEDA seguía abierta y sin resolver a mediados de 2026.

  • GitHub Actions no ofrece de forma nativa una etiqueta carbon-aware; lo que existe son servicios de terceros como CarbonRunner[5], que sustituyen el runs-on habitual por ejecutores que enrutan el trabajo hacia regiones con menor intensidad en tiempo real.

  • Azure documenta cómo desplazar cargas en tiempo y en región con el Carbon Aware SDK, y desde agosto de 2024 añade Azure Carbon Optimization como panel de medición; ninguna de las dos piezas actúa todavía por su cuenta.

El síntoma real de madurez no es que la conciencia de carbono ya funcione en piloto automático, sino que ha dejado de exigir tooling artesanal: hoy existe una pieza de infraestructura concreta, con repositorio público y nombre propio, para casi cada capa del problema. Activarla sigue siendo una decisión explícita del equipo, no un ajuste silencioso del proveedor.

Evolución de la inversión en energías renovables, la fuente de variabilidad de la red eléctrica que hace posible el cómputo consciente de carbono al planificar cargas en ventanas de alta generación solar y eólicaEvolución de la inversión en energías renovables, la fuente de variabilidad de la red eléctrica que hace posible el cómputo consciente de carbono al planificar cargas en ventanas de alta generación solar y eólica

La parte que sigue siendo difícil: medir bien

El problema fundamental del cómputo consciente de carbono no es implementarlo, es medir si realmente reduce emisiones. Hay dos formas de medir que dan respuestas muy distintas.

La primera es la intensidad media de la red, que es el número que publican organismos como Red Eléctrica de España o ENTSO-E. Es fácil de obtener pero conceptualmente discutible: si todo el mundo corre sus cargas en las horas de sol, la red deja de tener exceso de renovables en ese momento y la ventana desaparece. El cálculo asume que el consumo marginal es igual al medio, lo que no es verdad en redes con mucha variabilidad.

La segunda es la intensidad marginal, que mide qué central eléctrica arranca o apaga en respuesta a un cambio de demanda. Es la métrica económicamente correcta, pero mucho más difícil de calcular. WattTime publica una señal marginal en tiempo real (MOER)[6] para mercados de Norteamérica. ElectricityMaps investigó una señal marginal por machine learning para Europa a partir de 2024 y terminó retirándola de su producto[7]: su propio equipo documentó que el dato no es observable ni verificable contra una medida real, así que el resultado es un modelo estadístico y no una medición. Esa retirada es en sí misma la lección: la intensidad marginal es conceptualmente mejor, pero construir una señal fiable y auditable sigue sin resolverse, ni siquiera para uno de los proveedores más sofisticados del sector. La diferencia entre media y marginal puede ser del doble: una hora que parece limpia por intensidad media puede ser sucia en marginal si cualquier kilovatio-hora extra lo cubre un ciclo combinado de gas.

Para un equipo que quiera hacer cómputo consciente de carbono con integridad intelectual, la recomendación es usar intensidad marginal donde exista una fuente auditable, hoy sobre todo WattTime en Norteamérica, y ser explícito sobre qué métrica se reporta cuando no la haya. Las reducciones de emisiones publicadas con intensidad media y sin esa aclaración suelen estar infladas respecto a las reales.

Patrones que funcionan y patrones que no

El patrón que mejor funciona es retrasar cargas por lotes con ventana de tolerancia amplia:

  • Entrenamientos de modelos de IA que pueden arrancar en cualquiera de las 4 horas siguientes

  • Indexaciones de búsqueda que pueden correr cualquier día de la semana

  • Copias de seguridad incrementales que aceptan retraso de horas

Para estas cargas el ahorro de emisiones puede ser del 30 al 50 % con casi ningún impacto funcional.

El patrón que no funciona es forzar cargas interactivas a seguir la red. Un servidor web no puede esperar 4 horas a que baje la intensidad porque sus usuarios tampoco van a esperar. Para cargas de servicio la palanca correcta no es conciencia de carbono temporal sino eficiencia energética absoluta: perfilar, optimizar consumo por petición, usar arquitecturas que escalan a cero cuando no hay tráfico. Para ello, herramientas como Parca y Beyla permiten perfilar el consumo real por proceso sin modificar el código.

Un patrón intermedio interesante es la amortiguación de picos: si tu tráfico tiene picos diarios previsibles y puedes pre-calcular ciertos resultados durante la noche, mover ese precálculo a las horas de menor intensidad tiene doble beneficio: alivia el pico del día siguiente y reduce emisiones del precálculo.

La parte regulatoria que viene

Un factor que pocos equipos están vigilando pero va a empujar fuerte en los próximos dos años es la regulación europea. La Directiva de Eficiencia Energética revisada en 2023[8] obliga a los operadores de centros de datos con al menos 500 kilovatios de potencia instalada a reportar consumo, mix energético y emisiones a una base de datos europea (el primer informe, sobre 2023, venció el 15 de septiembre de 2024; desde 2025 el plazo anual es el 15 de mayo). Varios estados miembros han bajado ese umbral al transponer la directiva: Alemania a 300 kW, Francia a 100 kW.

En la práctica esto significa que los proveedores cloud empezarán a exponer métricas más detalladas de consumo y emisiones atribuibles a cada cliente. Para un equipo que tenga previsto reportar huella de carbono en el ejercicio 2026, conviene empezar ahora a recolectar estas métricas y a probar patrones conscientes de carbono que resulten auditables.

El riesgo de teatro ambiental

Un riesgo real del cómputo consciente de carbono es que se convierta en teatro. Un equipo anuncia que su canalización de CI es consciente de carbono, obtiene una medalla verde en la documentación corporativa, y la reducción real de emisiones es de menos del 5 % porque la mayoría de los trabajos no son retrasables.

La contramedida es la transparencia en las cifras. Un informe honesto de cómputo consciente de carbono incluye:

  • Qué proporción del total de cargas ha sido efectivamente reprogramada

  • Cuál fue la reducción de intensidad ponderada por energía consumida

  • Qué método se usó para medir

Si esas tres cosas no se reportan, probablemente la cifra publicada está inflada. Los auditores ya lo saben.

Mi lectura

El cómputo consciente de carbono ha dejado de ser un experimento de nicho para convertirse en una capacidad disponible de fábrica en buena parte de la plataforma moderna, aunque activarla siga siendo una decisión explícita del equipo y no un ajuste invisible del proveedor. Esto es una buena noticia para la sostenibilidad operativa del sector, pero exige más rigor por parte de los equipos. Activar una casilla en un ejecutor de CI no es descarbonizar una empresa, y tratarlo como tal confunde a los responsables de sostenibilidad y diluye la credibilidad de las iniciativas serias.

Mi recomendación práctica es clasificar cargas por sensibilidad al tiempo y aplicar la herramienta correcta a cada clase:

  • Cargas por lotes con ventana amplia: activar planificación consciente de carbono y medir el resultado con intensidad marginal.

  • Cargas interactivas: perfilar, optimizar y escalar a cero cuando se pueda.

  • Cargas híbridas: separar la parte precomputable a horarios limpios y mantener la parte en línea en eficiencia.

  • Reportar cada una por separado.

Lo que me resulta más interesante de esta transición es que es de las pocas optimizaciones de software que combinan beneficio ambiental real con ahorro económico. La electricidad más limpia suele ser más barata en mercados desregulados, porque el momento de sobra de renovables es también el momento en que el precio mayorista cae. Un equipo que planifica correctamente puede reducir factura y emisiones con la misma palanca. Esa alineación entre economía y ecología es rara y merece la pena aprovecharla antes de que desaparezca con la saturación del mercado.

Este artículo también está disponible en inglés: Carbon-aware computing: now the default behavior.

Fuentes

  1. Azure Carbon Optimization
  2. Carbon Aware SDK de la Green Software Foundation
  3. Sandbox de CNCF
  4. operador de KEDA consciente de carbono
  5. CarbonRunner
  6. WattTime publica una señal marginal en tiempo real (MOER)
  7. ElectricityMaps investigó una señal marginal por machine learning para Europa a partir de 2024 y terminó retirándola de su producto
  8. Directiva de Eficiencia Energética revisada en 2023