Sozialleistungsmissbrauchs-Mustererkennung

Das echte Ausmaß des Problems

Viele Überzahlungen entstehen ohne Absicht: falsche Angaben aus Unkenntnis, veraltete Informationen, vergessene Meldepflichten. Maschinelle Abgleiche sind in der Sozialverwaltung trotzdem keine Theorie. Der automatisierte Datenabgleich nach § 52 SGB II prüft Bürgergeldbeziehende viermal im Jahr, zum 1. Januar, 1. April, 1. Juli und 1. Oktober, unter anderem gegen Leistungen der Renten- und Unfallversicherung. Der Unterschied zu diesem Use Case: Dieser Abgleich ist gesetzlich geregelt, mit festem Katalog von Stellen und Daten. Ein Modell, das frei über Sachbereiche hinweg nach Mustern sucht, hat diese Grundlage nicht automatisch.

Das eigentliche Problem ist die Fragmentierung:

• Ein Antragsteller kann gleichzeitig Wohngeld beim Stadtamt, Bürgergeld beim Jobcenter und Kinderzuschlag bei der Familienkasse beantragen, drei verschiedene Behörden, drei Datensilos, drei Sachbearbeitende, die selten miteinander sprechen
• Quervergleiche zwischen Leistungsarten sind in den meisten Kommunen nicht möglich, weil Datenschutzvorgaben den systemübergreifenden Zugriff einschränken
• Sachbearbeitende haben für die inhaltliche Prüfung eines Antrags oft nur wenige Minuten, zu wenig, um Widersprüche zu Informationen in anderen Systemen manuell zu suchen
• Inkonsistente Angaben (Einkommenswechsel nicht gemeldet, Umzug ohne Ummeldung, gleichzeitige Mehrfachbeantragung) bleiben deshalb häufig jahrelang unbemerkt

Das Schadenspotenzial ist schwer zu beziffern, eine belastbare bundesweite Zahl zu Mehrfachauszahlungen über Sachbereiche hinweg haben wir nicht gefunden. Wer das Projekt begründen will, sollte deshalb zuerst die eigenen Rückforderungsfälle der letzten Jahre auswerten.

Mit vs. ohne KI, ein ehrlicher Vergleich

Hinweis zur Tabelle: Veröffentlichte Erkennungsraten aus deutschen Projekten haben wir nicht gefunden. Die europäischen Erfahrungen mahnen eher zur Vorsicht: Nach Recherchen der Volkskrant (2019), dokumentiert von AlgorithmWatch, hat das niederländische System SyRI in keiner seiner Stadtteilanalysen neue Betrugsfälle aufgedeckt.

Das Schlüsselmerkmal dieses Ansatzes ist, was er nicht tut: Er lehnt keine Anträge ab. Er setzt keine Sanktionen. Er trifft keine Entscheidungen. Er markiert Anträge mit Hinweisen, und ein Mensch entscheidet dann, ob der Hinweis einer Prüfung wert ist.

Einschätzung auf einen Blick

Zeitersparnis, mittel (3/5) Das Modell beschleunigt den Prüfprozess spürbar: Ohne maschinelle Unterstützung sind Querprüfungen über Sachbereiche schlicht nicht vorgesehen, nicht weil niemand will, sondern weil der Aufwand ohne System unverhältnismäßig wäre. Jeder Hinweis, den das System auswirft, braucht jedoch menschliche Nachbearbeitung. Die Zeitersparnis liegt deshalb nicht in der Prüfzeit je Fall, sondern darin, dass Prüfungen überhaupt systematisch stattfinden. Mittlerer Wert für diese Branche: signifikant gegenüber dem Ist-Zustand, aber kein kurzfristiger Entlastungseffekt.

Kosteneinsparung, niedrig (1/5) Dies ist der ehrlichste Score in diesem Anwendungsfall. Der Nutzen entsteht indirekt: verhinderte Fehlzahlungen, gesparte Rückforderungsverfahren, weniger aufwändige Nachprüfungen. Aber dieser Nutzen ist schwer zu quantifizieren, politisch heikel zu kommunizieren, und er landet oft nicht bei der Kommune, die das System bezahlt: Das Wohngeld tragen Bund und Länder, beim Bürgergeld trägt die Kommune vor allem die Kosten der Unterkunft. Dazu kommt die Prüfzeit für jeden Hinweis. Die laufenden Kosten allein können die verhinderten Fehlzahlungen aufzehren, die Rechnung weiter unten zeigt es. Beim direkten Kostenhebel gehört der Use Case zu den schwächsten der Kategorie.

Schnelle Umsetzung, niedrig (2/5) Vergaberecht, Datenschutzfolgenabschätzung, Rechtsgrundlagenprüfung, Beteiligungsrechte des Personalrats, Datenvorbereitung, Schulung: Realistisch vergehen zwölf bis achtzehn Monate von der Entscheidung bis zum Produktivbetrieb. Das ist kein technisches Problem, die Modelle sind erprobt, sondern ein verwaltungsrechtliches. Wer das unterschätzt, scheitert an der Beschaffung, nicht am Algorithmus.

