AIPLOMACY · Computer Vision Deployment
Why computer vision projects stall
We reviewed a practice of more than a hundred deployments and analysed the ones that went wrong. They had different causes — not one of them was the model.
A briefing for organisations evaluating computer vision on industrial, retail, logistics and public-facing sites. Drawn from deployment practice documented with True Detection.
The finding
Adoption is widespread. Value capture is not.
Most organisations evaluating computer vision have already seen a convincing demonstration. Very few have seen a deployment that produced the effect the demonstration implied.
It is tempting to read that gap as a technology problem. We think that reading is wrong, and it is expensive. Object detection is a mature, heavily benchmarked class of problem, and the research risk in a typical commercial deployment is close to zero. When a project disappoints, the cause is almost always somewhere else: on a mounting bracket, in a document nobody wrote, or in a response process nobody designed.
In building our Computer Vision Deployment course with True Detection, we examined the deployments that fell short. They had different primary causes — planning, cameras, data, people, economics, and the form in which results were delivered. Not one of them was a modelling failure. In no case did the technology turn out to be incapable of the task.
That has an encouraging consequence. If the risk does not sit in the technology, most of it sits inside your own organisation — which means it is knowable in advance, and a good deal of it is fixable for the cost of a conversation.
Exhibit
Where value leaks out of a deployment
Four stages, four decisions, and the failure that follows when each one is skipped.
| 1 Frame | 2 Prepare | 3 Prove | 4 Operate and scale | |
|---|---|---|---|---|
| The decision | Is this task solvable, and is it standard or bespoke? | Can this site actually produce the image the task needs? | What result would make us proceed — and against what? | Who acts on the output, and what happens if nobody does? |
| What fails when it is skipped | A requirement that cannot be annotated, measured or accepted | Accuracy blamed on the model when the cause is geometry or light | A pilot that measures, and is then asked to prove improvement | A system that works perfectly and is quietly no longer read |
| When it becomes visible | During annotation, as frames nobody can classify consistently | In the first week of footage, long before any metric moves | At the closing meeting, when the comparison does not exist | Months later, if anyone is measuring the response |
AIPLOMACY, from deployment practice documented with True Detection
The bottom row is the one we would ask you to notice. In every case the failure was detectable well before it was noticed, and usually in the raw material rather than in a dashboard. Frames, streams and the questions people ask about numbers are leading indicators. Reports are lagging ones.
What to establish first
Four questions that decide the outcome before anyone spends money
None of these requires a supplier, a budget or a technical specialist. Each one closes off a category of failure.
-
1. Is the sign physically in the frame?
A camera sees surfaces; it cannot see through them. One deployment set out to verify that a product had been assembled correctly, and only during scoping did it emerge that the ingredients in question sat beneath a layer of cheese.
The test: could a competent person, looking only at the camera image and nothing else, reliably make the judgement you want? If not, this is not a computer vision task, and no supplier can make it one.
-
2. Would two of your supervisors agree?
Requirements arrive regularly as “detect untidy appearance” or “check that this is done properly”. Each describes a judgement rather than an observation. Until somebody defines what properly means — what threshold, what visible state, what duration — there is nothing to annotate, nothing to train against, and no way to tell at acceptance whether the system is right or wrong.
This looks like a technical problem and it is not. It is your work, it takes calendar time, and it cannot be delegated — because it is a question about your operation rather than about vision.
Read the rest
Two more questions, and what sits around the technology
The full briefing is a six-page PDF. Tell us where to send it.
What the full briefing covers
- The two remaining questions, in full
- Why a detector that works on one site does not travel to another
- Where resistance actually forms — and it is not where managers expect
- Why timelines fork between one week and three months, and how to tell which you are on
- A documented case: the system that assumed a behaviour nobody had asked for
- Four things you can establish this week, without a supplier