Your AI Residency Approval Must Cover Feature Changes

A new model, web search or connector can change an AI data boundary without changing the product name. Your approval needs to follow the configuration.

Approve a configuration, not a product name

Your business approves an AI assistant after checking its storage region and supplier contract. A month later, someone enables web search, adds an external agent or selects another model. The product still has the same logo. The original approval may no longer describe the system staff are using. This is configuration drift: small changes in settings gradually move a service away from the conditions under which it was accepted.

This matters because residency commitments are not necessarily product-wide. They can depend on the subscription, workspace, model, deployment route and individual feature. A useful approval therefore says which configuration was assessed, which information it can handle and which changes require another look. A screenshot of a country selector is evidence of one setting, not evidence of every subsequent processing step.

Three recent UK reviews illustrate why the detail matters. C4C's 5 October 2026 residency review distinguishes storage from processing and highlights feature exclusions. SpotDev's vendor-tier review, updated in October separates vendor tiers rather than treating a brand as one service. Augustova's 20 October explanation makes the same distinction between where information rests and where the model reads it. These are useful secondary explanations, but the binding scope must come from the applicable supplier terms and your actual configuration.

The practical change is modest. When you approve a tool, record its edition, workspace identifier, allowed models, permitted connectors and web-search position. Add the date and the person responsible for the decision. Write down what would invalidate that approval. This lets a small business keep using useful AI without pretending that every new feature inherits an old assurance. It also gives an administrator something concrete to check when the supplier introduces another capability.

The feature you enable tomorrow may fall outside the promise you approved today.

Web search is a separate data-handling decision

Microsoft provides a concrete named example. Microsoft's enterprise data protection documentation says prompts and responses receive contractual protections under its Data Protection Addendum and Product Terms. It separately explains that Bing web queries have their own data-handling practices. Microsoft acts as an independent controller for that service. The page also states that the EU Data Boundary does not apply to web search queries. That is a scope distinction, not a claim that using search is inherently unlawful.

The same documentation explains that search queries are generated from prompts into a few words, with user and tenant identifiers removed. Those protections matter. They do not mean the query contains no sensitive business meaning. A narrowly described customer incident, an unreleased product name or an unusual employment dispute can still reveal information you did not intend to send into an external search process. Decide what is acceptable for your work, rather than assuming a search request is identical to the original internal conversation.

What this means in practice is that public research and confidential document analysis may need different settings. A marketing colleague checking published industry developments has a different requirement from a manager summarising a grievance file. Permit the first workflow where the terms and data classification support it. Keep web search disabled for the second if your approval requires that boundary, and provide a separate route for researching public information.

Test this with invented material, not a real employee record. Ask the assistant a question that could trigger search, observe the available audit evidence and compare it with the documented policy. A response that happens not to search is not proof that search is disabled. The acceptance evidence should include the administrative setting or enforced policy and its scope, alongside the test result. Staff guidance should explain the difference in ordinary language.

A protected chat does not automatically make its web queries part of the same contractual boundary.

Model selection can change the residency answer

The same Microsoft documentation contains a second specific example: it says Claude models from Anthropic are currently excluded from the EU Data Boundary and, where applicable, in-country processing commitments. These are two distinct scope exclusions in one supplier document, not a general judgement about Claude or Microsoft. They show why an approved application name cannot stand in for an approved processing route. Check the current terms again before relying on this position, because supplier commitments can change.

A business may approve one model route for ordinary working documents and reject another for a client with a strict location clause. That is a perfectly reasonable outcome. The mistake is letting a user select any available model while the internal register still says the entire service meets the stricter requirement. The approval needs an allowed-model list, or a policy that keeps restricted work away from model choices that have not been assessed.

Do not infer an answer from a model family name alone. A direct vendor application and a deployment of that model through a cloud platform can have different contracts and regional options. Equally, selecting a London resource does not by itself demonstrate that every supported model and routing mode processes exclusively in London. Ask for the deployment type, any cross-region routing and the precise geographic commitment for the chosen model.

For an administrator, the useful test is whether an ordinary user can cross the approved boundary without an approval step. Use a standard test account and check the model picker, agent catalogue and relevant settings. If a prohibited option remains reachable, either enforce a restriction or narrow the permitted data until you can. Keep the evidence of what was actually available on the test date. Do not turn a supplier roadmap into a present-tense assurance to a client.

Model availability is not proof that the model inherits every regional commitment.

Connectors and support access belong in the same review

