Wie KI unstrukturierte Daten für bessere Entscheidungen verarbeitet

Die wichtigsten Erkenntnisse

• IDP umfasst vier Phasen, die jeweils auf unterschiedliche Weise scheitern können: Parsing, Extraktion, Governance, Retrieval. Die meisten Projekte scheitern an der Governance, nicht am Modell.
• KI-basiertes Parsing überzeugt bei beeinträchtigten und variablen Layouts. Regelbasiertes RPA ist weiterhin überlegen bei stabilen, hochvolumigen Vorlagen mit geringen Extraktionskosten. Die Wahl richtet sich nach der Dokumentenvarianz, nicht nach dem Hype.
• Die Schema-Generierung ist ein fortlaufender Prozess. Dokumententypen verändern sich im Laufe der Zeit. Etablieren Sie von Anfang an einen Prüfzyklus mit menschlicher Beteiligung (Human-in-the-Loop).
• Werden personenbezogene Daten verarbeitet, gilt die DSGVO. Wird das System nach dem EU AI Act als Hochrisiko-System eingestuft, gilt dieser zusätzlich. Es handelt sich um getrennte Regelwerke, nicht um eine einzige Checkliste.
• In regulierten Branchen beseitigt eine On-Premise-Bereitstellung von LLMs eine ganze Klasse von Compliance-Risiken. Kosten und Latenz verändern sich dabei ebenfalls – in beide Richtungen.
• Erfahrungswerte aus unseren Pilotprojekten: Die Datenaufbereitung beansprucht 50–65 % des Aufwands. Die Modellierung liegt bei 10–15 %. Planen Sie entsprechend.
• Für vertieftes technisches Hintergrundwissen zum modernen RAG- und Orchestrierungs-Stack siehe unseren Leitfaden zum KI-Entwicklungs-Tech-Stack.

Wie KI unstrukturierte Inhalte parst

Beim Parsing wird eine Datei in Text und Layout überführt, über die ein Modell schlussfolgern kann. Die Qualität in dieser Phase begrenzt alles Nachfolgende. Ein schlechter Parser lässt sich nicht durch ein besseres Embedding-Modell kompensieren.

Die Arbeit ist wenig glamourös: Dateien deduplizieren, Kodierungen korrigieren, PDFs, DOCX, Scans und HTML in eine gemeinsame Darstellung normalisieren, Tabellen erkennen, Boilerplate entfernen und anschließend an Satz- oder Absatzgrenzen chunken. Moderne Parser kombinieren OCR mit Layout-Modellen, sodass ein Datum im Vertragskopf anders behandelt wird als ein Datum in der Fußzeile.

Der ehrliche Vergleich mit regelbasiertem RPA sieht wie folgt aus.

Die Abwägung ist substanziell. Wenn 95 % Ihrer eingehenden Dokumente identische Bestellungen von drei Lieferanten sind, ist die regelbasierte Extraktion günstiger und einfacher zu auditieren. Wenn Sie 200 Vertragsvorlagen von 40 Vertragspartnern verarbeiten, amortisiert sich das KI-Parsing bereits im ersten Quartal.

Zwei praktische Hinweise aus unserer eigenen Arbeit. Erstens: Bei einem großskaligen Bildsuchsystem mit mehr als 6 Millionen Bildern haben wir festgestellt, dass eine konsistente Vorverarbeitung – Zuschneiden, Rauschunterdrückung, Normalisierung – wichtiger war als der Austausch des zugrunde liegenden Modells. Zweitens: Die Chunking-Strategie ist der Punkt, an dem die meisten RAG-Projekte Qualität verlieren. Trennen Sie an Satz- oder Absatzgrenzen, nicht an festen Zeichenanzahlen.

Wie KI Felder extrahiert und Schemata generiert

Nach dem Parsing wandelt die Pipeline Rohtext in benannte Felder um. Dies ist KI-basierte Dokumentenextraktion, Klassifikation und Schema-Generierung – der Teil, der etwas erzeugt, das eine Datenbank aufnehmen kann.

