Before You Paste That Into Claude

A PM's Technical Guide to Data Masking

How AI data retention, training pipelines, and contract law intersect, and what that means for what you paste into a prompt box

A few months ago I was drafting a stakeholder escalation, behind schedule, and reached for Claude to sharpen the tone before sending. I pasted in my draft, hit enter, and the response came back clean. Calm. Diplomatic.

It was only after I'd copied it into my email client that I scrolled back up and looked at what I'd actually sent: the client's name, the exact penalty clause we were at risk of triggering, a budget figure that would tell a competitor precisely what we charge for a project this size.

Nothing malicious. Just speed outrunning judgement. And once I actually went and read how these systems handle that input after you hit enter, I realised most PMs are operating on assumptions that are roughly a year out of date.

This post covers the actual mechanics: what happens to your input at the infrastructure level, how that differs by account tier, what the law says, and a concrete masking protocol you can apply regardless of which tool you're using.

The Infrastructure: Where Your Prompt Actually Goes

Most people think of "don't share sensitive data with AI" as a vague hygiene rule. It's more precise than that, and the precision matters because the risk varies enormously by account type.

Consumer tiers train on your data by default, and now retain it for years, not days. As of late 2025, Anthropic's consumer terms (Claude Free, Pro, and Max) shifted to an opt-out model: unless you manually disable "Help improve Claude" in Privacy Settings, your conversations are eligible for model training and retained for up to five years. If you allow your chats or coding sessions to be used to improve Claude, that data may be retained in de-identified format for up to five years in the model training pipelines. If you opt out, you fall back to a 30-day retention window. This is not unique to Anthropic. OpenAI's ChatGPT Plus has the same structure: paid does not mean private by default, and you must explicitly find the data controls and turn training off.

Commercial and API tiers are a different contract entirely. Commercial users on Team, Enterprise, and API plans maintain a separate policy: Anthropic does not train generative models on code or prompts sent under commercial terms, unless an organization admin explicitly opts into a program like the Development Partner Program. This isn't a toggle you might forget. It's the default contractual position.

Retention windows on the API are short and getting shorter. As of September 2025, Anthropic reduced API log retention from 30 days to 7 days, with inputs and outputs automatically deleted after that window and never used for training. For organisations that genuinely need zero footprint, Anthropic offers Zero Data Retention, under which customer data is not stored at rest after the API response is returned, except where required by law or to combat misuse.

ZDR has a carve-out worth knowing about. Even under a Zero Data Retention agreement, Anthropic may still retain data where required by law or to combat usage policy violations and malicious use of the platform. "Zero" retention is not absolute. It is bounded by abuse-prevention and legal obligations that sit outside the commercial agreement.

The practical takeaway: if you are on Claude Pro, Claude Max, ChatGPT Plus, or any consumer-tier product, and you have not gone into settings to manually disable training, your default state right now is that client work could be sitting in a training pipeline for up to five years. That is the starting condition this entire article is responding to.

Why "Just Be Careful" Doesn't Hold Up

A vague caution doesn't map onto how the actual risk surfaces. Here's the more precise version, mechanism by mechanism.

Training data isn't deleted when you delete a conversation, if it already trained on something. Anthropic and other providers are explicit that opting out going forward doesn't retroactively scrub data already incorporated into a model. Once something has shaped model weights, there's no clean "unlearn" operation available. This is a hard technical constraint, not a policy choice anyone can simply reverse.

De-identification is not the same as anonymisation. Training data is typically retained "in de-identified format," which strips direct identifiers like names tied to accounts. It does not guarantee that the content itself, a specific contract clause, a distinctive budget figure, a recognisable internal process, can't be reconstructed or recognised by someone who already knows the context. De-identification protects against casual exposure. It does not protect against a sufficiently informed reader.

Regulatory exposure exists independently of the AI provider's own policy. In India, the Digital Personal Data Protection Act, 2023 imposes obligations on any organisation acting as a data fiduciary when personal data is shared with a third-party processor, which an AI provider functionally is the moment your prompt contains identifiable information about a person. The EU's GDPR imposes similar, longer-standing, and more rigorously enforced obligations, and many Indian firms serving European clients are bound by it contractually regardless of where their own servers sit. Neither framework cares what Anthropic's or OpenAI's terms of service say. They care what your organisation did with personal data.

Contract confidentiality clauses were written before this category of risk existed, which usually makes them stricter, not looser. Most NDAs and MSAs define "third party" broadly enough to capture an AI vendor without ever having anticipated one. Courts and counterparties tend to read ambiguity in confidentiality clauses in favour of the broader, more protective interpretation. Assume your contract already covers this, even if it was signed in 2019.

HIPAA and similarly regulated frameworks require a specific, signed agreement, not just a good privacy policy. Consumer accounts on Claude, regardless of plan, are not HIPAA compliant. Enterprise accounts can be configured for HIPAA compliance, but only with a signed Business Associate Agreement, Zero Data Retention mode, additional security controls, and audit logging. If your project touches health data and you're using a consumer-tier tool, you are very likely already out of compliance, irrespective of how careful your prompts are.

Mapping the Risk to What a PM Actually Handles

Project managers sit across more sensitive data categories than almost any other role, because the job requires synthesising finance, legal, HR, and client information into a single coherent narrative.