ROI-Sicherheit, mittel (3/5) Der Nutzen ist prinzipiell messbar: wie viele Hinweise wurden gegeben, wie viele davon bestätigten sich, wie hoch war das verhinderte Fehlzahlungsvolumen? Das Problem: Diese Zahlen werden in Deutschland von Behörden selten öffentlich kommuniziert. Der Nutzen muss aktiv gemessen und intern kommuniziert werden, er erscheint nicht von selbst in der Bilanz.

Skalierbarkeit, niedrig (1/5) Das ist das härteste Limit dieses Anwendungsfalls. Eine Lösung, die in einer Behörde funktioniert, kann nicht einfach auf die nächste übertragen werden: Jede Behörde hat eigene Datenstrukturen, eigene rechtliche Zuständigkeiten, eigene IT-Dienstleister und braucht eine eigene Datenschutzfolgenabschätzung. Das Konzept skaliert, aber jede neue Instanz kostet fast so viel wie die erste. govdigital und der Onlinezugangsgesetz-Rahmen arbeiten an gemeinsamen Infrastrukturen, aber der produktionsreife, plattformübergreifende Standard ist noch nicht da.

Richtwerte, stark abhängig von Behördengröße, vorhandener Dateninfrastruktur und rechtlicher Ausgangslage.

Was das Hinweissystem konkret macht

Das System arbeitet mit Machine Learning auf strukturierten Antragsdaten, nicht mit freiem Text, Gesichtserkennung oder Sprachauswertung. Das ist wichtig, weil der Datenschutzrahmen davon direkt abhängt.

Konkret verarbeitet das Modell folgende Datenpunkte:

• Antragsdaten aus einem Sachbereich (z. B. Bürgergeld): Haushaltsgröße, Adresse, gemeldete Mietkosten, Einkommensverhältnisse
• Referenzdaten aus anderen bewilligten Leistungen in derselben Behörde (z. B. Wohngeld für dieselbe Adresse)
• Historische Inkonsistenzmuster aus abgeschlossenen Prüffällen, was hat sich in der Vergangenheit als tatsächliche Auffälligkeit bestätigt?

Was das Modell ausgibt: Keine Entscheidung. Kein Score mit Persönlichkeitsprofil. Sondern: „Antrag ID-4817 weist folgende Inkonsistenz auf: Mietkosten werden für dieselbe Adresse gleichzeitig im Wohngeldbereich geltend gemacht. Empfehlung: Querprüfung mit Wohngeldakte.”

Ein Sachbearbeiter sieht diesen Hinweis und entscheidet eigenständig: Prüfe ich das nach? Ist die Inkonsistenz erklärbar? Brauche ich weitere Unterlagen?

Was das Modell nicht darf, und deshalb auch nicht tut:

• Anträge automatisch ablehnen oder bewilligen
• Verdachtsvermerke dauerhaft in der Verfahrensakte anlegen
• Risikoscores über Personen ohne Transparenz und Widerspruchsmöglichkeit speichern
• Entscheidungen treffen, die nur auf Algorithmusergebnissen basieren, ohne menschliche Prüfung

Der technische Ansatz verwendet typischerweise Anomalieerkennung (Isolation Forest, Local Outlier Factor) oder überwachtes Lernen (Random Forest, Gradient Boosting) auf historischen Antragsdaten. Die Details hängen von der Datenverfügbarkeit ab, aber die Grundarchitektur ist einfacher als bei vielen anderen ML-Projekten, weil die Daten strukturiert sind und das Modell keine Sprachintelligenz braucht.

Rechtlicher Rahmen: Was das Modell darf, und was es nicht darf

Das ist kein Fußnotenthema. Der rechtliche Rahmen bestimmt die Systemarchitektur, die Beschaffungsstrategie, die Logging-Anforderungen und den Workflow, und er ist der häufigste Grund, warum ähnliche Projekte in Deutschland scheitern oder gar nicht erst gestartet werden.

DSGVO Art. 22, das zentrale Verbot: Art. 22 DSGVO verbietet ausschließlich automatisierte Entscheidungen, die rechtliche Wirkung haben oder die betroffene Person erheblich beeinträchtigen, ohne menschliche Überprüfung. Das ist genau das Szenario, das dieses System vermeiden muss. Solange das Modell nur Hinweise gibt und ein Mensch entscheidet, greift Art. 22 nicht. Sobald das System de facto Anträge blockiert (auch wenn formal ein Mensch zustimmt, aber nie widerspricht), ist die Grenze überschritten.

