AI governance in banking

Governance starts with a decision at the top, written down. BaFin published guidance on ICT risks in the use of AI systems in December 2025 and asks for an AI strategy with responsibilities that can be named, derived from the business and IT strategy that MaRisk already requires. The point of the document is that nobody later has to reconstruct who approved a use case.

The strategy fixes three things the rest of the structure depends on: which uses the firm allows and which it rules out, which risk tier a use case falls into, and which committee decides a case that sits on the boundary. A firm with no such boundary ends up deciding each case in the project that proposed it.

The AI Act splits the duties by role. A provider of a high-risk system runs a quality management system under Article 17 of Regulation (EU) 2024/1689, covering the design process, the data governance, the testing and the post-market monitoring. A deployer, which is what most banks are when they buy a system, carries Article 26: use the system as the instructions say, assign human oversight to people with the competence and the authority for it, keep the logs, and inform workers before an AI system is used on them.

A bank that fine-tunes a purchased model or puts its own name on it can become a provider for that system, which moves the heavier set of duties to the bank. The role is therefore assessed per system and recorded in the AI and model inventory, not assumed once for the whole firm.

Since February 2, 2025 providers and deployers have had to take measures so that the people operating AI systems on their behalf have a sufficient level of AI literacy, under Article 4 of the AI Act. The duty applies to every firm using AI, whatever risk tier the system sits in, and it covers contractors working on the firm's behalf as well as employees.

What satisfies it depends on the role. A credit officer who reads a score needs to know what the model does not see; a developer needs the technical limits; a board member needs enough to challenge a proposal. A single company-wide e-learning module recorded as a completion rate is the version that tends not to survive a supervisory question.

Article 14 of the AI Act requires a high-risk system to be built so that natural persons can oversee it: they have to be able to understand its capacities and limits, stay aware of the tendency to over-rely on its output, interpret the result correctly, decide not to use it in a given case, and intervene or stop it.

In a bank this becomes a named role with a documented route. The person who may stop a scoring model mid-day is named in the model record, the technical means to do it exists and has been tested, and the decision is logged. Oversight that exists only as a sentence in a policy fails the first time a model starts refusing applications it should approve.

Two controls run before a high-risk system goes live and keep running after it. Bias testing compares outcomes across the groups protected by the General Equal Treatment Act, and the AI Act requires the training, validation and testing data sets for a high-risk system to be examined for possible biases under Article 10. A proxy is the trap: a model with no protected attribute in its feature set can still reproduce the effect through a postal code or a job title.

Data lineage answers the other question an auditor asks: where did the training data come from, what was changed on the way, and may the bank use it for this purpose. A system whose provider cannot name the training sources leaves the deployer unable to answer, which is a procurement decision and not a technical one. The inventory record carries both the lineage and the date of the last bias test.

A model returns a prediction; an agent takes an action, querying data, calling tools and starting a workflow, sometimes with nobody in the loop. The governance difference is the blast radius, so banks grade use cases by how much the system may do on its own: assistive, where a person decides and the system suggests; delegated, where the system prepares an action a person approves; and autonomous, where the system acts and a person monitors.

Each level carries its own controls. An autonomous agent needs a bounded set of actions it is authorized to take, a logged record of each one, a limit it cannot exceed without a human, and a tested way to stop it. Approving an agent at the level a prediction model was approved at is the mistake that produces an incident with no owner.

Many German institutions map their controls onto the NIST AI Risk Management Framework, NIST AI 100-1, which is voluntary and organizes the work into the four functions govern, map, measure and manage. It is not EU law and satisfies no AI Act obligation on its own.

Its use in practice is as a checklist against the firm's own control set, because it was written independently of any one regulator and covers the lifecycle in more detail than the Act does. The mapping document, showing which AI Act article and which MaRisk requirement each control answers, is the artifact an auditor asks for.

German co-determination law reaches AI before the AI Act does. Under section 87(1) number 6 of the Betriebsverfassungsgesetz the works council has a co-determination right on the introduction and use of technical devices designed to monitor the behavior or performance of employees, and a system that scores applications, ranks sales performance or flags communications falls under it.

Since the 2021 Betriebsrätemodernisierungsgesetz the works council may also bring in an expert when it assesses AI, and the employer carries the cost. Planning the agreement with the works council alongside the technical project is the part that decides the go-live date; running the project first and the agreement afterwards is how a finished system waits.

For insurers the same question has its own supervisory text. EIOPA issued an opinion on artificial intelligence governance and risk management in August 2025, which reads the existing Solvency II and IDD requirements as already covering AI and asks for governance proportionate to the risk of each use case, with fairness and explainability addressed where a system affects a customer outcome.

EIOPA has its seat in Frankfurt, so the authority writing these expectations for the insurance sector and the firms applying them often meet in the same city. AI in insurance covers the use cases behind the rules.

AI governance in banking is the internal structure that makes an AI system someone's responsibility: a management-approved AI strategy, a named owner and risk tier per system, human oversight with the authority to stop it, AI literacy for the staff who operate it, a complete inventory, and a route from a model failure to the management body. The duties come from the EU AI Act and, for ICT risk, from BaFin's guidance under DORA.

The management body carries the overall responsibility, as it does for ICT risk under DORA, and it cannot delegate that away. Below it a bank names a model or system owner in the first line, who answers for the use case and its data, with the second line validating and the internal audit function reviewing both. The person exercising human oversight under Article 14 of the AI Act is named separately, because stopping a system and owning it are different jobs.

No law requires a committee with that name. What the rules require is a decision point that can approve or refuse a use case against the firm's AI strategy, and a record of what it decided. Banks that build one usually seat risk, compliance, IT security, data protection and the business in it, and give it the mandate to place a use case in a risk tier, which is the decision that drives every control after it.