The question always arrives in the same order. An SMB deploys Copilot because it is already in the tenant. Six months later, someone reads that another model is better at writing, and a third better at document analysis. And the question lands: should we be using several?

Comparison articles answer with leaderboards and cost per million tokens. That is the wrong answer, because it is the wrong question.

The real cost is not the token

Model call prices keep falling. That is not where multi-model costs you money. It costs you elsewhere, on four lines that pricing pages do not show.

Routing has to be maintained. Deciding which request goes to which model is code or configuration. It lives, it breaks, it needs updating when a vendor retires a model. Someone has to own that component.

Evaluation doubles. You cannot claim a model is better for your case without measuring it on your data. Two models means two test sets to write and rerun at every version change.

The inventory grows. Each added model is one more vendor in the register your obligations require you to keep: purposes, data in, data out, contract. Our post on the CAI’s recommendations covers what that inventory must hold.

The compliance surface widens. And that is the most badly estimated line, for a specific reason.

The trap: hosted in Canada is not processed in Canada

Here is what vendor documentation says, and what almost nobody checks before signing.

A note on scope: if you only use Copilot inside Microsoft 365, you never choose these settings. The question arises as soon as you connect a model through an API or build an agent, which is exactly the moment multi-model comes into play.

Microsoft explicitly separates storage from processing for models served through Azure. The deployment types documentation, updated in August 2026, is unambiguous: data stored at rest remains in the designated Azure geography, but where inference is processed depends on the deployment type you choose.

Deployment typeWhere inference is processed
GlobalAny Azure region, worldwide
Data ZoneOnly within the designated zone: United States, European Union or Asia Pacific
Standard and Regional ProvisionedWithin the chosen Azure geography, Canada for instance

Three things follow.

There is no Canada data zone. The three zones offered are the United States, the European Union and Asia Pacific. For a request to be processed in Canada, you need a geography-based deployment in a Canadian region, not a zone.

The recommended default is Global, the one that can route anywhere. The documentation says so plainly: for most workloads, start with Global Standard. It is the default choice, and it is the one that sends your requests out of the country.

Geography-based deployments arrive last. On the same page: new models ship first on Global, then Data Zone, and geography-based types arrive afterward, with no guaranteed availability date.

The picture is the same elsewhere. In November 2025 AWS published a post on cross-region inference in Canada explaining that data at rest remains exclusively in the Canada (Central) Region, while inference requests originating from Canada can be routed to US Regions depending on the profile selected. At Google, the Vertex AI documentation draws the same line between residency at rest and where machine learning processing happens.

Put differently: across the three major clouds, “our data is in Canada” and “our requests are processed in Canada” are two distinct claims, and only the second one is configured explicitly.

The consequence, which is counterintuitive

If your residency requirement is real, it cuts you off from the newest models at your primary vendor. At Microsoft, that is documented: models ship first on global deployments. At the others, compare the model list offered in the Canadian region against the global list before concluding.

That is where multi-model stops being a performance optimisation and becomes a structural answer: a geographically constrained model for processing that touches personal information, a newer and less constrained model for everything else. The routing criterion is not model quality. It is data sensitivity.

That architecture has a simple shape: two lanes, a clear border between them, and a written rule saying what goes where.

Three criteria to decide

1. Do you actually have a residency requirement? Not “we would prefer”. A documented requirement, touching identifiable personal information. A useful reminder: Quebec’s private-sector privacy act does not forbid sending personal information outside Quebec, it requires a privacy impact assessment before doing so (section 17). Routing inference to a US region falls under that rule as soon as personal information appears in the request. If yes, multi-model becomes likely, because one vendor will not serve both needs well. If no, one model is almost always enough.

2. Who maintains the routing? Name the person. If you cannot, you do not have a multi-model architecture, you have technical debt in preparation.

3. Does the volume justify the complexity? The cost gap between two models only becomes meaningful above a certain call volume. Below it, the billing difference does not pay for the maintenance hours. Our measurement method applies here unchanged: establish the real cost before changing architecture.

When it is premature

For most SMBs we see, multi-model arrives too early. The signs: no process is measured yet, nobody knows what call volume is actually produced, and the choice rests on a comparison read online rather than a test on your own data.

The right order is the same as for automation tooling: process first, measurement next, architecture last. One model well integrated into a mapped process beats two models wired to a hunch.

What to ask for in writing

Whatever the vendor, three questions whose answers belong in the contract rather than on a marketing page: where are requests processed, where is data kept at rest, and is content used to train models. A vendor that answers all three clearly makes your inventory easier. A vendor that answers vaguely has just answered.

To place your uses before touching architecture: our Law 25 and AI assessment asks the questions in order. And if the routing question is live at your organisation, we untangle it with you.