Personal information and the cloud AI

A cloud AI can read a pile of receipts or a customer table in seconds. But those pages are full of names, addresses and account numbers, and the moment they leave your computer you cannot take them back. Here is what counts as personal information, where it goes wrong, and the two protections — a disguise and a promise — that people constantly mix up.

The two protections in one picture

Two panels. Protection one, the disguise: John Doe paid five hundred dollars becomes CUSTOMER underscore one paid five hundred dollars before anything leaves. Protection two, the promise: the vendor signs a contract to keep nothing, work in memory, no logs, no training. Caption: two protections with two different jobs; the safest setups use both.
1

What counts as a personal detail

Some clues name a person outright: a name, a home address, an email, a tax or card number. Others look harmless on their own — a customer number, a postcode, an unusual buying habit — but put a few together and a real person falls out. Both kinds count, and both need protecting.

Left: clues that name you outright, shown as a name tag, envelope, phone and bank card: name, home address, email, phone, tax number, bank account, card number. Right: clues that add up to you: customer number 4821, postcode 6011 and a rare weekly order combine into a person, that's John. Caption: both kinds count as personal information.
Under the hood

Personally identifiable information (PII) is anything that can identify, contact or locate a specific individual, alone or in combination. In finance it overlaps with PCI (payment card) data and PHI-style financial identifiers. Direct identifiers: names, billing addresses, emails, phone numbers, tax IDs (TIN/SSN/IRD), bank account and card numbers. Indirect identifiers: customer_id values, transaction IDs, granular postcodes, and rare purchase patterns that re-identify someone when cross-referenced with public data. De-identification that only strips the direct kind is not de-identification.

2

One click and it’s over the fence

Sending a page to a cloud AI means it leaves your building and lands on servers you do not control. Two things can go wrong at that moment: privacy laws in many countries say you must ask permission before other people’s details travel, and the vendor may keep copies you never see.

A customer table full of real names travels from your building over a dashed fence into the vendor's cloud. Below, two consequences: it can break the rules, since privacy laws in Europe, New Zealand and elsewhere require permission first; and it can leave copies, since prompts and files may be stored on the vendor's side.
Under the hood

Transmitting unredacted customer PII across an organisational boundary without consent can violate GDPR (Europe), CCPA (California), HIPAA (health-adjacent finance) and the New Zealand Privacy Act 2020. And by default, standard API calls and desktop chat sessions may retain prompt logs and file attachments on vendor infrastructure for debugging, context processing or model evaluation — customer records sitting in someone else’s storage.

3

Where it lingers

Leaks are rarely dramatic. A sentence with a name in it gets written into the vendor’s logs; a receipt pasted into a chat stays in the saved thread, where anyone in the workspace can scroll back to it years later. Deleting your copy does not delete theirs.

Left: a prompt saying John owes four hundred dollars is written into the vendor's logbook, kept for debugging and sometimes training. Right: a chat window holds a receipt with John Doe's name, and three workspace members can scroll back to it years later. Caption: deleting your copy does not delete theirs.
Under the hood

The two vectors: prompt/log leakage — raw prompts travel over the API, and if the provider logs inputs for debugging or training, the PII persists in external server logs; and thread persistence — chat products keep conversation history, so an unredacted document dropped into a thread lives on in cloud chat history, visible to everyone with access to that shared workspace or account.

4

Protection one: code names and a vault

The disguise. Before anything leaves, a small piece of software swaps every real name for a code name and locks the real value in a vault at home. The AI does all its thinking on the code names — it cannot leak what it never had. When the answer comes back, the same software swaps the real names back in, on your screen only.

On the way out, John Doe paid five hundred dollars becomes CUSTOMER underscore one paid five hundred dollars, the only version that crosses the fence to the cloud AI; the real name goes into an encrypted vault that never leaves home. On the way back, the AI's answer, still in code, is swapped back to John Doe on your screen; the vault opens at home, for you only.
Under the hood

This is the redaction/rehydration gateway. Redaction: local tooling (Microsoft Presidio, spaCy NER, regex rules) scans text, CSVs and receipt images and replaces PII with deterministic tokens, e.g. <CUSTOMER_001>. Processing: the sanitised prompt goes to the LLM, which does its structural, logic or code-generation work on the tokens. Rehydration: the gateway swaps tokens back to real values using an encrypted, in-memory mapping vault before rendering the result to the authorised user. The mapping never crosses the network.

5

Protection two: a signed promise to keep nothing

The promise. Under a Zero Data Retention agreement, the vendor commits in a contract: your data is worked on in memory, the answer is sent back, and then everything is thrown away. No logs, nothing saved to disk, no training on your data. It is a legal commitment with lawyers behind it, not a checkbox in the settings.

Your prompt and files, real details and all, go to the vendor, who works on them in memory only and then throws everything away. Three crossed-out items show what never happens: no logs written, nothing saved to disk, no training on your data. A signed agreement card reads Zero Data Retention, a contract, not a setting.
Under the hood

ZDR agreements are offered by enterprise API providers (Anthropic enterprise agreements, AWS Bedrock, Azure OpenAI). The vendor agrees never to log, persist or train on your inputs and outputs; requests are processed strictly in memory and discarded once the response is generated. They typically require enterprise contracts and minimum spend, and they protect the API path — a consumer desktop chat session is usually not covered.

6

Why you want both

Here is the mix-up this page exists to fix: the promise does not do the disguise’s job. Under ZDR the real names still cross the wire and sit in the vendor’s memory, which some privacy laws forbid regardless of what happens afterwards. And the disguise alone is heavy: the swapping machine must be built, maintained, and tuned so it masks neither too much nor too little. So production systems do both — the disguise protects your customers, the promise protects your business.

Three panels. The promise alone: good but not enough, the real name still crosses the wire into the vendor's memory, marked with a red cross. The disguise alone: strong but heavy work, a wrench for the build cost and a missed name, Jon D., slipping past. Both together: code names plus the signed contract earn a green tick, belt and braces. Caption: the disguise protects your customers, the promise protects your business.
Under the hood

ZDR’s limits: it prevents retention and training use, but PII is still transmitted and processed in the provider’s memory in real time, which can fail strict regimes that ban processing PII on unapproved processors at all; and it needs an enterprise contract.

Redaction’s limits: real engineering cost (OCR/NER pipelines, vault state management), plus the twin failure modes: over-redaction masks financial terms the model needed and ruins context; under-redaction lets an edge-case name through.

The recommendation for production financial systems: redact locally so personal attributes never cross the network, and back it with a ZDR agreement so the operational data that does travel is never logged or trained on.