Does 21 CFR Part 11 apply to a chatbot a scientist uses on a personal account?

Part 11 follows the record. If output from that session enters a GxP electronic record, the controls in 11.10 apply to how that record came to exist, and the absence of any company-side audit trail is itself the finding. The account being personal makes the gap wider rather than moving the activity out of scope.

Is the electronic signature on the approved document enough?

The signature under 11.50 records that a named person approved the content on a date. It carries no information about the generation of that content. An investigator asking which model drafted a paragraph gets no answer from the signature block.

Can the model provider's logs serve as the audit trail?

Provider logs record the API key and the request, so they attribute activity to an application rather than to the scientist. They also sit under the provider's retention policy and change control, not yours. They can corroborate an enterprise record and they do not replace one.

What about prompts that contain no regulated data?

Classify and record the decision anyway. A record showing the prompt was evaluated and found out of scope answers the question during an inspection. Silence in the log leaves the reviewer to assume nothing was checked.

AI Audit Trail for Biotech: What 21 CFR Part 11 Expects at the Model Boundary

Consider a deviation investigation that closes with a model-written root-cause paragraph sitting inside a validated quality system. The audit trail captures one action: a named analyst pasted text at 16:42. The prompt that carried batch numbers into a commercial model, and the model that answered, left no trace inside the regulated boundary. 21 CFR 11.10(e) calls for "secure, computer-generated, time-stamped audit trails to independently record the date and time of operator entries and actions that create, modify, or delete electronic records." The operator entry happened before that paste. An ai audit trail biotech teams can defend has to begin at the earlier point, where the request left the company.

I want to walk through what Part 11 asks for in that gap, why validated-system logs answer the wrong question, and what a QA reviewer needs in hand when an investigator asks who wrote a sentence.

TL;DR

Part 11 attaches to the operator entry that creates or modifies an electronic record, so a model-drafted paragraph puts the regulated moment at the prompt rather than at the paste into the quality system.
Validated application logs record the human keystroke and the document version. They rarely carry the prompt content, the model identity, the model version or the data classification that an investigator will ask about.
The defensible record sits outside the application that made the request, keyed to the authenticated person and written before the response returns.
Part 11 does not set a retention period. The predicate rule governing the underlying record does, and the audit trail inherits it.

What Part 11 attaches to

Part 11 sets out, in 11.1(a), "the criteria under which the agency considers electronic records, electronic signatures, and handwritten signatures executed to electronic records to be trustworthy, reliable, and generally equivalent to paper records." The scope follows the record, not the tool. A batch record, a deviation investigation, a validation summary and a stability report all stay in scope when they exist electronically under a predicate rule.

That framing decides the AI question. When a scientist asks a model to summarise sixty pages of stability data and the answer becomes part of a submission-supporting document, the model participated in creating a regulated record. The controls in 11.10 apply to the system that produced it. 11.10(d) limits "system access to authorized individuals," which presumes you can name the individual behind each action.

Naming that individual gets hard quickly in practice. The request to the model usually travels on a shared API key issued to an internal application, so the provider sees the application and never the scientist.

Where the validated system's audit trail stops

Quality systems in this sector carry mature audit trails. They record document creation, revision, review, approval and the electronic signature manifestation required under 11.50. Four things they usually miss when a model is involved.

The prompt content does not appear anywhere. The quality system only ever sees the finished paragraph. It has no record of the batch identifiers, deviation numbers or patient-adjacent data the scientist typed into the prompt window to get it.

The model identity does not appear either. A reviewer reading the record eighteen months later cannot tell whether a given paragraph came from an internal fine-tuned model or a consumer chat product opened in a browser tab.

The model version does not appear. Providers retire and replace model versions on their own schedule, so a validated state recorded in March may describe a model that no longer exists in September.

The classification decision does not appear. Nothing in the document version history says whether anyone evaluated the prompt against the company's rules on what may leave the network.

My own view, and plenty of QA directors will disagree, is that Part 11 remediation programmes for AI spend too much attention on signature manifestations and far too little on the plain fact that nobody can say which model wrote the sentence. The signature proves a human approved the text. It says nothing about where the text came from.

The record a reviewer can reconcile

The record that survives an inspection has a predictable shape, and it gets written at the point the request leaves the authenticated user, before any response comes back.

Per request, it carries the timestamp to sub-second precision, the person authenticated through the company identity provider, that person's role and its GxP relevance, the application or agent that carried the request, the destination provider and model identifier including version, the classification applied to the prompt content, the governing policy version, the enforcement outcome, and a hash of the request and response that lets a reviewer detect later alteration.

Two properties matter more than the field list. The record lives in storage the requesting application cannot rewrite, which is the "independently record" language in 11.10(e) doing real work. And retrieval runs by person, by time range, by batch identifier or by model version, because an investigator scoping a model-version issue needs every record touched by that version, not a keyword search across documents.

Teams building this at the application layer end up with one partial implementation per validated system. A single inspection point covering authenticated model traffic produces one record format across all of them. The same reasoning appears in our write-up of audit trail requirements by regulation, and the healthcare version of the argument sits in HIPAA AI audit trail.

Retention comes from the predicate rule

Part 11 governs trustworthiness. It does not name a retention period for audit trails, which surprises teams who go looking for one.

The period comes from the predicate rule attached to the underlying record. A record retained for a fixed interval past batch expiry carries an audit trail retained to the same horizon. Nonclinical laboratory records under the good laboratory practice regulations follow their own schedule. A company running one AI inspection point across research, manufacturing and pharmacovigilance will therefore hold several retention clocks against one record stream, which argues for tagging each record with the predicate rule that governs it at write time rather than reconstructing that mapping during an inspection.

Storage also has to answer within the whole window. A retrieval that requires a restore from archive turns a same-day inspection request into a multi-week finding.

Validation and the moving model

Computer system validation assumes a system you can freeze, challenge and document. Hosted models resist that assumption, since the provider controls the version and the deprecation date.

The workable pattern pins the model version in policy and records the pinned value on every request. When a provider retires that version, the recorded stream shows the exact request where the change took effect, which gives the change control record a real boundary instead of an estimate. Without the per-request model identifier there is no way to scope the impact assessment, and the assessment defaults to every document produced in the period.

11.10(k) already expects "revision and change control procedures to maintain an audit trail that documents time-sequenced development and modification of systems documentation." A model version swap modifies the system. The audit trail should show when.

DeepInspect

DeepInspect sits at the boundary this article keeps pointing to. It is a stateless proxy between authenticated users or agents and any LLM endpoint, so identity resolution, classification of prompt content, model routing and enforcement all happen inline on the HTTP request before it reaches the provider.

Every decision writes a signed record carrying the authenticated person, the role, the classification applied, the destination model and version, the policy version in force, the outcome and the timestamp. Records commit to append-only storage before the response returns to the caller, and retrieval by person, time range, model version or identifier runs in seconds. The scope is the authenticated HTTP traffic between your people or agents and the models they call. Validation of your quality system, the predicate rule mapping and the GxP judgment on what belongs in a record stay with the owners who hold them today.

If your Part 11 story for AI currently ends at a paste timestamp inside the quality system, the record sitting upstream of that paste is the one worth building. Book a demo today.