KI-Governance im Bankwesen: Das Operating Model für kontrollierte KI-Skalierung

Executive Summary

1Warum KI-Governance im Bankwesen anders ist

Künstliche Intelligenz im Bankwesen ist kein Zukunftsthema mehr. Sie hält bereits Einzug in Kreditrisiko, Betrugserkennung, AML, Kundenservice, Softwareentwicklung, regulatorisches Reporting, Cyber Defence, operationale Resilienz und interne Produktivität. Die European Banking Authority berichtete 2025, dass der KI-Einsatz im EU-Banken- und Zahlungsverkehrssektor deutlich über die Diskussionsphase hinaus ist: 92% der EU-Banken setzen KI bereits ein, während die übrigen 8% KI-Use-Cases pilotieren oder diskutieren. Damit verändert sich die Governance-Frage vollständig. KI-Governance im Bankwesen kann nicht länger als Ethik-Zusatz, Modellvalidierungsanhang oder Policy-Dokument eines Spezialistenteams behandelt werden. Sie wird Teil des Managementsystems der Bank.

Der zentrale Punkt lautet: KI-Governance soll KI nicht verlangsamen. Sie soll KI in einem beaufsichtigten Institut skalierbar machen.

Viele Banken betrachten KI-Governance noch immer als Compliance-Übung. Das ist nachvollziehbar, aber strategisch zu eng. In Europa spielen EU AI Act, DORA, GDPR, Outsourcing-Regeln, Model-Risk-Erwartungen, Internal-Governance-Anforderungen und die Prioritäten der ECB Banking Supervision eine Rolle. Doch die eigentliche Herausforderung besteht nicht darin, regulatorische Referenzen zu sammeln. Die eigentliche Herausforderung besteht darin, sie in ein Operating Model zu übersetzen, mit dem eine Bank KI-Systeme über Business, Technology, Risk, Compliance, Data, Cyber, Legal, Audit und Board hinweg identifizieren, genehmigen, ausrollen, überwachen und challengen kann.

Genau hier scheitern viele KI-Governance-Frameworks. Sie sehen auf Papier vollständig aus, verändern aber nicht, wie Entscheidungen getroffen werden.

Eine Bank kann eine KI-Policy veröffentlichen. Sie kann ein AI Committee gründen. Sie kann einen AI Officer ernennen. Sie kann Impact Assessments, Modelldokumentation, Datenqualitätsprüfungen und Human Oversight verlangen. Nichts davon ist falsch. Aber wenn diese Elemente nicht mit Investitionsentscheidungen, Architekturstandards, Risk Appetite, Vendor Onboarding, Change Governance, Incident Management und Board Reporting verbunden sind, hat die Bank keine KI-Governance. Sie hat KI-Papier.

Der Unterschied ist wichtig, weil Banking kein normales Technologieumfeld ist. Banken verarbeiten nicht einfach Daten. Sie vergeben Kredit, verwalten Einlagen, erkennen Finanzkriminalität, berechnen Kapital, sichern Zahlungsverkehr, verarbeiten hochsensible personenbezogene Daten und betreiben kritische wirtschaftliche Infrastruktur. Wenn KI in diese Prozesse eingebettet wird, wird sie Teil der Kontrollumgebung des Instituts. Die Frage lautet deshalb nicht, ob KI innovativ ist. Die Frage lautet, ob sie als Teil der Bank gesteuert wird.

KI-Governance im Bankwesen ist aus vier Gründen anders.

1. 1Die Folgen von Fehlern sind anders. Ein schlecht gesteuertes KI-System kann verzerrte Kreditentscheidungen, falsche Fraud Alerts, Kundenschäden, schwache AML-Erkennung, falsche Risikoklassifizierung, unkontrollierte Cyber-Exposure, Fehler im regulatorischen Reporting oder Überabhängigkeit von einem Drittanbieter-Modell erzeugen. In einer Consumer App kann schlechter KI-Output Reputationsrisiko erzeugen. In einer Bank kann er Kunden, Kapital, Conduct, Resilienz und aufsichtliches Vertrauen betreffen.
2. 2Der regulatorische Stack ist anders. Der EU AI Act führt horizontale Regeln für KI-Systeme ein, einschließlich Anforderungen an Hochrisiko-KI. DORA schafft einen verbindlichen Rahmen für digitale operationale Resilienz im Finanzsektor. GDPR bleibt zentral, sobald personenbezogene Daten, Profiling oder automatisierte Entscheidungen betroffen sind. Bankenregulierung verlangt bereits robuste Internal Governance, Risikomanagement, Outsourcing Oversight und Modellkontrolle. KI ersetzt keinen dieser Rahmen. KI schneidet sie alle.
3. 3Die operative Umgebung ist anders. Große Banken betreiben komplexe Technologielandschaften mit Legacy-Systemen, fragmentierter Data Ownership, mehreren Cloud-Anbietern, ausgelagerter Entwicklung, regionalen Plattformen, lokalen regulatorischen Anforderungen und überlappenden Kontrollfunktionen. KI-Governance kann daher nicht als sauberes akademisches Framework entworfen werden. Sie muss in der Realität eines komplexen Unternehmens funktionieren.
4. 4Das Accountability-Modell ist anders. Im Bankwesen sollte niemand glaubwürdig sagen: „Das Modell hat entschieden.“ Das Management bleibt verantwortlich. Das Board bleibt für Oversight verantwortlich. Risk und Compliance bleiben für Challenge verantwortlich. Technology bleibt für sichere und resiliente Implementierung verantwortlich. Das Business bleibt für Use Case und Ergebnis verantwortlich. KI-Governance muss diese Verantwortlichkeit sichtbar machen, bevor das Modell live geht — nicht erst nach einem Vorfall.

