GxP AI: Deploying LLMs Under Good Practice Requirements

GxP AI means running a language model inside a GxP-governed process without breaking the two things GxP cares about most: data integrity and traceability. The practical way to do that is to deploy the model inside your own perimeter, air-gapped, under four controls you can verify on your own hardware — weight provenance, capacity enumeration, no egress, and a signed audit chain — so a GxP diligence review has evidence to inspect, not a vendor's assurance to trust.

GxP is the umbrella term for the "Good Practice" quality regulations that govern life sciences: Good Manufacturing Practice (GMP), Good Laboratory Practice (GLP), Good Clinical Practice (GCP), Good Distribution Practice (GDP), and their siblings. The specifics differ by discipline, but the spine is constant — records must be controlled and defensible, and you must be able to show what happened, in what order, using which validated system. Introducing an LLM into that environment does not relax those obligations. It raises the bar, because an AI is a new system whose behavior and data flows now have to survive the same scrutiny as any other GxP-relevant equipment or software.

Why generic cloud AI struggles with GxP

Most enterprise AI offerings are a governance layer wrapped around a third-party API. For a GxP context that arrangement has structural problems, not cosmetic ones:

• You cannot prove what ran. A hosted model can be updated, quantized, or routed differently without notice. GxP wants the validated version pinned; a black-box API cannot give you that.
• The data leaves your control. Sending batch records, study data, or promotional material to an external endpoint conflicts with residency and confidentiality expectations for GxP-controlled data.
• The record is the vendor's, not yours. An audit export you cannot independently verify is a convenience feature, not a tamper-evident record. GxP integrity requires that alterations be detectable.

The fix is not more dashboards. It is to move the model to where the data already lives and make each compliance property a check you run yourself.

The four controls, mapped to GxP expectations

Hyfstele runs open-weight models inside your own perimeter, air-gapped, under four independently verifiable controls. Each one is verifiable on the customer's hardware, and each maps to a specific GxP expectation for data integrity and traceability.

1. Byte-identical weight provenance

   The weights loaded into memory are proven byte-for-byte identical to the public artifact you approved. Nothing was swapped or silently updated between approval and inference, so the validated model version is a fact.

   GxP: the validated system stays under configuration control; the version in use is provable, not assumed.

2. Dormant / latent capacity enumerated

   The capabilities present in the model — including capacity dormant until triggered — are enumerated and disclosed, so what the model could do is a known quantity going into a risk assessment.

   GxP: risk-based validation and supplier qualification start from a disclosed capability set, not a guess.

3. No egress

   There is no route to the internet and no name to resolve. Things go in; nothing comes out. GxP-controlled data cannot leave the perimeter and the model cannot phone home, because there is nowhere for a packet to go.

   GxP: data residency and confidentiality of controlled records are enforced by the boundary itself.

4. Tamper-evident signed audit chain

   Every inference call is anchored to a linked, tamper-evident audit chain signed with post-quantum cryptography (ML-DSA). Any alteration to the record of what ran breaks the signature and is detectable.

   GxP: ALCOA+ data integrity and 21 CFR Part 11 record/signature requirements — attributable, contemporaneous, alteration-evident.

How the signed chain serves GxP record requirements

GxP data integrity is usually summarized as ALCOA+: records must be Attributable, Legible, Contemporaneous, Original, Accurate — plus Complete, Consistent, Enduring, and Available. The unifying requirement underneath is that a record must be trustworthy over time and that any change to it must be detectable.

The audit chain is built for exactly that. Each entry binds an input, the model version, and the resulting output together at the moment of inference, and each is signed with ML-DSA and linked to the entry before it. Because the entries are chained and signed, an auditor can confirm the record is contemporaneous and that nothing was edited after the fact — a later alteration breaks the signature. That is the difference between an export and a record: one is regenerated on request, the other is tamper-evident evidence of what the AI actually did. This is also the substance behind 21 CFR Part 11 electronic-record and electronic-signature integrity, which sits inside the broader GxP frame.

No-egress and data residency for controlled data

Much GxP-controlled data is exactly the data you are least free to send off-site: patient-level clinical data under GCP, proprietary process and batch data under GMP, promotional review packages headed for a regulator. Data residency and confidentiality obligations frequently rule out any architecture where those records transit an external endpoint.

Running air-gapped with no egress makes the question moot. There is no route out and no name to resolve, so controlled data physically cannot leave the boundary and the model cannot reach anything outside it. You verify this the same way an inspector would want to: by inspecting network policy and DNS resolution on the host and confirming there is no path. Residency stops being a policy promise and becomes a property of the deployment.

Provenance and capacity as inputs to GxP diligence

Before an AI system enters a GxP process it passes through diligence — supplier qualification, a risk assessment, and validation planning. Two of the four controls exist to feed that review with facts instead of assurances:

• Weight provenance answers "what exactly is this system, and can it change without us knowing?" Hashing the loaded weights against the published artifact proves the running model is the version you qualified. Configuration control is demonstrable rather than asserted.
• Capacity enumeration answers "what could this model do, including things it does not do today?" Disclosing dormant and latent capacity lets the reviewer scope risk around a known capability set, which is the honest basis for a risk-based validation approach.

Both are inputs a reviewer can independently check against the deployment on the customer's own hardware — the kind of evidence a GxP diligence file is supposed to contain.

The live proof point: MLR assist

The approach is running in production, not sitting in a whitepaper. The Hyfstele MLR assist is a working deployment for pharmaceutical MLR (Medical, Legal, Regulatory) promotional review, with a live demo at mlr.hyfstele.com. Its operating doctrine is built for a GxP mindset:

The system flags potential issues in promotional material; a qualified human judges; and every step is proven on the signed audit chain. Critically, there is no LLM inside the flag decision plane — the model surfaces candidates, but the logic that decides what counts as a flag is deterministic and reviewable. The doctrine is short: "It flags. You decide." The accountable reviewer stays in control, and the tamper-evident record of every call is captured for audit — exactly the traceability posture GxP expects.

Frequently asked questions