
> **TL;DR.** A DPA for an AI vendor has to cover the same Article 28 ground as any other processor contract, plus four AI-specific concerns: training defaults, retention defaults, subprocessor depth, and EU/UK transfer mechanism. The vendor name on the front page tells you nothing on its own — the answer always lives in which product you bought (API, enterprise tier, consumer plan) and which retention setting is in force.

## Why an AI vendor DPA is different

A Data Processing Addendum is the contract Article 28 GDPR requires whenever a controller hands personal data to a processor. The structure is the same for any SaaS vendor: scope, instructions, security, subprocessors, transfers, deletion, audit, breach.

What changes with AI vendors is the surface area the DPA has to cover. Three additions force themselves into every serious review:

1. **Training position.** Does the vendor use your inputs and outputs to train models? Commercial defaults at the major providers say no. Consumer defaults at the same providers often say yes — and the default at the consumer tier has flipped at least once for both OpenAI and Anthropic in the last 18 months.
2. **Retention default.** How long does the vendor keep prompts and outputs after the API call returns? Defaults sit at 7-30 days on commercial tiers, with Zero Data Retention (ZDR) available on request from OpenAI and Anthropic. Some enterprise products on Microsoft and Google sit on customer-controlled storage and answer the question differently.
3. **Subprocessor depth and EU Data Boundary scope.** Most AI products now run on at least two clouds plus the model provider, and the subprocessor list has been growing. Anthropic became a Microsoft 365 Copilot subprocessor on 2026-01-07 and is explicitly out of EU Data Boundary scope for that route. Buyers who assumed Copilot meant EU-only processing got a surprise.

The DPA is the artifact that pins all three down in writing. Reading it once is not optional for any AI deployment that touches personal data, and a re-read on every major product change is the realistic minimum.

## The eight clauses that actually decide the risk

A serious DPA review looks at all standard Article 28 clauses, but the eight below carry most of the AI-specific weight.

### 1. Scope of processing and instructions

The DPA has to state what the vendor processes on your behalf and that they only process on your documented instructions. With AI products this clause has to expressly cover prompts, outputs, embeddings, attached files, retrieval-augmented context, and tool-call results. Vendors who quietly leave embeddings or tool-call payloads out of scope create a gap you cannot rely on for an Article 28 claim.

### 2. Training position (commercial tier)

The default at every commercial AI provider this review covers is contractually no training on customer data through the API or enterprise product. The contract clause is what gives that default legal weight — the help-centre page does not. Check that the DPA itself, not the marketing site, contains the no-training commitment.

### 3. Training position (consumer or free tiers)

The same vendor will often run a different default at the consumer tier. OpenAI flipped its consumer training default to opt-out by setting in late 2025; Anthropic flipped its consumer claude.ai default to opt-in for training on 2025-10-08, with up to five-year retention on inputs of users who opted in. Staff who use the free consumer product without an enterprise contract are inside the consumer default, not the commercial one. The DPA does not protect them because no DPA applies.

### 4. Retention defaults and Zero Data Retention

API retention defaults at OpenAI sit at 30 days. Anthropic dropped its API default from 30 days to **7 days** on 2025-09-14 — the strongest default in the LLM market at time of writing. Both vendors offer ZDR through their commercial sales channel, but ZDR is approval-gated, not on by default. A buyer who needs ZDR has to apply, document the use case, and accept that certain abuse-monitoring exceptions remain.

### 5. Subprocessor list and change-notice cadence

AI vendors are stacking subprocessors faster than legacy SaaS. The list now routinely includes the model provider, the cloud the model runs on, a content-moderation provider, an analytics provider, and a security tooling provider. The DPA should commit to publishing the list, giving notice on additions, and providing an objection mechanism. The realistic notice window has shortened to 14-30 days at most AI vendors, which compresses the buyer's diligence window.

### 6. EU/UK transfer mechanism

