If you run pharmacovigilance for a small or mid-sized marketing authorisation holder, you have almost certainly been pitched an AI tool in the last year. It might be a safety database with automated case intake, a literature screening service that promises to cut review time, a coding assistant that suggests MedDRA terms, or a generative tool that drafts narratives. The commercial case is easy to see. The regulatory case is less clear, and most of the commentary on the subject is written for large pharmaceutical companies with dedicated AI governance teams and validation departments.
This guide is written for the rest of the market. It explains what regulators and standard-setting bodies have said so far, turns the main principles into controls a small team can actually run, and gives you a vendor question list and an evidence file template. If you are searching for AI in pharmacovigilance compliance, CIOMS XIV implementation, AI case processing validation, or how to govern AI tools in a PV system, this is written for you.
What Has Been Published So Far
Several documents now shape expectations, and none of them is a rulebook for small companies. They are principles, and the work lies in applying them proportionately.
- CIOMS Working Group XIV published its final report on artificial intelligence in pharmacovigilance in December 2025. It sets out seven guiding principles: a risk-based approach, human oversight, validity and robustness, transparency, data privacy, fairness and equity, and governance and accountability
- On 14 January 2026 the FDA and EMA jointly published ten guiding principles of good AI practice in drug development, covering the medicines lifecycle including safety monitoring. They emphasise a human-centric, risk-based approach, clear context of use, data governance and multidisciplinary expertise
- Notes from a February 2026 meeting of the HMA and EMA group focused on AI indicate that guidance on AI in pharmacovigilance is planned, to be developed jointly with the Pharmacovigilance Risk Assessment Committee in a question and answer style, and that an EMA and FDA pharmacovigilance AI cluster is already active
- In the UK, the MHRA Inspectorate set out in June 2026 that responses to inspection findings must be verifiable and signed off by accountable people, whether or not AI was used. That statement is about inspection responses, but the underlying principle of human accountability applies across every GxP process
- For manufacturing, the draft EU GMP Annex 22 would be the first annex specifically about AI, with its focus on intended use, validation and human accountability
None of these documents tells you that a particular tool is acceptable. What they share is a message: the company is accountable for outputs, the level of control should match the risk, and you must be able to show your working.
The Seven CIOMS Principles in Plain Language
For a small team, it helps to translate each principle into one practical question:
- Risk-based approach: how much could patient safety or compliance suffer if this tool gets it wrong, and is our oversight proportionate to that?
- Human oversight: who looks at the output, when, and with what authority to override it?
- Validity and robustness: has the tool been shown to work on our type of data, and does it keep working when the data changes?
- Transparency: can we explain what the tool does and what it does not, well enough for someone outside the project to question a result?
- Data privacy: where does patient and reporter data go, who can see it, and is that lawful?
- Fairness and equity: could the tool perform worse for some populations, languages or product types without us noticing?
- Governance and accountability: who owns the tool, who approves changes, and who answers to an inspector?
Start with Where AI Touches Your System
Before you write a single policy, list every place AI is or could be used. For many small companies this list is longer than expected, because tools are often switched on by default or used informally by individuals. Common areas include:
- Case intake and triage, such as reading incoming emails and classifying them as adverse event reports
- Duplicate detection across sources
- MedDRA coding suggestions for events, indications and products
- Narrative drafting for individual case safety reports
- Literature screening, including title and abstract triage
- Signal detection support and trend analysis
- Drafting sections of aggregate reports, risk management plans or responses to authority queries
- Translation of source documents
Do not forget informal use. A team member pasting a case narrative into a general-purpose chatbot to tidy the wording has created a data privacy and confidentiality problem as well as a validation gap, even if the output is never submitted.
A Simple Risk Tiering Model
CIOMS makes clear that the extent of oversight should follow the risk. A three tier model works well for small companies:
- Lower risk: AI that helps with formatting, translation of non-case material or internal summaries, where the output is always checked and has no direct effect on a safety decision. Light controls: approved tool list, no patient data, user guidance
- Medium risk: AI that suggests an answer a person then confirms, such as coding suggestions or literature triage with every excluded item sampled. Moderate controls: intended use statement, documented performance check on your own data, defined reviewer, periodic monitoring
- Higher risk: AI that makes or strongly shapes a decision with regulatory or patient safety consequences, such as seriousness or causality assessment, automatic exclusion of literature, automatic submission of reports, or signal prioritisation. Strong controls: full validation against predefined acceptance criteria, ongoing performance monitoring, QPPV approval of the use case, and a person making the final decision
CIOMS also distinguishes between human-in-the-loop, where a person decides on each output, and human-on-the-loop, where the AI acts and a person monitors. For small companies the safest starting point is human-in-the-loop for anything that affects reporting or assessment.
Twelve Questions to Ask Every Vendor
Vendors will often say their tool is validated. That statement alone tells you little, because validation of the vendor’s software is not the same as proof that it works for your products, your data and your intended use. Ask:
- What exactly is the intended use, and what is explicitly out of scope?
- Is the tool rule-based, machine learning or generative, and does it use a third party model?
- What data was it trained on, and was any of it patient data?
- What performance was measured, on what dataset, with which metrics, and can we see the report?
- How does performance vary by language, source type or product type?
- How are errors detected and fed back, and how is drift monitored over time?
- When the model or its settings change, how will we be told, and can we test before it goes live?
- Where is our data processed and stored, and does any of it leave the country or the contract scope?
- Is our data used to train the vendor’s models?
- What audit rights do we have, and will you support a regulatory inspection of the tool?
- What happens to our data and audit trail if we leave?
- Which subcontractors are involved, and are they bound by the same terms?
If a vendor cannot answer these clearly, that tells you something about the level of control you can expect.
Build an Evidence File for Each Tool
Inspectors will not ask whether you have an AI policy first. They will ask you to show how a particular tool is controlled. A single evidence file per tool, held where the QPPV can reach it, should contain:
- An intended use statement and a risk tier with the reasoning
- A description of the human review step, including who does it and how they record it
- A validation or performance assessment, with acceptance criteria set in advance and results from your own data, including difficult and unusual cases
- Details of the data used for testing and how representative it was
- A monitoring plan with measures such as error rate, override rate and sampling results, plus review dates
- Change control records for model updates and configuration changes
- Training records for users, including the limitations of the tool
- The contract terms covering audit rights, data use and change notification
- Any data protection impact assessment
Link the tool to the PSMF as well. Where AI forms part of the system used for ICSR processing, the PSMF description of computerised systems and the quality system should reflect it. This matters because EU inspection guidance lists the fitness for purpose of computerised systems within the scope of routine pharmacovigilance inspections, so it is territory inspectors already expect to explore.
Watch for Automation Bias
CIOMS highlights the risk that people over-trust an automated suggestion. In a small team under time pressure this risk is real. If a coding assistant is right 95 times in 100, reviewers stop looking carefully at the other five. Practical countermeasures include:
- Randomly sampling accepted suggestions for second review
- Recording when reviewers override the tool, and reviewing those cases for patterns
- Periodically seeding known errors to check reviewers are paying attention
- Rotating reviewers and refreshing training
Mistakes We See Repeatedly
- Treating a vendor’s validation certificate as proof that the tool works for your intended use
- Allowing informal use of public chatbots with case data, with no policy and no monitoring
- Switching on AI features inside an existing safety database without a change control
- Having no performance check on your own data before go-live
- Failing to monitor for drift after launch
- Not telling the QPPV, who then cannot answer questions at inspection
- Leaving contracts silent on audit rights, model changes and data use
A 90 Day Starter Plan
- Days 1 to 15: inventory every AI use, formal and informal, and issue a short interim rule on what data may be used with which tools
- Days 16 to 40: assign risk tiers, and decide which uses to stop, which to keep and which to validate
- Days 41 to 70: build evidence files for the highest risk tools, and run performance checks on your own data
- Days 71 to 90: update the PSMF, SOPs and training, set monitoring dates, and brief the QPPV and senior management
Putting Governance Around Your AI Tools
Small companies rarely have the time to read every regulatory publication, interpret how it applies to their tools and build the controls from scratch. Quality and Vigilance Ltd helps pharmacovigilance and quality teams do this in proportion to their size, building on its work in pharmacovigilance consulting, outsourced PV services and audit and inspection support across GvP, GMP and GDP. The aim is a governance model that you can run with your current team, and that stands up when an inspector asks how a tool is controlled. The support typically includes:
- A gap review of how AI is currently used across your pharmacovigilance and quality processes, including informal use
- Risk tiering and a proportionate control framework aligned with CIOMS XIV and the FDA and EMA principles
- Vendor due diligence, including question lists, contract review and audit planning
- Evidence files and validation approaches that match the risk of each use case
- Updates to the PSMF, SOPs and training, and preparation for inspection questions on AI
Get in touch with Quality and Vigilance Ltd today to put practical, inspection-ready governance around the AI tools in your pharmacovigilance system.