Audit harness
Every prompt, every piece of data a model touched, and every output it produced is recorded, so when a regulator or an internal auditor asks what happened, there's a record to hand them instead of a reconstruction.
- Policy harness
- Model routing harness
- Data transfer harness
- Guardrails harness
- Security harness
- Evaluation harness
- Observability harness
- Cost and token harness
- Reliability harness
- Audit harness
What it controls
The audit harness is the compliance-grade record: who asked what, which data was accessed to answer it, what the model returned, and when. It is built to be handed to someone outside the engineering team, an auditor, a regulator, a legal team, not just read by the people who built the system.
This is distinct from the observability harness's operational traces. Observability is for keeping the system running; audit is for proving, after the fact, that it ran the way it was supposed to.
Why it matters
Regulated industries don't get to say "the model probably did the right thing." They need to show what data reached which model, under whose authorization, and what came back. Without a dedicated record for that, the honest answer to an audit request is often that nobody is sure.
This is also where "the model is not the villain" becomes concrete. A model that was given data it shouldn't have seen didn't do anything wrong on its own; the harness that should have logged and limited that access is what was missing.
What good looks like
- Every prompt, data access and output recorded, not a sample
- Records usable by someone outside engineering, legal, compliance, a regulator
- Access and actions tied to an identity, not just a system log line
- A record that supports frameworks like HIPAA, SOC 2, GDPR, DPDP, FedRAMP and PCI DSS — aligned to them, not certified by this harness alone
- Audit data retained and retrievable on the timeline compliance actually requires
How it fits the other nine
Audit is downstream of almost everything else: it records what the policy harness allowed, what the guardrails harness blocked, what the security harness protected, and what the reliability harness did when something failed. It is the harness that turns the other nine from "we believe this is controlled" into "we can show this was controlled."
In practice
Real patterns on the Resources page that lean on this harness:
- Reversible storage: soft delete, versioning and retention
- Healthcare claims validation with a full audit trail
Frequently asked questions
Does this make us compliant with HIPAA or SOC 2?
No single harness makes an organization compliant. The audit harness aligns with frameworks like HIPAA, SOC 2, GDPR, DPDP, FedRAMP and PCI DSS by keeping the records those frameworks require; alignment is not the same as certification, which is a separate, owner-confirmed process.
How is this different from the observability harness?
Observability is the operational trace engineering uses to keep the system running. Audit is the compliance-grade record built for someone outside engineering, an auditor or regulator, to review.
What exactly gets logged?
Prompts, the data a model accessed to respond, and the output it produced, tied to an identity and a timestamp. Specific retention windows and formats depend on what a given deployment and its compliance requirements call for.
Questions about your AI rollout?
Talk to us about which harnesses fit your models and data.