The sentence that starts the trouble is one an engineer says in review without thinking: we are using Claude through AWS. According to the dev.to post, that resolves two ways, and the two answers hand the review to different people [15].
One answer stays inside machinery you already operate: AWS Organizations, IAM, CloudTrail, CloudWatch, VPC endpoints, a central security account, AWS compliance evidence [7]. The other adds a party. Anthropic enters the assessment as platform operator and data processor, which puts its terms, privacy commitments, retention behavior, support model and third-party risk posture in scope [6].
That scope matters because of what the payload is. The post's list is the right one: internal documents, source code, customer context, financial information, architecture details, incident notes [5]. This is the part of the design that resists redaction, because the payload is assembled at call time by whoever happens to be using the tool. So count processors rather than features: one under Bedrock, two under the Anthropic-operated route [1]. The second count is a third-party risk exercise, and nothing in an AWS control catalogue performs it on your behalf.
Treat the Bedrock statement as a claim about a service model rather than a claim about your account. The post is explicit that the rest of the workload still decides where data lands: logging destinations, S3 buckets, CloudWatch log groups, backups, and downstream services [13]. Inference can sit inside one operator's boundary while your invocation logs come to rest somewhere your data processing agreement never mentioned. Residency behaves the same way. Pinning a workspace to an AWS Region does not by itself establish where inference runs or how geography is enforced [12].
Worth being clear about the evidence class. This is one practitioner's framing on dev.to rather than vendor documentation, and the author presents it as his own approach, opening with the point that he does not start from the model name [14][17]. The load-bearing line is the one about the model provider not receiving prompts and completions through the Bedrock service model. Before that goes into a review packet, it needs to come from the service terms.
His threshold is workable as written: low-risk experimentation, public content, or a workload where Anthropic is already an approved processor can take the native route, while confidential, regulated or customer-owned data means legal, procurement, privacy and security all understand the operating model before production [16]. Procurement finds out either way; the only variable is whether it finds out before the cutover.
In my context the default is the AWS-operated path for anything customer-owned, with the vendor review budget spent once, on the specific workloads that genuinely need native platform behavior. If your organisation has already cleared Anthropic as a processor, that default inverts, and the interesting question becomes logging destinations instead of operator identity.
