UK-Hosted AI Still Needs a Deletion Test

The Sovereign Cloud

2 November 2026 | By Ashley Marshall

A London server can keep an unwanted client document indefinitely. The hosting location tells you nothing about whether the copies disappear.

UK hosting answers where, not how long

A server in London can keep an unnecessary client document just as effectively as a server elsewhere. Choosing UK hosting may help satisfy a contractual location requirement, reduce some transfer complications or support operational control. It does not tell you which copies exist, who can retrieve them, or whether your deletion process reaches them. Those are separate questions, and an AI purchasing decision needs separate evidence for each.

Consider a fictional accountancy practice building an assistant over its working papers. Its original files sit on a UK server. A document-processing service extracts the text, a search database stores passages, the assistant retains conversations, and an administrator enables diagnostic logging during setup. Even if every component operates in the UK, deleting the original PDF might leave several useful representations behind. This is a design example, not a claim about any particular supplier or client.

The practical distinction is between geography and lifecycle. Geography describes where storage and processing occur. Lifecycle describes collection, copying, use, retention and eventual disposal. A credible proposal should explain both, including which subcontractors and support arrangements sit outside the main hosting commitment. You should not have to infer the disposal policy from a flag beside a data-centre location.

The ICO’s 8 October 2026 announcement makes this a timely business question. It reports changes, or commitments to change, from ten leading foundation model developers, including stronger mechanisms for people to exercise their rights. That is not a certificate of compliance for your installation. Ask your supplier for a worked deletion example before approving real client information. If they can demonstrate hosting but cannot explain disposal, you have verified only half of the proposed control.

Map the copies before testing the delete button

Start with a simple information map, not a new software purchase. Follow one document from upload to final answer and list every place that can retain its contents or a meaningful derivative. Include the original file store, extracted text, search passages, vector database, conversation history, generated reports, logs, temporary processing folders and backups. Add exported spreadsheets and support attachments where those are actually used. The point is to describe your workflow, not produce an impressive generic diagram.

For each location, record an owner, purpose, retention rule and disposal method. A search index may need a stable document identifier so deletion can remove every passage belonging to that file. A generated report may have become a separate business record with its own retention purpose. An embedding is not automatically anonymous just because it is a list of numbers; assess what it represents and how it links back to an identifiable person. Treat that assessment as part of the system design.

The ICO’s AI data-minimisation audit toolkit specifically recommends mapping personal information across the AI lifecycle, identifying unnecessary duplicates and documenting retention schedules. It also asks for evidence that those schedules are followed, with justification for information kept outside them. The page notes that guidance is under review following the Data (Use and Access) Act, so check the current position when making a legal decision.

What this means in practice is straightforward: the supplier should be able to point from a source document to its derived records without a manual hunt through unrelated folders. Ask them to demonstrate this using fictional information. If nobody knows which search records came from the document, the deletion problem already exists. Buying another privacy dashboard will not repair missing relationships between your records.

Do not confuse search removal with destruction

A document disappearing from an assistant’s answer is useful evidence, but it is not proof of destruction. The assistant might have lost permission to see the file. The search index might have refreshed. The record might have been archived rather than deleted. These outcomes can all make the user-facing test look successful while the information remains available through administration tools, investigation systems or a later restoration.

Microsoft provides a concrete example in its 24 September 2026 security update. It describes archiving inactive SharePoint content while keeping that content subject to retention and legal hold policies and discoverable through eDiscovery. The content drops out of Microsoft 365 Copilot indexing until reactivated. The same update describes Priority Cleanup for approved permanent deletion. These are different controls serving different purposes, not interchangeable names for making a search result disappear.

Use that distinction in your acceptance checklist. First test whether ordinary users and the assistant can still retrieve the document. Then inspect the underlying stores, derived search records and relevant administrative views. Finally ask what remains under retention, investigation or backup arrangements. A supplier should be able to explain why each remaining copy exists and whether it can return to normal use. Screenshots of an empty conversation window do not answer those questions.

Do not demand indiscriminate destruction either. Your business may need records for a valid statutory obligation, dispute or other justified purpose. The right to erasure is not absolute, and a sensible retention assessment separates material that should disappear from material that must remain restricted. Ask the person responsible for data protection to approve the distinction. The operational objective is a truthful outcome: deleted where required, retained where justified, and unavailable to routine AI retrieval when it no longer belongs there.

Read retention promises at product and feature level

Supplier assurances become unreliable when a single sentence is stretched across an entire product family. 'We do not train on your data' answers a training question. It does not, by itself, answer how long requests remain in backend systems, whether uploaded files persist, or what happens when someone sends feedback. Likewise, 'zero retention' needs a defined scope rather than an assumption that every connected feature stores nothing.

Anthropic’s commercial retention guidance is a useful named example. It states that API inputs and outputs are automatically deleted from its backend within 30 days, with exceptions including longer-retained services under customer control, agreed alternative arrangements, policy enforcement and legal requirements. For commercial products that save conversations, deleting a chat removes it from history immediately, while backend deletion takes place within 30 days. Neither statement is a universal promise that clicking delete instantly removes everything.

