LLMs, zero data retention, and HIPAA

Zero data retention (ZDR) is a configuration in which an AI provider does not persist your prompts and outputs after serving the request. It can reduce retention risk, and vendors frequently require it before they will handle regulated data. ZDR alone does not establish HIPAA compliance or replace a business associate agreement. In at least one major provider’s current terms, it is not uniformly compatible with the services covered by the provider’s BAA. This page explains the framework. Whether a specific AI deployment may handle your PHI depends on its configuration, your contracts, and applicable state law. Confirm the conclusion with privacy counsel. Vendor terms change frequently, so verify them against current documentation and your executed agreement.

​

What ZDR actually is

By default, most AI providers retain API inputs and outputs for a period, commonly around 30 days, for abuse monitoring, trust and safety review, and debugging. ZDR turns that logging off: the data exists transiently while the request is processed and is not written to durable storage afterward. The setting describes a vendor’s storage behavior for a particular configuration and set of covered services. It says nothing by itself about the rest of the data flow.

​

Controls that ZDR does not replace

Review data residency, subprocessors, and retention of derived artifacts such as embeddings, caches, and safety classifications separately.

​

Why vendors treat it as a precondition

If an AI provider creates, receives, maintains, or transmits PHI on a covered entity’s behalf, it may be a business associate under 45 C.F.R. § 160.103 and require a BAA. The exact relationship and contracting chain depend on who engages the provider and for what function.¹ General-purpose abuse-monitoring logs may place PHI in additional systems and expose it to a broader review process. ZDR can reduce the amount of PHI at rest, the number of systems in scope, and the consequences of a security incident. Some vendors make ZDR a condition of BAA coverage or permission to send regulated data for particular services. Treat that as a vendor- and service-specific contract term.

​

ZDR and BAA coverage do not always align

Review coverage at the service and feature level before choosing an architecture. BAA coverage is scoped per service, not per vendor. Providers publish which of their products and endpoints the BAA covers, and the exclusions are frequently substantial. Anthropic, for example, publicly documents that its BAA covers the Messages API and specified Claude Enterprise features, while explicitly excluding its Batch API, Files API, Skills API, Code Execution, Computer Use, and Web Fetch.² And ZDR can point in the opposite direction. In the same documentation, Anthropic states that certain covered models require 30-day data retention and are not available with ZDR enabled, while a different covered service is only covered under the BAA when ZDR is enabled.²

​

Why ZDR is not HIPAA compliance

Even with ZDR enabled, a signed BAA, and a covered service, the deploying organization retains its own HIPAA obligations.

​

1. Transmission is a disclosure

Sending PHI to a third party is a disclosure under the Privacy Rule regardless of what happens to it afterward. The disclosure must be permitted for treatment, payment, health care operations, or under an authorization, and it must satisfy the minimum necessary standard when that standard applies. ZDR does not make an impermissible disclosure permissible; it addresses retention after the disclosure.

​

2. Minimum necessary still applies to the prompt

ZDR governs retention after a request. The minimum-necessary standard, when applicable, governs what information is sent. Prompt design should therefore limit PHI to the fields needed for the permitted function.

​

3. The Security Rule applies to your systems

Access controls, audit logging, workforce training, and the required security risk analysis under 45 C.F.R. § 164.308(a)(1)(ii)(A) all cover your AI integration as an asset that handles ePHI. A vendor’s retention setting does not discharge any of them. OCR proposed a major update to the HIPAA Security Rule in January 2025, including removal of the required/addressable distinction and tighter risk-management and encryption expectations. Confirm the proposal’s current status before relying on either framework.³

​

4. Business associates are directly liable

Since the HITECH Act and the 2013 Omnibus Rule, business associates have independent HIPAA obligations and are subject to enforcement in their own right. In a DSO-PC group, that means the dental support organization (DSO), and the AI provider as the DSO’s subcontractor.

​

5. Patient rights still apply

If an AI-drafted note becomes part of the designated record set, it is subject to patient access and amendment rights. The record lives in your PMS; the vendor’s retention setting is irrelevant to it.

​

6. Breach notification still attaches

An impermissible disclosure of unsecured PHI is presumed to be a breach unless you document a low probability of compromise. Disclosing PHI to a vendor with no BAA is potentially reportable whether or not the vendor stored it.

​

7. Stricter regimes sit on top

State health privacy laws can be stricter than HIPAA, and some states now regulate AI in health care directly. Washington, for example, provides that AI may not be the sole means used to deny, delay, or modify health care services and requires human review for medical-necessity denials.⁴ HHS has separately addressed nondiscrimination in patient-care decision support tools.⁵

​

Where PHI may remain in your systems

ZDR at the model provider does not cover copies stored by the application, gateway, monitoring tools, or support systems. Inventory the full path rather than reviewing only the model endpoint. Prompt caching deserves specific attention. It is a retention mechanism whose entire purpose is persisting request content, it is frequently enabled by default for cost reasons, and it can operate at the vendor, at a gateway, or in your own application. Confirm where cached content lives, for how long, and whether it is inside your BAA’s scope. Every one of these belongs in your BAA inventory and your security risk analysis. See Build a minimum viable HIPAA program.

​

The DSO-PC chain

The structure adds two links most guidance doesn’t contemplate. Practical consequences:

