AI Governance in Banking: The Operating Model for Controlled AI at Scale

Executive Summary

1Why AI Governance in Banking Is Different

Artificial intelligence in banking is no longer a future topic. It is already entering credit risk, fraud detection, AML, customer service, software development, regulatory reporting, cyber defence, operational resilience and internal productivity. The European Banking Authority reported in 2025 that AI deployment in the EU banking and payments sector had moved well beyond discussion, with 92% of EU banks already deploying AI and the remaining 8% pilot testing or discussing AI use cases. That changes the governance question completely. AI governance in banking can no longer be treated as an ethics add-on, a model validation appendix or a policy document owned by one specialist team. It has become part of the core management system of the bank.

This is the central point: AI governance is not about slowing AI down. It is about making AI scalable in a supervised institution.

Many banks still frame AI governance as a compliance exercise. That is understandable, but strategically too narrow. In Europe, the EU AI Act, DORA, GDPR, outsourcing rules, model risk management expectations, internal governance requirements and ECB Banking Supervision priorities all matter. But the real challenge is not to collect regulatory references. The real challenge is to translate them into an operating model that allows a bank to identify, approve, deploy, monitor and challenge AI systems across business, technology, risk, compliance, data, cyber, legal, audit and the board.

This is where many AI governance frameworks fail. They look complete on paper, but they do not change how decisions are made.

A bank can publish an AI policy. It can create an AI committee. It can appoint an AI officer. It can require impact assessments, model documentation, data quality checks and human oversight. None of that is wrong. But if those elements are not connected to investment decisions, architecture standards, risk appetite, vendor onboarding, change governance, incident management and board reporting, the bank does not have AI governance. It has AI paperwork.

The difference matters because banking is not a normal technology environment. Banks do not merely process data. They allocate credit, manage deposits, detect financial crime, calculate capital, safeguard payments, handle sensitive personal data and operate critical economic infrastructure. When AI is embedded into those processes, it becomes part of the institution’s control environment. The question is therefore not whether AI is innovative. The question is whether it is governed as part of the bank.

AI governance in banking is different for four reasons.

1. 1The consequences of failure are different. A poorly governed AI system can create biased credit outcomes, false fraud alerts, customer harm, weak AML detection, incorrect risk classification, unmanaged cyber exposure, regulatory reporting errors or over-reliance on a third-party model. In a consumer app, poor AI output may create reputational risk. In a bank, it may affect clients, capital, conduct, resilience and supervisory trust.
2. 2The regulatory stack is different. The EU AI Act introduces horizontal rules for AI systems, including high-risk AI requirements. DORA introduces a binding framework for digital operational resilience in the financial sector. GDPR remains central whenever personal data, profiling or automated decision-making is involved. Banking regulation already requires robust internal governance, risk management, outsourcing oversight and model control. AI does not replace any of those frameworks. It intersects with all of them.
3. 3The operating environment is different. Most large banks run complex technology estates with legacy systems, fragmented data ownership, multiple cloud providers, outsourced development, regional platforms, local regulatory requirements and overlapping control functions. AI governance therefore cannot be designed as a clean academic framework. It must work inside a messy enterprise reality.
4. 4The accountability model is different. In banking, nobody credible should say: “The model made the decision.” Management remains accountable. The board remains accountable for oversight. Risk and compliance remain accountable for challenge. Technology remains accountable for secure and resilient implementation. Business remains accountable for the use case and its outcomes. AI governance must make that accountability visible before the model goes live, not after something has gone wrong.

A practical AI governance model should therefore start with a simple principle: every material AI use case must have a clearly accountable owner, a documented purpose, a defined risk classification, approved data sources, technical and business controls, human oversight where required, monitoring arrangements and a clear path for escalation.

That sounds obvious. In practice, it is difficult.

