A Client Asked About AI's Environmental Impact, Here's How I Answered

A client, mid-proposal review, asked directly how much energy the AI features we were proposing would actually consume, and whether it was something they should be worried about publicly. It's a fair question and one I don't think gets a straight answer often enough, because the public discourse around it tends to collapse into either "AI is an environmental catastrophe" or "it's basically nothing, don't worry about it," and neither extreme was the honest answer for their specific proposal.

What actually drives the footprint, for their specific case

The honest breakdown for their proposal: inference calls for a relatively small, well-scoped classification task running at their expected volume have a genuinely modest energy footprint, closer to "basically nothing" than to the training-run energy numbers that get cited in the big dramatic headlines. Those headline numbers are almost always about training frontier-scale foundation models, a cost they weren't incurring at all since we were using an existing hosted model via API, not training anything from scratch.

The AI environmental impact headline you've read is almost certainly about training a model you have no intention of training. Your actual footprint is a different, usually much smaller, number.

What I told them to actually weigh

I gave them the real, use-case-specific framing instead of either extreme: a rough estimate of energy per inference call at their projected volume, a comparison to a familiar baseline activity so the number had context, and a note that choosing a smaller, appropriately-sized model for the task rather than defaulting to the largest available model would meaningfully reduce the footprint for a task this scoped — a choice that also happened to reduce their cost and latency, which made it an easy recommendation rather than a tradeoff.

• Distinguish training footprint (usually not their cost) from inference footprint (usually their actual cost) explicitly.
• Right-size the model to the task — smaller models for well-scoped tasks cut energy use, cost, and latency together.
• Give a concrete, contextualized number rather than a vague reassurance or a vague alarm.
• Be honest that the picture changes completely if they move toward fine-tuning or training custom models later — flag that threshold proactively.

The client appreciated a specific, honest number more than they would have appreciated either a dismissive reassurance or an alarmist caveat, and it's the kind of question I'd rather answer with real numbers scoped to the actual decision than with whichever broad narrative happens to be dominating the news cycle that month.