EU AI Act, einschlägig ist Anhang III Nummer 5 Buchstabe a: Nummer 5 Buchstabe a erfasst KI-Systeme, die von Behörden oder in deren Namen verwendet werden, um zu beurteilen, ob natürliche Personen Anspruch auf grundlegende öffentliche Unterstützungsleistungen haben und ob solche Leistungen zu gewähren, einzuschränken, zu widerrufen oder zurückzufordern sind. Die Missbrauchserkennung in der Leistungsverwaltung liegt genau dort. Buchstabe b passt nicht, er betrifft die Kreditwürdigkeits- und Bonitätsbewertung natürlicher Personen und nimmt die Aufdeckung von Finanzbetrug sogar ausdrücklich aus. Diese Ausnahme hilft hier nicht weiter, sie steht in Buchstabe b und schränkt Buchstabe a nicht ein. Ob das konkrete System hochriskant ist, entscheidet deshalb Art. 6 Abs. 3. Die dort genannte Ausnahme für Systeme, die Abweichungen von früheren Entscheidungsmustern erkennen, meint etwa ein Werkzeug, das die Konsistenz der eigenen Bescheide prüft, und sie gilt nur, wenn das System die menschliche Bewertung weder ersetzt noch beeinflusst. Ein Hinweissystem, das einzelne Anträge zur Prüfung markiert, beeinflusst die Bewertung, darauf ist es angelegt. Die Ausnahme endet außerdem hart: Sobald das System ein Profiling natürlicher Personen vornimmt, gilt es immer als hochriskant, und ein Modell, das Antragstellende nach persönlichen Merkmalen in eine Risikorangfolge bringt, tut genau das. Wer sich auf die Ausnahme beruft, dokumentiert die Bewertung nach Art. 6 Abs. 4 und registriert das System nach Art. 49 Abs. 2 trotzdem, diese Pflicht gilt seit dem 2. August 2026. Die Hochrisiko-Anforderungen selbst, Datensatz-Dokumentation, Bias-Prüfung, menschliche Aufsicht, Logging und Informationspflichten, stehen in Kapitel III Abschnitte 1 bis 3 und greifen für Anhang-III-Systeme erst ab dem 2. Dezember 2027. Für die Behörde als Betreiberin gehört dazu vor der ersten Inbetriebnahme die Grundrechte-Folgenabschätzung nach Art. 27, die Einrichtungen des öffentlichen Rechts ausdrücklich trifft; Teile einer vorhandenen Datenschutz-Folgenabschätzung lassen sich nach Art. 27 Abs. 4 übernehmen. Wer ein solches System vor dem 2. Dezember 2027 in Betrieb nimmt, muss es als Behörde spätestens bis zum 2. August 2030 an die Anforderungen anpassen (Art. 111 Abs. 2 in der Fassung der Verordnung (EU) 2026/1744). Plane also mit der Hochrisiko-Einstufung, nicht mit der Ausnahme.

Grundgesetz Art. 19 Abs. 4, Rechtsweg muss offen bleiben: Jede betroffene Person muss die Möglichkeit haben, gegen eine behördliche Entscheidung, die auf einem algorithmischen Hinweis basiert, Rechtsmittel einzulegen. Das System muss deshalb vollständig protokollieren: Welcher Hinweis wurde wann gegeben, auf welcher Datengrundlage, welche menschliche Entscheidung folgte daraus. Ohne lückenlose Dokumentation ist der Rechtsweg faktisch versperrt.

SGB II und weitere Fachgesetze: Die Fachgesetze (SGB II, SGB XII, WoGG) regeln, welche Stellen welche Daten für welchen Zweck nutzen dürfen. Eine Querprüfung zwischen Bürgergeld- und Wohngeld-Daten ist nicht automatisch erlaubt, nur weil beide in derselben Kommunalverwaltung liegen. Die Zweckbindung der Sozialdaten (§ 67c SGB X) begrenzt den Datenaustausch, auch behördenintern, eine Übermittlung braucht eine Befugnis, etwa nach § 69 SGB X. Wer das umgeht, riskiert Beweisverwertungsverbote und Haftung.

Das Hinweissystem-Design als juristische Kategorie: Juristen in Datenschutzbehörden und Gerichten unterscheiden in der Praxis zwischen „Hinweissystem” (Entscheidungsunterstützung) und „Risikoklassifizierungssystem” (Scoring von Personen). Ersteres ist erheblich leichter rechtlich zu verankern. Die Bezeichnung allein reicht aber nicht, es kommt auf die tatsächliche Funktion an. Wenn ein System zwar formal als Hinweissystem gilt, aber in der Praxis dazu führt, dass 95 Prozent aller markierten Anträge ohne weitere Prüfung abgelehnt werden, ist es faktisch ein automatisiertes Entscheidungssystem, unabhängig vom Namen.

Empfehlung: Beauftrage vor dem Systementwurf ein Rechtsgutachten (Datenschutz + Fachrecht), nicht danach. Viele Projekte scheitern, weil das System technisch fertig ist, aber die Rechtsgrundlage fehlt.

Konkrete Werkzeuge, was wann passt

Die Werkzeugfrage ist zweitrangig. Die Rechts- und Datenfragen müssen zuerst geklärt sein. Aber wenn die Grundlage steht, gibt es unterschiedliche Wege:

KNIME Analytics Platform , Die naheliegendste Option für Verwaltungen ohne eigenes Datenteam. KNIME ist vollständig kostenlos und Open Source in der Desktop-Version, kann on-premise betrieben werden, und ermöglicht visuelle Modellentwicklung per Drag-and-Drop. Für die Anomalieerkennung auf strukturierten Antragsdaten sind keine fortgeschrittenen Programmierkenntnisse nötig, die relevanten Algorithmen sind als Nodes vorgefertigt. Limitation: Für produktive Workflows mit mehreren Nutzern oder automatisierten Prüfläufen ist der KNIME Business Hub (kostenpflichtig, Preise auf Anfrage) nötig. On-Premise möglich, wichtig für Hoheitsdaten.

