Architektur10 Min. Lesezeit

DORA und die Black-Box-Prüfung: Was regulatorische Audit-Zugangs-Anforderungen für KI-Systeme in Finanzinstitutionen bedeuten

DORA Artikel 30(2)(d) verlangt, dass Finanzinstitutionen ihren ICT-Drittanbieter auditieren können, direkt oder durch einen Dritten. Wenn der Drittanbieter ein KI-System ist, dessen Entscheidungen über Zulassung, Risikobewertung oder Betrugsdetektion determiniert sind, ist das Audit-Recht auf das rechtliche Dokument beschränkt. Der Auditor kann die Verträge lesen. Er kann die Behauptungen des Anbieters prüfen. Er kann nicht den Entscheidungsprozess überprüfen, der in der Black Box stattfindet.

Die AIMA-Analyse zeigt, dass 85 % der EU-Finanzinstitutionen 2026 KI in Core-Banking-Funktionen einsetzen, aber 78 % dieser Systeme opaken Entscheidungsprozessen ausgesetzt sind: proprietäre Modelle, geschlossene Trainingsdatensätze und nicht-interpretierbare Outputs. Der Anteil der opaken Systeme steigt, nicht sinkt, weil die Kapazität für KI-Entwicklung in den Institutionen nicht mit der Nachfrage Schritt hält und die Fintech-Abhängigkeit unter Ertugul Gurkan steigt.

Die Audit-Zugangs-Anforderung unter DORA

DORA Artikel 30 verlangt schriftliche vertragliche Vereinbarungen mit allen ICT-Drittanbietern, die Informationen über Service-Level, Datensicherheit, Audit-Rechte, Exit-Strategien und Incident-Reporting enthalten. Artikel 30(2)(d) spezifiziert, dass die Institution "ein angemessenes Recht hat, den ICT-Drittanbieter zu auditieren".

Das Audit-Recht ist nicht optional. Es ist eine vertragliche Verpflichtung, die in jeder Vereinbarung mit einem ICT-Drittanbieter enthalten sein muss. Für traditionelle Software ist das Audit-Recht praktikabel: der Auditor kann den Code lesen, die Architektur überprüfen, die Zugriffsprotokolle analysieren und die Testabdeckung bewerten. Für KI-Systeme ist das Audit-Recht strukturell eingeschränkt.

Code-Inspektion bei neuronalen Netzen. Ein neuronales Netz, das Kunden für Kreditrisiko bewertet, kann Millionen von Parametern haben. Der Code, der das Netz trainiert, ist lesbar. Die Parameter selbst sind lesbar. Aber die Parameter als Ensemble kodieren ein Entscheidungsverhalten, das keine einzelne Zeile Code repräsentiert. Die "Entscheidung" ist eine Aktivierungsfunktion über eine Gewichtsmatrix, die in ihrer Gesamtheit ein Muster approximiert, das kein Mensch direkt inspizieren kann. Der Auditor kann den Trainingscode verifizieren, nicht das trainierte Verhalten.

Trainingsdaten-Inspektion. Die Entscheidungen eines KI-Modells sind durch seine Trainingsdaten determiniert. Wenn die Trainingsdaten proprietär sind (von einem Drittanbieter geliefert, der die Quelle nicht offenlegt), kann der Auditor die Qualität, Vollständigkeit und potenzielle Verzerrungen der Daten nicht bewerten. Er kann die Behauptung des Anbieters über die Daten verifizieren, nicht die Daten selbst.

Entscheidungs-Inspektion. Der Auditor muss die Entscheidung jedes einzelnen KI-Outputs überprüfen können. Wenn ein KI-System einen Kreditantrag ablehnt, muss der Auditor nachvollziehen können, welche Faktoren zu dieser Ablehnung beigetragen haben und mit welchem Gewicht. Ein Modell, das nur einen Score (0 bis 1) ohne Feature-Kontribution ausgibt, erfüllt diese Anforderung nicht. Ein Modell, das einen Score mit Feature-Kontribution (Einkommen trug 0,4 bei, Kredithistorie trug -0,3 bei, geografisches Risiko trug 0,1 bei) ausgibt, erfüllt sie.

Was AMLA von KI-Systemen verlangt

