AG-171

Exception, Waiver and Compensating-Control Governance

Execution Integrity, Accountability & Approval Quality ~17 min read AGS v2.1 · April 2026
EU AI Act SOX FCA NIST ISO 42001

2. Summary

Exception, Waiver and Compensating-Control Governance requires that every deviation from established AI governance controls is formally requested, risk-assessed, time-bounded, approved at an appropriate authority level, documented with a compensating control, and tracked to expiry or resolution. In practice, no governance framework operates without exceptions — business conditions change, edge cases arise, and rigid controls occasionally need temporary relaxation. The danger is not that exceptions exist, but that they accumulate without oversight, persist beyond their intended duration, or lack compensating controls that maintain an acceptable risk posture during the exception period. AG-171 ensures that every exception is visible, justified, bounded, and compensated — preventing the governance framework from being hollowed out through a gradual accumulation of untracked waivers.

3. Example

Scenario A — Accumulated Exceptions Hollow Out Governance: A financial services firm deploys AI agents with a governance framework requiring multi-party approval for transactions exceeding GBP 100,000. Over 18 months, 23 exceptions are granted — each individually justified ("the approver is on leave," "the client has a time-sensitive deadline," "the backup approver's system is being upgraded"). Each exception waives the multi-party requirement for a specific agent or time period. However, no central register tracks these exceptions. At the 18-month mark, an internal audit discovers that 14 of the 23 exceptions are still active — 8 because no expiry date was set, and 6 because the expiry date passed but no process revoked the exception. The net effect: 14 AI agents are operating without multi-party approval, covering approximately 60% of the firm's transaction volume. The multi-party control that the firm represents to regulators as "in place" is effectively absent for the majority of transactions.

What went wrong: Each individual exception was reasonable when granted. The failure was systemic: no central register tracked active exceptions, no expiry enforcement revoked exceptions when their conditions ended, and no aggregate analysis assessed the cumulative impact of multiple exceptions on the overall governance posture. Consequence: FCA finding for inadequate systems and controls, with the aggravating factor that the firm's regulatory reporting represented the multi-party control as active. Potential enforcement for misleading the regulator. Remediation costs estimated at GBP 400,000 including system changes, retrospective review, and regulatory engagement.

Scenario B — Exception Without Compensating Control: A healthcare AI agent requires human clinician review for all medication recommendations — a control mandated by the organisation's clinical governance framework. During a staffing shortage, the clinical director grants a waiver allowing the agent to recommend common medications (paracetamol, ibuprofen, standard-dose antibiotics) without clinician review. The waiver specifies "until staffing returns to normal levels" — no specific end date. No compensating control is defined — the waiver simply removes the review requirement.

The agent begins recommending medications without clinician review. After 3 weeks, it recommends ibuprofen to a patient whose record includes a recent GFR reading of 28 mL/min (indicating Stage 4 chronic kidney disease, a contraindication for ibuprofen). The patient develops acute kidney injury requiring hospitalisation. The automated screening that would normally be the first line of defence was designed to flag issues for the clinician reviewer — without the reviewer, the flag was generated but nobody read it.

What went wrong: The waiver removed the control without implementing a compensating control. A compensating control could have been: automated contraindication screening with mandatory block (not just flag) for high-risk interactions. The waiver also had no specific end date, ensuring it persisted indefinitely. Consequence: Patient harm (acute kidney injury, 8-day hospitalisation), CQC investigation, MHRA clinical governance finding, medical negligence claim estimated at GBP 150,000-300,000, personal liability for the clinical director who granted the waiver without a compensating control.

Scenario C — Exception Granted by Unauthorised Approver: A Crypto/Web3 AI agent has a governance control requiring compliance review for all transactions exceeding 10 BTC (approximately GBP 350,000 at current rates). A team lead grants an exception for a specific client's transactions "because the compliance team is too slow and the client is threatening to move to a competitor." The team lead has authority to grant exceptions for internal workflow controls but not for compliance controls — compliance exceptions require the MLRO's (Money Laundering Reporting Officer) approval.

