AI Vendor Checklist for HIPAA-Regulated Teams: 14 Checks Across the Full PHI Path

Evaluating an AI vendor that will touch protected health information comes down to one discipline: trace the full PHI path, not just the contract. A vendor that creates, receives, maintains, or transmits PHI on your behalf is a business associate (45 CFR 160.103), the relationship requires a written agreement before PHI flows (45 CFR 164.502(e)), and that agreement then has to be true of every stage the content actually passes through — prompts and uploads, inference, storage, embeddings and other derived data, audit logs, and deletion at termination. As of 2026-08-28, this page walks that path stage by stage and turns it into a fourteen-item checklist, with what a good answer looks like and the red flag for each.

This page is general information about published regulations and agency guidance, not legal advice. Decisions about a specific vendor, agreement, or data flow belong with your organization's own counsel and privacy officer.

One honest sentence before any checklist: no vendor and no product — PrivateStack included — can make a covered entity or business associate meet its obligations under the Privacy, Security, and Breach Notification Rules. Those obligations attach to your organization and are met by your own program: your risk analysis, your policies and training, your agreements, your documentation. A vendor can change the facts that program runs on and hand you evidence; it cannot run the program for you.

The determination that comes first: is this vendor a business associate?

Everything else on this page is downstream of one status question. The Department of Health and Human Services has answered the modern versions of it directly in its published cloud-services guidance, including the two edges vendors most often argue: encryption does not change the answer, and neither does the word “platform.”

Trace the full PHI path

Most vendor reviews stop at “where do prompts go.” PHI moves through six stages in an AI workspace, each with its own places to land and its own retention clock — and the stages competing checklists skip, embeddings and logs, are exactly the ones where PHI persists after everyone believes it was deleted.

Do embeddings of PHI remain PHI?

This is where most published checklists stop, so it gets its own section. The honest answer: data derived from PHI should be treated as PHI until it is de-identified under 45 CFR 164.514 — format is not an exit. The Privacy Rule's standard turns on whether there is a reasonable basis to believe information can be used to identify an individual (164.514(a)), and it recognizes exactly two ways out: an expert determination that identification risk is very small, applying generally accepted statistical and scientific methods and documented (164.514(b)(1)), or the safe harbor — removal of eighteen identifier categories plus no actual knowledge that what remains could identify someone (164.514(b)(2)).

An embedding is a transformation of its source text, built to preserve meaning — and embedding-inversion and membership-inference research shows derived representations can leak what they were built from. A vector index built from clinical notes has been through neither 164.514 exit. So the checklist question is not “do you store embeddings” but “are vectors derived from PHI treated as PHI — same safeguards, same agreement scope, deleted when the source is deleted?” A vendor that answers “embeddings are anonymized” without a documented determination is making an undocumented expert determination on your behalf. The same logic guards the carve-out in the status table above: a vendor receiving only de-identified data is outside the rules only if the de-identification actually met 164.514(b) before the data left your control. And the discipline is not unique to health data: the CUI scoping guide for AI tools applies the same derived-data logic to controlled unclassified information, leg by leg.

When the audit log becomes a PHI store

The Security Rule expects audit controls — mechanisms that record and examine activity in information systems that contain or use electronic PHI (45 CFR 164.312(b)). But a log that captures prompt and output content containing PHI is itself such a system: it needs its own access controls, its own encryption, its own line in the risk analysis, and its own retention schedule. The three defensible log designs and where each one fails are mapped in the logging-modes guide, and the 21-field audit log schema template makes the content plane an explicit, declared field rather than an accident. Retention for the log itself is a scheduling decision, not a single number — the prompt log retention crosswalk maps it record type by record type.

The checklist

Fourteen items, in the order the review should run. Each carries what a good answer looks like and the red flag, because the failure mode in vendor review is accepting an adjective where an artifact was required.

1. 01Establish business-associate status in writing before any pilot

   What good looks like:

   The vendor states plainly that it is a business associate for your intended use — or shows precisely why the narrow conduit or de-identified-data carve-outs apply. The agreement comes before the first byte of PHI: 45 CFR 164.502(e)(1)(i) has no trial-period exception.

   Red flag:

   “We're just a platform, not a business associate,” or an invitation to pilot with production data while the paperwork is “in review.”

