AI strategy and governance for banks: a named accountable person for every kind of AI decision, an oversight arrangement that can be tested, and a path from pilot to production that the second line can actually approve.
Human in the loop is the standard answer to every AI risk question in banking, and it is a good answer when it is true. It stops being true when the human has forty seconds per case, no practical basis for disagreeing, and a process that asks for justification when they override and nothing when they accept.
Governance frameworks usually classify AI by technology or by risk tier. The more useful question is what role the AI plays in a decision, because that determines who is accountable and what accountability requires them to be able to do.
AI initiatives in every function
With no portfolio view and no shared stop list.
Obligations that differ by market
And a framework written for one of them.
Accountability described, not assigned
A committee owns it, which means nobody does.
Privacy settled per project
So the same question is answered differently.
Explainability treated as one problem
When the customer and the validator need different things.
Generative AI outside the model framework
Because it does not fit, so it was not entered.
Agents acting with no authority limit
The question is no longer whether the output was right.
Pilots that cannot be governed
Which is why they stop rather than scale.
Ask for the override rate on your most consequential AI-assisted decision. If the number is not available, the oversight control has never been tested and cannot be evidenced. If it is available and close to zero, the institution is operating an automated decision while describing a human one, which is the more difficult position of the two. Collecting it is a reporting change rather than a programme, and it is the first thing we would ask for.
Banking AI pilots rarely fail on the model. They fail at the second line, at the end, when somebody asks how this will be validated, monitored, explained and stopped, and the answers do not exist because nobody was asked those questions when the use case was chosen.
So we assess governability at selection, with the model risk and compliance functions involved in prioritisation rather than only in approval, and we include the cost of control in the business case. A use case that cannot be governed proportionately is not a cheap pilot, it is a pilot with a known ending.
Step 1
Assess AI maturity across capability, governance and data readiness
Step 2
Identify opportunities with the business, by function
Step 3
Establish what AI is already in use, including vendor features
Step 4
Classify each use by the role it plays in a decision
Step 5
Assess governability per use case before prioritising it
Step 6
Prioritise on value, risk, readiness and cost of control
Step 7
Name the accountable person per use case, not a committee
Step 8
Design the governance framework to extend what exists
Step 9
Design the oversight arrangement so it can be tested
Step 10
Define the lifecycle: approval, monitoring, review, retirement
Step 11
Plan adoption: training, process change, operating model
Step 12
Establish the cadence and the reporting that reaches the board
Take your three most advanced AI pilots and ask the second line what would be required to put each one in production. Ask now rather than at the end. The answers are usually obtainable in a week, they change which pilot should be first, and in at least one case they establish that the use case cannot be governed proportionately at all. Finding that out before the build is the cheapest governance work available.
Grouped by what each part does. We build the governance and the engineering that makes it operable. We do not build the AI on this page: the delivery pages in this section do that, and this page is deliberately separate from them.
Strategy
Enterprise AI strategy tied to business outcomes, with an explicit stop list alongside the roadmap
AI maturity assessment across capability, governance, data readiness and adoption
Opportunity identification by function, including the AI already in use without a sponsor
Operating model and governance
AI operating model: who decides, who monitors, who can pause, and what reaches the board
Governance framework design that extends your model risk framework rather than paralleling it
Accountability assignment per use case, to a named person who has accepted it
Review routes that are proportionate to the role the AI plays in the decision
AI policies and standards written so a product team can apply them without escalating, with procurement standards and documentation templates, since most AI will arrive through buying rather than building
Exception governance: who may grant an exception, on what basis, and when it expires
AI Centre of Excellence design on a federated model, including what it owns and what it must not own
Risk and responsible AI
Responsible AI framework: fairness, transparency, accountability and human oversight, defined so they can be tested rather than asserted
AI risk management integrated with your operational risk and model risk taxonomies
Third-party AI risk approach, for the models you did not build and cannot inspect
Generative AI and agent governance, covering the three gaps in section 7
Lifecycle and engineering
Model inventory and registry, covering anything that influences a decision rather than only traditional models
Model lifecycle governance: approval, deployment, monitoring, review, change and retirement
Evaluation and testing capability, including evaluation sets for generative use cases
Explainability and audit trail engineering, for both audiences in section 7
Human-in-the-loop controls engineered into the workflow rather than added beside it
These are the places AI governance gets tested in a bank. The governance question is different in each, and naming it is more useful than describing the oversight structure.
Lending and credit decisions
AI influencing whether a customer is approved, on what terms, and at what price.
Fraud model oversight
Detection models whose output blocks or delays legitimate customers as well as catching fraud.
Customer service AI
Assistants and automation in servicing, where the AI speaks to the customer directly.
Generative AI copilots
Staff-facing assistants drafting, summarising and answering questions from internal material.
Autonomous agents
AI taking actions in systems rather than producing output for a person.
Risk and compliance AI
AI used inside the control functions themselves: monitoring, screening, reporting support.
Enterprise AI portfolio
The whole set, viewed as a portfolio rather than as projects.
For any agent in or near production, ask who can stop it in the next five minutes. If the answer requires a developer, a deployment or a conversation about who has access, the institution has an automated actor it cannot halt. That is a different risk from a model being wrong, and it is the one governance question that cannot wait for the framework to be finished.
Governance architecture is mostly unremarkable engineering in service of a few obligations: know what you have, see how it behaves, explain what it did, and be able to stop it. The first of those is where most institutions are weakest.
Model inventory and registry
Everything influencing a decision, including vendor features and anything a team adopted directly.
Lifecycle management
Approval, deployment, change, review and retirement, with state visible per model.
Monitoring and observability
Performance, drift and behaviour, with thresholds and owners.
Evaluation and testing
Test sets and evaluation suites, including for generative use cases.
Explainability
Two forms for two audiences, per section 7.
Audit trail
What the model saw, what it produced, what was decided, who decided it.
Human-in-the-loop controls
Built into the workflow, with the override reason captured on both paths.
Reporting
Governance effectiveness and risk indicators, per section 8.
The NIST AI Risk Management Framework and its generative AI profile, which is the most widely used reference structure and is voluntary
ISO/IEC 42001 for an AI management system, where your institution wants a certifiable structure
ISO/IEC 23894 for AI risk management guidance
Your existing model risk management principles, which for a bank are usually the most authoritative starting point of the four
A bank’s model risk framework was designed for models with a defined input domain, deterministic behaviour and an owner inside the institution. Generative AI violates all three, which is why it tends to sit outside the framework rather than inside it.
Fairness and bias
Measured against definitions your conduct and legal functions set.
Transparency and explainability
Two forms, two audiences, per the sub-section below.
Data protection and privacy
What may be used for training, inference and retention.
Validation and independent review
Independent of the builder, including of us.
Regulatory alignment
Frameworks your governance may need to support, applicability yours.
Third-party AI risk
For models you cannot inspect, which is most of them.
Accountability and oversight
Named, accepted and testable, per section 2.
Incident management
Including what counts as an AI incident, which needs defining first.
Model monitoring is well understood and frequently implemented. Governance monitoring is neither, and without it the framework becomes a set of documents that describe an institution nobody has checked against reality.
Performance against the measure agreed at approval, not whichever measure looks best now
Input drift and population change, which is usually the earliest available warning
Output distribution change, which is what detects a generative model behaving differently after a change you did not make
Outcome differences across groups, against the fairness definitions your conduct function set
Agent behaviour, where agents are in use: unauthorised action attempts, tool-use exceptions, human intervention rate and completion quality. The first of those is the measure that tells you whether the authority limit is holding
Operational reliability of the AI service itself: availability, latency and dependency failures, since an assistant nobody can reach is an adoption problem that will be reported as a governance one
Value against the case the use was approved on, because a use case approved on a benefit that never arrived should be retired rather than monitored indefinitely
Incident and exception volumes, with a definition of what counts as an AI incident
Override rate per AI-assisted decision, in both directions, per section 2. The most informative single number on this page
Inventory completeness: models discovered through other means after the inventory was declared complete, which is the honest measure of whether registration is working
Reviews completed against reviews due, by tier, since an overdue review on a high-consequence model is a control failure rather than an administrative delay
Time from use case submission to decision, because a slow route is routed around and the routing-around is invisible
Use cases stopped or rejected, which should not be zero. A governance process that has never said no has not been tested
Accountability gaps: models in the inventory with no named accountable person, which should trend to zero
And models retired, because an AI portfolio that only grows is not being managed
RESTRICT. Narrow the use: fewer case types, lower values, a smaller population. Often enough, and reversible
ROUTE TO HUMANS. Move the decision back to a person, which is available only if the operational capacity to absorb it still exists. That is worth checking before it is needed
REVERT. Return to a previously approved version, which requires that version and its evidence to have been retained
SUSPEND AUTHORITY. For an agent, withdraw permissions rather than stopping the system, which is a finer instrument than an on and off switch
RETIRE. Withdraw the use case, with the inventory updated and the business told why
Ask how many AI use cases your governance process has rejected or stopped in the last year. If the answer is none, one of two things is true: either everything proposed was appropriate, which is unlikely in any institution running more than a handful of use cases, or the process cannot say no. Both answers are worth knowing, and this single question tells a board more about AI governance than any maturity score.
Outcomes depend on how much AI is already in use, the maturity of your model risk function and your markets. These are the changes the work is aimed at.
A single enterprise AI roadmap with a stop list, rather than initiatives in every function
A named accountable person for every AI use, who has accepted it and can describe what they are accountable for
An oversight arrangement that can be tested, with the override rate measured in both directions
An inventory that includes vendor features and directly adopted tools, maintained as a condition of something teams need
Generative AI and agents inside the risk framework rather than beside it, with the three gaps in section 7 addressed explicitly
Explainability that serves both audiences, including the ability to reconstruct a decision months later, and a third-party position that does not depend on inspecting a model you cannot see
Governance effectiveness measured, including the measures nobody currently has
Faster adoption, because governability was assessed at selection rather than discovered at the end
And a defensible answer to the question of what AI the institution uses and who is accountable for each item
Bring us your AI estate as it actually is, including the pilots nobody sponsored and the vendor features somebody switched on, and we will inventory it, map accountability, classify each use by its role in a decision, and tell you which of your pilots cannot be governed proportionately before you spend more on them.
CaliberFocus designs AI strategy and governance for banks that extends the model risk framework you already have rather than building a second one. We assess governability when a use case is selected, name an accountable person for every kind of AI decision, design oversight that can be tested, and build the inventory, evaluation and audit engineering that makes the governance operable.
- A named accountable person for every AI use case
- Human oversight that can be tested, with the override rate measured
- Generative AI and agents brought inside your model risk framework
- An AI inventory that includes vendor features and directly adopted tools
Security & Compliance
