Voice AI Data Flows: A Buyer Evidence Test for GDPR and UK Transfers

Voice AI Data Flows: A Buyer’s Evidence Test for GDPR and UK Transfer Questions

“Your calls stay in Europe” sounds like a complete answer until you ask which calls, which data objects, which legal entity, and which kind of access the statement covers. A phone interaction can pass through a carrier, a speech-to-text service, an orchestration layer, a model endpoint, a CRM, observability tools, support staff, and backups. The country shown on a cloud dashboard tells you where a particular copy is stored. It does not, alone, identify who receives the information, what the recipient does with it, or what happens when support investigates a failed call.

The practical decision is whether a real call workflow can be bounded well enough for a pilot. Use the Vocalis guide to GDPR questions for AI voice for the broader context; this companion gives procurement and privacy teams a concrete evidence test. It is not legal advice or a compliance certification. It is a repeatable way to map a specific voice service, compare the map with contracts and settings, and decide what remains unknown before real customer data is sent.

The recommendation: ask for a flow map that names the data object, recipient entity, purpose, region, access path, retention, and evidence for every step. Then verify a harmless test marker through the systems you are permitted to inspect. Do not accept a single “EU-hosted” answer as proof of the whole chain.

The reader’s decision and scope

This protocol supports four outcomes: approve a tightly scoped pilot, approve with data minimisation or features disabled, hold procurement pending evidence, or reject a workflow whose data path cannot be bounded. Use it before signing, enabling recording, connecting a customer database, changing a model, or adding a support provider.

It covers AI phone systems that process live audio, recordings, transcripts, phone numbers, call metadata, summaries, or derived labels such as intent. It does not decide the lawful basis, the legality of call recording in a particular country, or whether a DPIA is required. Those conclusions depend on the actual purpose, callers, data categories, scale, jurisdictions, and safeguards. Assign them to the controller’s privacy or legal owner.

The scope must be a configuration, not just a product brand. Capture the service tier, region, enabled features, speech and model providers, CRM connector, logging options, support access, and retention settings. Two teams buying the same product can create different data flows if one enables recording and another sends transcripts to a third-party model.

What search results and vendor pages leave unresolved

The existing Vocalis guide covers why a voice agent may handle personal data, lawful basis and transparency questions, minimisation, storage and security, rights, and DPIA considerations. That baseline helps a reader recognise the issues, but a purchaser still needs to verify the actual route: does the speech provider receive audio, does the model receive account context, can support access a trace, and does a backup include transcripts?

That gap is common in vendor review. A product page can describe a security feature, while the contract names a different entity, and the runtime configuration enables a logging option that the product overview does not discuss. These are not automatically contradictions; each source may describe a different service, purpose, or configuration. The buyer must reconcile them against the exact tenant and workflow.

A useful discussion question is: “If we disable recording, does any transcript or diagnostic snippet still persist, and which organisation can read it?” A yes/no answer is inadequate. Ask what “recording,” “persist,” and “read” mean in that product, and ask for an artefact that demonstrates the answer.

Why a data-flow map is more useful than a residency badge

An audio stream can be transiently processed without becoming a long-term recording. A transcript can be retained after the audio is discarded. A model request can include CRM context that never appears in a call recording. A support ticket can contain an error payload even when routine analytics are disabled. An export may then be copied into a customer system that is outside the voice provider’s deletion control.

For every object, track four questions separately: where is it transmitted or stored; which legal entity operates the component; which entity can access or receive it; and what purpose and instruction authorise that processing. Add a fifth row for the evidence that supports the answer. Region is one data point in this record, not a proxy for entity, purpose, or transfer assessment.

This distinction matters on both sides of the Channel. The EDPB’s SME guidance identifies an EEA transfer through cumulative elements that include a GDPR-subject controller or processor, disclosure or making personal data available to another organisation, and a recipient outside the EEA. Its guidance also explains that transfer conditions sit alongside the usual GDPR principles and processor contract. EDPB guidance on international transfers

The ICO’s UK restricted-transfer guide uses a three-step test involving UK GDPR applicability, a transfer initiated to an organisation outside the UK, and a separate legal entity as recipient. It specifically says server geography alone does not determine restricted-transfer status; the recipient’s establishment matters. This is a UK-specific test and should not be merged into an EEA assessment. Server location still matters for other contractual, security, resilience, or customer promises. ICO guide to restricted transfers

Original asset and method: the 12-row proof packet

