Globaler Field CTO fordert Führungskräfte auf, sich vor KI auf Dateninfrastruktur zu konzentrieren

Kai Waehner ist Global Field CTO bei Confluent und hat große Unternehmen wie BMW und Siemens beraten. Sein Schwerpunkt liegt auf Dateninfrastruktur, Integrationsstrategie und der Einführung von KI.

Wir haben uns mit Kai getroffen, um zu verstehen, warum so viele KI-Initiativen in Unternehmen scheitern. Das hat er dazu gesagt.

Ein Mustererkennungs-Vorteil

Mein Name ist Kai Waehner. Ich war die letzten neun Jahre als Global Field CTO bei Confluent tätig und habe mit Hunderten von Unternehmen in Nordamerika, Europa und dem asiatisch-pazifischen Raum zusammengearbeitet. Ich habe Unternehmen wie BMW, Volkswagen, Lufthansa, Siemens, DISH Networks und Globe Telecom beraten. Ich arbeite mit Führungskräften an Technologie-Strategien, Markteinführungsstrategien, Anbieterauswahl, Unternehmensarchitektur und Content-Erstellung.

Die Rolle des Field CTO unterscheidet sich davon, nur eine einzelne Engineering-Organisation zu leiten. Ich arbeite gleichzeitig in Dutzenden von Kundenumgebungen und berate Architekten sowie Führungskräfte der obersten Ebene zu Dateninfrastruktur, Integrationsstrategie und der Einführung von KI. Diese Breite verschafft mir einen Vorteil in der Mustererkennung, den man aus der Innenperspektive eines einzigen Unternehmens kaum erhält.

Mein Hintergrund umfasst die gesamte Geschichte der Unternehmensdatenintegration: ETL, ESB, iPaaS und API-Management, dann neun Jahre mit Fokus auf Daten-Streaming mit Apache Kafka und Flink als Rückgrat für ereignisgesteuerte Architekturen – und zunehmend Prozessorchestrierung und KI über das gesamte Spektrum hinweg, von prädiktivem maschinellem Lernen bis hin zu generativer und agentenbasierter KI. Ich halte regelmäßig Briefings für Analysten bei Gartner und Forrester und veröffentliche meine eigenen Recherchen, in denen Anbieterlandschaften, Architekturansätze und reale Anwendungsfälle aus der Industrie behandelt werden. Außerdem habe ich ein Buch über Daten-Streaming veröffentlicht.

Die Gespräche, die ich mit Technologie-Führungskräften über den KI-Wandel führe, drehen sich primär nicht um Modelle. Es geht um die Infrastruktur darunter. Agenten-basierte KI-Systeme, die autonom innerhalb von Unternehmensabläufen handeln, brauchen drei Dinge, um zuverlässig zu funktionieren:

• Echtzeitdaten, damit sie auf der aktuellen Realität agieren
• Prozessintelligenz, um zu definieren, was sie dürfen
• Vertrauen, das in die Architektur eingebettet ist, nicht nur in das Modell

Auf diese Konvergenz konzentriert sich mein Denken.

Warum Architekturschichten für KI-Erfolg konvergieren müssen

Branchenübergreifend sehe ich immer wieder, dass Unternehmen massiv in drei separate Schichten investieren: ein Datenintegrations-Backbone, eine Prozessautomatisierungsebene und zunehmend eine KI-Initiative. Das Problem ist, dass diese drei fast nie so konzipiert sind, dass sie zusammenarbeiten. Datenintegration bewegt Daten, ist aber nicht mit Geschäftsentscheidungen verknüpft. Prozessautomatisierung erzwingt Abläufe, basiert aber oft auf veralteten Kontexten. KI-Agenten geben Empfehlungen oder handeln, aber es fehlt ihnen eine kontrollierte Begrenzung ihres Handlungsspielraums. Jede Schicht arbeitet isoliert. Die konvergierte Architektur fehlt.