Ein praktisches KI-Governance-Modell sollte deshalb mit einem einfachen Prinzip beginnen: Jeder materielle KI-Use-Case braucht einen klar verantwortlichen Owner, einen dokumentierten Zweck, eine definierte Risikoklassifizierung, freigegebene Datenquellen, technische und fachliche Kontrollen, Human Oversight wo erforderlich, Monitoring und einen klaren Eskalationspfad.

Das klingt selbstverständlich. In der Praxis ist es schwierig.

Die Schwierigkeit besteht nicht darin, dass Banken keine Kontrollfunktionen hätten. Die Schwierigkeit besteht darin, dass KI quer durch diese Funktionen läuft. Data Governance mag Datenqualität verantworten. Technology mag Plattformen verantworten. Cyber mag Security Controls verantworten. Risk mag Model Risk verantworten. Compliance mag regulatorische Interpretation verantworten. Legal mag Vertrags- und Haftungsthemen verantworten. Procurement mag Third-Party Onboarding verantworten. Audit mag unabhängige Assurance verantworten. Das Business mag den Use Case verantworten. Das Board mag Fortschritt verlangen. Ohne integriertes KI-Governance-Modell sieht jede Funktion nur einen Teil des Risikos.

KI-Governance ist die Disziplin, die diese Teile zusammenführt.

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

2Der EU AI Act: Governance-Trigger, kein alleinstehendes Framework

Der EU AI Act wird häufig so diskutiert, als wäre er die gesamte KI-Governance. Das ist er nicht. Er ist ein wichtiger Trigger, aber nicht das ganze Framework.

Für Banken ist der AI Act besonders relevant, weil bestimmte Finanzdienstleistungs-Use-Cases in die Hochrisiko-Kategorie fallen können. Das offensichtlichste Beispiel ist die Bewertung der Kreditwürdigkeit. Nach Annex III des AI Act werden KI-Systeme, die zur Bewertung der Kreditwürdigkeit natürlicher Personen oder zur Erstellung ihres Credit Scores eingesetzt werden, als Hochrisiko-Systeme klassifiziert — außer wenn das System zur Erkennung finanziellen Betrugs eingesetzt wird. Diese Ausnahme ist wichtig, weil sie zeigt, dass die Klassifizierung nicht nur von der Technologie abhängt, sondern vom Zweck und Kontext der Nutzung.

Hier beginnt praktische Governance.

Eine Bank darf nicht nur fragen, ob ein Tool „KI“ ist. Das ist lediglich die erste Frage. Sie muss fragen, was das System tut, wer betroffen ist, ob es eine Entscheidung unterstützt oder trifft, ob die Entscheidung rechtliche oder ähnlich erhebliche Wirkung entfaltet, ob der Use Case mit Hochrisiko-Kategorien verbunden ist, ob personenbezogene Daten verarbeitet werden, ob das Modell intern entwickelt oder von einem Drittanbieter bereitgestellt wird und ob das System in einem regulierten Bankprozess eingesetzt wird.

Ein Modell für interne Produktivität kann einen Governance-Pfad benötigen. Ein Modell für Kundensegmentierung kann einen anderen benötigen. Ein Modell für Kreditwürdigkeit, Collections, Fraud Detection, AML-Alert-Priorisierung oder regulatorisches Reporting kann einen deutlich höheren Evidenzstandard erfordern. Die Technologie mag ähnlich aussehen. Die Governance-Pflicht ist es nicht.

Der AI Act verstärkt Anforderungen, die ernsthafte Banken bereits kennen sollten: Risikomanagement, Data Governance, technische Dokumentation, Aufzeichnungspflichten, Transparenz, Human Oversight, Genauigkeit, Robustheit und Cybersecurity. Das sind keine abstrakten Rechtsbegriffe. Sie lassen sich direkt auf Bankkontrollen abbilden. Risikomanagement verbindet sich mit Risk Appetite und Control Assessment. Data Governance verbindet sich mit Lineage, Qualität und autorisierter Nutzung. Dokumentation verbindet sich mit Auditierbarkeit. Aufzeichnungen verbinden sich mit Evidenz. Human Oversight verbindet sich mit Accountability. Robustheit und Cybersecurity verbinden sich mit technologischer Resilienz.

Deshalb sollte der AI Act nicht als separates Compliance-Silo umgesetzt werden. Wenn eine Bank ein eigenständiges AI-Act-Projekt schafft, das von Technology Governance, Data Governance, Model Risk Management, DORA, GDPR und Outsourcing Oversight getrennt ist, entstehen Doppelarbeit und Verwirrung. Strategisch sinnvoller ist es, den AI Act als Zwangsmechanismus zu nutzen, um das Enterprise-AI-Governance-Modell der Bank zu stärken.

Die AI-Act-Mapping-Arbeit der EBA ist hier relevant, weil sie die Auswirkungen des AI Act auf den EU-Banken- und Zahlungsverkehrssektor untersucht hat, mit besonderem Fokus auf Hochrisiko-KI-Systeme wie Kreditwürdigkeitsprüfung und Credit Scoring. Die zentrale Botschaft für Banken lautet: AI-Act-Readiness darf nicht als Paralleluniversum behandelt werden. Sie muss gegen bestehende sektorale Pflichten und aufsichtliche Erwartungen gemappt werden.

Praktisch bedeutet das: Jede Bank sollte ein KI-Use-Case-Inventar aufbauen, das mehr tut als Tools aufzulisten. Es sollte Zweck, Nutzergruppe, betroffene Population, Entscheidungswirkung, Datenkategorie, Modelltyp, Entwicklungsquelle, Drittanbieterabhängigkeit, operationale Kritikalität, regulatorische Relevanz und Kontrollstatus klassifizieren. Ohne ein solches Inventar kann Senior Management nicht wissen, wo KI-Risiko liegt. Ohne dieses Wissen kann es KI nicht steuern.

