A European healthcare provider wants to deploy a Foundry-hosted assistant that processes patient intake notes, and its legal team requires that patient data never leave the European Union at any point in processing, per GDPR obligations. What should the team do when creating the Foundry resource and model deployment?
Select an answer to reveal the explanation.
Short Explanation
This is about geography, not model behavior. You need to pick an Azure region inside the EU for both the Foundry resource and its model deployment, so patient data is processed and stored within EU boundaries. Safety filters, model size, and fine-tuning don't control where the servers are.
Full Explanation
The correct choice is selecting an Azure region within the European Union for both the Foundry resource and its model deployment. That keeps data processing and storage within European Union boundaries, which is the direct, supported way to satisfy a data residency requirement tied to GDPR. The content-filtering choice is incorrect because content filtering screens generated and submitted text for harmful content categories; it has no bearing on which geographic region processes or stores the data, so it does nothing to satisfy a residency requirement. The smaller, faster model choice is incorrect because model size and speed affect latency and cost, not where the computation physically occurs; a faster model deployed in a non-European Union region would still violate the residency requirement regardless of how briefly the data is in transit. The fine-tuning-on-anonymized-data choice is incorrect because fine-tuning on anonymized data might reduce exposure of specific patient identities during training, but the live deployment still needs to process real, current patient intake notes to be useful, and fine-tuning does not control which region that live processing happens in. Region selection at resource creation time is the mechanism that actually determines data residency, and it is the step the legal team's requirement is really about.