"We Have a UK Region" Is Not an Answer

#ai #machinelearning #cybersecurity #agents

What developers should actually ask AI security vendors before prompts start crossing borders

A vendor page that says "available in the UK" tells you almost nothing about where your prompts end up. It usually describes the platform, not the AI feature you are about to wire into production. Those are frequently different systems, with different storage backends and different telemetry pipelines.

This matters more for AI products than for the rest of your stack. A prompt is not a row in a database. It carries whatever the user pasted into it, plus retrieved context, plus tool output. Your logs then carry the same content a second time. So "where is our data" splits into at least four questions: inference, retrieval, logs, and support access.

Residency is not the legal control

The first thing to get straight is that UK GDPR does not regulate storage location directly. It regulates transfers. Hosting in London is evidence, not compliance. What you actually need is a named recipient and a valid transfer mechanism behind it.

Two recent changes shape how that assessment reads today. The Data (Use and Access) Act 2025 brought most of its data protection provisions into force on 5 February 2026, and it replaced the old "essentially equivalent" threshold for transfers with a "not materially lower" standard, as summarised in this breakdown of the new transfer regime. Separately, the European Commission renewed UK adequacy, which now runs to 27 December 2031, so EU to UK flows stay straightforward for the medium term.

On the engineering side, the NCSC is blunter. Cloud Security Principle 2 expects you to know the countries where your data is stored and processed, and to be able to justify that choice. That is a question you have to be able to answer on demand, not one you answer once in a procurement form.

The six questions

NeuralTrust's review of UK data residency across AI security vendors looked at public documentation for sixteen products and found that very few of them state a UK region for the AI component specifically. Several document a UK element somewhere in the platform without confirming it covers the AI features. Several solve it by shipping into your own environment instead. For the rest, nothing public was found, which is not the same as nothing existing.

So you ask directly, and you ask per data type:

Which region stores and processes prompts and model outputs
Where logs, traces, and telemetry are written
Who the sub-processors are and where each one sits
Whether support staff outside the UK can read customer data
Which transfer mechanism applies when the answer is not "UK only"
Whether the UK region covers the AI product or only the wider platform

Question six is the one that catches people. It is also the cheapest to verify, because the answer is either in the vendor's documentation or it is not.

Make it an architectural constraint, not a promise

The durable fix is to stop relying on a vendor's answer and start enforcing the boundary yourself. Route model traffic through a gateway you control, pin the egress, and make a violation fail closed rather than silently route to a US endpoint during a failover.

policies:
  - name: uk-residency
    match:
      workspace: uk-prod
    providers:
      allow:
        - azure-openai/uk-south
        - bedrock/eu-west-2
      deny: ["*"]            # no implicit failover outside the region
    data:
      redact_pii_before_egress: true
      prompt_logging:
        store: uk-south
        retention_days: 30
    on_violation: block

The shape matters more than the syntax. An allowlist with an explicit deny beats a default that falls back on the nearest healthy region. Logging needs its own destination, because that is where residency assumptions usually break. And redaction before egress reduces how much of the problem you have to solve with geography in the first place.

This is one of the reasons split control plane and data plane deployments keep showing up in regulated buying. Running the data plane in your own perimeter turns residency into something you can verify with a packet capture rather than something you take on trust. The broader tradeoffs between a hyperscaler region, a private cloud, and a fully air-gapped install are worth reading up on before you commit, and NeuralTrust's guide to data sovereignty for enterprise AI covers them in more depth than fits here.

Agents widen the blast radius

Everything above gets harder once the workload is agentic. An agent calls tools, writes to memory, and chains steps that each produce their own traffic and their own logs. A residency answer scoped to a single inference call does not cover a run that touched six services. If that is where you are heading, the threat model is worth working through properly, and Agent Security is a reasonable starting point for the categories involved.

The short version

Treat "UK region" as a claim to test rather than a feature to tick. Ask the six questions in writing. Get the answers per data type. Then put the boundary somewhere you control, so the next vendor who changes their hosting footprint does not quietly change your compliance posture with it.

DEV Community