HomeAI Build SprintProposition 01AI employeeProposition 02Use casesCasesInsights
About us
Plan an introduction

Insights

Why your AI pilot never reaches production (and how to break the cycle)

27 Jun 2026NewWorks7 min read
AgentsWorkflows & automatiseringPilot naar productieAI-adoptieGovernance
Why your AI pilot never reaches production (and how to break the cycle)

The demo went flawlessly. The steering committee was enthusiastic. The proof of concept showed exactly what you had hoped to see. And yet, six months later, the solution is not in production. The licence is still active, the PowerPoint is sitting somewhere on the server, and in the meantime everyone has already moved on to the next project. If this sounds familiar, you are not the exception, you are the rule.

The problem is not the technology

Figures from several large studies tell the same story. In its State of AI report of November 2025, McKinsey states that two thirds of organisations worldwide get stuck in the experimentation or pilot phase, and that only 7 percent have genuinely rolled out AI at enterprise scale. MIT NANDA calculated that 95 percent of generative AI pilots deliver no measurable result on the profit and loss account. And closer to home, in May 2026 KPMG Netherlands shows that only 58 percent of Dutch organisations already see clear business value from AI applications, well below the global average of 64 percent. "The ambition is clearly there, but many organisations find it difficult to make AI a structural part of daily practice," says Alexandra van der Tuin, who leads AI at KPMG Netherlands.

The problem rarely lies in the technology itself. The models work. The vendor has delivered on its promise. What is missing is the structure to turn a successful experiment into a working, managed and supported solution. There are four reasons why this goes wrong, and they keep recurring, regardless of the sector or the type of organisation.

Reason 1: The solution sits beside your systems, not inside them

Most AI pilots run in a sandbox. Clean test data, a shielded environment, and a team keeping a close eye on everything. Production looks fundamentally different: incomplete data from four different source systems, an ERP from 2009 that has no API, and an integration that someone has to maintain by hand.

Research by Harvard Business Review Analytic Services among 385 decision-makers shows that only 18 percent of organisations have fully integrated AI into their daily work processes. The rest use AI alongside the work, as an extra tool that you have to deliberately pick up. That does not deliver operational value, it adds an extra step. The same study identifies outdated IT systems as the main barrier: 69 percent of respondents cite legacy infrastructure as the biggest obstacle to scalable AI rollout.

This is also where most time is lost. As many as 71 percent of AI implementation teams spend more than a quarter of the total project time on data integration: connecting systems, setting up pipelines and configuring connectors. That is time that does not go into the solution itself, but into the foundation that should really have been there already.

Reason 2: No one has a grip on what the AI does

A model you do not understand is a model you do not trust. And what you do not trust, you do not use, or you use it in a way the organisation cannot control. The AI & Digital Marketing Trends 2026 report by Beeckestijn Business School shows that more than half of Dutch employees conceal that they use AI at work, almost half upload company data to public tools such as ChatGPT, and two thirds do not check the output. This phenomenon, "shadow AI", is not rebellion but a sign that there are no clear frameworks.

The absence of governance goes beyond policy. It touches the question of whether the organisation even knows what the model does, on the basis of which data it works, and when the output is wrong. Research shows that 92 percent of organisations agree that AI agents need strict rules and guardrails, but that fewer than half have actually documented those rules. That gap between awareness and execution is exactly where things go wrong: a system in production without monitoring, without a fallback, and without anyone who knows what "normal" behaviour looks like.

This also touches GDPR and EU AI Act obligations. Among Dutch organisations, 57 percent cite possible vulnerabilities around data security and privacy as the biggest obstacle to adopting AI. Those who do not answer those questions before going live answer them afterwards, under pressure, during an incident.

Reason 3: There is no long-term owner

AI systems are not static software. They degrade. The data shifts, the world changes, and a model that performed well last quarter produces suboptimal output today, without any error message appearing. Someone has to notice that. Someone has to decide when it is time to retrain. Someone has to explain to the rest of the organisation what has changed and why.

In most pilot projects that owner is absent. The vendor builds, delivers and moves on to the next project. The internal team that guided the pilot returns to daily operations. What remains is a system without a custodian, and that is precisely the situation that Vector Labs and other implementation partners consistently identify as the most common reason why AI is shut down in production. Three months later the model still works, but no one remembers why it makes the decisions it makes.

A recurring pattern in failed AI projects is that there were no clear success metrics up front, and that initiatives lose executive sponsorship within a few months. Without demonstrable value and without an owner, shutting down an AI solution is always the easiest decision.

Reason 4: Employees were never involved

A system that employees do not understand or do not trust is a system they do not use. That sounds obvious, but in practice adoption is consistently underestimated and dealt with last, once the technology is already finished. The results are predictable. Research by &samhoud among a thousand highly educated Dutch professionals shows that 45 percent never use AI at work, and only 16 percent use it daily. In organisations where leaders actively encourage use, adoption is 2.5 times higher than in organisations where they do not.

The gap is not only between employees themselves, but also between layers in the organisation. In the Netherlands, 78 percent of managers use AI, against 47 percent of employees. That gap reflects something structural: the people who build and order AI are rarely the people who have to use it every day. Microsoft's Work Trend Index 2025 reported that only 24 percent of Dutch workers feel comfortable working with AI agents. Those who feel threatened do not use the tool, or passively sabotage the rollout by sticking to old behaviour.

Adoption is not a communication issue. It is a design issue: the solution must fit the way people actually work, not the way it looked in the pilot.

How to actually get it into production

The organisations that successfully move AI from pilot to production do a number of things consistently differently. They do not start with the technology, but with a concrete, clearly defined business problem: a process with a measurable outcome, existing data of sufficient quality, and an internal owner who also manages the system after delivery. They do not select the most impressive use case, but the most implementable one.

They design for production from day one: integration with existing systems, GDPR compliance, monitoring and a fallback for when the system behaves abnormally are not afterthoughts but starting points. They define what success means before the first line of code is written, not in terms of model accuracy but in terms of business impact. And they involve the people who will use the solution every day early in the process, so that the tool fits real work processes and not an idealised version of them.

Projects that define clear, measurable success criteria up front are demonstrably more likely to succeed than those that do not. The difference lies not in the model, but in the preparation.

From pilot to production: the NewWorks approach

At NewWorks we begin every project with a validation phase: which problem are we solving, which data is available, who is the internal owner, and how do we measure success? Only when those questions are clear do we start building. We work on one use case at a time, code-first, EU-hosted, and we build nothing that we would not use ourselves. The AI Build Sprint delivers one working solution in four to eight weeks, integrated into the existing systems, with an owner who knows how it works and what to do with it once we are gone. Not a demo waiting for approval. Simply something that works.

Share

Curious how this would work for you?

Plan an introduction