The post-Schrems II structure stands: Standard Contractual Clauses for EU controller-to-processor transfers, the UK Addendum on top for UK controller exports, and a Transfer Impact Assessment to back both up. AI vendors should name the SCCs in use (the 2021 set, not the legacy 2010 set), the UK Addendum version, and any EU Data Boundary commitment they make on top. Anthropic's 2026-01 inclusion as a Copilot subprocessor with an explicit EU Data Boundary carve-out shows why the "EU-only" claim from any enterprise vendor needs the carve-outs read line by line.

### 7. Security commitments and certifications

The DPA should reference the vendor's security documentation, and the buyer should pull the documents named. SOC 2 Type II and ISO 27001 are the realistic floor; ISO 27701 and ISO 42001 (AI management system) are appearing on the better vendors. A DPA that names a certification the vendor has not actually maintained is a flag worth raising in writing before signature.

### 8. Deletion and return at end of contract

Article 28(3)(g) requires deletion or return at the controller's choice. With AI vendors the practical question is whether deletion applies to model artifacts that may have been built from the customer's data on enterprise tiers with fine-tuning or retrieval augmentation. A buyer who fine-tuned should ask for written confirmation that the fine-tuned model is deleted, not just the underlying training data.

## How the six vendors line up on the DPA basics

The full review for each vendor lives in the dedicated profile. The table below is the at-a-glance read for buyers triaging multiple products in one procurement window.

| Vendor | Commercial training default | API retention default | ZDR available | Profile |
|---|---|---|---|---|
| OpenAI | No (API/Enterprise) | 30 days | Yes, approval-gated | [OpenAI](/vendors/openai) |
| Anthropic | No (API/Team/Enterprise) | 7 days | Yes, approval-gated | [Anthropic](/vendors/anthropic) |
| Microsoft 365 Copilot | No (tenant-bound) | Tenant-controlled | N/A (tenant model) | [Microsoft 365 Copilot](/vendors/microsoft-365-copilot) |
| Google Gemini (Workspace) | No (workspace-bound) | Workspace-controlled | N/A (workspace model) | [Google Gemini](/vendors/google-gemini) |
| Perplexity (Enterprise) | No (Enterprise tier) | Enterprise-tier defaults | Enterprise-tier dependent | [Perplexity](/vendors/perplexity) |
| ElevenLabs | No (Enterprise / API) | Tier-dependent | Enterprise-tier dependent | [ElevenLabs](/vendors/elevenlabs) |

The pattern across the six: commercial defaults are protective, consumer defaults often are not, and the enterprise tenant-bound products (Copilot, Workspace Gemini) push retention into the buyer's own Microsoft or Google environment rather than holding it at the AI vendor.

## The DPA review steps for a procurement gate

The version below assumes the buyer has a procurement gate to clear and a DPO or compliance owner who has to sign off.

1. **Confirm which product the staff or app will actually use.** Commercial API, enterprise SaaS tenant, or consumer free / Pro / Max plan. The DPA only covers what the buyer actually contracted for.
2. **Pull the live DPA from the vendor's portal.** Do not rely on the marketing version of the page. Note the version number and date.
3. **Read clauses 1-8 above against the buyer's deployment.** Flag any clause whose scope does not match what the staff will actually do with the product.
4. **Cross-check the subprocessor list against EU Data Boundary expectations.** If the buyer needs EU-only processing, every subprocessor has to be inside that scope or have a documented carve-out the buyer can accept.
5. **Decide on ZDR or extended retention.** ZDR is the cleaner default for any deployment touching special-category data. The application step takes 1-3 weeks at OpenAI and Anthropic in our experience.
6. **Document the transfer mechanism.** SCC version, UK Addendum status, Transfer Impact Assessment on file. The procurement gate needs the three artifacts; the DPA itself usually only names the first.
7. **Record the consumer-tier exposure.** If staff might use the free consumer product alongside the contracted enterprise tool, the DPO needs a written policy on which is permitted. The default at the consumer tier is what governs, and that default is not always protective.

