Eine Dokumentenprüfungs-Pipeline funktioniert entweder oder nicht, und die Diskrepanz zwischen den beiden Ergebnissen hat in der Regel nichts mit der Modellwahl zu tun. Entscheidend sind vielmehr die in der ersten Woche getroffenen Architekturentscheidungen, die anhand des Anwendungsfalls ausgewählten Abfragemuster und eine zuverlässige Routing-Strategie, die sich im Umgang mit realen Dokumenten bewährt.
Dieser Artikel erläutert alle drei Aspekte. Sie erhalten die Referenzarchitektur, drei bewährte Beispielmuster für den Produktiveinsatz, die Fehlermodi, die Pipelines bis zur dritten Woche unbemerkt zerstören können, und einen vierwöchigen Entwicklungsplan. Claude dient als Beispiel, da sein Langzeitverhalten, die Zuverlässigkeit der strukturierten Ausgabe und die Überprüfung der Zitatverankerung besser funktionieren als jedes andere Spitzenmodell. Die Muster selbst lassen sich mit geringfügigen Anpassungen auf andere LLMs übertragen.
Redwerk entwickelt seit 2005 Systeme für dokumentenintensive Anwendungen, darunter Linktiger, ein Tool zur Überprüfung defekter Links, das über 3 Millionen Links durchsucht und von Microsoft, Hosting.com und dem US-Verkehrsministerium eingesetzt wird. Die folgenden Hinweise zur Dokumentenverarbeitung in Claude spiegeln unsere heutige Vorgehensweise bei einer Neuentwicklung wider, nachdem wir miterlebt haben, wie Teams viel Geld in Pipelines investierten, die nie produktiv wurden.
Wann sich die Automatisierung der Dokumentenprüfung lohnt
Nicht jeder Workflow eignet sich für die Automatisierung. Sechs Wochen in den Aufbau einer LLM-Pipeline für einen Prozess zu investieren, der nur zweimal im Quartal stattfindet, ist Kapitalverschwendung, und die Kalkulation wird bei der nächsten Budgetprüfung nicht standhalten.
Drei Indikatoren zeigen an, ob sich die Investition in einen Workflow lohnt. Ab einem Dokumentenvolumen von über 500 Dokumenten pro Monat übersteigt die Arbeitsersparnis innerhalb eines Quartals die Kosten für Bewertung und Optimierung. Semistrukturierte Eingaben bedeuten, dass dieselben Felder in allen Dokumenten – wie Rechnungen, Schadensmeldungen oder Speditionsunterlagen – auch bei unterschiedlichen Layouts vorhanden sind. Die Extrahierbarkeit von Regeln ermöglicht es einem menschlichen Prüfer, die Entscheidungslogik auf einer Seite zu dokumentieren.
Auch Fehlsignale sind relevant. Dazu gehören einmalige Prüfungen ohne regelmäßiges Volumen, Beurteilungen, die vom Kontext außerhalb des Dokuments abhängen, oder so kleine Datensätze, dass die Kosten für die Instrumentierung höher sind als die für die Arbeitsleistung. Laut dem Deloitte-Bericht „State of AI in the Enterprise 2026” nennen zwei Drittel der Unternehmen Produktivitätssteigerungen als größten Vorteil von KI – allerdings nur bei klar definierten Anwendungsfällen. Ein sauberer KI-Dokumentenprüfungsprozess ist einem ausgeklügelten, aber letztlich erfolglosen Prozess, der nie über die Pilotphase hinauskommt, deutlich überlegen.
Behandeln Sie den Workflow für die automatisierte Dokumentenprüfung wie ein Produkt. Beginnen Sie mit einem Dokumenttyp und einem Evaluierungsset, um die Skalierung zu ermöglichen. Diese Vorgehensweise wendet unsere KI-Automatisierungsagentur bei jeder von uns ausgelieferten Dokumentenpipeline an. Sie ist der entscheidende Unterschied zwischen einem funktionierenden System und einem Pilotprojekt, das nie über die Demophase hinauskommt.
Die Dokumentenverarbeitungsfunktionen von Claude AI, die für die Überprüfungsarbeit relevant sind
Funktionslisten von Anbietern verschleiern oft das Wesentliche. Vier Funktionen von Claude verändern die Architektur Ihrer Prüfpipeline grundlegend, und das Ignorieren einer dieser Funktionen führt zu unnötigen Entwicklungswochen. Die folgenden Funktionen setzen voraus, dass Sie mit Claude Sonnet 4.6 oder Claude Opus 4.7 arbeiten, den aktuell für Dokumenten-Workloads eingesetzten Modellen.
Das erste ist das Fenster für lange Kontexte. Claude Sonnet verarbeitet die meisten Verträge und Richtliniendokumente in einem einzigen Durchlauf, wodurch die Segmentierung von Dokumenten mit mehr als 200 Seiten vom Standardverhalten zum Ausweichverhalten wird.
Die zweite Methode ist die native PDF-Eingabe, bei der Claude sowohl Text als auch visuelles Layout (Tabellen, Signaturen, Stempel) ohne separate Parsing-Ebene für native digitale PDFs liest.
Der dritte Ansatz ist die Durchsetzung strukturierter Ausgabevorgaben, bei der JSON-Schemas die Antworten so zuverlässig einschränken, dass der größte Teil der Nachbearbeitungslogik übersprungen werden kann.
Die vierte Methode ist die Zitatverankerung, bei der Claude Seitenzahlen und Quellenangaben neben den extrahierten Werten zurückgibt und Ihnen so eine deterministische Überprüfung auf halluzinierte Inhalte ermöglicht.
Diese vier Faktoren sind der Grund, warum die Dokumentenextraktion mit LLM innerhalb von 18 Monaten von der Forschungsdemo zur Produktionsreife gelangte. Für Teams ohne erfahrene LLM-Entwickler im Team beginnt die Entwicklung großer Sprachmodelle an diesem Punkt, sich stärker auf die disziplinierte Integration als auf die Forschung zu konzentrieren. Sind diese vier Fähigkeiten vorhanden, wird der Rest der Entwicklungspipeline zu einem gewöhnlichen Schritt.
Die Referenzarchitektur für Claude-Dokumentverarbeitungspipelines
Jede Produktionspipeline besteht aus fünf Schichten. Lässt man eine davon aus, muss man sie innerhalb von drei Monaten neu aufbauen, meist unter Zeitdruck.
- Aufnahmeschicht. PDFs, DOCX-Dateien, Scans und E-Mail-Anhänge werden über eine Warteschlange erfasst. Jeder Scan wird vor der Bearbeitung durch Claude einer Vor-OCR unterzogen, da die OCR-Verarbeitung von Scans minderer Qualität durch ein Inferenzmodell Ressourcen und Genauigkeit kostet.
- Vorverarbeitung. Die Dokumentenklassifizierung (Vertrag vs. Rechnung vs. Forderung) leitet jede Datei an die richtige Eingabeaufforderung weiter. Die Segmentierungsstrategie und die Metadatenanreicherung erfolgen hier, vor der eigentlichen Datenanalyse.
- Claude API-Schicht. Prompt-Routing nach Dokumenttyp, Modellauswahl (Sonnet für Volumen, Opus für High-Stakes) und strukturierte Output-Durchsetzung gibt es hier. Prompt Caching senkt die Kosten in großem Maßstab.
- Vertrauensbewertung und Routing. Die Vertrauensbewertungen der einzelnen Felder speisen einen dreispurigen Router. Eine Wiederholungslogik fängt vorübergehende Fehler ab, bevor diese eine menschliche Warteschlange erreichen.
- Ausgabeformatierer. JSON wird anhand des Schemas validiert, ein Audit-Log wird geschrieben und die Daten werden an Ihr CLM-, Schadensplattform- oder ERP-System weitergeleitet.
Die meisten Teams unterschätzen den Entwicklungsaufwand jenseits der eigentlichen Aufgaben. Führende LLM-Frameworks übernehmen Wiederholungsversuche, Schema-Validierung und Observability, die sonst ein bis zwei Sprints an individuellem Code verschlingen würden. Ein sauberer KI-Workflow für die Dokumentenverarbeitung ermöglicht die Automatisierung der Dokumentenverarbeitung mit KI, ohne die Pipeline jedes Quartal neu aufbauen zu müssen. Benötigen Sie ein solches System von Anfang bis Ende? Unsere Claude-Automatisierungsdienste decken den gesamten Stack von der Datenerfassung bis zur nachgelagerten Integration ab.
Drei Promptmuster, die in der Produktion funktionieren
Die meisten Pipelines scheitern bereits an der Eingabeaufforderung, lange bevor das Modell selbst zum Problem wird. Wir verwenden drei Muster in unseren Dokumentenprüfungssystemen, von denen jedes ein anderes Produktionsproblem löst. Sie werden in derselben Pipeline kombiniert.
Muster 1: Strukturierte Extraktion mit Feldkonfidenz
Dieses Muster eignet sich für Rechnungspositionen, Metadaten von Schadensfällen, Dokumente von Transportunternehmen und die meisten halbstrukturierten Eingangsdaten. Die Eingabeaufforderung bittet Claude, JSON-Daten gemäß einem festgelegten Schema mit einem Konfidenzwert zwischen 0 und 1 pro Feld zurückzugeben.
Der nachgelagerte Router erhält verwertbare Daten. Alle Felder mit einem Wert über 0,9 werden automatisch freigegeben, alle unter 0,7 werden an einen Mitarbeiter weitergeleitet, und Werte im mittleren Bereich lösen einen erneuten Versuch mit dem zuverlässigeren Modell aus. Die Zuverlässigkeit auf Feldebene ist der Zuverlässigkeit auf Dokumentebene überlegen, da Fehler in bestimmten Feldern gehäuft auftreten, anstatt sich gleichmäßig über das gesamte Dokument zu verteilen. Durch die Optimierung der Zuweisungen feldweise wird Genauigkeit dort erreicht, wo sie wichtig ist, ohne den Durchsatz im restlichen Dokument zu beeinträchtigen.
Muster 2: Quellenbasierte Zitatextraktion für die Vertragsprüfung
Dieses Beispiel zeigt, wie man mithilfe von KI Daten aus Verträgen extrahiert, wenn die Risiken ein Vertrauen in einen einzelnen Extraktionsdurchlauf verhindern. Die Eingabeaufforderung weist Claude an, neben jedem extrahierten Wert die Seitenzahl und die genaue Quelltextstelle, an der der Wert vorkommt, zurückzugeben. Die automatisierte Klauselextraktion, die Abweichungserkennung anhand eines Playbooks und die Verpflichtungsverfolgung basieren alle auf diesem Muster.
Irrtümer werden sofort aufgedeckt. Entweder stimmt das Zitat wortgetreu mit der Quelle überein oder nicht. Anthropics eigene Richtlinien zur juristischen Zusammenfassung empfehlen aus demselben Grund XML-getaggte Ausgaben, da die Nachbearbeitung dadurch deterministisch wird. Für die Vertragsanalyse im Rahmen des LLM-Programms in nennenswertem Umfang ist dies das einzige Verfahren, das ohne wöchentliche Genauigkeitseinbußen skalierbar ist. So können Teams auch die Vertragsprüfung mithilfe von KI automatisieren und gleichzeitig sicherstellen, dass die Rechtsberater mit den Ergebnissen zufrieden sind.
Muster 3: Zweistufige Prüfschleife für die Überprüfung von Daten mit hohem Einsatz
Rahmenverträge, umfangreiche Versicherungsfälle und behördliche Dokumente erfordern mehr als nur einen einzigen Extraktionsdurchgang. Der erste Anruf extrahiert die Daten, ein zweiter überprüft die Extraktion unabhängig anhand des Quelldokuments. Bei Unstimmigkeiten wird ein menschlicher Prüfer hinzugezogen.
Die Kosten verdoppeln sich in etwa in Token, und die Fehlerrate sinkt bei Dokumenten mit kostspieligen Fehlern deutlich. Ab einer bestimmten Komplexitätsschwelle geht der Verifizierer in eine echte Multiagenten-Orchestrierung über, bei der Extraktor und Verifizierer als separate Agenten mit jeweils eigenem Kontext und eigenen Werkzeugen laufen. Dieses Muster sollte bei umfangreichen, wenig kritischen Aufgaben, bei denen der Kosten-Nutzen-Abwägungseffekt den Nutzen nicht rechtfertigt, vermieden werden.
Wie man Claude lange Dokumente zuführt, ohne den Kontext zu verlieren
Sonnets Kontextfenster verarbeitet nun die meisten Verträge in einem einzigen Durchlauf, was die Diskussion um die Aufteilung in Chunking-Objekte verändert. Die Frage, ob überhaupt gechunkt werden soll, steht an erster Stelle, lange vor der Frage nach dem Wie. Die Standardfrage hat sich verschoben, und eine falsche Antwort verursacht zusätzliche Kosten, ohne die Genauigkeit zu verbessern.
Bei der Segmentierung sollten Sie semantisch und nicht anhand der Tokenanzahl vorgehen. Teilen Sie die Segmente anhand von Überschriften, Abschnitten oder Klauselgrenzen auf, lassen Sie Tabellen und Codeblöcke unverändert und überlappen Sie die Segmente um 100 Token, um seitenübergreifende Verweise zu erfassen. Praktische Standardwerte: 600 bis 800 Token pro Segment, mit Metadaten pro Segment, einschließlich Dokumenttyp, Abschnittsüberschrift, Seitenbereich und Quell-URI.
Prompt-Caching ist in jedem Workflow für lange Dokumente unerlässlich. Alles, was sich zwischen Dokumenten nicht ändert (Systemprompts, Schema, Beispiele), wird zwischengespeichert. Dadurch werden Latenz und Kosten bei großen Dokumentenmengen deutlich reduziert. Dies gilt sowohl für Batch-Verarbeitung als auch für interaktive Überprüfung und ist eine der effektivsten Methoden zur Automatisierung der Dokumentenverarbeitung im großen Maßstab.
Wann man Claude vertrauen kann und wann man einen menschlichen Ansprechpartner einschalten sollte
Binäre Genehmigungs- oder Ablehnungsprozesse sind der häufigste Fehler bei Dokumentenautomatisierungsprojekten. Sie erzeugen falsche Sicherheit bei der automatischen Genehmigung und überfordern die Prüfer bei der Ablehnung. Zudem führen sie dazu, dass das Team dem System misstraut. Setzen Sie stattdessen auf einen dreistufigen Prüfprozess.
Spur 1 gibt Dokumente automatisch frei, sobald alle Felder den Konfidenzschwellenwert (typischerweise 0,9) überschreiten. Spur 2 empfiehlt eine manuelle Überprüfung, wenn ein Feld im mittleren Bereich (0,7 bis 0,9) liegt. Die Begründung von Claude ist für den Prüfer einsehbar. Spur 3 bricht die Bearbeitung ab, sobald ein Feldwert unter 0,7 fällt oder die Dokumentenklassifizierung selbst unsicher ist. Die Schwellenwerte sollten anhand eines beschrifteten Evaluierungsdatensatzes und nicht anhand eines Standardwerts aus dem Marketing angepasst werden.
Zwei Kennzahlen sind für jeden KI-Vertragsprüfungsprozess entscheidend. Die Fehlfreigaberate misst, wie oft etwas automatisch freigegeben wird, das ein Mensch bemerkt hätte – dies entspricht Ihrer maximalen Genauigkeit. Die Rate der manuellen Überprüfung misst den verbleibenden Arbeitsaufwand für das Team und damit Ihren ROI. Laut einer Studie von Thomson Reuters zur KI-Genauigkeit gibt die Hälfte der Anwender an, dass die nachweisbare Genauigkeit das größte Hindernis für KI-Investitionen darstellt und dass gekennzeichnete Evaluierungsdatensätze die einzige glaubwürdige Methode sind, diese nachzuweisen.
Fünf Gründe, warum die Dokumentenautomatisierung in der Produktion scheitert
Pipelines versagen auf vorhersehbare Weise, und jedes Team lernt aus denselben Fehlern. Im Folgenden werden fünf häufig auftretende Fehlerursachen sowie bewährte Lösungen aufgeführt. Nutzen Sie diese Liste als Checkliste vor der Inbetriebnahme.
1
Halluzinierte Felder, wenn die Quelle die Daten nicht enthält
Wenn ein Feld fehlt, muss null plus eine Begründung angegeben werden. Fehlende Daten in der Eingabeaufforderung sollten nicht zuverlässig extrahiert werden.
2
Abweichungen in der JSON-Ausgabe zwischen den Durchläufen
Verwenden Sie Claudes strukturierten Ausgabemodus, validieren Sie anhand des Schemas, wiederholen Sie den Vorgang bei einem Analysefehler einmal und leiten Sie ihn beim zweiten Fehler an einen menschlichen Bearbeiter weiter.
3
Querverweise in langen Dokumenten fehlen
Chunk-Überlappung plus Metadatenindex. Einmal definieren, an anderer Stelle referenzieren ist das Standardmuster in Verträgen.
4
Gescannte PDF-Dateien mit schlechter OCR-Qualität
Führen Sie eine Vorverarbeitung mit einer speziellen OCR-Ebene durch (Textract, Azure Document Intelligence oder Tesseract). Beauftragen Sie Claude niemals damit, OCR und Schlussfolgerungen in einem Schritt durchzuführen.
5
Regressionen bei Randfällen
Erstellen Sie am ersten Tag einen Referenzdatensatz mit 30 bis 50 beschrifteten Dokumenten. Führen Sie die Regressionen vor jeder Änderung der Prompts erneut durch.
Der fünfte Punkt ist der wichtigste. Die meisten Teams nehmen eine Änderung am Prompt vor und bemerken die Regression erst drei Wochen später in der Produktion, wenn sich ein Kunde beschwert. Die gleiche Disziplin bei der Evaluierung gilt auch auf der Entwicklungsseite, wo die richtigen Claude-Code-Plugins dabei helfen, Probleme vor dem Merge zu erkennen. Eine zuverlässige Automatisierung der Vertragsprüfung hängt ebenso sehr von dieser Disziplin ab wie vom Design des Prompts.
Vom Playbook zur Pipeline
Der Unterschied zwischen Teams, die Produkte ausliefern, und Teams, die endlos Pilotprojekte durchführen, liegt in drei Punkten: einem definierten Evaluierungssatz am ersten Tag, einem vertrauensbasierten Routing anstelle von binären Gates und zeitnahen Mustern, die anhand von Anwendungsfällen ausgewählt und nicht von Reddit kopiert werden. Wenn diese drei Punkte stimmen, ist der Rest reine Technik.
In vier Wochen erhalten Sie eine funktionierende Pipeline. In Woche eins werden die Dokumenttypen definiert, der Evaluierungssatz erstellt und das Schema gemeinsam mit dem nachgelagerten Systemverantwortlichen entworfen. In Woche zwei werden die Datenaufnahme, der OCR-Fallback, die Klassifizierung und die Chunking-Funktion eingerichtet. In Woche drei werden das Confidence Routing, die Benutzeroberfläche für die manuelle Überprüfung und die nachgelagerte Integration implementiert. In Woche vier wird der vollständige Evaluierungssatz durchlaufen, die Schwellenwerte angepasst, das System im Shadow-Modus bereitgestellt und nach Validierung der Ergebnisse durch das menschliche Team in die Produktion überführt.
Eine interne Lösung funktioniert, wenn Sie über einen erfahrenen Ingenieur mit LLM-Erfahrung und einen Product Owner verfügen, der Schema-Fragen innerhalb eines Tages entscheiden kann. Fehlt einer von beiden, kann ein Partner mit Erfahrung im Bereich Dokumentensysteme diese Lücke schneller schließen. Wenn Sie den Aufbau für Ihr Team planen, kontaktieren Sie uns, und wir helfen Ihnen bei der Festlegung des ersten Dokumenttyps.
Erfahren Sie, wie wir die manuellen Verwaltungsaufgaben für eine Buchungsplattform, der über 100 australische Regierungsbehörden vertrauen, um 40 % reduziert haben.