3Digital-Omnibus-Update: Die Timeline hat sich geändert, die Verantwortung nicht

Stand 29. Juni 2026 hat der Rat der Europäischen Union final grünes Licht für gezielte Vereinfachungsmaßnahmen zum AI Act gegeben. Laut Ratskommunikation verschiebt sich die Anwendung der Hochrisiko-Pflichten auf den 2. Dezember 2027 für stand-alone Hochrisiko-KI-Systeme und auf den 2. August 2028 für KI-Systeme, die in Produkte eingebettet sind. Ich kann auf Basis der hier verfügbaren Quellen nicht bestätigen, ob die finale Änderungsverordnung bereits im Amtsblatt der Europäischen Union veröffentlicht wurde.

Für Banken ändert das die Umsetzungsplanung, aber nicht die Governance-Logik.

Die zusätzliche Zeit sollte nicht genutzt werden, um KI-Governance zu verschieben. Sie sollte genutzt werden, um Inventar, Klassifizierungslogik, Datenkontrollen, Model-Risk-Ansatz, Third-Party Oversight und Board Reporting aufzubauen, die skalierbare KI ohnehin benötigt. Die Deadline kann sich verschieben. Die Verantwortung nicht.

Das ist wichtig, weil KI-Adoption nicht auf gesetzliche Fristen wartet. Banken setzen KI bereits in Kundeninteraktion, Betrugserkennung, Kreditprozessen, interner Produktivität, Softwareentwicklung und Risk Analytics ein. Wenn Governance bis zum spätestmöglichen Rechtsdatum wartet, sammelt die Bank über Jahre unklassifizierte, undokumentierte und schlecht kontrollierte KI-Exposure an.

Eine ernsthafte Bank sollte die geänderte Timeline daher als Planungsvorteil nutzen, nicht als Verzögerungsargument. Die richtige Frage lautet nicht: „Wie spät können wir compliant sein?“ Die richtige Frage lautet: „Wie früh können wir ein wiederverwendbares Governance-Modell bauen, das compliant scaling einfacher macht?“

Das ist der strategische Unterschied zwischen Deadline Management und kontrollierter Umsetzung.

4DORA: KI-Governance trifft operationale Resilienz

Diskussionen über KI-Governance konzentrieren sich oft auf Fairness, Explainability und Model Risk. Diese Themen sind wichtig. Für Banken reichen sie aber nicht aus.

DORA macht die technologische Realität unausweichlich. Regulation (EU) 2022/2554 schafft einen EU-weiten Rahmen für digitale operationale Resilienz im Finanzsektor, einschließlich ICT Risk Management, Incident Reporting, operationalem Resilienztesting und ICT Third-Party-Risk. Das betrifft KI direkt, weil KI-Systeme zunehmend von Cloud-Infrastruktur, APIs, Model Services, externen Datenanbietern, ausgelagerter Entwicklung und Technologieanbietern abhängig sind.

Eine Bank denkt vielleicht, sie implementiere einen Kundenservice-Chatbot. Aus Governance-Sicht führt sie möglicherweise einen neuen Datenfluss, eine neue Vendor-Abhängigkeit, ein neues Access-Control-Problem, eine neue Monitoring-Anforderung, ein neues operationelles Risikoszenario und einen neuen Incident-Management-Pfad ein. Nutzt der Chatbot generative KI, muss die Bank zusätzlich Hallucination Risk, Prompt Injection, Vertraulichkeitsabfluss, unzureichendes Logging, geringe Explainability, Model Drift und Abhängigkeit von Modellupdates des Providers berücksichtigen.

Deshalb kann KI-Governance nicht außerhalb operationaler Resilienz sitzen.

Ein ernsthaftes KI-Governance-Framework im Bankwesen muss DORA-artige Fragen von Anfang an stellen. Unterstützt das KI-System einen wichtigen Geschäftsservice? Hängt es von einem kritischen ICT-Drittanbieter ab? Was passiert, wenn der Model Service nicht verfügbar ist? Was passiert, wenn Outputs schlechter werden? Was passiert, wenn der Vendor das Modell ändert? Was passiert, wenn das System schädliche oder irreführende Outputs in großem Umfang produziert? Was passiert, wenn sensitive Daten über Prompts, Embeddings, Logs oder Outputs offengelegt werden? Wer erkennt das? Wer entscheidet, ob es ein ICT Incident, ein Data Incident, ein Model Issue, ein Conduct Issue oder alles zugleich ist?

Diese Fragen bestimmen, ob KI produktionsreif ist.

DORA verändert auch das Verhältnis zwischen KI-Innovation und Third-Party-Risk. Viele KI-Fähigkeiten werden nicht vollständig in der Bank gebaut. Sie kommen über Cloud Provider, AI Platforms, Software Vendors, Data Provider, Analytics Tools und spezialisierte Model Services. Das ist nicht automatisch problematisch. Aber es bedeutet, dass KI-Governance in Procurement, Outsourcing Assessment, ICT-Risikoklassifizierung, Vertragsklauseln, Exit Planning, Service Monitoring und Konzentrationsrisikoanalyse eingebettet werden muss.

Eine Bank, die KI-Vendor-Auswahl wie einen normalen Softwarekauf behandelt, verfehlt den Punkt. Es geht nicht nur darum, ob das Tool funktioniert. Es geht darum, ob die Bank die Nutzung dieses Tools in einem regulierten Umfeld kontrollieren, überwachen, erklären, challengen, beenden und nachweisen kann.

Hier wird Governance praktisch. Der AI Approval Process sollte nicht erst beginnen, nachdem Procurement den Vendor ausgewählt hat. Er sollte beginnen, bevor die Bank sich auf eine Architektur, ein Data-Sharing-Modell oder eine vertragliche Abhängigkeit festlegt, die später kaum noch rückgängig gemacht werden kann.

