The Regulatory Frame in 2026

The regulatory landscape for AI in pharmacovigilance in 2026 is neither hostile nor permissive. It is deliberate. Three developments in the past twelve months have moved the field from principle to practice.

On January 14, 2026, the FDA and EMA jointly released the Guiding Principles of Good AI Practice in Drug Development, ten principles that span the full product lifecycle including post-marketing safety surveillance.1 The principles are high-level rather than prescriptive, but they are consistent with, and in some cases go further than, the FDA’s January 2025 draft guidance on AI in drug and biological product regulation.2 Together they establish that the risk-based, context-of-use framework the FDA proposed for AI generally applies to pharmacovigilance specifically.

In December 2025, the Council for International Organizations of Medical Sciences published the report of Working Group XIV, Artificial Intelligence in Pharmacovigilance.3 CIOMS reports do not carry the force of regulation, but they are read carefully by regulators, and the XIV report articulates seven core principles including risk-based approach, human oversight, validity and robustness, transparency, data privacy, fairness, and governance. The report is the closest thing the industry has to a global consensus on what good PV AI practice looks like.4

Sitting alongside those is the July 2025 ISPE GAMP AI Guide, a 290-page companion to GAMP 5 Second Edition that finally gives quality and validation teams a framework specifically for AI/ML systems in GxP environments.5 GAMP 5 Second Edition (Appendix D11) opened the door in 2022. The 2025 guide walks through it.6

10 FDA-EMA joint principles for AI in drug development released Jan 14, 2026
7 CIOMS XIV core principles for AI in pharmacovigilance published Dec 2025
290 pages in the ISPE GAMP AI Guide, July 2025, used with GAMP 5 2nd Edition

Add to this the UK MHRA’s ongoing AI regulatory strategy and the MHRA AI Airlock program, which is testing how AI-enabled healthcare tools should be validated and monitored in a controlled setting.7 None of these instruments alone rewrites signal detection expectations. Together, they make it very difficult for a sponsor to argue in 2026 that expectations for AI in PV are unclear.

The frame in one sentence. AI governance in pharmacovigilance must be explainable, traceable, and inspection-ready, no different from any other GxP-regulated system, with the extent of validation and oversight sized to the risk of the AI’s output influencing a safety decision.

Beyond Disproportionality: The Method Shift

For roughly two decades, statistical signal detection in pharmacovigilance meant disproportionality analysis on spontaneous reporting databases. The core metrics, Proportional Reporting Ratio (PRR), Reporting Odds Ratio (ROR), Multi-item Gamma-Poisson-Shrinker (MGPS), and the Information Component (IC) with its shrinkage-based Bayesian credible interval, remain in daily use at FAERS, EudraVigilance, and VigiBase.8 They are simple to compute, well understood by regulators, and have detected real signals.

They also have well-documented limitations. PRR tends to overestimate disproportionality for frequently reported adverse events. ROR is highly sensitive to rare events and small sample sizes, where a handful of additional reports can inflate values enough to produce false positives. MGPS may over-shrink frequent events and mask genuine associations. The IC025 threshold does not directly translate to clinical strength. All disproportionality methods share the deeper problem that they cannot distinguish reporting bias from biological signal, and they treat each drug-event pair in isolation from covariates, indication, dose, and time.9

The response over the past five years has not been to abandon disproportionality but to layer new methods on top of it. Three additions matter most.

1. NLP for narrative extraction

Individual Case Safety Report (ICSR) narratives, clinical notes, biomedical literature, product labels, and patient-generated content all contain safety information locked in free text. Named entity recognition and relation extraction models can identify drug mentions, adverse event mentions, temporality, and causality assertions in unstructured text, feeding structured downstream analytics.10 A 2023 scoping review found named entity recognition and relation extraction were the dominant tasks in the field, with supervised deep-learning approaches producing better performance than earlier rule-based systems.11 The practical effect is that narratives, which were previously read one by one by triage staff, can be pre-classified for seriousness, listedness, and MedDRA coding candidates at a scale humans cannot match.