Der Workflow, den wir in produktiven Projekten einsetzen:

1. Jedes Dokument wird in eine Vektordarstellung eingebettet, um Vektorsuche und Clustering zu ermöglichen.
2. Die Embeddings werden geclustert. Natürliche Dokumententypen ergeben sich aus den Daten und nicht aus einer angenommenen Taxonomie.
3. Für jedes Cluster wird ein JSON-Schema mit Feldnamen, Typen und Pflichtfeldkennzeichnungen entworfen.
4. Überlappende oder mehrdeutige Cluster werden markiert. Ein Prüfer entscheidet, ob sie aufgetrennt oder zusammengeführt werden.
5. Das Schema wird für den Produktivbetrieb fixiert. Ein Änderungsprotokoll wird geführt.

Für eine vertiefte Auseinandersetzung mit vorgelagerter Datendisziplin, die nachgelagerte Schemata funktionsfähig macht, siehe unseren Leitfaden zur Datenstrategie für KI.

Die Falle liegt darin, dies als einmalige Einrichtung zu behandeln. Dokumentenformate verändern sich. Ein neuer Lieferant ergänzt ein Feld. Eine Regulierungsbehörde ändert das Formular. Sechs bis achtzehn Monate später verschlechtert sich die Extraktionsqualität unbemerkt, abhängig davon, wie schnell sich die Dokumentenquellen ändern. Die Schema-Prüfung benötigt einen festen Rhythmus – quartalsweise ist ein angemessener Ausgangspunkt, monatlich bei hohen Volumina.

Ein konkretes Beispiel aus unserem Portfolio: Bei unserer KI-basierten Lebenslauf-Prüfung für Kunden aus FinTech und Marketing verlangte dieselbe Position bei zwei Unternehmen unterschiedliche Nachweise. Fest kodierte Feldlisten übersahen die Hälfte der Signale. Cluster-basierte Schemata, die quartalsweise aktualisiert wurden, erfassten sie.

Vorteile der LLM-gesteuerten Schema-Generierung: Sie skaliert über Hunderte von Dokumententypen, deckt Kategorien auf, die andernfalls übersehen worden wären, und reduziert den anfänglichen Analyseaufwand. Nachteile: Sie halluziniert Felder, wenn Cluster zu klein sind, erfordert eine menschliche Prüfung, um sicherzugehen, und verursacht zusätzliche Embedding- und LLM-Inferenzkosten pro Dokument. Ab etwa einigen Tausend Dokumenten pro Typ lohnt sich der Aufwand. Darunter sollte das Schema manuell erstellt werden.

Warum scheitern die meisten IDP-Projekte an der Governance?

Die meisten IDP-Fehlschläge, zu denen wir zur Behebung hinzugezogen werden, sind keine Modellfehler. Es handelt sich um Governance-Fehler. Das Modell arbeitete wie vorgesehen, doch der Dokumentenkorpus, den es verarbeitete, war veraltet, dupliziert oder ohne verantwortlichen Eigentümer.

Vier Governance-Praktiken machen den Unterschied zwischen einem IDP-System, dem vertraut wird, und einem, das Entscheidungen unbemerkt beeinträchtigt:

• Eigentümerschaft: Jede Dokumentenklasse hat einen namentlich benannten Eigentümer auf der Fachseite. Kein Eigentümer, kein Produktivzugriff.
• Lebenszyklus: Dokumente haben ein explizites Ablauf- oder Prüfdatum. Richtlinien, die älter sind als die Regel, auf die sie sich beziehen, werden archiviert und nicht mehr abgerufen.
• Berechtigungsbewusstes Retrieval: Die Suchschicht berücksichtigt die Zugriffskontrolle zur Abfragezeit und nicht nur bei der Aufnahme. Ein Anwender ohne Zugriff auf einen Vertrag darf niemals einen Ausschnitt daraus in einer Chatbot-Antwort sehen.
• Audit-Trail: Jede Extraktionsentscheidung muss reproduzierbar sein. Welche Dokumentversion, welche Version des Extraktionsmodells, welche Schema-Version. Ohne dies lässt sich eine Compliance-Anfrage zu einer Entscheidung, die vor zwölf Monaten getroffen wurde, nicht belastbar beantworten.