The difficulty is not that banks lack control functions. The difficulty is that AI cuts across them. Data governance may own data quality. Technology may own platforms. Cyber may own security controls. Risk may own model risk. Compliance may own regulatory interpretation. Legal may own contractual and liability issues. Procurement may own third-party onboarding. Audit may own independent assurance. The business may own the use case. The board may ask for progress. Without an integrated AI governance model, each function sees only part of the risk.

AI governance is the discipline that brings those parts together.

ai-governance-in-banking-2.jpg16:9 · /insights/img/

2The EU AI Act: A Governance Trigger, Not a Standalone Framework

The EU AI Act is often discussed as if it were the whole AI governance story. It is not. It is a major trigger, but not the entire framework.

For banks, the AI Act is particularly relevant because certain financial services use cases can fall into the high-risk category. The most obvious example is creditworthiness assessment. Under Annex III of the AI Act, AI systems used to evaluate the creditworthiness of natural persons or establish their credit score are classified as high-risk, except where the system is used for detecting financial fraud. That exception is important because it shows that classification depends not only on the technology, but also on the purpose and context of use.

This is where practical governance starts.

A bank cannot simply ask whether a tool is “AI”. That is only the first question. It must ask what the system does, who is affected, whether it supports or makes a decision, whether the decision produces legal or similarly significant effects, whether the use case is linked to high-risk categories, whether personal data is processed, whether the model is internally developed or provided by a third party, and whether the system is used in a regulated banking process.

A model used for internal productivity may require one governance path. A model used for customer segmentation may require another. A model used for creditworthiness, collections, fraud detection, AML alert prioritisation or regulatory reporting may require a much higher standard of evidence. The technology may look similar. The governance obligation is not.

The AI Act reinforces requirements that serious banks should already recognise: risk management, data governance, technical documentation, record-keeping, transparency, human oversight, accuracy, robustness and cybersecurity. These are not abstract legal concepts. They map directly into banking control disciplines. Risk management connects to risk appetite and control assessment. Data governance connects to lineage, quality and authorised use. Documentation connects to auditability. Record-keeping connects to evidence. Human oversight connects to accountability. Robustness and cybersecurity connect to technology resilience.

That is why the AI Act should not be implemented as a separate compliance silo. If a bank creates a standalone AI Act project that is disconnected from technology governance, data governance, model risk management, DORA, GDPR and outsourcing oversight, it will create duplication and confusion. The more strategic approach is to use the AI Act as a forcing mechanism to strengthen the bank’s enterprise AI governance model.

The EBA’s AI Act mapping work is relevant here because it assessed the implications of the AI Act for the EU banking and payments sector, with particular attention to high-risk AI systems such as creditworthiness and credit scoring. The important message for banks is that AI Act readiness should not be treated as a parallel universe. It has to be mapped against existing sectoral obligations and supervisory expectations.

In practical terms, every bank should build an AI use-case inventory that does more than list tools. It should classify purpose, user group, affected population, decision impact, data category, model type, development source, third-party dependency, operational criticality, regulatory relevance and control status. Without that inventory, senior management cannot know where the AI risk is. Without knowing where the AI risk is, it cannot govern it.

3Digital Omnibus Update: The Timeline Changed, Accountability Did Not

As of 29 June 2026, the Council of the European Union has given final approval to targeted simplification measures for the AI Act. According to the Council communication, the application of high-risk obligations moves to 2 December 2027 for stand-alone high-risk AI systems and to 2 August 2028 for AI systems embedded in products. I cannot confirm from the sources available here whether the final amending regulation has already been published in the Official Journal of the European Union.

For banks, this changes implementation planning, but not the governance logic.

The additional time should not be used to postpone AI governance. It should be used to build the inventory, classification logic, data controls, model-risk approach, third-party oversight and board reporting that scalable AI requires anyway. The deadline may move. Accountability does not.

This matters because AI adoption does not wait for legal deadlines. Banks are already deploying AI in customer interaction, fraud detection, credit processes, internal productivity, software engineering and risk analytics. If governance waits until the last possible legal date, the bank will spend the next years accumulating unclassified, undocumented and poorly controlled AI exposure.

