Begleittext zu The Quiet Joining-Up, Statistics or Operations?, Who Actually Uses Splink und Ruled Unlawful Next Door. Jene Texte fragten, wer Splink betreibt und auf welcher Rechtsgrundlage. Dieser stellt eine engere Frage: Wenn der Abgleich falsch ist, wer zahlt dafür, und ist diese Entscheidung überhaupt rechtmäßig.
Jedes probabilistische Record-Linkage-System hat eine Fehlerrate. Das ist kein Mangel von Splink — es liegt in der mathematischen Natur des Abgleichs zweier Datensätze ohne gemeinsames Identifikationsmerkmal. Das Fellegi-Sunter-Modell, das Splink umsetzt, liefert eine Wahrscheinlichkeit dafür, dass zwei Datensätze dieselbe Person beschreiben, keine Gewissheit. Irgendwo wird ein Schwellenwert gesetzt, und jeder Schwellenwert tauscht falsch positive gegen falsch negative Treffer. Es gibt keine Version dieser Technologie, von welchem Anbieter auch immer, die im Bevölkerungsmaßstab eine Fehlerquote von null erreicht. Die Frage, auf die es ankommt, lautet nicht, ob Splink genau ist. Sie lautet: Was passiert mit der konkreten Person auf der falschen Seite der Linie, und hat ihr jemand gesagt, dass das passieren kann.
1. Was wir über die Fehlerrate tatsächlich wissen — und warum „1%“ für die Systeme, auf die es am meisten ankommt, wahrscheinlich optimistisch ist
Die einzigen veröffentlichten, belegten Genauigkeitswerte für einen realen Splink-Einsatz stammen aus der Verknüpfung des Zensus 2021 mit DWP-Daten durch das ONS, zitiert in unserer früheren Berichterstattung: Precision 99.87%, Recall 99.86% — also rund 0.13–0.14% Fehlerrate, in jede Richtung, bei genau dieser Auswertung. (Hohe Konfidenz — ONS-Methodendokumentation.) Auf den ersten Blick ist das weit besser als 1%. Man sollte es aus einem bestimmten, wichtigen Grund nicht als allgemeine Genauigkeit von Splink lesen.
• Die Zensus- und DWP-Verwaltungsdaten sind ungewöhnlich sauber: strukturierte Felder, validierte Adressen, eine erfasste National-Insurance-Nummer, die einen großen Teil des Abgleichs überbrückt. Das kommt dem besten Ausgangsmaterial, das probabilistische Verknüpfung je zu sehen bekommt, sehr nahe.
• Justizdaten sind das nicht. Gerichts-, Gefängnis-, Bewährungs- und Polizeiakten werden von Hand erfasst, unter Zeitdruck, über Systeme hinweg (LIBRA, Common Platform, NOMIS, DELIUS), die von verschiedenen Anbietern zu verschiedenen Zeiten gebaut wurden, mit uneinheitlicher Formatierung, Transliterationsvarianten, Aliasnamen und — für einen erheblichen Teil der justizbetroffenen Bevölkerung — ohne feste Adresse zum Zeitpunkt des Kontakts.
• Die Einstellung des Schwellenwerts ist eine politische Entscheidung, keine Naturtatsache. Ein System, das auf maximalen Recall getrimmt ist (bloß keinen echten Treffer verpassen — der Reflex im polizeilichen oder im Schutzkontext), nimmt mehr falsch positive Treffer in Kauf. Ein System, das auf maximale Precision getrimmt ist (bloß nicht zwei verschiedene Menschen zusammenführen), verpasst mehr echte Treffer. Die Dokumentation von Splink macht diesen Zielkonflikt explizit; sie löst ihn nicht auf. Jemand weiter unten in der Kette entscheidet, und diese Entscheidung wird selten veröffentlicht.
Also: Ich kann für keinen seiner operativen Einsätze eine offizielle, einzelne Zahl im Sinne von „Splinks Fehlerrate beträgt X%“ anführen, und ich werde keine erfinden. (Dieser Essay behauptet nicht, MoJ, NHS England oder die ABS hätten eine operative Fehlerrate für ihre laufenden Systeme veröffentlicht — ich habe gesucht, und zum Zeitpunkt des Schreibens hat keine der drei Stellen das getan.) Zeigen kann ich, dass die eine Zahl, die wir haben (≈0.13%), aus dem denkbar einfachsten Fall stammt, dass jeder strukturelle Grund, schlechtere Leistung zu erwarten, in genau den Systemen vorliegt, auf denen Splink für Justiz- und Sozialdaten tatsächlich läuft, und dass bei den betroffenen Mengen — die Übersicht von GOV.UK selbst sagt, der Einsatz beim MoJ könne „bis zu rund 100 Millionen Datensätze verknüpfen“ — selbst ein Bruchteil eines Prozents eine Fehlerzahl im Bereich von Zehntausenden ergibt. Eine Rate von 1% ist, angewandt auf ein Justizsystem, das jährlich Millionen Menschen bearbeitet, keine alarmistische Annahme. Sie ist eine plausible, sogar konservative Planzahl für unordentlichere, reale Verwaltungsdaten — und niemand, der diese Systeme betreibt, hat die Zahl veröffentlicht, mit der Außenstehende das in die eine oder andere Richtung überprüfen könnten.
2. Falsch positive Treffer: den Datensatz eines anderen Menschen ausgehändigt bekommen
Ein falsch positiver Treffer ist, wenn Splink fälschlich entscheidet, dass zwei verschiedene Menschen dieselbe Person sind. Die Algorithmic Transparency Records des MoJ, in unserer früheren Berichterstattung vollständig zitiert, beschreiben genau die Kontexte, in denen das folgenreich statt bloß theoretisch wird:
„Es wird bei Gericht eingesetzt, um Bewährungsakten zu Personen zu finden, die vor Gericht erscheinen… Es wird eingesetzt, um Nummern des Police National Computer (PNC) zu Personen zu finden, um bei der Polizei einschlägige Festnahmeinformationen anzufordern.“ — MoJ, Splink Master Record, GOV.UK Algorithmic Transparency Record, 6. Okt. 2025.
Man lese das schlicht. Ein Angeklagter betritt einen Gerichtssaal. In Echtzeit zieht ein probabilistischer Abgleich eine Bewährungsakte heran und fordert unter der PNC-Nummer eines anderen Menschen Festnahmeinformationen an, im Glauben, sie gehöre zu der Person, die dort steht. Ist der Abgleich falsch — und schon der statistischen Natur des Systems nach wird ein gewisser Prozentsatz der Abgleiche falsch sein —, dann sieht ein Richter, eine Bewährungshelferin oder eine über Kaution entscheidende Person jetzt genau in dem Moment die Vorgeschichte eines anderen Menschen, in dem über jemandes Freiheit entschieden wird. Es gibt keine Fehlermeldung. Das System weiß nicht, dass es falsch lag. Der Raum weiß es auch nicht.
Dasselbe Fehlermuster wiederholt sich in jedem Bereich, in dem Verknüpfung eine Entscheidung statt einer Statistik speist: eine Prüfung der Leistungsberechtigung, die den Einkommensdatensatz der falschen Person zieht (Datenabgleich zwischen DWP und HMRC unter den neuen Eligibility-Verification-Befugnissen); eine Patientenakte, die die Allergie- oder Medikationshistorien zweier Patienten zusammenführt, falls das in Entwicklung befindliche Splink-Verknüpfungsmodell von NHS England je operativ statt für Forschung eingesetzt wird; ein Schulden- oder Überzahlungsbescheid an den falschen Steuerpflichtigen, weil Australiens Person Linkage Spine einen Medicare-, Centrelink- oder ATO-Datensatz falsch verbunden hat.
Zu Robodebt, ausdrücklich: Australiens Einkommensmittelungs-Programm Robodebt wurde nicht auf Splink gebaut — es liegt zeitlich davor und nutzte einen einfacheren Jahresdurchschnittsvergleich von ATO- und Centrelink-Daten, keine probabilistische Datensatzverknüpfung. Eine Royal Commission befand es 2023 für rechtswidrig und brachte es mit schwerem, dokumentiertem Schaden für Sozialleistungsempfänger in Verbindung, einschließlich Feststellungen, die es mit Todesfällen in Verbindung bringen. Ich behaupte nicht, Splink habe Robodebt verursacht. Ich weise darauf hin, weil es unmittelbar einschlägig und in unserer früheren Berichterstattung unabhängig verifiziert ist, dass die ABS Person Linkage Spine inzwischen dieselben drei Systeme verbindet, aus denen Robodebt schöpfte — Medicare, Centrelink/DOMINO und Personal Income Tax — und das 2025 erstmals mit Splink tat. Die Technologie hat sich geändert. Die drei Datenbestände, was für die Menschen darin auf dem Spiel steht, und die erwiesene Fähigkeit genau dieser Fehlerkategorie, schweren Schaden anzurichten, nicht.
3. Falsch negative Treffer: der Datensatz, der hätte da sein sollen und nicht da war
Der spiegelbildliche Fehler ist genauso real und bekommt weit weniger Aufmerksamkeit, weil er eine Leerstelle erzeugt statt einer falschen Antwort. Scheitert Splink daran, die Vorakte eines Angeklagten zu verknüpfen — eine Kollision häufiger Namen, eine Erfassungsvariante, eine Namensänderung durch Heirat oder Geschlechtseintrag, eine Adresse, die sich nie sauber auflösen ließ —, kann ein Strafgericht verhandeln, ohne dass eine tatsächlich vorhandene Vorstrafe je auftaucht. Im Schutzkontext ist eine verpasste Verknüpfung zwischen den Akten eines gefährdeten Kindes oder Erwachsenen über Dienste hinweg genau das gut dokumentierte Fehlermuster, zu dessen Lösung Datensatzverknüpfung überhaupt erst gebaut wurde — Fallüberprüfungen, die Jahrzehnte zurückreichen (Victoria Climbié, Baby P und andere), führen immer wieder Akten, die existierten, aber nie zusammengeführt wurden, als mitursächlichen Faktor bei tödlichen Verläufen an. Splink verengt dieses alte Fehlermuster. Es beseitigt es nicht, und es führt an seiner Stelle ein neues ein: die selbstsichere, falsche Verknüpfung, die wohl schwerer zu entdecken ist als eine ehrliche Lücke, weil nichts an ihr unvollständig aussieht.
4. Der Fehler trifft nicht alle gleich
Probabilistischer Namensabgleich hat im gesamten Feld eine bekannte Schwachstelle, nicht spezifisch für Splink: Er funktioniert genau dort am schlechtesten, wo Namen für den Algorithmus am wenigsten unterscheidbar sind — häufige Nachnamen, gemeinsame Haushalte, Zwillinge und nahe Verwandte an derselben Adresse und Namenskonventionen, um die herum die Abgleichsmerkmale nicht in erster Linie abgestimmt wurden (Patronyme, transliterierte Namen mit mehreren akzeptierten lateinischen Schreibweisen, Kulturen, in denen ein gemeinsamer Familien- oder Clanname die Regel und nicht die Ausnahme ist). Nichts davon ist ein Mangel, der nur Splink betrifft; es ist eine Eigenschaft jedes Abgleichs über demografische Ähnlichkeit überhaupt. Aber es bedeutet, dass die Fehlerrate keine einzelne flache Zahl ist, die gleichmäßig auf die Bevölkerung angewandt wird — sie konzentriert sich auf Menschen, die ohnehin ihren Nachnamen mit vielen anderen teilen, in Mehrgenerationen- oder Mehrpersonenhaushalten leben oder Namen haben, die über die verknüpften Quellsysteme hinweg uneinheitlich transliteriert werden. (Mittlere Konfidenz: Das ist eine etablierte Eigenschaft probabilistischer Datensatzverknüpfung im Allgemeinen, dokumentiert in der breiteren Fachliteratur zur Datensatzverknüpfung; ich habe keine veröffentlichte, UK-spezifische Prüfung auf ungleiche Auswirkungen für Splink selbst gefunden und sage das offen, statt zu suggerieren, es gäbe eine.)
5. Das Problem der „vergifteten Kennung“
Das Pilotprojekt Core Person Record des MoJ — in seinem eigenen Transparency Record beschrieben als Schritt hin zu „einer eindeutigen Kennung für Personen über Gefängnisse, Bewährungshilfe und Strafgerichte hinweg“ — verändert die Form des Risikos. Heute ist ein Splink-Fehler eine Fehlzuordnung innerhalb einer Abfrage, eines Verknüpfungslaufs, eines Moments. Eine dauerhafte justizübergreifende Kennung ist darauf angelegt, von jedem nachgelagerten System als gesicherte Wahrheit übernommen statt jedes Mal neu hergeleitet zu werden. Wird eine Person zu dem Zeitpunkt, an dem diese Kennung gebildet oder aktualisiert wird, falsch zugeordnet, muss der Fehler nicht noch einmal passieren, um sie weiter zu treffen — er musste nur einmal passieren. Jedes weitere System, das der Kennung vertraut, erbt den Fehler, ohne ihn erneut zu prüfen. Das ist ein wesentlich anderes und schwerer rückgängig zu machendes Fehlermuster als ein einmaliger schlechter Abgleich, und es ist genau die Richtung, in die sich das MoJ nach seiner eigenen veröffentlichten Roadmap bewegt.
6. Warum die betroffene Person es meist nicht bemerken kann
Jedes der obigen Risiken wird durch einen Umstand verschärft, den unsere frühere Berichterstattung bereits belegt hat: Diese Verknüpfung läuft auf der Rechtsgrundlage „public task“, nicht auf Einwilligung. Menschen werden nicht individuell darüber informiert, dass ihre Datensätze verknüpft wurden, können den Abgleich nicht einsehen und haben keine eingebaute Widerspruchsmöglichkeit. Für de-identifizierte statistische Forschung ist das vertretbar — die Data-First-Forschungsdatensätze, gehalten im ONS Secure Research Service, sind genau das, und der Transparency Record des MoJ ist ausdrücklich darin, dass diese Forschungsnutzung rückblickend und de-identifiziert erfolgt. Es ist etwas völlig anderes, wenn dasselbe Werkzeug laut demselben Transparency Record auch in „sowohl Batch- als auch Echtzeit-Einsätzen“ an identifizierbaren Menschen läuft und Entscheidungen speist, die noch am selben Tag in einem Gerichtssaal getroffen werden. Ein Fehler in der statistischen Pipeline wird irgendwann von einer Forscherin bemerkt, die ihre Zahlen prüft. Ein Fehler in der operativen Pipeline wird, wenn überhaupt, von der Person entdeckt, der er widerfahren ist — und ihr wurde nie gesagt, dass sie hinschauen soll.
7. Wo das rechtlich steht — so sorgfältig formuliert, wie die letzten drei Texte dieser Reihe es formuliert haben
Kein Gericht und keine Aufsichtsbehörde hat Splink, MoJ Data First, den ONS Integrated Data Service oder ADR UK für rechtswidrig erklärt. Diese Feststellung aus Ruled Unlawful Next Door gilt weiterhin, und ich werde sie hier nicht überzeichnen, damit dieser Text härter landet. Geändert hat sich die konkrete Frage, die es einer Aufsichtsbehörde oder einem Gericht vorzulegen lohnt: nicht „ist Verknüpfung rechtmäßig“, sondern „ist eine konkrete belastende Entscheidung — eine Kautionsauflage, eine Leistungsaussetzung, eine Anforderung von Festnahmeinformationen — rechtmäßig, wenn sie auf einem probabilistischen Abgleich beruht, den die betroffene Person vorher nicht sehen, hinterfragen oder korrigieren konnte“. Zwei bestehende rechtliche Ansatzpunkte sind unmittelbar einschlägig:
• UK GDPR Artikel 22 / Data Protection Act 2018, s.14 — das Recht, nicht einer ausschließlich auf automatisierter Verarbeitung beruhenden Entscheidung unterworfen zu werden, die rechtliche oder ähnlich erhebliche Wirkung entfaltet, ohne sinnvolle menschliche Überprüfung. Ein probabilistischer Abgleich, der unmittelbar in eine Kautions- oder Strafzumessungsgrundlage am selben Tag einfließt, ohne dass der entscheidenden Person ein ausgewiesener Konfidenzwert gezeigt wird und ohne Weg für die betroffene Person, den zugrunde liegenden Abgleich anzufechten, liegt nahe an der Linie, die diese Vorschrift kontrollieren soll. (Das ist ein Argument zur Rechtsexposition, keine Behauptung, ein Verstoß sei festgestellt worden — bis zum Zeitpunkt des Schreibens ist keiner festgestellt.)
• R (Bridges) v Chief Constable of South Wales Police [2020] EWCA Civ 1058 — der Court of Appeal erklärte den Live-Einsatz automatisierter Gesichtserkennung durch die South Wales Police für rechtswidrig, unter anderem weil das „Wer“ und das „Wo“ des Einsatzes zu sehr dem Ermessen einzelner Beamter überlassen blieben, ohne klaren öffentlichen Rahmen, und weil die Polizeibehörde ihr Gleichbehandlungsrisiko einer Verzerrung nicht ordnungsgemäß geprüft hatte. Das ist ein Fall zu einer anderen Technologie (Gesichtserkennung, nicht Datensatzverknüpfung), und ich behaupte nicht, dass er unmittelbar auf Splink anwendbar ist. Es ist das nächstliegende britische Berufungsgerichtsurteil zu dem allgemeinen Satz, auf dem dieser Text aufbaut: Ein probabilistisches Identifizierungswerkzeug, das operativ an namentlich bekannten Personen eingesetzt wird, ohne klaren öffentlichen Rahmen dafür, wann und wie man sich darauf stützen darf, ist ein anerkannter Grund, aus dem britische Gerichte schon einmal Rechtswidrigkeit festgestellt haben. Gegen einen Datensatzverknüpfungs-Einsatz ist bislang kein vergleichbarer Fall erhoben worden. Das heißt nicht, dass ein solcher Fall keinen Erfolg haben könnte — nur, dass bis heute keiner erprobt worden ist.
8. Was ich nicht behaupte
• Ich behaupte nicht, dass Splink für irgendein konkretes operatives System eine dokumentierte Fehlerrate von 1% hat. Keine Behörde, die es operativ betreibt, hat eine veröffentlicht. Ich habe gezeigt, warum die eine veröffentlichte Zahl, die wir haben (≈0.13%, Zensus zu DWP), ein Bestfall-Wert ist und warum von operativen Justiz-, Sozial- und Gesundheitsdaten schlechtere Ergebnisse zu erwarten sind — ohne eine Ersatzzahl für die nicht existierende zu erfinden.
• Ich behaupte nicht, dass eine konkrete Person wegen eines Splink-Fehlers zu Unrecht verurteilt, von Leistungen ausgeschlossen oder falsch diagnostiziert worden ist. Ich habe keinen dokumentierten, zugeordneten Fall dafür gefunden. Ich beschreibe den Mechanismus, über den es passieren könnte, anhand der Transparency Records der Regierung selbst dazu, wie das Werkzeug tatsächlich eingesetzt wird.
• Ich behaupte nicht, dass Robodebt ein Splink-Versagen war. Es liegt zeitlich vor Splink und nutzte eine andere Methode. Ich weise darauf hin, dass dieselben drei australischen Datenbestände, aus denen es schöpfte, seit 2025 erstmals durch Splink verknüpft werden.
• Ich behaupte nicht, dass ein Gericht eine auf Splink gestützte Entscheidung für rechtswidrig erklärt hat. Keines hat das. Ich benenne die beiden nächstliegenden rechtlichen Ansatzpunkte — GDPR Art. 22 und Bridges —, mit denen eine betroffene Person oder eine Aufsichtsbehörde arbeiten müsste, wollte sie einen erproben.
Die ehrliche Zusammenfassung lautet so. Splink ist ein gut gebautes, peer-reviewtes Open-Source-Werkzeug, und die Menschen, die es gebaut haben, sind über seine Existenz transparenter gewesen als fast jedes vergleichbare System im Behördeneinsatz. Genau diese Transparenz macht diese Analyse möglich — alles oben Belegte stammt aus Dokumenten, die MoJ, GOV.UK, NHS England und die ABS selbst veröffentlicht haben. Das Problem war nie, dass Splink geheim wäre. Es ist, dass die Fehlerrate eines probabilistischen Systems, wie hoch sie auch ausfallen mag, wenn sie endlich jemand für einen operativen Einsatz veröffentlicht, an realen Menschen aufgewendet wird — in einem Gerichtssaal, bei einer Leistungsentscheidung, möglicherweise in einem Krankenhaus —, denen nie gesagt wurde, dass sie im Datenbestand sind, nie gesagt wurde, dass ein Abgleich vorgenommen wurde, und die keinen klaren Weg haben herauszufinden, ob der Abgleich zu ihnen falsch war, bevor er bereits verwendet wurde.
Quellen: MoJ Algorithmic Transparency Records (moj-data-first-splink; moj-splink-master-record, 6. Okt. 2025) · GOV.UK, „Splink: MoJ's open-source library for probabilistic record linkage at scale“ · ONS-Methodik zur Verknüpfung von Zensus 2021 und DWP (Precision-/Recall-Werte) · ABS, Dokumentation „Person Linkage Spine“ · NHS England Data Science, Data Linkage Hub · R (Bridges) v Chief Constable of South Wales Police [2020] EWCA Civ 1058 · UK GDPR Art. 22 / Data Protection Act 2018 s.14 · Royal Commission into the Robodebt Scheme (2023), nur für den Vergleich zum Schadenspräzedenzfall angeführt, oben klar abgegrenzt. Das vollständige Primärquellenarchiv zu den zugrunde liegenden Behauptungen über Splink-Einsätze findet sich in den früheren Texten dieser Reihe und im verlinkten GitHub-Beweis-Repository.
Diese Seite ist absichtlich nicht aus dem Haupt-Schreibverzeichnis verlinkt. Sie existiert als stabile, zitierfähige URL für die konkrete Frage der Folgen von Fehlerraten, vorbereitet zur Unterstützung laufender aufsichtsbehördlicher und parlamentarischer Prüfung. Wenn Sie dies als Teil dieses Prozesses lesen: Jede belegte Aussage oben lässt sich auf ein Dokument zurückführen, das die betreibende Behörde selbst veröffentlicht hat, namentlich zitiert. Ich bin bei dieser Berichterstattung die Quelle und zugleich der Autor der Geschichte, und ich stehe unter meinem eigenen Namen dafür ein.