The proof of concept worked. Then nothing moved.
The report is written, the board has seen it. A year later none of it is in use. The technology is rarely the problem. The reasons an AI pilot stalls are few, and they are almost always baked into the first design.
- PoC (proof of concept)
- A proof of concept, or PoC, checks on a small scale whether an idea can be built. Production asks for different things: real data with its exceptions, a named owner, integration with the systems already in place. AI pilots stall in that gap.
Why pilots stall
None of these show up during the pilot. It is set up so they do not.
Clean data in the test
For the pilot someone picks the ten best documents. In production you get scans from 2014, three versions of the same template and tables with empty columns. Accuracy drops, and the discussion starts.
Nobody runs it
Who updates the index, who takes the questions, who notices when quality slips? Between IT and the business unit that stays open. The system is not switched off. It just stops being used.
No approvals built in
What happens on an obviously wrong output? Who stops it, where is it confirmed? Until that is settled nobody signs the request for production. Many pilots hang on exactly this point, not on the technology.
Cost per request unknown
The pilot ran 40 requests a day on a developer’s account. What 4,000 requests cost, which model still carries that and who gets the invoice, nobody has worked out.
Users were not in the room
The pilot was built for the business unit, not with it. The people who are supposed to use it every day see it for the first time in the closing presentation. They find the three cases that fail within five minutes.
Security sign-off missing
The pilot ran on a laptop with a test file. Production needs data protection, IT security and often the works council to agree. Start that after the pilot and you lose months.
All six can be settled before the pilot. Afterwards it is tedious. Beforehand it costs almost nothing.
Continue, re-test or shut down
Not every stalled pilot needs to run again. We sort by day-to-day impact and by how certain the implementation is.
Straight to production
Only integration and an owner are missing. That takes a few weeks. This is where we start.
Re-test first
Run it on messy data and see where quality breaks. Design comes after that, not before.
Later
It clearly can be built. There is no reason to hurry, so it moves down the list.
Shut down
Whatever lands here gets closed. That is part of the job too.
Pilot versus production
Same idea, two different sets of demands. The right-hand column is what a proof of concept usually does not deliver.
| Criterion | In the pilot | In production |
|---|---|---|
| Data | Ten hand-picked documents | Everything on the file server, exceptions included |
| Success metric | “It works” | Hours that measurably disappear |
| Integration | Data pasted in by hand | Interfaces to ERP, document store, mailbox |
| Owner | The developer who built the pilot | A named person in the business unit |
| Error case | Clicked away | Stop rule and approval, documented and built in |
| Cost | Test account | Cost per request known, budget approved |
| Sign-off | None | Data protection, IT security, works council if needed |
Seven steps, an exit at the end of each
At the end of every step you decide whether to go on. If you stop, you keep everything produced up to that point.
The steps are separate so you can get out. Order everything at once and people stop raising the awkward findings halfway through.
Enquiry
Where is it stuck? We read the old pilot’s material, even if another vendor built it.
Consultation
Triage by impact and certainty. Set the order, name the candidates for shutting down.
Concept
Success metric in numbers, stop rule and owner go in writing here, together with the fixed price.
Development
Built on real data, exceptions included. Integration with your systems comes first, not last.
Review
The business unit uses the system and lists what does not fit. We work through the list.
Acceptance
Checked against the metric from step 3. It is not moved afterwards.
Operation
Handbook, monitoring, handover to your named person. We stay on under a maintenance contract if you want.
What belongs in the pilot already
Six decisions that rarely get made in a proof of concept. They are exactly what is missing later when production is requested.
Make them at the start and they cost almost nothing. Catch up on them at the end and you pay in months.
Three published projects, all in production
We do not show pilots as references. Only systems that have been handed over and run at the client appear on this site.
Each has a case study with architecture and numbers.
Five questions about your pilot
If you cannot answer three of them straight away, it is worth going back to the concept.
From pilot to production: frequently asked questions
Related topics
AI agency Munich
Production grade AI agents instead of pilots, with a fixed price and on-site meetings.
AI consulting Munich
Assessment and roadmap before anything is built. A no is a possible result.
EU AI Act documentation
Risk classification, system register and technical description for operators.
Show us the pilot, exactly as it is.
In thirty minutes we can tell you whether it is worth carrying on. If it is not, we say that too.