Ihr KI-Agent ist nur so schnell wie Ihre langsamste Datenpipeline.
Das ist keine Metapher. Es ist die operative Einschränkung, an der viele erste KI-Agent-Deployments in DACH-Unternehmen scheitern. Teams bauen einen beeindruckenden Agenten — und stellen fest, dass er Entscheidungen auf Basis von Daten trifft, die 18 Stunden alt sind. Weil das Datawarehouse nightly befüllt wird.
Der Nvidia GTC 2026 hat diesen Punkt explizit gemacht: Agentic AI erfordert Real-Time-Daten-Zugriff auf Enterprise-Niveau — eine Anforderung, die traditionelles Batch ETL und Data Warehousing schlicht nicht erfüllen kann.
Das ist die zentrale Botschaft dieses Artikels: Nicht „was ist falsch mit Ihren Agenten" — sondern „was Ihre Datenarchitektur tun muss, damit Agenten funktionieren."
Das Problem mit Batch ETL in einer agentischen Welt
Batch ETL (Extract, Transform, Load) hat über Jahrzehnte solide gute Arbeit geleistet. Daten aus Quellsystemen werden in regelmäßigen Intervallen extrahiert, transformiert, und in ein Datawarehouse geladen. Analysten können dann Reports erstellen, die (mit einer Verzögerung von Stunden bis zu einem Tag) den aktuellen Zustand des Unternehmens zeigen.
Für KI-Agenten, die in Echtzeit handeln müssen, ist diese Architektur fundamental inkompatibel:
Latenz tötet Agentic Usefulness Ein Vertriebsagent, der einem Kunden eine Produktempfehlung gibt, sollte wissen, was dieser Kunde gestern bestellt hat — nicht vor drei Wochen. Ein Bestandsagent sollte wissen, wie viel Lager gerade verfügbar ist — nicht wie viel gestern Abend war. Ein Fraud-Detection-Agent muss Transaktionen in Echtzeit prüfen — nicht auf Basis von gestern.
Batch-Systeme können keine Ad-Hoc-Abfragen von Agenten bedienen Agenten machen unvorhersehbare, kombinierte Abfragen: „Welche Kunden in Wien haben in den letzten 30 Tagen mehr als €500 ausgegeben und haben noch kein Follow-up von unserem Vertriebsteam erhalten?" Ein nightly ETL, das für vordefinierte Reports optimiert ist, ist für diese Queries typischerweise zu langsam oder nicht flexibel genug.
Agents brauchen State-Awareness über Zeit Viele agentic Workflows sind mehrstufig und dauern Minuten bis Stunden. Ein Bestellprozess-Agent startet, wenn eine Bestellung eingeht, und muss beim nächsten Schritt (Lager-Prüfung, Zahlungsverifizierung, Versand-Initiierung) jeweils den aktuellsten Datenzustand haben. Batch-Systeme bieten diesen Realtime-State nicht.
Die drei Datenintegrations-Paradigmen — und wo jedes für Agenten versagt
Paradigma 1: Batch ETL (nightly jobs)
Wie es funktioniert: Daten werden in vordefinierten Zeitintervallen (stündlich, täglich, wöchentlich) aus Quellsystemen extrahiert, transformiert, und in ein Target-System geladen.
Wo es für Agenten versagt:
- Latenz: Bis zu 24h veraltete Daten
- Skalierung: Kann keine hohe Frequenz von Ad-hoc-Abfragen bedienen
- Fehlende Eventualität: Keine Möglichkeit, auf Ereignisse in Echtzeit zu reagieren
Wann es trotzdem passt: Für Agenten, die analytische Tasks ausführen (Wochenbericht erstellen, monatliche Trends analysieren), ist Batch-Daten ausreichend. Das Paradigma sollte nicht eliminiert werden — aber es ist nicht die Basis für agentic Workflows.
Paradigma 2: ELT mit Datawarehouses (Snowflake, BigQuery)
Wie es funktioniert: Daten werden zuerst geladen, dann transformiert (Extract, Load, Transform statt ETL). Moderne Cloud-Datawarehouses wie Snowflake oder BigQuery bieten schnelle Abfragen auf großen Datensätzen.
Wo es für Agenten versagt:
- Latenz: Immer noch typischerweise Minuten bis Stunden hinter dem operativen System
- Kostenskalierung bei hohen Agent-Query-Volumen: Snowflake und BigQuery sind bei vielen, kleinen Queries teuer
- Nicht für Write-Back optimiert: Agenten wollen nicht nur lesen, sondern auch zurückschreiben
Wann es passt: Für analytische Agenten (Business Intelligence, Reporting) und für Use Cases, bei denen leichte Daten-Verzögerung akzeptabel ist.
Paradigma 3: Real-Time Streaming (Kafka, Flink, event-driven)
Wie es funktioniert: Ereignisse werden sofort nach dem Auftreten in einem Stream publiziert. Andere Systeme abonnieren diesen Stream und verarbeiten Ereignisse, sobald sie eintreffen. Apache Kafka ist der Standard für enterprise Event Streaming.
Vorteile für Agenten:
- Millisekunden-Latenz: Ereignisse sind sofort verfügbar
- Event-driven: Agenten können auf spezifische Ereignisse reagieren (neue Bestellung, Zahlung eingegangen, Lagerbestand unter Schwellenwert)
- Skalierung: Kafka kann Millionen von Ereignissen pro Sekunde verarbeiten
Wo es Herausforderungen hat:
- Komplexität: Kafka-Setup und Betrieb erfordern spezialisiertes Know-how
- Kosten: On-premise Kafka-Infrastruktur ist aufwändig; Cloud-Managed-Services (Confluent Cloud, AWS MSK) erheblich einfacher
Was Agentic AI wirklich von Daten-Infrastruktur braucht
Aus der Analyse der drei Paradigmen ergibt sich eine klare Anforderungsliste für agent-ready Daten-Infrastruktur:
1. Echtzeit-Datenzugriff (< 1 Sekunde Latenz für operative Daten) Agenten, die operative Entscheidungen treffen, brauchen operative Daten — nicht analytische Kopien davon.
2. Bidirektionale Fähigkeit Agenten lesen nicht nur Daten — sie schreiben Ergebnisse zurück, aktualisieren Status, protokollieren Aktionen. Die Daten-Infrastruktur muss Write-Back effizient unterstützen.
3. Event-Trigger Agenten sollen auf Ereignisse reagieren, nicht nur abgefragt werden. Event-driven Infrastruktur ermöglicht: „Wenn X passiert, aktiviere Agent Y."
4. Schema-Flexibilität Agenten greifen auf unvorhersehbare Kombinationen von Datenquellen zu. Starre Daten-Schemas bremsen Agenten; flexible, gut dokumentierte APIs ermöglichen ihnen, dynamisch zu agieren.
5. Kontext-Persistenz Multi-Step-Agent-Workflows brauchen Zugriff auf den Kontext vorheriger Schritte. Vector Stores, Redis-Caches, oder Workflow-State-Systeme (Temporal) lösen das Problem.
Event-Driven Architecture als Fundament für KI-Agenten
Die eleganteste Lösung für alle genannten Anforderungen ist eine event-driven Architektur — und sie ist der Standard-Empfehlungen für alle neuen Enterprise-Architekturen, die Agenten-Fähigkeit berücksichtigen müssen.
Das Grundprinzip: Jede signifikante Änderung im System wird als Ereignis publiziert. „Neue Bestellung eingegangen" ist ein Event. „Lagerbestand unter 100 Einheiten" ist ein Event. „Kundenstatus auf Premium geändert" ist ein Event.
Agenten abonnieren die Events, die für ihre Aufgabe relevant sind — und werden aktiviert, wenn diese Events eintreten. Sie arbeiten auf aktuellsten Daten, weil sie direkt auf Ereignisse reagieren.
Für DACH-Unternehmen, die Kafka-Komplexität vermeiden wollen: Kafka Managed Services (Confluent Cloud auf AWS/Azure) oder Azure Event Hub (für Microsoft-Stacks) bieten Event-Streaming ohne die operativen Aufwände von On-Premise-Kafka.
Praktische Upgrade-Pfade für DACH-Unternehmen (Brownfield)
Die meisten DACH-Unternehmen starten nicht auf der grünen Wiese — sie haben bestehende ETL-Pipelines, bestehende Datawarehouses, und müssen einen pragmatischen Migrationspfad finden.
Stufe 1: Change Data Capture (CDC) als erster Schritt CDC-Tools (Debezium ist der Open-Source-Standard) zapfen direkt die Datenbank-Transaktions-Logs an und publizieren jede Änderung als Event — ohne die bestehenden Applikationen zu ändern. Das ist der schnellste Weg, Echtzeit-Events aus bestehenden Systemen zu bekommen.
Stufe 2: Hybrid-Architektur aufbauen Bestehendes Data Warehouse wird nicht ersetzt — es bleibt für analytische Queries zuständig. Daneben entsteht eine Event-Streaming-Schicht für operative Agent-Use-Cases. Die zwei Schichten koexistieren.
Stufe 3: Schrittweise Migration Use Case by Use Case werden operative Workflows auf Event-Driven migriert. Das Datawarehouse bleibt für analytische Zwecke; Event-Streaming wird zur Basis für Agenten.
Tools-Vergleich: MuleSoft vs. Azure Data Factory vs. Airbyte vs. Fivetran
Für DACH-Unternehmen, die konkrete Tool-Entscheidungen treffen müssen:
MuleSoft Anypoint Platform Stärke: Integration mit Salesforce-Ecosystem, Governance, breite Konnektor-Bibliothek Schwäche: Teuer, komplex, nicht primär für Event-Streaming ausgelegt Für Agenten: Machbar, aber nicht optimal ohne zusätzliche Event-Layer
Azure Data Factory + Event Hub Stärke: Native Microsoft-Integration, Event Hub für echtes Streaming Schwäche: Tief in Azure gebunden, wenig sinnvoll außerhalb des Microsoft-Stacks Für Agenten: Sehr gut für Microsoft-Stacks
Airbyte (Open Source ELT) Stärke: Open Source, günstig, breite Konnektor-Bibliothek für analytische Use Cases Schwäche: Primär für Batch-Replication, nicht für Real-Time Streaming Für Agenten: Nur für analytische Agenten geeignet
Fivetran Stärke: Zero-Maintenance Data Pipelines, enterprise-ready Schwäche: Teuer bei hohem Volumen, ebenfalls primär Batch/Near-Real-Time Für Agenten: Wie Airbyte — gut für analytische, nicht für operative Agenten
Apache Kafka (Managed) Stärke: De facto Standard für Enterprise Event Streaming, massive Skalierung Schwäche: Operativer Aufwand (auch managed), Lernkurve Für Agenten: Beste Wahl für operative, Event-driven Agenten
Datenschutz und Governance: Wenn Agenten Daten konsumieren
Wenn KI-Agenten Datenpipelines direkt anzapfen, entstehen neue Governance-Fragen:
Wer ist für Daten verantwortlich, die ein Agent verarbeitet? Klar: Das Unternehmen. Agenten sind Tools — die organisatorische Verantwortung liegt beim Unternehmen.
Was wenn ein Agent personenbezogene Daten verarbeitet? DSGVO gilt uneingeschränkt. Verarbeitungsverzeichnis muss agentic Workflows erfassen. Bei automatisierten Entscheidungen: Art. 22 DSGVO beachten.
Audit-Trail für Datenzugriff Welche Daten hat welcher Agent wann abgefragt? Das muss protokollierbar sein — sowohl für Compliance als auch für Debugging.
Brauchen Sie Unterstützung beim Aufbau einer agent-ready Datenarchitektur? Sprechen Sie mit uns.
FAQ: Welche Datenintegrationsstrategie passt zu KI-Agenten?
Warum funktioniert mein nightly ETL nicht für KI-Agenten? Weil Agenten operative Daten in Echtzeit brauchen, um nützliche Entscheidungen zu treffen. Daten mit 12-24h Verzögerung machen agentic Workflows unzuverlässig oder wertlos.
Was ist der günstigste Einstieg in Event-driven für KI-Agenten? Change Data Capture (CDC) mit Debezium auf bestehenden Datenbanken — das gibt Ihnen sofort Event-Streams ohne Applikations-Änderungen. Gepaart mit einem managed Kafka-Service (Confluent Cloud Basic) sehr kosteneffizient.
Muss ich mein Datawarehouse ersetzen? Nein. Batch-orientierte Datawarehouses bleiben für analytische Use Cases sinnvoll. Sie brauchen eine Event-Streaming-Schicht ergänzend dazu für operative Agent-Use-Cases.
Wie teuer ist eine agent-ready Dateninfrastruktur? Stark vom Umfang abhängig. Ein erster Event-Streaming-Layer für 2-3 Quellsysteme ist als Managed Service für ca. €500-2.000/Monat machbar. Eine vollständige Enterprise-Event-Architektur: €5.000-20.000/Monat (Cloud) oder €100k-500k+ für On-Premise.
Weiterführende Lektüre: