Eine LLM-Pipeline für Schadenakten, Tickets und KYC-Unterlagen in Ihrer eigenen Infrastruktur: Extraktion, Validierung, Review und Audit

Schadenakten, Support-Tickets und KYC-Dokumente haben dasselbe Problem: Menschen lesen sie, um Felder auszufüllen, die ein anderes System braucht. Aus einem Schadenfall werden eine Policennummer, ein Schadendatum und Rechnungspositionen; aus einem Ticket eine Kategorie und ein Kunde; aus einem Ausweisdokument ein Name, ein Geburtsdatum und ein Ablaufdatum. Die Anforderung, die mit dieser Arbeit einhergeht, wird meist vor allem anderen genannt: Die Dokumente dürfen nicht an OpenAI oder einen anderen externen Modellanbieter gehen.

Wo das Modell läuft, ist eine separate Entscheidung, die ein früherer Artikel in diesem Blog vergleicht. Dieser hier setzt ein Open-Weight-Modell voraus, das innerhalb Ihrer Infrastruktur bereitgestellt wird, und beschreibt die Pipeline darum herum, vom Eingang bis zum Datensatz, den ein anderes System verarbeitet. Er erklärt die Mechanik; er ist keine Case Study.

Sieben Stufen, und jede davon bleibt intern

Daten von externen Anbietern fernzuhalten ist eine Eigenschaft der gesamten Pipeline, nicht des Modellaufrufs: Die OCR-Engine, das Review-Tool, das Evaluierungsset, der Audit-Speicher und die Logs enthalten alle das Dokument oder etwas daraus Abgeleitetes, wie der frühere Artikel über Piloten vollständig auflistet.

Eingang: das Dokument klassifizieren, bevor irgendetwas es liest

Jede spätere Stufe hängt vom Dokumenttyp ab: das Schema, die Regeln, die Reviewer und die Aufbewahrungsfrist; deshalb kommt die Klassifizierung zuerst und entscheidet über die Route. Eine per E-Mail eingehende Schadenakte kann ein Schadenformular, Rechnungen, Fotos und einen ärztlichen Bericht enthalten; jeder Anhang wird einzeln klassifiziert und demselben Fall zugeordnet.

• Erfassen Sie beim Eingang Kanal, Absender und einen Inhalts-Hash, damit ein doppelt gesendetes Dokument erkannt wird, bevor daraus zwei Fälle werden
• Klassifizieren Sie aus einer geschlossenen Liste von Typen; die Dokumentation von vLLM zu Structured Outputs führt einen Parameter choice auf, mit dem die Ausgabe genau eine der Auswahlmöglichkeiten ist, sodass der Klassifikator keinen Typ erfinden kann
• Schicken Sie ein Dokument, das zu keinem Typ passt oder nur mit geringer Übereinstimmung, an einen Menschen statt an das nächstliegende Schema

Zuerst Text und Layout, dann das Sprachmodell

Ein von Software erzeugtes PDF hat eine Textebene, die sich direkt lesen lässt. Ein Scan oder ein Handyfoto enthält nur Pixel, und etwas muss daraus Zeichen mit Positionen machen.

Die Open-Source-Engines für diesen Schritt laufen lokal. Die Kommandozeilen-Dokumentation von Tesseract zeigt eine TSV-Ausgabe mit einer Konfidenzspalte für jedes Wort und eine hOCR-Ausgabe mit einem Attribut für die Wortkonfidenz, ein Signal pro Wort, das die Routing-Stufe nutzen kann. Docling, eine Open-Source-Konvertierungsbibliothek unter der MIT-Lizenz, führt Seitenlayout, Lesereihenfolge und Tabellenstruktur unter ihren PDF-Funktionen auf, dazu OCR-Unterstützung für gescannte PDFs und Bilder sowie lokale Ausführung für sensible Daten und Air-Gapped-Umgebungen.

