Unstrukturiertes ETL: Der Integrationsansatz, den Enterprise-KI erfordert

Die meisten Unternehmensdaten sind unstrukturiert. Die meisten ETL-Pipelines ignorieren sie. So lässt sich diese Lücke schließen.

Wenn die meisten Teams über ETL sprechen, denken sie in der Regel an relationale Daten. Tabellen, Schemata, Fremdschlüssel. Ein Quellsystem, ein Transformationsschritt, ein bereinigtes Zielsystem. Es handelt sich um ein gut bekanntes Problem mit gut bekannten Lösungen.

Unstrukturierte Daten stellen ein ganz anderes Problem dar. PDFs, Verträge, E-Mail-Verläufe, Support-Tickets, Audio-Transkripte, Bilder, HTML-Seiten, frei formatierte Protokolle. Diese Inhalte machen einen erheblichen Teil der Daten aus, über die die meisten Unternehmen tatsächlich verfügen, und dennoch versuchen klassische ETL-Tools nicht einmal, sich damit auseinanderzusetzen.

Diese Lücke in der Transparenz wird zunehmend zu einem Problem. Die KI-Anwendungsfälle, in die Unternehmen heute investieren, benötigen Zugriff auf die unstrukturierten Datenquellen, auf denen das Geschäft tatsächlich basiert. Zum Beispiel vielleicht:

• Der Workflow für Vertragsanalysen muss PDF-Dateien lesen können
• Die KI im Kundenservice muss Tickets und Anrufaufzeichnungen bearbeiten 
• Das System zur Überwachung der Einhaltung von Vorschriften muss Richtliniendokumente analysieren und Abweichungen kennzeichnen

Wenn Ihre Integrationsschicht diese Eingaben nicht verarbeiten kann, kann die KI-Schicht (die darauf angewiesen ist) ihre Aufgabe nicht effektiv erfüllen.

Was unstrukturiertes ETL eigentlich beinhaltet

Strukturiertes ETL ist ein Pipeline-Problem. Unstrukturiertes ETL ist etwas anderes: ein Verständnisproblem, dem eine Pipeline zugrunde liegt.

Schon der Extraktionsschritt ist keine triviale Angelegenheit. Eine PDF-Datei kann ein gescanntes Bild, ein natives Dokument oder eine Mischung aus beidem sein. Ein Vertrag kann Tabellen, handschriftliche Anmerkungen und Anhänge enthalten. Ein E-Mail-Thread kann auf ein Dokument verweisen, das sich in einem separaten System befindet. Bevor eine Umwandlung stattfinden kann, müssen die Rohdaten analysiert, bei Bedarf per OCR verarbeitet und in sinnvolle Einheiten segmentiert werden.

Dann folgt die Strukturableitung. Worum geht es in diesem Dokument? Auf welche Entitäten bezieht es sich? Welche Schlüsselfelder sind für nachgelagerte Systeme von Bedeutung? Bei strukturierten Daten liefert das Schema die Antworten auf diese Fragen. Bei unstrukturierten Daten muss die Extraktionsschicht die Antworten ableiten, in der Regel mithilfe einer Kombination aus Regeln, der Erkennung benannter Entitäten und zunehmend auch großer Sprachmodelle.

Schließlich müssen die Ergebnisse an einem sinnvollen Ort gespeichert werden: in einem Vektorspeicher für die semantische Suche, in einer relationalen Datenbank für die Berichterstellung oder in einer nachgelagerten Anwendung, die ein bestimmtes Datenschema erwartet. Die Schritte der Transformation und des Ladens sind bekannt, doch die Verwertbarkeit der Ergebnisse hängt vollständig von der Qualität der Ergebnisse der Auswertungsschicht ab.

Wo Unternehmen in Schwierigkeiten geraten: Fehlerursachen

Die Festlegung einer Strategie für unstrukturiertes ETL ist nur die halbe Miete. Bei der Skalierung auf die Produktionsumgebung scheitern die meisten Unternehmen. Hier sind die häufigsten Fehlerquellen, die KI-Datenpipelines untergraben.

Zersiedelung durch Punktlösungen

Die häufigste Fehlerquelle ist die Zersplitterung durch Einzellösungen. Ein Team erstellt ein Python-Skript, um Daten aus PDF-Dateien zu extrahieren. Ein anderes Team nutzt ein anderes Tool für die E-Mail-Verarbeitung. Ein drittes Team übernimmt die Dokumentenerfassung manuell. Keiner dieser Prozesse verfügt über gemeinsame Funktionen zur Überwachung, Fehlerbehandlung, Herkunftsverfolgung oder Governance-Kontrollen. Das Ergebnis ist eine Ansammlung instabiler, unsichtbarer Pipelines, die unbemerkt ausfallen und nicht überprüft werden können. Wenn ein nachgelagertes KI-Modell fehlerhafte Ergebnisse liefert, ist es ein Projekt für sich, den Fehler auf ein Datenqualitätsproblem in einem undokumentierten Extraktionsskript zurückzuführen.

