A defence contractor's legal team spent six weeks building an AI disclosure framework. Forty pages covering FAR clauses, CUI handling, export controls. Solid work. Meanwhile their control plan still listed "certified operator visual inspection" for a surface defect detection process that an AI vision system had been running for three months. Nobody told the quality system. The quality system didn't ask. I keep seeing this pattern across aerospace. The National Law Review recently published a well-constructed guide on AI compliance and disclosure for government contractors — it walks through the legal architecture cleanly. But every contractor I speak with treats AI adoption as a legal problem first and a quality problem somewhere later. If ever.

The disclosure question is the easy one

Whether you can use AI on a government contract, whether you should disclose it, what data trained the model — these are answerable questions. Frameworks exist. Emerging case law is taking shape. Your general counsel can spend a productive week and emerge with something defensible. The harder question: does your AS9100 quality management system still certify the process you are actually running. When you replace a human inspector with an AI system, you have not changed a tool. You have changed the process. Under AS9100 and EN 9100, any change to a qualified process requires re-validation. Not my interpretation — the standard. PFMEA update. Control plan revision. Capability study. First Article Inspection if the change is significant. MSA on the new measurement system. At Airbus, every AI system we deploy into a manufacturing or inspection process goes through qualification review. Not procurement sign-off. Not IT approval. Not legal clearance. Qualification review by the engineering technical authority, with validation evidence and risk assessment reviewed before that system touches a conforming product. That discipline is part of how we cut EASA audit findings by 50% in a single cycle. Not because we avoided AI. Because we treated it as a process change.

AI in a qualified process is an unqualified change

Let me be specific. A Tier 1 supplier deploys an AI vision system for composite layup defect detection. The current control plan calls for a Level 2 certified inspector per their internal procedure. The AI hits 94% detection accuracy in pilot — better than the human baseline of 89%, measured across 2,400 parts. Procurement signs off. IT installs it. Production runs. What hasn't happened: no PFMEA update reflecting new failure modes — model drift, distribution shift, lighting degradation affecting inference confidence. No revised control plan identifying AI as the inspection method. No MSA on the system's measurement uncertainty. No qualification plan, no acceptance criteria, no process re-validation. No documentation of training data lineage. The supplier's quality system, on paper, still describes a process that no longer exists.
If your quality system doesn't know the process changed, the process didn't improve — it just became unaudited.
I have sat across from auditors who find this exact gap. The conversation follows a pattern. "When was this AI system qualified?" Silence. "Show me the validation report." More silence. "Who approved the control plan revision?" At which point the supplier's quality manager realises their three-month pilot is technically an unauthorised process change on qualified aerospace hardware. The cost of that realisation — corrective action, potential nonconformance quarantine, customer escalation — dwarfs whatever savings the AI delivered.

What requalification looks like when the inspector is non-deterministic

Traditional process validation assumes repeatability. AI systems are non-deterministic in ways human inspectors are not. A human inspector doesn't silently degrade because ambient lighting shifted by 300 lux or because a supplier changed their resin formulation and the input distribution moved with it. Your requalification approach has to account for things traditional validation ignores. Drift monitoring is non-negotiable — ongoing statistical evidence that model performance hasn't degraded since qualification, not a one-time study but a control chart on detection metrics reviewed on a defined cadence. Input validation belongs in the same breath. The model was qualified on a specific data distribution; your control plan needs an explicit answer for what happens when it sees something outside that distribution, not a shrug. Then there is the failure mode analysis. PFMEA-level work. What does the model miss, and how does that compare to what a human would miss? This is not a vendor demo — it is engineering evidence that lives in your quality records. And if a human still reviews AI outputs, that is a different process than full automation. Define the boundary. Qualify it. Document it. I deploy and integrate AI systems. I don't train foundation models. The distinction matters because the qualification burden falls on the integration, not the model. Your quality system doesn't care which architecture powers the inference. It cares whether you can prove the process produces conforming product, consistently, with evidence.

Key takeaways

  • AI deployment in a qualified process is a process change under AS9100/EN 9100 — PFMEA revision, control plan update, and full re-validation before production release.
  • Legal disclosure compliance and quality system revalidation are separate workstreams. Completing one does not satisfy the other; both must be closed before the AI touches conforming product.
  • AI inspection requires drift monitoring, input distribution validation, and defined human-in-the-loop boundaries that traditional MSA was never designed to cover.
  • If your control plan still describes a human process that AI has replaced, you are running an unauthorised process change on qualified hardware. An EASA or customer audit will find it.
Your lawyers will keep asking whether you can use the AI. Your quality system asks whether you can prove the process still works — and that is the question that surfaces in an EASA audit. Not whether your disclosure framework was thorough. Not whether your data handling is defensible. Whether your validation evidence is current, your control plan matches what is running on the floor, and your engineering technical authority signed off before the first conforming part passed through a process nobody requalified. The disclosure framework buys you legal comfort. The qualification evidence keeps you on the approved supplier list.