Is Zoom AI Companion HIPAA Compliant? A BAA and Feature Review

Zoom says AI capabilities are available to customers that have Business Associate Agreements with Zoom, while warning that certain AI capabilities may not be available to healthcare and higher education customers with BAAs. That makes the answer conditional. Zoom AI Companion can support a HIPAA-regulated workflow only when the customer has the right agreement, the exact capability is available under that agreement, and the customer operates the workflow with the safeguards HIPAA requires.

TL;DR

• Do not approve the Zoom AI Companion brand as one undifferentiated service. Record the exact capability and account, plus the meeting or chat workflow and data path that may handle PHI.
• Put a Zoom BAA in place before PHI enters the service, then confirm that the selected AI capability is available for BAA customers.
• Use Zoom's administrative controls and retention settings, plus access restrictions and user notices, as inputs to a customer-owned control plan.
• Recheck capability availability after product or account changes. A BAA does not turn every current or future Zoom AI capability into an approved PHI route.

Zoom gives a qualified yes, not blanket HIPAA approval

Zoom's current HIPAA Business Associate Agreement support article says it enters into BAAs with customers to facilitate HIPAA compliance. Under its "AI Feature Availability Under BAA" heading, Zoom says AI capabilities are available to BAA customers and that account administrators and users have controls for managing them. The same section says certain AI capabilities may not be available to healthcare and higher education customers with BAAs.

Those statements support a qualified answer. They do not support calling every Zoom AI Companion capability "HIPAA compliant" without reviewing the account and workflow. The approval object should be something narrow, such as Meeting Summary in a named Zoom Workplace tenant for a defined care-coordination purpose. It should not be the Zoom brand or an employee's personal account. It also should not cover every AI capability that later appears in an admin console.

This product-level approach matches the review used for other HIPAA-compliant AI tools. Procurement establishes the covered vendor relationship. Security and privacy teams approve the configured route that PHI actually takes.

The BAA establishes the contractual boundary

HIPAA generally requires a covered entity to obtain satisfactory assurances from a business associate that handles PHI on its behalf. Zoom's support article says customers can enter into a BAA when purchasing eligible plans and describes how existing healthcare customers can manage one. The Zoom for Healthcare page also says the platform supports customers' HIPAA obligations by executing a BAA.

The signed agreement must precede PHI use. Save the executed BAA and account identifier in one decision record. Add the approved capability and review date, and keep the current Zoom product documentation in the same record. If the organization changes plans or enables another capability, reopen the record before assuming the original decision carries forward. Do the same before connecting an outside application.

A BAA settles an important contract question. It does not configure who can start an AI capability, decide which meeting may contain PHI, set retention, or review activity. The HIPAA BAA guide for AI vendors explains why the covered service and operating evidence need separate owners.

Capability availability must be checked in the real tenant

A BAA customer still needs to confirm that the intended AI capability is available and enabled in its account. Zoom's wording is explicit that some AI capabilities may be unavailable for BAA customers. An administrator should therefore capture the exact capability name and its settings across the account and relevant groups, then for individual users. The evidence should show the tenant and setting state. It should also identify the reviewer and review time.

The test should then follow a representative workflow. For a meeting summary, identify who may start the capability and how participants are notified. Determine what source content is processed, where the resulting summary appears, who can read it, and how long related artifacts remain. If the workflow sends the summary into an EHR, a messaging service or an automation platform, review that destination separately. Zoom's BAA cannot extend through an outside processor merely because the transfer began inside Zoom.

The existing Zoom AI Companion security review covers the broader content map and model routes, along with administrative-control tests. A HIPAA decision adds the BAA and PHI-purpose checks to that security review.

Training and retention are different control questions

Zoom states in the BAA support article that it does not use customer audio and video; chat and screen sharing; attachments; or other communications-like content to train Zoom or third-party AI models. Its AI governance and privacy documentation separately describes encryption and access. It also covers processing locations and retention, plus subprocessors and how Zoom AI capabilities use customer content.

The training statement does not answer every retention question. A summary can remain available to users even when source content is not used for model training. A transcript may have its own retention path. Feedback can add context. Third-party subprocessors can participate in processing. Record each of those paths for the selected capability instead of using "not used for training" as a substitute for a data-flow review.

For PHI, minimum necessary also applies to the customer's design. A meeting that requires one clinical fact should not automatically expose an entire patient history to every participant or downstream summary. The PHI redaction guide for AI prompts shows how to reduce sensitive content on model API paths. Hosted Zoom interfaces require controls in Zoom and the surrounding clinical workflow rather than an external prompt gateway.

Administrative controls need an executed test

Zoom's administrative controls documentation describes centralized controls for AI functionality. The deployment record should show how the organization uses those controls, not merely link to the documentation. Test an approved role and a denied role against the capability. Confirm how settings inherit from account to group and user. Verify that the expected participant notice appears and that the resulting artifact follows the chosen access and retention settings.

Audit evidence should identify the natural person and the capability event wherever the platform exposes those fields. If a clinical application sends PHI through a separate model API, keep a request-level record with identity and purpose; data class and endpoint; policy version and outcome. A platform audit event and an application request record answer different questions. The HIPAA AI audit trail lists the evidence fields worth preserving.

Repeat the test when Zoom changes the capability, when the tenant changes its license, or when the workflow gains a new integration. A dated, successful test is stronger evidence than a screenshot of a toggle with no identified user or route and no result.

A defensible approval record

I would require eight fields before approving a Zoom AI workflow for PHI: the Zoom account; executed BAA; exact AI capability; clinical purpose; permitted users; source content; output destinations; and control owner. Add the retention setting and test result. Include the documentation version and next review date. Record exclusions just as carefully. Personal accounts and unavailable capabilities stay outside the decision. So do unreviewed integrations and newly released capabilities.

This structure turns a vague compliance claim into a reviewable conclusion. A named capability in a BAA-covered account may receive approval when it is available and the customer safeguards are implemented. Without the agreement, the workflow is ineligible for PHI. If capability coverage or settings are unverified, the decision remains pending. The same applies to downstream processing.

DeepInspect

DeepInspect can inspect authenticated HTTP requests sent directly from a customer application to model endpoints when those calls are routed through DeepInspect. It can apply identity-bound policy before forwarding a request and retain a per-decision audit record for that traffic.

Zoom's hosted meetings; Team Chat; AI Companion user interface; tenant administration; BAA coverage; participant notices; and Zoom-side retention remain outside DeepInspect's boundary. DeepInspect cannot make an unavailable Zoom capability eligible under a BAA. Use it for the customer-controlled HTTP model route it can actually observe, after the product and contract decision is complete. Book a technical deep dive at deepinspect.ai.