5GDPR und automatisierte Entscheidungen

KI-Governance im Bankwesen ist ohne Datenschutz-Governance unmöglich.

GDPR bleibt zentral, weil viele KI-Use-Cases im Bankwesen personenbezogene Daten, Profiling oder Entscheidungen betreffen, die Personen erheblich beeinflussen können. Artikel 22 GDPR gibt betroffenen Personen das Recht, nicht einer ausschließlich auf automatisierter Verarbeitung — einschließlich Profiling — beruhenden Entscheidung unterworfen zu werden, wenn diese Entscheidung rechtliche Wirkung oder ähnlich erhebliche Wirkung entfaltet, vorbehaltlich bestimmter Ausnahmen und Schutzmaßnahmen. Das ist direkt relevant, wenn KI in Kredit, Pricing, Collections, Customer Vulnerability, Fraud Controls oder anderen kundenrelevanten Entscheidungsprozessen eingesetzt wird.

GDPR betrifft aber nicht nur automatisierte Entscheidungen. Es geht auch um Rechtsgrundlage, Zweckbindung, Datenminimierung, Transparenz, Richtigkeit, Speicherbegrenzung, Integrität, Vertraulichkeit und Rechenschaftspflicht. Diese Prinzipien sind keine Hindernisse für KI-Governance. Sie sind Teil der KI-Governance.

Die EDPB Opinion 28/2024 ist wichtig, weil sie Datenschutzaspekte im Zusammenhang mit KI-Modellen adressiert, einschließlich der Frage, wann und wie ein KI-Modell als anonym gelten kann, wie Legitimate Interest als Rechtsgrundlage in Entwicklung und Deployment bewertet werden kann und welche Folgen eine unrechtmäßige Verarbeitung in der Entwicklungsphase haben kann. Für Banken ist das besonders relevant, weil Datenherkunft und rechtmäßige Datennutzung keine abstrakten Privacy-Fragen sind. Sie entscheiden darüber, ob die Bank den Modelllebenszyklus verteidigen kann.

Die praktische Konsequenz ist klar: KI-Governance muss Modellfreigabe mit Datenfreigabe verbinden.

Ein Modell sollte nicht nur deshalb freigegeben werden, weil es statistisch gut performt. Es muss auch klar sein, welche Daten genutzt wurden, ob die Bank sie für den beabsichtigten Zweck nutzen darf, ob personenbezogene Daten involviert sind, ob sensible oder geschützte Merkmale direkt oder indirekt enthalten sind, ob Proxies Bias erzeugen können, ob die Datenqualität ausreicht, ob Aufbewahrungsfristen definiert sind und ob die Verwendung der Outputs für Betroffene transparent ist, wo dies erforderlich ist.

Das ist besonders wichtig bei generativer KI und Large Language Models. Viele Banken starteten mit internen Produktivitäts-Use-Cases, weil diese niedrigeres Risiko zu haben schienen. Aber auch interne Tools können vertrauliche Informationen, personenbezogene Daten, Kundendaten, Code, Incident Records, HR-Material, Risk Reports oder aufsichtliche Dokumente verarbeiten. Wenn Mitarbeitende sensitive Informationen ohne angemessene Kontrollen in ein KI-Tool einfügen, kann die Bank Privacy-, Vertraulichkeits-, IP-, Security- und Regulierungsprobleme schaffen, bevor ein externer Kunden-Use-Case überhaupt existiert.

Deshalb reichen Acceptable-Use-Policies nicht aus. Banken brauchen technische Guardrails, Logging, Access Controls, Data-Loss Prevention, Training, Monitoring und klare Konsequenzen bei Fehlgebrauch. Noch wichtiger: Sie brauchen nutzbare freigegebene Alternativen. Wenn die offizielle KI-Umgebung zu langsam, zu restriktiv oder zu weit von der Arbeitsrealität entfernt ist, entsteht Shadow AI.

Shadow AI ist keine Innovationsstrategie. Sie ist ein Kontrollversagen.

6Model Risk Management und generative KI

KI-Governance im Bankwesen muss auf Model Risk Management aufbauen, darf sich aber nicht darauf beschränken.

Banken verstehen Modellgovernance bereits in Bereichen wie Kreditrisiko, Marktrisiko, Liquiditätsrisiko, Kapitalmodellen, Stresstests und IFRS 9. Sie kennen die Bedeutung von Validierung, Dokumentation, Monitoring, Limitations, Change Control und unabhängiger Challenge. Aber KI bringt zusätzliche Komplexität: nichtlineares Modellverhalten, Datenabhängigkeit, reduzierte Interpretierbarkeit, mögliche kontinuierliche Lernprozesse, Abhängigkeit von externen Modellanbietern und neue Output-Risiken.

Der EBA Follow-up Report zu Machine Learning für IRB-Modelle ist nützlich, weil er zeigt, wie prudenzielle Anforderungen, GDPR und AI Act zusammenwirken, wenn Machine Learning in Kreditrisikomodellen eingesetzt wird. Der überarbeitete ECB Guide to Internal Models klärt zudem aufsichtliche Erwartungen zum Einsatz von Machine-Learning-Techniken in internen Modellen. Das sind keine generischen KI-Ethik-Dokumente. Es sind bankenspezifische Aufsichtsmaterialien, die für ernsthafte KI-Governance relevant sind.

Die praktische Lehre lautet: Banken brauchen einen gestuften Model-Governance-Ansatz. Nicht jedes KI-System sollte denselben Validierungsprozess durchlaufen wie ein IRB-Modell. Das wäre nicht praktikabel. Aber nicht jedes KI-System darf wie ein einfaches Softwarefeature behandelt werden. Das Governance-Framework muss Modelle anhand von Materialität, Use Case, regulatorischer Relevanz, Entscheidungswirkung, Komplexität, Datensensitivität, Explainability-Bedarf, operationaler Abhängigkeit und potenziellem Schaden klassifizieren.

