Rund 2.800 Downloads pro Woche. So groß ist, weltweit, die Nachfrage nach dem bekanntesten quelloffenen Werkzeug, das personenbezogene Daten aus einem Bild entfernt — laut dem Paketindex von Snyk. Nicht pro Monat. Pro Woche. Halten Sie diese Zahl neben die Menge eingescannter Verträge, Ausweiskopien und unterschriebener Einwilligungen, die gerade in deutschen Aktenschränken liegen, und Sie sehen keine technische Lücke. Sie sehen einen Markt, der sich längst für seinen Kunden entschieden hat — und dieser Kunde ist nicht derjenige, der das Dokument in der Hand hält.
Die Extraktionsannahme
Öffnen Sie die Dokumentation eines beliebigen angesehenen Werkzeugs und sehen Sie sich den ersten Funktionsaufruf an. Er erwartet eine Zeichenkette. Sie übergeben Text, Sie bekommen Positionen zurück — Zeichen 40 bis 51 sind ein Name. Das ist eine saubere, ehrliche Schnittstelle, und für ihren Zweck ist sie die richtige.
Achten Sie aber darauf, was sie voraussetzt. Sie setzt voraus, dass der Text bereits existiert. Irgendwer hat die Seite schon in Zeichen verwandelt. Nennen wir es die Extraktionsannahme: Die gesamte Produktkategorie beginnt einen Schritt nach dem schwierigsten Teil der Arbeit und sagt nie laut, wer diesen Schritt eigentlich übernehmen soll.
Für Entwickler ist das unproblematisch, denn der Entwickler ist dieser Irgendwer. Er hat eine Datenbankspalte, ein Chatprotokoll, ein JSON-Feld. Text ist dort, wo sein Problem ohnehin lebt. Für die Person mit dem eingescannten PDF ist die Annahme das ganze Problem — und es wurde ihr stillschweigend zugeteilt.
Der Hinweis steht in der Installationsanleitung
Presidio — der De-facto-Standard, bei Microsoft entstanden und inzwischen von der Community verwaltet — bringt durchaus einen Bildredaktor mit, und der ist gut gemacht. Lesen Sie nach, wie man ihn zum Laufen bringt: das Python-Paket installieren, danach Tesseract OCR gesondert für Ihr Betriebssystem installieren, möglichst in einer aktuellen Fassung — die Dokumentation nennt Tests mit v5.2.0. Die Variante für medizinische Bilddaten trägt einen weiteren Vorbehalt: Sie schwärzt die Pixel, bereinigt aber nicht die personenbezogenen Daten, die womöglich noch in den Metadaten der Datei stehen.
Jeder dieser Sätze ist für einen Ingenieur nützlich. Keiner davon ist lesbar für eine Personalreferentin mit vierzig eingescannten Arbeitsverträgen. Das ist kein Dokumentationsmangel. Es ist eine Aussage darüber, für wen das Produkt gemacht ist — und eine ehrliche dazu.
Die großen Cloud-Anbieter machen dasselbe, nur mit mehr Umsatz daran: Sie verkaufen Ihnen Texterkennung als einen Dienst und Entitätenerkennung als einen zweiten und überlassen Ihnen die Verdrahtung dazwischen. Zwei Produkte, ein Integrationsprojekt, eine Rechnung. Die Zusammenbauarbeit — genau die Stelle, an der die Fehler tatsächlich passieren — ist konstruktionsbedingt Sache des Kunden.
Die Antwort des Platzhirschs: den schweren Teil bitte selbst
Bei Adobe Acrobat versuchen es die meisten Menschen wirklich, und die Antwort dort besteht aus zwei Schritten: erst Texterkennung über das Scan-Dokument laufen lassen, dann Suchen und Schwärzen benutzen. Anders gesagt: Führen Sie die Extraktion selbst durch, danach übernehmen wir. Dieselbe Annahme, nur mit einem Menschen in der Nahtstelle.
In dieser Nahtstelle wohnen die Supportanfragen. Die Erkennung scheitert unauffällig an einem kontrastarmen Fax. Die Suche findet elf von vierzehn Namen, weil der zwölfte mit einer zerbrochenen Ligatur gelesen wurde. An keiner Stelle wird ein Fehler gemeldet. Man verlangt von Ihnen, die Qualitätssicherung eines Verfahrens zu sein, das Ihnen nie gezeigt wurde.
Wir haben dieselbe Annahme getroffen. Unsere war schlimmer.
Ich würde das gern als Außenstehender kritisieren. Ich kann es nicht, denn wir haben die Extraktionsannahme ebenfalls ausgeliefert, an drei verschiedenen Stellen, und sind erst durch Nachmessen darauf gestoßen.
Unsere Erkennungskette musste entscheiden, ob eine Seite es wert ist, als Bild gelesen zu werden, und sie stellte die falsche Frage — „gibt es hier ein großes Bild?“ — und nahm die Fläche als Hinweis auf Wichtigkeit. Ein Firmenname in einem Briefkopfstreifen macht etwa ein halbes Prozent einer DIN-A4-Seite aus. Er fiel glatt durch. Die Größe war nie die Frage. Die Frage lautet, ob über dem Bild Text liegt: Text darüber bedeutet Wasserzeichen oder Hintergrund, kein Text darüber bedeutet, dass die Textextraktion an dieser Stelle blind ist — unabhängig von der Größe.
Schlimmer noch: Die Funktion, die prüfen sollte, ob eine Seite überhaupt eingebettete Bilder enthält, rief eine Methode auf, die unsere PDF-Bibliothek gar nicht besaß. Der Fehler wurde auf Debug-Ebene verschluckt. Sie antwortete „hier sind keine Bilder“, solange diese Abhängigkeit festgeschrieben war — auch bei einer Seite, die zu 65 Prozent aus Bild bestand. Ein stilles Falsch ist von einer richtigen Antwort nicht zu unterscheiden; genau so hat es überlebt.
Und wenn jemand von Hand ein Schwärzungsrechteck über einen eingescannten Briefkopf zog, las unser Editor die Textebene der Seite, fand nichts innerhalb des Rechtecks und erfasste nichts. Die Person markierte genau das, was sie am dringendsten entfernt haben wollte, und wir entfernten es stillschweigend nicht. Auf einer Seite, die wir gerade eben gelesen hatten — und deren Wörter wir danach weggeworfen haben.
Drei Fehler, eine Ursache, und es ist dieselbe wie die des Marktes: Wir griffen nach dem Text und behandelten das Bild als den Schritt von jemand anderem.
Wer den stillen Treffer bezahlt
Ein Werkzeug, das abstürzt, ist ärgerlich. Ein Werkzeug, das „keine personenbezogenen Daten gefunden“ auf einer Seite voller Namen meldet, ist etwas anderes: Es scheitert nicht, es stellt einen Freibrief aus und verschiebt die Haftung auf jemanden, der sie nicht überprüfen kann.
Überlegen Sie, wer eingescannte Dokumente tatsächlich verwahrt. Nicht das Plattformteam einer Großbank; dort gibt es Entwickler, und den Text hat man ohnehin schon. Es sind die Zweipersonenkanzlei, die Praxis, die Aufnahmebögen einscannt, die Sachbearbeiterin mit der Ausweiskopie, die Personalstelle mit unterschriebenen Angeboten. Die bildförmigen Dokumente sind überproportional die sensiblen — und die Menschen, die sie halten, können überproportional genau jene Integration nicht schreiben, die der gesamte Werkzeugmarkt von ihnen erwartet.
Sie können die Folgen auch am wenigsten abfedern. Wer als Entwickler eine Schwärzungskette falsch verdrahtet, schreibt ein Ticket. Wessen Ausweiskopie ungeschwärzt hinausging, wendet sich an die Aufsichtsbehörde — und nach DSGVO und BDSG ist die Panne binnen 72 Stunden zu melden.
Was sich ändert, wenn man für den anderen Kunden baut
Es ändert sich die Eingabe. Arbeitseinheit ist die Seite, wie sie vorliegt, Bild inklusive — und nicht eine Zeichenkette, die jemand anderes hätte liefern sollen.
Konkret: Texterkennung ist kein vorgelagerter Schritt, den der Nutzer anstößt, sie steckt in der Verarbeitungskette. Ein von Hand gezogenes Rechteck, das keine Wörter erwischt, liest seine eigene Seite noch einmal, damit eine manuelle Korrektur niemals wirkungslos bleiben kann. Erkannte Namen werden zu Rechtecken, die über die Pixel gemalt werden, und darunter entsteht eine neue durchsuchbare Textebene, damit die Datei brauchbar bleibt. Wenn Sie die Mechanik statt des Arguments möchten: Wir haben sie beschrieben in gescannte PDFs und Bilder richtig schwärzen.
Nichts davon ist klüger als das, was die Presidio-Autoren gebaut haben. Es sind dieselben Bausteine, nur angeordnet für jemanden, der nie ein Terminal öffnen wollte. Und es läuft auf dem Rechner, auf dem das Dokument ohnehin liegt — bei der Kopie eines Reisepasses ist das keine Geschmacksfrage.
Häufige Fragen
Warum übersehen Schwärzungswerkzeuge Text in Bildern?
Weil die meisten das Bild nie ansehen. Ihr Einstiegspunkt nimmt Text entgegen, also trifft eine eingescannte Seite ohne etwas Durchsuchbares ein und geht mit „nichts gefunden“ wieder hinaus, lautlos. Das Bild muss die Eingabe sein und nicht ein Schritt, den der Nutzer vorher erledigt.
Ist genau dafür nicht der Bildredaktor von Presidio gedacht?
Doch, und er funktioniert. Er ist aber auch ein Python-Paket, das erwartet, dass Sie selbst eine Texterkennung installieren — eine faire Bitte an Entwickler und eine unerfüllbare an die meisten Menschen mit Scans im Ordner. Wo seine Textmaschine passt und wo nicht, haben wir beschrieben in warum wir unsere eigene Erkennung gebaut haben, statt Presidio auszuliefern.
Warum zählt lokale Verarbeitung bei Scans besonders?
Weil Scans zum Sensiblen neigen: Ausweise, Aufnahmebögen, unterschriebene Verträge. Sie an einen Dienst zu schicken, damit er ihnen die Geheimnisse nimmt, heißt, dass die Geheimnisse zuerst bei diesem Dienst ankommen — genau das Risiko, wenn das Dokument selbst die sensible Sache ist.
Das Fazit
Dass ein PDF voller Bilder so schwer zu schwärzen ist, liegt nicht daran, dass das Problem ungelöst wäre. Jeder Baustein existiert seit Jahren. Es liegt daran, dass die Bausteine für Entwickler an Textströmen entworfen und bepreist wurden und der Zusammenbau — der teure, fehleranfällige Teil — demjenigen überlassen blieb, der die Datei zufällig in der Hand hielt.
Die meisten von ihnen sind keine Entwickler. Es ist jemand am Schalter, der eine Kopie von einem Dokument macht, das ein Fremder gerade herübergereicht hat, weil er etwas brauchte: eine Stelle, eine Behandlung, eine Wohnung. Dieser Mensch hat nicht in eine Verarbeitungskette eingewilligt. Er hat eingewilligt, dass ein Büro an einem Nachmittag sorgfältig mit einem Blatt Papier umgeht, auf dem er steht. Was wir bauen, sollte diese Sorgfalt zum Normalfall machen und nicht zu etwas, das man sich durch technisches Können erst verdienen muss.
promptShield führt Texterkennung, Erkennung und Schwärzung von eingescannten PDFs und Bildern auf Ihrem eigenen Rechner aus — kein Paket zu installieren, kein vorgelagerter Erkennungsschritt, und nichts, was hochgeladen wird. Probieren Sie es an dem Scan aus, den Ihr jetziges Werkzeug für sauber erklärt.