AI Governance: The Exception Log Boards Should Be Asking For
Return to Part 0: Table of ContentsPrevious Article: Part 32, Zero Trust for AI Agents
Ninety-eight per cent of the organisations EY surveyed for its first AI Risk and Governance Survey report having a formal AI governance policy. Forty-seven per cent report that they have, at least once, not applied it: an AI system went into production under deadline pressure, and the process the policy sets out was set aside. EY published the finding on its own newsroom on 15 September 2026. CIO Dive's independent coverage followed the next day, carrying a quotation from EY's Richard Jackson, Americas Assurance Chief Technology Officer: "Organizations are applying yesterday's governance rules to today's interactions with AI." Both figures describe the same 202 senior AI decision makers, board members and chief executives, at publicly traded United States companies with at least a billion US dollars in annual revenue.
Ninety-eight and forty-seven are not in tension with each other. They measure two different things. A policy attestation to a board answers a coverage question: does the document exist. Nobody in EY's survey was asked whether the policy was followed the last time following it was expensive, and that is the application question. It decides whether governance means anything under pressure, and it is very rarely the one on the slide.
This book closed its previous chapter on an enterprise architect at a New Zealand insurer who could not answer a narrower version of the same question: what is your egress side number, and who owns it. That chapter, Zero Trust for AI Agents, was about a technical control, prompt injection detection, that had improved for three straight quarters while nobody measured the exit side of the same agent's access. This chapter is the same failure one level up, at the level of governance itself. Ninety-eight per cent is the ingress number: the policy exists, and everyone can see that it exists. Nobody is publishing the egress number, how often the policy actually held when holding it cost something, because almost nobody keeps the record that would let them.
The practitioner fix is not complicated to state. Stop asking a governance owner for the policy. Start asking for the exception log: the record of every time the organisation's own AI process was set aside, with whose sign off and for what reason. A policy attestation proves a document exists. An exception log is the artefact that can actually answer whether it was followed.
Is that a genuinely new practice, or a relabelling of a control that already exists somewhere in the frameworks a New Zealand architect is already measured against? I checked three: the United States' National Institute of Standards and Technology AI Risk Management Framework, the certifiable international standard ISO/IEC 42001, and New Zealand's own Information Security Manual. The answer is a genuine three way split, and none of the three gives an unqualified yes.
NIST comes closest, almost by accident. Its AI RMF Playbook, the voluntary companion resource offering suggested actions against the framework's own subcategories, states under Measure 2.8 that accountable parties should "track, document, and measure organizational accountability regarding AI systems via policy exceptions and escalations, and document 'go' and 'no/go' decisions." That is close to word for word the artefact this chapter is arguing for. The qualifier has to travel with it every time the finding is used: the AI RMF carries no US federal mandate, and the Playbook is explicitly non-normative. NIST has written the idea down. Writing an idea down and requiring it are different claims, and no organisation is out of compliance with anything, anywhere, for lacking an exception log.
ISO/IEC 42001 sits at the other end of the enforceability spectrum. It is a certifiable management system standard, and Clause 10.2 genuinely requires organisations to log nonconformities and the corrective action taken against them, with documented evidence retained. A nonconformity, on the standard's own logic, is a failure discovered after the fact, through an audit, an incident or a complaint. A sanctioned exception, granted in advance because a deployment was urgent, is a different event, and nothing in the material available on Clause 10.2 suggests it was written with that second case in mind. Chapter 21 of this book, Continuous Conformity, made the underlying point about ISO 42001 in a different setting: a certificate is a claim about the management system, not a guarantee about any specific product's behaviour. This is the same gap, one level more specific. A certified organisation can log every discovered failure correctly and still hold no record of the exceptions it granted itself on the way to a deadline.
New Zealand's own Information Security Manual, maintained by the National Cyber Security Centre, has the closest structural match of the three, and it sits in an entirely different part of security practice. The manual's general provisions describe a formal Exception and Waiver regime. An Exception is the Accreditation Authority's documented dispensation from a specific requirement, bounded to the term of the accreditation or a shorter period the Authority sets. A Waiver is a shorter term arrangement pending full compliance, with accreditation withheld until its conditions are met. Both require a named authority and a stated rationale in advance of the deviation being accepted, closer to the shape of a sanctioned exception than either AI specific framework above gets. What it is not, on the evidence available while researching this chapter, is AI specific. Nothing found here suggests the manual's Exception and Waiver mechanism has ever been pointed at an AI or agentic system governance decision, in New Zealand or anywhere else, despite New Zealand already holding the architecture to do it in a different corner of its own practice.
Read the three together and the honest position is not that "ask for the exception log" restates an existing control under a new name. NIST has written down something close to it, voluntarily, with no mandate behind the words. ISO 42001 requires something adjacent, but only once the failure has already happened. New Zealand comes closest of the three in shape, a structure built for an entirely different purpose and never yet pointed at this one. No examined framework mandates a live, AI specific exception log. That is not evidence that organisations are failing an existing rule. It is evidence that the rule does not yet exist in the form that would have caught what EY measured, and a chief risk officer who wants to close the gap is building ahead of anything a framework will yet tell her she has to.
Only three frameworks were checked for this chapter: NIST's AI RMF and its Playbook, ISO/IEC 42001, and New Zealand's Information Security Manual. COBIT, the risk management provisions inside the EU AI Act, and sector specific financial or health AI governance standards were not checked, and a reader working under one of those should not assume the same gap holds without looking. An absence found in three places is not an absence found everywhere.
A second, independently commissioned instrument reaches the same shape without citing the first. OneTrust's 2026 AI-Ready Governance Report, fielded across eight countries by Sapio Research and published 14 September 2026, found 86 per cent of its 1,200 respondents had experienced at least one AI related incident in the past year: sensitive data or intellectual property exposure, unapproved employee use, misinformation or data loss among them. The most common organisational response was more employee training, at 49 per cent. The least common, at 27 per cent, was pausing or slowing AI deployment. EY and OneTrust were commissioned by different companies, fielded by different research houses, surveying overlapping but distinct populations, and neither cites the other in anything available while this chapter was researched. Two instruments landing on the same acknowledge-the-risk, do-not-slow-down pattern independently is worth more than either finding alone.
None of this means governance is getting worse. Stanford's 2026 AI Index recorded the share of businesses with no responsible AI policy at all falling sharply, from 24 per cent to 11 per cent. Read alongside EY's and OneTrust's numbers, the picture resolves rather than contradicts: coverage is improving, and application, once a policy exists, is the separate and still largely unmeasured question sitting underneath it.
Picture the version of this a New Zealand chief risk officer actually lives. She is preparing the board's quarterly technology risk pack. The AI governance slide has looked the same for three quarters: a tick beside the AI Governance Policy, a tick beside the Agentic AI Addendum, each one citing the framework it was modelled on. A newly appointed independent director, a career auditor, asks a question that has never come up before: how many times this quarter did someone get an exception to that policy, and who signed off on it. She does not have the number. The policy is current and was approved by the board over a year ago. What she does not have is any single place where a project team's request to skip the normal model approval gate, for an urgent client facing deployment, would have been recorded and reasoned through, rather than agreed in a chat thread and a verbal nod under deadline pressure. She knows it has happened; she has heard about it informally twice this year. Nobody had ever asked her to produce a record of it, so she had never built one. The director's question was not hostile. It was the first time anyone on that board had asked for the artefact that actually answers whether governance is working, rather than the artefact that proves it was written down.
New Zealand already has, in a different domain, an architecture that does roughly what "ask for the exception log" is asking for: a named authority, a documented rationale, a bounded term, agreed in advance of the deviation rather than discovered after it. Nobody appears to have pointed it at AI governance yet. That is a real gap, and it is also a head start. The mechanism does not need to be invented, only extended.
An exception log does not need to be complicated to close that gap. It needs four things NIST's Playbook and New Zealand's own Exception and Waiver regime both point at independently: a named approver, a stated reason, a bounded review date, and a link to whatever compensating control was put in place instead of the one that was skipped. A minimal schema:
ai_governance_exception:exception_id: "EXC-2026-014"system_or_agent: "Client-facing claims-triage agent, v3"policy_clause_bypassed: "AI-GOV-04.2, pre-deployment model risk assessment"reason: "Urgent client-facing deployment; assessment queue backlog"requested_by: "Product delivery lead"approved_by: "Named accountable executive, not a delivery role"approved_on: "2026-09-11"review_by: "2026-12-11"compensating_control: "Manual output review, 100% sampling, first 30 days"linked_incident: nullstatus: "open"That is a starting shape, not a finished control, and it is deliberately silent on two things a template cannot settle: who in a given organisation is the accountable executive for this specific policy clause, and how long a bounded review period should run before it converts to a permanent process gap. Those are governance decisions, not schema fields, and every organisation using this will need to make them itself.
Each field earns its place from one of the two frameworks that already come closest. The approved_by field, naming an accountable executive rather than the delivery role that requested the exception, is what New Zealand's Accreditation Authority already requires and what most chat thread approvals quietly skip. The review_by field is the bound that turns an exception into a decision rather than a permanent workaround; without it, an urgent deployment's temporary shortcut has no mechanism that ever asks whether it should still be temporary. The linked_incident field is what eventually lets a board ask the harder question this chapter does not attempt to answer: whether the exceptions an organisation grants itself correlate with the incidents it later reports. Twelve months of a populated log would make that a testable question instead of a suspicion.
A reviewer checking whether a log is real rather than decorative has a small number of things to look at, none of which need twelve months of history to apply. Time to approval matters: an exception approved in the same minute it was requested was very likely approved by the same person who requested it, whatever name sits in the approved_by field. A resubmission pattern matters more than a single entry: a request declined once and then resubmitted an hour later with softer wording, against the same underlying system, is not two separate exceptions. It is one exception that learned which word to avoid, and a log that cannot tell the two apart is not doing the job. The shape of the compensating_control field itself is worth the same scrutiny; "manual review" with no named reviewer and no stated sampling rate is a placeholder wearing the compensating control's clothing, not a compensating control. None of these checks need sophisticated tooling. They need someone with the authority to ask the same follow up question the independent director asked, this time of the log entries themselves rather than of the slide that used to stand in for them.
Building the log does not, by itself, make an organisation's AI governance sound. It makes one specific, previously invisible failure mode visible: the gap between a process that exists and a process that was followed. A populated log with fifty entries and no pattern of refused requests is itself a finding worth a board's attention, and a chief risk officer reading this chapter should treat a suspiciously clean log with the same scepticism she would bring to a policy nobody has ever needed an exception to.
Return to the chief risk officer one quarter after the director's question. The log now exists, six weeks old, eleven entries. Nine were approved with a named executive and a review date; two were declined outright, one of them for the same claims triage agent that prompted the original question, this time with the delivery lead redirected to the standard assessment queue rather than granted a shortcut. She does not yet have twelve months of data, and she says so plainly in the pack rather than overstating an early trend. What she does have, for the first time, is a document that would survive the same director's question asked a second time, and a number: two declines out of eleven requests, not zero. A log with no declines would have told her the gate exists on paper and nowhere else; two declines out of eleven is early evidence that somebody is actually holding the line some of the time, which is the only claim eleven entries can honestly support.
A later chapter in this part of the book is the natural home for a fuller escalation framework built on the same logic; this chapter's artefact is deliberately the smaller of the two, and the escalation matrix is the larger structure it feeds.
The same discipline is already visible in how infrastructure teams run authorisation decisions, just not yet pointed at AI governance. Open Policy Agent, the open-source policy engine now a graduated project of the Cloud Native Computing Foundation, ships decision logging as a documented, built-in feature: every policy evaluation it makes can be recorded with its inputs, the rule that fired and a timestamp, producing an auditable trail of every allow and deny decision across an organisation's infrastructure. That is the exception log this chapter is describing, already running in production, for a different class of decision. No project has yet pointed the same pattern at agentic AI approval gates specifically. The gap is not a tooling gap; the mechanism is free to adopt and already proven at scale. It is that nobody has yet asked an AI governance programme to use it the way infrastructure teams already do.
The same four-part shape, a named authority, a stated reason, a bounded term and a tracked outcome, is load-bearing well outside AI governance, and has been for decades. The United States' Risk Management Framework, set out in NIST Special Publication 800-37, does not let a federal information system operate on a policy's strength alone. A named Authorizing Official reviews residual risk against a specific system and can accept it only against a Plan of Action and Milestones: a documented deficiency, a remediation date, and continuous monitoring until the item closes. That is close to exactly the architecture this chapter is asking AI governance programmes to build, standard practice in federal system accreditation long before agentic AI existed. New Zealand agencies operating under allied interoperability expectations inherit a version of the same discipline generally. Extending it to agentic AI specifically is the gap this chapter has been describing all along.
So, before your next board pack goes out: how many exceptions did your organisation grant this quarter, and who signed off on each one? If nobody can answer that in under a minute, the policy on your slide is measuring the wrong thing.
If your programme needs an independent architecture assurance review before its next gate, message me and I will send the scope and the fixed fee.
• • •
The views expressed in this article are entirely my own, informed by more than 30 years of professional experience in architecture, security, and technology leadership in New Zealand. I write as director of Te Pono Limited; the views are personal and do not represent the position of any client, any government agency, or the New Zealand government. My commentary on legislation and policy is analytical, drawing on publicly available sources and my professional expertise in architecture, security, and AI governance, and it is politically neutral.
• • •
Andreas Hamberger is a New Zealand leader in Architecture & Security and Associate Member of the Institute of Directors. Zero Trust Architecture for the Agentic Enterprise is the first book in The Hamberger Report series, providing practitioners with deployable patterns and configurations for securing AI-driven systems. Through Te Pono he provides independent architecture assurance reviews and AI verification audits to boards and programmes; contact andreas@thehambergerreport.com for the scope and fixed fee.
This article was produced with AI assistance under my direction. Research, drafting and images pass through a pipeline I built and govern: automated gates for source verification, forbidden language and political neutrality, and my own review before anything is published. The tools include Claude, Gemini and Openart. The frameworks, arguments and editorial judgements are mine and are the same discipline I apply to the AI systems I audit for clients. AI accelerated the work; the thinking, and the responsibility for it, are mine.
[1] EY. "EY survey finds that autonomous AI implementation outpaces oversight, yielding an AI governance gap." 15 September 2026. https://www.ey.com/en_us/newsroom/2026/09/ey-survey-finds-that-autonomous-ai-implementation-outpaces-oversight-yielding-an-ai-governance-gap
[2] CIO Dive. "Businesses sidestep AI governance policies as concerns mount." 16 September 2026. https://www.ciodive.com/news/EY-governance-AI-policies-sidestep/830561/
[3] National Institute of Standards and Technology, AI Resource Center. "AI RMF Playbook, Measure 2.8." Accessed September 2026. https://airc.nist.gov/airmf-resources/playbook/measure/
[4] ISO Docs. "ISO 42001 Clause 10.2, Nonconformity and Corrective Action." Accessed September 2026. https://iso-docs.com/blogs/iso-42001-standards/iso-42001-clause-10-2-nonconformity-and-corrective-action
[5] National Cyber Security Centre, New Zealand. "NZISM v3.9 release notes." Accessed September 2026. https://www.ncsc.govt.nz/news/nzism-v3-9-release/
[6] OneTrust. "OneTrust Research: 86% of Organizations Experienced AI-Related Incidents, Yet Few Slowed Deployment." 14 September 2026. https://www.globenewswire.com/news-release/2026/09/14/3361166/0/en/onetrust-research-86-of-organizations-experienced-ai-related-incidents-yet-few-slowed-deployment.html
[7] vmblog. "OneTrust Research: 86% of Organizations Experienced AI-Related Incidents, Yet Few Slowed Deployment." 14 September 2026. https://vmblog.com/news/onetrust-research-86-of-organizations-experienced-ai-related-incidents-yet-few-slowed-deployment/
[8] Stanford Institute for Human-Centered Artificial Intelligence. "The 2026 AI Index Report, Responsible AI." Accessed September 2026. https://hai.stanford.edu/ai-index/2026-ai-index-report/responsible-ai
[9] The Hamberger Report. "Zero Trust for AI Agents" (trimmed per the standing backreference rule; full published title is colon-joined). Chapter 32, 17 September 2026. Internal reference, no external URL.
[10] The Hamberger Report. "Continuous Conformity." Chapter 21, 26 June 2026. Internal reference, no external URL.
[11] National Institute of Standards and Technology. "Special Publication 800-37 Revision 2, Risk Management Framework for Information Systems and Organizations." December 2019. https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-37r2.pdf