2. Machine learning for signal ranking

Disproportionality generates far more statistical alerts than any safety team can adjudicate. Machine learning models trained on historical signal validation outcomes can rank alerts by predicted likelihood of validation, allowing reviewers to prioritize.12 A 2022 Drug Safety article on supervised ML for signal validation classification demonstrated that ensemble models trained on historical labels can meaningfully outperform expert-only prioritization when the labels are of consistent quality. A 2024 Drug Safety article extended this to time-based prioritization of drug-drug interaction signals in FAERS.13

3. Network methods and real-world data

Signals do not respect the boundaries of a single database. Network analysis across electronic health records and administrative databases has been shown to detect drug-induced adverse events in ways that spontaneous reporting cannot.14 The International Society of Pharmacovigilance’s Real-World Evidence and Big Data Special Interest Group issued a 2025 position statement on the interplay of spontaneous reporting and longitudinal healthcare databases for signal management, arguing for integrated rather than sequential use.15

METHOD LAYER 1

Disproportionality (kept)

PRR, ROR, MGPS, IC on spontaneous reports. Regulators expect these to remain. They are well-characterized and cheap to run. The question is not whether to use them but whether to use them alone.

METHOD LAYER 2

NLP on narratives

Named entity recognition and relation extraction on ICSR narratives, literature, and EHR notes. Feeds structured signal detection and reduces triage workload if performance is documented and monitored.

METHOD LAYER 3

ML for signal ranking

Supervised models trained on historical validation outcomes rank statistical alerts by predicted likelihood of validation. Requires a labeled retrospective dataset and ongoing performance monitoring.

METHOD LAYER 4

Network + RWD

Network analysis across EHRs, claims, and administrative data. Complements spontaneous reporting, particularly for interactions and events with long latency. Requires careful confounding control.

The regulator posture in 2026 is not that traditional methods are obsolete. It is that any AI/ML method used to detect, prioritize, or characterize a signal is subject to the same standards of validation, documentation, and oversight that GxP systems have always required, adjusted for the risk that the model influences a safety decision.16

GVP Module IX and What Inspectors Actually Look For

GVP Module IX (Revision 1), the EMA’s Signal Management guideline, has not been rewritten to accommodate AI. It does not need to be. The guideline is method-agnostic. It requires marketing authorization holders to run a documented, quality-managed signal management process that is auditable and traceable, whatever methods are used underneath.17

The Module IX language that matters for AI reads roughly as follows. Signal detection should include manual review of ICSRs, statistical analyses, or a combination. Common datasets include spontaneous reporting from the MAH’s own database and from public databases such as FAERS, EudraVigilance, and VigiBase, plus active surveillance, studies, and scientific literature. Processes used should be adequately documented, and the steps taken in the management of a specific signal should be tracked and auditable.18 That last clause is where AI systems have started to lose points at inspection.

In our client work, three inspection themes recur.

Traceability of the algorithmic decision

Inspectors are asking not just what signals were detected but which alerts the algorithm suppressed, downweighted, or deprioritized, and why. If a supervised ranking model demoted an alert that would otherwise have been reviewed, the sponsor should be able to explain the model behavior on that specific case. This does not require full explainability of every neural weight. It does require case-level logging of model inputs, model version, output score, and any downstream human decision.

Human oversight sized to risk

The CIOMS XIV principle of human oversight is echoed in the FDA-EMA joint principles under “human-centric design.”19 Inspectors want to see that the humans in the loop are qualified, that their review is meaningful rather than rubber-stamp, and that oversight intensity is proportionate to the risk of the model’s output. Automated suppression of an alert that would otherwise be reviewed is a higher-risk decision than automated ranking of alerts within a workqueue.

Documented context of use

The FDA’s 2025 draft guidance introduced a formal notion of context of use, meaning a precise statement of what the model is intended to do, for whom, on what inputs, and against what performance thresholds.20 Applied to signal detection, this means the sponsor should be able to state, in a single paragraph in the validation package, what the model does, what population and data it applies to, what it does not apply to, and what performance is considered acceptable. Vague statements such as “the model supports signal detection” do not survive scrutiny.

