Change Control for Prompt and Model Updates in Validated AI Tools

Why a Text Edit Is a System Change

In a conventional validated system, a change usually arrives as code or as a configuration setting in an administration screen. It goes through a developer, a build, a test environment, and a release. The change control process was designed around that path, and it works reasonably well for it.

A tool built on a large language model (LLM) behaves differently. A large part of its behavior is written in plain language. The system prompt tells the model what role to take, what to refuse, and what format to return. A handful of worked examples in the prompt show it what a good answer looks like. Retrieval settings decide which documents it reads before it answers. Generation parameters such as temperature decide how much the output varies from one request to the next. Many of these items can be edited in a text field by anyone with access, and the edit takes effect on the next request. There is no build and no release note.

That is why teams under-control these tools. The edit feels like correcting a sentence in a work instruction, not like changing software. But the sentence is the software, or at least a large part of it.

Small Edits, Large Effects

The research record on this is consistent. Sclar and colleagues, in a paper presented at ICLR 2024, tested how several widely used open-source models responded to subtle changes in prompt formatting in few-shot settings. They found performance differences of up to 76 accuracy points on one model (LLaMA-2-13B) from formatting choices alone, and the sensitivity did not go away with larger models or instruction tuning.¹ Their recommendation was to report performance across a range of plausible formats rather than trust a single one. For a quality team, the practical lesson is simpler: an edit that a reviewer would call cosmetic can move results by a large margin.

Practitioners in the GxP validation community have reached the same conclusion from the other direction. Writing for ISPE’s Pharmaceutical Engineering in August 2026, Sambit Mohapatra noted that “AI systems may be more sensitive to change than traditional systems,” with small changes in instructions, retrieval sources, input data, or configuration settings having a significant effect on output. He added: “This creates pressure on change control and regression testing.”²

A software engineering study makes the point for model versions. Ma, Yang, and Kästner observed that LLM APIs are updated and scheduled for deprecation, which forces the applications built on them to keep adapting. Their case study on toxicity detection showed performance regression after model updates, along with effects on which prompt design choices worked. They argued that regression testing for LLM-based software needs basic changes to traditional methods, because of unclear notions of correctness, brittle prompts, and non-deterministic output.³

What the Draft EU Texts Say

The regulatory position is still forming, so it helps to be exact. In July 2025 the European Commission and PIC/S opened consultation on a revised Annex 11 (Computerised Systems) and a new Annex 22 (Artificial Intelligence) for the EU GMP guide. As of late September 2026 both remain drafts. Neither is in force.

The draft Annex 11 is direct about change. It says the pharmaceutical quality system should ensure that any change to a computerized system, “including but not limited to its configuration,” its hardware and software components, and its platform and operating system, is made in a controlled manner under defined procedures, and that any significant change that may affect product quality, patient safety, or data integrity should be subject to re-qualification and validation.⁴ It also asks that configuration choices be documented in a controlled configuration specification (section 6.6).⁴

The draft Annex 22 has a short, clear change control clause. Section 10.1 says a tested model, the system it runs in, and the process it supports should be put under change control before use, that any change to the model, the system, or the process should be documented and evaluated to decide whether the model needs retesting, and that “Any decision not to conduct such retest should be fully justified.” Section 10.2 adds configuration control and asks for effective measures to detect unauthorized change.⁵

There is an important limit. The draft Annex 22 applies to static models with deterministic output. It states that it does not apply to generative AI and LLMs, and that such models should not be used in critical GMP applications. Where they are used in non-critical GMP applications, qualified people should always be responsible for confirming that outputs are suitable, and the draft says its principles may be considered where applicable.⁵ EMA has since reopened the generative AI question, which we covered in our note on the June 2026 Annex 22 expert workshop.

So for an LLM-based tool used in GxP-relevant but non-critical work with human review, the obligation to control change comes from Annex 11, your quality system, and ordinary computerized system validation (CSV) practice. The Annex 22 change control clause is still the clearest written statement of what an inspector will look for, and it is sensible to apply it by analogy.

Define the Configuration Baseline First

You cannot decide what counts as a change until you have written down what the system is. For LLM tools this step is often skipped, because the validation package describes requirements and test results in detail but records the prompt as an attachment, if at all, and never lists the other settings that shape output.

The configuration management discipline from IT security gives a useful vocabulary. NIST Special Publication 800-128 defines a configuration item (CI) as a discrete target of configuration control, and it defines a baseline configuration as “a set of specifications for a system, or CI within a system, that has been formally reviewed and agreed on at a given point in time, and which can be changed only through change control procedures.”⁶ That is exactly what a validated LLM tool needs: a list of configuration items, each with an approved version, and a rule that none of them changes outside change control.

