The EU AI Act is the first broad, horizontal law that regulates artificial intelligence by risk rather than by sector. It is Regulation (EU) 2024/1689, it entered into force on 1 August 2024, and it applies across the whole single market to anyone who develops, sells, or uses AI systems with effects in the European Union, including companies based outside it. For a biotech, pharma, biologics, or combination-product organisation, that creates a second regulatory track running alongside the GxP rules you already follow, and the two tracks overlap in ways that are easy to get wrong.
This article is a working account of what the Act requires, how its risk tiers classify the AI you are likely to build or buy, where it intersects with GMP and (for any device-constituent part of a combination product) the medical-device rules, what the phased dates are (including the 2026 Digital Omnibus amendment that deferred the high-risk deadlines and is now in force), and what a regulated company should actually do. It is written so that after reading it you could scope the work, brief a quality or regulatory committee, and answer the questions an interviewer or an auditor will ask. It is general guidance to adapt and verify against the current text and your own legal advice, not a compliance directive.
If you have not yet built a base in how AI sits inside a regulated quality system, read AI governance in GxP and validating AI-enabled GxP systems first. The Act adds a legal layer on top of that quality work; it does not replace it.
Scope: Who and What the Act Covers
The Act regulates “AI systems” and “general-purpose AI models” placed on the EU market or whose output is used in the EU. Two scoping facts matter most for a life-sciences company.
It is extraterritorial. The obligations attach based on where the AI is used or where its output lands, not where the company sits. A US-headquartered manufacturer whose deviation-triage model is used by an EU site, or whose AI-enabled device is sold in the EU, is in scope. This mirrors how the General Data Protection Regulation reached non-EU companies, and it means “we are a US company” is not an exemption.
It is role-based. The same AI system carries different duties depending on what role you play. The two roles that matter most are the provider (broadly, the party that develops an AI system or has it developed and puts it on the market under its own name) and the deployer (the party that uses an AI system under its own authority in a professional context). A pharma or biologics manufacturer that builds an AI model into its own operations, or a combination-product maker that builds AI into a drug-device product, is a provider. A site or a manufacturer that buys a commercial AI tool and runs it is a deployer. You can be both at once: build a model in-house for your own operations and you are effectively the provider and the deployer of that system. Get the role wrong and you size the obligations wrong.
The Act layers four things on top of each other: a list of banned uses, heavy duties for “high-risk” systems, light transparency duties for a “limited-risk” middle band, and near-nothing for everything else. Plus a separate regime for general-purpose AI models. The rest of this article works through each.
The classification decision, for any one system, runs in a fixed order. Screen for a prohibited use first, because that is the highest-penalty band; then test the two high-risk routes; then check the transparency trigger; what is left is minimal-risk.
The Risk Tiers
Under Article 6(2), the standalone uses listed in Annex III are treated as high-risk by default. (Regulation (EU) 2024/1689, Article 6(2))
The Act sorts AI into tiers by the risk it poses to health, safety, and fundamental rights. The duties scale with the tier. The four tiers, from most to least restricted:
| Tier | What it means | Core obligation | Life-sciences relevance |
|---|---|---|---|
| Unacceptable (prohibited) | Uses judged to threaten fundamental rights or safety | Banned outright | Mostly not your AI, but watch HR and security uses (see below) |
| High-risk | Significant potential for harm to health, safety, or rights | Full conformity regime: risk management, data governance, technical documentation, logging, human oversight, accuracy and reliability, CE-type assessment | AI-enabled medical devices and IVDs land here; some operational AI may too |
| Limited risk | Interacts with people or generates content | Transparency: tell people they are dealing with AI or with AI-generated content | Patient-facing chatbots, AI-drafted content |
| Minimal risk | Everything else | No mandatory rules; voluntary codes encouraged | Most internal productivity and back-office AI |
Unacceptable risk: the prohibited practices
Article 5 bans a defined set of uses outright. The banned categories include social scoring, untargeted scraping of facial images to build recognition databases, certain manipulative or exploitative systems, and, important for employers, emotion inference in the workplace (with a narrow exception for medical or safety reasons) and certain biometric categorisation. These prohibitions applied first, on 2 February 2025.
A life-sciences company rarely builds prohibited AI in its core science. The exposure is usually at the edges: an HR vendor’s tool that infers candidate emotion from interview video, a security system doing biometric categorisation, a workforce-analytics product. The action here is an inventory that reaches HR, facilities, and security, not just the lab and the plant. A banned use carries the heaviest penalty band, up to EUR 35 million or 7 percent of global annual turnover, whichever is higher.
The 2026 Digital Omnibus, covered in the timelines section below, added two further categories to the Article 5 list: AI systems that generate or manipulate non-consensual intimate images of a real person, and systems that generate synthetic child sexual abuse material, the response to so-called “nudification” apps. Both bans apply from 2 December 2026, with no exemption for a system already on the market unless it already carries effective safeguards against that misuse. This is unlikely to be a core-science exposure for a life-sciences company, but a photo or content-editing feature bundled into an unrelated commercial productivity or marketing tool is exactly the kind of hidden AI the inventory step exists to catch, so fold it into the same HR, security, and vendor-tool sweep as the rest of Article 5.
High-risk: where most regulated AI lands
Two routes put an AI system in the high-risk tier.
Route 1, Annex I (Article 6(1)): AI inside a regulated product. If an AI system is a safety component of, or is itself, a product covered by listed EU product-safety law and that product already needs third-party conformity assessment, the AI is high-risk. The Medical Devices Regulation (EU) 2017/745 (MDR) and the In Vitro Diagnostic Regulation (EU) 2017/746 (IVDR) are on that list. For the pharma and biologics world this route bites mainly through combination products: where a drug-device combination has a device constituent that, assessed on its own, would need a notified body (broadly MDR Class IIa and above, or IVDR Class B and above), AI in that constituent is high-risk under the Act by this route. The same is true of any standalone AI-enabled diagnostic or software as a medical device a company puts on the market. This overlap is consequential where it applies and is covered in detail below.
Route 2, Annex III (Article 6(2)): listed standalone uses. Annex III lists standalone high-risk uses such as AI in employment and worker management, access to essential services, biometric identification, and critical infrastructure. Most pharma manufacturing-quality AI does not fall in an Annex III category, but employment-related AI used by your HR function can.
There is a carve-out worth knowing. Article 6(3) lets a provider treat an Annex III system as not high-risk if it does not pose a significant risk of harm, for example because it performs a narrow procedural task or only improves the result of completed human work and does not replace or influence the human decision. A system that profiles individuals is always high-risk regardless. If you rely on this exception, Article 6(4) requires you to document the assessment before the system goes on the market. Treat that documented assessment as a controlled record, not a casual note.
What “high-risk” obligates is substantial. A provider of a high-risk system must, broadly:
- run a risk-management system across the AI lifecycle;
- apply data-governance and data-quality measures to training, validation, and test data;
- produce technical documentation and keep it current;
- design in automatic logging (record-keeping) of events;
- enable meaningful human oversight;
- meet appropriate levels of accuracy, reliability, and cybersecurity (the requirement the Act states as accuracy, robustness, and cybersecurity);
- operate a quality-management system;
- undergo conformity assessment and carry the CE marking;
- register the system and run post-market monitoring.
If that list reads like GxP computerised-system validation and a quality system, that is the point. The mechanics rhyme with what you already do, which is both an opportunity (reuse your QMS) and a trap (the legal bases and the assessor are different).
Limited risk: transparency duties
Systems that interact with people or generate content carry a lighter duty: make the AI nature visible. If a patient or a user is talking to a chatbot, they must be told it is AI unless that is obvious. AI-generated or AI-manipulated content (synthetic audio, image, video, text in some cases) must be marked as such. For a life-sciences company this reaches patient-support chatbots, AI-drafted patient or HCP communications, and any synthetic media in training or marketing.
Minimal risk: most internal AI
Everything not caught above, spam filters, scheduling helpers, most back-office productivity AI, has no mandatory obligation under the Act. Voluntary codes of conduct are encouraged. The practical task is to be able to demonstrate that a given system is genuinely minimal-risk, which means you classified it deliberately and wrote down why, rather than assuming.
General-purpose AI models: a parallel track
Separately from the tiers, the Act regulates general-purpose AI (GPAI) models, the large foundation models. Providers of these models must produce technical documentation, give downstream integration information, put a copyright policy in place, and publish a summary of training content. Models judged to carry systemic risk, with the headline threshold set at training compute above 10^25 floating-point operations, carry extra duties: adversarial testing, systemic-risk assessment and mitigation, incident reporting, and cybersecurity.
For most life-sciences companies you are a downstream user of a GPAI model accessed through an API, not the model provider. You do not inherit the model-provider duties. But the model-provider’s documentation is your input: it feeds your own validation and your supplier assessment. When you build a regulated workflow on top of a vendor large language model, the prompt, retrieval setup, guardrails, and output handling are the part you own and must control. See qualifying LLMs and generative AI for GxP for how that plays out in a validated environment.
Common GxP AI Use Cases, Mapped to Risk Tier
The tier definitions above are abstract until you hold a real system against them. The table below runs the classification against the AI a pharma, biologics, or combination-product company actually builds or buys. Treat each row as a starting read, not a substitute for the documented Article 6(4)-style assessment; a small design change (does the AI decide, or does a human decide with the AI’s help?) can move a system from one tier to another. For the full step-by-step walk, see AI risk assessment in GxP.
| Use case | What it does | Likely tier | Why |
|---|---|---|---|
| Batch release disposition model | Scores batch and testing data and recommends an accept or reject decision to a human reviewer | Minimal risk under the Act (not Annex III, not itself a regulated product), unless embedded in a combination product’s device constituent | Advisory only; a human makes and owns the release decision. Still fully in scope of GMP, Part 11, and internal AI governance regardless of the Act’s tier |
| Adverse-event or pharmacovigilance case triage NLP | Extracts case information from incoming reports and ranks or routes them for a human reviewer | Minimal risk in most designs; can tip toward higher scrutiny if it drives a reportability decision with no meaningful human review | Not an Annex III category. GDPR Article 22 (automated decisions) still applies where the model touches personal data |
| AI-assisted labeling or patient-material drafting, human-approved | Drafts label text, patient leaflets, or HCP communications for human authoring and sign-off | Minimal risk while a human authors and approves the final content; limited risk (transparency) if AI-generated content reaches a patient or the public without a clear human-authored final step | Article 50 marking duty attaches to AI-generated content itself, not to drafting aids a human then rewrites and owns |
| Patient-support or HCP chatbot | Conversational interface for patients or healthcare professionals | Limited risk | Article 50 requires disclosing that the user is interacting with AI, unless that is obvious from context |
| Predictive-maintenance model for manufacturing or lab equipment | Predicts failure risk or maintenance timing from sensor and history data | Minimal risk under the Act | Not an Annex III category and not itself a regulated product, unless the equipment is a device or combination-product safety component |
| Deviation or CAPA triage and prioritisation model | Ranks open deviations or CAPAs for investigator attention | Minimal risk under the Act | Advisory ranking of completed human work; does not profile individuals or replace the investigation decision |
| AI feature embedded in a combination product’s device constituent (for example dosing guidance from patient inputs) | Adjusts guidance delivered through a connected device | High-risk, Annex I route | The device constituent, assessed on its own, needs a notified body under MDR or IVDR; see the section below |
| HR candidate-screening tool that infers emotion, sentiment, or suitability from interview video or resume text | Screens or ranks candidates | Prohibited if it infers emotion in the workplace (narrow medical/safety exception); otherwise likely Annex III (employment) high-risk | Article 5 bans workplace emotion inference outright; other employment-related AI is a listed Annex III use |
A system’s row can move. Retraining a minimal-risk triage model to make an autonomous decision instead of an advisory one, or adding a feature that profiles individuals, is a reclassification event, not a footnote; treat it the same way you would treat a GxP computerized-system change under change control for validated systems, and re-run the classification record.
The Combination-Product and Device-Constituent Overlap, in Detail
For the pharma and biologics world this overlap shows up wherever AI sits in a device constituent of a combination product, or in a standalone diagnostic or software as a medical device a company also sells. Where it applies, it cannot be misread, so work it step by step.
WHY it matters. An AI-enabled device constituent or diagnostic now sits under two EU regimes at once: the sector law (MDR or IVDR) and the AI Act. They are not alternatives. The AI Act adds requirements; it does not displace MDR/IVDR. The risk is double-counting effort, or worse, assuming MDR compliance covers the AI Act and finding a gap at audit.
WHAT the overlap is. Both regimes demand a quality-management system, risk management, technical documentation, clinical or performance evidence, post-market surveillance, and a conformity assessment by a notified body that ends in CE marking. The Act’s design intent is integration, not duplication: where a device already goes through MDR/IVDR conformity assessment, the AI-Act high-risk requirements are meant to be assessed within that same procedure, and the device’s existing technical documentation is meant to be extended to cover the AI-specific elements rather than duplicated in a separate file.
HOW to approach it, step by step.
- Confirm the device’s MDR/IVDR class and whether it needs a notified body. If yes (broadly MDR Class IIa+ or IVDR Class B+), assume the AI is high-risk under the Act via the Annex I route.
- Map the AI-Act high-risk requirements onto your existing MDR/IVDR deliverables. Most map onto something you have: AI-Act risk management onto your ISO 14971 file, data governance onto your design and verification records, logging onto your device-software design, human oversight onto your instructions for use and labelling, post-market monitoring onto your MDR post-market surveillance plan.
- Identify the genuinely new elements the Act adds, principally the data-governance and data-quality discipline for training/validation/test data, the AI-specific transparency and human-oversight design, and the AI-Act technical-documentation annex. Build those, do not rebuild what you have.
- Confirm your notified body is designated for the AI-Act assessment as well as MDR/IVDR, and plan the assessment as one combined exercise. Note that notified-body capacity and the harmonised standards that make the requirements concrete are still maturing, which is part of why the deadline (below) is under pressure.
- Keep a single, traceable line from MDR/IVDR evidence to AI-Act requirement so an assessor can see one coherent file, not two parallel ones.
ACCEPTANCE CRITERIA. You can show, for each AI-Act high-risk requirement, the specific MDR/IVDR deliverable that satisfies it or the new deliverable you created; the training/validation/test data governance is documented to the Act’s data-quality expectations; human oversight and AI transparency are designed in and reflected in the IFU; and the conformity-assessment plan names a notified body covering both regimes.
WORKED EXAMPLE. A biologics company markets a combination product whose device constituent is a connected delivery system with an AI feature that adjusts dosing guidance from patient inputs. Assessed on its own the device constituent would be MDR Class IIa and need a notified body, which makes the AI high-risk under the Act. The team does not start over. It maps the MDR risk file to the AI-Act risk-management requirement, extends the device-constituent technical documentation with an AI annex (model description, intended purpose, data lineage, performance against a held-out test set, human-oversight design), adds explicit data-governance records showing the training data was representative across the intended patient population, and confirms the notified body will assess the AI-Act elements inside the MDR procedure for the constituent. The output is one extended file and one combined assessment, not two programmes. The deeper treatment of AI in software as a medical device, including the device-constituent part of a combination product, is in AI and machine learning in SaMD, and the regulatory frame is the EU MDR and IVDR.
Provider Versus Deployer: Who Owes What
The role split is the most common source of confusion, so be deliberate about it.
| Dimension | Provider | Deployer |
|---|---|---|
| Who it is | Develops the AI system, or has it built, and puts it on the market under its own name; can be inside or outside the EU | Uses the AI system under its own authority in a professional context |
| Typical life-sciences example | A company building AI into a combination product’s device constituent; a manufacturer building its own quality model for internal use | A manufacturer or site buying and running a commercial AI tool |
| Core duties (high-risk) | The full conformity regime: risk management, data governance, technical documentation, logging, human-oversight design, accuracy and reliability and cybersecurity, QMS, conformity assessment, registration, post-market monitoring | Use the system per the provider’s instructions; ensure human oversight; ensure input data is relevant and representative for the intended use; monitor operation and keep logs; inform the provider/authorities of risks or serious incidents; where required, run a fundamental-rights impact assessment |
| Where the burden sits | Heaviest | Significant but lighter than the provider |
Two traps to avoid. First, building your own model makes you a provider, even if it never leaves your company, so you take on provider-level duties for that system. Second, substantial modification can flip a deployer into a provider: if you take a commercial high-risk system and materially change its intended purpose or retrain it in a way that changes its behaviour, you may become the provider of a “new” system and inherit those duties. Treat retraining and repurposing of a third-party model as a role-changing event, governed under change control for validated systems.
Walk the determination in order, for each AI system:
ROLES, internally. Decide early who owns the Act inside your organisation. A workable split: a named accountable owner per AI system (often the system or product owner); Regulatory Affairs owning the conformity-assessment pathway and notified-body interaction for any AI in a combination product’s device constituent; Quality owning the QMS overlap and the documented classification decisions; Legal/Privacy owning the prohibited-use screen and the GDPR interaction; and Data Science owning the data-governance and performance evidence. The failure mode is leaving it unowned because it “sounds like an IT or a legal thing,” and discovering at assessment that no function built the file.
Timelines and Phasing (and a Change That Is Not Yet Final)
The Act phases in. These are the dates set in the original Regulation (EU) 2024/1689, counted from entry into force on 1 August 2024:
| Date | What applies |
|---|---|
| 2 February 2025 | Prohibited practices (Article 5) and AI-literacy obligations |
| 2 August 2025 | General-purpose AI model rules; governance and national-authority provisions; penalty framework |
| 2 August 2026 | High-risk systems under Annex III (standalone listed uses); general full application |
| 2 August 2027 | High-risk systems under Annex I (AI embedded in regulated products, including MDR/IVDR devices) |
So a device maker reading the original text would plan for 2 August 2027 on the embedded-product route, while a company with an Annex III standalone use would plan for 2 August 2026. Both of those high-risk dates were later deferred by the Digital Omnibus, now in force and described next.
The change to flag, and its current legal status. Through 2025 the rollout fell behind, in large part because the harmonised standards and guidance companies need to implement the high-risk rules were not ready. On 19 November 2025 the European Commission published a package, widely referred to as the Digital Omnibus on AI, that would defer the high-risk deadlines. The Council, Parliament, and Commission reached a provisional political agreement on 7 May 2026; the European Parliament then formally endorsed the package on 16 June 2026 and the Council of the EU gave its final approval on 29 June 2026, moving the Annex III standalone high-risk deadline to 2 December 2027 and the Annex I embedded-product deadline to 2 August 2028, among other simplifications. That amendment is now law: it was published in the Official Journal on 24 July 2026 as Regulation (EU) 2026/1744 and entered into force on 27 July 2026, so the deferred high-risk dates are the operative deadlines rather than a pending proposal. Confirm the exact date against the current text for your own system, since a system’s classification still drives which date applies.
Status: the Digital Omnibus was adopted by both co-legislators (Parliament 16 June 2026, Council 29 June 2026), published in the Official Journal on 24 July 2026 as Regulation (EU) 2026/1744, and entered into force on 27 July 2026 (procedure 2025/0359(COD)). The deferred high-risk dates are therefore the operative law now, not a pending proposal. What did not move is the 2 August 2026 application of the Article 50 transparency duties, which still binds, with a short grace period for existing systems to align their content marking. Verify the current text for your own system, and do not let a deferred deadline become a reason to stop building, because the substantive high-risk requirements did not change, only when they bite.
The honest planning posture: build to the original dates, treat any deferral as schedule relief rather than a reprieve from the work, and re-check the legal status before any decision that turns on the exact date.
Penalties and the GDPR Overlap
The penalty bands track the seriousness of the breach. Article 99 sets the headline ceilings (whichever is higher of a fixed sum or a percentage of worldwide annual turnover); for SMEs and start-ups the lower of the two applies.
| Breach | Ceiling (higher of) |
|---|---|
| Prohibited practice under Article 5 | EUR 35 million or 7 percent of global annual turnover |
| Non-compliance with other obligations (most provider and deployer duties, including the high-risk requirements) | EUR 15 million or 3 percent of global annual turnover |
| Supplying incorrect, incomplete, or misleading information to authorities or notified bodies | EUR 7.5 million or 1 percent of global annual turnover |
Verify the current figures against the adopted text before quoting them, since the Digital Omnibus simplification package touches enforcement details as well as dates.
The Act does not run alone. Most life-sciences AI also processes personal data (patient inputs, HCP data, workforce data), so the General Data Protection Regulation applies in parallel. The two regimes reinforce each other: the Act’s data-governance and human-oversight duties sit beside the GDPR’s lawful-basis, data-minimisation, and automated-decision rules (Article 22 GDPR on decisions producing legal or similarly significant effects). Where an AI system makes or materially influences a decision about a person, screen both regimes together, and record the GDPR lawful basis and any data protection impact assessment alongside the AI-Act classification. Treating them as one screen, owned jointly by Quality and Legal/Privacy, avoids the gap where each function assumes the other covered it.
Post-Market Monitoring and Serious Incident Reporting for High-Risk AI
Classification is a point-in-time decision. For a high-risk system, the Act also imposes two live, ongoing obligations that a first pass at compliance tends to underweight: watching the system after it ships, and reporting fast when something goes seriously wrong. Both apply to the provider (the deployer carries a parallel duty to monitor and to tell the provider).
WHY required. A conformity assessment and a CE mark describe the system as it was at launch. A model can drift, a population it serves can shift, or a failure mode nobody anticipated can surface once thousands of real cases run through it. Article 72 exists to keep the technical file honest against what the system actually does in the field. Article 73 exists so that a market surveillance authority learns about a serious incident fast enough to act, rather than months later through a complaint or an audit.
WHAT Article 72, post-market monitoring, requires. A provider of a high-risk AI system must set up and document a post-market monitoring system, proportionate to the technology and its risk, that actively and systematically collects, documents, and analyses relevant data on the system’s performance across its lifetime, drawn from deployers or other sources, so the provider can keep evaluating whether the system still meets the high-risk requirements it was assessed against. Where relevant, the analysis covers how the system interacts with other AI systems. The monitoring plan is not a free-standing document; it is part of the Annex IV technical documentation, so it lives and is updated alongside the rest of the file. Where a system already sits inside an existing sector post-market surveillance framework, MDR/IVDR post-market surveillance for a device constituent is the clearest life-sciences example, the Act allows the two to be integrated rather than run as parallel programmes, provided the integrated approach gives equivalent protection. The Act required the Commission to adopt an implementing act by 2 February 2026 setting a template and a list of required elements for the plan; confirm the current template on the Commission’s AI Act service desk before building your own structure from scratch.
WHAT Article 73, serious incident reporting, requires. A “serious incident” is defined, broadly, as an incident or malfunction that directly or indirectly leads to a person’s death or serious harm to health, a serious and irreversible disruption to the management or operation of critical infrastructure, an infringement of Union law protecting fundamental rights, or serious harm to property or the environment. Where an in-scope high-risk system causes or contributes to one, the provider must report it to the market surveillance authority in the state where it happened. The clock is tiered and starts when the provider establishes, or has reasonable grounds to believe, a causal link between the AI system and the outcome, not necessarily the moment the incident occurred:
| Incident type | Reporting deadline |
|---|---|
| Widespread infringement, or an incident meeting the more severe criteria the Act sets out | Immediately, and not later than 2 days after becoming aware |
| Death of a person | Not later than 10 days after becoming aware |
| Any other serious incident (the default) | Not later than 15 days after becoming aware |
A provider who cannot assemble the full picture in time may file an incomplete initial report and follow up once the rest of the information is available; the clock is not a reason to wait for a complete investigation before reporting anything. The market surveillance authority is expected to act on a report within days of receiving it, which is the whole point of a short clock. The Commission published draft guidance and a reporting template for Article 73 in late 2025 and ran a public comment period into November 2025; confirm the current finalised guidance and template on the Commission’s AI Act pages before building an internal procedure, since the practical mechanics (the exact form, the national contact points) come from that guidance rather than from the Regulation’s text alone.
HOW this differs from ordinary GxP deviation and CAPA handling. The mechanics rhyme, an event happens, someone assesses it, someone reports it, but the addressee and the clock are new. A GxP deviation goes to your own quality system and, for a small subset of events, to a health authority under existing pharmacovigilance or field-alert rules. An AI-Act serious incident goes to a market surveillance authority, a different regulator with a different remit, on a clock measured in single-digit or low double-digit days rather than the weeks a typical deviation investigation runs on. The practical answer is not two parallel systems: route the initial detection and triage through your existing deviation or incident-management process, but add an explicit decision point, “does this also meet the Article 73 definition, and if so who owns the market-surveillance-authority notification and by when,” so the AI-Act clock does not get lost inside a slower internal investigation timeline. Where the AI sits in a device constituent, coordinate the Article 73 report with any parallel MDR/IVDR vigilance reporting for the same event rather than filing two uncoordinated notifications.
ACCEPTANCE CRITERIA. A post-market monitoring plan exists for every high-risk system, is part of the technical documentation, and names what data is collected, from where, how often, and who reviews it. A named owner and a written decision tree exist for recognising a serious incident and starting the Article 73 clock the same day evidence of a causal link emerges. The tiered deadlines (2, 10, or 15 days) are built into the procedure, not left to whoever is on shift to remember. Where a device-constituent overlap exists, the AI-Act and MDR/IVDR reporting are coordinated, not duplicated or contradictory.
WORKED EXAMPLE. The connected-device dosing-guidance feature from the combination-product example above ships and enters routine use. Six months in, the post-market monitoring data (collected under the integrated MDR/AI-Act plan) shows the model’s dosing suggestions drift for patients at the extremes of the training population’s weight range, a data-representativeness gap the pre-market testing had not surfaced at that scale. The monitoring review flags it, Data Science confirms the drift with held-out field data, and the team assesses whether any patient experienced serious harm from a suggestion in that range. One confirmed case of serious harm traceable to the drift starts the Article 73 clock (10-day track, since it involves harm to health at the serious end of the definition); the team reports to the market surveillance authority and coordinates the notification with the parallel MDR vigilance report for the same event, then retrains the model on an expanded population and updates the technical documentation to reflect both the incident and the fix. For a fuller treatment of the model-monitoring and retraining mechanics behind that fix, see the GxP machine-learning model lifecycle.
What Regulated Companies Should Do Now
A practical sequence, ordered so each step feeds the next.
- Inventory your AI. Build and maintain a register of every AI system you develop or use, reaching beyond the lab and plant into HR, security, IT, and commercial. You cannot classify what you have not found, and “hidden” AI inside a vendor feature is a recurring blind spot.
- Assign roles per system. For each entry, record your role: provider, deployer, or both, and remember that in-house builds make you a provider.
- Classify by tier, and document the reasoning. Prohibited, high-risk (which route), limited, or minimal. Where you conclude “not high-risk” under an Annex III exception, write the Article 6(4)-style assessment as a controlled record.
- Screen hard for prohibited uses first. This is the highest-penalty band and the deadline (February 2025) has already passed. The likely exposure is HR, security, and workforce tools, so look there.
- For high-risk AI in a combination product’s device constituent, run the MDR/IVDR overlap as one programme. Map, extend, and combine the assessment as described above; do not build a parallel file.
- Stand up AI governance and AI literacy. The Act expects appropriate AI literacy for staff who deal with AI systems, and the practical home for classification, oversight, and monitoring is an AI-governance framework that plugs into your existing QMS. See AI governance in GxP.
- Reuse your validation and QMS machinery. The risk management, data governance, documentation, logging, and human-oversight expectations align closely with how you already validate GxP computerised systems. Extend that work rather than starting fresh; the validation of AI-enabled GxP systems approach maps cleanly onto the Act’s high-risk expectations.
- Track the legal status. Keep a watch on the Digital Omnibus and the harmonised standards, and update your dates and plans as the text settles.
- Build post-market monitoring and serious-incident reporting for each high-risk system before it ships, not after an incident. Write the monitoring plan into the technical documentation, name who reviews the field data and how often, and give someone an explicit, dated owner’s job for recognising an Article 73 serious incident and starting the clock. See the section above for the mechanics and deadlines.
Common Mistakes and Audit-Finding Patterns
These are the recurring ways organisations get the Act wrong, framed so you can check yourself against each.
- Assuming geography is an exemption. “We are not an EU company” ignores the extraterritorial reach. If your AI or its output is used in the EU, you are likely in scope.
- Confusing the roles. Treating yourself as a mere deployer when you built or substantially modified the model, and so under-scoping the obligations. In-house builds and material retraining make you a provider.
- Treating MDR/IVDR compliance as AI-Act compliance. They overlap heavily but are not the same; the data-governance, transparency, and AI-specific documentation elements are additions you must build.
- Building a duplicate parallel file. The opposite error: re-documenting everything separately instead of extending the existing device technical documentation, wasting effort and creating two versions to keep in sync.
- Skipping the prohibited-use screen. Missing a banned HR or security tool, which sits in the highest penalty band and is already in force.
- No documented classification. Asserting a system is minimal or not-high-risk with nothing written down, so the conclusion cannot survive a question.
- Hidden AI. A vendor feature or an embedded model quietly doing classification or prediction that was never inventoried or assessed.
- Stopping work because of the proposed delay. Treating a not-yet-final deferral as permission to pause, then facing the full requirement with no runway.
- Ignoring the GPAI documentation chain. Building a regulated workflow on a foundation model without obtaining and using the model provider’s documentation as an input to your own validation and supplier assessment.
- No post-market monitoring plan separate from GxP change control. Treating periodic system review or annual product quality review as if it already satisfies Article 72, when neither was built to actively collect and analyse field performance data against the AI-Act requirements the system was assessed against.
- No named owner or written trigger for serious-incident reporting. A qualifying event under Article 73 gets treated as an ordinary deviation, worked at deviation-investigation speed, and the 2, 10, or 15-day clock is missed because nobody had the job of recognising it and starting the clock the same day.
Interview and Audit Questions, and How to Answer Them
Short, concrete answers signal a real practitioner.
“What kind of law is the EU AI Act, and what is its identifier?” It is Regulation (EU) 2024/1689, a horizontal, risk-based law that regulates AI across all sectors rather than industry by industry. It entered into force on 1 August 2024 and applies extraterritorially, based on where the AI or its output is used.
“What are the risk tiers?” Four, by descending obligation: unacceptable (prohibited outright), high-risk (full conformity regime), limited-risk (transparency duties), and minimal-risk (no mandatory rules). Separately, there is a regime for general-purpose AI models.
“How does it overlap with the medical-device rules?” AI in a combination product’s device constituent (or a standalone diagnostic or SaMD) that already needs a notified body under MDR or IVDR is high-risk under the Act via the Annex I route. The two regimes are additive but designed to be assessed together: extend the existing technical documentation and run one combined conformity assessment, do not build a parallel file.
“What is the difference between a provider and a deployer?” The provider develops the system and puts it on the market under its own name and carries the heavy conformity duties. The deployer uses it under its own authority and carries lighter duties: use it per instructions, ensure human oversight, monitor it, and report risks. Building your own model makes you a provider; substantially modifying a bought model can too.
“When do the rules apply?” Original dates: prohibited practices from 2 February 2025, GPAI and governance from 2 August 2025, Annex III high-risk from 2 August 2026, Annex I embedded-product high-risk from 2 August 2027. The 2026 Digital Omnibus, Regulation (EU) 2026/1744, in force since 27 July 2026, defers the high-risk dates (Annex III to 2 December 2027, Annex I to 2 August 2028); those deferred dates are now the operative law, while the 2 August 2026 transparency duties still apply.
“What would you do first at a company that has never looked at this?” Inventory all AI across the business including HR and security, assign provider/deployer roles, screen hard for prohibited uses, then classify each system by tier with the reasoning written down. Everything else follows from a complete, classified inventory.
“Can you reuse your existing validation work?” Yes, and you should. The Act’s high-risk expectations, risk management, data governance, documentation, logging, human oversight, align closely with GxP computerised-system validation. Extend the QMS and validation machinery rather than starting fresh, while being clear that the legal basis and the assessor differ.
“What happens after a high-risk system ships? Is classification a one-time event?” No. Article 72 requires an ongoing post-market monitoring system, part of the technical documentation, that actively collects and analyses field performance data so the provider can keep confirming the system still meets what it was assessed against. Article 73 requires reporting a serious incident, an incident causing death, serious health harm, serious disruption to critical infrastructure, a fundamental-rights infringement, or serious harm to property or the environment, to the market surveillance authority on a tiered clock: 2 days for the most severe or widespread cases, 10 days where death is involved, 15 days by default, all measured from when the provider establishes or has reasonable grounds to believe there is a causal link, not from the incident date.
The Honest Assessment
The EU AI Act is real, broad, and extraterritorial, and for life-sciences companies one of its sharpest edges shows up in combination products, where AI in a device constituent can sit under two demanding frameworks at once. The good news is that most of what the Act asks for in the high-risk tier, risk management, data quality, documentation, traceability, human oversight, monitoring, is work a mature quality organisation already knows how to do. The task is mapping and extending, not reinventing.
The complication is timing. The rollout has run ahead of the standards and guidance needed to implement it, which is why a deferral is on the table. The disciplined response is to build to the original dates, document classification decisions as you go, run the device overlap as a single programme, and keep watching the legal status so a not-yet-final deferral neither lulls you into stopping nor gets relied on as settled law. A company that has inventoried its AI, classified it deliberately, and reused its existing quality machinery will be ready whichever date prevails. A company waiting for the picture to settle will be reconstructing its position under time pressure, which is the harder place to be.