2. 02Obtain the business associate agreement in writing, and confirm which deployment tiers it covers

   What good looks like:

   A signed agreement before PHI flows, naming the covered products, tiers, and configurations — with the vendor volunteering which configurations are out of scope rather than leaving you to discover it.

   Red flag:

   “BAA available on request” with no tier scoping, or an agreement that covers the product's marketing name but not the plan and features you will actually use.

3. 03Verify the required contract terms are actually in the agreement

   What good looks like:

   The terms map to 45 CFR 164.504(e)(2) and 164.314(a)(2)(i): appropriate safeguards, reporting of uses and disclosures not provided for by the contract including breaches per 164.410, subcontractor flow-down, and return, destruction, or extended protections at termination.

   Red flag:

   A data-processing addendum written for other privacy regimes standing in for the 164.504(e) terms, with none of the required provisions present.

4. 04Get the complete subprocessor inventory — and the satellite agreements down the chain

   What good looks like:

   A current subprocessor list naming who touches PHI at which stage, confirmation that each has its own agreement per 45 CFR 164.502(e)(1)(ii) and 164.314(a)(2)(iii), and advance notice when the list changes.

   Red flag:

   “We use various cloud providers,” or a model provider that appears in the architecture diagram but not on the subprocessor list.

5. 05Trace attachments and uploads separately from prompts

   What good looks like:

   The upload pipeline is enumerated end to end — storage, preview and thumbnail generation, text extraction, malware scanning — and every helper service in that chain is named and covered.

   Red flag:

   A vendor that can answer the data-flow question for prompts but goes vague the moment the question becomes a PDF.

6. 06Pin the inference path: who serves the model, and what do they keep

   What good looks like:

   Named model providers, written retention terms — contractual zero-retention is the strong answer — and the provider's no-training commitment in the contract chain, not in a blog post.

   Red flag:

   A retention answer that covers only the vendor's own stores and goes silent on the model provider's.

7. 07Determine training use on your content

   What good looks like:

   A contractual commitment that PHI is never used to train or improve models, protection as the default rather than an opt-out someone must find and exercise.

   Red flag:

   Improvement rights buried in the terms of service, or an opt-out that must be re-exercised per workspace, per user, or per feature.

8. 08Ask the embeddings question in exactly these words: are vectors derived from PHI treated as PHI?

   What good looks like:

   Yes — same safeguards, same agreement scope, deleted when the source is deleted — or a documented de-identification determination under 45 CFR 164.514(b) that says otherwise, in writing.

   Red flag:

   “Embeddings are anonymized” with nothing documented. That is an expert determination made on your behalf, by a vendor, without an expert or a document.

9. 09Treat every log plane as a potential PHI store

   What good looks like:

   A per-plane inventory — audit, application, debug, analytics — stating which planes capture content versus metadata, with safeguards and a retention schedule for each plane that holds PHI.

   Red flag:

   Debug logging that echoes request bodies, or log pipelines flowing through third-party tooling that never appears on the subprocessor list.

10. 10Map the Security Rule safeguards to evidence, not adjectives

    What good looks like:

    Per-request attribution to a unique user identity (45 CFR 164.312(a)(2)(i)), audit controls (164.312(b)), encryption in transit and at rest, and a current risk analysis (164.308(a)(1)(ii)(A)) the vendor will let you review under NDA — noting the Security Rule's own distinction: encryption at rest is an “addressable” specification, meaning a documented decision is required, while unique user identification, audit controls, and the risk analysis are “required” specifications.

    Red flag:

    “Bank-grade security” and a trust page of logos, with no artifact behind either.

11. 11Fix the incident and breach-notification clock — through the whole chain

    What good looks like:

    The contract commits the vendor to report security incidents (45 CFR 164.314(a)(2)(i)(C)) and breaches of unsecured PHI per 164.410 in a stated number of days well inside the 60-calendar-day outer bound, with subprocessor discovery flowing to you on the same clock.

    Red flag:

    Notification “as required by law” with no stated days, and nothing binding the subprocessors' clocks — your own 60-day duty to individuals under 164.404 does not pause while the chain deliberates.

12. 12Verify deletion is a control you operate, not a request you make

    What good looks like:

    Deletion per plane — conversations, files, vectors, logs, backups — with stated backup-expiry windows, an operator-initiated path, and confirmation evidence when it completes.

    Red flag:

    A deletion promise that is silent about backups and derived stores, which is where PHI actually persists.

