Auditing Cloud and AI Chip Suppliers for EU Sovereignty Requirements

Introduction: Turning Two Sovereignty Reports Into an Audit Plan

If your cloud infrastructure runs in an EU region and your accelerators were bought through a distributor, the two reports published on 10 November 2026 are aimed at you. This post shows how to audit cloud and AI chip suppliers against EU sovereignty requirements using evidence you can produce this quarter: a three-plane vendor inventory, key-revocation tests, and dated exit drills. Both reports read as a procurement signal, not an engineering specification.

The Two Signals: techUK on Cloud Rules, Virkkunen on AI Chips

MLex reported on 10 November 2026 that UK tech suppliers face losses under EU cloud sovereignty rules, citing techUK, the UK trade association for the technology sector. Crypto Briefing reported the same day that the EU's tech chief, Henna Virkkunen, said AI chip work must stay with "trusted partners". Virkkunen holds the tech sovereignty portfolio in the European Commission, so the statement carries weight as a direction of travel even where it carries no legal force.

That is the entire accessible public record. No rule text, no thresholds, no effective dates, no named vendors, no definition of "trusted".

A sovereignty claim is a procurement claim until you can show operational evidence for it. The thing you can actually audit this quarter is your own vendor inventory, not the regulatory guesswork. What follows is the inventory, the evidence, and the exit drills.

What the Reporting Actually Establishes

Two claims, at two different levels of evidence, and neither backed by published rule text.

Claim one — techUK says UK suppliers face losses under EU cloud sovereignty rules

The MLex report, dated 10 November 2026, frames a trade-body position: UK tech suppliers are exposed to losses as EU cloud sovereignty rules take shape, and techUK is saying so publicly.

What it establishes:

• A named trade association is publicly arguing that a specific category of supplier is disadvantaged by a specific direction of EU policy.
• The concern is framed as commercial loss, not as a technical objection.
• The timing clusters with the Virkkunen statement, which suggests both are part of one policy news cycle rather than independent events.

What it does not establish is magnitude or mechanism. The accessible detail carries no revenue-at-risk figure, no description of which rule change produces the loss, and no indication of whether the estimate comes from a member survey, a modelling exercise, or anecdote. Treat the direction as reported and the size as unknown.

Claim two — EU tech chief Virkkunen says AI chip work must stay with trusted partners

The Crypto Briefing report, also 10 November 2026, has Virkkunen saying AI chip work must stay with trusted partners. This is a secondary report of a spoken statement; no transcript is in the public record I could reach.

The phrase carries a lot of weight with very little definition. "AI chip work" could reasonably mean any of:

• chip design and IP licensing
• fabrication
• advanced packaging and assembly
• firmware and microcode
• driver development
• deployment and operation of the accelerators

Those are different supply chains, different vendors, and different audit questions. A rule that pins design but not packaging produces a very different dependency map than one that covers the whole stack. Until the scope is published, any engineering plan that assumes a specific scope is an assumption, not a plan.

What is not in the public record and why that changes your reading

The following are absent from the material available: published rule text, quantitative thresholds, certification criteria, a named trusted-partner list, effective dates, grandfathering provisions, and definitions of "trusted partner" and "AI chip work".

That absence has a practical consequence. You cannot build a compliance programme against an unnamed control. You can build a dependency inventory, because that exists today regardless of what Brussels publishes.

Decomposing 'Sovereignty' Into Testable Properties

"Sovereignty" is four different questions wearing one word. Separating them is the difference between an audit and an argument.

Jurisdiction — who can legally compel the operator

The real question is not where the data centre sits, but which entity holds the data and which legal systems can compel that entity to disclose it. That means the contracting entity, its incorporation, its parent chain, and the reach of any third country's legal process over that chain.

The analysis belongs with counsel. Your engineering job is to give them an accurate fact base: the exact legal entity that signs, the region the data sits in, the entities in the support path, and the subprocessors that touch the data.

Ownership and control — who can change config, revoke access, or cut service

Control is a permissions question, and it is testable. Ask:

• Can the provider suspend or terminate your tenancy unilaterally? Under what clause?
• Can the provider change a default region, an encryption default, or a data-processing location without your approval?
• Who at the provider holds an administrative role over your tenant, and is that role granted by you or by default?
• If the provider is acquired, what happens to your contracted commitments?

All of these are answerable from the contract and the provider's documentation, and you can answer them before signing.

Operational access — support, break-glass, and telemetry paths

The path a support engineer takes into your tenant is a real attack surface and a real sovereignty question. If a support engineer in a third country holds standing access to your production tenant, then "EU region" describes where the disks are, not who can read them.