• Lesen Sie die Textebene, wo es eine gibt, und nutzen Sie OCR nur, wo es keine gibt, damit saubere Dokumente keine Erkennungsfehler aufnehmen
• Bewahren Sie Seitennummer und Bounding Box jedes Wortes auf, damit jedes extrahierte Feld einem Reviewer später auf der Seite gezeigt werden kann, von der es stammt
• Erhalten Sie Tabellen als Tabellen: Bei einer Rechnung, deren Spalten zu einer Textzeile zusammengedrückt werden, geht verloren, welcher Betrag zu welcher Position gehört

Stattdessen kann ein Vision-Language-Modell das Seitenbild lesen: Die Dokumentation von vLLM zu multimodalen Eingaben hält fest, dass Bildeingaben gemäß der OpenAI Vision API unterstützt werden. Was besser funktioniert, wird an Ihren Dokumenten gemessen, wobei zu beachten ist, dass eine separate OCR-Stufe Wortpositionen und Konfidenzen liefert und ein Modell, das ein Bild liest, nicht.

Schemagebundene Ausgabe: Die Form wird erzwungen, der Inhalt nicht

Jeder Dokumenttyp bekommt sein eigenes Ausgabeschema, versioniert wie Code. Die Dokumentation von vLLM zu Structured Outputs führt fünf Arten von Constraints auf: choice, regex, ein JSON-Schema, eine kontextfreie Grammatik und ein Structural Tag, mit Backends, darunter xgrammar, guidance, outlines und lm-format-enforcer, sowie einem Standardwert, auto, der versucht, anhand der Details der Anfrage ein geeignetes Backend zu wählen.

• Machen Sie „nicht gefunden“ zu einem expliziten Wert für jedes Feld, damit ein fehlendes Schadendatum als fehlend erfasst statt geraten wird
• Nutzen Sie Enumerationen für alles, worauf ein anderes System verzweigt: Schadenart, Ticket-Kategorie, Dokumenttyp, Ländercode
• Ergänzen Sie jedes Feld um eine Quellenangabe, also die Seite und die Wörter, aus denen es stammt, damit Validierung und Review es am Dokument prüfen können

Validieren Sie die Ausgabe im Anwendungscode noch einmal mit einem gewöhnlichen Validator für JSON Schema. Backends unterscheiden sich: Dieselbe Seite vermerkt, dass xgrammar, guidance und outlines reguläre Ausdrücke im Rust-Stil verwenden, während lm-format-enforcer das Python-Modul re nutzt, und dass bei Qwen3 Coder-Modellen mit aktiviertem Reasoning Structured Outputs deaktiviert werden könnten, wenn der Reasoning-Inhalt nicht in ein separates Feld geparst wird. Eine Generierung, die am Token-Limit stoppt, endet außerdem mitten im Datensatz. Die zweite Prüfung ist billig.

Validierung: die Geschäftsregeln, die es schon gibt, als Code geschrieben

Ein Datensatz, der zum Schema passt, kann trotzdem falsch sein. Die Prüfungen, die das aufdecken, sind die, die das Back Office heute von Hand anwendet, als Code pro Dokumenttyp geschrieben:

• Schadenfälle: Die Policennummer existiert im Bestandssystem, das Schadendatum liegt im Versicherungszeitraum, und die Rechnungspositionen ergeben in der Summe den Rechnungsbetrag
• Tickets: Die Kundenkennung verweist auf ein real existierendes Konto, und das genannte Produkt ist eines, das der Kunde tatsächlich hat
• KYC: Die Prüfziffern der maschinenlesbaren Zone sind korrekt, das Ablaufdatum ist nicht überschritten, und Name und Geburtsdatum in der maschinenlesbaren Zone stimmen mit denselben Feldern überein, die aus der visuellen Zone gelesen wurden