The exception enables the agent to process 47 transactions totalling 892 BTC (approximately GBP 31.2 million) without compliance review over 6 weeks. When the MLRO discovers the exception during a quarterly review, investigation reveals that 3 of the transactions had sanctions screening hits that would have been caught by the compliance review.

What went wrong: The exception was granted by someone without the authority to waive compliance controls. No structural check verified that the approver's authority level matched the control category being waived. Consequence: GBP 31.2 million in potentially non-compliant transactions, 3 sanctions screening misses, OFSI investigation, potential fine of up to 50% of the value of the breaching transactions, personal criminal liability for the team lead under the Sanctions and Anti-Money Laundering Act 2018.

4. Requirement Statement

Scope: This dimension applies to every governance control in the AI governance framework that can be subject to an exception, waiver, or temporary relaxation. This includes mandate limits (AG-001), escalation thresholds (AG-019), approval requirements (AG-170), data handling restrictions, monitoring parameters, and any other control that might be temporarily modified or suspended. The scope covers both formal exceptions (documented requests through an approval process) and informal exceptions (verbal agreements, ad-hoc email approvals, configuration changes that effectively waive a control). The test for inclusion is: does the action result in a governance control operating at a lower level of rigour than the defined standard? If yes, it is an exception and is within AG-171's scope, regardless of what it is called or how it was initiated.

4.1. A conforming system MUST maintain a centralised exception register that records every active, expired, and rejected exception, including the control being waived, the scope of the waiver, the justification, the compensating control, the approver, the expiry date, and the current status.

4.2. A conforming system MUST require that every exception request includes a defined compensating control that maintains an acceptable risk posture during the exception period — exceptions without compensating controls are not permitted.

4.3. A conforming system MUST enforce that exceptions have a specific expiry date or triggering condition, with a maximum duration (e.g., 90 days for standard exceptions, 30 days for compliance-related exceptions) after which the exception automatically reverts to the standard control.

4.4. A conforming system MUST verify that the approver of an exception has authority over the specific control category being waived — compliance exceptions require compliance authority, safety exceptions require safety authority, financial exceptions require financial risk authority.

4.5. A conforming system MUST automatically revoke exceptions when their expiry date passes or their triggering condition is met, restoring the standard control without requiring manual intervention.

4.6. A conforming system MUST perform aggregate impact analysis when a new exception is requested, assessing the cumulative effect of all active exceptions on the overall governance posture and blocking or escalating exception requests that would reduce governance coverage below defined thresholds.

4.7. A conforming system MUST log every exception lifecycle event (request, approval, activation, extension, revocation, expiry) in a tamper-evident record per AG-006.

4.8. A conforming system SHOULD require escalation to a higher authority level for exception renewals — first renewal to the original approver's manager, second renewal to the governance committee — creating increasing friction for exceptions that persist.

4.9. A conforming system SHOULD produce a periodic exception health report (at least quarterly) showing the total number of active exceptions, their aggregate impact on governance coverage, the longest-running exceptions, and any exceptions approaching their maximum renewal limit.

4.10. A conforming system MAY implement a governance coverage score that quantifies the percentage of the governance framework operating at full standard versus operating under exception, providing a single metric for governance posture.

5. Rationale

Every governance framework encounters situations where the standard controls are too rigid for the immediate business context. A staffing shortage reduces the availability of human reviewers. A system upgrade temporarily disrupts a monitoring capability. A business-critical transaction requires a limit that exceeds the standard mandate. In each case, an exception is a legitimate governance response — provided it is controlled.

The risk is not the individual exception. The risk is the accumulation of exceptions over time, each individually reasonable, that collectively erode the governance framework to a point where it no longer provides the protection it was designed for. This is the "swiss cheese model" of governance failure: each exception creates a hole, and eventually the holes align, allowing a failure to pass through every layer.

