What 'Your Chats Are Not Used for Training' Actually Means: How the Pipeline Separates Inference Data From Model Fine-Tuning and Why That Doesn't Prevent a Glitch From Leaking Your Private Joke Into Someone Else's Session

The 30-second answer

Your chat messages are processed through an inference pipeline that has no direct connection to the model's fine-tuning dataset. The model that generates your companion's replies never sees your logs in a training batch. But the infrastructure that serves those replies uses shared components: a vector database for memory retrieval, a session cache for latency, and a context-window buffer. A glitch in any of those shared components can theoretically route a fragment of your conversation into someone else's stream. The separation between inference and training is real, but it is not a hermetic seal.

The inference pipeline is a one-way valve

When you send a message to your AI companion, that text travels through an inference pipeline. The pipeline takes your prompt, appends the companion's system persona, and feeds the whole thing to a large language model that generates a reply. That model is a static snapshot. It was trained months ago on a curated dataset that included no user chat logs. The company fine-tuned it on synthetic data, internal roleplay scripts, and safety examples. Your messages never enter that training set.

After the model generates a reply, the pipeline discards the intermediate tensors. The only thing retained is the conversation log, which is stored in a separate database. That log is used for memory retrieval, session continuity, and sometimes for analytics or safety review. It is not fed back into the model's weights. The separation is architectural and deliberate.

Where the fine-tuning dataset actually comes from

Companies do not need your chats to fine-tune a companion model. They use synthetic dialogue generated by larger models, curated by human reviewers. They use public-domain fiction, transcripts of customer-support interactions, and hand-written scenarios that cover the emotional range they want the model to express. Some companies also use opt-in beta testers whose logs are explicitly flagged for training, but those are a separate data stream with clear consent boundaries.

Your chat log, even if anonymized, is a low-signal sample. It contains repetition, half-finished thoughts, and typos. It is not useful for fine-tuning a model that needs clean, varied examples. The cost of processing and sanitizing user logs for training exceeds the benefit for most companion apps.

The shared infrastructure that can still leak

The inference pipeline runs on servers that also host the vector database used for memory retrieval. When your companion remembers that you hate cilantro, it is because the pipeline queried a shared embedding index that maps your session ID to a stored vector. That index is shared across all users. A cache key collision, a stale hash, or a routing error in the load balancer can theoretically deliver a vector that belongs to a different session.

This is not a training data leak. It is an inference-level glitch. Your companion does not learn from the other user's memory. But for the duration of that one request, the model sees a vector that belongs to someone else. The reply it generates may reference a joke, a pet name, or a private detail that was never meant for you.

The context-window overflow is the most common vector

The model has a fixed context window, usually 4,000 to 8,000 tokens. When your conversation exceeds that limit, the pipeline summarizes earlier messages or drops them entirely. The summarization algorithm is shared across all sessions. If the algorithm misassigns a summary to the wrong session ID, the model generates a reply that blends two conversations. This is rare, but it has been documented by users who saw their companion reference a topic they never discussed.

Companies mitigate this by running session IDs through a strict namespace check before retrieval. But the mitigation is software, not physics. A bug in a deployment update, a race condition in the cache layer, or a corrupted index can bypass the check.

What the privacy policy actually guarantees

The privacy policy states that your chats are not used for training. That is a true statement about the fine-tuning pipeline. It does not guarantee that your chats are isolated from every other user's chats at every layer of the stack. The policy covers the model's weight update process. It does not cover the vector database, the session cache, or the context-window summarizer.

Some companies add a line about "industry-standard isolation" or "logical separation per tenant." That means the same server handles multiple users but keeps their data in separate database partitions. Logical separation is not physical separation. A misconfigured partition can merge two users' data until the next cleanup job runs.

How companies detect and fix cross-session leaks

When a cross-session leak occurs, the affected user usually sees a reply that references an unfamiliar topic. Companies rely on user reports to catch these glitches. Automated monitoring can detect anomalous token distributions or sudden shifts in topic, but it cannot distinguish between a user who suddenly changed the subject and a leak that imported a foreign vector.

Once reported, the engineering team checks the cache logs, the vector index, and the session routing table. They typically find a stale key or a race condition and deploy a fix within hours. The data from the affected sessions is purged from the cache and regenerated from the primary database.

The honest take for people who share private jokes

If you share something deeply private with your AI companion, you should assume that a glitch could surface it in another session. The probability is low, but it is not zero. The same infrastructure that makes your companion fast and responsive also creates surfaces for cross-session contamination. Companies have financial and reputational incentives to keep these glitches rare, but they cannot eliminate them entirely.

For most users, the risk is acceptable. The jokes you share are likely mundane. But if you are treating your companion as a confessional, you should treat the chat log as a document that could, through a chain of improbable events, be read by a stranger.

