KI-Governance in Banken: Wie Institute regulatorische Sicherheit und Innovationsgeschwindigkeit verbinden

KI ist in Banken längst kein Experiment mehr. Ob Betrugserkennung, Kreditrisiko, Kundenservice, Dokumentenverarbeitung oder Vertriebsprognosen: Machine Learning und GenAI liefern messbaren Nutzen – wenn Datenqualität, Prozesse und Verantwortung stimmen. Genau hier beginnt KI-Governance: als System aus Regeln, Rollen, Kontrollen und Standards, das Innovation ermöglicht, ohne Compliance, Risiko-Management und IT-Sicherheit zu kompromittieren.

Viele Institute stehen aktuell vor einem Spannungsfeld: Einerseits steigen Erwartungshaltungen (Kosten senken, Prozesse automatisieren, Time-to-Market verkürzen). Andererseits nehmen regulatorische und operative Risiken zu: Modelle können diskriminieren, Halluzinationen produzieren, sensible Daten leak-en oder Entscheidungen treffen, die nicht nachvollziehbar sind. Die Kernfrage lautet daher nicht: „Machen wir KI?“ Sondern: „Wie machen wir KI kontrolliert, auditierbar und skalierbar?“

1) Was KI-Governance in Banken wirklich bedeutet

KI-Governance ist mehr als eine Richtlinie oder ein „AI Policy“-PDF. In der Praxis umfasst sie mindestens vier Ebenen:

• Strategische Ebene: Welche KI-Anwendungsfälle sind erlaubt, priorisiert und finanziert? Wie passt KI zur Risiko- und Digitalstrategie?
• Organisatorische Ebene: Wer trägt Verantwortung (Business Owner, Model Owner, Risk Owner)? Wie laufen Freigaben, Eskalationen, Reviews?
• Technische Ebene: Wie werden Modelle gebaut, getestet, deployed, überwacht und versioniert? Wie sieht die Model- und Prompt-Factory aus?
• Kontroll- und Audit-Ebene: Wie werden Entscheidungen nachvollziehbar gemacht? Welche Evidenzen existieren für interne Revision und Aufsicht?

In Banken ist diese Struktur besonders wichtig, weil Modelle häufig in risikobehaftete Entscheidungen eingreifen: Kreditannahme, Limits, Fraud-Blocking oder AML-Screening. Schon kleine Fehler können finanzielle Schäden, Reputationsrisiken und aufsichtliche Findings auslösen.

2) Der Governance-Kern: Use-Case-Klassifizierung statt Bauchgefühl

Der häufigste Fehler in KI-Projekten ist eine fehlende Einordnung: Teams bauen „mal schnell“ ein Modell oder setzen einen Copilot ein, ohne sauber zu definieren, wofür es genutzt wird und welche Risiken es mitbringt. Governance beginnt deshalb mit einem pragmatischen Klassifizierungsprozess:

• Wirkungskreis: Unterstützt die KI nur Mitarbeitende (Assistenz), oder trifft sie Entscheidungen (Automatisierung)?
• Betroffene Daten: Enthält der Use Case personenbezogene Daten, Kontodaten, Gesundheitsdaten, Insiderinformationen?
• Risikodimension: Beeinflusst das System Kundenzugang, Pricing, Kredit, Compliance oder Security?
• Transparenzbedarf: Müssen Entscheidungen erklärbar sein (z. B. Ablehnung Kredit), oder ist es ein rein internes Tool?

Aus dieser Klassifizierung leiten Banken ab, welche Kontrollen verpflichtend sind: Dokumentationstiefe, Validierungsgrad, Monitoring-Frequenz, Freigabeinstanzen. Das Ziel: gleiche Standards für gleiche Risikoklassen – statt Governance nach Teamstärke oder Lobby.

3) Rollenmodell: Wer ist eigentlich „Owner“ von KI?

KI scheitert in Banken selten an Algorithmen – sondern an Zuständigkeiten. Ein tragfähiges Rollenmodell schafft Klarheit. Bewährt haben sich folgende Rollen, die je nach Hausgröße zusammengelegt werden können:

• Business Owner: Fachliche Verantwortung, Nutzenhypothese, Prozessintegration, KPI-Verfolgung.
• Model Owner: Technische Verantwortung für Modell/Pipeline/Prompt-Set, Versionierung, Deployment.
• Risk & Compliance Owner: Bewertung von Modellrisiken, Kontrollanforderungen, regulatorische Einordnung.
• Data Owner: Datenherkunft, Qualität, Berechtigungen, Löschkonzepte, Datenverträge.
• IT/Security Owner: Infrastruktur, Zugriffsmodelle, Secrets, Logging, Incident-Prozesse.

