Most failed AI pilots do not fail for technical reasons. They fail in the first two weeks, in decisions made before anyone trains a model. After eight years of building AI systems for industry, biotech, and medical technology, we see the same five mistakes over and over.
1. The pilot has no decision attached
"Let's see what AI can do with our data" is not a project — it is an invitation to an inconclusive demo. A pilot that works is attached to a decision someone actually makes: release or hold this batch, alert or don't alert, escalate or resolve. If you cannot name the decision, the operator who makes it today, and what a wrong call costs, the pilot has no way to succeed — there is nothing to succeed at.
2. The data is assumed, not audited
Teams routinely discover in week six that the labels are inconsistent, the interesting cases were never recorded, or the historical data does not match what the live sensors produce. A two-day data audit before committing prevents a two-month failure after. This is why our engagements start with a feasibility stage on the client's real data — not a proposal written from a slide deck.
3. Success is "accuracy" instead of acceptance criteria
"95% accurate" means nothing on its own. On a line with one defect per thousand parts, a model that says "OK" every time is 99.9% accurate and completely useless. Agree up front on the metric that matches the decision — false-alarm rate the operators will tolerate, miss rate the business will tolerate — and on the evaluation protocol. That number, agreed before development, is what separates an engineering project from a demo.
4. Nobody budgets for the demo-to-production gap
The model is a third of the work. The rest is what makes it usable: integration with your machines and databases, calibration drift, operator interfaces, logging, review workflows, retraining when reality shifts. Pilots scoped as "just the model" produce exactly that — a model, on a laptop, forever.
5. There is no internal owner
A system nobody inside the company owns is dead the day the consultants leave. The fix is boring and works: one named person on the client side, involved from the first week, who runs the system when we hand it over.
What we do differently
This is why GI works feasibility-first: a short, fixed-fee sprint on your data that ends in a working demo where the data allows — and an honest build / no-build recommendation either way. Telling a client not to build is a perfectly good outcome; it costs them a sprint instead of a year.