EU AI Act for Pharma: What Actually Applies and When

Regulation (EU) 2024/1689, the EU Artificial Intelligence Act, never uses the word "pharmaceutical." It regulates AI systems by risk tier and by their relationship to other EU product law, not by industry. Most explainers written about the Act are built for HR software vendors and credit-scoring companies, because those are the sectors Annex III names directly. Pharma isn't named anywhere in the text. That silence doesn't exempt pharma; it just means the classification takes one extra step most generic guides skip: tracing which EU product law already touches a given AI system before you can find where the Act's obligations attach to it.

I work with regulated companies building AI governance programs, and pharma clients ask a version of the same question every time: which of our AI systems actually trigger obligations, and by when. This guide answers that directly, with the article and clause numbers you can verify yourself.

What the EU AI Act Actually Regulates

The Act entered into force on 1 August 2024. Article 3(1) defines an "AI system" broadly: a machine-based system that infers, from the input it receives, how to generate outputs such as predictions, content, recommendations, or decisions that can influence physical or virtual environments. That definition is wide enough to catch a machine learning model trained to flag adverse events in pharmacovigilance data, and just as wide to catch a large language model summarizing a clinical study report.

The Act sorts every AI system into four tiers:

• Unacceptable risk: banned outright under Article 5.
• High risk: subject to the bulk of the Act's obligations.
• Limited risk: transparency duties only.
• Minimal risk: no obligations beyond voluntary codes of conduct.

Where a given pharma AI use case lands in that structure depends on what it does and what other EU law already covers it, not on the industry it sits in.

Where Pharma AI Actually Falls in the Risk Tiers

AI-Enabled Medical Devices and Companion Diagnostics

This is the clearest hook into the Act for pharma and medtech-adjacent companies. Article 6(1) classifies an AI system as high-risk when it's intended as a safety component of a product already covered by the Union harmonisation legislation listed in Annex I. That product also has to be required to undergo third-party conformity assessment under that legislation before the high-risk classification applies.

Annex I Section A lists the Medical Devices Regulation (EU) 2017/745 and the In Vitro Diagnostic Regulation (EU) 2017/746 among the covered frameworks. In practice, that means AI-driven software as a medical device (SaMD) and AI-based companion diagnostics that require notified body review under MDR or IVDR are high-risk AI systems under the Act.

Providers get until 2 August 2027 to meet the full set of obligations for these Annex I product-related systems, a longer runway than most other high-risk categories get. But a longer runway isn't the same as no obligation. A company building an AI-based diagnostic algorithm today should be designing to Article 9 through Article 15 requirements now, because retrofitting a risk management system onto a device already in market costs far more than building it in from the start.

Drug Discovery, Clinical Development, and the Research Exemption

Here's where the Act is genuinely more forgiving than most pharma compliance teams expect. Article 2(6) exempts AI systems developed and put into service for the sole purpose of scientific research and development. Article 2(8) exempts research, testing, and development activity carried out on an AI system before it's placed on the market or put into service. A target-identification model still living in a discovery team's research environment, one that has never touched a regulatory submission or a manufacturing decision, is likely outside the Act's reach entirely.

That exemption has a hard edge, though. The moment a model moves from research into a workflow that feeds a regulatory filing, a manufacturing release decision, or a patient-facing product, the exemption stops applying and the ordinary risk-tier analysis takes over. I've seen teams treat "it started in R&D" as a permanent shield. It isn't. It's a snapshot of the system's current use, and it needs to be re-evaluated every time the system's role changes.

Manufacturing, Pharmacovigilance, and General-Purpose AI Models

Most AI used in manufacturing quality systems and pharmacovigilance signal detection doesn't map cleanly onto an Annex III category. Annex III lists things like biometric identification, employment decisions, and access to essential public services: categories built around consumer-facing and public-sector harms, not batch release or adverse event triage. That means a lot of pharma's internal AI tooling sits in the minimal-risk tier by default, unless it also happens to be a safety component of an Annex I product.

The wrinkle is general-purpose AI models. Say a pharmacovigilance team is running adverse-event narrative summarization through a foundation model, or a regulatory affairs group is using an LLM-based tool to draft submission sections. In both cases, the obligations in Chapter V of the Act apply to the provider of that underlying model, not typically to the pharma company deploying it. The exception is fine-tuning or substantial modification of the model in-house, which can shift some provider obligations onto the deployer.

Chapter V's obligations for general-purpose AI models became applicable on 2 August 2025. It's worth knowing which foundation model sits underneath the tools your teams already use, and asking the vendor directly whether they're treating their model as one that carries "systemic risk" under Article 51, because that changes what documentation you're entitled to receive from them.

The Compliance Timeline

The Act phases in over three years, and the dates matter more for pharma than for most sectors, because the Annex I product route runs on a genuinely different deadline than everything else.