A serious bank should therefore use the changed timeline as a planning advantage, not as an excuse for delay. The right question is not: “How late can we comply?” The right question is: “How early can we build a reusable governance model that makes compliant scaling easier?”

That is the strategic difference between deadline management and controlled execution.

4DORA: AI Governance Meets Operational Resilience

AI governance discussions often focus on fairness, explainability and model risk. Those topics matter. But for banks, they are not enough.

DORA makes the technology reality unavoidable. Regulation (EU) 2022/2554 establishes an EU-wide framework for digital operational resilience in the financial sector, including ICT risk management, incident reporting, operational resilience testing and ICT third-party risk. That matters directly for AI because AI systems increasingly depend on cloud infrastructure, APIs, model services, external data providers, outsourced development and technology vendors.

A bank may think it is implementing a customer service chatbot. From a governance perspective, it may be introducing a new data flow, a new vendor dependency, a new access-control problem, a new monitoring requirement, a new operational risk scenario and a new incident-management path. If the chatbot uses generative AI, the bank must also consider hallucination risk, prompt injection, confidential data leakage, inadequate logging, poor explainability, model drift and dependency on the provider’s model updates.

This is why AI governance cannot sit outside operational resilience.

A serious AI governance framework in banking must ask DORA-type questions from the beginning. Is the AI system supporting an important business service? Does it depend on a critical ICT third-party provider? What happens if the model service is unavailable? What happens if outputs degrade? What happens if the vendor changes the model? What happens if the system produces harmful or misleading output at scale? What happens if sensitive data is exposed through prompts, embeddings, logs or model outputs? Who detects it? Who decides whether it is an ICT incident, a data incident, a model issue, a conduct issue or all of them?

These questions define whether AI is production-ready.

DORA also changes the relationship between AI innovation and third-party risk. Many AI capabilities will not be built entirely inside the bank. They will come through cloud providers, AI platforms, software vendors, data providers, analytics tools and specialist model services. That is not automatically a problem. But it means AI governance must be embedded into procurement, outsourcing assessment, ICT risk classification, contract clauses, exit planning, service monitoring and concentration-risk analysis.

A bank that treats AI vendor selection as a normal software purchase will miss the point. The issue is not only whether the tool works. The issue is whether the bank can control, monitor, explain, challenge, exit and evidence the use of that tool in a regulated environment.

This is where governance becomes practical. The AI approval process should not begin after procurement has selected the vendor. It should begin before the bank commits to an architecture, a data-sharing model or a contractual dependency that later becomes impossible to unwind.

5GDPR and Automated Decision-Making

AI governance in banking is impossible without data protection governance.

GDPR remains central because many banking AI use cases involve personal data, profiling or decisions that may significantly affect individuals. Article 22 of GDPR gives individuals the right not to be subject to a decision based solely on automated processing, including profiling, where that decision produces legal effects or similarly significant effects, subject to specific exceptions and safeguards. This is directly relevant when AI is used in credit, pricing, collections, customer vulnerability, fraud controls or other decision processes affecting clients.

But GDPR is not only about automated decisions. It is also about lawful basis, purpose limitation, data minimisation, transparency, accuracy, storage limitation, integrity, confidentiality and accountability. Those principles are not obstacles to AI governance. They are part of AI governance.

The EDPB’s Opinion 28/2024 is important because it addresses data protection aspects related to AI models, including when and how an AI model may be considered anonymous, how legitimate interest may be assessed as a legal basis in development and deployment, and what consequences may follow from unlawful processing in the development phase. For banks, this is especially relevant because data lineage and lawful data use are not abstract privacy questions. They determine whether the bank can defend the model lifecycle.

The practical implication is clear: AI governance must connect model approval to data approval.

A model should not be approved simply because it performs well statistically. It must also be clear which data was used, whether the bank has the right to use it for the intended purpose, whether personal data is involved, whether sensitive or protected characteristics are present directly or indirectly, whether proxies may create bias, whether data quality is sufficient, whether retention periods are defined, and whether the use of outputs is transparent to affected individuals where required.

