Section 1
Four tasks that account for most business value
Counting: units, vehicles, people, packages. Useful wherever throughput is currently estimated. Detection: is the safety guard in place, is the shelf empty, is there a spill, is someone in a restricted area. Useful for conditions that matter only in the moment they occur. Reading: extracting text and numbers from labels, plates, meters, forms, and handwritten dockets. Often the fastest payback of the four because it removes typing. Comparison: does this unit match the reference, is this weld consistent, is this batch discoloured. This is where quality inspection lives, and where the accuracy requirement is highest. If a proposed project does not reduce to one of these four, be sceptical. The build sequence for such projects is covered in [AI Automation in Product Development: From Idea to Launch](/blog/ai-automation-in-product-development-from-idea-to-launch).
Section 2
The cost is in the examples, not the model
Founders expect the expensive part to be the algorithm. It is not. Capable models are available off the shelf. The expensive part is examples: images from your actual site, in your actual lighting, labelled by someone who knows what correct looks like. Defect detection makes this vivid. To learn a defect, the system needs examples of it. If the defect occurs in one unit per thousand, collecting a few hundred examples takes months of production, and the ones you have may be photographed badly. Budget for the labelling, name the person doing it, and expect them to be a domain expert rather than a temporary hire. A dataset labelled by someone who could not tell a defect from a shadow will produce a system with the same weakness.
Section 3
It is fragile in ways software usually is not
A vision system is coupled to physical conditions. Move the camera two metres, change from daylight to fluorescent, put a new pallet wrapping in service, and accuracy drops without an error message anywhere. This is the failure that catches teams. The system does not break loudly. It degrades, and the numbers keep flowing into the dashboard. Control for it: fix and document camera positions, control lighting deliberately rather than relying on the room, put a known reference object in the frame so drift is detectable, and audit against manual counts on a schedule forever. Not for a launch period. Forever. Choosing tooling that permits this kind of monitoring is discussed in [Choosing the Right AI Automation Tools for Your Business](/blog/choosing-the-right-ai-automation-tools-for-your-business).
Section 4
Decide which error you can afford
Every vision system trades one error against the other, and the tuning point is a business decision that gets left to engineers by default. On a production line, a missed defect reaches a customer while a false alarm costs an inspection. If the defect is safety-related, tune hard toward false alarms and staff for them. On a retail shelf-monitoring system, the balance is reversed: a false alarm sends someone on a pointless walk, and the cost of a missed empty shelf is one lost sale. Write down the cost of each error type in money or risk before the pilot. Then set the threshold to match, and revisit it once you have real volumes rather than pilot volumes.
Section 5
Cameras pointed at people are a different category
The moment a camera can identify individuals, this stops being an operations project. Employee monitoring, facial recognition, and behaviour analysis carry legal duties in most jurisdictions and carry trust consequences everywhere. The defensible pattern is narrow and boring. Capture only what the task requires. Prefer systems that process on site and store a count rather than a face. Set short retention periods and enforce them. Tell staff before deployment, in specific terms about what is captured and what it is used for, and never let a system installed for safety quietly become a productivity monitor. A leader who cannot explain the deployment to the people in frame, in plain language, does not yet have a deployment they can defend. That kind of plain explanation is the skill examined in [Lessons from Great Storytellers in Business History](/blog/lessons-from-great-storytellers-in-business-history).
Section 6
Prove it against the clipboard
The right benchmark is not perfection. It is the process you have now, which is a person, intermittently, with a known error rate nobody has measured. So measure it. Run manual counts alongside the system for a defined period and compare. Track false positives and false negatives separately, because a single accuracy figure hides the trade-off that matters. Track uptime, since a camera offline for a shift is a gap in the record. Track how often a human overrode the system and who was right. Then convert to operations: labour hours released, faster detection of a fault, reduced waste, fewer disputes with suppliers over counts. If the only benefit anyone can name is that the data is now digital, the project has not yet found its business case.