
> **TL;DR.** Both products are tenant-bound enterprise AI: customer data stays in the buyer's existing Microsoft 365 or Google Workspace tenant by default, no training on customer content, BAA available on healthcare plans. The compliance picture diverges on subprocessor depth (Copilot added Anthropic as a subprocessor in January 2026 and that route is out of EU Data Boundary scope), EU Data Boundary maturity (Microsoft has the more developed published scope), and the AI Act deployer angle for HR-adjacent Copilot Agents.

## How the two compare

The full read for each lives in the [Microsoft 365 Copilot profile](/vendors/microsoft-365-copilot) and the [Google Gemini profile](/vendors/google-gemini). The eight-clause DPA hub structure sits at [DPA for AI vendors](/topics/dpa-for-ai-vendors).

### 1. Tenant model and data residency

| | Microsoft 365 Copilot | Google Workspace Gemini |
|---|---|---|
| Default location of customer content | Buyer's Microsoft 365 tenant | Buyer's Google Workspace tenant |
| Default retention of AI interactions | Tenant-controlled (lives in the buyer's M365 substrate) | Tenant-controlled (lives in the buyer's Workspace storage) |
| Data residency commitment | EU Data Boundary scope on Enterprise plans; specific Copilot routes have carve-outs | Workspace data residency available on Enterprise Plus; Gemini-for-Workspace inherits |
| Tenant-bound default applies to | Microsoft-hosted Copilot features | Google-hosted Gemini-for-Workspace features |

Both are tenant-bound by default. The buyer's compliance posture for the underlying M365 or Workspace tenant largely flows through to the AI feature; the AI feature does not relocate the data.

### 2. Training default on customer content

| | Microsoft 365 Copilot | Google Workspace Gemini |
|---|---|---|
| Use of customer content to train base models | No | No |
| Use of prompts and responses to improve the AI feature | No (commercial tier) | No (commercial tier) |
| Per-tenant fine-tuning available | Limited in M365 Copilot; broader in Azure OpenAI for custom builds | Available on Gemini for Workspace Enterprise; tenant-scoped |
| Contract location | M365 Services Terms + DPA; Microsoft Products and Services DPA | Workspace Customer Agreement + Cloud Data Processing Addendum |

The commercial default at both is protective. The Azure OpenAI and Gemini-Enterprise fine-tuning routes are tenant-scoped, so the customer's training data does not enrich another tenant's model.

### 3. Subprocessor depth and the Anthropic / OpenAI question

| | Microsoft 365 Copilot | Google Workspace Gemini |
|---|---|---|
| Underlying model provider | OpenAI (primary); Anthropic added 2026-01-07 | Google (Gemini family) |
| Foundation model providers as subprocessors | OpenAI and Anthropic both appear on the M365 Copilot subprocessor list | Google models are first-party; no external foundation-model subprocessor |
| EU Data Boundary scope of the Anthropic route | Explicitly out of scope as of 2026-01-07 | N/A |
| Cloud subprocessor | Microsoft Azure (first-party) | Google Cloud (first-party) |

This is the cleanest point of divergence. M365 Copilot's January 2026 subprocessor expansion brings Anthropic into the buyer's data-flow diagram, and Microsoft has been explicit that the Anthropic route is outside the EU Data Boundary commitment. Buyers who chose Copilot in part because of the EU Data Boundary need to read the carve-outs and decide whether the Anthropic-routed features are acceptable, or whether the tenant should disable those features.

Google Workspace Gemini avoids the question because the underlying models are Google's own, and the cloud is Google Cloud. Subprocessor depth is shallower, which simplifies the buyer-side documentation.

### 4. EU/UK transfer mechanism

| | Microsoft 365 Copilot | Google Workspace Gemini |
|---|---|---|
| SCC version | 2021 Module 2 | 2021 Module 2 |
| UK Addendum | Yes | Yes |
| EU Data Boundary commitment | Published, with named carve-outs (including the Anthropic-routed Copilot features) | EU data residency on Enterprise Plus; no equivalent "Data Boundary" branding |
| Region-locked enterprise option | Microsoft Cloud for Sovereignty for higher-assurance buyers | Sovereign Workloads / Assured Workloads for higher-assurance buyers |

Microsoft has the more developed published Data Boundary; Google has the equivalent functionality with less public marketing around it. For buyers in regulated industries (financial services, healthcare, public sector), the sovereign-cloud options at both vendors are the realistic answer rather than the standard Enterprise tier.

### 5. HIPAA BAA

| | Microsoft 365 Copilot | Google Workspace Gemini |
|---|---|---|
| BAA available | Yes — Microsoft signs BAAs for in-scope M365 and Azure services; Copilot inherits where in-scope | Yes — Google Workspace BAA covers Workspace Gemini for Healthcare and Life Sciences customers on eligible plans |
| Tier required | Enterprise (specific plans) | Enterprise (specific plans) |
| Consumer / SMB tier eligibility | No | No |

Both sign BAAs on the enterprise tier. The procurement workflow is the same on both sides: confirm tier eligibility with the sales channel, execute the BAA before any PHI enters the system, run a fresh Security Rule risk analysis. See the [HIPAA hub](/topics/hipaa-for-ai-tools) for the full checklist.

### 6. AI Act deployer obligations

Both vendors are GPAI providers under the EU AI Act. The deployer-side obligations land on the buyer regardless of which vendor they pick. The use-case classification matters more than the vendor:

- A Copilot or Workspace Gemini deployment used for general office productivity (drafting emails, summarising meetings, finding documents) sits in minimal-risk or transparency territory.
- A Copilot Agent or Workspace integration used in HR (CV screening, performance scoring, promotion decisions) brings the deployment into Annex III high-risk territory under either vendor. Deployer obligations land on the buyer.
- A Copilot Agent built on top of M365 data that performs decisions affecting access to essential services (banking, insurance, public services) is high-risk under both vendors.

The [EU AI Act hub](/topics/eu-ai-act-for-ai-buyers) covers the deployer assessment in full.

### 7. The Copilot Agents and Workspace integration angle

Copilot Studio and Google Workspace's AppSheet / Gemini-for-Workspace integration layer both let the buyer build custom agents on top of tenant data. This is where the AI Act exposure can climb fast:

- The agent's use case determines the AI Act risk tier, not the underlying platform.
- The custom data sources the agent connects to may expand the personal-data footprint beyond what the standard tenant DPA covers.
- Logging and human oversight controls become design-time buyer decisions, not vendor-default settings.

Buyers building agents on either platform should run the deployer assessment on the agent, not on Copilot or Gemini in general.

## Picking between them