What Goes in the Baseline

The table below is the list we start from. Not every tool has every item, and some tools have more. The point is to name every item that can change output, and to know who is able to change it today.

Two rows deserve a comment. The knowledge content row is where most unrecorded change happens in retrieval-based tools: the tool’s answers change every time someone adds or replaces a document in the index, and no one touches the tool itself. The evaluation assets row is on the list because changing how results are scored changes what the scores mean. A regression set or grading prompt that can be edited freely makes every later test result hard to defend.

Record the Items You Do Not Control

Some of what shapes output belongs to the vendor, and a baseline should say so plainly rather than imply control you do not have. Anthropic’s documentation offers a clear example. It states that each Claude model ID identifies a pinned version and that “Anthropic does not update the weights or configuration of an existing model ID.” In the same page it explains that the serving infrastructure around the model, including the request router, safety classifiers, and sampling logic, can change over time, and that “Occasionally, infrastructure updates produce minor differences in observable behavior even when the model ID and weights have not changed.”⁷

That is an honest description, and it has a direct consequence for validation. Pinning the model ID controls the largest source of change, but not all of it. The baseline should record the pinned ID, note that vendor-side infrastructure is outside your control, and name the compensating control you use to detect shifts. We describe that control, a scheduled check run, in the vendor section below.

Make Unauthorized Change Detectable

The draft Annex 22 asks for “effective measures” to detect any unauthorized change.⁵ The draft Annex 11 asks periodic reviews to identify undocumented changes, for example by configuration auditing.⁴ For an LLM tool, a few simple technical measures meet this well:

• Keep prompt text and configuration in version control, not in an administration screen that keeps no history. Each approved baseline gets a version identifier.
• Compute a fingerprint (a hash) of the deployed prompt and configuration at runtime and log it with every output. If the fingerprint does not match an approved baseline, the tool raises an alert.
• Query the deployed model version from the platform on a schedule. Microsoft’s documentation notes that the deployments endpoint returns the model version for each deployment, so this check can be automated.⁸
• Remove edit rights in production from the people who author prompts. Authors work in development. Releases move through the same path as any other change.

The logged fingerprint has a second benefit that is easy to overlook. When an inspector or an investigator asks which configuration produced a particular output six months ago, you can answer from the record rather than from memory.

What Counts as a Change: Three Classes and an Emergency Path

Once the baseline exists, the definition of a change is straightforward: any change to a configuration item in the baseline. The harder question is how much work each change needs. Treating every prompt edit as a major change produces a process so slow that people find ways to avoid it. Treating them all as minor produces a validated state that no one can describe.

We use three change classes plus an emergency path. Every change gets a record. What varies is the depth of assessment, the testing, and who approves.

The table below shows how common changes sort. The reasons column matters more than the class, because the reasons are what the approver is checking.

Changes That Do Not Look Like Changes

The classes only work if changes reach the change process at all. These are the ones that most often do not:

• Knowledge base updates. Content owners add or replace documents as part of normal document control, unaware that doing so changes a validated tool’s answers.
• Vendor default version moves. A deployment set to follow the vendor’s default version will move to a new model when the default changes. We cover this in detail below.
• Vendor infrastructure updates. As noted above, these can change behavior with no change to the model ID.⁷
• Platform-level safety filters. A central team tightens a content filter across all deployments, and one tool begins refusing a class of legitimate requests.
• Changes to the inputs. The draft Annex 22 includes changes to the process and to the physical objects a model uses as input among the changes to evaluate.⁵ The document equivalent is a new template. If the deviation report form changes, a tool that summarizes deviation reports is now reading different input.
• Evaluation asset edits. Someone improves the grading prompt, and every score after that date means something slightly different.

For each of these, the fix is a trigger, not a policy statement. Document control for any document type that feeds a retrieval index should include a step that notifies the tool’s owner. The platform team’s change process should list the deployments each setting affects. Input template changes should name downstream tools in their impact assessment.

Sizing the Impact Assessment

An impact assessment for a prompt or configuration change is shorter than one for a new system, but it has to answer questions that a conventional software change assessment does not ask. The draft Annex 22 expects activities to be based on risk to patient safety, product quality, and data integrity, and it expects close cooperation among process experts, QA, data scientists, and IT.⁵ In practice that means the process owner and the system owner answer the questions below together.

Justifying a Decision Not to Retest

