Policy Change Provenance Governance requires that every change to policy rules governing AI agent behaviour is tracked with complete provenance: who requested the change, who approved it, under what authority, with what justification, supported by what evidence, and through what review process. The provenance record must be immutable, tamper-evident, and linked to the policy version identifier per AG-269 so that any policy version can be traced back to its origin, approval chain, and business rationale. This dimension ensures that no policy change occurs without accountability and that the full history of policy evolution is reconstructable for audit, investigation, and regulatory purposes.
Scenario A — Unauthorised Policy Change Discovered During Audit: A financial-value agent's risk scoring policy is modified to lower the fraud detection threshold from a score of 0.85 to 0.70, increasing the false-positive rate significantly. The change was made directly in the rule engine configuration by a developer during an after-hours maintenance window. No change request was filed, no approval was obtained, and no justification was recorded. The change is discovered 4 months later when the fraud team investigates why fraud detection alerts have increased by 340%. The developer who made the change has left the organisation. The organisation cannot explain why the threshold was changed or who authorised it.
What went wrong: The policy store allowed direct modification without requiring provenance metadata. No approval workflow enforced authorisation. The change was invisible to the governance process. Consequence: 4 months of elevated false-positive fraud alerts creating operational waste estimated at £280,000, inability to demonstrate governance over policy changes to the regulator, FCA finding for inadequate change control under SYSC 6.1.1R.
Scenario B — Conflicting Justifications for the Same Change: A customer-facing agent's eligibility policy is modified to exclude applicants with County Court Judgments (CCJs) from premium products. The change request cites "credit risk management" as the justification. However, the actual motivation (discovered during a discrimination review) was a business decision to exclude a demographic group that correlates with CCJ presence. The provenance record captures only the stated justification, not the actual motivation. A regulatory investigation into potential indirect discrimination relies on the provenance record and concludes the change was risk-based — until internal communications reveal the actual rationale.
What went wrong: The provenance record captured the formal justification but not the underlying analysis or supporting evidence. The justification was misleading. Consequence: Regulatory investigation for potential Equality Act violation, reputational damage from discovery of misleading justification, estimated legal and remediation cost of £1.2 million.
Scenario C — Emergency Change Without Post-Hoc Ratification: A safety-critical agent's operating policy is modified during an emergency to bypass a temperature alarm threshold. The emergency change is documented as "emergency override — ratify later." The ratification never occurs. Over the following 6 months, 14 additional emergency changes are made, each with "ratify later" notes. When a safety audit occurs, 15 unratified emergency changes are discovered, none with documented approval or justification beyond the emergency note. The safety case for the system is invalidated because the operating policy has diverged from the approved safety case without formal review.
What went wrong: The emergency change process allowed changes without immediate approval (appropriate for emergencies) but did not enforce post-hoc ratification. The "ratify later" promise was a human commitment, not a system-enforced deadline. Consequence: Safety case invalidation, potential operational shutdown until the safety case is re-established, regulatory finding under IEC 61511 for inadequate management of change.
Scope: This dimension applies to all AI agents governed by configurable policy where the policy can be changed. Any system where policy rules can be added, modified, removed, or have their precedence altered is within scope. The scope covers all policy change types: new rules, rule modifications, rule removals, threshold changes, precedence changes, exemption additions, temporal trigger changes, and jurisdiction-specific variant changes. The scope extends to emergency changes, which must meet the same provenance requirements but may use an accelerated approval process with mandatory post-hoc ratification.
4.1. A conforming system MUST require a structured change request for every policy change, capturing: the proposed change, the requester's identity, the justification, the supporting evidence, the risk assessment, and the expected impact.
4.2. A conforming system MUST require documented approval from an authorised approver before any policy change is activated in production, with the approver's identity, approval timestamp, and approval scope recorded.
4.3. A conforming system MUST link the provenance record (change request, approval, justification, evidence) to the policy version identifier per AG-269, so that any version can be traced to its complete provenance.
4.4. A conforming system MUST store provenance records in an immutable, append-only data store that cannot be modified after the fact — corrections must be recorded as new entries referencing the original, not as overwrites.
4.5. A conforming system MUST enforce mandatory post-hoc ratification for emergency changes within a defined time window (recommended: 72 hours), automatically escalating unratified changes and blocking further emergency changes if the ratification backlog exceeds a defined threshold (recommended: 3 unratified changes).
4.6. A conforming system MUST record the separation of duties: the requester and the approver must be different individuals. Self-approval of policy changes is prohibited.
4.7. A conforming system SHOULD capture the supporting evidence for the change (e.g., regulatory requirement reference, incident report, business case, risk assessment) as part of the provenance record, not merely a text description of the justification.
4.8. A conforming system SHOULD implement automated provenance completeness checks that block activation of any policy change where required provenance fields are missing or incomplete.
4.9. A conforming system MAY implement provenance chain verification that validates the complete provenance chain for a policy version — from the original business requirement through the change request, approval, compilation, verification, sandbox testing, and activation.
Policy provenance addresses the question that regulators, auditors, and investigators invariably ask: "Why does this policy say what it says, and who decided it?" Without provenance, the organisation can demonstrate what the policy is (per AG-269) and how the policy was compiled (per AG-270), but cannot explain why the policy exists in its current form.
The accountability requirement is both operational and regulatory. Operationally, provenance enables root-cause analysis when a policy produces unexpected outcomes. If the policy was changed 3 weeks ago and the change introduced an unintended interaction, provenance identifies who requested the change, what they intended, and what evidence they relied on. Without provenance, the investigation begins with "who changed this and why?" — a question that may be unanswerable if the person has moved on or if multiple changes have been made.
The separation of duties requirement (4.6) exists because self-approved policy changes represent a single point of failure in the governance process. A developer who both writes and approves a policy change has no independent check on their work. The FCA, PRA, and other regulators explicitly require separation of duties in control environments. For AI agent policy, this means the person who writes the rule cannot be the person who approves it for production.
The emergency change requirement (4.5) balances two competing needs: the need for rapid response during emergencies and the need for governance. Emergency changes are permitted without the full approval process, but they must be ratified within a defined window. The automatic escalation for unratified changes prevents the "ratify later" backlog problem in Scenario C. The threshold limit (3 unratified changes) prevents the emergency process from becoming a routine bypass of the approval process.
The immutability requirement (4.4) prevents retroactive modification of provenance records. If provenance records can be altered after the fact, they cannot be trusted as evidence during investigations. Immutability means that if a provenance record needs to be corrected, the correction is a new record referencing the original — the original remains visible.
Recommended patterns:
Anti-patterns to avoid:
Financial Services. The FCA's Senior Managers and Certification Regime (SM&CR) requires that senior managers can be held personally accountable for failures in their areas of responsibility. Policy provenance creates the accountability chain: the senior manager who approved a policy change is identifiable from the provenance record. SOX Section 302 requires CEO/CFO certification that internal controls are effective — policy provenance provides the evidence trail for AI-related controls.
Healthcare. Clinical policy changes must be traceable to clinical evidence (e.g., updated clinical guidelines, new drug safety information). The provenance record must include the clinical justification and the clinical governance review. Changes to clinical decision support policy without clinical governance review violate the principles of clinical safety management per DCB 0129.
Critical Infrastructure. Safety-critical policy changes must follow the management of change (MOC) process required by IEC 61511 and similar standards. The provenance record must include the safety review, the updated safety case (if applicable), and the approval from the safety authority.
Basic Implementation — Every policy change has a change request with requester identity, justification, and approver identity. Provenance records are stored in a structured format. Separation of duties is enforced (requester != approver). Emergency changes are permitted with expedited approval and documented.
Intermediate Implementation — Provenance records are stored in an immutable, append-only data store. Supporting evidence is attached to change requests (not just text descriptions). Automated completeness checks block changes with missing provenance fields. Emergency changes have automated ratification tracking with escalation. Bidirectional linking between provenance records and policy version identifiers.
Advanced Implementation — All intermediate capabilities plus: provenance chain verification validates the complete chain from business requirement through activation. Provenance records are signed by the approver using a hardware security module. Automated analysis detects provenance anomalies (e.g., unusually frequent changes to the same rule, changes approved outside normal working hours). Independent audit of provenance completeness and accuracy. The provenance ledger is replicated to an independent custody environment.
Required artefacts:
Retention requirements:
Access requirements:
Test 8.1: Mandatory Provenance Enforcement
Test 8.2: Separation of Duties Enforcement
Test 8.3: Provenance-to-Version Linking
Test 8.4: Emergency Change Ratification Enforcement
Test 8.5: Immutability Verification
Test 8.6: Provenance Completeness Check
Test 8.7: Provenance Audit Trail for Historical Changes
| Regulation | Provision | Relationship Type |
|---|---|---|
| EU AI Act | Article 17 (Quality Management System) | Direct requirement |
| EU AI Act | Article 12 (Record-Keeping) | Supports compliance |
| SOX | Section 302 (CEO/CFO Certification), Section 404 (Internal Controls) | Direct requirement |
| FCA SYSC | 6.1.1R (Systems and Controls), 9.1.1R (Record-Keeping) | Direct requirement |
| FCA SM&CR | Senior Managers Regime | Supports compliance |
| NIST AI RMF | GOVERN 1.3, GOVERN 1.4, MANAGE 4.1 | Supports compliance |
| ISO 42001 | Clause 7.5 (Documented Information), Clause 8.1 (Operational Planning and Control) | Supports compliance |
| IEC 61511 | Clause 16 (SIS Modification) | Supports compliance |
Article 17 requires a quality management system covering "procedures and instructions for the design, design control and design verification." Policy changes are design modifications to the AI system's decision logic. The quality management system must track these changes with provenance — who designed the change, who verified it, and who approved it. Without provenance, the quality management system is incomplete.
Section 302 requires CEO/CFO certification that internal controls are effective. Section 404 requires assessment of internal control effectiveness. For AI agents executing financial operations, policy changes are modifications to internal controls. Provenance creates the accountability chain that supports the CEO/CFO certification — the senior manager can demonstrate that each control change was authorised, justified, and reviewed.
The Senior Managers and Certification Regime holds senior managers personally accountable for failures in their areas. Policy provenance creates the audit trail that identifies which senior manager approved each policy change. Without provenance, accountability is diffused — no individual can be identified as responsible for a specific policy decision.
Clause 16 requires a management of change (MOC) process for safety instrumented systems. Every change to safety-critical policy must follow MOC, with documented justification, safety review, and authorised approval. Policy provenance implements the record-keeping component of MOC for AI-governed safety parameters.
| Field | Value |
|---|---|
| Severity Rating | High |
| Blast Radius | All policy changes lacking provenance — potentially the entire policy evolution history |
Consequence chain: Without policy change provenance, the organisation cannot demonstrate who changed the policy, why, or under what authority. The immediate technical failure is the absence of accountability for a specific policy change. The operational impact is twofold: (1) during incident investigation, the root cause of a policy-related failure cannot be traced to the change that introduced it; (2) during regulatory audit, the organisation cannot demonstrate governance over its AI decision-making rules. The regulatory consequence varies by regime: SOX Section 404 material weakness findings for inadequate change control over financial AI systems (average remediation cost for SOX material weakness: $2.1 million based on 2023 analysis); FCA enforcement for inadequate systems and controls; IEC 61511 non-compliance for uncontrolled changes to safety systems. The personal accountability consequence is significant under SM&CR: the senior manager responsible for the area where an unauthorised policy change occurred may face personal regulatory action. The compounding factor is that provenance gaps are invisible until they are tested — the organisation may believe its governance is adequate until an audit or investigation reveals that policy changes were made outside the governance process.
Cross-references: AG-007 (Governance Configuration Control) provides the overarching change control framework that AG-277 specialises for policy changes. AG-269 (Policy Version Pinning Governance) provides the version identifiers that provenance records link to. AG-270 (Policy Compilation Verification Governance) is part of the provenance chain — the compilation verification is evidence that the change was correctly implemented. AG-271 (Rule-Test Coverage Governance) ensures that the policy change was tested before activation. AG-275 (Policy Simulation Sandbox Governance) provides the impact assessment that supports the change justification. AG-276 (Policy Explainability Schema Governance) provides the explainability that enables review of the change's effect. AG-278 (Policy Hot-Patch Rollback Governance) provides the rollback mechanism that provenance tracking enables — knowing which version to roll back to requires knowing the provenance of each version. AG-134 (Machine-Checkable Policy Semantics) enables automated provenance chain verification. AG-135 (Policy Precedence and Conflict Arbitration) requires provenance for precedence hierarchy changes. AG-136 (Independent Control-Plane Separation) supports the requirement that provenance records are stored independently of the agent. AG-138 (High-Assurance Invariant Verification) provides formal verification of provenance integrity properties.