Die von mir beobachteten Bereitstellungsmodelle unterscheiden sich erheblich. Manche Unternehmen betreiben vollständig verwaltete cloud-native Infrastruktur auf AWS, Azure oder GCP; bei großen, global agierenden Firmen kommt häufig noch eine eigenständige Bereitstellung in Festlandchina über Alibaba Cloud hinzu – getrennt aus rechtlichen, regulatorischen und datenschutztechnischen Gründen. Andere setzen auf hybride Architekturen mit lokalen Rechenzentren, die mit der Cloud verbunden sind, etwa aufgrund von Anforderungen an Datensouveränität oder schwer bewegbaren Altsystemen. Reglementierte Branchen wie Finanzdienstleister und Gesundheitswesen haben fast immer Multi-Region- oder Multi-Cloud-Anforderungen, nicht freiwillig, sondern aufgrund von Compliance-Vorgaben. Kunden in der Fertigungsindustrie verfügen oft über Edge-Deployments, bei denen Daten unmittelbar in der Nähe der Fertigung verarbeitet und anschließend zentral aggregiert werden.

In all diesen Umgebungen ist ereignisgesteuerte Architektur zur unternehmenskritischen Infrastruktur geworden. Apache Kafka hat sich als De-facto-Standard für Event-Broker durchgesetzt, da es echte Entkopplung zwischen Systemen, Echtzeitverarbeitung in beliebigem Maßstab und Integration über hybride oder Multi-Cloud-Strukturen hinweg ermöglicht. PayPal verarbeitet täglich über eine Billion Kafka-Nachrichten. New Relic nimmt Milliarden von Datenpunkten pro Minute auf. Das sind keine experimentellen Einsätze – sie sind das operative Rückgrat des jeweiligen Geschäfts.

Viele Unternehmen haben bereits die drei Bausteine für vertrauenswürdige, agentenbasierte KI. Was fehlt, ist das architektonische Commitment, sie miteinander zu verbinden.

Warum Datenbereitschaft vor KI-Bereitschaft kommt

Kais Gedanken

KI‑Bereitschaft ist Datenbereitschaft.

Was ich festgestellt habe: KI ist nicht der schwierige Teil. Die zugrundeliegende Dateninfrastruktur ist es.

Die meisten erfolgreichen oder gescheiterten KI-Initiativen in Unternehmen, die ich in den letzten neun Jahren gesehen habe, hingen weniger vom gewählten Modell ab, sondern vielmehr davon, ob es eine zuverlässige, gut gesteuerte und echtzeitfähige Basis gab, um das Modell mit aktuellen, genauen und vertrauenswürdigen Daten zu versorgen.

Ein gut abgestimmtes Modell, das veraltete oder inkonsistente Daten erhält, wird unzuverlässige Ergebnisse liefern. Ein agentisches KI-System ohne Prozessebene, die definiert, was es tun darf, wird irgendwann eine Aktion ausführen, die niemand erklären oder rückgängig machen kann. Das sind keine Modellprobleme. Es sind Infrastruktur- und Architekturprobleme. Und diese sind vollkommen vorhersehbar, noch bevor eine einzige Zeile KI-Code geschrieben wird.

Die praktische Konsequenz ist: KI-Bereitschaft ist Datenbereitschaft. Bevor ein Modell ausgewählt, ein KI-Anbieter gewählt oder ein Pilotprojekt gestartet wird, sollte ein CTO in der Lage sein, drei Fragen ehrlich zu beantworten.

1. Hat die Organisation zuverlässigen Zugriff auf Echtzeitdaten aus ihren operativen Systemen?
2. Gibt es geregelte Prozesse, die definieren, was ein KI-System autonom tun darf und was nicht?
3. Existiert ein Vertrauensrahmen auf Architekturebene, nicht nur im Modell selbst, der diese Grenzen im Echtbetrieb durchsetzen kann?

Wenn eine dieser drei Fragen mit Nein beantwortet wird, sollte die KI-Reise dort beginnen – und nicht beim Modell.

Warum KI in bestehende Geschäftsprozesse eingebettet werden muss

