OpenAI API Self-Serve HIPAA BAA: Eligibility and PHI Setup

On October 5, 2026, OpenAI added an in-product route for eligible API organizations to accept its standard Business Associate Agreement (BAA). Healthcare builders and administrators can now start that process in organization settings, according to the API changelog.

For a workflow handling protected health information (PHI), the useful question is which parts of the proposed deployment are covered. Review the contract, project policy and data flow together before sending PHI. The steps below turn the published requirements into a deployment review; they do not establish that a particular application is HIPAA compliant.

1. Confirm eligibility and accept the agreement

An enterprise contract is unnecessary, but self-serve enrollment requires prior API use sufficient to qualify. OpenAI does not publish a numeric threshold. A Not eligible yet status means the organization cannot currently enroll through this route. An admin must have signing authority. OpenAI’s enrollment instructions describe this sequence:

1. Select the intended organization; open Settings → Organization → General, then choose Enable under HIPAA compliance support.

2. Download and review the addendum and service coverage.

3. Confirm authority, review acknowledgments, organization name and Organization ID; choose Agree and enable.

4. Look for Active, then retain the agreement available through View agreement.

Once enabled, support cannot be switched off in platform settings. The agreement download covers self-serve acceptances, not externally arranged BAAs. Organizations needing custom terms can use the email route in the same help article. Public documentation does not establish a universal approval time or a separate self-serve enrollment fee.

2. Verify the project that will actually carry PHI

The HIPAA Implementation and Configuration Guide requires the BAA to expressly include API services. It also requires Modified Retention to be active for the associated organization and project before PHI is transmitted. An agreement for a different product or configuration in another project is insufficient.

Modified Retention is an umbrella term covering Modified Abuse Monitoring (MAM), Zero Data Retention (ZDR), Safety Retention and Eyes Off—not another name for MAM. Unless separate terms apply, the guide limits its use to HIPAA inputs and outputs. Check the executed agreement before combining unrelated workloads. See the API requirements and definitions.

Implementation recommendation: record the production Organization ID and Project ID alongside the agreement and effective retention policy. Confirm that the deployed credentials belong to that project. Do not infer a specific retention mode from Active alone: the enrollment documentation does not identify the resulting mode for every existing project.

3. Check both endpoint coverage and retention behavior

OpenAI’s HIPAA-eligible functionality list includes Responses, Chat Completions, embeddings, files, vector stores, batches, image and audio endpoints, subject to the BAA and provisioning. It is a coverage inventory, not a promise that every feature combination works with every retention policy. Check the exact endpoint and its feature limitations.

The data-controls documentation distinguishes these policies:

Files, vector stores and batches are not ZDR-eligible. That does not itself mean they are BAA-ineligible. Compare the retention matrix with the coverage list.

• Responses web search: live access is outside BAA coverage. Cache-only coverage requires a ZDR project inside a ZDR organization. See the HIPAA search limitation.

• Search configuration: set external_web_access: false on web_search. Omission enables live access; web_search_preview ignores the setting. This is a tool control, not sufficient proof of coverage. See the search guide.

• Background mode: current docs allow ZDR requests with store=false, but describe roughly ten minutes of temporary disk storage for execution and polling. Under MAM, persistence beyond polling requires explicit store=true. Review that temporary storage against your requirements. See background-mode retention.

• Image inputs: suspected child sexual abuse material can trigger image retention for manual review despite ZDR, MAM or Private Retention with PSP. See the image-input exception.

4. If choosing ZDR with PSP, plan for customer storage

ZDR with Private Safety Processing (PSP) is distinct from the OpenAI-hosted Private Retention policy above. OpenAI describes encrypted safety records held in customer-controlled AWS, Azure or Google Cloud storage for automated review. The customer must preserve records for at least 30 days. See the PSP architecture and requirements.

Console setup requires ZDR approval. PSP applies across the project. Follow the provider-specific setup, configure storage permissions and lifecycle rules, then register and validate the destination. Registration alone leaves the policy unchanged. Confirm both Validated status and the project policy Zero Data Retention with Private Safety Processing. See setup and verification.

Validated records a successful check, not continuous health. Assign an owner for access, lifecycle rules and revalidation. Disconnecting the last storage connection resets the project to its organization’s default policy; it does not delete retained objects. See PSP operations. Do not assume self-serve BAA acceptance automatically provisions PSP.

This design also adds a cloud provider to the review. HHS guidance says a provider storing electronic PHI can be a business associate even without the decryption key. Encryption does not remove the need to assess that provider’s agreement and responsibilities.

5. Keep a workflow-level release record

A practical review method is to keep one row per PHI-bearing step: input source, model and endpoint, tools, storage destination, retention policy, external recipients and responsible reviewer. This is an implementation recommendation derived from the contractual and feature boundaries above, not an official certification checklist.

For example, a proposed document-summary workflow should distinguish the initial upload, retrieval store, model request, application logs and final output destination. Evidence covering the model request does not answer what happens in the other steps. An unresolved destination should hold that workflow’s PHI release while the team resolves it.

HHS calls for an appropriate BAA and the customer’s own risk analysis when using cloud services for electronic PHI. It does not certify specific products. Have the organization’s compliance and security reviewers assess the whole flow, including third-party tools and telemetry. See HHS cloud-computing guidance.

OpenAI’s guide also prohibits PHI in support requests and using eligible services to maintain a designated record set. Access management, monitoring and backup procedures remain customer responsibilities. Keep those controls in the release record. See the general implementation requirements.

For the platform configuration portion, RohitAI’s OpenAI Terraform governance guide discusses reviewable changes and configuration drift. That is a supporting engineering practice, not a mechanism for accepting a BAA.

The immediate next step is to identify the intended production project, review the agreement, and assemble the feature-by-feature record before enabling a PHI-bearing deployment. The new settings flow makes standard agreement acceptance self-serve for eligible organizations; the remaining decisions are specific to the workflow.

Methodology: AI-assisted reporting and analysis based on OpenAI documentation and HHS guidance checked on October 5, 2026. No account enrollment, API execution, PHI submission, clinical evaluation or storage validation was performed. The rollout date comes from the changelog; its exact announcement time is not stated.