Keeping sensitive AI requests within approved infrastructure
Decide where each AI request may run, evaluate it on the device, and keep every permitted fallback within the same boundaries.
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.
Constraints: data sensitivity, approved geography, approved providers and which machines a team may use.
Preferences: cost, latency, energy use, and the suitability of each eligible machine and model.
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: Aventail™ Link returns an error. Handle the work 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
If your policy permits no destination for a request, Aventail™ Link returns an error. It does not broaden the permitted destinations to find an answer, so the request is not sent anywhere your policy excludes. Treat that error as a deliberate outcome in your application: show it to the user, record it without the request content, and send the work to a person or an approved exception process.
This is different from a permitted destination failing. A rule can list up to three approved fallback hops, tried in order after an error, timeout, authentication failure, provider outage or unavailable destination; if every hop fails, the documentation describes retrying the chain with backoff. Fallbacks only use destinations added to that rule, so apply the same boundary to every hop. Network peers can be eligible primary destinations when approved, reachable, offering the model and set to serve other devices, but they are not fallback hops. See destinations and fallback order.
A stopped local model is also not the same as a policy with no permitted destination. When a model is unavailable, the outcome depends on the route and any fallback you configured.
A worked validation in Aventail™ Control
The steps below follow the routing guide in the Aventail™ documentation and use its labels. They describe checks for you to run on your own fleet; they are not a record of tests we have performed. Use synthetic text throughout, never real confidential data.
Before you start
Fleet Admin or Super Admin access in Aventail™ Control, then Fleet operations → Routing.
One isolated test device, enrolled and online, running Aventail™ Link with a local model that already answers requests.
Step 1: isolate one test device
Give only the test device a unique tag, and check that no other device shares it.
Choose New policy, name it and select that tag under Auto-assign tags. Keep Inherit Org default rules off so organisation rules do not add destinations to the test.
On the device, keep Pin to a policy on Auto (follow tag selectors) and Manual route on Follow policy (no manual route).
Select the policy and review its device count before continuing.
Step 2: restricted test that stays local
Leave Default route as On device. The documentation’s example then adds a New rule with the condition CPU (%) > 0, held for 0 minutes, routed to On device, with the exit setting Leaves the group. That condition only matches an active test device. It is a test condition, not content or personal-data classification, and it is not an unconditional rule, so do not treat it as a security control.
For a sensitive-data boundary test, keep this policy local-only: no external default route, no inherited rules and no fallback hop. Never add an external fallback to the restricted test for convenience.
Wait until Delivery shows applied, and check Route and Signal. Delivery confirms the device received the policy; it does not prove where a request ran. Send a synthetic request, then confirm the actual destination in Recent usage and in the response.
To send the request, follow the runnable example in Run your first interface. It lists models with GET /v1/models and sends POST /v1/chat/completions to http://localhost:8100. Use a model ID returned by /v1/models rather than one copied from an example.
Step 3: separate permitted-cloud test
Run this as a separate test with harmless public text and a provider connection your organisation has approved in API key vault. A successful key test checks the provider key; it does not verify routing. The documentation’s local-first example adds the approved provider as a fallback hop, then briefly stops local serving to check that the fallback is used. Restore local serving afterwards. Cloud requests leave the device and may incur provider charges.
Step 4: check content-aware decisions separately
Aventail™ Link evaluates request content on the device, within your policy. The routing guide reviewed for this article does not document the specific sensitivity or geography settings, so confirm what your deployment offers with your administrator or with us. The CPU condition in step 2 does not test classification.
Prepare a small set of synthetic prompts: clearly sensitive, clearly public, and harder cases such as invented identifiers in unusual formats, sensitive details inside routine requests, and public text that looks sensitive. Record the destination each reaches. Content detection is a signal, not a guarantee that every case is caught, so keep hard boundaries in policy for work that must never leave approved infrastructure.
Expected checks for your team
Restricted test: the synthetic request runs on the test device, and Recent usage shows no external destination.
Permitted-cloud test: with local serving briefly stopped, the harmless public request reaches the approved provider and no other destination.
No permitted destination: when policy permits no destination for a request, Aventail™ Link returns an error and the request is sent nowhere. Ask your administrator how this case applies to your policies; a stopped local model does not reproduce it.
Restore: restart local serving, remove test fallback hops and tags, and return the device to its normal policy.
Evidence to keep
Aventail™ Link runtime version and model version.
The policy and rule chosen, and the Delivery state.
The synthetic input used.
The actual destination shown in Recent usage.
The observed response or error.
Leave out API keys, enrollment keys and real data.
Further reading: routing, platform architecture, versions and supported models and troubleshooting.
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.
Planning the wider rollout across laptops, shared servers and approved providers? Read how to deploy a private AI workspace across laptops and servers.