Responsible AI Starts With the Infrastructure You Choose

When people talk about responsible AI, they usually mean a policy. A set of principles, a review board, a page on the website saying the company cares about fairness and transparency. I don’t think those documents are useless. But after running agents on our own work and measuring what they actually do, I’ve come to believe most of the responsible decisions get made much earlier, by people who rarely think of themselves as making them.

They get made when someone picks a model, decides where it runs, decides what it’s allowed to touch, and decides what gets written down after it acts. Those choices set how much energy a task burns, what it costs, how far a mistake can travel, and whether anyone can reconstruct what happened afterward. A policy written after the fact can describe those choices, but it usually can’t change them.

So this piece covers three things we now treat as part of responsible AI from the first day of any build. The environment the system draws on, the impact of what it produces, and the infrastructure we choose on purpose to hold both.

The environmental cost of AI is mostly set by the model you pick

Every model call runs on hardware in a data center that draws power, and depending on where that data center sits, some of the power comes from burning something. That part is well known. What gets discussed much less is how much of the footprint is decided by a single procurement choice.

We measured this on ourselves. Across 61 real working sessions, we compared our own harness, Ultimus, running an open-weight model against Claude Code running Opus 5, using real token counts and real price tables. The cost result was measured and large. Ultimus came in about 110 times cheaper per 1,000 output tokens. Then we forced both setups onto the same energy scale to see how much of that gap came from our own engineering, and the harness itself accounted for roughly 1.2 times. Nearly all of the difference came from which model we chose to run. The full method and its limits are on the benchmark page.

Carbon is harder, and I want to be careful here, because this is where claims about sustainable AI tend to get sloppy. Tokens and dollars can be measured. Energy per token can’t, at least from outside the provider, because nobody publishes how much more energy a frontier model’s token takes than a token from a smaller model. Our estimate for a completed task lands somewhere between about 3 and 25 times lower, and that range is wide on purpose. It rests on an assumption nobody can currently verify, and it accounts for the smaller model needing more steps to finish the same work (15 steps against 8 on one fix we tracked). If someone quotes you a single precise carbon saving for an AI system, it’s fair to ask which assumption they picked and why.

Two practical lessons came out of this for us. The first is that step count matters more than price per token. A cheap model that wanders through fifteen attempts can burn more than an expensive one that finishes in eight, so anything that shortens the loop is also an environmental improvement. The second is that the model deserves the same scrutiny as any other supplier with a footprint, and the decision should be revisited regularly, because the right answer changes as models change.

There are parts we don’t measure yet, and water used for cooling is one of them. We report what we can measure, label what we estimate, and say plainly what’s missing. I think that’s the minimum anyone should expect from a vendor making environmental claims about AI, us included.

The impact of the output

The second part of responsible AI is what the system does with what it produces. A chatbot that writes a bad paragraph wastes someone’s afternoon. An agent that reroutes inventory, changes a production database, or files something on a customer’s behalf can do real damage, and it does it quickly.

So we judge an output by its consequences, and we try to settle those consequences before the action runs. For every agentic workflow we build, that comes down to a few concrete questions. What can this action change, and can it be undone? Who approved the boundary it’s operating inside? What did the agent see when it decided? And what did the action cost in money, compute and energy?

If those questions only get answered after an incident, the system was never really under control. The answers need to exist as a record at the moment of action, readable by the agent and by the people accountable for it. We wrote about why that record can’t live in a paragraph of setup text in Why Static Prompts Fail AI Agents. The business keeps moving, and a prompt written on setup day stays exactly as it was.

People matter here too. They review what the system did, and for anything consequential they sign off on it. A named person approving an action against a boundary that was set in advance is something you can show an auditor. A dashboard nobody has to sign is much weaker evidence.

Choosing AI infrastructure on purpose

The third part ties the first two together. Infrastructure is where the environmental and impact decisions actually live, so we try to choose each piece of it deliberately and be able to explain why. A few examples from the Ultimus harness show what that looks like in practice.

• The model is a variable. The harness is model-agnostic, so the model can change as prices, capability and energy use change, without rebuilding everything around it. Locking into a single provider hands every future footprint decision to someone else.
• Where the system runs is a decision. Some work belongs inside your own environment. When an operator marks up a screenshot to show the agent a layout problem, the capture and the annotation stay on the local machine, with no network call and no third-party vision service holding a picture of someone’s screen. For confidential work, that decides whether a capability is allowed in the room at all.
• What gets recorded is a decision. Cost, energy estimates and permissions are recorded for each action and served back to both the agent and the people governing it. The agent can read its own cost record and take a lighter path on the next step, and a person can read the same record and change a budget.
• External tools get checked. Tool definitions are pinned the first time they’re used, and if one changes later, the harness withholds it until someone looks. A quiet change to a tool is one of the easier ways for an agent to start doing something nobody approved.

None of these is dramatic on its own. Together they put the responsible choices inside the running system, where anyone can check them, and that’s the version of responsible AI I actually trust.

Questions worth asking before you deploy

If you’re evaluating an AI system or building one, these are the questions I’d put to it, and I’d put them to our own work first.

1. Which model does it run, and can that change without a rebuild?
2. What does a completed task cost in money and energy, and which of those numbers are measured versus estimated?
3. How many steps does a typical task take, and what’s being done to reduce them?
4. What can an action change, and who approved that boundary?
5. Where does the data go, and does anything leave your environment that doesn’t need to?
6. If something goes wrong on a Tuesday, can you reconstruct exactly what the agent saw and why it acted?

If a vendor can’t answer these plainly, I’d read their responsible AI principles as good intentions and keep asking for evidence.

Most of what makes AI responsible gets decided before a model writes a single word. We’d rather make those decisions on purpose and keep the record of why. If you want help working through them for your own systems, our AI operations and context advisory starts there.