A managed service provider for private AI: the work of standing it up, keeping it running, and turning your own way of working into capability on top of it.
Everything here is one engagement seen at different distances. You buy a bounded assessment first. If it says go, we deploy into a cloud account that is yours, then keep it current and build governed capability on it for as long as that is worth paying for. The asset stays with you either way.
Most AI vendors do one of these and call it a platform. A managed service provider does all four, and the thing being managed belongs to the client, not the provider. That single difference decides who holds the account, who gets the compute bill, who can read the configuration, and what is still running the day the relationship ends.
A single-tenant environment goes into a cloud account in your name. Identity, branding, posture tier, model access, roles, the knowledge base. Deployed from a tagged release by the same factory that deploys every other one.
Releases rolled to your deployment deliberately, one at a time. Drift and diff checks before a change. Acceptance scripts fired at the real deployment after one. Cost watch, access changes, a dated journal.
The model catalogue is regenerated as providers change it. Policy versions are pinned and numbered. The controls that must not weaken have tests that fail the build if they do.
Once the foundation is trusted, the work moves to capability: the procedures, exceptions and handoffs that are specific to you, turned into governed business software.
Each rung is a decision you make with something in hand from the rung before. Nothing here is a term commitment, and nothing is invoiced at signing. The full ladder, with what sits behind each figure, is on the pricing page.
A bounded look at your environment, your current AI landscape and where governed AI would create value. You keep the written assessment whether or not you proceed, and it can say do not do this.
Typically lands around $5,000 once the solutions pipeline is scoped. Milestone invoicing, nothing at signing. Ends with acceptance checks against the live deployment and handover documentation.
Releases, drift checks, acceptance scripts, catalogue upkeep, access changes, cost watch, a dated operations journal, and a direct line to the person who built it. Cancel anytime.
Capabilities are scoped per deliverable, because a named deliverable with acceptance criteria written first is the only honest way to price work whose shape we cannot know before we see the process. Longer engagements sit in the range of one junior technical hire, without the permanent headcount. Compute is billed by your cloud provider directly to you, at their list price. We never sit between you and that bill, so there is nothing for us to mark up.
The commercial question underneath every AI contract is what happens when you stop paying. Most answers are a key that expires. Ours separates the thing you bought from the service around it, because they live in different places: the asset is deployed in your cloud account, and the service is us.
| Question | The asset: the deployed platform | The service: managed operations |
|---|---|---|
| Where it lives | ✓Your cloud account, in your name | △With us, monthly |
| Who is billed for the compute | ✓You, by your cloud provider | ✕Not part of the fee |
| Who holds the data | ✓You. Data at rest stays in your account | ✕We hold none of it |
| Who holds the source | ✓Delivered to you with the deployment | △We keep improving it while engaged |
| If you stop paying | ✓Keeps running. Yours to keep | ✕Stops |
Running it afterwards needs a competent cloud engineer, which is exactly why runbooks and infrastructure as code are deliverables of the deployment and not internal artifacts. See ownership and exit.
You lose us, not the platform.The commercial model in five words
Your cloud provider bills you directly, at their list price, for everything the deployment consumes: the inference, the storage, the network, the small amount of always-on infrastructure. We see the same figures you do, and we have no margin in them.
org.tech is founder-led: one principal and a small bench of contractors, said plainly rather than dressed as a floor of engineers. The advantage is not headcount. It is that every deployment comes out of the same factory, from a tagged release and a clean checkout, so the work that would be bespoke at a consultancy is a parameter file here.
You talk to the person who built it. There is no account manager, no queue and no first-line tier to get past, and a change you ask for is made by someone who can read the code that implements it. The limit of that model is capacity, not competence, so we take on work at the rate we can do it properly and say so when we cannot. Continuity, and what happens if we are not here, is written up on the continuity page rather than left to a sentence in a contract.
No. The assessment stands alone and is deliberately bounded. Deployment without managed operations is possible and we will say so in writing, including what you take on by running it yourself. Capability work only makes sense after a foundation exists, which is why it is last on the ladder rather than bundled into the first invoice.
There is no term. Managed operations is monthly and cancellable, deployment is milestone invoiced with nothing due at signing, and capability work is quoted against a named deliverable. The engagement path is built as a sequence of gates for the same reason: each step should be worth taking on the evidence of the one before it.
These pages describe services around orgOS, the single-tenant platform deployed into a cloud account you own. The operational knowledge gateway is a different, smaller product for organizations whose people already use an AI assistant and need it to reach firm documents under governance. If you are not sure which you want, the decision page is written to talk you out of the bigger one where the smaller one is the right answer.
That is the intent, and the authoring path exists: a manifest contract, an SDK, a validator, a scaffold and a promotion route that only a named administrator of yours can approve. Be aware of where it stands. The path has been proven end to end by us acting as the client, and the first client-authored build is a pilot. See developer modules for what is true today and what is not.
For the assessment: an hour or two with the people who can answer for security, for operations and for IT, plus permission to ask uncomfortable questions about where your data goes today. Assessment prep lists what is worth gathering first, and the posture questionnaire is published so you can read the questions before the call.
Every other question about private AI gets easier once those two are separate. What we sell is the work: provisioning, operating, maintaining and extending an environment whose account, data, configuration and source are already yours.
Start with the bounded assessment: a written map of your environment, a recommended posture, and a recommendation we will stand behind even when it is no.