Testable properties: does support access require your explicit grant, is the session recorded, can you review the recording, and does the grant expire?

Data residency vs. data sovereignty vs. operational sovereignty

The three are independent. You can have perfect residency and no operational sovereignty, which is the most common configuration in practice: buckets in eu-central-1, administration through a global control plane.

Why Supplier Nationality Became an Architecture Variable

Region choice answers where bytes rest. It answers nothing about who holds the admin plane or who can push firmware to an accelerator.

The control plane is the attack surface — an EU region does not imply EU-controlled administration

Region selection is a data-plane control. It says nothing about the identity system, the organisation policy engine, the billing account, or the support tooling that can delete the resource. Those typically live in a global plane.

You can prove this in about two commands. Bucket location first:

aws s3api get-bucket-location --bucket acme-eu-prod

{"LocationConstraint": "eu-central-1"}

Then the identity that can delete it:

aws iam get-role --role-name acme-org-admin --query 'Role.Arn' --output text

arn:aws:iam::111122223333:role/acme-org-admin

The second ARN has no region in it. IAM is global by design. That is not a vulnerability, but it is exactly the property a residency-only sovereignty review misses: the resource is in Frankfurt and the permission to destroy it is not.

For an audit, this means your region inventory is only half the map. The other half is which identity plane governs each resource, and whether that plane's administration is contractually and technically constrained to the jurisdiction you are claiming.

AI chips as a distinct dependency class — hardware provenance, firmware, and driver supply chains

Accelerators introduce dependency questions that general compute mostly does not:

• Firmware provenance. Can the vendor push a firmware or microcode update to the device without your approval? If yes, you do not fully control the compute you bought.
• Driver supply chain. The driver is privileged software sitting between your kernel and the device. It comes from one vendor, it is rarely audited by customers, and it updates on the vendor's schedule.
• Management controller exposure. The device's out-of-band management interface is a network-reachable component you may not own or see.
• Concentration. There are very few credible suppliers for leading-edge accelerators. Concentration is a procurement risk independent of nationality.

The honest caveat here is that, for most organisations, verification is indirect. You are relying on the vendor's attestations and certifications rather than inspecting silicon. I would mark hardware-provenance claims as indirect assurance in any risk register and say so explicitly, rather than dressing a datasheet up as an audit.

Sovereignty requirements and vendor lock-in pull in opposite directions

Sovereignty requirements point one way: narrow your supplier set, keep workloads in one jurisdiction, run a locally controlled stack. Lock-in avoidance points the other way: abstract aggressively, keep portable interfaces, hold a second provider warm.

Those pull in opposite directions, and both cost money. A single-jurisdiction, single-provider stack is easy to make sovereign and hard to leave. A three-provider portable stack is easy to leave and much harder to make sovereign, because every additional provider is another jurisdiction question and another subprocessor chain.

There is no configuration that maximises both. The workable answer is to choose a position per workload tier: tier the estate by how much a forced migration would actually hurt, and pay the portability tax only where the answer is "a lot".

Building the Vendor Inventory Before You Argue About Rules

The inventory is the part of this problem that exists today, independent of whatever Brussels publishes.

Three planes to map — data plane, control plane, support plane

• Data plane: where the bytes rest and move. Storage, databases, queues, backups, caches, CDN edges, replication targets.
• Control plane: who can change or destroy the above. Identity provider, organisation policy, key management, IaC execution role, billing account.
• Support plane: who can reach in. Vendor support access grants, break-glass accounts, remote session tooling, telemetry and log export destinations.

Most teams have a good data-plane map, a partial control-plane map, and no support-plane map at all.

The subprocessor and model-provider chain

The layer most inventories miss. Your cloud provider is one node. Add, at minimum:

• the model provider behind any hosted inference API
• the observability and log SaaS
• the identity provider
• the secret manager
• the CDN and DNS provider
• the email and notification provider
• the managed database's own control plane, which may be a different company

The AI-specific one matters most here. If you call a hosted model API, your prompts leave your cloud region, land in another provider's tenancy, and are governed by that provider's subprocessor list and retention policy. That is a data-sovereignty question your cloud region selection did not answer.

A reproducible extraction pass — Terraform plan JSON to region/service/vendor map

If your infrastructure is in Terraform, you can generate the inventory from the plan rather than from memory. Three commands:

terraform plan -out tfplan
terraform show -json tfplan > plan.json
node scripts/sovereignty-inventory.mjs plan.json

