Compliance / Buyer's Guide
21 CFR Part 11 requires that electronic records be attributable, complete, and protected against alteration, backed by a secure, time-stamped audit trail. For an AI system that means every inference record must be tied to a known system version, kept intact through its retention period, and verifiable by an auditor without taking the operator's word for it. Below is what Part 11 expects, and the specific controls a regulated buyer should verify — on their own hardware — before putting an LLM into a GxP process.
Part 11 is deliberately technology-neutral. It governs the electronic records and signatures a system creates when those records support an FDA predicate-rule requirement — it does not carve out an exception for records that happen to be produced by a model. So the question a life-sciences buyer should ask about an AI system is not "is it approved," it is "can I show an inspector that the records it produces are attributable, unalterable, and reviewable." That is a question about controls, and controls are things you should be able to check.
Stripped to its core, Part 11 asks for a handful of properties on the electronic records that matter. The FDA's ALCOA framing — attributable, legible, contemporaneous, original, accurate — is the shorthand quality teams use, but the load-bearing requirements for an AI record are these:
None of that is unique to AI. What is new is that an LLM introduces two questions traditional systems didn't: which exact model version produced this record, and can I trust the environment the model ran in. Part 11's record-integrity bar still applies — you just have more to prove.
Hyfstele runs open-weight models inside your own perimeter, air-gapped, and exposes four controls that each map onto a Part 11 expectation. The point is not that a tool makes you compliant — it is that each control produces evidence you can verify yourself.
| Part 11 expectation | Verifiable control |
|---|---|
| Secure, time-stamped audit trail; records protected against undetectable alteration | Every inference call anchored to a tamper-evident audit chain, signed with post-quantum cryptography (ML-DSA), so any alteration, insertion, or deletion is detectable on verification. |
| Attributable records — knowing exactly which system version produced a record | Model weights proven byte-identical to the public artifact, so the version that generated a record is provable, not assumed. |
| Control over records; limiting system access and outbound pathways | No egress — no route to the internet and no name to resolve. Records and the model stay inside your perimeter. |
| Understanding system capabilities that could affect record integrity | Dormant / latent model capacity enumerated, so unused capability is accounted for rather than assumed away. |
The heart of Part 11 is the audit trail. It has to be secure, computer-generated, time-stamped, and it must not obscure previously recorded information when something changes. That is precisely the shape of a tamper-evident, cryptographically signed chain.
In Hyfstele, each inference record is linked to the one before it and covered by a digital signature. Alter an earlier output, reorder events, or drop a call, and the signature no longer validates and the chain no longer links — the tampering surfaces the moment anyone verifies. And verification does not depend on the vendor: anyone holding the public key and the chain can confirm, independently, that the AI decision record is intact.
"Attributable" is easy to satisfy for a person clicking a button. It is harder for a model, because a model can be quietly swapped, patched, or fine-tuned, and the record it produced would look identical. If you cannot say which exact model produced a record, you cannot fully attribute it.
Hyfstele proves the running weights are byte-identical to the published public artifact. That gives you a provable, not assumed, answer to "which system version created this record." Tie that provenance to the signed audit chain and you can attach a specific record to a specific, verifiable model version through its whole retention period. For the deeper treatment, see model provenance for compliance.
Part 11 record integrity assumes you actually control the records and who can reach the system. A model that calls out to a third-party API sends your records — and often the prompts that contain regulated content — outside your perimeter, where your controls and your audit trail no longer reach.
Hyfstele deploys on-prem and air-gapped: no egress means there is no route to the internet and no name to resolve. As the doctrine puts it, things go in and nothing comes out. Records stay where your quality system, your access controls, and your Part 11 audit trail govern them. This is also the difference between a data-residency claim you are asked to trust and one that is structurally true because the pathway does not exist. See running AI in a GxP environment for how this fits the broader validated-system picture.
It would be easy — and wrong — to say a tool makes you Part 11 compliant. Compliance is a property of your validated process and your quality management system, not of any single product, and no vendor can hand it to you in a box.
Hyfstele's reference use case is an AI assist for pharmaceutical Medical, Legal, and Regulatory promotional review (live at mlr.hyfstele.com). The doctrine is "It flags. You decide." The assistant runs a Flag → Judge → Prove flow, with no LLM inside the flag decision plane, and every flag — plus the human judgment on it — lands in the signed audit chain. When a reviewer later asks "why was this claim flagged, who cleared it, and which model version saw it," the answer is a signed, attributable record, not a reconstruction after the fact. That is the Part 11 posture in miniature: the record is the evidence.
Part 11 applies to the electronic records and signatures a system creates, modifies, maintains, or transmits when those records support an FDA predicate-rule requirement. It is technology-neutral, so if an AI system produces records used in a GxP process, those records fall under Part 11 — they must be attributable, complete, and protected against alteration, with a secure, time-stamped audit trail. The regulation does not exempt records because they came from a model.
It requires secure, computer-generated, time-stamped audit trails that independently record operator entries and any creation, modification, or deletion of records, without obscuring previously recorded information. The audit trail must be retained at least as long as the underlying record and be available for review and copying. For an AI system, that means each inference record must be attributable, tamper-evident, and reviewable by an auditor.
Ask for evidence you can check yourself, not a vendor assurance. A tamper-evident audit chain — each inference record linked and cryptographically signed — lets an auditor confirm on their own hardware that no record was altered, inserted, or deleted. Hyfstele signs each inference record with ML-DSA, a post-quantum standard, so the integrity of the AI decision trail is independently verifiable rather than asserted.
No. Compliance is a property of your validated process and quality system, not of a single tool, and Hyfstele does not issue a compliance certification. What Hyfstele provides are verifiable controls relevant to Part 11: a tamper-evident, ML-DSA-signed audit chain for every inference, byte-identical model provenance, and no-egress on-prem deployment. These support your obligations, but the compliance determination remains yours.
Attributability for an AI record means knowing exactly which system version produced it. Hyfstele proves the running weights are byte-identical to the public model artifact, so the version that generated a record is provable rather than assumed. Combined with the signed audit trail, this ties a specific record to a specific, verifiable model version through its retention period.
Hyfstele runs open-weight models inside your perimeter, air-gapped, with four controls you can verify yourself — and a signed audit trail built for the Part 11 bar. See the MLR assist live, or talk through a deployment.
Open the live demo Email Blake →