The Tool Desk
Outbyte PC Repair FREEClear out junk files and repair common Windows errorsFree Scan →Outbyte Driver Updater FREEScan for outdated or missing drivers - takes under a minuteDriver Scan →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
You cannot prove that an AI service will stay in a provider’s product portfolio. An uptime promise measures how often the current service is reachable under a stated definition; it does not stop the provider from retiring the product, terminating your account, entering bankruptcy, or ending support. A sound assessment therefore asks two separate questions: how likely is the service to be available in the near term, and how quickly can you continue essential work if access ends?
The defensible way to answer is to examine the contract and lifecycle notices, map every dependency, test what you can export, and operate a rehearsed fallback. The result is a continuity judgment, not a prediction of a provider’s financial future.
Start by separating uptime from survival
Availability has at least two meanings in an AI service:
- Operational availability: whether the endpoint, application, or API responds during the measurement interval covered by a service-level agreement (SLA).
- Lifecycle availability: whether the provider continues offering, supporting, and permitting access to that product over the period your workflow needs it.
An SLA normally addresses only the first meaning. NIST’s cloud guidance says published availability figures depend on the measurement interval and on what the provider defines as “up.” NIST SP 800-146 (2012) described provider availability promises historically ranging from 99.5% to 100.0%, while warning that calculation methods and definitions vary. Those figures are historical context, not a current survey of AI vendors.
#1 Best Overall
For scale, NIST SP 800-144 (2011) gives the arithmetic example of 4.38 hours of expected downtime in a year at 99.95% availability. That number illustrates how an SLA percentage translates into permitted downtime; it is not an estimate of the probability that an AI service will be shut down permanently.
A provider can meet an SLA until the day it announces a sunset. Conversely, a provider can remain in business while an API version, model, or feature is discontinued. Treat uptime evidence as one input to short-term operations planning, never as a survival guarantee.
Define the shutdown scenario you are actually assessing
“The provider shuts it down” can describe several events with different preparation requirements. Write down which ones matter to your organization before judging a service.
| Scenario | What changes | Evidence and response to examine |
|---|---|---|
| Temporary outage or facility loss | The service may return, but work is blocked during the interruption. | Incident communication, recovery commitments, alternate region or service, and a manual procedure. |
| Account suspension or termination | Your organization loses access even though other customers remain online. | Contractual suspension triggers, notice, appeal rights, export window, and an independent copy of required records. |
| Model or API deprecation | The product remains available but a version, endpoint, or behavior changes. | Deprecation stages, replacement compatibility, migration tools, testing time, and configuration changes. |
| Product retirement | The named AI service is removed from the provider’s portfolio. | Announcement lead time, export process, transition assistance, and a tested alternative. |
| Bankruptcy, acquisition, or prolonged permanent outage | Support, infrastructure, and access may end with little practical recovery help. | Your own backups, independent credentials and documentation, alternate equipment or provider, and a continuity runbook. |
NIST’s AI Risk Management Framework Playbook describes safely removing an AI system, temporarily or permanently, as a process that should minimize operational disruption and downstream harm. The Australian National AI Centre similarly advises maintaining alternative pathways for critical functions when an AI system malfunctions or is taken offline.
Read the agreement instead of inferring protection from an SLA
Collect the service agreement, order form, acceptable-use terms, privacy and retention language, API terms, export documentation, and product-lifecycle or deprecation policy that apply to your edition and country. Record the version and date you reviewed. NIST SP 800-146 emphasizes that provider agreements contain both promises and customer obligations, including limitations that can matter during termination.
Rank #2
Questions the contract must answer
- Who may terminate or suspend access: the provider, your organization, or both?
- What events permit immediate suspension, and which require advance notice?
- How much notice is promised for a product retirement, model removal, or material feature change?
- How long do you have to retrieve data after termination, and does the clock start at notice or at account closure?
- Are exports available to a suspended account, or must you request them through support?
- Which records, files, prompts, outputs, logs, embeddings, fine-tuning artifacts, and settings are included?
- What formats, rate limits, fees, identity checks, or technical prerequisites apply to export?
- When will the provider delete remaining copies, backups, and support records?
- Does the provider promise transition assistance or only a notice?
- Which obligations survive termination, such as confidentiality, payment, or audit duties?
Keep the answers with the service inventory. A marketing page or a generic uptime badge cannot override the applicable contract, and a lifecycle policy published by one provider does not bind another.
Map the dependency before choosing a fallback
List each business or personal task that relies on the service, then trace what enters and leaves it. Include people, software, data stores, credentials, schedules, and downstream decisions. NIST’s AI RMF Playbook recommends considering upstream and downstream consequences of deactivation; Australian guidance calls for assessing impacts on users and integrated systems.
Quick wins for a faster PC:
Fix the driver behind crashes, sound loss and screen glitchesFind Drivers →Clear out junk files and repair common Windows errorsFree Scan →Scan for outdated or missing drivers - takes under a minuteDriver Scan →Build a dependency record for every workflow
- Purpose: the decision or job the AI assists, such as classification, drafting, extraction, coding, or customer response.
- Criticality: what stops if the service is unavailable for an hour, a day, a week, or permanently.
- Inputs: documents, images, audio, prompts, personal data, proprietary data, and retrieval indexes.
- Outputs: generated text, structured fields, files, scores, citations, logs, and human approvals.
- Integrations: applications, webhooks, identity systems, queues, databases, and automations that expect a particular API or schema.
- Model-specific behavior: prompts, system instructions, token limits, tool calls, safety settings, fine-tuning, embeddings, and evaluation thresholds.
- People and process: staff who operate, review, correct, and escalate the results.
- Consequence: safety, legal, financial, service-level, or reputational impact if the output is delayed or wrong.
Mark whether a slower human procedure can perform the essential function. If it can, document the procedure and the minimum information a person needs. If it cannot, classify the workflow as requiring a technical alternative and give it a higher migration priority.
Test portability rather than trusting an export promise
Data export and service portability are different. An export may let you retain records while leaving you unable to reproduce the provider’s model behavior, retrieval index, orchestration, or evaluation results. The only reliable way to find out is to perform a representative export while the account is healthy.
Use a controlled export test
- Select representative cases. Include ordinary, large, edge-case, multilingual, and failure-prone inputs. Do not use real sensitive data unless your policy permits it; create safe test copies when possible.
- Export every relevant artifact. Check conversations, prompts, outputs, uploaded files, metadata, timestamps, feedback, logs, model and parameter settings, workflow definitions, access lists, and billing records that you need for audit or reconstruction.
- Inspect the format. Confirm that files are readable and, where automation requires it, machine-processable. Check character encoding, time zones, identifiers, relationships between records, pagination, and whether attachments remain linked.
- Measure the effort. Record the account role required, support tickets, rate limits, fees, elapsed time, and any data that cannot be exported.
- Restore outside the service. Open the files in software you control and verify that another system can ingest the fields you expect. A download that exists but cannot be parsed is not an operational backup.
- Store an independent copy. When your security and retention rules permit, keep an encrypted copy in storage controlled by your organization. Local storage preserves artifacts; it does not keep a hosted model or API running.
Australian decommissioning guidance specifically recommends determining extraction methods and the records to retain. NIST continuity guidance likewise emphasizes alternate services, equipment, or locations for essential functions.
Rank #3
Evaluate what “portable” means for an AI workflow
Use a portability inventory instead of a single yes-or-no field. Mark each item as exportable and useful, exportable but provider-specific, recoverable only manually, or not available. The categories below expose gaps that a basic conversation download can hide.
Free tools Windows power users keep installed
One-click scans. No signup required.
| Artifact | Why it matters during migration | Verification question |
|---|---|---|
| Source data and uploaded files | Another system cannot process what you cannot retrieve. | Can you obtain originals with filenames, versions, permissions, and timestamps intact? |
| Prompts and system instructions | They encode task logic and quality controls. | Can you export them in a reusable text or structured format? |
| Outputs and human decisions | They may be needed for records, audits, or future evaluation. | Are outputs linked to inputs, reviewers, model versions, and dates? |
| Embeddings, indexes, and retrieval configuration | Rebuilding search can be the largest migration task. | Can indexes and chunking or metadata rules be reproduced elsewhere? |
| Fine-tuning or adapter artifacts | They may capture behavior that a base model cannot reproduce. | Is the trained artifact downloadable and usable under its license? |
| Workflow and integration configuration | Triggers, schemas, and permissions connect AI to operations. | Can you recreate calls, webhooks, secrets, and error handling without hand-copying? |
| Evaluation sets and acceptance criteria | They let you test whether a replacement is fit for purpose. | Do you retain representative inputs, expected properties, and review instructions? |
None of these checks establishes what an unnamed vendor exports. Treat the result as service-specific evidence and repeat it after major product changes.
Choose a fallback that addresses the real dependency
A second AI provider is only one option. Compare alternatives against the task, data, integration, and people identified in your dependency record.
Possible continuity paths
- Another hosted service: potentially the fastest switch, but it may impose a different API, model behavior, retention policy, region, or contract.
- A locally operated model or workflow: can reduce dependence on one hosted endpoint, but requires suitable hardware, updates, security controls, and staff capability.
- Conventional software: rules, search, templates, or deterministic processing may cover a narrow essential function without generative-model behavior.
- Human or manual operation: often slower and more expensive, but valuable as a temporary mode for high-impact tasks.
- Reduced-function mode: queue nonessential work, disable optional automation, and preserve only the critical path until service is restored or migrated.
For each candidate, compare task capability, data controls, integration effort, switching time, recurring and one-time cost, staff training, and the evidence from a realistic test. Document where behavior differs; “compatible API” does not mean equivalent answers, safety behavior, latency, or output structure.
Run a migration drill before you need it
NIST recommends redundant or backup systems for continuity. A fallback that exists only in a procurement document is not redundancy. Schedule a limited exercise using representative, non-sensitive cases.
- Disable the primary service in a controlled test environment or route a small workload away from it.
- Restore the exported data, prompts, configuration, and evaluation set into the alternative pathway.
- Run the same cases and have qualified reviewers compare required properties, not just wording.
- Exercise authentication, rate limits, error handling, logging, approvals, and downstream integrations.
- Record elapsed time, staff actions, missing artifacts, unexpected costs, and decisions that require human review.
- Update the runbook, owners, contacts, and export schedule based on what failed.
Repeat the drill after major model, API, integration, or policy changes. The objective is to learn the actual switching time and capability boundary, not to claim that two systems are identical.
Independent reader supportYour contribution helps us test, update, and keep practical guides available for everyone.Use lifecycle policies as evidence, not promises
Some providers publish a sequence for deprecations. Such documentation is useful because it reveals whether the provider distinguishes maintenance, sunset, and full shutdown, and whether it describes alternatives. It still cannot predict a different provider’s conduct or guarantee that an exception will not be made.
Examples of published schedules
AWS describes three lifecycle states—maintenance, sunset, and full shutdown—and says sunset timelines are typically 12 months. “Typically” is important: this is AWS’s general description, not an industry norm or a guarantee for every service.
Cloud.gov publishes an example schedule in which an announcement occurs on day zero, new instances stop on day 30 or later, reminders are sent every 14 days from day 30, and shutdown occurs on day 150 or later. The policy also notes risk-based accelerated exceptions and places responsibility on customers to monitor notices and plan migration. Use this as an example of an explicit process, not as a forecast for a commercial AI product.
What’s actually slowing this PC down?
Pick the symptom - the matching free tool is one click away.
When reviewing a provider, look for equivalent stages, named replacement services, migration documentation, status history, and a clear notification channel. Absence of a published process is a risk signal, but its presence is not a survival guarantee.
Best Value
Assign monitoring, triggers, and ownership
Continuity fails when nobody is responsible for noticing a change or authorizing a switch. Keep an inventory of AI services, owners, contracts, data classifications, integrations, alternatives, and the latest export and drill dates. NIST’s AI RMF Playbook recommends inventories and documented contingency processes for high-risk third-party AI failures.
Define practical trigger levels
- Watch: repeated incidents, material API changes, ownership changes, pricing or policy changes, or a new deprecation notice.
- Prepare: a published sunset, shrinking support scope, failed export test, or a fallback that no longer meets the task.
- Switch: a termination notice, loss of required functionality, a security or compliance event, or an outage beyond the documented tolerance.
Name the person who monitors provider notices, the technical owner who tests exports, the business owner who accepts degraded service, and the approver who authorizes migration. Store contact details and credentials in a controlled location that remains accessible during an incident.
Account for security, retention, and deletion
Keeping a local copy can improve recovery only when it is lawful, secure, and useful. Classify exported data, encrypt it in transit and at rest, restrict access, set a retention period, and record deletion obligations. Do not assume that deleting your account immediately erases provider backups or support records; verify the applicable retention language and timeline.
Conversely, do not export more than you need. A continuity copy should contain the records and artifacts required to resume or verify the function, with a documented owner and access trail. If the workflow handles regulated or confidential information, involve the relevant privacy, security, legal, and records-management roles before selecting a fallback.
Common assessment mistakes and their fixes
- Mistake: treating 99.9% or 99.95% as a longevity rating.
Fix: record the SLA’s measurement definition separately from lifecycle and termination terms. - Mistake: assuming conversation export equals workflow portability.
Fix: test prompts, files, indexes, configurations, integrations, evaluations, and metadata as separate artifacts. - Mistake: choosing a second provider without a representative test.
Fix: run the migration drill and document behavior, timing, cost, and manual review needs. - Mistake: relying on a notice email that only one administrator receives.
Fix: assign monitored contacts and include provider status and lifecycle pages in routine review. - Mistake: storing backups without proving they can be restored.
Fix: open and ingest the export outside the service, then rehearse the recovery path. - Mistake: ignoring a manual mode because it is slower.
Fix: define which critical cases can be handled manually and how long that mode is acceptable. - Mistake: assuming a provider’s published schedule applies universally.
Fix: treat each policy as evidence about that provider only and read your own contract.
What cannot be predicted from public information
There is no established current statistic that quantifies the probability of an AI provider shutting down, nor a reliable industry-wide frequency for AI-service closures in the material available for this topic. Financial condition, acquisition plans, export capability, notice periods, and account actions remain provider- and contract-specific. Avoid assigning a percentage to shutdown risk without evidence that measures the same service, period, and event.
You can still make a defensible decision: identify the consequence of loss, measure the depth of your dependency, verify what you can take with you, and demonstrate that a fallback works. A service with excellent short-term uptime but no usable export and no tested alternative may be less resilient for a critical workflow than a less convenient service with clear exit terms and a functioning backup path.
A concise assessment worksheet
Complete these fields for every AI service that matters to your work:
Do these 3 things before closing this tab:
1Clear out junk files and repair common Windows errors2Fix the driver behind crashes, sound loss and screen glitches3Repair Windows errors before they cause bigger problems- Service, edition, region, contract version, and review date.
- Critical workflows, affected users, maximum tolerable interruption, and manual procedure.
- Termination, suspension, deprecation, notice, export, retention, and deletion terms.
- Inputs, outputs, prompts, files, indexes, configurations, integrations, and evaluation artifacts.
- Export test date, format, restoration result, missing items, and storage location.
- Fallback pathway, owner, switching steps, observed switching time, and known capability gaps.
- Monitoring contact, escalation trigger, migration approver, and next drill date.
Review the worksheet whenever the provider changes its model, API, contract, retention policy, or product status. The record should show not only what the provider says, but what your organization has actually exported and restored.
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.
