Where Do AI Companion Chats Actually Go?

The chat box makes a private conversation look simple. You type a sentence, press send, and a reply appears. Behind that small exchange there may be several different systems, each with its own reason to receive, store, or inspect part of what you wrote.

That matters more with an AI companion than with an ordinary search box. People often tell a companion about their relationships, health, fears, routines, and private fantasies. Before you share any of that, it is worth knowing where the message can travel.

A chat message crosses more trust boundaries than the interface shows

The short version: A typical cloud message can move from the app to a company server, then to an AI model provider, while separate systems handle safety, analytics, storage, and support.

The first stop is the client application. That is the desktop or mobile program where you type. The app may add account identifiers, device information, language settings, conversation IDs, or other metadata before it sends anything. The message you see is only one part of the request.

The next stop is usually the service’s backend. It authenticates your account, applies product rules, decides which model should answer, and records enough information to show the conversation again later. Even if a company uses a third-party model, the request normally passes through its own infrastructure first.

The backend can then send the prompt to an inference provider. That provider may be the same company, a cloud platform, or another AI business. The provider receives enough text to generate a response. Its retention and training rules may differ from the companion app’s policy, which is why a privacy policy should identify processors and not only the main brand.

After the response comes back, other systems may see an event rather than the whole conversation. Analytics can record that a message was sent, which feature was used, or how long generation took. A moderation system may scan the prompt and answer. Crash reporting may capture an error and a small part of the state around it. These systems do not all need the same data, but you should not assume that they receive none.

The model provider sees the prompt when inference happens in the cloud

The short version: If a remote model generates the answer, the text needed to generate that answer leaves your device and reaches a server outside your computer.

The exact consequences depend on the contract and policy for that service. OpenAI describes different controls for consumer and enterprise products on its consumer privacy page and enterprise privacy page. Those pages should not be treated as interchangeable. A promise made for an enterprise workspace does not automatically apply to a personal account.

The same distinction appears in companion services. Character.AI’s privacy policy lists user content, including chat communications, among the information the service collects. Replika’s privacy policy describes its own processing and also explains how some third-party providers are used.

The useful question is not simply, “Does the app use AI?” Every app in this category does. Ask instead:

• Which company receives the message that generates the reply?
• Is the message retained, and for how long?
• Is it used for model improvement, safety systems, or human review?
• Can the provider use a subcontractor?
• What happens when you delete the account?

If the policy answers only the first question, you do not have the full map.

Storage is a second system, separate from inference

The short version: A message can be deleted from the visible chat while copies remain in logs, backups, exports, moderation queues, or support systems for a stated period.

Generation and storage are related, but they are not the same operation. A service might send a prompt to a model provider without keeping the full text forever. It might also keep a conversation history so that your companion can remember it the next time you open the app.

Storage can exist in more places than the chat database. Product databases hold the conversation. Search indexes make old messages easier to retrieve. Backups preserve database snapshots. Error logs record failed requests. Moderation tools may retain items that triggered a review. Customer support systems may contain a copy if you pasted a conversation into a ticket.

This does not mean that every company keeps every copy forever. It means the phrase “I deleted the chat” needs a precise definition. Does it mean the row disappeared from the interface? Does it mean the primary database record was removed? Does it include backups and third-party processors? Good policies explain the difference.

The OWASP mobile storage guidance treats sensitive data storage as a separate security question. An application can have a secure transport path and still mishandle data on the device. The reverse is also possible. Privacy is a chain, not one checkbox.

People and contractors can become part of the path

The short version: A privacy policy should tell you whether staff, service providers, or reviewers can access content and under which conditions.

Human access is not the same as public exposure, but it is still part of the trust boundary. A support agent may need to inspect an account problem. A safety reviewer may need to examine a flagged message. An engineer may receive an error report while fixing a failed request.

The important details are the controls around that access: who can see the text, why they can see it, how access is logged, and how long the copy remains available. If the policy says “service providers” without explaining what they do, that is a reason to ask more questions before using the app as a diary.

OWASP’s Secrets Management Cheat Sheet is written for developers, but its basic lesson applies here. Credentials and access paths need to be managed, rotated, and limited. A company that cannot explain who can reach production data has not given you a useful privacy answer.

A privacy policy is a map, not proof

The short version: Read the policy, then compare it with the app’s actual network behavior and the controls exposed in the product.

Start with the policy. Find the sections about user content, retention, training, subprocessors, deletion, international transfers, and account closure. Write down each promise in plain language. “We may retain content to provide the service” is different from “we delete message content after generation.”

Then watch the product. On macOS, tools such as Little Snitch and nettop can show which processes make network connections. On Windows, GlassWire can show connection activity. Use the app for an ordinary conversation and note what connects, when it connects, and what the policy says about that destination.

A one-time connection during setup may be a model download or an update check. A connection on every message is more important to understand. A connection every few minutes while you are idle may be analytics, licensing, sync, or another background service. The destination alone does not prove what was sent, but it tells you where to ask the next question.

I wrote a full offline verification walkthrough and a separate explanation of what “runs locally” actually means. Both are useful because a narrow claim about the model does not always describe the whole application.

Local processing removes one large link from the chain

The short version: When the model and conversation stay on your computer, there is no cloud inference request for the ordinary chat, but local software still deserves normal security checks.

Local Waifu takes this approach for the core conversation. The model runs on your Mac or Windows PC, and the ordinary chat does not need a remote model server. The privacy policy describes the limited cases where an optional feature can use a network connection.

That architecture does not make a computer magically safe. Malware, stolen devices, weak backups, and careless exports still matter. It does remove one important trust boundary: a cloud database holding your private conversation is no longer required for the reply to appear.

That is the real question to ask of any companion app. Not whether the landing page uses the word private, but which systems must receive your message for the app to work. Once you can draw that map, you can decide what belongs in the conversation.

Frequently asked questions

Where does an AI companion message go?

With a cloud companion, a message can pass through the app’s backend, a remote model provider, storage, moderation tools, analytics, and backups. The exact path depends on the product.

Can an AI model provider see my conversation?

If the provider generates the response remotely, it receives the text needed to answer. Whether it stores or reuses that text depends on its policy and contract.

Does deleting a chat remove every copy?

Not necessarily. You need to check whether the product also removes logs, backups, moderation records, support copies, and data held by subprocessors.

How can I check whether an app connects to the internet?

Use a network monitor such as Little Snitch on macOS or GlassWire on Windows. Watch the app during setup, ordinary chat, and idle time.

Does Local Waifu send ordinary chats to a cloud model?

The core Local Waifu conversation runs on the user’s Mac or Windows PC. Optional network-based features are described in the privacy policy.

• OpenAI consumer privacy
• OpenAI enterprise privacy
• Character.AI Privacy Policy
• Replika Privacy Policy
• OWASP local storage testing
• OWASP Secrets Management Cheat Sheet

Questions people ask

Back to the blog