
The environmental debate around AI is often placed in the sustainability section of the company, where it becomes a reporting matter, a disclosure matter, or a reputational matter. By the time it gets there, most of the important decisions have already been made.
The environmental impact of AI is not shaped mainly by the annual report. It is shaped by product choices made much earlier. Which model was selected. How often it is called. Whether the system defaults to generation when retrieval would do. Whether latency targets force expensive compute. Whether every user action triggers inference or only the ones that matter. Whether the team built a feature that solves a real problem or simply adds a layer of fashionable intelligence to something that was already working.
Every model choice is also a resource choice
A strange habit has developed in many AI teams. Model choice is discussed as though it were mainly a question of quality, capability, or technical ambition. Bigger model or smaller model. Faster model or smarter model. In practice, that decision also carries implications for cost, latency, infrastructure strain, and carbon impact.
If a team chooses a heavier model for a use case that only needs a narrower and cheaper one, that is not only an architecture decision. It is a product judgement. The team has decided that the extra compute is justified by the user value. In many cases, nobody says it that directly, which is exactly why the ethics stay fuzzy.
Latency pressure can become an ethical problem, not just a product one
There is another layer that companies do not examine closely enough. The modern product instinct is to push for lower latency at almost any cost. Faster feels better. Faster looks more advanced. Faster improves adoption and makes the feature feel magical.
But in AI systems, faster can also mean more expensive infrastructure choices, more aggressive provisioning, less efficient batching, and more resource-hungry serving patterns. A company may think it is making a user experience decision when it insists on near-instant generation everywhere. In reality, it may be making a hidden decision about energy intensity and carbon burden for a very marginal gain in perceived user delight.
Also Read: How to get beyond the chatbot and boost your AI productivity
A serious team should be able to ask a harder question. Does this use case truly require this speed, or are we burning more compute to remove a few seconds of waiting that users would have accepted quite happily? That is not anti-innovation. It is disciplined judgement.
Carbon is often the result of weak product discipline upstream
Many firms speak about AI emissions as though they are the unavoidable byproduct of progress. That framing lets product teams off too easily. A large share of the environmental cost in AI is not simply the price of doing business. It is the price of design choices that were never challenged properly.
Consider how much waste enters the system through product habits that are treated as normal. Features that call a model too often. Workflows that trigger repeated generation because the first output is not grounded well enough. Interfaces that encourage users to regenerate endlessly because nobody designed for confidence or finality. Architectures that use large models for routine classification or extraction tasks. Orchestration layers that look sophisticated but create multiple expensive calls where one would have been enough.
None of this is abstract. It is the operational reality of many AI products.
When viewed that way, environmental ethics starts looking less like a sustainability speech and more like a test of product seriousness. Teams that cannot control unnecessary inference, retries, and overbuilt flows are not only weak on cost discipline. They are weak on environmental discipline too.
The most responsible AI products will not always be the most technically flamboyant
There is still too much status attached to using the most powerful model available. In some companies, restraint is interpreted as compromise. Smaller models look less ambitious. Simpler architectures look less impressive. Retrieval-first systems can sound less glamorous than generative ones. But the product leader with mature judgement will increasingly ask a more grounded question.
What level of intelligence is actually required for this task?
That question matters because many business problems do not need the full weight of frontier capability on every interaction. Some tasks need reasoning depth. Some need consistency. Some need structured extraction. Some need speed. Some need a safe and bounded answer. Treating all of them as invitations for maximum model power is not thoughtful design. It is often a failure to match compute intensity to user value.
Cost, carbon and user value should be discussed together, not separately
One reason this issue remains weakly governed is that organisations split the conversation into silos. Product talks about user benefits. Engineering talks about performance. Finance talks about cost. Sustainability talks about carbon. By the time those views meet, the feature is usually already live, and the room is arguing over trade-offs that were baked in earlier.
This is the wrong sequence.
Also Read: Product management as method acting: Becoming your user
A stronger company would ask these questions together from the beginning. What value is this feature creating? What is the latency expectation that truly matters? What is the marginal gain from using a more expensive model? What does that do to operating cost at scale? What does it imply for resource consumption? Is there a lighter path to the same user outcome?
Environmental ethics should shape the product brief, not the corporate statement
The most distinctive shift companies need to make is procedural. Environmental responsibility in AI should be built into the product brief itself.
A team should be able to explain why this model class is appropriate for this job. Why this latency level is worth the infrastructure burden. Why is this frequency of inference necessary? Why this workflow cannot be narrowed? Why does this user need to justify this operational intensity? If the team cannot answer those questions clearly, then the sustainability language that appears later is unlikely to mean very much.
This is what makes the issue strategic rather than symbolic. Product leaders decide what gets built, how much complexity gets added, what kind of performance is pursued, and where efficiency is allowed to shape the experience. Those decisions are environmental decisions whether they are written that way or not.
A company that leaves this entirely to sustainability reporting is effectively saying it wants to measure the consequence without governing the cause.
The next generation of strong AI products will look more selective
There is a common assumption that the future belongs to products that apply AI more broadly and more aggressively. In practice, the stronger products may be the ones that apply it more selectively and more intelligently.
They will know where generation is truly useful and where deterministic systems are better. They will know where latency matters and where patience is acceptable. They will know when to reserve heavy models for exceptional cases rather than routine flow. They will treat inference as something to allocate deliberately, not something to spray across the interface because it feels innovative.
That kind of selectivity will produce better economics, better operational control, and a cleaner environmental posture. More importantly, it will reflect a better philosophy of product building.
—
Editor’s note: e27 aims to foster thought leadership by publishing views from the community. You can also share your perspective by submitting an article, video, podcast, or infographic.
The views expressed in this article are those of the author and do not necessarily reflect the official policy or position of e27.
Join us on WhatsApp, Instagram, Facebook, X, and LinkedIn to stay connected.
The post The environmental ethics of AI should be a product decision, not a sustainability footnote appeared first on e27.