## When the DPA is not enough

A DPA covers processor obligations. It does not cover the AI-specific risks that sit upstream:

- The DPIA the buyer owes under Article 35 for the deployment itself
- The AI Act role assessment (provider, deployer, distributor) for any system that touches the EU market
- The buyer's own data-mapping for what categories of personal data the deployment ingests
- The retention policy the buyer applies on its own side, regardless of the vendor's retention default

The DPA pins the vendor down. The DPIA and the AI Act role assessment pin the buyer down. Both have to land before the procurement gate closes.

## Related reading

- The buyer-side AI Act read for the same six vendors: [EU AI Act for AI buyers](/topics/eu-ai-act-for-ai-buyers)
- The US healthcare-adjacent read for the same vendors: [HIPAA for AI tools](/topics/hipaa-for-ai-tools)
- Head-to-head on the two most-asked-about API vendors: [OpenAI vs Anthropic DPA](/compare/openai-vs-anthropic-dpa)
- Enterprise tenant comparison: [Copilot 365 vs Google Workspace AI](/compare/copilot-365-vs-google-workspace-ai-compliance)


Buyer-side reference for the AI vendor DPA. What clauses matter, what defaults bite, and where the six biggest vendors land on each. CIPP/E-reviewed.

DPA for AI vendors: what to actually check before you sign


> **TL;DR.** Most buyers of AI tools sit in the deployer role under the EU AI Act. The high-risk obligations are set to be postponed to 2027-12-02 under the Digital Omnibus, a political agreement reached on 7 May 2026 that is still pending formal adoption (expected before 2 August 2026; it takes legal effect only on publication in the Official Journal). The provider transparency obligations, the GPAI obligations on the model maker, and the prohibited-use rules are already in force. Deployer-side obligations turn on the use case, not the vendor: buying Copilot does not exempt the buyer from running their own deployer assessment.

## The four roles and where buyers usually land

The Act assigns obligations by role. The same vendor can be a provider in one transaction and a deployer in another, so the role is a per-deployment classification.

- **Provider.** Develops the AI system and places it on the EU market or puts it into service under its own name. OpenAI, Anthropic, Google, Microsoft, Perplexity, and ElevenLabs all sit here for their respective products.
- **Deployer.** Uses an AI system under its own authority in the course of professional activity. This is almost every business buyer.
- **Importer / Distributor.** Brings the system into the EU market or makes it available without modifying it. Resellers and integrators frequently land here.
- **Affected person.** The natural person the AI system's output is used on. Not an obligation-bearer but a rights-holder.

A UK company using ChatGPT Enterprise to triage applicant CVs is a deployer of a high-risk AI system (the use case is hiring, not the tool itself), even though OpenAI is the provider. A UK company using ChatGPT Enterprise to draft marketing emails is a deployer of a non-high-risk use case. Same vendor, same product, different obligations.

## The risk tiers and what each one means

The Act stacks obligations by risk tier, with prohibited uses at the top and minimal-risk uses at the bottom.

### Prohibited uses (Article 5, in force 2025-02-02)

Eight categories of AI use are banned outright in the EU: subliminal manipulation causing harm, exploitation of vulnerabilities, social scoring by public authorities, predictive policing based purely on profiling, untargeted facial-image scraping, emotion inference in workplace or education (with narrow safety carve-outs), biometric categorisation by protected characteristic, and real-time remote biometric identification in public spaces (with narrow law-enforcement carve-outs).

Buyers should treat the prohibited list as a hard procurement gate. A vendor whose product is sold for any of the eight should not enter the procurement pipeline.

### High-risk systems (Annex III, deployer obligations postponed to 2027-12-02)

Annex III lists eight high-risk use case categories:

1. Biometrics
2. Critical infrastructure
3. Education and vocational training
4. Employment, worker management, access to self-employment
5. Access to and enjoyment of essential private services and public services
6. Law enforcement
7. Migration, asylum, border control
8. Administration of justice and democratic processes