**Pick Copilot when:**

- The buyer is already on Microsoft 365 and the procurement gate values the published EU Data Boundary documentation
- The buyer needs the broader Microsoft Purview, Sensitivity Labels, and Conditional Access integration for DLP-driven controls on the AI surface
- The use case is HR-adjacent and the buyer wants Microsoft's Responsible AI Standard documentation as part of the deployer evidence base

**Pick Workspace Gemini when:**

- The buyer is already on Google Workspace and a fully first-party model stack is preferable (no Anthropic-style subprocessor question)
- The buyer prefers the shallower subprocessor depth for simpler Transfer Impact Assessment documentation
- The buyer's developer workflows use Google Cloud / Vertex AI as the production AI surface and Workspace Gemini is the office-productivity layer above

**Consider Cloud for Sovereignty or Assured Workloads when:**

- The buyer sits in financial services, public sector, or healthcare with sovereign-cloud requirements
- The standard EU Data Boundary or Workspace data residency is not enough on its own to clear the procurement gate

## The agents question changes the answer

If the buyer's actual deployment plan is "build Copilot Agents" or "build Workspace integrations" rather than "use the off-the-shelf AI feature," the vendor selection question is downstream of the AI Act deployer assessment for the agent itself. Run that assessment first.

## Related reading

- The eight DPA clauses both vendors are scored against: [DPA for AI vendors](/topics/dpa-for-ai-vendors)
- The deployer-side AI Act read: [EU AI Act for AI buyers](/topics/eu-ai-act-for-ai-buyers)
- The healthcare-specific procurement checklist: [HIPAA for AI tools](/topics/hipaa-for-ai-tools)
- Cross-comparison: [OpenAI vs Copilot enterprise compliance](/compare/openai-vs-copilot-enterprise-compliance)
- Cross-comparison: [Gemini vs Vertex AI compliance](/compare/gemini-vs-vertex-ai-compliance)


Side-by-side compliance read on Microsoft 365 Copilot and Google Workspace Gemini for enterprise procurement. Tenant model, training defaults, EU Data Boundary, BAA, AI Act deployer obligations. CIPP/E-reviewed.

Copilot 365 vs Google Workspace AI: compliance comparison for enterprise buyers


> **TL;DR.** ElevenLabs sits at the front of the voice synthesis category and has the most developed published voice-clone consent regime. The category-wide compliance picture turns on three buyer-side controls regardless of vendor: documented consent from any natural person whose voice is cloned, deepfake labelling under EU AI Act Article 50(4), and tier discipline (Enterprise contract for any deployment touching personal data). The hyperscaler voice products (OpenAI Voice, Azure Speech, Google Cloud TTS) integrate more easily into existing Microsoft or Google compliance frameworks.

## The voice AI compliance frame

Voice AI splits into three buyer scenarios with materially different compliance pictures:

1. **Synthetic voice generation from text** (text-to-speech with stock voices). Lower compliance load. Subject to EU AI Act deepfake labelling on most public-facing deployments.
2. **Voice cloning from a sample of a real person's voice.** High compliance load. Triggers consent obligations under GDPR Article 6 and 9 (voice is biometric data when used to identify a person), defamation and IP exposure, and EU AI Act deepfake obligations.
3. **Speech-to-text transcription.** Different vendor category (Whisper, Azure Speech-to-Text, Google Speech-to-Text). Compliance load is the standard processor analysis under the DPA.

This comparison addresses scenarios 1 and 2. The full ElevenLabs read is at the [ElevenLabs profile](/vendors/elevenlabs).

### 1. The consent regime for voice cloning

| | ElevenLabs | Hyperscaler voice (OpenAI / Azure / Google) |
|---|---|---|
| Voice-clone product available | Yes — Instant Voice Cloning, Professional Voice Cloning | OpenAI Voice (custom voice in preview / limited release); Azure Custom Neural Voice (gated); Google Custom Voice (gated) |
| Consent verification process | Voice-likeness verification statement; ID and voice match steps on Professional cloning | Identity verification + license terms; gated commercial release |
| Vendor enforcement against unauthorised cloning | Watermarking, classifier-based detection, DMCA-style takedown | Restricted release; contractual prohibition; takedown processes |
| Documented buyer obligation | Buyer warrants the voice owner has consented | Buyer warrants the voice owner has consented |

The voice-clone consent picture is broadly aligned across vendors — every credible vendor has a "buyer is responsible for consent" warranty in the terms. ElevenLabs has the most public-facing consent verification process; the hyperscalers gate voice cloning behind manual approval which serves a similar function.

The compliance gap is on the buyer side, not the vendor side. A buyer who clones a voice without documented consent has a defensible vendor contract and an undefendable position under GDPR, defamation law, and (where applicable) right-of-publicity statutes.

### 2. Deepfake labelling under the EU AI Act

EU AI Act Article 50(4) lands on deployers of AI systems that generate or manipulate audio constituting a deepfake. The obligation is to disclose that the content is artificially generated or manipulated.

| | ElevenLabs | Hyperscaler voice |
|---|---|---|
| Underlying technology subject to Article 50(4) | Yes — voice cloning produces deepfake-class output | Yes — custom voice products produce deepfake-class output |
| Vendor-provided watermarking / provenance signal | Audio watermarking + classifier | C2PA support on some Microsoft surfaces; provenance signals on Google Cloud output |
| Buyer-side disclosure obligation | Yes, on deployer of public-facing audio | Yes, on deployer of public-facing audio |
| Exceptions | Narrow — artistic, satirical, or fictional work with clear context | Narrow — same |

The buyer-side disclosure obligation lands the same way regardless of vendor. A UK ad agency using ElevenLabs to generate a brand voiceover for a public campaign and a UK ad agency using Azure Custom Neural Voice for the same campaign both owe the deepfake disclosure. Vendor selection does not change the obligation.

### 3. Training defaults and customer-data use

| | ElevenLabs Enterprise / API | OpenAI Voice (Enterprise / Azure OpenAI) | Azure Speech Custom Neural Voice | Google Cloud TTS Custom Voice |
|---|---|---|---|---|
| Vendor uses cloned voices to train shared models | No (Enterprise tier) | No (Enterprise / Azure OpenAI) | No (tenant-scoped) | No (tenant-scoped) |
| Vendor uses prompts / inputs to improve service | No (Enterprise tier) | No (Enterprise tier) | No | No |
| Vendor uses non-personal usage data for service improvement | Yes, aggregated | Yes, aggregated | Yes, aggregated | Yes, aggregated |
| Customer voice clone reusable by other customers | No | No | No | No |

