Datenschutz vor der KI: Was die automatische Erkennung findet – und was ein Scan kaputt macht

Im letzten Beitrag ging es darum, dass Namen schwärzen keine Anonymisierung ist und dass die Aufbereitung von Daten vor dem Prompt in die Architektur gehört, nicht auf eine Schulungsfolie. Eine Frage ist dabei offen geblieben, und es ist die, auf die es im Betrieb ankommt: Wie gut findet so eine automatische Erkennung eigentlich, was sie finden soll?

Ich habe das für mein eigenes Datenschutz-Gateway gemessen. Die Zahlen stehen unten. Interessanter als die Bestwerte ist der Befund, der nicht im Plan stand: Auf eingescannten Unterlagen bricht die Erkennung genau bei den Datentypen zusammen, bei denen sie auf getipptem Text am zuverlässigsten ist.

Warum es dazu wenig Zahlen gibt

Als ich nach Vergleichswerten gesucht habe, fand ich vor allem Ratgebertexte. Sie empfehlen übereinstimmend, personenbezogene Daten vor der KI-Nutzung zu entfernen. Keiner davon nennt eine Erkennungsquote, und keiner unterscheidet zwischen einem getippten Text und einem gescannten Dokument.

Das ist bequem für alle Beteiligten. Eine Empfehlung, die keine Zahl nennt, kann nicht widerlegt werden. Für dich als Anwender ist sie aber wertlos, weil du an ihr nicht ablesen kannst, wie viel Restrisiko du dir einkaufst.

Was gemessen wurde

Grundlage ist ein Referenzdatensatz aus 66 erfundenen deutschen Geschäftstexten: Rechnungen, Support-Mails, Außendienstnotizen, Verträge, Kundenlisten. In diesen Texten sind 593 Fundstellen von Hand annotiert, also markiert als „hier steht etwas, das nicht zum Anbieter darf“. 54 Beispiele mit 479 Fundstellen bilden den Prüfumfang, zwölf weitere eine getrennte Kategorie mit Lesefehlern, zu der ich gleich komme.

Alle Angaben sind erfunden. Die Steuer-Identifikationsnummern und Sozialversicherungsnummern erfüllen trotzdem ihre Prüfziffer, sonst würde man das Prüfverfahren gar nicht testen, sondern nur die Ziffernlänge. Dasselbe gilt für die IBANs.

Gemessen wird zweierlei. Recall sagt, wie viel von dem gefunden wird, was tatsächlich da ist. Precision sagt, wie viel von dem Gefundenen wirklich eine Fundstelle war. Für die Pseudonymisierung kommt eine dritte Zahl dazu, und sie ist die wichtigste: der Anteil der Fundstellen, den überhaupt irgendeine Erkennung abdeckt, unabhängig davon, ob sie den Typ richtig benennt. Was hier durchrutscht, steht im Klartext im Prompt.

Das Ergebnis auf getipptem Text

466 von 479 Fundstellen sind abgedeckt. Die dreizehn offenen sind schnell erzählt: neun davon sind Ortsnamen, die zugleich gewöhnliche Wörter oder Vornamen sind. Essen, Hagen, Kiel. Die restlichen vier sind einzeln stehende Vor- oder Nachnamen aus schnell getippten internen Notizen, teils klein geschrieben, etwa hr. mertens in einer Außendienstnotiz.

Beides sind keine Musterprobleme, sondern Eigennamen. Ein größeres Sprachmodell hilft dagegen wenig; eine gepflegte Liste der Mitarbeiter, Kunden und Standorte eines Mandanten schließt die Lücke zuverlässiger, weil sie kurz und stabil ist.

Die niedrige Precision bei Organisationen fällt auf. Sie liegt bei 0,434, und das ist eine Einstellung, kein Mangel. Für diesen Zweck ist ein zu viel maskiertes Wort billiger als ein übersehener Firmenname: Der Fehltreffer ist in der Prüfansicht mit einem Klick erledigt, die übersehene Nummer wäre bereits beim Anbieter. Wer eine solche Erkennung nach Precision auswählt, optimiert für den falschen Fehler.

Der Befund: Was ein Scanner kaputt macht

Jetzt der Teil, der mich beim Messen überrascht hat. Ich habe dieselben Beispieltexte mit den Fehlern versehen, die Texterkennung auf deutschen Geschäftsunterlagen tatsächlich macht: eine 0, die als O gelesen wird, eine 1 als l, Trennstriche am Zeilenende, zusätzliche Leerzeichen mitten in einer Nummer.

Die Sozialversicherungsnummer fällt auf 0,000. Nicht auf einen schlechteren Wert, sondern auf null: Keine einzige wird noch erkannt. Die Steuer-Identifikationsnummer fällt auf 0,333, die IBAN auf 0,700.

Der Grund ist die Prüfziffer. Sie ist es, die diese Erkennung im sauberen Text so präzise macht, denn eine Zahlenfolge, die die Prüfsumme erfüllt, ist mit hoher Wahrscheinlichkeit wirklich eine IBAN und keine beliebige Nummer. Und sie ist es, die ein einziges falsch gelesenes Zeichen zerstört: Die Prüfsumme stimmt nicht mehr, die Regel greift nicht, die Nummer ist für das System keine Nummer mehr.

