AI inference, and where it actually runs

Sentinel-Q sends security telemetry to a model endpoint: alert text, process command lines, hostnames, usernames, sign-in addresses. Where that endpoint performs the inference is a data-transfer question with a regulator attached to it, so the platform treats it as a question about evidence rather than a question about configuration. This article explains the difference, because that difference is the whole of the design and it is the part customers find counter-intuitive.

The short version: an operator declaring a region produces an assertion, and an assertion still reads as unverified. Not because we doubt the operator, but because a claim is not evidence, and the field exists to tell you which of the two you have.

The four provenance levels

Every residency verdict carries two values: a geography (eu, us, global, non-eu or unknown) and a provenance saying how we came to believe it. The provenance is the load-bearing half.

`verified` — observed from the platform itself

The model platform told us, in an API response, where it ran the inference. This level is not reachable today. Microsoft Foundry answers the relevant field with not_available, and no other provider we support reports it either. The hook exists in the code so that the day a platform starts answering, this starts verifying. Being explicit that the strongest level is currently unattainable is more useful to you than quietly not mentioning it.

`derived` — mechanically derived from documented rules

The endpoint URL, or a declared deployment SKU plus its region, resolves to a place through rules the provider publishes. This is the strongest level actually achievable, and it is what a passing configuration looks like in practice.

`asserted` — an operator said so

Somebody declared a geography that nothing in the request corroborates. It is recorded, it is attributed, and it does not satisfy the residency claim.

`undeclared` — nothing declared and nothing derivable

We cannot tell. Outside a development deployment this is a startup failure rather than a warning, because treating we could not tell as equivalent to it is fine was a real defect in an earlier version of this guard.

One function decides whether the residency claim holds, and the console page, the AI system card and the evidence bundle all call it. In plain words: the geography must be the EU, the provenance must be verified or derived, and nobody must have acknowledged non-EU inference. Any other combination reports unverified.

Why a declaration is deliberately not enough

An earlier version of this guard checked the region name in the endpoint URL. For the deployment in question that name read swedencentral, so the check passed and reported EU residency. The deployment was a globally distributed one, which serves requests from capacity anywhere regardless of where the resource sits. The guard was green and the claim was false — which is worse than having no guard, because a green check is what stops anybody looking again.

So the rule now is that the SKU decides whether the region matters at all. A region-scoped deployment type confines processing to its region; a global one does not, whatever its resource is called.

Where the region does matter, it is read from the endpoint hostname in preference to a declared value. A hostname is structural and an environment variable is a declaration, so the stronger evidence wins; the declared region is consulted only when the hostname carries none. The verdict records which of the two it used, so a reviewer can see it.

Nineteen Azure regions are recognised as EU, EEA or covered by a GDPR adequacy decision, including westeurope, northeurope, swedencentral, germanywestcentral, francecentral, italynorth, polandcentral, spaincentral, norwayeast and switzerlandnorth. uksouth and ukwest resolve as United Kingdom and therefore not EU. A region the platform does not recognise resolves to unknown rather than being accused of being non-EU.

The endpoint URL is the evidence

For the three non-Azure providers the URL is doing almost all of the work, and two specific URLs are worth memorising because they are the ones people get wrong.

https://eu.api.openai.com/v1                        eu       derived
https://api.openai.com/v1                           unknown  undeclared   → refused

https://europe-west4-aiplatform.googleapis.com      eu       derived
https://europe-west2-aiplatform.googleapis.com      non-eu   derived      → refused
https://generativelanguage.googleapis.com           global   derived      → refused

(direct Anthropic, any endpoint)                    global   derived      → refused

The refusal for OpenAI's global host is worth quoting, because it is a statement about what the platform can and cannot see rather than a statement about OpenAI:

Direct Anthropic is a different shape of answer, and the honest position is stronger than we cannot tell. Anthropic publishes two inference geographies, global and us, and neither is the EU. So the platform records that EU inference is known to be impossible for that provider, and an asserted EU claim against it is refused outright rather than accepted as an assertion: the declared inference geography "eu" is refused: it contradicts the provider's published geographies. No configuration of ours changes that, and telling you so is more useful than letting you configure something that will never satisfy a reviewer.

What happens when you declare a region by hand

You can declare an inference geography of eu, us or global. The declaration is accepted only into a slot the endpoint could not fill — it never overrides an established finding — and when accepted it produces asserted with this recorded basis:

And then the consequence, which is the sentence this whole article exists to make legible:

This is not scepticism about your competence. It is that the field is read by an auditor, and an auditor asking how do you know needs the answer to distinguish between "the endpoint hostname says so and Google documents what that means" and "our administrator believes the project was created with that setting". Both may be true. Only one is evidence. A field that collapsed them would be less useful than a field that does not exist.

The refusal, and the acknowledgement that is not a fix

A configuration whose geography is not established inside the EU or EEA is refused before the row is written, which matters: a disabled row with a sealed key inside it is a configuration somebody will later switch on without re-reading the refusal. You get HTTP 409 with the code residency_not_established, the derived geography, the provenance, whether EU is even possible for that provider, the recorded basis, and requires_acknowledgement: true.

It is 409 rather than 400 for a reason worth understanding: the request is well-formed and every value in it is valid. What is refused is the consequence.

The way through is an explicit acknowledgement, and the console's wording is the wording you are agreeing to:

What holds on the shipped configuration today

On the platform-managed provider as currently deployed, EU inference does hold, and it holds as derived rather than verified. The deployment is a model resource in Sweden (EU) with region-scoped deployments, so the SKU rules resolve the region and the region is an EU one. The AI system card reports it as established.

Two conditions on that, which are conditions and not footnotes.

1. It holds only for that provider and that SKU. The Claude-on-Foundry path is retained and reachable, and it has no EU inference geography on any platform. Selecting it re-requires the acknowledgement, which disclaims the claim rather than satisfying it.
2. There was a quality cost and it was paid deliberately. The EU-resident model on this configuration is measurably weaker on security-triage work than the alternative that could not be made EU-resident. If you would rather have the stronger model, that is a choice you can make with your own provider — and it is a choice with a residency consequence you will then own.

If your organisation cannot accept non-EU inference and cannot accept the EU-resident model either, the route through is to run without the model features. The posture assessment is deterministic checks and never calls a model. The detection library is rules. The evidence bundle and the audit chain are queries over your own data. You lose the investigation and the assistant; you do not lose the platform.

Where to read the verdict, and what to put in a questionnaire

Three surfaces, all computed from the same function, so they cannot disagree with each other.

• Settings › AI provider shows EU residency holds or Unverified, together with the fields Inference geography, How we know, Deployment type and Resource region. How we know is the provenance. Requires ai:provider.read, which is an administrator permission.
• The AI system card, at GET /api/v1/organizations/{orgID}/ai/system-card, gated on compliance:frameworks.read. Its inference_region field is the literal string unverified whenever residency does not hold.
• The evidence bundle, which carries the same card. See The evidence bundle.

The verdict is recomputed on every read rather than stored, so a change to the rules — a new region recognised, an adequacy decision withdrawn — applies to your existing configuration the next time anybody looks. That is deliberate. A residency verdict cached at the moment somebody pressed Save is a verdict about the past.

What to read next

1. Bringing your own AI provider — the configuration surface these rules are applied to.
2. The EU AI Act and your system card — the four cases the card distinguishes and the exact disclosure text for each.
3. Where your data lives — storage residency, which is the stronger and separate claim.