Skip to content

Shut Down an AI System

Ending an AI system responsibly is as important as launching one well. This journey helps you decommission safely.

Step 1
Decide
Step 2
Plan
Step 3
Communicate
Step 4
Execute
Step 5
Close

Step 1: Confirm the Decision

Make sure shutdown is the right choice and properly authorised.

Valid Reasons to Shut Down

Reason Consideration
Risk exceeds benefit Document the risk assessment
No longer needed Confirm with all stakeholders
Being replaced Ensure replacement is ready
Cannot be fixed Document remediation attempts
Compliance failure Legal/regulatory requirement
Budget cuts Executive decision documented

Before Deciding

Read: When to Kill a Project

Questions to answer:

  • Who has authority to make this decision?
  • Have we explored alternatives?
  • What's the impact on users and processes?
  • Are there contractual obligations (vendors, partners)?
  • What are the sunk cost considerations?

Get Authorisation

  • Decision-maker identified
  • Business case for shutdown documented
  • Formal approval obtained
  • Stakeholder notification plan approved

Step 2: Plan the Shutdown

A poorly planned shutdown can cause as much damage as a poorly planned launch.

Impact Assessment

Area Questions
Users Who relies on this? What's their alternative?
Processes What workflows break? What needs redesign?
Data What happens to the data? Retention requirements?
Integrations What other systems connect to this?
Contracts Vendor agreements, SLAs, notice periods?
Compliance Audit trail requirements? Regulatory notifications?

Timeline Planning

Recommended timeline:

Milestone Timing
Decision announced T-8 weeks
User notification T-6 weeks
Alternative solutions available T-4 weeks
Training on alternatives T-3 weeks
Final warning T-1 week
Shutdown T
Post-shutdown support T+2 weeks

When you can't wait:

If safety, legal, or security issues require immediate action:

  1. Shut down immediately
  2. Communicate concurrently
  3. Provide emergency alternatives
  4. Document decisions for later review
  5. Plan orderly decommissioning of remaining components

Technical Planning

Components to address:

  • Model endpoints/APIs
  • Training pipelines
  • Data stores
  • Monitoring and logging
  • Scheduled jobs
  • Infrastructure resources

Components to address:

  • API integrations
  • Prompt templates
  • User interfaces
  • Vendor account/contract
  • Usage tracking
  • Cost allocation

Step 3: Communicate

Clear communication prevents confusion and maintains trust.

Stakeholder Communications

Audience Message Focus Channel
End users What changes, when, alternatives Email + in-app
IT/Support Technical changes, new processes Direct briefing
Executives Decision summary, impact, timeline Brief/memo
Vendors Contract termination, timeline Formal notice
Partners Integration changes Direct outreach

Key Messages

  1. Why - The reason for shutdown (honest but appropriate)
  2. When - Clear dates and milestones
  3. What instead - Alternatives available
  4. Support - How to get help during transition
  5. Thanks - Acknowledge those who used/built it

Step 4: Execute the Shutdown

Systematic execution prevents loose ends.

Pre-Shutdown Checklist

  • All stakeholders notified
  • Alternatives in place and tested
  • Data backup/export completed
  • Audit logs preserved
  • Rollback plan ready (just in case)

Shutdown Sequence

  1. Disable new users/requests - Stop growth
  2. Migrate active users - Help them transition
  3. Set read-only mode - If applicable
  4. Final data export - Last chance for users
  5. Disable service - Turn it off
  6. Archive assets - Code, data, documentation

Data Handling

Data Type Action Retention
Model artifacts Archive or delete Per policy
Training data Return, delete, or archive Per agreements
User data Return to users or delete Per privacy policy
Logs/audit trail Archive Per compliance requirements
Documentation Archive Permanent

Step 5: Close Out

Formally complete the shutdown and capture learnings.

Administrative Closure

  • Infrastructure decommissioned
  • Vendor contracts terminated
  • Costs stopped accruing
  • Access permissions revoked
  • Project closed in tracking systems

Documentation

Preserve for the future:

  • Why the system was shut down
  • Timeline of shutdown process
  • Lessons learned
  • What worked well
  • What would you do differently

Lessons Learned

Questions to document:

  • Why did we build this in the first place?
  • What would have told us earlier this wouldn't work?
  • What did we learn that helps future projects?
  • Who needs to know these lessons?

Celebrate (Seriously)

Shutting down a system that isn't working takes courage. It's a success:

  • Resources freed for better uses
  • Risk removed from the organisation
  • Honest assessment over sunk cost fallacy
  • Learning generated for future efforts