Risk category	What it includes	Why it's specifically dangerous
Commercial	Budgets, margins, vendor rates, pricing structures	Reveals competitive position; de-identification doesn't anonymise a distinctive number
Contractual	Penalty clauses, SLA terms, termination conditions	Often confidential by the explicit terms of the contract itself, separate from any AI provider's policy
Personnel	Performance issues, conflicts, disciplinary matters	Triggers employment law and data protection obligations regardless of model training policy
Strategic	Roadmaps, unreleased features, market entry plans	High-value information that, once it exists in any external system, cannot be recalled
Client intelligence	Vendor relationships, internal approval chains, decision-makers	Commercially valuable to competitors even when phrased as a passing operational detail

Masking as a Pre-Processing Step, Not an Afterthought

Think of masking the way you'd think about sanitising input before it hits a production system; it's the same logic applied to your own typing. You are pre-processing the data to strip anything identifying before it crosses a trust boundary, in this case the boundary between your organisation's systems and a third-party model provider's infrastructure.

Here's the protocol, applied category by category.

Strip the Names: Entities and Organisations

Real	Masked
Infosys	Client A
HDFC Bank	Vendor B
Tata Consultancy Services	Partner C

Maintain a consistent mapping within a single session. Reusing "Client A" throughout avoids accidentally re-identifying the entity by mixing real and masked references later in the same conversation, which is a more common failure mode than people expect.

Round the Numbers: Financial Figures

Real	Masked
₹2.4 crore	A mid-size budget
18% margin	A healthy margin

If you need the model to operate on an actual number, structurally, for a formula, a table, a variance calculation, substitute a fictional figure of similar order of magnitude. The model's output quality depends on the structure of the number, not its truth value.

Swap the Names for Roles: Personnel Data

Real	Masked
Rajesh (Project Sponsor)	Sponsor
Priya (Team Lead, underperforming)	Team Lead

This is the category with both a confidentiality dimension and an ethical one. A real individual's performance issue, run through a third-party system, is processing personal data about someone who never consented to it, even where they're not directly named.

Soften the Dates: Timelines

Real	Masked
Go-live: 15 March 2025	Go-live: in six weeks
Contract end: 31 December 2025	Contract end: end of year

Specific dates, cross-referenced against public filings, tenders, or press releases, can sometimes be sufficient to re-identify a project even with names stripped. Relative time references preserve everything the model needs without anchoring the conversation to a discoverable real-world point.

Describe, Don't Quote: Legal Language

Don't paste:

"Clause 14.3: In the event of a delay exceeding 10 business days, the vendor shall pay liquidated damages at the rate of 0.5% of the contract value per day..."

Describe instead:

"There's a penalty clause triggered by delays beyond ten business days. Help me draft a response acknowledging the delay and outlining mitigation."

Contract text is frequently confidential under the explicit terms of the agreement itself. Reproducing it verbatim into a third-party system isn't only a data exposure risk, it may constitute a direct breach of the confidentiality clause you're already bound by.

Three Questions to Run Before You Hit Send

Before sending a prompt, run it through three questions in order:

1. What's my account tier, and what's the actual retention and training policy attached to it? If you don't know whether you're on a consumer or commercial tier, or whether training is enabled, find out before doing anything else. This single fact changes the entire risk calculation.

2. Does this prompt contain anything in the five risk categories above? Commercial, contractual, personnel, strategic, or client intelligence data. If yes, move to question three. If no, you likely don't need to mask anything.

3. Have I substituted every identifying detail with a generic or fictional equivalent, while preserving everything the model actually needs to help me? If the answer is yes across names, figures, roles, dates, and legal language, you're clear to send.

What Changes Once You're on an Enterprise Plan

If your organisation runs Claude for Work, Claude Enterprise, or an API integration under a Data Processing Addendum, the underlying contract is materially different, not training by default, shorter retention windows, and the option of Zero Data Retention for qualifying use cases.

But "Enterprise" is not a single uniform guarantee. Confirm the specific configuration: whether ZDR is actually enabled for your organisation (it's opt-in even within Enterprise), what the DPA actually covers, and whether any HIPAA, FedRAMP, or other compliance certifications your project requires are actually in place for your specific deployment, not just available somewhere in Anthropic's product line.

If you're on a consumer tier, which covers most individual PMs day to day, none of these protections apply to you by default, and masking is not optional.

The Policy Will Keep Changing. The Habit Shouldn't.

The architecture here is genuinely still settling. Retention policies, training opt-ins, and regulatory enforcement are all moving targets, evidenced by the fact that Anthropic's own consumer terms changed materially in just the last year. Independent privacy evaluations note that Anthropic's GDPR compliance remains contested, with no regulatory action taken as of early 2026 but the underlying interface design still criticised as a potential dark pattern.

Treat every policy detail in this article as current as of writing, and verify against the provider's live documentation before making a compliance decision that matters. What won't change, regardless of how the policies shift, is the underlying discipline: strip identifying detail before it crosses the trust boundary. That habit is provider-agnostic and policy-proof.

Got a masking protocol of your own, or a near miss you learned from? I'd genuinely like to hear it in the comments.

Tags: #ProjectManagement #AI #DataPrivacy #DataMasking #Claude #ZeroDataRetention #PMTools #DPDPAct #GDPR #AIGovernance #DataProtection