This is particularly important for generative AI and large language models. Many banks started with internal productivity use cases because they appeared lower risk. But even internal tools can process confidential information, personal data, client data, code, incident records, HR material, risk reports or supervisory documents. If employees paste sensitive information into an AI tool without proper controls, the bank may create privacy, confidentiality, intellectual property, security and regulatory issues before any external customer use case exists.

This is why acceptable-use policies are not enough. Banks need technical guardrails, logging, access controls, data-loss prevention, training, monitoring and clear consequences for misuse. More importantly, they need usable approved alternatives. If the official AI environment is too slow, too restrictive or too disconnected from how employees work, shadow AI will emerge.

Shadow AI is not an innovation strategy. It is a control failure.

6Model Risk Management and Generative AI

AI governance in banking must be built on model risk management, but it cannot be limited to traditional model risk management.

Banks already understand model governance in areas such as credit risk, market risk, liquidity risk, capital models, stress testing and IFRS 9. They know the importance of validation, documentation, monitoring, limitations, change control and independent challenge. But AI introduces additional complexity: non-linear model behaviour, data dependency, reduced interpretability, continuous learning possibilities, dependency on external model providers and new forms of output risk.

The EBA’s follow-up report on machine learning for IRB models is useful because it shows how prudential requirements, GDPR and the AI Act intersect when machine learning is used in credit risk models. The ECB’s revised Guide to internal models also clarifies supervisory expectations around the use of machine learning techniques in internal models. These are not generic AI ethics documents. They are banking-specific supervisory materials that matter for serious AI governance.

The practical lesson is that banks need a tiered model governance approach. Not every AI system should go through the same validation process as an IRB model. That would be unworkable. But not every AI system can be treated as a simple software feature either. The governance framework must classify models based on materiality, use case, regulatory relevance, decision impact, complexity, data sensitivity, explainability needs, operational dependency and potential harm.

A low-risk internal summarisation tool may require controlled access, data restrictions, logging and acceptable-use monitoring. A model used for AML alert prioritisation may require stronger validation, explainability, bias assessment, performance monitoring and operational back-testing. A creditworthiness model may require a much more formal governance path because it can directly affect access to financial resources and may fall into a high-risk AI category.

Model risk management also needs to evolve for generative AI. Traditional validation asks whether the model performs against defined metrics on defined data. Generative AI adds questions that are harder to reduce to a single score. Does the system hallucinate? Does it produce plausible but wrong output? Does it leak confidential information? Is it vulnerable to prompt injection? Does it generate discriminatory or misleading responses? Does it behave differently across languages? Does it degrade when the provider updates the model? Can the bank reproduce outputs? Can the bank explain why a response was generated? Does the use case require deterministic behaviour, or is probabilistic output acceptable?

These questions must be answered before deployment, not after an incident.

AI governance must define what “good enough” means for each class of AI use case. If the bank cannot define acceptance criteria, it cannot govern the system. If it cannot govern the system, it should not scale it.

ai-governance-in-banking-3.jpg16:9 · /insights/img/

7The AI Inventory: The Most Underrated Governance Tool

The most important AI governance artefact in a bank is not the policy. It is the inventory.

Without an AI inventory, the bank cannot know its exposure. Without knowing its exposure, it cannot classify risk. Without risk classification, it cannot apply proportionate controls. Without proportionate controls, it either over-controls low-risk use cases or under-controls material ones.

A serious AI inventory should include at least the following dimensions: use-case owner, business process, legal entity, jurisdiction, user group, affected population, model type, provider, data sources, personal-data involvement, decision impact, materiality, AI Act classification, GDPR relevance, DORA relevance, outsourcing relevance, model-risk classification, validation status, monitoring metrics, incidents, limitations, residual risk and retirement status.

