AI where nothing gets out

Some work cannot leave the building. Contracts, production data, compliance evidence and source code are often covered by rules about where they may be stored and who may see them. For that work, the question is not which AI is best. It is where the AI is allowed to run. We build for that constraint from the start.

Why the boundary comes first

Security is the architecture, not a layer added at the end. When intelligence systems work on sensitive records, the boundary, the residency and the access controls are the foundation the rest is built on. If a model needs a cloud API that the data may not reach, the model has to come to the data.

That is the reasoning behind our security and trust position: source data, outputs and inference stay inside the environment you control, and nothing is sent to our infrastructure, third-party analytics or outside model providers unless you configure it.

Many ways to deploy, one set of controls

The deployment is chosen by where the data may go, not by what the software needs. Our deployment modes run from the most connected to the most isolated:

1. Hosted. A managed environment run by us, where speed of adoption and managed operations come first.
2. Public cloud. Dedicated instances in your AWS, Azure, Google Cloud or Oracle account, aligned with your cloud standards.
3. Private cloud or VPC. Inside your enterprise network, with access, storage and controls set around your boundary.
4. On-premise. Software, storage and local inference on your own servers, planned around the environment your team runs.
5. Edge. Intelligence placed near industrial sites and equipment, where latency and connectivity shape the design.
6. Offline. Local workflows that operate without a continuous internet connection.
7. Air-gapped. A physically isolated installation with no external network connection.

Whichever mode you choose, access control, audit trails, human review and the rule that your data stays where you put it apply the same way. Only the infrastructure changes.

Models that run where the data is

A model that runs inside the boundary has to be small enough to run there. Our specialist models deploy directly to your infrastructure, and core operations need no external calls. Weights sit on your servers, inference runs in your environment, and the processing logs stay with you.

Every output also records which model version produced it. When a model is replaced, you can see which decisions it made and which it did not, which matters a great deal in a restricted network where the record may be the only evidence.

Planning for offline and air-gapped sites

An offline or air-gapped system is a design problem before it is an installation. With no external network connection, the local models, the dependencies, the way data is transferred in and out, and the way the system is maintained all become part of the deployment design. Nothing is left to be discovered after go-live.

For offline sites in particular, we define how data is transferred, how updates are applied, and what must remain available without a connection. In air-gapped and edge deployments the system is built to keep full functionality with no internet connection at all. Our sovereign operations work shows the pattern: a production loss system on a manufacturer’s own infrastructure, and a camera-trap system specified to process everything without an internet connection.

Agreeing the controls before anything is built

Security requirements are settled at the start of every deployment. We walk through the architecture, data flows, access controls and threat model with your security and infrastructure teams before anything is built. Data handling terms, controls, incident response and audit access are written into the deployment plan.

In practice that means some controls change with the mode. In an air-gapped deployment there is no transit to secure, while on-premise and VPC deployments keep all traffic inside your network perimeter. Customer-managed keys are supported in cloud and on-premise deployments, so you control the key lifecycle. Our engineers have no standing access to your environment, and any support access is granted by you, scoped, time-limited and logged.

If you already know where your data may go, that is the place to start. Describe the operational problem and the boundary, and we will show what can run inside it.