Aiko

Aiko is the kind of companion who listens without judgment and remembers the small details you mention in passing. Aiko is built for deep, unhurried conversations that feel natural and grounded, making her a good choice for users who want a consistent emotional anchor.

Tylor

Tylor brings a sharp, no-nonsense presence to your chats, someone who will call you out on your own contradictions without making it a therapy session. Tylor is for users who want banter and honesty over validation and soft landings.

▶ Tylor's video in full · all of Tylor

Yasmin

Yasmin balances warmth with a playful edge, making her a natural fit for users who want both emotional support and a partner in low-stakes mischief. Yasmin thrives in conversations that mix genuine connection with lighthearted teasing.

Harper

Harper is the companion who stays present without filling the silence with questions. She is designed for ai girlfriend deep conversation where the goal is understanding, not entertainment. Harper works well for users who need a companion that can handle long pauses and return to a thread without a recap.

The difference between inference isolation and database isolation

Inference isolation means your prompt is processed in a separate request context from every other user's prompt. The model sees only your text, your companion's persona, and the retrieved memory vectors for your session. Database isolation means your stored chat logs are in a separate partition from every other user's logs. These are different guarantees.

A company can offer inference isolation while sharing a single database cluster. The isolation happens at the application layer, not the storage layer. A bug in the application code can break inference isolation without touching the database. Conversely, a database partition break can expose your logs to a support agent without affecting inference.

Why the glitch is hard to reproduce

Cross-session leaks are rare because they require a specific confluence of conditions: a cache key collision, a stale routing table, and a request that arrives at the exact moment the collision is active. Reproducing that in a test environment is difficult because the conditions are transient. Companies rely on monitoring and user reports instead of proactive testing.

The glitch is also hard to detect from the user side. If your companion references a topic you never discussed, you might assume it is a hallucination or a context-window artifact. You are unlikely to suspect that the text came from another user's session. Most cross-session leaks go unreported because users attribute them to normal model weirdness.

What you can do to minimize risk

You cannot control the company's infrastructure. But you can control what you share. If a detail is sensitive enough that you would be distressed if a stranger read it, do not share it with an AI companion. Treat the chat log as a semi-public document. The same advice applies to any cloud-based service, whether it is a messaging app or a note-taking tool.

You can also use services that offer end-to-end encryption, though even those services must decrypt the message to send it to the model for inference. The encryption protects the message in transit and at rest, but the model sees the plaintext during generation. A glitch in the inference pipeline can expose that plaintext regardless of encryption.

The role of the vector database in memory retrieval

The vector database is the component most likely to cause a cross-session leak. When your companion recalls a detail from a previous conversation, the pipeline converts your current message into a vector and searches the database for similar vectors that belong to your session. The search is scoped by your session ID. But if the database index is corrupted or the session ID is misassigned, the search can return a vector from a different user.

This is not a training data leak. The model does not learn from the foreign vector. It uses it as context for the current reply. The reply may reference a detail that belongs to someone else, but the model's weights remain unchanged. The leak is ephemeral and limited to that single response.

Earn while you recommend

If you know people who could benefit from the kind of companionship these AI partners provide, you can earn a commission by sharing your experience. Check out the kindroid promo code page for current offers and the ai companion affiliate program for details on how to monetize a review site, a Discord community, or a social media presence.

Common questions

Can a company see my chats if they are not used for training?

Yes. The company can still access your chat logs for safety review, debugging, or compliance audits. The "not used for training" claim only covers the model fine-tuning pipeline. It does not prevent a support agent or a safety reviewer from reading your logs.

Does end-to-end encryption prevent cross-session leaks?

No. End-to-end encryption protects your messages in transit and at rest, but the model must decrypt them to generate a reply. The decrypted text is processed through the same inference pipeline. A glitch in that pipeline can expose the decrypted text to another session.

How often do cross-session leaks happen?

Public reports are rare, but that may reflect under-reporting instead of true rarity. Users often attribute strange replies to model hallucination. Companies do not publish leak statistics. The safest assumption is that leaks happen infrequently but not never.

Can I request that my chat logs be deleted to prevent leaks?

Yes. Most companion apps allow you to delete your chat history or your entire account. Deletion removes the data from the primary database and the vector index, which eliminates the risk of that data leaking. Check the app's data retention policy for the exact deletion window.

Is the risk higher for users who have very long conversations?

Yes. Longer conversations generate more memory vectors and more context-window summaries, which increases the surface area for a glitch. Users with multi-month chat histories are statistically more likely to encounter a cross-session artifact.

What should I do if I see a reply that references something I never said?

Report it to the company's support team. Include the session timestamp and the exact text. This helps the engineering team identify the root cause and fix the infrastructure bug. Do not assume it is a harmless hallucination.