Every visual inspection vendor is selling AI right now. The pitches are familiar: better detection sensitivity, lower false reject rates, faster line speeds, more consistent classification. Some of these claims are true. Some are partially true. All of them are beside the point if the buyer’s quality system is not ready to qualify, validate, and maintain an AI model under cGMP.
The conversation we keep having with clients is not about which AI vendor to choose. It is about whether their change control, deviation, and validation procedures can absorb a system that learns from data, evolves with retraining, and cannot always be explained the way traditional software can. Buying AI is the easy part. Owning it is the work.
What Makes AI Different from the Software You Already Validate
Traditional software validation answers a defined question: does the code produce the documented output for the documented input? An if/then statement either fires correctly, or it does not. The validation is finite, the test cases are enumerable, and the system behaves the same way today as it did the day it was qualified.
AI validation does not work that way. The model is the output of a training process, not the product of a specification. Its behavior is statistical—not in the trivial sense that it produces probabilities, but in the substantive sense that its performance on any specific input is an empirical question, not a deductive one. Two implications follow:
- Validation must be evidence-based, not specification-based. You test the model against representative populations, not against an exhaustive list of inputs.
- Validation is not permanent. The model can drift as production conditions change, as new defect modes emerge, or as inputs shift outside the training distribution. Ongoing performance monitoring is part of the validated state.
The Quality System Gaps We See Most Often
When we audit quality systems for AI readiness, the same gaps appear repeatedly:
- Change control procedures that do not contemplate model retraining as a change event. If a vendor retrains the model on new data and pushes an update, is that a change that requires revalidation? Most procedures do not say.
- Data governance that treats training images as IT artifacts rather than as part of the validated system. Training data lineage, annotation provenance, and dataset versioning are typically absent.
- Deviation handling that has no playbook for a model that begins misclassifying a defect type. Is the AI a piece of equipment in deviation? A method in deviation? Both? Most QMS procedures cannot answer this.
- Supplier oversight that does not extract the vendor’s data on their training set, their retraining cadence, or their model performance monitoring. The vendor is treated as a black box, which means their AI is too.
What Gillson Recommends Before You Procure
Our consistent advice to clients evaluating AI for visual inspection is to do four pieces of internal work before the procurement decision:
- Define the inspection problem in measurable terms. “Better detection” is not a requirement. Detection rate of X% on critical defects with a false reject rate below Y% is. Without measurable acceptance criteria, no vendor’s performance can be evaluated honestly.
- Confirm your defect library is fit for AI use. The model will be trained, qualified, and monitored against your defect library. If the library is sparse, inconsistent, or unrepresentative, the AI will inherit those weaknesses—and the weaknesses will be harder to detect once they are baked into a model.
- Update change control to cover model lifecycle events. Retraining, dataset updates, hyperparameter changes, and infrastructure migrations all need defined classification under your change control SOP.
- Define your monitoring strategy. What metrics will you track post-deployment? At what frequency? What triggers retraining or revalidation? These answers belong in a procedure before the model is qualified, not after.
The Explainability Trade-Off
One of the harder conversations in AI for visual inspection is about explainability. More accurate models tend to be less interpretable. Less interpretable models are harder to investigate when they misclassify, harder to defend in a regulatory audit, and harder to integrate into a deviation system that expects a clear chain of cause and effect.
Our view is that explainability is not always achievable, but the trade-off should be made deliberately. If you adopt a model architecture that cannot fully explain its classifications, the offsetting controls—larger qualification sets, more frequent performance monitoring, human review of borderline cases—need to be in place before the model goes live. The right answer is not always the most accurate model. It is the most accurate model that your quality system can actually own.
Human Inspectors Are Not Going Away
AI accelerates and tightens visual inspection. It does not eliminate human inspection from the program. Human inspectors are still the baseline against which automated systems are qualified, the fallback when systems are down, and the judgment layer for genuinely novel defects that the model has never seen. Programs that scale back human inspector training and qualification on the assumption that AI is replacing them are setting up the program to fail when it most needs human judgment to be sharp.
The Bottom Line
AI is going to be part of visual inspection for the foreseeable future, and the manufacturers who adopt it well will have meaningful advantages in detection performance and operational efficiency. The manufacturers who adopt it poorly will have novel audit findings, deviations they cannot easily investigate, and validated systems that drift quietly out of compliance.
The difference is not the AI. It is the quality system around the AI. Before you select a vendor, qualify your own quality system to own what you are about to install. Everything downstream gets easier when that work is done first.
