On 13 October 2026, we attended the “Deploying AI in the GxP World” webinar, organised by ISPE Poland together with ProductLife Group (PLG). Naomi Ofili and Gabrièle Piaton from PLG spoke at the event. They discussed the risk assessment, validation and safeguards needed to move from an AI pilot to a deployment whose operation can be documented and assessed during an inspection. The webinar formed part of a series linked to the AI in Pharma 2026 conference.
1. What is GxP, and how does it affect AI deployment in pharma?
GxP is an umbrella term for good practices covering areas such as medicinal product manufacturing, clinical trials and pharmacovigilance. One of the webinar’s central messages was that assessing an AI application should begin with its intended use and impact on a specific process. The same model can support tasks with very different implications for product quality, patient safety and documentation.
The speakers illustrated this through translation. Translating internal correspondence and translating product information submitted to regulatory authorities require separate assessments. The same applies to literature analysis: the requirements depend on whether the search supports market monitoring or the identification of information about medicine safety.
How the AI output is subsequently used also matters. Text, classifications or metadata may become part of regulated documentation. The assessment should therefore consider the solution’s role in the process, its impact on GxP records and the consequences of an error. The speakers recommended carrying out this analysis when developing the project’s business case, so that the validation scope, resources and costs can be identified early.
2. AI validation needs to be planned across the operational lifecycle
Validation provides documented evidence that a system is fit for its intended use. The webinar repeatedly returned to the question of how to demonstrate this suitability for AI. The speakers referred to the risk-based approach described in GAMP 5 and to guidance on artificial intelligence.
The materials cited included the ISPE GAMP Guide: Artificial Intelligence, published in 2025, which addresses AI-enabled systems in GxP areas. Another reference was the European Medicines Agency’s reflection paper on AI in the medicinal product lifecycle.
The practical questions concerned data and evaluation criteria. Do the test examples reflect real documents and products? Was the test dataset independent of the data used to tune the solution? Which results will we consider acceptable, and did we define these criteria before testing began?
The approach presented also covered limiting outputs unsupported by source material, assessing behavioural stability, monitoring performance, handling invalid inputs and detecting bias. Testing before release was combined with controls during operation and assessment of the impact of model changes.
Reference collections of test cases developed with subject matter experts, described during the presentation as golden sets, can help. Revisiting the same cases across successive versions of a solution makes it possible to check whether a change has reduced performance on tasks that matter to the organisation. We explore practical ways to support testing and quality documentation in our comparison of AI QA tools for pharma.
3. Human oversight extends beyond approving an output
Naomi Ofili distinguished between two levels of human involvement. The first is human-in-the-loop: a stage in the process at which an expert approves, edits or rejects an AI output. The second is oversight across the solution’s entire lifecycle, including monitoring, preventing uncritical acceptance of automated outputs and the ability to stop the system.
In the workflow described, the AI output underwent automated checks before being reviewed by a designated expert. Information about the sources, instructions given to the model, its version and the approval was retained. This record made it possible to reconstruct the conditions under which the output was produced and identify who approved its use.
The expert also helped define acceptance criteria and develop test cases. Their knowledge therefore informed the solution’s design and the way its quality was assessed. For a company planning a deployment, this means assigning responsibilities and allocating time for expert involvement from the outset.
4. What did the examples of literature monitoring, translation and data migration show?
The speakers illustrated these principles with three examples from projects carried out by the PLG team. Each highlighted different requirements for assessing AI outputs and their subsequent use.
4.1. Literature monitoring for pharmacovigilance
In the first example, AI supported the review of scientific publications for pharmacovigilance. The system proposed a category for each article and a rationale, both of which were reviewed by an expert. Gabrièle Piaton emphasised that a particularly challenging step was translating the specialists’ assessment method into a structured decision tree. This example showed the importance of documenting expert knowledge and classification criteria before automating a task.
4.2. Translation of regulated documentation
The second example concerned AI-assisted translation reviewed by a human against quality criteria tailored to the risk associated with the document. The process also included reconstructing the formatting to facilitate the translators’ subsequent work. Assessment of the solution therefore covered content quality, the review process and the document’s suitability for further use.
4.3. Data migration and document classification
In the third example, AI supported document classification, metadata extraction and mapping data to the target system’s structure. The speakers highlighted the difficulty of distinguishing between similar document classes and the consequences of misclassification. They stressed the need to trace data provenance, transformations and approvals, as well as to perform quantitative and qualitative verification before migrated data are put into use.
5. Hosting and costs should be considered before the pilot
A separate part of the webinar focused on solution architecture. The speakers suggested deciding before the pilot where data would be processed, what information would be recorded in logs and whether the model version could be controlled. Their criteria for selecting an environment included confidentiality, data-processing location, update arrangements, the ability to reconstruct system activity and the cost of switching suppliers.
The discussion also covered selecting models for individual tasks. Smaller, specialised models can help reduce costs if they meet the defined quality requirements. The proposed economic assessment focused on the cost of completing a task and obtaining the expected result. The speakers also highlighted the possibility of reusing components for information retrieval, testing, monitoring and output approval. We discuss the division of responsibilities between a pharmaceutical company and its supplier, along with update controls, in more detail in our article on SaaS validation in pharma and GxP requirements.
6. What helps move an AI pilot into day-to-day operation?
Towards the end of the session, the speakers highlighted collaboration between technical teams, subject matter experts and the customer around a jointly agreed backlog. They also stressed the importance of appointing a business owner responsible for adoption of the solution and measurement of its outcomes.
The experiences presented suggested a sequence of activities: defining the intended use and responsibilities, assessing risk, designing controls, building and validating the solution, and then maintaining it. Decisions about data quality, human oversight and change management affect every stage.
For companies preparing a deployment, this means resolving several questions before the pilot: what task will AI perform, who will approve its outputs, how will their quality be assessed, and what will happen if the model or data source changes? The answers help teams plan the technical work, validation requirements and ongoing maintenance.
7. How does TTMS support deployments in pharmaceutical environments?
Translating these decisions into requirements, tests and documentation requires collaboration between people who understand the business process, technology and quality assurance. At TTMS, we combine software development and maintenance for the pharmaceutical industry with TTMS Quality’s expertise in computerised system validation.
Our validation services cover validation planning, requirements specification and review, test development and execution, results assessment and reporting. We use a risk-based approach and GAMP 5 guidance. The scope of work is tailored to the system’s intended use and the requirements of the specific process.
If you are planning to use AI in a pharmaceutical process or preparing to take a pilot further, talk to our specialists about your solution’s requirements, risks and validation scope.
Can an AI pilot in pharma start with synthetic data?
Yes, synthetic data can help test an initial concept without using actual patient data or confidential documentation. However, they should reflect the structure, diversity and challenges of the intended application. Overly simple examples can give a misleading impression of the solution’s quality. It is worth including missing information, errors and ambiguous cases. The results of such a pilot are insufficient to demonstrate that the system is suitable for a real GxP process. Further assessment requires representative test data, agreed acceptance criteria and controls proportionate to risk.
What should you do when AI and an expert assess the same document differently?
The discrepancy should be reviewed according to an established procedure. The source document, AI output, solution version and the expert’s assessment and rationale should be retained. The cause may be a model error, ambiguous content or evaluation criteria that are too broad. Such cases help determine whether instructions, classification rules or tests need to change. An expert’s correction should not automatically trigger an update to a model used in a regulated process. Any change should be assessed, tested and approved, while retaining an independent dataset for quality evaluation.
How should employees be prepared to use AI in pharmaceutical processes?
Training should address the specific task, data and scope of the user’s responsibilities. Employees need to know what information they may submit to the system, how to check outputs and when to raise concerns. Exercises involving incorrect, incomplete or seemingly convincing responses are useful. They help assess whether users can verify an output rather than accept it uncritically. Instructions for handling failures or periods when the solution is unavailable are also helpful. Team preparation should include an assessment of practical skills, and training should be updated when the system or procedures change.
