This is a situation we come across more and more often at BleuLemon: a client hands us a problem, we build a POC, we test it with the teams, and it works, genuinely. The need is covered, the users agree, the time saved is real. So naturally, the question comes:
"When do we put it into production?"
And that is where the trouble starts. A few weeks later, the project can find itself stuck, neither challenged nor abandoned, simply caught in that strange zone where everybody finds it interesting, but nobody manages to move it forward.
This is not a marginal phenomenon. Gartner reported in January 2026 that at least 50% of generative AI projects had been abandoned after their POC, mainly for reasons of data, risk, cost or insufficiently demonstrated value. BCG observed in September 2025 that only 5% of companies manage to generate value from AI at scale, and McKinsey notes that 88% of companies use AI in at least one function, but that only 7% have deployed it at organisation scale.
So AI is everywhere. But industrialised AI is still rare. Our experience leads us to a simple answer:
Many AI POCs do not die because they failed. They die after they succeeded.
We ask the POC to answer the wrong question
When we launch a POC, the question is generally: "can AI do it?" That is the first thing to check. But in 2026, it is almost the easiest one.
What the POC does not tell us is whether we will be able to run the solution with 5,000 users instead of 20, with the real access rights, the real security constraints, the production costs, and above all with the organisation that this solution will sometimes deeply reshape.
We have simply taken on a debt.
I like to call this scaling debt: like technical debt, it lets us move faster today, but it will have to be repaid tomorrow.
To move fast, we bypassed the very people we now need
To test an idea quickly, the business often asks us not to involve Data, AI, architecture or security straight away, otherwise the project would take six months to start. We quickly get something convincing. Then industrialisation comes, and we go back to the teams we carefully left aside: the conversation changes immediately, with a volley of questions about the model, the hosting, the rights, the compliance.
It is tempting to conclude that "the AI team is blocking the project". That would be unfair: we are asking them to sign off, after the fact, on decisions they never took part in.
The shortcut that let us succeed quickly on the POC becomes the detour that then stops us deploying it.
The answer is not to put thirty people into every experiment, but to involve a few key players very early, with one simple rule:
You are not here to slow the POC down. You are here to stop us building a POC that cannot be industrialised.
And then someone asks: "is this technology approved?"
The POC runs on a reasonable technology: an LLM, an agentic framework, an API. Then the question lands: "is this technology approved here?" The problem is that the approval process for AI solutions often does not exist yet: which category of models, on which data, from which level of autonomy does validation become necessary?
The solution cannot go into production because it does not comply with a governance that does not exist yet.
Removing governance would be a poor answer, however: as soon as an agent acts on the real world, we are talking about rights, responsibilities and security. Gartner estimates that only 13% of organisations currently have a sound agent governance capability, while a Fortune 500 company will run more than 150,000 of them by 2028. And McKinsey shows that it is precisely the companies that redesign their work processes, the practice most correlated with the economic impact of AI among 25 studied, that get the most value from it.
Governance should not be the toll booth installed at the POC's exit. It should be part of the road.
Your POC no longer arrives alone
Every POC now arrives in a company where Copilot, Rovo, Agentforce, IBM or Google solutions and in-house developments already exist. The question is no longer only "does this solution meet the need?" but "do we want one more building block in our IT landscape?" Gartner calls it agent sprawl, the uncontrolled proliferation of agents.
How do we avoid the Wild West without becoming the department of "no"?
Past a certain point, an AI POC is no longer a functional project: it is an enterprise architecture decision.
Sometimes the POC even works a little too well
An activity takes up five FTEs; AI lets a single assisted employee absorb most of the workload. The gain is dramatic, but what do we do with the other four people? Do we cut roles, redeploy them, retrain them? Who will be accountable when the AI gets it wrong?
Change management is no longer a workstream of the project. It is the project.
If AI saves 20 minutes a week for 200 people, it is a productivity project. If it takes an activity from five FTEs to one, it is an organisational transformation project, with an entirely different governance.
The higher the gain the POC announces, the harder it can become to deploy, politically and humanly.
"Let's wait six months. AI will have changed again."
Which model do we choose today, knowing that everything will move within twelve months? The reasoning that pushes us to wait is rational, but in six months the same uncertainty will still be there.
How do we make sure that replacing this technology in two years' time is not a drama?
This is where architecture becomes essential again: decoupling the business logic from the model, keeping the evaluations, avoiding dependence on a single vendor. It is the same question as reversibility.
Let us not industrialise only our model. Let us industrialise our ability to change model.
Then comes the plumbing
A RAG assistant is beautiful on 200 curated documents. The company's real document system is something else: 500,000 files, several versions, disparate formats, inherited rights, permissions that keep changing. The real challenge is then no longer to get an intelligent answer, but to be absolutely certain that the AI never gives an employee information they were not entitled to see. Then comes everything a POC never had to handle: monitoring, incidents, SLAs, support, and costs that change scale.
That does not mean the POC was bad. It had simply proven something else.
A successful POC should almost worry us
We are used to celebrating when a POC succeeds. But it may be the moment when we should also start to worry: if AI can genuinely cut the time spent on an activity by five, we need to think about the organisation that goes with it; if it can reach the whole of the company's knowledge, we need to question its rights.
Technology sometimes starts moving faster than the company's ability to absorb it.
The POC tells us AI is ready. The blockage that follows tells us the company is not yet. So perhaps we should change the question we ask at the start:
"If it can do it, are we really ready to let it?"
A POC that works is not yet a successful project. It is only a project that has just earned the right to ask the real questions.
Perhaps, in the end, we should stop doing POCs
We must of course keep experimenting. But perhaps we should look, from the outset, for two proofs in parallel: a proof of value (is this worth continuing?) and a proof of deployability (if it works, do we know what to do next?). That does not mean making every POC heavier, but being able to answer, even roughly, a few questions before starting:
Who will take ownership of this solution if the POC works?
Which AI, architecture, security or Data teams need to be involved right now?
Which existing platform, Copilot, Rovo, Agentforce or another, already covers all or part of the need?
Roughly what will the cost be when we go from 20 to 20,000 users?
What will the impact be on the business and on people if the POC delivers the gains expected?
And if the chosen technology becomes obsolete, are we able to replace it?
We do not need to have all the answers. But we do need to know that they can exist.
At BleuLemon, we do MVPs
That is why, at BleuLemon, we recommend stopping doing POCs. A POC proves that a technology works, and that is no longer enough. What is needed, from the outset, is a project that includes all the governance, architecture, rights and organisation required to be genuinely viable in a company and to scale. That is no longer a POC. It is an MVP, a Minimum Viable Product.
Let's talk about it
At BleuLemon, our role is no longer only to demonstrate that an AI use case works. It is to help you ask, before the POC, the questions that will decide whether it can survive it.
Do you recognise one or more of these blockers? Let's talk about it.
Sources
Figures checked on 11 September 2026:
Gartner, Why Half of GenAI Projects Fail: generative AI projects abandoned after POC and the reasons behind it, data, risk, cost, value.
Gartner, Six Steps to Manage AI Agent Sprawl: the maturity of agent governance and anticipating "agent sprawl".
Boston Consulting Group, The Widening AI Value Gap, September 2025: the share of companies generating value from AI at scale.
McKinsey, The State of AI, 2025: the gap between AI adoption and deployment at organisation scale, and the link between redesigning work processes and the economic impact of generative AI.