govdigital , Wer als Behörde eine vollständig souveräne, BSI-Grundschutz-konforme Infrastruktur für den KI-Betrieb braucht, findet bei govdigital, der öffentlich-rechtlichen Genossenschaft mit 32 Mitgliedern (Stand Mai 2026), eine legitime Alternative zu US-Hyperscalern. govdigital bietet keine fertigen Fraud-Detection-Modelle, aber die Infrastruktur, auf der Behörden eigene Modelle betreiben können. Beschaffung über Rahmenverträge der Mitgliedsorganisationen (Dataport, ekom21, AKDB u. a.). Sinnvoll besonders dann, wenn US-Cloud-Abhängigkeiten ausgeschlossen werden müssen.

scikit-learn / Python-basierte Eigenentwicklung, Wenn die zuständige Behörde oder ihr IT-Dienstleister eigene Data-Science-Kapazitäten hat, ist eine Python-basierte Eigenentwicklung die flexibelste und kostengünstigste Option. scikit-learn ist kostenlos (BSD-Lizenz), enthält alle relevanten Algorithmen für Anomalieerkennung (Isolation Forest, LOF, Random Forest) und kann vollständig on-premise betrieben werden. Voraussetzung: Python-Entwickler mit ML-Erfahrung, die dauerhaft für Modellpflege verfügbar sind. Ohne diese Ressource ist der Ansatz keine Lösung, sondern ein Wartungsproblem.

Aleph Alpha (PhariaAI) , Für Behörden, die über die strukturierte Anomalieerkennung hinaus auch natürlichsprachliche Dokumentenverarbeitung (z. B. Analyse von Freitextangaben in Anträgen) einsetzen wollen: Aleph Alpha betreibt PhariaAI auf europäischer Infrastruktur oder im eigenen Rechenzentrum der Behörde und führt Referenzen in der öffentlichen Verwaltung. Seit September 2026 fusioniert das Unternehmen mit dem kanadischen Anbieter Cohere, das gemeinsame Unternehmen tritt als Cohere auf; wenn eure Vergabe Sitz oder Eigentümer des Anbieters als Kriterium führt, klärt das vor Vertragsabschluss. Laut Handelsblatt wollte die Bundesagentur für Arbeit 2024 bis zu 19 Millionen Euro für KI zahlen, mit Aleph Alpha als Partner. Öffentliche Preise nennt Aleph Alpha nicht, sie entstehen im Einzelvertrag. Sinnvoll, wenn Textverständnis ein wesentlicher Teil des Anwendungsfalls ist.

Zusammenfassung: Wann welcher Ansatz

• Kein eigenes IT-Team, kleines Budget → KNIME on-premise + externer Implementierungspartner
• Souveräne Cloud-Infrastruktur gesucht → govdigital-Mitgliedsnetzwerk
• Eigene Data-Science-Kapazität vorhanden → scikit-learn / Python, on-premise
• Textverarbeitung + Betrieb im eigenen Rechenzentrum + mittleres bis großes Budget → Aleph Alpha PhariaAI, Vertragspartner nach der Cohere-Fusion vorher klären

Datenschutz und Datenhaltung

Dieser Anwendungsfall verarbeitet ausschließlich Sozialdaten, sie genießen nach §§ 35, 67 ff. SGB I/X einen besonders hohen Schutz. Das gilt unabhängig davon, welches System eingesetzt wird.

Was das konkret bedeutet:

• Rechtsgrundlage sind die Befugnisse im Sozialgesetzbuch (§§ 67b ff. SGB X mit dem Fachrecht) auf Basis von Art. 6 Abs. 1 lit. e DSGVO, nicht Einwilligung und nicht berechtigtes Interesse, auf das sich eine Behörde bei ihren Aufgaben nach Art. 6 Abs. 1 Unterabs. 2 DSGVO nicht berufen kann
• Alle Daten müssen in einer Infrastruktur verarbeitet werden, die den Behörden vollständige Kontrolle gibt, US-Cloud ist in diesem Kontext ein K.-o.-Kriterium, nicht eine Abwägungsfrage
• Für Sozialdaten gilt zusätzlich § 80 SGB X: Auftragsverarbeitung nur im Inland, in der EU, in gleichgestellten Staaten oder in Drittstaaten mit Angemessenheitsbeschluss, und an nicht-öffentliche Stellen nur, wenn sonst Störungen im Betriebsablauf drohen oder es erheblich kostengünstiger ist. Ausgenommen sind IT-Dienstleister in mehrheitlich öffentlicher Hand mit vorheriger Genehmigung der obersten Dienstbehörde
• Der IT-Dienstleister, der das Modell betreibt, muss einen Auftragsverarbeitungsvertrag (AVV) nach Art. 28 DSGVO abschließen
• Eine Datenschutzfolgenabschätzung (DSFA) nach Art. 35 DSGVO ist bei diesem Anwendungsfall regelmäßig Pflicht, nicht optional: Das Risiko für die betroffenen Personen (falsche Verdachtsmarkierungen, Datenmissbrauch) ist erheblich
• Der Landesdatenschutzbeauftragte sollte frühzeitig einbezogen werden, nicht am Ende als Kontrollinstanz, sondern am Anfang als Beratungsinstanz. Ergibt die DSFA ein hohes Restrisiko, ist die vorherige Konsultation nach Art. 36 DSGVO ohnehin Pflicht

