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 many 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
This is the part that is rarely spelt out.
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 messaging app 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.
Our article on WhatsApp at work covers the same misunderstanding in a different setting: 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 under way, but in all honesty it is not yet common practice.
Homomorphic encryption makes computing on encrypted data possible in principle, but remains orders of magnitude too slow for large language models. Some providers use secure enclaves (a walled-off region of the processor that even the operator cannot inspect) 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 by 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 keeps nothing. Text discarded right after the check never ends up decrypted on a disk at all. The questions to ask about that are set out in where your data goes.
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 an exciting conclusion, but the only one that holds regardless of vendor, tier and year. Encryption governs how your text travels. What goes into it remains the decision of the person typing.
