A logistics company operates across the European Union and must keep all AI processing within EU data centers for regulatory reasons. When browsing the Foundry model catalog, the team finds that the specific frontier model their prototype was built on is not offered as a deployment option in any EU region. What should the team do?

The compliant path is to select a different catalog model that is offered for deployment in an EU region and adapt the prototype to it, because regional data residency is a hard regulatory constraint and the only compliant path is to choose a model that can actually run within the required boundary rather than trying to work around where the data is processed. Deploying the original model in a non-EU region and routing requests through a VPN to mask the traffic origin is incorrect because a VPN changes where the traffic appears to originate on the network, not where the model actually executes and processes the data, so the underlying compliance problem is not solved; it is only obscured. Deploying the original model in a non-EU region because Foundry's terms of service supersede local data residency rules is incorrect because a cloud provider's terms of service do not override the regulatory data residency requirements a company operating in the EU is subject to, so that reasoning inverts the actual legal relationship. Keeping the prototype design unchanged and requesting an exception from the compliance team after launch is incorrect because launching first and seeking a compliance exception afterward exposes the company to the very violation it is trying to avoid; residency requirements need to be satisfied before processing happens, not retroactively excused.