AI Governance in Banking: From Pilots to Lifecycle Control
AI adoption has outgrown pilot-era controls
AI is becoming ordinary infrastructure inside financial institutions. The Bank of England and Financial Conduct Authority survey found that 75% of responding firms were already using AI and another 10% planned to do so within three years. Respondents expected the median number of use cases to rise from nine to 21. Operations and IT accounted for the largest share of reported use cases, while optimisation, cyber security and fraud detection were among the most common applications.
That breadth changes the management problem. A controlled proof of concept can rely on a small team, a fixed dataset and manual review. A production portfolio may span customer service, coding assistance, document analysis, financial crime operations, credit processes and internal decision support. Models can change, vendors can update services, prompts can drift, and employees can create unofficial uses outside normal procurement. A static approval at launch is therefore not enough.
The policy direction is converging around lifecycle control. The Financial Stability Board's June 2026 consultation proposes 12 sound practices across organisation-wide governance and the stages of AI development and deployment. It is a consultation rather than a binding standard, but it provides a useful benchmark for boards deciding whether their existing technology, data, model and operational-risk processes form a coherent AI system.
Build one inventory that answers five questions
Banks often begin with several partial lists: models tracked by model risk, vendors tracked by procurement, applications tracked by technology, and experiments tracked by innovation teams. AI governance needs a joined view. For each use case, management should be able to identify the business purpose, accountable owner, data used, model or service dependency, and decision or action influenced.
The inventory should capture embedded AI as well as internally developed models. A software upgrade may introduce summarisation, ranking or recommendation features without being labelled an AI project. Likewise, a workflow may call several models through an orchestration layer. Recording only the user-facing application obscures the dependencies that matter when a provider changes a model or a component fails.
Materiality should be based on impact, not technological novelty. Useful factors include whether the output affects a customer, moves money, changes access to a product, generates regulatory evidence, handles confidential data, or operates at high volume. The result should be a small number of risk tiers tied to specific approval, testing, monitoring and human-review requirements. Tiering prevents low-risk productivity tools from receiving the same process as credit or payment decisions, while keeping both visible.
Clarify ownership before adding committees
AI crosses functions, but shared interest cannot mean diluted accountability. The business owner should remain responsible for the outcome produced by the workflow, including customer impact and operating performance. Technology should own the platform and engineering controls; data owners should approve access and quality; independent risk functions should set standards and challenge evidence; internal audit should assess whether the framework operates as described.
A central AI office can maintain policy, evaluation tools and reusable controls, but it should not become the nominal owner of every deployment. Nor should a committee approve a use case when no executive is willing to own its residual risk. Approval records should name the person with authority to accept limitations, fund remediation and stop the service. Where responsibility changes, the inventory and access rights should change with it.
Treat data lineage as a control, not documentation
Advanced AI does not remove familiar data risks; it makes them harder to observe. The BIS Financial Stability Institute highlights privacy, quality and security concerns, intensified by third-party dependencies and concentration among major service providers. A bank therefore needs to know which data enters a system, why its use is permitted, where it travels, how long it is retained and whether it may be used by a provider to improve another service.
For generative systems, lineage should extend to grounding content and user prompts. Retrieval libraries need named owners, freshness rules and access controls. Sensitive fields should be filtered before a request leaves the bank's boundary. Output logs should be retained in proportion to the risk and purpose, with clear limits on reuse. Where a model cannot provide deterministic source attribution, the workflow should not present its output as verified fact.
This is also a product-design issue. Constraining the available tools, documents and actions can be more effective than asking a broad model to behave safely. A customer-service assistant grounded only in approved product material is easier to test than one with open-ended web access. An operations agent that may prepare a payment instruction but cannot release it without a separate authorised control offers a clearer boundary than an agent with end-to-end authority.
Validation must test the workflow, not only the model
Traditional validation asks whether a model performs as specified under defined assumptions. AI-enabled workflows add questions about prompts, retrieval, tool calls, user behaviour and fallbacks. Testing should cover accuracy and stability, but also prohibited actions, data leakage, misleading confidence, prompt injection, latency, capacity limits and the quality of escalation to a person.
The Basel Committee's digitalisation review describes practices already observed at banks: firm-wide AI policies, human review, employee education, enhanced validation, formal approval, controlled gateways, grounding against vetted documents, security checks and ongoing performance monitoring. The practical lesson is to assemble these measures into a repeatable release process rather than a collection of optional safeguards.
Release evidence should include an intended-use statement, known limitations, benchmark results, adverse-test results, approval records and a rollback plan. Validation must be independent enough to challenge the business case, yet close enough to understand the complete workflow. When a vendor model changes materially, the bank needs a trigger for reassessment rather than assuming the original approval remains valid.
Put human oversight where it can change the outcome
A human-in-the-loop label has little value if the reviewer sees too many alerts, lacks the underlying evidence or is discouraged from disagreeing with the system. Oversight should be designed around intervention rights: what the reviewer can see, how much time is available, which actions require confirmation, and how disagreement is recorded.
For lower-risk drafting and summarisation, sampling and post-use review may be sufficient. For customer eligibility, transaction release or regulatory reporting, pre-action review and dual control may be appropriate. Banks should measure whether reviewers actually identify errors, not merely whether a review step exists. Rising override rates, falling review time or repeated acceptance of identical outputs can signal automation bias or a poorly designed control.
Make customer impact observable
A technically accurate average can still hide poor outcomes for particular products, languages or customer groups. Testing should use the population and conditions in which the system will operate. Complaint categories, escalation rates, abandoned journeys and correction requests can reveal harms that laboratory benchmarks miss. Where an AI-supported decision has a meaningful customer effect, staff should be able to explain the operative reason and correct the underlying record.
Transparency should be proportional and useful. A generic notice that AI may be used does not explain whether a customer is speaking with an automated assistant, whether content has been generated, or how to seek human review. The bank should decide these disclosures as part of product design, test whether customers understand them, and keep evidence that the promised escalation route actually works.
Manage providers as part of the AI system
Many banks will consume AI through cloud platforms, enterprise software and specialist vendors. Contracts should address model-change notice, permitted data use, data location, subcontractors, logging, security testing, incident notification, audit evidence, service continuity and exit support. Technical teams also need a version-aware gateway so they can identify which model processed a request and apply consistent access, filtering and usage controls.
Concentration deserves explicit attention. Two applications bought from different suppliers may depend on the same cloud, foundation model or data service. Mapping common dependencies reveals correlated failure and bargaining risk. Portability is rarely a simple model swap: prompts, evaluations, retrieval systems and control evidence may all be provider-specific. Exit testing should therefore demonstrate that a critical service can be degraded safely, transferred or operated manually within its tolerance for disruption.
Connect AI governance to operational resilience
The European Central Bank reported in June 2026 that more than 85% of banks under European banking supervision use AI. The same speech stressed that a bank can be financially strong yet unable to deliver critical services during technology disruption. AI governance should therefore sit inside service resilience, not beside it.
For each material use case, the bank should define failure modes and a safe state. What happens if the model is unavailable, slow, wrong or compromised? Can the workflow fall back to rules, manual processing or a previous version? Are queues capped so delayed requests do not create an uncontrolled backlog? Does the incident team know when to disable an AI feature without shutting the entire customer journey?
Monitoring should combine technical, risk and business measures. Accuracy samples, exception rates, unsafe-output tests, latency, vendor incidents and data-quality indicators are necessary, but so are customer complaints, operational losses, employee workarounds and changes in decision patterns. Thresholds need named owners and predetermined responses. A dashboard without intervention authority is reporting, not control.
Measure the portfolio, not just individual use cases
Senior management needs to see accumulation. The same modest control gap repeated across 80 applications can become material, and several low-impact services may rely on one provider or dataset. Portfolio reporting should show use cases by risk tier, business line, provider, data class and lifecycle status, alongside overdue reviews, open limitations and concentrations. It should also show benefits realised, because weak-value applications consume scarce validation and resilience capacity.
Change metrics are equally important. Track how often models, prompts, retrieval sources and permissions change, how many changes trigger reassessment, and whether post-release incidents cluster around updates. This turns change control into evidence about where the operating model is fragile. Over time, reusable test suites and standard gateways should reduce approval effort without reducing scrutiny.
A 90-day programme for senior management
Days 1-30: establish visibility
Name an executive sponsor and a cross-functional control forum. Reconcile technology, model, procurement and business inventories. Define risk tiers and identify the most material ten to 20 use cases. For each, document ownership, data, dependencies, decision rights and current monitoring. Freeze no activity by default; instead, route undisclosed or unowned uses into a rapid assessment.
Days 31-60: standardise evidence
Create a common approval pack covering intended use, impact assessment, data lineage, evaluation, security, human oversight, vendor terms and fallback. Set minimum tests by risk tier. Introduce a controlled access gateway for external models and a process for model-change notification. Define the metrics that will be reported to the relevant risk committee.
Days 61-90: prove the controls
Select two material services and run failure exercises. Simulate model unavailability, degraded output, a compromised grounding source and a vendor change. Measure recovery time and decision quality. Close gaps, then use the evidence to set the next funding priorities. The aim is not a one-off compliance project; it is a reusable control plane that lets the bank scale useful AI with explicit accountability.
FAQ: AI governance in banking
Does every AI tool need model-risk approval?
Not necessarily. Banks should apply proportionate requirements based on impact and use. Every use should be visible and owned, while deeper validation and independent approval should be reserved for higher-risk applications.
How should banks govern generative and agentic AI?
Govern the whole workflow: model, data, prompts, retrieval, tools, permissions, human intervention and fallback. Agentic systems require especially clear limits on which actions can be prepared, recommended or executed.
What should boards receive?
Boards need portfolio-level information: material uses, risk appetite exceptions, common providers, incidents, validation coverage, control-test results and whether critical services can operate through disruption.
How often should an AI use case be reassessed?
Use event-driven reassessment for model, data, workflow or regulatory changes, supported by periodic review. Material vendor updates and significant performance drift should trigger fresh testing.
What is the clearest sign that governance is working?
Management can identify every material use, explain who is accountable, reproduce the approval evidence, detect deterioration and move the service to a safe state without improvisation.