Why most production AI fails its first audit — and how to build so it doesn't
The gap between a working AI demo and a system that survives an examiner's questions is not model quality. It's five specific engineering decisions most teams skip.
Every regulated firm we talk to has the same story. Someone on the team built an impressive AI pilot — a voice agent, a document summarizer, a decision assistant. Leadership loved the demo. Then the compliance officer asked three questions:
- Can you show me exactly why it said that?
- What stops it from saying something it shouldn't?
- Who reviewed the transcript where it got it wrong?
And the project stalled, sometimes for a year.
The problem is almost never the model. Modern models are good enough for most operational workflows in healthcare, lending, and advisory work. The problem is that the system around the model was never designed to be examined — and in a regulated business, examination is not an edge case. It is the operating environment.
The five decisions that determine auditability
After shipping AI systems in front of patients, lending workflows, and RIA operations, we've found the audit outcome is mostly decided by five engineering choices made in the first two weeks of the build.
1. Log decisions, not just conversations
A transcript tells you what the AI said. An auditor wants to know what the AI decided — which policy it applied, which data it consulted, which threshold it crossed. In Sentinel, every action an agent proposes is evaluated against explicit rules before execution, and the verdict is bound to the exact rule version with a SHA-256 hash. When an examiner asks "why was this loan action allowed," the answer is a lookup, not an archaeology project.
2. Put the gate inline, not after the fact
Most teams bolt on review after the AI acts — a weekly sample of transcripts, a dashboard someone checks. That's monitoring, not control. The difference matters enormously to a regulator: an inline gate can prevent a prohibited action; a dashboard can only report it. If the AI touches money, PHI, or a credit decision, the screen has to happen before execution.
3. Design the human handoff as a first-class feature
Every system we operate has an explicit escalation path: the voice agent warm-transfers with full context, the decision gate routes edge cases to a named reviewer. Auditors don't expect AI to be perfect. They expect the failure mode to be a human, not a shrug.
4. Keep PHI and PII out of the model's memory
HIPAA and fair-lending compliance both get dramatically simpler when you can state, in writing, that no protected data is used for training and that identifying fields are redacted before the model sees them. This is an architecture decision, not a policy document — it has to be true in the data flow, not just the handbook.
5. Version everything a regulator might ask about
Prompts, rules, model versions, escalation thresholds. When behavior changes, you need to answer "what changed, when, and who approved it." Git solved this problem twenty years ago; most AI deployments just don't bother to use it for the parts that matter.
The uncomfortable implication
None of this is exotic. But all of it has to be built in, not added later — retrofitting an audit trail onto a system that wasn't designed for one usually costs more than the original build.
That's the real reason demos die in compliance review. It's not that the compliance officer is obstructionist. It's that the demo was built to impress, and the questions were always going to be about control.
If you're planning an AI build in a regulated workflow, start with the five decisions above — or talk to someone who has already made them in production. It's the difference between a pilot that stalls and a system that survives its first examination.