Kritischer Punkt: Für das niederländische System SyRI erklärte das Bezirksgericht Den Haag am 5. Februar 2020 die gesetzliche Grundlage für unvereinbar mit Art. 8 der Europäischen Menschenrechtskonvention, weil (unter anderem) nicht transparent war, wie Risikomeldungen zustande kamen, und Betroffene die Gründe nicht erfahren konnten. Das ist der konkrete Maßstab, an dem ein deutsches Hinweissystem gemessen wird.

Empfehlung zur Datenhaltung: On-premise oder govdigital-Infrastruktur. Keine US-Cloud für Sozialdaten. Keine dauerhafte Speicherung von Risikoscores über Personen ohne vollständige Transparenz und Widerspruchsmöglichkeit.

Was es kostet, realistisch gerechnet

Einmalige Kosten (Pilotprojekt, eine Behörde):

• Rechtsgutachten (Datenschutz + Fachrecht SGB): 5.000–15.000 Euro
• Datenschutzfolgenabschätzung: 8.000–20.000 Euro (extern begleitet)
• Datenvorbereitung und Datenbereinigung: der größte Einzelposten, typisch 3–6 Monate Aufwand intern oder extern, bei externen Dienstleistern 30.000–80.000 Euro
• Modellentwicklung und -test: 20.000–60.000 Euro extern, weniger mit eigenen Data Scientists
• Schulung der Sachbearbeiterinnen und Sachbearbeiter: 5.000–15.000 Euro
• Gesamter Pilotprojektrahmen: 70.000–190.000 Euro, abhängig von Behördengröße, Datenqualität und Rechtsaufwand

Laufende Kosten (jährlich):

• Infrastruktur (on-premise oder govdigital): 10.000–30.000 Euro/Jahr
• Modellpflege, Nachtraining, Qualitätssicherung: 15.000–40.000 Euro/Jahr (intern oder extern)
• Audit und Dokumentationspflichten: 5.000–10.000 Euro/Jahr

Alle Beträge sind Planungsannahmen ohne veröffentlichte Vergleichszahlen für Deutschland.

Zum Vergleich: SyRI wurde nach Angaben von AlgorithmWatch in fünf Jahren von fünf Gemeinden angefragt, nur zwei Projekte liefen tatsächlich, und keines deckte nach Recherchen der Volkskrant (2019) neue Betrugsfälle auf. Das ist keine Warnung gegen Hinweissysteme generell, sondern gegen schlecht designte und rechtlich nicht abgesicherte Systeme.

Rechenbeispiel, keine Prognose: Eine mittelgroße Kommunalverwaltung mit 5.000 Anträgen im Jahr. Angenommen, das System führt zu 20 bestätigten Mehrfach- oder Fehlbezügen mit durchschnittlich 3.000 Euro Jahresleistung, beides nicht belegt. Das sind 60.000 Euro verhinderte Fehlzahlungen (20 mal 3.000 Euro). Dagegen stehen laufende Kosten von 30.000 bis 80.000 Euro im Jahr und die Prüfzeit für alle Hinweise, auch die unbegründeten. Netto bleiben zwischen minus 20.000 und plus 30.000 Euro im Jahr. Die Einrichtung von 70.000 bis 190.000 Euro kommt damit im besten Fall nach gut zwei Jahren wieder herein (70.000 durch 30.000 Euro), im schlechteren nie.

Und nicht alles davon landet bei der Kommune, die zahlt: Wohngeld erstattet der Bund den Ländern zur Hälfte, beim Bürgergeld trägt die Kommune vor allem die Kosten der Unterkunft, den Regelbedarf zahlt der Bund. Ein Projekt dieser Art braucht deshalb eine Finanzierung, die zu den Kostenträgern passt, oder eine andere Begründung als den Haushalt der Kommune.

Woran du den Nutzen misst: Nicht am Modell, sondern an nachverfolgten Hinweisen: Wie viele Hinweise wurden gegeben? Wie viele davon bestätigten sich bei menschlicher Prüfung? Wie hoch war das verhinderte Auszahlungsvolumen? Diese Zahlen müssen aktiv erhoben werden, sie entstehen nicht automatisch.

Drei typische Einstiegsfehler

1. Die Rechtsgrundlage als letzten Schritt behandeln. Der häufigste und teuerste Fehler. Viele Pilotprojekte werden technisch konzipiert, beschafft und entwickelt, und scheitern dann an der Rechtsprüfung kurz vor dem Go-live. Die Reihenfolge muss umgekehrt sein: Erstens Rechtsgrundlagenprüfung, zweitens Datenschutzfolgenabschätzung, drittens technische Konzeption. Wer das vertauscht, zahlt die Konzeptionskosten zweimal.

