The Residency Evidence File: How UK Buyers Can Audit an AI Vendor's Data Footprint

When a UK organisation buys an AI service, the residency conversation often ends with a reassuring sentence: the data stays in the UK. That sentence may be true, but it is not evidence. Under UK GDPR, the controller remains accountable for where personal data is processed, who can access it and how long it is kept. In 2026, boards and audit committees are rightly asking for something more durable than a sales assurance. They want a receipt: a documented chain that shows what was claimed, what was tested and what remains uncertain.

This is not a legal opinion, nor a substitute for advice from counsel. It is a practical evidence-pack approach for UK buyers who need to verify an AI vendor's data flows, subprocessor locations and storage regions before renewal, during onboarding or at quarterly governance reviews.

Begin with a data-flow inventory, not a questionnaire

A generic security questionnaire will produce generic answers. Start instead with your own inventory of the AI use case. Identify the personal data that enters the service: prompts, uploaded documents, customer records, images, voice notes, outputs, feedback, support tickets, telemetry and logs. Note which items are personal data, which are special category data and which are confidential commercial information. Then mark the points where that data could leave your environment: inference, fine-tuning, model evaluation, content moderation, observability, backup, disaster recovery and vendor support.

That inventory becomes the scope of the evidence request. It also stops the discussion drifting into abstract promises about "the cloud" and keeps it focused on the specific service you are buying.

The five documents in a credible evidence pack

A credible pack normally contains five elements. First, the data processing agreement and the Article 28 terms that set out the processor's obligations, including subprocessing, assistance and deletion. Second, a current subprocessor register that names each entity, its role and its processing location. Third, a data-flow diagram that covers hosting, inference, support access, monitoring, backups and any model provider involved. Fourth, a technical configuration statement describing storage and processing regions, replication, backup location, retention periods and deletion mechanics. Fifth, an attestation or audit report whose scope actually covers the service in question.

Certifications such as ISO 27001 or SOC 2 are useful, but they are not residency evidence. They indicate that controls have been examined; they do not prove that a particular tenant's data is stored in a London region rather than replicated to Dublin, Frankfurt or Virginia. Treat them as supporting material, not the answer.

Read the subprocessor register like a map

A subprocessor register is often where the real geography appears. Look beyond the headline hosting provider. The register may include a content delivery network, an observability platform, a support ticketing system, an email provider, a model provider and a translation service. For each, ask where processing occurs, whether support staff can access customer data and what transfer mechanism applies.

Be wary of entries described only as "global" or "follow-the-sun". These are not necessarily unacceptable, but they require closer reading. If personal data moves outside the UK, the transfer needs a lawful mechanism and an assessment. The UK International Data Transfer Agreement or the UK Addendum to the EU standard contractual clauses may be relevant, depending on the vendor's structure. The point for the buyer is not to draft the mechanism but to confirm that it exists, that it covers the actual flow and that the vendor can evidence it on request.

Test the technical claims, not just the paperwork

Paperwork can be accurate and still incomplete. Ask the vendor's engineering or security team for a written statement on how tenant isolation, region selection, backup replication and deletion are configured. Clarify whether inference is always routed to the contracted region or can fail over elsewhere. Ask whether prompt logs and embeddings are stored, where they sit and how long they persist. Confirm whether customer data is used for model training and, if so, under what opt-out or contractual restriction.

Where possible, validate the statement with a controlled test tenant and sample data. Ask for a walkthrough of the administration console showing region settings and retention controls. Request a sample deletion record or a description of how deletion is verified across backups. These steps will not satisfy every auditor, but they turn a marketing claim into a testable assertion.

Map the evidence to UK GDPR obligations

The evidence pack should be read against your own accountability duties. Article 28 requires suitable processor guarantees and a written contract. Article 30 requires records of processing, including transfers and retention. Article 32 requires appropriate security. Transfer rules require a lawful route for any restricted overseas processing. Retention and deletion obligations require more than a policy statement; they require a mechanism.

Data residency is not the same as data sovereignty. A UK region may still be operated by a US-owned provider subject to foreign legal requests, and a UK storage location may sit alongside global support access. The evidence file should record these distinctions rather than flatten them into a single assurance.

Build a quarterly attestation routine

Residency evidence ages quickly. Subprocessors change, regions are added, support models shift and contracts are varied. A quarterly routine keeps board reporting accurate without turning governance into a continuous audit.

In the first month, refresh the AI use-case inventory and confirm which services handle personal data. In the second, request delta evidence: updated subprocessor register, confirmation of region settings, notice of any transfer changes and the latest attestation report. In the third, validate the evidence against the inventory, record exceptions and prepare a one-page attestation for the board or risk committee. That page should state the service, the evidence date, the confirmed storage and processing regions, any changes since the last review, open exceptions, the accountable owner and the next review date.

Keep the evidence in a register with version control. Treat a change of subprocessor, a new region, a merger or a material contract variation as a trigger for an out-of-cycle review.

When the evidence is thin

If a vendor cannot produce a coherent pack, do not simply accept the reassurance. Options include limiting the data sent to the service, using pseudonymisation, requiring a UK-only tenant, negotiating audit and notification rights, or delaying the purchase until the gap is closed. In some cases the right answer is a documented risk acceptance with an exit plan. What matters is that the decision is recorded and owned.

The residency receipt is not a certificate to frame on the wall. It is a living file that shows how you know what you know. For UK buyers in 2026, that is the difference between a comfortable claim and defensible governance.