21 CFR Part 11 Audit-Trail Requirements Applied to AI
21 CFR Part 11 requires audit trails that are secure, computer-generated, time-stamped, and protected from undetected alteration. To apply that to AI, every inference call is captured as a system-generated, time-stamped record and anchored to a cryptographic chain signed with post-quantum ML-DSA. Because each entry is linked to the one before it, any change to a past record breaks the chain and is detectable — and an auditor can re-verify the whole chain independently, on your own hardware.
Part 11 was written for electronic records and signatures, long before LLMs. But its audit-trail requirements translate almost directly to AI — if the record of what the model did is complete, attributable, and tamper-evident.
What Part 11 actually asks of an audit trail
The core language lives in 11.10(e): covered systems must use "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," and those trails must not obscure previously recorded information. Read plainly, four properties do the work:
Two more expectations sit alongside 11.10(e): the trail must be retained for at least as long as the underlying record, and it must be available for agency review and copying throughout that period.
Applying each principle to AI inference
An AI system that assists regulated work — drafting, screening, or reviewing content — generates a stream of inference calls. Each call is an "action" in Part 11 terms. Here is how the four principles map onto that stream in a Hyfstele deployment.
- Secure → the chain is signed, not merely access-controlled. Every entry carries a post-quantum ML-DSA signature and embeds the hash of the previous entry. Security doesn't rest on "only admins can reach the log table"; it rests on the fact that any edit invalidates the signature and breaks the chain.
- Computer-generated → anchored by construction. The audit entry is written by the inference path itself. There is no route for a call to be served without a corresponding, signed, chained record. Completeness is a property of the wiring, not a policy someone has to remember to follow.
- Time-stamped → each entry records when. Every anchored record captures the date and time of the inference call, tying a specific request and response to a specific moment.
- Non-obscuring → append-only and detectable. Entries are only ever added, never rewritten in place. If a past entry is altered, the break surfaces at exactly that point when the chain is re-verified, so prior information can never be silently obscured.
Tamper-evidence: a signed chain vs. a mutable application log
The distinction Part 11 cares about most is between a record you can change without anyone knowing and a record where any change is detectable. Ordinary application logs sit on the wrong side of that line.
| Property | Mutable application log | Signed, tamper-evident chain |
|---|---|---|
| Editing a past entry | Possible and invisible | Possible, but breaks the chain and is detectable |
| Deleting or backdating | Leaves no trace | Invalidates every entry after it |
| How entries are written | By application code; can be bypassed | By the inference path itself; anchored by construction |
| Basis of trust | "Trust our access controls" | Recompute the hashes and check the signatures yourself |
| Who can verify | Effectively only the vendor | An auditor, independently, on customer hardware |
| Holds up over retention period | Usually unsigned; no long-term integrity claim | Signed with post-quantum ML-DSA for decades-long defensibility |
A mutable log answers "what does the record say now?" It cannot answer "has this record been changed since it was written?" For a Part 11 audit trail, the second question is the only one that matters — and a mutable log fails it silently.
Why post-quantum ML-DSA signing matters for long-term records
Hashing links the entries; signing is what makes an alteration provable rather than merely suspected. Hyfstele signs each entry with ML-DSA — the NIST-standardized post-quantum signature scheme.
This choice is driven by retention. Part 11 requires the audit trail to stay trustworthy for at least as long as the record it documents, and pharmaceutical or GxP records can carry retention obligations measured in years or decades. A signature scheme that a future quantum computer could forge would undermine the integrity claim precisely when an old record is pulled in an inspection. Signing today with a post-quantum algorithm means the integrity guarantee you assert in 2026 is still one you can defend when the record surfaces long after.
Verification happens on your hardware — auditors check it themselves
Because a Hyfstele deployment runs inside your own air-gapped perimeter and verification is purely cryptographic, an auditor does not have to take anyone's word for it. They can recompute the hash chain and check every ML-DSA signature independently, on the customer's own hardware. Part 11 asks that audit trails be available for the agency to review and copy; a chain that anyone can re-verify goes past availability to reproducible evidence.
The audit trail is the fourth of four independently verifiable controls in a Hyfstele deployment — a secure-LLM setup that runs open-weight models inside your own air-gapped perimeter:
Hyfstele does not certify Part 11 compliance, and we do not claim the model is clean, safe, or free of hidden behavior — no one can honestly claim that about an open-weight model. Compliance is a property of your validated system, your procedures, and your organization's controls. What we make available is four controls you can verify on your own hardware. The audit chain doesn't prove the model is trustworthy; it proves the record of what the model did is complete and unaltered. Evidence you can reproduce, not our word.
Where this shows up: MLR promotional review
Hyfstele's flagship use case is an AI assist for pharmaceutical MLR (Medical, Legal, Regulatory) promotional review, with a live demo at mlr.hyfstele.com. It runs a strict doctrine — It flags. You decide. — along a Flag → Judge → Prove flow, with no LLM inside the flag-decision plane. The tamper-evident, Part 11-aligned audit chain is the "Prove": the durable, signed record of what was flagged, what a human decided, and the inference behind it.
Frequently asked questions
What does 21 CFR Part 11 require of an audit trail?
Part 11 (specifically 11.10(e)) requires the use of secure, computer-generated, time-stamped audit trails that independently record the date and time of operator entries and actions, and that do not obscure previously recorded information. In practice this means the trail must be generated by the system rather than entered by a user, carry trustworthy timestamps, capture the who/what/when of each action, be retained for at least as long as the record it documents, and be available for the agency to review and copy.
How does anchoring AI inference to a signed chain meet the tamper-evidence expectation?
Each inference call is captured as a record that embeds a cryptographic hash of the previous entry and is signed with post-quantum ML-DSA. Because every entry is linked to the one before it, editing, deleting, or backdating any past entry breaks the chain and is detectable. Part 11 does not require that records be physically impossible to change; it requires that changes not obscure prior information and be detectable. A signed, chained trail delivers exactly that property.
Why use post-quantum ML-DSA signatures for a Part 11 audit trail?
Part 11 records must remain trustworthy for the full retention period, which for pharmaceutical and GxP records can be years or decades. ML-DSA is the NIST-standardized post-quantum signature scheme, chosen so the integrity guarantee still holds after cryptographically relevant quantum computers arrive. Signing today's inference records with a post-quantum algorithm means the integrity claim you make now is still defensible when the record is pulled in an inspection long into the future.
Can an FDA auditor verify the audit chain independently?
Yes. The deployment runs inside the customer's own air-gapped perimeter and verification is purely cryptographic, so an auditor can recompute the hash chain and check each ML-DSA signature themselves on the customer's own hardware. Part 11 requires that audit trails be available for agency review and copying; a chain that anyone can independently re-verify goes beyond availability to reproducible evidence — the guarantee rests on math the auditor can recompute, not on a vendor's assurance.
Does Hyfstele certify Part 11 compliance?
No. Compliance is a property of your validated system, your procedures, and your organization's controls, not something a vendor can certify on your behalf. What Hyfstele provides is a set of controls that are verifiable on your own hardware — including a tamper-evident, post-quantum-signed audit chain that maps directly to Part 11 audit-trail expectations. The posture is evidence you can reproduce, not a compliance stamp.
See the audit trail in a real review
The MLR promotional-review assist runs the full Flag → Judge → Prove flow, with every inference anchored to a signed, tamper-evident chain. Watch it live, or ask how the four controls verify on your own hardware.