13. 13Get the termination story in writing: return, destruction, or extended protections

    What good looks like:

    The 45 CFR 164.504(e)(2)(ii)(J) behavior, stated with timelines: at termination, PHI is returned or destroyed if feasible; where destruction is infeasible — backups are the honest example — the contract's protections extend and further use is limited to what makes destruction infeasible.

    Red flag:

    Silence about what survives termination, or “we may retain data as required by our policies.”

14. 14Walk the data-flow diagram with your privacy officer before signature

    What good looks like:

    The vendor produces a current data-flow diagram naming every store and subprocessor stage by stage, reviews it live with your privacy officer, and the diagram agrees with the subprocessor list and the agreement's scope.

    Red flag:

    No diagram exists, or the diagram, the subprocessor list, and the agreement each tell a different story.

This checklist is the PHI overlay on a broader instrument: the AI vendor security questionnaire carries 21 scored questions across data flow, retention, logging, isolation, training use, incident response, and access control — run it first, then apply these fourteen items wherever PHI is in scope.

How PrivateStack fits this checklist

PrivateStack's healthcare posture is built to answer this checklist, and the scoping comes first: PHI workloads belong on an Enterprise deployment. On an Enterprise deployment, PHI never leaves your VPC and never reaches PrivateStack systems, so your business-associate surface stays inside your own cloud. The platform runs on HIPAA-ready architecture — encryption, access control, audit logging, and isolation consistent with the technical safeguards expected of systems that handle protected health information — and every request is logged in a complete, exportable audit trail: who accessed what, and when. Hosted-tier inference is processed by a disclosed US-based subprocessor under contractual zero-retention terms: prompts are never stored and never used for training.

On the agreement itself, our published position is the one item 02 asks you to extract from any vendor: handling PHI in production requires a Business Associate Agreement (BAA), a signed BAA is required before processing PHI, and not every configuration is in scope — contact us first. Bring your privacy officer to the security review; we will walk the data-flow diagram together and work through BAA requirements where they apply. And the limits, stated plainly: none of this runs your risk analysis, writes your policies, or performs the program the Rules require of your organization — no product can, and we will not tell you otherwise. The healthcare solution page covers the deployment in detail, and the security page carries the full control set.

Questions people actually ask

Do embeddings created from protected health information remain protected health information?

Treat them as PHI unless a documented de-identification determination says otherwise. The Privacy Rule's standard (45 CFR 164.514(a)) turns on whether there is a reasonable basis to believe information can be used to identify an individual — not on its format — and the only two recognized exits are expert determination under 164.514(b)(1), which requires a qualified expert applying generally accepted statistical and scientific methods to document a very small identification risk, and the safe harbor under 164.514(b)(2), which requires removing eighteen identifier categories plus having no actual knowledge the remainder could identify someone. A vector derived from a clinical note is a transformation of identifiable information, and embedding-inversion and membership-inference research shows derived representations can leak what they were built from. A vendor that treats vectors as out of scope without a documented determination is making that call for you, undocumented. Ask for the position in writing, and for delete-with-source behavior.

Does signing a business associate agreement make an AI tool safe for protected health information?

No. The agreement is a required legal instrument (45 CFR 164.502(e), 164.504(e)) — it is not a control. It does not configure retention, scope the subprocessor chain, keep PHI out of debug logs, or run your risk analysis. That is why the agreement is item two on this checklist rather than the whole checklist, and why your own obligations under the Privacy, Security, and Breach Notification Rules remain yours regardless of what any vendor signs.

Is an AI vendor still a business associate if it only stores encrypted data and cannot read it?

Yes. The Department of Health and Human Services' published answers are explicit: an entity that maintains electronic PHI on behalf of a covered entity or business associate is a business associate even if it cannot view the information, and lacking the decryption key does not exempt it from the status or its obligations. Encryption significantly reduces the risk of unauthorized viewing, but it does not by itself satisfy the Security Rule's administrative and physical safeguards, and it does not remove the requirement for an agreement.

How quickly must an AI vendor notify you of a breach?