The draft Annex 22 sentence on retesting sets a useful standard: a decision not to retest should be fully justified.⁵ For LLM tools, we recommend making that decision rare. Once the regression set runs automatically, a full run takes minutes to hours of machine time and a short review of results. The effort of writing a defensible justification for skipping it is often greater than the effort of running it. The main legitimate case for not retesting is a Class A change, where the fingerprint check shows that no output-affecting item changed. That check is itself the evidence.

Who Signs

Approval should follow the class. For Class A, the system owner. For Class B, the process owner, who understands what a wrong output means in the business process, and the system owner, who understands the configuration. For Class C, add QA, and add whoever owns any downstream system or procedure that changes. The prompt author should never be the approver of their own change. This is ordinary segregation of duties, and it matters more when the change is a paragraph of text that anyone can read and feel qualified to judge.

Regression Testing With a Fixed Test Set

The regression set is the most important part of the process. It is the one piece of evidence that shows the changed configuration still does what the validated configuration did. It needs to be built with care, protected from the people whose work it judges, and read in a way that respects the fact that LLM output varies.

Build the Set From the Intended Use

The draft Annex 22 gives sound guidance on test data even though its scope excludes LLMs. It asks that test data be representative of the full sample space of the intended use, stratified to include all subgroups, and inclusive of common and rare variations, with the selection rationale documented. It asks that labels be verified to a very high degree of correctness, and it says that generating test data or labels with generative AI is not recommended and should be fully justified.⁵

Anthropic’s guidance on building evaluations adds practical detail from the model developer’s side. It recommends designing test cases that mirror the real-world task distribution and not forgetting edge cases, such as irrelevant or nonexistent input data, overly long inputs, and ambiguous cases where even people would struggle to agree.¹⁰

For a validated LLM tool, a workable regression set has five kinds of cases:

1. Core cases for each task in the intended use, in rough proportion to how often each task occurs.
2. Known hard cases that a process expert identifies: long documents, poor scans, unusual terminology, conflicting source statements.
3. Past failures. Every incident, complaint, or reviewer correction that reveals a real error becomes a new case once its root cause is understood.
4. Negative cases where the right answer is to decline, to say the information was not found, or to flag the input as out of scope.
5. Format cases that check the output structure any downstream step depends on.

Each case needs an expected result that a process expert has approved. For extraction and classification tasks, the expected result is usually exact. For drafting and summarizing tasks, it is a short rubric: the facts that must appear, the facts that must not, and the format rules. Our earlier piece on evaluating output quality when there is no ground truth covers rubric design in more depth.

Write Acceptance Criteria Before the Run

The draft Annex 22 asks that acceptance criteria be defined by a process expert, documented, and approved before acceptance testing begins, and that a test plan be approved before testing starts.⁵ The same discipline applies to each change. For change control, the most useful criterion is usually relative, not absolute: the changed configuration should perform no worse than the current approved configuration on every stratum of the set, and should introduce no new failures on cases marked critical. The draft’s “no decrease” principle, which says a model’s acceptance criteria should be at least as high as the performance of the process it replaces, points the same way.⁵

Writing the criteria first matters because LLM results invite rationalization after the fact. When a changed prompt improves the average and breaks three cases, it is tempting to decide those three were not important. If the criteria said in advance which cases are critical and what happens when one fails, the decision is already made.

Keep the Set Sealed

The draft Annex 22 spends a full section on test data independence. It asks that data used to test a model not be used in its development, that test data be protected by access control and an audit trail, and that it be recorded “which data has been used for testing, when and how many times.”⁵

For prompt-based tools, the specific risk is that the prompt author tunes the prompt against the regression set. After enough rounds, the prompt performs well on those cases and no one knows how it performs on anything else. The fix is to keep two sets:

• A development set that authors can see and use freely while they iterate.
• A release set that is access-controlled, run only by the release process, and never shown case by case to the author before the change is approved. Record each run, as the draft asks.

The release set should grow. Add new cases from incidents and from new behaviors on a schedule, version the set, and treat each new version as a change to an evaluation asset. When the set changes, run the current approved configuration against the new version first, so the baseline scores are known before any change is judged against them.

Handle Non-Determinism by Design

Many teams assume that setting temperature to zero makes outputs repeatable. The evidence says otherwise. Ouyang and colleagues studied ChatGPT code generation across 829 problems and found that setting temperature to zero does not guarantee determinism, though it does reduce variation compared with the default setting.⁹ Ma and colleagues list non-determinism as one of the three reasons that traditional regression testing does not transfer directly to LLM APIs.³

So the test design has to expect variation instead of hoping to remove it:

