Journal

Soliloquy journal

AI Companion Privacy Checklist

Use this AI companion privacy checklist to review storage, model providers, training terms, analytics, retention, exports, deletion, and account safety.

Before using an AI companion, check what conversation data is stored, which model provider receives it, whether training use is addressed, how long records remain, and whether you can export and delete your data. If a privacy page does not answer one of those questions, treat the answer as unknown rather than assuming the safest outcome.

AI companion chats can become more personal than ordinary search queries. A warm interface does not change the underlying data flow: text may pass through the companion app, its database, a model provider, and operational systems needed to deliver the reply.

The short AI companion privacy checklist

Review these points before sharing anything sensitive.

  1. What account, profile, character, conversation, and usage data is stored?
  2. Which company runs the language model, image model, or voice service?
  3. Does the policy clearly address model training or improvement use?
  4. Do analytics include message text, prompts, memory, or exact page identifiers?
  5. Is personal data sold or shared, and for what purposes?
  6. What are the retention periods for content, logs, and backups?
  7. Can you export conversations and permanently delete the account?
  8. Are public characters separate from private conversations?
  9. What happens when you connect your own provider key or external channel?
  10. Is the service appropriate for your age and risk level?

A policy does not need to use those exact headings. It should still let you answer the questions in plain language.

1. Separate account data from conversation content

“We collect data needed to run the service” is too broad to evaluate. Look for categories.

Account data may include:

  • email address and profile settings,
  • subscription, credit, or payment status,
  • device, version, and sign-in records.

Companion content may include:

  • character profiles and instructions,
  • conversation messages,
  • generated images or audio,
  • summaries, saved facts, and pinned memories,
  • files or text you intentionally upload.

Operational data can include request timing, success or failure categories, abuse signals, and error diagnostics.

These categories have different sensitivity and retention needs. A product may reasonably keep an account email while the account exists, retain raw diagnostics for a short period, and let a user delete a conversation independently.

2. Identify every connected service

The companion app may not generate the reply itself. It can send the context needed for your request to a language-model provider. Image, voice, payment, authentication, and messaging features may involve other providers.

Check:

  • whether the provider is chosen by the app or by you,
  • what content must be sent to complete the request,
  • whether your provider account or API key changes the terms,
  • whether a connected messaging channel keeps its own copy,
  • where to find each provider's privacy terms.

“Bring your own key” does not mean no data leaves the device. It usually means requests go to the provider selected by the user, using their credentials. The provider still needs the prompt or content required to generate the response.

Never paste a wallet seed phrase, private key, password, recovery code, or provider secret into a companion conversation.

3. Look for an explicit training answer

Storage and model training are different questions. A service can store a chat so you can reopen it without using that chat to train a model. A connected provider may have its own improvement or retention terms.

Look for a direct statement covering:

  • the companion product itself,
  • hosted model providers,
  • bring-your-own-key providers,
  • optional feedback submissions,
  • whether a setting or account type changes the rule.

If the policy says only that data is used to “improve services,” do not translate that into a stronger promise. Ask support or avoid submitting material that depends on an unstated restriction.

4. Check whether analytics contain content

Analytics can measure whether a page opened or a request failed without recording what the user wrote. A useful policy distinguishes product events from conversation content.

Ask whether analytics include:

  • raw messages or prompts,
  • companion memories or profile text,
  • search text,
  • conversation, character, or user identifiers,
  • exact URLs containing private IDs,
  • payment proof or wallet addresses,
  • raw error messages that might echo user content.

Also check whether analytics are sent to a third-party SDK or kept within the service's own systems. “Anonymous” is less informative than a list of fields excluded from collection.

5. Understand sharing and selling

A service may need vendors to host data, deliver model responses, process payments, or investigate abuse. That is different from selling personal data or sharing it for advertising.

The policy should explain the main purposes for disclosure, such as:

  • operating contracted infrastructure,
  • completing a user-requested model or payment action,
  • investigating fraud, abuse, or security incidents,
  • complying with a valid legal request,
  • protecting users and others from harm.

