Green AI es la práctica de diseñar, entrenar y operar sistemas de inteligencia artificial que cumplen su objetivo con el menor impacto ambiental compatible con la calidad, la seguridad y el servicio requerido. No equivale a usar un centro de datos «verde», elegir un modelo pequeño ni comprar compensaciones. Es una disciplina de ingeniería: fija una unidad de trabajo, mide el sistema completo, compara alternativas equivalentes y evita que una mejora local aumente el impacto total.

Esta guía convierte el concepto en decisiones concretas. Sirve tanto para un modelo propio como para una API generativa y distingue las palancas que actúan sobre datos, arquitectura, entrenamiento, inferencia, infraestructura y operación.

1. Qué es Green AI y qué no es

Conviene separar dos ideas. Green AI, o sostenibilidad de la IA, intenta reducir los impactos del propio sistema. AI for Green utiliza IA para un objetivo ambiental, como prever generación renovable o detectar fugas de agua. Un proyecto puede pertenecer a ambas categorías, a una sola o a ninguna.

La distinción importa porque una aplicación con finalidad climática también consume electricidad, agua y hardware. Para afirmar que produce un beneficio neto hay que comparar el escenario con IA con una línea base realista sin ella. Nuestra guía sobre el impacto ambiental de la IA generativa desarrolla los límites del ciclo de vida; aquí nos concentramos en cómo intervenir sobre el diseño.

La recomendación ITU‑T L.1801 organiza la evaluación desde concepción y desarrollo hasta operación y retirada. Este enfoque impide declarar sostenible un modelo solo porque su inferencia es rápida: también existen preparación de datos, experimentos fallidos, capacidad ociosa, fabricación de equipos y fin de vida.

Afirmación	¿Demuestra Green AI?	Qué falta comprobar
«Usamos energía renovable»	No por sí sola	Consumo, ubicación, correspondencia temporal y efectos locales
«El modelo tiene pocos parámetros»	No por sí sola	Calidad, número de intentos, hardware y carga completa
«La GPU es muy eficiente»	No por sí sola	Utilización real, servidor, refrigeración y vida útil
«Compensamos las emisiones»	No	Reducción directa y contabilidad separada de cualquier compensación
«Bajamos los Wh por resultado válido»	Es una evidencia útil	Carbono, agua, materiales, volumen total y límites del cálculo

2. Medir antes de optimizar

Una optimización sin línea base puede trasladar el consumo de un componente a otro. La medición debe empezar con una descripción del servicio: entrada, salida, criterio de aceptación, nivel de disponibilidad y periodo observado.

Definir una unidad funcional

La unidad funcional representa el valor entregado. Puede ser una imagen aceptada a una resolución concreta, mil documentos clasificados con una precisión mínima, una hora de audio transcrita o una incidencia resuelta. La ITU recomienda declarar esta unidad, los límites del sistema, las fuentes y las asignaciones.

Separar energía, carbono, agua y materiales

Estos indicadores están relacionados, pero no son intercambiables. La electricidad se expresa en Wh o kWh; las emisiones dependen, entre otros factores, del mix eléctrico y del momento; el agua depende de la refrigeración y de la generación eléctrica; el impacto incorporado procede de fabricar y retirar equipos. Una mejora en energía no garantiza el mismo porcentaje de reducción en los demás indicadores.

Incluir el sistema de producción

Google mostró por qué el perímetro cambia el resultado en su metodología para la inferencia de Gemini: además del acelerador activo incluyó CPU y RAM anfitrionas, capacidad inactiva asignada y sobrecarga del centro de datos. La cifra resultante no debe extrapolarse a otros servicios, pero la lección metodológica sí: medir solo la potencia del chip subestima la operación.

3. Elegir el modelo mínimo suficiente

El modelo «más capaz» no es automáticamente el adecuado. La decisión debe realizarse contra un conjunto de pruebas representativo, no contra una demostración llamativa.

Empezar por la alternativa sin IA

Una regla, una consulta SQL, una plantilla o una búsqueda convencional pueden resolver tareas deterministas con menos complejidad. La primera pregunta de Green AI es si el modelo aporta una mejora verificable frente a esa línea base.

Aplicar escalado progresivo

