GOVERN 1.7 Decommissioning AI systems: evidence

What GOVERN 1.7 asks for when retiring an AI system

GOVERN 1.7 expects an organization to have documented processes and procedures for decommissioning and phasing out AI systems safely, without increasing risk or reducing the trustworthiness the organization has built. When a model, agent or AI-enabled service is being replaced, retired or switched off, the team needs a written process that it can show to an internal reviewer, an auditor or a regulator. NIST AI 100-1 is voluntary and has no certification, so nobody issues a badge for this. The requirement is met through your own policy, your own decision records and the evidence those records point to, which is why the work has to be planned before the switch-off date arrives.

This requirement is easy to miss for three reasons. Decommissioning is often handled as an IT task, such as deleting a virtual machine or revoking an API key, when the AI-specific questions are about users, business processes and downstream decisions. Dependencies are hidden: other services may call the model's endpoint, reports may depend on its outputs, and a retrieval index or fine-tuned variant may be shared with another system. Retained data and models also outlive their owners. Training sets, logs, prompts, evaluation results and model weights can sit in backups or object storage long after the project team has moved on, and nobody is clearly accountable for them. A useful first check is to ask who would answer for the system's records if a complaint or investigation arrived next year, and whether the inventory entry (see GOVERN 1.6) would show that person.

Which AI systems, data and third parties fall under decommissioning

Decommissioning work varies widely depending on where a model runs, what it touches and who depends on it. The cards below cover the scoping decisions that determine how much evidence, coordination and retained data a retirement needs under GOVERN 1.7 Decommissioning AI systems.

In-house models versus third-party AI services

A model you train and host yourself gives you control over its weights, serving stack and retained artifacts, so you must remove or archive all of them. A third-party AI service keeps its own copies of your prompts, outputs and logs under its own retention terms. Confirm which party holds each artifact, and whether the contract requires the provider to delete data on exit and in what form.

Generative AI versus other models

Generative AI systems add prompts, system instructions, retrieval indexes and tool configurations to the model itself, and each can carry sensitive content. NIST AI 600-1 suggests that generative AI deployments have protocols to deactivate the system when needed and that data retention, data leakage and system dependencies are considered at decommissioning. Classical predictive models usually need less of this, but their training data and feature pipelines still require review.

Customer-facing versus internal systems

Customer-facing systems carry notice, complaint and continuity obligations, and users may rely on their outputs for decisions. Internal systems may still hold employee data and shape business decisions. The Playbook suggests addressing user and community concerns in decommissioning policy, so the communication plan, the support window and the path for affected people should match the audience's exposure.

Systems that feed other systems

A scoring model, classifier or summarizer may be called by downstream applications, reports or other AI components without its owner knowing. Map upstream inputs and downstream consumers before switching anything off, because removing a feeder can silently break decisions. Record each dependency and confirm that the owners of dependent systems have accepted the cutover date.

Data, logs and prompts that outlive the application

Training data, inference logs, evaluation results, prompt histories and feedback records often persist long after the application is retired. Regulatory data retention rules, possible legal or forensic investigations and migration needs determine how long each set must be kept and where. Confirm retention periods with legal counsel before deletion, and document what was kept, where it sits and who may access it.

Model weights and vector stores

Model weights, fine-tuned adapters and vector stores built from internal documents are artifacts that can leak sensitive content or be restored into a new environment. Decide whether each is archived for traceability, destroyed or migrated, and record the decision with the storage location. Access to archived weights and indexes should stay restricted after the application is switched off.

Vendors whose contracts end with the system

Contracts for model APIs, hosted vector databases, annotation services and data labeling often end with the system but keep data processing or retention obligations alive. Check termination clauses, data return and deletion commitments, and written confirmation of deletion. Under GOVERN 6 supplier governance, these exit terms belong in the decommissioning checklist, not in a later procurement review.

How an assessor tests GOVERN 1.7 and what passes

