Architecture

The difference is whether the architecture is a decision or a default. If nothing about your situation forces a choice, the default is a good one and there is nothing to agonise over. If something does — and the questions below will tell you — it is worth settling before anyone builds anything.

Your keys, your accounts — wherever it runs. The platform reaches models through provider API keys, and you supply them. That is the same on your own hardware as it is in the cloud. The keys live in your environment, your traffic never passes through us, and your provider bills you directly at their published rates — there is no markup, because there is nothing in the middle to mark up.

Handover is the deliverable, not an upsell. There is no managed-service tier here by design — you own and operate what you paid for. Documentation and runbooks are written to a standard where a competent engineer could rebuild the entire stack from them without us, which is the honest answer to the continuity question your procurement team will ask, and the reason it is part of the build rather than something sold to you afterwards.

On premise, the hardware decides what you can run. In the cloud, the GPU decides what you pay. Those are two different problems. Buy a machine that is too small and some models simply will not fit on it — a decision you live with for years. Rent in the cloud and nothing is too small, but the meter runs: a dedicated GPU can cost more per month than the licences it replaces, so "move it to the cloud" is not automatically the cheaper answer. It depends entirely on how busy the thing is.

Add retrieval and the arithmetic shifts again. Your corpus has to be embedded up front, re-embedded whenever documents change, and a vector store has to run alongside the model. That is a real line item, not a feature toggle. None of this fits honestly on a web page. It is half an hour on a call — what you need to run, how often, on whose hardware, and whether retrieval is in scope — and at the end of it you get real numbers instead of a range.

What actually determines your data boundary+

Most vendors answer this with a tidy table. We won't, because the honest answer is that your boundary is not a feature we ship — it is a consequence of four architectural choices, and it changes when any of them changes.

The choice	What it decides
Whose tenancy inference runs in	This matters more than "your cloud or ours." A managed model service inside your own cloud account, configured correctly, means the data never leaves your cloud boundary at all — which is a stronger guarantee than most on-premise setups achieve by accident.
Whether you use retrieval	The moment documents are embedded into a vector store, you have a second data path with its own ingress and egress. Plenty of assessments never need it. If yours does, that path gets designed deliberately rather than inherited.
Which model endpoints you enable	Open models can run entirely on hardware you control. Enabling a frontier endpoint introduces a third party, and that is a decision you make per model — not one made for you at signup.
Who holds the encryption keys	Customer-held keys are available in every arrangement except the shared tier. Where we hold them, we say so plainly rather than describing it as "enterprise-grade encryption."

This is a conversation, not a checkbox. Anyone who hands you a fixed residency guarantee before asking what you intend to build has told you something useful about how carefully they will handle your data. We map your four answers on the call, write the resulting boundary down, and that document becomes part of the engagement.