PPassTheCertExam

Study guides / CCAO-F / Domain 6

Governance, Risk, and Responsible Use · Lesson 4 of 5

6.4 — Data Residency and Privacy Considerations

Distinguish where a request's model inference runs from where an organization's data is stored at rest, and understand why classifying data sensitivity comes before either control.

"Data residency" for a Claude-based system actually covers two distinct things that can be controlled independently: where a given API request's model inference is processed, and where an organization's data is stored at rest. A regulatory or privacy requirement can apply to one without applying to the other, so knowing which lever controls which is exactly the kind of practical, applied knowledge this domain's "apply data sensitivity, regulatory, and privacy considerations" bullet is testing.

Inference Location vs. Data Storage Location

A European customer who needs a specific API request's model inference to run only on US-based infrastructure, due to a regulatory requirement, without changing where their workspace data is stored at rest, has a narrow, well-defined ask: control the inference location on that request, and leave storage alone. This is a real, separate lever from the organization's standing data-storage configuration — exactly the kind of narrow, per-request control this scenario calls for, without triggering a broader, unwanted change to where data lives long-term.

Conversely, an organization with a blanket requirement that all customer data be stored within a particular region, regardless of which specific request processed it, is describing a storage-at-rest requirement — a different control, aimed at where data persists rather than where any single computation happens. Applying the wrong lever to a described requirement is the most common way this gets tested: reaching for a workspace-wide storage setting when the ask is about a single request's inference, or vice versa.

Why This Distinction Matters for Compliance

Regulatory frameworks frequently draw exactly this distinction, which is why it matters practically and not just as a product detail. A company handling EU customer data may face a legal requirement about where that data is stored long-term that's separate from, and sometimes stricter than, any requirement about where processing occurs for a given request. Getting this backwards — assuming a storage change satisfies an inference requirement, or that setting inference location handles a storage-residency obligation — can leave an organization technically non-compliant even though it made a real, deliberate change.

Consider a concrete case: a retailer with customers across the EU and US has a data residency clause in its contract with EU customers requiring their data to be stored within the EU. Separately, the retailer wants some flexibility about which infrastructure actually performs inference for performance reasons. These are two different promises to two different stakeholders, satisfied by two different controls — storage location is set once, at the organizational or workspace level, to keep the contractual promise about data at rest, while inference location can, if needed, be controlled per request without breaking that promise, because inference and storage were never the same commitment in the first place.

Classification Comes Before Either Control

There's a step that logically comes before either control, though: knowing what a piece of data actually is before deciding how, or whether, to send it to Claude at all. Not every regulatory or privacy consideration is solved by choosing the right residency setting — some data (certain categories of health information, government-issued IDs, or other high-sensitivity personal data, depending on the organization's own policy and applicable law) may need to be excluded, redacted, or specially handled entirely, independent of where inference happens to run or where results are stored. Classifying data sensitivity first is what tells you whether a residency control is even the right tool for a given piece of data, or whether the data shouldn't be sent as-is in the first place.

Key Concept

Inference location and data-at-rest storage location are controlled separately, and a regulatory or privacy requirement can apply to just one of them. Classifying data sensitivity comes first and determines whether a residency control is even the right tool — some sensitive data may need special handling or exclusion regardless of where inference runs or data is stored.

Common Exam Distractor

An answer that reaches for a workspace-wide data storage or residency setting, when the actual requirement is about where a specific request's inference runs (or vice versa), conflates the two distinct controls. Watch for scenarios that explicitly say storage should stay unchanged — that's the signal pointing to the inference-specific control, not the org-wide one. Also watch for scenarios that treat "de-identified" data as automatically exempt from any sensitivity classification or residency consideration — de-identification reduces risk, but it doesn't eliminate the need to classify the data or apply the correct control.

Exam traps

Practice question

A hospital system wants to pilot Claude for scheduling optimization using de-identified patient scheduling data. Two separate requirements apply: internal policy requires classifying data sensitivity before any AI use, and their regulator requires that inference on data derived from EU patients run on EU-based infrastructure, without changing where the organization's data is stored at rest. Which pair of actions correctly satisfies both requirements?

  • A Classify the data's sensitivity first per internal policy, then apply the appropriate per-request inference-location control for requests involving EU-patient-derived data Correct

    This does both things the scenario requires in the right order: classify sensitivity before any AI use, and use the narrow, per-request inference control that matches a requirement explicitly scoped to inference, not storage.

  • B Skip sensitivity classification since the data is de-identified, and change the organization's entire workspace storage region to the EU

    This skips the required classification step and also applies the wrong lever — the stated requirement is about inference location on specific requests, not the organization's overall data-at-rest storage region, which the scenario says should stay unchanged.

  • C Classify the data's sensitivity, then relocate the entire organization's account to a separate EU-based Anthropic account

    This is a drastic, unnecessary action that doesn't correspond to a documented per-request control, and goes far beyond the narrow inference-location requirement actually described.

  • D Assume de-identified data requires no classification step and no inference-location control, since it isn't personally identifiable

    This skips both stated requirements — internal policy still requires classification before any AI use, and the regulator's inference-location requirement applies regardless of de-identification status.

Build exercise: Distinguish Inference Location, Storage Location, and Data Sensitivity

Intermediate · 20 minutes

You'll practice:

  1. In a browser, look up Anthropic's documentation on data residency and inference location, and write down, in your own words, the distinction between where inference runs and where data is stored at rest.

    This confirms your understanding of the two distinct concepts before applying them to specific scenarios, using the actual documented language rather than assumption.

    You should see: A short written explanation distinguishing 'where a request is processed' from 'where organizational data is stored long-term,' noting that these are controlled independently.

    Hints 
    1. Note whether the documentation frames per-request inference control separately from organization-wide storage configuration.
    2. Look for language that explicitly says these two things can be set independently of each other.
    3. If the terms feel interchangeable to you at first, write that down explicitly as the distinction to watch for.

  2. Draft a simple one-page data sensitivity classification for a hypothetical business, covering three tiers (e.g. public, internal, sensitive/regulated) with one or two example data types per tier. Note, for each tier, whether it could reasonably be sent to Claude at all, and whether it would need any special handling beyond a residency setting.

    This exercises the classification step that the lesson says comes before choosing a residency control — a skill distinct from just knowing the inference-vs-storage distinction.

    You should see: A short written classification with three tiers, example data types for each, and a one-line note per tier on AI-use suitability.

    Hints 
    1. Make your 'sensitive/regulated' tier concrete — health data, government IDs, or financial account numbers are good examples.
    2. For at least one tier, note that de-identification would reduce but not eliminate the need for classification.
    3. Keep each tier's note short — a sentence is enough to demonstrate the judgment.

  3. Write two short scenarios, modeled on the practice question, where one scenario's requirement is clearly about inference location only and the other is clearly about storage location only. Note which control fits each and justify your answer in one sentence.

    This exercises picking the correct, narrowly-scoped control based on which requirement is actually described, avoiding the common trap of reaching for the broader or wrong setting by default.

    You should see: Two scenarios, each correctly matched to either the per-request inference control or an organization-wide storage setting, with a one-sentence justification for each.

    Hints 
    1. Make the two scenarios explicitly contrast with each other, the way the practice question's options do.
    2. Double-check your justification references the specific requirement stated (inference vs. storage), not a general 'data residency' concern.
    3. Consider what would go wrong — which real requirement would go unmet — if you applied the wrong control to each scenario.

Sources