Fable 5.1 on Bedrock: data retention is now an architecture decision

Bedrock has always sold itself on two security models: zero operator access (no service operator can read model input or output) and zero data retention by default. The abuse detection doc still asserts both. What Anthropic introduced with the Covered Model category is a named exception: for Claude Fable 5 and Fable 5.1, all traffic is retained for up to 30 days for automated offline abuse detection, and classifier-flagged traffic is subject to human review performed by AWS.

Two things that did not change, worth repeating because a hurried reading gets both wrong. First: your content does not go to Anthropic. The provider_data_share mode is legacy, and the doc itself states that sharing content with model providers is not supported today — it grants a permission nobody exercises. Second: nothing changes for Claude models released before Fable 5. The doc is explicit, and the mechanism is elegant: each model declares its own allowed_modes, so an account set to aws_review that also calls Opus 4.8 retains nothing from Opus — Opus permits none, and none wins for it.

The friction isn't what AWS does with the data. It's that the authorization to do it lives in a scope most teams don't control.

If you work under BACEN 4.893, PCI-DSS or LGPD, odds are your organization already has an SCP denying anything that writes prompts to durable storage. The Bedrock docs even publish that SCP as an example, denying bedrock-mantle:PutAccountDataRetention whenever bedrock-mantle:DataRetentionMode is anything other than none. That SCP is correct — and it makes Fable 5.1 permanently unavailable across the whole OU.

What bothers me isn't the block; it's the granularity. The mode resolves across project → account → model default, and the only practical command today is aws bedrock put-account-data-retention --mode aws_review, which applies to the entire account. Turning Fable 5.1 on in the shared production account authorizes AWS human review over every workload that runs on a model requiring review, indefinitely, until someone remembers to turn it off. Project scope exists precisely to avoid that, and it is the only reason I would consider enabling this without cutting a new account.

The practical recommendation inverts the instinct: don't ask for an SCP exception — ask for an account. A dedicated account, inside its own OU with an SCP that permits aws_review and nothing beyond it, gives you a named blast radius, a separate bill, and a one-line audit answer. An exception carved into a production OU's SCP is debt nobody audits later.

This is the part every piece of coverage I read missed, and it is the most serious one for anyone operating in Brazil or Europe. The Fable 5.1 model card lists the bedrock-runtime endpoint with In-Region unsupported in every Region on earth. The Geo profile (us.anthropic.claude-fable-5-1) exists only in the US, Canada and GovCloud. In sa-east-1, eu-central-1, eu-west-1 and everywhere else, the only open door is the Global profile — global.anthropic.claude-fable-5-1, which routes inference anywhere in the world.

Now pair that with a sentence in the abuse detection doc: if cross-region inference is enabled, retained inputs and outputs are stored in the destination Region, meaning wherever the request was processed. Put the two together and the result is blunt: a bank in São Paulo calling Fable 5.1 is authorizing 30-day retention of prompts in a Region it did not pick and cannot predict per request. That is not a latency footnote — it is a data-residency assertion that belongs in your DPIA before any proof of concept.

For residency-constrained shops the options are short and none are free: run through the US Geo profile and classify the data as transferred, negotiate Enterprise Frontier Safeguards eligibility while it still grants ZDR, or accept that Fable 5.1 stays outside the regulated perimeter and serves workloads with no personal data — code generation over an internal repository, for instance.

Fable 5.1's adaptive reasoning is always on and cannot be disabled; what you control is the effort level — low, medium, high, xhigh, max, defaulting to high. A public Converse test with {"output_config":{"effort":"max"}} showed the jump: 410 thinking tokens against zero on the default call, with latency moving from ~8.3s to ~13.7s. Thinking tokens are billed output tokens. A miscalibrated effort inside an agent loop doesn't raise your bill by 10% — it raises it by multiples, and the only evidence is a usage block nobody aggregates.

The second cost leak is refusal. Prompt-stage refusals, blocked before inference begins, are not billed. Mid-stream refusals, after partial output, are billed for the tokens generated before the block. With a materially higher refusal rate coming from the cybersecurity and life-sciences classifiers, a vulnerability-analysis pipeline can pay for output the user never saw.

And there is an endpoint choice that reshapes the whole architecture: on bedrock-mantle, Fable 5.1 supports neither Guardrails nor Knowledge Bases nor Agents nor the Converse API — only streaming, prompt caching and token counting. Bedrock Guardrails exist only through bedrock-runtime. If you need your own content filter in front of the model, there is no decision to make; bedrock-runtime is the only path, and it's the one the docs recommend for new applications anyway.