Control and data are always separate — you just choose where your data runs.
orqo is split-plane from the ground up. The control plane — configuration and orchestration — is orqo's SaaS, and it holds none of your content at rest. The execution plane — where your data is actually processed — is a distinct tier you place: in the orqo cloud by default, in your own cloud, or on hardware orqo delivers to your premises.
Plain-language promises the rest of this page backs up in detail.
Your data never trains a model. Frontier-model calls run through Zero Data Retention endpoints — nothing is retained by any provider, nothing trains a model. With local models, no external provider is involved at all. No configuration lets your data train anything, in any form.
You choose where it's processed. The execution plane runs in the orqo cloud by default, in your own cloud account, or on hardware orqo delivers to your premises — your call, set by contract.
Each tenant is isolated. Access to your data is least-privilege, scoped to your organization, and logged — reachable only by the people and processes working on your behalf.
You can take it all back. Request a full export or permanent deletion at any time, and orqo honors it across its systems and subprocessors.
This isn't a mode you switch on — it's how orqo is built. Configuration and execution are two distinct planes, for every organization, by design.
Same system, same split-plane architecture. What changes from one to the next is one thing: where your data is processed.
The orqo cloud — the default. The execution plane runs in the orqo cloud. Your data is processed under encryption and per-tenant isolation, and any frontier-model call goes through a Zero Data Retention endpoint. Nothing to provision — sign in and run.
Your cloud — orqo-operated. The execution plane runs inside your own cloud account, so your data stays in your cloud. orqo operates it for you (with root access), you configure it through a web interface, and a managed GPU in your account — from a host like CoreWeave — is added when you want local models. A separate, negotiated engagement.
On-prem — delivered metal. orqo ships pre-installed hardware: a turnkey box with a small web interface for configuration and a GPU that runs local LLMs for the agents. No data, and no model call, ever leaves your building.
Whenever a frontier model is used — in the orqo cloud or in your own cloud — the call reaches a Zero Data Retention endpoint: it keeps no copy and never trains. But ZDR means a provider retains nothing; it doesn't mean your data was never transmitted to them. When your requirement is that data must not leave your boundary, a local model is the answer — and "boundary" has two senses. A GPU in your own account — your cloud, or a dedicated host like CoreWeave — keeps your data legally in-boundary: your account, your contract, no commercial AI touching it. orqo-delivered metal keeps it physically in-boundary too — it never leaves the building.
It was built into the architecture from day one — and it travels with the execution plane, wherever it runs.
TLS 1.3 on every service endpoint and AES-256 at rest. Between components, a WireGuard mesh (Headscale-managed) means no plaintext path exists anywhere in the system.
Each tenant's data is logically isolated. Access is scoped to the operational people and processes working on your behalf, logged, and revocable — with an incident-response process and breach notification consistent with applicable law.
The access, encryption, audit-logging, and data-handling controls SOC 2 calls for are already implemented; the system is being prepared for a formal examination, with the report to be published once complete.
orqo executes the custom tools your agents rely on, and runs real code when a job needs it — without ever exposing the system itself.
A tool built in the Tool Factory can call an API, read a feed, or transform data — but it runs isolated from orqo itself. Doing the work never means reaching into the system that runs it.
For real code execution, orqo connects to a runtime you choose — a managed cloud sandbox, any server you can SSH into, or your own laptop through the ORQO Bridge desktop app (an outbound connection, no open ports). Your code executes on infrastructure you control, never on the orqo system itself.
Some agreements prohibit processing confidential information through a third-party AI system unless specific guarantees — around training, encryption, deletion, and ownership — are in place. Running local models — in your own account (your cloud, or a dedicated GPU host like CoreWeave), or on hardware orqo delivers to you — satisfies each directly.
With local models, no commercial AI service is in the chain at any step — not for inference, not for routing, not for any processing. The model runs on a GPU in your own account — your cloud, or a dedicated host like CoreWeave — or on the box orqo delivers; deletion authority is yours; and orqo acquires no ownership interest in your data at any step.