Artikel 22 verbietet Ihrem Modell nicht, zu entscheiden. Er beschränkt eine Entscheidung, die ausschließlich auf automatisierter Verarbeitung beruht und rechtliche oder ähnlich erhebliche Wirkung für eine Person entfaltet – es sei denn, sie ist für einen Vertrag erforderlich, nach Unions- oder mitgliedstaatlichem Recht zulässig oder durch ausdrückliche Einwilligung gedeckt. Erfüllen Sie eine Bedingung, schulden Sie trotzdem Schutzmaßnahmen. Das ist das ganze Spiel für Finanz-KI.
Die meisten Teams lesen den Artikel als Verbot und schnallen entweder jedem Fall einen Menschen an oder schieben die gesamte Frage an die Rechtsabteilung und warten. Beides ist auf unterschiedliche Weise teuer. Die technische Aufgabe ist enger gefasst: entscheiden, welche Entscheidungen tatsächlich unter Artikel 22 fallen, die von diesen Entscheidungen geforderten Schutzmaßnahmen bauen und alles Übrige straight through laufen lassen.
Was als automatisierte Entscheidung gilt
Die entscheidende Formulierung lautet „ausschließlich auf automatisierter Verarbeitung beruhend“ in Verbindung mit „rechtlicher Wirkung“ oder Wirkungen, die die Person „in ähnlicher Weise erheblich beeinträchtigen“. Einen Kredit ablehnen, ein Konto schließen, eine Zahlung einfrieren, eine Versicherung bepreisen, eine Verdachtsmeldung einreichen, die zum Off-Boarding führt: All das überschreitet die Erheblichkeitsschwelle ohne großen Streit. Ein Fraud-Score, der lediglich eine manuelle Prüf-Queue sortiert, tut das in der Regel nicht, weil noch ein Mensch entscheidet.
Die Falle ist das Wort „ausschließlich“. Ein Mensch in der Schleife nimmt Sie nur dann aus Artikel 22 heraus, wenn dieser Mensch tatsächlich entscheidet. Der EuGH hat das im SCHUFA-Urteil (C-634/21, Dezember 2023) konkret gemacht: Ein Kredit-Score kann selbst die automatisierte Entscheidung nach Artikel 22 sein, wenn ein Dritter „maßgeblich“ auf ihn zurückgreift und der Score eine bestimmende Rolle dabei spielt, ob Kredit gewährt wird. Der Analyst weiter unten, der genehmigt, was auch immer der Score sagt, ist also keine Schutzmaßnahme. Er ist eine Formalität, und die Entscheidung bleibt automatisiert.
Zwei Fragen entscheiden die Einordnung, und beide sind aus Ihrer Architektur heraus beantwortbar statt aus einer Meinung:
- Hat der Prüfer die Daten, die Zeit und das Mandat, zu einem anderen Schluss zu kommen? Wenn die Oberfläche einen Score und einen Genehmigen-Button zeigt und sonst nichts, lautet die Antwort nein.
- Gibt es eine Schwelle, unterhalb derer das System ganz ohne menschliche Berührung handelt – sei es straight-through-Genehmigung, automatische Ablehnung oder automatische Meldung? Alles unterhalb dieser Schwelle fällt eindeutig in den Anwendungsbereich.
Wir kartieren das auf Ebene der Entscheidung, nicht des Modells. Ein Modell kann sowohl eine im Anwendungsbereich liegende automatische Ablehnung als auch eine außerhalb liegende Prüf-Queue speisen. Die Pflichten aus Artikel 22 hängen am Zweig, also ist der Zweig die Stelle, an der wir instrumentieren.
Die Schutzmaßnahmen in die Laufzeit einbauen
Wenn eine Entscheidung in den Anwendungsbereich fällt, verlangt Artikel 22 Absatz 3, dass Sie der Person menschliches Eingreifen, die Darlegung des eigenen Standpunkts und die Anfechtung des Ergebnisses ermöglichen. Das sind Laufzeitfähigkeiten. Ein Richtlinien-PDF liefert keine davon. Wenn das System nicht rekonstruieren kann, warum es in dem Moment so entschieden hat, wie es entschieden hat, ist keine der drei real.
Diese Rekonstruktion ist ein Lineage-Problem. Das Recht auf Anfechtung ist nur dann sinnvoll, wenn Sie für eine an einem bestimmten Datum getroffene Entscheidung beantworten können, welches das Modell war, welche Features es gesehen hat und welche Werte diese Features in genau jenem Augenblick hatten. Hier hört Point-in-Time-Korrektheit auf, eine Trainingsset-Feinheit zu sein, und wird zur rechtlichen Pflicht. Wenn Ihr Feature Store den aktuellen Wert eines Features ausliefert, während jemand eine vor zwei Quartalen getroffene Entscheidung anficht, erklären Sie eine Entscheidung, die es nie gegeben hat.
Konkret persistieren wir für jede im Anwendungsbereich liegende Entscheidung:
- Die Modellversion und den exakten Feature-Vektor, wie er ausgeliefert wurde – als Snapshot zum Entscheidungszeitpunkt festgehalten, nicht auf Abruf neu berechnet.
- Die Entscheidung, die überschrittene Schwelle und die Reason Codes, die für genau diesen Datensatz am höchsten rangierten.
- Ob ein Mensch geprüft hat, wer, und was er sehen und ändern konnte.
Reason Codes verdienen Sorgfalt. Eine SHAP-artige Attribution über Ihre Produktions-Features ist eine belastbare Grundlage für die „aussagekräftigen Informationen über die involvierte Logik“, die Artikel 13 bis 15 verlangen – aber nur, wenn die Features für Menschen lesbar sind. „Attribut f_2291“ erklärt einer betroffenen Person nichts und einer Aufsichtsbehörde nichts. Wir lösen Attributionen zu benannten, dokumentierten Features zurück auf, bevor sie das System verlassen, und halten die Zuordnung unter Versionskontrolle, damit eine im Juni gegebene Erklärung im Dezember noch reproduzierbar ist.
Die Erklärung, die Sie tatsächlich schulden
Es hält sich hartnäckig der Mythos eines umfassenden „Rechts auf Erklärung“ in der DSGVO. Der durchsetzbare Text gibt der Person aussagekräftige Informationen über die involvierte Logik sowie die Tragweite und die angestrebten Auswirkungen der Verarbeitung (Artikel 13 bis 15). Das ausdrückliche Recht auf Erklärung einer konkreten Entscheidung wohnt in Erwägungsgrund 71, der die Auslegung leitet, aber keine eigenständige Pflicht schafft. Sektorregeln gehen oft weiter. Ein US-amerikanischer Adverse-Action-Notice muss konkrete Hauptgründe nennen, und das EU-Verbraucherkreditrecht verlangt inzwischen eine aussagekräftige Erklärung, wenn eine Ablehnung auf einer automatisierten Bewertung beruht. Beide setzen eine höhere Messlatte als die DSGVO allein.
Wir bauen auf die strengere Anforderung und lassen sie die schwächere miterfüllen. Das bedeutet: Die für einen Adverse-Action-Notice erzeugten Reason Codes sind dieselben Artefakte, die eine DSGVO-Auskunftsanfrage beantworten, gezogen aus demselben Snapshot – sodass die Geschichte, die einer Person erzählt wird, nie davon abhängt, welche Regulierung die Frage ausgelöst hat. Auseinanderlaufende Erklärungen über verschiedene Kanäle sind genau das, woran Organisationen ertappt werden, weil die Person sie vergleicht.
Nichts davon verlangt, dass ein Mensch jede Entscheidung berührt – das ist die Befürchtung, die solche Projekte ins Stocken bringt. Es verlangt, dass in den Anwendungsbereich fallende Entscheidungen einen Audit-Trail tragen, der dicht genug ist, um sie zu rekonstruieren und anzufechten; dass der Pfad der menschlichen Prüfung dort echte Befugnis hat, wo Sie eine solche behaupten; und dass die Schwelle, die Automatisiertes von Geprüftem trennt, eine bewusste, dokumentierte Zahl ist statt eines Zufalls dort, wo jemand einen Cutoff gesetzt hat. Bauen Sie diese drei, und Straight-Through-Processing und Artikel 22 stehen nicht länger im Widerspruch.
Häufige Fragen
Verbietet die DSGVO automatisierte Kreditentscheidungen?
Nein. Artikel 22 beschränkt Entscheidungen, die ausschließlich auf automatisierter Verarbeitung beruhen und rechtliche oder ähnlich erhebliche Wirkung entfalten. Er erlaubt sie jedoch, wenn sie für einen Vertrag erforderlich, gesetzlich zulässig oder durch ausdrückliche Einwilligung gedeckt sind – vorausgesetzt, Sie ermöglichen menschliches Eingreifen, die Darlegung des eigenen Standpunkts und die Anfechtung der Entscheidung.
Gibt es in der DSGVO tatsächlich ein Recht auf Erklärung?
Der verbindliche Text gewährt betroffenen Personen aussagekräftige Informationen über die involvierte Logik (Artikel 13 bis 15). Ein ausdrückliches Recht auf Erklärung einer konkreten Entscheidung findet sich in Erwägungsgrund 71, der auslegend, aber für sich genommen nicht durchsetzbar ist. Wir bauen ohnehin für die strengere Lesart.
Nimmt ein Mensch, der auf „Genehmigen“ klickt, eine Entscheidung aus Artikel 22 heraus?
Nur wenn dieser Mensch echte Befugnis und ausreichende Informationen hat, um das Ergebnis zu ändern. Ein Prüfer, der einen Score ohne die Daten oder das Mandat zum Übersteuern abnickt, macht die Entscheidung nicht zu einer nicht automatisierten – und Aufsichtsbehörden haben das genau so festgestellt.