Hat das CJEU-SCHUFA-Urteil SCHUFA verboten?

Nein. Das Urteil hat nicht den SCHUFA-Score selbst für unzulässig erklärt, sondern festgestellt, dass die Score-Berechnung selbst eine automatisierte Einzelfallentscheidung im Sinne von Art. 22 DSGVO ist, wenn der Score maßgeblich für eine Entscheidung eines Dritten verwendet wird. SCHUFA und vergleichbare Auskunfteien arbeiten weiter, aber unter strengeren Transparenz-, Auskunfts- und Begründungspflichten. Außerdem braucht es jetzt eine der Ausnahmen aus Art. 22 Abs. 2 DSGVO (Einwilligung, Vertrag, Rechtsvorschrift), um einen solchen Score in einer substantiellen Entscheidung verwenden zu können.

Ist kvit ein Hochrisiko-KI-System nach EU AI Act?

Nein. Annex III §5(b) erfasst KI-Systeme, die zur Bewertung der Kreditwürdigkeit natürlicher Personen oder zur Ermittlung deren Bonität bestimmt sind. kvit bewertet Rechnungen als vertragliche Dokumente — das Subjekt des Scores ist nicht die natürliche Person, sondern das Dokument und die Geschäftsbeziehung. Wir verarbeiten zwar personenbezogene Daten (Kontaktdaten des Schuldners), aber das System trifft keine Aussage über die Kreditwürdigkeit dieser Person.

Worin liegt der Unterschied zwischen Rechnungs- und Personen-Scoring praktisch?

Im Datenmodell, in den Eingangsdaten und in der Ausgabe. Personen-Scoring nimmt persönliche Merkmale (Wohnort, vergangene Kredite, Online-Verhalten, demografische Variablen) und gibt einen Wert aus, der etwas über die Person aussagen soll. Rechnungs-Scoring nimmt rechnungs-spezifische Merkmale (Betrag, Tage seit Fälligkeit, Antwortverhalten auf vorherige Mahnungen für diese Rechnung) und gibt einen Wert aus, der etwas über die Wahrscheinlichkeit der Begleichung dieser Rechnung aussagt. Eine identische Person mit zwei verschiedenen Rechnungen kann zwei verschiedene Rechnungs-Scores haben, ohne dass das die Person beurteilt.

Brauche ich als kvit-Kunde eine Datenschutz-Folgenabschätzung (DSFA)?

Nicht automatisch. Eine DSFA nach Art. 35 DSGVO ist erforderlich, wenn die Verarbeitung voraussichtlich ein hohes Risiko für die Rechte und Freiheiten natürlicher Personen birgt. Für die Standard-B2B-Konstellation (Schuldner sind juristische Personen, kvit verarbeitet nur Kontaktdaten der Ansprechpartner zur Mahn-Kommunikation) ist die DSFA-Pflicht in der Regel zu verneinen. Wir stellen Kunden auf Anfrage eine vorausgefüllte Risiko-Bewertung zur Verfügung, mit der die DSFA-Prüfung effizient durchführbar wird, falls Ihr DSB sie für nötig hält.

Was, wenn die EU-Regulierung sich ändert und Annex III §5(b) erweitert wird?

Wir verfolgen die regulatorische Entwicklung kontinuierlich. Sollte payment-behaviour-scoring eines Tages explizit unter Annex III aufgenommen werden, würden wir die Hochrisiko-Pflichten erfüllen — Konformitätsbewertung, Risikomanagement, EU-Datenbank-Eintragung. Die fundamentale Architektur (Score-am-Vertrag, nicht-an-der-Person) würden wir auch dann beibehalten, weil sie unabhängig von der Regulierung die operativ und ethisch sauberere Lösung ist. Kunden würden frühzeitig informiert; bestehende Verträge würden nicht rückwirkend belastet.

Wie sehe ich, ob meine bestehende Forderungs-Software EU-AI-Act-konform ist?

