Because approval often attaches to a declared model, not to the live service that users actually hit. If the provider swaps the model, hosting location, or upstream dependency, the organisation may inherit a new risk profile without a new review. That is why governance has to track operational identity, not just procurement records.
How approvals can stay current while governance still drifts
The approval can remain valid on paper while the service that actually executes the workload changes underneath it. That creates a classic governance gap: the approved object is stable, but the operational reality is not. The risk is not only policy non-compliance, but also stale assumptions about hosting, dependency chain, and control boundaries.
When a model swap happens, the organisation may still be “approved” for one risk profile while operating under another. That matters because downstream controls, logging expectations, data handling, and jurisdictional assumptions can all change without a fresh review.
What changes materially when the model, host, or dependency changes
AI model changes are governance-relevant because they can alter who operates the system, where the service runs, what data it touches, and which upstream vendors now sit in the trust path. Identity Security Programme Guide is useful here because it frames governance around operating reality, not just procurement records, and that is exactly the control problem this question exposes.
A provider-side swap can also change the assurance basis for the service. If the model is replaced, the live service may inherit different retention terms, safety properties, content filters, regional processing, or incident-handling obligations. For governance, the key question is whether the approval covered a named version or the operating envelope that users actually depend on.
That is why current practice increasingly treats model versioning, hosting location, and third-party dependencies as governance inputs, not technical footnotes. A clean procurement trail does not guarantee a clean operational trail.
Why operational identity matters more than static approval records
Governance breaks when the control owner tracks a document rather than the live service. The practical unit to govern is the operational identity of the service, meaning the exact combination of model version, deployment location, dependency chain, and authority under which the service is running. If any of those elements changes, the original approval may no longer describe the real risk surface.
Agentic AI Security Policy Template helps operationalise this idea by centring registration, ownership, access, monitoring, and retirement on the live system rather than an abstract label. That same principle applies to model governance, where the approval should follow the service instance and its dependencies.
Agentic AI Compliance Guide is also relevant because it ties audit evidence to the current system state. When evidence does not reflect the active model or hosting arrangement, compliance becomes stale even if the original sign-off was valid when issued.
Risk and Threat Considerations
Model swaps can create silent exposure because the change often looks operational rather than governance-related. The organisation may continue to rely on an unchanged approval while the provider has altered the risk profile through a new model, a new region, or a new subcontracted dependency. That weakens accountability and can also complicate incident response if the service behaves differently from the approved baseline.
Failure mechanism: The approval attaches to a declared asset, but the production service changes its operational identity after review, leaving the control owner blind to a new hosting, dependency, or data-flow state.
Impact: The organisation can end up relying on outdated assurances for access, privacy, resilience, logging, and vendor oversight, which increases the chance of an unreviewed control failure or regulatory gap.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
NIST AI RMF and NIST SP 800-53 Rev 5 set the technical controls, while ISO/IEC 42001:2023 and ISO/IEC 27001:2022 define the regulatory obligations.
| Framework | Control / Reference | Relevance |
|---|---|---|
| ISO/IEC 42001:2023 | A.8.4 — AI system development and deployment | Model swaps and hosting changes alter AI system deployment state. |
| Recommendation — Require change control for model, hosting, and dependency updates before continued use. | ||
| NIST AI RMF | GV.2 — Map | The question is about governance drift when AI service reality changes. |
| Recommendation — Map live model and dependency changes into governance records and review triggers. | ||
| NIST SP 800-53 Rev 5 | CM-3 — Configuration Change Control | Unreviewed model or hosting changes are configuration changes with governance impact. |
| AU-6 — Audit Record Review, Analysis, and Reporting | Governance needs evidence that the active service matches the approved state. | |
| Recommendation — Enforce formal change control for model, hosting, and dependency modifications. Review logs and records to detect when the live AI service diverges from approval. | ||
| ISO/IEC 27001:2022 | A.5.9 — Inventory of information and other associated assets | Governance depends on knowing the current AI service and dependency inventory. |
| Recommendation — Maintain an accurate inventory of models, hosts, and dependent services. | ||
Practitioner Guidance
What to verify: Confirm that approval records are version-specific and that the approved object matches the active model, region, and dependency chain. If the live service has changed but the ticket has not, the approval is no longer a reliable control.
Decision rule: If the provider can change the model or hosting path without triggering a new review, treat that as a governance defect and require re-approval on the service state, not the procurement entry.
What good looks like: The organisation can prove, for any live AI service, exactly which model is running, where it is hosted, which upstream services it depends on, and who owns the current approval decision.
Practitioner takeaway: Governance is sound only when the review follows the live operational service. If the approval cannot move when the service moves, the control has become ceremonial.
Related resources from NHI Mgmt Group
- Why do AI model servers create NHI governance risk even when deployed locally?
- Why does model drift create risk even when the AI system is still running?
- Why do AI agents in shared threads create governance risk even when the model itself is working correctly?
- Why do AI-generated malware techniques still create risk even when the code changes on every run?
Deepen Your Knowledge
Free weekly newsletter
Subscribe to the NHI & AI Identity Journal
The latest on NHI and Agentic AI security – articles, research, breaches, news and events every week.
Bonus 33% off our NHI Course when you subscribe.
Reviewed and updated by the NHIMG editorial team on October 11, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org