Using Claude through a third-party platform means your application sends data to a service endpoint operated by your cloud provider (Amazon Bedrock, Google Vertex AI, Microsoft Foundry) or by Anthropic running on AWS (Claude Platform on AWS). Understanding that flow in plain terms is the foundation for every privacy and compliance conversation that follows. None of it is mysterious, but it does need to be stated precisely rather than assumed.
What is actually in a request
More than most teams first realize. A Claude API call can carry the user's visible message, your system prompt (which often encodes business logic and internal terminology), documents or images attached for analysis, retrieved passages from your internal knowledge bases if you use retrieval-augmented generation, tool definitions describing your internal systems, and tool results containing whatever those systems returned. The response comes back the same way. In short: treat the full request and response as potentially sensitive production data, not as "just a prompt." If customer records flow into your prompts, customer data is flowing to the platform endpoint.
The path, step by step
The basic flow is the same on every platform. Your application builds a request and sends it, encrypted in transit, to the platform's API endpoint in your chosen region (or via a global endpoint on Vertex AI, if you use one). The platform authenticates the caller — cloud IAM credentials on Bedrock and Vertex, SigV4 signing with a workspace ID on Claude Platform on AWS, an API key on Foundry — runs inference on the model, and returns the response. Because these are cloud services, your platform and networking teams can apply familiar controls: identity-based access, private connectivity options, and the provider's standard logging.
Two flow details deserve explicit attention in your diagram. First, features that fetch external content — web search or web fetch tools, where available — introduce traffic to third-party sites that would not otherwise exist. Second, anything your own application logs (full prompts, responses, or both) creates a second copy of the data under your control, with its own retention question.
Retention and training: verify, don't assume
The two questions every privacy reviewer asks are: how long is request and response data retained by the platform, and is it used to train models? These are contractual and policy matters that vary by platform and agreement, and they change over time — so this guide deliberately does not state specifics. Running Claude through your cloud provider means the data handling terms come from your agreement with that provider; it inherits your cloud provider's compliance posture, and you should confirm the specifics with your provider in writing. Ask for the current documentation on retention periods, whether prompts are stored at all beyond processing, any human-review scenarios (for example, abuse monitoring), and the provider's position on training use. Get the answers attached to your contract file, not a chat message.
A short verification checklist
Before launch, be able to answer these in writing. What categories of data can appear in prompts, and did anyone check the retrieval pipeline, not just the user input? Which region processes requests, and does that satisfy your residency commitments? What does the platform retain, for how long, under which agreement? Is any data used for model training, per current provider documentation? What do you log on your side, where, and with what retention? And who can invoke the model at all — is access scoped, and is usage audit-logged? If each question has an owner and a documented answer, your security review becomes a review rather than an investigation.
Where to go next
For the region and geography side, continue with Data Residency Questions Your Legal Team Will Ask. For reducing what sensitive data enters prompts in the first place, read Handling PII in Claude Requests, or review the launch checklist on the main guide.