AI Governance in Life Sciences: A Practical Guide

Life sciences companies have been governing high-stakes technology for decades. GxP, 21 CFR Part 11, ISO 13485, ISO 14971 — the muscle memory for validating something before it touches a patient is already there. What's new with AI is not the discipline of governance. It's that the object being governed keeps changing after you've approved it.

A locked software function does the same thing every time you run it. A machine learning model, especially one with a defined retraining schedule, does not — and the regulatory frameworks written for static systems assume a kind of stability that adaptive AI simply does not offer. That gap is the whole problem this guide is about, and it's why "AI governance life sciences" searches keep landing on generic AI risk content that never quite answers the question a pharma quality lead or a medtech regulatory affairs director actually has: what do I file, what do I validate, and who signs off when the model drifts?

Why Life Sciences AI Governance Is a Different Problem

In most industries, AI governance is a compliance overlay on top of an existing product. In life sciences, AI touches products that are already regulated end to end — a diagnostic algorithm sits inside a medical device regulated under the EU's Medical Device Regulation (MDR) or In Vitro Diagnostic Regulation (IVDR); a manufacturing anomaly-detection model sits inside a process governed by 21 CFR Part 211; a clinical trial patient-matching tool sits inside a protocol reviewed by an IRB and, eventually, FDA.

That means AI governance in this sector is never a standalone discipline. It has to reconcile with quality management systems already in place under ISO 13485:2016, with risk management under ISO 14971:2019, with computer system validation practices, and with sector-specific regulatory expectations that are still being written in real time. The organizations getting this right are not bolting an "AI policy" onto their QMS. They're extending the QMS itself to treat a model as a controlled asset with its own lifecycle, the same way they already treat a piece of manufacturing equipment or a validated spreadsheet.

The Regulatory Landscape, Segment by Segment

FDA and Medical Device Software

FDA's clearest statement on AI-enabled devices is the "Good Machine Learning Practice for Medical Device Development: Guiding Principles," issued jointly with Health Canada and the UK's MHRA in October 2021. It lays out ten principles, covering things like multi-disciplinary expertise throughout the product lifecycle, representative training data, and human factors considerations — but the principle with the most practical teeth is the expectation that a device's performance monitoring plan account for real-world data drift, not just pre-market validation data.

The mechanism that actually operationalizes ongoing model change is the Predetermined Change Control Plan (PCCP), first proposed in FDA's April 2023 draft guidance and finalized in December 2024 as "Marketing Submission Recommendations for a Predetermined Change Control Plan for Artificial Intelligence-Enabled Device Software Functions." A PCCP lets a manufacturer pre-specify, at the time of clearance, exactly what changes a model is allowed to make on its own — a bounded retraining schedule, a defined performance floor — without triggering a new 510(k). Without one, every retraining event is a potential new submission. I've seen manufacturers treat the PCCP as a paperwork formality rather than the governance instrument it actually is; the plan only works if the verification methods and acceptance criteria in it are ones your quality system can actually execute on schedule.

Pharma and Drug Development

FDA published draft guidance in January 2025, "Considerations for the Use of Artificial Intelligence to Support Regulatory Decision-Making for Drug and Biological Products," which introduces a risk-based credibility assessment framework for AI models used anywhere in the drug development lifecycle — including models that never touch a patient directly, like ones used in target identification or trial design. The credibility of the AI output is assessed relative to the specific regulatory decision it supports, not in the abstract, which means the same model can require a thin justification for an exploratory use and a heavily documented one for a use that informs a labeling claim.

The European Medicines Agency's parallel statement is the "Reflection Paper on the Use of Artificial Intelligence in the Medicinal Product Lifecycle" (EMA/CHMP/CVMP/83833/2023), adopted in July 2023. It applies across the full lifecycle — discovery, nonclinical, clinical, and post-authorization — and explicitly flags the need for human oversight proportionate to risk, echoing language that shows up again in the EU AI Act.

Medical Devices Under the EU AI Act

Regulation (EU) 2024/1689 (the EU AI Act) doesn't need a separate high-risk list for most medical device AI — Article 6(1) classifies an AI system as high-risk automatically when it's a safety component of a product already covered by MDR or IVDR and required to undergo third-party conformity assessment. That means most Class IIa, IIb, and III AI-enabled devices inherit high-risk status by reference, and manufacturers now have to run two conformity assessments in parallel: the existing MDR/IVDR notified body review and the AI Act's Chapter III, Section 2 high-risk obligations (Articles 9–15) — risk management system, data governance, technical documentation, human oversight — which apply here because the device is classified via Annex I's list of harmonisation legislation, not the standalone Annex III use-case list, with post-market monitoring covered separately under Article 72.

The Standards Layer

Underneath the regulations sits a standards stack that gives you the actual mechanics:

• ISO/IEC 42001:2023 covers the AI management system itself. Clause 6.1.2 covers AI risk assessment, and Annex A gives 38 controls you can map directly to GxP requirements.
• ISO 14971:2019 covers medical device risk management. Most AI-enabled device manufacturers already have it wired into their QMS and simply need to extend it to cover algorithmic failure modes.
• ISO/IEC 23894:2023 covers AI-specific risk management guidance, filling gaps ISO 14971 wasn't written to address — data drift and model degradation among them.

Comparing the Frameworks

Building the Program: What Actually Has to Exist

