AI systems are embedded across the pharmaceutical R&D pipeline, from target identification through pharmacovigilance signal detection. Regulatory competence has not kept pace: a 2024 survey of life-science professionals found only 9% reported knowing the EU and US AI regulatory frameworks well, with 35% reporting no understanding at all.1Pistoia Alliance, 'Pistoia Alliance Survey Exposes AI Knowledge Gap' (February 2024), reporting that 9% of 125 life-science professionals surveyed self-reported knowing EU and US AI regulations well; cf. Deloitte Insights, 'The Rise of Artificial Intelligence in Biopharma' (accessed February 2026) (documenting near-ubiquitous AI/ML deployment across large-cap pharmaceutical R&D pipelines). That gap collides with the EU AI Act's August 2026 compliance deadline.
1. Risk Classification: Where Pharma R&D Systems Fall
The AI Act (Regulation (EU) 2024/1689) establishes four risk tiers: unacceptable risk (prohibited), high risk, limited risk (transparency obligations), and minimal risk (no specific obligations).2Regulation (EU) 2024/1689 of the European Parliament and of the Council of 13 June 2024 laying down harmonised rules on artificial intelligence [2024] OJ L 2024/1689. The classification determines the compliance burden, and for pharmaceutical R&D, the classification landscape is more complex than it initially appears.
The most consequential category for pharma is "high-risk." Art. 6(1) classifies an AI system as high-risk where it is, or is a safety component of, a product covered by Annex I (which lists the MDR and IVDR) and that product is required to undergo third-party conformity assessment under the Annex I legislation, a threshold met by virtually all MDR Class IIa-and-above and IVDR Class B-and-above devices.3AI Act (n 2), Art. 6(1) and Annex I, Section A, points 11–12 (MDR and IVDR); cf. MDCG 2025-6, 'FAQ on Interplay between the MDR/IVDR and the AI Act' (19 June 2025). That test appears tractable on its face, until applied to the reality of pharmaceutical R&D, where the boundary between a medical device and an internal research tool is functional, not intentional. Art. 6(1) applies from 2 August 2027 under Art. 113(c), one year after the August 2026 deadline for standalone high-risk systems under Annex III, but the classification analysis cannot wait for that later date: determining which pathway applies is itself a prerequisite for compliance planning. A clinical decision support algorithm built as an internal workflow tool may, depending on the claims made about its outputs and its proximity to patient-facing decisions, cross the threshold into medical device territory, a threshold the MDCG's guidance on AI Act/MDR/IVDR interplay acknowledges but does not resolve.
The classification challenge extends beyond medical devices. Art. 6(2) and Annex III capture standalone high-risk AI systems in eight categories, some of which intersect with pharmaceutical operations at the margins (notably biometric processing under Annex III(1), and AI used for public-authority evaluation of eligibility for healthcare benefits under Annex III(5)(a) or for emergency healthcare triage under Annex III(5)(d)). Pharmaceutical R&D is not explicitly listed in Annex III, but the functional scope of several Annex III categories reaches into drug development in ways that depend on how the system is used, not how it was designed. The Annex III classification is not absolute: Art. 6(3) carves out systems that do not pose a significant risk of harm to health, safety, or fundamental rights, subject to four enumerated gating conditions (narrow procedural task, improving a previously completed human activity, detecting decision-making patterns subject to proper human review and not replacing the prior human assessment, or preparatory tasks for Annex III assessments). The umbrella "significant risk" standard is not statutorily defined, however, leaving the carve-out's scope unsettled at the margin. One line in that provision is fixed rather than fuzzy: an Annex III system that performs profiling of natural persons is always high-risk, and the carve-out is unavailable to it.4AI Act (n 2), Art. 6(2) and Annex III (pharma-adjacent points: 1 biometrics; 5(a) eligibility for essential public assistance benefits and services, including healthcare; 5(d) emergency healthcare triage); Art. 6(3) and its closing subparagraph (an Annex III system performing profiling of natural persons is always high-risk); "significant risk" is not defined in Art. 3.
2. The Threshold the Classification Assumes: Does the Act Reach R&D at All?
The classification analysis presupposes a prior question: whether the AI Act reaches a given research system at all. For pharmaceutical R&D, that premise is not automatic. The Act carves two exclusions out of its own scope that bear directly on the discovery and preclinical phases. Under Art. 2(6), the Regulation does not apply to AI systems or models, including their output, developed and put into service for the sole purpose of scientific research and development. Under Art. 2(8), it does not apply to research, testing, or development activity on AI systems or models before they are placed on the market or put into service. A large share of target identification, in-silico screening, and internal modeling plausibly sits inside one exclusion or the other, which means the August 2026 and August 2027 deadlines do not bite in the laboratory.5AI Act (n 2), Art. 2(6) (AI developed and put into service for the sole purpose of scientific research and development), Art. 2(8) (research, testing or development prior to placing on the market or putting into service) and Recital 25; on clinical-stage recapture cf. AI Act (n 2), Art. 60 (testing in real world conditions) and MDCG 2025-6 (n 3).
The exclusions are narrower than they first read. Recital 25 confines them: a system used for anything beyond pure research, or one that crosses from development into deployment, loses the benefit. The pivot in Art. 2(8) is sharper still. Its closing sentence withdraws the exclusion for testing in real-world conditions, and MDCG 2025-6 indicates that MDR clinical investigations and IVDR performance studies generally constitute exactly that. A diagnostic or decision-support model that is exempt while it is being built re-enters scope the moment it is tested on patients in a clinical investigation. The boundary the analysis most needs to locate is therefore not the August deadline but the line between development and the first real-world test.
For a US reader, the intuition carried over from domestic practice, that internal research tooling operates in a lightly governed space until a product is submitted, is half right and half dangerous. It holds for genuine discovery work that never leaves the research environment. It fails the moment the same model is repurposed toward a regulated output, because the AI Act fixes scope by use, not by the function that built the tool. Whether a model trained for discovery and later consulted in designing a clinical protocol still serves the sole purpose of research is precisely the question the Regulation leaves open, and the answer turns on facts internal to how the model is used.
3. High-Risk AI in Pharma R&D: The Compliance Requirements
For AI systems classified as high-risk, the AI Act imposes seven substantive requirements under Chapter III, Section 2 (Art. 9–15), preceded by an Art. 8 chapeau that integrates them with existing Union harmonisation procedures.6AI Act (n 2), Chapter III, Section 2 (Art. 8–15): Art. 8 (compliance chapeau), Art. 9 (risk management), Art. 10 (data governance), Art. 11 (technical documentation), Art. 12 (record-keeping), Art. 13 (transparency), Art. 14 (human oversight), Art. 15 (accuracy, robustness, cybersecurity). The requirements span risk management, data governance, transparency, human oversight, and cybersecurity. Their interaction with pharmaceutical-specific regulatory obligations (GCP, GMP, pharmacovigilance) is where the compliance architecture becomes complex, because the AI Act's requirements overlap with but do not map onto existing pharmaceutical quality frameworks.
For pharmaceutical R&D, several of these requirements present specific challenges. Art. 10 requires training datasets to have appropriate statistical properties for the intended purpose, including representativeness for the persons or groups to whom the system will apply. This intersects uncomfortably with known biases in clinical trial populations: an AI system trained predominantly on data from European or North American clinical trials may fail the representativeness standard if its intended purpose extends to broader populations, even if the underlying trial data met all applicable GCP requirements at the time of collection. Where that representativeness gap is to be closed by drawing on broader real-world health data, a second framework converges on the same problem: the European Health Data Space provides for the secondary use of electronic health data, including for the training and testing of AI systems, yet its secondary-use regime is scheduled to apply only from 2029. The data source that might one day satisfy Art. 10 is not operational on the timeline the high-risk obligations run to.7Regulation (EU) 2025/327 of the European Parliament and of the Council of 11 February 2025 on the European Health Data Space (EHDS Regulation) [2025] OJ L 2025/327; the secondary-use chapter lists training, testing and evaluation of AI systems among permitted purposes, with most secondary-use provisions applying from 2029.
The logging requirement under Art. 12 creates a tension with pharmaceutical data integrity obligations. EU GMP Annex 11 (Computerised Systems) already imposes audit trail requirements on computerised systems used in pharmaceutical manufacturing and quality control. The AI Act's logging requirements are broader in scope and differently structured, creating the prospect of parallel but non-identical logging obligations for the same AI system, depending on whether the system falls within GMP scope, AI Act scope, or both.
These requirements primarily bind providers (typically the AI developer or vendor), but deployers face a parallel layer. Art. 26 requires the deployer to follow the provider's instructions for use, maintain human oversight, and retain the system's automatically generated logs for at least six months. Art. 50 adds transparency obligations toward natural persons interacting with the system. Art. 27 layers on a fundamental rights impact assessment, but only for deployers that are bodies governed by public law, that provide public services, or that run the narrow Annex III uses in creditworthiness and insurance. A commercial pharmaceutical company deploying clinical-research AI is generally none of those, so the much-discussed fundamental rights impact assessment usually does not attach to it at all. The assessment that does attach sits in a different instrument: processing clinical data through an AI system almost always triggers a data protection impact assessment under Art. 35 GDPR, and Art. 22 GDPR constrains decisions taken solely by automated means where an algorithm screens or excludes trial participants. Deployer status is the more common posture for pharmaceutical companies, and the load-bearing obligations are the Art. 26 oversight-and-logging duties and the GDPR assessment, not the fundamental rights impact assessment that most AI Act commentary foregrounds.8Regulation (EU) 2016/679 of the European Parliament and of the Council of 27 April 2016 on the protection of natural persons with regard to the processing of personal data (GDPR) [2016] OJ L119/1, Art. 35 (data protection impact assessment) and Art. 22 (automated individual decision-making); cf. AI Act (n 2), Art. 26, Art. 27 and Art. 50.
For most pharmaceutical deployers, the binding assessment is not the AI Act's fundamental-rights review but the data protection impact assessment the GDPR already required.
4. The MDR/AI Act Convergence: Dual Conformity Assessment
AI systems that qualify as medical devices are the category most immediately relevant to pharmaceutical companies developing companion diagnostics, clinical decision support tools, or software as a medical device (SaMD). For these systems, the AI Act creates a dual compliance burden that compounds the already substantial MDR requirements.
Under the AI Act as adopted, the framework does not create a separate conformity assessment procedure for AI-enabled medical devices. Instead, it integrates the AI Act requirements into the existing MDR conformity assessment pathway: notified bodies conducting MDR assessments must also verify compliance with the AI Act's high-risk requirements.9AI Act (n 2), Art. 6(1) and Art. 43(3); cf. European Commission proposal COM(2025) 836 final (Digital Omnibus on AI, 19 November 2025) clarifying integration into existing product safety frameworks. This integration is conceptually elegant but practically demanding: notified bodies must develop competence in both regulatory frameworks, and manufacturers must produce technical documentation that satisfies both the MDR's General Safety and Performance Requirements (GSPR, Annex I) and the AI Act's Chapter III obligations simultaneously. The pool of notified bodies equipped to assess an AI-embedded device against both regimes is narrow, and that scarcity compounds the device-route timeline rather than relieving it: the additional year to August 2027 is set against an assessment that fewer bodies are competent to perform.
The November 2025 Digital Omnibus proposal, the Commission's response to industry concerns about implementation readiness, addresses some coordination issues but does not fundamentally simplify the dual assessment. The proposed amendments clarify that a single conformity assessment procedure covers both MDR and AI Act requirements for medical device AI, and that notified bodies may rely on the AI Act's harmonized standards (once adopted) as a basis for presumption of conformity. The proposal also contemplates linking application of the high-risk rules to standards availability, with a fallback timeline extending the standalone-system deadline to 2 December 2027 and the embedded-system deadline to 2 August 2028. Whether and in what form the proposal is adopted remains pending, and the harmonized standards themselves are still in development: CEN-CENELEC JTC 21 (Artificial Intelligence) has published working drafts but no final harmonized standards as of early 2026.10CEN-CENELEC JTC 21 (Artificial Intelligence), Work Program (2025) and accompanying progress reporting; Commission Implementing Decision C(2023) 3215 of 22 May 2023 (Standardisation Request M/593), repealed and replaced by Commission Implementing Decision C(2025) 3871 of 23 June 2025; no final harmonized standards published in the Official Journal as of February 2026.
For US pharma companies developing AI-enabled medical devices at German R&D sites, this creates a practical problem: the regulatory pathway requires notified body assessment against standards that do not yet exist in final form. The interim approach, demonstrating compliance through technical documentation aligned with draft standards and existing ISO/IEC frameworks (particularly ISO/IEC 42001:2023 for AI management systems and ISO 14971 for risk management), carries inherent uncertainty about whether the documentation will satisfy the final harmonized standards when they are published.
5. General-Purpose AI: The Obligations Already in Force
While the high-risk deadline dominates planning discussions, the AI Act's obligations for general-purpose AI (GPAI) models took effect on 2 August 2025, and as of early 2026, many pharmaceutical companies had not audited their exposure.11AI Act (n 2), Art. 113(b) (Chapter V, including GPAI obligations under Art. 51–56, applicable from 2 August 2025); cf. Art. 111(3) (transitional provision deferring full compliance to 2 August 2027 for GPAI models placed on the market before 2 August 2025); on downstream modification or fine-tuning that makes a deployer a provider, Art. 25 and Recital 109.
The GPAI obligations under Art. 51–56 apply to providers of general-purpose AI models, meaning the companies that develop and make available the foundation models. For pharmaceutical companies that deploy GPAI models (rather than develop them), the primary obligation is to ensure that their use of the GPAI model's outputs complies with downstream regulatory requirements. But the boundary between "provider" and "deployer" is not always clear in pharmaceutical R&D: a company that fine-tunes a foundation model on proprietary clinical data may, depending on the degree of modification, become a "provider" of a new AI model, with the corresponding obligations.
The practical risk is less about the GPAI model itself than about its integration into regulated processes. A large language model used internally for literature review carries different regulatory exposure than the same model integrated into a clinical trial protocol design workflow or a pharmacovigilance signal detection pipeline. The AI Act does not regulate the model in isolation; it regulates the system in context. And the context of pharmaceutical R&D is one where AI system outputs frequently feed into regulated decisions: submissions to BfArM, safety reports to EMA, clinical study reports supporting marketing authorization applications. A contract with a GPAI provider can allocate responsibility for model performance. It cannot allocate the regulatory consequence of a BfArM submission that relied on AI-generated analysis. That consequence attaches to the marketing authorization holder.
6. Liability Beyond the Administrative Fines
The fine schedule is only one axis of exposure, and for a product company it is rarely the largest. The revised Product Liability Directive brings software and AI systems squarely within the definition of a defective product, extends to defects introduced by post-market updates and learning behavior, and introduces disclosure duties and rebuttable presumptions that ease a claimant's burden of proving defect and causation in technically complex cases. Member States must transpose it by 9 December 2026, inside the window in which the high-risk obligations begin to bite.12Directive (EU) 2024/2853 of the European Parliament and of the Council of 23 October 2024 on liability for defective products and repealing Council Directive 85/374/EEC (PLD) [2024] OJ L 2024/2853; brings software and AI systems within "product"; rebuttable presumptions of defectiveness and causation; transposition by 9 December 2026. A US reader anchored in domestic product-liability practice will recognize the shape but not the burden-shifting: the presumptions run against the manufacturer in precisely the situations where an AI system's opacity would otherwise defeat a claim.
The companion instrument that would have addressed fault-based AI liability, the proposed AI Liability Directive, has been withdrawn, leaving the product-liability regime to carry the civil-exposure weight on its own, with the gaps that implies for purely economic loss and for harms outside the directive's defined damage categories.13Commission, 'Proposal for a Directive on adapting non-contractual civil liability rules to artificial intelligence (AI Liability Directive)' COM(2022) 496 final, listed for withdrawal in the Commission Work Programme 2025 and subsequently withdrawn. An AI-driven adverse outcome in a clinical or diagnostic setting is, for many systems, a more probable loss path than an AI Act enforcement action, and it travels back to the US balance sheet through the same channels any product-liability exposure does.
7. The German Implementation Context: Concurrent Frameworks, Incomplete Authority
Germany's implementation of the AI Act occurs against the backdrop of several concurrent regulatory developments that amplify the compliance burden for pharmaceutical R&D operations.
The German standard contractual clauses for commercial clinical trials of medicinal products (Standardvertragsklauselverordnung, StandVKlV; distinct from the GDPR Standard Contractual Clauses for international data transfers), applicable to contracts concluded from 18 December 2025, impose specific data governance requirements on clinical trial agreements that overlap with the AI Act's data governance obligations under Art. 10. Where clinical trial data is used to train or validate AI systems, the contractual framework governing that data must accommodate both the StandVKlV clauses and the AI Act's data quality requirements. The interaction is not seamless: the StandVKlV clauses address data controllership and processing purposes, while the AI Act addresses data representativeness and bias, different dimensions of the same underlying data governance challenge.14Verordnung über Standardvertragsklauseln für die Durchführung klinischer Prüfungen (Standardvertragsklauselverordnung, StandVKlV), Art. 1 of the Verordnung zur Vereinfachung der Durchführung und Genehmigung klinischer Prüfungen, BGBl. 2025 I Nr. 215, applicable to contracts concluded from 18 December 2025; cf. AI Act (n 2), Art. 10.
The joint BfArM/Paul-Ehrlich-Institut application portal on PharmNet.Bund, operational since 1 July 2025 under the Medizinforschungsgesetz (MFG, BGBl. 2024 I Nr. 324, in force 30 October 2024), offers regulatory scientific advice on medical device and pharmaceutical questions, which may include AI classification questions where the system is part of a regulated product. As is standard for regulatory scientific advice, the output is non-binding; capacity is limited, and the interplay between BfArM's advice on AI classification and the AI Act's conformity assessment pathway, administered through notified bodies, not BfArM, creates a coordination gap that companies must bridge themselves. The result is a regulatory-advice channel that addresses one piece of the compliance puzzle but cannot deliver binding clarity on the AI Act question.
As of early 2026, Germany's enforcement architecture remains incomplete. The AI Act required Member States to designate national competent authorities for AI Act supervision by 2 August 2025 under Art. 70. Germany did not meet that deadline: although the Bundesnetzagentur has stood up a preparatory KI-Service Desk and is earmarked as the prospective national supervisory authority, formal statutory designation awaits dedicated implementing legislation, and the allocation of supervisory responsibility between the Bundesnetzagentur (AI Act) and BfArM (pharmaceutical and medical device regulation) for AI systems at the intersection of both frameworks remains unresolved.15AI Act (n 2), Art. 70 (designation of national competent authorities; 2 August 2025 deadline under Art. 113(b), missed by Germany pending dedicated implementing legislation); Bundesnetzagentur, 'KI-Service Desk' (3 July 2025); for AI systems covered by Union harmonization legislation in Annex I Section A, market-surveillance competence is allocated to the relevant sectoral authority under Art. 74. A US pharma company deploying an AI system in clinical trials at a German site may face supervisory questions from two authorities with different mandates and potentially different interpretations of the same regulatory text.
8. Beyond the EU: The FDA Baseline and the Swiss Parent
A US pharmaceutical company reading this against its own regulatory map is anchored in the FDA's approach to AI, which by early 2026 runs through the FDA's draft guidance on the use of artificial intelligence to support regulatory decision-making for drug and biological products and its risk-based, context-of-use credibility framework.16FDA, 'Considerations for the Use of Artificial Intelligence to Support Regulatory Decision-Making for Drug and Biological Products' (draft guidance, January 2025), establishing a risk-based credibility-assessment framework keyed to the model's context of use. The instinct to treat AI Act conformity as a European recharacterization of that framework is the trap. The FDA's model is risk-based, specific to a context of use, oriented to a submission, and issued as non-binding draft guidance; the AI Act is horizontal, fixed by product classification rather than context of use, oriented to a conformity assessment, and backed by binding fines. Documentation built to satisfy the FDA's credibility framework does not transfer into an AI Act technical file, and showing that a model is credible for a defined context of use does not establish that it meets the Art. 10 data-governance or Art. 14 human-oversight obligations. The two regimes ask different questions, and satisfying one leaves the other open.
The Basel-headquartered side of the same corporate group sits in a third position again. Switzerland has decided against a horizontal AI statute, opting for a sector-specific approach and the ratification of the Council of Europe's AI Convention, which it signed in March 2025.17Schweizerischer Bundesrat, 'Auslegeordnung zur KI-Regulierung: der Bundesrat will die KI-Konvention des Europarats ratifizieren' (Medienmitteilung, 12 February 2025); Council of Europe Framework Convention on Artificial Intelligence and Human Rights, Democracy and the Rule of Law (CETS No. 225, 2024), signed by Switzerland on 27 March 2025; on Swiss data protection, Bundesgesetz über den Datenschutz (DSG) vom 25. September 2020 (SR 235.1). A Swiss parent therefore faces no domestic AI act of the kind its German subsidiary must satisfy. That asymmetry is deceptive, because the AI Act reaches providers and deployers established outside the EU where the output of their AI systems is used within it. A model run from a Swiss head office but feeding a German clinical or regulatory process is not outside the Regulation by virtue of its location, and the question of which group entity is the provider and which the deployer does not resolve along the corporate-structure lines a US parent might assume.
9. The Compliance Architecture Problem: Inventory, Timeline, and Cascade
The compliance timeline is not abstract. Pharmaceutical companies deploying standalone high-risk AI systems (Annex III) in the EU, including at German R&D sites, must have conformity assessments completed, technical documentation prepared, and quality management systems operational by 2 August 2026. AI systems classified as high-risk through the medical device route under Art. 6(1) face the same substantive requirements but with an application date of 2 August 2027 (Art. 113(c)). The extra year is less generous than it appears: the dual MDR/AI Act conformity assessment for device-route systems is substantially more demanding, and the notified body capacity constraints are already apparent. For AI systems already in use under either pathway, this is not a greenfield exercise but a retroactive compliance program that must be layered onto operational systems without disrupting ongoing R&D activities.
Most pharmaceutical companies lack a comprehensive inventory of the AI and machine learning systems deployed across their EU operations. AI systems were adopted incrementally, often by individual R&D teams, without centralized registration or classification, because until the AI Act, no regulatory framework required it. The retroactive discovery that an organization does not know how many AI systems it operates, what risk tier they fall into, or which regulatory overlays (MDR, IVDR, GMP, GCP) apply to each is itself a compliance finding. And the scope of that discovery exercise (how broadly "AI system" is defined under Art. 3(1), whether rule-based decision tools qualify, where the boundary falls between a validated statistical model and an AI system) is not settled by the regulation or the guidance published to date.
The penalty framework provides urgency. Administrative fines under the AI Act reach up to EUR 35 million or 7% of the preceding financial year's total worldwide annual turnover, whichever is higher, for violations of the prohibited practices provisions; up to EUR 15 million or 3% for other violations, including non-compliance with high-risk requirements.18AI Act (n 2), Art. 99 (fines); the 7% threshold applies to prohibited AI practices under Art. 5; the 3% threshold applies to non-compliance with obligations for high-risk AI systems under Art. 8–15. For a large US pharmaceutical company, the 3% threshold on global turnover translates to nine-figure exposure, against which the cost of retroactive compliance is negligible.
But the deeper risk is not financial. It is operational: an AI system found non-compliant with the AI Act's high-risk requirements after August 2026 may need to be withdrawn from use, which, if the system is integrated into an ongoing clinical trial or a marketed medical device, creates regulatory continuity problems that extend well beyond the AI Act itself. The intersection between AI Act non-compliance and GCP, GMP, or MDR obligations means that an AI Act enforcement action can trigger cascading regulatory consequences across multiple frameworks simultaneously.
These are not questions that a single compliance function can resolve in isolation. Regulatory affairs may understand the AI Act classification; IT governance may understand the technical documentation requirements; neither may understand how their assumptions interact, and the compliance program may memorialize that gap rather than bridge it. The same indeterminacy runs along the value chain: the line between provider and deployer that decides who carries the Art. 8–15 obligations is movable, because a deployer that fine-tunes or repurposes a system can become its provider, and the allocation a contract records may not match the allocation the Regulation imposes.
The August 2026 deadline converts what would otherwise be a strategic question into an operational one, with a timeline that leaves limited room for the discovery that the underlying compliance architecture does not yet exist.