Most chatbots built today aren't built from scratch. They're a product layer, a system prompt, some retrieval logic, a chat interface, sitting on top of a third party large language model API: OpenAI, Anthropic, Google, or a similar vendor. That architecture creates a privacy disclosure problem a standard web privacy policy doesn't anticipate: every message a user types gets sent to a company that isn't yours, processed by a system whose training and retention practices you don't control, and a policy that only describes what your own servers do is describing half the data flow.
Map where a message actually goes before you write anything
A single chat message from a user can touch several distinct systems, each with its own data handling:
Two separate retention clocks are running here, one your own systems control, and one the LLM vendor controls under its own terms, and a policy that only addresses the first one leaves out exactly the part a privacy-conscious user is most likely to ask about: "does the AI company get to keep what I typed."
Whether the vendor trains on your data is a specific, checkable fact
This is the single most consequential disclosure decision in the whole policy, and it isn't optional or a matter of house style, it's a fact about the specific vendor and API tier you're using. Major LLM API providers generally distinguish their developer-facing API products from their consumer-facing chat apps: as a matter of policy, several leading providers state that data submitted through their API platforms is not used to train their models by default, while data submitted through the free consumer chat product may be used for training unless the user opts out in account settings. Terms like this change, and they differ by vendor and by product tier within the same vendor, so the only responsible approach is to read the current data usage terms for the exact API and tier your product actually calls, and disclose that specific answer rather than a general assumption either way.
Self-hosted / first-party model vs. third-party LLM API
| Self-hosted model | Third-party LLM API | |
|---|---|---|
| Where chat data is processed | Your own infrastructure | Vendor's infrastructure |
| Vendor may use data for training | Not applicable | Depends on vendor terms and tier |
| You control retention period | Only your own copy, not vendor's | |
| Separate vendor privacy disclosure needed |
Chat log retention: your copy and the vendor's copy are different questions
Beyond whatever the model vendor retains under its own terms, most chatbot products keep their own copy of conversations, for debugging, quality review, abuse monitoring, or to give the chatbot memory of earlier turns in a session. The policy needs to state, separately from anything said about the vendor: how long your own systems retain full conversation logs, whether logs are reviewed by human staff (a common practice for quality assurance, and one users are frequently surprised by if it isn't disclosed), and whether logs are de-identified or aggregated before being used for any secondary purpose like product analytics.
A chatbot that stores full conversation transcripts indefinitely, with no stated retention limit, is a common and avoidable gap, since a short, defined retention window, deleted or anonymized after a stated number of days, is both a better privacy practice and a much easier thing to write an accurate policy sentence about.
Giving users a real control, not just a disclosure
A policy that accurately describes training-data use is still incomplete if it doesn't also say what a user can actually do about it. Consumer-facing AI chat products increasingly ship an account-level toggle for training-data use, letting a user opt out of having their conversations used to improve the underlying model, separate from whatever the product's default setting is. If the chatbot you're building sits on top of a consumer product with a setting like this, or offers its own equivalent toggle, the policy should point users to it by name rather than describing training-data use as a fixed, unchangeable fact. If no such control exists, that's worth stating plainly too, since a policy that implies control the product doesn't actually offer is arguably worse than one that's silent on the point.
Sensitive information users type into a chat window
Unlike a structured form with defined fields, a chatbot's open text input means users can type anything, including health information, financial details, or other sensitive categories of data they wouldn't necessarily put in a signup form. The policy should address this directly: whether the product has any filtering or handling process for sensitive information typed into chat, what happens to it if not (it flows through the same pipeline as any other message, to your logs and the vendor's API, unless specifically filtered), and, if the chatbot is used in a regulated context like health or finance, whether any additional safeguards apply.
What the policy needs to include, pulled together
- The name of the specific third-party LLM API vendor or vendors used, not a vague reference to "AI technology."
- Whether that vendor uses submitted data to train its models, based on the vendor's own current terms for the specific product tier in use.
- How long your own systems retain conversation logs, and whether they're reviewed by staff or used for analytics.
- Whether logs are de-identified or aggregated before any secondary use.
- How a user can request deletion of their chat history, matching the same data-subject-rights mechanisms, GDPR erasure, CCPA deletion, the rest of your policy already promises.
- A note that users shouldn't submit sensitive personal information they wouldn't want retained, if the product has no specific filtering for it.
Keep the disclosure current as the underlying model changes
LLM vendors update their data usage terms, add new model versions, and sometimes change default training behavior with little notice. A chatbot's privacy policy is one of the faster-moving sections of a company's overall privacy documentation as a result, and it's worth checking the vendor's current API data usage terms at each model or vendor swap, not just at initial launch, the same discipline a mobile app needs when an SDK or ad network changes mid-release.
Our Privacy Policy Generator builds AI and chatbot-specific disclosure language, third-party processor identification, training-data use, and retention, into a policy scoped to how your product actually processes conversations. For a broader look at how privacy policies across the web are handling AI disclosures generally, see How Many Privacy Policies Mention AI Training, and for the equivalent process on a mobile app's own third-party SDK disclosures, How to Write a Privacy Policy for a Mobile App covers the same underlying discipline outside the chatbot context.
The information in this article is for informational purposes only and should not be construed as legal advice on any matter, and does not create a lawyer-client relationship.