Die rechtliche Ebene lrigt parallel dazu, nicht darin eingebettet. Halten Sie die Grenzen sauber.

• Wenn Sie personenbezogene Daten aus der EU verarbeiten, gilt die DSGVO. Sie regelt Rechtsgrundlage, Aufbewahrung und Betroffenenrechte, unabhängig davon, ob KI beteiligt ist.
• Wird das System selbst nach dem EU AI Act als Hochrisiko-System eingestuft, kommen weitere Pflichten hinzu: Risikomanagement, Data Governance, Protokollierung, menschliche Aufsicht.
• Im Mai 2026 verschob die Einigung zum Digital Omnibus zur AI die Hochrisiko-Pflichten nach Anhang III auf Dezember 2027. Dies erweitert das Compliance-Fenster für Hochrisiko-Anwendungen, verändert jedoch nicht die Gestaltungsprinzipien. Systeme, die heute mit Governance, Protokollierung und menschlicher Aufsicht konzipiert werden, vermeiden Nacharbeiten, sobald die Frist erreicht wird.
• Britische Implementierungen unterliegen der Aufsicht der ICO nach britischem Datenschutzrecht.
• US-Teams ohne verbindliches bundesstaatliches KI-Gesetz orientieren sich häufig freiwillig am NIST AI Risk Management Framework.
• Bildungsprodukte, die US-Schülerdaten verarbeiten, fallen zudem unter FERPA.

Für das vollständige Compliance-Bild über FERPA, DSGVO, EU AI Act und US-Bundesstaatengesetze hinweg siehe unseren Leitfaden zum Datenschutz bei KI-Implementierungen.

Es handelt sich um getrennte Regelwerke mit unterschiedlichen Auslösern. Sie in einem einzigen Aufzählungspunkt zusammenzufassen, führt dazu, dass Teams Pflichten übersehen.

Polina Volodina, KI-Beraterin bei Silk Data, formuliert die Scoping-Frage, die wir Kunden stellen, bevor eine Architektur entworfen wird: „Bevor wir über Modelle sprechen, kartieren wir, welche Daten personenbezogen sind, in welcher Jurisdiktion sie liegen und wer für welche Dokumentenklasse verantwortlich ist. Das entscheidet, ob das System überhaupt in einer Public Cloud laufen kann.“

Für Kunden in regulierten Branchen lautet die Antwort häufig: On-Premise. Wir haben lokale LLMs implementiert, die in der internen Plattform einer Marketingagentur laufen, sodass Kundendaten den Perimeter nie verlassen. Die Abwägung ist substanziell: On-Premise bedeutet mehr Einrichtungsaufwand, weniger Modellauswahl und höhere Infrastrukturkosten. Es beseitigt aber auch eine Klasse von Compliance- und Vertraulichkeitsrisiken, die kein API-Vertrag vollständig neutralisieren kann.

Wie Pipelines Dokumente in Entscheidungen überführen

Das Ergebnis einer IDP-Pipeline sind nicht saubere Daten. Es sind schnellere, belastbare Entscheidungen. Eine Vertragsprüfung, die zwei Tage gedauert hat, dauert jetzt zwei Stunden. Ein Schadensfall, der drei Übergaben erforderte, wird nun automatisch weitergeleitet.

Speziell für RAG-Pipelines entscheidet die Qualität des Retrievals – nicht die Qualität der Generierung – darüber, ob die Antwort korrekt ist. Vier Muster sollten von Anfang an konsequent umgesetzt werden:

