Compliance for AI systems is the practice of making AI behavior, data handling, access, monitoring, and documentation meet legal, regulatory, contractual, and organizational requirements. What applies varies by industry, geography, and use case, and deciding which regimes are in scope is a legal determination rather than an engineering one.
From an engineering perspective, compliance is an evidence problem. Whatever the specific requirement, you will be asked to show something rather than assert it: what the system did on a given date, what you tested before shipping, who reviewed the cases needing review, who had access to the data, and what changed since anyone last looked. Systems that struggle in a review are rarely behaving badly. They usually cannot produce a record of behaving well.
This is why compliance cannot be added as copy in a prompt. Instructing a model to follow a regulation produces no artifact and enforces nothing. And no tool, platform, or vendor makes a system compliant. Software can produce and retain evidence. The obligation stays with the team operating the system.
Build better agents with Arize
Trace, evaluate, and learn. Build agents that work with Arize AX and start tracing your runs today.
Prefer open source? Try Arize Phoenix for self-hosted, open source agent observability.
Key takeaways
- Compliance for AI is mostly an evidence problem. If it happened and you cannot show it happened, a review treats it as if it did not.
- Six artifacts carry most of the weight: audit trails, documented evaluation, human oversight records, access control, retention rules, and change history.
- Nothing makes a system compliant. Tools produce evidence; the obligation stays with the operator.
- Nondeterminism is the hard part. You cannot promise a model never does something, so the defensible position is measured rates, real controls, and honest documentation.
- Your trace store inherits the sensitivity of what it records, which puts observability inside the compliance boundary rather than beside it.
What a review actually asks engineering for
Requirements differ across regimes, and the underlying questions are consistent. Expect to produce:
- An audit trail. What went in, what came out, what the system decided, when, for which user, and which model and prompt version were live. For agents, every tool call and data access, not only the final response.
- Evidence of evaluation. Not that you have evals, but the results: what was tested, on which set, with which scorer, on what date, and the outcome before release.
- A record of human oversight. Where a person is meant to be in the loop, evidence that they were: reviewed cases, reviewer identity, decision, timestamp.
- Access control and data minimization. Who can see production inputs and outputs, and whether sensitive fields are stored only where needed.
- Retention and deletion. Documented periods, and a working mechanism to delete a subject’s data everywhere it landed, traces included.
- Change history. Model versions, prompt versions, tool definitions, and guardrail configuration, with dates and approvals.
- An incident record. What went wrong, when you learned about it, what you did, what changed afterward.
Each is an engineering artifact with an owner and a storage location, or it is not real.
The regimes engineers hear about
Teams building AI products most often encounter the EU AI Act, GDPR and comparable privacy laws, sector rules such as HIPAA in United States healthcare, and contractual obligations from enterprise customers, which arrive first and are frequently the strictest thing you deal with.
Do not derive your obligations from a blog post, including this one. What generalizes is the engineering posture: the artifacts above cover most of what these regimes eventually ask for, and building them early beats reconstructing them under deadline. For the EU AI Act there is a useful overview of what engineering teams should be monitoring to keep that evidence available. Read it as orientation, then have counsel determine what applies to you.
Documentation is the piece engineers underrate. Explaining what the system does, what it was tested against, and what its limits are is both a review requirement and the discipline that makes transparency a design property rather than a report written afterward.
Why AI compliance is harder than it looks
Nondeterminism. Traditional controls assume the same input produces the same behavior. Models do not, so you cannot honestly promise a behavior never occurs. What you can offer is a measured rate on a documented test set, enforcement in code where the consequence is serious, and monitoring that catches the exception.
Audit trails contain the regulated data. The record proving what happened holds the inputs and outputs, meaning personal or sensitive information. Your trace store now falls under the same access controls, retention limits, and deletion obligations as your primary database, and a deletion request that skips it is not complete. Every system touching that data is in scope, which is why vendors handling health information hold certifications covering how that information is stored and secured. Model providers, vector stores, and orchestration services sit inside the same boundary. Confirm each one’s terms and retention behavior. That is a procurement question, and it does not transfer your own obligations.
Retention pulls both ways. One requirement says keep records to prove what happened. Another says do not keep personal data longer than necessary. The usual approach is tiered: full traces for a short window, then redaction or aggregation, with periods written down and actually enforced.
Evidence rots. An evaluation from four model versions ago documents a system you no longer run. Compliance artifacts need a refresh cadence tied to change, or they become misleading rather than merely stale.
FAQ
What does AI compliance mean for an engineering team day to day?
Mostly instrumentation and record keeping. Trace inputs, outputs, tool calls, and versions. Store evaluation results as artifacts rather than console output. Log review decisions where a human is in the loop. Enforce access controls and retention on the trace store the way you do on production data. Keep a change history for models, prompts, and tools. None of it is exotic engineering, and all of it is cheaper to build in than to retrofit.
What do we need to log for an AI audit trail?
At minimum: the request and response, the model and prompt version in effect, the timestamp, the user’s identity or pseudonymous identifier, and the outcome. For agents, add every tool call with its arguments and result, every data source read, and every point where the system routed or escalated. Store it with access controls and a retention period, because the log itself is now sensitive.
Does the EU AI Act apply to my product?
That depends on what the system does, where it is used, and your role in the supply chain, and it is a determination for legal counsel rather than an engineering team. What engineering can do without waiting is build the evidence: documented evaluations, production monitoring, records of human review, and a change history. None of that is wasted if the answer comes back narrower than expected.
Can a vendor or platform make us compliant?
No. A vendor can help you produce and retain evidence, and its own certifications may reduce the diligence you owe on that part of the stack. Compliance is a property of your system, your data handling, and your documentation, and the accountability stays with you. Treat any claim to the contrary as a reason for more scrutiny.
How long should we retain AI traces and evaluation records?
There is no universal number, and it should be a written decision rather than a default. Typical practice separates the two: detailed traces with sensitive content on a shorter window, aggregated metrics and evaluation results for longer, since those carry less personal data and are what a review usually wants. Set the periods with legal input, enforce them with a job, and confirm deletion reaches every store.
