The possibility is proven. The deployment isn't.

Here is an uncomfortable observation: your AI pilot didn't die because the model was weak. It died because you installed a capability where you should have launched a product. I have attended this funeral before. In the 2010s the casket held a problem-solving programme; this decade it holds a neural net. The eulogy is word for word. PES Media made the point in print recently: the challenge in AI engineering is no longer possibility, it is deployment. Correct conclusion. Undefined word. So let us define deployment the way a plant would.

Installation is not deployment

Installation is a technical event. Camera mounted, inference server racked, demo running flawlessly on the golden parts the supplier pre-sorted. Deployment is an operational state: the model taking part in production as a process step with defined responsibility, an agreed escape allowance, a reaction plan, and an owner whose phone rings when the line stops at 03:00. Between those two definitions lies the gap where €300,000 of cameras, licences and integration goes to be politely bypassed by week three.

The capability itself is now an off-the-shelf purchase. Analysts put the AI defect-detection software market at roughly 12% compound growth, and the ecosystem is consolidating around it – Boomi has just acquired Elementary Data to bolt data quality and governance onto the flow. The market is doing what markets do: commoditising the easy half. Models are the easy half.

A demo proves the model. A launch proves the plant.

I ran this experiment a decade early. At Witte Automotive we cut failure costs hard with QRQC, A3 and a Q-Wall discipline that refused to let problems age. Later, rolling the same toolset across a multi-site network of more than 2,000 people, I watched the split appear inside a year. The sites that adopted the paperwork failed politely. The sites that embedded it in daily management – tiered meetings, standard work, reaction plans an operator could reach without leaving the station – cut failure costs and kept them cut. Same tools, same training, same slides. The variable was the operating routine around the tool. An algorithm obeys the same law, at higher speed.

Borrow the launch discipline we already own: APQP for algorithms

Nobody in automotive ships a bracket on the strength of a demo. A part reaches the line through APQP: feasibility, PFMEA, control plan, capability study, signed tolerances, a reaction plan for the day the process speaks. The same companies then let a model go live on a pilot deck and a metric from the vendor's curated test set. That is not a knowledge gap. It is a discipline we already own and failed to apply. Three transfers do most of the work:

• Run a PFMEA for the model-in-process. Treat the model as a step between part presentation and disposition. False accept is an escape – severity unchanged, a scratch is still a scratch. False reject costs downtime and, worse, teaches operators to override; a model that cries wolf gets muted permanently. Then add lighting drift, presentation variation, retraining contamination. Detection is not the vendor's recall figure. Detection is your system: audit samples, escape monitoring, escalation paths. Score it honestly and the RPN says what the sales deck would not.
• Sign the false-accept threshold before go-live. No customer accepts "good parts, mostly" as a tolerance on a bore. Yet models routinely go live with no agreed escape allowance at all. Define it in PPM, sign it like a dimensional spec, and set the audit frequency to detect at that rate. A threshold negotiated after the first field complaint is not a threshold; it is a settlement.
• Handle drift as uncontrolled process change. Retraining on contaminated data, new lighting, a supplier's subtly different surface finish – each changes model behaviour without appearing in any change log. That is an uncontrolled change to a special characteristic. Contain it, run it as an 8D, release it through change control – or stop calling the process controlled. IATF 16949 does not care that the parameter lives in a weights file.

What sixty-three models arguing taught me about uncertainty

I built and run MultiPS, a platform that sends each query to 63+ models in parallel and synthesises consensus. Everyone assumes the hard engineering was the models. It never was; models can be rented by the hour. The hard engineering was the disagreement rule – what counts as consensus, when dissent is signal rather than noise, what escalates instead of averaging itself into confident nonsense.

The lesson transfers to the shop floor intact. Consensus – among sixty-three models, or between a vision system and a line operator – does not deliver truth. It delivers a visible distribution of opinion, useful only if you decided in advance what to do with it. A confidence score is an opinion with a decimal point, not a measurement. Deployment means writing down, before the first shift, who adjudicates a split verdict, what gets contained while they do, and what the model is never allowed to decide alone.

The engineering press has moved the goalposts, and purchasable capability will keep compounding at double digits. Good. Possibility was never our department; launch discipline always was, under older names. An algorithm going live in a plant is a product launch – with a PFMEA, a signed tolerance for its errors and change control over its own mind. Run it that way and it lives. Install it and the funeral is already booked. The eulogy, as always, will praise the demo.