Unterschätzung des Volumens

Die zweite Fehlerquelle besteht darin, das Volumenproblem zu unterschätzen. Unstrukturierte Daten treffen nicht in vorhersehbaren Abständen in Chargen ein. Sie sammeln sich kontinuierlich an. Support-Anfragen gehen rund um die Uhr ein. Verträge werden nach den Zeitplänen der Geschäftsabschlüsse abgeschlossen, nicht nach den Zeitplänen des Integrationsteams. Eine Verarbeitungsarchitektur, die bei 1.000 Dokumenten pro Tag gut funktioniert, hält bei 100.000 möglicherweise nicht mehr stand.

Berechtigungen außer Acht lassen

Die dritte Fehlerquelle besteht darin, die Bedeutung von Zugriffsrechten und ACLs zu vernachlässigen. Für alle diese Dokumente sind an ihrem Speicherort Zugriffsrechte festgelegt, unabhängig davon, ob sie sich in einem Dateispeicher befinden oder an ein anderes Objekt angehängt sind (ein Ticket, eine E-Mail oder ein Datensatz in einem CRM-System). Diese Berechtigungen müssen beachtet und zusammen mit den aus dem Dokument ausgelesenen Informationen weitergegeben werden, um zu vermeiden, dass die Erfassung zu einer Quelle für Datenlecks wird, die eigentlich eingeschränkt sein sollten oder gesetzlichen Vorschriften unterliegen.

Einmal einstellen und dann vergessen 

Der letzte Fehler ist, unstrukturiertes ETL als einmalige Maßnahme zu betrachten. Dokumentformate ändern sich. E-Mail-Systeme werden ersetzt. Neue Datenquellen kommen hinzu. Eine dauerhafte Lösung erfordert Pipelines, die gegenüber diesen Änderungen robust sind und die aktualisiert, getestet und versioniert werden können. Einmalige Extraktionsskripte reichen langfristig nicht aus. 

So sieht ein produktionsreifer Ansatz aus

Der Ausgangspunkt besteht darin, die Extraktion unstrukturierter Daten als vollwertigen Pipeline-Typ zu behandeln und nicht als Ausnahme, die außerhalb der zentralen Integrationsplattform behandelt werden muss. Das bedeutet, dass hier dieselben Funktionen für die visuelle Erstellung, Überwachung, Alarmierung, Wiederholungslogik und Herkunftsverfolgung gelten wie bei strukturierten Pipelines.

SnapLogic erfüllt diese Anforderung durch eine Kombination aus nativen Snaps zur Dokumentenverarbeitung, mit LLM verbundenen Extraktionspipelines und einem Metadaten-Framework, das Herkunftsinformationen von der Quelle zum Ziel überträgt. Eine Pipeline, die Verträge einliest, kann wichtige Daten, Vertragsparteien, Verpflichtungen und Vertragsstrafenklauseln extrahieren, die Ausgabe anhand eines Schemas validieren und das Ergebnis an das richtige nachgelagerte System weiterleiten – und das alles innerhalb derselben Orchestrierungsschicht, die auch für die Datenbankreplikation und die API-Integration verwendet wird.

Der praktische Vorteil liegt in der einheitlichen Abwicklung. Das Team, das Ihre Salesforce-Synchronisierungspipeline überwacht, nutzt dasselbe Dashboard, um auch Ihre Pipeline zur Vertragserfassung zu überwachen. Anomalien werden an einer zentralen Stelle sichtbar. Herkunftsabfragen funktionieren sowohl für strukturierte als auch für unstrukturierte Quellen. Compliance-Teams können Datenflüsse prüfen, ohne wissen zu müssen, welche maßgeschneiderten Skripte wo ausgeführt werden.

Die Rolle von LLMs in der Extraktionsschicht

Große Sprachmodelle haben die Möglichkeiten der Extraktion aus unstrukturierten Daten grundlegend verändert. Aufgaben, die zuvor eine aufwendige Regelentwicklung erforderten – wie beispielsweise die Extraktion von Klauseln aus nicht standardisierten Vertragsformaten oder die Klassifizierung der Absicht von frei formulierten Support-Nachrichten –, können nun durch einen gut mit Prompts versehenen Modellaufruf innerhalb der Pipeline bewältigt werden.

Der Schlüssel liegt darin, LLM-Aufrufe als Pipeline-Komponenten zu behandeln, für die dieselbe operative Disziplin gilt wie für jeden anderen Schritt. Das bedeutet, Eingabeschemata zu definieren, Ausgaben zu validieren, Fehler elegant zu handhaben und gegebenenfalls zwischenzuspeichern, um die Kosten zu kontrollieren. Ein LLM-Extraktionsschritt, der ohne Validierung oder Wiederholungslogik ausgeführt wird, ist ein Risiko. Ein ordnungsgemäß instrumentierter Schritt hingegen ist eine dauerhafte Funktion, auf die sich Kerngeschäftsprozesse verlassen können.

