An open source answer to private AI for business

Ask three vendors what private AI means and you get three different products. One means your data stays in a region you chose. One means the model weights run on hardware somebody can point at. The third has started to mean that the agents doing the work, and everything they know about your company, sit somewhere you can read.

Each use is testable, and the tests do not overlap:

The definitions most teams meet first cover residency and hosting, then stop. Cloudera's explainer says private AI "allows organizations to safeguard their proprietary data and intellectual property. By keeping data and AI models within a secure environment" (Cloudera). Teradata draws the line at full control: "every data byte and every model weight resides on infrastructure the organization owns and operates" (Teradata). Both are correct about the layer they describe. Neither says where the agent's working knowledge goes, and that is the layer the third definition is about.

An assistant that answers questions needs a model. An agent that files the invoice, updates the customer record and posts to the channel needs four more things, and each one is a document:

• the instructions, meaning the prompt, the rules about what it may touch, and the skills it loads;
• the memory, the accumulated knowledge of your accounts, your naming, your exceptions;
• the credentials, one grant per system it reaches;
• the record, what it did, in what order, and who approved it.

None of those is large. Each is small enough to be a file, which is why where they are stored is a design decision. In a product that calls itself private, they are usually rows in the vendor's database, edited through a form, exported on request. The export is the moment to test: ask for the instructions and the memory in a form that runs somewhere else. An export of chat history looks complete and cannot rebuild a running agent.

That is also the point where a procurement review changes shape. The security questionnaire asks where the data is stored, and most vendors answer it. The question that never gets asked is who can change the instructions that tell the agent what to do with that data, and how that change is recorded. A vendor console with one admin login answers both badly.

Put the platform in your own VPC and the model calls, the database and the file storage move inside your network. Two of the three definitions are now satisfied at once, which is why residency and hosting get conflated in so many deployments. The perimeter is real work and it buys something real: the data does not leave, and you can name the rack.

The perimeter does not touch the third definition. If the only way to change a prompt is a form in someone else's application, you own the server and rent the knowledge. If the memory is a table in a schema nobody documented, you cannot move it to another tool and keep the agent's judgement. If the audit record is a screen rather than rows you can query, you can show a regulator that actions happened, not what the agent was told when it took them.

There is a version of this that survives the test: the vendor ships the same software you run, and the configuration is plain files in your repository. Then the perimeter is a deployment detail, and the knowledge is portable. Where that is not true, the perimeter is a boundary around a rental.

Kortix is built that way. Every agent, skill, rule, connector and piece of context is a file in one git repo, so a prompt change arrives as a diff, a revert is a git revert, and a second environment is a clone (Kortix). The repository holds the manifest, the agents' prompts, the skills and the memory file.

The platform is the same shape. kortix self-host init writes the stack's files on the server, kortix self-host start brings it up, and kortix self-host doctor checks it. Self-host and the database, the files, the repos, the secrets and the audit record all sit on disk you control, on one Docker Compose stack built from the same images the managed cloud runs. Caddy terminates TLS on ports 80 and 443, and a daily updater pulls new images, migrates and rolls the services.

The three deployment shapes, cloud, VPC and on-premises, are set side by side on the private AI platform page.

Put together, the four documents sit in one place a reviewer can open: the database, the files, the repository, the secrets and the audit record on your disk, and the compute on a provider you chose, with the API URL written down in your own configuration. The split is a decision you can defend, which is more than a claim of privacy usually survives.

Two cases, and both are worth saying plainly. If a rule requires an air gap, Kortix is not the product. The stack pulls its images over the internet, sessions run on compute you configure, and the instance has to be reachable from that compute. A regulated environment that cannot allow either is better served by a smaller system that runs no remote sessions at all.

If nobody on the team wants to run a server, the ongoing work is real: DNS records for the domain, the API and a wildcard for previews, ports 80 and 443 open, certificate renewal, a daily image update, and a signup lock. That last one matters most. Until EMAIL_URL or DISABLE_SIGNUP=true is set, anyone who reaches a fresh instance can create a confirmed account for any address, the admin address included. It is one command at the right moment, and it is a step somebody has to own.

Where those duties have an owner, the trade is good: run it on Kortix Cloud, in your VPC, or on your own on-prem network. Self-host is free. Where they do not, the managed cloud is the cheaper answer, and the files are the same either way.