Cowork and data retention: what to know

Why this deserves a direct answer, not an assumption

Data handling questions get asked more often, and answered more vaguely, than almost anything else in how people evaluate a new AI tool for work — and the honest answer is that retention behaviour depends on the specific product and configuration in use, not a single blanket policy that applies identically everywhere across every surface a company offers. Assuming a collaborative surface follows the same retention rules as the API, or the reverse, without checking, is a real risk for any organisation with actual compliance obligations to satisfy.

Don't assume it matches the API's retention behaviour

If your organisation has specific data-retention requirements — a zero-retention policy, for instance — verify those requirements against the specific product and surface actually being used for a given task, rather than assuming a policy that applies to one part of a product family automatically extends to every other part of it. A collaborative, consumer-oriented surface and a programmatic API integration are different products, potentially governed by different terms and different retention behaviour, even when both sit under the same broader product family.

Where to actually go for a binding answer

This site's own factual spine centres on the API's mechanics specifically — pricing, context windows, caching, effort — and that scope deliberately doesn't extend to authoritative claims about a different product's specific data-handling terms, which are governed by their own documentation and can change independently of anything covered here. For a binding, current answer, go to the current official documentation and terms for the specific product you're actually using, rather than treating general guidance from anywhere else — including this site — as a substitute for that check.

What's safe to assume, and what isn't

It's reasonable to assume that a company operating multiple related products applies some baseline standard of care across all of them — but "baseline standard of care" and "identical retention policy" are different claims, and only the specific, current documentation for the product you're actually using can confirm the second one. Treat any retention-related decision that has real compliance stakes as something to verify directly against current terms before relying on it, not something to infer from how a different, related product behaves.

Questions worth asking before adopting any surface for sensitive work

Before routing genuinely sensitive material through any collaborative surface, it's worth having clear, current answers to a short set of questions: what's retained, for how long, whether it's used to improve the underlying models, and whether an organisational-level policy like zero retention is available and how it's actually enforced for that specific product. Treat the absence of a clear answer to any of these as a reason to hold off rather than to assume the answer is favourable by default — an unclear policy is not the same as a good one, and shouldn't be treated as equivalent just because it's more convenient to proceed.

Keeping this check current, not just doing it once

A product's retention terms aren't guaranteed to stay fixed indefinitely — terms can be updated, and a check performed when a tool was first adopted doesn't necessarily still describe its current behaviour months or years later. For anything genuinely sensitive, periodically re-confirming current terms is worth the small recurring effort, rather than relying permanently on an answer that was correct only at the moment it was originally checked.

Why this site stays narrow on purpose here

This site's accuracy discipline works by sourcing every claim against a specific, checked reference and refusing to state anything it can't confirm that way — which is exactly why broader product terms outside that scope get pointed elsewhere rather than guessed at. A confident-sounding but unverified claim about data handling is worse than no claim at all, given what's actually at stake for a reader making a real compliance decision based on it.

See zero data retention, and which models support it for how this constraint plays out specifically on the API side, which is the surface this site's factual spine actually covers in depth.