# Dokumente, PDFs und Scans für KI-Agenten erschließen

> Zuverlässig wird es mit einer Pipeline statt eines einzelnen Uploads: Dokumenttyp erkennen, Text-PDFs direkt parsen, Scans per OCR oder Vision-Modell lesen, Tabellen und Layout erhalten. Danach entscheiden Sie, ob der Agent feste Felder extrahiert oder per RAG im Volltext sucht.

Kanonische URL: https://www.ruebstudio.de/de/wissen/ki-agenten-anbinden/dokumente-pdf-ocr-ki-agent  
Autor: Dr.-Ing. Marcus Rüb, Founder  
Veröffentlicht: 2026-10-14

In den meisten Unternehmen steckt das Wissen, das ein KI-Agent braucht, nicht in Datenbanken, sondern in Dokumenten: Angebote als PDF, eingescannte Lieferscheine, Prüfberichte, Datenblätter, Excel-Kalkulationen und Zeichnungen. Ob ein Agent brauchbare Antworten liefert, entscheidet sich oft schon beim Einlesen dieser Dateien. Dieser Überblick zeigt, wie eine belastbare Dokumenten-Pipeline aufgebaut ist und welche Entscheidungen Sie dabei treffen müssen.

## Was bedeutet es, Dokumente für KI-Agenten zu erschließen?

Dokumente erschließen heißt, aus Dateien einen Text mit Struktur zu machen, den ein Sprachmodell zuverlässig verarbeiten kann: Überschriften, Absätze, Tabellen, Lesereihenfolge und Seitenbezug bleiben erhalten, Scans werden lesbar. Erst darauf kann ein Agent Felder extrahieren, Fragen beantworten oder Vorgänge auslösen.

