Board and executive leadership should own AI risk accountability, with clear operational responsibility assigned across data, security, and AI teams. Regulators are no longer looking for informal consensus or departmental policy statements. They want a traceable decision model, defined approvals, and evidence that the institution can produce on demand.
Who should own AI risk accountability in a regulated bank?
Board and executive leadership should own AI risk accountability, with clear operational responsibility assigned across data, security, and AI teams. Regulators are no longer looking for informal consensus or departmental policy statements. They want a traceable decision model, defined approvals, and evidence that the institution can produce on demand.
Why board ownership is the right accountability model
In a regulated bank, AI risk accountability sits with the board because the risk is not limited to model performance. It extends into customer harm, regulatory breach, conduct risk, third-party dependence, and operational resilience. The accountable body must therefore be able to set appetite, approve exceptions, and challenge management when AI use cases move beyond tolerance.
The practical distinction is between accountability and execution. Management can run the control framework, but board and executive ownership is what gives the programme authority when trade-offs arise between speed, innovation, and control. If ownership is too low in the organisation, approvals become fragmented and no one can explain why a particular AI use case was accepted, restricted, or stopped.
That ownership model also needs to be explicit enough for audit and supervision. A bank should be able to show who accepted the risk, what evidence they reviewed, which control gaps were present, and which team is responsible for ongoing monitoring. Without that traceability, accountability becomes informal and hard to defend.
How responsibility should be split across the bank
Ownership should not collapse all AI work into one central team. The board owns the accountability line, executive leadership owns the operating model, and specialist teams own the controls they can actually execute. Data teams usually own training data quality, lineage, retention, and access constraints. Security teams own threat exposure, monitoring, and control testing. AI or model teams own design, validation, drift management, and change control.
A useful rule is that no team should own a risk it cannot measure or remediate. For example, a model team can validate performance, but it should not be solely responsible for legal or regulatory sign-off. Likewise, security can enforce access and monitoring, but it should not be the only approver for business use, because business impact and customer treatment sit outside pure technical control ownership.
This split works best when decision rights are written down in a RACI-style model or an equivalent governance map. The point is not the format, it is that every material AI use case has one accountable executive, named control owners, and a path for escalation when control evidence is missing or a use case changes materially.
What regulators will expect to see in practice
Supervisors usually care less about the organisational chart than about whether the bank can demonstrate disciplined control. They expect approval records, risk assessments, inventory coverage, model or use-case boundaries, testing results, exception handling, and periodic review. If a regulated bank cannot show those items quickly, the governance model will be seen as weak even if the policy language is polished.
That is why ownership should be tied to evidence retention from the start. The accountable executive should know where the decision record lives, who updates it, and how it is reviewed after a model change, incident, or vendor change. For banks using AI in high-impact workflows, governance should be able to answer a very simple supervisory question: who can stop this system if the risk profile changes?
For banks trying to strengthen board oversight of AI, the best starting point is a board briefing on AI risk that translates technical exposure into decision-ready language. The operational details then need to be anchored in documented control ownership, which is why NHIMG’s NHI Ownership and Accountability Guide is useful when the same bank is mapping ownership across machine or service identities that support AI systems.
Risk and Threat Considerations
When AI accountability is vague, the main risk is not just a governance gap, it is a compounding control failure. Models may be approved by one function, operated by another, supplied by a third party, and monitored by nobody with clear authority to intervene. That creates weak escalation, slow incident response, and a real chance that an AI issue continues after it should have been suspended.
Failure mechanism: Responsibility disperses across data, technology, compliance, and business teams, but no single accountable owner remains able to sign off risk acceptance, enforce change control, or produce evidence for supervisors.
Impact: The bank can lose the ability to demonstrate control over customer-facing decisions, vendor dependencies, and model changes, which raises regulatory, conduct, and operational resilience exposure.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
NIST AI RMF and NIST SP 800-53 Rev 5 set the technical controls, while ISO/IEC 42001:2023 and DORA define the regulatory obligations.
| Framework | Control / Reference | Relevance |
|---|---|---|
| ISO/IEC 42001:2023 | 4.2 — Understanding the needs and expectations of interested parties | Banks must align AI accountability to regulator expectations and oversight demands. |
| 5.1 — Leadership and commitment | Board and executive ownership are central to accountable AI governance in regulated banks. | |
| 5.2 — AI policy | A bank needs a documented AI policy that turns accountability into enforceable governance. | |
| Recommendation — Define accountable owners and evidence so AI governance satisfies supervisory expectations. Assign board-level accountability and executive ownership for AI risk decisions. Issue an AI policy that defines decision rights, approvals, and escalation. | ||
| NIST AI RMF | GOVERN — Govern | The question is fundamentally about who owns AI risk governance and oversight. |
| MAP — Map | Banks must inventory AI uses and understand risk context before assigning ownership. | |
| MANAGE — Manage | Ongoing accountability depends on documented controls, reviews, and escalation paths. | |
| Recommendation — Establish AI governance roles, accountability, and oversight at executive level. Map AI use cases, stakeholders, and risks before approval. Manage AI risks with named owners, control testing, and escalation. | ||
| DORA | Article 5 — ICT risk management framework | Regulated banks need formal ICT risk governance and accountability for technology-enabled AI risk. |
| Article 6 — ICT systems, protocols and tools | AI systems in banks require controlled operational ownership and monitored tooling. | |
| Recommendation — Embed AI accountability inside the bank’s ICT risk management framework. Assign ownership for AI systems, controls, and monitoring tools. | ||
| NIST SP 800-53 Rev 5 | PM-1 — Information Security Program Plan | A formal program plan supports enterprise accountability and governance for AI risk. |
| CA-2 — Control Assessments | Banks need evidence that AI controls are assessed and reviewable on demand. | |
| Recommendation — Document AI governance roles, responsibilities, and oversight in the security program. Assess AI controls regularly and retain evidence for audit and supervision. | ||
Practitioner Guidance
What to prioritise: Assign one accountable executive per material AI use case or AI domain, then document the control owners underneath that person. If a use case cannot be mapped to a named approver, treat it as not ready for production.
What to verify: Check that each AI decision path has an inventory entry, a risk owner, an approval record, an exception process, and a review cadence. If any one of those is missing, the governance story is incomplete even if the system is technically secure.
What good looks like: A regulator or internal auditor can ask for a specific AI use case and receive, within minutes, the accountable executive, the operating owners, the last review date, the open issues, and the evidence used to justify continued use.
Practitioner takeaway: In a regulated bank, AI accountability must sit high enough to carry risk acceptance, but close enough to operations to force evidence, challenge exceptions, and stop uncontrolled expansion.