99%+ sustained defect detection across 8,000+ SKUs sounds like a finish line. It isn't. Every retrain is a change. If you're running a validated QA line, every change to the inspection model is a change to your process — and under ISO 9001, process changes require control. Most manufacturers running AI vision today have no documented procedure for that.
This post covers why unmanaged retraining is a compliance exposure, what a practical model change-control framework looks like, and how the tools Hypernology builds into HyperQ AI Vision with LOT-based data management make governance achievable without slowing your QA team down.
The gap nobody talks about
ISO 9001 requires that you identify and control changes that could affect product or service conformity. Most QA managers understand this for physical process changes: a new material supplier, a revised torque spec, a die modification. The change control procedure is documented, approved, and audited.
The same principle applies to an AI inspection model. When that model gets retrained — on new defect examples, on data from a new product variant, on corrections from a failed lot — it becomes a different model. Its outputs may shift. Its false-positive rate may change. A defect class it previously caught reliably may become less sensitive if the new training data diluted that class.
If you ship parts that passed under one version of the model and fail under the next, and you have no record of which version inspected which lot, you have a traceability problem. If an auditor asks when the model was last changed and what validation was performed before it went live, "we updated the AI" is not an acceptable answer.
One quality director at a precision-parts facility described the situation plainly: "We validated our AOI. Nobody told us the AI model inside it needed its own validation cycle." That observation is increasingly common as AI inspection moves from pilot to production.
What makes an AI vision model different from fixed inspection rules
A rule-based AOI system uses fixed thresholds and geometric templates. Change the threshold, change the rule — the delta is explicit and auditable. The change record is: "Threshold for crack width changed from 0.05 mm to 0.04 mm on [date], approved by [engineer], effective for lots from [lot number]."
An AI vision model learns from labeled examples. Its "rules" are implicit in millions of learned weights. When you add 200 new labeled images and retrain, the model's behavior changes across every defect class — not just the class those 200 images targeted. You cannot read the delta out of a config file. The only way to know what changed is to test the new model against a known reference set and compare outputs.
This is not a weakness of AI inspection. It is the nature of learned models. The response is not to avoid retraining — regular retraining is how the system sustains performance as product variants, materials, and line conditions evolve. The response is to build a change-control wrapper around the retraining cycle, just as you build change control around any other process change that affects inspection output.
The four artifacts of model version control
A production vision model should have four traceable artifacts for each version. These are not complex documents — they are structured records that answer the questions an auditor or quality engineer would ask.
Model version artifacts
| Artifact | What it records | Who owns it |
|---|---|---|
| Version identifier | Model ID, training date, dataset hash, number of training images used | Vision system / software |
| Training data manifest | Which labeled images were added, which were excluded, which defect classes are represented | QA data owner |
| Pre/post validation report | Detection rate, false-positive rate, and per-class sensitivity delta vs. prior version on reference test set | QA engineer |
| Change approval record | Approver name, effective date, effective lot number, rationale for change | QA manager / sign-off authority |
Without all four, you have a version number but not a change record. Version numbers alone are not change control.
Retraining triggers and the sign-off gate
Not every retraining event is equal. A useful framework distinguishes three retraining triggers, each with a different sign-off requirement.
Corrective retrain — triggered by a false positive or false escape event. A specific defect class failed in production. New labeled examples of that class are added. This is the highest-priority trigger and requires the fastest turnaround, but it also carries the highest risk of unintended behavior change. Requires: full validation run on reference test set before deployment.
Expansion retrain — triggered by a new product variant or SKU being added to the line. The model is extended to cover a new visual context. Lower risk of disrupting existing classes if managed carefully. Requires: validation on new SKU test set plus regression check on existing high-volume SKUs.
Periodic retrain — scheduled maintenance to incorporate accumulated labeled data and maintain robustness as line conditions drift. Lower urgency. Requires: standard validation run; can be batched with other changes.
Retraining sign-off template (minimum viable)
- Retraining trigger: [corrective / expansion / periodic]
- Date retrain initiated:
- Dataset change: [images added / images removed / classes modified]
- New model version ID:
- Validation test set: [ID and version of reference set used]
- Detection rate vs. prior version: [delta by class]
- False-positive rate vs. prior version: [delta]
- Known behavior changes: [yes / no — if yes, describe]
- Approved by: [name, title]
- Effective from lot number:
- Effective date:
- Prior version archived: [yes / no]
This template lives in your document control system, not in the vision software. The vision software provides the data to fill it; the QA team owns the record.
LOT-based audit trails: why they matter for model versioning
The most defensible posture in a customer complaint or audit scenario is: "We can tell you which model version inspected every lot, and we can show you the validation record for that version."
LOT-based defect tracking, built into the HyperQ AI Vision dashboard, creates the foundation for this traceability. Every inspection run is linked to a lot. Every defect logged is tied to a lot identifier. When you combine lot-level tracking with model version records, you can reconstruct the full inspection history for any part or batch: which version ran, when it was validated, what its performance envelope was at the time.
This matters beyond internal QA. In automotive supply chains, IATF 16949-aligned customers expect part traceability back to the production run. When AI inspection is part of the acceptance decision, the inspection record is part of the traceability chain. A lot accepted under an unvalidated model update is a gap in that chain.
At a Tier-1 automotive parts supplier running HyperQ AI Vision across multiple lines covering 8,000+ product variants, the combination of automatic line-change switching — under 2 seconds, zero manual configuration — and PLC and recipe integration means that lot changes, recipe changes, and line changes are all logged automatically. That log feeds the audit trail. Model version events are the remaining layer to add, and the data structure is already there to receive them.
Customer labeling tools: governance starts at data creation
One of the less-discussed compliance risks in AI inspection is training data provenance. If an operator is adding defect labels to images that will feed the next retrain, who decided those labels are correct? What prevents mislabeled images from corrupting the training set?
HyperQ AI Vision includes proprietary customer labeling and training tools designed for QA teams, not machine-learning engineers. The intent is to put model improvement in the hands of the people who know the defects — floor QA, not a remote data science team. But governance requires that the labeling activity itself is controlled.
Minimum controls for customer labeling:
- Labeling authority: which roles may add or modify labels (not every operator)
- Label review: a second-party check before labeled images are committed to the training set
- Disputed labels: a defined escalation path when operators disagree on a defect class
- Excluded images: a record of images reviewed and rejected from training, with reason
None of these require additional software. They require a documented procedure. The labeling tool provides the mechanism; the QA system provides the oversight.
Where the ISO 9001 framework applies
ISO 9001's change-control requirements do not name AI models. They do not need to. The standard requires that you determine the need to control changes to production and service provision, review the effects of changes, authorize the changes, and retain documented information describing results of reviews and authorizations.
The word "process" in ISO 9001 covers any activity that transforms inputs to outputs — including an inspection activity. An AI model is the mechanism by which that inspection activity produces a pass/fail judgment. Changing the model changes the mechanism. The change-control obligation follows from that.
Three questions worth testing against your current practice:
- If your current vision model were retrained today without your knowledge, would you know? (Is model versioning logged in the system, or would a software update go unrecorded?)
- If a customer dispute arose over a lot accepted three months ago, could you identify which model version inspected it?
- If an auditor asked for the validation record for your current model version, could you produce it within 24 hours?
For most facilities running AI inspection today, the honest answer to at least one of these is no. That is the gap this framework closes.
Practical rollout: four steps before next retrain
You do not need to build a full model governance program before the next retraining event. Four steps will close the most significant exposure:
Step 1: Version-stamp the current model. Record the current model version ID, the date it was deployed, and the lot number it became effective from. This is the baseline. Everything forward is traceable from this point.
Step 2: Define your retraining sign-off authority. Decide who must approve a model update before it goes live. In most facilities, this is the QA manager or QA engineer with sign-off authority — the same person who approves other process changes. Document this in your change-control procedure.
Step 3: Create a reference test set. Select 50–100 labeled images that represent your current defect classes at current production conditions. This is your regression benchmark. Every retrain must pass this set before deployment. The set itself should be version-controlled.
Step 4: Connect model events to lot records. Map your model version change events to the lot numbering system. When a new model version goes live, log the effective lot number. This creates the link between the inspection record (which references the lot) and the model record (which references the version).
None of these steps require changes to the vision system software. They are procedural additions to your existing QA documentation system. The vision system provides the raw materials; your QA system provides the governance wrapper.
Honest scope: what this framework does not solve
Model change control closes the governance gap around retraining. It does not solve every AI inspection compliance challenge.
It does not address initial model validation — the validation you perform when you first deploy AI inspection on a new product. That is a separate qualification activity, typically involving a designed study against reference parts with known defect status.
It does not address concept drift monitoring — the ongoing surveillance of model performance between retrains to detect gradual degradation before it becomes a defect escape. Lot-level false-positive rates and detection rates from the dashboard feed this monitoring, but the monitoring procedure itself is outside the scope of change control.
It does not replace your existing process failure mode analysis. AI inspection is a detection control. Change control ensures the detection control remains validated. It does not change the underlying process capability.
Knowing what the framework covers and what it does not is part of responsible implementation.
The moat is governance, not the model
Any vision system can be retrained. What makes a production deployment hold up where a pilot doesn't is whether the model stays reliable under operational conditions, across hundreds of SKUs, over months and years.
Governance is what makes that reliability sustainable. LOT-based traceability, proprietary customer labeling tools, and the data management architecture in HyperQ AI Vision are designed with this in mind. The 99%+ sustained detection rate across 8,000+ product variants is not a launch-day number — it is a production track record that depends on controlled, traceable model improvement.
The 47 production contracts Hypernology holds are not held because the underlying AI is magic. They are held because the system performs reliably in production conditions and can be improved without breaking the quality record it is part of.
If your QA system is validated and the AI model it relies on is not, the gap is procedural. Procedures are fixable.
Send us one lot's worth of inspection images from your current setup, specify the defect classes you care about, and we will return a model validation report within 2 weeks — no contract until the detection rate meets your spec against your actual production data. Start the validation here.