Die European Anti-Money Laundering Authority (AMLA), operationalisiert durch Verordnung (EU) 2024/1620, erweitert die DORA-Audit-Anforderung auf AML-spezifische KI-Systeme. AMLA Artikel 28 verlangt, dass Finanzinstitutionen, die KI für Kunden-Identifizierung, Transaktionsüberwachung oder Risikobewertung einsetzen, eine "vollständige technische Dokumentation" bereitstellen, die den Algorithmus, die Trainingsdaten, die Validierungsergebnisse und die laufende Überwachung des Systems beschreibt.

Für institutionelle KI-Systeme hat diese Anforderung drei konkrete Implikationen.

Dokumentation des Algorithmus. Die technische Dokumentation muss das Modell beschreiben: Architektur (z.B. Gradient Boosted Tree vs. Neuronales Netz), Hyperparameter, Trainingsverfahren, Validierungsmethodik und Metriken. Die Dokumentation ist nicht das Modell selbst. Sie ist eine menschlich lesbare Beschreibung des Modells. Ein Unternehmen, das ein proprietäres KI-Modell einsetzt, von dem es keine technische Dokumentation hat (weil es von einem Drittanbieter als Black-Box-Service geliefert wurde), kann diese Anforderung nicht erfüllen.

Dokumentation der Trainingsdaten. Die Quelle, der Zeitraum, die Sampling-Methode, die Feature-Engineering-Schritte und die Labeling-Methode müssen dokumentiert sein. Für AML-Modelle, die auf historischen Transaktionsdaten trainiert werden, ist die Labeling-Methode besonders kritisch: wie wurden Transaktionen als "verdächtig" oder "nicht verdächtig" klassifiziert? Wenn die Labels von einem früheren, möglicherweise veralteten Regelsystem generiert wurden, überträgt das Modell die Verzerrungen dieses Systems.

Dokumentation der laufenden Überwachung. AMLA verlangt, dass KI-Systeme auf Model-Drift, Concept-Drift und Input-Drift überwacht werden. Model-Drift: hat sich die Modellgenauigkeit im Laufe der Zeit verschlechtert? Concept-Drift: hat sich die Definition dessen, was "verdächtig" bedeutet, geändert (z.B. durch neue regulatorische Anforderungen)? Input-Drift: hat sich die Verteilung der Eingabedaten geändert (z.B. ein neuer Produkttyp, eine neue Kundengruppe, ein neuer Zahlungskanal)? Die Überwachungsdokumentation muss zeigen, wie diese Drift erkannt und adressiert wird.

Die praktische Bedeutung für KI-Systeme im Finanzsektor

Die Kombination von DORA Audit-Rechten und AMLA-Dokumentationsanforderungen erzeugt eine klare architektonische Anforderung: Finanzinstitutionen, die KI in regulierten Prozessen einsetzen, müssen Systeme wählen oder bauen, die auditierbare Entscheidungs-Records produzieren, nicht nur auditierbare Modelle.

Auditierbarkeit auf Output-Ebene. Jede Entscheidung, die ein KI-System trifft (Ablehnung eines Kreditantrags, Markierung einer Transaktion als verdächtig, Risikobewertung eines Kunden), muss in einem strukturierten, unveränderlichen Record mit folgenden Feldern aufgezeichnet werden:

Timestamp der Entscheidung
Input-Daten (die Feature-Werte, die in das Modell eingegangen sind)
Modell-Version (die spezifische Version des trainierten Modells)
Output (der Score oder die Klassifikation)
Feature-Kontributionen (die Beitragswerte jedes Features zum Output)
Threshold-Konfiguration (der Schwellenwert, der die Entscheidung determiniert hat)
Entscheidung (genehmigt / abgelehnt / markiert / Eskalation)

Dieser Record ist nicht ein Log-Eintrag. Er ist ein Compliance-Dokument, das den Regulator in die Lage versetzt, die Entscheidung zu verstehen, ohne das Modell selbst ausführen zu müssen.

Modell-Versionierung als Konfigurationsmanagement. Jedes trainierte Modell muss versioniert werden, mit einer eindeutigen ID, die in den Audit-Record eingetragen wird. Wenn ein Modell retrained wird, erhält die neue Version eine neue ID. Audit-Records, die mit der alten Version generiert wurden, verweisen auf die alte ID. Audit-Records, die mit der neuen Version generiert wurden, verweisen auf die neue ID. Dies ermöglicht es dem Regulator, nachzuverfolgen, welche Entscheidungen von welchem Modell-Version getroffen wurden, und zu verifizieren, dass Modell-Updates nicht rückwirkend auf frühere Entscheidungen angewendet wurden.