Ein internes Low-Risk-Summarisation-Tool kann kontrollierten Zugriff, Datenrestriktionen, Logging und Acceptable-Use-Monitoring benötigen. Ein Modell zur AML-Alert-Priorisierung kann stärkere Validierung, Explainability, Bias Assessment, Performance Monitoring und operatives Backtesting erfordern. Ein Kreditwürdigkeitsmodell kann einen deutlich formaleren Governance-Pfad benötigen, weil es den Zugang zu finanziellen Ressourcen direkt beeinflussen kann und möglicherweise in eine Hochrisiko-KI-Kategorie fällt.

Model Risk Management muss sich auch für generative KI weiterentwickeln. Traditionelle Validierung fragt, ob ein Modell gegen definierte Metriken auf definierten Daten performt. Generative KI fügt Fragen hinzu, die schwerer auf einen einzigen Score zu reduzieren sind. Halluziniert das System? Erzeugt es plausible, aber falsche Outputs? Gibt es vertrauliche Informationen preis? Ist es anfällig für Prompt Injection? Produziert es diskriminierende oder irreführende Antworten? Verhält es sich je nach Sprache unterschiedlich? Verschlechtert es sich, wenn der Provider das Modell aktualisiert? Kann die Bank Outputs reproduzieren? Kann sie erklären, warum eine Antwort erzeugt wurde? Erfordert der Use Case deterministisches Verhalten oder ist probabilistischer Output akzeptabel?

Diese Fragen müssen vor dem Deployment beantwortet werden, nicht nach einem Vorfall.

KI-Governance muss definieren, was „gut genug“ für jede Klasse von KI-Use-Case bedeutet. Wenn die Bank keine Akzeptanzkriterien definieren kann, kann sie das System nicht steuern. Wenn sie das System nicht steuern kann, sollte sie es nicht skalieren.

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

7Das KI-Inventar: Das am meisten unterschätzte Governance-Werkzeug

Das wichtigste KI-Governance-Artefakt in einer Bank ist nicht die Policy. Es ist das Inventar.

Ohne KI-Inventar kennt die Bank ihre Exposure nicht. Ohne Exposure-Kenntnis kann sie Risiko nicht klassifizieren. Ohne Risikoklassifizierung kann sie keine proportionalen Kontrollen anwenden. Ohne proportionale Kontrollen übersteuert sie Low-Risk-Use-Cases oder untersteuert materielle Use Cases.

Ein ernsthaftes KI-Inventar sollte mindestens folgende Dimensionen enthalten: Use-Case Owner, Geschäftsprozess, Legal Entity, Jurisdiktion, Nutzergruppe, betroffene Population, Modelltyp, Provider, Datenquellen, personenbezogene Daten, Entscheidungswirkung, Materialität, AI-Act-Klassifizierung, GDPR-Relevanz, DORA-Relevanz, Outsourcing-Relevanz, Model-Risk-Klassifizierung, Validierungsstatus, Monitoring-Metriken, Incidents, Limitations, Residual Risk und Retirement Status.

Das Inventar muss auch KI erfassen, die in Vendor-Produkten eingebettet ist. Das wird leicht übersehen. Banken denken möglicherweise nicht, dass sie KI einsetzen, wenn sie Software mit eingebauter KI-Funktionalität kaufen. Aus Governance-Sicht kann Embedded AI aber dennoch Prozesse, Entscheidungen, Datenflüsse und operationale Abhängigkeiten beeinflussen. Vendor AI liegt nicht außerhalb der Verantwortung der Bank, nur weil das Modell in einem Drittanbieterprodukt sitzt.

Das Inventar sollte außerdem Experimentieren von Produktion trennen. Ein Proof of Concept in einer Sandbox ist nicht dasselbe wie ein Tool, das von hunderten Mitarbeitenden genutzt wird, oder ein Modell, das Kundenergebnisse beeinflusst. Aber auch Piloten brauchen Governance. Sie brauchen Grenzen: freigegebene Daten, freigegebene Umgebungen, Zeitlimits, Exit-Kriterien und Regeln für den Übergang in Produktion.

Der Übergang vom Piloten in Produktion ist einer der risikoreichsten Momente in der KI-Governance. Viele Fehler entstehen, weil ein Use Case, der informell begonnen hat, operativ wird, ohne ein angemessenes Control Gate zu passieren. Eine Demo wird ein Workflow. Ein Workflow wird eine Abhängigkeit. Eine Abhängigkeit wird ein Kontrollproblem.

KI-Governance muss diesen Übergang sichtbar machen.

8Human Oversight jenseits der Checkbox

Human Oversight ist eines der am häufigsten wiederholten Konzepte in der KI-Governance. Es ist auch eines der am häufigsten missverstandenen.

Eine Bank sollte nicht behaupten, meaningful human oversight zu haben, nur weil irgendwo eine Person im Prozess vorkommt. Human Oversight muss gestaltet werden. Der menschliche Reviewer muss Zweck des KI-Systems, Limitationen des Modells, Entscheidungskontext, Eskalationskriterien und die Umstände verstehen, unter denen der KI-Output gechallenged oder overridden werden muss.

Das ist im Bankwesen besonders wichtig, weil Mitarbeitende KI-Outputs übervertrauen können, wenn diese präzise, technisch oder souverän wirken. Eine Kreditempfehlung, ein Fraud Score, eine AML-Priorisierung, ein Customer-Risk-Summary oder eine Anomalie im regulatorischen Reporting kann objektiv wirken, weil sie von einem Modell erzeugt wurde. Aber Modelloutput ist keine Wahrheit. Er ist eine strukturierte Schätzung, die unter Annahmen, Datenlimitationen und Designentscheidungen entsteht.