Die KI-Integrationsschicht von SnapLogic macht LLM-Aufrufe zu vollwertigen Bestandteilen der Pipeline. Modelle führender Anbieter lassen sich über „Snaps“ anbinden – mit konfigurierbaren Wiederholungsversuchen, Auswertungsanalyse und Weiterleitung an nachgelagerte Prozesse. Teams können Extraktionspipelines erstellen, die ein LLM zur Inhaltsauswertung aufrufen und die strukturierten Ergebnisse anschließend an ein beliebiges Ziel weiterleiten – ganz ohne benutzerdefinierten Orchestrierungscode.

OEM- und Embedded-Integration: eine Chance für ISVs und Plattformentwickler

Unstrukturiertes ETL ist sowohl für Unternehmens-IT-Abteilungen als auch für Softwareanbieter eine gleichermaßen nützliche Funktion, die diese direkt in ihre eigenen Produkte integrieren können. Denken Sie dabei an Branchen, in denen dokumentenintensive Arbeitsabläufe zum Standard gehören. Dazu zählen beispielsweise Legal-Tech, Versicherungen, das Gesundheitswesen, Finanzdienstleistungen, Beschaffungsplattformen und das Vertragslebenszyklusmanagement. 

In jedem dieser Märkte erwarten Kunden von den Anbietern, dass diese Dokumente nicht nur speichern, sondern auch sinnvoll nutzen. Schlüsselbegriffe extrahieren. Unregelmäßigkeiten kennzeichnen. Felder automatisch ausfüllen. Relevante Klauseln hervorheben.

Anbieter, die diese Frage mit einer nativen Funktion beantworten können – und nicht mit der Aufforderung, eine Verbindung zu einem Drittanbieter-Tool herzustellen –, verfügen über einen bedeutenden Produktvorteil. Und der schnellste Weg zu dieser Funktion führt über die Einbindung einer bewährten Integrations- und Extraktionsschicht, anstatt eine solche von Grund auf neu zu entwickeln.

Das OEM-Programm von SnapLogic ermöglicht es Softwareanbietern, die gesamten Integrations- und ETL-Funktionen – einschließlich der Verarbeitung unstrukturierter Daten – direkt in ihre eigenen Plattformen einzubetten. Die Lösung wird als White-Label-Produkt bereitgestellt und in der Infrastruktur des Anbieters implementiert. Kunden nutzen eine native Funktion und kein separates Integrationstool. Der Anbieter gestaltet die Benutzeroberfläche, während SnapLogic die technische Umsetzung übernimmt.

Für Produktteams, die prüfen, wie sie ihre Plattform um Dokumentenintelligenz erweitern können, läuft die Frage „Selbst entwickeln oder integrieren“ in der Regel auf die langfristigen Wartungskosten hinaus. Die Entwicklung eines maßgeschneiderten Extraktions-Stacks bedeutet, die Verantwortung für die OCR-Ebene, die LLM-Orchestrierung, das Konnektor-Ökosystem, die Überwachungsinfrastruktur und die Compliance-Kontrollen zu übernehmen. 

Durch die Integration von SnapLogic stehen diese Funktionen vom ersten Tag an zur Verfügung, sodass die Entwickler ihre Zeit darauf verwenden können, das Produkt von der Konkurrenz abzuheben, anstatt sich mit der zugrunde liegenden Infrastruktur zu beschäftigen.

Von der Theorie zur Pipeline: Erste Schritte

Der praktische Ausgangspunkt für die meisten Teams besteht darin, zwei oder drei Dokumenttypen mit hohem Volumen zu identifizieren, die derzeit manuell bearbeitet werden müssen oder für deren Verarbeitung instabile und isolierte Skripte verwendet werden. Verträge, Rechnungen und Support-Tickets sind gängige Ansatzpunkte. Der Aufbau einer geregelten und überwachten Extraktionspipeline für diese Quellen schafft ein wiederverwendbares Muster, das sich auf den nächsten Anwendungsfall ausweiten lässt, ohne dass man wieder bei Null anfangen muss.

Für Produktteams stellt sich die Frage, welche KI-Funktionen in Ihrer Roadmap vom Zugriff auf Dokumente oder unstrukturierte Daten abhängen und ob Sie die entsprechenden Funktionen selbst entwickeln oder einbinden möchten, um diese zu unterstützen.

So oder so, das zugrunde liegende Prinzip ist dasselbe. KI-Workflows sind nur so leistungsfähig wie die ihnen zugrunde liegende Datenzugriffsebene. Diese Ebene richtig zu gestalten – unter Einbeziehung sowohl strukturierter als auch unstrukturierter Quellen – ist die Grundlage, die alles andere erst möglich macht.

Möchten Sie sehen, wie es in der Praxis funktioniert? Nehmen Sie an einer selbstgesteuerten Produkttour teil oder vereinbaren Sie eine Demo, um einen SnapLogic-Integrationsexperten kennenzulernen und über unstrukturiertes ETL für Ihre Umgebung oder Ihr Produkt zu sprechen.