Where data sits
In the hosting environment we operate. Isolation is enforced separately across storage, encryption, integrations, event delivery and authorization; your installation has its own RSA-2048 key pair.
01
Comparison matrix
The same platform, four placements. The difference is not in the feature list but in where the data sits and which connections leave the building.
| Topic | SaaS | Private cloud | On-premise | Air-gap |
|---|---|---|---|---|
| Where data sits | In the hosting environment we operate, isolated per tenant. | In your cloud subscription; region is your choice. | In your own data centre or server room. | Inside the organisational boundary, on a machine with no external network. |
| Infrastructure responsibility | Hosting, operations and updates ours; configuration and authorization yours. | Subscription, network and identity yours; platform operations shared. | Hardware, network, backup and operations yours; platform support ours. | Entirely yours; support runs through internal channels or on site. |
| Updates | Applied on release. | In a planned maintenance window, with your approval. | Via an installation package, in your maintenance window. | Via a manually transferred package; no updates over the internet. |
| Local AI (361 Local) | Available depending on the hardware profile. | Yes — full performance on a GPU-backed instance. | Yes, the default choice. | Yes — it is the only AI path. |
| Cloud AI models | Yes, with the providers you enable. | Yes, as far as your egress policy allows. | Only if the organisation permits outbound traffic. | No. Cloud provider models are not listed and are refused. |
| External channels | All available. | All available. | Those permitted outbound connectivity. | Internal channels only. Anything requiring an external API does not work. |
| Internet requirement | Yes. | Yes. | Not mandatory; depends on channel and provider choices. | None — that is the premise. |
| Typical reason to choose | Fast start, no operational burden. | Corporate cloud standard and region requirements. | Data ownership, proximity to existing systems, regulatory expectation. | Environments where network separation is mandatory. |
02
SaaS — we host it
Responsibility split
Hosting, backup, monitoring and version upgrades are ours. User and role definitions, authorization policy, which AI providers are enabled and which data the AI may see are yours.
Updates
Applied when a release ships. Because schema changes do not require a restart, upgrades are not planned around downtime.
What does not work, or is limited
- An air-gap guarantee cannot be given — with hosting on our side, the sentence "data never crosses your boundary" cannot be constructed in this model.
- There is no direct access to systems on your internal network; connecting to your existing business system requires a secure gateway (VPN or a published endpoint).
- Running local models depends on the hosting hardware profile; dedicated GPU needs are assessed separately.
- Hardware choice and OS-level customisation are not under your control.
Typical requirements
No servers on your side. What is needed: a user list and role map, access details for the systems to be connected, and — if an internal system is in scope — a network gateway.
03
Private cloud — your subscription
Where data sits
In your cloud subscription, in the region you select. The residency discussion closes with the region choice; billing and resource ownership stay with you.
Responsibility split
Subscription, network topology, identity provider, backup policy and cost management are yours. Platform installation, configuration and version support are ours.
Updates
Applied in a planned maintenance window with your approval, tied to your change management process.
What does not work, or is limited
- Your cloud provider's regional and service constraints pass straight through — GPU-backed instances are not available everywhere, and local model performance follows the instance you pick.
- If your egress policy is closed, cloud AI providers and external channels will not work. That is a consequence of your network policy, not a platform limitation.
- Backup and disaster recovery fall under your cloud configuration; our SaaS backup plan does not apply in this model.
Typical requirements
A Windows Server 2019 or later instance, .NET Framework 4.8, a managed or self-hosted database, identity integration. For local models: at least 16 GB RAM and 8 CPU cores; 32 GB+ RAM and a CUDA-capable NVIDIA GPU recommended for quality models.
04
On-premise
Where data sits
In your own data centre. Business data, AI configuration, knowledge bases and the vector store all stay inside the same boundary; with localOnly on, no prompt or embedding leaves it.
Responsibility split
Hardware, operating system, network, backup and monitoring are yours. Platform installation, release packages, configuration and support are ours. Once installed, running the platform does not depend on us.
Updates
Via an installation package, in your maintenance window. Since schema changes do not stop the runtime, upgrades do not require a full day of downtime.
What does not work, or is limited
- Cloud AI models work only if the organisation permits outbound traffic. With egress closed, 361 Local and the other local runtimes are in play and cloud models cannot be selected.
- External channels (messaging, SMS, social, external email, video meetings) require outbound connectivity; if your network policy forbids it, those channels are unavailable.
- Capacity planning is on you: model size is checked against the machine's RAM/VRAM and models that do not fit are flagged — but enlarging the hardware is not in our hands.
- Backup and recovery drills run through your processes.
Typical requirements
Windows Server 2019+ or Windows 10/11, .NET Framework 4.8. Minimum 16 GB RAM and 8 CPU cores; 32 GB+ RAM and a CUDA-capable NVIDIA GPU recommended. At install time the platform scans the machine: RAM, AVX2/AVX512 instruction sets, CUDA/VRAM and Vulkan support are detected, and acceleration falls back CUDA → Vulkan → CPU on its own.
05
Air-gap — disconnected
The most constrained and the clearest model. There is no point softening the limits here: nothing that needs an external API works. In exchange, "data cannot leave the machine" is not a promise in this model — it is a physical property of the network.
What works
- 361 Local — the embedded llama.cpp runtime; no separate installation, no external key.
- Local embedding generation and semantic search over the knowledge base.
- Local OCR and local text-to-speech.
- All business modules, role-based access control, row-level security and the audit trail.
- GuardrailPipeline and its four detectors.
- Internal channels: web chat, email through an internal SMTP server, internal MQTT.
- Automations: manual, scheduled and entity-event triggers.
What does not work
- Cloud AI providers. Including the wide model catalogue reachable through a router, no cloud model can be used; with
localOnlyon they are not even listed. - External channels: messaging apps, SMS providers, social networks, external email services, video meeting platforms, external help-desk federation.
- Outbound webhooks and REST calls to external systems.
- Flows that need external SMTP — passwordless email sign-in included; with an internal mail server it works.
- Downloading models from the internet. Models are transferred by hand, which is why local model files are explicitly part of the backup scope.
- Online updates. Releases are applied from a manually transferred package.
Responsibility split
Entirely yours. Installation, update packages and support run through internal channels or on site; unless remote access is explicitly provisioned, no support session touches the network.
Typical requirements
The on-premise requirements apply, with two additions: extra disk for model files, and a defined transfer procedure for update packages (approved removable media or a one-way transfer). Since local models are the only AI path here, hardware choice is not optional.
There is a hybrid middle road
You do not have to choose between full air-gap and full cloud. Sensitive workloads can stay on the local model while heavy reasoning goes to the cloud — as far as your organisation allows — and both pass through the same governance gate. The decision table for which work runs where is in the local AI field guide.
06
What never changes
The deployment model changes where data sits; it does not change governance. The following are identical across all four.
The same governance gate
GuardrailPipeline and four detectors (PII, hallucination, prompt injection, cost) are in play on every request.
The same authorization model
Role-based access control and row-level security apply to AI as they do to people.
The same audit trail
Immutable records across ten event types, from agent execution to data deletion.
The same human approval
Propose → approve → undo for risky tool calls and autonomous actions.
The same data rights
Export and deletion requests run through the same interface; retention periods are configurable.
The same platform surface
Modules, designers, channels and AI surfaces are identical; only the outbound connections differ.
07
Technical requirements
These are the platform's own requirements, not estimates. They apply directly to on-premise and air-gapped deployments, and determine the instance profile in a private cloud.
| Item | Requirement |
|---|---|
| Operating system | Windows Server 2019 or later; or Windows 10/11 |
| Runtime | .NET Framework 4.8 |
| Minimum | 16 GB RAM · 8 CPU cores — enough for small models, trials and pilot workloads |
| Recommended | 32 GB+ RAM · CUDA-capable NVIDIA GPU — for quality models and heavy document/OCR pipelines |
| Acceleration | Falls back automatically CUDA → Vulkan → CPU; a missing GPU driver does not stall installation |
| Air-gap additions | Extra disk for model files + a defined transfer procedure for update packages |
The server side runs on Windows
This is an architectural fact rather than a preference, and a direct constraint for organisations whose operating policy allows only Linux or containers. We recommend settling this point before discussing deployment models — see Is 361 for you?
08
Which one fits you
If you want to start quickly
With no internal residency requirement and no appetite for running servers, start with SaaS. Moving later is possible; your data is held in an exportable form.
If you have a corporate cloud standard
When subscription, region requirement and identity provider are already defined, private cloud is the path of least friction.
If data must stay inside
Where a regulatory expectation, a contractual duty or proximity to existing systems applies, choose on-premise. Local models are the default there.
If network separation is mandatory
If data must never leave under any circumstance, air-gap. Read the "what does not work" list above with the relevant teams before installation — that list is what prevents surprises.