AI in pharma: scope a pilot without bypassing the quality system

An AI tool may summarise deviations, compare reports, prepare a batch-record review or flag an unusual image. Those uses do not carry the same responsibility. On a pharmaceutical site, the starting question is straightforward: which decision will the system influence, and what happens when its answer is wrong?

That question comes before choosing a supplier, model or interface. It separates a document-based trial from a system that participates in manufacturing, quality control or product release. The required evidence, people involved and change path will not be the same.

Swissmedic notes that AI and machine-learning uses already reach medicinal-product development, manufacturing and regulatory activity. It highlights data quality, model traceability, quality control and bias. Its AI framework points to work by the EMA, ICH, IMDRF, WHO and FDA. It does not replace a site's quality system. It does underline the need to understand and document the system's actual use.

Start with the decision, not the tool

The same model can have very different consequences depending on its integration. An assistant that helps an engineer find a procedure in a controlled document copy has a limited scope when access, source material and review are controlled. The same assistant, connected to an electronic batch record and used to sort issues requiring a quality decision, enters a more sensitive workflow.

Scoping should therefore describe the intended decision in process and quality terms, rather than through the tool's trade name. A first record can fit on one page:

• the exact task the system prepares, recommends or performs;
• the decision owner and person who reviews the output;
• data read, source systems and any personal data involved;
• data or records the system may change;
• plausible errors and their operational consequences;
• the fallback route when the tool is unavailable or its answer is doubtful.

This description also helps stop a vague project. “Put AI into quality” identifies no need, test or responsibility. “Prepare a list of items to review in deviation reports, without changing records and with QA review” already creates a workable scope.

Separate assistance, recommendation and decision

Three levels should be separated from the outset.

Assistance prepares information. A system may find relevant passages in approved procedures or gather entries for a report. A qualified person retains analysis and decision-making. The trial can then assess source relevance, omissions, incorrect answers and review time.

Recommendation classifies or prioritises items for human review. Risk rises when a recommendation can cause a missed deviation, quality signal or critical datum. Sorting criteria, edge cases and the way an operator can override the tool need to remain visible.

Automated decision-making changes a state, validates a result, modifies a parameter or triggers an action without review at the time of execution. It cannot be treated as a demonstration. Its intended use, interfaces, input data and test conditions need assessment under the site quality system before production use.

This separation does not provide regulatory classification by itself. It helps the project team ask the right questions of QA, regulatory affairs, IT and process owners. It also avoids presenting a drafting function as a control function, or the reverse.

Assess the change before connecting production

Swissmedic's technical interpretation of notifications under Article 41 MPLO, version 4.0 of 23 September 2026, identifies AI or ML software used in manufacturing or supply among examples of major changes. It mentions LLMs for complaint management, adverse-drug-reaction notifications, PQRs or batch-record review, as well as machine learning applied to yield or automated visual inspection. It also identifies new AI applications in quality control. The full document needs to be read alongside the relevant licences and site context.

It would be incorrect to infer that a Swissmedic notification is required for every assistant used by a pharmaceutical business. The document describes categories and examples of major changes. The applicable assessment depends on intended use, licence scope, data, process and local procedures. That assessment belongs to the site's authorised quality and regulatory functions.

However, a project affecting a manufacturing system, batch review, quality data or a release decision should not be connected like an office tool. The impacted systems, change records, evidence and point at which QA becomes involved need to be identified. Reconstructing that traceability after a prototype wastes time and reduces the value of the testing already completed.

Build a pilot that produces useful evidence

A defensible pilot does not try to prove that “AI works”. It addresses a bounded task against agreed criteria. The best starting material is often a set of cases with known answers: anonymised records where appropriate, approved histories, common errors and cases the available sources cannot answer.

The protocol can compare tool output against verified human reference work. It records correct answers, missing sources, omissions, debatable classifications and confident responses where data is absent. It also documents access limitations, versions used and review time. A plausible answer without an usable source cannot support a GMP decision.

The output of a good pilot is more concrete than a demonstration:

• a known data flow from source to output;
• a list of test cases and outcomes;
• system limits and excluded cases;
• human-review and escalation rules;
• a fallback procedure and a decision to continue, adapt or stop.

That evidence supports later integration choices, work estimates and the preparation of any required qualification. It prevents a supplier promise from being confused with a function proven on the real process.

Keep data and access in their proper place

Available data determines pilot quality. A model cannot fix an obsolete procedure, incomplete history or conflicting document versions. Before document ingestion, the team needs to identify the source of truth, access rules, documents that can be used and material that must remain out of scope.

For an initial trial, controlled copies and read-only access reduce operational risk. GMP records must retain their system of record. AI output can be exported into a working report, but it should not silently become the new version of an instruction, batch record or quality decision.

This discipline extends the principles in our article on AI agents in industry: usefulness depends on source material, access and the checks performed by the team. In pharma, the boundary between analytical support and a GxP function must remain explicit.

Connect the trial to the system life cycle

The pilot does not replace qualification or validation work. It prepares it. Our guide to GAMP 5 in pharma automation explains that the effort depends on intended use, patient-safety risk, product quality, data integrity and the site quality system.

When integration continues, user requirements, risk assessment, architecture, interfaces, responsibilities, testing and change rules need to be connected. An updated model, new document set or changed prompt can change system behaviour. Those changes need an owner, a record and acceptance criteria appropriate to the agreed scope.

Assign an owner to every change

A pilot becomes fragile when maintenance remains implicit. A team may understand the use case at launch, then change its scope, supplier, document set or review method a few months later. Without defined responsibility, no one can tell whether current output remains comparable with the results of the first tests.

The process owner defines the operational need and consequences of an error. The system owner manages architecture, interfaces and versions. QA assesses the level of control expected by the quality system. IT and cybersecurity handle identities, access, transfer and retention of data. A supplier can explain its product and provide technical material, but it cannot decide the acceptable risk level for the site.

This allocation should appear in the project record, including for a limited first integration. It makes straightforward but decisive questions answerable: who can change the sources used by the model? Who approves a new version? Which person reviews test results? Who stops the tool when it behaves unexpectedly?

A prompt change, filtering-rule change, model update or new corpus can look minor because it does not modify a PLC. It can still change the answer presented to an operator or reviewer. The team therefore needs to decide which changes are routine configuration and which require impact assessment, testing or formal approval. The answer depends on the use case and QMS; it cannot simply be copied from another project.

Decide from the pilot

The end of a pilot should produce an explicit decision. Continuing may mean preparing an integration with requirements, architecture and a qualification plan. Adapting may mean reducing scope to a document task, completing the data or redesigning human control. Stopping can be the right conclusion when source material is insufficient, review time exceeds the expected benefit or residual risk is not acceptable.

All three outcomes have equal value when they rest on test cases and a readable assessment. They avoid keeping a tool in permanent demonstration mode, with no clear rule for production use.

Vanguard Systems can help scope the use case, map the data flow, prepare test criteria and connect the pilot with existing automation and documentation systems. Quality decisions, regulatory assessment and production approval remain with people authorised by the site. Our qualification and validation service and page on pharmaceutical automation describe this work scope.

Sources: Swissmedic, framework for AI in the medicinal-product life cycle; Swissmedic, notifications under Article 41 MPLO, V4.0.