Human Oversight muss daher mit Training, Prozessdesign, Entscheidungsrechten und Accountability verbunden sein. Wer darf das KI-System overrulen? Wann muss es overrult werden? Welche Evidenz ist erforderlich? Werden Overrides überwacht? Werden Muster in Overrides geprüft? Ist der menschliche Reviewer ausreichend unabhängig? Besteht Automation Bias? Gibt der Prozess genug Zeit für echte Prüfung, oder stempelt der Mensch den Modelloutput nur ab?

Es ist leicht, „human in the loop“ in eine Policy zu schreiben. Es ist deutlich schwerer, einen Prozess zu gestalten, in dem der Mensch tatsächlich Kompetenz, Autorität und Zeit hat, die Maschine zu challengen.

Für High-Impact-Banking-Use-Cases ist dieser Unterschied entscheidend.

9Explainability: Nicht jedes Modell braucht dieselbe Erklärung

Explainability ist ein weiterer Bereich, in dem Banken praktische Disziplin brauchen.

Nicht jedes KI-System benötigt dieselbe Erklärungstiefe. Ein Modell zur Weiterleitung interner Service Tickets braucht nicht dieselbe Explainability wie ein Modell zur Unterstützung der Kreditwürdigkeitsprüfung. Ein generativer KI-Assistent, der interne Policies zusammenfasst, braucht nicht denselben Erklärungsstandard wie ein Modell zur Risikoklassifizierung. Aber jedes materielle KI-System braucht einen Erklärungsstandard, der zu seiner Nutzung passt.

Explainability sollte nach Zielgruppe und Zweck definiert werden. Ein Data Scientist benötigt möglicherweise technische Erklärung. Ein Model Validator benötigt Performance-Treiber, Limitationen und Sensitivitätsanalyse. Ein Business User benötigt Reason Codes und Entscheidungslogik. Ein Kunde benötigt verständliche Informationen darüber, wie eine ihn betreffende Entscheidung zustande kam. Ein Supervisor benötigt Evidenz, dass die Bank das System versteht, kontrolliert und überwacht.

Eine einzige Erklärungsmethode wird diese Anforderungen nicht erfüllen.

Für Banken muss Explainability mit Accountability verbunden sein. Wenn niemand das Modell gut genug erklären kann, um es zu challengen, sollte die Bank beim Einsatz in materiellen Entscheidungsprozessen vorsichtig sein. Das bedeutet nicht, dass nur einfache Modelle genutzt werden dürfen. Es bedeutet, dass die Bank begründen können muss, warum ein Modell für den Use Case geeignet ist, wie seine Limitationen kontrolliert werden, wie Outputs überwacht werden und wie betroffene Stakeholder geschützt werden.

Das BIS Financial Stability Institute hat KI-Regulierung im Finanzsektor als aktives aufsichtliches Entwicklungsfeld beschrieben, einschließlich Model Risk, Data Privacy, Explainability und generative-AI-spezifischen Risiken wie Hallucination.

Die richtige Frage lautet nicht: „Können wir das Modell perfekt erklären?“ Die richtige Frage lautet: „Können wir es ausreichend für die Entscheidung erklären, die es unterstützt, und für das Risiko, das es erzeugt?“

10Third-Party-AI und Embedded Vendor AI

Third-Party-AI wird eine der schwierigsten Governance-Herausforderungen für Banken.

Viele Banken werden externe Provider für Foundation Models, Cloud Infrastructure, AI Platforms, Vendor Applications, Data Services, Monitoring Tools und spezialisierte Analytics nutzen. Das ist rational. Keine Bank sollte annehmen, jede KI-Fähigkeit intern bauen zu können. Aber die Nutzung von Drittanbietern verlagert Accountability nicht von der Bank weg.

Der Financial Stability Board hat Third-Party Dependencies, Market Correlations, Cyber Risks sowie Herausforderungen in Model Risk und Governance als KI-bezogene Vulnerabilities mit potenziellen Implikationen für die Finanzstabilität identifiziert. Für Banken ist das hochrelevant, weil KI-Adoption Abhängigkeiten von wenigen Technologie- und Cloud-Anbietern konzentrieren kann.

Aus Governance-Sicht erzeugt Third-Party-AI mehrere Fragen.

Weiß die Bank, ob das Vendor-Produkt KI enthält? Erlaubt der Vertrag der Bank, Rolle, Limitationen und Update-Zyklus des Modells zu verstehen? Kann die Bank Datennutzung beschränken? Kann sie verhindern, dass der Vendor Bankdaten für Training nutzt? Sind Logs verfügbar? Kann die Bank Outputs testen? Liefert der Vendor ausreichende Dokumentation? Was passiert, wenn der Vendor das Modell ändert? Was passiert, wenn der Provider den Service beendet? Gibt es einen Exit Plan? Bestehen Konzentrationsrisiken über die Bank hinweg? Hängen mehrere kritische Prozesse vom selben Provider ab?

Diese Fragen sollten nicht nur für kritische Outsourcing-Arrangements gestellt werden. Sie sollten Teil von AI Vendor Governance insgesamt sein, proportional zur Materialität.

Procurement-Teams brauchen KI-Literacy. Legal-Teams brauchen KI-spezifische Vertragspositionen. Technology-Teams brauchen Architekturstandards. Risk-Teams brauchen Vendor-Risk-Klassifizierung. Business-Teams müssen verstehen, dass KI-Kauf nicht dasselbe ist wie normaler Softwarekauf.