• Run each case more than once. Three to five runs per case is a reasonable starting point for most tools. Higher-risk cases may warrant more.
• Define a per-case pass rule in advance. For critical cases, require a pass on every run. For others, a stated proportion may be acceptable.
• Track stability as its own measure. If a change makes results less consistent across runs without lowering the average, that is still a regression for a tool whose users expect the same answer to the same question.
• Compare against criteria, not against the previous output text. Exact string comparison between old and new outputs will fail constantly and tell you nothing. Compare each output against the approved expected result or rubric.

Read Case-Level Flips, Not Only the Average

A change can raise the average score and still break cases that used to work. Researchers have documented this for model updates. In their MUSCLE paper, Echterhoff and colleagues found that when a base language model is updated, task-specific adapters built on it show “negative flips,” meaning previously correct instances are now predicted incorrectly, even when the downstream training procedure stays the same.¹¹ Their focus was fine-tuned adapters, but the pattern is familiar to anyone who has moved a prompt-based tool to a new model: the overall result looks better, and a user reports that a question the tool used to answer correctly now gets a wrong answer.

For change control, report three things for every regression run, by stratum:

The negative flip list is the part a reviewer should read line by line. Each entry is a specific input where a user who relied on the tool yesterday would get a worse answer tomorrow.

Choose Graders You Can Defend

Someone or something has to decide whether each output passes. There are three options, and most tools use a mix:

• Code checks for anything structured: exact field matches for extraction, label matches for classification, schema validation for format. These are quick to run and repeatable.
• Expert review against a rubric for judgment-heavy outputs. This is slower, so it works best on a smaller, high-risk subset of the set.
• An LLM grader that scores outputs against the rubric. This scales, and it needs its own controls. Zheng and colleagues, in work presented at NeurIPS 2023, found that strong LLM judges could agree with human preferences more than 80% of the time, about the same level at which humans agree with each other. They also documented position bias, verbosity bias, and self-enhancement bias, along with limited reasoning ability.¹²

If you use an LLM grader, treat it as an evaluation asset under change control, calibrate it against expert labels before relying on it, and check its agreement with experts again whenever the grader’s model or prompt changes. Where you can, avoid grading a model with a grader built on the same model, given the self-enhancement bias the researchers observed.

OpenAI’s evaluation guidance frames the operating goal well: it describes quantitative evals as useful benchmarks for automated regression testing, and recommends continuous evaluation that runs evals on every change and grows the eval set over time.¹³ For a validated tool, “every change” means every change that reaches Class B or Class C.

Vendor Model Updates From the Customer’s Side

Qualifying the vendor, including what they commit to about change notification, is a separate topic from the one here. This section is about your own process: what you do when the model under your validated tool is going to change, whether you chose that change or not. For vendor-side evaluation, our AI vendor evaluation scorecard is a starting point.

Pin the Version and Check the Upgrade Setting

Model providers and cloud platforms handle versions differently, and the difference matters. Anthropic states that its model IDs are pinned snapshots and that updated versions are released under new IDs.⁷ Microsoft Foundry lets each deployment choose an upgrade policy. Its documentation lists three options: opt out of automatic upgrades, in which case a deployment needs a manual upgrade and stops working when its model is retired; upgrade automatically once a new default version becomes available; or upgrade automatically when the current version expires. Microsoft notes that it notifies customers at least two weeks before a new version becomes a model’s default, and that update policies are set per deployment and vary by model and provider.⁸

For a validated tool, the upgrade policy is a validation decision, not an IT preference. A deployment set to follow the default version will move to a new model on the vendor’s schedule, and the first sign may be a user noticing different answers. We recommend that validated tools use a fixed version, that the chosen policy be recorded in the configuration baseline, and that the scheduled version check described earlier confirm the setting has not changed. The trade-off is explicit: a fixed version means the deployment will stop working at retirement, so the replacement must be planned well ahead.

Treat the Retirement Calendar as a Change Schedule

Every model version has a retirement date, and vendors publish them. That makes the largest change your tool will face a planned event with a known date. The change record should open when the vendor announces the deprecation, not in the last weeks before retirement. A sequence that works:

Watch for Changes Nobody Announced

Pinning and planning cover announced changes. They do not cover infrastructure changes that alter behavior under the same model ID, which Anthropic openly says can happen,⁷ or API-side updates that are not clearly communicated, which Ma and colleagues identified as a real concern for developers building on LLM APIs.³

The compensating control is a scheduled check run (software teams often call this a canary run): a small, fixed subset of the release set, run against the production configuration on a schedule, weekly for most tools. The scheduled check does not approve anything. It detects. If its results shift beyond a set tolerance and there is no change record to explain the shift, treat it as an unplanned event under your deviation or incident process. Our piece on AI incident management in GxP covers how to classify and investigate that kind of event.

When the Vendor’s Date Leaves No Time

