Chatbot Privacy: What to Collect, When to Ask, What to Keep

Apple's June developer update moved on-device AI from a platform demo toward an everyday app pattern. Its Foundation Models framework gives developers a native Swift API for AI features that run on-device, use image input, call server models when needed, and connect to custom skills — and DeepLearning.AI's Batch framed the shift plainly: privacy, offline behavior, and free local inference are becoming part of what users expect from AI software.

A website chatbot cannot copy that architecture, and mostly should not. It needs current product information, conversation logs for quality review, handoff context, and lead capture — cloud-shaped problems. But it inherits the expectation. When users get used to AI that says "this stays on your device," a chatbot that gates every answer behind an email field feels dated. The privacy bar is no longer set by your legal policy; it is set by the best AI experience your customer used that week.

You can meet that bar without local inference by answering the three questions in this article's title clearly: what to collect — the minimum the current answer needs; when to ask — after the bot has been useful, and only when the task requires identity; and what to keep — records your team can openly describe, stored outside the model prompt. Each question gets a section below, plus disclosure copy you can paste into your own widget.

What to Collect: Less Than the Workflow Knows

The practical privacy line most teams miss: what the system knows about the customer is not what the model should see.

A support workflow may legitimately hold a verified email, an account ID, a plan, and ticket history. The model prompt needs almost none of it. Here is the difference for one real question:

Contact record (stored for the team, never in the prompt):
  email: [email protected]
  plan: Pro (annual)
  open ticket: #4821

What the model sees for "How do I export my data?":
  - the last 6 messages of this conversation
  - "user is on the Pro plan"
  - retrieved source: "Exporting your data" help article

The model gets the plan name because the export flow differs by plan. It does not get the email address, because no part of answering the question requires one.

A clean design separates three layers:

This separation matters more as chatbots gain memory. A returning visitor should not have to repeat everything, but the bot also should not narrate the customer's history back at them — the chatbot memory guide calls this the line between removing friction and performing surveillance.

Collection surface also includes where the bot runs and what it can touch. A widget that can be embedded on any domain lets a third party collect conversations under your name, so domain restrictions should be standard rather than an enterprise add-on. Rate limits keep abuse from turning into scraping or runaway costs. And every tool the bot can call — tickets, webhooks, CRM writes — widens the surface, so each action needs a permission boundary and a failure path that does not expose private data. The chatbot security attack-surface guide treats this as an injection problem; it is equally a collection problem.

When to Ask: After the First Useful Answer

Many website chatbots damage trust before the first answer by demanding an email, phone number, company size, or budget up front. That gate made sense for static lead forms. In an AI chat it reads as "collecting data before helping" — exactly the pattern on-device AI is training users to reject.

The rule: answer first when the question can be answered safely without identity. Ask when there is a reason the visitor can see.

Sequenced this way, lead capture converts better, not worse — qualification lands after the bot has demonstrated value, which is the pattern the chatbot lead generation guide is built around.

What to Keep: Records the Team Can Stand Behind

Keeping data is not the failure mode; hiding what you keep is.

A hosted chatbot legitimately keeps three kinds of records: conversation logs for quality review, contact details the visitor chose to share, and the source material answers are grounded in. Each has a reason a customer would accept when stated plainly — improve answers, follow up, stay accurate. Keep those, say so, and stop there. What should not be kept: sensitive fields pasted into chat (tell users not to enter passwords or payment details), identity data attached to conversations that never requested follow-up, and prompt logs that duplicate the contact record.

Retention deserves an explicit number, too. "We keep logs" without a window means "forever," and forever is the answer that looks worst in a breach notice or a data-access request. Pick a period that matches the record's job — conversation logs long enough to catch quality regressions, contact records for as long as the relationship is live — write it into the privacy policy, and honor deletion requests across all three layers, not just the visible transcript. A chatbot vendor that cannot tell you where conversation data lives and how to delete it has answered the trust question for you.

Grounding belongs in the same trust budget. A bot that guesses because it cannot find the right source creates accuracy risk and trust risk at once, and the customer experiences them as one bad interaction; in regulated topics the exposure compounds, as the chatbot hallucination liability article documents. When sources do not support an answer, the bot should say it cannot confirm and offer a handoff. When the question is legal, medical, or financial, it should give general information only and route to the right professional channel.

Say Exactly What the Bot Does

The worst response to the on-device trend is privacy theater — language that implies local processing when the chatbot is cloud-backed. Trust erodes fastest when the user feels the boundary moved after they already shared something.

Honest and narrow beats grand and vague:

If you want a starting point, this disclosure fits next to a chat widget and covers everything that matters:

About this chat: Answers are generated by AI from our help content, and our team may review conversations to improve them. Please don't enter passwords or payment details. If you'd like a follow-up, share your email when asked — it goes to our support team.

Adapt it to what you actually do; the copy only works if it is true. If conversations feed retraining, say that too. Regulated industries need the fuller treatment in the AI chatbot compliance guide, but this paragraph is the product-copy floor — and it beats a "private AI chatbot" badge that a single subpoena or support escalation would contradict.

Trust Is Now Something Customers Can Feel

Apple's on-device push matters to website chatbots not because they should imitate the architecture, but because it makes private-by-default AI feel normal. A chatbot that collects only what the answer needs, asks for identity when the visitor can see why, keeps records it can openly describe, and hands off cleanly when conversations cross into private territory will feel modern next to that baseline. One that grabs contact details first and hides the data path will feel older every month.

Agentkit's defaults follow this shape: the bot answers from your trained sources without gating, lead capture asks only where you configure it to, and domain restrictions and rate limiting are included on every plan.

Build your chatbot for free →

No credit card required.