Global Field CTO Urges Leaders to Focus on Data Infrastructure Before AI
Discover why enterprise AI projects fail without strong data infrastructure, and how leaders can build governed, real-time systems that support trustworthy AI adoption.
Kai Waehner
Global Field CTO at Confluent
Pattern-Recognition: Kai Waehner's experience spans globally, offering a unique pattern-recognition advantage in enterprise AI.
Infrastructure Focus: Enterprise AI success relies on converging architecture layers: data, process automation, and AI strategies.
Data Readiness: AI projects often succeed or fail based on data infrastructure, not the chosen model.
Embedded AI: Integrating AI into existing workflows enhances performance, governance, and audibility.
Security Concerns: AI-generated code may introduce vulnerabilities; rigorous review and testing are essential.
Kai Waehner is Global Field CTO at Confluent, and has advised large enterprises such as BMW and Siemens. His focus is on data infrastructure, integration strategy, and AI adoption.
We caught up with Kai to understand why so many Enterprise AI initiatives fail. Here's what he had to say.
A Pattern-Recognition Advantage
My name is Kai Waehner. I spent the last nine years as Global Field CTO at Confluent, working with hundreds of enterprises across North America, Europe, and Asia Pacific. I've advised companies like BMW, Volkswagen, Lufthansa, Siemens, DISH Networks, and Globe Telecom. I work with executives on technology strategy, go-to-market execution, vendor evaluation, enterprise architecture, and content creation.
Want more from The CTO Club?
Create a free account to finish this piece and join a community of CTOs and engineering leaders sharing real-world frameworks, tools, and insights for designing, deploying, and scaling AI-driven technology.
Have an account? Log In
The Field CTO role differs from running a single engineering org. I work across dozens of customer environments simultaneously, advising architects and C-suite leaders on data infrastructure, integration strategy, and AI adoption. That breadth gives me a pattern-recognition advantage that is hard to get from inside one company.
My background spans the full history of enterprise data integration: ETL, ESB, iPaaS, and API Management, then nine years focused on data streaming with Apache Kafka and Flink as the backbone for event-driven architectures, and increasingly, process orchestration and AI across the full spectrum from predictive machine learning to generative and agentic AI. I brief analysts at Gartner and Forrester regularly and publish my own research, covering vendor landscapes, architecture patterns, and real-world industry case studies. And I also published a book on data streaming.
The AI transformation conversation I have with technology leaders is not primarily about models. It is about the infrastructure underneath them. Agentic AI systems that take autonomous actions inside enterprise workflows need three things to work reliably:
- Real-time data so they act on current reality
- Process intelligence to define what they are allowed to do
- Trust built into the architecture, not just the model
My thinking focuses on that convergence.
Why Architecture Layers Must Converge for AI Success
Across industries, I consistently see enterprises invest heavily in three separate layers: a data integration backbone, a process automation layer, and increasingly, an AI initiative. The problem is that these three are almost never designed to work together. Data integration moves data but does not connect to business decisions. Process automation enforces workflows but runs on stale context. AI agents generate recommendations or take actions, but lack a governed boundary around what they can do. Each layer works in isolation. The converged architecture is missing.
The deployment models that I see vary significantly. Some organizations run fully managed cloud-native infrastructure across AWS, Azure, or GCP, and larger global enterprises often include mainland China deployments on Alibaba Cloud, kept deliberately separate for legal, regulatory, and data privacy reasons. Others operate hybrid architectures with on-premise data centers connected to the cloud, driven by data sovereignty requirements or legacy systems that they cannot move quickly. Regulated industries like financial services and healthcare almost always have multi-region or multi-cloud requirements, not by choice but by compliance mandate. Manufacturing customers frequently have edge deployments where they process data close to the factory floor before aggregating it centrally.
Across all these environments, event-driven architecture has become mission-critical infrastructure. Apache Kafka has emerged as the de facto standard event broker for true decoupling between systems, real-time processing at any scale, and hybrid and multi-cloud integration. PayPal processes over a trillion Kafka messages daily. New Relic ingests billions of data points per minute. These are not experimental deployments. They are the operational backbone of the business.
Many enterprises already have the three pieces they need for trusted agentic AI. They are missing the architectural commitment to make them converge.
Why Data Readiness Precedes AI Readiness
Here's what I've found: AI is not the hard part. The data infrastructure underneath it is.
Most enterprise AI initiatives I have seen succeed or fail in the past nine years depended less on the model chosen and more on whether the organization had a reliable, governed, real-time foundation to feed that model with current, accurate, and trustworthy data.
A well-aligned model receiving stale or inconsistent data will produce unreliable outputs. An agentic AI system with no process layer defining what it can do will eventually take an action nobody can explain or reverse. These are not model problems. They are infrastructure and architecture problems. And these are entirely predictable before writing a single line of AI code.
The practical implication is that AI readiness is data readiness. Before selecting a model, before choosing an AI vendor, before launching a pilot, a CTO should be able to answer three questions honestly.
- Does the organization have reliable access to real-time data from its operational systems?
- Are there governed processes that define what an AI system can and cannot do autonomously?
- Is there a trust framework in place at the architecture level, not just inside the model, that can enforce those boundaries in production?
If the answer to any of those three is no, the AI journey should start there, not with the model.
Why AI Must Be Embedded into Existing Business Processes
The most significant change I have driven is shifting from building AI as a separate initiative to embedding it into existing business processes. This is highly underinvested and consequential. In fact, I'd say most CTOs should be shifting from designing new AI systems to designing how AI participates in existing workflows, what boundaries that the process layer enforces, and how governance and auditability are built in — before deploying a single model.
Before I made this shift, the pattern was almost always the same. An AI project would start disconnected from operational systems. The model performed well in the lab. In production, it lacked reliable access to current data, a defined boundary for its actions, and integration into the approval workflows the business depended on. Impressive demo. Failed deployment.
The change I now consistently push for is twofold.
- First, treat the existing event-driven architecture as the foundation for AI adoption rather than a replacement target. The systems stay. The business processes stay. AI participates in already running workflows, consuming real-time events, and acting within boundaries the process layer defines.
- Second, move AI guardrails out of the model and into the process orchestration layer. A well-aligned model is not enough. Trustworthy AI in production means the workflow layer enforces approval gates, escalation paths, and audit trails for every autonomous action the agent takes.
Alpian, Switzerland's first fully licensed digital private bank, is a strong example of this done right from day one. Alpian built their entire platform event-driven, with Apache Kafka as the central nervous system connecting microservices, domain data products, and AI agents. When they introduced agentic AI and RAG into client interaction workflows, the architecture was already ready. Kafka events gave the agents real-time context. The process layer enforced compliance controls. They built in field-level encryption and schema governance from the start.
The result was a regulated financial institution running autonomous AI agents inside governed, auditable workflows, which is exactly the pattern most traditional enterprises are now trying to retrofit.
Organizations that get this right treat AI adoption as an architectural discipline, not a project sprint.
Organizations that get this right treat AI adoption as an architectural discipline, not a project sprint…The gap between good and bad outcomes almost always stems from whether the data infrastructure was ready before AI introduction.
Why Data Readiness Determines AI Deployment Success
After nine years at Confluent across hundreds of enterprise environments, the AI results I have seen are deeply uneven. The gap between good and bad outcomes almost always stems from one thing: whether the data infrastructure was ready before AI introduction.
On the positive side, numbers from well-architected deployments are compelling. BMW prevents over 500 minutes of unplanned production downtime per year at a single plant. Alpian runs a fully regulated digital bank with agentic AI embedded in governed, auditable client workflows. The qualitative pattern across successful deployments is consistent: faster time to market, reduced operational cost in high-volume repetitive workflows, and meaningfully better customer experience when AI accesses real-time context rather than stale batch data.
On the negative side, the failure pattern is equally consistent. AI projects without a governed data foundation almost always yield the same result: impressive demos, failed production deployments. The model works in the lab. In production, it receives stale or inconsistent data, hallucinates on edge cases, takes actions with no audit trail, and erodes rather than builds business confidence in AI. MIT research estimates that around 95% of enterprise AI pilots fail to deliver measurable business impact. This number matches my observations in the field.
The most recent failure mode I'm seeing is governance added too late. Organizations deploy agentic AI and then discover, usually after an incident, that no process layer defined what the agent could do, no escalation path for uncertain model outputs, and no audit trail to reconstruct events. That is not an AI problem. It is an architecture problem. And it is entirely preventable.
Why AI Informs Decisions But Humans Ensure Accountability
I consistently see a pattern: AI informs and accelerates. It makes autonomous decisions within defined boundaries. But humans own accountability for the decisions that matter most.
On the AI-informed side, research synthesis, content creation, code generation for well-scoped problems, automated testing, and security scanning add clear value. In my own work, AI tools compress days of synthesis across analyst reports, customer conversations, and technical documentation. The output still requires expert judgment to validate, but the starting point is much further along.
On the autonomous decision side, AI agents should decide independently when risk is bounded and the process is well-governed. Fraud detection in financial services is the clearest example. Below a defined risk threshold, an AI agent automatically blocks a transaction with no human in the loop. As transaction size increases and regulatory exposure grows, the process orchestration layer routes the case to a human analyst before taking any action. The boundary is not fixed. The business defines it, the workflow encodes it, and the process layer enforces it, not the model itself.
On the explicitly human side, I draw the line at decisions with major architectural consequences, strategic business risk, or significant regulatory accountability. Choosing a foundational architecture pattern, selecting a strategic technology vendor, designing the governance model for an agentic AI system: These remain human decisions. Moving faster does not recover the consequences of getting them wrong.
Why AI Under Delivers in Three Main Areas
AI has not delivered the technical or engineering impact that customers initially expected in three areas.
The first is enterprise data integration. AI promised to dramatically simplify connecting heterogeneous systems: schema mapping, data quality enforcement, transformation logic, and governance across complex hybrid environments. In practice, AI assists with these tasks but does not solve them. A model cannot reason its way out of the underlying architectural debt, legacy systems with undocumented data models, inconsistent semantics across business units, missing metadata, and fragmented ownership. Engineers still must do the hard work.
The second is agentic AI in complex, multi-step enterprise workflows. The demos are compelling. In production, agents fail unpredictably when they encounter edge cases that training data did not cover, when the context window lacks enough current state, or when the process layer does not gracefully catch and handle agent errors. The gap between what an agent can do in a controlled environment and what we can trust it to do autonomously in a regulated production workflow is still significant.
The third is architectural decision-making. AI tools have meaningfully accelerated routine coding, test writing, and documentation. But they do not reliably improve decisions about foundational architecture. Models reflect past patterns. Enterprise architecture requires judgment about future constraints, regulatory trajectories, and technology bets that models cannot make well. Teams that over-rely on AI for architectural decisions tend to produce systems that are locally coherent but globally fragile.
The common thread across all three is this: AI delivers when the problem is well-scoped, the data is clean and current, and a human with domain expertise is in the loop. It underdelivers wherever the problem requires contextual judgment, organizational change, or architectural thinking that goes beyond pattern matching on historical data.
How AI Struggles With Security and Scalability in Code
The most consistent struggle I see is at the boundary between AI-generated code and production-grade engineering judgment.
AI code generation tools are genuinely useful for well-scoped, repetitive tasks: boilerplate, test cases, documentation, and straightforward transformations. The problems emerge when teams extend that trust to architectural decisions, security-sensitive code, or scalability-critical components without rigorous human review.
On the security side, AI-generated code frequently introduces subtle vulnerabilities that pass automated scanning but fail under adversarial conditions. Prompt injection is the clearest current example in agentic AI systems. An agent that generates or executes code based on user input without proper input validation and sandboxing creates attack surfaces that are easy to miss and difficult to detect after the fact. I have seen this pattern appear in early agentic AI deployments where teams focused on capability and speed and treated security review as a later step.
On the scalability side, AI tools tend to generate solutions that work correctly at small scale but carry hidden assumptions about data volume, concurrency, or latency that only surface under production load. A generated Kafka consumer that works fine in testing can fail unpredictably at ten thousand events per second if the generated code does not account for partition rebalancing, offset management, or backpressure handling. The model does not know your production environment. It knows patterns from training data.
The practical response is not to stop using AI for code generation. It is to treat AI-generated code the same way you would treat code from a capable but junior engineer who has never seen your production system. Review it. Test it under realistic conditions. And never let it near security-critical or scalability-critical paths unless a senior engineer signs off.
What Technology Leaders Must Do Next
Here are three pieces of advice, in the order they matter:
First, invest in your data foundation before your AI ambition. Organizations delivering measurable AI outcomes are not those that moved fastest to a new model. They had clean, real-time, governed data flowing through their systems before the AI conversation started. If your data is siloed, stale, or ungoverned, fix that first. No model compensates for bad data at scale.
Second, treat AI governance as an architecture problem, not a policy problem. Writing guidelines about responsible AI use is necessary but not sufficient. The process layer actually governs agent behavior in production: the workflow gates, the approval thresholds, the escalation paths, and the audit trails that enforce boundaries regardless of what the model recommends. Build those into the architecture from the start. Retrofitting governance after deployment is expensive, unreliable, and usually happens after something has gone wrong.
Third, think in both directions simultaneously. Bottom-up pressure to ship AI use cases quickly is real and legitimate. So is the top-down need for a strategic architecture that avoids creating fragmented point solutions you will spend years untangling. CTOs that I see navigating this well can hold both at the same time: moving fast on specific use cases while maintaining a clear architectural north star that keeps those use cases composable and governable over time.
The organizations that will look back on this period as a competitive advantage are not those that adopted AI earliest. They built the infrastructure to make AI trustworthy, and then moved fast on top of that foundation.
Follow Along
You can keep up with Kai Waehner's work on his website, blog, and LinkedIn.
More expert interviews to come on The CTO Club!
