AI governance for financial services firms: a step-by-step guide
- 2 days ago
- 5 min read
AI governance for financial services firms: a step-by-step guide
Financial services firms are deploying AI faster than they are governing it. Supervisors have confirmed they will not write a separate AI rulebook, which means the obligations you already hold apply to a decision made by a model in the same way they apply to one made by a person. At the same time, clients and counterparties have started asking how your AI is governed, and they are asking before contracts are signed.
This guide sets out the seven steps to a defensible AI governance position, what each step involves, and the mistakes that cause the most rework.
Your roadmap
1. Build an AI inventory
List every AI system in use across the firm. Include the systems you built, the systems you bought, and the AI features inside software you procured for another purpose.
For each entry, record what it does, which business area uses it, what data it uses, and whether a decision it makes affects a customer.
This step almost always takes longer than expected. Most firms find AI they had not classified as AI, usually inside a purchased platform where a supplier switched a feature on. You cannot govern what you have not listed, and the inventory is the first thing a reviewer asks to see.
2. Classify each system by risk
Assess each system on what it decides and who it affects. A tool that drafts internal summaries carries different risk from a model that declines a credit application.
Classification determines how much control is proportionate. Without it, firms either govern everything to the same standard, which is expensive and slow, or govern nothing consistently.
If your firm sells into or operates in the European market, this is also the point at which you identify systems that fall into the high-risk category under the EU AI Act. Creditworthiness assessment is one of them.
3. Assign a named owner
Every system needs one accountable individual, recorded by name.
Not a committee, not a function, not "the data team". In a regime built on individual accountability, collective ownership fails the first question a reviewer asks, which is who is answerable for this decision.
The owner does not need to have built the system. They need to be able to explain what it does, what it is permitted to do, who approved it, and on what basis.
4. Map the obligations that apply
Four existing obligations do most of the work, and each behaves differently when the decision-maker is a system.
Individual accountability. A senior person remains answerable for the outcome, and cannot delegate that to a vendor or a model.
Fair customer outcomes. A model producing materially different results for different groups of customers creates the same problem as a policy that does. The difference is that a policy can be read, and a model has to be tested.
Operational resilience. If a system sits inside an important business service, it falls within the same resilience expectations as any other critical component, including what happens when the provider is unavailable.
Third-party risk. Most firms are buying AI rather than building it. That is a supplier arrangement, and it carries the usual due diligence, contractual and oversight expectations.
5. Put proportionate controls in place
Match the controls to the classification from step two.
For systems that affect customer outcomes, that normally means human oversight with real authority. The reviewer needs the information, the time and the standing to disagree with the system. A screen that requires a click before the decision proceeds is not oversight.
It also means testing before deployment and monitoring after it. A system that was accurate and fair at launch is not necessarily either today, and the only way to know is to keep measuring.
6. Evidence that the controls operate
This is where most firms fall short, and it is not because the controls are missing.
The reviews happen. The oversight is real. But nothing records it at the time, so when evidence is requested it has to be reconstructed, and reconstructed evidence looks like invented evidence to the person examining it.
Record the control operating, with a date and a name, at the point it operates. Testing results, oversight decisions, incidents, approvals and reviews all need to leave a trace as they happen.
7. Keep it current
Models are replaced. Providers change their terms. New data sources are added. Regulations move.
Set a review cycle for each system and a trigger for material change, so the documentation moves when the system does. This is the most common failure of all, because it requires no mistake by anyone. It only requires time to pass.
What counterparties are asking
The questions arriving in vendor and client due diligence have become consistent. It is worth checking whether you can answer each one from records rather than memory.
Which AI systems do you operate, and who owns each one.
What data was the model trained on, and who holds the rights to it.
How do you know it is working as intended, and when did you last check.
How do you know it treats customers fairly.
What happens when it produces the wrong answer, and has that procedure ever been used.
Is your AI governance aligned to a recognised standard such as ISO/IEC 42001.
Common pitfalls
1. Starting with a policy. A policy written before the inventory describes a firm that may not exist. Inventory first, then classify, then write.
2. Adopting a template unedited. If the policy says access reviews happen monthly and they happen quarterly, you are now measured against a standard you do not meet. Write what you actually do, or change what you do.
3. Treating bought AI as out of scope. You remain answerable for outcomes produced in your business, regardless of who built the model.
4. Assuming model risk management covers it. Supervisors confirmed during 2026 that revised model risk guidance does not extend to generative and agentic systems. Firms with mature model risk functions often have no governance covering the AI they are actually deploying.
5. Leaving evidence until the end. Evidence assembled in the final weeks of a period it was meant to span does not demonstrate that a control operated across that period.
Timing
An inventory and classification exercise for a firm with a small number of systems is usually a matter of weeks. Building the controls and evidence around them takes months, and depends on how much already exists.
If a client or counterparty has set a deadline, that is the constraint to plan against. Regulatory deadlines have moved and may move again. Commercial ones have not.
How we help
Buckingham Capital Consulting has advised firms on compliance, governance and regulator engagement since 2013.
We support boards and senior management on AI governance: how AI is used across the business, who is accountable for it, and whether the firm could demonstrate that to a client, an auditor or a regulator.
Our work spans AI governance reviews, readiness against ISO/IEC 42001 and the EU AI Act, policies and board reporting, and responses to client due diligence on AI.
Hael advises firms on AI governance and compliance, built on fifteen years of regulatory practice.
Hael supports firms through ISO/IEC 42001, the EU AI Act, SOC 2 and ISO 27001, from first assessment to certificate, and ensuring ongoing compliance. Services span readiness, implementation, internal audit, certification support, client security reviews and continuous assurance.