Wichtig ist dabei nicht, neue Hierarchien zu schaffen, sondern Entscheidungswege zu verkürzen. Viele Banken nutzen dafür ein leichtgewichtiges „AI Governance Board“: ein interdisziplinäres Gremium, das Use Cases in der frühen Phase bewertet und klare Leitplanken setzt.

4) Technische Mindeststandards: Von Model Registry bis Prompt Logging

Governance wird nur wirksam, wenn sie technisch umgesetzt ist. Für klassische ML-Modelle gehören dazu typischerweise:

• Model Registry: zentrale Ablage mit Versionen, Metadaten, Ownern, Freigabestatus
• Reproduzierbarkeit: Trainingsdaten-Hash, Code-Version, Feature-Definitionen, Parameter
• Validierung: Performance, Robustheit, Bias-Checks, Drift-Analysen
• Monitoring: Daten-Drift, Modell-Drift, Ausfallraten, Fehlalarme, KPI-Abweichungen

Für GenAI und LLM-basierte Systeme kommen zusätzliche Anforderungen hinzu, die häufig unterschätzt werden:

• Prompt- & Template-Versionierung: Änderungen sind „Code“ und müssen nachvollziehbar sein
• Prompt Logging: Welche Eingaben wurden verarbeitet, welche Outputs erzeugt (inkl. Maskierung sensibler Daten)?
• Guardrails: Sicherheitsfilter, Content-Policies, Injection-Prevention, Output-Constraints
• RAG-Governance: Welche Wissensquellen werden genutzt, wie aktuell sind sie, wer darf sie pflegen?

Wenn Banken diese Standards früh setzen, entsteht ein skalierbarer Rahmen: Teams können schneller liefern, weil klar ist, welche Artefakte, Tests und Nachweise nötig sind. Genau das ist der Kern moderner KI-Governance: Standardisierung für Geschwindigkeit – nicht Bürokratie.

Im zweiten Teil schauen wir nun auf die Praxis: Governance-Blueprint für Banken, konkrete Kontrollen für GenAI, typische Fallstricke (Shadow AI), und wie man Governance so baut, dass sie Innovation messbar beschleunigt.

Jetzt wird es also praktisch: Wie sieht ein umsetzbarer Governance-Blueprint aus, der sowohl regulatorische Anforderungen erfüllt als auch die Innovationsgeschwindigkeit erhöht? Und welche Besonderheiten müssen Banken bei GenAI/LLMs berücksichtigen?

5) Ein Governance-Blueprint, der in der Bank wirklich funktioniert

Ein praxistaugliches Modell ist ein dreistufiger Prozess, der jede KI-Initiative von Anfang an strukturiert:

• Stage 0 – Intake & Klassifizierung: Use Case kurz beschreiben, Datenarten definieren, Wirkungskreis bewerten, Risikoklasse zuordnen.
• Stage 1 – Build mit Mindestkontrollen: Technische Entwicklung inklusive Dokumentation, Tests, Security-Checks und Freigabepaketen.
• Stage 2 – Operate & Audit: Monitoring, Incident-Prozesse, regelmäßige Reviews, Rezertifizierung bei Änderungen.

Der Schlüssel ist, dass Stage 0 schnell geht (z. B. 30–60 Minuten), aber verbindlich ist. Ziel: Schattenprojekte verhindern, ohne Innovation zu blocken. Viele Banken arbeiten hier mit einem standardisierten Intake-Formular und einem festen Turnus (z. B. wöchentlich) für die erste Entscheidung.

6) „Shadow AI“: Das größte Governance-Risiko entsteht außerhalb der IT

Ein unterschätztes Risiko ist nicht das zentrale KI-Team – sondern die dezentrale Nutzung von KI-Tools in Fachbereichen. Mitarbeitende kopieren Inhalte in öffentliche Tools, nutzen private Accounts oder bauen Workarounds mit Browser-Plugins. Daraus entstehen Risiken:

• Datenabfluss: Kundendaten oder interne Informationen landen in nicht freigegebenen Systemen.
• Unkontrollierte Entscheidungen: KI-Outputs werden „blind“ übernommen (z. B. E-Mail-Antworten, Risiko-Einschätzungen).
• Intransparenz: Keine Logs, keine Freigaben, keine Nachvollziehbarkeit – ein Audit-Albtraum.

Die Gegenmaßnahme ist nicht „Verbote per Rundmail“, sondern ein Kombi-Ansatz:

• Freigegebene KI-Umgebung: Unternehmens-LLM oder abgesicherte Anbieter-Instanzen mit Datenschutz- und Logging-Konzept.
• Klare Richtlinien: Was darf in KI eingegeben werden, was nicht? Mit Beispielen und Standardfällen.
• Enablement: Schulungen für sichere Prompts, Umgang mit Halluzinationen, Quellenprüfung.
• Technische Leitplanken: DLP-Regeln, Proxy-Filter, SSO, Rollenberechtigungen, Audit-Logs.