Vier Indikatoren. (1) Hat der Anbieter eine schriftliche Stellungnahme zur AI-Act-Einordnung — und benennt er Annex III §5(b) explizit? Schweigen ist verdächtig. (2) Wie ist das Datenmodell organisiert — gibt es ein **debtor_credit_score**-Feld oder ein **invoice_default_probability**-Feld? Letzteres ist sauber, ersteres riskant. (3) Welche externen Bonitäts-Datenquellen werden abgerufen — SCHUFA, Creditreform, Bisnode? Diese sind in der Personen-Bewertungs-Zone. (4) Gibt es einen Sub-Verarbeiter-Auflistung, eine AVV-Vorlage, EU-Datenresidenz schriftlich? Wenn nicht, ist die Compliance-Architektur ohnehin lückenhaft.

Architektur

SCHUFA, der EU AI Act, und warum kvit Rechnungen bewertet — nicht Personen

Kyle Nelson8. Juni 2026

Mit dem CJEU-SCHUFA-Urteil von 2023 und der Inkraftsetzung des EU AI Act 2024 hat sich für automatisiertes Scoring in der EU der rechtliche Spielraum dramatisch verändert. Wer eine KI-gestützte Forderungs-Software einsetzt, sollte verstehen, wo die Trennlinie zwischen Hochrisiko-System und nicht-hochriskanter Software verläuft — und welche Architekturentscheidungen dahinter stehen. Dieser Beitrag erklärt die Rechtslage präzise und zeigt, warum kvit von Anfang an Rechnungen bewertet, nicht Personen.

Was die CJEU-SCHUFA-Entscheidung tatsächlich gesagt hat

Am 7. Dezember 2023 entschied der Europäische Gerichtshof in der Rechtssache C-634/21 (OQ gegen Land Hessen, betreffend SCHUFA), dass die automatisierte Berechnung eines Wahrscheinlichkeitswerts über die Zahlungsfähigkeit einer natürlichen Person eine automatisierte Einzelfallentscheidung im Sinne von Artikel 22 Absatz 1 DSGVO darstellt — sobald dieser Wert eine maßgebliche Rolle bei einer nachfolgenden Entscheidung eines Dritten spielt.

Konkret: Wenn eine Bank ihre Kreditentscheidung maßgeblich auf einen SCHUFA-Score stützt, dann gilt nicht erst die Kreditentscheidung der Bank, sondern bereits die Score-Berechnung selbst als automatisierte Einzelfallentscheidung mit allen damit verbundenen Schutzpflichten. SCHUFA wird damit zum Verantwortlichen im Sinne von Art. 22 DSGVO — nicht nur die Bank, die den Score abfragt.

Die unmittelbaren Folgen für die Praxis:

Automatisiertes Personen-Scoring ist nicht ohne Weiteres zulässig. Es braucht eine der Ausnahmen aus Art. 22 Abs. 2 DSGVO: ausdrückliche Einwilligung der betroffenen Person, vertragliche Notwendigkeit oder eine nationale Rechtsvorschrift.
Der Score-Anbieter steht in der Verantwortung. Wer ein Personen-Scoring an Dritte verkauft, kann sich nicht mehr darauf zurückziehen, dass die Entscheidung erst beim Abnehmer fällt.
Transparenz- und Auskunftspflichten verschärfen sich. Betroffene haben einen Anspruch auf aussagekräftige Information über die Logik des Scorings (Art. 15 Abs. 1 lit. h DSGVO).
Ähnliche Konstellationen wurden mitgemeint. Das Urteil wirkt weit über SCHUFA hinaus — auf jede Software, die personenbezogene Wahrscheinlichkeitswerte berechnet und an Dritte für deren substanzielle Entscheidungen liefert.

EU AI Act Annex III §5(b) — die nächste Ebene

Der EU AI Act (Verordnung 2024/1689) trat am 1. August 2024 in Kraft, mit gestaffelten Anwendungszeitpunkten bis 2027. Annex III listet die KI-Anwendungen, die als hochriskant gelten und damit den umfangreichen Pflichten aus Kapitel III unterworfen sind.

