Most AI pilots stall for reasons that have little to do with the model. The data is messier than the demo, the ERP has no usable connection, nobody owns the result, nobody approves the output, and nobody agreed what done means. A pilot reaches production when one workflow gets an owner, an approval step and a measure before anything is built.
#Key takeaways
- A pilot that worked in a demo has proven the model, not the workflow around it.
- The usual blockers are data, integration with older systems, ownership, approval and a missing definition of done.
- Wiring AI into an old ERP without a usable API is an integration project that most pilot plans never included.
- A pilot gets into production when one named person owns it and another approves what it produces.
- Start with one workflow and real users, not three pilots and a steering committee.
#Why do AI pilots stall before production?
You are not alone if three pilots ended as three demos. Gartner, july 2024 predicted that 30% of generative AI projects would be abandoned after proof of concept, citing poor data quality, weak risk controls and unclear business value. A report from MIT, covered by Virtualization Review on the MIT NANDA report, august 2025, found that 95% of organizations saw no business return from generative AI.
In operations-heavy companies the same five gaps come up again and again:
- data: the pilot ran on a clean sample. Real inputs arrive as scanned pdfs, half-filled forms and messages in Arabic and English.
- integration: the workflow runs in an ERP that is fifteen years old. Reading from it and writing back was never scoped.
- no owner: the pilot belonged to an innovation team, and the department that would use it never asked for it.
- no approval step: nobody decided who checks the output before it reaches a customer, a supplier or the ledger.
- no measure of done: the pilot was judged on whether it impressed people, not on a number the department already tracks.
#What changes when a pilot is built to run in production?
The order of work changes. Instead of starting with a model, Stennir starts by mapping one workflow with the person who runs it: where the input arrives, which rules apply, where the result goes and which exceptions need judgement. That map becomes the spec, and it shows early whether the real blocker is the data or the integration.
Then three things are agreed before building: who owns the workflow on the client side, who approves the output, and which measure counts as done, such as backlog size or the share of cases handled without rework. The build happens inside the systems the team already uses, with every action logged, and real users see it from the first version.
#How do you take a hackathon prototype to production safely?
A hackathon prototype is useful evidence. It proves the task is possible. What it usually lacks is error handling, access controls, logging, a test set built from real cases and a way to switch it off. Treat the prototype as a draft spec, not as the first release.
The safe path is to rebuild the parts that touch customers or money behind an approval step, test them against a set of real past cases, and add monitoring before more users join. The worked example on taking an AI prototype to production walks through those steps on one workflow.
We are
Stennir takes one workflow from pilot to production inside your own systems, with a named owner, a person approving the output, and a measure agreed up front.
We aren't
Stennir is not a lab that runs more pilots, and not a platform vendor that asks you to move your work into a new tool.
#Our project is stuck at the trial stage. What do we do first?
Pick the pilot whose department actually wants it, and ask the person who would use it daily to describe the work it replaces. If they cannot, the pilot was solving the wrong problem. If they can, write down the exceptions, name an approver and agree the measure. That usually reveals whether the gap is data, integration or ownership.
Teams in the Gulf often add one more step: the workflow has to handle Arabic and English inputs, not only the English sample the pilot was tested on. Checking that early saves another stall later.
#What should a COO with stalled pilots do next?
Choose one stalled pilot and one owner, then bring both to a conversation about AI implementation, where Stennir builds one workflow running with real users and keeps it monitored afterwards. If you are not sure which pilot deserves it, AI consulting ranks the options first. See also AI for operations. You can take the free readiness assessment or book a 30-minute call.
#Common questions
What do you need from us to restart a stalled pilot?
The pilot itself, the person who would use it every day, a set of real past cases and access to the systems it must read from and write to. You also name who approves the output. Stennir uses those to map the workflow and find which of the five gaps stopped it.
Can you reuse what our developers already built?
Often, yes. A prototype shows which prompts and steps work. Stennir keeps what holds up against real cases and rebuilds what is missing for production: access control, logging, error handling, an approval step and monitoring. Your developers can stay involved and keep the code, which stays in your accounts.
Does it work with an old ERP that has no proper API?
It can, but that is integration work and it is scoped as such from the start. Options include reading exports, using the database directly with read-only access, or working through the screens your team already uses. Stennir names the approach before building so it does not surprise anyone later.
What could go wrong in production that did not go wrong in the pilot?
Real inputs are messier, volumes are higher and edge cases appear that the sample never had. That is why Stennir keeps a person approving the output, logs every action, tests against real past cases and monitors results once real users start, so problems show up as numbers rather than as complaints.