The table below is an original buyer-run protocol assembled on 28 October 2026 from the EDPB’s processor and transfer guidance, the ICO’s UK test, and voice privacy research. The sample size is twelve evidence questions, not twelve vendors or observed incidents. No provider was tested for this article. Each row asks for a document or configuration record and, where safe, a sandbox demonstration. The protocol excludes penetration testing, legal opinions on a particular transfer, and verification of undisclosed infrastructure. Its limitation is explicit: evidence supplied by a vendor can be incomplete or inaccurate; the buyer must record the boundary of every test.

#	Evidence row	Minimum artefact	What a safe test can show
1	Audio path	Carrier and speech-service flow	Which approved component receives synthetic audio
2	Transcript path	Speech output and destination map	Whether a unique synthetic phrase appears in permitted logs
3	Context path	CRM fields sent to orchestration/model	Whether excluded fields are absent from a test request
4	Entity and role	Legal names, roles, purpose per service	Whether names match the DPA and subprocessor schedule
5	Region and copies	Primary, replica, backup, transient location	Whether tenant settings match the written region statement
6	Human access	Roles, support path, just-in-time controls	Whether a restricted test account is denied
7	Model use	Training, evaluation, abuse review, improvement	Whether tenant control and contractual text agree
8	Retention	Duration and trigger for each object	Whether a disposable test object expires as configured
9	Deletion	Active, derived, exported, and backup scope	What the provider’s scoped deletion receipt actually covers
10	Transfer route	Recipient, destination, mechanism, assessment	Which named entities receive data outside a territory
11	Caller notice	Timing, language, recording and purpose content	Whether notice occurs before substantive data collection
12	Change and exit	Notice, objection, export, termination process	Whether a simulated change or exit has an owner and route

Use statuses rather than a percentage score: verified means a current artefact and a safe test support the claim; conditional means it depends on a setting or service tier; unknown means the evidence is absent or too broad; contradicted means documents or tests disagree. These labels structure a decision; they do not measure legal compliance.

Name the entities before you discuss countries

Start with the legal entity that signs the agreement, but do not stop there. Ask for the entity that operates the telephony integration, the speech recogniser, the model endpoint, the logging service, the CRM connector, and support. A brand name may cover several companies. A cloud provider may host a service without deciding its purpose; a support affiliate may receive data only when a ticket is opened; a model company may process request content under a separate service term. The map should identify each role per purpose rather than label the whole vendor “processor.”

The EDPB describes a processor as acting on the controller’s instructions and a sub-processor as processing under the processor’s instructions. Its SME guidance says the controller must authorise subprocessor engagement in writing and that the processor-subprocessor contract must provide equivalent protection. The processor contract should also address instructions, security, rights requests, incidents, deletion or return, audit, and compliance information. EDPB: controller or processor

Ask the vendor to map role and purpose across at least these categories: call content; account and billing administration; product analytics; abuse and fraud prevention; support diagnostics; model quality review; and service improvement. A company may process call content only on instructions yet use account telemetry for a separate purpose. The role may differ by operation. Ask what data is involved, how long it is held, whether it is linked to callers, and which term governs it.

Compare the answer to the data processing agreement, product terms, model terms, and the dated subprocessor list. If a support affiliate can inspect traces but is absent from the document supplied, ask whether the access is technically possible, contractually authorised, and included in the approved chain. If it is conditional on a support case, identify who opens that case, whether customer approval is required, and whether access is logged.

Draw the audio and text pipeline as a sequence

Do not use a single box called “AI platform.” Draw each transition from the caller, and label every arrow with both the object and direction. A typical flow might be: telephone carrier routes caller ID and live audio; speech service receives audio and emits text; orchestration attaches a small amount of context; model service returns a response; CRM stores a summary and disposition; observability stores timing and errors; support receives a diagnostic bundle when troubleshooting begins.

flowchart LR
  Caller -->|number + live audio| Carrier
  Carrier -->|audio stream| Speech
  Speech -->|transcript| Orchestrator
  Orchestrator -->|prompt + minimal context| Model
  Model -->|response| Orchestrator
  Orchestrator -->|summary + disposition| CRM
  Orchestrator -->|events + errors| Logs
  Logs -->|scoped diagnostic| Support
  Speech -->|if enabled| RecordingStore
  CRM -->|customer system controls| CustomerRetention
~~~

Replace each generic label with the named provider and legal entity after procurement. If the vendor refuses to name an entity publicly, ask for the information under a confidentiality process; do not substitute the company’s brand. Mark which paths are live, which persist, and which are activated only by a support or quality-review event. Add a version, date, owner, and unresolved edges to the diagram.

