Regulators from the Bank of England and Financial Stability Board have made it clear: human-in-the-loop (HITL) controls alone won't satisfy your accountability obligations for AI systems. Financial institutions must allocate responsibility for the integrity of the entire AI process, not just individual outputs.
This template provides a starting point for documenting process-level accountability that goes beyond HITL review checkpoints. Use it to define who owns what across your AI lifecycle and how you'll demonstrate that ownership to examiners.
Purpose of the Template
This policy template establishes process-level accountability for AI systems where HITL controls exist but aren't sufficient on their own. It assigns clear ownership across the AI lifecycle and defines escalation paths when process integrity breaks down.
You need this when:
- Your governance relies heavily on output review but lacks clear process ownership.
- Examiners ask who's accountable when an AI system produces problematic outputs over time.
- You're implementing ISO/IEC 42001 Annex A controls and need to operationalize clause 6.2.2 (roles and responsibilities).
- SR 11-7 validation reports identify HITL as a compensating control without addressing underlying process gaps.
The template doesn't replace HITL controls. It documents the accountability structure that makes those controls part of a defensible governance framework.
Prerequisites
Before customizing this template, ensure you have:
Clear AI Inventory: You can't assign process ownership without knowing which systems exist, their risk tier, and their lifecycle stage. Your inventory should include model type, business owner, technical owner, and current governance status.
Lifecycle Process Map: Document your actual AI lifecycle using ISO/IEC 5338 categories (development, verification and validation, deployment, operation, monitoring, maintenance). Don't map to an idealized process you don't follow yet.
Existing Control Documentation: Gather your current HITL procedures, approval workflows, and monitoring protocols. This policy will reference them, not replace them.
Stakeholder List: Identify who currently makes decisions about AI systems, even informally. You're documenting reality first, then refining it.
The Template
AI PROCESS ACCOUNTABILITY POLICY
Version 1.0
1. PURPOSE AND SCOPE
This policy establishes process-level accountability for AI systems deployed
in [organization name]. It assigns ownership across the AI lifecycle and
defines escalation requirements when process integrity issues arise.
This policy applies to all AI systems subject to [SR 11-7 / [EU AI Act](/glossary/eu-ai-act) /
internal [risk tiering](/glossary/risk-tiering) framework]. It supplements, but does not replace,
existing human-in-the-loop controls documented in [reference your HITL
procedures].
2. PROCESS OWNERSHIP STRUCTURE
2.1 Business Process Owner
The Business Process Owner holds accountability for the integrity of the
entire business process where the AI system operates.
Responsibilities:
- Define acceptable process outcomes and risk tolerances
- Approve AI system deployment into the process
- Review aggregated performance metrics [frequency: monthly/quarterly]
- Escalate when process outcomes deviate from tolerances
- Authorize process changes that affect AI system operation
Assignment: [Business unit head / Product owner / Department VP]
2.2 AI System Owner
The AI System Owner ensures the AI system operates according to approved
specifications and use restrictions.
Responsibilities:
- Maintain [Technical Documentation (Annex IV)](/glossary/technical-documentation-annex-iv) or model documentation
- Monitor for distribution drift, performance degradation, and contextual
risk factor changes
- Coordinate [model recalibration](/glossary/model-recalibration) or retraining when required
- Enforce [model limitations and use restrictions](/glossary/model-limitations-and-use-restrictions)
- Report system-level issues to Business Process Owner
Assignment: [Data science lead / ML engineering manager / Analytics director]
2.3 HITL Control Owner
The HITL Control Owner manages the design and effectiveness of human review
checkpoints within the process.
Responsibilities:
- Define which outputs require human review and approval criteria
- Train reviewers on decision standards and escalation triggers
- Monitor reviewer performance and inter-rater reliability
- Identify patterns in overridden or escalated decisions
- Report control effectiveness to AI System Owner quarterly
Assignment: [Operations manager / Quality assurance lead / Compliance officer]
2.4 Validation Function
The Validation Function provides independent assessment of AI system integrity
per [SR 11-7 / ISO/IEC 42001 clause 9.2].
Responsibilities:
- Conduct initial validation before deployment
- Perform ongoing monitoring per validation protocol
- Execute triggered validation when material changes occur
- Report validation findings to Business Process Owner and governance committee
- Maintain [validation evidence](/glossary/validation-evidence) repository
Assignment: [Model validation team / Internal audit / Third-party validator]
3. ACCOUNTABILITY MECHANISMS
3.1 Performance Reporting
AI System Owner produces monthly process integrity reports covering:
- Output volume and distribution vs. design specifications
- HITL override rate and override reasons
- Performance metric trends (accuracy, precision, fairness metrics)
- Incidents or near-misses requiring [root cause analysis](/glossary/root-cause-analysis)
- Contextual risk factor changes
Business Process Owner reviews reports and documents acceptance or required
actions.
3.2 Escalation Triggers
AI System Owner escalates to Business Process Owner when:
- Performance metrics breach established thresholds for [specify timeframe]
- HITL override rate exceeds [X]% for [specify timeframe]
- Distribution drift detected via [specify statistical test and threshold]
- Material change to input data sources or feature availability
- [Vendor model risk](/glossary/vendor-model-risk) event affecting [outsourced models](/glossary/outsourced-models)
Business Process Owner escalates to governance committee when:
- Process outcomes fail to meet business objectives
- Multiple escalation triggers occur within [specify timeframe]
- Regulatory inquiry or examination finding relates to the AI system
- Proposed [remediation](/glossary/remediation) requires material process redesign
3.3 Approval Authority
Changes requiring Business Process Owner approval:
- Model recalibration or retraining
- Modification to model limitations and use restrictions
- Changes to HITL control design or review criteria
- Expansion to new use cases or customer segments
Changes requiring governance committee approval:
- System decommissioning or replacement
- Elevation or reduction in risk tier
- Material changes to accountability assignments in this policy
4. DOCUMENTATION AND AUDIT TRAIL
AI System Owner maintains:
- Current Technical Documentation or model card
- Validation evidence from initial and ongoing validation
- Monthly performance reports and Business Process Owner sign-offs
- Escalation log with resolution documentation
- Change history for all approved modifications
Records retention: [specify period per your records policy]
5. POLICY REVIEW
This policy will be reviewed [annually / biannually] or when:
- Regulatory guidance materially changes
- Organizational AI risk appetite is revised
- Pattern of escalations indicates accountability gaps
Next review date: [specify]
Approved by: [Governance Committee Chair]
Date: [specify]
Customizing the Template
Section 1 - Scope: Replace bracketed references with your actual frameworks. If you're in financial services, cite SR 11-7. If you're subject to the EU AI Act, reference your high-risk AI classification procedure. Don't list frameworks you don't actually follow.
Section 2 - Ownership: Map roles to your organization chart. The Business Process Owner should be senior enough to own business outcomes, not just the AI system. If you have distributed accountability (e.g., regional process owners), add a table mapping systems to owners.
For the AI System Owner, pick the person who currently makes decisions about model performance, not the person who should. You can refine later.
If your HITL controls span multiple functions (e.g., front-line review plus compliance sampling), assign a coordinating owner and document the relationship.
Section 3.1 - Performance Reporting: Specify your actual metrics. If you measure fairness, name the metric (demographic parity, equalized odds, etc.). If you don't measure fairness yet, remove it from the template and add it when you do. Don't document aspirational reporting you can't produce.
Set realistic frequencies. Monthly reporting works if you have automated monitoring. Quarterly may be more realistic for complex validation metrics.
Section 3.2 - Escalation Triggers: Quantify your thresholds. "Performance metrics breach" is too vague. Specify: "Accuracy drops below 85% for two consecutive months" or "Precision-recall F1 score declines by more than 5 percentage points from validation baseline."
For HITL override rates, analyze your current data. If reviewers override 15% of outputs today, setting a 5% threshold guarantees immediate escalation. Start with current state plus a margin, then tighten over time.
Section 4 - Documentation: Reference your existing document management system. If validation evidence lives in a specific repository, name it. If you don't have centralized storage yet, this policy creates the requirement to build it.
Validation Steps
Test the Escalation Path: Pick a real AI system and walk through a hypothetical performance issue. Can you identify the AI System Owner? Do they know how to reach the Business Process Owner? Does the Business Process Owner understand their authority to halt the system?
If the answer to any question is no, your accountability structure exists on paper but not in practice.
Check Against Existing HITL Procedures: Your HITL documentation should reference this policy's HITL Control Owner. If there's a conflict about who owns reviewer training or override analysis, resolve it before you publish.
Map to Your AI Inventory: Every AI system in your inventory should have assigned owners per Section 2. If you can't fill in the names, you've discovered a gap. Fix the gap or remove the system from production.
Review with Validation Function: Your validators will need to assess whether this accountability structure is effective. Show them the draft and ask: "Can you validate against this?" If they identify ambiguities, clarify them now.
Audit the Documentation Trail: Pick one deployed system and verify you can produce everything Section 4 requires. If you can't, this policy will create compliance findings instead of preventing them.
This template won't satisfy regulators if your underlying AI governance is broken. But it will force you to document who's accountable for what, which is the first step toward fixing it.