The Enterprise / commercial default at every credible voice AI vendor is protective. Consumer and free-tier defaults are not, and a deployment that touches personal data under any of these consumer tiers is exposed.

### 4. BAA position for US healthcare voice work

| | ElevenLabs | OpenAI Voice | Azure Speech | Google Cloud TTS |
|---|---|---|---|---|
| BAA available | Enterprise tier only — sales-channel approval | Yes — Enterprise tier and Azure OpenAI route | Yes — Microsoft signs BAAs for in-scope Azure services | Yes — Google Cloud BAA covers eligible services |
| Consumer tier eligibility | No | No | N/A (no consumer tier) | N/A (no consumer tier) |

For US healthcare voice work (clinical narration, patient-facing voice assistants, audio-summarisation of clinical notes), the BAA gate is the procurement floor. Consumer or creator tiers of any voice AI vendor are not BAA-eligible. See the [HIPAA hub](/topics/hipaa-for-ai-tools) for the full checklist.

### 5. Subprocessor depth

| | ElevenLabs | Hyperscaler voice |
|---|---|---|
| Cloud subprocessor | Multi-cloud (AWS, Google Cloud) | First-party (Microsoft Azure or Google Cloud respectively) |
| Foundation model provenance | ElevenLabs first-party | OpenAI / Microsoft / Google first-party |
| TIA documentation depth | Multi-cloud means more providers to document | Shorter data flow; fewer providers |

The Transfer Impact Assessment is shorter for the hyperscaler voice products simply because the cloud and the model maker are the same vendor. ElevenLabs's multi-cloud stack is more complex to document but allows buyers to choose region commitments through the underlying cloud.

### 6. EU/UK transfer mechanism

All credible vendors in scope publish 2021 SCCs Module 2 with the UK Addendum. Region commitments vary:

- ElevenLabs: EU region availability on Enterprise; confirm with sales channel for region-locked deployment
- OpenAI: Region-locked deployment available via Azure OpenAI; EU residency on certain Enterprise plans
- Azure Speech: EU region available; EU Data Boundary applies on in-scope services
- Google Cloud TTS: EU region available; Workspace data residency or Google Cloud region pinning

## Picking between them

**Pick ElevenLabs Enterprise when:**

- The use case is creator workflow, brand voice production, audiobook narration, podcast post-production, or accessibility narration
- The voice cloning consent regime needs to surface a verifiable consent artifact (the ElevenLabs Professional Voice Cloning verification flow)
- The buyer values the public watermarking / classifier story for downstream provenance signalling

**Pick a hyperscaler voice product when:**

- The buyer is already on Azure or Google Cloud and the procurement gate values single-vendor data-flow simplicity
- The use case is enterprise voice (IVR, customer support, internal voice assistants) where the integration into existing Microsoft or Google infrastructure outweighs voice quality differences
- HIPAA BAA, EU Data Boundary, or sovereign-cloud commitments are part of the procurement gate and the hyperscaler's broader framework simplifies the audit

**The deepfake disclosure obligation lands the same way regardless.** Vendor selection does not move that obligation.

## The voice-clone-without-consent failure mode

The biggest compliance failure in voice AI is not vendor selection. It is using a voice-clone product to clone a real person's voice without documented consent.

The downstream consequences include GDPR Article 6 / 9 exposure (no lawful basis for processing biometric voice data), defamation and right-of-publicity claims, contract breach of the vendor's own terms (which the buyer warranted compliance with), and reputational damage that survives any later contractual remediation.

The buyer-side control is procedural: any voice-clone deployment has to include a documented consent artifact from the natural person whose voice is cloned, refreshed when the use case changes, and revocable on request. The vendor cannot make this happen for the buyer.

## Related reading

- The DPA hub: [DPA for AI vendors](/topics/dpa-for-ai-vendors)
- The deployer-side AI Act read covering deepfake labelling: [EU AI Act for AI buyers](/topics/eu-ai-act-for-ai-buyers)
- For US healthcare voice work: [HIPAA for AI tools](/topics/hipaa-for-ai-tools)
- Cross-comparison: [OpenAI vs Anthropic DPA](/compare/openai-vs-anthropic-dpa) (for the underlying foundation model picture if voice runs on top of a general-purpose model)


Buyer-side compliance comparison of ElevenLabs against the broader voice AI category. DPA, voice-clone consent regime, deepfake labelling under the EU AI Act, training defaults, BAA position. CIPP/E-reviewed.

ElevenLabs vs other voice AI vendors: DPA comparison for compliance buyers


> **TL;DR.** Workspace Gemini and Vertex AI both run on Google's Gemini model family, but the compliance pictures diverge sharply. Workspace Gemini is a tenant-bound office-productivity feature inside an existing Google Workspace contract. Vertex AI is a Google Cloud developer platform with granular region selection, customer-managed encryption keys, BAA on eligible services, and a Model Garden that includes Anthropic, Meta, Mistral, and other third-party models as subprocessors. Workspace Gemini fits office productivity; Vertex AI fits product builds and regulated workflows.

## The two surfaces

The shared underlying technology is Google's Gemini model family. The product wrapper, contract, and compliance surface around it differs.

The Workspace Gemini read sits at the [Google Gemini profile](/vendors/google-gemini). Vertex AI does not yet have its own CompanyScope profile; the comparison below covers the buyer-side compliance read.

### Workspace Gemini

- Bundled into Google Workspace plans (Business Standard, Business Plus, Enterprise Standard, Enterprise Plus)
- Operates inside the buyer's existing Workspace tenant
- Customer data lives in the buyer's Workspace storage
- Contract is the Workspace Customer Agreement plus the Cloud Data Processing Addendum

### Vertex AI

- A Google Cloud product the buyer subscribes to separately
- Operates inside the buyer's Google Cloud project, with project-scoped IAM and VPC controls
- Customer data lives in Google Cloud Storage, BigQuery, or wherever the buyer pipes it
- Contract is the Google Cloud Master Services Agreement plus the Cloud Data Processing Addendum, with the Vertex AI service-specific terms layered on

## How the two compare

### 1. Tenant model and where customer data sits

| | Workspace Gemini | Vertex AI |
|---|---|---|
| Data location | Buyer's Workspace tenant (mail, drive, chat, meet, docs) | Buyer's Google Cloud project; explicit region selection |
| Region selection | Workspace data residency on eligible plans | Per-service region selection at the resource level |
| Customer-managed encryption keys (CMEK) | Available on Enterprise Plus for in-scope services | Available on most Vertex AI services |
| VPC Service Controls | Workspace integration limited | Yes — VPC SC perimeter applicable to Vertex AI |