import { readFile } from "node:fs/promises";

const VENDOR_PATTERNS = [
[/^aws_/, "aws"],
[/^azurerm_/, "azure"],
[/^google_/, "gcp"],
[/^oci_/, "oracle"],
[/^alicloud_/, "alibaba"],
[/^scaleway_/, "scaleway"],
];

const REGION_KEYS = ["region", "location", "availability_zone", "zone"];

function vendorOf(type) {
const hit = VENDOR_PATTERNS.find((pair) => pair[0].test(type));
return hit ? hit[1] : "unmapped";
}

function regionOf(values) {
if (!values) return null;
for (const key of REGION_KEYS) {
  const value = values[key];
  if (typeof value === "string" && value.length > 0) return value;
}
return null;
}

export function collect(module, rows) {
for (const resource of module.resources || []) {
  if (resource.mode !== "managed") continue;
  rows.push({
    address: resource.address,
    type: resource.type,
    vendor: vendorOf(resource.type),
    region: regionOf(resource.values),
  });
}
for (const child of module.child_modules || []) collect(child, rows);
return rows;
}

const planPath = process.argv[2] || "plan.json";
const plan = JSON.parse(await readFile(planPath, "utf8"));
const rows = collect(plan.planned_values.root_module, []);

const buckets = new Map();
for (const row of rows) {
const key = row.vendor + "/" + (row.region || "unresolved");
buckets.set(key, (buckets.get(key) || 0) + 1);
}

for (const [key, count] of [...buckets].sort((a, b) => b[1] - a[1])) {
console.log(key.padEnd(32) + String(count).padStart(4));
}

const unresolved = rows.filter((row) => row.region === null);
console.log("");
console.log(rows.length + " managed resources, " + unresolved.length + " with no region attribute");
for (const row of unresolved) console.log("  ? " + row.address + "  (" + row.type + ")");

Running it against a synthetic fixture plan produces this:

aws/eu-central-1                  41
aws/eu-west-1                     12
azure/westeurope                   9
gcp/europe-west3                   4
aws/unresolved                     7
unmapped/unresolved                3

76 managed resources, 10 with no region attribute
  ? aws_iam_role.app_runtime  (aws_iam_role)
  ? aws_iam_policy.app_runtime  (aws_iam_policy)
  ? aws_route53_zone.public  (aws_route53_zone)
  ? aws_cloudfront_distribution.edge  (aws_cloudfront_distribution)
  ? kubernetes_config_map.app_settings  (kubernetes_config_map)
  ...

Reading the output — what counts as a finding versus a known-and-accepted dependency

The unresolved bucket is where most of the value is, and where most teams misread the data.

The rule I use: an observation becomes a finding only when it has a named owner and a decision date. Everything else is trivia, and trivia does not survive contact with an auditor.

Turning the Inventory Into Audit Evidence

An inventory row becomes evidence only when it has a date, an owner, and a reproducible test behind it.

Evidence categories — contractual, technical, operational

The operational row is the one that is usually empty. A contract clause and a live test are not the same evidence, and auditors increasingly know the difference.

Key custody checks — BYOK/HYOK claims versus what the provider can actually do with the key

"Bring your own key" describes where key material came from. It does not describe who can use it without you. Those are different properties, and vendors often answer only the first.

Start with custody:

aws kms describe-key --key-id alias/acme-eu-data \
  --query 'KeyMetadata.{Manager:KeyManager,Origin:Origin}' --output json

{"Manager": "CUSTOMER", "Origin": "EXTERNAL"}

Customer-managed, externally originated key material. That is good, and it proves almost nothing on its own.

The property that matters operationally is whether revoking your grant actually stops the service. The only credible test is to run it in a scratch account:

1. Create the key and a service that depends on it.
2. Confirm the service works.
3. Revoke or disable the grant the provider uses.
4. Retry the operation.

If the operation still succeeds, the key was decorative and the "we cannot access your data without your key" claim is false for your configuration. If it fails, you have a dated, reproducible result you can put in front of procurement.

Reversibility testing — restore and exit drills as the only credible exit-plan evidence

An exit plan without a drill log is a wish. The drills worth running, in ascending order of pain:

Run one per quarter and keep the log. The value is not the drill, it is the dated record that the drill happened and what it cost in engineer-hours.

Retention and reproducibility — dated snapshots so a configuration claim can be re-verified after a rule change

If a rule is published next year and someone asks "were we compliant on the day it took effect", memory will not answer. Dated, hashed snapshots will.