Sometimes the plan fails. A retirement notice arrives with little lead time, or the replacement model fails the regression set and no alternative is ready. This is what the emergency path exists for. Cut over with a documented rationale, raise human review for the affected tasks (for example, full review of outputs that were previously sampled), and complete the full Class C evaluation within a fixed period. Then look at why the plan failed. If the cause was late notice from the vendor, that is an input to the vendor’s next periodic evaluation.

What the Change Record Must Show

The change record is what an inspector reads, and it is what your own team will read a year from now when someone asks why the tool behaves the way it does. For LLM tools, it needs a few elements that a conventional software change record does not.

Link Every Output to a Configuration Version

The single most useful habit is to log the configuration version (or its fingerprint) with every output the tool produces. It turns the change history into something an investigator can use. If a deviation summary drafted in March is questioned in September, the record shows which prompt, model, and retrieval index produced it, and the change history shows what has changed since. Our article on building an AI model registry describes where these version records can be kept alongside other model metadata.

Periodic Review Picks Up the Pattern

Change control handles changes one at a time. Periodic review looks at them together. The draft Annex 11 asks periodic reviews to cover changes to configuration since the last review, confirm that documentation reflects them, assess the combined effect of multiple changes, and identify undocumented changes, for example by configuration auditing.⁴ For LLM tools, the periodic review should also look at the trend in scheduled check results, the number of emergency changes, how many cases the release set gained, and whether the release set still reflects how the tool is used. Our note on periodic review for AI systems goes further.

Making the Process Workable

A process that is correct and slow will be bypassed. The goal is a process where the controlled path is also the easiest path for the people making changes.

Release on a Cadence

Most prompt and configuration changes are not urgent. Grouping them into a scheduled release, monthly for many tools, has three benefits. It reduces the number of regression runs and approvals. It makes the combined effect of several changes visible in one test, rather than leaving it to periodic review. And it gives users a predictable point at which behavior may change, which helps reviewers know when to pay closer attention. Urgent fixes still go through Class B on their own, and emergencies use the emergency path.

Pre-Approve the Changes You Expect

Some changes recur and are well understood. Adding newly approved documents of an existing type to a retrieval index is the common example. For these, a pre-approved change protocol can define in advance what is allowed, how it will be tested, and what results allow release without a new approval cycle.

The medical device side offers a model for this structure, though not a rule that applies to pharma. FDA’s final guidance on predetermined change control plans (PCCPs) for AI-enabled device software functions, in its current version dated August 2025, recommends that a plan describe the planned modifications, the methodology to develop, validate, and implement them, and an assessment of their impact.¹⁴ That guidance governs device marketing submissions and does not cover internal pharma tools. The three-part structure still translates well into an internal procedure: what may change, how it will be tested and released, and what the impact assessment concluded, all approved by QA once, with each use of the protocol recorded as a Class B change that references it.

Give Every Production Prompt an Owner

Each production prompt and configuration needs one named owner, usually the process owner or someone they delegate to. The owner decides which changes to request, keeps the development set current, and answers questions about why the prompt says what it says. Authors write and test in development. The release process, not the author, moves the approved configuration to production. If your environments are not set up to support that split, our piece on environment strategy for validated systems is relevant. Broader questions of how prompts are cataloged and reused are covered in our article on governing prompt libraries.

Keep the Burden Proportionate

Not every tool needs the full apparatus. A low-risk internal drafting aid, where every output is reviewed in full by a qualified person, may need a release set of a few dozen cases, a single run per case with expert review, and a light change record. A tool whose output drives a routing decision with sampled review needs much more. The classes, the baseline, and the sealed set scale down well. What should not scale down is the rule that every change gets a record and that the running configuration can always be matched to an approved one.

Conclusion

The difficulty with LLM-based tools is not that change control principles no longer apply. They apply fully. The difficulty is that the things that change are easy to overlook: a paragraph of instructions, a setting on a deployment page, a document added to an index, a version the vendor retires on its own schedule. The answer is to make those things visible. Write the configuration baseline so every output-affecting item has a name and a version. Sort changes into classes so the effort matches the risk. Gate releases on a sealed regression set, with criteria set in advance, repeated runs to account for variation, and a line-by-line reading of the cases that got worse. Plan vendor model changes from the day they are announced, and run a scheduled check to catch the changes nobody announced.

Sakara Digital works with pharma and biotech organizations that are putting LLM-based tools into GxP-relevant work and need a change control process that quality, IT, and the business can all live with. If you are working out how to bring prompts, configuration, and model versions under control without making every small improvement wait weeks, we are happy to talk it through and share what we have seen work.

For Further Reading