Healthcare AI Backup and Recovery Under the HIPAA Contingency Rule

HIPAA disaster-recovery coverage is mature, tested, and almost entirely written for databases and EHR systems. AI deployments in healthcare inherit the same contingency obligation — the rule does not distinguish artifact types — but the artifacts are different: model weights, training and evaluation datasets, prompt and output stores bearing PHI, and an inference stack whose configuration makes the system reproducible. A DR plan that restores the database and loses the model is compliant paperwork around a non-functioning clinical system. This page maps the rule onto the AI artifact classes.

Quick Answer: What Does HIPAA Require for AI System Backup and Recovery?

The contingency rule (45 CFR 164.308(a)(7)) requires five elements: a data backup plan, a disaster recovery plan, an emergency mode operation plan, testing procedures, and criticality analysis — and every element extends to AI artifacts: weight versions, datasets, prompt/output stores with PHI, and inference configurations. Best practice carries over directly (3-2-1 immutable backups, RTO/RPO by criticality, tested restores — a tested restore, not a saved file). The conservative posture: treat weights trained on patient data as PHI-bearing — they can memorize training data — and back them up with dataset-class controls. Infrastructure recovery (the provider share) and artifact recovery (the entity's share) must be split explicitly in the BAA.

Scope: The Contingency Rule Meets the AI Stack

The contingency rule requires five elements — a data backup plan, a disaster recovery plan, an emergency mode operation plan, testing procedures, and applications-and-data criticality analysis — and the AI stack extends every one of them: the backup plan must name artifact classes beyond databases, the criticality analysis must rank AI systems by clinical dependence, and emergency mode must state what clinicians do when the AI is down. Scoping AI into the rule is not optional overhead; an AI system that touches PHI is inside the contingency obligation whether or not anyone planned for it.

The criticality row is where AI systems most often break the plan, because clinical dependence is newer than the plan's assumptions: a documentation assistant ranked low until the clinic reorganized around it, an inference tier ranked high because triage reads it. The analysis is a living document, and the AI rows change as clinical workflows absorb the systems.

Shared Responsibility: Who Backs Up What in Hosted AI

In hosted AI the duties split by layer: the provider backs up and can recover the infrastructure layer — compute configurations, fabric state, and storage volumes under the contract's recovery objectives — while the covered entity owns the AI artifacts regardless of hosting: weight versions, training and evaluation datasets, prompt and output stores bearing PHI, and the deployment configurations that make the system reproducible. The BAA should state the split explicitly; the recurring failure is assuming the provider's infrastructure backup covers artifact recovery, discovered only when a restore produces running hardware and no model.

The infrastructure share is real recovery work — volume snapshots, configuration state, and storage tiers restored under contracted objectives — and it belongs in the BAA with stated recovery terms. OneSource Cloud covers that share in BAA-eligible dedicated environments with SOC 2 Type II audit readiness in U.S. data centers: the enclave recovers under contract, while the entity's artifact backups ride the storage tiers on their own schedule and controls. The two recoveries meet at the same incident, which is exactly why the split must be written down before it.

Evidence Artifacts: The Tested Restore for AI Systems

The operative guidance is blunt — a tested restore, not a saved file — and for AI systems the test must cover the artifact classes: restore a weight version and verify serving, restore a dataset and verify checksums and lineage, restore a prompt/output store and verify access controls survive, and time each against the stated RTO. Documented evidence includes the test schedule (the proposed 2025 Security Rule update strengthens testing and documentation expectations), timed results against RTO/RPO per class, and the downtime procedure clinicians rehearsed — the emergency-mode element most plans file and never test.

RTO and RPO differ by class, and the differences are the design: prompt and output stores typically need the tightest recovery (ongoing care depends on recent interactions), datasets and weights can carry longer objectives if version discipline keeps the recovery target current, and configurations are cheap to mirror frequently. Set the numbers per class in the criticality analysis, then let the restore test tell you whether they were fiction.

Residual Risk: What Backup Cannot Recover

Backup recovers data, not context: a restored model serving stale clinical guidance is a correctness incident, not a recovery; fine-tuning data that cannot be re-collected legally limits retraining options; and PHI embedded in weights by memorization resists both backup and deletion symmetrically — the conservative posture treats weight artifacts as PHI-bearing throughout. Residual controls are clinical (model-version governance, validation on restore) and legal (documented acceptance of the retraining boundary), and they belong in the plan next to the RTOs, not after an incident.

For teams building the infrastructure share of this plan on dedicated capacity, the starting reference is OneSource Cloud for Healthcare AI — BAA-eligible single-tenant environments, SOC 2 Type II audit readiness, U.S. data centers — covering the enclave rows of the contingency worksheet so the entity's artifact program starts from a contracted foundation.

FAQ

Are model weights themselves ePHI that must be backed up under the plan?

Treat them as PHI-bearing when trained on patient data: research on memorization shows weights can encode training data, so the conservative and defensible position includes weight versions in the backup plan with encryption and access controls matching the dataset class — which also resolves the symmetric problem of deleting weights when the underlying data rights expire.

What does OneSource Cloud cover in AI system recovery?

OneSource Cloud covers the infrastructure share: BAA-eligible dedicated environments with SOC 2 Type II audit readiness in U.S. data centers, where storage volumes and configurations recover under contracted objectives while weight versions, datasets, and prompt stores remain tenant artifacts backed up under the entity's own plan — the explicit split the BAA should state.