The same guidance identifies further exceptions, including feedback-related data retained for five years and additional requirements for certain covered models. These details are not reasons to reject a supplier automatically. They are reasons to match the actual account, model, feature and contract to the information you intend to send. A separate application wrapping a model can also keep its own logs or documents independently of the model provider.

An October 2026 review by meeting-notes developer Humla illustrates how easily app, API and feature policies get conflated. It is a commercial developer’s interpretation, not regulatory guidance, so use the supplier’s primary documentation for decisions. In practice, write down the exact service and enabled features, link the applicable policy, and record any exceptions. Recheck that record when someone changes the model or adds file storage, feedback collection or another integration.

Run a deletion drill with fictional information

Choose one low-risk workflow and create a clearly fictional test document containing a unique marker. Use no real customer names, health details, payment information or confidential material. Record where the document is uploaded, which processing steps run, and where its content becomes searchable. Confirm that the assistant can retrieve the marker before you attempt deletion; otherwise, an empty answer afterwards tells you very little.

Next, trigger the disposal route your staff would actually use. Do not let the supplier substitute a special database cleanup that ordinary administrators cannot repeat. Record the time, the person or service making the request, and the stores expected to change. Test the original file, derived passages and conversation access separately. Querying the assistant once is not enough: it could simply choose a different answer or fail to retrieve a surviving copy.

What this means in practice is a small acceptance table with an expected result for each location. The source file might disappear immediately, a search index might update after a documented delay, and a provider’s backend copy might follow its contractual retention window. Record observed results separately from supplier assurances. You cannot independently prove deletion inside a provider’s private systems from your laptop; contractual commitments and audit evidence have a different role from your own checks.

Include a controlled restoration exercise in a non-production environment if backups are part of the design. Confirm that restored information does not quietly become searchable again without the disposal restrictions being reapplied. Agree the safe test boundary with the system owner. Your pass condition is not 'the model said it could not find it'. It is that each store has an accountable outcome, documented timing and evidence appropriate to the control being claimed.

Keep evidence without keeping the deleted document

The obvious objection is that this creates more administration for a small business. It can, if every disposal request becomes a lengthy technical investigation. The answer is to build repeatable controls into a narrow workflow before scaling it. One clear information map, one tested disposal process and one named owner are more useful than a large policy document nobody can apply. Start with the client information that creates the greatest confidentiality or contractual exposure.

Keep a lightweight disposal record containing the request reference, affected systems, completion times and relevant exceptions. Avoid copying the deleted document into that record as evidence. Even a diagnostic screenshot can recreate the very information you intended to remove. Use non-content identifiers where appropriate, restrict access to the record itself and set a justified retention period for it. Evidence should establish what happened without becoming another uncontrolled archive.

Backups deserve an explicit rule rather than a vague promise. Ask how long deleted information can remain in protected backup sets, who can restore it, and how restrictions are reapplied after restoration. Where immediate physical removal is not feasible, obtain a precise explanation of isolation and eventual expiry rather than claiming instant erasure. The appropriate arrangement depends on the system and the legal duties involved; a hosting postcode alone settles none of it.

Finally, make disposal part of change acceptance. Adding another connector, exporting chats to a CRM or turning on detailed tracing can create a new retained copy. Re-run the relevant part of the drill when those changes occur. Assign someone to check policy and contract updates rather than assuming last year’s assurance still applies. UK-hosted and locally operated AI can be valuable choices, but control means knowing what remains after you ask the system to forget. Make the deletion test part of the purchase, not an emergency task after the first complaint.

Frequently Asked Questions

Does UK GDPR require all AI data to stay in the UK?

No. UK data protection law does not impose a blanket UK-only hosting requirement. International transfers, contractual restrictions, sector duties and the specific processing arrangements still need assessment.

Does deleting the original file remove it from an AI search index?

Not necessarily. The system needs to identify and dispose of the derived passages and related records. Test those stores rather than assuming a source-file deletion propagates automatically.

Is removing content from Copilot the same as deleting it?

No. Content can stop appearing in AI retrieval while remaining retained for other purposes. Microsoft’s September 2026 update explicitly distinguishes archiving from approved permanent deletion.

Does a no-training promise mean a provider keeps no data?

No. Training use, request retention, stored files and conversation history are separate questions. Check the exact product, feature, model and contractual terms.

Must every backup copy disappear immediately?

Do not assume that outcome. Establish justified retention, isolation, expiry and restoration controls. Have the appropriate data protection owner assess whether the arrangement meets the duties applying to your information.

Can a business refuse an erasure request?

The right to erasure is not absolute. Assess the request and any applicable grounds for retaining information, such as legal obligations or legal claims. Document the decision and restrict inappropriate AI use of retained material.

How can a small business test this without a specialist laboratory?

Start with one workflow, a fictional document and a unique marker. Record the expected outcome for each store, run the ordinary disposal route and have the system owner check the results. Obtain provider evidence for systems you cannot inspect.

How often should we repeat the deletion drill?

Use a risk-based review schedule and repeat the affected checks whenever you add a connector, change storage or logging, alter models or receive a material retention-policy update.