What actually happens to your data on AWS, OpenAI, and Anthropic

What actually happens to your data on AWS, OpenAI, and Anthropic

Indigo hero graphic with database icons for a guide on AWS, OpenAI, and Anthropic data privacy

"Does this AI service train on our data" is one of the most searched questions from businesses adopting AI, and it gets answered badly most of the time, either with blanket reassurance or blanket fear. The real answer depends entirely on which specific product you mean, and the gap between the two most common answers is exactly where most business data actually gets exposed.

The distinction that actually matters: consumer app vs. API

This is the one thing worth understanding before anything else. The free chat app in a browser and the paid API the same company sells to businesses are different products with different data terms, even though they're the same model underneath. Anthropic's consumer plans (Free, Pro, Max) have used conversations to train Claude since September 2025 unless a user opts out in privacy settings. OpenAI's consumer Free and Plus tiers work the same way by default. The commercial API tier from both companies does not train on inputs or outputs by default. An employee pasting a client contract into the free ChatGPT or Claude app in a browser tab is a real training-data exposure. The same company's paid API, integrated properly into a product, is a contractually different situation. Nearly every "AI leaked our data" story that isn't a security breach is this distinction, not a lie in a privacy policy.

What the major providers actually commit to, with sources

  • Anthropic API: does not use inputs or outputs to train models by default; API data is automatically deleted after 7 days and is never used for training without explicit opt-in.
  • OpenAI API: does not train on API data by default; default retention is up to 30 days for abuse monitoring, and qualifying enterprise customers can enable Zero Data Retention, prompts and outputs processed in memory only, never written to disk.
  • AWS Bedrock: never shares customer data with the underlying model providers and never uses it to improve base models, full stop, regardless of tier.

The AWS-specific answer: using a hosting service as the boundary, not the AI itself

This is what "use a hosting service to protect business data while still using AI" actually looks like in practice. Bedrock supports AWS PrivateLink, which keeps every request between your VPC and the model entirely inside AWS's private network, never touching the public internet, encrypted in transit and at rest via your own KMS keys. The practical effect: your application calls a foundation model, but the request never leaves a network boundary you control and can audit, and it never reaches the model vendor as a separate party at all, Bedrock sits between you and them. For a regulated business, that's a materially different risk profile than calling a public API endpoint directly, even though the same underlying model answers the prompt either way.

# Bedrock via PrivateLink: the request path
Your VPC → PrivateLink endpoint → Bedrock (AWS network only) → model
# never touches the public internet at any point

The maximum-control tier: keeping data on hardware you own

If a contractual guarantee isn't enough and the requirement is that data never leaves a machine you physically control, that's a real, different tier, and it's more accessible than most guides suggest. I installed Ollama and ran Meta's open-weight Llama 3.1 8B model on ordinary hardware, no cloud, no GPU rental. It downloads once (4.9GB), uses 5.26GB of memory once loaded, and answered a real prompt at roughly 50 tokens per second, about 1.6 seconds for a 69-token response. Nothing left the machine at any point, because there was nowhere for it to go.

$ ollama pull llama3.1:8b
$ ollama run llama3.1:8b "your prompt here"
# or as a private API any internal tool can call:
$ curl http://localhost:11434/api/generate -d '{"model":"llama3.1:8b","prompt":"...","stream":false}'

That same setup runs on an ordinary, no-GPU VPS, a Hetzner CX32 (4 vCPUs, 8GB RAM) is about €6.80/month at current pricing, as an always-on internal endpoint. Worth being honest: CPU-only inference away from Apple Silicon's acceleration will run slower than the number above. The trade isn't speed, it's a hard, physical guarantee instead of a contractual one, for the specific data that actually needs it.

Securing your own team is a separate problem from picking a vendor

Everything above is about what happens to data once it reaches a provider. It says nothing about who on your side can send what. That's an internal access problem, and the same mistake shows up constantly: one shared login or API key used by everyone on a team for every tool, with no way to tell afterward who sent what. The fix is the same access-control pattern regardless of which provider you picked, per-person or per-tool identity, not a shared credential, and a scope that's the intersection of what the tool is allowed to touch and what that specific person is allowed to see. I've written the mechanics of that separately, it's a deeper problem than fits here, but it's the piece that actually determines whether "we picked a provider with good data terms" translates into an internal team that's actually careful with what it sends.

In order of how much control each one buys: a properly configured business API tier (not the free consumer app) is enough for most day-to-day use. Bedrock with PrivateLink, or the equivalent private-networking option from any major cloud, is the right layer when the data is regulated or contractually sensitive. Self-hosting is for the specific data where a contract isn't enough and a physical guarantee is the actual requirement. Very little business data needs the third tier. Nearly all of it currently gets treated, by accident, as if it's fine in the first tier's free consumer version, which is the one place none of the training guarantees above actually apply.