News
|
August 12, 2026
AI Governance in Life Sciences: What FDA and EMA Now Expect
Life Sciences
Back to All News
FDA and EMA now expect documented provenance for AI used in drug development. Here’s why controlling your documents isn’t the same as governing the data your AI reads from them.
Ask any regulated life sciences company who approved a given document, when, and which version is current, and you’ll get an answer in about four clicks. Veeva Vault or Documentum will tell you. That’s what those systems are for, and they do it well.
Now ask a harder question. Last Tuesday, when your AI drafting assistant produced a paragraph of a health authority response, what exactly did it read? Which document, which version, which page? Was that version still approved at the time? Has it been superseded since, and if it has, does anyone know the draft is now stale?
Most organizations can’t answer that. Not because they’ve been careless, but because nothing in the existing stack was ever built to. And it matters more this year than last, because in January 2026 the FDA and EMA jointly published ten principles for AI in drug development, and a striking number of them are about documentation, provenance, and traceability rather than about models at all.
Here’s the thesis: your document management system governs documents. Your AI doesn’t read documents. It reads a derivative of them (extracted text, chunks, embeddings, tables pulled out of PDFs) and that derivative layer sits almost entirely outside your validated environment. Closing that gap is now the practical work of AI governance in life sciences.
Both agencies expect you to define what an AI model is for, show evidence it’s fit for that specific purpose, document how its data was sourced and handled, and keep a human accountable for the regulatory decision. Neither prohibits AI. Both have shifted the burden from permission to proof.
The clearest statement of this is the joint publication from January 14, 2026: Guiding Principles of Good AI Practice in Drug Development, issued by FDA and EMA together. Ten principles. Several are worth reading twice if you run regulatory operations:
Principle 4 is clear context of use: the specific task the model performs and the weight its output carries in a regulatory decision.
Principle 6 is data governance and documentation, and the language is direct: data source provenance, processing steps, and analytical decisions should be documented in a detailed, traceable, and verifiable manner, in line with GxP requirements.
Principle 9 is life cycle management, which asks for scheduled monitoring and periodic re-evaluation rather than a one-time qualification.
That joint document builds on a body of work already in place. FDA’s January 2025 draft guidance, Considerations for the Use of Artificial Intelligence To Support Regulatory Decision-Making for Drug and Biological Products (docket FDA-2024-D-4689), introduced Context of Use (COU) and a risk-based credibility assessment framework, the idea being that the evidence you owe scales with how much the model’s output influences a regulatory decision. As of this writing the guidance remains in draft and is marked “not for implementation,” which some teams read as permission to wait. That’s a misread. Draft guidance tells you where the agency’s thinking is going, and this one has been consistent for eighteen months.
On the device side, FDA finalized Marketing Submission Recommendations for a Predetermined Change Control Plan for Artificial Intelligence-Enabled Device Software Functions in August 2025. Different regulatory area, same underlying logic: say in advance how the model will change, how you’ll evaluate it, and what evidence you’ll keep.
EMA’s reflection paper on AI in the medicinal product lifecycle rounds out the picture on the European side.
Read across all of it and the through-line is boring, in the best way. Define the use. Prove it fits. Document the data. Keep a person responsible. None of that is exotic to anyone who has lived through a Part 11 audit.
Because your AI doesn’t consume documents. It consumes data extracted from documents, and that extraction is where governance stops.
Walk the actual path. An approved Clinical Study Report lives in Vault, versioned and locked. To make it usable by a retrieval-augmented generation system, something has to open that PDF, convert it to text, decide what to do with the tables, split the result into chunks, and write those chunks into a vector index. Only then does the AI see anything.
Every step in that chain is a place where fidelity is lost and lineage is dropped. A table that renders correctly in the PDF becomes a run-on paragraph of numbers. A chunk boundary lands mid-sentence and severs a qualifier from the claim it was qualifying. A footnote that scoped the result to a subpopulation gets separated from the result. The AI then reasons over the wreckage, fluently.
And here’s the part that should worry you more: that index is usually a snapshot. When version 4.0 of the CSR supersedes version 3.0 in Vault, the chunks derived from 3.0 don’t necessarily go anywhere. Nobody approved them. Nobody versioned them. Nobody scheduled their retirement. They just sit in the index, still perfectly retrievable, still sounding authoritative.
Your DMS governs a document you’re no longer using. Nothing governs the copy your AI is actually reading.
This is what Principle 6 is pointing at when it asks for documented provenance and processing steps. Not “where is the source document”, most companies can answer that. But “what happened to it between the repository and the model,” which is a different question, and one most stacks weren’t designed to answer.
ALCOA+ has a useful vocabulary here, even though it predates all of this. Attributable, legible, contemporaneous, original, accurate, complete, consistent, enduring, available. Apply those nine words not to the CSR but to the chunk of extracted text your AI retrieved. Attributable to which version? Contemporaneous with what? Original in what sense, when it’s a lossy conversion nobody validated?
The framework holds up. It’s just being applied one layer too high.
Not at generation. Pilots break at traceability, at staleness, and at the point where human review stops scaling, usually all three at once, and usually right after the pilot succeeds.
Traceability first. A statement that can’t be traced to a specific version of a specific document in a specific CTD module can still be true. It just can’t be defended efficiently. Your reviewer becomes an archaeologist, reconstructing where the sentence probably came from. That’s not a review process. It’s a search process with a review at the end of it.
Then staleness. This one is genuinely dangerous because it produces no error signal at all. Retrieval from a superseded document returns a confident, well-formed, sourced-looking answer. There’s no exception thrown, no flag raised. The only way to catch it is to already know the right answer, which rather defeats the purpose.
Then scale. A pilot with three reviewers and forty documents is manageable by inspection, people notice when something looks wrong. Push to three hundred documents and thirty reviewers across four submission types, and inspection stops working. The controls that carried the pilot were informal and human, and they don’t survive contact with volume.
Agentic systems compress this timeline hard. When one AI step’s output becomes the next step’s input (retrieve, then draft, then check, then revise) an ungoverned source at step one propagates through everything downstream, and the audit trail you need is not a log of what the model said but a record of what it read at each hop.
The pattern is consistent enough to state as a rule: a regulatory AI pilot doesn’t fail because the model was bad. It stalls because the evidence underneath it was never governed, and nobody discovers that until the pilot works well enough to expand.
It means the data your AI reads is treated as a regulated artifact in its own right - versioned, lineage-tracked, tied to an approved source, and retired when that source is superseded. The extracted layer gets the same discipline the document layer already has.
1. Extraction has to be accurate and repeatable. If two runs over the same PDF produce different text, you have no baseline to validate against. Tables, footnotes, and figure captions carry disproportionate regulatory weight and are exactly what naive extraction mangles.
2. Every derived fragment has to carry its lineage. Not “this came from the CSR” but this came from version 3.2, section 11.4, page 213, approved on this date, extracted by this process on this date. That’s the record Principle 6 is asking for, and it has to be captured at extraction time. You cannot reconstruct it later.
3. The layer has to stay current with the source. When a document is superseded, the fragments derived from it need to be invalidated or refreshed, automatically, as a property of the system, not as a quarterly cleanup task somebody owns in a spreadsheet.
4. It has to be inspectable. Someone should be able to ask, six months after a submission, what the model read on a given date, and get an answer without a forensics project.
Note what this is not. It’s not a replacement for Vault or Documentum, those remain the system of record for approved content, and they should. It’s a layer underneath the AI and downstream of the repository, doing a job neither the DMS nor the model was built for.
This is where document processing platforms like Adlib fit. Adlib provides the document accuracy and traceability layer between validated repositories and the AI tools reading from them: high-fidelity extraction, preserved lineage back to approved source, and the ability to link an AI-generated answer to the specific document and version behind it, without displacing the systems of record your quality organization already validated.
The honest framing is that this is unglamorous infrastructure. It doesn’t demo well. But improving what your AI reads reliably outperforms improving which model reads it, and the teams who figured that out early are the ones whose pilots made it into production.
Five questions. If your team can’t answer all five about a given tool, the tool isn’t ready for regulated work, regardless of how well it writes.
• Can every AI-generated statement be traced to a specific document version, not just a document?
• Is the model’s context of use (COU) defined and written down for this specific task?
• When a source document is superseded, what happens to the extracted data already in your index?
• Can you show how your extraction process was validated, and would two runs produce identical output?
• If an inspector asked what the model read on a given date, could you answer without a reconstruction exercise?
The third and fourth questions are the ones that tend to produce uncomfortable silences. They’re also the ones the January 2026 principles speak to most directly.
FDA and EMA have now said the same thing in the same document, which is unusual and worth noting. The expectation is provenance: know what your AI used, prove it was appropriate, keep the record.
Meeting that expectation is mostly not an AI problem. It’s a data governance problem. The organizations that treat their document-derived data as regulated content (versioned, traceable, tied to approved sources, retired on schedule) will add AI use cases without relitigating governance every time. The ones that don’t will keep running pilots that work beautifully until the moment someone asks where an answer came from.
Start with the question you can’t currently answer. What did it read?
Adlib will be at RAPS Convergence 2026 in Charlotte, September 15–17. If you’re working through AI governance in regulatory operations, come find us or reach out before the show.
AI governance in life sciences is the set of controls that make AI use defensible in regulated work: defining each model’s context of use, assessing and documenting its credibility for that use, tracking the provenance of the data it consumes, and keeping a human accountable for regulatory decisions. FDA and EMA set out ten shared principles covering this in January 2026.
Yes. FDA’s January 2025 draft guidance does not prohibit AI in regulatory decision-making. It asks sponsors to define the model’s context of use, assess risk, establish credibility proportionate to the model’s influence, and maintain human oversight, proof rather than permission.
Because AI reads extracted data, not original documents. Without provenance linking each output back to a specific approved document version, reviewers can’t efficiently confirm that AI-generated content reflects current approved content, and superseded sources produce confident, wrong answers with no error signal.
No. A validated DMS governs approved documents, which is necessary but not sufficient. The text, tables, and embeddings extracted from those documents (what AI systems actually query) typically sit outside that validated boundary, without versioning, lineage, or a retirement process tied to the source.
FDA & EMA — Guiding Principles of Good AI Practice in Drug Development (Jan 2026)
EMA — Reflection Paper on the Use of Artificial Intelligence in the Medicinal Product Lifecycle
FDA — Artificial Intelligence for Drug Development (CDER overview)
FDA — Data Integrity and Compliance with Drug CGMP (ALCOA+ source guidance)
FDA — eCTD Technical Conformance Guide (CTD/eCTD module structure)
Take the next step with Adlib to streamline workflows, reduce risk, and scale with confidence.