Vertex AI provides the granular controls regulated buyers usually need (CMEK, VPC SC, region pinning at the resource level). Workspace Gemini provides the simpler office-productivity wrapper that does not need them for most deployments.

### 2. Training default and the Model Garden question

| | Workspace Gemini | Vertex AI |
|---|---|---|
| Use of customer content to train Google base models | No | No |
| Tenant-scoped fine-tuning | Limited | Available — Vertex AI Tuning, customer-scoped |
| Third-party models available | N/A | Yes — Model Garden hosts Anthropic Claude, Meta Llama, Mistral, and others |
| Third-party model use of customer content | N/A | Governed by Vertex AI's contract; the third-party model provider does not separately receive customer data |
| Buyer responsibility for third-party model choice | N/A | Yes — Model Garden picks add the third-party model provider as a subprocessor under Vertex AI's terms |

The Model Garden is the structural Vertex AI difference. A buyer who picks Claude or Llama through Vertex AI gets that model under Vertex AI's contract, not directly from Anthropic or Meta. The third-party model provider sits as a subprocessor under Vertex AI's DPA, which simplifies the buyer's contracting but expands the subprocessor list.

### 3. HIPAA BAA position

| | Workspace Gemini | Vertex AI |
|---|---|---|
| BAA available | Yes — Google Workspace BAA covers Workspace Gemini for Healthcare and Life Sciences customers on eligible plans | Yes — Google Cloud BAA covers in-scope Vertex AI services |
| Tier required | Eligible Workspace plan | Google Cloud project with BAA executed |
| Consumer / free tier | No BAA | No BAA |
| Eligible services | Specific Workspace Gemini features in scope | Specific Vertex AI services in scope; not all Model Garden models are HIPAA-eligible — confirm by service |

The Model Garden BAA picture needs the buyer to confirm by service. A third-party model offered through Vertex AI may or may not be in HIPAA scope depending on the underlying provider's own posture. The Vertex AI sales channel is the reliable source.

### 4. EU/UK transfer mechanism

| | Workspace Gemini | Vertex AI |
|---|---|---|
| SCC version | 2021 Module 2 | 2021 Module 2 |
| UK Addendum | Yes | Yes |
| Region commitment | Workspace data residency on Enterprise Plus | Per-resource region pinning at deployment time |
| Sovereign cloud option | N/A within Workspace | Assured Workloads for regulated and public-sector buyers |
| TIA depth required | Standard | Higher — Model Garden picks expand the subprocessor diagram |

### 5. AI Act deployer-side read

Both products are GPAI provider deployments under the EU AI Act when Google is the vendor. The deployer obligations land on the buyer based on use case:

- Workspace Gemini for office productivity (drafting emails, summarising meetings, document search) sits minimal-risk or transparency-tier.
- Vertex AI used to build a customer-facing chatbot, an automated screening tool, or a clinical decision-support feature can put the buyer into Annex III high-risk territory.
- Vertex AI Model Garden picks that include Anthropic or Meta GPAI models inherit those models' GPAI documentation; the buyer's deployer assessment uses the documentation Vertex AI publishes plus the model provider's published material.

See the [EU AI Act hub](/topics/eu-ai-act-for-ai-buyers) for the deployer assessment workflow.

### 6. Subprocessor depth

| | Workspace Gemini | Vertex AI |
|---|---|---|
| Foundation model provider | Google (first-party) | Google + optional third-party models from the Model Garden (Anthropic, Meta, Mistral, others) |
| Cloud subprocessor | Google Cloud (first-party) | Google Cloud (first-party) |
| Third-party connector ecosystem | Workspace add-ons (controlled at tenant) | Vertex AI Extensions, Agent Builder integrations |
| TIA documentation depth | Shorter | Longer — list every Model Garden model the buyer's app actually invokes |

## Picking between them

**Pick Workspace Gemini when:**

- The use case is office productivity inside an existing Google Workspace tenant
- The buyer wants tenant-bound defaults without additional Google Cloud subscription, project structure, or developer overhead
- The compliance frame is minimal-risk or transparency-tier under the AI Act

**Pick Vertex AI when:**

- The buyer is building a product, an internal tool, or a regulated-industry workflow on top of Gemini or another model
- The deployment needs region pinning, CMEK, VPC Service Controls, or sovereign-cloud assurance
- The HIPAA BAA scope needs to be controlled at the Google Cloud project level, with the buyer choosing which services are in scope
- The buyer wants the Model Garden choice (Claude, Llama, Mistral) under one Google Cloud contract rather than direct vendor contracts

**Run them in parallel when:**

- Workspace Gemini covers the office-productivity layer for staff
- Vertex AI covers the production AI surface the buyer ships to customers or uses in regulated workflows
- The compliance owner manages two distinct deployer assessments because the use cases differ

## The Model Garden expands the subprocessor map

The single biggest compliance-side consideration when picking Vertex AI is the Model Garden subprocessor expansion. Each third-party model the buyer's app invokes is a subprocessor under Vertex AI's contract. The Transfer Impact Assessment needs to list them; the AI Act deployer assessment needs to reference each model provider's GPAI documentation; the HIPAA BAA scope needs to confirm each model is in scope where PHI is involved.

This is manageable — Google handles the contracting upstream so the buyer does not need separate Anthropic or Meta contracts — but the buyer's documentation has to track the choices.

## Related reading

- The DPA hub: [DPA for AI vendors](/topics/dpa-for-ai-vendors)
- The AI Act deployer-side read: [EU AI Act for AI buyers](/topics/eu-ai-act-for-ai-buyers)
- The HIPAA-specific checklist: [HIPAA for AI tools](/topics/hipaa-for-ai-tools)
- Cross-comparison: [Copilot 365 vs Google Workspace AI compliance](/compare/copilot-365-vs-google-workspace-ai-compliance)
- Cross-comparison: [OpenAI vs Anthropic DPA](/compare/openai-vs-anthropic-dpa) (because Vertex AI Model Garden offers Anthropic models as well)


Two Google AI surfaces with materially different compliance pictures. Workspace Gemini for office productivity, Vertex AI for developers and integrations. Tenant model, region commitments, BAA, model-garden subprocessor exposure. CIPP/E-reviewed.

Gemini vs Vertex AI: compliance comparison for Google buyers


> **TL;DR.** Both vendors run protective commercial defaults: no training on customer data through the API and Enterprise tiers, ZDR available on approval. Anthropic edges OpenAI on the API retention default (7 days vs 30) and on the EU/UK transfer documentation depth. OpenAI edges Anthropic on enterprise tier maturity, BAA breadth, and the Azure OpenAI route for buyers already on Microsoft. Consumer-tier defaults at both vendors are not protective and need their own policy.

