Special offer. See more information about Outbyte and uninstall instructions. Please review EULA and Privacy policy.

iTechGuides is reader-supported. When you buy through links on our site, we may earn an affiliate commission. As an Amazon Associate I earn from qualifying purchases. Learn more

To assess your business’s dependence on AI, trace each AI service—including features embedded in other vendors’ products—to the work it supports, then estimate what happens if it becomes unavailable or unreliable. Prioritize workflows by business impact, set recovery expectations for each, and document and test a fallback. There is no universal AI-dependency score or outage recovery target; the right plan depends on your operations, customers, safety and compliance needs, and supplier arrangements.

What counts as an AI dependency?

Look beyond AI tools employees intentionally open. A dependency may be a purchased application, a third-party model or API your software calls, or an AI feature built into a supplier’s product. The business may rely on it even if staff do not know which model or provider is behind the feature.

NIST’s AI Risk Management Framework (AI RMF) Playbook recommends identifying and documenting third-party AI systems and components, and managing risks associated with external resources. Its guidance is voluntary, not a binding legal requirement; NIST says the framework is being revised and notes a concept paper released April 7, 2026, for a profile on trustworthy AI in critical infrastructure. See the NIST AI Risk Management Framework and the NIST AI RMF Playbook.

Special offer. See more information about Outbyte and uninstall instructions. Please review EULA and Privacy policy.

Map AI services to the work they support

Start with business workflows rather than a vendor list. Ask teams what work they perform, which applications or services they use, and whether AI contributes to any step. Follow each dependency through the process: an AI feature may be only one component, while access credentials, integrations, input data, staff review, or another upstream service may also be necessary.

Record what is known and flag what is not. For embedded features, ask the supplier what AI components or upstream services the product relies on, how an outage or provider change is communicated, and what happens to the feature when its dependency fails. Avoid assuming that a product will continue working unchanged when an AI component is unavailable.

Estimate the business impact and set local targets

Use a business impact analysis (BIA) to identify mission-essential functions, the assets that enable them, and the consequences of disruption. NIST’s NIST IR 8286D, Using Business Impact Analysis to Inform Risk Prioritization and Response describes BIA as a basis for prioritizing risk and response. Apply that thinking to AI-enabled work: assess what stops, slows, becomes less accurate, or creates customer, financial, safety, privacy, or compliance consequences.

Do not treat availability as the only failure condition. A service may remain reachable while producing delayed, inconsistent, or degraded output. A provider change, or an outage in upstream data or software, can also disrupt the workflow. These are useful planning scenarios, not a formal NIST outage taxonomy.

Special offer. See more information about Outbyte and uninstall instructions. Please review EULA and Privacy policy.

For each important function, decide how long the business can tolerate disruption and what recovery target is appropriate. Base those choices on business impact, customer commitments, safety, applicable legal or regulatory requirements, and contracts. The cited NIST guidance does not prescribe a universal AI-outage target, and legal duties or supplier terms vary by organization, jurisdiction, and sector.

Use a workflow worksheet to capture dependencies and consequences

For each AI-enabled workflow, record the following. This worksheet is a practical synthesis of BIA and third-party contingency guidance, not a NIST-prescribed form.

  • Business function and owner: Name the function the workflow supports and the person accountable for it.
  • AI components and providers: Record the service, provider, model or API, embedded AI component, and any known upstream dependencies.
  • Operating requirements: Note the required inputs and outputs, integrations, credentials, data, and staff processes.
  • Disruption consequences: Describe what stops, slows, becomes less accurate, or could affect customers, finances, safety, privacy, or compliance if the service is unavailable or degraded.
  • Tolerance and recovery target: State how long disruption is tolerable and the recovery target chosen for this function.
  • Fallback and tradeoffs: Identify any tested manual process, alternate provider, cached or offline capability, or other redundancy; name who can activate it and document its data, quality, security, or privacy tradeoffs.
  • Incident handling and return to service: Record how the disruption will be detected, who will be notified, where decisions will be logged, and how the workflow will return to normal.

Choose and document a usable fallback

For every high-impact workflow, make the fallback operational rather than aspirational. Specify the signal that triggers a switch, who is authorized to decide, what staff do instead, how incoming work is queued or handled, and how normal service is restored—or how the AI feature is safely taken out of use. If no practical alternative exists, document how the business will contain the impact and communicate delays.

The Playbook’s Manage guidance says: “Verify contingency processes for handling negative impacts associated with mission-critical third-party AI systems.” It also suggests considering redundancy for vital third-party AI functions. Redundancy can reduce reliance on a single provider, but it does not remove the need to plan for the data, security, privacy, quality, and operational differences involved.

Special offer. See more information about Outbyte and uninstall instructions. Please review EULA and Privacy policy.
Independent reader supportYour contribution helps us test, update, and keep practical guides available for everyone.Support on Ko-Fi

Compare fallback options by their real tradeoffs

When there is more than one plausible fallback, compare the options against the needs of the workflow. NIST’s cited pages do not provide a fixed scorecard; these criteria apply their focus on business impact, third-party risk, and contingency planning.

  • Recovery time and impact: How quickly can the alternative take over, and what work or service quality is lost while the primary service is unavailable?
  • Portability and substitutability: Can the data and workflow move, and can another provider or model perform the required task?
  • Security and privacy: Does the alternative change where data goes, who can access it, or how it is protected?
  • Output quality: What review or additional human work is needed, and what quality tradeoffs are acceptable?
  • Operational effort: Can staff use the alternative under pressure, and what training or process changes does it require?
  • Ongoing cost and readiness: What does it take to maintain and exercise the fallback so it remains usable?

Exercise the plan and keep it current

A fallback that has never been tried may fail when needed. Exercise the steps with the people expected to use them: simulate a provider outage or degraded output, activate the alternative, confirm how work is tracked, and practice returning to normal service. Use what the exercise exposes to update ownership, contact paths, access, instructions, and recovery expectations.

Review the plan when staff, workflows, systems, or provider arrangements change. The cited guidance supports contingency planning and testing for mission-critical third-party AI systems, but it does not set a universal exercise frequency. Choose a cadence that fits the function’s impact and the rate at which its dependencies change.

When to get organization-specific advice

NIST’s framework and BIA guidance help structure the assessment, but they do not establish industry-specific legal duties, contract terms, or mandatory recovery times. Check requirements that apply to your jurisdiction and sector, review supplier agreements, and involve the appropriate legal, security, privacy, safety, and continuity owners for the affected function.

Special offer. See more information about Outbyte and uninstall instructions. Please review EULA and Privacy policy.

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.