Gemini Trains on Your Conversations by Default: Unless You Turn Off Keep Activity

Paying for Gemini doesn't mean you're exempt from training—whether conversations are used to improve models depends on the Keep Activity toggle.
Starting from a Hacker News reminder, the article points out that Google's Gemini uses conversations for model training even for paid subscribers; the deciding factor is the Keep Activity toggle, not payment status. Three mechanisms in Google's documentation are most relevant to developers: the Keep Activity toggle, human review, and a long data retention period (three years is mentioned in discussions). Turning the toggle off only affects future conversations—historical data isn't automatically deleted; some conversations may also be viewed by humans, exposing pasted keys and internal code to both machine training and human review. The article offers four actionable recommendations: check and turn off the toggle, keep sensitive content out of conversations, factor data terms into tool selection, and establish clear input guidelines in enterprise environments—emphasizing that this is a common issue for AI assistants, and the real risk lies in the habit of default acceptance.
Google's Gemini is using your conversation data to train its models—even if you pay for a premium subscription. This conclusion comes from a "Tell HN" post on Hacker News, where the poster reminds developers: before pasting code into Gemini, figure out what the Keep Activity toggle actually controls.

Paying Doesn't Mean You're Exempt from Training
Many people assume "paying users' data gets special treatment," but according to this post, subscribing to Gemini doesn't let you opt out of conversation training. Google's documentation is explicit about this: whether conversations are used to improve models depends on the Keep Activity setting, not your payment status.
This distinction matters. Enterprise procurement often treats "data not used for training" as a negotiation condition, while individual developers tend to let their guard down because "I paid." Both mindsets rest on the same misjudgment—conflating a commercial relationship with data terms. Google puts control in a specific product toggle: you either turn it off manually or accept the default behavior.
Keep Activity, Human Review, and Three-Year Retention
Three items in Google's documentation are most relevant to developers: the Keep Activity toggle, the human review mechanism, and the data retention period.
When Keep Activity is on, conversations can be saved and used for model improvement; when off, new conversations no longer enter the training pipeline. But there's an easily overlooked detail—turning it off applies "going forward," and historical data isn't automatically deleted as a result.
Human review is another layer. Some conversations may be reviewed by people for quality assessment or model tuning. For developers who've pasted internal code, API key fragments, or architecture designs, this means the exposure surface isn't just "machine training" but also "human eyes."
On retention, the documentation notes that training-related data may be kept for an extended period, with the three-year figure repeatedly mentioned in discussions. Three years far exceeds the commercial value lifecycle of a code snippet from a short-term project.
Keep Activity is an activity-record control at the Google account level, located in the "Data & privacy" settings of your Google account. It's related to but not identical with the conversation history toggle within the Gemini app. Its scope covers multiple Google services that record usage activity, so turning it off affects more than just Gemini—it also affects retention policies for search, location history, and other activity data. For developers, what to watch for is that this toggle may appear in different locations and follow different logic at the account level versus the app level; turning it off in one interface doesn't necessarily mean all related records have stopped being written. It's advisable to return to the account activity page after turning it off to confirm the status, and check whether saved Gemini activity entries still exist—avoid concluding that the data flow has stopped based solely on the interface feedback of a single toggle.
Human review typically appears in mainstream AI service terms as "limited human review," used for abuse detection, quality assessment, and security incident investigation. It's distinct from the model training pipeline, but input content can likewise be seen by people, and the review scope is often not limited to flagged conversations. For developers, this means that even with training-related activity retention turned off, keys, internal endpoint addresses, or undisclosed business logic pasted into conversations may still be viewed by humans. The practical response is to treat the review mechanism as a risk surface just as important as training, substituting or abstracting sensitive fragments rather than relying on a single toggle to isolate risk.
What Developers Should Do Before Pasting Code
For this situation, the post's advice can be summarized into several actionable steps.
First, check and turn off Keep Activity. This is the most direct control point, but note that it only affects future conversations—existing history still needs to be handled separately.
Second, keep sensitive content out of the conversation. Keys, internal endpoints, and undisclosed business logic shouldn't appear in any input box that may be retained or reviewed, regardless of whether the service is paid.
Third, factor data processing terms into tool selection. When teams choose AI coding assistants, training data policy should be an evaluation dimension alongside code completion quality and context length.
Fourth, enterprise environments need clear input guidelines. Rather than relying on each developer's self-discipline, write down rules for "what can be pasted and what must be redacted."
This Isn't a Problem Unique to Gemini
Zooming out, using conversation data for training is common practice among current AI assistants; the differences lie only in defaults, toggle locations, and transparency of terms. A setting you turn off in product A won't automatically carry over to product B.
For developers, the real risk isn't any one vendor's specific policy but the habit of "default acceptance." Pasting code takes a second, while understanding a data terms document often takes ten minutes—this asymmetry is the root of the problem.
The value of the post lies here too: it doesn't stop at complaining but lays out the specific mechanisms in Google's documentation, letting everyone who uses Gemini to write code judge for themselves. Turning off a toggle takes only a few steps, but realizing you need to turn it off is the harder step.
Data retention period refers to the maximum storage time a service provider commits to in its terms before user data is deleted or anonymized. This figure is usually set separately for different categories such as training data, abuse investigation records, and billing records, so the "three years" mentioned in the documentation may not apply to all data types—read it category by category. The practical significance of the retention period is that even if you turn off activity recording afterward, data already within the retention window will still exist for the established period, and processing of deletion requests may also be delayed. For developers, when assessing the risk of a code snippet, consider retention duration together with the decay curve of its sensitivity—temporary keys for short-term projects may expire within weeks, while the commercial value lifecycle of an architecture design diagram is often longer; the two don't carry the same risk level. Understanding the category differences in retention terms is more helpful for making judgments than memorizing a specific number of years.
Related articles

Codex in Practice: A Complete Guide to Enterprise-Grade Agent Skills Development
An in-depth analysis of a Bilibili Codex practical course covering core capabilities, agents.md configuration, MCP protocol, multi-agent collaboration, and enterprise plugin development—building a complete framework for enterprise AI coding tool adoption.

A Beginner's Guide to LLM Fine-Tuning: From Principles to Industry Implementation
Starting from the layered structure of general LLMs, this guide systematically covers the motivations, cost comparisons, and applicable scenarios of LLM fine-tuning, with three open-source cases: Bencao, LawGPT, and FinGPT, illustrating implementation paths in healthcare, law, and finance.

Claude Code in Practice: From Installation to MCP, Skills, and SubAgents
Claude Code tutorial: NPM install with Node.js prerequisites, using CC Switch to bypass account login and avoid bans, permission modes, built-in commands, MCP, Skills, SubAgents, and CLAUDE.md project files—helping developers move from natural language chat to structured AI coding workflows.