AG-171 addresses this by treating exceptions as first-class governance artefacts with their own lifecycle: request, risk assessment, compensating control design, approval, activation, monitoring, and expiry. Every exception must have a compensating control — this is the critical requirement that distinguishes a governed exception from an uncontrolled waiver. A compensating control is an alternative control that maintains an acceptable (though potentially reduced) risk posture while the primary control is relaxed. For example, if the primary control is multi-party approval and the exception waives the second approver, the compensating control might be post-execution review within 24 hours, or reduced transaction limits during the exception period.

The expiry requirement ensures that exceptions are temporary by default. Without an expiry mechanism, exceptions persist indefinitely — the human who granted the exception moves to another role, the business condition that justified it changes, but the exception remains active because nobody revokes it. Automatic expiry with escalation for renewal creates a structural pressure toward restoring standard controls.

The aggregate impact analysis prevents the accumulation problem. Each new exception request is evaluated not in isolation, but in the context of all active exceptions. If granting the new exception would reduce governance coverage below a defined threshold (e.g., below 80% of controls operating at standard), the request is escalated to a higher authority or blocked. This creates organisational visibility into the overall governance posture, not just individual control status.

6. Implementation Guidance

Exception governance requires a combination of a centralised register, an approval workflow with authority verification, compensating control management, and automatic expiry enforcement. The implementation must be integrated with the governance framework's control configuration — when an exception is granted, the underlying control must be reconfigured to operate in exception mode, and when the exception expires, the control must automatically revert.

Recommended patterns:

Anti-patterns to avoid:

Industry Considerations

Financial Services. FCA SYSC 3.2.20R requires firms to establish and maintain adequate compliance and internal control arrangements. Exception governance is a core component of internal control. The FCA expects firms to demonstrate that exceptions are tracked, time-bounded, and compensated. During supervisory visits, the FCA routinely reviews the exception register and challenges long-running or poorly compensated exceptions.

Healthcare. Clinical governance exceptions (e.g., waiving clinician review for certain medication categories) must be approved by the appropriate clinical governance body and must include compensating controls that maintain patient safety. CQC inspections examine exception registers for evidence of appropriate governance.

Public Sector. Government agencies operating under the UK Government Functional Standard for Security (GovS 007) must maintain risk exception registers and ensure that exceptions are approved at the appropriate authority level. Exceptions to security controls must include compensating controls and be reviewed by the Senior Information Risk Owner (SIRO).

Maturity Model

Basic Implementation — A centralised exception register exists and is used for all formal exceptions. Each exception has an expiry date and a named approver. Expiry is monitored (though may be manual). Compensating controls are documented in the exception request. Coverage: all formal exceptions are registered; informal exceptions may not be captured.

Intermediate Implementation — All basic capabilities plus: authority-matched approval verifies the approver's authority over the specific control category. Automatic expiry revokes exceptions when their date passes. Compensating controls are monitored during the exception period. Aggregate impact analysis evaluates each new request in the context of active exceptions. Renewal escalation increases the required authority level for each renewal. Coverage: all exceptions (formal and informal) are captured through integration with the control configuration layer.

Advanced Implementation — All intermediate capabilities plus: a governance coverage score provides a single metric for the organisation's governance posture. Compensating control adequacy is validated through testing (not just documentation). The exception register integrates with regulatory reporting, enabling the organisation to demonstrate its exception posture to regulators on demand. Exception patterns are analysed to identify systemic issues (e.g., a control that is frequently excepted may need to be redesigned rather than repeatedly waived).

7. Evidence Requirements

Required artefacts:

Retention requirements:

Access requirements:

8. Test Specification

Test 8.1: Exception Without Compensating Control Is Rejected

Test 8.2: Automatic Expiry Enforcement

Test 8.3: Authority Verification

Test 8.4: Aggregate Impact Analysis

Test 8.5: Renewal Escalation

