Computer vision in business software: the use cases that pay for themselves

Where it earns its keep

Visual quality inspection is the clearest case. A camera on a line checking for defects works the same way at hour eight as at hour one, which is precisely where human inspection degrades, and the output is a decision with a direct cost attached.

Document and receipt capture from photographs is a second, feeding into the extraction pipelines covered in AI document processing. Safety compliance monitoring, inventory and shelf auditing, and damage assessment for claims round out the applications we see reach production most often.

The data reality

Model architecture is largely a solved, commoditised problem. Getting several thousand representative labelled images of your specific situation, including the rare defect you actually care about, is the project. Teams consistently underestimate this by a wide margin.

Class imbalance is the recurring difficulty: if a defect occurs in one item per thousand, a naive model achieves excellent accuracy by declaring everything fine. Deliberate collection of the rare class, augmentation, and metrics that account for imbalance are all necessary rather than optional.

Nobody has ever been blocked by the model architecture. They have been blocked by not having pictures of the thing going wrong.

Choosing the error you prefer

In inspection, a false negative lets a defect through to a customer while a false positive sends a good item for manual review. Those costs are rarely equal, and the model's threshold should be tuned to reflect which one hurts more in your business.

That decision belongs to operations, not to the data science work, and it should be revisited as volumes change. Framing it explicitly at the start prevents the common outcome where a technically accurate system is rejected because it fails in the direction the business cares about.

Where the model runs

Edge deployment on or near the camera removes network dependence and latency, which matters when a decision has to be made in the time an item passes a point on a line. It costs more in hardware and makes updates a logistics exercise.

Cloud inference is simpler to operate and update but depends on connectivity and adds round-trip time. Many production systems split the two: a small model on the edge for immediate filtering, with uncertain cases escalated to a larger model centrally. Classic vision libraries and modern models coexist happily here, and standard ML tooling still handles much of the surrounding pipeline.

Integration is most of the work

A model that identifies a defect changes nothing until the result reaches the system that stops the line, flags the batch or opens the ticket. That integration, plus the interface where a human reviews flagged items, is usually the larger half of the delivery.

Plan for drift as well. Lighting changes, cameras move, suppliers change materials, and accuracy decays quietly. Continuous sampling and periodic retraining are part of the operating cost, not a one-off, which is a point we make in AI observability.

Frequently asked questions

How many images do we need to train a model?

It depends on task difficulty and visual variability, but expect thousands including a meaningful number of the rare cases you care about. Transfer learning from pre-trained models reduces this substantially.

Can we use existing CCTV cameras?

Sometimes, though resolution, angle and lighting frequently prove inadequate for reliable inspection. A short feasibility test on real footage is much cheaper than discovering it after the project starts.

How accurate does it need to be?

Accurate enough to beat the current process at an acceptable error balance. Compare against measured human performance, which is often lower and more variable than people assume.

Have a visual check a person currently performs repeatedly? A free 30-minute consultation will assess feasibility against your actual images and constraints.