Organisations should measure AI emissions across the full lifecycle, not just training. The biggest gains usually come from deployment choices, because inference can dominate total energy use once a model is in production. Practical steps include using smaller task-specific models where possible, reducing unnecessary prompts, improving model efficiency, and choosing data centres and hardware with lower power and cooling overheads.
Training and deployment both matter, but deployment usually drives the biggest footprint
Reducing the environmental impact of large language model starts with treating emissions as a lifecycle issue. Training is visible and resource intensive, but once a model is in production, inference can become the larger source of energy use because every user request repeats the cost. That is why the most effective reductions usually come from deployment design, workload sizing, and infrastructure choices rather than training alone.
Organisations should first decide whether a large general-purpose model is actually required for the task. A smaller task-specific model, selective routing, or tighter prompt design can reduce compute demand without changing the business outcome. This is where the biggest operational trade-offs appear: lower latency, lower cost, and lower power use are often aligned when teams avoid overbuilding the model path.
For practitioners, the key control point is not “use AI more efficiently” in the abstract. It is to understand which workloads are frequent, which prompts are wasteful, and which model choices create avoidable repetition. The same logic applies across training and deployment, but deployment tends to deliver faster and larger savings because it affects every inference call.
What changes emissions most in practice
The main levers are straightforward. Organisations can improve efficiency by reducing prompt bloat, caching repeated outputs where appropriate, batching requests, using quantised or distilled models, and selecting hardware and cloud regions that deliver better performance per watt. Data centre efficiency also matters, because power distribution and cooling overhead can materially change the footprint of the same workload.
Lifecycle measurement is essential if the goal is real reduction rather than a cleaner estimate. Teams should track training runs, fine-tuning, inference volume, model size, and infrastructure utilisation together, because a model that looks efficient in training can still be wasteful in production if it is called excessively or deployed too broadly. If you do not measure inference separately, you will usually optimise the wrong part of the system.
Where AI is delivered through shared platforms, the environmental impact also depends on governance decisions around access and usage patterns. Overly broad access to a general-purpose model can create excessive or duplicate demand, just as poor request discipline can inflate energy use. That makes usage policy and workload routing part of the sustainability problem, not just engineering preferences. See also the Ultimate Guide to NHIs for broader governance patterns that help reduce unnecessary system activity.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
NIST CSF 2.0, NIST AI RMF, NIST AI 600-1 and CIS Controls v8 set the technical controls, while ISO/IEC 42001:2023 define the regulatory obligations.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST CSF 2.0 | GV.RM — Risk Management Strategy | Lifecycle emissions measurement is a governance risk-management concern for AI operations. |
| Recommendation — Track model energy and emissions as part of enterprise risk management for AI services. | ||
| NIST AI RMF | MEASURE — Measure AI risks and impacts | This topic depends on measuring lifecycle impacts, not only training runs. |
| Recommendation — Measure training and inference impacts separately to guide lower-carbon model choices. | ||
| ISO/IEC 42001:2023 | A.6 — AI system lifecycle | Reducing environmental impact requires lifecycle controls across training and deployment. |
| Recommendation — Build lifecycle impact checks into model selection, deployment, and change management. | ||
| NIST AI 600-1 | MAP — Map generative AI context and use | GenAI footprint depends on use-case mapping, workload fit, and deployment context. |
| Recommendation — Map each GenAI use case to the smallest model and deployment pattern that meets the need. | ||
| CIS Controls v8 | 8 — Audit Log Management | Operational measurement of model usage and inference volume depends on reliable telemetry. |
| Recommendation — Log model requests and infrastructure usage so you can identify wasteful inference patterns. | ||
Practitioner Guidance
What to prioritise: Focus first on the highest-volume inference workloads, because they often outweigh training once the model is live. The fastest wins usually come from replacing oversized models, trimming repeated prompts, and eliminating unnecessary calls before you invest in deeper infrastructure changes.
What to verify: Measure energy and emissions across training, fine-tuning, and production inference separately. If a dashboard only shows training cost, it will miss the point where most operational impact accumulates. Track request volume, model selection, and hardware utilisation together so you can see whether changes are actually reducing total compute demand.
What good looks like: The model portfolio is tiered by use case, high-volume tasks are routed to smaller or more efficient models by default, and deployment environments are chosen for efficiency as well as availability. In mature setups, teams can explain why a given model is used, how often it is called, and what footprint that choice creates.
Practitioner takeaway: Environmental reduction is usually won in production design, not in a one-time training optimisation, so the real objective is to minimise repeated compute without degrading the task outcome.
Related resources from NHI Mgmt Group
- What breaks when organisations do not test large language models for privacy leakage before deployment?
- Why do large language models create risk when organisations use them with sensitive data or operational knowledge?
- How should security teams reduce identity risk when employees use large language models with sensitive enterprise data?
- How should organisations reduce security risk when fine-tuning code generation models on mixed-quality training data?
