Journal

Can it run inside our own cloud? Yes, and it usually should

The system and the data it reads are yours. The account they live in should be too. Here is what that looks like in practice, and what it costs you in effort.

Published 3 min readCardon Studio

Where the system lives decides who owns it

An AI system is a few services, a store of documents, a set of prompts and rules, and the logs of every request. If all of that sits in a vendor's account, you own a subscription. If it sits in yours, you own a system. The difference shows up the day you want to change something, audit something or leave.

So the default is that everything is deployed into your cloud account, under your access controls and your billing. The model can be a hosted one called through your own API keys, or an open one running on your own machines. Either way, the requests and the answers never pass through infrastructure we control.

What we need from you

Less than people expect. A project or account in your cloud, with a role that lets us deploy services and read logs, scoped to that project. Access to the documents and systems the assistant will read, at the level a new employee in that team would get. A person who can approve changes to production and who reads the monthly report.

If your team has an infrastructure standard, we follow it. If it does not, we set the project up the plain way and write it down, so whoever inherits it does not have to guess. Secrets stay in your secret store. Nothing is hard coded, and nothing is copied out.

What stays yours, in writing

Everything. The code, the prompts, the evaluation set, the infrastructure definitions and the runbook are in your repositories from the first week. There is no licence to renew and no component that only we can operate. The runbook is written for an engineer who has never met us: how to deploy, how to roll back, what each alert means and what to do about it.

This is not generosity. It is the only arrangement under which a business should put a system in front of its customers. A system you cannot operate without its builder is a liability, however well it works.

The day you decide to stop

Our access is removed by you, in your console, in an afternoon. Nothing breaks, because nothing depended on our accounts. If you continue with your own team, they have the runbook, the evaluation set and the monitoring. If you continue with another studio, they have the same. If you keep working with us, nothing changes.

We say this in the first call because it changes how the rest of the conversation goes. Once ownership is settled, the questions become about the work, which is where they belong.

When it should not be your cloud

Sometimes a business has no cloud account and no one to hold one. Then we create the account in your name, with your billing and your ownership, and hand over the root credentials with the runbook. It takes a day longer at the start and saves the argument later.

The one thing we do not do is host it ourselves. The system is not a product we sell access to. It is a piece of your operation, and it should live where the rest of your operation lives.