An absent arrow also needs evidence. If a vendor says the model never sees a phone number, ask whether the number is removed before prompt construction and whether logs preserve the pre-redaction request. If recordings are disabled, ask whether transient buffers, speech-service traces, or caller-side recording remain. The goal is not to presume that every system stores everything; it is to make each claim falsifiable.

## Treat “not stored” and “not used for training” as separate statements

“Not stored” may refer only to a durable recording. The platform may still process a live stream, create text, hold temporary buffers, or capture an error excerpt. Ask the vendor to define storage, transient processing, cache, diagnostic log, and retention in operational terms. Ask for the component that enforces the setting and the account or service tier where it applies.

“Not used for training” can exclude foundation-model training while leaving evaluation, abuse monitoring, human review, product analytics, fine-tuning, or model improvement. Request a separate answer for each purpose. Ask whether the setting covers inputs and outputs, every model provider, the entire tenant, and support cases. Record whether the commitment is contractual, configurable, a default, or a policy statement subject to change.

A synthetic marker can show whether a test string is visible in the specific logs or exports inspected. It cannot prove that no copy exists elsewhere or that a model was not trained on data across a population. Negative claims require a combination of contractual terms, configuration evidence, records, and suitable independent assurance. Do not write “we tested and proved no training”; record precisely what setting was checked and what the test could observe.

When a sales response says “customer data is never used,” ask which legal entity the phrase covers and whether it includes troubleshooting. Ask for the applicable term, not a slide deck. If there is a conflict between policy, contract, and admin control, treat the answer as contradicted until the vendor explains which text governs and how the configuration matches it.

## Retention is per object, not per product

Build a retention schedule for audio, live buffers, transcripts, summaries, CRM fields, embeddings, operational events, support attachments, abuse records, billing logs, and backups. Not every deployment uses each object. Mark “not generated” only when the product owner or vendor can explain how that absence was verified. Otherwise record “unknown.”

For each object, ask who selects the duration, what starts the clock, whether it can be configured, and what exceptions apply. A transcript might be retained for a short support window while the CRM summary follows the customer record schedule. A security event might need a distinct period from the content it references. A backup may age out on a schedule, even after the active record is deleted. Capture these distinctions in the map instead of flattening them into “retention: 30 days.”

Test expiry in a non-production tenant with a disposable marker and the shortest safe interval available. Keep the creation timestamp, configured duration, query method, and observation result. If the service cannot wait for full expiry, request a redacted test report or a documented lifecycle and mark the result conditional. Do not claim a test pass when you only verified that a user-facing screen no longer displays the item.

Deletion should specify scope. Ask whether it includes active stores, derived fields, model prompts, analytics, support tickets, CRM copies, exports, and backups; identify which party controls each copy. The EDPB says the processor contract should provide for return or deletion at the controller’s choice after service ends and for information needed to demonstrate compliance. A generic ticket marked “complete” is not the same as a scoped deletion receipt.

## Make access a testable path

Ask which roles can view raw audio, transcripts, prompts, summaries, metadata, and support bundles. Separate ordinary customer administrators from vendor operations, support, engineering, and subprocessors. Determine whether support access is persistent or just-in-time, whether the customer approves it, how the session is bounded, and what audit record is available.

Use a sandbox account with the least privilege that should still work. Attempt only a safe read of the synthetic test record and confirm that access is denied when the policy says it should be. Then review a redacted audit event for an authorised access. Record the user role, tenant, endpoint, expected outcome, observed result, and any exception. Do not test cross-tenant access in production or attempt to access another customer’s data.

