AI audit trail: a receipt for AI work

You get a receipt for a coffee. You get one for a train ticket, a parcel and a tank of fuel. Spend a month's budget on AI compute, and you usually get a bill.

A bill tells you what you owe. A receipt tells you what you got. For most things we buy, the two arrive together. For AI work, they usually don't, and that gap is starting to matter.

What you get today

Most teams that buy AI capacity see three things: a usage dashboard, an invoice and a contract. The dashboard shows how many requests went through. The invoice shows the total. The contract describes what the provider promised.

What's missing is the link between them. Which requests ran where? On what kind of hardware? Did they run in the region you asked for? Were they delayed, retried or moved somewhere else when a site got busy? For most buyers, the honest answer is "we assume so". Ask for the story behind one specific request, and it often takes a support ticket and a few days to piece it together.

That works while AI is a side project. It works less well when AI handles customer conversations, medical notes, financial documents or anything an auditor might ask about later.

Why a receipt matters now

Three things have changed.

AI is moving into regulated work. When a bank, a hospital or a public body uses AI, someone eventually asks where the data went and what happened to it. "Our provider said so" is a weak answer in an audit.

Placement has become a choice. Requests can run in many places, and the choice affects cost, speed and which rules apply. Once there's a choice, there's a need to show which choice was made.

Finance teams want to match spend to work. A single monthly total makes it hard to see which product, team or customer drove the cost. A receipt per workload makes that possible.

What a useful receipt looks like: Commit, Place, Deliver

A good receipt for AI work doesn't need to be complicated. It needs to answer the questions a buyer, an auditor or a finance lead would actually ask. We call the three parts Commit, Place and Deliver, the same record described from the finance and compliance side in the companion article, AI compliance audit trail: trust is a record, not a promise.

Commit. What did the buyer ask for? Which model, under which policy, with which limits on location, cost or timing? This is the order, written down before the work starts.

Place. Where did the work actually run? Which region, which site, which class of hardware? If the request moved during processing, where did it move and why?

Deliver. What came back, and when? Did the work complete as committed? If something changed along the way, the record says so instead of hiding it.

Put together, those three parts let anyone compare what was promised with what happened. That comparison is the whole point of a receipt.

What it should not be

A receipt is not a marketing page or a promise. It's a record that can be checked after the fact.

It also shouldn't expose what it doesn't need to. A good record says that a request ran in a given place under a given policy. It doesn't need to store the prompt or the answer to do that. Buyers should be able to prove placement without handing over their data a second time.

And it should be readable by people who aren't engineers. If only the provider's own team can interpret a record, it isn't doing its job.

Questions to ask your provider

If you buy AI capacity today, these questions show quickly how much of a receipt you already have:

1. Can you show me where a specific request ran, after the fact?
2. Can you show that my requests stayed inside the region or country I asked for?
3. If a request was moved to another site, would I know?
4. Can I break down my spend by workload, team or customer?
5. Can my auditor read the record without your help?
6. Do you keep the content of my requests to produce this record?

If most answers start with "not exactly", you're buying on trust. That may be fine for some work. For anything that matters to your customers or your regulator, it's worth asking for more.

Why this is hard to retrofit

Receipts are easier to design in than to bolt on. A system built around a few large data centers has little reason to track placement closely, because there's only one or two places the work can go. A network that spreads work across many sites has to know where every request goes just to run at all.

That's why we think receipts and distributed capacity belong together, as we explain in Data center outage: what happens when one site goes down. The more places your AI can run, the more you need a record of where it did.

Where Starfield fits

We're building Starfield Fabric as a network of standardized compute close to power, connectivity and demand. It is designed to place workloads by policy, so a buyer's rules on latency, data residency, model and load decide where each request goes.

We're designing that network so every workload can generate an auditable record of commitment, placement and delivery. In plain terms: a receipt for AI work, written as the work happens, that a buyer can check later.

We think that record will become as normal as a delivery confirmation for a parcel. Right now it's rare. That's the part we're building with Starfield Fabric.

If you buy AI capacity and want records you can hand to an auditor, talk to us through the contact link on this page.