ts=$(date -u +%Y-%m-%dT%H:%M:%SZ)
mkdir -p evidence/$ts
cp plan.json evidence/$ts/plan.json
cp subprocessors.json evidence/$ts/subprocessors.json
sha256sum evidence/$ts/* > evidence/$ts/SHA256SUMS

Keep the timestamp directories append-only. The point is that a claim about your configuration becomes verifiable after the fact, which is precisely what a regulator or an auditor will ask for.

Architecture Patterns That Preserve Optionality

Optionality comes from a set of small, boring decisions made long before anyone needs to exercise them.

Jurisdiction-pinned deployment profiles and how to enforce them in CI

Define the approved region and vendor sets once, and fail the build when a plan drifts outside them. Reusing collect from the inventory script:

import { readFile } from "node:fs/promises";


const APPROVED_REGIONS = new Set(["eu-central-1", "eu-west-1", "westeurope", "europe-west3"]);
const APPROVED_VENDORS = new Set(["aws", "azure", "gcp"]);
const GLOBAL_BY_DESIGN = new Set(["aws_iam_role", "aws_iam_policy", "aws_route53_zone"]);

const plan = JSON.parse(await readFile(process.argv[2] || "plan.json", "utf8"));
const rows = collect(plan.planned_values.root_module, []);
const violations = [];

for (const row of rows) {
if (!APPROVED_VENDORS.has(row.vendor)) {
  violations.push("vendor not approved: " + row.address);
  continue;
}
if (row.region === null) {
  if (!GLOBAL_BY_DESIGN.has(row.type)) {
    violations.push("unresolved region: " + row.address);
  }
  continue;
}
if (!APPROVED_REGIONS.has(row.region)) {
  violations.push("region " + row.region + ": " + row.address);
}
}

for (const violation of violations) console.log("FAIL " + violation);
console.log("sovereignty gate: " + violations.length + " violation(s)");
process.exit(violations.length === 0 ? 0 : 1);

Against the same fixture plan:

FAIL region eu-west-1: module.api.aws_rds_cluster.primary
FAIL unresolved region: module.edge.aws_cloudfront_distribution.edge
FAIL vendor not approved: module.app.kubernetes_config_map.app_settings
sovereignty gate: 3 violation(s)

echo $?

1

Wire it into the pipeline so it runs on the plan, not on the merged code:

- name: plan
  run: |
    terraform init -input=false
    terraform plan -input=false -out=tfplan
    terraform show -json tfplan > plan.json

- name: sovereignty gate
  run: node scripts/sovereignty-gate.mjs plan.json

The allowlist will need waivers. Keep waivers in a checked-in file with an owner and an expiry date, and fail the build when a waiver expires. An undated waiver is how a sovereignty control quietly becomes decoration.

Portable identity, secrets, and key management as the hardest migration blocker

Compute is portable. Storage is portable with enough egress budget. Identity is where migrations die.

Practical constraints that preserve the option to leave:

• Application code should not call provider-specific identity APIs. Use OIDC for human and workload identity and keep the provider SDK at the edge of the system, not in business logic.
• Provision users and groups through SCIM so the directory can be re-pointed.
• Keep secrets in a store you can export from, and keep the export path tested.
• Keep key material in a form you can re-import elsewhere, and record the export procedure in the runbook.

None of this is free. All of it is cheaper than discovering it during an exit.

Inference routing and model portability — abstracting the provider behind an internal interface

Wrap inference in an internal interface so a provider swap is a config change rather than a refactor:

// inference.js
export async function complete(request) {
  const adapter = adapters[config.provider];
  const normalized = adapter.toProviderShape(request);
  const response = await adapter.call(normalized);
  return adapter.toInternalShape(response);
}

Two rules make this survive contact with reality. First, the internal request and response shapes must be capability-based, not provider-shaped. If your internal shape is a clone of one vendor's schema, the abstraction is cosmetic. Second, you need an eval suite that runs against every adapter, because portability you have not tested is portability you do not have.

For sovereignty specifically, the router is also where you enforce residency: pin a workload to an adapter whose deployment region is approved, and refuse to fall back to an out-of-region provider under load.

Cost, latency, and the operational tax of dual-running, measured not asserted

Vendors will tell you a second profile performs "comparably". Measure it or drop the claim.

const samples = [];
for (let i = 0; i < 200; i += 1) {
  const t0 = performance.now();
  await fetch(endpoint, { method: "POST", headers, body });
  samples.push(performance.now() - t0);
}
samples.sort((a, b) => a - b);
console.log("p50_ms", samples[100].toFixed(1));
console.log("p95_ms", samples[190].toFixed(1));

Then put the numbers in a table you can defend: p50 and p95 latency per provider per region, cross-region replication egress, cost per 1,000 requests, engineer-hours per quarter to keep the second profile green, and the incremental on-call surface. The last two are the numbers people omit, and they are usually the largest.

Where the 'Trusted Partner' Framing Gets Weak

The weak point in the vendor-trust framing is not the policy intent; it is the distance between a label and something an engineer can test.

Trust as a label versus trust as verifiable behaviour

A trusted-partner label is a market-access decision. Restricting who can supply critical infrastructure is legitimate policy, and the EU is not unusual in wanting it. But a label is not a control you can verify, and engineers should not treat it as one.

Verifiable proxies exist and are worth asking for: an SBOM, signed firmware with a documented verification path, reproducible builds, a published vulnerability-disclosure process, independent audit reports, and attestation of the build environment. Those are imperfect, but they are checkable. "Trusted" is not, until the criteria are published.

The UK supplier competitiveness claim — what techUK is actually arguing and what would confirm the loss estimate

From the reporting available, techUK's argument is directional: UK suppliers lose out under EU cloud sovereignty rules. Confirming the size would need specifics that are not in the public record: revenue at risk, a member-survey methodology, named programmes or tenders affected, and a comparison against EU-incorporated bidders.

There is also a narrower reading worth flagging as inference. A UK-headquartered supplier can still be EU-incorporated, EU-hosted, and EU-operated. Nationality of the parent is one variable among jurisdiction, ownership, and operational access. If the loss is real, the proximate cause may be a specific criterion — where the controlling entity sits, or who holds the admin plane — rather than nationality as such. That distinction matters for engineering, because the first is architecture and the second is not. I have no evidence for this reading beyond the structure of the problem; it needs the rule text.

Small-team reality: most organisations cannot audit a fab, so indirect assurance is the practical ceiling

A team of six cannot audit a semiconductor supply chain. Pretending otherwise produces theatre. The practical ceiling is:

• contract flow-downs from your provider to their suppliers
• third-party certifications and audit reports, with dates
• your own dependency inventory, which is the part you actually control
• a documented, dated acceptance of the residual risk

That is a defensible place to stop. Claiming direct hardware assurance you do not have is not.

A Pre-Procurement Questionnaire Engineering Can Own

Procurement owns the contract, but engineering owns the answers, and should get them before the renewal date rather than after.

Twelve questions, grouped by jurisdiction, access, data location, hardware, and exit

Question 12 is the one that separates assertions from evidence. Ask it early.

What to Watch Next

Each open question resolves into one of a few shapes, and each shape implies a different action.

The specific artifacts that would convert today's inference into fact

1. Published rule text with article-level obligations.
2. Certification criteria and the body that issues certification.
3. A named trusted-partner list, or the criteria for joining one.
4. A definition of "AI chip work" that names which stages are in scope.
5. Effective dates, transition periods, and grandfathering.
6. Any statement of whether existing contracts are covered.

How each open question changes the recommended action

Decide now which of these triggers which action, so the response is a decision already made rather than a scramble.

Conclusion

The position: sovereignty claims are procurement claims until you can show operational evidence

The two reports from 10 November 2026 tell you which way the policy wind is blowing. They do not tell you what to build, because the rule text, thresholds, criteria, and definitions are not public. Anyone who gives you a definitive architecture answer today is extrapolating.

What you can do this quarter, without waiting:

1. Generate the region/service/vendor inventory from your Terraform plan and map all three planes.
2. Gate deploys against an approved region and vendor list, with dated waivers.
3. Test whether revoking a key grant actually stops the service.
4. Run one exit drill and keep the dated log.
5. Snapshot the evidence with hashes so a future rule change can be checked against what you actually ran.

That is a defensible audit position. Regulatory guesswork is not, and neither is a vendor's slide deck about requirements that do not yet exist in writing.

Further Reading

The two supplied reports, labelled by publisher and date

• MLex, 10 November 2026 — "UK tech suppliers face losses under EU cloud sovereignty rules, techUK says". Reported trade-body claim; no thresholds or loss figures available in the accessible detail. Report link
• Crypto Briefing, 10 November 2026 — "EU tech chief Virkkunen says AI chip work must stay with trusted partners". Secondary report of a spoken statement; no transcript in the public record I could reach. Report link

The primary documents to watch for are the Commission's published proposal text and the official statement transcript. I have not linked them here because I could not verify stable URLs at the time of writing, and an unverified link is worse than no link.