This table sets out how an assessor would test GOVERN 1.7 across policy, sampled retirements, retention and artifact recovery, with the evidence each test asks for and the findings that usually appear. Read each row as a test the organization should be able to pass before an assessor arrives. NIST does not certify against the AI RMF, so the results are for internal or customer-facing assurance only.

Test area	Test approach and evidence requested	Common findings
Decommissioning policy and approvals	Confirm a written decommissioning procedure exists, covers user and community concerns, and was approved by the accountable owner. Request the version history and approval record.	No written policy, or a policy that exists only in a project plan with no approver named.
Sampled retired systems	Select a sample of retired AI systems and request the dependency review, user notice, cutover plan and sign-off for each. Confirm the steps in the procedure were followed in practice.	Dependency reviews skipped, users not notified, or retirement recorded without a sign-off.
Upstream and downstream dependencies	Check that each sampled retirement lists consumers, data feeds, APIs, integrations and downstream reports, and that each was re-pointed or closed before shutdown.	Downstream reports or automated jobs still calling a retired model or endpoint after shutdown.
Retention periods	Compare the retention period set for each retired system's data, logs and model artifacts against the legal, regulatory and business requirements recorded under GOVERN 1.1. Request the retention schedule and deletion records.	Retention periods set by default, not by requirement, or no deletion or extension decision recorded.
Preserved artifacts and recovery	Ask the team to locate a sampled model version, training data reference, evaluation report and decision log for a retired system within a set time. Confirm storage location and access controls.	Artifacts stored on personal drives or in deleted repositories, or no index showing where they are kept.
Replacement and migration	Review the migration plan that moved users or workloads to a successor system and the testing that confirmed the successor met the same requirements.	Migration treated as complete without comparing outputs, or accountability for the successor not assigned.
Shadow AI systems	Compare the AI system inventory maintained under GOVERN 1.6 with network, cloud and application records to find systems that were never registered and so never reviewed for retirement.	Shadow AI systems never inventoried, so they run beyond the decommissioning process.
Retained data ownership	Request the list of retained datasets and stores tied to retired systems, with a named owner and an end date for each. Confirm that owners were told when their data would be deleted.	Retained data with no owner or end date, which leaves it outside any review cycle.

How to implement decommissioning in six steps

This sequence turns GOVERN 1.7 into a documented, repeatable retirement process so that an AI system can be phased out without leaving unmanaged dependencies, lost records or users who were never told it was ending. Each step closes with a named artifact that an internal reviewer or independent assessor can inspect.

