Cuando Microsoft y ThoughtWorks presentaron la Green Software Foundation en 2021, el computo consciente de carbono era un concepto de nicho que sonaba bonito en presentaciones de sostenibilidad pero tenia poca traccion operativa. Cuatro anios despues, en septiembre de 2025, la situacion ha cambiado de forma silenciosa pero profunda: planificar cargas no interactivas por intensidad de carbono de la red electrica se ha convertido en el comportamiento por defecto en buena parte de la pila moderna. Este post repasa como se llego aqui y que hay que entender para aprovecharlo sin caer en teatro ambiental.
Que 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 dia soleado en el sur de Espanol, la red esta llena de solar y la intensidad puede estar en 80 gramos de CO2 por kilovatio-hora. A las 20:00 del mismo dia, 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 dia puede ser superior a 3 en muchas regiones europeas.
El computo consciente de carbono aprovecha esta variabilidad para ejecutar cargas flexibles en el tiempo, como entrenamientos de modelos, compilaciones de CI, copias de seguridad o 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 mas limpia reduce emisiones de forma proporcional.
Tambien hay una version espacial del mismo principio. Si tu carga puede correr en cualquiera de tres regiones geograficas de tu proveedor cloud, y una de esas regiones tiene una red mucho mas limpia en este momento, ejecutar ahi tiene el mismo efecto. Azure lleva desde 2023 ofreciendo un servicio de optimizacion de carga electrica que funciona asi, Google Cloud tiene Carbon Free Energy Scores para sus regiones, y AWS publica datos de intensidad pero no ha integrado politicas automaticas.
Lo que cambio en dos anios
En 2023 el ecosistema de herramientas era un conjunto de proyectos experimentales sueltos. El Carbon Aware SDK de la Green Software Foundation era util pero requeria bastante integracion manual. ElectricityMaps tenia una API solida pero poca adopcion. Kepler, el exportador de metricas de consumo a Prometheus, acababa de entrar en sandbox de CNCF.
En septiembre de 2025 el panorama esta mucho mas integrado. Kepler es un proyecto graduado de CNCF con despliegues en produccion en Spotify, Red Hat y varias instituciones financieras. El KEDA Carbon Aware Scaler, lanzado en 2024, permite escalar automaticamente cargas Kubernetes segun la intensidad de carbono. GitHub Actions incluye desde junio de 2025 una etiqueta carbon-aware en los ejecutores alojados que retrasa hasta 6 horas los trabajos programados si la red esta sucia. GitLab ha anunciado algo equivalente para octubre.
Lo mas significativo quiza es que muchas plataformas lo han hecho por defecto sin cambiar la API visible. Azure Functions redistribuye tareas de fondo entre regiones de forma transparente, sin que el usuario tenga que configurar nada, y ha publicado datos agregados de la reduccion de emisiones obtenida. Esto es el sintoma de madurez: la conciencia de carbono deja de ser una opcion premium y pasa a ser un ajuste interno del proveedor.
La parte que sigue siendo dificil: medir bien
El problema fundamental del computo 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 numero que publican organismos como Red Electrica de Espanol o ENTSO-E. Es facil 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 calculo 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 que central electrica arranca o apaga en respuesta a un cambio de demanda. Esta es la metrica economicamente correcta pero mucho mas dificil de calcular. WattTime la publica para mercados estadounidenses y ElectricityMaps empezo a ofrecerla en 2024 para Europa. 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 computo consciente de carbono con integridad intelectual, la recomendacion es usar intensidad marginal donde este disponible, y ser transparente con cual de las dos metricas se esta reportando. Las reducciones de emisiones publicadas usando intensidad media suelen estar infladas respecto a las reales, y eso se nota cuando auditan organismos serios.
Patrones que funcionan y patrones que no
El patron 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 busqueda que pueden correr cualquier dia 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 por ciento con casi ningun impacto funcional.
El patron 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 consciencia de carbono temporal sino eficiencia energetica absoluta: perfilar, optimizar consumo por peticion, usar arquitecturas que escalan a cero cuando no hay trafico. Mezclar los dos conceptos es una confusion habitual.
Un patron intermedio interesante es la amortiguacion de picos. Si tu trafico tiene picos diarios previsibles y puedes pre-calcular ciertos resultados durante la noche, mover ese precalculo a las horas de menor intensidad tiene doble beneficio: alivia el pico del dia siguiente y reduce emisiones del precalculo. Este patron funciona bien en sistemas de recomendacion, analisis de logs y generacion de informes programados.
La parte regulatoria que viene
Un factor que pocos equipos estan vigilando pero va a empujar fuerte en los proximos dos anios es la regulacion europea. La Directiva de Eficiencia Energetica revisada en 2023 obliga a los operadores de centros de datos con mas de 500 kilovatios a reportar consumo, mix energetico y emisiones. La siguiente iteracion, esperada para 2026, incluira metricas de uso efectivo y no solo de capacidad instalada. Esto pone presion sobre toda la cadena, incluyendo a los inquilinos de la nube.
En la practica esto significa que los proveedores cloud empezaran a exponer metricas mas detalladas de consumo y emisiones atribuibles a cada cliente. Esto ya se esta viendo en Azure y Google Cloud; AWS sigue mas opaco pero se movera cuando la regulacion apriete. Para un equipo que tenga previsto reportar huella de carbono en el ejercicio 2026, conviene empezar ahora a recolectar estas metricas y a probar patrones conscientes de carbono que resulten auditables.
El riesgo de teatro ambiental
Un riesgo real del computo consciente de carbono es que se convierta en teatro. Un equipo anuncia que su canalizacion de CI es consciente de carbono, obtiene una medalla verde en la documentacion corporativa, y la reduccion real de emisiones es de menos del 5 por ciento porque la mayoria de los trabajos no son retrasables. La promocion supera a la sustancia.
La contramedida es la transparencia en las cifras. Un informe honesto de computo consciente de carbono incluye que proporcion del total de cargas ha sido efectivamente reprogramada, cual fue la reduccion de intensidad ponderada por energia consumida, y que metodo se uso para medir. Si esas tres cosas no se reportan, probablemente la cifra publicada esta inflada. Los auditores ya lo saben.
Mi lectura
El computo consciente de carbono ha pasado de concepto de promocion comercial a capacidad integrada en la plataforma en un plazo muy corto. Esto es una buena noticia para la sostenibilidad operativa del sector, pero exige mas 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 recomendacion practica es clasificar cargas por sensibilidad al tiempo y aplicar la herramienta correcta a cada clase. Cargas por lotes con ventana amplia: activar planificacion consciente de carbono y medir el resultado con intensidad marginal. Cargas interactivas: perfilar, optimizar y escalar a cero cuando se pueda. Cargas hibridas: separar la parte precomputable a horarios limpios y mantener la parte en linea en eficiencia. Reportar cada una por separado.
Lo que me resulta mas interesante de esta transicion es que es de las pocas optimizaciones de software que combinan beneficio ambiental real con ahorro economico en muchos casos. La electricidad mas limpia suele ser mas barata en mercados desregulados, porque el momento de sobra de renovables es tambien el momento en que el precio mayorista cae. Un equipo que planifica correctamente puede reducir factura y emisiones con la misma palanca. Esa alineacion entre economia y ecologia es rara y merece la pena aprovecharla antes de que desaparezca con la saturacion del mercado.