The regulatory outer bound is 60 calendar days from discovery: a business associate must notify the covered entity of a breach of unsecured PHI without unreasonable delay and in no case later than 60 calendar days after discovery (45 CFR 164.410), and a breach is treated as discovered on the first day it is known or would have been known with reasonable diligence. Your own duty to notify affected individuals runs on the same without-unreasonable-delay, 60-day standard from your discovery (164.404). A third clock is different in kind: notifying the Secretary of a breach affecting fewer than 500 individuals is due within 60 days after the end of the calendar year in which the breach was discovered (45 CFR 164.408) — distinct from both the business-associate-to-covered-entity and covered-entity-to-individual clocks. Contracts routinely shorten the vendor's clock, and should — every subprocessor hop adds a discovery-and-notification handoff, and a slow chain consumes the window in which you have to act.

Can a governed AI workspace keep audit logs if prompts contain protected health information?

Yes — the Security Rule's audit-controls standard (45 CFR 164.312(b)) expects mechanisms that record and examine activity in systems containing electronic PHI. But a log that captures prompt content containing PHI is itself such a system: it needs its own access controls, encryption, place in the risk analysis, and retention schedule. The defensible designs — full-content, redacted field-level, and metadata-plus-hash — are mapped mode by mode in our logging guide, with the contexts where each fails. The requirement this checklist adds is that the choice be deliberate and written down, not discovered in a debug log later.

Two companion reads finish the picture: the zero data retention vs no training guide maps the eight planes a single request can leave content on, and the closed-API comparison covers where each deployment model leaves these controls — including where the closed API wins. And to turn these checks into rules your workforce actually follows, the healthcare template in the AI acceptable-use policy templates renders the same discipline as ten adoptable clauses.

Primary sources

Every regulatory statement above traces to one of these publications. Read the instrument before any vendor's interpretation — including ours.

• 45 CFR 160.103 — Definitions — The definitions the whole analysis stands on: business associate — including subcontractors that create, receive, maintain, or transmit PHI on behalf of another business associate — and protected health information itself.
• 45 CFR 164.502(e) — Disclosures to business associates — The satisfactory-assurances condition before PHI may flow to a business associate ((e)(1)(i)), and the provision that pushes the same assurance down the chain when a business associate engages a subcontractor ((e)(1)(ii)).
• 45 CFR 164.504(e) — Business associate contracts — The required contract provisions: safeguards, reporting of non-contracted uses and disclosures including 164.410 breaches ((e)(2)(ii)(C)), subcontractor flow-down ((e)(2)(ii)(D)), and return, destruction, or extended protections at termination ((e)(2)(ii)(J)).
• 45 CFR 164.308 — Administrative safeguards — The accurate-and-thorough risk analysis ((a)(1)(ii)(A)), security incident identification, response, mitigation, and documentation ((a)(6)), and the business-associate-contracts standard ((b)).
• 45 CFR 164.312 — Technical safeguards — Access control including unique user identification, the audit-controls standard — mechanisms that record and examine activity in information systems that contain or use electronic PHI ((b)) — integrity, person or entity authentication, and transmission security.
• 45 CFR 164.314(a) — Organizational requirements — The Security Rule terms a business associate contract must carry — comply with the applicable requirements, bind subcontractors by contract, report security incidents — applied identically to business-associate-to-subcontractor contracts ((a)(2)(iii)).
• 45 CFR 164.514 — De-identification — The de-identification standard ((a)), expert determination — generally accepted statistical and scientific principles, documented very-small risk ((b)(1)) — and the safe harbor's eighteen identifier categories plus the actual-knowledge condition ((b)(2)).
• 45 CFR 164.404 — Notification to individuals — Notification to individuals by the covered entity: the discovery rule, and the without-unreasonable-delay, 60-calendar-day outer bound on that leg.
• 45 CFR 164.408 — Notification to the Secretary — The Secretary's own clock: breaches affecting 500 or more individuals are reported contemporaneously with the individual notice, and breaches affecting fewer than 500 individuals within 60 days after the end of the calendar year in which they were discovered.
• 45 CFR 164.410 — Notification by a business associate — Notification to the covered entity by the business associate: the discovery rule, and the without-unreasonable-delay, 60-calendar-day outer bound on the business associate's leg.
• Department of Health and Human Services — business associate questions and answers — The Office for Civil Rights' published answers on cloud services: when a provider is a business associate, the no-view holding (encrypted storage without the key is still a business associate), the narrow transmission-only conduit exception, and the carve-out for properly de-identified data.