Von Andrew Tan
Warum 85 % der Unternehmen nicht bereit für KI sind
Fivetrans Benchmark 2026 ergab, dass 85 % der Unternehmen agentische KI auf einer Infrastruktur betreiben, die nicht bereit ist. Das Modell ist nicht das Problem. Die Datenpipelines, die es speisen, sind es.
Hier ist ein Muster, das an immer mehr Orten auftaucht:
Ein Unternehmen verbringt sechs Monate damit, LLMs zu evaluieren: Sie führen Benchmarks durch, verhandeln Verträge, bauen einen Proof of Concept. Das Modell sieht großartig aus. Dann setzen sie es in der Produktion ein und die Agenten beginnen auf eine Weise zu halluzinieren, die nichts mit dem Modell zu tun hat.
Die KI ist in Ordnung, aber die Daten, die sie speisen, sind es nicht.
Das ist es, was Fivetrans Enterprise Data Infrastructure Benchmark Report 2026 tatsächlich misst, wenn er sagt, dass 85 % der Unternehmen nicht bereit für agentische KI sind. Nicht, dass ihre Modelle falsch sind, sondern dass ihre Pipelines falsch sind.
Was "nicht bereit" tatsächlich bedeutet
Der Ausdruck "KI-bereite Infrastruktur" wird verwendet, um viele Dinge zu verkaufen. Es bedeutet normalerweise etwas Vages über Cloud-Scalability. Das ist nicht das, was der Fivetran-Bericht misst.
Die drei konkreten Probleme, die sie identifiziert haben:
Veraltete Daten. Der Agent argumentiert über den Zustand von gestern. Für einen Kundenservice-Agenten bedeutet das, dass er nicht weiß, dass eine Rückerstattung bereits erfolgt ist. Für einen Betrugserkennungs-Agenten arbeitet er mit Mustern, die 18 Stunden alt sind. Batch-Pipelines, die stündlich oder nachts laufen, können Agenten nicht unterstützen, die auf das reagieren müssen, was jetzt passiert.
Keine Schema-Durchsetzung. Quellsysteme ändern sich ständig. Spalten werden umbenannt, Typen erweitert, neue Felder erscheinen. Wenn Ihre Pipeline keine Schema-Verträge downstream durchsetzt, kann ein Agent fehlerhafte Daten erhalten, die gültig aussehen — und selbstbewusst darauf reagieren.
Keine Beobachtbarkeit. Die meisten Pipeline-Überwachungen sagen Ihnen, ob ein Job ausgeführt wurde. Sie sagen Ihnen nicht, ob die Daten korrekt sind. Ein Agent kann Daten aus einer Pipeline konsumieren, die technisch läuft, aber stillschweigend 20 % der Ereignisse fallen lässt. Sie werden es erst wissen, wenn jemand bemerkt, dass der Agent sich seltsam verhält, und dann ist der Schaden bereits entstanden.
Dies sind keine neuen Probleme. Es sind die gleichen Datenqualitätsprobleme, die Analyseteams seit Jahren plagen. Was sich geändert hat, ist der Explosionsradius. Ein Datenqualitätsproblem in einem BI-Dashboard ist ein schlechtes Diagramm. Ein Datenqualitätsproblem in einem agentischen System ist eine autonome Entscheidung, die auf falschen Informationen basiert.
Das Stack-Mismatch
Das Problem des KI-bereiten Datenstacks ist ein tiefes Missverhältnis in den Architekturannahmen.
Die meisten Unternehmensdatenstacks wurden um Batch-Verarbeitung herum aufgebaut. Nächtliche ETL-Jobs. Tägliche Warehouse-Aktualisierungen. Dashboards, die jeden Morgen aktualisiert werden. Das gesamte System wurde für Durchsatz über Frische optimiert.
KI-Agenten haben andere Anforderungen. Sie benötigen Daten, die aktuell sind, nicht nur genau. Sie müssen auf das reagieren, was in den letzten Sekunden oder Minuten passiert, nicht in den letzten zwölf Stunden. Und wenn sie falsch liegen, müssen sie vom System aufgefangen werden — nicht nur protokolliert und weitergemacht.
Die Unternehmen, die bereit sind — die 15 % — haben nicht unbedingt ihren gesamten Stack ersetzt. Die meisten von ihnen haben dort auf Echtzeit umgestellt, wo es darauf ankommt, und Batch beibehalten, wo es sinnvoll ist. Der Kundenbestellstrom läuft in Echtzeit. Die vierteljährliche Kostenrechnung läuft weiterhin nachts. Der Unterschied ist die Absicht: Sie haben explizite Entscheidungen darüber getroffen, welche Daten Frische benötigen, und Pipelines entsprechend aufgebaut.
Die drei Eigenschaften, die tatsächlich wichtig sind
Es gibt viel Lärm darüber, was eine "KI-bereite" Infrastruktur erfordert. Normalerweise ist es eine Checkliste eines Anbieters, die bequem zu seinem Produkt passt. Hier ist die Version, die zu den tatsächlichen Ausfallmodi passt:
Frische. Nicht nur "Echtzeit für alles" — das ist teuer und oft unnötig. Aber für die Daten, auf die Ihre Agenten tatsächlich reagieren, müssen Sie die Verzögerung kennen und Garantien darüber haben. Wenn Ihre Kundendaten 4 Minuten alt sind, in Ordnung — solange Ihr Agent das weiß und darauf reagiert. Was Agenten bricht, ist, wenn sie annehmen, dass Daten aktuell sind und es nicht sind.
Konsistenz. Agenten kombinieren oft Daten aus mehreren Quellen, um eine Entscheidung zu treffen. Wenn diese Quellen auf unterschiedlichen Zeitplänen oder mit unterschiedlichen Frischegraden laufen, erhalten Sie subtile Inkonsistenzen, die schwer zu debuggen sind. Eine Kundenabfrage sagt, dass das Konto aktiv ist; der Transaktionsstrom hat nicht aufgeholt und zeigt es als schwebend geschlossen. Der Agent trifft eine Entscheidung, die für jede Quelle individuell korrekt ist, aber für den kombinierten Zustand falsch.
Beobachtbarkeit auf Ereignisebene. Pipeline-Überwachung informiert Sie über Jobs. Die Zuverlässigkeit von Agenten erfordert die Überwachung einzelner Ereignisse. Werden Ereignisse verarbeitet oder fallen gelassen? Entspricht das Schema dem, was der Agent erwartet? Gibt es Spitzen, die nachgelagerte Verbraucher überwältigen? Dies ist eine andere Klasse von Überwachung, als die meisten Teams aufgebaut haben.
Was das für die Entscheidung "bauen vs. kaufen" bedeutet
Die KI-Welle bringt eine Rechnung ans Licht, die sich in vielen Ingenieurorganisationen angesammelt hat: die Kosten für die Behandlung der Dateninfrastruktur als gelöstes Problem.
Teams, die vor zwei Jahren benutzerdefinierte Batch-Pipelines gebaut haben und es als erledigt betrachteten, stehen nun vor einer schwierigen Wahl: Echtzeit in ein System nachzurüsten, das nicht dafür ausgelegt war, oder neu zu bauen. Keine der Optionen ist billig. Nachrüsten führt tendenziell zum Zwei-Pipeline-Problem — ein Batch-System für die Historie, ein Streaming-System für Echtzeit, zwei Codebasen, die ungefähr dasselbe tun, aber mit leicht unterschiedlicher Logik und ständig divergierenden Ergebnissen.
Die Teams, die dies gut handhaben, sind diejenigen, die diese Wahl nicht treffen müssen. Wenn Batch und Streaming als dieselben Pipelines mit denselben Werkzeugen laufen, ist das Umschalten eines Workflows von stündlich auf Echtzeit eine Konfigurationsänderung, kein Neuschreiben. Die Beobachtbarkeit, die Schema-Durchsetzung, die Fehlerbehandlung — es kommt mit der Plattform, nicht als benutzerdefinierter Aufbau obendrauf.
Darum geht es bei layline.io. Nicht nur Echtzeit um ihrer selbst willen, sondern die Fähigkeit, explizite, absichtliche Entscheidungen über die Datenfrische im gesamten Stack zu treffen — ohne zwei separate Systeme zu pflegen, um dorthin zu gelangen.
Die Frage, mit der man sich auseinandersetzen sollte
Die Zahl von 85 % ist auffällig. Aber die interessantere Frage ist: Wie viele dieser Unternehmen wissen, dass sie zu diesen 85 % gehören?
Die Teams, die in Schwierigkeiten sind, sind normalerweise nicht die mit offensichtlich kaputten Pipelines. Es sind diejenigen mit Pipelines, die scheinbar funktionieren — Jobs laufen, Dashboards laden, keine aktiven Vorfälle — aber mit stillen Zuverlässigkeitsproblemen, die erst auftreten, wenn ein KI-Agent beginnt, auf den Daten folgenschwere Entscheidungen zu treffen.
Wenn Ihre Agenten sich seltsam verhalten und Sie das Modell bereits ausgeschlossen haben, schauen Sie sich die Daten an.
Andrew Tan ist ein Serienunternehmer und Gründer von layline.io, der Unternehmensdatenverarbeitungsinfrastruktur aufbaut, die sowohl Batch- als auch Echtzeit-Workloads im großen Maßstab bewältigt.