Ausweisdokumente bringen ihren eigenen Validator mit. ICAO Doc 9303, die Spezifikation für maschinenlesbare Reisedokumente, definiert Prüfziffern in der maschinenlesbaren Zone, berechnet nach Modulo 10 mit einer fortlaufend wiederholten Gewichtung von 7, 3, 1, wobei die Buchstaben A bis Z als 10 bis 35 und das Füllzeichen als null zählen, und hält fest, dass die Prüfziffern es Lesegeräten ermöglichen, zu verifizieren, dass die Daten korrekt interpretiert werden.

Routing: Regeln und Signale entscheiden, welche Felder ein Mensch sieht

Das Routing wird pro Feld entschieden, nicht pro Dokument: Ein Schadenfall, dessen Rechnungssumme scheitert, während alles andere besteht, schickt ein Feld an einen Menschen, nicht die ganze Akte. Die Signale:

• Jedes Scheitern eines Validators, einschließlich eines vom Schema geforderten Felds, das das Modell als nicht gefunden markiert hat
• Niedrige OCR-Konfidenz bei den Wörtern, aus denen das Feld gebildet wurde, mit einer Schwelle, die pro Feld am Evaluierungsset festgelegt wird
• Zwei Quellen, die sich widersprechen, etwa die maschinenlesbare und die visuelle Zone desselben Reisepasses
• Felder, die per Entscheidung nie automatisiert werden, etwa ein geltend gemachter Betrag über einem festgelegten Limit
• Eine Zufallsstichprobe von Feldern, die alles bestanden haben, damit die Rate der Fehler, die niemand markiert hat, gemessen statt angenommen wird

Die eigene Sicherheitsangabe des Modells bleibt bewusst außen vor; ein früherer Artikel in diesem Blog erklärt, warum sie ein schwaches Gate ist.

Der Review-Bildschirm zeigt die Seite mit den zitierten Wörtern hervorgehoben neben dem vorgeschlagenen Wert, sodass ein Reviewer prüft, statt neu zu lesen. Jede Korrektur wird pro Feld gespeichert, mit altem Wert, neuem Wert, Reviewer und einem Grund aus einer kurzen Liste. Sobald eine zweite Person sie bestätigt, geht sie ins Evaluierungsset ein, aber nie in den eingefrorenen Teil, auf dem Release-Entscheidungen getroffen werden.

Evaluierung pro Dokumenttyp und pro Feld, nicht ein globaler Score

Eine einzige Genauigkeitszahl für die Pipeline verdeckt das Ergebnis, auf das es ankommt, etwa dass Ablaufdaten auf den Personalausweisen eines Landes scheitern, während jedes andere Feld besteht. Messen Sie entlang der Linien, die auch das Routing nutzt:

• Pro Feld: exakte Übereinstimmung nach der Normalisierung und getrennt davon, wie oft das Feld übersehen oder erfunden wurde, je nachdem, ob das Dokument es enthält oder nicht
• Pro Dokumenttyp und pro Eingabeart, etwa digitales PDF, Scan und Handyfoto, weil jede ihr eigenes Fehlermuster hat
• Pro Route: der Anteil automatisierter Felder und die Fehlerrate in der daraus gezogenen Stichprobe
• Nach Kosten gewichtet: Eine falsche Kontonummer und ein falsch geschriebener Straßenname sind nicht derselbe Fehler

Ein Release, ob neues Modell, neuer Prompt, neues Schema, neue OCR-Version oder neuer Validator, wird auf dem eingefrorenen Set bewertet, bevor es live geht, und das Gate gilt pro Feld: Kein Feld eines Dokumenttyps fällt unter seine Abnahmeschwelle, selbst wenn der Durchschnitt steigt. Wie das erste gelabelte Set entsteht, beschreibt der frühere Artikel über Piloten, die nie in Produktion gingen.

Audit-Trail: welches Modell und welcher Prompt welches Feld erzeugt hat

Ein strittiger Schadenfall oder die Frage eines Prüfers zu einer akzeptierten Identität betrifft ein Feld in einem Dokument. Der Nachweis, der sie beantwortet, wird geschrieben, während die Pipeline läuft, ein Eintrag pro Feld, in einem Append-only-Speicher:

