In July 2025 the European Commission published a draft of EU GMP Annex 22, the first GMP text written specifically for artificial intelligence. Its scope section contains these two passages:
“The document applies to models with a deterministic output which, when given identical inputs, provide identical outputs. Models with a probabilistic output which, when given identical inputs, might not provide identical outputs are not covered by this document and should not be used in critical GMP applications.”
“Following the above, the document does not apply to Generative AI and Large Language Models (LLM), and such models should not be used in critical GMP applications.”
Stakeholders in the consultation asked for room for generative models, and EMA held a workshop in mid-2026 on a risk-based approach. A final text is targeted for the end of 2026.
We have looked at the question from a different side. We built a document-assessment pipeline that contains an LLM and gives identical outputs for identical inputs at every stage, and we measured that it does. This post explains what we mean by that, why we think it is the right requirement for regulated document assessment regardless of what the final Annex 22 says, and what it costs.
A word on scope. Annex 22 is written for the manufacture of medicinal products. Document assessment is done under other rules as well: 21 CFR Part 11 asks electronic-record systems to be validated for “accuracy, reliability, consistent intended performance”; the US device quality regulation and FDA’s Computer Software Assurance guidance ask for validation of quality-system software and re-evaluation on change; the EU AI Act asks high-risk systems to perform consistently throughout their lifecycle. Each of these asks for consistency or controlled change in its own words, and none requires byte-identical output. We quote Annex 22 because it states the identical-output criterion in a single sentence. The current draft excludes LLMs by name, so replayability alone does not bring an LLM system within its scope. Whether a final text leaves room for such a system is for regulators to decide.
Determinism is not correctness
One thing first, because it is the objection everyone raises. A deterministic system can be consistently wrong. Determinism does not make an assessment correct.
What determinism gives you is different and, we will argue, prior. It makes every error reproducible, so it can be attributed to a cause and the fix can be verified. It turns the system into a function of its inputs, so the validation methods that already exist for computerised systems apply to it. And it makes “nothing changed” a statement that a machine can check. Correctness still has to be established by qualified people against a reference. We are preparing that study separately. This post is about the precondition.
Four levels of “deterministic”
The word is applied to different parts of a system, and the same sentence can describe a strong condition or a much weaker one. It helps to say which part is meant. A recent technical report from Enveda on reviewing pharmaceutical batch records with Claude is a good example of doing so: it uses “deterministic” for the code around the model (the page windowing, the coverage ledger, the severity caps) and states separately that the model output is not:
“Sampling parameters cannot be set on the AI models used and no seed is available, so findings vary between identical runs.”
“Few findings appeared in every one of three identical runs, and repeat findings were often re-graded.”
Their design has a person disposition every comment, and it measures consistency for each configuration change by running each candidate up to three times on a fixed test set. That is a sound engineering answer under the constraints of a hosted model. It is also the situation the Annex 22 sentence describes, and it shows why a reader needs to know which part of a system a claim of determinism covers.
To make that explicit we use four levels.
| Level | What is identical across runs | Typical example |
|---|---|---|
| L0 | Nothing guaranteed. Model called with temperature 0 | Standard practice with hosted APIs |
| L1 | Model output, on the same hardware at the same concurrency | A self-hosted server under fixed conditions |
| L2 | Model output, regardless of concurrency, restarts, or which identical GPU runs it | Batch-invariant inference |
| L3 | Every stage: OCR, extraction, embedding, indexing, retrieval, inference, verification. The full output can be regenerated byte for byte from the record | The pipeline in our preprint |
“Replayable” is our word for L3. Given the record of an assessment, you can replay it and get the same bytes.
What we measured
Our preprint (arXiv:2610.21300) reports the measurements behind that table. They were made on public FDA documents for one class of medical device, because that corpus is public: anyone can obtain the documents, send the same prompts to the hosted deployments, and recompute our numbers from the deposited records. The property measured is a property of the pipeline, not of the documents: the same stages, with the same settings, process a batch record, a design file or a supplier audit report. The stage most sensitive to the kind of document is OCR, and we report below what OCR did with and without the same discipline.
At L0, we sent 70 byte-identical prompts to fourteen hosted deployments (seven models, each through two routes) five times on each of two consecutive days, asking for temperature 0 and a fixed seed wherever the interface accepted them. No deployment returned the same output on every prompt, and twelve of the fourteen changed at least one assessment label. Within a single day, the number of prompts whose label changed ranged from 0 to 18 of 70 by deployment. Two deployments changed labels only between the two days, which a one-day validation would have called stable. Turning reasoning down to the lowest documented setting made it worse, not better: on the eight deployments that allow it, the number of prompts with a changed label rose in seven, and for one model from 14 to 42 of 70.
At L1 and L2, we served an open-weight model ourselves on one GPU. Sent one request at a time, all 700 outputs over two days were byte-identical. Sent from eight concurrent senders with batch invariance disabled, the full output varied on 58 of 70 prompts and the label on 5. With batch invariance enabled, all outputs were byte-identical to the sequential ones, at a cost of 18% in run time. In the full pipeline the same held at one, eight and sixteen concurrent items, across a kill and restart of the inference server, and on a second GPU of the same model. A GPU of a different model did not reproduce the run, and the per-stage hashes located every difference.
At L3, we extended the same discipline to the rest of the pipeline. OCR, the embedding model, the vector index and the retrieval step each had their own sources of variation, and each was fixed or constrained. Removing the discipline from one stage at a time moved that stage’s output and no other: with the OCR servers run without batch invariance and sixteen documents ingested concurrently, the extracted text changed for 13 of the 42 documents that needed OCR and for none of the 294 that had a text layer. With every stage constrained, the complete assessment of 337 documents and 776 items could be regenerated byte for byte.
Why this is the right requirement
Three reasons, in order of weight.
It serves what existing rules already ask for. Rules outside Annex 22 do not ask for identical outputs in those words, but they ask for things that depend on them. 21 CFR Part 11 asks for validation that ensures “accuracy, reliability, consistent intended performance.” Change control asks you to evaluate whether a change requires retesting. Audit trails exist so that an assessment can be reconstructed. For a system that contains an LLM, we do not know of any way to satisfy these with existing validation methods other than making the whole pipeline a function of its inputs. Repeating runs measures variability; it does not bound it. Statistical acceptance criteria for LLM output would be a new validation framework that no regulator has defined. And “the meaning is the same” is not a criterion a machine can check: it needs a judge, and the judge is either another LLM or a person who cannot review thousands of items.
It makes change impact measurable. The first rule of a controlled experiment is to change one variable. If the assessment result moves when nothing has changed, you cannot measure the effect of changing something: a prompt, a retrieval setting, a new revision of a document, a model upgrade. Under noise you need many runs per condition and a statistical test. Under determinism you need one run per condition, and the diff is the effect. A diff of zero means no impact, and you can say so in a change record. Annex 22’s clause 10.1, which asks you to justify every decision not to retest, becomes decidable.
It makes both compute and expert time scale. The input to the model call is fully determined by the item, the retrieved passages, the prompt and the pinned model configuration. Hash all of that, and any item whose hash is unchanged does not need to be re-inferred. Because the output is a function of that input, its label, comment, citation and reference are also unchanged, so an expert who reviewed that output does not need to review it again. When a document set is updated, retrieval, which is cheap, tells you exactly which items were touched. Inference and expert review, which are expensive, are confined to those. Annex 22’s clause 10.5, which can imply “a consistent review of every output” when a human is in the loop, becomes a review of the delta.
What it costs
We should be honest about the bill.
Determinism at L2 and L3 means serving the model yourself with pinned weights, a pinned inference engine and batch-invariant kernels, and it means pinning the OCR model, the embedding model and the index build. Batch-invariant inference is slower than unconstrained batching; our preprint reports the measured throughput cost.
Against that, the hosted-API alternative has costs that do not show up on the invoice: changes on the provider side that the caller cannot see or schedule (our L0 measurements are the visible part of those changes), model retirements that set the date of a revalidation, multiple runs to reach the same confidence, and a sandbox cycle for every configuration change. None of this is a fault of the providers; a shared service is operated for many customers, and a validated pipeline is one customer with unusual needs. The cost of determinism is the cost that change control already asks you to carry. It moves from unplanned to planned, and the memoisation above pays a good part of it back.
What this is not
It is not a claim of Annex 22 compliance. The Annex is a draft, its sentences are written about models rather than systems, and compliance is a claim about an entire computerised system in its environment. What we can say is that the deterministic-output criterion in the draft’s scope, applied to the whole pipeline rather than the model alone, is one that an LLM-based assessment system can meet, and we have measured one that does.
It is not a claim that the pipeline has been validated on medicinal-product records. Our measurements are on medical-device documents, of which about 100 of 3,150 pages needed OCR. Scanned and handwritten batch records put most of their load on that stage, and the OCR result above is the relevant one.
It is also not a claim that a replayable system is accurate. The next piece of evidence we owe is an expert study of assessment accuracy, and we are looking for regulatory-affairs and quality professionals, in devices and in pharmaceuticals, to take part in it.
Materials
- Preprint: arXiv:2610.21300v1 (CC BY 4.0).
- Supplementary data and analysis scripts: Zenodo, DOI 10.5281/zenodo.23282335 (CC BY 4.0). The deposit includes recorded inputs and outputs, per-stage hashes, environment records and analysis scripts, but not the assessment pipeline’s source code.
- European Commission, Draft EU GMP Annex 22: Artificial Intelligence (2025 consultation draft).
- Enveda, “CDP: a language-model system for quality review of executed pharmaceutical batch records” (October 2026).
Ryosuke Suzuki is CTO of GFLOPS, which develops AskDona, and is an inventor on a provisional patent application related to this work.