Privacy tier vs vendor promise: which data may reach a cloud LLM?

A vendor’s privacy page describes the vendor; a privacy tier describes your data and decides which model hosts may receive it. The page is evidence for your review. The tier is the boundary your routing policy enforces before any model is chosen.

“We use an approved vendor” leaves the real decision open. May this host process these inputs, for this purpose, under this agreement, in this jurisdiction? Answer that before the first prompt leaves the building.

The Model Portfolio gives that decision a structure. Chapter 8 defines four privacy tiers and the rules that enforce them, and states plainly that a provider’s published privacy policy is not route approval. Chapter 3 makes privacy class a mandatory field in the model registry, your record of every model and host in use, checked before cost or capability.

The tiers are operating categories, not GDPR categories, and assigning one certifies nothing.

Which business data can I safely send to a cloud LLM under GDPR?

Only data covered by the recorded approval for that route: the right tier, the approved purpose, the approved jurisdiction. Classify the input first, then see which hosts remain eligible. A model’s quality or availability cannot supply a permission nobody recorded.

The book sorts data into four tiers:

Tier	What belongs here	Permitted hosts in the book’s framework
T1: Public / open	Publishable material with no personal data, no proprietary content and no regulated or contract-restricted data.	Any cloud host, including shared inference and public APIs.
T2: Internal / general	Ordinary internal business data. Personal, regulated, privileged, personnel and highly sensitive commercial data are all out of scope.	Cloud hosts with standard commercial data-processing agreements, within your compliance boundary.
T3: Confidential / restricted	Personal data, employee data, financial records, health information, legally privileged material and restricted commercial content.	Hosts cleared by recorded legal review for the data category and jurisdiction: a cloud host with the required agreements and transfer mechanisms, or an on-premises or VPC-isolated deployment. No shared public inference.
T4: Air-gapped / sovereign	Data whose sovereignty, classification or customer-contract requirements prohibit any external processing.	On-premises only, with no network egress to any external API.

When two criteria point to different tiers, the book’s rule is to take the higher one and document why. Ambiguity resolved downward is a compliance risk; resolved upward, it is only a routing cost.

Publicly accessible is not the same as T1. T1 excludes personal data, which the chapter reads broadly: an email address counts, so does a name combined with an employer, and so does a user identifier that could reasonably be linked to a person. Deleting the name does not settle the question.

Internal is not the same as T2. Financial projections, acquisition discussions, competitive intelligence and legal strategy are not necessarily personal data, but the chapter gives them T3 treatment because disclosure carries major organizational risk. Check commercial sensitivity and contract restrictions, not only customer names.

How do you classify a task before choosing the model?

Classify what a kind of work can receive, not what it usually receives. A document assistant that mostly handles internal policy documents but accepts HR attachments is a T3 task.

List every input, not just the typed sentence: the document or message, attachments, retrieved passages, conversation history, user identifiers and any setup data the application adds.

The tier you register for the task type is a floor, so no request can argue its way down into a cheaper host. What actually arrives can still raise it. Chapter 8’s rule:

Effective tier = the highest of the registered task-type tier, any tier carried by the session or upstream context, and any tier a runtime signal detects in the payload.

Signals may raise the tier; nothing lowers it below the floor, and unknown never resolves downward. A T2 task that receives a pasted HR file is served at T3 for that request. A T3 task stays T3 when today’s document looks harmless. If the detector itself fails, the request goes to the fail-closed path instead of being waved through.

Lowering a registered tier takes more than a cleaner prompt: narrow the task type’s data scope, show that higher-tier data can no longer reach it, and record the change with a date.

What is model routing? shows the other fields a route carries, from mandate to fallback. Frontier, workhorse, or local helps you choose a model class among the hosts that pass the tier check.

What should the GDPR review answer?

Chapter 8 frames GDPR as review questions for your legal or compliance owner to answer before the routing policy is approved. This is not legal advice or a complete checklist; the goal is a recorded decision your routing can enforce.

1. Could GDPR apply to this route? Counsel confirms the scope; you record the answer, the frameworks that govern the task type and its jurisdiction.
2. Is the provider acting as a processor, and under which instrument? If so, which data processing agreement or equivalent contract is required? Record its status, the data categories and jurisdiction it covers, and when that status was checked.
3. Does the route involve cross-border processing? It may need a transfer mechanism or another documented basis. Do not infer permissibility from a provider’s marketing page.
4. What exactly was approved? Record the entity, processing purpose, data category, jurisdiction and transfer assessment. Recheck when the provider, region, contract or regulation changes.

In the book’s registry, each host gains six governance fields: DPA status, legal-review record, maximum permitted tier (the host’s tier ceiling), jurisdiction scope, air-gap status and tier review date. A signed agreement is the paperwork that makes the review possible; with no recorded approval, the ceiling stays where it was.

Read the ceiling together with the approval behind it, because that approval names a purpose, a data category and a jurisdiction. A host approved for summarizing support tickets is not thereby approved for analyzing employee performance. Link the approval record to the route.

A worked example: one support task, two cloud hosts

This example is hypothetical. A software company wants a weekly summary of support themes. The task can receive customer messages, email addresses, account identifiers and conversation history, so it is registered at T3. Messages from customers whose contracts prohibit external processing are kept out.

