Keeping sensitive AI requests within approved infrastructure

Most organisations do not need every AI request to stay on premises. They need sensitive requests to stay within infrastructure they have approved, while other work can use whichever approved destination fits best.

What AI data residency means for a request

AI data residency concerns where information is stored and processed. For inference, identify the destination that receives the prompt and runs the model, then review conversation storage, retrieved documents, analytics and connected tools separately. Keeping stored data in one region does not establish where every request is processed.

For example, Microsoft distinguishes storage location from inference processing scope: Global deployments may process prompts across available geographies, while DataZone deployments stay within the specified zone. Check the exact deployment type and enabled features before approving an endpoint. See Microsoft’s data processing documentation.

A checklist for approving one workflow

• Name one workflow and its owner: the task, users, model requirements and data it handles.

• Record the restriction: which data may use which regions, machines and providers, and who approves exceptions.

• Check the exact destinations: endpoint, deployment type, processing scope and current model and hardware support.

• Review the surrounding application: conversation storage, retrieval, connectors, analytics, access and retention.

• Write permitted fallback paths, including what should happen when no approved destination is available.

• Test with synthetic examples, inspect the selected destination and rule, and agree what evidence to retain.

Decide where each request may run

Start by writing down the destinations your organisation is prepared to approve. Typically: the user's device, other company machines or servers, private cloud in a chosen region, and frontier APIs used through your own accounts.

Then decide which kinds of work may use which destinations. A confidential contract, a customer record or a board paper may be restricted to approved machines in the UK or EU. A request to rewrite a public product description may be allowed to use an approved frontier API. Write these as rules your organisation owns. Define approved regions with the people responsible for your organisation’s data protection requirements.

Evaluate the request on the device

Aventail^™ Link is the runtime installed on each participating machine. When an application sends a request, Link evaluates it locally, inside the runtime, before choosing a destination. That evaluation can consider the content of the request, such as whether it appears to contain sensitive data and what type of task it is, alongside the policy your organisation has distributed to that machine.

Because this content-aware evaluation happens on the device, the query does not need to be sent to Aventail^™ for analysis. The destination that is finally selected does receive the request, because it has to process it. Read the platform architecture.

Apply mandatory constraints before preferences

Order matters. Mandatory constraints are applied first and remove destinations that are not allowed for this request. Preferences then choose among the destinations that remain.

1. Constraints: data sensitivity, approved geography, approved providers and which machines a team may use.

2. Preferences: cost, latency, energy use, and the suitability of each eligible machine and model.

3. Selection: send the request to one eligible destination.

Preferences can never reintroduce a destination that a constraint has removed.

Choose between eligible machines and frontier APIs

Eligible destinations fall into two groups. The first is infrastructure running Aventail^™ Link: the current device, an approved and reachable peer machine, or a server or private cloud machine. Here a supported model runs on hardware you have approved. The second is an approved frontier API, where the model runs at the provider under your organisation's account.

Among eligible machines, Link can weigh whether a supported model suits the task, how that model performs, and the capacity and current conditions of each device. A peer only counts if it is reachable, has a suitable model available and is permitted by policy. Model and hardware support depends on the runtime version, platform and model format, so check versions and supported models rather than assuming any model runs anywhere.

An illustrative scenario

The following is a fictional example to show how the rules combine. It does not describe a real customer.

Write the policy in plain language before configuring it. An example for this workflow:

• Confidential supplier agreements: approved organisation-managed machines in the UK or EU only.

• Public job adverts: approved internal destinations or specifically approved frontier APIs.

• Fallback for confidential work: another eligible destination within the same boundary.

• No eligible destination: stop the request or handle it manually; do not expand the boundary.

These are illustrative policy requirements, not Aventail^™ configuration syntax. Your team should confirm how they map to the current runtime and application.

A legal team member asks for a summary of a confidential supplier agreement. Policy marks this kind of document as sensitive and limits it to approved machines in the UK or EU. Frontier APIs are therefore removed before any preference is considered. Link then compares the remaining options: the laptop has a suitable model but limited memory, and an approved UK server running Link has more capacity. The request runs on that server.

Later the same person asks for help rewording a public job advert. Policy treats this as non-sensitive and permits an approved frontier API, so preferences can select it if it fits best.

When no destination is eligible

Sometimes no approved destination is available for a restricted request, for example when the only permitted server is unreachable. Your policy should define what is permitted in that situation, such as which fallbacks are allowed, so the behaviour is a deliberate decision rather than an assumption. Apply the same boundaries to every fallback path, and do not plan around a request quietly moving outside policy.

Test the boundary before introducing sensitive data

• Try a synthetic confidential document and confirm the selected model, destination and routing rule.

• Make the preferred destination unavailable and check that the fallback remains approved.

• Make every approved destination unavailable and confirm the application handles the failure as intended.

• Test ambiguous or unclassified input against your chosen policy; do not assume content detection catches every sensitive item.

Inference is one part of the data picture

Choosing where a model runs governs the inference destination. It does not by itself decide where an application stores conversations, what plugins or connectors can reach, or what usage reporting is collected. Review those settings separately. Read about usage analytics and the security guide.

Aventail^™ Control is where you configure policy, models and machines. It distributes configuration ahead of time and receives management, device and routing events. It sits outside the inference request path, so prompts do not pass through it on the way to a destination.

Next steps

Begin with one workflow that handles sensitive material, list its approved destinations, and write the constraints before the preferences. See how this works for organisations on the Enterprise page, or read how Aventail^™ works.