Die bedeutendste Veränderung, die ich vorangetrieben habe, ist der Wechsel von KI als eigenständige Initiative hin zur Einbettung in bestehende Geschäftsprozesse. Das ist massiv unterinvestiert und hat weitreichende Folgen. Tatsächlich würde ich sagen, dass die meisten CTOs nicht mehr neue KI-Systeme entwerfen sollten, sondern stattdessen gestalten müssen, wie KI in bestehende Workflows eingebunden wird, welche Grenzen die Prozessebene vorgibt und wie Governance und Nachvollziehbarkeit bereits vor dem Einsatz eines einzigen Modells eingebaut werden.

Bevor ich diesen Wechsel vollzogen habe, war das Muster fast immer gleich: Ein KI-Projekt startete losgelöst von den operativen Systemen. Das Modell überzeugte im Labor. Im Produktivbetrieb fehlte jedoch der zuverlässige Zugriff auf aktuelle Daten, eine klar definierte Handlungsgrenze sowie die Integration in die Freigabeworkflows, auf die sich das Unternehmen stützte. Eindrucksvolle Demo. Gescheiterte Einführung.

Die Veränderung, die ich jetzt konsequent vorantreibe, ist zweigeteilt.

• Erstens: Die bestehende ereignisgesteuerte Architektur als Fundament für die KI-Einführung betrachten – und nicht als ein abzulösendes Ziel. Die Systeme bleiben. Die Geschäftsprozesse bleiben. KI wird als Teil bestehender Workflows integriert, konsumiert Echtzeit-Events und handelt innerhalb der von der Prozessebene gesetzten Grenzen.
• Zweitens: KI-Schutzmechanismen aus dem Modell heraus in die Prozess-Orchestrierungsebene verlagern. Ein gut abgestimmtes Modell allein genügt nicht. Vertrauenswürdige KI im Produktivbetrieb bedeutet, dass die Workflowschicht Freigabeschranken, Eskalationswege und Prüfpfade für jede autonome Handlung des Agenten durchsetzt.

Alpian, die erste voll lizenzierte digitale Privatbank der Schweiz, ist ein herausragendes Beispiel dafür, wie das von Anfang an richtig gemacht wurde. Alpian baute die komplette Plattform ereignisgesteuert auf, wobei Apache Kafka als zentraler Nervenknotenpunkt fungiert und Microservices, Domänendatenprodukte sowie KI-Agenten verbindet. Als sie agentische KI und RAG in die Kundeninteraktions-Workflows einführten, war die Architektur längst bereit. Kafka-Events gaben den Agenten Echtzeitkontext. Die Prozessebene setzte Compliance-Kontrollen durch. Sie implementierten von Anfang an Feldverschlüsselung und Schemaregelwerke.

Das Ergebnis war eine regulierte Finanzinstitution mit autonomen KI-Agenten innerhalb gesteuerter, auditierbarer Workflows – exakt das Muster, das viele traditionelle Unternehmen nun nachträglich einzuführen versuchen.

Unternehmen, die dies richtig machen, begreifen die Einführung von KI als architektonische Disziplin – nicht als kurzfristiges Projekt.

Warum Datenbereitschaft über den Erfolg von KI-Einführungen entscheidet

Nach neun Jahren bei Confluent in Hunderten von Unternehmensumgebungen sind die KI-Ergebnisse, die ich erlebt habe, sehr unterschiedlich. Der Unterschied zwischen guten und schlechten Resultaten liegt fast immer an einer Sache: ob die Dateninfrastruktur vor der Einführung von KI bereit war.

Auf der positiven Seite sind die Zahlen gut konzipierter Implementierungen überzeugend. BMW verhindert pro Jahr über 500 Minuten ungeplante Produktionsausfälle in einem einzigen Werk. Alpian betreibt eine vollständig regulierte Digitalbank mit agentenbasierter KI in gesteuerten, prüfbaren Kundenprozessen. Das qualitative Muster erfolgreicher Implementierungen ist konsistent: schnellere Markteinführung, reduzierte Betriebskosten bei hochvolumigen, repetitiven Arbeitsabläufen und eine spürbar bessere Kundenerfahrung, wenn KI auf Echtzeit-Kontext statt veralteter Batch-Daten zugreifen kann.

