Your AI stack is also a dependency map.

Use this guide to: identify the dependencies needed to deliver a working AI service.

List what must keep working

A customer sees an application. Its delivery may depend on identity services, data access, retrieval, a model endpoint, compute capacity, logging and a payment system. The dependency map should follow a real request from input to accepted outcome. An architecture diagram becomes commercially useful when it shows which failure can interrupt that outcome.

For each dependency, record the owner, replacement options, contractual commitments and the time needed to switch. Keep a distinction between an alternative that exists in principle and one that has actually been evaluated for the workload. The second is stronger evidence of resilience.

Separate model portability from service portability

An application may be able to send requests to a second model with a small code change. That does not establish comparable quality, latency or capacity. Its prompts, retrieval process and review rules may need adjustment. The acceptable fallback is the one that still meets the customer's requirements.

The OECD's 2025 report on competition in AI infrastructure discusses the interconnected supply chain behind compute. Our interpretation for an individual operator is to inspect dependencies across the stack. Replacing a model endpoint does not automatically replace the cloud, hardware or data arrangement on which delivery relies.

Read the commercial minimums

A supplier can be technically replaceable while remaining commercially expensive to leave. Identify reserved capacity, minimum spending, data-transfer charges, notice periods and rights to stored outputs. These are diligence questions, not assertions about the terms of any particular provider.

Use the current contract and dated product documentation. A remembered pricing page is a weak foundation for a migration estimate. Where the terms are ambiguous, record the ambiguity and request clarification before treating the migration as an available option.

Test the fallback as a service

Choose a small representative workload and run it through the proposed alternative. Measure accepted output, response time, review effort and total cost. Confirm that the expected capacity can actually be obtained. Document the steps that still require manual intervention.

Then ask what happens to requests in progress, stored data and the customer-facing promise during a switch. A fallback that works only after several days may be useful for continuity planning, but it does not satisfy a promise of uninterrupted service. Match the plan to the commitment.

Pay for flexibility deliberately

Extra portability and spare capacity have costs. The goal is not to eliminate every dependency. It is to choose which dependencies to accept, which to reduce and what evidence justifies that choice. Revisit the map when the workload, supplier terms or operating scale changes.