## How the two compare on the eight clauses that decide the risk

This comparison is the buyer's-side read against the eight DPA clauses set out in the [DPA for AI vendors](/topics/dpa-for-ai-vendors) hub. Full vendor-by-vendor detail lives in the [OpenAI profile](/vendors/openai) and the [Anthropic profile](/vendors/anthropic).

### 1. Commercial training default

| | OpenAI | Anthropic |
|---|---|---|
| API | No training on customer data by default | No training on customer data by default |
| Enterprise / Team | No training | No training |
| Contract location of commitment | DPA + Service Terms | DPA + Commercial Terms |
| How a buyer turns it on | Opt-in via account settings (uncommon) | Opt-in via account settings (uncommon) |

Both vendors are aligned. The clause is in the DPA, not buried in the marketing site, and the default favours the buyer.

### 2. Consumer training default

| | OpenAI | Anthropic |
|---|---|---|
| Free / consumer Plus | Opt-out (training default on; user has to disable) | Opt-in (training default off; user has to enable) since 2025-10-08 |
| Retention on consumer plans | Conversation history retention up to 30 days by default; longer with memory enabled | Up to 5 years for users who opted in to training |

The consumer-tier default is the area where the two vendors diverge most. Anthropic's flip to opt-in on 2025-10-08 made consumer claude.ai the more protective consumer default, though the 5-year retention horizon for opted-in users is longer than OpenAI's consumer retention. Neither default is good enough to support PHI, special-category GDPR data, or anything subject to a procurement gate.

### 3. API retention default

| | OpenAI | Anthropic |
|---|---|---|
| Default API retention | 30 days | **7 days** (dropped from 30 on 2025-09-14) |
| ZDR available | Yes, approval-gated | Yes, approval-gated |
| Time to ZDR approval (typical) | 1-3 weeks | 1-3 weeks |
| Carve-outs from ZDR | Abuse and safety monitoring exceptions | Abuse and safety monitoring exceptions |

Anthropic's 7-day default is the strongest commercial-tier retention default in the LLM market at the time of this review. Buyers who need shorter than 7 days still have to go through the ZDR approval process at both vendors.

### 4. Subprocessor depth

| | OpenAI | Anthropic |
|---|---|---|
| Published subprocessor list | Yes, updated on change | Yes, updated on change |
| Notice cadence on additions | 14-30 days | 30 days |
| Objection mechanism | Customer may object; vendor proposes alternative or contract termination right | Customer may object; vendor proposes alternative or contract termination right |
| Notable subprocessors at time of review | Microsoft Azure (training and inference); Cloudflare; Stripe; Snowflake | Amazon Web Services; Google Cloud; Cloudflare; Stripe |
| Cross-vendor subprocessor relationship | OpenAI runs on Azure infrastructure (Microsoft is the cloud) | Anthropic became a Microsoft 365 Copilot subprocessor on 2026-01-07 |

OpenAI's Azure relationship and Anthropic's appearance as a Copilot subprocessor mean that a buyer using OpenAI and Microsoft 365 Copilot is, in many cases, transacting with the same upstream cloud through different prime contracts. The implications for data-flow diagrams and Transfer Impact Assessments are worth pinning down explicitly.

### 5. EU/UK transfer mechanism

| | OpenAI | Anthropic |
|---|---|---|
| EU SCC version | 2021 Module 2 (Controller-to-Processor) | 2021 Module 2 (Controller-to-Processor) |
| UK Addendum | Yes | Yes |
| Transfer Impact Assessment | Vendor publishes supporting docs; buyer responsible for TIA | Vendor publishes supporting docs; buyer responsible for TIA |
| EU Data Boundary equivalent | EU data residency available on certain Enterprise plans | EU data residency available on Enterprise; the Microsoft 365 Copilot route is explicitly out of EU Data Boundary scope as of 2026-01-07 |
| Customer-data location commitment | Region-restricted on Azure OpenAI for buyers using that route | Multi-region; primarily US infrastructure for direct API |

Buyers needing strict EU-only processing should pull the most recent regional commitments directly from the sales channel rather than relying on the standard DPA. Both vendors offer the option; both gate it through Enterprise contracts.

### 6. Security commitments

| | OpenAI | Anthropic |
|---|---|---|
| SOC 2 Type II | Yes | Yes |
| ISO 27001 | Yes | Yes |
| ISO 27701 | Yes | In progress at time of review; confirm directly |
| ISO 42001 (AI management system) | Pursuing | Pursuing |
| HIPAA BAA available | Yes, on Enterprise / API Enterprise / Azure OpenAI | Yes, on Enterprise; sales-channel gated |
| GDPR Article 28 commitments | In DPA | In DPA |

Both vendors clear the realistic floor (SOC 2 + ISO 27001) and are pursuing the AI-specific ISO 42001. The HIPAA BAA picture matters for US healthcare buyers — see the [HIPAA hub](/topics/hipaa-for-ai-tools) for the procurement workflow.

### 7. Deletion and contract end

Both vendors commit to deletion or return of customer data at contract end. For buyers who fine-tuned a model on customer data, the practical question is whether deletion extends to the fine-tuned artifact. OpenAI's fine-tuning deletion language is explicit; Anthropic's enterprise tier handles this through bespoke commercial terms — confirm in writing if fine-tuning is in scope.

### 8. Breach notification

Both vendors commit to notification of a personal-data breach without undue delay, with 72 hours as the realistic floor. Both flow the notification through to the buyer's named DPO contact.

## Picking between them

The decision usually turns on two factors that sit outside the DPA itself.

**Pick OpenAI when:**

- The buyer is already on Azure and wants the Azure OpenAI route for region-locked deployment
- The buyer needs the breadth of HIPAA-eligible products (Enterprise, Edu, API on Enterprise, Azure OpenAI)
- The buyer's app stack is built against the OpenAI API surface

**Pick Anthropic when:**

- The buyer needs the shortest API retention default available without negotiating ZDR
- The buyer's procurement gate requires the consumer-tier default to be opt-in for training, not opt-out
- The buyer is already using Claude through the Claude API and wants to consolidate

**Consider both alongside each other when:**

- The buyer's deployment is a multi-model pipeline (common in legal, financial-services, and clinical-summarisation work)
- The buyer needs a fallback model provider for resilience and the two vendors run on different upstream cloud providers (Azure for OpenAI; AWS and GCP for Anthropic direct)

## The consumer-tier exposure is the trap