The inventory must also capture AI that is embedded in vendor products. This is easy to miss. Banks may not think they are deploying AI when they buy software with built-in AI functionality. But from a governance perspective, embedded AI can still affect processes, decisions, data flows and operational dependencies. Vendor AI is not outside the bank’s responsibility simply because the model sits inside a third-party product.

The inventory should also separate experimentation from production. A proof of concept in a sandbox is not the same as a tool used by hundreds of employees or a model affecting customer outcomes. But pilots need governance too. They need boundaries: approved data, approved environments, time limits, exit criteria and rules for moving into production.

The move from pilot to production is one of the highest-risk moments in AI governance. Many failures happen because a use case that started informally becomes operational without passing through a proper control gate. A demo becomes a workflow. A workflow becomes a dependency. A dependency becomes a control issue.

AI governance must make that transition visible.

8Human Oversight Beyond the Checkbox

Human oversight is one of the most repeated concepts in AI governance. It is also one of the most misunderstood.

A bank should not claim meaningful human oversight simply because a person is somewhere near the process. Human oversight must be designed. The human reviewer must understand the purpose of the AI system, the limitations of the model, the decision context, the escalation criteria and the circumstances under which the AI output should be challenged or overridden.

This is especially important in banking because employees may over-trust AI outputs when those outputs look precise, technical or confident. A credit recommendation, fraud score, AML prioritisation, customer-risk summary or regulatory-reporting anomaly may appear objective because it is generated by a model. But model output is not truth. It is a structured estimate produced under assumptions, data limitations and design choices.

Human oversight must therefore be linked to training, process design, decision rights and accountability. Who can override the AI system? When must they override it? What evidence is required? Are overrides monitored? Are patterns of overrides reviewed? Is the human reviewer sufficiently independent? Is there a risk of automation bias? Does the process allow enough time for real review, or is the human merely rubber-stamping the model?

It is easy to write “human in the loop” in a policy. It is much harder to design a process where the human actually has the competence, authority and time to challenge the machine.

For high-impact banking use cases, that difference is decisive.

9Explainability: Not Every Model Needs the Same Explanation

Explainability is another area where banks need practical discipline.

Not every AI system requires the same level of explanation. A model used to route internal service tickets does not require the same explainability as a model used to support creditworthiness assessment. A generative AI assistant summarising internal policies does not require the same explanation standard as a model used in risk classification. But every material AI system needs an explanation standard appropriate to its use.

Explainability should be defined by audience and purpose. A data scientist may need technical explanation. A model validator may need performance drivers, limitations and sensitivity analysis. A business user may need reason codes and decision logic. A customer may need understandable information about how a decision affecting them was made. A supervisor may need evidence that the bank understands, controls and monitors the system.

A single explanation method will not satisfy all these needs.

For banks, explainability must connect to accountability. If nobody can explain the model well enough to challenge it, the bank should be cautious about deploying it in material decision processes. That does not mean only simple models can be used. It means the bank must be able to justify why a model is appropriate for the use case, how its limitations are controlled, how outputs are monitored and how affected stakeholders are protected.

The BIS Financial Stability Institute has identified AI regulation in financial services as an area of active supervisory development, including model risk, data privacy, explainability and generative-AI-specific risks such as hallucination.

The right question is not: “Can we explain the model perfectly?” The right question is: “Can we explain it sufficiently for the decision it supports and the risk it creates?”

10Third-Party AI and Embedded Vendor AI

Third-party AI will be one of the hardest governance challenges for banks.

Many banks will rely on external providers for foundation models, cloud infrastructure, AI platforms, vendor applications, data services, monitoring tools and specialist analytics. This is rational. No bank should assume it can build every AI capability internally. But the use of third parties does not transfer accountability away from the bank.

The Financial Stability Board has identified third-party dependencies, market correlations, cyber risks, and challenges in model risk and governance as AI-related vulnerabilities with potential financial stability implications. That is highly relevant for banks because AI adoption may concentrate dependencies on a small number of technology and cloud providers.