The 2027-12-02 postponement was provisionally agreed on 7 May 2026 and is pending formal adoption (expected before 2 August 2026). It takes legal effect only on publication in the Official Journal; until then, 2 August 2026 remains the live compliance date on the statute books, so a deployer planning around the later date is planning around an agreement that is not yet law. The postponement does not eliminate the obligations. It moves the high-risk deployer-side requirements (data governance, human oversight, technical documentation, post-market monitoring, FRIA where applicable) to 2027-12-02. The provider-side high-risk obligations also moved, but providers placing high-risk systems on the EU market before that date still face the future obligations and most are designing in advance.

Buyers should still classify any in-scope deployment now. The transition window is the cheapest time to build the controls; trying to retrofit them in November 2027 is the expensive path.

### General-purpose AI (GPAI) obligations (in force 2025-08-02)

GPAI provider obligations (technical documentation, copyright policy, training-data summary) and the additional obligations for GPAI with systemic risk (model evaluations, adversarial testing, incident reporting) sit on the model maker, not on the buyer. The buyer's interest in the GPAI obligations is indirect: the documentation the GPAI provider publishes is part of what the deployer needs to satisfy its own information obligations downstream.

### Transparency obligations (in force 2026-08-02)

Three transparency duties land on providers and deployers in parallel:

- AI systems interacting with natural persons have to disclose they are AI (deployer-facing obligation in many B2C deployments).
- Synthetic audio, image, video, or text output has to be marked as artificially generated where possible (provider obligation).
- Deepfakes have to be labelled (deployer obligation).
- Emotion recognition and biometric categorisation systems have to inform the natural person (deployer obligation).

Buyers running customer-facing chatbots, AI-generated voiceovers, or AI-generated marketing imagery should map their deployments against these now.

### Minimal-risk systems

Everything else. No specific obligations under the Act, though the buyer's own GDPR, sector-specific, and product-liability obligations continue to apply.

## What a deployer assessment actually contains

A deployer-side assessment is the artifact the buyer's compliance owner needs on file before the deployment goes live. It is not a vendor questionnaire — the vendor cannot make this assessment for the buyer.

1. **Use case description.** What the staff or app will actually do with the AI system, in plain language.
2. **Risk tier classification.** Is the use case prohibited (Article 5), high-risk (Annex III), GPAI-with-systemic-risk-adjacent, transparency-tier, or minimal-risk?
3. **Provider documentation collected.** GPAI summary, system documentation, any provider-side risk assessment the vendor publishes.
4. **Data governance.** Quality and representativeness of input data, any pre-processing, any human review checkpoints.
5. **Human oversight design.** Who reviews outputs, with what authority to override or stop the system, on what cadence.
6. **Logging and post-market monitoring plan.** What the deployment logs, who reviews the logs, on what cadence.
7. **Fundamental Rights Impact Assessment (FRIA) where required.** Annex III deployments in public administration or essential-service contexts trigger FRIA.
8. **Interaction with GDPR.** The Article 35 DPIA and the AI Act assessment are separate artifacts that often share evidence. Run them in parallel, do not collapse them into one document.

## Where the six vendors land on the buyer-side read

| Vendor | Provider role (EU) | Buyer-side note | Profile |
|---|---|---|---|
| OpenAI | GPAI provider; system provider for ChatGPT products | Most ChatGPT-API deployments are deployer-side non-high-risk; HR or education use cases bring high-risk obligations onto the buyer | [OpenAI](/vendors/openai) |
| Anthropic | GPAI provider; system provider for Claude products | Same deployer-side pattern as OpenAI; consumer claude.ai use needs its own deployer policy because no enterprise contract covers it | [Anthropic](/vendors/anthropic) |
| Microsoft 365 Copilot | System provider (Microsoft); Anthropic and OpenAI are subprocessors | Tenant-bound default makes most office-productivity uses minimal-risk; HR Copilot agents move the deployment into high-risk Annex III territory | [Microsoft 365 Copilot](/vendors/microsoft-365-copilot) |
| Google Gemini (Workspace) | GPAI provider; system provider for Workspace Gemini | Workspace defaults push retention to the buyer's environment, which simplifies the deployer-side logging obligation | [Google Gemini](/vendors/google-gemini) |
| Perplexity | System provider for Perplexity products | Search-with-citations use cases sit minimal-risk; regulated-industry deployments require Enterprise tier and a deployer assessment | [Perplexity](/vendors/perplexity) |

