Deploying a private AI workspace across laptops and servers

The short answer

Deploy a private AI workspace in stages. Start with one workflow on one approved machine running Aventail^™ Link, prove the model and the observed route, then add a shared on-premises or private-cloud machine, and only then permit approved external providers for the work that needs them. Write down, for each workflow, which destinations are allowed, who owns the decision and how to restore the previous configuration. The rest of this guide explains each step.

What “private AI workspace” actually means

A private AI workspace is more than a self-hosted model. It is the interface employees use, plus four boundaries IT and security teams need to define: where inference executes, who manages the machines and configuration, where conversations and documents are stored, and who can reach each model endpoint. Saying a system is “self-hosted” answers only part of the first question.

In Aventail^™, three products divide that work:

• Workspace is the chat and document interface employees use. It can use a model served by Aventail^™ Link or a separate browser model. See Chat in Workspace.

• Aventail^™ Link is the runtime installed on each participating supported machine. It receives management commands, runs models and applies routing policy locally when a request arrives.

• Aventail^™ Control is the browser interface for accounts, devices, models, deployments and fleet configuration. It distributes configuration, models and keys ahead of time and receives device and routing events. It sits outside the inference request path.

The architecture documentation describes these as two separate data paths: a management path between Control, hosted services and Link, and an inference path between Workspace or your application, Link and the model. Hosted Control does not receive prompt or response bodies. That is a different statement from saying nothing inspects content: Link can evaluate a request locally to apply your policy, and whichever destination executes the request, and any application involved, processes what it receives. Control can also be hosted on your own infrastructure. Registration, downloads and hosted applications still require connectivity, so do not plan on a fully air-gapped workspace unless that has been confirmed for your deployment.

Three deployment patterns

Each request executes at one selected destination. Aventail^™ does not pool machines into one accelerator or split a single request across several machines, so plan capacity per destination.

1. Local inference on employee laptops

A supported model runs on the employee’s own machine through Aventail Link. This fits personal drafting, review of material that should not leave the device, and work that must continue during travel. Validate that the model fits the machine’s memory and disk, that its quality is acceptable for the task, and that the device stays enrolled and up to date.

Local inference can run without a network connection when the model is installed, its endpoint is running, the policy permits it and the application you use is available offline. Hosted Workspace, registration, model downloads and Control all require connectivity, so “the model runs locally” and “the whole workspace works offline” are separate claims to test.

2. A shared on-premises or private-cloud machine running Link

A larger model runs on a server or private-cloud machine your organisation operates, also running Aventail Link. Laptops can route requests to it as a network peer when it offers the exact selected model and its Serve other devices control is enabled, as described in the routing documentation. This fits teams that need a model too large for laptops while keeping confidential material on internal infrastructure.

Validate the serving endpoint as its own service. The security guidance notes that the tested local endpoint used HTTP and that Control sign-in does not automatically protect a model’s serving port. Review the listener, authentication, TLS and firewall rules before other machines can reach it, and never expose the port publicly simply to make an integration connect.

3. Hybrid: internal machines plus approved frontier APIs

Some work needs a frontier model. In a hybrid deployment, routing rules can send permitted requests to an approved provider, using a connection stored in the API key vault, while confidential work stays on internal machines. The provider receives and processes requests sent to it under your organisation’s own account and terms. Validate the provider’s access, quota and data terms, and test whether its model behaves acceptably for the workflow. For deciding when to keep alternatives available, read how to reduce AI provider dependency.

Hardware and model support

Current Aventail^™ Link packages are published for macOS on Apple Silicon, Linux x64 and Windows x64. A package being available does not mean every model works on every machine. Whether a model runs depends on the runtime version, operating system and architecture, the model format and engine, available memory and disk, and network access for downloads. The documentation states that Linux and Windows installation journeys have not yet been tested on devices for its guides, so include them in your own pilot. Check the compatibility and versions page rather than relying on fixed version numbers, which change between releases.

