Why AI Systems Are Hard to Audit – AI doesn’t have controls, it has guardrails — and you can’t audit a guardrail
AI Teams Think in Guardrails. Auditors Think in Controls. That Gap Is Where Programs Fail.
Steven Ross made an observation in the ISACA Journal earlier this year that I’ve been chewing on since, because it explains a failure pattern I keep encountering and had never named properly. Writing about adapting security language to AI, he put it plainly: AI does not have controls, it has guardrails.
That reads like a semantic quibble. It isn’t. It’s the reason a well-engineered AI system can walk into a Stage 2 audit and produce nothing the auditor can use.
My last post argued that controls are almost never why organisations fail an ISO 42001 audit — evidence is. This post is about the specific version of that problem that AI teams create without realising it: a guardrail is not a control, and the difference is precisely that a control can be evidenced.
Ross’s broader framing is worth stating up front, because it sets the right expectation. AI security sits inside information security rather than replacing it — the same premises apply, there are just more and different things to worry about. Nobody needs a parallel security universe. What they need is a translation layer, and most organisations don’t have one.
What actually separates the two
| Control | Guardrail | |
|---|---|---|
| Behaviour | Deterministic — same input, same result | Probabilistic — same input, possibly different result |
| Outcome | Binary: it operated or it didn’t | Graded: it usually holds |
| Failure | An event, on a date | A rate, over a population |
| Test | Reproducible | Statistical |
| Evidence | A dated record of an instance | A benchmark, valid until the model changes |
| Ownership | A named person | Frequently no one |
The critical row is failure. A control fails as an event — the approval wasn’t obtained on 14 March. A guardrail fails as a distribution — the content filter catches 97.3% of attempts, and the other 2.7% happened somewhere you don’t know about. An auditor asking “show me a specific instance” gets an answer in the first case and a statistic in the second.
Which leads to the sentence I’d build an entire AI audit methodology around:
You cannot audit a guardrail. You can only audit the control that governs the guardrail.
The model is not the auditable object. The envelope around it is.
Turning a guardrail into something evidenceable
Five moves. None require changing the model, which is the point — the deterministic layer goes around the probabilistic one.
1. Wrap it in a deterministic gate. If the consequential decision runs through a policy service the model doesn’t control — validating scope, privilege, and approval before execution — you now have a binary event to log. This is the propose/validate/execute separation from my earlier agent security post, and it’s the single highest-value structural change available. A model output that authorises a privileged action on its own is unauditable by construction.
2. Define the threshold, then record the reading. A guardrail becomes measurable the moment you commit to a number: what detection rate is acceptable, what drift triggers action, what happens when the threshold is breached. ISO 42001 Clause 6.2 requires measurable AI objectives and Clause 9.1 requires you to actually monitor and evaluate them. An unmeasured guardrail satisfies neither. “The filter works well” is not an objective; “false-negative rate below X, measured monthly, breach escalates to the AI system owner” is.
3. Version the guardrail as a document. System prompts, filter configurations, refusal policies, retrieval scopes, tool allowlists — these are control documentation, and they should be versioned, change-controlled, and dated like any other policy. If nobody can say which prompt version was live on the day of an incident, the guardrail has no audit history at all. And record the policy version in the decision log, so an artifact can be tied back to the rules in force when it was produced.
4. Test adversarially and retain the results. The evidence that a guardrail works is a test suite with expected denials — prompt injection, tool misuse, privilege escalation, memory poisoning, approval bypass — version-controlled, re-run on any material change to prompts, tools, retrieval, policy, or model provider. This maps to A.6.2.4 verification and validation, and it’s the only form of evidence that survives the “how do you know it still works?” question. Statistical assurance decays the moment the model version changes.
5. Log the decision, not just the outcome. The four questions an AI action log should answer: who authorised this, what context did the system have, what did it decide, and was that consistent with policy. A.6.2.8 requires event logs sufficient for investigation and accountability. Outputs alone don’t meet that bar.
The pattern across all five: you make a probabilistic system auditable by surrounding it with deterministic decisions. Where the model is uncertain, the governance must not be.
Six places the vocabulary mismatch actually bites
Ross’s articles work through several concepts where the same word means different things to AI practitioners and security professionals. These are the ones that cause real audit trouble.
Robustness. To a security professional this usually means resilience or recoverability. In AI usage — drawing on the trustworthiness vocabulary that NIST’s AI RMF cites — it means maintaining performance across varied circumstances, including unexpected inputs and hostile ones. Two different requirements, one word. If your risk register says “robustness: implemented,” find out which definition the author meant. Usually only one of them has been addressed.
Safety versus security. Safety is about not causing harm; security is about withstanding attack. AI joins them, because adversarial manipulation is a route to harm. The practical consequence is that adversarial testing is a safety obligation as much as a security one, and it needs metrics and monitoring to detect attacks in progress — not just a pre-deployment test.
Explainability. Ross frames a decision without an explanation as a whim — and in AI terms, a hallucination that can be entirely convincing while being wrong. For auditors this is more than an ethics concern. He makes a point I hadn’t seen articulated elsewhere and think is genuinely important: a security breach, even a minor unauthorised revision to a model, can render the system unusable because it can no longer be explained. Integrity failure and explainability failure are the same failure. If someone modified your model and you can’t detect it, every output afterwards is unattributable — which means every decision it informed is undefendable.
Privacy. Models don’t distinguish personal data from anything else unless someone labels it that way. The classification burden sits upstream in data preparation (A.7.4, A.7.6), not in the model. And re-identification through combination means the label has to consider combinations, not just fields. Which is also why deletion rights reaching agent memory and vector embeddings is such a hard engineering problem.
Availability. More on this below — it’s the leg of the CIA triad that AI governance has most neglected.
Controls versus guardrails. The one this post is about. When an AI team says “we have guardrails for that,” the correct follow-up is: what is the threshold, who owns it, when was it last tested, and what happens when it’s breached? If those have answers, you have a control. If they don’t, you have a hope.
Segregation of duties is missing, and it’s structural
This is the finding I’d expect to write in most AI-developing organisations, and Ross identifies the root cause precisely: the people who build models have effectively complete access to them, and concepts like separation of duties and dual control have barely entered AI development practice as a discipline.
Consider what that means concretely. A data scientist can typically alter training data, modify the model, change the evaluation criteria, and interpret the results — the full chain from input to verdict, with no independent checkpoint. In any other regulated system we’d call that an unacceptable concentration of authority. The person who initiates a payment doesn’t approve it. The administrator doesn’t edit the logs recording their own activity.
And this connects directly to the agentic prohibited patterns I’ve written about before, because it’s the same principle appearing at a different layer:
- An agent should not approve its own high-impact action
- An agent should not control its own security monitoring
- A model owner should not be the sole evaluator of that model’s fitness
Three statements of one rule. ISO 42001 Clause 5.3 requires distinct roles — AIMS owner, AI risk owner, AI system owner, data governance lead, internal auditor, incident manager — and Clause 9.2 requires audit independence. Those aren’t bureaucratic overhead. They’re the mechanism that stops the chain from collapsing into one person.
Ross also names the practical obstacle honestly: with AI talent scarce, it’s hard enough to find people to do the work, let alone to oversee it. Fair. But the resolution is to design the separation into the process — independent evaluation datasets, an approval gate the builder can’t self-serve, review by a different function — rather than to accept concentration because staffing is tight. Small organisations solve this with external reviewers all the time.
Availability: the leg nobody assessed
Ross’s most recent piece makes a case I think AI governance has genuinely underweighted, and it reframes something I’d previously treated as a resilience concern rather than an assurance one.
Availability for AI isn’t only recoverability. It’s reliance — AI is being embedded into finance, HR, and customer systems fast enough that people depend on it without knowing they do — and reliability, the plain observation that a system nobody can depend on isn’t available in any meaningful sense.
Then the part with real audit consequences. AI systems are dynamic and nondeterministic. Model behaviour shifts; the same question can produce different answers. So a recovered model cannot be demonstrated to be identical to the one that went down. Recovery of an IT system restores a known state. Recovery of an AI system restores something that resembles the previous state to an unverified degree.
Ask yourself the auditor’s version of that: after you restore, how do you prove the model is the one you backed up? Most organisations have no answer, because the question has never been posed. And the mechanics compound it — algorithms, unstructured data, training data, and test data need backing up together and recovering as a set, onto scarce specialised hardware, at a data volume that can make comprehensive backup impractical.
The governance implications:
- Availability belongs in the AISIA, not just the DR plan. Impact assessment should ask what happens to affected individuals when the system is unavailable, and how you’d know the restored system is equivalent.
- Model integrity evidence is availability evidence. Model registry, version pinning, checksums or signing, checkpoint lineage, and recorded evaluation results at restore. Without those, “we recovered it” is an assertion.
- Test the restore and evaluate the restored model, not just the infrastructure. A successful restore that produces a differently-behaving model is a failed restore.
- Ross’s architectural options — checkpoint-based training to shorten retraining, warm and hot standby replicas, multiregional deployment — are worth knowing, though he’s candid that organisations building their own AI applications may not manage the scale that AI vendors do.
His recommendation is one I’d endorse without qualification: don’t place strategic reliance on an AI system whose availability can’t be assured to a level your users can tolerate. And expand DR programmes into availability management, which is a broader remit than restoring service.
So what does an AI audit actually test?
Pulling it together — the object of assessment isn’t the model. It’s the envelope. Six things you can genuinely test:
- The decision boundary. Which actions require deterministic authorisation, and does the gate hold when the model is adversarial?
- The thresholds. Are guardrail parameters defined numerically, measured, and escalated on breach?
- The versioning. Prompts, filters, tool policies, model versions — change-controlled and traceable to a date?
- The test evidence. Adversarial suite with expected denials, re-run on material change, results retained.
- The separation. Can any single person build, evaluate, approve, and deploy without an independent checkpoint?
- The restoration. Can you demonstrate the recovered model is equivalent to the one you lost?
Rate each honestly — 0 not implemented, 1 ad hoc, 2 partial, 3 defined, 4 implemented and evidenced, 5 measured and continuously improved. Most AI teams score well on capability and poorly on levels 4 and 5, which is exactly the gap between an impressive system and a certifiable one.
From the practitioner’s chair
Leading VDR organization through ISO 42001 Stage 2 certification on the first attempt and then serving as internal auditor taught me that the hard conversations are almost never about whether something works. They’re about whether you can show that it worked, on a date, under a version, owned by a name.
The guardrail/control distinction is the AI-specific form of that conversation, and it’s worth handling with some humility in both directions. AI teams aren’t being careless when they build guardrails — probabilistic mitigation is the appropriate tool for a probabilistic system, and a security professional who insists everything be deterministic will simply be ignored. Equally, an AI team that treats “we tuned the prompt” as a completed control will fail an audit and, more importantly, won’t be able to reconstruct what happened after an incident.
The productive framing is not guardrails are inadequate. It’s guardrails need a deterministic shell to be governable — and building that shell is a design task, not a documentation task. It’s much cheaper before deployment than after.
What to do in the next 90 days
- Inventory your guardrails as if they were controls. For each, write down: threshold, owner, last test date, breach response. The blanks are your gap list.
- Identify every consequential action authorised by model output alone, and put a deterministic gate in front of it.
- Put prompts and filter configs under change control, and record the version in the decision log.
- Stand up an adversarial test suite with expected denials, and wire it to the release process.
- Check for concentration of authority in model development — can one person train, evaluate, approve, and ship?
- Ask the restore question. After recovery, how would you prove the model is the same one? If nobody knows, that’s your most interesting finding.
The vocabulary gap isn’t going to close on its own, and it doesn’t need to. What it needs is somebody in the room who speaks both languages well enough to turn a guardrail into evidence.
Work with DISC InfoSec
DISC InfoSec helps B2B SaaS and financial services organisations make AI systems auditable, not just defensible — AIMS scoping, AI and agent inventories, AISIA methodology, guardrail-to-control translation, adversarial test design, evidence architecture, and internal audit against ISO/IEC 42001, NIST AI RMF, and EU AI Act Articles 14 and 26.
I led ShareVault through ISO 42001 Stage 2 certification on the first audit attempt as the internal practitioner, served as their internal auditor, and authored their MCP Governance Standard.
Readiness path: free 15–20 minute readiness call → ISO 42001 gap assessment or ISO 27001 gap assessment → 7–10 day Quick-Start → full implementation and certification support.
auditing AI systems, ISO 42001 audit, AI segregation of duties, AI availability, explainability, TEVV
DiscInfoSec — Principal Consultant, DISC InfoSec (Deura Information Security Consulting LLC), Petaluma, CA CISSP, CISM | ISO/IEC 42001 & ISO/IEC 27001 Lead Implementer | PECB Authorized Training Partner
📅 calendly.com/hd-deurainfosec 📧 info@deurainfosec.com 📞 (707) 998-5164 🌐 deurainfosec.com
Sources and references
- Steven Ross, “AI Security in Context,” ISACA Journal vol. 2, 2026; “AI Security in Context: Part 2,” vol. 3, 2026; “Artificial Intelligence Availability Concerns,” vol. 5, 2026 — the guardrails framing, the segregation of duties observation, and the availability argument all originate with these columns and are worth reading in full
- ISO/IEC 42001:2023 — Clauses 5.3, 6.2, 9.1, 9.2; A.6.2.4, A.6.2.8, A.7.4, A.7.6
- ISO/IEC TS 5723:2022 (trustworthiness vocabulary), cited via NIST AI RMF 1.0
- NIST AI RMF 1.0 (NIST AI 100-1); MITRE ATLAS
- OWASP Agentic Security Initiative; OWASP AI Agent Security Cheat Sheet
Download the AI Governance & Cybersecurity pdf file
MachineLearning & Artificial Intelligence
AI Vulnerability Scorecard: Discover Your AI Attack Surface Before Attackers Do
Your Shadow AI Problem Has a Name-And Now It Has a Score
Most AI Security Tools Won’t Pass an Audit. Here’s a 15-Minute Way to Find Out.
InfoSec services | InfoSec books | Follow our blog | DISC llc is listed on The vCISO Directory | ISO 27k Chat bot | Comprehensive vCISO Services | ISMS Services | AIMS Services | Security Risk Assessment Services | Mergers and Acquisition Securit
DISC InfoSec blog | DISC InfoSec Site
- A signed two-page policy beats a fifty-page draft. Every time…
- We have guardrails for that is not a control – Here’s the difference
- Point-in-time remediation is dead against a persistent adversary
- Your Security Stack Isn’t Obsolete. Your Operating Model Is
- Thirty years of security assumed the attacker was unauthorized – Your agent isn’t