ElevenLabs sits separately because voice synthesis triggers the Article 50(4) deepfake labelling obligation on most public-facing uses. The [ElevenLabs profile](/vendors/elevenlabs) covers the deployer-side specifics.

## The procurement workflow under the Act

The version below assumes a UK / EU buyer with a procurement gate and a DPO or compliance owner.

1. **Map the use case.** Annex III? Transparency-tier? Minimal-risk? The vendor cannot answer this — only the buyer's description of what staff will do with the system answers it.
2. **Pull the provider's technical documentation.** GPAI model card or system documentation depending on the product. Note the version.
3. **Pull the DPA in parallel.** The DPA and the AI Act documentation answer different questions but both feed the procurement gate. See [DPA for AI vendors](/topics/dpa-for-ai-vendors).
4. **Decide on FRIA.** Public administration, essential services, and law enforcement contexts trigger FRIA. Most private-sector business deployments do not.
5. **Write the deployer assessment.** The eight-section structure above. Keep it short — 4-8 pages is realistic.
6. **Design the human oversight checkpoint.** Who reviews, with what override authority, on what cadence. Document the answer before go-live, not after.
7. **Set the post-market monitoring cadence.** Quarterly log review is the realistic floor for any deployment with personal data; monthly for any high-risk use case.

## The 2027-12-02 postponement is not a holiday

The deferral applies to the deployer-side high-risk obligations, not to:

- Prohibited uses (Article 5, in force since 2025-02-02)
- GPAI provider obligations (in force since 2025-08-02)
- Transparency obligations (in force 2026-08-02)
- The whole of GDPR, which continues regardless

Buyers running any of the three live tiers now should already have the matching controls in place. Buyers in Annex III territory have a 18-month window to design the controls properly; using the window is cheaper than the alternative.

## Related reading

- The contract-side compliance read: [DPA for AI vendors](/topics/dpa-for-ai-vendors)
- US healthcare angle on the same vendors: [HIPAA for AI tools](/topics/hipaa-for-ai-tools)
- Comparison on the most-common enterprise pairing: [Copilot 365 vs Google Workspace AI compliance](/compare/copilot-365-vs-google-workspace-ai-compliance)
- Comparison on the most-common API pairing: [OpenAI vs Anthropic DPA](/compare/openai-vs-anthropic-dpa)


Deployer-side guide to the EU AI Act for buyers procuring AI tools. Role classification, risk tier, the 2027-12-02 high-risk postponement, and where each major vendor sits. CIPP/E-reviewed.

EU AI Act for AI buyers: what you actually have to do


> **TL;DR.** HIPAA covers US protected health information (PHI), and the AI vendor only becomes a Business Associate when the deployment processes PHI on behalf of a Covered Entity or another Business Associate. OpenAI, Anthropic, Microsoft, and Google all sign BAAs on specific enterprise tiers; Perplexity Enterprise has an emerging position; consumer tiers and free products are never BAA-eligible. The BAA is necessary, not sufficient — the rest of the HIPAA Security Rule still has to land on the buyer's side.

## When HIPAA enters the AI procurement conversation

HIPAA (the US Health Insurance Portability and Accountability Act, as amended by HITECH) applies to:

- **Covered Entities (CEs):** health plans, healthcare clearinghouses, and most healthcare providers that transmit health information electronically
- **Business Associates (BAs):** any vendor that creates, receives, maintains, or transmits PHI on behalf of a Covered Entity
- **Subcontractors of BAs:** treated as Business Associates themselves under the Omnibus Rule

