Pharmaceutical regulatory compliance means meeting rules such as the FDA’s current good manufacturing practice (CGMP) regulations, so that the data generated can be trusted and activities can be reconstructed later. Published studies show AI for pharma compliance cutting the time spent retrieving guidance and drafting documents. An AI system used in GxP work still has to be validated for its intended use, auditable and access-controlled, and its outputs have to be reviewed by the people who answer for the result.
The rest of this page sets out what the regulations ask for, how regulators judge an AI model, and which artefacts make an AI-assisted workflow defensible in front of an inspector.
What pharmaceutical regulatory compliance requires in practice
In the US, the FDA describes CGMP as regulations that provide for systems assuring proper design, monitoring and control of manufacturing processes and facilities. The “current” in the name matters. The FDA expects companies to use up-to-date technologies and systems, and says equipment that was adequate 10 or 20 years ago may fall short today. Non-compliance has legal consequences: a drug made outside CGMP conditions is considered “adulterated” under the law.
Testing alone is not adequate to ensure quality. The FDA’s own example is a manufacturer testing 100 tablets from a batch of 2 million, which is why quality has to be built into the process at every step rather than checked at the end. We go through the manufacturing side in more depth in our guide to what cGMP regulations actually require.
FDA investigators record what they observe on Form FDA 483 at the end of an inspection. The agency then classifies the inspection. No action indicated (NAI) means an acceptable state of compliance and voluntary action indicated (VAI) means objectionable conditions the firm can correct itself. An official action indicated (OAI) classification is generally changed only after corrective and preventive actions have been verified by an on-site follow-up inspection. The FDA aims to finish classification within 90 days of an inspection ending.
In the EU, EudraLex Volume 4 sets GMP. Its Annex 11 covers computerised systems: lifecycle management, supplier oversight, audit trails, electronic signatures and system security. PIC/S calls data integrity a fundamental requirement of an effective pharmaceutical quality system, and the UK MHRA promotes a risk-based approach to GXP data management. The International Council for Harmonisation (ICH) harmonises technical standards for drug development and registration across countries.
The FDA defines data integrity as the completeness, consistency and accuracy of data. Data should be attributable, legible, contemporaneously recorded, original or a true copy, and accurate: ALCOA. MHRA and PIC/S extend that to ALCOA+ by adding complete, consistent, enduring and available, and MHRA says plainly that expectations do not differ whichever acronym is used.
All records required under CGMP, including those on computerised systems, are subject to FDA inspection. The FDA gives the example that an email authorising batch release is a CGMP record it may review. Anything an AI tool produces that feeds a GxP decision should be assumed to fall inside that scope.
Can an LLM keep track of FDA and EMA guidance for a compliance team?
Yes, as a retrieval and drafting aid that augments human expertise, with its answers checked against the source documents. As a source of truth, no. The authors of the QA-RAG study describe FDA and EMA guidance as voluminous and intricate enough that finding and applying the relevant part takes considerable time. Their corpus alone held 1,263 FDA guideline documents and 141 ICH guidelines, and they cite an estimate that compliance can consume up to 25% of a medium or large manufacturing site’s operational budget.
Much of this domain-specific knowledge is missing from the training data of general-purpose LLMs. LLMs hallucinate, producing plausible but incorrect content, and in pharmaceuticals even a minor misreading of a regulation can lead to non-compliance. The EMA and Heads of Medicines Agencies (HMA) add that models may never have seen the information a novel regulatory question needs, and that validating these systems is hard.
Both published systems cited here, QA-RAG and RegGuard, use retrieval-augmented generation (RAG). The model answers from documents retrieved at query time rather than from what it memorised. RegGuard, built with Roche on internal compliance reports, SOPs and quality records, combined hierarchical semantic chunking with a domain-tuned reranker. At a retrieval depth of 15 it reached a faithfulness score of 0.9252 and a groundedness rate of 0.8453 on its own evaluation set. The details that matter for compliance sit around the model: provenance tracking, access control and incremental indexing as documents change, plus two compliance officers manually verifying a 15% sample of the generated question-answer pairs used for evaluation.
Treat such a system as a fast first reader whose citations a person checks, not as an oracle. The QA-RAG authors say the same about their own system: it is designed to augment, not replace, human expertise and judgement.
The rules themselves are changing. The EMA calls the EU’s new pharmaceutical legislation the most significant overhaul of the framework in over two decades. The adopted acts are expected to enter into force in 2026, followed by a transition period to 2028 while member states align national law, and the EMA will publish guidance to help applicants comply. Document versioning and effective dates belong in the index metadata from the start.
How FDA and EMA judge an AI model: context of use and credibility
The FDA’s draft guidance covers AI used to support a regulatory decision about a drug or biological product’s safety, effectiveness or quality. Its central idea is model credibility. That means trust in a model’s performance for a particular context of use, where context of use is how the model addresses a specific question of interest. The draft sets out a 7-step, risk-based credibility assessment built around that context of use. It appeared as a January 2025 draft.
Risk in this framework has two parts: how much the model’s output influences the decision, and how serious the consequences of a wrong decision would be. When the FDA proposed the framework it cited experience with more than 500 drug and biologic submissions with AI components since 2016. A review in npj Digital Medicine counts more than 800 submissions with AI components to CDER since 2016.
The FDA also asks for detailed pre-specification. The draft recommends describing model inputs and outputs, features, feature selection, parameters and development data. The authors of the npj review add that the performance metric, cross-validation folds, fixed random seeds, software versions, preprocessing steps and computational environment should be pre-specified when AI is used for primary or secondary outcomes. That list reads like the manifest of a reproducible ML pipeline, which is exactly what it is.
On the European side, the EMA’s reflection paper on AI in the medicinal product lifecycle was adopted and published on 30 September 2024 and takes a human-centred, risk-based approach. The FDA’s CDER and CBER have also developed 10 guiding principles for AI in drug development jointly with the EMA. Separately, the EMA and HMA issued principles for using LLMs in regulatory activities.
Draft Annex 22: AI in GMP manufacturing
For manufacturing, EU GMP Annex 11 and Chapter 4 are being revised alongside a new Annex 22 on AI. The draft covers AI models in critical applications with direct impact on patient safety, product quality or data integrity, for example models that predict or classify data. It emphasises a defined intended use, established performance metrics, training data quality and the management of test data.
Several draft requirements translate directly into engineering work:
- Test data independence: data used to test a model must not be used in development, training or validation. If it is split off a common pool, the people who trained the model must never have had access to it, and this is enforced by access control and audit trails.
- Explainability during testing: systems should record the features that drove a classification or decision, using techniques such as SHAP, LIME or heat maps where applicable.
- Change control: the model, its system and the process it supports go under change control before deployment, and any decision not to retest after a change must be fully justified.
The industry-side counterpart is the ISPE GAMP Guide: Artificial Intelligence, which frames AI-enabled computerised systems as needing to be fit for intended use and compliant in GxP environments. Cross-sector AI regulation such as the EU AI Act also bears on this work.
The data integrity controls an AI tool inherits
Draft Annex 22 applies to the computerised systems in which AI models are used, and the controls below apply to those systems.
The audit trail comes first. The FDA defines it as a secure, computer-generated, time-stamped electronic record that allows reconstruction of the creation, modification or deletion of an electronic record. The draft Annex 11 spells out what it must contain. The audit trail must unambiguously capture who made a change (including role), what changed (old and new value), when (including time zone) and, for changes to existing values, why. It must be recorded at the time of the event rather than at the end of a process. Annex 11 and MHRA use definitions that agree with the FDA’s, with MHRA framing it as the “who, what, when and why” of an action.
Identity is the second control. When login credentials are shared, no unique individual can be identified, and the FDA says such a system does not conform to CGMP. The draft Annex 11 is blunter: shared accounts other than read-only ones constitute a violation of data integrity. Actions on GxP records, such as second person review, must be attributable to a specific individual.
The checklist below lists what a GxP-facing AI tool should demonstrate and the guidance each item comes from.
| Check | What the system must show |
|---|---|
| Validated for intended use | Validated before use and kept in a validated state across its lifecycle |
| Validation evidence | Executed test scripts, and screen dumps where relevant, showing requirements are met |
| Locked audit trail | Always enabled, not editable by any user; changes to its settings or system time are themselves logged |
| Unique accounts | No shared accounts except read-only ones |
| Restricted change rights | Changes to specifications, parameters, data or methods limited to authorised personnel by technical means where possible |
| Independent administrators | Admin rights not held by anyone who generates, reviews or approves the data |
| Least privilege | Role-based access granting the minimum needed for each job function |
| Login records | Successful and failed logins with user, role, date and time |
| Protected after release | Data, metadata and audit trails protected from change for the retention period |
| Periodic review | Documented checks that the system remains fit for intended use and validated |
Passing validation does not close the matter. PIC/S warns that validated systems can still lose or alter records through accident or malice, so validation has to be supplemented by administrative and physical controls and by user training. For the wider picture of what GxP compliance requires of AI software in manufacturing, see our dedicated guide.
Which AI outputs a person must review and approve
Human review of records is written into CGMP. The FDA states that all production and control records, including audit trails, must be reviewed and approved by the quality unit. Where regulations fix a review frequency, audit trail review follows it. Elsewhere, firms set the frequency through a risk assessment of data criticality and impact on product quality.
Draft Annex 22 extends review into model operation. When a model provides input to a human operator’s decision and testing effort has been reduced, records should be kept. Depending on criticality, this may mean reviewing every model output according to a procedure. Reviewing the features that drove test results is also part of approving them.
For generative drafting, the AutoIND study supports a division of labour between humans and AI. In the AutoIND study, initial drafting time for IND written summaries fell by about 97%. For one of the two INDs studied, it went from about 100 hours to 3.7 hours. No critical regulatory errors were found, but an experienced assessor judged that expert writing was still needed to bring emphasis and conciseness up to submission-ready quality. The detailed review flagged verbosity inflated three to five times, 35% missing critical information and 32% structural issues. Our worked example of AI-assisted drafting of a submission section shows what that review loop looks like on a real section.
The EMA and HMA tie the depth of review to the risk. The greater the potential harm, the greater the scrutiny, and users should avoid automation bias by checking outputs for veracity, reliability and fairness. We would build the review step into the workflow as a recorded, attributable action, because an unrecorded glance at an AI draft leaves no evidence that review happened.
Evidence an engineering team can hand to auditors
Reconstructing an AI-assisted conclusion has two distinct parts. The authors of AuditWeave call them provenance (which documents, retrievals, transformations and model outputs produced the conclusion) and integrity (proof that the record of that chain has not been altered since).
AuditWeave’s approach is a SHA-256 hash chain. Each event stores the previous event’s hash with its own, so any modification, insertion, deletion or reordering invalidates every later hash. Over 10,000 events, recording cost 22.42 microseconds per event, against 0.24 for an unprotected baseline, and full verification of 100,000 events took 1.21 seconds. Verification flagged every injected mutation across 2,000 randomised trials.
The limits matter as much as the numbers. The design gives tamper-evidence, not tamper-resistance: someone who controls the storage could recompute the whole chain unless its head is anchored to an independent external reference. It attests to what was recorded, not to whether the recording reflected reality. Its authors also state that the library does not by itself establish compliance with any regulation, and that this determination belongs to auditors and counsel.
That last point is the honest boundary for all of this work. Approval-grade evidence (task-specific evaluations, governance evidence packs, lineage for production decisions) is an engineering output that an auditor or compliance owner can read and sign against. It is engineering, not policy advice or certification. TechnoLynx builds this evidence as AI engineering for life sciences teams and the people who must sign against it.