• Mehrstufige Indexierung. Speichern Sie feingranulare Chunks für Präzision und übergeordnete Metadaten (Titel, Abschnitt, Seite, Dokumententyp) für den Kontext. Ein Chunk ohne seinen übergeordneten Kontext ist oft technisch relevant, aber praktisch falsch.
• Getrennte Ingest- und Retrieval-Pipelines. Optimieren Sie Embedding und Chunking beim Ingest im Batch-Modus. Halten Sie das Retrieval zur Abfragezeit schlank und konsistent mit demselben Embedding-Raum. Eine Kopplung beider führt dazu, dass Teams nach dem Start feststellen, dass eine Dokumentaktualisierung den gesamten Korpus neu einbetten muss.
• Hybrides Retrieval. Kombinieren Sie dichtes (vektorbasiertes) und dünnbesetztes (schlüsselwortbasiertes) Retrieval. Dichtes Retrieval bewältigt semantische Abfragen gut, verfehlt jedoch Exact-Match-Fälle (Vertragsnummern, Rechnungs-IDs, Gesetzesverweise). Hybrides Retrieval erfasst beides.
• Query Rewriting. Anwenderfragen entsprechen selten der Art, wie Dokumente formuliert sind. Ein Query Rewriter (LLM-basiert) formuliert die Frage in Formen um, die zu abrufbaren Inhalten passen. Das erhöht die Latenz, verbessert aber den Recall.

Zwei Produktivbeispiele aus unserer Arbeit zeigen, wie nutzbare Ergebnisse aussehen. In unserem Projekt zur automatischen Nachrichtenanalyse speisen geparste Artikel Clustering, Opinion Mining und Quervergleiche zwischen Quellen, die als Chrome-Erweiterung bereitgestellt werden. Redakteure erhalten Unterschiede zwischen Quellen und keinen Berg von Duplikaten. In einer siebenjährigen Partnerschaft mit einem deutschen Verlagshaus haben wir eine KI-Suche und ein lokales LLM auf deren Archiven aufgebaut.

Wie Silk Data belastbare IDP-Systeme entwickelt

Wir haben NLP- und Dokumentenverarbeitungssysteme für Kunden aus Verlagswesen, FinTech, Marketing und EdTech ausgeliefert. Das wiederkehrende Muster: Beginn mit einem dreimonatigen Proof of Concept auf einer tatsächlichen Dokumentenauswahl, Messung an einer Baseline (häufig der bestehende manuelle Prozess oder regelbasiertes RPA) und erst dann Entscheidung für den vollständigen Rollout. Wenn SQL oder eine Regel-Engine ausreicht, sagen wir das. Wenn On-Premise die einzige belastbare Bereitstellung ist, sagen wir auch das. Für einen tieferen Einblick in die Frage, wann sich individuelle KI-Entwicklung im Vergleich zu Standardplattformen lohnt, siehe unseren Leitfaden zur individuellen KI-Entwicklung.

Yuri Svirid, CEO von Silk Data, zur Empfehlung, die wir neuen Kunden am häufigsten geben: „Das erste Ergebnis ist meist kein Modell. Es ist eine klare Antwort auf die Frage, ob man selbst entwickeln, kaufen oder darauf verzichten sollte. In etwa einem Drittel der Fälle lautet die ehrliche Empfehlung, dass dieses Problem noch keine KI benötigt. Dieses Gespräch ist mehr wert als ein Pilotprojekt, das nie hätte starten sollen.“

Für eine käuferorientierte Sicht auf denselben Problembereich behandelt unser Leitfaden zu Beispielen zur KI-Dokumentenverarbeitung Anwendungsfälle, Werkzeugebenen und Plattformkategorien.

Wenn Sie über einen Dokumentenbestand verfügen, den Sie nicht abfragen können, schreiben Sie an hello@silkdata.ai und nennen Sie die Dokumententypen, Volumina und die Jurisdiktion. Wir sagen Ihnen, wie sinnvolle erste drei Monate aussehen.