How to evaluate AI vision vendors without proprietary lock-in: the two questions every checklist misses
Ten thousand US dollars. That is the entry price for HyperQ AI Vision software, with the hardware sold separately at 420 US dollars per industrial 12-megapixel rolling-shutter camera or 1,200 dollars for the global-shutter equivalent. Twenty-five thousand and up is the typical entry price for an integrated hardware-and-software bundle from the largest hardware-locked vision incumbents. The headline-price gap is real. The decision-cost gap is much larger than that, and most vendor evaluation checklists never get to where it lives.
Every vendor comparison guide for industrial AI vision asks the same questions. Detection accuracy on a benchmark. Inspection speed at line speed. Defect categories supported out of the box. Camera resolution. Software user interface. Those questions are real. They are also the commoditised layer of the evaluation — the questions every vendor has rehearsed and every checklist already covers. The questions that decide whether the deployment ages well over five years are not on the spec sheet, and they are the two questions this post is about.
The first is hardware compatibility. The second is training-data ownership. Each of them, when answered honestly by the vendor, predicts the deployment cost trajectory more reliably than any number on the spec sheet.
Question one: does this system work with the cameras you already own
The architectural distinction between a hardware-agnostic vision system and a hardware-locked vision platform is the single most consequential evaluation question, and the one most vendor sales conversations route around. The hardware-locked vendors sell cameras, lighting, and software as a single bundle. The price the buyer sees on the proposal is the bundle. The price the buyer does not see is the migration cost when the bundle ages out, the upgrade cost when the vendor releases the next generation, and the integration cost when the line needs to handle a product the original bundle was not specified for.
A hardware-agnostic vision system runs on the cameras the buyer already has, or on industrial cameras the buyer can source from any vendor at commodity prices. The inference is the intelligence. The hardware is interchangeable. The buyer who deploys 12-megapixel rolling-shutter cameras today can swap them for a 20-megapixel generation in 2030 without re-licensing the software, without re-training the model from scratch, and without scheduling a vendor-led migration.
The buyer-side discipline is concrete. Ask the vendor for the exact camera models the system supports. If the answer is "the cameras we sell," the system is hardware-locked. If the answer is a list of industrial camera manufacturers and a specification range the system runs against, the system is hardware-agnostic. The Auto Parts customer (Client A) operates 8,000 product variants on industrial cameras at the lower price tier across six lines at 11,520 units per day per line — the architecture works at scale, and the hardware-cost line in their P&L is the cost of standard industrial cameras, not the cost of a proprietary ecosystem.
The economics of the answer compound over the deployment lifecycle. A line running 30 to 50 percent lower hardware footprint against an equivalent hardware-locked deployment over a five-to-ten-year horizon is the difference between a CFO-defensible inspection programme and a renewing capital line item the operations team has to fight for every budget cycle.
Question two: do you own the training data, or does the vendor
The training-data question is the second-largest hidden cost in the category, and it is the question vendors prefer to discuss in abstract terms. The concrete framing is: when a new defect type appears on your line, who labels the examples, who retrains the model, who deploys the update, and who owns the artefact at the end of the process.
The vendor-controlled retraining cycle puts the labelling on the customer's side, the model retraining on the vendor's side, the deployment timeline on the vendor's quarterly schedule, and the artefact in the vendor's cloud. The customer-side cost looks small at the moment of contract — a labelling fee per image, a retraining cycle every month or two. The cumulative cost over the deployment's life is large, and the operational cost of waiting for the vendor's next cycle to address a new defect class on the line is larger still. The dashboard-without-action-loop failure mode we covered in the post on predictive quality and how AI vision detects process drift before it becomes defects lives at this boundary.
The customer-owned retraining workflow is structurally different. The labelling tool runs on the operator's review screen. The retraining executes on the customer's edge infrastructure or on-premise compute. The model versioning is auditable with rollback available in minutes. The artefact lives where the customer's data lives. The vendor relationship is the platform and the model architecture; the data is the customer's, and the retraining cadence is the cadence of the line's actual events rather than the vendor's calendar.
The Display Panel customer (Client C) operates this pattern at the limit case — one to two missed defects per year on a mature line, with the customer's QA team capturing each new defect type, labelling it on the line, and retraining the model without raising a vendor ticket. The customer owns the data. The cycle from new defect to deployed-model fix is measured in days when the team is engaged, not weeks waiting for a vendor's queue. We covered the continuous-learning architecture in detail in the post on AI vision continuous learning and edge model retraining.
The buyer-side question is direct. Ask the vendor whose name is on the training-data artefact at the end of the contract. If the answer is the vendor's, the buyer has signed up for a recurring dependency that scales with the line's defect-class variety. If the answer is the customer's, the buyer has retained the asset that compounds in value as the line generates more training data.
What the checklist actually looks like
The two questions above are the load-bearing questions. The rest of the evaluation is the routine technical-and-commercial diligence the buyer would run on any industrial capital decision. The full checklist runs through the following items.
Camera and optics compatibility. The exact industrial camera models the system supports. The lens specifications the inference is calibrated against. The lighting accessories the model has been trained with. The cost line for sourcing each item independently rather than as part of the vendor's bundle.
Detection accuracy on the customer's own data. A confusion matrix per defect class, measured against the customer's labelled samples, not against a vendor benchmark. False-positive rate at the operating threshold the line will run. False-negative rate against the customer's escape-cost-weighted defect distribution.
Inference latency at sustained load. The ninety-ninth percentile latency under sustained eight-hour continuous operation, on the actual hardware that would deploy at the customer's line speed, with the actual model size and image resolution the inspection requires. The thermal-throttling failure mode we covered in the post on edge inference for manufacturing AI lives in the gap between cold-benchmark and sustained-state numbers.
Integration architecture. The protocol stack the system uses to talk to the line's PLC (Modbus TCP, EtherNet/IP, Profinet). The integration pattern to the customer's MES or ERP. The data-sovereignty position — on-premise, edge, air-gappable, with cloud sync optional. The audit-trail format the system produces per inspection event.
Deployment timeline and on-site commitment. Hours-to-deploy on existing camera infrastructure. Weeks-to-go-live from contract to production. Days-on-site for installation and commissioning. The customer-side resources required during deployment and the vendor-side resources retained after handover.
Retraining workflow ownership. Who labels new examples. Who retrains the model. Who validates against held-out data. Who deploys the update. Where the model artefact lives. The cycle time from new defect type observed to deployed-model fix.
Total cost of ownership at year five. The software-licence base case. The hardware-cost line, sourced commodity versus sourced from the vendor's catalogue. The retraining-cycle cost. The integration-and-maintenance cost. The migration cost at end of deployment lifecycle.
The two answers that decide the deployment
If the vendor's answer to the hardware question is "the cameras we sell" and the answer to the training-data question is "we retrain on a quarterly cycle," the buyer has a structurally locked deployment whose costs compound. The headline price on the proposal is the smallest cost line. The deployment is defensible only if the buyer accepts the lock-in as the price of the integration.
If the vendor's answer to the hardware question is a list of supported industrial cameras and the answer to the training-data question is "the customer's team owns the labelled data and the retraining cadence," the buyer has a deployment whose costs compress over time. The integration responsibility sits with the buyer's team. The capability compounds with the line's data. The vendor relationship is the platform and the model, not a renewable dependency.
The architectural argument behind this is the same one we covered in the post on what the world's two largest machine vision companies could not solve on high-mix lines. The hardware-locked vision incumbents are excellent on the inspection problems their bundles were built for. On lines where the product mix scales beyond the configuration overhead the incumbents can absorb, the architecture is the constraint, not the price.
What you can verify before any commitment
The checklist above is answerable in advance. Send the inventory of the camera infrastructure currently on the line, a representative sample of labelled inspection data spanning the actual defect distribution, and the PLC and MES integration map. Within two weeks, we run the inference against your data on our infrastructure and return four artefacts. A confusion matrix per defect class on your sample, with false-positive and false-negative rates measured against your labels. A hardware-compatibility report listing the cameras already on your line that the system runs against without modification. The minimum image count required to retrain on a new product variant on your specific defect distribution. A written assessment of the retraining-workflow ownership boundary your QA team would adopt.
Deployment timeline runs four to eight weeks from contract signing to live operation, with two days on-site for installation and PLC integration. Hardware footprint runs 30 to 50 percent lower than hardware-locked vision ecosystems. The retraining workflow is owned by the customer's QA team after handover, with the platform supplying the labelling tools and the model versioning.
Two questions decide the deployment. Hardware compatibility decides whether the cost line compounds or compresses over the deployment's life. Training-data ownership decides whether the capability compounds with the customer's data or stays dependent on the vendor's cycle. Run the checklist on those two questions first. The rest of the evaluation falls out cleanly when both answers are clean.