Why Computer Vision Solutions Fail in Production (and How to Choose One That Works)

Short answer: Computer vision solutions usually fail in production because real site conditions differ from the conditions they were tested in (camera angle, lighting, distance, equipment), and because nobody planned how to monitor and maintain them. The fix is to judge fit before you buy, test on your own footage against targets agreed in advance, and choose a provider that is open about limits.

This guide is for CTOs, CIOs, IT directors, security directors and operations leaders in the United States (with notes for Saudi Arabia and Oman) who have a specific problem and existing video. It skips neural-network theory and covers what decides whether a project works.

What is computer vision?

Computer vision is a field of artificial intelligence that enables computers to interpret images and video, so they can recognize objects, people, text and events and act on what they see. Modern systems rely mostly on machine learning, and in particular deep learning, although classical image-processing methods are still used for simpler tasks.

A computer sees an image as a grid of numbers (pixel values). Computer vision turns those numbers into something useful: a label (“helmet”), a location (a box around it) or an event (“person entered a restricted zone”). Inputs can be photos, video files, live streams from CCTV and IP cameras, and sometimes depth or thermal sensors.

Computer vision is the technology. A computer vision solution, covered below, is the complete system built around it: cameras, compute, models, rules, alerts and maintenance.

How does computer vision work?

A computer vision model learns patterns from many labeled examples, then applies those patterns to new images and video frames.

• Collect data: images or video that represent the real scene, including hard cases such as night, rain and crowding.
• Label the data: people mark what is in each image, for example by drawing boxes around helmets.
• Train a model: a neural network, typically a convolutional neural network (CNN) or a vision transformer, adjusts its parameters until its predictions match the labels. In a CNN, early layers tend to learn simple features such as edges and textures, and later layers combine them into shapes and objects.
• Validate and test: the model is evaluated on images it did not train on. Held-out test data is what shows how well it is likely to perform.
• Deploy (inference): the trained model runs on new frames, on a server, in the cloud or on an edge device at the site.
• Monitor and retrain: performance is checked over time, and the model is updated as conditions change.

Training and inference are different. Training happens once or periodically and needs substantial compute. Inference runs on every frame the system analyzes, which is why real-time systems depend on model speed and hardware.

Computer vision tasks

Real-time and video tasks

Computer vision tools and frameworks

Tools and models are building blocks. They do not on their own detect a missing helmet, alert a supervisor and keep working after the pilot ends. That is what a complete solution adds.

What are computer vision solutions?

A computer vision solution is a complete system that turns camera video into decisions: cameras capture a scene, AI models detect objects or events, rules decide which detections matter, and a person or system acts on the alert. The model is only one component.

Vendors use “model,” “software,” “platform” and “solution” interchangeably. They are different things, and the difference matters when you compare quotes.

Machine vision usually means controlled industrial imaging, such as fixed lighting on a production line. Construction sites, yards, ports and entrances have variable conditions, which is where general computer vision is typically used.

Is computer vision the right fit for your problem?

Computer vision fits when the event is visible on camera, happens often enough to measure, and triggers a response someone is ready to carry out. It is a poor fit when a person could not reliably see the event in the footage, or when a simpler sensor does the job.

Typical use cases include PPE detection, restricted-zone alerts, fire and smoke detection, intrusion and weapon detection, vehicle and pedestrian monitoring, crowd density, road-condition assessment, and defect and quality inspection. In site security, it usually works as a layer on top of existing cameras rather than a replacement for them.

RootBlock Labs’ industry pages cover manufacturing, energy, logistics, warehousing, construction, mining and stadiums.

A five-question fit test

• Is the event visible? If a person cannot reliably see it in the footage, a model will struggle too.
• How often does it happen? Very rare events are hard to validate.
• What does a miss cost, and what does a false alarm cost? This sets your thresholds.
• Do cameras already cover the area from a useful angle?
• Who responds to an alert, and what will they do?

Weak answers to questions 1 and 5 are the most common reasons projects stall.

When computer vision is not the right tool

