10 Phases to Take Your IT Services Net Carbon Negative (With AI)
TL;DR — AI is making net-zero harder for the companies building it.
But AI-enabled IT services can still be net carbon negative —
if you measure both sides of the ledger and build a tool that proves it.
This is the 10-phase roadmap.
Phase 1: Start With the Uncomfortable Numbers
Before we build anything, let's look at what the data actually says.
Google's 2025 report: emissions +18% YoY. Microsoft: +25%. Meta: +64%.
All driven by AI infrastructure buildout. Data center electricity load at Google
alone grew 37% year over year.
A 2026 Nature study on US AI server deployments found the industry is
unlikely to meet net-zero by 2030 without "substantial reliance on highly
uncertain carbon offset and water restoration mechanisms."
So if someone in your org says "we're carbon neutral because we use AI,"
that's not a defensible claim. The defensible claim is:
AI-enabled IT services reduce more carbon than they emit.
Google's own 2026 report shows 9 AI products enabled 41 Mt CO₂e in
third-party emissions reductions — roughly 3× their own total emissions.
That's the gap we're going to close, phase by phase.
Phase 2: Adopt the Counterfactual Framework
Every claim in this article rests on one equation:
Net Impact = Emissions Generated (digital) − Emissions Avoided (physical baseline)
markdown
If the result is negative, you're net carbon negative.
The critical rule: you must declare what's being replaced, not just
what's being added.
| Scenario | Replaces? | Net Effect |
|---|---|---|
| Video call replaces 500 km car trip | ✅ Yes | Strongly negative |
| Digital document replaces paper + courier | ✅ Yes | Negative |
| AI chatbot adds a layer on top of phone support | ❌ No | Positive (worse) |
| Cloud migration replaces on-prem servers | ✅ Yes | Negative |
Bake this into every tool and report you build. If a use case doesn't
replace something, it doesn't count toward the net-negative claim.
Phase 3: Measure Your Baseline (CodeCarbon + EcoLogits)
You can't prove net-negative if you can't measure the "generated" side.
Two open-source tools from the CodeCarbon non-profit cover the full stack:
CodeCarbon — local & cloud compute
from codecarbon import EmissionsTracker
with EmissionsTracker() as tracker:
# your training / inference / batch job here
train_model()
tracker.print_result()
# Emissions (gCO2eq): 12.45
# Energy (kWh): 0.031
# Carbon intensity (gCO2eq/kWh): 402
Measures CPU, GPU, and RAM power, applies regional grid carbon intensity.
Supports PyTorch, TensorFlow, Hugging Face.
EcoLogits — GenAI API calls
from ecologits import EcoLogits
from openai import OpenAI
EcoLogits.init(providers=["openai"])
client = OpenAI(api_key="sk-...")
response = client.chat.completions.create(
model="gpt-4o-mini",
messages=[{"role": "user", "content": "Summarize this report"}],
)
print(f"Energy: {response.impacts.energy.value.mean} kWh")
print(f"GHG: {response.impacts.gwp.value.mean} kgCO2eq")
Intercepts API responses, extracts token counts and latency, computes
energy via regression curves fitted to benchmark data. Tracks both
operational and embodied (hardware manufacturing) emissions.
Key insight from the 2026 literature: 45% of recent papers now
strictly evaluate software-level carbon estimators like CodeCarbon.
This is no longer a niche concern — it's becoming standard practice.
Deliverable: A carbon_baseline.py script that wraps all your
compute and API calls, logs emissions to a time-series DB, and gives
you a per-service, per-month baseline.
Phase 4: Right-Size Your Models (Biggest Quick Win)
The single highest-impact lever for reducing "generated" emissions
is not switching data centers. It's using the smallest model
that gets the job done.
| Strategy | Typical Reduction | How |
|---|---|---|
| Route simple tasks to small models | 40–70% per query | Intent classifier → model router |
| Quantize models (FP16 → INT8) | 50–75% energy | Minimal accuracy loss |
| Batch processing | 30–80% (batch 8→64) | Amortize fixed overhead |
| Cache frequent queries | 100% for hits | Semantic cache layer |
| Trim context windows | 20–40% | Remove irrelevant tokens |
A simple router pattern:
def route(prompt: str) -> str:
"""Route to the smallest model that can handle the task."""
complexity = classify_complexity(prompt) # LLM or heuristic
if complexity == "simple":
return "gpt-4o-mini" # ~0.02 gCO2e per reply
elif complexity == "medium":
return "gpt-4o" # ~0.1 gCO2e
else:
return "o1" # reasoning model, use sparingly
EcoLogits estimates put a typical small-model reply at under 0.02 g CO₂e,
while a large reasoning model with long output can hit several grams.
That's a 100×+ difference for the same user-facing task.
Deliverable: A model routing layer in your API gateway with
per-request carbon logging via EcoLogits.
Phase 5: Carbon-Aware Scheduling (Shift to Clean Hours)
Not all workloads are real-time. Batch jobs, model retraining,
CI/CD pipelines, data processing — these can be shifted to
hours when the grid is cleaner.
The numbers
- DeepMind load-shifting at Google: 19% reduction with zero training impact.
- Eco-Orchestrator (2026 paper): 34.7% reduction by shifting compute to windows with grid intensity <150 gCO₂eq/kWh.
- Academic HPC clusters (Edinburgh ARCHER2, Stuttgart HLRS, Berkeley NERSC): 15–25% savings from temporal shifting with no measurable impact on time-to-result.
- 2026 survey: ~46% of energy-aware computing papers now focus on carbon-aware scheduling, mostly via metaheuristics (PSO, deep RL).
Implementation sketch
# Pseudocode for a carbon-aware job scheduler
from electricitymaps import get_realtime_carbon_intensity
def should_run_job(job, sla_deadline):
current_intensity = get_realtime_carbon_intensity(job.region)
forecast = get_forecast(job.region, hours_ahead=6)
# Find the lowest-carbon window within SLA
best_window = min(forecast, key=lambda h: h.carbon_intensity)
if best_window.carbon_intensity < 150: # gCO2eq/kWh threshold
return schedule_at(best_window.timestamp)
elif current_intensity < 200:
return run_now()
else:
return defer(job, until=sla_deadline - buffer)
In Kubernetes, this becomes a scheduler plugin that reads
grid carbon intensity from APIs like WattTime or Electricity Maps
and defers non-critical pods to low-carbon windows.
Market context: Carbon-aware data center software is projected
to reach $12.4B by 2030. This is no longer experimental.
Deliverable: A scheduler plugin (K8s or Airflow) that shifts
batch workloads to low-carbon windows, with SLA guardrails.
Phase 6: Optimize the Energy Infrastructure
This is the "boring but essential" phase. You can't be net-negative
if your data center is leaking energy.
| Lever | Impact | Status in 2026 |
|---|---|---|
| 24/7 Carbon-Free Energy (CFE) | Eliminates Scope 2 | Google at 67% globally; replacing annual renewable matching as the standard |
| Liquid cooling | PUE 1.05–1.15 | Now standard for AI facilities |
| Kubernetes autoscaling | 30–50% less overprovisioning | Table stakes |
| Spot instances | Shift to renewable peaks | 60–80% cost + carbon savings |
| Retire unused capacity | 10–20% reduction | Kill experimental envs, idle GPUs, redundant models |
| Edge inference | Reduces data transport | Jetson AGX Orin, Coral, etc. |
The 2026 shift: 24/7 CFE is replacing annual renewable energy
credits as the standard commitment. Hyperscalers are pivoting to
nuclear (Amazon/X-energy, Google/Kairos Power, Microsoft/Three Mile
Island) — $10B+ combined.
For IT services teams, the practical move is:
- Demand 24/7 CFE from your cloud provider (not just "renewable").
- Push PUE < 1.2 in any on-prem you control.
- Kill the dead weight — audit for unused VMs, idle GPUs, orphaned containers. This is free carbon reduction.
Deliverable: An infrastructure carbon audit + a 12-month
energy optimization plan with PUE targets and CFE procurement
milestones.
Phase 7: Quantify Avoided Emissions (Scope 4) — The Multiplier
This is the phase that turns "net positive" into "net negative."
Scope 4 (avoided emissions) is the carbon your customers or
users would have emitted without your service. It's the multiplier
that makes the whole argument work.
How to calculate it
For each service, define the counterfactual (what happens without
your service) and apply standard emission factors:
def calculate_avoided_emissions(use_case: dict) -> float:
"""
use_case = {
"type": "video_conferencing",
"trips_replaced": 500, # business trips/year
"avg_distance_km": 250, # one-way
"car_occupancy": 1.2, # people per car
}
"""
avoided = 0.0
# Business travel
if use_case["type"] == "video_conferencing":
trips = use_case["trips_replaced"]
distance = use_case["avg_distance_km"] * 2 # round trip
# 150 gCO2e per passenger-km by car (DEFRA/ICCT factor)
avoided += trips * distance * 0.150
# Paper
elif use_case["type"] == "digital_documents":
tonnes_paper = use_case["tonnes_paper_saved"]
# ~2.2 kgCO2e per kg of paper (lifecycle)
avoided += tonnes_paper * 1000 * 2.2
# Cloud vs on-prem
elif use_case["type"] == "cloud_migration":
servers_replaced = use_case["servers_replaced"]
# On-prem server: ~500 kgCO2e/year (energy + embodied amortized)
# Cloud: ~200 kgCO2e/year (shared infra, higher utilization)
avoided += servers_replaced * 300
return avoided # kgCO2e avoided per year
The math that sells it
| Use Case | Avoided (kgCO₂e/yr) | Generated (kgCO₂e/yr) | Net |
|---|---|---|---|
| 500 video calls replacing 500 km car trips | 37,500 | ~78 (500 × 0.157 g) | −37,422 |
| 20 tonnes paper → digital | 44,000 | ~5 | −43,995 |
| 10 on-prem servers → cloud | 3,000 | ~2,000 | −1,000 |
| AI logistics optimization (1,000 routes) | ~50,000 | ~200 | −49,800 |
The avoided side is 100–1000× larger than the generated side in
most real-world IT service substitutions.
Deliverable: A scope4_calculator.py module with sector-specific
emission factors, integrated into your dashboard.
Phase 8: Build the Showcase Dashboard
This is the software that makes the case visible to stakeholders
who will never read a CO₂ report.
Architecture
┌──────────────────────────────────────────────────────┐
│ Frontend (React / Streamlit / Dash) │
│ │
│ ┌────────────┐ ┌────────────────┐ ┌───────────┐ │
│ │ Input Form │ │ Waterfall Chart│ │ What-If │ │
│ │ (use case, │ │ (avoided vs. │ │ Sliders │ │
│ │ volume) │ │ generated) │ │ (model, │ │
│ └────────────┘ └────────────────┘ │ volume) │ │
│ └───────────┘ │
├──────────────────────────────────────────────────────┤
│ Backend (Python / FastAPI) │
│ │
│ ┌──────────────┐ ┌──────────────┐ ┌───────────┐ │
│ │ CodeCarbon │ │ EcoLogits │ │ Scope 4 │ │
│ │ (compute) │ │ (GenAI API) │ │ Calculator│ │
│ └──────────────┘ └──────────────┘ └───────────┘ │
│ │
│ ┌────────────────────────────────────────────────┐ │
│ │ Net Impact = Avoided − Generated │ │
│ └────────────────────────────────────────────────┘ │
├──────────────────────────────────────────────────────┤
│ Data Layer │
│ • Grid carbon intensity (Electricity Maps API) │
│ • Cloud provider PUE / CFE % │
│ • Sector emission factors (DEFRA, ICCT, ADEME) │
│ • Time-series store (TimescaleDB / InfluxDB) │
└──────────────────────────────────────────────────────┘
The key UX decision
The dashboard should not lead with "your AI footprint is X kg."
That sounds alarming and invites the "AI is bad" reflex.
Lead with:
"Without this service, the footprint would have been Y kg.
With it, the footprint is Z kg. You saved Y − Z kg."
The waterfall chart shows the avoided emissions as a large green bar
and the generated emissions as a small red bar. The net is the gap.
What-if sliders
- "What if we doubled usage?" → shows the net stays negative
- "What if we switched to a larger model?" → shows the net narrows but stays negative
- "What if we added a new use case?" → shows cumulative net
This is what makes the claim robust to skepticism.
Deliverable: A deployable dashboard (Streamlit is fastest for MVP;
React + FastAPI for production) with the architecture above.
Phase 9: Integrate Into CI/CD (Carbon Gates)
Once you can measure, you can gate.
Add a carbon check to your CI/CD pipeline, the same way you add
linting or security scans:
# .github/workflows/carbon-check.yml
name: Carbon Budget Check
on: [pull_request]
jobs:
carbon:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v4
- uses: actions/setup-python@v5
with:
python-version: "3.11"
- run: pip install codecarbon ecologits
- name: Run carbon test
run: |
python -c "
from codecarbon import EmissionsTracker
with EmissionsTracker() as t:
# Run your test suite / inference benchmark
run_benchmark()
emissions = t.get_total_emissions()
budget = 50 # gCO2e per PR
if emissions > budget:
print(f'::error::Carbon budget exceeded: {emissions:.1f}g > {budget}g')
exit(1)
print(f'Carbon: {emissions:.1f}gCO2e (budget: {budget}g)')
"
This is the FinOps of carbon. You set a budget per PR, per
service, per month. When it's exceeded, the pipeline fails (or warns).
Carbon-aware deployment
For non-critical deployments, shift them to low-carbon windows:
# Deploy only when grid carbon is below threshold
def carbon_aware_deploy(deploy_command, region, threshold=200):
while True:
intensity = get_grid_carbon(region)
if intensity < threshold:
subprocess.run(deploy_command, shell=True)
return
time.sleep(300) # retry every 5 min
Deliverable: CI/CD carbon gates + carbon-aware deployment
script integrated into your pipeline.
Phase 10: Report, Iterate, Prove (The Annual Loop)
The final phase is the one that makes the claim stick.
The annual report format
┌─────────────────────────────────────────────────────────┐
│ Annual Carbon Report — FY2026 │
│ │
│ Emissions Generated (Scope 1+2+3 digital): 12.4 t │
│ Emissions Avoided (Scope 4): 487.2 t │
│ ───────────────────────────────────────────────────── │
│ NET IMPACT: −474.8 t│
│ │
│ By service: │
│ • Video conferencing: −37.4 t (500 trips avoided) │
│ • Digital documents: −44.0 t (20 t paper) │
│ • Cloud migration: −1.0 t (10 servers) │
│ • AI logistics: −49.8 t (1,000 routes) │
│ • All other services: −342.6 t │
│ │
│ Carbon reduction levers applied: │
│ • Model right-sizing: −62% per-query emissions │
│ • Carbon-aware scheduling: −19% batch emissions │
│ • 24/7 CFE procurement: Scope 2 → 0 │
│ • PUE optimization: 1.32 → 1.08 │
│ │
│ Next year targets: │
│ • Expand Scope 4 to 3 new use cases │
│ • Carbon gate in 100% of CI/CD pipelines │
│ • 24/7 CFE for all cloud workloads │
└─────────────────────────────────────────────────────────┘
The honest caveat (include this in every report)
This net-negative claim holds only because the digital service
replaces a more carbon-intensive physical process. If the service
merely adds a digital layer without removing the physical one,
the net effect is positive. We report both sides of the ledger
because we believe the claim is only credible when the math is
visible.
This one paragraph is what separates a credible report from greenwashing.
Deliverable: An automated annual report generator that pulls
from your time-series DB, applies the counterfactual framework,
and produces the waterfall + narrative above.
The Full Stack at a Glance
Phase 1 → Acknowledge the problem (AI is making it harder)
Phase 2 → Adopt the counterfactual framework (avoided > generated)
Phase 3 → Measure baseline (CodeCarbon + EcoLogits)
Phase 4 → Right-size models (biggest quick win, 40–70% reduction)
Phase 5 → Carbon-aware scheduling (15–35% reduction)
Phase 6 → Optimize energy infrastructure (24/7 CFE, PUE, kill dead weight)
Phase 7 → Quantify avoided emissions (Scope 4 — the multiplier)
Phase 8 → Build the showcase dashboard (make it visible)
Phase 9 → Integrate into CI/CD (carbon gates, carbon-aware deploy)
Phase 10 → Report, iterate, prove (annual loop, honest caveats)
What This Is NOT
- It's not a claim that "AI is green." AI infrastructure is energy- hungry, and the 2025–2026 data makes that clear.
- It's not a claim that you can ignore Scope 3 (embodied carbon in GPUs, servers, construction). You can't. But you can manage it through procurement, lifecycle extension, and honest reporting.
- It's not a one-time project. It's a continuous loop: measure → optimize → report → repeat.
What This IS
A defensible, math-backed argument that your AI-enabled IT services
are net carbon negative — with the dashboard to prove it, the
CI/CD gates to enforce it, and the annual report to keep it honest.
The counterfactual is your friend. Use it.
Tools referenced: CodeCarbon,
EcoLogits,
ML CO₂ Impact,
Electricity Maps,
Climatiq,
Net0.
Emission factors: DEFRA, ICCT, ADEME, GHG Protocol.
---
Top comments (0)