A staged rollout

The deployment planning guide recommends proving one deployment before expanding: compatibility, a representative test, then a controlled rollout that preserves a recovery option. In practice:

1. Choose one workflow and its owner. Name the data it handles and the destinations it may use.

2. Prepare one test machine. Follow the quick start or, for a server, Add devices using the exact command your Control environment provides. Confirm the device appears online.

3. Deploy and test the model. Deploy a model from Control or Link, wait for deployment to finish and start serving. A downloaded file alone does not mean an endpoint is running. Test with harmless input in Workspace.

4. Add representative machines. Include at least one shared server if the workflow needs one, and the platforms your staff actually use.

5. Apply policy and check delivery. Create the routing policy for a dedicated device tag. Confirm each device reports the policy as applied, then send a harmless request and check the destination recorded in recent usage. A policy acknowledgement still needs an inference test.

6. Roll out in rings. Use Fleet configuration to publish a revision and apply it ring by ring, checking the applied revision, model state and a successful response before advancing. Stopping a rollout prevents further promotion; it does not reverse changes already applied.

7. Keep recovery owned. Record the previous approved configuration before each change, name who can restore it, and restore it if acceptance checks fail.

A fictional example

Imagine a fictional legal operations team. Summaries of confidential internal documents may run only on an approved internal server. Rewriting already-public text may also use an approved external provider. The team’s rules reflect that:

• A confidential summary goes to the internal server. If that model is unavailable, a configured fallback may try another approved internal destination; it never widens the boundary to the external provider.

• Network peers are primary destinations only, not fallback hops. Fallback hops are tried after an error, timeout, authentication failure, outage or unavailable destination.

• If no destination is permitted for a request, it fails with an error rather than going somewhere disallowed. That is a different case from an unavailable destination that triggers an eligible configured fallback.

The team tests both cases with synthetic text before using real documents. For a deeper data-boundary walkthrough, see AI data residency and secure routing.

Governance acceptance checklist

These are recommended checks for IT and security teams, not a statement that every control is an automatic product feature. The NIST AI Risk Management Framework groups similar activities under Govern, Map, Measure and Manage; it is voluntary guidance, not a certification.

• Ownership: a named owner for each workflow and its data.

• Destinations and access: approved destinations per workflow, including fallback hops, and who may change them.

• Models: licence terms, quality for the task, and the memory and disk each machine needs.

• Network: serving listener, authentication, TLS and firewall rules reviewed separately from Control sign-in.

• People and keys: organisation members assigned appropriate built-in roles in Team; enrolment and provider keys stored securely and revoked when no longer needed.

• Storage: where Workspace conversations and documents are stored, and for how long.

• Analytics and connectors: usage analytics, retention and any connected applications reviewed.

• Tests: observed destination, no-permitted-destination error and fallback behaviour verified with synthetic data.

• Change and recovery: changes reviewed, previous configuration recorded and a named person able to restore it.

Frequently asked questions

Can laptops and servers be used together?

Yes. Each runs Aventail^™ Link, and policy decides which eligible destination executes each request. A laptop can send a request to a server peer that offers the selected model and serves other devices. Each request runs on one destination.

Is local inference the same as a fully offline workspace?

No. A local model can run offline when it is installed, running and permitted by policy. Registration, downloads, hosted Control and hosted Workspace need connectivity.

What does hosted Aventail^™ Control receive?

Management, device and routing events. Prompt and response bodies do not pass through hosted Control. Destinations and applications process the requests they receive.

What happens when no destination is allowed?

The request fails with an error. Aventail^™ does not send it to a disallowed destination. Configured fallback applies only when an eligible destination fails or is unavailable.

Next steps

See how this fits your organisation on Aventail^™ Enterprise, and read how Aventail^™ works for the full request and management boundaries.

For rule design, fallback testing and connecting coding tools such as Claude Code and OpenCode, see how to route between local models and approved cloud APIs.