Annex III §5(b) erfasst:

KI-Systeme, die dazu bestimmt sind, die Kreditwürdigkeit natürlicher Personen zu bewerten oder deren Bonität zu ermitteln, mit Ausnahme von KI-Systemen, die zur Aufdeckung von Finanzbetrug eingesetzt werden.

Was diese Klassifikation auslöst, wenn sie greift:

Konformitätsbewertung vor Inverkehrbringen (Art. 43 AI Act) — entweder intern oder durch eine benannte Stelle, je nach Anwendungsfall.
Risikomanagementsystem über den gesamten Lebenszyklus (Art. 9).
Data Governance mit Anforderungen an Trainings-, Validierungs- und Testdaten (Art. 10).
Technische Dokumentation (Art. 11) und Logging (Art. 12).
Transparenz gegenüber Nutzern (Art. 13) und menschliche Aufsicht (Art. 14).
Eintragung in die EU-Datenbank (Art. 49) und CE-Kennzeichnung.
Post-Market-Monitoring und Berichtspflicht bei schwerwiegenden Vorfällen (Art. 72, 73).

Was Annex III §5(b) konkret kostet

Die Anforderungen oben sind nicht symbolisch. Wer ein Hochrisiko-System nach Art. 6 Abs. 2 AI Act in den Verkehr bringt, baut faktisch eine zweite Compliance-Organisation neben dem eigentlichen Produkt auf:

Eine Konformitätsbewertung dauert je nach Komplexität sechs bis achtzehn Monate. Die laufenden Pflichten — Risikomanagement, technische Dokumentation, Logging, Post-Market-Monitoring — sind keine Einmalaktion, sondern dauerhafte Funktionen, die personell besetzt sein müssen. Schätzungen aus der Industrie sehen die jährlichen Kosten für ein mittelgroßes Hochrisiko-KI-System im hohen sechsstelligen Bereich.

Das ist nicht falsch oder ungerecht — für ein System, das die Lebenschancen einer Person beeinflusst (Kreditvergabe, Vermietung, Versicherung), sind diese Anforderungen sachlich begründet. Aber es ist eine bewusste Hürde, die der Gesetzgeber gesetzt hat. Wer sie umgeht, indem er das System anders aufbaut, statt es konform zu machen, betreibt keine Regulierungs-Arbitrage — er nutzt den vom Gesetzgeber vorgesehenen Differenzierungs-Spielraum.

Die Architekturentscheidung: Rechnungen scoren, nicht Personen

kvit berechnet einen Score — einen Wahrscheinlichkeitswert, mit dem eine Rechnung in einer bestimmten Zeit beglichen wird. Aber das Subjekt dieses Scores ist die Rechnung als vertragliches Dokument, nicht die natürliche Person, die der Schuldner ist.

Konkret bedeutet das:

Eingangsdaten sind Rechnungs-spezifisch: Betrag, Tage seit Fälligkeit, vorherige Mahnstufen auf dieser konkreten Rechnung, Kanal-Antwortverhalten auf dieser Rechnung, Branche und Geschäftsmodell des Schuldners als juristischer Person.
Eingangsdaten sind explizit NICHT: SCHUFA-Score oder vergleichbare externe Bonitäts-Signale, persönliche Daten der natürlichen Personen hinter dem Schuldner-Unternehmen, Wohnortdaten, Online-Verhalten, persönliches Zahlungshistorien-Profil.
Ausgabe ist ein Rechnungs-Attribut: Der Score landet im Datensatz invoice, nicht im Datensatz person oder debtor_contact. Er informiert die Wahl der Mahn-Strategie für genau diese Rechnung — nicht eine generelle Aussage über die Kreditwürdigkeit eines Menschen.
Anwendungskontext ist B2B-Forderungsmanagement. Die Schuldnerseite ist überwiegend eine juristische Person (Unternehmen), die nicht in den Schutzbereich von Art. 22 DSGVO fällt. Wo natürliche Personen Schuldner sind (B2C-Restbestände), gilt zusätzliche Sorgfalt — siehe nächster Abschnitt.

