Pharma GxP AI Compliance: Part 11 Audit Trails for AI
GxP pharma workflows are wiring LLM calls into validated systems, but 21 CFR Part 11 audit-trail and ALCOA+ data-integrity expectations do not stop at the application log. This walks through where AI calls sit under Part 11 and how an external per-decision record supplies attributable, tamper-evident evidence.
A pharmacovigilance analyst opens a serious adverse event case, pastes the narrative into a large language model, and asks it to draft the MedWatch 3500A summary. The safety database records that a case narrative was finalized at 14:32 by user PVANALYST04. It captures nothing about the model call: which analyst's identity authorized it, what patient data left the validated boundary, or what policy governed the request. 21 CFR Part 11 and ALCOA+ expectations follow that AI call, and the application's audit trail never saw it.
That gap repeats across batch documentation, pharmacovigilance, and regulatory writing. I want to walk through where LLM calls sit under Part 11, why application-controlled logs fail the data-integrity test, and how an external per-decision record supplies the attributable, contemporaneous, tamper-evident evidence an FDA investigator expects.
What 21 CFR Part 11 requires from an electronic record
21 CFR Part 11 is the FDA rule, finalized in 1997, that governs electronic records and electronic signatures in regulated environments. It sets predicate expectations for any record that supports a GxP decision. Records must be attributable to a specific person, protected against undetected alteration, and reproducible for inspection in human-readable form. Section 11.10(e) is explicit about the mechanism: a secure, computer-generated, time-stamped audit trail that independently records the actions that create, modify, or delete a record, and that operators cannot obscure. On top of Part 11, the FDA and the UK MHRA apply ALCOA+ as the data-integrity test: attributable, legible, contemporaneous, original, accurate, plus complete, consistent, enduring, and available. Computer system validation is expected for any system that creates or maintains these records. Those requirements were written for a validated LIMS or MES. An LLM call now sits inside the same regulated workflow, carrying the same evidentiary weight.
Where LLM calls enter validated pharma workflows
An LLM call enters a validated GxP workflow in three main places. In batch documentation, an operator on a manufacturing execution system asks a model to draft a deviation narrative or a CAPA summary against the electronic batch record. In pharmacovigilance, a safety analyst uses a model to draft an ICSR narrative or an ICH E2B(R3) summary from case intake. In regulatory writing, a medical writer drafts sections of a clinical study report or a protocol against source data. Each host system already carries its own computer system validation and Part 11 audit trail. The model sits outside that system, and the call to it is an HTTP request to a model API. The chromatography data system, the LIMS instrument interfaces, and the MES internals stay outside the AI-traffic boundary and keep their existing controls. The new and ungoverned surface is the HTTP call the workflow makes to the LLM, where identity-aware authorization decides whether the request is attributable at all.
ALCOA+ breaks at the AI call when the application writes its own log
ALCOA+ starts to fail at the AI call when the same application writes its own log. Attributability: the model API is commonly called with a shared service account or an API key issued to the application, so both the provider-side and application-side records show the service, not the analyst who initiated the request. Contemporaneousness: the application writes its entry after the response returns, if it writes one at all, so the recorded time drifts from the event. Originality and accuracy: the application that produced the AI-assisted text also owns the log, so the record is a copy its author controls. An AI call the validated system never recorded behaves like shadow AI from an evidence standpoint. IBM's Cost of a Data Breach analysis found breaches involving shadow AI took 247 days to detect, six days longer than standard breaches, and cost $670,000 more on average. The validation teams I work with usually discover this the first time an inspector asks who authorized an AI-assisted narrative.
The letter of Part 11 versus surviving an FDA inspection
The letter of Part 11 could be read to allow a JSON entry in the validated application's own database. That reading holds until an FDA investigator arrives with a data-integrity focus. Form 483 observations and warning letters in the data-integrity area turn on three questions: can you attribute this record to a specific person, can you show it was contemporaneous, and can you prove it was not altered after the fact. For an AI-assisted batch narrative, the investigator asks which model produced the text, who authorized the call, what source data went into the prompt, and what policy governed the decision. A log the application writes about itself can answer those questions only with evidence the author controls. Section 11.10(e) asks for a computer-generated, time-stamped audit trail the operator cannot obscure, and a record the operating application owns fails that independence test. The audit-trail requirements across regulations converge on the same independence property.
An external per-decision record makes the AI call attributable and contemporaneous
The requirement resolves to a specific artifact: for every AI request, a record produced outside the application that made the call. That record carries a verified identity for the person or agent behind the request, the role and authorization in effect, the data classification of the prompt, the policy version applied, the decision outcome, and a timestamp precise enough to correlate with the batch record or the safety case. It is committed before the model response returns, so the author cannot suppress it, and it is signed, so alteration is detectable. Map that to ALCOA+: attributable through verified identity, contemporaneous through the pre-response commit, original and accurate through the integrity signature, enduring through independent retention. This is the per-decision audit record that a tamper-evident log makes admissible in an inspection. The evidence sits beside the validated system's own audit trail rather than depending on it, so an inspector can compare the two and see they agree.
DeepInspect
This is the gap DeepInspect closes. DeepInspect runs as a stateless proxy on the HTTP path between your authenticated users or agents and any LLM API they call. It governs the AI request itself, not the MES internals, the LIMS instrument interfaces, or the computer system validation your systems already carry. For each call, it evaluates the caller's identity, the data classification of the prompt, model authorization, and organizational policy, then permits, redacts, or blocks the request before it reaches the model.
Every decision produces a per-decision audit record - identity, role, policy version, data sensitivity, outcome, and timestamp - signed, tamper-evident, and committed before the application receives the response. Because the proxy is the gate every request passes through, the recording is automatic and independent of the application that made the call. That is the attributable, contemporaneous, tamper-evident evidence 21 CFR Part 11 and ALCOA+ expect for an AI-assisted record, and it stays model-agnostic across the LLM providers a pharma stack tends to accumulate.
As an AI gateway for regulated industries, that record is the difference between an AI call you can defend in an FDA inspection and one you cannot. Book a demo today.
Beyond Part 11
Part 11 is one expression of a requirement showing up across pharma's regulatory surface. EU Annex 11, the computerised-systems counterpart to Part 11, applies the same audit-trail and attributability expectations to GMP systems operated in Europe. ICH E6(R3) Good Clinical Practice extends contemporaneous, attributable record-keeping to trial data, including AI-assisted analysis. The EU AI Act Article 12, whose high-risk provisions take effect August 2, 2026, requires automatic recording of events over the lifetime of the system, including timestamps, input data, and identification of the natural persons involved. A pharma company running LLM calls inside a validated workflow in Europe faces Part 11-style data integrity and Article 12 logging at the same time. The per-decision record that satisfies attributability under ALCOA+ already carries the identity and timestamp Article 12 names. One evidence layer answers the FDA investigator and the Article 12 auditor from the same record.
Frequently asked questions
- Does 21 CFR Part 11 apply to LLM calls inside a validated system?
Part 11 governs electronic records and signatures that support GxP decisions. When an LLM drafts a deviation narrative, an ICSR summary, or a CSR section that becomes part of the regulated record, the output and the act of generating it fall inside Part 11's scope. The model call is itself a record-creating event. What matters to the FDA is attributability and integrity: can you show which person authorized the AI-assisted content, when, and that it was preserved unaltered afterward. The validated application's audit trail usually captures the human's final save, not the model call that shaped it. That leaves the AI step undocumented at the exact resolution Part 11 and ALCOA+ care about. Treat every LLM call that touches a GxP record as an event that needs an attributable, contemporaneous, tamper-evident entry, produced independently of the application that made the call.
- What makes ALCOA+ attributability hard for AI-assisted records?
Attributability requires the record to tie back to a specific person. LLM integrations commonly authenticate to the model API with a shared service account or a single API key issued to the application, so both provider-side and application-side logs show the service identity, not the analyst who initiated the request. When ten medical writers share one integration, the model API sees one caller. The batch record shows a human final approver, and the AI call that produced the draft carries no verified identity of its own. Reconstructing who did what then depends on stitching session heuristics together after the fact, which is the kind of inference an FDA investigator discounts. Attributability at the AI call requires identity to travel with each HTTP request to the model and to be written into an independent record at the moment of the call, so the person behind the prompt is fixed in evidence.
- Can our existing validated system's audit trail cover the AI call?
The validated system's audit trail records actions inside that system: who logged in, what field changed, when a record was saved. The call to an external LLM API leaves that system as an HTTP request and returns as a response. Unless the application was specifically built to log the prompt, the data classification, the model identity, and the authorizing user for every call, its audit trail records the human's edit, not the model interaction that produced it. Even where the application logs something, it owns that log, so the record is a copy the author controls rather than independent evidence. See our AI compliance audit checklist for the fields an AI-assisted record needs. The dependable pattern keeps the AI-call evidence in a record produced outside the application, so an inspector can compare the two and confirm they agree.
- Is an external audit record a substitute for computer system validation?
No. Computer system validation demonstrates that a GxP system performs as intended and stays in a validated state. That work stays with your MES, LIMS, safety database, and their suppliers. An external per-decision record covers a different surface: the HTTP call your validated workflow makes to an LLM, which validation packages written before the integration existed never contemplated. The two are complementary. CSV shows the validated system behaves correctly. The per-decision record shows the AI call that the system triggered was attributable, authorized, and preserved unaltered. A gateway that produces that record does not revalidate your systems and should be treated as an evidence and enforcement layer for AI traffic, documented in your validation plan as such. Keeping that boundary clear also keeps your validation scope honest and your inspection story consistent.
- How does this relate to EU AI Act Article 12 for a pharma company in Europe?
A pharma company using LLMs inside a validated workflow operated in Europe can face two logging regimes at once. 21 CFR Part 11 and its EU Annex 11 counterpart set data-integrity and audit-trail expectations for GxP records. EU AI Act Article 12, whose high-risk provisions take effect August 2, 2026, requires automatic recording of events over the system lifetime, including timestamps, input data, and identification of the natural persons involved. The overlap is nearly exact at the AI call: both want an attributable, time-stamped, durable record of what the system did and who was behind it. A per-decision record built for ALCOA+ attributability already carries the identity and timestamp Article 12 names. Rather than build two logging stacks, the validation leads I talk to want one evidence layer that answers a Part 11 inspector and an Article 12 auditor from the same record.
- Does redacting data at the gateway interfere with the GxP record?
Redaction at the gateway applies to what reaches the model, not to the GxP record itself. If a policy blocks patient identifiers or unreleased batch data from leaving in a prompt, the gateway records that a redaction or block occurred, under which policy version, for which user. That decision becomes part of the audit evidence rather than a silent edit. The validated system keeps its own complete record of the underlying data. What the gateway changes is the content of the outbound HTTP request to the LLM and the creation of an attributable entry describing that enforcement. For an ALCOA+ review, that improves completeness: the enforcement decision is now documented instead of sitting as an undocumented gap between the workflow and the model. Configure redaction policies with your data-integrity and QA teams so the recorded decisions map to your GxP data-classification scheme.