• Dokument-ID und Inhalts-Hash, die Seite und die Wörter, auf die sich das Feld beruft
• Die Version der OCR- oder Layout-Engine und ihre Konfidenz für diese Wörter
• Modellname und Prüfsumme der Gewichte, die Version des Prompt-Templates und die Schemaversion
• Das Ergebnis jedes Validators, die gewählte Route und ihr Grund
• Der Reviewer, der Wert vorher und nachher und der Zeitpunkt, falls ein Mensch ihn geändert hat

Die KI-Verordnung der EU (EU AI Act) legt eine Protokollierungspflicht für Systeme fest, die sie als hochriskant einstuft: Art. 12 Abs. 1 bestimmt, dass Hochrisiko-KI-Systeme technisch die automatische Aufzeichnung von Ereignissen (Protokollierung) während des Lebenszyklus des Systems ermöglichen müssen. Anhang III listet die Hochrisiko-Anwendungen auf, darunter die Bewertung der Kreditwürdigkeit natürlicher Personen, ausgenommen die Aufdeckung von Finanzbetrug, sowie die Risikobewertung und Preisbildung bei Lebens- und Krankenversicherungen; Art. 6 Abs. 3 legt fest, wann ein gelistetes System dennoch nicht als hochriskant gilt, etwa wenn es eine eng gefasste Verfahrensaufgabe erfüllt. Ob eine bestimmte Pipeline in den Anwendungsbereich fällt, ist eine Frage für die Rechtsabteilung des Kunden; ein zur Laufzeit geschriebener Eintrag pro Feld ist in jedem Fall nützlich.

Personenbezogene Daten: Jede Stufe sieht nur, was ihre Aufgabe erfordert

Eine Pipeline kopiert personenbezogene Daten an mehr Orte als den ursprünglichen Ordner. Art. 5 Abs. 1 lit. c DSGVO verlangt, dass personenbezogene Daten dem Zweck angemessen und erheblich sowie auf das für die Zwecke der Verarbeitung notwendige Maß beschränkt sind („Datenminimierung“). Art. 25 Abs. 2 verlangt Maßnahmen, die sicherstellen, dass durch Voreinstellung nur personenbezogene Daten verarbeitet werden, deren Verarbeitung für den jeweiligen bestimmten Verarbeitungszweck erforderlich ist, und wendet dies auf die Menge der erhobenen Daten, den Umfang ihrer Verarbeitung, ihre Speicherfrist und ihre Zugänglichkeit an. Auf die Pipeline übertragen:

• Das Modell erhält die Seiten, die sein Schema braucht, nicht die ganze Fallakte
• Reviewer sehen die Felder in ihrer Queue, und der Zugriff auf vollständige Dokumente wird rollenbasiert gewährt und protokolliert
• Anwendungslogs erfassen Dokument-IDs, Feldnamen und Ergebnisse, keine Feldwerte oder Prompts
• Traces von Prompts und Ausgaben liegen, sofern sie fürs Debugging aufbewahrt werden, im selben zugriffsbeschränkten Speicher wie die Dokumente, mit einer eigenen kurzen Aufbewahrungsfrist
• Das Evaluierungsset ist eine Kopie echter Dokumente und erhält dieselben Zugriffskontrollen

Das OWASP Logging Cheat Sheet zählt sensible personenbezogene Daten und einige Formen personenbezogener Identifikationsdaten, etwa Gesundheitsdaten und staatliche Kennungen, zu den Daten, die in der Regel nicht direkt in Logs erfasst werden sollten, und hält fest, dass solche Daten stattdessen entfernt, maskiert, bereinigt, gehasht oder verschlüsselt werden sollten.