Warum das mehr ist als juristische Kosmetik

Die Differenzierung zwischen Rechnungs- und Personen-Scoring hat drei konkrete operative Konsequenzen für jeden, der kvit als Tool einsetzt:

Keine Hochrisiko-System-Pflichten. Da das System nicht in Annex III §5(b) fällt, entfällt der gesamte Pflichtenkanon aus Kapitel III des AI Act — Konformitätsbewertung, EU-Datenbank-Eintragung, CE-Kennzeichnung, Post-Market-Monitoring auf dieser Ebene. Das macht das Produkt günstiger und schneller anpassbar, ohne die Schutzziele zu untergraben.

Schlankere Datenschutz-Folgenabschätzung. Eine DSFA nach Art. 35 DSGVO ist nicht automatisch erforderlich. Sie kann je nach Einsatzkontext sinnvoll sein (B2B mit Einzelunternehmern, große Datenmengen), aber sie ist kein strict requirement ohne Anlass.

Kein Art. 22-Konflikt. Da kvit nicht automatisiert über natürliche Personen entscheidet (es entscheidet darüber, welche Mahn-Aktion auf eine Rechnung folgt), kollidiert das System nicht mit Art. 22 Abs. 1 DSGVO. Das vereinfacht den Rechtsrahmen erheblich.

Wo wir transparent sind: die Grenzen unserer Architektur

Intellektuelle Ehrlichkeit verlangt, auch die Grenzen dieser Architektur zu benennen:

Personenbezogene Daten werden verarbeitet — Schuldner-Kontaktdaten (Name, E-Mail, Telefon, Anschrift), die für die Mahn-Kommunikation notwendig sind. Diese Verarbeitung läuft über Art. 6 Abs. 1 lit. b DSGVO (Vertragsdurchführung / vorvertragliche Maßnahmen) oder Art. 6 Abs. 1 lit. f (berechtigtes Interesse). Die DSGVO-Pflichten — Information, Auskunft, Löschung, Datenresidenz — gelten vollumfänglich.

Wenn der Schuldner eine natürliche Person ist (Einzelunternehmer, Freiberufler, B2C-Forderungen), nähert sich der Anwendungsfall der Grenze. Wir behandeln diese Fälle mit zusätzlicher Sorgfalt: keine pauschale Bonitäts-Aussage, keine Speicherung von Scores im Personen-Profil, jede menschlich überprüfbare Entscheidung bleibt menschlich überprüfbar.

Der Score informiert workflow-Entscheidungen, ist aber human-überschreibbar. Welche Mahnstufe als nächstes geht, welcher Kanal genutzt wird, wann an den Partner für das gerichtliche Mahnverfahren übergeben wird — überall steht ein menschlicher Freigabe-Schritt zur Verfügung. Der Score schlägt vor, der Mensch entscheidet.

Jede automatisierte Aktion ist hash-chain logged. Auch wenn das nicht aus der AI-Act-Hochrisiko-Klassifikation folgt — wir haben den lückenlosen, unveränderlichen Audit-Log von Anfang an implementiert, weil er für Compliance-Reviews, Audit-Trails und schlicht für gutes Engineering der Default sein sollte.

Was das für die Buyer-Diligence bedeutet

Wer als CFO, Datenschutzbeauftragter oder Legal Counsel eine KI-Forderungs-Software evaluiert, kann mit fünf gezielten Fragen sehr schnell die Spreu vom Weizen trennen:

