A security questionnaire comes back from a vendor with the encryption row ticked: in transit and at rest, both yes. Someone reads that as clearance for sensitive data. It is not, and the gap between those two statements is where a lot of AI risk assessments quietly go wrong.
Encryption is a real control against a real threat. Just not this one.
What encryption does cover
Cloud services apply encryption in two standard places, and each does exactly one job.
In transit. Traffic between your browser and the provider's server travels over an encrypted connection. Anyone listening on the café network sees that you are talking to a service, not what you said. This is the padlock in the address bar, and it works.
At rest. Data sits encrypted on the data centre's disks. Anyone who removes a drive or obtains a backup tape gets nothing usable. This also works, against that scenario.
Both protect against an outsider. Neither protects against the party holding the key, which is the provider.
Why the recipient has to read it
Here is the part rarely made explicit.
A language model computes on your text. It splits it into tokens, maps those to numbers, and calculates the next token from them. That cannot be done on ciphertext: well-encrypted data is by design indistinguishable from noise, and there is nothing to compute on noise.
So the moment your message arrives, it is decrypted. It sits readable in server memory during processing, and afterwards it is usually stored so your history works. None of this is underhanded. It is the only way the service can function.
Which is also why an AI assistant cannot be end-to-end encrypted the way a messenger is. Under end-to-end encryption only the recipient can decrypt and the intermediary cannot. With an assistant, the intermediary is the recipient. There is nobody else at the other end.
The same misreading in a different setting appears in WhatsApp at work: encryption protects the transport, not the recipient, the device, or the question of whether the message should have been sent.
What happens to the decrypted text
Once decrypted, all the ordinary rules of the service apply:
- The conversation is stored, with a retention period. See what a chat history actually is.
- On suspicion of abuse, provider staff may review it.
- On a consumer account it is used for training by default unless you opt out.
- Under a preservation order it can be retained even after you delete it.
Encryption changes none of these four. They sit alongside it, and together they matter more to your assessment than the encryption row does.
Is there technology that fixes this?
Work is happening, and it is honest to say it is not yet practice.
Homomorphic encryption makes computing on encrypted data possible in principle, but remains orders of magnitude too slow for large language models. Secure enclaves (a walled-off region of the processor that even the operator cannot inspect) are being used by some providers for parts of their pipeline, and that is a genuine improvement. It is a different thing from end-to-end encryption, and what falls inside the boundary varies per vendor.
The working rule for now: in an assessment, do not assume the provider cannot read your text unless they document precisely how that has been closed off.
What does help
Two things, both less tidy than a tick on a form.
The first is processing that never leaves the device. What stays on your own machine needs no protection in transit, because it is not in transit. That is a real difference, with real trade-offs, set out in on-device or cloud.
The second is the text itself. Less sensitive data in the prompt means less sensitive data sitting decrypted on a server, however well that server is defended.
Not a thrilling conclusion, and the only one that holds independent of vendor, tier and year. Encryption governs how your text travels. What is in it stays a decision made by the person typing.