1. Model Inventory and Risk Classification

You cannot govern what you have not inventoried. Every AI-enabled system in the organization — including the ones procurement bought as part of a vendor's SaaS platform and nobody flagged as "AI" — needs a record: what it does, what data trains it, what decision it informs or automates, and what happens if it's wrong. Classify each one by the regulatory frame it falls under (device software, GMP process control, clinical decision support, internal drug discovery tool) because the governance obligations differ sharply by category. A model that recommends a manufacturing batch release parameter carries a different risk profile than one that summarizes literature for a medical writer, even though both might sit on the same internal ML platform.

2. Model Documentation as a Living Record

Regulators increasingly expect documentation that reads less like a one-time validation report and more like a device history file: training data provenance, intended use statement, performance characteristics across the populations the model will actually see, known limitations, and — critically — a defined monitoring plan for what happens after deployment. If the model has a PCCP or an equivalent internal change-control mechanism, the documentation needs to show the boundaries of what can change without re-review, not just what the model does today.

3. Validation That Accounts for Drift

Computer system validation practices built for static software don't map cleanly onto a model that updates. The fix isn't to abandon validation rigor, it's to validate the process that governs change, not just the artifact at a point in time. That means defining acceptance criteria for retraining before it happens, setting a performance floor that triggers a hold if a model drifts below it, and keeping the validation evidence tied to a specific model version, not the product name in general.

4. Human Oversight That's Actually Specified

"Human oversight" shows up in nearly every framework above, and it's the requirement most often satisfied on paper and not in practice. A named reviewer with the authority to override the model, a defined escalation path when confidence scores fall outside expected ranges, and evidence that the override actually happens sometimes — not just that it's theoretically possible — is what separates real oversight from a checkbox in a policy document.

5. Post-Market Monitoring and Pharmacovigilance Integration

For device software, this ties into existing post-market surveillance obligations. For anything touching drug safety signals, it has to connect to the existing pharmacovigilance system rather than running as a parallel process nobody reconciles. An AI model that flags adverse event patterns is itself a safety-relevant system, and its own failure modes need to be monitored with the same seriousness as the signals it's meant to detect.

Where Programs Actually Fail

In my experience, the two most common gaps aren't technical:

• Governance sits in the wrong department. Treating AI governance as a document exercise that lives in the quality department, disconnected from the data science team actually building and retraining models, produces a beautiful policy nobody follows because it was never built around how the models actually get updated.
• The inventory is under-scoped. Teams govern the AI systems that were formally procured through IT and miss the ones embedded inside a vendor's LIMS upgrade or a CRO's data analytics platform — exactly where an auditor or a notified body will look first.

The organizations that get this right usually start smaller than they'd like: one model, fully documented and monitored end to end, used as the template the rest of the inventory gets built against — rather than a comprehensive framework that looks complete on paper and has never been tested against a real model change.

FAQ

Does ISO 42001 certification satisfy FDA or EU AI Act requirements for medical device AI? No single certification substitutes for regulatory clearance. ISO/IEC 42001:2023 certifies that an organization's AI management system meets an international standard, which can serve as supporting evidence in a regulatory submission and helps satisfy EU AI Act Article 17's quality management system obligations, but it does not replace FDA's 510(k)/De Novo pathway or EU MDR/IVDR conformity assessment.

Do I need a Predetermined Change Control Plan for every AI-enabled device? Not by law, but without one, every model update capable of changing device performance is a candidate for a new marketing submission. FDA's December 2024 final guidance describes the PCCP as optional, but for any device where retraining is a foreseeable part of the lifecycle, skipping it means re-litigating clearance with every meaningful update.

Is a large language model used for internal drug discovery research subject to the same governance as a clinical AI tool? The regulatory obligations differ, but the governance principles don't disappear just because a model never touches a patient directly. FDA's January 2025 draft guidance on AI in drug development applies a credibility framework scaled to how much a regulatory decision relies on the model's output, so a discovery-stage tool used to prioritize compounds carries lighter documentation burden than one informing a submission claim, but it still needs to be inventoried and assessed.

How does the EU AI Act interact with a device already CE-marked under MDR? Article 6(1) of Regulation (EU) 2024/1689 classifies AI systems as high-risk automatically when they're safety components of products requiring third-party conformity assessment under MDR or IVDR. That means the AI Act's Chapter III, Section 2 obligations — triggered here through Annex I, not the standalone Annex III use-case list — run in parallel with the existing MDR conformity assessment, not as a replacement for it — manufacturers need both files current at once.

What's the single most common documentation gap regulators flag in AI-enabled device submissions? A monitoring plan that doesn't specify a quantitative performance floor. Manufacturers frequently document what the model does and how it was trained, but leave the post-market monitoring plan qualitative — "we will monitor for performance degradation" — without stating the metric, the threshold, or the action triggered when it's crossed.

Governance in this sector isn't about picking the right framework off a shelf. It's about building the inventory, documentation, and change-control muscle that lets your quality system treat a model the way it already treats every other regulated asset — which is the same work life sciences companies have been doing for GxP compliance all along, just applied to something that doesn't hold still. If your organization is mapping AI governance obligations against an existing quality system, our healthcare and pharma advisory work and our deeper look at governing machine learning inside validated pharmaceutical systems walk through the GxP-specific mechanics in more depth.

Last updated: 2026-09-06