The Act's own transitional provisions set these dates. A company tracking only 2026 as "the" EU AI Act deadline is tracking the wrong date for anything tied to a medical device or IVD, and possibly a date that's too generous for a foundation-model tool already live in production.

Where the EU AI Act Sits Next to Frameworks You Already Use

Pharma compliance teams aren't starting from zero. GxP, ISO 13485, MDR quality systems, and increasingly ISO 42001 already govern large parts of how these companies build and validate software. The Act doesn't replace any of that; it adds a parallel, EU-specific layer with its own enforcement mechanism.

The practical value of this table is knowing which piece does which job. ISO 42001 gives the management system architecture: policy, risk assessment, competence, operational controls, internal audit, management review. The EU AI Act tells you, for a specific subset of your AI systems, what substantive requirements that management system has to produce evidence against.

A company that has already built an AI management system under ISO 42001 clause 6.1.2 has done most of the risk-assessment groundwork Article 9 of the AI Act requires. It isn't automatically compliant, but the remaining gap is a mapping exercise, not a rebuild.

Building Governance That Covers GxP and the AI Act Together

The mistake I see most often is standing up a separate "AI Act compliance" workstream that never talks to the existing quality organization. That's backwards. Article 17 requires providers of high-risk AI systems to operate a quality management system covering regulatory compliance strategy, design and development controls, data management, risk management, and post-market monitoring. A company already running GAMP 5-aligned computerized systems validation and EudraLex Volume 4 Annex 11 controls already has most of those elements in place under a different name. The job is integration, not duplication.

For a pharma compliance team working through this now, that means three concrete moves:

1. Inventory every AI system in use or in development, and classify each one against the risk-tier analysis above, not a generic checklist, because the Annex I product route and the research exemption are the two calls that actually change your timeline.
2. Fold compliance into existing design controls. For anything landing in the high-risk tier, build the Article 9 risk management system and Article 11 technical documentation into your existing design control process rather than running a parallel one.
3. Revisit the inventory whenever a system's use case changes. A discovery-stage model that graduates into a submission workflow doesn't carry its research exemption with it.

None of this is a one-time project. The Act's phased dates mean a system correctly classified as out of scope in 2025 might need reclassifying in 2027 if its role in the business changes. The inventory should be a living document owned by whoever already owns the quality system, not a slide deck built once for a steering committee.

Getting Started Without Overbuilding

I'd rather see a pharma compliance team build a lean, accurate inventory of five AI systems than a comprehensive-looking governance framework that never gets tested against a real classification decision. Start with the systems most likely to land in the high-risk tier: the Annex I product route and the research-exemption edge cases covered above are the two places to look first, not a fresh list of categories.

Work outward from there. This risk assessment framework for regulated drug development walks through the same classification logic in more operational detail, and the EU AI Act service page covers the broader compliance program beyond pharma specifically.

The companies that get burned by this Act aren't the ones running sophisticated AI programs. They're the ones who assumed pharma wasn't really the target audience, because the word never appears in the regulation, and found out during a notified body review that their diagnostic algorithm's technical file never addressed Article 9 at all.

I'm Jared Clark, Principal Consultant at Certify Consulting. I publish this kind of AI governance research through regulatedai.consulting, Certify's advisory practice for regulated organizations building AI programs. If you want a second set of eyes on where your AI inventory actually lands in this risk structure, that's the conversation to have before a notified body or a competent authority forces it.

Frequently Asked Questions

Does the EU AI Act apply to pharmaceutical companies based outside the EU? Yes, if the AI system's output is used within the EU. Article 2 sets the Act's territorial scope by where the system is placed on the market or where its output is used, not by where the provider is headquartered, so a US-based pharma company selling an AI-enabled diagnostic in the EU market is in scope.

Is AI used in early drug discovery covered by the EU AI Act? Generally not, while it stays in a research context. Article 2(6) and 2(8) exempt AI systems developed solely for scientific research and development, and R&D activity conducted before a system is placed on the market. That exemption ends the moment the model's output feeds a regulatory submission, manufacturing decision, or patient-facing product.

Who inside a pharma company should own EU AI Act classification decisions? The team that already owns quality and regulatory affairs, not a standalone AI ethics committee. Article 17's quality management system requirement for high-risk AI providers maps onto functions pharma compliance already staffs: design controls, risk management, document control, post-market surveillance. Routing classification decisions through quality avoids building a parallel structure that duplicates GxP work already underway.

Does ISO 42001 certification satisfy EU AI Act requirements? Not automatically, but it covers a substantial share of the groundwork. ISO 42001:2023's risk assessment process at clause 6.1.2 maps closely to the Article 9 risk management system requirement, and the standard's operational controls overlap with several Article 11 through 15 obligations. A gap analysis against the specific Articles is still necessary, since the Act includes requirements, like conformity assessment and CE marking for certain systems, that ISO 42001 doesn't cover.

Last updated: 2026-08-18