An AI assistant often becomes more useful when connected to documents, a CRM or an external agent. Each connection can introduce another organisation, another set of terms or another place where information becomes accessible. The assessment must follow that path. Approval of the original chat service does not automatically approve a connector developer, a third-party agent operator or a support arrangement that can inspect the resulting records.

The ICO guidance on restricted transfers makes an important point: a transfer is not only about sending information abroad. Making personal information accessible to a separate organisation outside the UK can also count. Its worked example describes an Indian IT support company accessing information that remains on UK servers. The ICO sets out a three-step test involving whether UK GDPR applies, whether the transfer is initiated to an organisation outside the UK and whether that organisation is a separate legal entity.

That does not mean every overseas employee or remote login has the same legal treatment. Follow the actual legal entities, contractual relationships and responsibilities. The ICO also distinguishes initiating a transfer from merely authorising it. Where a UK processor designs a service involving an overseas sub-processor, responsibilities can differ from a controller contracting directly with that overseas organisation. Ask your privacy adviser to apply the guidance to your arrangement rather than treating a server postcode as a legal conclusion.

What this means in practice is a short connection register. Record the connector or agent, operator, information it can retrieve, destination service, access scope and approving owner. Include support access where relevant. For each addition, compare the proposed flow with the approved baseline before granting it access. If the supplier cannot explain the route clearly, use synthetic information during evaluation and leave sensitive material out until the missing evidence is resolved.

Your data can cross a boundary through access, not just through a file upload.

Do not confuse a sensible boundary with a UK-only rule

The strongest counterargument is practical: a small business cannot reopen a legal assessment whenever a button moves. Nor should it. UK GDPR does not impose a blanket requirement that every AI workload must remain in the UK. International processing can be lawful where the relevant requirements and transfer mechanism are satisfied. Client contracts, sector obligations and your own risk decisions may impose a narrower boundary, but those are reasons to identify explicitly, not assumptions to apply to every task.

Create a proportionate change rule. Cosmetic interface updates should not need a residency review. A change of processing region, model provider, web-search status or connected service may need one because it can change the assessed flow. Establish those triggers in advance. The person approving a new feature should know whether it stays within the existing decision or needs input from the owner of the data and, where appropriate, a privacy specialist.

An illustrative small-business arrangement could separate public information, routine internal material and restricted client files. Public research can use a broad approved feature set. Internal material can use a documented enterprise configuration. Restricted files can require a specific assessed route or remain outside AI altogether. These are example operating choices, not statutory categories or a claim that the same controls suit every firm. Apply your existing information classification rather than creating an elaborate parallel system.

This approach avoids two expensive extremes. One is buying a costly private deployment for harmless public work without a clear reason. The other is allowing every feature for every document because the supplier has a familiar enterprise label. Make the boundary fit the information and the commitment you actually made. Then explain it to staff with recognisable examples: a public competitor page is not the same as a named customer complaint, even when both can be pasted into one chat box.

A tighter location requirement can be a commercial choice without being a universal legal requirement.

Make feature changes visible before the assurance becomes stale

Start with the assistant that handles the most consequential information, not a company-wide spreadsheet exercise. Save the current contractual references and relevant configuration evidence in an appropriate internal location. Record what you know about storage, inference, search, agents, connectors and support. Mark uncertainties honestly. A supplier document describing a capability is not evidence that your tenant has that capability enabled, and a configured setting is not a substitute for understanding its contractual scope.

Assign a named operational owner and a review trigger. Before that person enables a new model or connector, they compare it with the baseline and record the decision. Review supplier change notices that affect processing locations or sub-processors. Periodically check that administrative restrictions still apply to ordinary users. The frequency should reflect the sensitivity of the work and how often the service changes, rather than a made-up universal monthly or quarterly requirement.

Use a small acceptance exercise after a material change. With synthetic documents, try the workflow as an ordinary user, verify that restricted options are unavailable and inspect the relevant audit records. Confirm the configuration and current supplier scope together. If a material uncertainty remains, pause the affected feature or keep restricted information out while the owner resolves it. There is no need to switch off unrelated approved work simply because one extension is still being assessed.

Finally, keep this separate from deletion and retention checks. Our guide to testing AI deletion deals with what happens to copies after you remove information. This review asks whether a feature change sends or exposes information somewhere new in the first place. Both matter, but neither proves the other. A good residency approval is a maintained statement about a working configuration, not a badge that remains valid regardless of what happens next.

Keep the original approval and a short record of what changed, who checked it and why it still fits.