The prompt reads: “Group these tickets by product issue. Leave customer names out of the summary.”

That instruction shapes the output. It does not remove a single name or email address from the input the host receives.

Two hosts are on file, with invented approvals:

Host	Recorded approval	May it receive this batch?
A	T2 ceiling, internal documentation	No. The task’s T3 floor is above A’s ceiling.
B	T3 ceiling, support-ticket analysis for these data categories and this jurisdiction	Yes, within that approval.

Assume B’s contractual and transfer review is complete. Neither row describes a real provider.

The rule gives three answers. A ticket with a customer’s email address goes to B. So does a generic troubleshooting message through the same task, because the floor is still T3. And if B is down, neither host may take the batch; A’s spare capacity changes nothing.

Now the company wants to add messages from a customer whose contract prohibits any external processing. It can keep them out of this task, or raise the task to T4 with an on-premises path or a defined blocked outcome. It cannot stay at T3 because most customers have looser contracts.

The output is a route card someone else can check:

Task: weekly support-theme summary
Inputs in scope: customer support messages and their ticket context
Inputs excluded: material barred from external processing
Registered tier: T3
Primary host: B, within its recorded support-analysis approval
Secondary cleared host: none (single point of failure, documented)
If B is unavailable: hold in a durable queue; retry; enforce a maximum wait
On expiry: return a structured error; alert the named owner
Log: tier, task type, intended host, reason blocked, handling outcome

The card is illustrative: the retry interval, maximum wait, approval record and owner still need filling in.

What happens when no cleared host is available?

Under pressure, the tempting answer is whichever host is up. Chapter 8 rules that out: no availability argument overrides a tier constraint. It leaves three designed responses:

• Queue and retry. Hold the request in a durable queue, not an in-memory buffer, with a configurable retry interval and a maximum wait, after which it ages out with an error. This suits batch and near-real-time work.
• Degrade to a lower-tier function. Return a reduced response that needs none of the sensitive input, such as a structured acknowledgment that the document was received and will be processed when capacity returns. This product-level degraded mode needs product design as well as routing.
• Fail with a structured error. Return an error stating that the compliant path is unavailable, with enough detail for the calling system to show a meaningful message or escalate manually. The routing log records a blocked route, never a success.

The task’s latency class decides: a real-time, user-facing task cannot queue for minutes, while a batch job can wait hours. Decide before deployment who is alerted when a restricted route blocks. A blocked request that leaves no log entry is a compliance gap.

The constraint covers every path that carries the payload: the primary route, the fallback chain, and any mirrored, shadow or evaluation copy of the same request. Testing a replacement model on copies of live requests earns no exemption.

An override can move a request to another model the effective tier already permits, never across the tier itself. Logging a prohibited disclosure records it; it does not license it. If the business genuinely needs data somewhere its tier forbids, that calls for reclassification through your compliance process.

What must the routing log show?

Chapter 8’s audit table lists the fields: request timestamp, task type, privacy tier assigned, model host selected, routing rule applied, override flag, override approver, routing outcome (success, fallback or blocked) and latency. An input fingerprint is optional in the operational log and is a hash only, never raw content. For a blocked route, the chapter’s design template adds the intended host, the reason for blocking and the handling outcome.

The chapter separates a detailed operational log from a summary compliance log and sets no universal retention period: your legal or compliance owner sets each one from purpose, applicable law and contract.

The agent audit trail article covers the broader reconstruction drill. For privacy tiers the test is narrower: from the records alone, can a colleague show which host received the data and why that host was cleared for it?

One limit remains: the routing precondition governs the stack you operate, not a browser tab an employee opens on a personal account. For that, the book uses an approved-model list written in tier terms: which tools, for which categories of data, through which accounts.

Try this today

Take the last five prompts your team sent to an external model. Review them where that data is already approved to be held, not by pasting them into another external model.

1. Reconstruct the full input. Include attachments, retrieved context and conversation history. Note a reference, not a copy of sensitive text.
2. Assign the book’s tier. Check for personal data, commercial sensitivity and contract restrictions. Compare the result with the task’s registered tier and anything the session added, and take the highest. A missing classification is already a finding.
3. Name the actual destination. Host, service and account, plus any fallback or evaluation copy. If the records cannot say where the data went, write that down.
4. Find the approval that applied. Compare the effective tier with the host’s ceiling, then check purpose, data category and jurisdiction. Missing evidence counts as a gap, not a match. An approval recorded later does not show what was permitted when the prompt was sent.
5. Pick the first fix. Any prompt whose tier exceeds what its route was cleared for is your first fix. Stop it recurring, name an owner, record the permitted route or the blocked outcome, and put the row in front of your legal or compliance owner.

Keep one row per prompt: reference, effective tier, destination, approval, match or gap, next action, owner.

Five clean rows describe five prompts, not the system. If all five match, run the chapter’s tier drill on your most sensitive task type: from the registry alone, name its tier, the hosts cleared for that tier, and what happens when none of them is available. A gap in any answer is a finding you can fix before an auditor names it.

Cite this:Privacy tier vs vendor promise: which data may reach a cloud LLM?Len P. van der Hof. https://lenvanderhof.com/en/blog/privacy-tier-vs-vendor-promise/ · Published 6 November 2026.