Auf der negativen Seite ist das Scheitern ebenso konsistent. KI-Projekte ohne eine gesteuerte Datenbasis führen fast immer zum gleichen Resultat: beeindruckende Demos, gescheiterte Produktivsetzungen. Das Modell funktioniert im Labor. Im Produktivbetrieb erhält es veraltete oder inkonsistente Daten, halluziniert bei Spezialfällen, handelt ohne Prüfpfad und untergräbt so das Geschäft mit KI, anstatt Vertrauen zu schaffen. Forschungen des MIT schätzen, dass etwa 95 % der KI-Pilotprojekte in Unternehmen keinen messbaren Geschäftsnutzen bringen. Diese Zahl deckt sich mit meinen Beobachtungen in der Praxis.

Der jüngste Fehler, den ich beobachte, ist eine zu spät eingeführte Governance. Organisationen setzen agentenbasierte KI ein und stellen dann meist erst nach einem Vorfall fest, dass keine Prozessebene definiert, was der Agent tun darf, kein Eskalationsweg für unsichere Model-Ergebnisse existiert und keine Prüfkette zur Rekonstruktion von Ereignissen vorhanden ist. Das ist kein KI-Problem, sondern ein Architekturproblem. Und es ist vollständig vermeidbar.

Warum KI Entscheidungen informiert, aber Menschen für Verantwortung sorgen

Ich sehe immer wieder ein Muster: KI informiert und beschleunigt. Sie trifft autonome Entscheidungen innerhalb definierter Grenzen. Aber Menschen tragen die Verantwortung für die wichtigsten Entscheidungen.

Auf der durch KI informierten Seite stiften Forschungssynthese, Inhaltserstellung, Codegenerierung für klar umrissene Probleme, automatisiertes Testen und Sicherheitsscans eindeutigen Mehrwert. In meiner eigenen Arbeit verdichten KI-Tools mehrere Tage an Auswertung von Analystenberichten, Kundengesprächen und technischer Dokumentation. Das Ergebnis muss immer noch durch Experten geprüft werden, aber der Ausgangspunkt ist deutlich weiter vorn.

Auf der autonomen Entscheidungsseite sollten KI-Agenten eigenständig entscheiden, wenn das Risiko begrenzt und der Prozess gut gesteuert ist. Betrugserkennung in der Finanzbranche ist das klarste Beispiel. Unterhalb einer definierten Risikoschwelle blockiert ein KI-Agent eine Transaktion automatisch, ohne dass der Mensch eingreifen muss. Steigt die Transaktionssumme und damit die regulatorische Relevanz, leitet die Prozesssteuerung den Fall vor weiteren Schritten an einen menschlichen Analysten weiter. Diese Grenze ist nicht starr. Das Unternehmen definiert sie, der Arbeitsablauf kodiert sie und die Prozessebene setzt sie durch – nicht das Modell selbst.

Auf explizit menschlicher Seite ziehe ich die Grenze bei Entscheidungen mit großen architektonischen Folgen, strategischen Unternehmensrisiken oder erheblicher regulatorischer Verantwortung. Die Wahl eines grundlegenden Architekturpatterns, die Auswahl eines strategischen Technologieanbieters, das Design des Governance-Modells für ein agentenbasiertes KI-System: Das bleiben menschliche Entscheidungen. Schnelleres Vorgehen kann die Folgen von Fehlentscheidungen hier nicht wieder gutmachen.

Warum KI in drei zentralen Bereichen zu wenig leistet

In drei Bereichen hat KI die technischen oder ingenieurmäßigen Effekte nicht geliefert, die die Kundschaft anfangs erwartet hatte.

