What a compliance team asks about AI

When a company's accounts are audited, the auditor does not take the totals on trust. They ask for invoices, bank statements and approvals. The numbers matter less than the trail behind them.

AI is heading the same way. Compliance teams and auditors are starting to ask what an AI system did, where it ran and who was responsible. This piece sets out the questions they typically ask, the records that answer them, and how an AI provider can help.

This article is general information, not legal advice. What you must record depends on your sector, your location and the rules that apply. (For a starting map, see "AI and data rules: where to look by region".)

Why the questions are changing

For a long time, AI was treated like any other software. If the vendor had the usual security certificates, that was often enough.

That is changing. AI systems handle sensitive inputs, make or support decisions, and may run in places the buyer never sees. New AI rules and existing privacy rules both push organisations to show, not just say, how their AI is used.

The questions compliance teams ask

Most questions fall into six groups.

What was used? Which model, and which version, handled the work? Was it changed during the period under review?

Where did it run? In which country or region was the data processed? Was any of it processed somewhere else, even briefly? (We explain why storage and processing differ in Stored here, processed there.)

What data went in? Did inputs include personal or sensitive data? Was any of it kept afterwards, and for how long? Was it used to train anything?

Who could access it? Which people and systems at the provider could see inputs or outputs? Were any subcontractors involved?

What was promised, and was it delivered? What did the contract commit to on location, availability and handling? Is there evidence that each commitment was met?

What went wrong? Were there incidents, outages or errors? How were they found, reported and fixed? (See What happens when one site goes down?.)

The records that answer them

Good answers rest on records made at the time, not on recollection later. The records an auditor typically finds most useful include:

• Model and version records, showing what ran and when it changed.
• Placement records, showing where each piece of work was processed.
• Data handling records, covering retention, deletion and any use beyond the request.
• Access logs, showing who or what touched the data.
• Subprocessor lists, kept current, with locations.
• Commitment records, linking what was promised to what was delivered.
• Incident records, with dates, scope and follow-up.

Not every audit needs all of these. But a provider that can supply them saves a compliance team a great deal of effort.

How a provider can supply them

There are several ways a provider can help, and they work best together.

Documentation. Clear policies on data handling, retention and access, kept up to date and dated.

Independent reports. Third-party audits and certifications cover a provider's general controls. They are useful, but they describe the provider, not your specific workloads.

Per-workload records. Records tied to your own work show what happened to it in particular. These fill the gap that general reports leave. (We describe this idea in A receipt for AI work.)

Export. Records are most useful when they can be exported in a form your team or auditor can read and keep.

Questions to ask your provider

Before you need to answer an auditor, ask your provider:

1. Can you show which model and version handled our work over a given period?
2. Can you show where each workload was processed?
3. How are those location statements made, and who stands behind them?
4. What happens to our inputs and outputs after processing?
5. Which subcontractors can access our data, and where are they?
6. How will you tell us about incidents, and how quickly?
7. Can we export these records ourselves?

The third question deserves care. Some location statements are attested by the operator. Others may claim more. Ask exactly what is being stated and on what basis. (See What we will and won't claim here.)

What we are building

We think compliance should rest on records made as the work happens.

Starfield deploys standardized compute close to power, connectivity and demand, then connects it through one programmable network for AI inference. Workloads are placed by policy, on latency, data residency, model and load, and every workload can generate an auditable record of commitment, placement and delivery.

Those records are designed to give a compliance team the trail an auditor asks for. Location in them is attested, not cryptographically proven.

If your compliance team needs a clear record of where and how your AI work ran, use Request capacity below.