The evaluation question every AI vision vendor prepares for is "what is your detection accuracy." The evaluation question that determines the five-year cost of the contract is "what cameras does this run on, and what happens when you release the next generation." One of those questions is on every RFP template. The other is almost never asked until the buyer is already locked in.
The procurement dynamic is not accidental. Detection accuracy is a number that can be presented on a spec sheet, validated in a proof-of-concept, and compared across vendors in a formal evaluation. Hardware lock-in and training-data dependency are structural properties of the vendor's business model that do not appear on spec sheets and only become visible at the moments when the buyer needs to exercise the flexibility the contract does not provide. By then, the switching costs are real and the leverage is gone.
The five questions below expose both. They are not trick questions. Any vendor with a hardware-agnostic architecture and a customer-owned training workflow can answer all five cleanly. A vendor whose architecture depends on proprietary hardware and vendor-controlled retraining will not be able to answer them without qualifying the answer in ways that reveal the lock-in.
Question 1: Can I use my existing cameras, or must I buy new hardware from you?
This is the binary version of the hardware-lock-in question. The answer divides the market cleanly.
The hardware-locked vendor's answer will be some version of "the system is optimised for our camera range" or "we recommend our bundled camera for best performance." These are true statements. They are also the tell. The system is optimised for the vendor's cameras because the inference model was trained and validated against the vendor's cameras. Changing the camera changes the image characteristics, which requires retraining — a process the vendor controls the timeline and cost of.
The hardware-agnostic answer is a list of compatible camera specifications and a statement that the inference model is trained against the customer's production-line images, whatever camera produces them. The Auto Parts customer (Client A) sources cameras at 420 US dollars for the 12-megapixel rolling-shutter model. The model was trained against images from that camera under that line's lighting conditions. Swapping to a different camera brand next year would require retraining against the new camera's image characteristics — a process the customer's QA team can initiate on their own timeline, without a vendor engagement.
Question 2: What happens to my inspection configuration when you launch a next-generation camera?
This is the forward-looking version of Question 1. Most buyers evaluate hardware compatibility at the point of deployment. The lifecycle cost of the decision runs over three to five years.
The hardware-locked vendor's next-generation camera will ship with some combination of a new lens mount, a new SDK version, a new communication protocol, and a new minimum lighting specification. Each of these is a compatibility break with the configuration the buyer validated in the proof-of-concept. The vendor's migration path is a professional services engagement — a few days to a few weeks of engineering time, depending on the line complexity, to revalidate the inspection logic against the new camera hardware.
Across a six-line facility doing a hardware refresh, the migration cost is real. The production downtime during revalidation is real. The schedule dependency on the vendor's professional services availability is real. None of these appear on the hardware-locked vendor's product comparison sheet.
The hardware-agnostic answer is that the camera upgrade path is a customer procurement decision, not a vendor-managed migration. The inspection model retrained against the new camera's images is an operation the customer's QA team controls on their own timeline.
Question 3: Can the system handle product changeovers without vendor intervention?
This is the operational question that exposes architecture limitations at the scale where most high-mix lines actually operate.
The hardware-locked vendor's system typically handles changeovers through a recipe management framework — the operator loads a new recipe, the system reconfigures for the new variant, and the line resumes. At low variant counts (under 50 or so), this is a manageable workflow. At 8,000 variants with 30-plus changeovers per shift, manual recipe loading at the changeover frequency collapses the inspection station's effective throughput. The auto-switching capability — where the PLC's product-change signal reconfigures the inspection station without operator intervention — is either absent or limited to a small variant library on most hardware-locked platforms.
The Client A deployment ran into this ceiling with two successive hardware-locked vendors before the HyperQ deployment. Both vendors evaluated the 8,000-variant requirement and assessed auto-switching at that scale as outside their architecture's capability. The HyperQ PLC bi-directional integration auto-switches the inspection configuration in the background on every PLC changeover signal, across the full 8,000-variant library, with no operator involvement. The changeover overhead dropped from 45 minutes per line to a background system operation.
The question to ask in the evaluation: "Show me what happens when the PLC sends a product-change signal to the inspection station for a variant that was introduced after the initial deployment, without a vendor reconfiguration event." The answer to that demonstration predicts the operational reality at 12-month post-deployment scale.
Question 4: How many labelled images do you require, and can I do the labelling myself?
This question exposes the training-data dependency and the ongoing retraining cost structure.
The 10,000-image requirement is the figure associated with supervised deep-learning classification at industry-standard training regimes. At 10,000 images per defect class across a high-mix product range, the labelling cost before the first model deploys runs to several thousand dollars per defect class, recurring each time a new product variant is introduced or a defect morphology evolves. On a high-mix line with frequent new product introductions, the training-data maintenance cost can exceed the software licence cost annually.
HyperQ AI Vision reaches production-grade accuracy from roughly 1,000 images per class — the order-of-magnitude reduction is patented. The labelling workflow runs on the customer's own data, using labelling tools provided as part of the deployment. The customer's QA team owns the training data and the retraining cadence. The vendor relationship is the platform and the model architecture; the data is the customer's asset.
The second part of the question — "can I do the labelling myself" — is a check on whether the vendor's retraining workflow is customer-accessible or vendor-gated. A vendor-gated retraining cycle creates a recurring dependency: each new defect type on the line requires a vendor engagement to incorporate into the model. On a line with frequent new defect types, this is a cost and schedule dependency that scales with the line's evolution.
Question 5: What does the 3-year TCO look like if I switch vendors in year 2?
This is the exit-cost question, and it is the one most buyers find uncomfortable to ask in a sales context. Ask it anyway.
The hardware-locked vendor's exit cost in year 2 includes: the full replacement cost of the proprietary hardware (cameras, controllers, lighting, and any dedicated hardware that cannot be reused), the retraining cost for the new vendor's model against the customer's defect distribution, and the revalidation cost against the customer's inspection specifications. On a six-line facility with bundled hardware at premium pricing, the hardware replacement cost alone can run to the total software cost of the alternative deployment.
The hardware-agnostic vendor's exit cost is lower because the customer already owns the cameras (commodity hardware, not vendor-proprietary), already owns the labelled training data, and already has a retraining workflow the QA team knows how to run. The switching cost is a software migration and a retraining event, not a hardware writedown and a fresh capital investment.
The TCO question does not require the buyer to plan to switch vendors. It requires the buyer to understand the switching cost before they are in a position where switching costs are material. The asymmetry in exit cost is often the most convincing argument for hardware-agnostic selection even when the buyer has no current intention to change vendors — because the hardware-agnostic option preserves optionality that the hardware-locked option forecloses.
Running the evaluation
The five questions above are the structural test. Any vendor who can answer all five cleanly — without qualifying hardware compatibility, without imposing a vendor-controlled retraining dependency, without a migration engagement at camera upgrade time, without a high exit cost at the software migration event — has a hardware-agnostic architecture. The detection accuracy comparison runs after these five questions are answered, not before. Accuracy on a defect class is table stakes. These questions determine the five-year cost structure.
We have covered the broader evaluation framework in the post on how to evaluate AI vision vendors without proprietary lock-in and the full TCO model in the post on AI vision versus manual inspection cost for APAC manufacturers.