2. Das System als Entscheidungssystem designen und als Hinweissystem dokumentieren. Das klingt nach einem Papierphänomen, ist aber in der Praxis dokumentiert. Wenn Sachbearbeiterinnen und Sachbearbeiter strukturell keine Zeit haben, Hinweise tatsächlich zu prüfen, wird das System de facto zum Ablehnungsautomaten, unabhängig davon, was in der Verfahrensbeschreibung steht. Art. 22 DSGVO schaut auf die Funktion, nicht auf die Bezeichnung, das hat der EuGH im SCHUFA-Urteil (C-634/21) für Scores klargestellt, die eine Entscheidung maßgeblich bestimmen. Das erfordert: ausreichende Kapazität für die menschliche Prüfung als Bedingung für den Systembetrieb, regelmäßige Überprüfung der Follow-through-Rate (Wie viele Hinweise werden tatsächlich manuell geprüft?), und eine klare Eskalationsregel: Was passiert, wenn das Prüfvolumen die Kapazität übersteigt?

3. Das Modell einmalig trainieren und dann nicht mehr pflegen. Sozialleistungsanträge verändern sich: neue Leistungsformen, veränderte Einkommenssituationen durch Konjunkturzyklen, neue Betrugsmuster, gesetzliche Änderungen in SGB II, SGB XII, WoGG. Ein Modell, das mit Daten von 2024 trainiert wurde und bis 2029 ohne Nachtraining läuft, wird zunehmend irrelevante Hinweise geben, oder systematisch falsch. Das Modell braucht einen festen Wartungsvertrag, nicht nur eine technische Lösung. Wer das bei der Beschaffung weglässt, kauft ein System mit eingebautem Verfallsdatum.

Was mit der Einführung wirklich passiert, und was nicht

Die größte Spannung bei diesem Anwendungsfall entsteht nicht zwischen Technik und Datenschutz, sondern zwischen dem System und den Menschen, die damit arbeiten müssen.

Widerstandsmuster 1: „Das Modell verdächtigt Menschen.” Dieser Einwand kommt fast immer, von Sachbearbeitenden, Personalrat und manchmal der Behördenleitung. Die Antwort ist nicht eine technische Erklärung, sondern eine Designfrage: Das Modell kennt keine Menschen. Es erkennt Inkonsistenzen in Antragsdaten. Die Person dahinter kann eine berechtigt Antragstellende sein, die einen Meldefehler gemacht hat. Die Sachbearbeitung entscheidet das. Diese Unterscheidung muss in der Schulung klar benannt werden, und sie muss sich in der Systemoberfläche widerspiegeln: kein roter Alarm, kein Verdächtigen-Label, sondern: „Zu dieser Angabe gibt es eine Inkonsistenz, bitte prüfen.”

Widerstandsmuster 2: Die Hinweise häufen sich, aber die Prüfkapazität fehlt. Das ist das gefährlichste Szenario. Wenn ein System pro Tag 40 Hinweise gibt, aber das Team nur Zeit für 5 Prüfungen hat, werden die übrigen 35 entweder ignoriert oder durchgewinkt, was das System faktisch wertlos macht und rechtlich problematisch. Lösung: Die Prüfkapazität muss vor dem Go-live definiert und mit der erwarteten Hinweisrate abgeglichen werden. Wenn beides nicht passt, ist das System noch nicht einsatzbereit.

Widerstandsmuster 3: Misstrauen durch schlechte Modellperformance in der Pilotphase. Wenn das Modell in den ersten Wochen überwiegend Hinweise auf völlig unbedenkliche Fälle gibt (hohe False-Positive-Rate), verlieren Sachbearbeitende das Vertrauen schnell und dauerhaft. Eine gute Pilotphase testet das Modell an historischen Fällen, bei denen das Ergebnis bereits bekannt ist, und stellt sicher, dass die Erkennungsrate akzeptable Werte hat, bevor das System für Echtvorgänge geöffnet wird.

Was konkret hilft:

• Sachbearbeitende frühzeitig in die Konzeptphase einbeziehen, nicht als Betroffene, sondern als Expertinnen und Experten, die wissen, welche Inkonsistenzen wirklich relevant sind
• Personalrat einbinden: Ein Hinweissystem kann als Leistungsüberwachung verstanden werden (es protokolliert, welche Hinweise wer wie prüft). Das muss in der Betriebsvereinbarung adressiert sein
• Qualitätsdaten bereitstellen: Die ersten drei Monate sind immer für Kalibrierung, ein klar kommuniziertes Lernfenster reduziert Frustration

Realistischer Zeitplan mit Risikohinweisen

Wichtig: Diese Zeitplanung setzt voraus, dass die Entscheidungsträger der Behörde voll hinter dem Projekt stehen. Ein Wechsel in der Behördenleitung oder ein politischer Gegenwind können jeden Schritt verlangsamen. Das ist kein technisches Risiko, und kein planbares.

Häufige Einwände, und was dahintersteckt

„Das ist Diskriminierung, ML-Modelle diskriminieren arme Menschen.” Das ist kein unbegründeter Einwand. Er verdient eine ehrliche Antwort statt eine Beschwichtigung.

Das österreichische AMS-System (Arbeitsmarktchancen Assistenz-System), das 2020 vor Gericht landete, vergab systematisch Punktabzüge für Frauen, Mütter und Personen über 50, weil diese Gruppen historisch schlechtere Vermittlungschancen hatten. Das System hat reale Diskriminierung kodiert und als algorithmisch neutral verkleidet. Die österreichische Datenschutzbehörde versuchte das System zu verbieten.