Un patrón robusto es usar una cascada: regla o caché para casos conocidos, modelo pequeño para casos habituales y modelo mayor solo cuando la incertidumbre o la dificultad lo justifican. El enrutador también consume y puede equivocarse, por lo que debe evaluarse como parte del sistema.

Comparar por calidad constante

Precisión, cobertura, tasa de resolución, alucinaciones, latencia y seguridad deben tener umbrales previos. Después se compara la energía entre configuraciones que los superan. Si se cambia a un modelo más pequeño y cae la calidad, los reintentos humanos o automáticos pueden anular el ahorro.

Decisión	Cuándo probarla	Riesgo que hay que medir
Modelo más pequeño	Tarea estrecha o repetitiva	Pérdida de calidad en casos raros
Cascada de modelos	Dificultad muy desigual	Errores del enrutador y doble ejecución
Recuperación de información	Conocimiento acotado y cambiante	Coste de indexación y contexto demasiado largo
Caché semántica	Consultas repetidas	Respuestas obsoletas o incompatibles con privacidad
Procesamiento por lotes	Trabajo no interactivo	Latencia y acumulación de cola

4. Reducir el coste ambiental de los datos

Datos redundantes, de baja calidad o conservados sin propósito aumentan almacenamiento, transferencias y ciclos de entrenamiento. La guía del Programa Nacional de Algoritmos Verdes sobre datos y algoritmos propone filtrar redundancias, reutilizar conjuntos existentes, comprimir y seleccionar arquitecturas acordes con el caso de uso.

Calidad antes que volumen

Antes de ampliar un conjunto conviene localizar duplicados, ejemplos corruptos, etiquetas incoherentes y variables que no participan en la decisión. Una reducción debe validarse por subgrupos: eliminar datos de forma indiscriminada puede perjudicar casos minoritarios aunque mejore la media.

Evitar recomputación

Versionar datos y transformaciones permite reutilizar artefactos válidos. Si cada experimento vuelve a descargar, limpiar y vectorizar todo el corpus, el gasto del preprocesamiento queda oculto en la métrica del entrenamiento. Deben registrarse tanto los pasos compartidos como los específicos de cada prueba.

Establecer retención y retirada

No todo dato debe conservarse indefinidamente. Una política útil define propósito, responsable, fecha de revisión, restricciones legales, dependencias y eliminación segura. El ahorro de almacenamiento es secundario a privacidad y trazabilidad: Green AI no justifica borrar evidencia necesaria ni reutilizar información sin autorización.

5. Entrenar con un presupuesto de cómputo

El coste relevante no es solo la ejecución final. Búsquedas de hiperparámetros, pruebas abandonadas, ajuste y reentrenamientos forman parte del desarrollo. Un presupuesto explícito obliga a priorizar los experimentos que reducen incertidumbre.

Partir de una línea base barata

Un modelo simple detecta pronto si la señal de los datos es suficiente. Después se incrementa complejidad solo cuando la mejora en el indicador de negocio y calidad lo compensa. Para no confundir progreso con azar, cada experimento debe registrar código, datos, semilla, hardware, duración y resultado.

Reutilizar en vez de entrenar desde cero

Transfer learning, ajuste eficiente en parámetros y destilación pueden reducir el trabajo frente a un entrenamiento completo, pero no son ahorros garantizados. Hay que sumar la generación de datos, el modelo docente, los ensayos y la inferencia posterior. La decisión correcta depende del volumen de uso: una optimización costosa puede amortizarse en millones de ejecuciones y no en un prototipo breve.

Detener experimentos que no prometen

El early stopping y la poda de configuraciones evitan completar ensayos claramente inferiores. Antes de aplicarlos hay que fijar el indicador y una regla de parada reproducible; detener solo cuando «parece suficiente» impide comparar resultados.

6. Optimizar la inferencia que ocurre de verdad

En producción importan la distribución de solicitudes, la concurrencia, el contexto, la longitud de salida y el porcentaje de respuestas aceptadas. Un benchmark sintético a máxima ocupación puede no representar un servicio con picos y capacidad ociosa.

Reducir trabajo que no aporta valor

• limitar contexto a documentos pertinentes en vez de enviar historiales completos;
• fijar longitudes de salida coherentes con la tarea;
• agrupar solicitudes compatibles cuando la latencia lo permita;
• reutilizar resultados seguros y vigentes;
• detectar bucles de agentes y establecer presupuestos de pasos;
• retirar endpoints, índices y modelos que ya no reciben tráfico útil.