Was genau bewertet das System — die natürliche Person oder die Rechnung / den Vertrag? Die Antwort muss präzise sein, mit Verweis auf die Datenmodell-Felder.
Welche Eingangsdaten fließen in den Score ein? Insbesondere: gibt es SCHUFA-Abrufe, Bonitätsdaten aus externen Quellen, persönliche Verhaltensdaten der natürlichen Personen?
Hat der Anbieter eine AI-Act-Konformitätsbewertung durchgeführt? Wenn ja, warum war sie nötig? Wenn das System nicht hochriskant ist, ist die Antwort: nein, war nicht nötig.
Wo liegen die Daten und wer ist Auftragsverarbeiter? EU-Datenresidenz ist 2026 Marktstandard, nicht Premium-Feature. Sub-Verarbeiter müssen aufgelistet und vertraglich gebunden sein.
Wie wird eine einzelne automatisierte Aktion dokumentiert? Audit-Log auf Pflicht-Ebene reicht; hash-chain-gesicherter Log ist besser. Bei DSGVO-Auskunftsanfragen muss man jeden Schritt rekonstruieren können.

Was passiert, wenn sich die Rechtslage verschiebt

Die Regulierung in diesem Bereich ist nicht statisch. In Brüssel laufen mindestens drei Bewegungen, die unsere Architektur betreffen können:

Die Revision der Datenschutz-Folgenabschätzung-Liste durch nationale Aufsichtsbehörden — manche bauen Forderungsmanagement explizit in die Pflicht-DSFA-Liste ein, was die Anforderungen erhöht, ohne den AI Act zu berühren.

Brüssel-Diskussionen über Annex-III-Erweiterungen. Es gibt Lobby-Bewegungen, payment behaviour scoring explizit unter Annex III aufzunehmen. Das wäre eine substanzielle Verschiebung — und der Hauptgrund, warum wir die Architektur dokumentiert und versionierbar halten.

Nationale Umsetzungs-Spezifika in Deutschland, Österreich und der Schweiz. Manche Behörden gehen strenger vor als der EU-Standard fordert; wir tracken die Entwicklung pro Markt.

Worst-case-Szenario: Wenn unsere Architektur eines Tages doch unter Annex III §5(b) fallen sollte, würden wir explizite Einwilligungs-Flows für jeden Schuldner einbauen und die zusätzlichen Hochrisiko-Pflichten erfüllen. Aber die Grundstruktur — Score-am-Vertrag, nicht-an-der-Person — würden wir nicht ändern. Sie ist unabhängig von der Regulierung die ehrlichere Antwort auf das Problem.

Häufige Fragen

