Across 2023 and 2024, many pharmaceutical companies launched AI proofs of concept on their pharmacovigilance corpora. The typical scenario: an impressive demonstration, enthusiastic feedback. Then, when the time comes to move into production, the case lands on the desks of the DPO (Data Protection Officer) and Medical Affairs.

The enthusiasm ends. The questions begin.

"Which servers does your clinical data pass through? In which country? Under which jurisdiction?"

"If the AI produces an erroneous pharmacovigilance signal, who is liable?"

"How do I prove to a GxP auditor that this answer really comes from file XYZ, section 4.3?"

No cloud RAG (Retrieval-Augmented Generation) vendor has a satisfactory answer to these three questions. And the pharmaceutical industry cannot afford to ignore them.

The double lock: sovereignty and enforceability

Lock 1 — The sovereignty of clinical data

Data from clinical trials, pharmacovigilance reports, marketing-authorisation (MA) dossiers — this data is covered by GDPR obligations (health data), GxP requirements, FDA regulations (21 CFR Part 11) and ICH. Sending it to a cloud API, even with a signed DPA (Data Processing Agreement), creates a chain of legal liability that almost every pharmaceutical Legal department refuses to take on.

This is not paranoia. It is risk management.

Lock 2 — Regulatory enforceability

An answer produced by a generic RAG is not enforceable before the ANSM (the French medicines agency) or the EMA (European Medicines Agency). For an AI answer to be usable in pharmacovigilance, it must meet two conditions:

  1. Come exclusively from verified, sourced documents
  2. Be reproducible — if I re-run the same query tomorrow, I get the same answer

No conventional RAG reliably satisfies both of these conditions.

Why RAG fails on a pharmacovigilance corpus

On a pharmacovigilance corpus, a standard RAG system produces answers that are partially or entirely incorrect — with no way to tell them apart from the correct ones. This is not a tuning problem: it is structural.

7 days the reporting window for a serious SUSAR — a misclassification is a regulatory breach
100% of answers traceable to the source document with a knowledge network
ALCOA+ native compliance — attributable, legible, contemporaneous, original, accurate

Three structural problems explain this result:

Problem 1 — Semantic granularity

In pharmacovigilance, "serious adverse event" and "adverse event" are legally distinct concepts. Yet their vector representations are very close — and RAG conflates them. A "suspected unexpected serious adverse reaction" (SUSAR) carries a reporting obligation within 7 days. A "non-serious adverse event" can wait for the periodic report. Confusing the two in an AI answer is a direct regulatory risk.

Problem 2 — The chronology of clinical cases

A pharmacovigilance case has a critical temporal structure: a reaction occurring at day +14 cannot be attributed to a dose taken at day +2. The chronology is not a detail — it is the causality itself. Splitting the case into fragments breaks this chronology: two fragments of the same case can be processed independently, and the temporal relationship that established causality disappears.

Problem 3 — Pre-training knowledge as a source of contamination

When the RAG system cannot find the information in the retrieved fragments, the model "fills in" using knowledge drawn from public scientific publications, patient information leaflets and public pharmacovigilance databases. This knowledge predates your marketing authorisation, your proprietary clinical studies and your PSUR (Periodic Safety Update Report). It does not reflect your data. It replaces it — without flagging that it has done so.

The most dangerous characteristic: these hallucinations are written with the same confidence as the correct answers. There is nothing in a RAG system's output that distinguishes a grounded answer from an invented one.

The architecture that satisfies all three stakeholders

The solution is not an "improved" RAG. It is a fundamentally different architecture, resting on a simple principle: the language model translates the question — the knowledge network (Knowledge Graph) produces the answer.

In concrete terms:

  1. Structuring the corpus. Your data (marketing authorisations, PSURs, clinical studies, PV signals, medical-rep visit data) is modelled in a knowledge network. Each entity — molecule, indication, population, adverse event, temporality, regulatory decision — is a node. Each relationship is a typed edge, traceable back to its source document. The hierarchy SUSAR → serious SUSAR → serious unexpected SUSAR is encoded explicitly.
  2. Translation into a formal query. "Have there been cases of raised transaminases in patients over 65 on molecule X since 2020?" — the model turns this question into a formal query over the network, not into text generation.
  3. Factual extraction. The query is executed. The results are extracted directly from the nodes and relationships of the network — not generated. Each result comes with its source: document, section, paragraph, version, date.

Answers to the three questions raised in the introduction:

DPO The data stays 100% on-premise. No transit to a third party. No external API. No third-party chain of liability.
Medical Affairs Every answer is traceable to the source paragraph. Reproducible. Auditable. The query can be re-run and will return the same result.
GxP auditor The architecture is ALCOA+ compliant — Attributable, Legible, Contemporaneous, Original, Accurate. Traceability is native, not bolted on afterwards.

The use cases that justify the ROI within 6 months

  • Pharmacovigilance signal — automatic identification of a pattern in the reports, cross-referenced against the clinical-trial history. A result in minutes, traceable, ready for the medical team.
  • Preparing ANSM / EMA responses — automatic consolidation of the required elements from the document corpus. The outline, references and relevant excerpts in a few minutes rather than several days.
  • Searching for precedents — "Have we already had a similar signal on a molecule in the same therapeutic class?" → the network answers in seconds, with the relevant cases cited.
  • Consistency across successive dossiers — automatic detection of inconsistencies between year N's PSUR and the data published in year N-1's studies. The EMA requires the PSUR to be submitted within 70 days of the data lock point — every week saved on consolidation counts.

For organisations that want to test without taking the risk

The first obstacle to adoption is often: "How do we test without exposing our real data?" Our approach: we start with a representative corpus provided under NDA, or with public reference data (EMA publications, European patient information leaflets) to calibrate the architecture on your domain. The proof of concept takes place in a controlled environment, with your teams, before any access to proprietary data.

A mutual NDA is available from the very first contact.