The Conventional Wisdom
Setting your Amazon Bedrock account to none mode is often seen as eliminating data retention risk. Your prompts and model outputs disappear after each request. Compliance box: checked. Data governance obligation: satisfied. You might think nothing persists.
This belief is common among compliance teams evaluating generative AI platforms. Many organizations treat the none setting as a quick fix, configure it once, declare victory, and move on.
Why It's Incomplete
The none mode does what it promises: zero data retention for inference requests. However, it doesn't cover three critical gaps:
First, automated content scanning operates independently of your retention mode. Amazon Bedrock uses mechanisms to identify child sexual abuse material in model input and output. Flagged content may be stored and reviewed for reporting purposes, even when mode is none. This isn't a loophole, it's a legal obligation AWS must meet. Your "zero retention" policy has an exception that might not be documented in your data processing inventory.
Second, the none ceiling can block necessary functionality. Some Bedrock APIs require data retention: the Batch API and the Responses API with store=true can't function without it. Setting your mode to none makes these APIs unavailable, potentially hindering business capabilities and causing development teams to seek workarounds.
Third, account-level settings might not be enough. A project set to inherit will follow the account setting above it. If someone changes the account from none to provider_data_share, every project inheriting that setting changes too. Your zero-retention workload is now one AWS CLI command away from data sharing, and your quarterly access reviews won't catch it unless you're specifically monitoring retention mode drift.
The Evidence
Retention mode functions as a ceiling, not a floor. Your configured mode declares the maximum level of data retention you'll accept. Models that support zero retention will continue operating that way regardless of your account setting. But this ceiling architecture creates a false sense of permanence.
Consider the interaction table from the source documentation. When your account mode is none and you invoke Claude Sonnet (which supports none), you get zero retention. But when your account is provider_data_share and you invoke the same model, you still get zero retention, Sonnet doesn't require data sharing. The account setting didn't force retention where the model didn't need it.
Now reverse the scenario. Your account mode is none, and someone attempts to invoke Claude Fable 5, which requires provider_data_share. The call is blocked. Your ceiling is below what the model requires. This is correct behavior, but it means your compliance control is reactive, not proactive. You're stopping the attempt, not preventing the misconfiguration that made the attempt possible.
The provider_data_share mode requires explicit opt-in at the account or project level. You don't inherit it from a model, it's a conscious decision. This control depends on your IAM boundaries, your change management process, and your ability to detect drift.
What to Do Instead
Stop treating retention mode as a set-it-and-forget-it control. Build a layered enforcement architecture that assumes account-level settings will change.
Use Service Control Policies for Enforcement. If your regulatory requirements prohibit data sharing with third-party model providers, deploy an SCP at the organization root that denies bedrock:PutAccountDataRetentionPolicy when the mode is provider_data_share. This prevents any account from opting in, regardless of admin access. SCPs don't cover the management account, so complement them with IAM policies there.
Isolate Workloads by Retention Requirement. If you're using the bedrock-runtime endpoint (Invoke, Converse APIs), project-level data retention isn't available. The account-level retention mode applies to all requests. Create an organizational unit structure that separates zero-retention workloads from research environments:
Organization Root
├── OU: Zero-Retention (SCP attached)
│ ├── Account: Production-App-A
│ └── Account: Production-App-B
└── OU: Research (no SCP)
└── Account: ML-Experimentation
Apply the restrictive SCP only to the Zero-Retention OU. This gives you workload isolation through account boundaries, not configuration settings.
For the Bedrock-Mantle Endpoint, Use Amazon Bedrock Projects. Projects allow you to set retention modes per-project within the same account. A production project handling customer data can enforce none while a research project in the same account uses provider_data_share. Each project enforces its own retention ceiling independently. This only works with models accessed through OpenAI-compatible APIs and the Anthropic Messages API on the mantle endpoint, check endpoint availability before you architect around it.
Document the CSAM Exception. Your privacy impact assessment should explicitly state that automated content scanning may retain flagged material for reporting purposes regardless of retention mode. This isn't a compliance failure, it's a legal requirement. But if your Data Subject Access Request process doesn't account for it, you'll misrepresent what happens to personal data.
Monitor Retention Mode Drift. Your preventive controls (SCPs, IAM policies) should make unauthorized changes difficult. But verify they're working. Build a daily check that compares current retention modes against your approved baseline. Alert on any account or project where the mode has changed. Treat retention mode as a critical configuration item in your CMDB, not a forgotten setting.
When the Conventional Wisdom Is Right
Setting your account to none eliminates retention for standard inference requests with compatible models. If you're using Claude Sonnet for a production chatbot and you've verified the model supports zero retention, the none mode does exactly what you need. Your prompts and responses are processed and immediately discarded.
The none ceiling also blocks models requiring data sharing. If your compliance posture prohibits third-party data sharing, the none mode prevents accidental use of incompatible models. The API call fails with a clear error. This is preferable to silently allowing data sharing because someone didn't read the model's terms.
The conventional wisdom breaks down when you assume the setting is permanent, ignore the CSAM exception, or treat account-level controls as sufficient for workload isolation. The none mode is a necessary control, just not a sufficient one.