Define the decommissioning policy and triggers
Write the policy that says when an AI system is retired and who approves it. Name the triggers the policy recognizes, such as end of business need, a failed risk review, a vendor withdrawing support, a regulatory change or a replacement going live. Assign an accountable owner and a sign-off path. The output is a decommissioning policy and a trigger register, approved by the accountable executive and linked to the AI inventory entry for the system. The step is done when every system on the inventory can be mapped to at least one trigger and an owner.
Map upstream and downstream dependencies
Identify everything the system depends on and everything that depends on it. Upstream items include training and reference data, pre-trained models, APIs, libraries, prompts, retrieval indexes and identity connections. Downstream items include applications, dashboards, reports, business processes and other AI systems that consume its outputs. Engineering owners confirm each link with the system's operators. The output is a dependency map that records each link, its owner and its failure impact. The step is done when the owners of the system and of each dependent service have signed off the map.
Set notice and business continuity plans
Decide who must be told that the system is ending, what they must be told and by when, based on the policy and on the impact recorded in the dependency map. Cover affected users, the teams that rely on outputs and, where the system touches people outside the organization, the communities or customers who were affected by it. Document the business continuity plan for functions that lose the system, including manual fallbacks and the non-AI alternatives where they exist. The output is a notice plan and a continuity plan. The step is done when the notices have been issued and the fallback owners have accepted their roles.
Decide retention and forensic holds
Decide what must be kept after shutdown and for how long, using the retention rules that apply to the data, logs and records the system produced. Consider possible future legal or forensic investigations, incident reviews and audits. Record where decommissioned models, datasets, prompts, evaluation results and logs will be stored, who can access them and when they will be destroyed. Legal and privacy staff confirm the retention periods. The output is a retention decision record that names each artifact class, its storage location, its access rule and its disposal date. The step is done when the record is approved and the storage location is confirmed to exist.
Run migration to a replacement and validate it
If a replacement system exists, move the workload to it in a controlled sequence, with the same dependencies rewired and the same data handling rules applied. Run the replacement against the test cases and monitoring thresholds used for the retiring system, and compare outputs during a parallel run. Record any differences and decide whether each one is acceptable. Where no replacement exists, the validation confirms that the non-AI alternative covers the business need. The output is a migration log and a validation report with sign-off from the business owner. The step is done when the validation report shows no unresolved differences that the owner has not accepted.
Shut down and deactivate the system
Disable user access, stop scheduled jobs, revoke service credentials and API keys, and turn off inference endpoints. Confirm that the system no longer receives requests and no longer writes new outputs. For generative AI systems, the Generative AI Profile calls out the need for protocols that allow deactivation when necessary. Verify each shutdown step against a checklist. The output is a shutdown checklist with timestamps and the name of the person who confirmed each action. The step is done when monitoring shows zero traffic and the infrastructure owner confirms the endpoints are closed.
Record closure and update the inventory
Archive the decommissioned system's artifacts according to the retention decision record and update its entry in the AI inventory to show it is retired. Write a closure memo that summarizes the reason for retirement, the dependencies handled, the notices issued, the replacement used, the retention locations and any open issues. Send the memo to the accountable owner and to the governance function that reviews AI risk. The output is a closure memo and an inventory record marked retired. The step is done when the governance function has accepted the memo and no open item remains without an owner. Confirm the required review cycle with your own governance policy.

Evidence that shows a decommissioning was done safely

A safe decommissioning leaves a trail that an assessor, regulator or incident investigator can follow from the decision to retire a system through to its final closure. The six artifacts below connect the policy, the per-system record, the dependency and retention decisions, the migration check and the sign-off that closes the file.

Decommissioning policy with approvals

The written policy sets the rules every retirement must follow: who may request a decommissioning, who approves it, how user and community concerns are considered, and when a system must be retired. Check that the policy names the approvers by role, carries a version history and shows the date each approver signed it. Without signed approval, a later reviewer cannot tell whether the rules were in force when a system was retired.

Per-system decommissioning record

Each retired system needs its own record that states why it was withdrawn, which version was running, when service stopped and who carried out each step. The record should point to the matching AI inventory entry so the retirement is visible in the system register. Confirm that the record captures the deactivation step, since GOVERN 1.7 expects safe deactivation to be possible when a system must be switched off.

Dependency map

A dependency map lists the upstream data feeds, models, APIs and the downstream applications, reports and people that rely on the system being retired. It is the basis for a sound plan because a retirement that breaks a downstream process increases risk. Check that the map was built from the running environment and reviewed by the owners of each dependent system, not only by the team that operates the model.

Retention and legal hold decisions

This record states what data, logs, model versions and evaluation results are kept after retirement, where they are stored, for how long, and who can access them. It should also show whether any legal hold or forensic need applies. Ask for the retention schedule and confirm it matches the regulatory retention rules that apply to your sector, since the Playbook names regulatory data retention and possible future investigations as factors.

Migration validation results

When a replacement system takes over, the validation results show that the new system performs the same function within the agreed limits and that users and dependent processes still work. Keep the test cases, the comparison results, the sign-off of the business owner and any issues found during cutover. Where the system is generative AI, also record how data leakage and configuration risks were checked during migration, as NIST AI 600-1 suggests.

Closure sign-off

The closure sign-off confirms that every task in the decommissioning record is complete, that access has been removed, that the stored artifacts are in the designated location, and that the inventory status is changed to retired. It is the final signature on the file and should be given by the accountable owner, not only the engineer who ran the shutdown. An assessor will test whether closure dates, access removal and inventory status agree with each other.

