Why AI PoCs die in week six, and how to ship in week eight instead
After three industrial projects and a dozen pitches, the pattern is the same. The PoC works in a notebook, dies on integration, and is buried by week ten.
A pattern I see in every Italian SME I have consulted with — Dekali, Extrema, the System Consulting client, and three more that did not turn into projects: the AI proof-of-concept dies on week six. The model works. The integration does not. The team gets demoralised. The PoC budget gets repurposed for a new sales hire. The story spreads. The next AI engineer the company talks to inherits a sceptical room.
The failure mode is consistent enough to map. Week one to three, the engineer prototypes in a Jupyter notebook. By week three there is a demo that wows everyone. Week four to five, the engineer realises they need to connect the model to the existing ERP, or the existing CRM, or the existing Excel workflow that the office actually runs on. Week six is the integration meeting where the ERP vendor explains that exposing the right data requires a six-month change request and a three-thousand-euro fee. The model becomes irrelevant. The PoC is buried at week ten.
The fix is structural, not technical. I now refuse to start a PoC until three integration questions have written answers. First, who owns the data the model will consume? If the answer is "a vendor whose contract requires sign-off for any data export", the PoC is built on a hidden cliff. Second, where will the model output be displayed? If the answer is "we will figure that out later" or "in a new tab", you are building a parallel product nobody will open. Third, who maintains it after launch? If the answer is "the AI engineer", you have built a system that ends the day the engineer leaves.
The PoCs that ship in week eight rather than dying in week six have those answers locked in week zero. The model risk is not the bottleneck. The integration risk is. So I now scope the PoC around the integration constraint, not the model capability. If the existing ERP can only consume one prediction per order per day, the model is designed to produce one prediction per order per day, even if it could produce real-time. If the existing UI has exactly one place to put a number, the model output is exactly one number. The model fits the slot it has been given.
The second structural fix is the "decoy demo". The first version we show stakeholders is deliberately not the most accurate one we could build. It is the most integrated one we could build. A 70%-accurate model wired correctly into the ERP, with a clear placement for its output and a clear path for the analyst to override it, is more valuable in week four than a 95%-accurate model sitting in a notebook. The decoy demo reframes the conversation from "is the model good enough?" — which is unanswerable — to "is the integration good enough?" — which is answerable, and which is the actual blocker.
The third structural fix is documentation no engineer writes spontaneously. A one-page sequence diagram of the full integration, listing every system that will see the prediction, every actor who will need access, and every place the prediction will be displayed. The diagram is reviewed by the IT lead, the operations lead, and the eventual maintainer. Anything they cannot sign off becomes a blocker for the PoC. This sounds like bureaucracy. It is the single highest-leverage hour I now spend in week one of any new project.
The outcome of doing PoCs this way: my projects ship. Dekali shipped. Extrema shipped. Adhoc SCF will ship. The model in each was not the most sophisticated I could have built. The model was the most slot-fitting I could have built. The lesson is that in an SME, the model is the easy part, and the slot is the engineering.