Die Aufbewahrung unterscheidet sich je nach Dokumenttyp, und für KYC in der EU wird sie durch das Geldwäscherecht festgelegt. Art. 77 der Verordnung (EU) 2024/1624, die ab dem 10. Juli 2027 gilt, verlangt von den Verpflichteten, eine Kopie der im Rahmen der Sorgfaltspflichten gegenüber Kunden eingeholten Dokumente und Informationen aufzubewahren und sicherzustellen, dass diese Aufzeichnungen nicht geschwärzt werden. Er legt eine Aufbewahrungsfrist von fünf Jahren fest, gerechnet ab dem Ende der Geschäftsbeziehung oder dem Datum einer gelegentlichen Transaktion, nach deren Ablauf personenbezogene Daten zu löschen sind, vorbehaltlich der Ausnahmen in demselben Artikel. Der ursprüngliche KYC-Datensatz bleibt im führenden System vollständig erhalten; die eigenen Kopien der Pipeline, von Traces bis zu Review-Snapshots, werden minimiert und nach einem eigenen, kürzeren Zeitplan gelöscht.

Durchsatz: eine Queue für die Lastspitze, Kapazität für den Normalbetrieb

Das Volumen im Back Office ist ungleichmäßig: Ein Ereignis kann viele Versicherungsnehmer gleichzeitig treffen, und ein Ausfall füllt die Ticket-Queue. Queues, Backpressure und ein manueller Fallback sind im früheren Artikel über Piloten beschrieben; spezifisch für eine selbst gehostete Dokumentenpipeline ist Folgendes:

• Trennen Sie Queues nach Dringlichkeit: Eine KYC-Prüfung, auf die ein Kunde beim Onboarding wartet, steht nicht hinter einem Stapel historischer Schadenfälle an
• Skalieren Sie OCR-Worker auf CPU und Modellserver auf Beschleunigern unabhängig voneinander, weil sie bei unterschiedlichen Volumina an ihre Grenze kommen
• Beobachten Sie die eigene Queue der Serving-Engine: vLLM stellt an seinem Endpunkt /metrics Prometheus-Metriken bereit, darunter die Anzahl der Requests, die auf Verarbeitung warten, und den Anteil belegter Key-Value-Cache-Blöcke
• Skalieren Sie Worker nach Queue-Tiefe statt nach CPU-Last; die Dokumentation von KEDA beschreibt das Skalieren beliebiger Container in Kubernetes anhand der Anzahl zu verarbeitender Events, unter anderem mit Scalern für Messaging-Systeme, sowie Scale-to-Zero

Die Beschleunigerkapazität in Ihrer eigenen Infrastruktur ist kurzfristig fix, deshalb wird die Reihenfolge, in der Queues zurückstehen, vorab festgelegt, nicht während der Lastspitze.

Schadenfälle, Tickets und KYC: dasselbe Gerüst, andere Regeln

• Schadenfälle: viele Dokumente pro Fall, Tabellen in Rechnungen und oft Gesundheitsdaten, die Art. 9 DSGVO zu den besonderen Kategorien zählt, deren Verarbeitung untersagt ist, es sei denn, eine Ausnahme aus demselben Artikel greift. Art. 22 gibt einer Person das Recht, nicht einer ausschließlich auf einer automatisierten Verarbeitung beruhenden Entscheidung unterworfen zu werden, die ihr gegenüber rechtliche Wirkung entfaltet oder sie in ähnlicher Weise erheblich beeinträchtigt, mit Ausnahmen in Art. 22 Abs. 2. Ob die Pipeline nur extrahiert und prüft, während ein Schadenbearbeiter entscheidet, ist deshalb eine Designentscheidung, die gemeinsam mit dem Datenschutzbeauftragten des Kunden getroffen wird, keine technische Voreinstellung
• Tickets: kurze Texte, hohes Volumen und jemand, der auf eine Antwort wartet, daher zählt die Latenz mehr; die Ausgabe ist meist eine Kategorie, eine Priorität und einige Identifikatoren. Ticket-Text wird von Menschen außerhalb des Unternehmens geschrieben und ist für das Modell eine nicht vertrauenswürdige Eingabe, ein Risiko, das der frühere Artikel über Piloten behandelt
• KYC: wenige Dokumenttypen mit strengen Formaten, etwa Reisepässe und Personalausweise, was die regelbasierte Validierung stark macht. Ein Selfie, das mit dem Foto im Dokument abgeglichen wird, bringt biometrische Daten hinzu, die Art. 9 DSGVO ebenfalls als besondere Kategorie aufführt, wenn sie zur eindeutigen Identifizierung einer Person verarbeitet werden. Die Aufbewahrung folgt dem Geldwäscherecht, und das Ergebnis fließt in eine Compliance-Entscheidung ein, die ein Mensch oder eine dokumentierte Regel trifft