• The event is not visible, even to a person.
• A simpler tool does the job: smoke detectors, access control, weight sensors or RFID.
• Nobody will act on the alerts.
• Camera conditions cannot be improved and are too poor.
• The event is extremely rare, a false alarm is very costly, and no human can verify.
• The expectation is “zero errors.”

A provider that never tells you when computer vision is the wrong answer deserves extra questions.

What it can and cannot do for human operators

Computer vision can augment people who monitor video. It analyzes streams continuously and directs attention to relevant events, so operators are not asked to watch dozens of mostly empty scenes. It does not make skilled operators unnecessary. In a peer-reviewed study of 73 CCTV operators and novices watching a 90-minute video, Donald, Donald and Thatcher (2015) found that about half of the target behaviours were detected and false alarms were high. Vigilance decrements appeared in novices and generalists, while specialists maintained their performance. The study measured human operators, not AI systems, but it supports directing human attention to the events that matter.

How does a computer vision solution work?

A solution runs video through a chain of stages, and the AI model is only one of them.

• Capture: cameras produce a video stream.
• Preprocessing: frames are decoded, resized and selected for analysis.
• Inference: a model outputs detections such as “person,” “helmet” or “smoke,” each with a confidence score and location.
• Tracking: detections are linked across frames so one person stays one person.
• Event logic: rules decide when a detection becomes an event.
• Alert and action: a notification, alarm, ticket or message to another system, handled by a person or an automated workflow.
• Monitoring and improvement: performance is tracked, failures are reviewed, and models and settings are updated.

The chain that matters is detection → rule → event → alert → human or system action. Without the rule layer you get constant false alarms or missed events. Without a named responder, a correct alert changes nothing.

Generic example: a PPE use case detects people and helmets. The event logic requires the person to be inside a defined zone, to lack a helmet for a set number of seconds, and to be clearly visible before an alert is sent. The alert goes to a named supervisor who confirms and acts.

Can computer vision work with your existing CCTV cameras?

Often yes, but not automatically. Having CCTV does not mean your footage suits every use case. Many analytics can be added without replacing cameras, provided the footage holds enough usable detail for your specific event.

What you can usually reuse:

• IP cameras that provide a network stream. Many support RTSP for streaming and ONVIF for interoperability, but support varies by model and firmware, so verify camera by camera. ONVIF Profiles S and T cover video streaming, and Profile M covers metadata and events for analytics.
• Your existing video management system (VMS), if it can share streams or receive events.
• Existing cabling, subject to bandwidth checks. Older analog cameras may need encoders or replacement.

Pixels on target, explained. Pixel density is the camera’s horizontal resolution divided by the width of the scene it covers at a given distance (JVSG). A 4K camera (3,840 pixels wide) covering a scene 120 m wide at the far fence delivers 3,840 ÷ 120 = 32 px/m there, even though the same camera gives far higher density up close.

What the standard says, and what it does not. The widely used DORI levels come from the 2014 edition of IEC 62676-4, also published as EN 62676-4. They define pixel density for human viewing tasks: detection at 25 px/m, observation at about 63 px/m, recognition at 125 px/m and identification at 250 px/m, as reproduced in manufacturer data sheets such as Bosch’s and Dallmeier’s. IEC published a revised second edition in October 2025, so check which edition a specification or tender cites. These figures are camera and viewing guidance. They are not AI model performance claims and do not guarantee that a model will detect or classify anything at those densities. Only testing clips from your own cameras answers that.

Which stream does the analytics use? Many cameras offer a high-quality main stream and a lower-quality substream. Analytics is sometimes run on the substream to save bandwidth and compute, which can make results worse than the headline specification suggests. Always ask which stream, at what resolution and frame rate, goes to the analytics.

What software can and cannot fix. Software can help with exposure handling, noise reduction, training on footage like yours and threshold tuning. It cannot recover information the camera never captured, and super-resolution can invent plausible-looking detail that was never in the scene. Night motion blur is usually fixed with better lighting or camera settings, and occlusion with better placement or extra angles. Rule of thumb: if a human reviewer struggles to identify the event in your clips, the model probably will too.

