Most AI failures in enterprise are not model failures. They are governance failures.
When we walk into a stalled AI rollout, the chatbot usually works. The reason it has not shipped is that nobody can answer how it logs prompts, who can see the outputs, what happens when retrieval returns the wrong document, or how a regulator could audit a single answer six months later.
The fix is not a better model. It is the operating system around the model — and that is what we mean when we say 'audit-ready.'
The checklist below is what we apply on every engagement. It is not exhaustive, and most of it is unglamorous. But it is the difference between a demo that lights up the executive briefing and a system that survives external review.
1. Threat-model the boundary between user input and tool calls. The model is a renderer; tools are the actuators. Anything user-controllable that flows into a tool argument is an injection vector.
2. Schema-validate every structured output. If the model returns JSON, validate it against a strict schema before any downstream code touches it. Reject and retry on schema failures.
3. Cite sources. Every retrieved fact in the response should link back to the document, page and snippet it came from. Without this, you cannot defend an answer.
4. Log everything reversibly. Every prompt, every retrieval, every tool call, every output, with a correlation ID. Default retention: 13 months unless otherwise scoped.
5. Redact PII at the edge. Strip or tokenize PII before it ever touches the model API. Use a deterministic vault so you can map back when needed.
6. Run an eval harness on every change. Golden questions, golden answers, run nightly. A regression in retrieval quality should fail the build, not the user.
7. RBAC the data, not just the UI. Document-level permissions enforced at retrieval time. Two users asking the same question should get answers that respect their access.
8. Approval gates on consequential tool use. Sending an email or making a payment is not the same as searching a wiki. Force a human in the loop on the irreversible 5%.
9. Red-team before launch. Internal team plus external partner. We track findings against MITRE ATLAS.
10. Provide a kill switch. A single config flag that disables the copilot — wired to alerts on cost, latency or hallucination spikes.
11. Train the humans. Write a one-page user guide that says clearly what the copilot is good at, where it fails, and how to challenge an answer. Distribute it before launch.
Builds that ship with all eleven of these tend to clear security, legal and the audit committee within two weeks. Builds that miss three or more tend to stall for two quarters. The model is the easy part. The discipline around it is the work.