If the AI deployment will process PHI — meaning identifiable health information linked to a US Covered Entity — the AI vendor needs to sign a BAA before any PHI touches the system. Inputs that look benign (a transcribed clinical conversation, a summarised radiology report, a draft patient letter) can be PHI under the regulation, and HIPAA does not have a small-volume exemption.

Non-US healthcare buyers (NHS Trusts, EU public health bodies) do not have HIPAA exposure directly. They face the analogous obligations under their own jurisdictions (UK Data Protection Act 2018 plus NHS DSPT for the NHS; national health-data laws across the EU plus GDPR Article 9). HIPAA still matters indirectly when these buyers select a US-hosted AI vendor, because the BAA-eligible tier is usually the one with the strongest privacy controls overall.

## What a BAA actually requires

A Business Associate Agreement is a HIPAA-specific contract that obligates the BA to:

1. Use and disclose PHI only as the BAA permits
2. Implement Security Rule administrative, physical, and technical safeguards for electronic PHI
3. Report unauthorised use or disclosure to the Covered Entity
4. Make information available for individual access and amendment requests
5. Provide accountings of disclosure where required
6. Make BA records available to HHS for compliance audits
7. Return or destroy PHI at termination where feasible
8. Pass equivalent terms down to any subcontractor that touches PHI

A BAA does not, on its own, satisfy the Security Rule. The Covered Entity still has to do its own risk analysis, design its own administrative safeguards, train its own workforce, and document its own decisions. The BAA pins the BA's obligations down; the Security Rule pins the CE's down.

## Which AI vendors sign BAAs and on what tier

| Vendor | BAA-eligible tier | Consumer / free tier | Profile |
|---|---|---|---|
| OpenAI | Yes — ChatGPT Enterprise, ChatGPT Edu, OpenAI API on Enterprise agreement, certain Microsoft Azure OpenAI deployments | No — ChatGPT free, Plus, Team without explicit BAA addendum | [OpenAI](/vendors/openai) |
| Anthropic | Yes — Claude Enterprise and Claude API on Enterprise agreement; sales-channel approval required | No — claude.ai free, Pro, Max | [Anthropic](/vendors/anthropic) |
| Microsoft 365 Copilot | Yes — Microsoft signs BAAs for in-scope Microsoft 365 and Azure services; Copilot inherits this where in-scope | No — consumer Microsoft accounts | [Microsoft 365 Copilot](/vendors/microsoft-365-copilot) |
| Google Gemini (Workspace) | Yes — Google Workspace BAA covers Workspace Gemini for Healthcare and Life Sciences customers on eligible plans | No — consumer Gemini, free Workspace | [Google Gemini](/vendors/google-gemini) |
| Perplexity | Emerging — Perplexity Enterprise has been pursuing BAA-readiness; confirm current status with sales | No — free Perplexity, Perplexity Pro | [Perplexity](/vendors/perplexity) |
| ElevenLabs | Enterprise tier only — voice synthesis from PHI requires Enterprise contract and BAA; the consumer and creator tiers are not BAA-eligible | No — creator, starter, pro consumer tiers | [ElevenLabs](/vendors/elevenlabs) |

The pattern across the six: the BAA lives on the enterprise tier, gated by sales-channel approval. Anyone using the free or consumer product with PHI is creating a HIPAA breach risk that no later contracting can retroactively cure.

## What the BAA does not cover

The BAA addresses the contractual relationship. The buyer still owns:

### 1. The Security Rule risk analysis

Required by 45 CFR § 164.308(a)(1)(ii)(A). The Covered Entity has to conduct an accurate and thorough assessment of the potential risks and vulnerabilities to the confidentiality, integrity, and availability of electronic PHI. Adding an AI vendor to the workflow is a material change that triggers a fresh risk analysis, not an addendum to an old one.

### 2. The minimum-necessary rule