What meeting GOVERN 1.7 costs in money and effort

This table breaks down the cost components of decommissioning an AI system under GOVERN 1.7, showing who is paid for each, whether it is one-time or recurring, and what drives it up. Most of the spend is internal staff time, so the drivers listed are the levers to review before requesting a quote. No prices or durations are given because none were supplied for this topic.

Cost component	One-time or recurring	What drives it	How to keep it down
Decommissioning policy drafting	One-time, with periodic review	Number of AI system types in scope, legal review cycles, and how many user and community concerns the policy must address	Build one standard procedure with system-specific annexes instead of a policy per system
Dependency mapping	One-time per system, updated on change	Number of upstream and downstream integrations, data feeds and embedded models, and how current the asset records are	Use an existing inventory and logging data to find dependencies before manual interviews
Migration engineering	One-time per retirement	Whether a replacement system exists, data format changes, cutover testing and rollback planning	Plan migration into the replacement project scope and reuse existing test environments
Archive storage for retained artifacts	Recurring until the retention period ends	Volume of models, logs, prompts and evaluation records kept, plus the storage location and retention length set by regulators	Define a retention schedule per artifact type and purge what the schedule no longer requires
Legal and records review	One-time per retirement, plus recurring checks where retention rules change	Sector rules on data retention, legal hold risk, and the need for forensic readiness	Ask counsel to approve a standard retention template once, then apply it per system
Assessor sampling and evidence	One-time per assessment cycle	Number of decommissioned systems the assessor samples and how complete the decommissioning records are	Keep one dated record per retirement covering decision, dependencies, data disposition and sign-off
Inventory and logging tooling	Recurring if licensed, otherwise staff time	License fees for commercial asset and logging products, and the number of endpoints or model components tracked	Self-hosted open-source tooling can remove license spend for inventory and logging, though staff time for setup and upkeep remains

Which self-hosted open-source tools can produce decommissioning evidence

No open-source tool decides whether an AI system should be retired, and none replaces the decommissioning policy. The four tools below can, however, produce records that show what was running, what depended on it, and what state it was in when it was taken out of service. Each covers a different part of the evidence trail.

Locating retired assets with GLPI

The GLPI Assets module tracks computers, software, network equipment and other items, entered by hand or pushed automatically by the GLPI Agent through native inventory. For GOVERN 1.7, the asset records help teams find every host, device and software package that a retiring AI system touched, so none is left running or unaccounted for. Check that the asset status changes are dated and that disposal of hardware follows your data retention rules. Confirm that inventory data reflects the retired system before you close the record.

Proving access and services were removed

The Wazuh Syscollector module collects installed software, running services, users and groups, open ports and network interfaces from each endpoint and stores them in the Wazuh indexer. Snapshots taken before and after shutdown can show that the service, its accounts and its listening ports are gone. Ask which collection interval applies to your endpoints and keep the pre-decommissioning snapshot as part of the retirement record. Inventory views show what the endpoint reports, so verify the removal on the host as well.

Mapping downstream dependencies with Langfuse traces

Langfuse records each trace of a request, including LLM calls, retrieval steps, tool executions and custom logic, with timing, inputs, outputs, token usage and metadata. For GOVERN 1.7, traces reveal which tools, retrieval sources and calling applications still rely on the system, which is the starting point for upstream and downstream dependency analysis. Export and retain the trace history for the period set by your retention policy, since it may later support investigations. Traces only show dependencies that actually ran during the observed period.

Recording the last test state with garak

garak probes language models for hallucination, data leakage, prompt injection, misinformation, toxicity generation and jailbreaks. It writes a JSONL report of every attempt and evaluation, plus a hit log of attempts that found a vulnerability. Keeping these files, with the model version and configuration, documents the system's security posture at retirement, which helps during later reviews or investigations. Store the reports with the model identifier they tested, or the record loses its meaning.

Who owns decommissioning, who can help, and where the assessor stops

