![](\"https:\/\/cdn.pblzr.de\/dacbb27c-1270-4041-b681-e2b95f06f8a1\/2026\/09\/criticalmanufacturing-logo-400x300_TEXT.jpg\"){kind=logo}
<\/p>\n<\/p>\n
The demos look great. A second use case is launched. Then a third. Each one starts from scratch. None of them builds on the others. After twelve months, the board\u2019s question shifts from \u201cWhat is our AI strategy?\u201d to \u201cWhere\u2019s the return on investment?\u201d Why 95% of corporate AI projects fail to deliver a return on investment.<\/p>\n
The data confirms what those responsible for digital transformation are observing in their own companies. The report from the MIT Media Lab\u2019s NANDA project concludes that, despite companies\u2019 enormous investments in generative AI, 95% of companies are not achieving a business return. And the report includes a quote from an interview with the COO of a medium-sized manufacturing company that I found particularly valuable for this discussion:<\/p>\n
\u201cThe hype on LinkedIn suggests that everything has changed, but nothing fundamental has shifted in our operational processes. We\u2019re processing some orders faster, but that\u2019s really all that\u2019s changed.\u201d<\/p>\n
So this isn\u2019t a modeling problem\u2014it\u2019s an architectural problem. This becomes most evident in a discussion currently taking place in nearly every IT department of a manufacturing company: Should we connect our new AI agents directly to the operational systems that control the factory?<\/p>\n
The technically correct answer is \u201cno.\u201d The strategically important answer is: \u201cWhy?\u201d<\/p>\n
There\u2019s a meme circulating in IT circles that sums up the problem with a reference to Gandalf: You shall not connect an MCP to your operational database.<\/p>\n
The Model Context Protocol (MCP) is the new standard for granting AI agents access to enterprise data and tools. In a manufacturing environment, the operational database behind the execution system stores the current production status. Work in progress. Equipment status. Quality holds. Genealogy. Operator actions. Process enforcement. Technically speaking, it\u2019s possible to connect an AI agent directly to this database. But it\u2019s also the fastest way to ensure that your AI program never makes the leap from pilot operation to production.<\/p>\n
The reason lies not only in security, although the security risk is real. The reason is that this architecture is not scalable. Every new use case must figure out the same operational meaning from scratch. Every model must relearn what a \u201cHold\u201d instruction means, what a route is, who is authorized to approve what, and what constitutes a valid state change. There are no cumulative resources. There is no shared context. There is no regulated path from insight to action.<\/p>\n
Every AI pilot project that bypasses the execution layer rebuilds the context that should actually be created once and reused forever. Executives driving these transformations sense this intuitively, even if they can\u2019t put a name to it. That\u2019s why their pilot projects look impressive in the conference room but prove fragile on the shop floor. That\u2019s why the second use case takes almost as long as the first. That\u2019s why the program never reaches its promised scale.<\/p>\n
When AI is connected to manufacturing through the wrong level of abstraction, four specific things go wrong. None of these manifest as system errors. All of them show up on the income statement.<\/p>\n
An AI agent that draws conclusions from raw data tables will ultimately deliver a confident, plausible, but incorrect answer.
In the boardroom, that\u2019s embarrassing. In a factory, it changes the way operators treat every future recommendation. Once manufacturing employees lose trust in the system, the value of every downstream use case drops to zero\u2014regardless of the model\u2019s quality.<\/p>\n
A row in a database is not a business transaction. Actions such as lifting a lockout, changing a route, moving materials, or adjusting equipment statuses are subject to manufacturing decisions that involve rules, approvals, and consequences. An AI based on rows rather than events makes decisions that appear correct when viewed in isolation but cause chaos when considered as a whole. The operational definition of a delayed batch is not the same at one site as it is at another.<\/p>\n
Models that do not take this into account provide recommendations that represent an average across all plants and are not applicable anywhere.<\/p>\n
There is only a single tool call between an AI that answers a question and one that performs an action. Without a regulatory layer in between, that boundary disappears.<\/p>\n
So if an agent ultimately writes incorrect data into production or triggers a workflow that skips a required check, the incident report won\u2019t say, \u201cIt was the AI.\u201d It will say: \u201cWe don\u2019t know what happened.\u201d<\/p>\n
That is a worse outcome than any number of failed pilot projects, no matter how large.<\/p>\n
In regulated environments\u2014including medical devices, pharmaceuticals, semiconductors, and, increasingly, aerospace and defense\u2014any system that affects production status must be validated, traceable, and explainable.<\/p>\n
An AI agent with direct database access cannot meet this standard. The agent itself isn\u2019t the problem; it\u2019s the architecture surrounding it. Any regulatory authority involved will recognize this even before the AI team does. Each of these issues can be resolved in a pilot project. None of them can be resolved in production operations.<\/p>\n
The cost of fixing these issues retroactively\u2014through revalidation, rebuilding trust, and restoring credibility with the board\u2014is an order of magnitude higher than the cost of designing the architecture correctly from the start.<\/p>\n
It\u2019s never been easier to create an AI demo for manufacturing. APIs, connectors, MCP, function calls, low-code orchestration. A skilled team can produce something impressive within a week: realistic-looking data, natural-language responses, generated SQL, a draft action plan. To executives, it may seem as though the future is already here, but in reality, they\u2019re still a long way from it.<\/p>\n
Most of these demos work because they leave out the crucial parts. They run on limited amounts of data. They assume clean semantics. They use user-friendly prompts. They rely on elevated permissions. They avoid edge cases. They aren\u2019t confronted with the pressures of shift changes, audit requirements, plant exceptions, site-specific configurations, or regulatory oversight.<\/p>\n
Anyone can demonstrate AI, but few can deploy it reliably in live operations. The difference lies not in the model, but in what lies between the model and the factory. A proof-of-concept can answer the question: \u201cWhich batches are delayed?\u201d A production system must answer a much more difficult question: Which batches are delayed\u2014according to the correct operational definition, for this user, at this location, based on validated data, with traceable reasoning, without disclosing confidential information, and without triggering an unsafe downstream action.<\/p>\n
The correct pattern is easy to describe but more difficult to implement. AI agents should not connect to the operational database. They should connect to regulated production capacities, which in turn operate via the execution system.<\/p>\n
This regulated capacity layer is where the added value is created, and that is where the business significance lies. Authorization, sequencing, validation, and traceability are also enforced there. There, the distinction between \u201crecommend\u201d and \u201cexecute\u201d is made explicit.<\/p>\n
Every AI use case connected through this layer reuses everything that has been previously modeled, rather than reinventing it.<\/p>\n
What I have emphasized time and again is that a well-modeled execution layer is the canonical operational data model that makes AI trustworthy at scale. Simply put: structure first, then intelligence. McKinsey reached the same conclusion from a different perspective in April 2026. In \u201cScaling agentic AI with data transformations,\u201d they report that nearly two-thirds of companies have experimented with AI agents, but fewer than 10% have scaled them to the point where they deliver tangible value. Their assessment is clear: \u201cSuccess with agentic AI depends on a data architecture that can support increasing levels of autonomy, coordination, and real-time decision-making.\u201d<\/p>\n
Eight out of ten companies cite data constraints as a barrier. In the manufacturing industry, this data architecture already exists. It is referred to as the execution layer. For a CIO or transformation leader, this shifts the focus of the AI discussion in a useful way. The question is not which AI tool to buy. The question is which layer of the architecture possesses the controlled capabilities on which every future AI use case will depend.<\/p>\n
If this layer exists and is under your own control, AI becomes an investment that pays off. If this is not the case, every pilot project is a standalone initiative, and the program will never reach the scale that justifies the budget. Create an execution layer that amplifies every AI use case.<\/p>\n
If you\u2019re leading digital transformation at a manufacturing company, a shift in the AI discussion is on the horizon. The first wave was about access: Can we get models to communicate with our systems? The next wave is about control: Can we get models to act through our systems securely, at scale, and with self-reinforcing results?<\/p>\n
The companies that win this next wave will not be the ones with the best models. They will be the ones whose operational layer has been built to form the canonical context for AI. They will have a standardized competency layer upon which every new use case can be built at no cost. Their second AI initiative will cost only a fraction of their first. Their tenth will be almost free. The companies that fall behind will continue to launch pilot projects. The pilot projects will continue to look good. And the return on AI investment will continue to take twelve months to materialize.<\/p>\n
AI in manufacturing doesn\u2019t fail because the models are wrong. It fails because the execution was never properly modeled. Once that\u2019s fixed, AI stops being a pilot program and becomes a self-reinforcing asset. So yes, you shouldn\u2019t connect MCP directly to your operational database. But the real point goes beyond that. You should build an execution layer that makes every AI use case a multiplier of the previous one, rather than a repetition of the same initial project.<\/p>\n
This is the architectural decision that determines whether your AI program achieves the scalability it was sold on, or whether it quietly becomes the most expensive collection of demos your company has ever paid for.<\/p>\n
– – – – –<\/p>\n