Test 8.6: Compensating Control Monitoring

Test 8.7: Exception Register Completeness

Conformance Scoring

9. Regulatory Mapping

RegulationProvisionRelationship Type
EU AI ActArticle 9 (Risk Management System)Supports compliance
EU AI ActArticle 17 (Quality Management System)Direct requirement
FCA SYSC3.2.20R (Compliance)Direct requirement
SOXSection 404 (Internal Controls Over Financial Reporting)Direct requirement
ISO 27001Clause A.5.1 (Policies for Information Security)Supports compliance
NIST AI RMFGOVERN 1.4, MANAGE 2.2Supports compliance
ISO 42001Clause 6.1 (Actions to Address Risks), Clause 9.2 (Internal Audit)Supports compliance
DORAArticle 9 (ICT Risk Management Framework)Supports compliance

EU AI Act — Article 17 (Quality Management System)

Article 17 requires providers of high-risk AI systems to implement a quality management system that includes procedures for risk management, post-market monitoring, and corrective actions. Exception governance is a core quality management procedure — it ensures that deviations from the standard governance posture are controlled, temporary, and compensated. An organisation that cannot demonstrate its exception posture cannot demonstrate an effective quality management system.

FCA SYSC — 3.2.20R

SYSC 3.2.20R requires firms to maintain adequate compliance and internal control arrangements. The FCA interprets this as requiring not just controls, but governance of the control framework itself — including the management of exceptions. Supervisory reviews routinely examine exception registers, and the FCA has issued findings against firms with long-running, poorly compensated, or untracked exceptions.

SOX — Section 404

Section 404 requires management to assess the effectiveness of internal controls. An exception register that shows 30% of controls operating under exception undermines the management assertion that controls are effective. Exception governance enables management to understand, quantify, and manage the gap between the designed control framework and its actual operating state — which is precisely what Section 404 requires.

ISO 27001 — Clause A.5.1

ISO 27001 requires policies for information security to be defined, approved, and reviewed. Exceptions to security policies must be formally managed. The ISO 27001 audit explicitly checks for a risk exception register and evaluates whether exceptions are time-bounded, compensated, and approved at the appropriate level.

10. Failure Severity

FieldValue
Severity RatingHigh
Blast RadiusFramework-wide — accumulated exceptions can compromise the entire governance framework

Consequence chain: Without exception governance, the governance framework erodes incrementally. Each individual exception is reasonable, but the accumulation is destructive. The immediate technical failure is a control operating at reduced rigour without visibility — the organisation's governance dashboard shows the control as "active" while the exception has effectively disabled it. The operational impact compounds over time: as exceptions accumulate, the gap between the designed governance posture and the actual governance posture widens. After 12-18 months of untracked exceptions, the governance framework may be operating at 50-60% of its designed coverage while the organisation reports to regulators that it is fully compliant. The business consequence includes: regulatory enforcement for misrepresenting the control environment, individual incidents that the excepted controls would have prevented (fraud, data breach, patient harm, financial loss), and the cost of emergency remediation when the exception accumulation is discovered. In regulated sectors, the discovery of widespread untracked exceptions typically triggers a formal regulatory investigation, which can result in enforcement actions, required business restrictions, and personal liability for the senior managers responsible for governance oversight.

Cross-references: AG-019 (Human Escalation & Override Triggers) for escalation of exception requests; AG-170 (Approval Quality and Substantive Review Governance) for ensuring exception approvals are substantive; AG-006 (Tamper-Evident Record Integrity) for immutable logging of exception lifecycle events; AG-049 (Governance Decision Explainability) for explaining the rationale for granting or denying exceptions; AG-007 (Governance Configuration Control) for detecting informal control modifications that bypass the exception process.

Cite this protocol
AgentGoverning. (2026). AG-171: Exception, Waiver and Compensating-Control Governance. The 783 Protocols of AI Agent Governance, AGS v2.1. agentgoverning.com/protocols/AG-171