You can't shut down what you can't see. A bipartisan bill now requires certain AI companies to maintain the ability to shut down, throttle, or suspend their models. The Department of Homeland Security could issue that order. But legislative authority means nothing if you don't know which endpoints, APIs, cloud resources, and identity systems connect to your AI infrastructure.
Scope
This guide covers practical steps for mapping and managing AI system dependencies within your existing infrastructure. You'll find specific guidance on inventory practices, dependency mapping techniques, and shutdown procedures that work in production environments. This isn't about compliance theater; it's about building executable shutdown plans before an incident forces your hand.
Key Concepts and Definitions
AI System Dependency: Any component your AI system requires to function, including data sources, authentication services, compute resources, external APIs, and downstream consumers of AI outputs.
Shutdown Surface: The complete set of components you must disable, throttle, or isolate to effectively stop an AI system. This includes not just the model endpoint, but every integration point.
Integration Cascade: The chain reaction that occurs when you disable one component. Your AI model might call three APIs, which each call five more services, which connect to identity systems your other applications use.
Executable Shutdown Policy: A documented procedure that maps directly to infrastructure controls you can actually trigger. "Shut down the AI system" isn't executable. "Disable API key X, revoke IAM role Y, terminate EC2 instance Z" is.
Requirements Breakdown
Inventory Requirements
Your AI inventory needs four data points minimum:
System identifier and purpose: What does this AI system do? "Customer support chatbot" or "fraud detection model" works. "AI-powered insights platform" doesn't tell you enough.
Technical endpoints: Every URL, API gateway, webhook, or service mesh entry point. Include internal and external endpoints.
Authentication mechanisms: API keys, OAuth tokens, service accounts, IAM roles. You can't shut down what you can't authenticate to.
Compute resources: Container names, Lambda function ARNs, VM instance IDs. Where does the actual inference happen?
Dependency Mapping Requirements
Map three layers deep from each AI system:
Layer 1: Direct dependencies: What does your AI system call directly? Vector databases, preprocessing pipelines, model serving infrastructure.
Layer 2: Shared infrastructure: What do those dependencies rely on? Your vector database uses your identity provider. Your preprocessing pipeline reads from your data lake. Your model serving uses your container orchestration platform.
Layer 3: Downstream consumers: What calls your AI system? Your mobile app, your web application, your batch processing jobs. Shutting down the AI system breaks these consumers.
Document all endpoints, APIs, cloud resources, identity systems, and more.
Change Management Requirements
Your dependency map expires the moment someone ships new code. Treat AI system changes like you treat production database schema changes:
- Require infrastructure-as-code for all AI deployments
- Tag cloud resources with the AI system identifier
- Log every API integration at deployment time
- Review the dependency map during incident response exercises
Implementation Guidance
Build Your Initial Inventory
Start with your cloud provider's resource tags. If you're on AWS, query for resources tagged with "ai-system" or "ml-model". If you don't have tags, start tagging today before you do anything else.
Query your API gateway logs for the past 30 days. Filter for endpoints that return inference results. Look for patterns: /predict, /inference, /chat, /generate. Each pattern represents a system you need to inventory.
Check your identity provider's service account list. AI systems often use dedicated service accounts. Each account maps to a system.
Map Dependencies Systematically
Pick one AI system from your inventory. Open your observability platform and trace a single request end-to-end. Follow it through every service boundary. Document each hop.
For each service the request touches, answer three questions:
- Can this service function without the AI system? (Identifies hard dependencies)
- Can the AI system function without this service? (Identifies your shutdown surface)
- What else uses this service? (Identifies blast radius)
Repeat for your three highest-risk AI systems. High-risk means customer-facing, financially material, or handling sensitive data.
Design Executable Shutdown Procedures
Your shutdown procedure needs to be a runbook, not a policy document. Write it for the engineer who's being paged at 2am, not for the compliance auditor.
For each AI system, document:
- The specific API keys to revoke (include the key IDs)
- The IAM roles to disable (include the role ARNs)
- The compute resources to terminate (include instance IDs or container names)
- The load balancer rules to modify (include the rule IDs)
- The expected impact on downstream systems
Test your shutdown procedure in a staging environment. Time how long it takes. Document what broke.
Common Pitfalls
Assuming you can shut down just the model endpoint: Your model endpoint might be stateless, but your preprocessing pipeline maintains connections to your data warehouse. Your vector database caches embeddings in Redis. Your API gateway has rate limiting rules that assume the AI system is available. Shutting down one component doesn't isolate the system.
Forgetting about cached responses: Your CDN caches AI-generated content for 24 hours. Your mobile app caches responses locally. Your batch processing job downloaded predictions yesterday. Disabling the API doesn't stop these cached responses from circulating.
Overlooking indirect authentication paths: You revoked the API key, but the AI system also authenticates via your service mesh's mutual TLS. You disabled the IAM role, but the container still has credentials baked into the image. You changed the password, but the session tokens are valid for another hour.
Treating the dependency map as a one-time project: Your map is outdated the moment your team deploys new code. Without continuous updates, you're planning a shutdown based on last quarter's architecture.
Quick Reference Table
| Action | What to Document | Where to Find It | Shutdown Method |
|---|---|---|---|
| Disable API access | API key IDs, OAuth client IDs | API gateway console, identity provider | Revoke keys, disable clients |
| Revoke permissions | IAM role ARNs, service account names | Cloud IAM console, identity provider | Detach policies, disable accounts |
| Stop compute | Instance IDs, container names, function ARNs | Cloud compute console, container orchestrator | Terminate instances, scale to zero |
| Block network traffic | Security group IDs, firewall rule names | Cloud networking console, firewall management | Remove ingress rules, add deny rules |
| Invalidate caches | CDN distribution IDs, cache keys | CDN console, Redis/Memcached | Purge cache, update TTLs to zero |
| Disable integrations | Webhook URLs, event subscriptions | Integration platform, event bus | Delete webhooks, pause subscriptions |
Your next step: Pick your most critical AI system. Open your architecture diagram. Count how many components you'd need to touch to shut it down completely. If you don't have an architecture diagram, that's your actual next step.
