The problem most AI vendors ignore
Deploying a machine-learning model that predicts defects or adjusts a molding process is the easy part. Making that model survive an FDA or notified-body audit is where most "AI for manufacturing" projects quietly fall apart. A model that can't be validated, explained, and governed has no business touching a regulated process — no matter how good its accuracy looks in a notebook.
With the FDA Quality Management System Regulation (QMSR) taking effect February 2, 2026, harmonizing 21 CFR Part 820 with ISO 13485:2016, the bar for software-driven manufacturing controls is explicit. This is a practical look at how to deploy ML so it holds up.
Treat the model as a manufacturing process, not a science project
Under ISO 13485 §7.5.6, processes whose output cannot be fully verified by subsequent inspection must be validated. An ML model adjusting process parameters or flagging defects is exactly such a process. That means:
- Defined intended use. Document precisely what the model decides, its operating range, and what it must not be trusted to do.
- Acceptance criteria up front. Sensitivity, specificity, and false-negative tolerances defined before validation — not reverse-engineered from results.
- IQ/OQ/PQ thinking applied to software. Installation (environment, versions, data pipeline), operational (does it behave across the input range?), and performance (does it hold on real production data over time?).
Computer Software Assurance (CSA), not box-checking
The FDA's CSA guidance shifts effort from exhaustive documentation toward risk-based, critical-thinking assurance. For a process-control model, the highest-risk failure modes — a missed critical defect, an unsafe parameter change — get the deepest testing and the strongest controls. Low-risk features get proportionate scrutiny. This is how you keep validation rigorous without drowning the program in paper.
Explainability is a regulatory requirement, not a nicety
A black-box model that can't explain why it rejected a part or changed a setpoint is indefensible in an audit. Explainable AI (XAI) techniques — feature attribution, monotonicity constraints, surrogate decision rules — let a quality engineer and an auditor understand the model's reasoning. If you can't explain it, you can't validate it.
Govern the model over its lifecycle
Models drift. Materials change, tools wear, and a model validated in March may be subtly wrong by September. Lifecycle governance is the part teams forget:
- Versioning every model, dataset, and training run, with traceability to the validated baseline.
- Drift monitoring on live inputs and outputs, with defined thresholds that trigger review.
- Retraining controls — who can retrain, on what data, and what re-validation is required before a new version goes live.
Predetermined Change Control for models that retrain
Borrowing from the FDA's thinking on adaptive AI in devices, a Predetermined Change Control Plan defines, in advance, the envelope within which a model may update without a new submission or full re-validation: the data it may learn from, the performance bounds it must stay within, and the verification each update must pass. This is what makes a continuously-improving model compatible with a change-controlled quality system.
Risk management (ISO 14971) extended to AI failure modes
Your risk management file should treat the model as a potential source of harm: what happens on a false negative, on silent drift, on bad input data, on an out-of-distribution part? Each AI-specific failure mode needs a control and a documented residual-risk justification.
The bottom line
AI in a regulated molding plant is achievable today — but only if validation, explainability, and governance are designed in from the first line of code, not bolted on before the audit. The teams that get this right deploy models that cut scrap and downtime and pass inspection. The teams that don't end up with an impressive pilot that legal won't let them run.