Hat das CJEU-SCHUFA-Urteil SCHUFA verboten?: Nein. Das Urteil hat nicht den SCHUFA-Score selbst für unzulässig erklärt, sondern festgestellt, dass die Score-Berechnung selbst eine automatisierte Einzelfallentscheidung im Sinne von Art. 22 DSGVO ist, wenn der Score maßgeblich für eine Entscheidung eines Dritten verwendet wird. SCHUFA und vergleichbare Auskunfteien arbeiten weiter, aber unter strengeren Transparenz-, Auskunfts- und Begründungspflichten. Außerdem braucht es jetzt eine der Ausnahmen aus Art. 22 Abs. 2 DSGVO (Einwilligung, Vertrag, Rechtsvorschrift), um einen solchen Score in einer substantiellen Entscheidung verwenden zu können.
Ist kvit ein Hochrisiko-KI-System nach EU AI Act?: Nein. Annex III §5(b) erfasst KI-Systeme, die zur Bewertung der Kreditwürdigkeit natürlicher Personen oder zur Ermittlung deren Bonität bestimmt sind. kvit bewertet Rechnungen als vertragliche Dokumente — das Subjekt des Scores ist nicht die natürliche Person, sondern das Dokument und die Geschäftsbeziehung. Wir verarbeiten zwar personenbezogene Daten (Kontaktdaten des Schuldners), aber das System trifft keine Aussage über die Kreditwürdigkeit dieser Person.
Worin liegt der Unterschied zwischen Rechnungs- und Personen-Scoring praktisch?: Im Datenmodell, in den Eingangsdaten und in der Ausgabe. Personen-Scoring nimmt persönliche Merkmale (Wohnort, vergangene Kredite, Online-Verhalten, demografische Variablen) und gibt einen Wert aus, der etwas über die Person aussagen soll. Rechnungs-Scoring nimmt rechnungs-spezifische Merkmale (Betrag, Tage seit Fälligkeit, Antwortverhalten auf vorherige Mahnungen für diese Rechnung) und gibt einen Wert aus, der etwas über die Wahrscheinlichkeit der Begleichung dieser Rechnung aussagt. Eine identische Person mit zwei verschiedenen Rechnungen kann zwei verschiedene Rechnungs-Scores haben, ohne dass das die Person beurteilt.
Brauche ich als kvit-Kunde eine Datenschutz-Folgenabschätzung (DSFA)?: Nicht automatisch. Eine DSFA nach Art. 35 DSGVO ist erforderlich, wenn die Verarbeitung voraussichtlich ein hohes Risiko für die Rechte und Freiheiten natürlicher Personen birgt. Für die Standard-B2B-Konstellation (Schuldner sind juristische Personen, kvit verarbeitet nur Kontaktdaten der Ansprechpartner zur Mahn-Kommunikation) ist die DSFA-Pflicht in der Regel zu verneinen. Wir stellen Kunden auf Anfrage eine vorausgefüllte Risiko-Bewertung zur Verfügung, mit der die DSFA-Prüfung effizient durchführbar wird, falls Ihr DSB sie für nötig hält.
Was, wenn die EU-Regulierung sich ändert und Annex III §5(b) erweitert wird?: Wir verfolgen die regulatorische Entwicklung kontinuierlich. Sollte payment-behaviour-scoring eines Tages explizit unter Annex III aufgenommen werden, würden wir die Hochrisiko-Pflichten erfüllen — Konformitätsbewertung, Risikomanagement, EU-Datenbank-Eintragung. Die fundamentale Architektur (Score-am-Vertrag, nicht-an-der-Person) würden wir auch dann beibehalten, weil sie unabhängig von der Regulierung die operativ und ethisch sauberere Lösung ist. Kunden würden frühzeitig informiert; bestehende Verträge würden nicht rückwirkend belastet.
Wie sehe ich, ob meine bestehende Forderungs-Software EU-AI-Act-konform ist?: Vier Indikatoren. (1) Hat der Anbieter eine schriftliche Stellungnahme zur AI-Act-Einordnung — und benennt er Annex III §5(b) explizit? Schweigen ist verdächtig. (2) Wie ist das Datenmodell organisiert — gibt es ein debtor_credit_score-Feld oder ein invoice_default_probability-Feld? Letzteres ist sauber, ersteres riskant. (3) Welche externen Bonitäts-Datenquellen werden abgerufen — SCHUFA, Creditreform, Bisnode? Diese sind in der Personen-Bewertungs-Zone. (4) Gibt es einen Sub-Verarbeiter-Auflistung, eine AVV-Vorlage, EU-Datenresidenz schriftlich? Wenn nicht, ist die Compliance-Architektur ohnehin lückenhaft.

Weiterlesen

KI im ForderungsmanagementVertiefung zu den konkreten LLM-Einsatzpunkten — wo wir Sprachmodelle verwenden und wo wir bewusst auf deterministische Software setzen.
Inkasso Software — Vollständiger VergleichWo kvit gegenüber den klassischen Anbietern und den anderen Software-Stacks steht, inkl. Compliance-Architektur.
Warum kvit — ein Brief vom GründerDie Hintergrund-Entscheidung, warum kvit von Anfang an Rechnungen statt Personen bewertet — Teil der DNA, nicht nachträglicher Compliance-Patch.
ViDA E-Rechnung Pflicht 2028 — Vollständiger GuideDie zweite große EU-Bewegung, die unsere Architektur prägt: strukturierte E-Rechnungen als Eingangsformat.

Architektur-Dokumentation für Ihren Datenschutzbeauftragten

kvit stellt Kunden auf Anfrage die vollständige Datenmodell- und Datenfluss-Dokumentation zur Verfügung — Sub-Verarbeiter-Liste, AVV-Vorlage, AI-Act-Einordnung, DSFA-Vorausfüllung. Schreiben Sie uns an legal@kvit.ai.

Dokumentation anfordern