Ob Dokumente von einem externen Modellanbieter ferngehalten werden, entscheidet sich daran, wo das Modell läuft. Ob man der Pipeline die Dokumente anvertrauen kann, entscheidet alles, was um das Modell herum liegt: das Schema, die Regeln, die Review-Queue und der Nachweis, wer jedes Feld erzeugt hat.

Welche Engineering-Firmen bauen das innerhalb Ihrer eigenen Infrastruktur?

Auf die Frage gibt es drei Arten von Antworten, und sie verkaufen verschiedene Dinge. Anbieter von Dokumentenverarbeitung verkaufen eine Plattform, manchmal on-premises installierbar, die Sie auf Ihre Dokumente konfigurieren. Cloud-Anbieter verkaufen verwaltete Dienste, die in ihrer Infrastruktur laufen. Engineering-Firmen bauen die Pipeline in Ihrer Umgebung aus offenen Komponenten und Ihren Regeln.

Mit welcher Art Sie auch sprechen, diese Fragen zeigen, ob ein Team das schon einmal gebaut hat:

• Welche Stufen rufen irgendeinen Dienst außerhalb Ihres Netzwerks auf, einschließlich OCR, Monitoring, Error Tracking und Annotationstool?
• Wie sieht das Ausgabeschema für einen Ihrer Dokumenttypen aus, und wie wird „nicht gefunden“ dargestellt?
• Welche Signale schicken ein Feld ins Review, und wie wurden die Schwellen gewählt?
• Wie gelangen Korrekturen der Reviewer ins Evaluierungsset, ohne den Teil zu kontaminieren, auf dem Release-Entscheidungen beruhen?
• Können sie für ein Feld in einem Dokument das Modell, den Prompt, das Schema und den Reviewer zeigen, die seinen Wert erzeugt haben?
• Wem gehören der Pipeline-Code, die Schemas und das Evaluierungsset, wenn die Arbeit endet, und welche Teile bleiben wiederverwendbare Komponenten des Anbieters?

Eine Antwort, die bei der ersten und der fünften Frage allgemein bleibt, heißt, dass Datenpfad und Audit-Trail noch nicht entworfen sind.

Was amBrain über die eigene Arbeit in diesem Bereich sagen kann

Was amBrain über die oben in der Zusammenfassung beschriebene Produktionsintegration hinaus öffentlich belegen kann: amBrain baut seit 2019 Software. Wir arbeiten in drei Formaten: vollständige Umsetzung, dediziertes Team oder Engineers, die in Ihrem Team mitarbeiten. Der Kunde behält das volle Eigentum an Produkt und Code, ausgenommen unsere wiederverwendbaren Komponenten.

Dieser Artikel erklärt, wie eine solche Pipeline funktioniert; er ist keine Case Study, nennt keine Kunden und behauptet nicht, dass amBrain ein System für Schadenfälle, Tickets oder KYC gebaut hat. Die oben genannte Produktionsarbeit ist die Extraktion von Mitteilungen von Brokern und Handelsplätzen für ein Handelssystem.

Der erste Schritt ist also nicht die Wahl eines Modells. Er besteht darin, für einen Dokumenttyp das Schema, die Regeln, die es prüfen, und die Felder, die ein Mensch immer sehen muss, schriftlich festzulegen, bevor irgendein Dokument die Pipeline erreicht.