# An open source private AI platform is a control plane you own

> A private AI platform is bought for its control plane: where the rules, the credentials and the record live. Model lists change quickly, and connector counts with them. Kortix is the open-source AI Operating System: your agents, their skills, your company memory, and every connector in one git repo you own.

URL: https://privateaiforcompanies.com/private-ai-platform

## The five parts, and the one that decides lock-in

Every private AI platform is assembled from the same five parts. Vendors differ in who operates each one, and in how easily you can take it away.

The instructions come first: prompts, skills, and the rules about what an agent may touch. Model access is second: the endpoint that serves tokens, and the key that pays for them. Credentials come third, one grant for each system an agent reaches. Then the record, meaning sessions, approvals, and the trail of what was done. The control plane is fifth. It holds the other four, because it runs the database, the files and the configuration that hand all of them to an agent at run time.

Buyers spend most of the evaluation on model access. That is the part which changes fastest, and the worst thing to standardise on. A provider reprices an endpoint, a model lands, a version retires. A model list written in spring is wrong by autumn. Connector counts move the same way. At the size most teams buy, the apps they use were on the list already.

Lock-in follows the control plane, and it turns on one question. Are the instructions and the record data you can read, or screens a vendor shows you? Where they are rows in someone else's database, and a form is the only editor, the other four parts are on loan. Where they are files in a repository, another system can run them next month.

Kortix is built for the second answer. Every agent, skill, rule, connector and piece of context is a file in one git repo. A prompt change arrives as a diff. A revert is a git revert, and a staging copy is a clone. A connector policy is a few lines in the manifest at the repo root: a match pattern and an action, reviewed like any other change.

## The four questions to put to a vendor

A demo answers the questions the vendor picked. These four decide whether the contract is reversible. Each has a document behind it.

**Can I read the rules?** Ask for the file, not a screenshot of an editor. Instructions kept per agent in a database cannot be diffed between Tuesday and Friday. Undoing a bad change becomes a support ticket. A repository answers in one command.

**Can I export the memory and the history?** Chat exports look complete and rebuild nothing. Ask for the working memory, the skill definitions and the session record, in a format another system can load. Then ask who approves the export, and how long it takes.

**Where does the agent's computer run?** On Kortix, sessions run on Platinum sandboxes, not on the server ([self-hosting docs](https://kortix.com/docs/developers#self-hosting)). Ask every vendor for the provider and the region. Ask what the agent's machine can reach. A network team will put those two questions first.

**Who approves what reaches production?** In Kortix this is a setting, and it starts open: "Approval gates you set. Off until you set them." Ask each vendor to show the default. Then ask who can change it, and where that change is recorded.

The four answers fit on one page. Two vendors rarely answer all four the same way. The [comparison page](/private-ai-platform-comparison) sets Kortix, Prem AI, Xyner AI and VDF AI beside each other on these questions.

## What private costs in operations

Self-hosting costs nothing. The work it takes is another matter. Five duties come with a server you own, and each needs a name against it before the first deploy.

The server itself, sized for the API, the database and the web app. A DNS record for the main domain, plus a wildcard for the previews that change requests open. TLS on ports 80 and 443. Renewal has to keep working after the person who set it up changes teams. An updater, because an instance that stops pulling images collects last year's bugs. And a signup lock, which is the step people skip: until you set `EMAIL_URL` or `DISABLE_SIGNUP=true`, anyone who reaches the instance can create a confirmed account for any address, the admin address included ([self-hosting docs](https://kortix.com/docs/developers#self-hosting)).

That is the recurring work, and a platform engineer carries it in an afternoon a month. A team of four without one cannot. For that team the managed cloud is the honest advice, with the same files behind it: "Run it on Kortix Cloud, in your VPC, or on your own on-prem network. Self-host is free."

The server also leaves one question open, and a network review asks it early. Sandboxes run on the compute provider you configure. The instance has to be reachable so they can call back. So what you own outright is the data, the rules and the record. The machine the agent works on stays rented. Put that split in the architecture note, because it is the first thing a reviewer will test.

## When per-seat or per-token pricing is the better buy

Two pricing shapes dominate this market. Each is reasonable once it is matched to who carries the operations.

Per-seat, billed annually, is the better buy when the vendor carries the operations. The seat price covers patching, the TLS renewal and a person on call. Your security team gets a counterparty with a contract to review. For a small company with no platform engineer, that is worth more than the discount self-hosting offers. VDF AI sells on-prem this way, as annual seat bundles with unlimited agents and workflows ([VDF AI](https://vdf.ai/pricing)). Privonis prices at €60 a month with one dedicated server per 25 people ([Privonis](https://www.privonis.com/pricing)).

Per-token pricing suits teams whose usage is spiky and whose models change. A group that runs a few hundred sessions in a launch month, and forty the month after, pays for the difference. Nobody renegotiates a contract when a cheaper model appears. The bill is harder to forecast, though. An agent that retries a failed call ten times pays ten times, and the person holding the budget sees it afterwards.

A third shape exists: pay for compute, and own the software. The recurring cost becomes the server plus the model calls on keys you already hold. The five duties do not disappear. They get a name and a calendar entry.

Buy seats instead when the answer to "who owns the updater" is nobody, or when procurement needs a vendor contract with an SLA. That is a real answer for a lot of teams. The files can move later, if the platform holds them as data rather than screens.

Whichever shape you pick, the deployment is the next piece of work. The guide to [running AI agents privately](/run-ai-agents-privately) covers the server, the stack and the model keys. The [self-hosting guide](/self-hosting-kortix) covers the install and the first run.

## The rule, in the project file

`kortix.yaml`

```yaml
# Connectors: the credentials live in Kortix, never in this file.
connectors:
  - slug: linkedin
    provider: composio
    app: linkedin
    policies:
      - match: "linkedin.create_*"
        action: require_approval
```

Source: https://kortix.com/

A connector policy from the manifest at the root of a Kortix project, where every LinkedIn create call waits for a person.

## What people ask about a private AI platform

Short answers, and the limit each one leaves in place.

### Is there an AI that is private?

Yes, in the sense that matters at work: the instructions, the memory and the record can sit where you can read them. Every platform still sends tokens to a model endpoint and runs the work on a machine, so check where those two sit before you call the deployment private.

### Which AI is best for private use?

The one whose files you can take away, judged on its control plane. Compare two products by asking each for the agent's instruction file and an export of its memory, then see which vendor answers with a document and which with a sales call.

### How do I run my own private AI?

Put the Kortix stack on a Linux server you control and point a domain at it. Sign up as the admin, add a model key, then set `EMAIL_URL` or `DISABLE_SIGNUP=true` and restart. The stack runs on the server, and sessions run on sandboxes, so plan for both.

### What is the best personal AI platform?

For one person the deciding factors are the same as for a company: where the instructions live and how cleanly you can leave. A self-hosted instance on a small server keeps the agents and the memory in a repo you own, with sessions on a compute provider you configure.

## Read the file before you sit through a demo

The rules, the connectors and the record are in a repo you can clone today.

[Try Kortix](https://kortix.com) · [Compare five private AI platforms](https://privateaiforcompanies.com/private-ai-platform-comparison)