From a governance perspective, third-party AI creates several questions.

Does the bank know whether the vendor product includes AI? Does the contract allow the bank to understand the model’s role, limitations and update cycle? Can the bank restrict data use? Can it prevent the vendor from using bank data for training? Are logs available? Can the bank test outputs? Does the vendor provide sufficient documentation? What happens when the vendor changes the model? What happens if the provider withdraws the service? Is there an exit plan? Are there concentration risks across the bank? Are multiple critical processes dependent on the same provider?

These questions should not be asked only for critical outsourcing arrangements. They should be part of AI vendor governance more broadly, with proportionality based on materiality.

Procurement teams need AI literacy. Legal teams need AI-specific contractual positions. Technology teams need architecture standards. Risk teams need vendor-risk classification. Business teams need to understand that buying AI is not the same as buying ordinary software.

The most dangerous AI vendor risk is not always the most visible one. Sometimes it is the AI functionality hidden inside a platform the bank already uses. A vendor introduces a new AI feature. A business team switches it on. Data begins to move. Outputs enter a workflow. Nobody updates the inventory. Nobody assesses the risk. Nobody informs the board.

That is how shadow AI becomes institutional risk.

11Business Value and the Kill Mechanism

AI governance should not be designed only around risk. That would be incomplete.

Banks need AI because they need better productivity, better customer experience, stronger fraud detection, faster software delivery, improved risk analytics, more efficient controls and better use of data. A governance model that only blocks AI will fail. It will push innovation into informal channels or make the bank strategically slower.

The right governance model must connect risk control with value creation.

Every material AI use case should have a business case. What problem does it solve? What process does it improve? What cost does it reduce? What risk does it mitigate? What customer outcome does it improve? What control weakness does it address? What metric will prove that the use case is working?

Without that discipline, AI becomes theatre.

Banks are especially vulnerable to AI theatre because executive pressure is high. Every institution wants to show that it is active in AI. Every function wants a use case. Every vendor claims AI capability. Every strategy presentation includes a slide on generative AI. But activity is not transformation.

A bank with fifty pilots and no scalable control model is not ahead. It is exposed.

A bank with fewer use cases, but a clear platform, governed data pipelines, reusable approval paths, measurable benefits and controlled production deployment may be in a much stronger position. The objective is not to maximise the number of AI experiments. The objective is to operationalise AI where it creates value and can be controlled.

This is why AI governance should include a kill mechanism. Not every AI use case should survive. If a use case does not create measurable value, cannot be controlled, duplicates existing capabilities, increases complexity or creates disproportionate risk, it should be stopped. Mature governance is not only about approval. It is also about termination.

ai-governance-in-banking-4.jpg16:9 · /insights/img/

12AI Governance as an Enterprise Capability

The banks that will scale AI successfully will treat AI governance as an enterprise capability.

That means the bank has one common AI taxonomy. It knows what counts as AI, what counts as generative AI, what counts as a model, what counts as high impact, what counts as production use and what counts as prohibited or restricted use.

It means the bank has one controlled inventory. Not ten spreadsheets. Not scattered registers across risk, technology, data and compliance. One reliable view of AI adoption and risk.

It means the bank has risk-based approval pathways. Low-risk productivity tools move through a proportionate process. High-impact decision systems receive deeper review. Third-party AI is assessed before adoption. Material changes trigger re-approval.

It means the bank has an AI control library. Data controls, access controls, logging, monitoring, bias testing, explainability, cyber testing, vendor controls, incident triggers and human oversight are not reinvented for every use case.

It means the bank has AI literacy at multiple levels. Board members need enough understanding to challenge management. Senior executives need enough understanding to own decisions. Control functions need enough understanding to assess risk. Employees need enough understanding to use tools safely.

It means the bank has metrics. AI governance without metrics becomes narrative. The bank should track AI use cases by status, risk class, business line, legal entity, provider, control maturity, issues, incidents, value delivered and audit findings.

