Is Grok HIPAA Compliant? The BAA and Zero Data Retention Gate

Is Grok HIPAA compliant? SpaceXSI now publishes a Business Associate Agreement request path and contract language for a narrow answer. Its Enterprise Terms say a customer must execute a BAA and use the Zero Data Retention-enabled API before submitting protected health information. Conditional eligibility is limited to that approved API workflow. Other hosted and mobile surfaces require their own written coverage. The same applies to connector and beta surfaces.

TL;DR

• SpaceXSI has a public BAA questionnaire for customers requesting an agreement to support HIPAA compliance when using SpaceXSI APIs.
• Enterprise Terms require an executed BAA and the Zero Data Retention-enabled API before a customer submits PHI.
• The public path supports conditional API eligibility, not a universal claim that every Grok surface may process PHI.
• Healthcare teams still own minimum-necessary use and identity controls. They also own authorization and application retention, plus downstream processors and operating evidence.

Is Grok HIPAA compliant for API use

SpaceXSI's public BAA questionnaire says it is for customers requesting a Business Associate Agreement to enable HIPAA compliance when using SpaceXSI APIs. The form requires an authorized company representative and says SpaceXSI will review the request. Its Enterprise FAQ adds that the company can support customer HIPAA obligations under some circumstances and directs buyers to that questionnaire.

The public path supports API eligibility under stated conditions. A customer can request a BAA, but a submitted questionnaire is not an executed agreement. Approval begins only after the healthcare organization receives and signs the BAA. The organization must then confirm the contracting entity and match the agreement to the purchased API service and intended PHI route.

Current legal pages identify SpaceXAI LLC as "SpaceXSI," while older assessments may name xAI. Preserve the entity shown in the executed agreement and order form. A familiar x.ai URL cannot substitute for matching the legal counterparty.

The contract requires a BAA and ZDR together

The current SpaceXSI Enterprise Terms contain the decisive condition. A customer must not intentionally submit PHI unless it has first entered a BAA with SpaceXSI and uses the company's Zero Data Retention-enabled API for that data. These are cumulative requirements, not alternatives.

The same terms describe ZDR behavior. User Content should exist only transiently to generate and return the response. SpaceXSI says it deletes User Content by the earlier of delivery of the response or one hour after completion of the inference request, with no durable logs or backups and no persistent copies containing that content afterward. The customer is responsible for preserving records required for legal, regulatory, or audit purposes.

Without ZDR, the Enterprise Terms allow automatic deletion of User Content no later than 30 days after the interaction, subject to stated exceptions and alternate written terms. That standard retention path does not satisfy the contract's PHI condition. A security review should verify that the production credential and endpoint actually have ZDR enabled, rather than relying on a sales statement or test-project screenshot.

SpaceXSI separately says Enterprise User Content is not used to train its models, subject to disclosed customer-controlled settings. That rule leaves the BAA and ZDR as independent requirements, along with authorization to disclose PHI.

Hosted Grok surfaces need separate written coverage

The BAA page expressly names SpaceXSI APIs. The Enterprise Terms cover API and related business services, including Grok, but their PHI clause directs protected health information through the ZDR-enabled API. Public marketing on the Grok Business page displays a HIPAA label alongside SOC 2 and SSO, plus SCIM. That badge does not override the more specific contract condition.

Treat grok.com and Grok on X as unapproved for PHI unless the executed BAA and written service schedule explicitly include them. Apply the same rule to mobile applications and Business chat, as well as connectors and voice. Image features and agents also need explicit coverage. So do beta offerings. Some of those paths may store conversations, call external tools, or involve a third party. The customer needs the exact inclusion and exclusion language, not an inference from the product family.

This product-specific method matches the Grok enterprise security review. Security controls can support an eligible workflow after the contract gate passes. They cannot extend a BAA to an unnamed service.

Map PHI through the complete request path

A healthcare application can send more than the text visible in a prompt box. System instructions and retrieved chart excerpts can carry PHI. Previous messages and tool results can carry it too, as can images and metadata. Draw the route from the source system to the API. Continue it through every log and queue, then through each monitoring service and support process to the output destination.

Then match each processor to a contract. Review SpaceXSI's subprocessor list and the BAA's subcontractor terms. If an application uses an external retrieval service or sends Grok output to another vendor, that branch needs its own HIPAA basis. A covered API call does not pull an uncovered integration inside the agreement.

HHS cloud computing guidance says a cloud service handling electronic PHI for a covered entity or business associate generally requires a HIPAA-compliant BAA. The AI vendor BAA guide explains how to keep the covered-service schedule and processor chain tied to the actual architecture.

Customer controls decide whether the deployment is compliant

The BAA and ZDR establish provider-side prerequisites. The healthcare organization still decides who may use the workflow, for what purpose, and with which patient information. It must enforce access removal and incident response. Sanctions and workforce training also need enforcement, along with periodic evaluation. It also must maintain any records that ZDR intentionally prevents SpaceXSI from retaining.

Minimum necessary applies to the assembled request. A user asking for one paragraph does not justify retrieving a complete longitudinal chart. The application should limit source fields and verify the patient context. It should also block unrelated attachments. The PHI redaction guide can reduce unnecessary identifiers, but redaction does not fix an uncovered service or an unsigned BAA.

Audit design needs the same care. Preserve the authenticated user or workload and approved purpose. Record the data classification and API route, along with the policy version and outcome. Include the timestamp. Avoid copying full PHI into a secondary decision log. The HIPAA AI audit-log guide separates evidence needed for accountability from unnecessary content retention.

A defensible approval records the narrow eligibility

A complete approval file should contain the signed BAA and SpaceXSI legal entity. Include the order form and named API service, followed by the ZDR confirmation and model and endpoint. Add the subprocessor review and data-flow diagram, then name the customer control owner. Add test evidence showing that a non-ZDR route rejects PHI and that an unauthorized identity cannot call the approved route.

Review the file after a model change or new API capability. An integration or billing change also requires review, as does a contract update. Beta features should be outside the workflow until written terms and coverage support them. If the BAA or ZDR requirement is missing, keep PHI out.

The public evidence is stronger than a marketing badge because it exposes both an acceptance path and a contractual condition. It still answers only whether a specific deployment can become eligible. No vendor is "HIPAA certified" for every customer use. Compliance depends on the agreement and covered service. It also depends on the configured architecture and daily operation.

DeepInspect

DeepInspect can inspect authenticated HTTP requests deliberately routed to an approved SpaceXSI API endpoint. It can bind identity and purpose to each call, then classify the assembled payload. It can require the approved ZDR route and deny prohibited content. It can also retain a decision record without duplicating the full prompt.

SpaceXSI's BAA decision and ZDR implementation are outside that boundary. Provider processing and hosted Grok products are outside it too, as are third-party integrations. The contract and architecture must establish eligibility first. DeepInspect then helps operate the healthcare organization's policy on the API traffic it can actually observe.

Book a technical deep dive at deepinspect.ai.