There are four places an AI model can run, from your own setup to anywhere in the world. Each step out gives you more models to choose from and less control over where your data goes.
Your rule sets the limit. The job picks the boundary.
Your residency rule decides how far out you're allowed to go. Within that limit, the job decides. For regulated data, that usually means boundary 1 or 2 with a smaller model, tested on real examples. For everything else, use whatever does the job best. Only move a regulated job further out when testing shows nothing closer does it well, and you can show your working.
Your account isn't your own setup. Using a model through your own cloud account feels like running it yourself. It's in your account, on your bill and in your region. But the provider runs the model, so you're relying on their terms. That's boundary 2, not boundary 1. Boundary 1 means you host the model yourself.
Your region isn't always where the model runs. When someone asks "which region are we in?", they could mean three things: where the data is stored, where the service is set up, or where the model runs. The boundaries are about the last one, and it's usually a separate setting. Azure, AWS and Google all offer the same choice under different names: one region, a wider area, or global. In most consoles, boundary 2 and boundary 3 are one dropdown apart.
This puts two things on one line: where the model runs and who runs it. They don't have to move together. In practice they do, because each step out trades control for choice.
It goes wrong in the other direction too. When nobody can say where their AI runs, the safe answer is to block it. A lot of companies limit AI simply because they don't understand it, and miss out on jobs that were safe all along.
It also only works per job. One rule for the whole organisation means the strictest rule sets the limit for everything, including work that never touches regulated data.
So you'll usually end up with more than one model, in more than one boundary. That's normal. You can even split a single job by what each step sees. A bigger model further out can work out what's being asked. A smaller one you control can handle the data itself.
You don't have to wire this up by hand. A supervisor, an AI that reads each request and decides which model should handle it, can do the routing for you. It sends anything that touches the data to the model you control, and the rest further out. The catch is that the supervisor sees every request, so it has to sit inside your strictest boundary.
When I've done this before, we sorted each piece of work by the data it touched, then ran it inside the boundary that matched. Two things came out of it that I didn't expect.
We understood our own data better. You can't sort work by sensitivity until you know which systems hold what. That did more than any governance exercise had.
Changing models got easy. When code asks for a specific model, every upgrade means changes everywhere. When it asks for a boundary instead, swapping the model is one decision in one place.