Warum klassisches ETL für KI-Agenten oft nicht mehr ausreicht — und ELT an Bedeutung gewinnt (Datenintegration 2026)
Ende März 2026 löste ein Hacker-News-Post über Grafeo — eine neue einbettbare Graphdatenbank — eine Diskussion darüber aus, welche Anforderungen moderne Dateninfrastrukturen für KI-Systeme erfüllen müssen.
Traditionelle relationale Datenbanken allein decken viele agentische Anforderungen nicht vollständig ab, insbesondere bei unstrukturierten Daten, semantischer Suche und komplexen Beziehungsmodellen. Graphstrukturen, Vektordatenbanken, semantische Layer — das sind keine Hype-Technologien mehr, sondern für viele KI-Deployments relevante Bausteine.
DACH-Unternehmen, die ihre KI-Strategie aufbauen, während ihre Datenpipelines im ETL-Paradigma feststecken, schaffen oft keine optimale Grundlage für skalierbare KI-Anwendungen.
ETL vs. ELT: Der schnelle Rückblick
Für alle, die die Grundlagen brauchen:
ETL (Extract, Transform, Load) Die klassische Methode: Daten werden aus Quellsystemen extrahiert, dann transformiert (bereinigt, zusammengeführt, aggregiert), und erst dann ins Zielsystem geladen. Die Transformation passiert in einem separaten, spezialisierten Prozess — typischerweise in einem ETL-Tool oder auf einem ETL-Server.
ELT (Extract, Load, Transform) Die moderne Methode: Daten werden aus Quellsystemen extrahiert, sofort in Rohform in ein leistungsfähiges Zielsystem geladen, und die Transformation passiert dort — on-demand, mit der vollen Rechenleistung des Zielsystems (Data Warehouse, Data Lake, Data Lakehouse).
Klingt nach einer technischen Reihenfolge-Frage. Ist aber fundamental anders.
Wo klassisches ETL bei KI-Agenten an Grenzen stößt
Fünf Bereiche, in denen das ETL-Paradigma für agentische KI-Anforderungen oft weniger geeignet ist:
1. Schema-First vs. Schema-Flexibel ETL setzt ein definiertes Schema voraus: Hier sind die Felder, hier die Datentypen, hier die Transformationsregeln. KI-Agenten brauchen Schema-Flexibilität — sie verarbeiten unstrukturierte Dokumente, variablen JSON, E-Mail-Texte, die alle unterschiedliche Strukturen haben. Starre ETL-Pipelines reagieren oft empfindlich auf unerwartete Feldstrukturen oder Schemaänderungen.
2. Batch vs. Real-Time ETL wurde für nächtliche Batch-Läufe designt. "Gestern Nacht wurden die Daten transformiert" war akzeptabel, wenn Mitarbeiter am nächsten Morgen einen Report sehen. Ein KI-Agent, der in Echtzeit auf eine Kundenanfrage reagiert, braucht Daten von jetzt — nicht von gestern Nacht.
3. Vorab-Transformation vs. On-Demand-Query ETL transformiert alle Daten im Voraus, nach vordefinierten Regeln. KI-Agenten stellen ad-hoc Fragen, die niemand vorhergesehen hat: "Was ist die Kaufhistorie dieses Kunden kombiniert mit seiner Service-Ticket-Frequenz kombiniert mit seiner letzten Vertragsänderung?" Solche Kombinationen lassen sich für viele agentische Use Cases schwerer vorab transformieren.
4. Zentralisierte Logik vs. Agenten-natürliche Datenzugriffe In ETL liegt die Transformationslogik in der Pipeline. In einer agentischen Architektur liegt die Logik im Agenten — und der Agent greift direkt auf Daten zu. Das macht direkte, flexible Datenzugriffe wichtiger als fertig-transformierte Reports.
5. Monolithische Pipelines vs. Modular-Composable Layers ETL-Pipelines sind oft hart gekoppelt: Eine Änderung in der Quelltabelle kann die Transformation beeinflussen. Agentische KI-Architekturen profitieren von modularen, unabhängigen Datenschichten, die sich ohne kaskadierende Abhängigkeiten weiterentwickeln können.
Ein praxistauglicher Data Stack für KI-Agenten
Ein praxistauglicher Ansatz kombiniert vier Schichten:
Schicht 1: Data Lakehouse (Speicher + Verarbeitung) Ein Data Lakehouse (Snowflake, Databricks, Azure Fabric) kombiniert die Flexibilität eines Data Lakes (unstrukturierte und semistrukturierte Daten, Schema-on-Read) mit der Performance eines Data Warehouses (ACID-Transaktionen, SQL-Abfragen, Governance). Das ist für viele moderne KI-nahe Datenarchitekturen eine geeignete Basis.
Für DACH-Unternehmen relevant: Snowflake und Databricks bieten EU-Regionen und Residency-Optionen; konkrete Compliance-, Governance- und Vertragsanforderungen müssen dennoch im Einzelfall geprüft werden.
Schicht 2: ELT-Transformation (dbt + Airbyte) Airbyte bietet eine breite Connector-Landschaft für die Ingestion von Rohdaten ins Lakehouse. dbt (data build tool) transformiert die Rohdaten on-demand im Warehouse — mit versionierten SQL-Modellen, Lineage-Tracking und automatisierten Tests. Transformation-Logik liegt als Code im Git-Repository, nicht als undurchschaubare ETL-Prozesse.
Schicht 3: Vektor- und Semantic Layer KI-Agenten brauchen semantischen Zugriff — nicht nur "gib mir Zeilen aus Tabelle X", sondern "finde Dokumente ähnlich zu Y" und "was bedeutet dieses Konzept in unserem Datenschema?" Vektordatenbanken (Pinecone, Weaviate, pgvector in PostgreSQL) ermöglichen Similarity-Search. Semantische Layer (Cube.dev, dbt Semantic Layer) machen Business-Metriken KI-zugänglich ohne SQL-Kenntnisse.
Schicht 4: Graph Layer (optional) Graph-Datenbanken (Neo4j, Grafeo, Amazon Neptune) können besonders sinnvoll sein, wenn Beziehungen, Abhängigkeiten und Wissensstrukturen zentral sind — etwa für Fragen wie "welche Kunden kennen denselben Kontakt?" oder "wie hängen diese Prozesse zusammen?". Der Grafeo-HN-Post zeigt: das Interesse an Graph-Datenbanken für Knowledge-Representation wächst.
Echtzeit vs. Batch: Wann brauche ich was?
Nicht jede Datenquelle braucht Echtzeit-Ingestion. Ein pragmatisches Framework:
Echtzeit-Streaming (CDC, Kafka, Event Streams):
- Kundenstatus-Updates (Kauf, Kündigung, Beschwerden)
- Transaktionsdaten in Finanzanwendungen
- IoT/Sensor-Daten für operative KI-Anwendungen
- Jeder Datenpunkt, bei dem "gestrige Daten" falsche Agenten-Entscheidungen produzieren
Batch (stündlich bis täglich):
- Historische Analysen und Reportings
- Daten aus Legacy-Systemen ohne CDC-Unterstützung
- Referenzdaten (Produktkataloge, Preislisten), die sich selten ändern
- Aufbereitete ML-Feature-Tables für Scoring
Datenqualität in einer ELT-Welt
Der größte Einwand gegen ELT: "Wenn die Rohdaten direkt geladen werden — wer kümmert sich um die Qualität?"
Kurze Antwort: dbt Tests und Data Contracts.
dbt Tests: Jedes Transformationsmodell kann mit eingebetteten Tests ausgestattet werden: Ist dieses Feld nicht-null? Sind die Werte in einem definierten Bereich? Gibt es keine Duplikate? Diese Tests laufen nach jeder Transformation und flaggen Qualitätsprobleme sofort.
Data Contracts: Explizite Vereinbarungen zwischen Datenproduktionsteams ("wir liefern dieses Schema in dieser Qualität") und Konsumenten. Das verlagert Qualitätssicherung an die Quelle — wo sie hingehört.
Schema Evolution: Was passiert, wenn ein Quellsystem ein Feld umbenennt? In ELT mit versionierten dbt-Modellen ist Schema Evolution handhabbar — breaking changes werden im Git-History sichtbar, nicht in einer versteckten ETL-Konfiguration.
Tool-Landschaft für DACH
Was österreichische und DACH-Unternehmen in der Praxis einsetzen:
Transformation: dbt (open source oder dbt Cloud, EU-Hosting verfügbar) ist für viele moderne SQL-Transformations-Stacks ein weit verbreitetes Standardwerkzeug.
Ingestion: Airbyte (open source, self-hosted oder Cloud mit Data-Residency-Optionen) mit breiter Connector-Landschaft. Fivetran als alternative managed Option.
Storage: Snowflake (EU Business Critical für DSGVO-sensitive Deployments), Databricks on Azure Frankfurt, BigQuery EU.
Orchestrierung und Scheduling: Apache Airflow (self-hosted), Prefect, Dagster — für die Orchestrierung und das Dependency-Management von Datenpipelines.
MuleSoft im Enterprise-Kontext: MuleSoft Anypoint Platform ist im Enterprise-Kontext weiterhin eine starke Option für SAP-, Salesforce- und Legacy-Anbindungen. MuleSoft + ELT sind komplementär: MuleSoft orchestriert API-basierte Integration und Real-Time-Events; dbt/Airbyte übernimmt analytische Transformationen.
Migrationspfad: Von Legacy-ETL zu modernem ELT
Kein DACH-Unternehmen wirft sein bestehendes ETL von heute auf morgen weg. Ein pragmatischer Phasenplan:
Phase 1: Parallel-Betrieb (3–6 Monate) Neues ELT für neue Use Cases und neue Datenquellen aufbauen. Legacy ETL läuft weiter für bestehende Reports und Prozesse. Kein riskanter Big-Bang-Wechsel.
Phase 2: Schrittweise Migration (6–18 Monate) ETL-Pipeline für ETL-Pipeline in dbt-Modelle migrieren, von den am wenigsten kritischen anfangend. Jede migrierte Pipeline wird mit Tests abgesichert, bevor die Legacy-Pipeline abgeschaltet wird.
Phase 3: Agentic Layer aufbauen (parallel) Während die Migration läuft, Vektor-Layer und Semantic Layer für KI-Agenten aufbauen. Erste Agenten können schon auf die neuen ELT-Daten zugreifen, während noch nicht alle Legacy-Pipelines migriert sind.
Das Ai11-Datenintegrations-Framework
Wir begleiten DACH-Unternehmen auf diesem Weg — von der Ausgangssituation-Bewertung bis zur produktiven agentic Datenarchitektur. Kein theoretisches Framework, sondern praxiserprobter Ansatz aus echten Implementierungsprojekten.
Mehr zu unserem Datenintegrations-Service
Auch relevant: KI-Agenten, die auf einer sauberen Datenarchitektur aufbauen — denn ein Agent ist nur so gut wie die Daten, auf die er zugreift.
Arbeitet Ihr Daten-Stack noch stark ETL-zentriert? Lassen Sie uns das gemeinsam bewerten.