Der erste Bereich ist die Integration von Unternehmensdaten. KI versprach, die Anbindung heterogener Systeme erheblich zu vereinfachen: Schema-Abgleich, Sicherung der Datenqualität, Transformationslogik und Governance in komplexen hybriden Umgebungen. In der Praxis unterstützt KI diese Aufgaben, löst sie aber nicht. Ein Modell kann keine Altlasten aus der Architektur beseitigen, mit Altsystemen mit undokumentierten Datenmodellen, inkonsistenten Bedeutungen über verschiedene Geschäftsbereiche hinweg, fehlenden Metadaten und fragmentierter Verantwortung umgehen. Die eigentliche Arbeit bleibt beim Engineering-Team.

Der zweite Bereich ist agentenbasierte KI in komplexen, mehrstufigen Unternehmensabläufen. Die Demos sind überzeugend. Im Produktivbetrieb scheitern Agenten unvorhersehbar, wenn sie auf Sonderfälle stoßen, die vom Trainingsdatensatz nicht abgedeckt sind, wenn das Kontextfenster nicht genügend aktuellen Zustand enthält oder wenn die Prozessebene Agentenfehler nicht sauber auffängt und behandelt. Die Lücke zwischen dem, was ein Agent in einer kontrollierten Umgebung leisten kann, und dem, was wir ihm in einem regulierten Produktivworkflow autonom anvertrauen können, ist noch erheblich.

Der dritte Bereich ist die Architektur-Entscheidungsfindung. KI-Werkzeuge haben die Routine-Codierung, das Schreiben von Tests und die Dokumentation spürbar beschleunigt. Doch sie führen nicht verlässlich zu besseren Entscheidungen hinsichtlich grundlegender Architektur. Modelle spiegeln vergangene Muster wider. Unternehmensarchitektur erfordert aber Urteilsvermögen über künftige Restriktionen, regulatorische Entwicklungen und Technologiewetten, zu denen Modelle keinen belastbaren Beitrag leisten können. Teams, die zu sehr auf KI bei Architekturentscheidungen vertrauen, bauen oft Systeme, die lokal schlüssig, aber global fragil sind.

Das verbindende Muster in allen drei Bereichen ist: KI liefert dann, wenn das Problem klar umrissen ist, die Daten sauber und aktuell sind und ein Experte aus dem Fachbereich eingebunden ist. Sie bleibt unter den Erwartungen, wo das Problem kontextbasiertes Urteil, organisatorischen Wandel oder architektonisches Denken erfordert, das über das Erkennen von Mustern in historischen Daten hinausgeht.

Wie KI mit Sicherheit und Skalierbarkeit im Code kämpft

Die beständigste Herausforderung, die ich beobachte, liegt an der Schnittstelle zwischen KI-generiertem Code und ingenieurtechnischem Urteilsvermögen für produktionsreife Software.

KI-Codegenerierungstools sind tatsächlich nützlich für klar abgegrenzte, sich wiederholende Aufgaben: Boilerplate, Testfälle, Dokumentation und einfache Transformationen. Probleme entstehen, wenn Teams dieses Vertrauen auf Architekturentscheidungen, sicherheitskritischen Code oder für die Skalierbarkeit entscheidende Komponenten ausweiten – ohne sorgfältige menschliche Prüfung.

Auf der Sicherheitsseite schleichen sich durch KI-generierten Code häufig subtile Schwachstellen ein, die automatisierte Scans bestehen, aber unter Angriffsszenarien versagen. Prompt-Injektionen sind das derzeit klarste Beispiel in agentischen KI-Systemen. Ein Agent, der auf Basis von Benutzereingaben Code generiert oder ausführt – ohne saubere Validierung und Sandboxing der Eingaben – schafft Angriffsflächen, die leicht übersehen werden und im Nachhinein schwer zu erkennen sind. Dieses Muster habe ich in frühen, agentischen KI-Einführungen gesehen, bei denen Teams auf Fähigkeiten und Tempo fokussiert waren und die Sicherheitsüberprüfung als späteren Schritt betrachteten.

