Field Guide
KI-Governance & Compliance im Finance-Bereich
Der EU AI Act, Model Risk Management und aufsichtsrechtliche Erwartungen, übersetzt in Engineering, das Sie ausliefern können.
Ab August 2026 greifen die Hochrisiko-Pflichten des EU AI Act, und Kredit-Scoring, Versicherungs-Pricing und Betrugserkennung fallen klar darunter. In den USA hat sich das Model Risk Management über SR 11-7 hinaus weiterentwickelt. In Deutschland behandelt die BaFin KI inzwischen als ICT-Risiko unter DORA. Nichts davon ist abstrakte Politik: Es landet als konkrete Anforderung an Systemen, die Sie gerade jetzt bauen.
Dieser Leitfaden übersetzt dieses regulatorische Gewicht in Engineering: was eine Hochrisiko-Einstufung tatsächlich verlangt, wie Sie ein Modell so validieren und überwachen, dass es einer Prüfung standhält, und welche Dokumentation und menschliche Aufsicht vor dem Go-live vorhanden sein muss, nicht danach.
Aktuelle Signale
- Der EU Digital Omnibus (vorläufig, Mai 2026) verschiebt die Annex-III-Pflichten für Hochrisiko-Anwendungen, einschließlich Kreditscoring, auf den 2. Dezember 2027, vorbehaltlich der Annahme durch den Rat.
- SR 26-2 löst SR 11-7 ab, mit wesentlichkeitsbasierter Aufsicht, und verzichtet auf die pauschale jährliche Revalidierung, lässt generative und agentische KI jedoch außen vor.
- DORA gilt seit Januar 2025; die BaFin verortet KI nun innerhalb kritischer IKT, mit Abhängigkeitskartierung, Drittanbieterverträgen und Vorfallmeldungen.
- Die CFPB stellt klar, dass KI-gestützte Kreditentscheidungen weiterhin konkrete ECOA-Begründungscodes und dokumentierte Disparate-Impact-Tests erfordern, so komplex das Modell auch sein mag.
In diesem Leitfaden
KI-Incident-Postmortems im Finanzsektor durchführen
Ein Modell-Incident ohne Postmortem ist ein Incident, den Sie wiederholen werden. Hier ist der schuldfreie Postmortem-Prozess, den wir für KI-Fehler im Finanzsektor fahren.
LesenConsumer Duty und KI im britischen Finanzsektor
Die Consumer Duty der FCA verändert, was eine KI-gestützte Entscheidung nachweisen können muss. So entwickeln wir Systeme, die gute Ergebnisse und faire Preis-Leistung liefern.
Ein Operating Model für KI-Governance im Finance-Team
Governance scheitert, wenn sie ein Gremium ohne Verkabelung ist. Hier ist das Operating Model mit Rollen und Gates, das wir Finance-Teams rund um KI aufsetzen helfen.
DSGVO und automatisierte Entscheidungen in der Finanz-KI
Artikel 22 und das Recht auf Erklärung bestimmen, was ein Finanzmodell allein entscheiden darf. So bauen wir es technisch um, ohne den Workflow auszubremsen.
KI-Anbieter-Due-Diligence: die Fragen, auf die es ankommt
Wer einen KI-Anbieter einkauft, importiert dessen Modellrisiko ins eigene Haus. Hier ist die Due-Diligence-Checkliste, die wir nutzen, bevor ein Finanzteam unterschreibt.
Menschliche Aufsicht für Hochrisiko-KI gestalten
Der EU AI Act verlangt wirksame menschliche Aufsicht, keinen Gummistempel. So gestalten wir Prüfpunkte, die ein Mensch tatsächlich wahrnehmen kann.
Ein Bias-Audit-Workflow für Kreditvergabemodelle
Disparate-Impact-Tests, die Suche nach der weniger diskriminierenden Alternative und Produktionsmonitoring: der Fairness-Workflow, den wir für Kreditmodelle betreiben.
Technische Dokumentation nach EU AI Act, die einer Prüfung standhält
Eine Einstufung als hochriskant bedeutet ein Dokumentationspaket, keine Folie. Hier steht, was Anhang IV tatsächlich verlangt und wie wir es als Engineering-Nachweis aufbauen.
Model Cards, die der Finance-Governance wirklich helfen
Eine Model Card ist Dokumentation, mit der ein Prüfer arbeiten kann – kein Marketing. Hier steht, was wir für ein Finanzmodell darauf festhalten und warum sich jedes Feld seinen Platz verdient.
Red Teaming von KI-Systemen in Finanzdienstleistungen
Angreifer testen Finanz-KI auf Jailbreaks, Datenlecks und verzerrte Ausgaben. So führen wir Red Teaming an einem System durch, bevor es ein Angreifer oder ein Prüfer tut.
Audit-Trails, die Finanz-KI reproduzierbar machen
Wenn ein Prüfer fragt, warum das Modell so entschieden hat, müssen Sie die Entscheidung exakt rekonstruieren können. Hier ist das Logging und Versioning, das eine Entscheidung reproduzierbar macht.
Schatten-KI: die Tools regulieren, die Ihre Mitarbeitenden längst nutzen
Ihr Team fügt Daten in Chatbots ein, ob Sie es freigegeben haben oder nicht. Hier sind die Nutzungsrichtlinie und die Kontrollen, die wir mit Finanzunternehmen darum herum aufbauen.
Kontinuierliches Modell-Monitoring, das einer Aufsicht standhält
Eine jährliche Revalidierung genügt nicht für ein Modell, das wöchentlich driftet. Hier ist das Monitoring, das Alerting und der Nachweispfad, den wir für beaufsichtigte Finanzmodelle aufbauen.
DORA-Incident-Response, wenn die KI das IKT-Risiko ist
Unter DORA ist ein KI-Ausfall ein IKT-Vorfall mit laufenden Meldefristen. Hier ist der Workflow für Erkennung, Klassifizierung und Meldung, den wir für KI-Systeme aufbauen.
Aufbau eines KI-Modellinventars und einer Model Registry
Man kann nicht steuern, was man nicht auflisten kann. Hier sind das Modellinventar, die Registry und die Metadaten, die wir aufbauen, damit Risiko und Revision jedes Modell in Produktion sehen.
Die BaFin liest KI jetzt als IKT-Risiko: Was DORA von Ihren Modellen verlangt
Die BaFin-Orientierungshilfe vom Dezember 2025 ordnet KI dem IKT-Risikoregime der DORA zu, nicht einem separaten Ethik-Ressort. Was das für Register, Vorfälle und Tests bedeutet.
Wenn das Modell jemand anderem gehört: Third-Party-KI und Anbietermodellrisiko
Eine gehostete Modell-API ist ein IKT-Dienst, kein Feature. So behandeln wir Anbietermodellrisiko, Konzentrationsrisiko und stille Updates unter DORA-Maßstäben.
Was die August-2026-Frist des EU AI Act von Ihnen verlangt
Systeme für Kreditbewertung und Versicherungstarifierung fallen künftig unter das Hochrisiko-Regime, und der Stichtag ist nun in Bewegung. Was das für das System bedeutet, das Sie gerade bauen.
MiCA für Stablecoins und Krypto-Zahlungen: Was Engineering-Teams bauen müssen
MiCA übersetzt Regeln für Kryptowerte in konkrete Kontrollen für Emittenten und Zahlungsdienstleister. Hier ist das Monitoring-, Reporting- und Data-Lineage-Engineering, das tatsächlich dahintersteckt.
Wenn Ihr Kreditmodell eine Ablehnung nicht erklären kann, dürfen Sie es für diese Ablehnung nicht einsetzen
ECOA Regulation B verlangt konkrete Gründe innerhalb von 30 Tagen nach einer Kreditablehnung. Das stellt Anforderungen an das Modell, das die Entscheidung getroffen hat, nicht nur an die Dokumentation darum herum.
So testen Sie Kredit- und Pricing-Modelle wirklich auf Fairness
Ein geschütztes Merkmal wegzulassen macht ein Modell nicht fair. So testen wir Kredit- und Pricing-Modelle auf mittelbare Diskriminierung und Proxy-Diskriminierung und sichern die Nachweise.
Modellrisikomanagement, wenn das Modell ein LLM ist
SR 11-7 wurde für deterministische Modelle geschrieben. Der Nachfolger aus dem Jahr 2026, SR 26-2, hat das Modellrisikomanagement modernisiert, klammert generative KI jedoch aus dem Anwendungsbereich aus. So lässt es sich auf ein LLM erweitern.
Erklärbarkeitsmethoden, die einer Modellvalidierung standhalten
Die meiste Arbeit an der Erklärbarkeit überzeugt den Data Scientist, der das Modell gebaut hat, und sonst niemanden. So machen wir sie belastbar für die Validierung, die Aufsicht und den abgelehnten Kunden.
Arbeiten Sie an etwas Ähnlichem?
Erzählen Sie uns von Ihren Daten und dem Workflow drumherum, und Sie bekommen eine ehrliche Einschätzung.
30-minütiges Erstgespräch buchen