Sustainable AI Is Product Strategy, not a CSR Footnote
AI features do not just create user value, they create digital demand. Product managers need to account for both.
AI has entered the product roadmap with remarkable speed. In many organisations, it has moved from curiosity to strategic priority before teams have fully developed the judgement needed to use it well.
For technology organisations, AI is no longer only a feature to add to products. It is becoming part of how products are built, operated, sold and improved. Teams are using AI to write code, summarise research, generate designs, support customers, analyse data, produce content, automate workflows and accelerate internal delivery.
It often arrives less like a product decision and more like a productivity upgrade, this is exactly why its sustainability impact is easy to miss.
Office energy is visible, hardware procurement is visible. AI, by contrast, often appears as a prompt box, a model API, a subscription, a code assistant or an embedded capability inside a tool the organisation already uses.
It feels weightless, but it is not. Behind the interface sits compute, energy, data centres, cooling, hardware, networking, model deployment and repeated inference at scale. The International Energy Agency projects that global data-centre electricity consumption will more than double to around 945 TWh by 2030, with AI identified as the most important driver of that growth alongside wider demand for digital services.
This shows how AI is consequential and consequential things belong in product strategy.
The digital demand blind spot
Technology organisations often talk about sustainability through infrastructure, procurement, cloud hosting, offices, hardware and reporting. AI complicates that picture because it can hide inside everyday product and delivery workflows.
If a team uses AI APIs, cloud services, enterprise assistants, SaaS products with embedded AI or internally built AI tools, the environmental impact does not disappear simply because the compute happens somewhere else. The Greenhouse Gas Protocol’s Scope 3 calculation guidance covers emissions across 15 categories, including purchased goods and services. The exact accounting treatment will depend on the supplier, tool, hosting model and reporting boundary, but the strategic point is simpler: AI usage creates digital demand and that demand has to be understood.
The product question cannot stop at whether AI saved time. It also needs to consider what new compute demand was created, how often that demand repeats, whether the same outcome could be achieved with less intensive technology and what happens when a feature scales from a prototype to everyday use.
Technology organisations may not always own every part of the footprint directly, but they shape the conditions that create it.
The demand trap
The sustainability issue is not only the footprint of an individual model call, it is also the competitive pattern AI can create.
Once one team starts using AI to write faster, analyse faster, prototype faster or generate more output at lower marginal effort, others feel pressure to follow. Over time, what was once additional becomes expected. The organisation does not necessarily become calmer or more focused, it may simply process more.
This matters because efficiency does not always reduce total impact. In energy and sustainability research, rebound effects describe situations where efficiency gains lower the cost or effort of an activity and therefore increase overall consumption. AI sustainability researchers Sasha Luccioni, Emma Strubell and Kate Crawford apply this concern directly to AI, arguing that the environmental debate cannot focus only on direct energy use. It also needs to consider indirect effects created by business incentives, market behaviour and organisational norms.
For product teams, this is a critical point. AI can reduce friction, but reduced friction can also increase demand: more artefacts, more variants, more automation and more processing, without necessarily improving the quality of the decision.
The goal is not to slow down useful AI, it is to avoid building a product culture where more processing is mistaken for better judgement.
Measurement is not perfect, but it is possible
One reason organisations avoid this conversation is that AI emissions are hard to measure. This is true, but it is not a reason to ignore them.
Product teams make decisions under uncertainty all the time. They estimate benefits, model costs, compare options and make trade-offs before perfect data exists. Sustainability should be treated the same way: not as a demand for impossible precision, but as a discipline for better decisions.
The most useful move is to define a functional unit. Not simply “what are the emissions of this system?”, but “what are the emissions per useful outcome?” For example, this might mean emissions per resolved customer query, per code change accepted or per case moved forward without quality issues. This connects carbon to value and makes trade-offs visible.
The Green Software Foundation’s Software Carbon Intensity specification, now an ISO-accredited standard, ISO/IEC 21031:2024, provides a practical framework for measuring software emissions, comparing solutions and tracking improvement over time. The point is not to minimise compute in isolation, it is to match the intervention to the outcome.
A high-capability model may be justified for complex work. A smaller model, retrieval approach, rules-based flow, template, cache or better content design may be enough for simpler work. Product teams should be able to explain why the selected level of AI is proportionate to the value being created.
Making the invisible visible
The strategic case for sustainable AI is clear, whilst the harder part is making it practical.
I have been experimenting with this through a desktop tool built using Codex. The tool calls different AI APIs as part of a workflow and automatically logs each interaction: model used, token counts, number of calls, retries, estimated cost and an emissions estimate based on available data.
The estimates are not perfectly accurate. But that is not the point, the point is that previously invisible compute becomes legible.
A raw emissions figure may be technically useful, but it is easier to act on when a team can see it alongside familiar reference points, such as the equivalent energy use of a household appliance or the cost of a repeating workflow at scale. That comparison is not a substitute for formal reporting. But rather, it is a way of helping teams understand scale and ask better questions.
The deeper value is the feedback loop it creates. For example, if the log shows that one workflow drives most of the impact, the team can redesign it or if a frontier model is being used for simple classification, a smaller model can be tested.
The product does not just report its footprint, it learns from it.
This is a useful reminder that sustainable AI practice does not have to begin with a large governance programme. It can start with lightweight instrumentation, clear assumptions and a willingness to make impact visible.
Build sustainability into delivery practice
Measurement is one side of this. The other is building sustainable habits into everyday engineering and product decisions.
I created a sustainability review skill in Claude to assess code, infrastructure, CI/CD pipelines and product decisions against environmental criteria. It reviews areas including algorithmic efficiency, CPU and runtime waste, dependency hygiene, CI/CD waste, telemetry minimisation, cloud resource choices and model usage discipline.
The model usage section is especially relevant to AI product work. It defaults to the smallest adequate model, requires prompt caching for repeated large prefixes, encourages batching and only escalates to a larger model when clearly justified.
That kind of review turns sustainability from an abstract principle into a repeatable delivery habit. It gives teams a way to ask better questions during design, implementation, pre-PR and pre-merge stages, rather than discovering waste after the system is already live.
This is important because many AI sustainability decisions are not made in annual reporting cycles. They are made in ordinary delivery choices, e.g. how often a job runs, how large a prompt becomes, which model is selected, etc.
Small choices compound and AI makes that compounding faster.
A practical pattern for SCI-aware AI products
Product teams building AI applications can start with a simple pattern.
Define the useful outcome. Without a functional unit, the team will only measure activity, not value.
Instrument every AI call. Capture model, provider, feature, workflow, token count, calls, retries, latency, cost and region where available.
Estimate energy and carbon using the best available method. That may mean supplier reporting, cloud emissions dashboards, token-based estimates or fallback assumptions where better data does not yet exist.
Report impact in product terms: per workflow, per document, per completed task or per useful outcome. Include uncertainty rather than pretending the estimate is more precise than it is.
Use the data to improve the product and make changes, e.g. reduce unnecessary model calls, cache repeated answers, shorten prompts, use retrieval more carefully, route simple tasks to smaller models, batch flexible work where possible and remove low-value AI features.
This is not about making product teams become carbon accountants. It is about making cost, carbon, quality and value visible at the same time.
Right-sizing AI is product management
Sustainable AI is not anti-AI. It is against treating AI as exempt from normal product judgement.
Some problems genuinely require powerful models. Complex reasoning, language understanding, multimodal processing and high-quality generation can create real value. But many problems do not require the most capable model available. Some can be solved with better content, search, rules, templates, structured data, workflow redesign or a smaller model.
This is where sustainability and product craft align. A good product manager should already be asking whether a solution is proportionate to the problem. Sustainable AI just adds another dimension to that judgement.
Before scaling an AI product, teams should be able to explain what problem it solves, why AI is better than the alternatives, what model capability is needed, how often it will run, what emissions data is available, what the functional unit is and what limits should be set before usage grows. These questions do not block AI but improve it.
Product strategy means deciding what not to scale
AI will become part of how technology organisations build and operate products. That is not inherently a problem, the problem is treating AI as productivity infrastructure while keeping its environmental impact outside the product conversation.
The future of AI in product management should not be measured only by what it makes faster. It should be measured by whether it helps teams make better decisions, including decisions about the physical infrastructure their digital products depend on.
Technology organisations may not own every emission created by the systems they use or enable, but they do shape demand. They influence architecture, workflows, model choices, procurement decisions, user expectations and the normalisation of AI-enabled delivery. That influence creates responsibility.
Sustainable AI is not a constraint on product ambition, it is how product ambition becomes accountable.