OpenAI ZDR Addendum: The Procurement Term That Decides Whether You Can Use ChatGPT for PHI

The default API terms are not HIPAA-eligible OpenAI's enterprise contract stack reads in two layers, and most procurement teams only read the first. The first is the Business Associate Agreement, signed before any PHI goes near the API. The second is the Zero Data Retention addendum, the document that actually changes how OpenAI's infrastructure handles prompts and completions. The BAA, on its own, does not get you to a HIPAA-defensible posture. Default OpenAI API terms include a 30-day retention window for abuse monitoring. Inputs and outputs are retained on OpenAI infrastructure for up to 30 days for safety, abuse, and policy review. That window exists for legitimate reasons; it is also a 30-day PHI retention liability sitting in a vendor environment your team has not assessed or scoped into your risk register. The enterprise tier has stronger defaults than ChatGPT consumer, but "stronger than consumer" is not "HIPAA-eligible." We have audited four mid-market healthcare deployments in the last twelve months where the procurement file contained a signed BAA and nothing else. In each case, leadership operated on the assumption that "we have a BAA with OpenAI" closed the question. In each case, the actual configuration, default API terms, no ZDR, prompts containing patient identifiers, would not have survived a regulator's first request for documentation. The BAA is necessary. It is not sufficient. What the ZDR addendum actually says Under ZDR, prompts and completions are not retained on OpenAI infrastructure after the API response is delivered. The 30-day abuse-monitoring window does not apply. The traffic is not stored, not logged at the content layer on OpenAI's side, not available for OpenAI human review, and not used for model training. Metadata (timestamps, token counts, model identifiers, billing data) is still retained, operational telemetry, not PHI, but the substantive content is not. What ZDR does not do is equally important. It does not waive the customer's Security Rule obligations. It does not create an audit log on the customer's side; the customer still has to build that. It does not extend to fine-tuning data, which is a separate addendum and a separate retention surface. It does not cover Assistants API stateful features (threads, file uploads, persistent memory) the same way it covers stateless completions, those features explicitly create retained state, and a ZDR posture has to be reconciled against which API surfaces the workload uses. ZDR also imposes obligations on the customer. The contract typically requires that the customer not use the API in ways that would defeat abuse monitoring, and that the customer keep its own audit trail sufficient to support a misuse investigation. The procurement-side cost is not zero; it transfers a share of the monitoring burden onto the customer's environment. For HIPAA workloads, the trade is correct, but the customer side has to actually be implemented. The addendum is granted on request to enterprise customers with documented eligibility. It is not the default. A team that has not asked for it does not have it. The procurement-call sequence Before signing the OpenAI enterprise contract for any PHI-touching workload, run this sequence with the OpenAI enterprise team. The order matters; each question disambiguates the next. One: "Is ZDR active on the account, or only on specific API keys or projects?" ZDR can be scoped at the organization or project level. If the answer is "project-level only," confirm which projects and whether your engineering team has visibility into project membership at the time a prompt is sent. The answer that means "sign" is unambiguous org-level coverage. Anything else is a configuration question that has to be closed before launch. Two: "Which API surfaces are covered?" Stateless completions, chat completions, and the responses API are typically in scope. Assistants features that retain state (threads, vector stores, file search), batch, and fine-tuning are addressed separately. Get the list in writing. Three: "What is the model coverage?" ZDR usually covers the production model line. New, preview, and beta models may be excluded. If your roadmap depends on a model not yet covered, the date coverage extends is the date PHI traffic can start. Four: "What is the customer-side audit obligation under the addendum?" Most teams skip this. The answer determines the audit log you have to build (next section). Five: "What is the breach-notification mechanism, and how is it scoped to ZDR-covered traffic?" The interaction between the BAA's notification clause and the ZDR posture, what gets notified, on what timeline, with what specificity, should be explicit before signing. The answer that means "renegotiate" is any version of "we will get back to you" on questions one, two, or three. The answer that means "sign" is written, specific, and reconciles to the architecture you have already drafted. The audit-log gap ZDR moves the prompt-content audit log entirely onto the customer side. OpenAI is not retaining your prompts and completions; the customer is the only place a HIPAA-grade audit trail can live. The Security Rule requires audit controls sufficient to reconstruct who accessed PHI, when, and what was disclosed. For an LLM workflow that means: prompt content, completion content, user identity, timestamp, model and version, application context, retained six years. This is a build, not a configuration. The architectures we recommend put a logging proxy between the application and the OpenAI API: every request and response captured, hashed for integrity, written to an append-only store inside the customer's BAA-covered cloud environment, indexed for retrieval against user, patient, and time. Encryption at rest. Access scoped to the audit-review role, not the application role. We have not yet audited a healthcare OpenAI deployment that built this log correctly on the first attempt. The most common failure is logging request metadata but not the prompt and completion bodies, on the theory that storing the bodies "feels like a PHI risk." It is not, it is the audit obligation. The risk is in not having it when the regulator asks. Where the Diagnostic Fits, and three actions this week If your team is running OpenAI for a workload that touches PHI, the Adopt-AI-Safely Diagnostic answers whether the BAA and the ZDR addendum together cover the architecture you have actually built. Two to three weeks, fixed-scope, fixed-price written report. We pull the executed contracts, walk the API surfaces in use, validate ZDR scope against the workload, evaluate the audit log against HIPAA retention requirements, and produce a sequenced fix plan. The report closes the gap between "BAA is signed" and "PHI workload is defensible," and stands on its own. Three actions any CIO, CTO, or compliance lead can take inside the next five business days, regardless of whether they engage us: 1. Pull the executed OpenAI contract file. Confirm whether the ZDR addendum is signed and at what scope (org vs. project). If it is not in the file, it is not in force; the procurement call sequence above is the next step. 2. Inventory the API surfaces in production. Stateless completions, Assistants threads, file uploads, fine-tuning. Reconcile each against the ZDR coverage. Anything outside ZDR scope is either a remediation or a deliberate exception with a documented rationale. 3. Audit your prompt-and-completion log. Confirm bodies are captured, hashed, retention is set to six years, and the access role is scoped. If the log is metadata-only, that is the gap to close before the next workload ships. The OpenAI ZDR Procurement Checklist (one-page PDF) pairs with this briefing, the five questions, the answers that mean sign, the answers that mean renegotiate, and the audit-log fields HIPAA expects. Pair it with the HIPAA AI Architecture Field Guide and the Vendor BAA Chain Field Guide. The Diagnostic is at /diagnostic; the Adopt-AI-Safely outcome at /outcomes/adopt-ai-safely; healthcare-specific work at /industries/healthcare; the regulated-SaaS overlay at /industries/regulated-saas; counsel-ready engagements at /counsel.