AI Governance Exception Registers That Expire
Manage AI governance exceptions with bounded scope, accountable risk owners, compensating controls, enforceable expiry and documented closure.
An AI governance exception register records a temporary, bounded departure from an agreed control, who accepted the resulting risk and what ends the exception. It should not become a second policy system where permissions expand through informal notes. Connect each exception to a specific deployment, compensating control, review date and enforceable expiry or stop decision.
This article is for governance and service owners managing limited enterprise-agent pilots. The example is a temporary restriction to one document format while a connector is being improved. It does not justify bypassing tenant isolation, human authority or another control whose failure would make the use case unacceptable. Some conditions must remain release blockers.
Separate an exception from an incident and a change
An exception accepts a defined limitation for a limited purpose. An incident records an observed problem requiring response. A change modifies the approved system or procedure. They can be related, but one record should not conceal the others. If a control fails unexpectedly, recording an exception afterward does not erase the incident or establish that prior actions were authorised.
The NIST AI RMF FAQs describe the framework as voluntary risk-management guidance. The register below is an operational proposal aligned with that general task, not a required NIST form or evidence of legal compliance. Applicable obligations and non-waivable controls need qualified review in the organisation's actual context.
Make the scope narrower than the deployment
An exception should identify the exact control, affected candidate, process, tenant and environment. “Pilot exception” is too broad to tell an operator what may continue. State the permitted activity and the excluded activity separately. For example, the worker may prepare drafts from one approved file format while unsupported formats are returned to manual handling.
| Register field | Required decision | Example of an inadequate entry |
|---|---|---|
| Control reference | Which approved requirement is not fully met? | General statement that some controls are unfinished |
| Bounded scope | Which cases and deployment version are affected? | Permission covering all future agents and customers |
| Risk owner | Who has authority to accept this specific risk? | The developer who requested the exception approves alone |
| Compensating control | What reduces exposure while the limitation remains? | A promise to monitor without named signals or response |
| Expiry condition | What date or event ends the permission? | A review date with no behavior when the date passes |
| Remediation | Who will remove the need for the exception? | An unassigned backlog item without acceptance criteria |
| Closure evidence | What demonstrates the control now works? | A ticket marked done without a repeatable verification |
Record rejected requests too. They explain why a boundary exists and help prevent the same request from being reframed until somebody approves it. Access to the register may itself need restriction, especially when it describes weaknesses or references sensitive cases. Share summaries according to purpose rather than publishing every operational detail.
Do not let an exception create unlimited authority
Risk acceptance and action authorisation are separate decisions. A service owner may accept reduced convenience during a pilot without granting an agent permission to access new data or execute additional actions. Any necessary authority change should pass its own normal review and enforcement path. The register can reference that decision but should not substitute for it.
Define which controls cannot be waived through the ordinary exception process. The list depends on the organisation and task, but it should be approved before exceptions are requested. Where a proposed departure would remove the essential basis for the use case, the answer may be to reduce scope or delay release rather than invent a compensating label.
Tie monitoring to a specific response
“Enhanced monitoring” is not a complete compensating control. Name the signal, collection path, owner, response time and action taken when the condition occurs. If unsupported documents must go to manual handling, count rejected inputs and verify that no fallback parser silently processes them anyway.
Estimate the workload created by the compensation. A manual review requirement is ineffective when nobody is available to perform it. Record expected case volume, available qualified reviewers and the intake limit if capacity is exhausted. Treat those numbers as planning assumptions to validate, not as evidence of achieved operational performance.
Define expiry as behavior, not a reminder
At expiry, the affected permission or deployment path should move to its documented safe state unless a new decision has been made. An email reminder alone does not establish this behavior. Depending on the scope, the system may stop new intake, restrict a tool, or require a fresh release decision. Existing external effects need separate reconciliation.
Renewal should create a new decision that cites the previous exception, current evidence and reason remediation is incomplete. Do not edit the old expiry date in place and lose the original commitment. Repeated renewal is useful information: it may indicate that the accepted limitation has become a permanent design choice requiring a different governance decision.
Test the register against a synthetic pilot
Create an exception for a single file format in a synthetic pilot. Submit an allowed file, an unsupported file and a case from a different tenant or candidate. The register's scope should support the first permitted path and leave the other paths subject to their normal controls. The existence of an exception must not widen unrelated access.
Advance the test clock past expiry and verify the specified stop behavior. Then attempt a renewal using evidence from a different deployment. The reviewer should identify the mismatch rather than accept a superficially complete form. Repeat with the risk owner unavailable and confirm that an unqualified substitute cannot approve merely to clear the queue.
Close the exception with evidence of the correction
When remediation is ready, rerun the original failing case and relevant regression cases. Record the corrected candidate and the verification result. The process owner should confirm whether the limitation has actually been removed or whether the business scope simply changed. Those are different reasons for closure and should remain distinguishable.
Keep links to incidents, changes and release decisions so another reviewer can reconstruct the sequence. Avoid deleting an expired exception just because it is no longer active. Its history may explain why a case followed a restricted route or why a particular release was allowed only under supervision.
Review the portfolio for recurring causes
Report active, expired, renewed and closed exceptions separately, with age and affected scope. Do not treat a declining count as an improvement without checking whether records were removed, merged or reclassified. Examine recurring causes such as unclear ownership, unavailable evidence, unrealistic review capacity or integration contracts that remain unsettled.
The worksheet is useful when an operator can determine what is allowed today, who is accountable and what happens tomorrow if nothing changes. That is more actionable than a spreadsheet of accepted risks with no connection to runtime behavior, remediation work or the people who must make the next decision.
Use the worksheet and related implementation guides
Use the parent guide for the wider architecture, then apply this article to one bounded implementation. The adjacent articles cover related decisions without replacing this worksheet.
Download the editable worksheet. Next step.
Engineering draft, 18 October 2026. Primary sources checked on this date; specialist review remains pending. The worksheets describe proposed tests, not measured customer results. OATI remains a developer preview. Local implementation evidence does not establish independent assurance, customer acceptance or production readiness for a particular deployment.