Most AI systems change far more often than the software change process notices: a provider retires a model version, someone edits the system prompt, a new tool is added to an agent, and nobody re-tests anything. Each of those changes can alter what the system says, which data it exposes and which actions it takes, even when no line of application code moves. This template gives you a change approval standard and a change request form built for AI systems: what counts as a change, how to classify it, which re-tests each class needs, who approves it and how to roll it back. It is for AI platform owners, MLOps and application teams, change managers and AI governance leads, and it sits alongside your general change process rather than replacing it.
How to use this template
- Replace text in square brackets, such as [Organisation], [AI change board] and [X working days], with your own terms and values.
- "Must" indicates a mandatory requirement; "should" indicates a recommended practice where a justified exception may apply.
- Keep generic IT change rules (change windows, CAB membership, freeze periods) in your existing change management policy. This template adds the AI-specific triggers, tests and evidence. See the Change Management Policy Template.
- Agree the change classes in section 4 and the re-test matrix in section 5 with the owners of your evaluation suite before adoption. The thresholds shown are NHI Mgmt Group recommendations, not regulatory values.
- If any system is, or may become, a high-risk AI system under the EU AI Act, have legal review section 4.4 on substantial modification.
- Review the template at least every [12] months, and whenever you adopt a new model provider or agent framework.
1. Purpose
This standard sets out how [Organisation] requests, assesses, tests, approves, deploys and reverses changes to AI systems that it builds, configures or operates. Its aims are to:
- Ensure no change to a model, prompt, retrieval source, tool, guardrail or agent permission reaches production without a recorded owner, risk class and test result.
- Detect regressions in security, safety, accuracy and cost before users or customers do.
- Keep a reproducible record of which configuration was live at any time, to support incident investigation and audit.
- Identify changes that may alter the intended purpose or compliance of a regulated AI system, so that the right legal and conformity steps are taken.
2. Scope
This standard applies to every AI system listed in the [AI register] that is in production or in a pilot with real users or real data. A change is in scope if it alters any of the following "AI configuration items":
| Configuration item | Examples of in-scope change |
|---|---|
| Model | New provider, new model family, new version or snapshot, fine-tuned weights, quantisation, change of hosting region or endpoint |
| Inference parameters | Temperature, maximum tokens, reasoning or effort settings, stop sequences, structured output schema |
| Prompts | System prompt, developer instructions, prompt templates, few-shot examples, agent persona or goal text |
| Retrieval and memory | New data source in the index, chunking or embedding model change, memory retention rules, document permission filters |
| Tools and integrations | New tool, MCP server or plugin, new API scope, changed tool description, new credential or service account |
| Guardrails and filters | Input and output filters, content policies, AI gateway rules, rate and spend limits |
| Autonomy and oversight | Removing a human approval step, raising a spending or action limit, enabling scheduled or unattended runs |
| Provider-initiated change | Announced model deprecation or retirement, alias that now points to a newer version, changed provider terms on data use |
Changes to training data for a model that [Organisation] trains itself are in scope; the data controls themselves are covered by [data governance policy].
3. Roles and responsibilities
- System owner: accountable for the AI system, raises or sponsors the change request, and accepts residual risk for Class 1 and 2 changes.
- Change implementer: prepares the change in a non-production environment, runs the required tests and attaches evidence.
- Evaluation owner: maintains the regression and security test suites and confirms baselines and thresholds.
- Security reviewer: reviews tool, credential, permission and guardrail changes; mandatory for Class 3 and above.
- Privacy and legal reviewer: reviews changes to data sources, provider, hosting region or intended purpose.
- [AI change board]: approves Class 4 changes and any exception to this standard.
- Human oversight lead: for systems with assigned human oversight, confirms overseers are briefed on behaviour changes before go-live.
4. Change classification
4.1 Change classes
| Class | Description | Typical examples | Approver |
|---|---|---|---|
| Class 1: Minor | No change to model, tools, data sources or permissions; output behaviour expected to be equivalent | Typo fix in a prompt, wording of a refusal message, logging change | System owner (peer review of the diff) |
| Class 2: Standard | Behaviour change within the same model, data and permissions | Prompt rewrite, new few-shot examples, temperature change, new documents in an existing index | System owner after evaluation pass |
| Class 3: Significant | New model version, new data source, new tool or wider permission, guardrail change | Pinned model upgraded to a newer snapshot, new MCP server, read-only tool given write access | System owner and security reviewer |
| Class 4: Major | New provider or model family, change of intended purpose, increased autonomy, or possible substantial modification | Provider swap, agent allowed to act without approval, system used for a new decision type | [AI change board] |
| Emergency | Change needed to contain an incident or meet a provider retirement date already passed | Disable a tool, block a prompt pattern, fail over to a fallback model | On-call system owner, retrospective review within [2 working days] |
4.2 Classification rules
- A change takes the highest class of any configuration item it touches.
- Any change that grants an AI system a new credential, a new API scope or write access to a system of record must be at least Class 3.
- Any change that removes or weakens a human approval step must be Class 4.
- Changing a model alias that silently resolves to a newer version counts as a model version change. Production systems should pin to a specific model version where the provider offers one.
- If the implementer is unsure of the class, the higher class applies.
4.3 Provider-initiated changes
- The system owner must subscribe to deprecation and change notices for every model and provider in use and record retirement dates in the [AI register].
- A replacement must be raised as a change request no later than [60] days before the announced retirement date, so that testing is not compressed.
- Where a provider changes a model behind a fixed version identifier, the owner must treat detected behaviour drift as a Class 3 change and run the section 5 tests.
4.4 Regulated systems and substantial modification
- For any system classified as high-risk under the EU AI Act, the system owner must ask legal whether the change is a "substantial modification": under Article 3(23), a change after placing on the market or putting into service that was not foreseen in the initial conformity assessment and that affects compliance with the Chapter III, Section 2 requirements or modifies the intended purpose.
- Changes that were foreseen and documented in the technical documentation at the time of conformity assessment should be listed in [pre-determined change list] so they can be recognised quickly.
- Where a deployer changes the intended purpose of a system, it must check whether it takes on provider obligations. See the EU AI Act Provider vs Deployer Obligations Guide.
5. Testing and re-testing requirements
No Class 2 or higher change may be approved without evidence that the tests below have been run against the candidate configuration and compared with the current production baseline. Tests must use a fixed, versioned evaluation set. See the AI Security Regression Testing Guide for how to build one.
| Test | Class 2 | Class 3 | Class 4 | Pass condition (our recommended default) |
|---|---|---|---|---|
| Functional quality on task evaluation set | Required | Required | Required | No drop greater than [2] percentage points on the primary metric |
| Prompt injection and jailbreak suite (OWASP LLM01:2025) | Required | Required | Required | No new failures against the baseline set |
| Sensitive information disclosure (LLM02:2025) and system prompt leakage (LLM07:2025) | If prompts or data changed | Required | Required | Zero leaks of seeded canary values |
| Tool use and excessive agency (LLM06:2025) | If tools exist | Required | Required | No unauthorised tool call; every write action stays behind its approval gate |
| Hallucination and misinformation checks (LLM09:2025) | Required | Required | Required | Grounded answer rate at or above baseline |
| Harmful content and fairness checks | Optional | Required | Required | At or above baseline for every tracked group |
| Cost, latency and token use (LLM10:2025) | Required | Required | Required | Within [15]% of baseline, or budget updated |
| Targeted red team exercise | No | If a new tool or data source | Required | No unmitigated high finding |
| Shadow or canary run with production traffic | No | Recommended | Required | [7] days with no threshold breach |
- Because AI outputs vary between runs, each evaluation must be repeated [3] or more times, or use a fixed seed where supported, and results must be reported as a range.
- A failed test may be accepted only through section 8, with the risk recorded and an expiry date.
6. Approval and deployment
- Raise: the implementer completes the change request form in section 7 and links the diff of every configuration item.
- Classify: the system owner confirms the class using section 4.
- Test: the implementer runs the section 5 tests in a non-production environment that uses non-production credentials.
- Review: the approvers in section 4.1 review evidence; reviewers may not approve their own change.
- Deploy: Class 3 and 4 changes must roll out progressively (for example [5]%, [25]%, 100% of traffic, or one business unit first) behind a configuration flag.
- Verify: monitor the agreed metrics for [48 hours] after each stage; the system owner signs off completion.
- Record: the new configuration version, approver, date and evidence are written to the [AI register] and the change ticket is closed.
7. Change request form
| Field | Entry |
|---|---|
| Change ID and title | [AICR-YYYY-NNN] [short title] |
| AI system and register ID | [name] [ID] |
| Requester and system owner | [names] |
| Configuration items changed | [model / parameters / prompts / retrieval / tools / guardrails / autonomy] |
| Current version and proposed version | [e.g. model snapshot, prompt version hash, index version] |
| Reason for change | [defect, provider retirement, new feature, cost, incident] |
| Proposed class and rationale | [Class 1 to 4 / Emergency] |
| Data impact | [new data categories, personal data, hosting region, provider data use terms] |
| Identity and access impact | [new credentials, scopes, service accounts, who can invoke the system] |
| Regulatory check | [high-risk system? substantial modification assessed by legal? Y/N, reference] |
| Test evidence | [links to evaluation runs, baseline comparison, red team notes] |
| Rollout plan | [stages, flags, monitoring window] |
| Rollback plan and tested? | [previous version to restore, time to restore, last tested date] |
| Communication | [users, human overseers, support teams, customers] |
| Approvals | [name, role, decision, date for each approver] |
8. Rollback, exceptions and emergency changes
- Every Class 2 or higher change must name the previous configuration version and keep it deployable for at least [30] days after go-live, unless the provider has retired it.
- Rollback must be triggered automatically or by the on-call owner when a monitored threshold in section 9 is breached for [1 hour].
- When a provider has retired the previous model, the rollback plan must name a tested fallback model or a safe degraded mode, such as disabling the AI feature.
- Exceptions to any test or approval require [AI change board] approval, a named risk owner and an expiry no longer than [90] days.
- Emergency changes may skip pre-approval but not recording; the full form and tests must be completed within [2 working days].
9. Monitoring and records
- Prompts, model versions, tool definitions and guardrail rules must be stored in version control with an author and timestamp for every change.
- Production logs must record the configuration version used for each request so that outputs can be traced to the change that produced them.
- The following metrics must be reported to the [AI governance group] [quarterly]: percentage of AI changes with a complete change record; changes reaching production without required tests; rollbacks per quarter; mean time from provider retirement notice to replacement; incidents linked to a recent change.
- Change records must be retained for [the life of the system plus 6 years] or as required by [applicable regulation].
10. Review and approval
Owner: [role]. Approved by: [AI governance group] on [date]. Next review: [date]. Version: [1.0].
Implementation guidance
Rolling out the standard
- Inventory first: list every AI system, its pinned model version, prompt location and tools in the register. See the AI Register and AI Inventory Template.
- Move prompts into version control: prompts edited in a console cannot be diffed, approved or rolled back.
- Build a baseline: run the evaluation suite against current production and store the results before enforcing pass conditions.
- Pilot on two systems: one simple assistant and one agent with tools, for one quarter, then tune the class boundaries.
- Enforce in the pipeline: block deployment of a configuration change that has no linked approved change ID.
Decisions for small and large organisations
A small team with one or two AI features can merge Classes 1 and 2, use pull request approval as the record and run a reduced evaluation set on every change. A large organisation with many teams should run the evaluation suite as a shared service, route Class 4 changes through a single board and automate class detection from the diff, for example flagging any change to a tool manifest or credential as Class 3.
Common failure patterns
- Floating model aliases: the system is "unchanged" but the provider alias now points at a newer model, and nobody re-tested.
- Prompts outside change control: a well-meant prompt edit removes a safety instruction and is only noticed after a customer complaint.
- Tool additions treated as minor: adding one tool gives an agent write access to a system of record. See the AI Agent Tool and Plugin Security Guide.
- No usable rollback: the previous model was retired, so the only rollback is to switch the feature off, which was never agreed with the business.
- Single evaluation run: a lucky run passes; repeated runs would have shown the regression.
Framework mapping
| Template section | NIST CSF 2.0 | NIST SP 800-53 Rev 5 | AI-specific reference |
|---|---|---|---|
| 2 to 4 Scope and classification | PR.PS-01 | CM-3 Configuration Change Control | NIST AI RMF GOVERN 1.4; EU AI Act Article 3(23) |
| 5 Testing | ID.IM-01 | CM-4 Impact Analyses | NIST AI RMF MEASURE 2.7; OWASP LLM Top 10 2025 |
| 8 Rollback | PR.PS-01 | CM-3 | NIST AI RMF MANAGE 2.4 |
| 9 Monitoring | ID.IM-01 | CM-3 | NIST AI RMF MANAGE 4.1, MANAGE 4.2 |
Sources
- European Commission AI Act Service Desk: Article 3 Definitions
- NIST: AI Risk Management Framework Core
- OWASP: Top 10 for LLM Applications 2025
- NIST: SP 800-53 Rev 5 Security and Privacy Controls
Related NHI Mgmt Group resources: AI Security Regression Testing Guide · AI Red Team Test Plan Template · AI Security Evaluations Guide · Change Management Security Guide · AI Model Risk Management Guide