A camera audit you can run this week

• List the cameras covering the target area with model, resolution, angle, height and distance.
• Note whether each is IP/networked or analog/DVR-based.
• Check power and network access near the cameras and any hardware that would sit beside them.
• Export day, night and bad-weather clips, including moments when the event occurred.
• Check which stream analytics would receive.
• Mark obstructions, glare sources and dark spots.
• Share the clips with any provider you are evaluating and ask what they can and cannot detect, and why.

Not sure your cameras are good enough? Tell RootBlock Labs about your site and it will start with a site assessment of what your existing cameras can support. Request a site assessment.

What determines computer vision accuracy?

Accuracy depends on the dataset, the conditions, the metric and the confidence threshold. A claim such as “95% accurate” means little unless all four are stated.

• Precision: of the alerts raised, how many were correct?
• Recall: of the real events, how many did the system catch?
• Confidence threshold: the score above which a detection becomes an alert. Raising it reduces false alarms but increases misses.

Precision and recall pull against each other, so there is no single best setting, only the right trade-off for your risk. A false positive wastes time and trains operators to ignore alerts. A false negative is a missed safety, security or quality event. Across many cameras running around the clock, even a small false-positive rate adds up, especially when real events are rare. For high-severity events you may accept more false alarms if a person verifies before acting.

How to test on your own footage:

• Use test data the model never trained on, ideally from different days and cameras.
• Include hard cases: night, dust, rain, crowds, partial occlusion.
• Agree what counts as correct, and your acceptance targets, before testing.
• Report precision and recall by condition, not as one blended number.
• Split train and test data by camera, day or site, not by random frame, or near-identical frames leak across the split and results are inflated.

Why do computer vision systems fail in production?

Most failures come from the gap between tested and real conditions, combined with no plan to monitor and maintain the system.

Throughput versus latency. Throughput is how many frames or streams a system processes per second (FPS). Latency is how long one event takes to travel from capture to alert. A system can have high throughput and still deliver late alerts, for example if it batches frames. Check how many streams each device handles at your resolution and frame rate, what happens when load rises, and the end-to-end delay from event to alert, not just model speed.

A model-only speed benchmark can hide the gap between model speed and system performance. The case study below reports 100+ FPS for a detection model on an edge accelerator and states plainly what that does and does not establish.

Production-readiness checklist: accuracy measured on your footage by condition; acceptance targets agreed in advance; end-to-end latency measured; capacity tested at full load; named alert responder and workflow; false-alarm handling process; monitoring and retraining plan; camera health monitoring; security controls in place.

Edge AI, cloud or hybrid: where should processing happen?

Edge suits time-critical alerts, limited bandwidth and remote sites. Cloud suits central analytics and variable load. Hybrid suits many multi-site operations. There is no universally best architecture.

Edge processing does not by itself make a system legally compliant or guarantee data residency. It changes data flows, but compliance depends on what is stored, who can access it, and what leaves the site, including alerts, snapshots and logs. When sizing hardware, work from requirements: number of cameras, resolution, frame rate, model complexity and latency, then ask how many streams each device supports at those settings. For outdoor or industrial sites, check rated operating temperature, dust and vibration tolerance. For a deeper look at running inference on site, see Edge AI.

Case study: YOLOv8n on the Blaize X1600 GSP, and what a speed benchmark does and does not show

RootBlock Labs reports that its engineers evaluated and worked on deploying the YOLOv8n object detection model on the Blaize X1600 GSP edge AI accelerator, with a reported benchmark of 100+ frames per second (FPS) at a 416 × 244 pixel input. This is an internal technical benchmark, not a customer deployment. No independent public benchmark of this exact combination was located when this article was reviewed, so the figure should be read as RootBlock Labs-reported.