Your organization owns every decision about retiring an AI system. The owner of each system decides when it is phased out, what replaces it and which users are affected. Legal and records staff set how long decommissioned models, prompts, logs and training data must be kept and what can be deleted. The security team approves removal of access, service accounts, API keys and data connections, and confirms that retained artifacts are locked down. No outside party can make these calls on your behalf.

System owner: signs off the retirement date, the replacement system and the communication to users and affected communities.
Legal and records staff: define regulatory data retention periods and flag any hold for possible future legal or forensic investigation.
Security team: approves revocation of credentials, removal of integrations and the access rules for archived artifacts.
Business continuity owner: confirms that downstream processes can run without the system or on its replacement.
Inventory owner: updates the AI system inventory so the retired system is marked as decommissioned with the storage location of its artifacts.

Before the retirement starts, check that each of these roles is named in writing and that the decommissioning policy says who can approve each step.

Where decommissioning programs usually fall short

Most decommissioning gaps trace back to one problem: the organization stops tracking a system before it has finished retiring it. The cards below cover the places where that gap usually appears, from the inventory to retained data and notices to affected people, with a specific fix for each.

Retired systems missing from the inventory

When a system is switched off but its record is deleted, nobody can later tell that it ever existed, which makes forensic review and legal hold work slow. Keep retired entries in the AI inventory with a status, a retirement date, an owner and a link to the decommissioning record. Check that the inventory review run under GOVERN 1.6 also reports on retired systems that still have live credentials, endpoints or stored data.

Dependencies discovered during an outage

Teams often find out that a downstream report, API consumer or scheduled job relied on a model only after it stops responding. Before the shutdown date, map upstream and downstream dependencies from service logs, API gateway records and integration configurations, not from memory. Require each consuming team to confirm in writing that they have moved to the replacement or accepted the loss of the function.

Retained data without an end date

Training sets, prompt logs and conversation traces are often kept indefinitely because no one owns the deletion decision. Record each data store tied to the retired system, the regulatory retention rule that governs it, and the date it will be deleted or archived. Ask legal counsel to confirm which retention periods apply in your jurisdiction, since these vary by sector and data type.

Models and prompts in unmanaged storage

Model weights, prompt templates and evaluation outputs are copied into shared buckets, notebooks and personal drives during a migration and never removed. Move preserved artifacts into one access-controlled archive with a named custodian, an access log and a retention end date. Generative AI deployments also need the deactivation protocol and data leakage checks described in NIST AI 600-1 before the old endpoint is closed.

No proof that users were told

Affected users, business units and community groups may learn about a retirement from a broken workflow rather than a notice. Keep a dated record of who was notified, through which channel, what changed for them, and where they could raise a concern or request a manual alternative. This record is the evidence that the decommissioning policy addressed user and community concerns, and it should be stored with the decommissioning file.

Access left open after shutdown

Service accounts, API keys, vector store credentials and cloud roles often outlive the system they served and remain valid for months. Revoke credentials and remove network routes as a dated step in the decommissioning checklist, then confirm the removal with an access review. Keep the revocation record as evidence that the system no longer processes data after its retirement date.

Questions buyers ask about GOVERN 1.7 decommissioning

Does decommissioning an AI system require a certificate under the NIST AI RMF?

No. The NIST AI RMF is voluntary and has no certification, accreditation or conformity assessment program, so no certificate is issued for GOVERN 1.7. NIST does not validate or endorse any organization's use of the framework. If a customer or regulator asks for evidence, the organization shows its decommissioning policy, retirement records and retained artifacts. An independent auditor can test those records against a separate standard, such as ISO/IEC 42001, if one applies. DeployOpen prepares systems and evidence but does not issue reports or certificates.

How much effort does decommissioning an AI system take, and what drives it?

The effort depends mostly on how many other systems depend on the one being retired, how much data and how many model versions must be kept, and whether a replacement system is ready. A standalone internal model with no downstream consumers is usually a small task. A system embedded in customer workflows, reporting pipelines or third-party integrations takes longer because each dependency must be mapped, tested and migrated. Ask any provider for a written breakdown of discovery, migration, data handling and evidence work, and ask which items are one-time and which recur, such as archive storage and periodic access reviews.

