Sovereign AI buyer questions, answered.

All of them stay inside your tenant boundary. We deploy the inference runtime into your cloud account or on-prem environment, so prompts, completions, embeddings, and any fine-tuning data never leave the region or VPC you nominate. The boundary is set up at install time and audited the same way you would audit any other piece of infrastructure in that environment.

No. We do not run a managed multi-tenant inference service. The model weights, the inference servers, and the surrounding agents all run inside your boundary, so tenant traffic is never mixed and we do not have the option to retain a prompt after the fact. That is what makes the deployment "sovereign" in the sense a regulator recognises — the only place a prompt exists is your environment.

By default, nothing crosses outbound. If you opt in to telemetry (we recommend it for production support), the only thing that leaves the boundary is a signed heartbeat with the runtime version and a prompt-hash counter — no prompt text, no completion text, no customer record fields. The exact telemetry contract is in the install paperwork so security review can sign off before anything ships.

The runtime is model-agnostic. Most regulated installs run on an open-weights foundation model (Llama, Mistral, Qwen) inside the tenant boundary so weights are auditable like any other binary. We can also wrap a commercial API you already have a contract with, but the value of a sovereign install is that you do not have to. Either way, the model version is pinned and recorded on every receipt.

Every inference writes a signed record with prompt hash, model version, retrieved context, tool calls, and outcome. The agent trace is reproducible — given the same inputs and the same model version, you get the same outputs. For audit, we expose a step-by-step view of every prompt the agent issued, why it issued it, and what it did with the response. The conversation with compliance stops being "why did it do that" and becomes "here is the receipt".

A signed JSON line per inference with prompt hash, model identifier, retrieved-doc identifiers, tool calls, and the operator identity that triggered the run. Logs are written to your log sink (CloudWatch, Stackdriver, Splunk, on-prem) using your retention rules. We hand you the schema at install time so your SIEM can ingest the trail natively.

Typical engagement is 8 to 12 weeks. The first two weeks are residency and access — VPC, IAM, model weights, log sinks. The middle four are agent build against one high-friction workflow, with audit wired up alongside. The final two to four are pilot, sign-off, and handover. We start with one workflow on purpose; graduating the same boundary to the next one is fast once the receipts hold.

Either, depending on the engagement. A Single Deployment (one-time install) hands the runtime to your platform team — they own the change window, the on-call rota, and the model upgrades. A Managed Subscription keeps the runtime under our support contract: we host, update, and monitor inside your boundary, you keep the audit trail and the keys. Both runtimes are the same code; the only difference is who pages when something beeps.

Behind your change window, with the audit trail intact. Every model upgrade is a new pinned version that is recorded on every subsequent receipt, so if a regulator asks "which model answered this prompt on March 4", the answer is in the log. Workflow changes go through the same review as any other production change — we do not hot-patch the agent at runtime.

When the agent needs to act inside a web application (a portal, an admin console, an internal tool), it does so from an isolated browser session that lives inside your boundary. The session is short-lived, scoped to the workflow it is running, and the actions it takes are recorded the same way prompt-and-completion receipts are. The agent never authenticates as a human user from your normal fleet — it uses a service identity with the minimum permissions the workflow requires.

The runtime is designed to satisfy the data-residency, explainability, and least-privilege requirements we see most often in regulated buyers: DORA and ECB outsourcing guidance for EU banks, MAS and APRA expectations for insurers, HIPAA-adjacent controls for healthcare vendors, and the procurement rules for government-adjacent work. We do not claim a single "compliance certification" — the artefacts (audit trail, residency boundary, scoped identities) are what your auditor will ask for, and they are first-class outputs of the install.

It is not a hosted SaaS you connect to, not a fine-tuning service that ships your data to a third party, and not a wrapper around a commercial LLM API. If any of those is what you actually need, there are cheaper options and we will say so — but if the deployment has to defend itself against a residency, audit, or explainability review, the install shape is what makes that conversation tractable. See the agent run on production-shaped data →, or review install pricing for the engagement shape.