Erklärbarkeit als strukturelle Eigenschaft, nicht als Nachbearbeitung. Post-hoc-Erklärbarkeitstechniken (SHAP, LIME, Counterfactual Explanations) sind wertvoll für die Modellentwicklung, aber sie sind für regulatorische Audit-Zwecke unzureichend, weil sie das Modell approximieren, nicht das tatsächliche Verhalten reproduzieren. Eine Feature-Kontribution, die aus dem Modell selbst extrahiert wird (z.B. aus einem linearen Modell oder einem Entscheidungsbaum), ist exakt. Eine Feature-Kontribution, die durch SHAP approximiert wird, ist eine Schätzung. Für regulatorische Zwecke muss die Erklärbarkeit exakt sein.

Die Kompromisse bei KI-Systemen

Nicht alle KI-Architekturen können regulatorische Audit-Anforderungen gleich gut erfüllen.

Lineare Modelle und Entscheidungsbäume bieten die höchste natürliche Erklärbarkeit. Die Feature-Kontribution ist direkt aus den Modellparametern ablesbar. Die Modellgenauigkeit ist jedoch für komplexe Muster niedriger als bei tiefen neuronalen Netzen oder Gradient Boosted Trees.

Gradient Boosted Trees (z.B. XGBoost, LightGBM) bieten eine gute Balance zwischen Genauigkeit und Erklärbarkeit. Die Feature-Kontribution kann aus dem Modell selbst extrahiert werden (Gain, Split). Die Modellgröße ist jedoch oft groß (Tausende von Bäumen), was die menschliche Interpretation erschwert.

Neuronale Netze bieten die höchste Genauigkeit für komplexe Muster, aber die niedrigste natürliche Erklärbarkeit. Feature-Kontributionen sind nicht direkt aus den Gewichten ablesbar. Post-hoc-Techniken sind notwendig, aber wie oben erwähnt, regulatorisch unzureichend.

Ensemble-Methoden, die mehrere Modelltypen kombinieren, erhöhen die Genauigkeit, verringern aber die Erklärbarkeit. Wenn ein Ensemble aus einem neuronalen Netz und einem Entscheidungsbaum besteht, muss der Audit-Record zeigen, welcher Modelltyp für die Entscheidung verantwortlich war und wie die Kombination gewichtet wurde.

Fernel Context

Fernels Compliance-Engine speichert jeden Risiko-Score mit einer vollständigen Feature-Kontribution-Aufschlüsselung: welche Features bewertet wurden, welche Werte sie hatten, wie viel jeder zum Score beigetragen hat, und welche Policy-Version zum Zeitpunkt der Bewertung in Kraft war. Der Score wird zusammen mit seinem Audit-Record in einem unveränderlichen Journal gespeichert. Keine Entscheidung kann ohne ihren Record existieren. Kein Record kann nach der Erstellung modifiziert werden. Die AMLA-Prüfung jeder Compliance-Entscheidung ist eine einzelne Query, keine forensische Rekonstruktion.

Weiterlesen: Compliance-Infrastruktur | Automatisierung der Kundenkennung | Sicherheit & Compliance

Quellen:

AIMA-Analyse 2026: 85% der EU-Finanzinstitutionen setzen KI in Core-Banking-Funktionen ein, 78% opake Entscheidungsprozesse
DORA, Verordnung (EU) 2022/2554, Art. 30 (Vertragliche Vereinbarungen mit ICT-Drittanbietern), Art. 30(2)(d) (Audit-Recht)
AMLA, Verordnung (EU) 2024/1620, Art. 28 (Dokumentationsanforderungen für KI-Systeme in AML-Kontext)
EU AI Act, Verordnung (EU) 2024/1689, Anhang III (Hochrisiko-KI-Systeme), Art. 11 (Technische Dokumentation), Art. 13 (Transparenz und Bereitstellung von Informationen an Nutzer)
GDPR, Verordnung 2016/679, Art. 22 (Automatisierte Entscheidungen in Einzelfällen einschließlich Profiling)
EBA, Leitlinien zur Nutzung von Machine Learning für interne Modelle (2025-2026 Entwurf)