What You Must Not Send

Every safety idea in this course so far has pointed one way. Agents You Can Trust is about the outside world reaching your agent: injection, jailbreaks, a tool doing more than it should. Keep the attacker out.
This chapter is the opposite direction. Not what gets in, but what goes out. Every call you make ships text to a company on the other side of a network, and often the other side of a border. That text was your user's CV, your customer's support thread, your employer's unreleased contract.
Nobody attacked you. You sent it. That is the whole risk, and it is the one an engineer is most likely to create by accident, in a debug log, on a Tuesday.
In short: You are the controller for anything you send, so the duty is yours and not your provider's. Know where the compute physically sits, turn off training on your data in writing, and treat your own logs and vector indexes as the real exposure, because they usually are.
Every Call Is a Data Transfer
Start with the plainest version. A model API call takes your prompt, sends it over the network to someone else's machine, and that machine returns tokens. Between those two events your text existed on hardware you do not own, in a country you may not have chosen, handled by a company whose retention policy you probably have not read.
The model does not learn from it, which is worth saying because people fear the wrong thing. As established in What an LLM Actually Is, the model is frozen. Your prompt does not enter the weights.
The risk is not the model. It is the copies.

Count them on a normal feature. The request itself. The provider's logs. Your application logs. The transcript you saved so the user can resume. The chunks you embedded into a vector index for retrieval. That is five places one paragraph of personal data now lives, and you built four of them.
The Legal Part, In Plain Words
You do not need to be a lawyer, and you do need three facts, because they change how you build.
You are the controller. Under GDPR the party who decides why and how personal data is processed carries the duty. That is you. Your model provider is a processor acting on your instruction. Buying an API does not move the obligation, and "our vendor handles compliance" is not a defence anybody accepts.
You need a reason to send it at all. A lawful basis, a purpose, and no more data than that purpose needs. Sending a whole customer record because it was easier than selecting three fields is a real finding in a real audit, not a style opinion.
Deletion has to reach every copy. When a user exercises their right to erasure, the database row is the easy part. The vector index holding their embedded CV is personal data. So is the saved transcript. So is the debug log from March. If you cannot reach all of them, you cannot honour the request, and you find that out at the worst possible moment.
Data Residency: Where the Compute Physically Sits
Data residency is the question of which country your data is processed in, and it is a contract and architecture question rather than a technical one.
For a lot of European work the requirement is simple to state: personal data stays in the EU. That is satisfiable, because the major providers offer regional endpoints and data-processing terms that commit to it. It is also easy to break by accident, because the default endpoint is usually not the regional one, and a fallback provider added during an incident may sit somewhere else entirely.
Three things to get right, once, at the start:
- Pick the regional endpoint explicitly and pin it in configuration, rather than accepting a default.
- Sign the data processing agreement, and check what it says about sub-processors, because your provider has vendors too.
- Make sure your fallback path lands in the same region. A retry that quietly crosses a border is still a transfer.
Training on Your Data Is a Setting, Not a Promise
Most providers separate consumer products from API access, and API traffic is typically excluded from training by default. Typically is not a compliance answer.
Get it in the contract. Confirm the retention window for logs, which is often measured in days for abuse monitoring, and confirm whether zero-retention is available for your tier. Then write down what you confirmed and when, because the answer changes with the plan, the region and the model, and the version you checked a year ago is not the version you are running now.
The Rule That Survives Every Regulation
Regulations differ by country and change over time. This does not.
Send the minimum that makes the feature work. Not the record, the fields. Not the document, the paragraph. Not the whole transcript, the last few turns.
| Never in a prompt | Why |
|---|---|
| Credentials, API keys, tokens | You are pasting a secret into a log you do not control, and into yours |
| Full payment card numbers | Regulated separately and much harder. There is no good reason for a model to see one |
| Health, biometric, religious, political data | Special categories, higher bar, and rarely needed for the task at hand |
| Whole database rows or full user records | Almost always more than the task needs. Select the fields |
| Anything you would not paste into a shared document | The honest personal test, and it is right more often than the formal one |
Redaction before sending is cheap and works. Strip the identifiers, send the text, map the answer back on your side. Most features that look like they need personal data need the shape of it, not the identity.
Nobody Attacked You
Go back to the two directions. The guardrails chapter is about defending a boundary someone is pushing on. This chapter has no attacker in it at all.
The exposure is written by an engineer who wanted better debugging, or who passed the whole object because selecting fields took longer, or who added a fallback endpoint at 2am during an incident. All three are ordinary, reasonable moves. All three create a copy of somebody's data in a place with no policy attached to it.
So put the discipline where the mistake happens. Select the fields. Pin the region. Turn off training in writing. And go and read your own logs, because that is where you will find the thing you did not mean to send.