If it’s encrypted, why isn’t that the same as private?

Data has three states. Encryption normally covers two.

Data is either moving, sitting still, or being worked on. Encryption in transit protects the first. Your words are scrambled between your phone and the server, so the network in between cannot read them. Encryption at rest protects the second. The disks the data lands on are scrambled, so a drive pulled out of a rack is useless on its own.

The third state is the one that decides privacy. Conventional computation processes readable input, but specialized designs can change who can access it. Confidential computing uses a protected hardware region; homomorphic encryption can perform some operations on ciphertext. Almost every claim that data is encrypted is a claim about the two states on either side of that.

• In transit. Protected between your device and the server. Standard, and worth having.
• At rest. Protected on the disks it is written to. Also standard.
• In use: transport and disk encryption alone do not protect input while ordinary server software processes it.

Where conventional inference decrypts a request

End-to-end encryption is a real guarantee, and it holds. The keys live on the endpoints, the server sees only ciphertext, and the operator can deliver a message it cannot read. That works because delivery does not require comprehension. The server’s job is to move bytes from one device to another, and bytes are allowed to be opaque.

Conventional inference decrypts a request where the model runs. Who can access readable input depends on the system; confidential-computing and supported encrypted-computation approaches have different trust models and limits.

Who holds the key decides what the lock is for

A lock is only as private as its key. When a provider encrypts data at rest with keys it manages, the encryption defends against a stolen drive, a mislaid backup, or an attacker holding the disk but not the system. It does not by itself prevent service components from accessing data or determine what happens under legal process; key custody and system design matter.

Encryption also says nothing about time or purpose. A sentence can be encrypted on the wire, encrypted on disk, written to a debug log, retained for a year, replicated across regions, and used to train the next model. All of that is compatible with the words “we encrypt your data.” Retention, access and reuse are separate questions that need separate answers.

Can a server compute without reading? Sometimes, at a price.

Two approaches attack the in-use problem directly. Confidential computing decrypts data inside a protected region of the processor that the operating system and the hypervisor cannot read, and the chip can attest to which code is running there. The plain text still exists. What moves is the thing you have to trust: a hardware vendor and the correctness of that silicon, which researchers have repeatedly worked around through side channels.

Fully homomorphic encryption goes further. It allows certain computations to run on ciphertext without ever decrypting it, and the math is sound. The cost is speed. General-purpose computation under it is orders of magnitude slower than the same work on plain data, which is why it shows up in narrow, high-value operations rather than as the runtime for a whole language model.

Keeping readable input on your own hardware

Keeping inference on hardware you control removes the conventional cloud inference request from that path. Other architectures, such as configured confidential computing or supported encrypted computation, use different trust models and have their own limits. The prompt may be readable to software on the device, and the surrounding app may still use a network for other features.

This is not a claim that a phone is invulnerable. The words are readable in memory while they are being used, and the device’s own protections still matter. What changes is who else is in the sentence. The surrounding app may also use a network for sync or other functions.