Providers should treat Annex IV updates as release-gating work whenever a model, prompt, training set, or intended purpose changes. If the evidence trail lags the deployed state, the organisation risks having a compliant-looking file that no longer describes the system being assessed or monitored.
Why Annex IV Updates Need to Move Before the Model Change Goes Live
Annex IV is not just documentation, it is part of the compliance record that describes what the system is, what it does, and how it has been assessed. If a provider ships a changed model or prompt while the evidence pack still reflects the old version, reviewers lose the ability to match the deployed system to the documented one. That gap is what makes Annex IV work release-gating rather than follow-up admin.
The practical trigger is any change that alters system behaviour, intended purpose, training data, or operational boundaries. A model update may be technically small but still material if it changes outputs, risk profile, or the controls needed to explain and supervise the system. In the EU AI Act regulatory framework, providers are expected to keep technical documentation aligned with the system as placed on the market or put into service, which is why the file set must move in step with the release.
That same logic applies when the change sits outside the weights file. Prompt changes, RAG changes, guardrail changes, and training set changes can all alter the effective system even if the model name stays the same. For a provider, the question is not whether the artefact changed, but whether the evidence trail still describes the actual behaviour and intended use of the current system.
What Counts as a Release-Gating Change
The easiest mistake is to treat only a full model replacement as a documentation event. In practice, Annex IV updates should be prioritised whenever the deployed behaviour changes enough that a regulator, auditor, or internal reviewer would ask a different question about the system. That includes shifts in intended purpose, scope of use, data sources, post-processing logic, fallback behaviour, and human oversight assumptions.
This is why providers should think in terms of AI management system governance, not just engineering release notes. The release package should show what changed, why it changed, and which sections of the technical record need revision before the updated system is treated as current. If the control story and the deployed system diverge, the documentation is no longer a reliable artefact for assessment or traceability.
For organisations running multiple models, the same rule applies to lineage and dependency changes. A new foundation model, a new adapter, or a materially different prompt chain can create a new compliance posture even when the product name remains unchanged. Providers should assume that anything affecting performance, autonomy, or intended purpose is likely to require Annex IV review before promotion to production.
How Providers Should Sequence Documentation, Review, and Deployment
The right operating model is to make the documentation delta part of the change gate, not a post-release cleanup task. In other words, the release should not be considered complete until the Annex IV record has been updated, validated, and versioned against the shipped system. That sequencing is what keeps the compliance file from becoming historical rather than evidential.
This is especially important in environments with third-party components, shared model services, or outsourced development because the provider still owns the coherence of the technical file. Even where a supplier delivers part of the model stack, the provider remains responsible for ensuring that the documented description, evaluation evidence, and intended use all describe the current system. CIS Controls v8 is useful here as a reminder that inventory, change control, and audit logging support that traceability function even when the regulatory duty is broader than any single control family.
Providers should also keep a clear distinction between minor tuning and material change. If the change alters outputs in ways that affect safety, transparency, performance, or user reliance, treat it as documentation-sensitive until proven otherwise. The safe default is to update the evidence trail first, then deploy, rather than hoping the file can be repaired later without losing consistency.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
CIS Controls v8 sets the technical controls, while EU AI Act and ISO/IEC 42001:2023 define the regulatory obligations.
| Framework | Control / Reference | Relevance |
|---|---|---|
| EU AI Act | Technical documentation and record-keeping | Annex IV is the AI Act technical documentation record for high-risk systems. |
| Recommendation — Update the technical file before release so it matches the deployed AI system. | ||
| ISO/IEC 42001:2023 | AI management system | The question is about governing AI changes through controlled documentation and release discipline. |
| Recommendation — Tie model releases to documented change control and versioned AI governance records. | ||
| CIS Controls v8 | CIS-8 — Audit Log Management | Traceability and change evidence support keeping documentation aligned with deployed systems. |
| Recommendation — Retain change and release evidence so the current system state can be reconstructed. | ||
Practitioner Guidance
What to verify: Before release, verify that the Annex IV file describes the exact model version, prompt logic, intended purpose, and evaluation state that will be exposed to users. If any of those four items are stale, the change should stay blocked until the record is corrected.
Decision rule: If the change can alter behaviour, outputs, scope of use, or the evidence needed to explain the system, treat Annex IV as release-gating work. If it only changes internal wording with no effect on assessed behaviour, document it through the normal change record but do not overstate it as a compliance event.
What good looks like: The deployed system, the technical documentation, and the approval history should all point to the same version and the same intended use. A reviewer should be able to reconstruct the current system without guessing which artefact is authoritative.
Practitioner takeaway: The documentation is not supporting material after deployment, it is part of the system’s control surface, so any change that moves the real system should move the Annex IV evidence trail first.
Related resources from NHI Mgmt Group
- How should teams decide when to prioritise prompt tuning over model changes?
- How should security teams prioritise NHI remediation in cloud environments?
- Should organisations prioritise external exposure or internal credential governance first?
- How does the consumer-secret-entitlement model help with governance at scale?