Sozialleistungsmissbrauchs-Mustererkennung

Das echte Ausmaß des Problems

Die Bundesagentur für Arbeit geht davon aus, dass Sozialleistungsbetrug in der großen Mehrheit der Fälle unbeabsichtigt entsteht — falsche Angaben aus Unkenntnis, veraltete Informationen, vergessene Meldepflichten. Dennoch: Laut Bundestag-Antwort auf die Anfrage der CDU/CSU-Fraktion (Drucksache 20/12831, 2024) prüft die Bundesagentur bereits heute rund 150.000 Studienbescheinigungen pro Jahr maschinell auf Auffälligkeiten beim Kindergeld. Das zeigt: Das Konzept maschineller Konsistenzprüfung ist in der deutschen Sozialverwaltung längst keine Theorie mehr.

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
• Sachbearbeiter haben im Schnitt unter zehn Minuten pro Antrag für die inhaltliche Prüfung — 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. Der Sozialbetrug-Bericht des Bundesrechnungshofes (2023) hält strukturelle Mehrfachauszahlungen für „systematisch untererfasst” — was nicht primär an böswilligen Tätern liegt, sondern an der fehlenden Möglichkeit, legitime Querprüfungen automatisiert durchzuführen.

Mit vs. ohne KI — ein ehrlicher Vergleich

Hinweis zur Tabelle: Interne Erfahrungswerte aus deutschen Pilotprojekten sind nicht öffentlich verfügbar — die Erkennungsraten-Spanne basiert auf vergleichbaren europäischen Systemen (laut Pulitzer Center „Unlocking Europe’s Welfare Fraud Algorithms”, 2023).

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 kurzfristig nicht im Haushalt sichtbar. Die Einführungskosten (Datenvorbereitung, Rechtsgutachten, Beschaffung, Schulung, Betrieb) übersteigen erkennbare direkte Einsparungen in den ersten zwei bis drei Jahren regelmäßig. Kein anderer Anwendungsfall in dieser Kategorie ist beim direkten Kostenhebel schwächer — deshalb dieser Score.

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. Die BA berichtet nicht, wie viel ihr Kindergeld-Prüfsystem spart. Der ROI ist real, aber er 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 — Hochrisikoeinstufung beachten: Systeme zur Bewertung der Kreditwürdigkeit oder zum Scoring natürlicher Personen durch Behörden fallen unter die Hochrisiko-Kategorie des EU AI Act (Anhang III, Punkt 5b). Ob ein Hinweissystem für Sozialleistungen darunter fällt, hängt von der konkreten Ausgestaltung ab — ist es ein Werkzeug zur Entscheidungsunterstützung oder ein Scoring-System für Personen? Diese Frage muss vor der Beschaffung mit einem auf KI-Recht spezialisierten Anwalt geklärt werden. Im Zweifelsfall gelten die Hochrisiko-Anforderungen: Datensatz-Dokumentation, Bias-Prüfung, menschliche Aufsicht, Logging, Informationspflichten.

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 Daten (§ 67 SGB X) begrenzt den Datenaustausch — auch behördenintern. 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 Cloud-Genossenschaft aus 31 deutschen IT-Dienstleistern — 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 ist der einzige europäische LLM-Anbieter mit nachgewiesenem Fokus auf souveräne Deployments in der öffentlichen Verwaltung. Die BA hat 2024 einen 19-Millionen-Euro-Vertrag mit Aleph Alpha für Verwaltungsautomatisierung abgeschlossen. Preis: Jahresverträge auf Anfrage, im mittleren bis hohen sechsstelligen Bereich. 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 + souveräne KI + mittleres bis großes Budget → Aleph Alpha PhariaAI

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:

• Alle Daten müssen in einer Infrastruktur verarbeitet werden, die den Behörden vollständige Kontrolle gibt — US-Cloud ohne EU-Datenhaltungsvertrag ist in diesem Kontext ein K.-o.-Kriterium, nicht eine Abwägungsfrage
• 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. Mehrere Datenschutzbehörden bieten für öffentliche Stellen Vorabbefragungen an

Kritischer Punkt: Das holländische SyRi-System wurde 2020 vom Haager Gericht verboten, weil es (unter anderem) keine transparente Erklärung lieferte, wie Risikoscores zustande kamen, und weil Betroffene keine Möglichkeit hatten, die Scores zu prüfen oder anzufechten. 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–180.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

Zum Vergleich: Das niederländische SyRi-System kostete nach Schätzungen im Rahmen der Pulitzer-Center-Recherche (2023) mehr als 325.000 Euro jährlich — bei „sehr niedriger Erfolgsquote”, wie der holländische Rechnungshof befand. Das ist keine Warnung gegen Hinweissysteme generell, sondern gegen schlecht designte, überteuerte und rechtlich nicht abgesicherte Systeme.

