Where does model inference run, and what leaves with it?

Every other hop in a security platform was designed by the vendor and appears in their architecture. The model hop is frequently a call to somebody else's API, which means it is a subprocessor relationship with its own terms, its own regions and its own retention behaviour.

That has a practical consequence: the answer can change without your involvement. A vendor switching model providers for cost or quality reasons has changed where your alert context goes, and unless the subprocessor list is change-controlled you will find out when you next read it.

It also has a contractual consequence. Your data processing agreement with the vendor covers the vendor. Whether it flows down adequately to the model provider is a separate question, and it is the one worth asking in writing.

Run the analyst on Anthropic, or an EU-hosted model that meets your residency rules.

It is tempting to treat model calls as metadata traffic, and for some product analytics that is fair. For security triage it is not.

To form a useful verdict a model needs the specifics: which account, which host, which process, which parent process, which destination, and often the text of whatever looked suspicious. That is the same material that makes the alert worth investigating, and it is customer content by any reading.

It can also include material you did not intend to send. A suspicious document attached to a phishing alert, a command line containing a credential, an error message quoting a database row. None of that is exotic, and all of it travels with the context.

Which model, named, and whether you are told when it changes. Model identity matters less for sovereignty than provider identity does, but a vendor who will not name it usually cannot name the rest either.

Which provider operates the endpoint, and under whose contract. This is the sovereignty question proper: it determines which legal orders reach the inference layer.

Which region executes inference. Distinct from where the provider is headquartered, and distinct again from where the vendor is hosted.

Whether prompts and outputs are retained, by whom and for how long. A zero-retention arrangement is a materially different exposure from a thirty-day one, and the difference is contractual rather than technical.

If the context contains personal data, and in security telemetry it almost always does, a transfer outside the EEA needs a lawful mechanism under GDPR Chapter V like any other transfer. The model layer is not a special case, it is just an easy one to overlook.

Under NIS2 Article 21 the vendor's dependencies are inside your supply chain assessment, and the model provider is a dependency. Under DORA Article 28 financial entities need contractual terms including where the service is provided from, which reaches the inference layer through the vendor.

The AI Act adds obligations that vary with the risk class of the system, and whether a given security tool falls into a regulated class is a legal assessment for your organisation. It is worth noting that none of these requires the inference to happen in the EU. They require you to know where it happens and to have a basis for it.