AI Governance Exceptions Register: Authority, Safeguards, and Expiry

Define entry criteria before teams request exceptions. A request should identify the exact policy clause, standard, control, evidence, gate, or configuration that cannot be met; why; which system, use, data, users, decisions, suppliers, and environments are affected; and what happens if the departure continues. A broad statement such as “security exception” is not a governable scope.

Approval authority should correspond to the requirement and residual exposure. The owner of a control should advise on feasibility, but should not automatically accept the business risk created by its absence. Material privacy, security, operational, customer, workforce, or regulatory consequences may require specialist challenge and senior business acceptance. Record dissent and conditions rather than presenting consultation as unanimous approval.

An exception decision should test necessity, alternatives, scope, materiality, reversibility, duration, compensating controls, monitoring, and remediation credibility. Conditions may restrict data, users, decisions, automation, integrations, geography, transaction volume, or operating hours. Evidence should demonstrate that safeguards are configured and operating before the departure begins where practicable.

Expiry is a decision trigger, not an administrative date. Before expiry, the owner must restore the requirement, request renewal with updated evidence, propose a permanent design change, or stop the affected activity. Renewal should be harder than initial approval when root cause, remediation, or monitoring has not improved. Expired exceptions need automated escalation and, where exposure warrants it, restriction or suspension.

A single operating event can create several linked records. If an approved AI service loses required logging after a supplier change, the missing control is an issue; uncertainty about undetected misuse is a risk; any confirmed harmful event is an incident; and permission to continue temporarily under compensating review is an exception. Each record has a different owner, authority, clock, and closure test. Link them through system and use-case identifiers rather than collapsing them into one narrative.

Permanent acceptance of a different control design is not an exception. If management determines that an alternative control meets the governing objective, update the control specification through authorized design governance, test it, migrate affected systems, and close the temporary exception. If the policy requirement itself is no longer appropriate, use policy change authority. Repeated exceptions should not become a shadow mechanism for changing standards without review.

Compensating controls need their own assurance. Identify which part of the unmet requirement they address, what exposure remains, who operates them, how often, from which population, with what evidence, and what happens on failure. Manual review may be reasonable for a short and narrow departure, but it can become unreliable as volume grows. Capacity, competence, independence, and sample coverage belong in the decision.

Closure requires verification by someone with suitable authority or independence from the remediation activity. Confirm the original requirement now operates, the exception conditions ended, temporary access or workarounds were removed, linked risks and issues were updated, monitoring returned to the standard path, and evidence was retained. A ticket marked complete or a supplier assurance statement is insufficient when operating configuration remains unchanged.

Review individual exceptions according to exposure and the portfolio at a regular governance cadence. Look for concentration by business unit, supplier, model, control, policy clause, data type, or approver; repeated renewals; missing evidence; weak remediation; and exceptions opened after operation began. These patterns may reveal underfunded controls, impractical policy, supplier dependency, or decision routes that teams avoid.

Portfolio measures can include active material exceptions, expired exceptions, median age, renewals, repeat control gaps, overdue remediation, failed compensating controls, and time to verified closure. Counts need context: distinguish low-impact transitional departures from exceptions affecting consequential decisions, sensitive data, autonomous action, or critical suppliers. Leaders should see both residual exposure and the management action required.

Define the governing requirement through the AI governance policy template.

Map compensating safeguards through the AI control library framework.

Keep underlying exposure distinct in the AI risk register.

Use the parent AI governance controls guide to place exception handling within the wider control lifecycle.