Das gefährlichste KI-Vendor-Risiko ist nicht immer das sichtbarste. Manchmal ist es die KI-Funktionalität, die in einer Plattform verborgen ist, die die Bank bereits nutzt. Ein Vendor führt ein neues KI-Feature ein. Ein Business-Team aktiviert es. Daten beginnen zu fließen. Outputs gelangen in einen Workflow. Niemand aktualisiert das Inventar. Niemand bewertet das Risiko. Niemand informiert das Board.

So wird Shadow AI zu institutionellem Risiko.

11Business Value und der Kill-Mechanismus

KI-Governance sollte nicht nur um Risiko herum designt werden. Das wäre unvollständig.

Banken brauchen KI, weil sie bessere Produktivität, bessere Customer Experience, stärkere Fraud Detection, schnellere Softwareentwicklung, bessere Risk Analytics, effizientere Kontrollen und bessere Datennutzung benötigen. Ein Governance-Modell, das KI nur blockiert, wird scheitern. Es treibt Innovation in informelle Kanäle oder macht die Bank strategisch langsamer.

Das richtige Governance-Modell muss Risikokontrolle mit Wertschöpfung verbinden.

Jeder materielle KI-Use-Case sollte einen Business Case haben. Welches Problem löst er? Welchen Prozess verbessert er? Welche Kosten reduziert er? Welches Risiko mindert er? Welches Kundenergebnis verbessert er? Welche Kontrollschwäche adressiert er? Welche Metrik zeigt, dass der Use Case funktioniert?

Ohne diese Disziplin wird KI zu Theater.

Banken sind besonders anfällig für AI Theatre, weil der Executive Pressure hoch ist. Jedes Institut will zeigen, dass es in KI aktiv ist. Jede Funktion will einen Use Case. Jeder Vendor behauptet KI-Fähigkeit. Jede Strategiepräsentation enthält eine Folie zu generativer KI. Aber Aktivität ist keine Transformation.

Eine Bank mit fünfzig Piloten und keinem skalierbaren Kontrollmodell ist nicht voraus. Sie ist exposed.

Eine Bank mit weniger Use Cases, aber klarer Plattform, governeden Data Pipelines, wiederverwendbaren Approval Paths, messbarem Nutzen und kontrolliertem Produktionsdeployment kann deutlich stärker positioniert sein. Das Ziel ist nicht, die Zahl der KI-Experimente zu maximieren. Das Ziel ist, KI dort zu operationalisieren, wo sie Wert schafft und kontrollierbar ist.

Deshalb sollte KI-Governance einen Kill-Mechanismus enthalten. Nicht jeder KI-Use-Case sollte überleben. Wenn ein Use Case keinen messbaren Wert schafft, nicht kontrollierbar ist, bestehende Fähigkeiten dupliziert, Komplexität erhöht oder unverhältnismäßiges Risiko erzeugt, sollte er beendet werden. Reife Governance bedeutet nicht nur Freigabe. Sie bedeutet auch Beendigung.

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

12KI-Governance als Enterprise Capability

Banken, die KI erfolgreich skalieren, werden KI-Governance als Enterprise Capability behandeln.

Das bedeutet: Die Bank hat eine gemeinsame KI-Taxonomie. Sie weiß, was als KI zählt, was als generative KI zählt, was als Modell zählt, was als High Impact zählt, was Production Use ist und welche Nutzungen verboten oder eingeschränkt sind.

Es bedeutet: Die Bank hat ein kontrolliertes Inventar. Nicht zehn Spreadsheets. Nicht verstreute Register in Risk, Technology, Data und Compliance. Eine verlässliche Sicht auf KI-Adoption und Risiko.

Es bedeutet: Die Bank hat risikobasierte Approval Pathways. Low-Risk-Produktivitätstools laufen durch einen proportionalen Prozess. High-Impact-Decision-Systems erhalten tiefere Review. Third-Party-AI wird vor Adoption bewertet. Materielle Änderungen lösen Re-Approval aus.

Es bedeutet: Die Bank hat eine AI Control Library. Datenkontrollen, Access Controls, Logging, Monitoring, Bias Testing, Explainability, Cyber Testing, Vendor Controls, Incident Triggers und Human Oversight werden nicht für jeden Use Case neu erfunden.

Es bedeutet: Die Bank hat KI-Literacy auf mehreren Ebenen. Board-Mitglieder brauchen genug Verständnis, um Management zu challengen. Senior Executives brauchen genug Verständnis, um Entscheidungen zu verantworten. Kontrollfunktionen brauchen genug Verständnis, um Risiko zu bewerten. Mitarbeitende brauchen genug Verständnis, um Tools sicher zu nutzen.

Es bedeutet: Die Bank hat Metriken. KI-Governance ohne Metriken wird zur Erzählung. Die Bank sollte KI-Use-Cases nach Status, Risikoklasse, Business Line, Legal Entity, Provider, Control Maturity, Issues, Incidents, Value Delivered und Audit Findings tracken.

Es bedeutet: Die Bank hat Assurance. Internal Audit sollte nicht warten, bis KI bereits informell skaliert wurde. Audit sollte Governance Framework, Inventarvollständigkeit, Control Design, Approval Evidence, Monitoring und Issue Remediation prüfen.

Es bedeutet: Die Bank hat einen Management-Rhythmus. KI-Governance sollte regelmäßig im passenden Executive Forum geprüft, bei Materialität an das Board eskaliert und mit Strategie, Technologieinvestitionen und Risk Appetite verbunden werden.

Externe Frameworks können diese Arbeit unterstützen. ISO/IEC 42001:2023 spezifiziert Anforderungen und Leitlinien für Aufbau, Implementierung, Aufrechterhaltung und kontinuierliche Verbesserung eines AI Management Systems. Das NIST AI Risk Management Framework und das Generative AI Profile bieten eine strukturierte Referenz für AI Risk Management, einschließlich Risiken generativer KI.

