Everyone’s writing AI governance frameworks. Writing the framework is easier than proving it works.
EU AI Act obligations are already applying, with others arriving in stages.[1] The NIST AI RMF[2] is on every board slide. Your CEO has asked some version of “what’s our AI policy?” And across the industry, the response has been the same: a policy document, a committee, a RACI chart — and then, when someone asks “prove this model was tested before it went live,” silence.
My work starts with the next question: show me the evidence. I’m an IT risk and controls lead — SOX, audits, control testing, the whole alphabet — and I’m starting this newsletter because too much of the conversation stops at policy design, before control testing begins.
Governance without evidence is theater. This newsletter is about the evidence.
What AI, Audited is
Every week: one AI governance development that actually matters, the control behind it, and something you can use — a template, a checklist, a test step. Written from the operator’s seat, not the ivory tower. No jargon, no hype. Trust but verify.
Start here: the five AI controls I’d stand up first
If you got handed “AI governance” on Monday morning, here’s where I’d start — five controls that establish a practical baseline for what auditors, regulators, and your board will eventually ask for:
1. AI system inventory. You can’t govern what you can’t list. Every model, every vendor AI feature, every shadow deployment — in one register, with an owner. Evidence: the inventory itself, reviewed quarterly.
2. Data lineage and privacy. What data went into the model? Where did it come from, and was it allowed to be there? Personal data used without appropriate authorization or safeguards is a privacy risk wearing a lab coat. Evidence: data flow documentation, privacy review sign-off.
3. Access and change management. Who can touch the model, the prompts, the training pipeline — and what changed, when, approved by whom? The same IT general controls you run for financial systems apply here. Evidence: access reviews, change tickets.
4. Pre-deployment testing and approval. A gate before anything reaches production: what was tested, what the results were, who signed off. Evidence: test plans, results, approval records.
5. Ongoing monitoring. Models drift. Outputs get weird. Someone needs to be watching — with defined thresholds and an incident path. Evidence: monitoring reports, incident logs.
None of this is exotic. That’s the point. Start with familiar control discipline, then adapt it to AI-specific risks — model drift, prompt injection, training-data provenance — the places where AI genuinely breaks the old playbook.
One distinction worth making early, because this newsletter will hold it every week: documentation isn’t evidence that a control operated. An inventory proves a list exists; dated reconciliation, review notes, anWhat I'd do Monday morningWhat I'd do Monday morningd resolved exceptions provPick control #1. Send one email: "Please reply with every AI tool, model, or vendor feature your team uses — and for each: what you use it for, who owns it, what data goes in, and whether its outputs influence decisions."What I'd do Monday morninge it’s maintained. A monitoring report proves alerts fired; sign-off that someone reviewe
d and dispositioned them proves someone was watching.
Here’s what that looks like plotted — find your red cells first, because that’s where Monday morning starts:
Figure 1. AI risk heat map. Risk = likelihood × impact, following the risk assessment
What I'd do Monday morning
Pick control #1. Send one email: "Please reply with every AI tool, model, or vendor feature your team uses — and for each: what you use it for, who owns it, what data goes in, and whether its outputs influence decisions."
Then reconcile the replies against procurement records and your approved-tools list. The gap between what people report and what's actually running is shadow AI — and it's where your real inventory lives. I mapped this risk in my master's research with the DART framework: six dimensions, from unintentional data disclosure to the trust–dependence paradox, with persistent gaps in employee awareness and organizational controls.[4]
Your inventory starter
Copy this into a spreadsheet. One row per tool. Fill in what you know; the blanks are your first exceptions.
Tool / vendor: Acme Chatbot (example)
Use case: Customer support drafts
Owner: J. Smith
Data involved: Customer chat logs
Outputs influence decisions? Yes — agent reviews before sending
Notes: No privacy review on file
Next week
I'll take a real-world AI failure apart, control by control, and show exactly where the evidence broke down.
Sources
[1] European Commission, "Regulatory framework on AI" — https://digital-strategy.ec.europa.eu/en/policies/regulatory-framework-ai
[2] NIST, "AI Risk Management Framework" — https://www.nist.gov/itl/ai-risk-management-framework
[3] ISO/IEC 23894:2023, Information technology — Artificial intelligence — Guidance on risk management (ISO/IEC JTC 1/SC 42).
[4] Sebastian, G., "Digital Shadow AI Risk Theoretical Framework (DART): A Framework for Managing Data Disclosure and Privacy Risks of AI Tools at Work," Master's Thesis (2026) — https://research.google/pubs/digital-shadow-ai-risk-theoretical-framework-dart-a-framework-for-managing-data-disclosure-and-privacy-risks-of-ai-tools-at-work-2/
AI, Audited is a weekly newsletter on AI governance and accountability — for the people who have to prove it. If this was useful, forward it to the person in your org who just got handed "AI governance."