Life-sciences manufacturers are moving AI out of isolated trials and into production, quality and engineering workflows. The difficult part is no longer proving that a model can classify, predict or optimise something. The difficult part is keeping that model controlled when the plant changes.
Rockwell Automation’s 1 October 2026 life-sciences report puts some useful numbers around the shift: 90% of respondents said digital transformation is necessary, 58% had already deployed smart-manufacturing technology at scale or in parts of their operations, and 64% planned to expand AI and machine-learning use over the next 12 months. That is a strong signal that AI is becoming part of normal manufacturing architecture rather than a separate innovation project.
For pharmaceutical and other regulated plants, that changes the engineering work. A model may perform well in development and still be unsuitable for production if its data lineage, operating limits, change control and fallback behaviour are vague.
Validation now has to cover the model lifecycle
The European Commission’s draft GMP Annex 22 on Artificial Intelligence is particularly relevant here. It sets out expectations around intended use, acceptance criteria, training and test data, explainability, confidence, operation, performance monitoring, change control and human review. The document is still draft guidance, but its direction is technically sensible: validation cannot end when the initial model passes a test set.
A production AI system has at least four things that can change independently: the process, the sensors and data pipeline, the software around the model, and the model itself. Any of those changes can alter behaviour even when the model file has not been touched.
Consider a vision model checking a vial closure. A new camera, different lighting geometry, revised label material or small mechanical adjustment can shift the image distribution. A model used for anomaly detection on a process skid may drift because the operating recipe, cleaning cycle or raw material properties changed. In both cases, the AI has not necessarily failed. Its operating environment has changed.
This is why I would treat model monitoring as part of the validated system rather than as a dashboard added afterwards. The plant needs defined limits for when a model remains trusted, when an engineer must review it, and when the system reverts to a deterministic method or manual decision.
Good data matters more than sophisticated AI
Most industrial AI problems I see begin lower in the stack. Tags have unclear units. Equipment states are inferred differently by different systems. Historian gaps are ignored. Manual quality codes are inconsistent. Time alignment between PLC, laboratory and MES records is weak. A sophisticated model trained on that data can still produce a convincing but unreliable answer.
For regulated manufacturing, the data path should be traceable from source to decision. That includes the sensor or source record, timestamping, transformations, contextualisation, model input, model version, output and any action taken from that output.
That does not mean every AI project needs an enormous data platform. It means the critical path needs to be explicit. CANS normally approaches this from the plant floor upward: instrumentation and machine signals first, then PLC/SCADA and edge collection, then operational context, and only then analytics or AI. The same principle applies whether the application is condition monitoring, quality inspection, energy optimisation or a digital twin.
More on the underlying integration approach is available in our industrial automation and SCADA and industrial solutions pages.
Separate advisory AI from control authority
A useful design decision is to separate what the AI is allowed to know from what it is allowed to change.
For many pharmaceutical applications, the first production deployment should be advisory. The model can detect an abnormal pattern, rank likely causes, predict a quality risk or recommend a process adjustment, while an operator or engineer remains responsible for the action. This makes the validation boundary easier to define and gives the site time to collect evidence under real operating conditions.
Closed-loop AI is possible, but it should sit behind deterministic engineering constraints. The PLC, DCS, safety system and validated interlocks should continue to enforce the hard operating envelope. AI should not become a second uncontrolled control system simply because it can calculate a setpoint.
For an optimisation application, for example, the AI can search within approved limits while the existing controller retains the sequence, permissives, trips and fallback states. If communications fail, the model becomes unavailable or confidence falls below an accepted threshold, the plant should return to a known operating mode without depending on the AI to recover itself.
This layered approach is also how we describe controlled optimisation in CansNEXUS: observe first, then recommend, then permit supervised action, and only authorise closed-loop operation where the application has been engineered and validated for it.
Computer software assurance is moving in the same direction
The US FDA’s February 2026 final guidance on Computer Software Assurance applies specifically to software used in medical-device production and quality management systems, so it should not be presented as pharmaceutical GMP guidance. Even so, its risk-based engineering approach is relevant to manufacturers more broadly: assurance effort should be proportional to the function’s risk, and testing should establish confidence that the automation performs as intended.
That is a better engineering model than producing large quantities of validation paperwork with little connection to actual failure modes. For AI, the evidence should concentrate on what could affect product quality, patient safety, traceability, data integrity or release decisions.
I would want to see representative test data, defined acceptance criteria, edge cases, degraded-data tests, version control, audit records, access control and a clear procedure for model changes. If a model influences a critical decision, its monitoring should also show whether current production data still resembles the conditions under which the model was validated.
Singapore makes this especially relevant regionally
Singapore remains a major biopharmaceutical manufacturing base. Singapore EDB reports more than 60 biopharmaceutical manufacturing plants and says eight of the world’s top ten biopharmaceutical companies operate manufacturing facilities there. The sector is also adding advanced facilities that rely heavily on digital systems, automation, analytics and AI-related expertise.
For Malaysian and Singapore suppliers working into these plants, the opportunity is not only in the AI model. It is in the engineering around the model: reliable instrumentation, machine integration, validated data acquisition, OT architecture, cybersecurity, auditability, traceability and controlled interaction with the production system.
That is where industrial automation experience matters. An AI application in a regulated plant still has to coexist with PLC logic, batch records, alarms, recipes, historian records, maintenance work, quality procedures and the people who operate the process at 3 a.m.
What I would insist on before production use
- Write the intended use in engineering terms, including what the model is not allowed to decide.
- Identify the exact data sources and transformations that feed the model.
- Define acceptance criteria using plant-relevant error measures, not only generic model accuracy.
- Test abnormal, missing and out-of-range data.
- Keep deterministic limits, interlocks and safe states independent from the AI unless specifically validated otherwise.
- Record model, software and configuration versions so every production decision is attributable.
- Monitor drift and define the trigger for review, retraining or withdrawal.
- Put model changes through formal change control rather than treating retraining as routine background activity.
Machine vision is a good example. False accepts and false rejects should be related to actual quality risk, not hidden inside a single accuracy percentage. Our AI vision inspection work follows the same principle: image engineering, PLC handshaking, reject logic, traceability and model validation belong in one system design.
Continuous readiness is an engineering discipline
The phrase ‘continuous readiness’ is useful if it is taken literally. A validated AI system should remain ready to explain what version is running, what data it used, whether its performance is still acceptable, what changed, who approved the change and what happens when confidence is lost.
That is a much more practical objective than trying to prove that an AI model is permanently correct. Industrial systems change. Validation therefore has to include the mechanisms that detect and control that change.
If you are evaluating AI for quality inspection, predictive maintenance, process optimisation, manufacturing analytics or another regulated production application, send CANS an enquiry or WhatsApp CANS on +60 12-295 9602. We can review the plant architecture, data path, control boundaries and validation requirements before the AI layer is allowed to influence production.
References
- Rockwell Automation — The New Operating Model for Life Sciences Manufacturing: Moving from Compliance to Continuous Readiness, October 2026.
- US FDA — Computer Software Assurance for Production and Quality Management System Software, final guidance, February 2026.
- European Commission — EudraLex Volume 4 consultation on revised Chapter 4, Annex 11 and new Annex 22 on Artificial Intelligence.
- Singapore Economic Development Board — Biotechnology & Pharmaceuticals in Singapore.
Recent Comments