Eine Bank sollte Framework Alignment jedoch nicht mit regulatorischer Readiness verwechseln. ISO und NIST können das Managementsystem unterstützen, ersetzen aber nicht EU AI Act, DORA, GDPR, EBA-Erwartungen, ECB Supervision, Internal-Governance-Pflichten oder lokale regulatorische Anforderungen.

Der beste Ansatz ist, externe Frameworks als Gerüst zu nutzen — nicht als das Gebäude selbst.

13Was Boards jetzt fragen sollten

Boards und Senior Executives sollten nicht auf ein perfektes KI-Governance-Framework warten, bevor sie bessere Fragen stellen. Sie können jetzt beginnen.

• Sie sollten fragen: Haben wir ein vollständiges KI-Inventar, einschließlich Third-Party- und Embedded AI?
• Sie sollten fragen: Welche KI-Use-Cases könnten Kunden, Mitarbeitende, Risikoentscheidungen, Financial Crime Controls, regulatorisches Reporting, Kapital oder operationale Resilienz materiell beeinflussen?
• Sie sollten fragen: Welche KI-Systeme könnten unter Hochrisiko-Kategorien des EU AI Act fallen, und welche Evidenz stützt diese Klassifizierung?
• Sie sollten fragen: Wie verbindet sich KI-Governance mit DORA, GDPR, Outsourcing, Model Risk Management und Internal Governance?
• Sie sollten fragen: Wer verantwortet jedes materielle KI-System end to end?
• Sie sollten fragen: Kann das Management Datenqualität, rechtmäßige Datennutzung, Modellperformance, Human Oversight, Monitoring und Issue Management nachweisen?
• Sie sollten fragen: Welche Third-Party-AI-Abhängigkeiten entstehen, und wo könnte Konzentrationsrisiko auftreten?
• Sie sollten fragen: Wo wird generative KI bereits von Mitarbeitenden genutzt, und wie wird Shadow AI verhindert?
• Sie sollten fragen: Welchen messbaren Wert hat KI geliefert, und welche Use Cases sollten beendet werden?
• Sie sollten fragen: Wann prüft Internal Audit das KI-Governance-Framework?

Diese Fragen sollen KI nicht verlangsamen. Sie sollen KI real machen.

14Fazit

KI-Governance im Bankwesen wird häufig missverstanden. Sie wird als regulatorische Last, Compliance-Checkliste oder defensive Kontrollschicht behandelt. Diese Sicht ist zu begrenzt.

In einer europäischen Bank ist KI-Governance der Mechanismus, der KI-Skalierung ermöglicht, ohne Accountability, Resilienz, Datenschutz, Modellkontrolle oder aufsichtliches Vertrauen zu untergraben.

Die Institute, die scheitern, werden nicht zwingend diejenigen sein, die langsam sind. Einige werden schnell sein, aber ohne Kontrolle. Andere werden komplexe Governance-Dokumente bauen, die Entscheidungsprozesse nicht verändern. Beide Ansätze werden stecken bleiben.

Erfolgreiche Institute werden etwas Schwierigeres tun. Sie werden KI-Strategie mit dem Operating Model der Bank verbinden. Sie werden wissen, wo KI eingesetzt wird. Sie werden Risiko konsistent klassifizieren. Sie werden Daten und Modelle gemeinsam steuern. Sie werden Third-Party Dependencies kontrollieren. Sie werden Human Oversight wirksam machen. Sie werden Boards Evidenz liefern, nicht Slogans. Sie werden schwache Use Cases stoppen und starke skalieren.

Das ist der Unterschied zwischen KI-Experimenten und KI-Transformation.

Eine Bank kann KI-Tools kaufen. Sie kann Cloud-Plattformen kaufen. Sie kann Modellzugang kaufen. Sie kann Consulting Support kaufen. Aber sie kann Accountability nicht kaufen. Sie kann Judgement nicht outsourcen. Sie kann Vertrauen nicht delegieren.

KI-Governance im Bankwesen ist deshalb nicht die administrative Seite von KI. Sie ist die Führungsdisziplin, die entscheidet, ob KI zu einer kontrollierten Enterprise Capability wird oder zu einer weiteren Schicht unkontrollierter Komplexität.

Die nächste Wettbewerbslinie im europäischen Bankwesen wird nicht zwischen Banken verlaufen, die KI nutzen, und Banken, die sie nicht nutzen. Fast alle ernsthaften Institute werden KI nutzen. Die Linie wird zwischen Banken verlaufen, die KI auf Skalierungsebene steuern können, und Banken, die zwischen Innovation Theatre und aufsichtlichem Unbehagen gefangen bleiben.

Bei KI-Governance wird dieser Unterschied sichtbar.

15Quellen

Die faktische und regulatorische Grundlage dieses Artikels umfasst: den EU AI Act und seine Hochrisiko-Klassifizierungslogik einschließlich Annex III; die Ratskommunikation vom 29. Juni 2026 zur Vereinfachung des AI Act und den angepassten Hochrisiko-Timelines; DORA und seinen ICT-Risk- und Third-Party-Risk-Rahmen; GDPR einschließlich automatisierter Entscheidungen nach Artikel 22; EDPB Opinion 28/2024 zu KI-Modellen und personenbezogenen Daten; EBA-Material zu KI-Adoption und AI-Act-Auswirkungen im Banken- und Zahlungsverkehrssektor; ECB-Material zu internen Modellen und Machine Learning; FSB-Material zu KI-bezogenen Finanzstabilitätsrisiken; BIS/FSI-Arbeiten zu KI-Regulierung im Finanzsektor; ISO/IEC 42001:2023; sowie das NIST AI Risk Management Framework und das Generative AI Profile.