45 CFR § 164.502(b). The CE has to limit use and disclosure of PHI to the minimum necessary for the intended purpose. AI deployments tend to ingest more than needed by default — a clinical summarisation tool pointed at a full chart processes far more PHI than a tool that summarises only the consult note. Tightening the input set is a buyer-side design decision.

### 3. Workforce training

45 CFR § 164.308(a)(5). Workforce members have to be trained on the CE's policies and procedures with respect to PHI. Adding an AI tool to clinical workflow triggers training on the new policy, not just a software rollout.

### 4. Audit controls

45 CFR § 164.312(b). The CE has to record and examine activity in systems that contain or use electronic PHI. The AI vendor's logging is part of the picture; the CE's own audit policy is the rest.

### 5. Breach notification

45 CFR §§ 164.400-414. The CE owes 60-day notification on breaches affecting more than 500 individuals. AI-vendor breach affecting PHI on behalf of the CE flows up through the BA's breach notification to the CE, then out from the CE under the CE's own obligation.

### 6. State law

HIPAA preempts contrary state law only where state law is less protective. State laws on health information (Texas HB 300, California CMIA, New York SHIELD Act, Illinois BIPA for biometrics) often impose stricter obligations than HIPAA. The BAA does not address state-law exposure at all.

## The HIPAA procurement checklist for AI tools

The checklist below assumes a US Covered Entity buying an AI tool that will process PHI.

1. **Confirm BAA eligibility on the specific product and tier.** The marketing site rarely covers tier-by-tier eligibility; the sales channel is the reliable source.
2. **Execute the BAA before any PHI enters the system.** Pilots, demos, and proof-of-concept work on real PHI without a BAA are technical breaches.
3. **Run a fresh Security Rule risk analysis covering the AI workflow.** Existing risk analyses pre-AI rarely cover the new threat surface.
4. **Apply minimum-necessary on the input side.** Decide what PHI elements the deployment actually needs and prevent the rest from reaching the vendor.
5. **Document the human oversight checkpoint.** Clinician review of AI output for any clinical-decision-supporting deployment is the realistic floor.
6. **Train workforce on the new policy.** Software training and HIPAA policy training are different artifacts and both need to land.
7. **Set audit cadence.** Who reviews vendor logs, on what cadence, with what escalation path.
8. **Document state-law exposure.** Texas, California, New York, Illinois, and other states with stricter health-information regimes need their own line items.

## The non-US healthcare angle

UK and EU healthcare buyers do not face HIPAA directly but face analogous obligations:

- **UK:** Data Protection Act 2018 plus UK GDPR plus the NHS Data Security and Protection Toolkit (DSPT) for any NHS-touching deployment. The Caldicott principles apply on top.
- **EU:** GDPR Article 9 (special-category data) plus national health-data laws. France's LPM/SNDS regime, Germany's SGB V framework, and the Health Data Hub in France each add jurisdiction-specific requirements.

The BAA does not satisfy any of these. UK and EU buyers should run their AI vendor reviews under the matching local regime, not against the HIPAA structure.

## Related reading

- The general processor-contract read: [DPA for AI vendors](/topics/dpa-for-ai-vendors)
- The EU buyer-side read: [EU AI Act for AI buyers](/topics/eu-ai-act-for-ai-buyers)
- For US healthcare-adjacent enterprise tooling: [Copilot 365 vs Google Workspace AI compliance](/compare/copilot-365-vs-google-workspace-ai-compliance)
- For US healthcare research and clinical-summarisation workflows: [Perplexity vs ChatGPT for regulated industries](/compare/perplexity-vs-chatgpt-regulated-industries)


Healthcare buyers reading the HIPAA position on AI vendors. Which vendors sign BAAs, on which tiers, and what the BAA does and does not cover for AI deployments. CIPP/E-reviewed.

Topic guides

DPA for AI vendors: what to actually check before you sign

EU AI Act for AI buyers: what you actually have to do

HIPAA for AI tools: what a Business Associate Agreement actually covers