The audit question that reveals the gap. “Show me a case where the model deprioritized an alert, and explain why that was the right decision.” If the sponsor cannot answer with case-level logs and model reasoning, the AI system is running ahead of its governance.

E2B(R3), ICSR Processing, and the AI Case Intake Question

The FDA completed implementation of ICH E2B(R3) for electronic ICSR submissions in 2024, with full industry adoption effective through 2026. EudraVigilance and other major regulators had already moved to R3.21 R3 is a data model change, not an AI change, but it matters for AI in a specific way. R3 supports richer structured data than R2, which means downstream analytics, including AI-based signal detection, can consume higher-quality inputs. It also means the errors that AI makes at intake propagate into a more prescriptive data structure and are more visible on inspection.

AI has moved from pilot into routine use at case intake in the past three years. Industry reporting cites triage times dropping from around thirty minutes per case manually to under a minute for automated triage, and follow-up cycles compressing from around forty-five days to under five.22 Case processing productivity has risen from roughly one ICSR per hour for a human reviewer to hundreds per hour for automated platforms handling the same workload. Those numbers are marketing-adjacent but directionally consistent with what we see in production.

The regulatory question is not whether these tools work. It is whether the sponsor has established that they work for its specific product safety profile, on its specific input distribution, with performance monitoring that will detect degradation.

Where E2B(R3) automation runs into trouble. Seriousness determination is a regulated medical decision. AI can extract candidate seriousness criteria from narrative text and flag them for review with confidence scores. The final determination must still be made by a qualified reviewer, with the decision recorded and traceable. Programs that let the model be the final arbiter of seriousness in production are creating regulatory risk they do not fully understand.

Duplicate detection is another area where AI has moved fast. Automated matching during E2B XML import identifies potential duplicates before they enter the processing pipeline. If the model has a false negative, a duplicate reaches the safety database and inflates counts, potentially generating a spurious disproportionality signal downstream. If it has a false positive, a legitimate case is merged with an unrelated case, and information is lost. Both failure modes have inspection consequences. The mitigation is not to stop using duplicate detection AI, it is to monitor its precision and recall against a labeled sample on an ongoing basis.23

The Six Validation Gaps We See Most Often

We work with pharma and biotech clients on GxP AI validation. The gaps below appear in different combinations in almost every PV AI validation package we review. None are exotic. All are addressable.

1

Missing or vague context of use

The validation package describes what the model does technically but does not commit to the intended use, population, input distribution, out-of-scope conditions, and acceptable performance thresholds. Without a documented context of use, there is no way to state whether the model has passed validation.

2

No independent test set

Training, tuning, and validation are done on overlapping data. The reported performance is optimistic. Regulators are now asking specifically for a held-out test set that was not touched during model development, with documented data provenance and time-based separation where signal drift is expected.

3

Performance reported without confidence intervals or subgroup breakdown

Aggregate accuracy or F1 without subgroup analysis obscures where the model fails. Subgroup analysis by product, therapeutic area, indication, reporter type, and MedDRA System Organ Class is the minimum standard. Confidence intervals should accompany all reported metrics.

4

Human oversight described in policy but not evidenced in operation

The SOP says a qualified reviewer confirms every high-risk model decision. Case-level logs show reviewers approving thousands of decisions per hour, or approving in bulk. The audit trail contradicts the policy. This is the single most common finding pattern we see.

5

No model performance monitoring in production

The model was validated at go-live. Nothing checks whether it is still performing at go-live levels three months later. Drift on input distribution, on label distribution, or on model performance is not being measured. Retraining triggers are not defined.

6

No change control for model updates

The vendor pushes a model update. The sponsor accepts it. There is no impact assessment, no revalidation, no user acceptance test on production data. This gap has been in FDA warning letters in adjacent domains and is coming to PV.

