To assess your business’s dependence on AI services, trace each service—including AI built into suppliers’ products—to the work it supports, judge the consequences of losing or degrading it, and document a tested fallback for high-impact workflows. Set disruption and recovery targets for your own business; NIST guidance does not prescribe a universal AI-outage score or recovery time.
What counts as an AI dependency?
Include more than tools your staff deliberately open. An AI dependency may be a purchased application, a model or API called by your software, or an AI feature embedded in a third-party product. It may also depend on upstream data, integrations, credentials, or other software. The NIST AI RMF Playbook recommends identifying and documenting third-party AI systems and components and managing risks tied to external resources.
As an Amazon Associate I earn from qualifying purchases.
Map dependencies from business work outward: start with a function or workflow, then identify the people, systems, services, data, and suppliers it relies on. This can reveal AI components that are easy to miss because they are bundled into a supplier’s offering.
Recommended Free Tools
How to assess the business impact
Use a business impact analysis (BIA) to identify mission-essential functions, the assets that enable them, and the consequences of disruption. NIST’s IR 8286D, Using Business Impact Analysis to Inform Risk Prioritization and Response, describes BIA as a basis for prioritizing risk and shaping response. Apply that approach to workflows that rely on AI rather than treating every AI tool as equally important.
#1 Best Overall
Consider different failure conditions, not just a service being completely offline. A workflow could be affected by loss of access, slow responses, inconsistent or degraded output, a provider change, or failure of an upstream data or software component. These are practical scenarios to assess, not a formal NIST outage taxonomy.
For each scenario, record what work stops or slows, what becomes less accurate, and whether the result could affect customers, finances, safety, privacy, or compliance. Identify the accountable owner and the length of disruption the function can tolerate. A service used in a nonessential task may warrant a different response from one supporting a mission-essential function.
Rank #2
Use a worksheet for each AI-enabled workflow
The following worksheet is a practical synthesis of BIA and third-party contingency guidance, not a NIST-prescribed form. Complete one entry for each workflow that matters to business operations.
- Function and owner: Name the business function, workflow, and accountable person.
- Dependency map: Record the AI service, provider, model or API, embedded components, and upstream dependencies known to your organization.
- Operating requirements: List the inputs, outputs, integrations, credentials, data, and staff processes required to keep the workflow running.
- Impact if disrupted: Note what would stop, slow down, or become less accurate, and the likely customer, financial, safety, privacy, or compliance consequences.
- Tolerance and recovery: Set how long the function can tolerate disruption and an appropriate recovery target for that function.
- Fallback readiness: Record whether a manual process, alternate provider, cached or offline capability, or other redundancy exists; who can activate it; and what quality or data tradeoffs it brings.
- Incident handling: Specify how the issue will be detected, who will be notified, how decisions will be recorded, and how normal operation will resume.
Choose and document a usable fallback
For each high-impact workflow, make the fallback actionable rather than simply noting that an alternative exists. NIST’s AI RMF Playbook advises organizations to verify contingency processes for mission-critical third-party AI systems and suggests considering redundancy for vital third-party AI functions. It states: “Verify contingency processes for handling negative impacts associated with mission-critical third-party AI systems.”
Rank #3
Document these decisions for each fallback:
- Trigger: What outage or degradation is serious enough to switch?
- Authority: Who can approve the switch?
- Procedure: What manual process or alternate service will staff use?
- Work handling: Will work be queued, processed at reduced capacity, or handled another way?
- Return to service: How will the organization decide that the primary service is safe to resume, or that it should remain out of use?
Compare fallback options against business needs
When there are genuine alternatives, compare them on the factors that affect the workflow and the business, rather than assuming that switching providers is simple. NIST’s cited guidance does not supply a fixed scorecard; the comparison below applies its focus on impact, third-party risk, and contingency planning.
| Factor | Question to answer |
|---|---|
| Recovery time | How quickly can the alternative take over, including setup and approval? |
| Impact while unavailable | What customer, operational, financial, safety, privacy, or compliance effects remain during the transition? |
| Portability | Can the necessary data, prompts, workflow, and configuration move to the alternative? |
| Substitutability | Can another provider or model perform the required task, and what changes are needed? |
| Security and privacy | Does the fallback change how information is handled or who can access it? |
| Output quality | What quality differences or added review are expected? |
| Operational complexity | Can staff operate the alternative reliably under outage conditions? |
| Maintenance cost | What effort is required to keep the fallback ready and exercise it? |
Set local recovery targets and exercise the plan
Choose disruption tolerances and recovery targets according to the business impact, customer commitments, safety considerations, applicable legal or regulatory requirements, and supplier contracts. NIST’s BIA and contingency materials support this planning, but do not set one recovery time that fits every AI service or organization.
Rank #4
Exercise the fallback so staff can verify that the trigger, authority, procedure, and return-to-service decisions are workable. Revise the plan when staff, systems, workflows, or provider arrangements change. The cited guidance does not establish a universal exercise frequency, so set one that fits the function’s risk and operating needs.
What NIST guidance does—and does not—require
The NIST AI Risk Management Framework (AI RMF) is voluntary guidance for incorporating trustworthiness considerations into AI design, development, use, and evaluation; it is not itself a binding legal requirement. NIST’s AI RMF page says the framework is being revised and reports a concept note released April 7, 2026, for a profile on trustworthy AI in critical infrastructure. Its companion Playbook organizes suggested actions under Govern, Map, Measure, and Manage.
Best Value
The cited material does not establish industry-specific legal duties, supplier contract terms, mandatory recovery times, or a universally correct continuity plan. Check the requirements that apply to your jurisdiction, sector, suppliers, and affected business functions.
Quick Recap
Product prices and availability are accurate as of the date/time indicated and are subject to change. Any price and availability information displayed on Amazon at the time of purchase will apply.