Die statistische Namenserkennung verhält sich umgekehrt. Sie bleibt bei 0,960 und damit stabil, weil ihr ein vertauschtes Zeichen wenig ausmacht. Ein Mirlam Falkenhain ist für sie weiterhin eine Person.

Die Stärke im einen Fall ist die Schwäche im anderen, und zwar bei denselben Datentypen. Das ist kein Detail für Entwickler.

Was daraus für deinen Betrieb folgt

Wenn du Rechnungen, Verträge oder Behördenpost scannst und anschließend durch eine KI schicken willst, dann verschiebt dieser Befund drei Dinge.

Die Qualität deiner Texterkennung ist eine Sicherheitseigenschaft. Bisher war sie eine Komfortfrage: Je besser die OCR, desto weniger Tippfehler im Ergebnis. Nach dieser Messung heißt eine schlechte Texterkennung nicht schlechterer Text, sondern eine unerkannte Sozialversicherungsnummer im Prompt. Deutsches Sprachmodell in der OCR, Geradeziehen schiefer Scans, ordentliche Auflösung. Das sind keine Optimierungen mehr, sondern Teil des Schutzes.

Die Prüfung durch einen Menschen ist bei Scans keine Vorsicht. Sie ist die einzige Stelle, an der eine zerbrochene Nummer noch auffällt. Und die Oberfläche muss dafür erlauben, eigene Stellen nachzumarkieren, nicht nur die vorgeschlagenen abzunicken. Wer die Freigabe zur Formsache macht, hat bei gescannten Unterlagen nichts.

Nummern und Namen brauchen unterschiedliche Wachsamkeit. Beim getippten Text kannst du dich auf die festen Regeln verlassen und musst bei den Namen genauer hinsehen. Beim Scan ist es genau andersherum. Das ist kontraintuitiv, weil eine Nummer nach dem eindeutigeren Fall aussieht als ein Name.

Was diese Zahlen nicht sagen

Dazu gehört auch, was die Messung nicht hergibt.

54 Beispiele sind wenig. Bei fünf Sozialversicherungsnummern bedeutet ein einziger Fehler zwanzig Prozentpunkte. Für die seltenen Datentypen ist das eher ein Funktionsnachweis als eine belastbare Quote.

Der Datensatz stammt von derselben Person wie die Erkennungsregeln, also von mir. Was mir beim Schreiben der Muster nicht eingefallen ist, fehlt mit einiger Wahrscheinlichkeit auch in den Testtexten. Der ehrlichste nächste Schritt wären echte, anschließend anonymisierte Dokumente aus der Praxis als zweiter, unabhängiger Datensatz.

Und die Kategorie mit den Lesefehlern ist nachgebaut, nicht gescannt. Die Fehler sind den typischen Tesseract-Fehlern nachempfunden, aber es ist kein Blatt Papier durch einen Scanner gelaufen. Das steht als nächstes an.

Ein Lauf mit gepflegter Wörterbuchliste erreicht übrigens vollständige Abdeckung. Diese Zahl nenne ich hier bewusst nicht als Ergebnis: Die Begriffe darin stammen aus dem Referenzdatensatz selbst, gemessen wird also gegen das eigene Lösungsblatt. Der Lauf zeigt, dass die Mechanik funktioniert, und was eine Fallliste im günstigsten Fall leisten kann. Eine Kachel mit „100 % Abdeckung“ wäre der eine Satz, an dem die Glaubwürdigkeit aller anderen Zahlen hängen bliebe.

Und was ist mit fertigen Werkzeugen?

Die Erkennung setzt auf Microsoft Presidio auf, ein quelloffenes Werkzeug, das inzwischen eigene deutsche Regeln mitbringt. Die habe ich gegen meine eigenen gemessen, in derselben Umgebung.

Bei Steuer-Identifikationsnummer und Sozialversicherungsnummer ist der Standard gleich gut. Beide arbeiten mit demselben Prüfverfahren, mehr ist da nicht zu holen. Bei Kennzeichen und Postleitzahlen fällt der Standard im laufenden Betrieb auf 0,526 beziehungsweise 0,559 zurück. Der Grund ist nicht das Muster, sondern die Bewertung: Der mitgelieferte Recognizer für Postleitzahlen vergibt für eine fünfstellige Zahl einen sehr niedrigen Grundwert und verlässt sich darauf, dass in der Nähe ein Wort wie „Anschrift“ steht. In einem Briefkopf steht dort meistens nichts.

Das ist der praktische Kern für jeden, der so etwas einkauft oder selbst baut: Ein Werkzeug, das auf dem Papier den richtigen Datentyp kennt, erkennt ihn in deinen Dokumenten noch lange nicht. Zwischen „unterstützt deutsche Steuernummern“ und „findet sie in deinem Briefkopf“ liegt die ganze Arbeit.

Die Zahlen zum Nachrechnen

Die vollständigen Werte je Datentyp, die Methode, der Vergleich mit den Standardregeln und die Grenzen der Messung stehen auf einer eigenen Seite: Messung der Erkennung personenbezogener Daten. Dort steht auch, mit welchem Befehl und welchen Programmversionen sich der Lauf wiederholen lässt.

Wenn du selbst so etwas betreibst oder planst und andere Werte misst, schreib mir. Vergleichszahlen sind zu diesem Thema selten, und zwei Datensätze sagen mehr als einer.