Public context for the model. Ultralytics publishes YOLOv8n at a 640-pixel input with 37.3 mAP (50-95) on the COCO validation set, 3.2 million parameters and 8.7 billion FLOPs. At 416 × 244 the input has about 101,500 pixels, roughly a quarter of the 409,600 in a 640 × 640 frame, so the public mAP figure does not describe accuracy at this input size. Ultralytics has also released newer models since YOLOv8, including YOLO26 in January 2026.

What the number covers, and what it does not. It is a reported inference result. The information available does not document whether the measurement included video decoding, preprocessing, post-processing, data transfer or the full video pipeline, and it includes no accuracy, latency, power or cost figures. The gap matters because a model-only speed result is not the same as a working system.

What to take from it:

• A compact detection model can reach high inference throughput on an edge accelerator at a small input size. That is a useful early filter when comparing hardware.
• It is not a procurement decision on its own. The next questions are what the figure measures, what accuracy comes with it, and how many streams the full pipeline can sustain.
• Ask any provider, including RootBlock Labs, to document the same things for any speed claim: what was timed, over how long, per stream or combined, at what batch size and numeric precision, and with what accuracy.

Pretrained, fine-tuned or custom models?

A pretrained model can be enough for common objects in clean footage. Fine-tuning is often the practical middle path for CCTV. Custom development is justified mainly for unusual targets or strict requirements.

General models are often trained on images that look different from CCTV. Surveillance footage tends to be lower resolution, compressed, more distant and shot from elevated angles. Good fine-tuning needs representative footage across cameras, times of day and seasons, consistent labeling rules, hard cases (blur, occlusion, lookalikes), a held-out test set from cameras or days the model never saw, and a plan for updates. Be cautious with “no training needed” claims. They may be true for easy conditions and false for yours. Also check model licensing: some popular open-source models carry licenses with obligations for commercial products.

When does custom computer vision development make sense?

Custom development makes sense when your target is unusual (a specific part, piece of equipment or condition that general models do not recognize), your accuracy requirements are strict, or your site differs enough from public training data that fine-tuning alone does not close the gap. For common objects such as people, vehicles, helmets and vests, a fine-tuned model is often enough. A development engagement should include data collection and labeling, a held-out test set, edge deployment, integration with your VMS and alerting, and a maintenance plan. RootBlock Labs’ edge work includes model conversion and inference optimization for accelerator hardware, as in the case study above.

How does computer vision integrate with your existing systems?

A detection only helps when it leads to a decision and an action. Define each link: who decides, based on what information, and what they do next.

A solution that forces operators onto a second screen often goes unused, so check where alerts will actually appear.

Securing the system itself

Cameras, edge devices, streams and APIs are part of your attack surface. Basic controls: change default credentials, keep camera and device firmware updated, place video devices on separate network segments, encrypt streams and management connections where supported, restrict and log access to video, alerts and configuration, monitor device health, and assign someone to own camera and device security. Independent security testing of edge devices and networks is worth considering as part of any deployment. See Cybersecurity.

What should US buyers check on privacy, biometrics and hardware?

Treat event detection and individual identification as two different risk categories. PPE, restricted-zone, fire and smoke, vehicle and crowd-density detection do not inherently require identifying individuals. Facial recognition and other biometric identification are regulated more strictly in several jurisdictions. Whether a given system collects a biometric identifier depends on what it computes and stores, which is a question for counsel. Requirements vary by state, sector, data type and use case. This section is general information, not legal advice.