• One BAA per PC. Each professional entity is a separate covered entity. A ten-PC group needs ten DSO-PC BAAs, and those BAAs need to actually contemplate the AI use.
• The DSO needs a subcontractor BAA with the AI provider, and must ensure it flows the same restrictions down.
• Keep records segregated by PC. A shared AI tool spanning several PCs should prevent one practice’s context from appearing in another’s workspace, consistent with the applicable record-ownership and access rules.
• The DSO has direct regulatory duties in its role as a business associate; its liability does not arise solely from the contract.

The concrete case this wiki keeps flagging: 835 remittance files are PHI. Running them through a model for denial root-cause classification puts PHI in a prompt. Teams build that as a finance project and miss the BAA, the encryption, and the risk analysis entirely. See The 835.

​

The CPOD overlay, the part unique to this structure

Privacy is not the only exposure. A DSO deploying AI that influences clinical decisions may be exercising a function the corporate practice of dentistry (CPOD) doctrine reserves to the PC. Recall what the newest corporate-practice statutes actually enumerate. California’s SB 351 bars management entities from participating in billing, coding, equipment selection, and clinical staff oversight, and bars private equity groups and hedge funds from determining what diagnostic tests are appropriate or determining the need for referrals. Oregon’s SB 951 reaches management-entity control over scheduling, clinician compensation, coding, billing, and payer contract terms.⁶ Now map AI onto that list. Dentistry’s AI wave is arriving through exactly these doors: radiograph-analysis tools that flag caries, bone loss, and calculus; PMS-integrated coding assistants; scheduling optimizers. The test is the same one this wiki applies everywhere: who decides, and who merely implements? AI that surfaces options for a dentist who genuinely decides is support. AI that decides and informs the dentist is control, regardless of what the management services agreement (MSA) says, and regardless of whether a human nominally clicks approve on a queue of a thousand items. If you build clinical or coding AI in the DSO, document that the PC approved the tool, that dentists can reject its output, and that rejection actually happens at a rate consistent with genuine review. See What a DSO can and can’t do and Run a CPOD self-audit. There is also a records question: if AI output becomes part of the clinical record, the PC owns it, not the DSO that built the tool.

​

De-identification: the other route

If data is properly de-identified under 45 C.F.R. § 164.514 through Safe Harbor or Expert Determination, it is no longer PHI for HIPAA purposes. Safe Harbor requires removal of the 18 specified identifiers and no actual knowledge that the remaining information could identify a person.⁷ For some analytics uses, proper de-identification can remove the data from HIPAA’s definition of PHI. Free-text clinical narratives are difficult to de-identify reliably. Safe Harbor’s identifier list is straightforward for structured fields, but prose can contain identifying context such as an unusual presentation, a referring dentist’s name, an embedded date, or an employer description. Automated de-identification of notes has a meaningful error rate. Imaging raises separate questions because Safe Harbor includes full-face photographs and comparable images. Get expert advice before treating a radiograph or photo set as de-identified. If you rely on de-identification for anything sensitive, use Expert Determination and document it. Do not assume a regex pass over notes produces de-identified data.

​

Unapproved consumer AI use

Day-to-day exposure may come from staff using consumer tools outside the approved workflow. For example, a front-desk coordinator might paste a patient’s chart into a consumer chatbot to draft an appeal narrative for a downgraded crown. Sending PHI to a vendor without the required BAA is an impermissible disclosure. Technical controls alone will not prevent it. Use an acceptable-use policy, workforce training that names the behavior, and an approved tool that meets the team’s practical needs. Training should state the rule plainly: never paste patient information into an AI tool that isn’t on the approved list.

​

Deployment controls

​

The one-sentence version

ZDR is a useful control that reduces how much PHI sits at a vendor. HIPAA is a set of obligations on you that ZDR does not touch, and the two are configured independently, sometimes in opposite directions.

​

Sources

1. 45 C.F.R. § 160.103 (definitions of business associate and covered entity); business associate contract requirements at 45 C.F.R. § 164.504(e). eCFR.
2. Anthropic, Is Anthropic willing to sign a BAA?. Cited because it publicly documents the per-service coverage matrix and the ZDR interaction; other major providers publish their own. This is not an endorsement. Read the vendor’s current terms.
3. HHS OCR proposed HIPAA Security Rule update, January 2025. Confirm current status. See HIPAA Journal, HIPAA Updates and HIPAA Changes.
4. State AI-in-healthcare laws, including Washington’s provision that AI not be the sole means of denying, delaying, or modifying care. See Live Compliance, AI in Healthcare: The Regulatory Landscape. Verify current text and effective date against the state’s own statute.
5. HHS OCR, “Ensuring Nondiscrimination Through the Use of Artificial Intelligence and Other Emerging Technologies,” addressing patient care decision support tools. See Reed Smith, HHS Recent Guidance on AI Use in Health Care.
6. Cal. S.B. 351 (2025); Or. S.B. 951 (2025). Both are written for health care management entities generally; their enumerated lists are the clearest statutory statement of what a management company must not control. See the legislation tracker for citations, effective dates, and the dental-specific analogues.
7. 45 C.F.R. § 164.514(a)–(b). HHS, Guidance Regarding Methods for De-identification of PHI.