Das niederländische System SyRI (2020 gerichtlich gestoppt) wurde auf ganze Stadtteile angesetzt, deren Bewohnerinnen und Bewohner nicht erfuhren, dass und warum sie markiert wurden, strukturell eine Targeting-Entscheidung, die Nachbarschaften statt Anträge unter Verdacht stellte.

Was folgt daraus für ein deutsches Hinweissystem zur Inkonsistenzerkennung?

Erstens: Das Modell darf keine Merkmale verwenden, die als Proxys für Herkunft, Geschlecht oder Familienform wirken, Adresse in bestimmten Stadtteilen, Anzahl Kinder, Geburtsland. Es prüft, ob die Angaben in einem Antrag konsistent sind, nicht ob eine Person einer bestimmten Gruppe angehört.

Zweitens: Das Risiko von Proxy-Diskriminierung ist real und muss aktiv gemessen werden. Wenn das Modell Anträge aus bestimmten Postleitzahlen oder mit bestimmten Familienkonstellationen systematisch häufiger markiert, ist das ein Hinweis auf ein Modellproblem, kein Hinweis auf Betrug.

Drittens: Das Hinweissystem-Design ist genau dafür da, automatisierte Diskriminierung zu verhindern: Weil ein Mensch entscheidet, bleibt die Möglichkeit, im Einzelfall zu differenzieren.

Viertens: Auch die Alternative hat Kosten. Bürgergeld und Wohngeld sind Rechtsansprüche, kein gedeckeltes Budget, nicht erkannte Überzahlungen gehen deshalb nicht zulasten anderer Leistungsbeziehender, sondern zulasten der Allgemeinheit. Und sie treffen die Betroffenen selbst: Wer eine Überzahlung erst nach Jahren zurückzahlen muss, steht schlechter da als bei einer frühen Klärung.

Die ehrliche Einschätzung: Diskriminierungsrisiken sind real, müssen aktiv gemessen und dokumentiert werden, und sind der Grund, warum ein Hinweissystem ohne ausreichende Governance nicht eingeführt werden darf. Aber sie begründen kein generelles Verbot, sie begründen hohe Anforderungen an Design, Transparenz und Kontrolle.

„Wir haben keine Rechtsgrundlage für den Datenzugriff.” Das stimmt häufig, und ist der Kerngrund, warum viele dieser Projekte scheitern. § 67c SGB X bindet Sozialdaten streng an den Zweck, für den sie erhoben wurden. Eine Querprüfung zwischen Bürgergeld- und Wohngelddaten ist nicht automatisch erlaubt. Es gibt gesetzlich geregelte Abgleiche, etwa den automatisierten Datenabgleich nach § 52 SGB II, aber jeder mit festem Katalog von Stellen und Daten, und Übermittlungsbefugnisse wie § 69 SGB X, deren Reichweite im Einzelfall zu prüfen ist. Dieser Einwand ist kein Projektende, er ist die Aufgabe der Phase 1.

„Wir haben nicht genug Daten für ein Modell.” Bei kleinen Behörden mit wenigen Tausend Anträgen pro Jahr ist das realistisch. Ein überwachtes Lernmodell braucht historische Daten mit bekanntem Ergebnis (echte Fälle von Mehrfachauszahlungen, die nachher bestätigt wurden). Wenn diese Daten fehlen, weil Fälle gar nicht systematisch erfasst wurden, startet man mit einem unüberwachten Ansatz (Anomalieerkennung ohne Labels). Das ist möglich, aber anspruchsvoller zu validieren. Kleine Behörden sollten überlegen, ob eine Kooperation mit dem Landkreis oder IT-Dienstleister sinnvoll ist, um Trainings- und Betriebskosten zu teilen.

Woran du merkst, dass das zu dir passt

Signale, die für diesen Anwendungsfall sprechen:

• Deine Behörde bearbeitet mehr als 3.000 Sozialleistungsanträge pro Jahr, darunter mehrere Leistungsarten (Wohngeld, Bürgergeld, Kinderzuschlag, Pflegegeld), die strukturell getrennt geprüft werden
• Querprüfungen zwischen Sachbereichen finden bei euch heute nicht systematisch statt, nicht weil niemand will, sondern weil der Aufwand es verhindert
• Ihr habt einen IT-Dienstleister, der Sozialdaten bereits auf gesicherter, BSI-konformer Infrastruktur verarbeitet und einen Track Record mit ähnlichen Projekten hat
• Eure Datenhaltung ist vollständig digital und strukturiert, nicht mehr in Teilen papiergebunden
• Deine Behörde hat eine Rechtsabteilung oder externen Datenschutzberater, der auf öffentliches Recht und SGB-Datenschutz spezialisiert ist

Wann es sich (noch) nicht lohnt, vier harte Ausschlusskriterien:

1. Papierbasierte oder hybride Aktenführung. Wenn ein erheblicher Teil der Antragsdaten nicht digitalisiert und strukturiert vorliegt, gibt es keine Datenbasis für das Modell. Der erste Schritt ist dann vollständige digitale Aktenführung, nicht KI.