The unifying theme across these gaps is that AI validation in PV is often treated as a point-in-time exercise. Modern regulator expectations, articulated most clearly in the FDA-EMA joint principles under “life-cycle management” and in the GAMP AI Guide’s ongoing performance monitoring guidance, treat validation as a continuous process.24

Validation Deliverables Checklist for PV AI Systems

The following is the minimum set of documented deliverables we expect a PV AI validation package to contain before an inspection. It is written to be model-agnostic; the specifics of what “acceptable performance” means differ by use case, but the deliverables do not.

DeliverableWhat it demonstratesCommon failure mode
Documented context of useWhat the model is for, on what data, for what population, out-of-scope conditions, and acceptable performance thresholdsWritten as marketing language, not as an inspection-defensible commitment
Data provenance and lineageSource of training, tuning, and test data; time period; population; any labels used, who labeled them, inter-rater reliabilityData origin unclear; labels reused from other projects without validation
Independent test set reportPerformance on data untouched during model development, broken down by subgroup, with confidence intervalsData leakage between splits; no subgroup analysis; no confidence intervals
User acceptance testing on production-representative dataBusiness acceptance under realistic operating conditions, not just technical performance on curated benchmarksUAT run on synthetic data or on the same test set as the technical validation
Human oversight design and evidenceWhich human decisions are required, who is qualified to make them, what the reviewer sees, how much time they have, and evidence that the design is being followed in operationPolicy says one thing, case-level logs show another
Model performance monitoring planWhat is monitored (input drift, output drift, performance on labeled sample, human override rate), how often, thresholds, and who owns the responsePlan exists on paper; no dashboard, no alerts, no owner
Retraining and change control procedureWhat triggers retraining, who approves it, how retrained models are validated before deployment, and how vendor updates are managedRetraining ad-hoc; vendor model updates accepted without impact assessment
Case-level audit trailFor each case processed, the model version, inputs, outputs, confidence, any human decision, and any override, retrievable for inspectionAggregate logs only; individual cases cannot be reconstructed
Explainability documentation appropriate to the use caseThe sponsor can explain, for representative cases, why the model produced the output it did, at a depth appropriate to the risk of the decision“Black box” is treated as an acceptable answer
Risk assessment and mitigation registerDocumented risks (bias, drift, adversarial input, integration failure) with owner, likelihood, impact, and mitigationRegister is generic and copy-pasted across systems
Vendor management and supplier assuranceWhere the model is provided by a vendor, evidence the vendor’s development, validation, and change management meet sponsor requirementsVendor SOC reports treated as sufficient without domain-specific assurance
Fairness and bias assessmentEvidence that the model does not systematically underperform for subpopulations relevant to signal detection (e.g., pediatric, geriatric, non-English narratives, specific product classes)Not performed, or performed only on training data

Practical tip. These twelve deliverables should map to sections of a single validation summary report, with pointers to the underlying evidence. When an inspector asks about the model, the reviewer should be able to open one document and navigate to the answer, not hunt across a SharePoint site.

Regulator Expectations vs. Industry Practice: A Gap Analysis

The gap between what regulators now expect and what the industry is actually doing is not evenly distributed. Some organizations are ahead. Many are behind. The pattern below reflects what we see across sponsors we have worked with or reviewed in the past eighteen months.

DimensionRegulator expectation (2026)Common industry practiceGap severity
Context of usePrecise, inspection-defensible statement per modelMarketing language or generic use caseHigh
Validation dataIndependent test set with documented provenance and subgroup analysisVendor-supplied metrics, no subgroup analysisHigh
Human oversightSized to risk, evidenced in operation, reviewer time and qualifications documentedPolicy exists; production logs show cursory reviewHigh
Performance monitoringOngoing measurement on labeled sample; drift detection; retraining triggersOne-time validation at go-liveHigh
Change controlImpact assessment and revalidation for any model change, including vendor updatesVendor updates accepted with minimal reviewMedium-High
ExplainabilitySponsor can explain individual model decisions at a depth appropriate to risk“Black box” accepted; no case-level explanation availableMedium-High
Bias and fairnessDocumented assessment across relevant subgroupsNot performed or performed only during developmentMedium
Data governanceDocumented provenance, quality, and lineage for training and inference dataTraining data provenance unclear; inference data logged but not analyzedMedium
Case-level audit trailEvery case reconstructable including model version and inputsAggregate logs onlyMedium
Vendor assuranceDomain-specific assurance beyond generic SOC reportsSOC 2 accepted as sufficientMedium
Human-in-the-loop for high-risk decisions (seriousness, causality)Required and documented; model output is an input, not a decisionGenerally in place but occasionally undermined by throughput pressureLow-Medium
Disproportionality methods documentationWell documented, long-standingGenerally strongLow

