Your AI inspection passed validation. It rewrites itself every shift.

The vendor slide deck arrived last week. "Continuously learning vision models." The pitch is clean — the system adapts to new defect modes, ingests operator feedback, improves its acceptance accuracy over time. Who wouldn't want that? Anyone who has to explain to a EASA auditor why the rejection threshold on line three shifted between Tuesday and Wednesday without an engineering change notice.

I run inspection systems under AS9100. When a vendor tells me their model "learns continuously," what I hear is: this system will change its pass-fail boundary on its own, without a signature, without a PFMEA update, without an 8D when the false-accept rate creeps up. That is not a feature. It is a regulatory liability dressed up in machine-learning terminology.

What validation locks down — and why a self-updating model voids it

Software validation under AS9100 and EN9100 exists for a specific reason. You freeze the model version. You validate against a golden sample set that represents your known defect universe. You document the decision boundary — what the model accepts, what it rejects, where the grey zone lives. Every requirement traced to a test case, every test case to a signed result. That validation package is your evidence that the system making pass-fail calls on the line is the system you intended to deploy.

The model that passed validation on day one is a known quantity. Fixed weights. A false-accept rate you can reproduce on demand. Now the vendor ships an update mechanism that adjusts those weights in production — gradually, silently, based on data the model encounters on the line. The decision boundary moves. The false-accept rate changes. But your validation package still describes the day-one model. You are running an inspection process your own quality records cannot describe.

This is not a grey area in the standard. AS9100 and IATF 16949 require that any change to a production process — including software and firmware changes — go through a structured engineering change process. PFMEA updated. Control plan revised. Customer notification where required. Re-validation where the change touches acceptance logic. A model that rewrites itself bypasses every one of those gates. Continuously. Which means you cannot even point to a moment in time when the change occurred.

Drift without a trail

Every major vision-inspection vendor is now pitching "continuously learning AI" as though that phrase should inspire confidence rather than dread. One outfit announced next-generation self-improving models last quarter. In an aerospace supply chain, that phrase means your acceptance criteria are a moving target with no engineering signature attached.

I deploy AI inspection systems. I also build multi-model orchestration platforms — MultiPS runs 63 models in parallel with consensus synthesis, and every one of those models is version-locked. When I update a model, it goes through a gate: version bump, validation run against the golden set, side-by-side comparison of before-and-after performance, documented approval. I do not let models rewrite their own acceptance logic in production. Not because I lack confidence in the technology. Because I know what a regulator asks during an audit, and "the model learned" is not an acceptable answer to "why did this part pass?"

The practical damage is traceable even when the model is not. Your rejection rate drifts. Maybe it improves — the model gets sharper at catching a certain defect mode. Maybe it regresses — the model adapts to a process variation that is itself a problem, and starts accepting parts that should fail. Either way, the threshold moved. No engineering signature. No PFMEA update. No 8D triggered when the false-accept rate climbs, because you do not even know it climbed. The model adjusted quietly. Your monitoring is calibrated to a boundary that no longer exists.

A model that improves itself in secret is a process change without a paper trail — and in aerospace, that is indistinguishable from a defect.

The deployment pattern that holds

The pattern is the same discipline you already apply to every other production change. The model that runs on the line is the model that passed validation — locked weights, no online learning, no weight updates without a gate. Every model update is a new version: tagged, stored alongside its validation package. You can pull the day-one model six months later and reproduce its results exactly. A model update goes through the same engineering change process as a tooling modification — PFMEA review, control plan update, golden-set validation, documented approval. If the change affects acceptance criteria, customer notification. You track false-accept and false-reject rates continuously, not to auto-correct the model but to detect when the process has drifted far enough to warrant a controlled update cycle.

None of this is exotic. It is software validation discipline applied to machine learning — the same discipline that contributed to a 50% reduction in EASA audit findings in one cycle at my operation. Auditors do not want innovation in your inspection logic. They want traceability. They want to see that the system making pass-fail decisions on day ninety is the system you validated on day one, or that any deviation went through a documented gate with a named approver.

A static model is not a limitation. In a regulated inspection system, determinism is the specification. The vendor who tells you their model learns on its own is telling you they have built a system that cannot be validated — only trusted. Trust is not a quality strategy. Lock the weights, version the releases, gate the updates. The day the model changes is the day you re-validate. Everything else is drift.