The single biggest procurement risk with either vendor is not the commercial DPA — both are protective. It is the consumer-tier exposure when staff use the free or personal product alongside the contracted enterprise one.

A staff member who pastes a draft procurement contract into free ChatGPT or free claude.ai is operating under that vendor's consumer default. The enterprise DPA does not apply. The buyer's procurement policy has to address this directly, either by blocking the consumer products at the network or by writing an explicit usage policy that staff have signed.

## Related reading

- The hub on the eight DPA clauses: [DPA for AI vendors](/topics/dpa-for-ai-vendors)
- The EU AI Act deployer-side read for both vendors: [EU AI Act for AI buyers](/topics/eu-ai-act-for-ai-buyers)
- The US healthcare-specific read: [HIPAA for AI tools](/topics/hipaa-for-ai-tools)
- Cross-comparison: [OpenAI vs Copilot enterprise compliance](/compare/openai-vs-copilot-enterprise-compliance)
- Cross-comparison: [Perplexity vs ChatGPT for regulated industries](/compare/perplexity-vs-chatgpt-regulated-industries)


Head-to-head DPA comparison between OpenAI and Anthropic for commercial API and enterprise buyers. Training defaults, retention, ZDR, subprocessors, EU transfers, consumer-tier exposure. CIPP/E-reviewed.

OpenAI vs Anthropic DPA: side-by-side compliance read for buyers


> **TL;DR.** ChatGPT Enterprise is a standalone OpenAI product with its own contract, DPA, and admin surface. Microsoft 365 Copilot is a feature inside an existing Microsoft 365 tenant, governed by the M365 contract and Microsoft's Products and Services DPA. ChatGPT Enterprise is the cleaner pick for a generation-and-analysis workflow that lives outside the buyer's existing Microsoft tenant; Copilot is the cleaner pick when the use case is grounded in M365 data and existing Microsoft 365 controls should govern. The Azure OpenAI route bridges the two for buyers who want OpenAI models with Microsoft contracting.

## The three routes a Microsoft buyer faces

A buyer that wants OpenAI-class generation has three procurement routes:

1. **ChatGPT Enterprise direct from OpenAI.** Separate contract, separate admin console, OpenAI as data processor.
2. **Microsoft 365 Copilot.** OpenAI models exposed through Microsoft, governed by M365 contract; Microsoft is data processor, OpenAI is subprocessor.
3. **Azure OpenAI.** OpenAI models exposed through Microsoft Azure for developer use; Microsoft is data processor, OpenAI is subprocessor; the contract is Azure's.

The first two are the comparison below. Azure OpenAI sits between them as a developer-facing option that mirrors many of Copilot's contracting properties.

The full reads sit at the [OpenAI profile](/vendors/openai) and the [Microsoft 365 Copilot profile](/vendors/microsoft-365-copilot).

### 1. Contract structure and data processor

| | ChatGPT Enterprise | Microsoft 365 Copilot |
|---|---|---|
| Contract | OpenAI Master Services Agreement + DPA | Microsoft Customer Agreement / Enterprise Agreement + Microsoft Products and Services DPA |
| Data processor | OpenAI | Microsoft |
| Subprocessor for foundation model | N/A (OpenAI is the model maker) | OpenAI; Anthropic added 2026-01-07 |
| Cloud subprocessor | Microsoft Azure | Microsoft Azure (first-party) |
| Existing buyer relationship needed | None — direct OpenAI contract | Existing M365 contract |

ChatGPT Enterprise is the direct path; Copilot is the indirect path through Microsoft. For buyers already on M365 with mature procurement and DLP controls, the indirect path is often simpler because the controls already exist. For buyers without M365 or with a generation-heavy use case that does not need to be grounded in M365 data, the direct ChatGPT Enterprise contract is cleaner.

### 2. Where customer data lives

| | ChatGPT Enterprise | Microsoft 365 Copilot |
|---|---|---|
| Default data location | OpenAI infrastructure (US primary; EU residency on certain Enterprise plans) | Buyer's existing M365 tenant; EU Data Boundary scope on Enterprise plans |
| Customer content tenancy | OpenAI workspace tenant | Microsoft 365 tenant |
| Underlying storage of conversations | OpenAI's enterprise storage with admin export and retention controls | M365 substrate — conversations land in the buyer's Microsoft 365 environment |

Copilot's tenant-bound default means the buyer's existing M365 data governance flows through to the AI feature. ChatGPT Enterprise sits in a separate OpenAI-managed environment, which simplifies the data-flow diagram on the OpenAI side but adds a parallel environment to govern.

### 3. Training default

| | ChatGPT Enterprise | Microsoft 365 Copilot |
|---|---|---|
| Use of customer content to train base models | No | No |
| Use of prompts and responses to improve the AI feature | No | No |
| Contract location of commitment | OpenAI DPA + Enterprise terms | Microsoft Products and Services DPA + M365 terms |

The commercial default at both is protective. The clause is in the DPA at both vendors.

### 4. Subprocessor depth

| | ChatGPT Enterprise | Microsoft 365 Copilot |
|---|---|---|
| Foundation model providers as subprocessors | N/A (OpenAI is first-party) | OpenAI (primary); Anthropic added 2026-01-07 |
| EU Data Boundary scope of the Anthropic route | N/A | Explicitly out of scope as of 2026-01-07 |
| Cloud subprocessor | Microsoft Azure | Microsoft Azure (first-party) |
| Implication for buyer's TIA | Straightforward — OpenAI on Azure | More complex — Microsoft + OpenAI + Anthropic, with named EU Data Boundary carve-outs |

This is the single biggest compliance-side reason to weigh the two routes carefully. Buyers who chose Copilot in part because of the published EU Data Boundary commitment need to read the carve-outs that landed when Anthropic joined the subprocessor list in January 2026 — the Anthropic route is explicitly outside the Data Boundary scope.

### 5. EU/UK transfer mechanism

| | ChatGPT Enterprise | Microsoft 365 Copilot |
|---|---|---|
| SCC version | 2021 Module 2 | 2021 Module 2 |
| UK Addendum | Yes | Yes |
| EU residency commitment | Available on certain Enterprise plans | EU Data Boundary on Enterprise plans (with named carve-outs) |
| Sovereign cloud option | N/A within OpenAI direct | Microsoft Cloud for Sovereignty for regulated and public-sector buyers |

For buyers in heavily regulated EU / UK contexts, Microsoft's published sovereign-cloud options are the realistic answer at scale. ChatGPT Enterprise's EU residency is more of a plan-level commitment.

### 6. HIPAA BAA

