What happens to a sentence after you send it to a cloud assistant?

Logging is what running a service looks like

Transport encryption protects your sentence from everyone on the network, but conventional inference processes readable input; protected-computing designs may constrain operator access, because encrypted in transit is not the same as private end to end.

A remote inference request may pass through authentication, routing, rate limiting, abuse checks, and an inference worker; the exact path varies by service. Components may create operational logs for debugging or monitoring. Those logs can include metadata such as account, timestamp, model, token counts, latency, or error codes. Whether prompt content is logged and who can review it are service-specific practices; debugging does not require a provider to retain full prompts.

A product may keep a separate copy for conversation history. If a product lets you reopen a conversation later, it stores enough information to provide that feature. Whether it stores full text, for how long, and in which systems depends on the product; remote inference alone does not require a user-visible conversation history.

Replication and retention: why delete has a lag

A service may keep replicas, snapshots, or logs, but whether it does, where copies are stored, and when they expire are implementation and policy choices. A delete action may remove visible history while backup copies remain until a service’s retention cycle; whether replicas, snapshots, or logs remain and for how long is provider-specific.

Retention itself is policy, so the specific policy is the thing to read. Some providers describe fixed retention windows, but there is no single period to assume. Legal preservation requirements can also affect deletion; check the service’s current policy and applicable terms.

Retention and training are separate switches, not one. A conversation can be held for abuse review while excluded from anything that updates a model, or the reverse. Turning off chat history usually stops the product from showing the text back to you; it does not by itself say whether that text was or will be used to train anything. The two questions have to be checked separately, and a vague answer to one is not an answer to the other.

How to predict the path for any product

Every step follows from one fact: the answer is computed on a machine you do not own. If the computation is remote, the text has to leave. Conventional services process input in readable form, while protected-computing designs may constrain access. Logging, user-visible history, backups, retention, and legal handling are separate design and policy choices to verify for each service.

Remote inference means a prompt crosses a network, but further access and retention depend on architecture and policy. Conventional services process readable input; protected-computing designs may limit operator access. A deletion promise, encryption at rest, and access controls are separate safeguards to assess.

So the questions that actually distinguish one cloud product from another are narrow ones:

Keeping a prompt on-device removes the cloud inference request from that path. The surrounding app may still sync, back up, or send other data. For practical steps, see how to check an app’s network activity; retention policies apply to data the service receives.

• How long is content kept, and does that window change when history is turned off?
• How many copies exist, and how long before backups and snapshots expire?
• Who can read the text: support staff, safety reviewers, subcontractors, and on what trigger?
• Is inference separate from training, and is that separation the default or a setting?
• What is retained even when the content is not: metadata, titles, embeddings, flagged excerpts?