Absolute language deserves careful reading. “We never share data” is unlikely to describe basic hosting and legal obligations. A narrower promise such as “we do not sell personal data” can be clear while still acknowledging necessary processors.

6. Compare retention periods

Do not look for one universal number. Services often retain different records for different lengths of time.

Check separately for:

  • account content while the account remains active,
  • deleted conversations or characters,
  • backups and recovery copies,
  • security and abuse records,
  • raw product events,
  • diagnostic records,
  • aggregated daily or monthly statistics.

Deletion may remove active account data while limited backup or security copies expire later. The policy should say so instead of promising that every byte disappears instantly.

7. Verify export and deletion controls

A privacy page should identify actions you can actually take.

Look for:

  • export of your account data in a usable format,
  • deletion of individual conversations or characters,
  • permanent account deletion from inside the product,
  • a support route when self-service controls fail,
  • a warning about what cannot be recovered.

Before deleting an account, run the export and open the downloaded file. A “download complete” message is not enough if the file is empty, incomplete, or unreadable.

Deletion is also not the same as hiding a conversation from the sidebar. Confirm whether the action removes the underlying content or merely archives it.

8. Distinguish public characters from private chats

AI character products often combine a public catalog with private conversations. The permissions should be separate.

A public character page may expose the character's name, introduction, scenario, creator attribution, image, or opening message. It should not make another user's conversation, companion memory, or personal profile public.

When creating a character, check the default visibility and review the rendered public page. Do not put private instructions, personal contact details, or secrets into fields intended for public discovery.

For Soliloquy specifically, published and approved character records form the public catalog. Conversations, messages, companion memory, and user personas remain account-private. Our character-page audit explains why public approval and search indexing are still treated as separate decisions.

9. Protect the account around the chat

Privacy controls cannot protect an account someone else can open.

  • Protect the email account used for sign-in.
  • Use provider-specific security controls for connected model accounts.
  • Do not share API keys between people or paste them into chats.
  • Review active external channels and disconnect ones you no longer use.
  • Treat exported data as sensitive; store or delete the file deliberately.
  • Contact support if you suspect account access or an unfamiliar connection.

No online service can promise absolute security. Your decision should account for both the service's safeguards and the sensitivity of the material you choose to submit.

What Soliloquy's current policy says

We reviewed the public Soliloquy Privacy Policy against the checklist above. As of September 3, 2026, it says:

  • account details, created characters and settings, saved conversations, generated content, usage, and balance records may be stored to operate the product;
  • personal data is not sold;
  • product analytics do not contain conversation or reply text, prompts, memories, entered text, provider keys, exact URLs, dynamic page IDs, or raw errors and stacks;
  • no third-party analytics SDK is used;
  • connected model, image, voice, and payment services handle the information needed for a requested action under their own terms;
  • raw product events, narrow reply diagnostics, client faults, server metric buckets, and summaries have stated retention periods;
  • users can export account data, delete individual content, and permanently delete the account inside Soliloquy;
  • the service is intended only for adults 18 and older.

The current policy does not make one blanket promise about the training practices of every third-party model provider. It tells users that connected services operate under their own terms. If provider training or retention is a deciding factor, review the selected provider before sending a request.

Read the current Soliloquy Privacy Policy and Terms of Service directly. The live legal pages, not this article, are the controlling text and may change as the product changes.

How we reviewed the checklist

We mapped each question to a concrete public-policy section, then checked the current product paths for data export, individual content controls, account deletion, private conversation ownership, public-character visibility, and connected-service disclosure.

That comparison also exposed the unanswered provider-training question above. We left it as an explicit limitation instead of inferring a promise from unrelated analytics language. This is the standard to use on any companion service: confirm what the policy actually says, test that the promised controls exist, and label missing answers as unknown.

For a closer look at what a companion may save inside a private conversation, read how AI companion memory works.