To plan ABA AI continuity, fallback, and vendor exit, map every clinical, operational, data, identity, integration, vendor, and human dependency. Define which work can continue, pause, or move to an approved alternative; preserve source records and qualified decision authority; test exports, configuration recovery, access revocation, and downstream reconciliation; and assign evidence-based activation, return, transition, and closure gates before an outage or contract end occurs.
Map the critical workflow and safe stop
Tariq records which work depends on the model, prompt, retrieval corpus, vendor APIs, identity provider, network, source system, logs, reviewers, downstream applications, and support staff. For each function, he defines maximum tolerable disruption, recovery time objective, recovery point objective, minimum safe operating mode, and stop condition. These are practice planning targets, not guarantees. Clinical care proceeds only when the qualified role has the current information, setting, staff, supervision, communication, and safety supports needed.
Separate outage types
Plan for vendor downtime, regional outage, model retirement, degraded quality, quota exhaustion, compromised credentials, security incident, contract dispute, insolvency, acquisition, feature removal, data-export failure, and deliberate termination. A technically available service may still be unusable because its model changed, logs failed, terms changed, or required human review is unavailable. Each trigger has a named incident, clinical, privacy, security, operations, payer, finance, contract, and communication owner as applicable.
Choose approved fallback by function
A fallback may be manual work, a smaller approved scope, queued processing, another validated provider, or a safe hold. It must preserve current source evidence, privacy, accessibility, clinical and payer authority, signatures, documentation history, deadlines, and audit trail. Do not send PHI to an unapproved provider during an outage. Test whether staff can reach offline instructions and contacts when the normal platform is unavailable.
Preserve regulated data duties during disruption
HHS cloud guidance says a cloud provider maintaining ePHI can be a business associate even if it lacks the encryption key, and each regulated party retains duties for its role. An outage or exit does not suspend access, incident, record, or contract responsibilities. Map which party can retrieve data, protect residual copies, investigate events, support access requests, and meet applicable notice or retention duties throughout the transition.
Prepare portable evidence
Inventory source documents, prompts, retrieval corpus, embeddings when portable, configuration, model and version history, evaluation sets, acceptance results, user and role mappings, audit logs, outputs, human edits, approvals, incidents, monitoring, and downstream references. Distinguish what the practice owns, can export, must rebuild, or cannot lawfully retain. Test export format, completeness, integrity, access, and restoration before the exit window.
Put exit duties in the contract
HHS sample BAA provisions address return or destruction of PHI at termination when feasible and continuing protections when return or destruction is infeasible. Tailor actual agreements with counsel. Confirm assistance, export timing and format, deletion and certification, subcontractors, surviving protections, transition support, model and prompt ownership, audit evidence, incident cooperation, change notice, fees, and termination rights. A BAA is only one part of the service and data exit.
Revoke access and close integrations
Disable service and workload identities, API keys, OAuth grants, webhooks, scheduled jobs, network routes, support accounts, and data feeds in a controlled sequence. Close queues, prevent duplicate retries, reconcile every in-flight action, and preserve required records. Verify vendor, subprocessor, backup, and support copies against the approved retention and deletion decision. Keep residual access for evidence only when authorized, time-bound, logged, and assigned.
Exercise recovery and migration
NIST SP 800-34 Rev. 1 is final federal information-system contingency guidance that private practices may adapt; it is not itself a general mandate for ABA providers. Run tabletop and technical exercises for detection, activation, safe stop, source access, manual work, alternate route, data restoration, identity revocation, communication, backlog reconciliation, return, and closure. Test with an unavailable leader and at least one failure in the fallback.
Work through a continuity exercise
Tariq locks 16 fictional outage and exit scenarios. Twelve meet activation, safe-stop, fallback, source access, authority, communication, reconciliation, recovery acceptance, identity closure, and evidence-retention gates: 12 of 16, or 75%. One fallback sends data to an unapproved provider, one export omits reviewer edits, one scenario cannot revoke a vendor token, and one returns to service before backlog reconciliation. All four corrective actions remain open.
Define return and closure evidence
Technical availability is a milestone. Return to routine use requires validated versions, access, logs, source connections, qualified staffing, backlog status, incident decisions, and downstream reconciliation. Vendor exit closes only after exports are accepted, in-flight work is resolved, identities and integrations are disabled, data decisions are evidenced, contracts and payments are reconciled, affected people receive required communication, and residual monitoring has an owner.
Connect continuity to AI governance
The voluntary AI RMF Manage Playbook includes suggested actions for incident response, recovery, monitoring, change management, and decommissioning. It is useful structure, not a private-practice mandate or proof of compliance. Link the continuity plan to the approved AI use-case inventory, risk tier, acceptance evidence, incident process, vendor file, and change record so recovery does not restore a configuration that governance has already suspended or retired.
Use a continuity and exit checklist
- Which dependency can stop safe or timely work?
- What continues, pauses, or moves to an approved fallback?
- Can the practice restore source, configuration, edits, and audit evidence?
- Which identities, queues, and integrations must close?
- What proves vendor return or deletion?
- Who accepts recovery, migration, and final closure?
Rehearse vendor exit before the deadline
Run an exercise that exports configurations, prompts, source inventories, logs, user and permission records, open queues, correction history, monitoring results, and required retained data. Verify file formats, completeness, encryption, access, and the ability to use the evidence without the vendor's interface. Test deletion and return requests against the agreement and record what the vendor can and cannot certify.
Move a controlled fictional workflow to the approved fallback or replacement. Reconcile outputs, record links, identities, duplicate prevention, user access, and monitoring before widening the migration. Preserve the old and new system versions long enough to explain differences. A technically successful transfer can still fail if staff lose the source evidence or review controls needed for responsible work.
Protect people and service continuity during transition
Tell users which functions are available, held, manual, or changed, and where to raise an urgent concern. Keep AAC, language assistance, accessible communication, safety routes, and qualified clinical decision-making available. A client or family should not have to understand the vendor transition to obtain the underlying service or correct an affected record.
Track deadlines and open work by consequence. Assign owners for clinical records, authorizations, claims, schedules, messages, payments, staff tasks, privacy requests, incidents, and appeals. The exit leader confirms that every queue has a final disposition and that no temporary workaround silently became a new ungoverned AI use.
Close the provider relationship with evidence
Revoke credentials, tokens, integrations, service accounts, support access, webhooks, scheduled jobs, and subprocessor routes. Reconcile final invoices and usage, document returned or destroyed data and any infeasible destruction, preserve required records under the applicable authority, and update the AI inventory, risk analysis, incident contacts, and vendor register. Independent review should confirm that the old route can no longer receive new work.
Related resources
- Protect PHI in ABA AI Prompts, Logs, and Feedback
- Control ABA AI Cost, Token, Quota, and Capacity Risk
- Set AI Confidence, Abstention, and Escalation Thresholds for ABA Work
- Route ABA AI Work Across Models and Providers Safely
Sources
- Council of Autism Service Providers, Organizational Guidelines public overview
- U.S. Department of Health and Human Services, HIPAA Security Rule Summary
- U.S. Department of Health and Human Services, Sample Business Associate Agreement Provisions
- U.S. Department of Health and Human Services, Guidance on HIPAA and Cloud Computing
- National Institute of Standards and Technology, SP 800-34 Rev. 1 Contingency Planning Guide
- National Institute of Standards and Technology, AI Risk Management Framework
- National Institute of Standards and Technology, AI RMF Playbook Manage function