Probar cuantización, poda y destilación

Reducir precisión numérica, eliminar pesos o transferir capacidades a un modelo menor puede disminuir memoria y acelerar la ejecución. La documentación de TorchAO de PyTorch reúne cuantización y sparsity para entrenamiento e inferencia. Sus mejoras publicadas pertenecen a configuraciones concretas: cada equipo debe volver a medir calidad, latencia y energía sobre su propio hardware.

Contar fallos, no solo éxitos

Timeouts, respuestas filtradas, regeneraciones y llamadas internas también consumen. El denominador debe ser el número de resultados válidos entregados. Para agentes, además conviene registrar pasos por tarea, llamadas de herramientas, tokens recuperados y porcentaje de tareas abandonadas.

7. Hardware, nube, carbono y agua

La Agencia Internacional de la Energía estimó que todos los centros de datos consumieron unos 415 TWh en 2024, alrededor del 1,5 % de la electricidad mundial, y proyectó cerca de 945 TWh para 2030. Son cifras del conjunto de centros de datos, no del consumo exclusivo de IA. La AIE también advierte que la concentración geográfica hace que el efecto sobre redes locales sea más intenso que la cuota mundial.

Buscar utilización, no solo potencia

Un acelerador reciente puede ejecutar más trabajo por unidad de energía, pero sustituir equipos antes de tiempo incorpora nueva fabricación. Conviene comparar energía por resultado, utilización prevista, vida útil, reparabilidad y huella incorporada. El grupo MLCommons Power desarrolla procedimientos para medir potencia y eficiencia junto con el rendimiento en benchmarks MLPerf; es una referencia para exigir comparaciones reproducibles.

Región y horario necesitan contexto

Mover cargas flexibles a horas o regiones con menor intensidad de carbono puede reducir emisiones operativas. No debe hacerse a costa de duplicar datos, incumplir residencia, degradar la red o aumentar el estrés hídrico. El factor medio anual tampoco describe una hora concreta; la granularidad debe corresponder a la decisión.

El PUE no describe todo el impacto

El PUE relaciona la energía total de la instalación con la usada por equipos TI. Ayuda a analizar refrigeración y distribución, pero no informa por sí solo del carbono de la electricidad, agua, fabricación o utilidad de la carga. La guía de infraestructuras sostenibles del PNAV amplía la revisión a ubicación, energía, mantenimiento, reparación y reciclaje.

8. Protocolo para comparar dos configuraciones

1. Fijar la tarea y el umbral. Por ejemplo, mil documentos con F1 mínima, latencia máxima y mismos controles de seguridad.
2. Congelar el conjunto de prueba. Debe incluir casos habituales, difíciles y grupos relevantes.
3. Describir ambas configuraciones. Modelo, versión, precisión, hardware, región, software, tamaño de lote y caché.
4. Calentar y repetir. Separar arranque de régimen estable y realizar suficientes repeticiones para mostrar variabilidad.
5. Medir el perímetro. Acelerador, host, memoria, tiempo, capacidad ociosa asignada y sobrecarga de instalación disponible.
6. Contar salidas válidas. Incluir fallos, reintentos y rutas alternativas.
7. Calcular intensidad. kWh y, cuando sea posible, gCO₂e y agua por resultado válido.
8. Analizar sensibilidad. Repetir con distintos volúmenes, longitudes y factores de emisión.
9. Documentar límites. Dato medido, estimado, omitido y razón de cada corte.
10. Decidir y vigilar. Publicar el criterio de elección y comprobar deriva de calidad y consumo.

Métrica	Configuración A	Configuración B	Criterio de decisión
Resultados válidos / total	Medir	Medir	Superar el umbral de calidad
Wh por resultado válido	Medir	Medir	Menor, con igual perímetro
Latencia p95	Medir	Medir	Cumplir el servicio
gCO₂e por resultado	Calcular con fuente y fecha	Calcular con fuente y fecha	Menor sin desplazar impacto
Coste incorporado	Declarar cobertura	Declarar cobertura	Considerar vida útil y hardware nuevo

