The engagement where a governed AI environment stops being a diagram and becomes an address your people can sign in to.
From $2,500, typically landing around $5,000 once the solutions pipeline is scoped. Milestone invoicing, nothing at signing. Deployment means a single-tenant environment in an account in your name, branded as yours, with the posture your assessment recommended, the models your work needs, your first users and roles, your knowledge base, and the documentation to run it without us.
A deployment is one organization in one cloud account. That is not a marketing frame, it is the isolation model: there is no shared tenant to be separated from. The diagram separates three things people tend to blur: what you bring, what the deployment installs, and what is reached rather than installed.
You create the cloud account, or nominate an existing one, and hold its root credentials. We agree the posture tier from your assessment, write it down as the configuration the infrastructure reads, and record every override with its reason. The same typed object drives the deployment and the plan page your people see inside the product, and a test fails the build if they disagree.
Hosted sign-in with the factors you chose, passkeys and second factors self-service, tokens in httpOnly cookies, the user directory inside your account. DNS, certificates and the origins each future module will serve from. Your name, your colours, your wordmark: white-labelled at build time, so nobody signing in sees ours.
Per-account model access is requested and granted, the allowlist is set as a deploy-time parameter, and the catalogue is generated from the provider's live list rather than typed by hand. Residency applies here: where a model has no route inside your pinned region, the request is refused with a reason instead of quietly sent elsewhere.
Roles are identity groups with grants an administrator can edit at runtime; nothing in the running system can create a role. Then the first documents. One limit matters more than the rest: everything loaded into a knowledge base is readable by every user of that deployment, so the first load is chosen accordingly. See chat and knowledge.
Scripts fired at the real deployment over HTTPS, not a test harness: a replayed ticket refused, a forged session refused, one application's session presented at another's origin refused, a corrupted upload quarantined. Then the documentation: runbooks, the infrastructure as code, the architecture record and the posture with its exceptions.
Some of this cannot be delegated, and pretending otherwise is how deployments stall. Root credentials, billing and the decision about who may see what are yours by design, not by oversight.
| Task | Your side | org.tech |
|---|---|---|
| Create the cloud account and hold root credentials | ✓You, always | ✕Never ours |
| The billing relationship with the cloud provider | ✓Direct to you | ✕We are not in it |
| Request per-account model access in the provider console | △Your console, our checklist | △We walk you through it |
| DNS zone, delegation and certificates | △You own the domain | ✓We specify and wire it |
| Identity configuration and factor policy | △You choose the policy | ✓We configure it |
| Infrastructure, deployment and version stamping | ✕Nothing to do | ✓From a tagged release |
| Naming the first users, roles and grants | ✓Your decision | △We create them with you |
| Choosing what goes into the knowledge base | ✓Your content owner | △We load and verify |
| Acceptance checks against the live deployment | △You watch them run | ✓We run them |
| Accepting the deployment | ✓Yours to sign | ✕Not ours to declare |
Where a row is marked part on both sides it is genuinely shared work: we bring the checklist and the sequence, you bring the authority. The full division of duty, including who can pause a deployment, is on shared responsibility.
The cloud account is in your name and you hold the root credentials. Client isolation is the account itself. At the entry posture no cross-account role for us exists at all; on the hardened tiers our access is scoped and session-capped.
Your provider bills you directly at list price for compute, storage and inference. We do not resell it and hold no margin in it, so your finance owner can read the bill without asking us what a line means.
Documents, conversations, the index and the audit records sit in your account. We hold no client data on our infrastructure. Model invocation logging records model, caller, latency and token counts, and carries no prompt or answer text.
Yours to keep. If the service ends you keep running it, hand it to another provider, or take it apart. Nothing expires and nothing phones home to be let in.
Delivered with the engagement rather than produced on exit, because an exit package written under notice is worth very little. The other half of that honesty: running it afterwards needs a competent cloud engineer.
The resolved posture with its standing exceptions, on the plan page inside the product, generated from the same object that built the infrastructure. Plus the architecture record and a controls matrix mapping 17 technical control rows to recognised criteria.
The infrastructure deploys from one command. Around it sits a checklist of steps that need a person: console work in your account, a use-case form for some model vendors, certificates, DNS delegation, identity configuration, creating the first roles, and every post-deploy check. Most of the calendar goes on those, not on us.
The entry posture suits a first evaluation and low-sensitivity use. It has no private network path and no account-level audit trail, and a security review will usually want Standard. Deciding that before the deploy is cheaper than discovering it after, which is why the posture questionnaire happens in the assessment and not at handover.
Usually yes, though a dedicated account under your existing organization is often cleaner, because the isolation model here is the account boundary itself. Where an account already carries unrelated workloads we will say what that costs you in blast radius and evidence quality, and let you decide.
There is a floor: from $2,500. What moves it is the solutions pipeline, the posture, and how much of the surrounding work is yours to do. Typically it lands around $5,000, invoiced by milestone with nothing due at signing. The whole ladder is on pricing.
Hosted sign-in with passkeys, TOTP and second factors is standard, and the user directory lives in your account. Federation with an existing enterprise identity provider is scoped per engagement rather than sold as a shipped feature. There is no SAML support.
Posture is a deploy-time parameter, so a change is a release rather than a switch. That is deliberate: an administrator cannot alter the allowlist, the content policy, the tier or residency from inside the running system. Changing it is normal work under managed operations.
No. You can take the deployment and run it. We will tell you in writing what that means: releases, drift checks, catalogue upkeep, cost watch and acceptance scripts become yours. It is the right call where you already have a cloud team to carry them.
The authoring path exists and is careful: a manifest contract, a validator, a scaffold, staging publication, and promotion only by a named administrator of yours approving an exact artifact hash. Our automation cannot promote. The honest status is that the first client-authored build is a pilot; see developer modules.
Deployment is quoted off a real scope, which is what the bounded assessment exists to produce before anybody signs anything.