ROI-Schätzung (konservativ): Wenn ein System in einer mittelgroßen Kommunalverwaltung mit 5.000 Anträgen/Jahr 20 tatsächliche Mehrfach- oder Fehlanträge mit durchschnittlich 3.000 Euro pro Fall (Jahresleistung) identifiziert, sind das 60.000 Euro verhinderte Fehlzahlungen — zuzüglich gesparter Rückforderungsverfahren (500–2.000 Euro je Fall). Bei einem Pilotprojekt mit 150.000 Euro Einmalkosten erreicht man den Break-even nach drei bis fünf Jahren — wenn die Erkennungsrate stabil bleibt und die Ergebnisse konsequent nachverfolgt werden.

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 und die SyRi-Rechtsprechung schauen auf die Funktion, nicht auf die Bezeichnung. 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 holländische SyRi-System (verboten 2020) lief ausschließlich in einkommensschwachen Stadtteilen mit hohem Migrationsanteil — strukturell eine Targeting-Entscheidung mit diskriminierender Wirkung.

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 Verteilungseffekte. Wenn Mehrfachauszahlungen nicht erkannt werden, werden die Budgets aller Leistungsempfangenden de facto gekürzt — weil das Gesamtbudget endlich ist. Das ist eine verdeckte Verteilungswirkung, die selten benannt wird.

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. § 67 SGB X begrenzt die Zweckbindung von Sozialdaten streng. Eine Querprüfung zwischen Bürgergeld- und Wohngelddaten ist nicht automatisch erlaubt. Es gibt aber gesetzliche Öffnungsklauseln (z. B. für die Bekämpfung von Leistungsmissbrauch nach § 60 SGB II), und die OZG-Infrastruktur schafft zunehmend technische Voraussetzungen für berechtigte Querprüfungen. 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. Querprüfung setzt individuelle richterliche Erlaubnis je Fall voraus. Wenn der Datenzugriff zwischen den relevanten Sachbereichen in eurer Behörde nur mit Gerichtsbeschluss möglich ist, fehlt die technische Grundlage für das 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 Analyse-Vorlage ist kein Prompt für ein KI-System, sondern eine Struktur für ein internes Abstimmungsgespräch mit Fachrecht, IT und Datenschutz:

Quellen & Methodik

• SyRi Netherlands (2020): Haagse Rechtbank, Urteil vom 5. Februar 2020 — Das niederländische Welfare-Fraud-Erkennungssystem wurde für rechtswidrig erklärt (EKMR Art. 8, DSGVO Art. 22). Kosten: über 325.000 Euro/Jahr bei niedriger Erfolgsquote. Quellen: AlgorithmWatch (algorithmwatch.org/en/syri-netherlands-algorithm/), Privacy International, Human Rights Law Review (Oxford Academic, 2022: doi.org/10.1093/hrlr/ngac010).
• Bundesagentur für Arbeit (2024): Antwort der Bundesregierung auf Kleine Anfrage CDU/CSU, Bundestag Drucksache 20/12831 (2024) — Bestätigt maschinelle Prüfung von ca. 150.000 Studienbescheinigungen/Jahr auf Kindergeldbetrug. Quelle: bundestag.de/presse/hib/kurzmeldungen-1019588.
• Ö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.
• Bertelsmann Stiftung (2023): KI-Register für Deutschland — Öffentliche Verwaltung ohne systematische Transparenz über KI-Einsatz. Quelle: bertelsmann-stiftung.de (Transparente digitale Verwaltung: Umsetzbarkeit eines KI-Registers für Deutschland, 2023).
• Pulitzer Center (2023): „Unlocking Europe’s Welfare Fraud Algorithms” — Investigativrecherche zur Verbreitung und Wirkung von Welfare-Fraud-Algorithmen in Europa, inkl. SyRi-Kosten. Quelle: pulitzercenter.org/projects/unlocking-europes-welfare-fraud-algorithms.
• AlgorithmWatch (2020/2021): „Unsere Untersuchung der Hartz-IV-Algorithmen zeigt: Hier diskriminiert der Mensch und nicht die Maschine” — algorithmwatch.org. Befund: diskriminierende Muster kommen vom Gesetz und menschlichem Verhalten, nicht vom Algorithmus selbst.
• Handelsblatt (2024): „Digitalisierung: Arbeitsagentur will bis zu 19 Millionen Euro für KI zahlen” — BA-Kooperation mit Aleph Alpha für Verwaltungsautomatisierung. Quelle: handelsblatt.com/politik/deutschland.
• Kostenschätzungen: Erfahrungswerte aus vergleichbaren Pilotprojekten in europäischer Sozialverwaltung; keine repräsentativen Studien für Deutschland verfügbar. Eigene Einschätzung.
• Art. 22 DSGVO, Art. 35 DSGVO, §§ 67 ff. SGB X: 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.