A 2024 IEEE Access study on multi-user voice assistants reports access-control weaknesses in specific consumer voice systems. It developed automated tests and found that some operations were protected while other operations could expose private information. The paper does not establish that a particular business voice platform is vulnerable; its value here is narrower: voice interfaces can create authorization edges that are easy to overlook, so a buyer should verify the exact roles and actions in its own service. [IEEE Access study, published 18 March 2024](https://ieeexplore.ieee.org/document/10474339/)

Request a role matrix, redacted log sample, and vendor explanation of emergency access, break-glass identity, impersonation, and audit retention. If the provider cannot share details for security reasons, ask for independent assurance that maps to the control. Note any limitation and avoid collecting secrets or another tenant’s information.

## Explain the notice before the caller shares information

A caller should understand who is speaking, why voice data is processed, and what alternatives exist before substantive details are requested. A web privacy page linked after the interaction does not necessarily make a spoken notice understandable at the point of collection. The exact disclosure and lawful basis must be decided for the real service, country, and call purpose by the controller’s privacy owner.

Voice notice has interaction design constraints. The caller may be driving, using a second language, calling about a sensitive issue, or trying to reach a person quickly. Test the first sentence, timing, repetition, interruption behaviour, and human route. Ask whether the system asks for an account number before it explains the AI interaction or recording. Check what happens when the caller says “stop,” asks for a person, or refuses a recording.

A 2026 PoPETs paper studied privacy notices in voice interfaces. The authors interviewed 21 voice-assistant users, then ran a within-subject study with 160 participants; participants preferred notices delivered in the default app voice before data was requested. This is a bounded study about notice preferences, not proof that one script satisfies law or applies unchanged to business calls. It supports testing timing and delivery instead of assuming that a link is enough. [PoPETs 2026: Privacy by Voice](https://www.petsymposium.org/popets/2026/popets-2026-0049.php)

For an acceptance test, write a plain-language script, get the relevant privacy owner to review it, and run it through representative call scenarios. Record whether the notice is heard before the agent asks for personal information, whether the caller can interrupt, and whether the human fallback works. Do not infer consent merely from a caller continuing the conversation.
## A controlled test run: trace one harmless marker

Create a disposable test call in a non-production tenant. Use an artificial name and a unique phrase that is not a real person’s data, such as “test token violet 84.” Do not use a customer account, phone number, payment reference, health detail, or internal secret. The test plan should identify which vendor logs and exports the team is authorised to inspect; it is not permission to search systems outside your contract.

Before the call, record the active service configuration and save a dated copy of the data-flow diagram, subprocessor page, relevant product terms, and retention settings. During the call, state the marker once in a low-risk context. Afterward, search only approved test records, exports, and logs for that phrase. Record where it appears, the entity responsible for the component, the observed retention state, and whether the vendor’s explanation matches the artefact.

This test can reveal a mismatch, such as a transcript appearing in an observability export despite a “no recording” setting. It cannot prove the absence of data in unknown systems. Treat every negative result as “not found in systems A, B, and C using method M at time T,” not “no data exists.” If the vendor’s architecture includes components you cannot inspect, record them as evidence gaps and ask for an attestation or scoped report.

Delete the synthetic test record through the documented workflow. Capture the request ID and response. Search the same approved surfaces again, then ask how backups and downstream copies are handled. A successful deletion test is limited to the objects and systems the test can observe. Keep the result with the object inventory so a later reviewer can understand both the evidence and its blind spots.

## Worked example: an EEA retailer serving callers in Britain

Imagine a retailer based in the EEA uses a voice agent to answer order-status calls. The speech service receives live audio; an orchestration service sends the transcript and a minimal order reference to a model; a CRM connector returns shipping status; a logging tool stores error codes; support can inspect traces when a ticket is opened. The supplier says “EU data centre.” That answer covers a location claim but leaves several questions unanswered.

First, identify the contracting entity and each recipient. Does the speech service belong to the vendor or a separate subprocessor? Can support staff from another affiliate access transcripts? Is the model service operated by a separate entity? Second, label the objects each receives. Does the model need a full name or phone number, or can a one-time order token answer the question? Third, record each purpose and setting: service delivery, security, troubleshooting, analytics, and model improvement should not be combined into one vague purpose.

For EEA processing, the EDPB’s transfer criteria focus on whether data is made available to a separate organisation outside the EEA, among other elements. For UK restricted transfers, the ICO asks whether UK GDPR applies, whether the transfer is initiated to an organisation outside the UK, and whether the recipient is a separate legal entity. These analyses are not identical. The retailer should assess the actual entities and flows under the law that applies rather than infer the answer from a caller’s location or the cloud region alone.

A restricted pilot might send only a random order token to the model, disable transcript retention, keep CRM lookup behind a narrowly scoped connector, and require customer approval for support access. If those controls are unavailable, the team could use a human-only channel for order-specific calls while allowing the agent to answer general questions. These are operational risk controls, not legal safe harbours. The privacy owner should document the choice and residual uncertainty.

## How to keep evidence current

A review is a snapshot. The service can change after a model update, a new subprocessor, a product-tier migration, a modified support process, or a retention-setting change. Assign an owner to monitor vendor notices and define which changes reopen approval. Request advance notice, a meaningful objection period, and a route to disable or terminate the affected processing if a change cannot be accepted.

Keep an evidence register with claim, source document/version, exact clause or setting, owner, verification date, result, and caveat. For example: “Transcript retention is configured for the pilot tenant; verified in admin export on 28 October; the vendor’s general support terms allow troubleshooting access after a ticket; a sample access log was provided with direct identifiers redacted.” That is more reviewable than “vendor is GDPR compliant.”

The EDPB says a processor should make necessary information available to demonstrate compliance and allow audits or inspections under the contract. Proportionate assurance can include a scoped audit report, redacted access logs, control descriptions, or a sandbox demonstration. It need not mean unrestricted access to production infrastructure. If evidence is withheld, record exactly what the reviewer could not verify and who accepted that uncertainty.

## Use a decision ladder, not a compliance percentage

Choose a result for each material evidence row: verified, conditional, unknown, or contradicted. Then make a decision:

- **Proceed to a limited pilot** when purpose and data are narrow, entities and routes are mapped, and remaining gaps have owners and deadlines.
- **Proceed with restrictions** when recording, CRM context, analytics, or support access can be reduced to meet the business need.
- **Hold for evidence** when a material recipient, retention path, or deletion boundary remains unknown.
- **Reject the workflow** when the organisation cannot control the path or the residual risk violates its policy.

Do not average the rows into a single score. A verified encryption setting cannot cancel an unknown model recipient. A known data-centre location cannot compensate for an unbounded support-access path. The decision belongs to accountable business, privacy, and security owners and should state the allowed purpose, user group, data classes, configuration, and expiry date of approval.

## Add a lightweight proof-pack validator

A small validator can stop a review from being marked complete while required evidence fields remain empty. This example checks documentation completeness; it does not determine whether a transfer is lawful, whether a provider statement is true, or whether the residual risk is acceptable. Its output is a list of gaps for a human reviewer.



```javascript
const required = [
  "object", "recipientEntity", "purpose", "role",
  "region", "accessPath", "retention", "deletionEvidence",
  "contractReference", "verifiedAt"
];

function review(rows) {
  const findings = [];
  for (const [index, row] of rows.entries()) {
    const missing = required.filter(key =>
      row[key] === undefined || row[key] === null || String(row[key]).trim() === ""
    );
    if (missing.length) findings.push({ row: index + 1, missing });
    if (row.status === "verified" && !row.evidenceReference) {
      findings.push({ row: index + 1, missing: ["evidenceReference"] });
    }
  }
  return findings;
}

// Keep this synthetic fixture separate from production call data.
const sample = [{
  object: "synthetic transcript",
  recipientEntity: "Named test processor Ltd",
  purpose: "speech transcription",
  role: "processor",
  region: "documented region",
  accessPath: "restricted support role",
  retention: "test tenant setting",
  deletionEvidence: "test request record",
  contractReference: "DPA section reference",
  verifiedAt: "2026-10-28",
  status: "verified",
  evidenceReference: "redacted test artefact"
}];

const findings = review(sample);
if (findings.length) {
  console.error(JSON.stringify(findings, null, 2));
  process.exitCode = 1;
} else {
  console.log("Documentation fields present; human review still required.");
}
```



Run this against a locally stored, redacted manifest, not against a live provider API. The sample values are placeholders and do not describe a real vendor. A production implementation would also validate permitted statuses, dates, entity identifiers, and document versions. Do not let a green result be presented as a compliance certificate; it merely says that the paperwork has the fields this team decided to require.

## Keep the protocol aligned with broader AI governance

The OECD’s AI work frames effective governance as a way to capture benefits while mitigating risks, and its digital policy materials include work on data flows and privacy. That perspective supports treating voice-data handling as an operating-model issue with assigned owners and review triggers. It does not replace the GDPR transfer analysis, determine a controller or processor role, or certify a provider. [OECD artificial intelligence policy work](https://www.oecd.org/en/topics/artificial-intelligence.html)

KPMG’s trusted-AI technology governance overview is a consulting perspective on governance controls and technology operations. It can help a team think about ownership, lifecycle controls, and evidence responsibilities, but it is not independent proof about a supplier’s tenant or infrastructure. Use it to structure management questions, then rely on your own contract, settings, and scoped test for the particular deployment. [KPMG trusted AI governance overview](https://kpmg.com/us/en/capabilities-services/alliances/kpmg-servicenow/trusted-ai-technology-governance.html)



```

## What market evidence can and cannot tell you

Gartner reported a survey of 265 customer-service leaders conducted in April and May 2025. The survey release says digital self-service and live chat were expected to gain importance, while AI agents remained outside the top ten technologies ranked by respondents for current and two-year value. This is a measure of leaders’ perceptions, not proof of customer preference, privacy quality, or a specific product’s effectiveness. It is relevant only as a reminder to keep an assisted-service route and assess the whole support journey. [Gartner survey on service technologies](https://www.gartner.com/en/newsroom/press-releases/2025-08-27-gartner-survey-finds-self-service-and-live-chat-will-surpass-traditional-channels-as-top-customer-service-technologies-by-2027)

The market signal does not make phone support obsolete. A voice agent may serve routine questions; a human may be necessary for complex or sensitive cases; another channel may be inaccessible to a caller. The data-flow test should therefore include outage, escalation, and caller choice. A fallback can itself introduce a new recipient if it forwards audio or transcripts to another service.

## Failure modes that invalidate the evidence

**Region-only assurance:** the answer names a cloud region but omits legal entities and remote access. Ask for recipients and support paths.

**Purpose bundling:** “service improvement” hides analytics, human review, or model evaluation. Split purposes and match each to terms and settings.

**Transient-data blind spot:** durable recordings are off, but logs retain snippets or transcripts. Define every object and test authorised logs.

**Subprocessor drift:** the public list changes without clear tenant applicability. Preserve a dated list, notice clause, and objection route.

**Deletion overclaim:** a ticket says “deleted” but does not cover summaries, exports, or backups. Require scoped evidence.

**Role-label shortcut:** the vendor says “processor” without explaining independent account or telemetry purposes. Map roles per operation.

**Marker overreach:** one test call is used to claim the entire environment has no copies. State what was searched and what was inaccessible.

**Notice after collection:** the agent asks for identifiers before explaining the interaction. Test timing from the caller’s point of view.

**Single-score masking:** an average hides an unknown recipient or contradictory contract. Escalate material unknowns directly.

## Limitations and contradictions to preserve

“EU data residency” and “international transfer” are different questions. A copy may stay within the EEA while another entity receives or can access information outside it. A server outside a territory does not alone answer the ICO’s separate-entity test. The exact result depends on recipient identity, disclosure, applicable law, and operational facts. Do not generalise one jurisdiction’s guidance to another.

Auditability also has a boundary. A buyer needs evidence to make an accountable decision, while a vendor should not expose secrets, other tenants’ data, or exploitable details. Accept a redacted, scoped artefact when it still supports the specific claim; otherwise record the limitation.

The PoPETs study concerns voice-interface notice preferences, the IEEE paper concerns consumer multi-user voice systems, and Gartner’s survey concerns service-leader rankings. None certifies a business call platform. Use each source only for the claim it supports. The 12-row packet itself is a proposed method and has not been benchmarked across vendors.

## Approval checklist

- [ ] The workflow, purpose, tenant, tier, features, and jurisdictions are specified.
- [ ] Audio, transcripts, identifiers, prompts, outputs, logs, CRM copies, and backups are separate rows.
- [ ] Every recipient is named by legal entity, country, role, service, and purpose.
- [ ] The diagram distinguishes storage, live processing, access, and disclosure.
- [ ] The DPA and subprocessor schedule agree with the map and current configuration.
- [ ] Model training, evaluation, abuse review, support access, and improvement are answered separately.
- [ ] Retention and deletion evidence covers derived data and documents the backup boundary.
- [ ] EEA and UK transfer questions are considered under their respective rules.
- [ ] A safe test marker confirms only the systems actually observed.
- [ ] Callers receive understandable notice before substantive information is collected.
- [ ] Human fallback and outage behaviour are tested without creating an unapproved path.
- [ ] Unknowns and contradictions have owners, deadlines, and explicit decision outcomes.
- [ ] Approval is scoped to purpose, data classes, configuration, users, and review date.

## Final recommendation

Do not buy a compliance label and do not decide from a region badge. Ask the vendor to show the chain: what leaves the call, which organisation receives it, for what purpose, under whose instruction, where it is processed or retained, who can access it, how long it lasts, how it is deleted, and how the customer will hear about a change.

If named entities, current documents, scoped settings, and safe tests align, the organisation has evidence for a bounded decision. If the answer is only “EU cloud,” a generic DPA, or “we never train on your data,” keep the pilot narrow or pause until the gaps are resolved. The deliverable is a decision that operations, security, and privacy owners can explain and revisit—not a decorative compliance percentage.