La guía del PNAV sobre configuración de la ejecución añade prácticas de versionado, reproducibilidad, hardware, software y ejecución distribuida. Resulta útil como lista de control, pero no sustituye la medición del caso real.

9. Patrones útiles y antipatrones frecuentes

Patrones que suelen merecer una prueba

• Presupuesto por tarea: límite de tokens, pasos, reintentos o segundos antes de escalar.
• Cascada observable: rutas simples primero y registro de cuándo se activa el modelo mayor.
• Artefactos reutilizables: datos procesados, embeddings y modelos versionados.
• Control de regresión ambiental: el pipeline falla si empeora energía por resultado más allá del margen aceptado.
• Retirada explícita: modelos y recursos inactivos tienen propietario y fecha de baja.

Antipatrones que producen falsas mejoras

• comparar modelos con distinta calidad o tareas diferentes;
• informar potencia nominal como si fuera energía consumida;
• ignorar CPU, memoria, almacenamiento, red y capacidad ociosa;
• optimizar Wh por consulta mientras aumenta el número de consultas;
• cambiar de hardware sin contabilizar fabricación y vida útil;
• presentar energía contratada como impacto cero;
• publicar una estimación sin fecha, perímetro ni incertidumbre.

Después de revisar las metodologías oficiales, el patrón común es sencillo: cada afirmación ambiental necesita un denominador, un límite del sistema y una fecha. Sin esos tres elementos, una cifra precisa puede ser poco informativa.

10. Preguntas frecuentes

¿Green AI significa usar modelos pequeños?

No. Un modelo pequeño puede requerir más reintentos o no superar el umbral. Green AI elige la configuración con menor impacto por resultado válido, incluida la calidad.

¿Cuantizar siempre reduce el consumo?

No puede darse por supuesto. Suele reducir memoria y puede mejorar rendimiento, pero el efecto depende del hardware, el software, el tamaño de lote y la pérdida de calidad. Hay que medir antes y después.

¿Es mejor ejecutar en local o en la nube?

No existe una respuesta universal. En local puede aprovecharse un equipo ya disponible; la nube puede lograr mejor utilización. Deben compararse energía por tarea, mix eléctrico, transferencia, capacidad ociosa, vida útil, privacidad y servicio.

¿Basta con conocer el PUE del centro de datos?

No. El PUE solo describe la sobrecarga energética de la instalación. No mide utilidad, carbono de la electricidad, agua ni fabricación del hardware.

¿Cómo se evalúa una API que no publica su energía?

Se documenta la ausencia, se mide la actividad accesible —modelo, tokens, llamadas, reintentos y resultados válidos— y se piden datos al proveedor. Una estimación externa debe presentarse como escenario, no como telemetría.

¿La eficiencia garantiza una reducción total?

No. Si una tarea se abarata puede usarse mucho más, fenómeno conocido como efecto rebote. Por eso se vigilan tanto la intensidad por resultado como el consumo total mensual.

¿Qué debería aparecer en un informe Green AI?

Objetivo, unidad funcional, calidad, límites, periodo, versiones, hardware, energía, factores de emisión, agua y materiales cubiertos, volumen, incertidumbre, exclusiones y medidas de reducción. Si se comparan alternativas, deben compartir tarea y umbrales.

Conclusión: Green AI es una disciplina de decisiones

Una IA más eficiente nace de una cadena de elecciones comprobables: no automatizar lo que una regla resuelve, usar el modelo mínimo suficiente, depurar datos, limitar experimentos, reducir trabajo inútil en inferencia, aprovechar el hardware y operar con contexto territorial. Ninguna técnica aislada convierte un sistema en sostenible.

El orden recomendado es evitar, medir, reducir y volver a medir. Solo después tiene sentido comunicar el resultado. Así, Green AI deja de ser una promesa y se convierte en un proceso que un tercero puede revisar y repetir.

---

Fuentes y método editorial: síntesis propia basada en ITU‑T L.1801 (febrero de 2026), Energy and AI de la AIE, guías del Programa Nacional de Algoritmos Verdes, metodología de inferencia de Google, MLCommons Power y documentación de PyTorch/TorchAO. Las cifras de proveedores se consideran específicas de su sistema y periodo; no se extrapolan a otros modelos. Última revisión: 28 de julio de 2026.