• Illinois (BIPA, 740 ILCS 14). Covers retina or iris scans, fingerprints, voiceprints and scans of hand or face geometry, and excludes photographs. It requires written notice and a written release before collection, a written retention schedule, and destruction when the purpose is met or within three years of the person’s last interaction, whichever is first. It is the one of these three laws with a private right of action, with liquidated damages of $1,000 (negligent) or $5,000 (intentional or reckless) per violation. A 2024 amendment limits repeated collection from the same person by the same method to one recovery and allows electronic signatures. On April 1, 2026, the Seventh Circuit held in Clay v. Union Pacific that the amendment applies to cases pending when it was enacted. Liability for non-compliance remains.
• Texas (CUBI, Bus. & Com. Code § 503.001). Requires notice and consent before capturing a biometric identifier for a commercial purpose, limits disclosure, and requires destruction within a reasonable time, no later than one year after the purpose expires. Only the Attorney General can enforce it, with civil penalties of up to $25,000 per violation. Amendments effective January 1, 2026 (HB 149) add exceptions for AI training and for AI developed or deployed to detect or respond to security incidents, fraud and other illegal activity, with the training exception not applying where a system is used to uniquely identify a specific individual (statute). Texas has settled CUBI claims with Meta for $1.4 billion (2024) and Google for $1.375 billion (2025), both involving consumer face and voice features rather than CCTV analytics.
• Washington. RCW 19.375 applies when a biometric identifier is enrolled in a database for a commercial purpose. It requires notice, consent, or a mechanism to prevent later commercial use, has a carve-out for security purposes, and is enforced solely by the Attorney General. The separate My Health My Data Act can also reach biometric data collected as consumer health data and allows private actions through the Consumer Protection Act. A July 2026 review found no comprehensive Washington consumer privacy act in force.
• Other states. Biometric and privacy rules also appear in other state laws. There is no single federal law governing video analytics.
• Camera hardware sourcing (NDAA Section 889). Section 889 of the FY2019 NDAA is implemented in FAR 52.204-25 and the offeror representation at 52.204-24. Part A bars executive agencies, since August 13, 2019, from procuring equipment, systems or services that use “covered telecommunications equipment or services” as a substantial or essential component or as critical technology, and bars contractors from providing them. Part B bars agencies, since August 13, 2020, from contracting with entities that use such equipment. For video surveillance, the covered definition names Hytera, Hikvision and Dahua equipment (and subsidiaries and affiliates) only for public safety, security of Government facilities, physical security surveillance of critical infrastructure and other national security purposes. The clause includes exceptions (such as backhaul or roaming services) and refers to waivers. It does not mean every such camera is unlawful in every setting. Agency “Revolutionary FAR Overhaul” class deviations are relocating this text into FAR Part 40, so check which version your contract uses. If you sell to federal customers, review your camera brands with procurement counsel.
• Retention, access and signage. Decide how long footage and event data are kept, who can see them, and how people are notified, from day one.
• Document purpose. Write down why each camera and analytic exists.
• Check the whole data flow, including snapshots, logs, backups and support access, not only the video stream.

Saudi Arabia

Saudi Arabia’s Personal Data Protection Law (Royal Decree M/19 of 2021, amended by M/148 on March 27, 2023) took effect on September 14, 2023, with a one-year grace period that ended September 14, 2024 (Clyde & Co). SDAIA is the regulator. The law’s definition of personal data expressly includes still or moving pictures of an individual, and sensitive personal data includes biometric data. Transfers outside the Kingdom require an adequacy basis or appropriate safeguards, with a risk assessment where sensitive data is transferred on a continuous or widespread basis. Law-firm reporting says SDAIA’s review committees issued 48 enforcement decisions by early 2026, with administrative fines of up to SAR 5 million. Confirm current requirements against SDAIA’s published texts with local counsel.

Oman

Oman’s Personal Data Protection Law (Royal Decree 6/2022) and its Executive Regulation (Ministerial Decision 34/2024) became fully enforceable on February 5, 2026. Royal Decree 68/2026, published September 6 and effective September 7, 2026, amended the law. It extends the law to the processing of personal data of individuals in Oman wherever the processing takes place, requires erasure once the purpose ends (with limited exceptions), and adds new processing grounds. Under the consolidated text, biometric data (defined to include the facial image) may be processed only with a Ministry permit (Article 5). The amendment adds an exception (Article 5 bis) for processing through surveillance devices and cameras used to fulfil security requirements issued by competent entities. Cross-border transfers follow the controls in the regulation (Article 23). Because that exception depends on requirements issued by competent entities, do not assume that all video analytics qualify. Confirm with local counsel.

