When a team asks "can we put this in a prompt?", the honest answer in most organizations is "nobody has decided yet." That uncertainty produces two failure modes: cautious teams stall useful projects, and incautious teams paste whatever they have into the prompt. Data classification is the fix. You almost certainly have a classification scheme already — the goal is not to invent a new one for AI, but to extend the one you have with an explicit ruling for each tier.
Start from what the platforms actually do with your data
A classification decision is only as good as the facts underneath it. Two facts matter most, and both are documented rather than folklore.
Training. Anthropic's stated default for its commercial products, including the Claude API, is that it "will not use your inputs or outputs … to train our models" — the exception is when you explicitly opt in, for example by submitting feedback. For commercial customers, Anthropic describes itself as a data processor acting on the customer's instructions.
Retention. On the Claude API, Anthropic's stated default is to automatically delete inputs and outputs on its backend within 30 days of receipt or generation, with documented exceptions (for example, content flagged as a Usage Policy violation may be retained longer). Organizations with stricter needs can pursue a zero-data-retention (ZDR) arrangement through their Anthropic account team — it is a contractual arrangement, not a self-serve toggle. Note that some models carry retention requirements of their own: Claude Fable 5, for instance, requires 30-day retention and is not available under ZDR.
The 3P twist. If you reach Claude through Amazon Bedrock or Google Cloud, the cloud provider — not Anthropic — is the data processor, and retained data stays within your cloud provider's environment. Your classification rulings should therefore reference the platform you actually use, and you should confirm data-handling terms with that provider rather than assuming Anthropic's first-party terms apply.
A tier-by-tier starting point
The table below is a common starting posture — recommended practice to adapt, not a compliance conclusion. Your legal and security teams own the final rulings.
| Existing tier | Typical examples | Suggested starting posture for Claude |
|---|---|---|
| Public | Published docs, marketing pages | Allowed on any approved platform |
| Internal | Wikis, process docs, non-sensitive tickets | Allowed on approved platforms with logging in place |
| Confidential | Contracts, financials, customer records | Requires review: named use case, approved platform, retention terms verified |
| Restricted | Regulated data (PHI, payment data), secrets, credentials | Prohibited by default; exceptions only with the specific contractual arrangement the data requires (e.g., a BAA for PHI) |
For restricted data the platform choice does real work. Anthropic offers HIPAA-ready API access with a signed Business Associate Agreement (BAA) as an option for organizations handling protected health information — but per Anthropic's documentation that readiness does not extend to Amazon Bedrock, Google Cloud, Microsoft Foundry, or Claude Platform on AWS, where you must verify equivalent terms with the cloud provider directly. Credentials and secrets belong in no prompt on any platform, ever; that ruling costs nothing and prevents the most avoidable incidents.
Publish the ruling where the question gets asked
A classification mapping that lives in a policy PDF changes little. Put the tier-to-ruling table in the places engineers and business users actually look: the internal AI portal, the top of your prompt-engineering guide, the intake form for new use cases. Each ruling should name the approved platforms, because "yes on Bedrock inside our AWS boundary" and "yes on the first-party API" are different answers with different data-processor relationships.
Finally, treat the mapping as versioned and owned. Platforms change — retention options, model-specific requirements, and feature availability all move — so assign an owner who re-verifies the underlying facts against official documentation on a schedule, and date every published ruling.
Where to go next
Turn the tier rulings into a full grid with a data sensitivity matrix, then enforce them upstream with input data controls. For the retention details behind these rulings, see retention and deletion practices.