How long does a decommissioning project take?

No general duration is published for this work, so the timeline must be set from the written scope. The main drivers are the dependency map, the number of consumers that need notice, the migration path to a replacement, legal holds or forensic requirements, and how long the retention period runs before archived artifacts can be moved. Organizations often phase the shutdown, running old and new systems in parallel for a period. Confirm with the team whether the timeline includes archive verification and a post-retirement check, not only the switch-off date.

What must the organization supply before decommissioning starts?

The organization must supply the decision authority, the current AI inventory entry, a list of upstream and downstream dependencies, the data sources and retention rules that apply, and the names of the people who will receive notice of the change. It must also state the business continuity requirement and any legal or forensic obligations. Without these, the team cannot define what to preserve or where to store it. Your implementation partner can prepare runbooks and evidence templates, but the policy decisions and risk acceptance stay with the organization.

Can we decommission an AI system in-house?

Yes, if the team has the skills and time to map dependencies, run the migration, verify archives and write the records. Many organizations keep ownership in-house and bring in outside help only for specific gaps, such as a migration engineer, an independent review of the retention plan or a test of whether retired endpoints still accept traffic. Decide which parts you will own before requesting a quote, and ask for the deliverables in writing. DeployOpen works on fixed-scope engagements agreed in writing before work starts.

How should retained data and artifacts be stored, and for how long?

Retention is set by the organization's legal, regulatory and business requirements, not by a fixed period in the NIST AI RMF. The Playbook suggests defining where and for how long decommissioned systems, models and related artifacts are stored, and considering regulatory data retention and possible legal or forensic investigations. Store preserved items in a controlled location with access logging, integrity checks and a documented owner. Confirm the retention period with legal counsel and the relevant regulator before deletion, and record the destruction date when the period ends.

How should we handle generative AI systems under GV-1.7-001 and GV-1.7-002?

NIST AI 600-1 asks organizations to have protocols that let generative AI systems be deactivated when necessary, and to consider data retention, data leakage and system dependencies when decommissioning them. In practice, test the deactivation path, revoke API keys and credentials, and confirm that prompts, outputs and logs containing sensitive data are handled under your retention rules. Check dependencies on hosted models, vector stores and tool integrations, since these often sit outside the core application. Logs from observability tools may contain prompts and outputs, so review them before archiving or deleting.

How DeployOpen scopes and prepares GOVERN 1.7 evidence

DeployOpen helps organizations build the decommissioning procedures and evidence that GOVERN 1.7 calls for, inside the client's own infrastructure. Work starts with a written, fixed scope that names the AI systems to be retired, their dependencies and the artifacts to be preserved. The organization keeps ownership of its policies and decisions, and an independent assessor reviews the outcome.

How we scope

Agree in writing which AI systems, models and components fall inside the decommissioning scope before work begins.
Map upstream and downstream dependencies, integrations and data flows that a retirement would affect.
Confirm with the client which retention rules, legal holds and forensic needs apply, and who approves each decision.

How we build

Draft a decommissioning procedure covering user communication, business continuity and a migration path to the replacement system.
Configure logging and inventory records in the client's own tools so retired systems and their state stay traceable.
Test the retirement steps in a non-production environment and document the results before any live shutdown.

How we hand over

Deliver the written decommissioning procedure, dependency register and retention schedule for the client's approval.
Provide an archive record listing where retired models, configurations and logs are stored and for how long.
Hand over runbooks and evidence files so the client's own staff can repeat the process and show it to an assessor.

How we support

Engagements are fixed-scope, so scope, deliverables and timelines are agreed in writing before work starts.
Ongoing support, upgrades and periodic review of the procedure are available as a retainer.
Confirm with DeployOpen during scoping which evidence an independent assessor will need, since DeployOpen prepares evidence but does not issue reports or certificates.