Is Perplexity HIPAA Compliant? Verify the BAA and Service Scope

Is Perplexity HIPAA compliant? Perplexity currently markets its Enterprise offering as HIPAA compliant, while its security page uses the narrower phrase "HIPAA-aligned safeguards." Neither public statement is enough to approve protected health information by itself. HHS requires a HIPAA-compliant Business Associate Agreement when a cloud service creates or receives electronic PHI, or maintains or transmits it for a covered entity or business associate. Keep PHI out until the executed BAA and its covered-service scope match the exact Perplexity workflow.

TL;DR

• Perplexity's public Enterprise page says the offering is HIPAA compliant, while its security page describes HIPAA-aligned safeguards.
• Public marketing does not substitute for an executed BAA covering the exact organization and service. It must also cover the capability and PHI route.
• Verify whether Enterprise search and uploaded files fall inside the agreement. Do the same for connectors and Computer, audit webhooks and any third-party model routes.
• Apply controls for minimum-necessary use and identity. Add retention and access controls, plus incident and audit controls, after the contract gate passes.
• DeepInspect can govern deliberately routed HTTP model calls, but it cannot create BAA coverage or control direct hosted Perplexity sessions.

The public Perplexity HIPAA claim needs contract evidence

The current Perplexity Enterprise page says Perplexity is GDPR and HIPAA compliant and that enterprise customer data is not used to train its models. The Perplexity security page, last updated August 21, 2026, describes "HIPAA-aligned safeguards" alongside SOC 2 Type 2 certification and other security practices.

Those pages support a procurement inquiry. They do not publicly identify the contracting entity, covered Enterprise plans, included capabilities, exclusions, or the BAA acceptance path. They also do not show whether a buyer's executed order form activates any required HIPAA configuration. A healthcare approval should therefore treat the claim as vendor evidence to verify, not as a blanket permission to submit PHI.

Ask Perplexity for the BAA and covered-service schedule. Record the organization and workspace, plan, product names, enabled capabilities, subprocessors, and third-party model routes. Record the retention choices and contract effective date. If Perplexity supplies those details only under NDA, preserve the reviewed documents in the vendor file rather than replacing them with a screenshot of the public page.

HHS makes the BAA a gate, not an optional extra

HHS cloud computing guidance says a covered entity or business associate may use a cloud service to store or process ePHI when it enters a HIPAA-compliant BAA with the provider and otherwise complies with the HIPAA Rules. HHS also explains that a cloud provider handling ePHI can be a business associate even when it cannot view encrypted data.

The agreement defines permitted and required uses and disclosures. It also addresses safeguards, breach reporting, and subcontractors. Return or destruction and other business-associate duties also belong in the agreement. That contract gate comes before a security-feature review. SOC 2 reports, encryption, SSO, or a provider's "HIPAA-aligned" language cannot replace the BAA.

The HIPAA BAA guide for AI vendors explains the wider vendor-chain review. For Perplexity, procurement should map each named service and processor to the signed agreement instead of assuming that one Enterprise label covers every path.

Service scope must follow the PHI route

A Perplexity workflow can include the hosted Enterprise interface, an uploaded file, web search, an organization repository, a connector, or an agentic Computer action. It may also involve a third-party model and a customer-controlled audit webhook. Each component can receive PHI or metadata derived from it.

Draw the route for one representative task. Name the workforce user and workspace. Add the source system and connector, the Perplexity capability, selected model path, generated answer, storage location, audit destination, and every downstream application. Then mark which boxes appear in the BAA or covered-service schedule.

The Perplexity Enterprise security review documents current SSO, SCIM, sharing, connector, and retention controls. Those settings matter after eligibility is established. They do not prove that Computer, every connector, every model, or a webhook receiver is contractually covered for PHI. An uncovered branch keeps the workflow outside the approval until the contract and architecture are reconciled.

Minimum necessary applies to prompts and retrieved context

HHS's minimum necessary guidance generally requires reasonable steps to limit PHI uses, disclosures, and requests to the minimum needed for the intended purpose, subject to stated exceptions. An Enterprise account does not perform that purpose test for the healthcare organization.

A user may ask for a short discharge summary while a connector retrieves an entire chart. An agent may add previous threads or files to the request. The approval should identify the intended purpose and authorized role. It should also identify permitted source fields and the approved output destination. Test the assembled request rather than reviewing only what the user typed.

Use synthetic records first. Confirm that a user without the required role cannot invoke the PHI workflow. Verify that retrieval excludes unrelated patients and unnecessary fields. Inspect the answer for carried-forward identifiers. Record the policy outcome and reviewer. The PHI redaction guide covers content reduction before an approved model request, but redaction remains a customer control rather than a substitute for coverage.

Enterprise controls still need operating evidence

Once the BAA and service scope pass, the organization needs evidence that production still matches the approved design. Preserve the workspace identifier and SSO configuration. Record authorized groups, connector settings, file and thread retention, sharing restrictions, audit destination, and incident contacts. Assign an owner to each control.

Test a permitted request and a prohibited request on a defined cadence. The evidence should connect the authenticated person or workload to the approved purpose and data class. It should identify the Perplexity route and policy version. It should also identify the result and timestamp. Keep content retention separate from decision retention so the audit system does not become another unnecessary PHI repository.

Perplexity's audit stream can provide provider-side activity evidence. The Perplexity Enterprise audit-log review explains its webhook and content sensitivity. A customer-controlled policy decision answers a different question: whether the enterprise authorized this disclosure before the model received it. Keep both records when the architecture supports them.

Direct Enterprise use and API routing have different boundaries

A healthcare application that deliberately routes an HTTP model call through a customer control point can attach verified identity and purpose before transmission. It can classify the assembled payload and enforce the approved destination. It can also retain a decision record. That path makes the customer's minimum-necessary and authorization rules testable.

A direct Perplexity browser session may bypass that control point. The Enterprise workspace and browser policy govern that route, along with endpoint controls and Perplexity's own logs. Computer actions and connector retrieval can also cross boundaries that an external model gateway does not see. The architecture should state which paths are controlled instead of treating every Perplexity capability as one interchangeable endpoint.

No technical route repairs a missing contract. If the organization lacks a signed BAA covering the chosen service and capability, keep PHI out. If the BAA exists, enforce the healthcare organization's remaining rules only on traffic and systems the relevant control can actually observe.

DeepInspect

DeepInspect can inspect authenticated HTTP model traffic that a healthcare application or agent deliberately routes through its stateless proxy. It can evaluate application-supplied identity and PHI classification before forwarding an approved request. It can also evaluate the destination and policy version, then create a per-decision audit record.

Perplexity's contract, BAA scope, hosted Enterprise interface, connectors, Computer actions, retention, and provider-side processing are outside that boundary. DeepInspect can help enforce the covered entity's policy on a controlled model route. It cannot turn an uncovered Perplexity service into a HIPAA-eligible one.

Book a technical deep dive at deepinspect.ai.