The pattern is clear. The gaps are concentrated in the parts of AI governance that were not part of traditional PV validation: subgroup performance, ongoing monitoring, change control for models, and case-level explainability. These are not technology problems. They are process and documentation problems. They are also fixable with a focused six-to-nine-month effort in most organizations, provided leadership is willing to fund it and quality leadership is willing to hold the line.

Where the pressure will come from first. Not from a bespoke AI-in-PV guidance. From a routine inspection that asks harder questions than it did two years ago, using the FDA-EMA joint principles and the CIOMS XIV report as reference documents. Sponsors that have not tightened up model governance in the past twelve months are exposed.

Lifecycle Management: The Part Most Programs Skip

The one theme running through the FDA-EMA joint principles, the CIOMS XIV report, the GAMP AI Guide, and the MHRA AI Airlock work is that AI systems require lifecycle management, not point-in-time validation. This is where most PV AI programs are still weakest.

Lifecycle management for PV signal detection AI has four practical components.

Performance monitoring on a labeled sample

Choose a random sample of production cases each period (weekly or monthly, depending on volume) and label them independently. Compare model output to labels. Track precision, recall, F1, and subgroup performance over time. Set alert thresholds. When performance degrades, investigate before deciding whether to retrain. Measurements of actual performance degradation are more important than drift statistics alone.25

Input distribution monitoring

Signal detection models are trained on a snapshot of the reporting landscape. That landscape shifts. New products enter the market, new reporter populations appear (patient-generated content grew substantially during and after COVID-19), new MedDRA versions ship, and new therapeutic areas emerge. Monitoring the input distribution against the training distribution is the earliest indicator that something has changed, often before performance degrades enough to catch on the monitored sample.

Human override rate as a signal

The rate at which qualified reviewers override the model, in either direction, is one of the most useful operational signals of model health. A rising override rate suggests the model is drifting. A collapsing override rate raises the question of whether reviewers are still engaging meaningfully or have started to rubber-stamp the model. Either pattern is inspectable.

Change control for retraining and vendor updates

Retraining is a change to the validated system. So is a vendor pushing an updated model. Both should trigger an impact assessment, a fit-for-purpose validation on production-representative data, and formal approval before deployment. This is the point that most sponsors miss when they procure PV AI as a SaaS offering rather than an on-premise system.

The SD perspective. Point-in-time validation is a habit inherited from static software. AI systems are not static software. Sponsors that treat PV AI validation as a one-time event, and their vendor management as SOC-report-collection, are building the kind of program that will fail an inspection when the inspector asks how the model performed last month.

Conclusion

The direction of regulatory expectation is now clear. AI in pharmacovigilance signal detection is welcome, provided the sponsor can prove that its models are validated on independent data, monitored in production, overseen by qualified humans in proportion to risk, and governed through a documented lifecycle. The FDA-EMA joint principles, the CIOMS XIV report, the ISPE GAMP AI Guide, and the MHRA’s ongoing work close the ambiguity that used to give safety teams cover. The remaining question for most organizations is whether their programs match their documentation.

Sakara Digital works with pharma and biotech organizations building the kind of AI validation and governance programs that survive inspection. If you are exploring AI in signal detection, ICSR processing, or literature surveillance and want an independent perspective on where your program is strong, where it is exposed, and where to start, we are happy to have that conversation.