Wer heute über Agentic AI spricht, legt den Fokus auf die verfügbaren Modelle. Welches ist leistungsfähig genug? Welches lässt sich am besten in bestehende Prozesse einbetten? Welches liefert die überzeugendsten Ergebnisse?
Das sind alles legitime Fragen, aber sie sollten nicht die ersten sein, die sich Entscheider und Entscheiderinnen stellen. Dass Agentic-AI-Projekte in der Praxis scheitern, liegt selten am Modell. Die eigentliche Ursache ist in den meisten Fällen eine Datenbasis, die fragmentiert, inkonsistent und widersprüchlich ist. Auf einem solch fragilen Fundament kann auch der leistungsfähigste Agent keine belastbare Entscheidung treffen. Wer das übersieht und zuerst das Modell auswählt, statt die Architektur zu klären, riskiert, dass der Agent zuverlässig und wiederkehrend auf Basis falscher Grundlagen handelt.
Agenten haben höhere Anforderungen als klassische KI
Generative KI ist so ausgelegt, dass Menschen das generierte Ergebnis sichten, bewerten und dann entscheiden. Der Effizienzgewinn von Agentic AI liegt genau darin, dass sie diesen Schritt überspringen, Entscheidungen autonom treffen und Aktionen direkt in den Systemen auslösen. So zum Beispiel das Schreiben von Tickets, das Ändern von Beständen oder das Anstoßen von Lieferkettenaktionen.
Diese Handlungsfähigkeit verändert die Anforderungen an die Datenarchitektur. Bei einem Sprachmodell, das Texte zusammenfasst, ist ein veralteter Datenstand ärgerlich. Ein Agent, der auf Basis veralteter oder inkonsistenter Daten einen Auftrag freigibt oder eine Disposition auslöst, wird zum teuren Risiko.
Drei Muster, die KI-Agenten in der Praxis ausbremsen
Aus der Arbeit mit Unternehmen in der Logistik, der Industrie und ERP-nahen Umfeldern kristallisieren sich für mich drei problematische Muster heraus.
1) Datenkopien als Standardantwort auf neue Anforderungen
In historisch gewachsenen IT-Landschaften existieren häufig bereits zahlreiche Datenhaltungen und Kopien; etwa in Fachanwendungen, Integrationsschichten, Data Warehouses oder Data Lakes. Sie sind meist über Jahre entstanden, weil unterschiedliche Systeme, Teams und Anforderungen jeweils eigene Datenstrukturen, Qualitätsregeln und Verantwortlichkeiten etabliert haben. Bei einem neuen Use Case kommt häufig eine weitere Datenhaltung hinzu. Operative Daten werden identifiziert, extrahiert und für die Anwendung aufbereitet. Dadurch werden bestehende Kopien und Datenpfade nicht unbedingt ersetzt, sondern um eine zusätzliche Ableitung ergänzt. Auch diese Kopie braucht Pflege, Monitoring und eigene Zugriffsregeln.
Bei einer klassischen Analyse ist das bereits ein großer Kostenfaktor. Für KI-Agenten kommt ein größeres Risiko dazu, denn wenn mehrere Datenhaltungen existieren, stellt sich die Frage, welche davon maßgebend ist. Handelt ein Agent auf Basis einer veralteten Kopie, die nicht mehr aktuell ist, trifft er Fehlentscheidungen, automatisiert und wiederholt. Das lässt sich nur schwer wieder korrigieren.
Sinnvoller ist es, gar nicht erst so viele Kopien entstehen zu lassen. Agenten sollten auf eine eindeutige operative Datenbasis zugreifen, die alle relevanten Systeme speist und von ihnen gespeist wird.
2) Technische Integration ohne semantische Eindeutigkeit
Gewachsene IT-Landschaften gelten intern oft als „integriert", weil Daten technisch zwischen Systemen fließen. Für KI-Agenten ist das jedoch nicht ausreichend.
Eine API schafft eine Verbindung, aber keine fachliche Eindeutigkeit. Ein Bestand, der im Lagersystem als verfügbar gilt, kann an anderer Stelle noch gesperrt sein. Das mag technisch korrekt sein, ist aber fachlich widersprüchlich. Menschen gleichen solche Unschärfen durch Erfahrung und Kontextwissen aus. Ein Agent kann das nicht leisten, weil ihm der Kontext fehlt, den Menschen üblicherweise durch Erfahrung aufbauen.
Entscheidend ist deshalb, dass die beteiligten Systeme dieselbe operative Realität abbilden: gemeinsame Semantik, konsistente Zustände, nachvollziehbare Datenflüsse. Interoperabilität ist mehr als Datenaustausch.
3) Fehlende Nachvollziehbarkeit im Betrieb
Wenn ein Agent in einen Prozess eingreift, muss sich im Nachhinein erklären lassen, auf welcher Datenbasis entschieden wurde, welche Regeln galten und welche Transformationen zwischen Quelle und Aktion lagen.
In gewachsenen Architekturen ist diese Rückverfolgung schwieriger als erwartet, wenn Daten mehrere Systeme, Pipelines und Zwischenhaltungen durchlaufen. So wird schnell unklar, auf welchen Datenstand sich eine Entscheidung tatsächlich bezogen hat. Debugging wird zur Schnitzeljagd über Systeme, Teams und Zeitfenster hinweg.
Was eine belastbare Datenarchitektur für Agentic AI leisten muss
Die Anforderungen lassen sich auf drei wesentliche Eigenschaften verdichten:
Aktualität: Agenten handeln auf Basis von Zuständen. Wenn diese Zustände nur in Intervallen synchronisiert werden, verlagert sich die Verantwortung für die Aktualität in den Anwendungscode. Mit allen Risiken, die das mit sich bringt.
Ein Praxisbeispiel: Ein Agent löst eine Bestellung aus, weil der Lagerbestand 5 Einheiten zeigt. Diese wurden jedoch zwei Minuten zuvor von einem anderen System reserviert. Die Datenbank synchronisiert sich aber nur alle 15 Minuten.
Konsistenz: Wenn mehrere Systeme dieselbe Entität – also Aufträge, Bestände oder Kunden – unterschiedlich abbilden, trifft der Agent Entscheidungen auf Basis widersprüchlicher Grundlagen. Es ist nicht die Schuld des Modells, dass die Architektur nicht optimal auf ihn ausgelegt ist.
Ein Praxisbeispiel: Ein Agent prüft, ob ein Kundenauftrag freigegeben werden kann. Das ERP-System meldet den Status ‘freigegeben’. Das Lagerverwaltungssystem zeigt denselben Auftrag aber noch als ‘in Prüfung’ an. Der Agent handelt auf Basis des ERP-Stands und löst die Lieferung aus, dabei war die Qualitätsprüfung noch nicht abgeschlossen.
Nachvollziehbarkeit: Agenten müssen erklären können, warum sie gehandelt haben. Das setzt voraus, dass Kontext-Snapshots reproduzierbar festhalten, welche Datenbasis, welche Regeln und welche Berechtigungen eine Aktion ausgelöst haben. Ohne durchgängige Korrelation wird die Nachvollziehbarkeit und das Debugging zur mühsamen Suche.
Ein Praxisbeispiel: Ein Agent storniert automatisch eine Lieferung. Warum genau, lässt sich im Nachhinein nicht mehr eindeutig rekonstruieren, denn die Daten – auf deren Basis er das entschieden hat – sind in der Zwischenzeit in einer Pipeline überschrieben worden. Letztendlich kann das Unternehmen dem Kunden und dem Team nicht mehr erklären, was passiert ist und wie sich das vermeiden lässt.
Daten-Nähe statt Datenbewegung
Das Architekturprinzip, das diese Anforderungen adressiert, lässt sich auf einen Kern bringen: Data Centric Compute. Statt Daten für jeden neuen Anwendungsfall in neue Systeme zu verschieben und weitere Kopien zu erzeugen, wird die Verarbeitung möglichst nah an den relevanten Daten ausgeführt.
Das bedeutet jedoch nicht, sämtliche Unternehmensdaten physisch in einer zentralen Datenbank zusammenzuführen. Entscheidend ist vielmehr, sie über eine gemeinsame Datenebene konsistent, aktuell und kontrolliert zugänglich zu machen. Die Daten können dabei durchaus in unterschiedlichen operativen Systemen verbleiben. Für KI-Agenten entsteht so ein einheitlicher Datenkontext, ohne dass für jeden Agenten eine neue Datenpipeline und ein weiteres Datensilo aufgebaut werden muss.
Dort wo KI-Agenten operative Entscheidungen treffen und Aktionen auslösen, müssen die relevanten Zustände zeitlich aktuell, semantisch belastbar und berechtigungstechnisch kontrollierbar verfügbar sein. Architekturen, die Datenbewegung als Standardlösung etablieren, stoßen unter diesen Anforderungen an Grenzen. Zukunftsfähig sind Plattformarchitekturen, die Übergänge reduzieren, Nachvollziehbarkeit erhöhen und Betrieb vereinfachen – kurz: die zum belastbaren Digital Backbone des Unternehmens werden.
Die Fragen, die vor der ersten Agenten-Entscheidung beantwortet sein sollten
Bevor Agentic AI in produktive Prozesse eingeführt wird, lohnt es sich, drei Fragen ehrlich zu beantworten:
1) Gibt es eine gemeinsame operative Realität?
Bilden die beteiligten Systeme dieselben Zustände, Begriffe und Prozessschritte einheitlich ab oder existieren parallele Wahrheiten, die manuell abgeglichen werden?
2) Wie viele Datenkopien entstehen pro Use Case?
Jede Kopie ist ein neues Produkt, das betrieben, überwacht und bei Änderungen angepasst werden muss. Architekturen, die Datennähe ermöglichen, reduzieren diesen Aufwand strukturell.
3) Halten die Entscheidungen einem Audit stand?
Agenten müssen erklären können, warum sie gehandelt haben. Das setzt voraus, dass Kontext-Snapshots reproduzierbar sind und Berechtigungen nicht nur dokumentiert, sondern technisch durchgesetzt sind.
Wer die Hausaufgaben macht, gewinnt Kontrolle
Wer die Datenbasis klärt, bevor er den ersten Agenten startet, verwandelt einen ambitionierten Piloten in eine nachvollziehbare operative Anwendung. Wer diese Vorarbeit überspringt, riskiert, dass der Agent zuverlässig auf Basis falscher Grundlagen handelt: schnell, automatisiert und schwer korrigierbar.
