What leaves the building

Draw the boundary before the pilot

Every automation that calls a hosted model exports data. Somebody will eventually ask what, to whom, and under what terms, and the answer should not be assembled in a hurry.

Four questions, answered from the provider’s current terms rather than from memory, because these terms change:

1. Is our data used for training? Business and enterprise tiers generally say no by default; consumer tiers frequently say yes unless you opt out. The gap between those two sentences is where most organisational trouble starts, because somebody piloted on a personal account.
2. Where is it processed? Region matters if any contract or regulation names one.
3. How long is it retained? Many providers keep inputs for a period for abuse monitoring even when they do not train on them. Zero-retention arrangements exist on some enterprise agreements; they are not the default.
4. Who at the vendor can read it, and under what process?

Write the answers down with the date you checked. That page is what your security review needs, and it takes twenty minutes.

Minimisation beats everything else

The strongest control is also the simplest: send only the fields the task requires.

An agent classifying a complaint needs the complaint text. It does not need the account number, the card’s last four digits, the date of birth or the full address that happened to be in the same record. A model summarising a meeting needs the transcript, not the attendees’ phone numbers.

This is verifiable in a way that most privacy controls are not. You can read the function that builds the payload and see exactly which fields it takes. You can write a test asserting that no other key appears. Nobody can do the equivalent for a redaction model.

Build the request from an explicit field list, never by serialising the whole record and hoping.

Redaction reduces exposure and does not anonymise

Replacing names with placeholders before sending, then restoring them afterwards, is a useful technique. Microsoft Presidio does it as a free library; spaCy’s named-entity models underneath it are free too.

Now the honest part, because this gets oversold and the oversell causes real harm.

Entity recognition misses things. It misses non-Western names more often than Western ones, because that is what the training data over-represents; so the population your redaction protects least is frequently the population that most needs it. It misses identifiers embedded in prose (“the chap from the Bandra branch who joined in March”). And even perfect name removal does not anonymise: a record with a postcode, a date of birth and a job title identifies a person in a small population without naming them. Combinations of quasi-identifiers re-identify, which is the finding behind decades of work on this and the reason regulators treat pseudonymised data as personal data.

So describe it accurately: redaction is defence in depth. It lowers what a leak exposes. It does not convert personal data into non-personal data, and any policy document that claims it does is inviting an unpleasant conversation later.

The local option is real

A 7-to-14-billion-parameter model running on your own hardware never sends anything anywhere. Ollama makes this a two-line install; llama.cpp runs on a laptop CPU if you are patient and on modest consumer GPUs comfortably.

The honest trade: on classification, extraction, routing and rewriting, a small local model is often close enough that the difference does not change the decision. On hard multi-step reasoning and long documents, the gap to a frontier model is still large. That gap is the thing to measure on your own data rather than argue about, and if a local model clears your threshold, an entire category of data-boundary problem stops existing.

A hybrid is often best: local model for the ninety per cent of records that are routine, hosted model for the escalations, with the escalation path minimised to the fields it needs.

The copies you forgot

Your traces hold everything the agent read. Your error reports hold the payload that failed. Your prompt-caching layer holds recent inputs. Your evaluation fixtures may hold real customer records that somebody copied in during a busy week.

Every one of those is in scope for the same terms and the same deletion requests as the database. Put the trace store, the fixture set and the error logs on the retention schedule, and be able to demonstrate that a deletion request reaches all four.

One page, drawn

Source, fields sent, processor, retention, deletion trigger. One line per flow. It fits on a page, it survives a change of staff, and it is the artefact that turns “are we allowed to do this” from a week of meetings into a five-minute read.