It means the bank has assurance. Internal audit should not wait until AI has already scaled informally. It should test the governance framework, inventory completeness, control design, approval evidence, monitoring and issue remediation.

It means the bank has a management rhythm. AI governance should be reviewed regularly by the appropriate executive forum, escalated to the board where material, and connected to strategy, technology investment and risk appetite.

External frameworks can support this work. ISO/IEC 42001:2023 specifies requirements and guidance for establishing, implementing, maintaining and continually improving an AI management system. NIST’s AI Risk Management Framework and Generative AI Profile provide a structured reference for AI risk management, including generative AI risks.

But a bank should not mistake framework alignment for regulatory readiness. ISO and NIST can support the management system, but they do not replace the EU AI Act, DORA, GDPR, EBA expectations, ECB supervision, internal governance obligations or local regulatory requirements.

The best approach is to use external frameworks as scaffolding, not as the building itself.

13What Boards Should Ask Now

Boards and senior executives should not wait for a perfect AI governance framework before asking better questions. They can start now.

• They should ask: do we have a complete AI inventory, including third-party and embedded AI?
• They should ask: which AI use cases could materially affect customers, employees, risk decisions, financial crime controls, regulatory reporting, capital or operational resilience?
• They should ask: which AI systems may fall into high-risk categories under the EU AI Act, and what evidence supports that classification?
• They should ask: how does AI governance connect to DORA, GDPR, outsourcing, model risk management and internal governance?
• They should ask: who owns each material AI system end to end?
• They should ask: can management evidence data quality, lawful data use, model performance, human oversight, monitoring and issue management?
• They should ask: which third-party AI dependencies are emerging, and where concentration risk could arise?
• They should ask: where is generative AI already used by employees, and how is shadow AI prevented?
• They should ask: what measurable value has AI delivered, and which use cases should be stopped?
• They should ask: when will internal audit review the AI governance framework?

These questions are not designed to slow down AI. They are designed to make AI real.

14Conclusion

AI governance in banking is often misunderstood. It is treated as a regulatory burden, a compliance checklist or a defensive control layer. That view is too limited.

In a European bank, AI governance is the mechanism that allows AI to scale without undermining accountability, resilience, data protection, model control or supervisory trust.

The institutions that fail will not necessarily be those that move slowly. Some will move quickly but without control. Others will build complex governance documents that do not change decision-making. Both approaches will stall.

The institutions that succeed will do something harder. They will connect AI strategy to the operating model of the bank. They will know where AI is used. They will classify risk consistently. They will govern data and models together. They will control third-party dependencies. They will make human oversight meaningful. They will provide boards with evidence, not slogans. They will stop weak use cases and scale strong ones.

That is the difference between AI experimentation and AI transformation.

A bank can buy AI tools. It can buy cloud platforms. It can buy model access. It can buy consulting support. But it cannot buy accountability. It cannot outsource judgement. It cannot delegate trust.

AI governance in banking is therefore not the administrative side of AI. It is the leadership discipline that determines whether AI becomes a controlled enterprise capability or another layer of unmanaged complexity.

The next competitive divide in European banking will not be between banks that use AI and banks that do not. Almost all serious institutions will use it. The divide will be between banks that can govern AI at scale and banks that remain trapped between innovation theatre and supervisory discomfort.

AI governance is where that divide will become visible.

15Sources

The factual and regulatory basis for this article includes: the EU AI Act and its high-risk classification logic, including Annex III; the Council’s 29 June 2026 communication on AI Act simplification and revised high-risk timelines; DORA and its ICT-risk and third-party-risk framework; GDPR, including automated decision-making under Article 22; EDPB Opinion 28/2024 on AI models and personal data; EBA material on AI adoption and AI Act implications for banking and payments; ECB material on internal models and machine learning; FSB material on AI-related financial stability vulnerabilities; BIS/FSI work on AI regulation in financial services; ISO/IEC 42001:2023; and the NIST AI Risk Management Framework and Generative AI Profile.