A practical guide to sustainable AI

Sustainable AI starts before a model is chosen. Define the outcome, decide whether AI is necessary, set quality and environmental requirements, then use the smallest system that completes the task. Measure the whole workflow—including retries and tools—reduce wasted tokens and idle hardware, and prefer lower-carbon infrastructure. Report absolute totals as well as efficiency per result.

This guide treats sustainability as an operating practice, not a product label. No model is impact-free, and no single metric captures electricity, carbon, water, hardware, social value and risk. The goal is to make proportionate choices with a visible boundary, improve them over time and resist turning a renewable contract or climate contribution into a claim that the underlying computation disappeared.

Step 1: define the need and the counterfactual

Write down what the system must achieve and what would happen without it. The alternative might be an existing rule, search function, spreadsheet, smaller statistical model or a person using established software. AI is justified when it improves the outcome enough to warrant its costs and risks.

Choose a functional unit that reflects useful work: one correctly classified document, one resolved request or one accepted summary. Set thresholds for accuracy, safety, latency and human review. This prevents an energy-efficient but unusable system from appearing sustainable.

UNESCO’s Recommendation on the Ethics of Artificial Intelligence frames proportionality and environmental protection as life-cycle responsibilities. That wider view matters. Sustainability includes who bears water, land and material impacts, not only a global carbon average.

Document the decision even when AI is rejected. That creates a reusable record and helps teams resist adding generation later simply because an API has become cheap or fashionable.

Keep the note brief but explicit.

Step 2: establish a measurable baseline

Record model, input and output tokens, request volume, tool calls, retries and success rate. Where possible, measure server electricity and utilisation; otherwise use a documented estimate. Include data-centre overhead and the carbon intensity applied to electricity. Keep embodied hardware and water as separate fields if evidence is incomplete.

Measure both intensity and totals. Energy per successful task can fall while total electricity rises because usage grows. A monthly dashboard should therefore show the rate, the number of functional units and absolute consumption.

Use the same boundary before and after a change. The Software Carbon Intensity specification requires baseline and improved systems to use matching methods and assumptions. That discipline stops a team from claiming progress merely because it excluded supporting equipment or switched denominators.

Attach dates and software versions to the baseline. A comparison made after a provider silently changes its model or serving system may otherwise attribute improvement to the wrong intervention.

Step 3: right-size models and data

Start with the least complex approach that passes the evaluation. A classifier or retrieval system may replace generation. For language tasks, small language models can handle extraction, rewriting and focused assistance with lower computational requirements than much larger models.

Escalate selectively. A router can send routine cases to a smaller model and difficult cases to a stronger one. Test real traffic rather than relying only on general benchmarks, which may not represent your domain, languages or failure costs.

Reduce training waste too. Curate useful data, reuse capable models, fine-tune only when prompting or retrieval cannot meet the need, and stop experiments that are not learning anything. Record unsuccessful runs; hiding them understates development cost and makes later teams repeat the same work.

If a larger model is necessary, narrow where it appears. Escalating a minority of difficult cases can be more proportionate than upgrading the default for all traffic.

Record why escalation occurred.

Step 4: design a lean application

Tokens are a design variable. Remove irrelevant history, retrieve only pertinent passages, cap output at a useful length and summarise long-running conversations. Cache stable responses and embeddings. Combine compatible requests in batches when latency allows.

Tools deserve their own budget. Search, agents and self-checking loops can turn one user action into many model calls. Set maximum steps, end when confidence is sufficient and expose expensive modes as deliberate choices. Better prompts should reduce ambiguity, not merely be short; a clear request that succeeds once beats several terse retries.

Evaluate the full chain after each change. Quantisation, pruning and mixture-of-experts systems can lower some compute, but networking, memory, retrieval and application code still consume resources. Optimise the bottleneck you actually measure.

User experience can prevent waste as well. Show when a costly mode is active, make cancellation immediate and preserve completed work so an interrupted task does not restart from zero.

Step 5: run infrastructure efficiently

Choose hardware suited to the workload, then keep it usefully occupied. Batching, autoscaling and efficient inference engines can reduce energy per result. Avoid reserving large accelerators for sporadic jobs that run adequately elsewhere. Extend hardware life when the operational gain from replacement does not justify new embodied impacts.

Location and time change operational emissions. Shift flexible training or batch jobs towards lower-carbon hours where that does not move harm to water-stressed or grid-constrained communities. Prefer providers that disclose physical grid effects, facility efficiency and procurement rather than offering a single green badge.

Renewable-energy data centres can materially reduce carbon, but annual certificates do not prove every hour was fossil-free. Electricity supply, water, construction and chips need their own claims and evidence.

Include resilience in the infrastructure decision. A low-carbon location that causes frequent failures and repeated jobs may not improve the complete workflow, while reliable scheduling can protect both results and resources.

Step 6: govern use and avoid rebound

Efficiency makes AI cheaper and easier to add. Without limits, more features and traffic can erase per-task gains. Give each new use case an owner, a volume expectation and a review date. Retire experiments and generated content that no longer serve a purpose.

Procurement teams should ask vendors for model names or classes, energy boundaries, locations, renewable accounting, water metrics and hardware life-cycle data. Confidential details may remain, but “proprietary” should not excuse the absence of any environmental evidence.

Publish uncertainty and corrections. Separate measured values from estimates, location-based emissions from contractual accounting, and reductions from contributions or offsets. Green AI is credible when efficiency and absolute demand remain visible together.

Give product teams a stopping rule. If adoption or success remains below the agreed threshold, remove the feature and release its reserved capacity instead of letting a pilot become permanent by neglect. Review that rule on schedule.

Act promptly.

A simple practice for everyday users

Individuals cannot select data-centre cooling, but they can avoid needless work. Use ordinary software when it is sufficient. Choose a smaller capable model, keep context relevant, request a proportionate answer and stop regenerating once the result works. Our guide to reducing your AI carbon footprint turns these into quick decisions.

Treechat makes one part of that practice visible. It routes routine questions towards smaller models and estimates operational energy from model and token use, with published allowances for data-centre overhead and grid carbon. It cannot see a live facility meter, training allocation or complete hardware life cycle. Those boundaries are explicit at /methodology.

Sustainable AI is not achieved once. Models, traffic and electricity systems change, so measure again after launch. Keep the useful outcome constant, lower the resources needed to deliver it, watch absolute growth and describe remaining impacts plainly.

For personal use, that review can be simple: notice which tasks create long conversations or repeated outputs, then change the default next time rather than trying to calculate every gram yourself.