| | ChatGPT Enterprise | Microsoft 365 Copilot |
|---|---|---|
| BAA available | Yes — ChatGPT Enterprise, ChatGPT Edu, OpenAI API on Enterprise agreement, Azure OpenAI route | Yes — Microsoft signs BAAs for in-scope M365 and Azure services; Copilot inherits where in-scope |
| Eligible tier | Enterprise / Edu | Enterprise M365 plans where Copilot is in scope |

Both sign BAAs at the enterprise tier. The procurement workflow is the same; see the [HIPAA hub](/topics/hipaa-for-ai-tools).

### 7. AI Act deployer-side read

Both vendors are GPAI providers (OpenAI directly; Microsoft as the system provider for Copilot, with OpenAI and Anthropic as the GPAI providers behind it). The deployer-side obligations land on the buyer based on use case:

- ChatGPT Enterprise used for general writing, research, code, and analysis sits minimal-risk or transparency-tier.
- Copilot used for office productivity sits the same way.
- Either product used for HR decisions, automated underwriting, or other Annex III use cases brings high-risk obligations onto the buyer.
- Custom Copilot Studio agents that act on M365 data can climb the AI Act risk tier quickly — the use case classifies the deployment, not the platform.

See the [EU AI Act hub](/topics/eu-ai-act-for-ai-buyers) for the deployer assessment workflow.

### 8. Admin controls and integration surface

| | ChatGPT Enterprise | Microsoft 365 Copilot |
|---|---|---|
| Identity | SAML / SCIM / OIDC | M365 identity (Entra ID) |
| DLP integration | OpenAI Enterprise admin + custom integrations | Microsoft Purview (Sensitivity Labels, DLP policies, Insider Risk Management) |
| Conditional Access | Custom | Entra Conditional Access applies natively |
| Audit logging | OpenAI Enterprise audit logs | M365 audit substrate (Purview Audit) |
| Custom agents / extensions | GPTs, Assistants API | Copilot Studio, Copilot Agents |

The admin-surface differential is the practical reason most large enterprises already on M365 lean toward Copilot for office productivity. The existing Purview / Entra investment pays off immediately. Buyers without that estate, or with a generation-heavy use case that does not need the M365 integration, get cleaner results from ChatGPT Enterprise directly.

## Picking between them

**Pick ChatGPT Enterprise when:**

- The use case is generation, drafting, code, analysis, or research and is not grounded in M365 data
- The buyer is not already on M365 or the existing M365 contract is small
- The deployment needs OpenAI's broader API surface (Assistants, Files, Vision, Voice) as well as the chat product

**Pick Microsoft 365 Copilot when:**

- The use case is grounded in M365 content (Outlook, SharePoint, Teams, Loop, Word, Excel)
- The buyer's procurement gate values the Purview / Entra / Conditional Access integration
- The compliance frame benefits from the published EU Data Boundary documentation (subject to the Anthropic-route carve-outs)
- Copilot Agents are the planned production AI surface

**Pick Azure OpenAI when:**

- The buyer wants OpenAI models on the Microsoft contract surface for region-locked deployment
- The use case is developer-facing rather than office-productivity-facing
- A Microsoft Cloud for Sovereignty layer is part of the procurement gate

**Run both when:**

- ChatGPT Enterprise covers staff-facing generation workflows outside M365
- Copilot covers in-M365 productivity
- Two distinct deployer assessments because the use cases differ

## The Anthropic subprocessor question changes the read

For any buyer whose procurement gate specifically values EU Data Boundary commitments, the January 2026 Anthropic addition to the Copilot subprocessor list is the compliance-side question that needs answering before signing. The realistic responses:

1. Accept the carve-out and document that Anthropic-routed Copilot features are outside the EU Data Boundary scope.
2. Disable the Anthropic-routed features at the tenant level (administratively possible at time of review).
3. Move generation-heavy workloads to ChatGPT Enterprise direct, where the data-flow diagram is shorter.

The decision depends on which Copilot features the buyer actually uses and how strict the procurement gate is.

## Related reading

- The DPA hub: [DPA for AI vendors](/topics/dpa-for-ai-vendors)
- The AI Act deployer-side read: [EU AI Act for AI buyers](/topics/eu-ai-act-for-ai-buyers)
- The HIPAA-specific checklist: [HIPAA for AI tools](/topics/hipaa-for-ai-tools)
- Cross-comparison: [OpenAI vs Anthropic DPA](/compare/openai-vs-anthropic-dpa)
- Cross-comparison: [Copilot 365 vs Google Workspace AI compliance](/compare/copilot-365-vs-google-workspace-ai-compliance)


Buyer-side compliance comparison of ChatGPT Enterprise and Microsoft 365 Copilot for enterprise procurement. Tenant model, training defaults, EU Data Boundary, BAA, AI Act deployer obligations, subprocessor exposure. CIPP/E-reviewed.

OpenAI vs Copilot enterprise compliance: which one for procurement


> **TL;DR.** ChatGPT Enterprise and ChatGPT Edu have a more mature compliance story (BAA, ISO 27001, ISO 27701, ZDR, deeper enterprise tooling). Perplexity Enterprise is closing the gap and has a structural advantage for regulated-industry research workflows: every output ships with source citations the buyer can verify, which simplifies the audit trail. For research and discovery tasks under regulated supervision, Perplexity Enterprise is often the better procurement read; for transactional and integration tasks, ChatGPT Enterprise still leads.

## The comparison frame

Regulated industries — financial services (FCA, PRA, SEC, FINRA), healthcare (HIPAA, NHS DSPT, EU national health laws), legal (SRA, BSB), pharmaceutical (FDA, EMA), and others — share three procurement concerns when picking an AI tool:

1. **Evidence trail.** Output the regulator can audit back to source.
2. **Tier eligibility.** The contracted product, not a consumer adjacent one.
3. **Data controls.** Training defaults, retention defaults, BAA where applicable, region commitments where applicable.

Perplexity and ChatGPT solve a different first-order problem (search-with-citation versus general-purpose generation), and that difference flows into the regulated-industry read.

The full vendor reads sit at the [Perplexity profile](/vendors/perplexity) and the [OpenAI profile](/vendors/openai).

### 1. What the tool actually does for a regulated user

| | Perplexity Enterprise | ChatGPT Enterprise |
|---|---|---|
| Primary mode | Search-grounded answers with inline citations | General-purpose chat, document generation, code, analysis |
| Default output structure | Answer + cited sources (URLs the user can click) | Answer; sources only when the user asks the model to cite |
| Retrieval source | Live web + connected knowledge bases | OpenAI training set + retrieval-augmented when the buyer wires it up |
| Strongest use cases for regulated buyers | Regulatory research, market intelligence, due diligence summaries, expert-witness preparation | Drafting, summarisation, code, structured-data work, customer support, integration with other systems |