Gulf site conditions. For Gulf deployments, also plan for heat and enclosure cooling, dust and sand on lenses, low-sun glare on east- and west-facing cameras, long distances that reduce pixels on target, night operations, and alerts in the languages your responders use, such as English and Arabic.

Build, buy or use an API?

Build if you have strong ML and engineering capacity and a core, differentiating use case. Buy from a specialist if you want production results without building a vision team. Use a cloud API for simple, common tasks.

In-house builds most often underestimate data collection and labeling, day-two operations (monitoring, retraining, camera management), integrations, edge hardware selection, and security and privacy compliance. If you are unsure, run a small proof of concept on two options and compare them on your own footage.

How do you implement a computer vision solution?

Implement in stages with exit criteria, starting with one event type on a few cameras. Some organizations bring in computer vision consulting at the start to test feasibility objectively before investing.

Involve the people who will respond to alerts from day one, and agree success measures before the pilot starts.

What does a computer vision solution cost, and where does ROI come from?

There is no reliable single price: cost depends on the whole system, not just the model, and ROI should be measured against your own baseline. Be skeptical of generic cost or ROI figures that are not tied to your numbers.

Ask any provider for a breakdown by these categories, not a single figure: cameras and installation (if coverage is inadequate); edge hardware, GPUs or servers; cloud usage; software, licensing and per-camera or per-stream fees; data collection, labeling and validation; model development; integration and deployment; maintenance, monitoring and retraining (easy to underbudget); and cybersecurity and compliance.

Build the ROI case from your baseline of incident frequency, incident cost, downtime, manual monitoring hours, inspection time, response time and compliance records, then compare it against those cost categories.

RootBlock Labs says it scopes projects after a site assessment that checks camera age, placement and resolution first, so a quote reflects your cameras and use case rather than a generic price list.

How do you choose a computer vision solution provider?

Choose a provider that will test on your footage, report accuracy with conditions, and be candid about limitations. Whether you call it a vendor, a services company or a development partner, the same questions apply, including to RootBlock Labs.

Questions to ask:

• Can you test on our footage before we commit, with agreed targets?
• What precision and recall do you report, and under what conditions?
• What camera quality do you require, and what happens when footage is poor?
• Where does inference run, and how many streams can the hardware handle at our settings?
• How do you handle false positives and missed detections?
• How do you integrate with our VMS, alarms and other systems?
• How do you secure cameras, devices, APIs and data?
• Who maintains and retrains models, and how often?
• Where is our data stored, who can access it, and how do you handle US state privacy requirements?
• What happens after deployment, and can you show relevant experience and a customer reference?

Red flags: accuracy claims with no conditions or test method; no offer to test on your footage; promises of 100% accuracy; no maintenance or drift plan; vague answers on security, data location or privacy law; reluctance to discuss limitations.

Comparing vendors? Use the ten questions above with every provider, including RootBlock Labs. Request a site assessment.

About RootBlock Labs

RootBlock Labs is an Edge AI, computer vision and cybersecurity company serving industrial and government operators in the United States, Saudi Arabia and Oman. This section describes capabilities stated on its website, not performance evidence.

• Computer vision on existing cameras, intended to add a live detection layer to already-installed cameras, including PPE detection, fire and smoke detection (stated as an addition to certified alarms, not a replacement), road safety (road-defect and traffic monitoring), crowd management and weapon detection (visible firearms and knives, with a person verifying each alert).
• On-site processing. Models run on edge hardware at the site rather than in the cloud, which the company says supports continued operation if the connection drops.
• Security testing. Its cybersecurity team offers penetration testing and AI red teaming, which the company says it also applies to the detection systems it deploys.
• Object detection, not identification. Its weapon-detection page states that the system looks for objects, not identities.
• Camera suitability first. A site assessment evaluates the existing cameras before a project is scoped.

Want to test this on your own cameras?

Tell RootBlock Labs about your site and cameras, and it will start with a site assessment of what your existing cameras can support. Request a site assessment.

Frequently Asked Questions