Das klingt trivial, ist es aber nicht. Ein PDF ist kein strukturiertes Dokument, sondern eine Druckbeschreibung. Die Dokumentation der Python-Bibliothek pypdf sagt es deutlich: Das Format ist darauf ausgelegt, ein gewünschtes Druckbild zu erzeugen, und [PDF-Dateien enthalten keine semantische Ebene](https://pypdf.readthedocs.io/en/stable/user/extract-text.html). Überschriften, Kopfzeilen, Seitenzahlen und Absätze sind nicht als solche markiert, Text liegt als positionierte Zeichen vor. Tabellen sind laut derselben Quelle meist nur absolut positionierter Text, sodass Zeilen und Spalten schwer zu rekonstruieren sind.

Typische Einsatzfelder in Unternehmen:

- **Angebots- und Anfragebearbeitung:** Lastenhefte, Anfrage-PDFs und Zeichnungsköpfe auslesen, um ein Angebot vorzubereiten (siehe [KI-Agent für die Angebotserstellung](https://www.ruebstudio.de/de/ki-agenten/angebotserstellung)).
- **Eingangsbelege:** Bestellungen, Auftragsbestätigungen und Lieferscheine in Felder zerlegen und mit dem ERP abgleichen.
- **Wissensmanagement:** Handbücher, Arbeitsanweisungen und Prüfberichte durchsuchbar machen (siehe [KI-Agent für Wissensmanagement](https://www.ruebstudio.de/de/ki-agenten/wissensmanagement)).
- **Technischer Service:** Wartungsprotokolle und Servicehandbücher für Diagnosefragen nutzbar machen (siehe [KI-Agent für den technischen Service](https://www.ruebstudio.de/de/ki-agenten/technischer-service)).

## Wie funktioniert eine Dokumenten-Pipeline für Agenten?

Eine belastbare Pipeline hat vier Stufen: Dokumenttyp erkennen, Inhalt parsen oder per Texterkennung lesen, in ein strukturiertes Zwischenformat wie Markdown oder JSON überführen und erst dann an den Agenten übergeben. Jede Stufe lässt sich einzeln prüfen, das macht Fehler auffindbar.

**1. Eingang und Klassifikation.** Die Datei kommt aus einem Postfach, einem Netzlaufwerk, einem DMS oder einem Upload. Die Pipeline stellt fest, um welche Art Datei es sich handelt: PDF mit Textebene, PDF aus einem Scanner, Office-Dokument, Bild oder E-Mail mit Anhängen. Davon hängt der weitere Weg ab. Ein einfacher Test für PDFs: Liefert die Textextraktion pro Seite kaum Zeichen, handelt es sich vermutlich um einen Scan.

**2. Parsing und Texterkennung.** Text-PDFs und Office-Dateien werden direkt geparst. Scans brauchen eine Texterkennung, entweder klassische OCR oder ein Vision-fähiges Sprachmodell, das die Seite als Bild liest. Gute Parser erkennen zusätzlich Layout-Elemente: Überschriften, Tabellen, Kopf- und Fußzeilen, Abbildungen, Ankreuzfelder.

**3. Strukturiertes Zwischenformat.** Das Ergebnis wird als Markdown oder JSON gespeichert, mit Seitennummer und Herkunftsdatei. Markdown ist für Sprachmodelle gut lesbar und erhält Tabellen und Überschriften. Das Zwischenformat ist zugleich Ihr Prüfpunkt: Was hier falsch steht, kann der Agent nicht mehr korrigieren.

**4. Übergabe an den Agenten.** Entweder extrahiert ein Modell daraus feste Felder nach einem Schema, oder die Texte werden in Abschnitte zerlegt, indiziert und per Retrieval-Augmented Generation (RAG) bei Bedarf abgefragt. Mehr dazu im Abschnitt über Varianten.

### Werkzeuge für das Parsing (Stand Oktober 2026)

- **[Docling](https://github.com/docling-project/docling)** ist ein quelloffenes Werkzeug unter MIT-Lizenz, gestartet vom AI-for-Knowledge-Team bei IBM Research Zürich und heute ein Projekt der LF AI & Data Foundation. Es verarbeitet laut Repository unter anderem PDF, DOCX, PPTX, XLSX, HTML, E-Mails und Bilder, erkennt Layout, Lesereihenfolge, Tabellenstruktur und Formeln, bietet OCR für Scans und läuft auch lokal ohne Internetverbindung. Ausgabeformate sind laut [Formatübersicht](https://docling-project.github.io/docling/usage/supported_formats/) unter anderem Markdown, HTML, verlustfreies JSON und Chunks für RAG-Pipelines.
- **[Tesseract](https://tesseract-ocr.github.io/tessdoc/)** ist eine OCR-Engine unter Apache-2.0-Lizenz. Seit Version 4 nutzt sie ein LSTM-basiertes neuronales Netz, die aktuelle Hauptversion ist 5, und die offiziellen Sprachdaten decken nach eigener Angabe über 100 Sprachen ab. Tesseract liefert Text, aber keine Tabellenstruktur; es ist ein Baustein, kein vollständiger Dokumenten-Parser.
- **[Azure AI Document Intelligence](https://learn.microsoft.com/en-us/azure/ai-services/document-intelligence/prebuilt/layout)** ist ein Cloud-Dienst von Microsoft. Das Layout-Modell (`prebuilt-layout`, API-Version 2024-11-30 GA) extrahiert Text, Tabellen, Ankreuzfelder sowie Rollen wie Titel, Überschriften, Kopf- und Fußzeilen und kann das Ergebnis als Markdown ausgeben.
- **Sprachmodelle mit direkter PDF-Eingabe:** Laut [Anthropic-Dokumentation](https://platform.claude.com/docs/en/build-with-claude/pdf-support) wandelt die Claude-API jede PDF-Seite in ein Bild um und liefert den extrahierten Text der Seite mit, sodass auch Diagramme und Abbildungen gelesen werden.

Ein minimales Beispiel aus der Docling-Dokumentation, das eine Datei in Markdown umwandelt (aktuelle Version auf PyPI im Oktober 2026: 2.138.0, Python ab 3.10):

```python
from docling.document_converter import DocumentConverter

# Lokaler Pfad oder URL
source = "eingang/lieferschein_4711.pdf"
converter = DocumentConverter()
result = converter.convert(source)
print(result.document.export_to_markdown())
```

## Welche Dokumentarten verlangen welchen Weg?

Nicht jedes Dokument ist gleich schwierig. Text-PDFs aus einem System lassen sich fast verlustfrei parsen, Scans brauchen Texterkennung, Tabellen brauchen Strukturerkennung, und technische Zeichnungen bleiben der schwierigste Fall. Planen Sie die Pipeline nach der Dokumentart, die bei Ihnen am häufigsten vorkommt.

**Text-PDFs** stammen aus ERP, Textverarbeitung oder einem PDF-Drucker. Die Zeichen sind im Dokument enthalten. Probleme entstehen bei der Lesereihenfolge (mehrspaltige Layouts, Randnotizen), bei Leerzeichen und bei Tabellen. Die pypdf-Dokumentation weist darauf hin, dass korrekte Leerzeichen schwer zu garantieren sind, weil Abstände über Positionsangaben statt über echte Leerzeichen entstehen. Ein layoutbewusster Parser löst das deutlich besser als reine Textextraktion.

**Scans und Fotos** enthalten nur Bildpunkte. Ohne Texterkennung sieht der Agent nichts. Die Qualität hängt stark von der Vorlage ab: Tesseract arbeitet laut eigener Dokumentation [am besten mit mindestens 300 dpi](https://tesseract-ocr.github.io/tessdoc/ImproveQuality.html), schief eingezogene Seiten sollten gerade gerichtet und dunkle Scanränder entfernt werden. Stempel, handschriftliche Vermerke und Durchschläge bleiben fehleranfällig, unabhängig vom Werkzeug.

**Tabellen** sind das häufigste Problem in der Praxis: Positionslisten in Bestellungen, Messwerttabellen in Prüfberichten, Stücklisten. Ohne Strukturerkennung verrutschen Spalten, und der Agent ordnet eine Menge der falschen Position zu. Werkzeuge wie Docling oder das Azure-Layout-Modell rekonstruieren Zeilen und Spalten und geben sie als Markdown-Tabelle aus. Prüfen Sie Tabellen trotzdem stichprobenartig, besonders bei verbundenen Zellen und Tabellen über Seitengrenzen.

**Office-Dokumente** (Word, Excel, PowerPoint) sind strukturell einfacher, weil sie Absätze und Tabellen bereits kennen. Bei Excel ist die Frage eher, was der Agent sehen soll: Formeln oder berechnete Werte, alle Blätter oder nur eines. Das Azure-Layout-Modell etwa unterstützt laut Microsoft keine Tabellenanalyse für XLSX-Dateien; hier lohnt sich oft der direkte Zugriff mit einer Tabellenbibliothek.

**Technische Zeichnungen** sind der schwierigste Fall. Schriftfeld, Zeichnungsnummer und Werkstoffangabe lassen sich mit einem Vision-fähigen Modell meist lesen. Bemaßungen, Toleranzen und Bezüge in der Zeichnungsfläche sind dagegen fehleranfällig. Nutzen Sie Zeichnungen deshalb für Metadaten und Vorprüfung, nicht als alleinige Grundlage für Kalkulation oder Fertigung, und lassen Sie Werte, die in ein Angebot fließen, von Fachleuten bestätigen.

### Strukturierte Extraktion oder RAG?

Die zweite Grundsatzentscheidung betrifft, was der Agent mit dem Text tut. Beide Varianten setzen dieselbe Parsing-Stufe voraus, unterscheiden sich aber in Ziel, Prüfbarkeit und Aufbau.

| Kriterium | Strukturierte Extraktion | RAG |
|---|---|---|
| Ziel | feste Felder in ein System schreiben | freie Fragen an viele Dokumente |
| Typisches Dokument | Bestellung, Lieferschein, Rechnung | Handbuch, Richtlinie, Prüfbericht |
| Ergebnis | JSON nach Schema | Antworttext mit Quellenangabe |
| Prüfung | Feld für Feld gegen Regeln | Stichproben, Evals mit Testfragen |

Bei der **strukturierten Extraktion** definieren Sie ein Schema, etwa Bestellnummer, Lieferdatum und Positionen mit Menge und Artikelnummer. Das Modell füllt es aus, Ihre Software validiert es. Anbieter bieten dafür eigene Funktionen: Die Claude-API garantiert mit [Structured Outputs](https://platform.claude.com/docs/en/build-with-claude/structured-outputs) per eingeschränkter Dekodierung schemakonformes JSON. Die Dokumentation nennt aber auch Ausnahmen: Bei Ablehnungen oder abgeschnittenen Antworten kann die Ausgabe vom Schema abweichen, und Schema-Vorgaben wie Minimum und Maximum für Zahlen werden nicht unterstützt. Plausibilitätsprüfungen (Summe der Positionen, gültige Artikelnummer) bleiben deshalb Ihre Aufgabe.

Bei **RAG** werden die Dokumente in Abschnitte zerlegt, als Vektoren indiziert und bei jeder Frage die passenden Abschnitte in den Kontext geladen. Das skaliert auf große Bestände, verlangt aber gutes Chunking: Ein Abschnitt, der mitten in einer Tabelle abgeschnitten wird, liefert falsche Antworten. Deshalb ist ein Parser, der Überschriften und Tabellen erhält, für RAG genauso wichtig wie für die Extraktion.

### Lokal oder in der Cloud verarbeiten?

Die dritte Entscheidung betrifft den Ort der Verarbeitung. Cloud-Dienste ersparen Ihnen den Betrieb eigener Infrastruktur und bringen spezialisierte, laufend gepflegte Modelle mit. Lokale Werkzeuge halten vertrauliche Dokumente im eigenen Netz und lassen sich datenschutzkonform betreibbar aufsetzen, ohne Auftragsverarbeitung bei Dritten.

Beide Stufen lassen sich getrennt entscheiden. Eine häufige Kombination: Parsing und OCR lokal mit Docling oder Tesseract, nur der bereinigte Text geht an ein Sprachmodell. Wer auch das Modell im Haus betreiben will, findet die Grundlagen unter [souveräne KI](https://www.ruebstudio.de/de/souveraene-ki). Beachten Sie bei Cloud-Modellen mit direkter PDF-Eingabe die Grenzen: Die Claude-API nimmt laut [Dokumentation](https://platform.claude.com/docs/en/build-with-claude/pdf-support) Anfragen bis 32 MB und je nach Kontextfenster 100 oder 600 Seiten an, verschlüsselte oder passwortgeschützte PDFs gehen nicht.

## Welche Voraussetzungen brauchen Sie?

Sie brauchen drei Dinge: einen klaren Zugriff auf die Dokumentquellen, eine Vorstellung davon, welche Felder oder Fragen der Agent beantworten soll, und eine Stichprobe echter Dokumente mit bekanntem richtigem Ergebnis. Ohne diese Stichprobe lässt sich Qualität weder messen noch verbessern.

**Daten.** Sammeln Sie 30 bis 100 typische Dokumente je Dokumentart, inklusive der schwierigen: schlechte Scans, Tabellen über mehrere Seiten, Mischungen aus Deutsch und Englisch. Halten Sie für jedes Dokument fest, was der richtige Inhalt der wichtigsten Felder ist. Das ist Ihr Testsatz.

**Systeme.** Klären Sie, woher die Dokumente kommen (Postfach, Netzlaufwerk, SharePoint, DMS) und wohin die Ergebnisse gehen (ERP, CRM, Ticketsystem). Die Pipeline braucht Lesezugriff auf die Quelle und einen definierten Schreibweg ins Ziel, idealerweise über eine API statt über Dateiablagen.

**Organisation.** Legen Sie fest, wer unsichere Ergebnisse prüft und wie schnell. Ein Agent, der bei geringer Sicherheit an einen Menschen übergibt, ist im Betrieb wertvoller als einer, der immer antwortet. Klären Sie außerdem Aufbewahrung und Löschung der Zwischenformate, denn diese enthalten denselben Inhalt wie die Originale.

## Wie gehen Sie Schritt für Schritt vor?

Beginnen Sie mit einer einzigen Dokumentart und einem messbaren Ziel, bauen Sie die Pipeline gegen Ihren Testsatz und erweitern Sie erst, wenn die Ergebnisse stabil sind. Wer alle Dokumentarten gleichzeitig angeht, kann Fehler nicht mehr zuordnen.

1. **Dokumentart wählen.** Nehmen Sie die Art mit dem höchsten Volumen und klarer Struktur, etwa Auftragsbestätigungen von Lieferanten.
2. **Testsatz anlegen.** Echte Dokumente plus erwartete Ergebnisse, wie oben beschrieben.
3. **Parsing testen.** Wandeln Sie den Testsatz mit zwei Werkzeugen in Markdown um und vergleichen Sie Tabellen, Lesereihenfolge und Sonderzeichen von Hand. Hier fallen die meisten Probleme auf.
4. **Extraktion oder RAG aufsetzen.** Schema definieren oder Chunking und Index konfigurieren. Jede Ausgabe bekommt Seitenbezug und Herkunftsdatei.
5. **Prüfregeln ergänzen.** Plausibilitäten, Abgleich mit Stammdaten, Schwellwert für menschliche Prüfung.
6. **Messen.** Feldgenauigkeit bzw. Antwortqualität gegen den Testsatz, Laufzeit und Kosten pro Dokument. Für Kosten bei Cloud-Modellen gibt Anthropic für PDFs [typischerweise 1.500 bis 3.000 Text-Token pro Seite](https://platform.claude.com/docs/en/build-with-claude/pdf-support) an, zuzüglich der Bild-Token, weil jede Seite auch als Bild verarbeitet wird.
7. **In den Prozess einbinden.** Erst nach stabilen Messwerten an das Zielsystem anbinden, zunächst mit Prüfung jedes Ergebnisses, dann schrittweise mit Stichproben.

## Wo liegen Grenzen und Risiken?

Die größten Risiken sind stille Fehler: verrutschte Tabellenspalten, verwechselte Ziffern in Scans und Felder, die das Modell plausibel, aber falsch ergänzt. Sie fallen nicht durch Abstürze auf, sondern erst im Folgeprozess. Gegenmittel sind Seitenbezug, Plausibilitätsprüfungen und menschliche Prüfung bei Unsicherheit.

- **Halluzinierte Felder.** Fehlt ein Wert im Dokument, kann ein Modell ihn aus dem Kontext ableiten oder erfinden. Erlauben Sie im Schema ausdrücklich leere Werte und verlangen Sie für jedes Feld die Fundstelle.
- **Kontextgrenzen.** Lange oder dichte Dokumente sprengen das Kontextfenster eines Modells. Anthropic weist darauf hin, dass dichte PDFs mit kleiner Schrift, komplexen Tabellen oder vielen Grafiken das Kontextfenster füllen können, bevor die Seitengrenze erreicht ist. Teilen Sie solche Dokumente in Abschnitte.
- **Handschrift und Stempel.** Handschriftliche Vermerke, Paraphen und Stempel bleiben fehleranfällig. Wo sie rechtlich relevant sind, etwa bei Abnahmen, gehört ein Mensch in die Prüfung.
- **Sicherheit.** Dokumente aus externen Quellen können Text enthalten, der wie eine Anweisung an das Modell formuliert ist. Behandeln Sie Dokumentinhalt immer als Daten, nie als Befehl, und geben Sie dem Agenten nur die Rechte, die er für die Aufgabe braucht.
- **Wartung.** Ändert ein Lieferant sein Belegformat, kann die Extraktion still schlechter werden. Wiederholen Sie die Messung gegen den Testsatz regelmäßig.

Nicht passend ist eine KI-Pipeline, wenn Ihre Dokumente bereits strukturiert vorliegen, etwa als EDI-Nachricht oder strukturierte E-Rechnung. Dann ist das direkte Einlesen der Struktur zuverlässiger als jede Texterkennung.

## Wie fangen Sie an?

Nehmen Sie 50 echte Dokumente einer Art, wandeln Sie sie mit einem lokalen Parser wie Docling in Markdown um und sehen Sie sich das Ergebnis an. Nach einem Nachmittag wissen Sie, ob Ihr Engpass beim Lesen der Dokumente liegt oder erst bei der Weiterverarbeitung.

Daraus ergibt sich der nächste Schritt. Liegt das Problem beim Lesen, investieren Sie in bessere Scans, ein stärkeres Layout-Modell oder ein Vision-fähiges Sprachmodell. Liegt es bei der Weiterverarbeitung, definieren Sie das Schema schärfer oder verbessern das Chunking. In unserem eigenen Betrieb hat sich bewährt, das Markdown-Zwischenformat dauerhaft zu speichern: Es macht jede spätere Antwort des Agenten auf die Seite zurückverfolgbar.

Welche Agenten auf einer solchen Dokumenten-Pipeline aufsetzen, von der Angebotserstellung bis zum Service, zeigt die Übersicht [KI-Agenten für Fachbereiche](https://www.ruebstudio.de/de/ki-agenten). Weitere Anleitungen zur Anbindung einzelner Systeme finden Sie im [Wissensbereich](https://www.ruebstudio.de/de/wissen).

## Häufige Fragen

### Kann ein Sprachmodell ein PDF nicht einfach direkt lesen?

Viele Modelle nehmen PDFs direkt an, Claude etwa wandelt jede Seite in ein Bild um und liefert den extrahierten Text mit. Für Einzelfragen genügt das; für Tausende Dokumente, wiederkehrende Felder oder lokale Verarbeitung lohnt sich eine eigene Parsing-Stufe.

### Brauche ich für eingescannte Lieferscheine zwingend OCR?

Ja, irgendeine Form der Texterkennung ist nötig, weil ein Scan nur Bildpunkte enthält. Das kann klassische OCR wie Tesseract sein oder ein Vision-fähiges Sprachmodell, das die Seite als Bild liest.

### Wann ist strukturierte Extraktion besser als RAG?

Wenn Sie immer dieselben Felder brauchen, etwa Bestellnummer, Liefertermin und Positionen, und diese in ein System schreiben wollen. RAG passt, wenn Mitarbeitende freie Fragen an einen großen, wechselnden Dokumentenbestand stellen.

### Lassen sich vertrauliche Dokumente ohne Cloud verarbeiten?

Ja. Werkzeuge wie Docling und Tesseract laufen vollständig lokal, und auch das Sprachmodell kann auf eigener Hardware betrieben werden. Der Preis dafür ist eigener Betriebsaufwand; die Erkennungsqualität sollten Sie an Ihren eigenen Vorlagen vergleichen.

## Quellen

- [Anthropic: PDF support (Claude API Dokumentation)](https://platform.claude.com/docs/en/build-with-claude/pdf-support)
- [Anthropic: Structured outputs (Claude API Dokumentation)](https://platform.claude.com/docs/en/build-with-claude/structured-outputs)
- [Docling – GitHub-Repository](https://github.com/docling-project/docling)
- [Docling: Supported formats](https://docling-project.github.io/docling/usage/supported_formats/)
- [pypdf: Extract Text from a PDF](https://pypdf.readthedocs.io/en/stable/user/extract-text.html)
- [Tesseract OCR – Dokumentation](https://tesseract-ocr.github.io/tessdoc/)
- [Tesseract: Improving the quality of the output](https://tesseract-ocr.github.io/tessdoc/ImproveQuality.html)
- [Microsoft Learn: Document Intelligence layout model](https://learn.microsoft.com/en-us/azure/ai-services/document-intelligence/prebuilt/layout)