The citation behaviour is the structural advantage for Perplexity in regulated work. A compliance officer reviewing a research summary can click each citation, confirm the source, and document the evidence trail without re-running the workflow. ChatGPT will cite sources when asked but does not surface them by default in the same way.

### 2. Tier eligibility and the consumer trap

| | Perplexity Enterprise | ChatGPT Enterprise |
|---|---|---|
| Eligible tier for regulated use | Perplexity Enterprise | ChatGPT Enterprise; ChatGPT Edu; ChatGPT API on Enterprise agreement; Azure OpenAI |
| Tier without enterprise contract | Perplexity Pro; Perplexity free | ChatGPT Plus; ChatGPT Team without explicit BAA addendum; ChatGPT free |
| BAA eligibility (US healthcare) | Emerging — Perplexity Enterprise has been pursuing BAA-readiness; confirm with sales | Yes — ChatGPT Enterprise, ChatGPT Edu, OpenAI API on Enterprise; Azure OpenAI also |
| Training default on the eligible enterprise tier | No training on customer data | No training on customer data |

A staff member using free Perplexity or free ChatGPT for regulated work is operating outside the enterprise default. Both vendors' consumer tiers create the same exposure: the procurement policy has to address consumer use directly, either by blocking the consumer products or by an explicit signed-policy approach.

### 3. Data controls

| | Perplexity Enterprise | ChatGPT Enterprise |
|---|---|---|
| Training on customer data (enterprise tier) | No | No |
| Default retention of enterprise interactions | Enterprise-tier dependent; confirm with sales | 30 days at the API; ChatGPT Enterprise has bespoke retention controls |
| ZDR equivalent | Enterprise-tier dependent | Yes, approval-gated |
| SOC 2 Type II | Yes | Yes |
| ISO 27001 | In progress at time of review; confirm | Yes |
| ISO 27701 | In progress at time of review; confirm | Yes |
| EU data residency | Enterprise option | Enterprise option; Azure OpenAI provides region-locked deployment |

ChatGPT Enterprise has a more mature published security posture. Perplexity Enterprise has been closing the gap; buyers in regulated industries should pull the most recent attestations directly through the sales channel rather than relying on the public marketing pages.

### 4. AI Act deployer-side read

Both vendors are GPAI providers. The deployer-side obligations land on the buyer based on the use case, not the vendor:

- Regulatory research, market intelligence, and due-diligence summarisation generally sit minimal-risk under the Act.
- Clinical decision support, automated underwriting, automated credit scoring, and similar regulated-use cases bring Annex III high-risk obligations onto the buyer.
- Buyers in financial services or healthcare are usually also subject to sectoral AI guidance (FCA / PRA on AI in financial services; FDA on AI/ML-based Software as a Medical Device; EMA on AI in medicines regulation) — these sit on top of the AI Act.

See the [EU AI Act hub](/topics/eu-ai-act-for-ai-buyers) for the deployer assessment workflow.

### 5. Subprocessor depth

| | Perplexity Enterprise | ChatGPT Enterprise |
|---|---|---|
| Foundation models in use | Mix of Anthropic, OpenAI, and Perplexity's own | OpenAI's own models |
| Cloud subprocessor | Amazon Web Services; Microsoft Azure | Microsoft Azure |
| Search index | Perplexity's own crawled index + connected sources | N/A in the base product |
| Implication for buyer's TIA | More providers in the diagram; multi-cloud | OpenAI runs on Azure; the data flow is shorter |

For buyers in regulated industries with strict Transfer Impact Assessment requirements, ChatGPT Enterprise on Azure OpenAI has the simpler data-flow diagram. Perplexity Enterprise's multi-cloud, multi-model stack is more complex to document but offers more redundancy.

## Picking between them

**Pick Perplexity Enterprise when:**

- The regulated-industry use case is research or due diligence and the citation-by-default behaviour materially shortens the evidence trail
- The compliance officer needs to verify every output against named sources
- The buyer's team is small and the workflow is "research → summary → human review → file" rather than "AI in production"

**Pick ChatGPT Enterprise when:**

- The use case includes generation, drafting, summarisation, and code in addition to research
- The buyer needs HIPAA BAA, ISO 27001 + ISO 27701, and ZDR all under one contract today
- The buyer is building AI into a product surface (integrations, agents, customer-facing workflows) and needs the breadth of the OpenAI API

**Run both side by side when:**

- The buyer's compliance owner is auditing a research workflow and the regulated-industry use case demands citations the regulator can click through
- The team's drafting and generation workflow can run on ChatGPT Enterprise while the research workflow runs on Perplexity Enterprise

## The shared regulated-industry checklist

Both vendors require the same buyer-side controls before any regulated-industry deployment:

1. Enterprise tier confirmed; consumer tier blocked or policy-controlled
2. DPA or BAA executed before any in-scope data enters the system
3. Sectoral AI guidance reviewed (FCA, FDA, EMA, SEC, FINRA, NHS DSPT, etc.)
4. Use-case classification under the EU AI Act if any EU exposure
5. Logging cadence set; human-review checkpoint documented
6. Workforce training delivered on the actual approved tool, not a generic AI policy
7. Quarterly review of vendor subprocessor changes (more important on Perplexity given the broader stack)

## Related reading

- The DPA hub: [DPA for AI vendors](/topics/dpa-for-ai-vendors)
- The AI Act deployer-side read: [EU AI Act for AI buyers](/topics/eu-ai-act-for-ai-buyers)
- The HIPAA-specific checklist: [HIPAA for AI tools](/topics/hipaa-for-ai-tools)
- Cross-comparison: [OpenAI vs Anthropic DPA](/compare/openai-vs-anthropic-dpa)
- Cross-comparison: [OpenAI vs Copilot enterprise compliance](/compare/openai-vs-copilot-enterprise-compliance)


Comparison of Perplexity and ChatGPT for buyers in financial services, healthcare, legal, and other regulated industries. Tier eligibility, source-citation evidence trail, training defaults, BAA position. CIPP/E-reviewed.

Vendor comparisons

Copilot 365 vs Google Workspace AI: compliance comparison for enterprise buyers

ElevenLabs vs other voice AI vendors: DPA comparison for compliance buyers

Gemini vs Vertex AI: compliance comparison for Google buyers

OpenAI vs Anthropic DPA: side-by-side compliance read for buyers

OpenAI vs Copilot enterprise compliance: which one for procurement

Perplexity vs ChatGPT for regulated industries: compliance comparison