AI in Pharmaceutical Presentations: Medical, Legal, and Regulatory Review

In pharmaceutical presentations, AI belongs in assembly and quality control. It does not belong in claim generation.

That single distinction determines whether an AI deployment in this sector helps a medical, legal and regulatory review process or quietly undermines it.

Why claim generation is the wrong use

A generative system produces fluent statements that read as though they came from the underlying data. In most contexts that fluency is an advantage. In promotional pharmaceutical material it is the specific hazard.

An unsubstantiated claim in a slide deck is not a wording preference to be tightened in review. It is a regulatory issue. And the characteristic output of a generative system is exactly the thing MLR review exists to catch: a statement that is plausible, consistent with the surrounding narrative, professionally formatted, and not supported by the reference it appears near.

Worse, fluency makes review harder. A clumsy overclaim gets caught. A well written one, positioned next to a genuine reference, is much more likely to pass.

So the design principle is straightforward: the system retrieves approved claims with their references. It does not compose new ones.

Where AI genuinely helps

Assembling approved content into templates. Cleared claims, approved visuals, mandatory safety information, prescribing information references, into the correct template for the market and audience. Mechanical, high volume, and it removes the manual copying that introduces version errors.

Retrieving claims with their references attached. The claim and its supporting reference travel together as a unit, so a slide cannot carry one without the other.

Reference integrity checking. Does every claim have a linked reference? Does the reference exist? Does it point to the correct location in the source? Are the references current? This is tedious, entirely checkable, and currently done by people under deadline pressure who miss things.

Localisation with locked regulatory text. Market specific mandatory information retrieved from records rather than translated, with product labelling text locked. In a multi market organisation this is a large saving and a large risk if done as translation.

Change reporting against the last approved version. For a reviewer, what changed matters more than what exists. A precise diff against the previously approved version substantially reduces review time and increases what review catches.

Pre submission quality checks. Mandatory safety information present and complete, prescribing information reference correct, audience appropriate content, no off label material in a promotional piece, consistent product naming, accessibility.

Document review at scale. Reading regulatory texts, codes or internal standards against specific questions, with citations.

Where it must not go

Generating claims. Any statement about efficacy, safety, comparison or patient benefit comes from an approved record, not from a model.

Interpreting clinical data. Producing a summary that a medical audience will read as an interpretation of clinical evidence is a medical affairs activity carried out by qualified people with professional accountability. Generation followed by review does not substitute for authorship in this context.

Deciding what is on label. The boundary between approved indications and off label discussion is a regulatory determination.

Selecting which data to present. Selective presentation of data is a well understood promotional risk. Which studies and which endpoints appear is a decision requiring medical and regulatory judgement about balance.

Real patient data. Case studies and patient material carry health data, which is special category data under Article 9. This needs a specific assessment before any tool touches it, not a general AI policy.

The approved claims library

This is the load bearing structure, and it is worth building carefully because everything else depends on it.

Each claim record should carry:

• The exact approved claim text, verbatim.
• The supporting reference, with the specific location in the source, not just a citation.
• The products and indications it applies to.
• The markets and audiences it is approved for, since a claim cleared for one market may not be cleared for another.
• The language, with each translation separately approved.
• The owner, the approval date, the approving reviewers and the expiry date.
• The version, so a superseded claim can be identified in existing material.

Then two rules that make the library safe.

A claim without a linked reference is not retrievable. Not flagged. Not available with a warning. Not retrievable. The link is the substantiation, and a claim without one has nothing behind it.

An expired claim is unusable rather than old. Past its expiry, the system will not serve it. This is what actually drives the review work, because a claim that is merely marked as stale will still get used by someone under pressure.

Fitting AI to the MLR process

MLR review applies regardless of how material was produced. What changes is the quality of what arrives at review.

Before review. The system assembles from approved records. Every claim carries its reference. Mandatory safety information is present. Regulatory wording is locked. Anything unresolved is marked and blocks submission rather than being smoothed over.

At review. Reviewers see the material, the claim records used with their versions, a diff against the last approved version, and the unresolved items. Their attention goes to judgement rather than to checking whether references exist.

After approval. The approved version is frozen with its claim versions and its reviewer record. Localisation happens from that approved base, not from a working draft.

The gain here is worth stating precisely, because it is not what people expect. The value is not that review becomes faster, although it often does. The value is that review becomes more effective, because reviewers stop spending their attention on mechanical checks a system does better.

Data protection specifics

Health data is special category data under Article 9 and requires an additional condition beyond an ordinary lawful basis.

Three places it appears in presentation workflows, often unnoticed:

Case studies and patient materials. Even anonymised, a case with a condition, an age, a location and a treatment sequence can identify someone to a clinician who treated them.

Real world evidence and registry extracts. Small cohorts re identify. Suppression of small cells is a genuine control here, not a statistical nicety.

Adverse event material. Carries both health data and its own regulatory handling requirements, and should be kept out of general presentation workflows entirely unless specifically assessed.

The control is minimisation before anything reaches a model, and an explicit rule that real patient data does not enter a general presentation tool without a specific documented assessment.

The EU AI Act position

Stated precisely, as of 2026:

• The AI literacy obligation under Article 4 has applied to deployers since 2 February 2025. For MLR reviewers this is directly relevant: a reviewer who does not understand how the system produces output cannot exercise meaningful oversight, and the failure mode here is a fluent unsupported claim.
• Transparency obligations under Article 50 have applied since 2 August 2026.
• Annex III high risk obligations were deferred to 2 December 2027 by Regulation (EU) 2026/1744, in force since 27 July 2026.

A presentation assembly tool is usually not a high risk system. Document the assessment, particularly where the same platform might later be extended toward anything touching clinical decision support, which is a different classification question entirely.

The governance checklist

Where offgen fits

offgen retrieves from approved records rather than composing, and an unmatched request produces a marked gap rather than an invention, which is the behaviour this sector needs most. Claim records and their references survive into the file, so a reviewer can trace any statement. Lockable elements protect mandatory safety information, prescribing information references and regulatory wording. Output stays native and editable, so MLR annotation happens on the real artifact.

Our security overview, trust center and data processing agreement support the vendor assessment.

The framing I would keep: in this sector the constraint is not what the system can write. It is what it must never write. Design the prohibition first, and the rest of the workflow follows from it.