7) GenAI-spezifische Kontrollen: Halluzinationen sind kein „Bug“, sondern Betriebsrisiko

Während klassische ML-Modelle oft auf definierte Outputs optimiert sind, erzeugen LLMs probabilistische Antworten. Banken müssen deshalb Kontrollen definieren, die dieses Verhalten absichern:

• Use-Case-Design: GenAI sollte in kritischen Prozessen nicht „entscheiden“, sondern Vorschläge machen (Human-in-the-Loop).
• Output-Constraints: Strukturierte Antworten (z. B. JSON), begrenzte Antwortlängen, Zitationspflicht aus Quellen.
• Grounding/RAG: Antworten auf geprüfte Wissensquellen stützen; „freie“ Antworten in regulierten Kontexten minimieren.
• Evaluation: Testsets mit realistischen Fällen, Red-Teaming, Prompt-Injection-Tests, Sicherheitsbewertungen.
• Fallback-Mechanismen: Wenn Confidence niedrig oder Quellen fehlen: „Ich weiß es nicht“ statt Fantasieantwort.

Eine wirksame Praxis ist die Einführung eines GenAI-Release-Pakets, ähnlich einem Change-Request: Prompt-Versionen, RAG-Quellenliste, Testnachweise, Security-Review und Freigabeprotokoll. Damit wird GenAI „releasefähig“ wie jede andere Banksoftware.

8) Governance als Accelerator: Standardisierte Bausteine statt Einzelfall-Diskussionen

KI-Governance wird oft als Bremse wahrgenommen, weil jede Idee durch Gremien muss. Das kann man umdrehen: Governance wird zum Beschleuniger, wenn man wiederverwendbare Standards schafft. Beispiele:

• Vordefinierte Risikoklassen: Je Klasse fixe Mindestkontrollen, klare Verantwortlichkeiten, definierte Review-Zyklen.
• Template-Bibliothek: Modellkarten, Prompt-Cards, DPIA-Bausteine, Testprotokolle, Betriebsdokumentation.
• Approved Components: Freigegebene Datenquellen, Vektor-Datenbanken, LLM-Provider, Monitoring-Stacks.
• AI Factory: CI/CD für Modelle und Prompts, automatisierte Tests, zentrale Registry, automatisiertes Deployment.

So reduziert man Governance-Aufwand pro Projekt drastisch. Teams müssen nicht jedes Mal neu verhandeln, sondern arbeiten in einem bekannten Rahmen. Genau das schafft Geschwindigkeit – und reduziert gleichzeitig Findings im Audit.

9) Messbarkeit: Ohne KPIs wird Governance zum Selbstzweck

Damit Governance nicht als reine Compliance-Übung endet, braucht es Kennzahlen. Sinnvolle KPIs für Banken sind z. B.:

• Time-to-Approval: Wie lange dauert Stage 0 bis Freigabe?
• Reuse-Rate: Anteil der Projekte, die Standard-Templates und Approved Components nutzen.
• Incident-Rate: Anzahl relevanter KI-Vorfälle (Datenabfluss, Fehlentscheidungen, policy breaches).
• Model/Prompt Drift: Häufigkeit und Schwere von Qualitätsabfällen im Betrieb.
• Business Impact: Einsparungen, Durchlaufzeiten, Fehlerquoten, Kundenzufriedenheit je Use Case.

Diese KPIs gehören regelmäßig ins Management-Reporting. So wird KI-Governance Teil der Steuerung – und nicht nur „Dokumentation für die Revision“.

10) Ein realistischer Startplan für die nächsten 90 Tage

Wenn du KI-Governance in einer Bank pragmatisch aufsetzen willst, funktioniert ein 90-Tage-Plan oft besser als ein „Big Bang“:

• Tage 1–30: Intake-Prozess, Risikoklassen, Rollenmodell, freigegebene KI-Umgebung definieren.
• Tage 31–60: Templates & Mindeststandards, Model/Prompt Registry, Logging/Monitoring-Basis etablieren.
• Tage 61–90: 2–3 Pilot-Use-Cases durch den Prozess laufen lassen, Lessons Learned in Standards zurückspielen.

Wichtig: Governance nie „im Elfenbeinturm“ definieren, sondern mit echten Use Cases testen. Die besten Kontrollen entstehen aus realen Konflikten zwischen Fachbereich, IT, Risiko und Compliance.

Fazit: Gute KI-Governance ist kein Blocker, sondern die Voraussetzung dafür, dass Banken KI skalieren können. Wer Rollen, Risikoklassen und technische Standards früh etabliert, reduziert Schatten-KI, verbessert Auditierbarkeit und gewinnt Geschwindigkeit – genau dort, wo Banken sie am dringendsten brauchen.