Audit Trail
Answer "where did this go" with a record.
Every request from every product writes one line to the same trail: what ran, when, in which region, and under which policy. It is metadata only, never prompt content, and it is retained for as long as your own policy says. The question your data protection officer asks has an answer you can export.
what ran · where · under which policy
Four lines from one afternoon. The refusal is a record too.
Nobody doubts that it happened. They doubt that you can show it.
An auditor does not ask whether your AI calls stayed in the EU. They ask you to demonstrate it, for a date range, across every application and every person who used one. Assembled from provider dashboards and application logs, that answer takes a week and still has gaps: the requests that were refused, the ones a service quietly skipped, the ones that ran from a tool nobody registered.
How it works
Written, retained, exported.
There is nothing to switch on. Every service on the platform writes to the same trail as it runs, which is why the record has no gaps to explain.
- 01WrittenOne line per requestEvery product and every service writes as it runs: which model, which region, which services applied, which policy allowed it, and who or what asked. A refusal is a line like any other.
- 02RetainedKept on your policyYou set the retention window and the trail holds to it. Longer windows come with the larger plans, and the window is the same for every product on the account.
- 03ExportedHanded to the reviewerExport a date range and give a reviewer the record rather than a screenshot. The same rows feed the Compliance Center's Art. 30 and EU AI Act reports.
The last line is the one that matters: content is not in here.
Why it is different
A log you can hand over.
Most systems can tell you what succeeded. An audit trail has to tell you what was refused, what was skipped and what left the region, and it has to be safe to show someone outside your team.
Refusals are recorded
A blocked non-EU route, a firewall gate, a refused model. The events where nothing happened are the ones an auditor came to see.
One trail, three products
Chat, Code and the API write to the same record, so there is one place to look rather than three exports to reconcile.
Safe to share
Metadata only means the record can leave your team without taking your customers' data with it.
Feeds the reports
The Compliance Center builds Art. 30 and EU AI Act records from these rows, so the documentation matches what actually ran.
The record
What it holds, and what it never will.
Metadata, never prompts
The trail records what ran, where and under which policy. It never stores what was said, so the record itself is not another copy of your customers' data.
Written by the platform
Services write as they run, not from your application code, so the trail cannot be skipped, forgotten or dropped in a hotfix.
Retained on your policy
You set the window. Nothing is kept beyond it, and nothing is quietly kept longer because it was interesting.
FAQ
Questions people ask about the audit trail.
- Is prompt content stored?
- No. The trail is metadata only: what ran, when, in which region and under which policy. It never stores what was said.
- How long is it kept?
- For the retention window your plan sets and your policy chooses. Nothing is kept beyond it.
- Does it record requests that failed?
- Yes, and those are usually the important ones. A refused non-EU route, a refused model and a firewall gate each write a line.
- Do the three products share one trail?
- Yes. Chat, Code and the API write to the same record, so a date range covers all of them at once.
- Can we export it?
- Yes. Export a date range and hand a reviewer the record. The same rows feed the Compliance Center's reports.
Start here
Every call on the record, from the first one.
Create a key and the trail is already writing. There is nothing to switch on and nothing to instrument.