Auf der Skalierbarkeitsseite neigen KI-Tools dazu, Lösungen zu erzeugen, die im kleinen Rahmen funktionieren, aber versteckte Annahmen hinsichtlich Datenmenge, Nebenläufigkeit oder Latenz enthalten, die sich erst unter Produktionslast zeigen. Ein generierter Kafka-Consumer, der im Test problemlos läuft, kann bei zehntausend Events pro Sekunde unvorhersehbar scheitern, wenn der Code beispielsweise keine Rücksicht auf Partition-Rebalancing, Off-Set-Management oder Backpressure nimmt. Das Modell kennt Ihre Produktionsumgebung nicht. Es kennt Muster aus den Trainingsdaten.

Die praktische Lösung ist nicht, auf KI-basierte Codegenerierung zu verzichten, sondern KI-generierten Code so zu behandeln, wie Sie Code einer fähigen, jedoch unerfahrenen Entwicklerin oder eines Entwicklers behandeln würden, die oder der Ihr Produktionssystem noch nie gesehen hat. Prüfen Sie ihn. Testen Sie ihn unter realistischen Bedingungen. Und lassen Sie ihn nie in sicherheitskritische oder skalierbarkeitskritische Teile, ohne Freigabe einer erfahrenen Ingenieurin oder eines erfahrenen Ingenieurs.

Was Technologieführende jetzt tun müssen

Kais Gedanken

Investieren Sie in Ihre Datenbasis, bevor Sie sich KI-Zielen widmen…behandeln Sie KI-Governance als Architekturfrage, nicht als Richtlinienproblem…denken Sie in beide Richtungen gleichzeitig.

Hier sind drei Empfehlungen, in ihrer Reihenfolge der Wichtigkeit:

Erstens: Investieren Sie zuerst in Ihre Datenbasis, bevor Sie sich KI-Zielen widmen. Organisationen, die messbare KI-Erfolge vorweisen können, waren nicht unbedingt die Schnellsten bei einem neuen Modell. Sie hatten bereits saubere, aktuelle und gut verwaltete Datenströme im eigenen System, bevor die KI-Diskussion begann. Wenn Ihre Daten isoliert, veraltet oder unkontrolliert sind, beheben Sie das zuerst. Kein Modell kann schlechte Daten im großen Maßstab ausgleichen.

Zweitens: Behandeln Sie KI-Governance als Architekturfrage, nicht als reine Richtlinienfrage. Leitlinien für verantwortungsvollen KI-Einsatz zu schreiben ist nötig, aber nicht ausreichend. Die Prozessebene steuert tatsächlich das Verhalten von Agenten im Produktionsbetrieb: Workflow-Gates, Freigabeschwellen, Eskalationswege und Audit-Trails, die Grenzen durchsetzen – egal, was das Modell empfiehlt. Bauen Sie diese Regelungen direkt in die Architektur ein. Governance im Nachhinein einzubauen ist teuer, unzuverlässig und passiert meist erst, wenn bereits etwas schiefgelaufen ist.

Drittens: Denken Sie in beide Richtungen gleichzeitig. Der Druck, KI-Anwendungsfälle schnell umzusetzen, kommt von unten und ist real und nachvollziehbar. Genauso wichtig ist jedoch der strategische Architekturansatz von oben, der verhindert, dass isolierte Einzellösungen entstehen, die später mühsam entwirrt werden müssen. Die CTOs, die ich dabei als erfolgreich erlebe, können beides gleichzeitig: Sie realisieren spezifische Anwendungsfälle zügig und behalten dabei einen klaren architektonischen Nordstern bei, sodass diese Anwendungen langfristig zusammensetzbar und steuerbar bleiben.

Die Unternehmen, die auf diese Zeit als Wettbewerbsvorteil zurückblicken werden, sind nicht jene, die als erste KI eingeführt haben. Sie haben zunächst die notwendige Infrastruktur geschaffen, um KI vertrauenswürdig zu machen – und darauf aufbauend schnell Innovationen umgesetzt.

Bleiben Sie dran

Sie können Kai Waehners Arbeit auf seiner Website, im Blog und auf LinkedIn verfolgen.

Weitere Experteninterviews folgen im CTO Club!