2. Unterbesetzte Sachbearbeitungsteams, die schon heute keine Zeit für zusätzliche Prüfungen haben. Ein Hinweissystem, das Hinweise erzeugt, die niemand prüfen kann, ist kein Fortschritt, es ist Noise, der die Arbeitsqualität senkt und das Vertrauen in das System dauerhaft beschädigt. Das System setzt voraus, dass Kapazität für Nachprüfungen tatsächlich vorhanden ist.

3. Keine Befugnis für den Abgleich. Wenn das Rechtsgutachten ergibt, dass eure Sachbereiche Daten nur im Einzelfall und auf konkreten Anlass austauschen dürfen, fehlt die Grundlage für ein systematisches Hinweissystem. Das ist kein technisches Problem, sondern ein rechtliches, das vor dem Systementwurf gelöst sein muss.

4. IT-Modernisierungsphase mit noch unbereinigten Altdaten. Behörden, die gerade ihre Fachanwendungen auf neue Systeme migrieren, haben typischerweise eine Datenbasis mit Duplikaten, Umzugsfehlern und inkonsistenten Formaten. Ein Modell, das auf dieser Datenbasis trainiert wird, lernt die Fehler, nicht die Muster. Erst wenn die Migration stabil und die Datenqualität geprüft ist, ist der Zeitpunkt für ein ML-Projekt richtig.

Das kannst du heute noch tun

Bevor du über Technologie nachdenkst: Führe ein internes Audit durch. Welche Sozialleistungsarten werden in deiner Behörde gleichzeitig bearbeitet? Gibt es heute eine manuelle Querprüfung zwischen diesen Bereichen, wer macht sie, wie oft, mit welchem Ergebnis? Wenn die Antwort „keine” oder „selten” ist, hast du die Ausgangsbasis.

Die folgende Vorlage ist in erster Linie eine Struktur für ein internes Abstimmungsgespräch mit Fachrecht, IT und Datenschutz. Du kannst sie mit einem KI-Assistenten vorbereiten, weil sie keine personenbezogenen Daten enthält. Was dabei herauskommt, ist ein Entwurf für eure Rechtsabteilung, keine rechtliche Prüfung, und genau solche Entwürfe zitieren gern falsche Paragrafen.

Quellen & Methodik

• SyRI, Niederlande: Rechtbank Den Haag, Urteil vom 5. Februar 2020, C/09/550982 / HA ZA 18-388, Verstoß gegen Art. 8 EMRK. Einsatzgeschichte und Volkskrant-Befund (keine neuen Betrugsfälle aufgedeckt) laut AlgorithmWatch (algorithmwatch.org, abgerufen am 18.09.2026). Weitere Analyse: Human Rights Law Review (Oxford Academic, 2022: doi.org/10.1093/hrlr/ngac010).
• Automatisierter Datenabgleich: § 52 SGB II, Abgleich zum 1. Januar, 1. April, 1. Juli und 1. Oktober (gesetze-im-internet.de, abgerufen am 18.09.2026)
• Sozialdatenschutz: § 67c SGB X (Zweckbindung), § 69 SGB X (Übermittlung für soziale Aufgaben), § 80 SGB X (Auftragsverarbeitung von Sozialdaten) (gesetze-im-internet.de, abgerufen am 18.09.2026)
• Kostenträger Wohngeld: § 32 WoGG, der Bund erstattet den Ländern das Wohngeld zur Hälfte (gesetze-im-internet.de, abgerufen am 18.09.2026)
• KI-Verordnung (EU) 2024/1689, Anhang III Nr. 5 Buchst. a, Art. 6 Abs. 3, Art. 27 (eur-lex.europa.eu, abgerufen am 18.09.2026); Geltungsbeginn und Art. 111 Abs. 2 nach der Verordnung (EU) 2026/1744
• EuGH, Urteil vom 7. Dezember 2023, C-634/21 (SCHUFA): Art. 22 DSGVO bei Scores, die eine Entscheidung maßgeblich bestimmen.
• Österreichisches AMS-System (2020–2022): Algorithmwatch-Dokumentation und wissenschaftliche Analyse (Österreichische Akademie der Wissenschaften, TU Wien, University of Michigan), System vergab systematisch Punktabzüge für Frauen, Mütter und Personen über 50. Österreichische Datenschutzbehörde untersagte System zunächst (August 2020), Verbot vom BVwG aufgehoben (Dezember 2020). Quelle: kontrast.at/ams-algorithmus/, netzpolitik.org 2020/2021.
• Handelsblatt (2024): „Digitalisierung: Arbeitsagentur will bis zu 19 Millionen Euro für KI zahlen”, BA-Kooperation mit Aleph Alpha. Quelle: handelsblatt.com/politik/deutschland.
• Kosten, Erkennungsraten und Rechenbeispiel: Planungsannahmen der Redaktion; veröffentlichte Zahlen aus deutschen Projekten haben wir nicht gefunden.
• Art. 22, 35 und 36 DSGVO: Gesetzestexte in geltender Fassung.

Du willst wissen, ob euer konkretes Datenmodell und eure Rechtsgrundlage für diesen Ansatz geeignet sind? Das lässt sich in einem kurzen Gespräch einschätzen, meld dich.