Private AI means artificial intelligence running on computers your organisation owns and controls, so documents and prompts stay on your premises. It differs from an enterprise licence for a public AI service, where your data still travels to another company's servers. MICKAI® is a private AI operating system installed on hardware you own.
What does private AI actually mean?
Private AI means the model runs on compute your organisation controls, and the data you put into it stays inside your own network boundary. The weights sit on your hardware, inference happens on your hardware, and nothing about a query needs to cross a link you do not own.
Three parts matter, because suppliers use "private" for a range of arrangements.
Where the weights live. A model file on a server in your rack is private. A model file in a vendor's tenancy that only you can query is not.
Where inference runs. The arithmetic has to happen on your silicon. If the prompt leaves the building to be processed, the deployment is not private, whatever the contract says.
Where the surrounding data lives. Prompts, retrieved documents, outputs, logs and embeddings are all copies of your information. Privacy that covers the model but not the log file is not privacy.
Private deployment is the baseline the field starts from now, not the differentiator. Running a model on hardware you own is a solved problem. The hard part is everything built around it before a regulated organisation can put it into production.
How is private AI different from an enterprise licence for a public AI tool?
An enterprise licence changes the contract governing your data. Private AI changes where your data physically goes. The first is a legal control, the second an architectural one, and they are not substitutes for each other.
Business tiers of public AI chatbots usually commit that your inputs will not train the provider's models, that retention is limited, and that staff access is restricted. Those are real commitments and reputable providers honour them. But the data path is unchanged. Your prompt and any attached documents travel to infrastructure the provider operates, are processed there, and you verify what happened by reading the provider's paperwork, not by inspecting your own systems.
Under UK GDPR that difference has a name. Use a public service and you are a controller relying on a processor, with everything that follows: a processor contract, due diligence on sub-processors, a transfer mechanism if processing happens outside the UK, and an accountability trail. The ICO guidance on AI and data protection sets out how existing data protection principles apply to AI systems and who is accountable. Run the system yourself and much of that chain collapses into a control environment you can audit directly.
None of this makes cloud the wrong answer. For work that is not regulated, shared infrastructure is hard to beat on economics. The argument is narrower: where the data is itself the regulated asset, renting the intelligence means accepting a data path you cannot inspect. There is a longer comparison of sovereign AI, private cloud and on-premise for buyers weighing all three.
Where does the data go when AI is private?
In a correctly configured private deployment, nowhere outside your network. The load-bearing word is "configured", because most accidental egress in on-premise AI has nothing to do with inference.
The leaks to look for are the dull ones: telemetry on by default, crash reporting, licence activation calls, automatic model downloads from a public registry, update checks, and third-party components inside an otherwise local stack that phone home. Each is defensible in isolation. Together they mean a system described as local is still holding a conversation with the internet. That is why running AI locally does not by itself guarantee privacy.
We build Mickai SIOS, the Sovereign Intelligence Operating System, to be offline capable with no data egress. Put a tap between the machine and everything else, then install it, disconnect it, use it, and see what it tries to reach. A supplier who cannot survive that test is selling a hosted service with a local front end.
Which kinds of organisation choose private AI?
Organisations where the data is itself the regulated or contractually restricted asset, and where a supervisor, a client or a court may later ask what the system did and why. That covers financial services firms, legal practices, government departments and their suppliers, defence supply chain companies, and any business holding third-party confidential information under contract.
The pattern is not distrust of cloud security engineering. These organisations already carry obligations a shared service makes awkward to discharge. The FCA and the PRA expect regulated firms to manage outsourcing and third-party dependency risk, including for services material to their operations: see the FCA Handbook at SYSC 8 and PRA Supervisory Statement SS2/21 on outsourcing and third party risk management. Professional confidentiality duties sit uncomfortably with sending client material to a processor the client never agreed to.
A second group is worth naming: organisations using AI on material they are not permitted to disclose to anyone, including to a third party's AI tooling. For them the calculation is short. If the work cannot go out, the intelligence has to come in.
Does private AI mean you have to build it yourself?
No, and building it yourself is usually the expensive route. Serving a model locally takes an afternoon. Making that model usable by non-technical staff, under access control, with a retention position, an audit trail and a safe way to update it, takes considerably longer.
That gap is why we built an operating system rather than an application. Mickai SIOS installs on hardware the customer owns and sits between a model and a working business process: role-based access, fifty specialised models we call brains, studios for the functions a business actually runs, and a record of every consequential action. The difference between that and a self-hosted chat endpoint is set out in the comparison of a sovereign intelligence operating system and a private LLM.
Build against buy should turn on the surrounding controls, not the model. Ask any supplier, including us, how approval works, where logs go, how updates reach an offline machine, and what happens when a model produces a wrong answer someone acted on.
One honesty note, since it comes up in procurement. A local OCR runtime has read scanned PDFs in our controlled tests, and extraction and ingestion integration into SIOS is still being completed. If a supplier says unstructured document ingestion is finished, ask to see it on your own documents.
What does private AI not solve on its own?
Privacy is a property of the data path, not of the decisions the system makes, and the two get conflated constantly. Moving the model inside your perimeter removes a class of confidentiality risk and leaves every other risk where it was.
A private deployment still needs access control, or it becomes a search engine over material most staff should not see. It still needs a retention position, because prompts and outputs are records. It still needs someone accountable for what the system may decide alone. The NCSC guidelines for secure AI system development, published with international partners, treat secure design, development, deployment and operation as one lifecycle. The UK government AI Cyber Security Code of Practice sets out voluntary security principles for organisations that develop and operate AI systems. Neither becomes irrelevant because the hardware is yours.
One risk private deployment concentrates rather than removes. Bringing sensitive material into one system a hundred people can query creates an insider exposure that did not exist while the data sat scattered across a file share. Our answer: consequential actions wait for a named person to approve them, and the approval is sealed in the Open Audit Record, so a later edit makes verification fail.
How do you prove an AI deployment is genuinely private?
With evidence a third party can check, not with assurances from the supplier. Two kinds of evidence matter: what the system does on the network, and what record it leaves of its own behaviour.
Network evidence is straightforward and you should insist on it. Run the system on an isolated segment, capture everything at the boundary, exercise it with real work, and read the capture. Behavioural evidence is harder, and it is where most on-premise AI is weakest: a local log file is only as trustworthy as the administrator who can edit it.
That is what the Open Audit Record is for. Every consequential action in SIOS is sealed with ML-DSA-65, the post-quantum signature scheme NIST published as FIPS 204 in 2024. An auditor exports the record, verifies the signatures offline against a public key, and does it with tools that are not ours.
The distinction to hold on to is tamper-evident rather than tamper-proof. Nothing stops an administrator with physical access from altering a stored record. What the seal does is make the alteration fail verification, so interference is detected rather than prevented. A supplier promising a record that cannot be touched is either confused or hoping you are.
Our closed beta is open and one regulated company is onboarding as a design partner. If you are weighing private AI against an enterprise licence, the sovereign AI overview covers the wider picture. The network test above is the one to run first.
Frequently asked questions
Does private AI mean the AI runs without an internet connection?
Not necessarily, although it should be able to. Private AI means inference happens on hardware you own; the machine may still sit on your corporate network for ordinary reasons. The test worth applying is whether the system keeps working with the internet disconnected. Mickai SIOS is offline capable, so an air-gapped installation is a supported configuration rather than a degraded one.
Do we need our own data centre to run private AI?
No. A single server in a locked comms room is enough for many workloads, and a small rack covers most mid-sized deployments. What matters is that the hardware sits under your control and your physical security, not that it sits in a purpose-built facility. Sizing depends on how many people query the system at once and which models you run.
Can a private AI system still be updated?
Yes. Updates are packaged and applied deliberately rather than arriving silently, which is the point of the design. On a connected installation the process looks conventional. On an air-gapped one, updates travel on removable media, are verified against a signature before installation, and are applied on a schedule you set. Nothing updates itself without an administrator agreeing to it.
Who can see our prompts in a private AI deployment?
Only the people your access controls permit, plus anyone holding administrative access to the underlying machine. That is a smaller and more knowable set than with a public AI service, where the provider's infrastructure and authorised staff also sit in scope. It is not zero, which is why prompt access should be role-based and why administrative actions belong in a signed record.
Is private AI the same thing as sovereign AI?
They overlap without being identical. Private AI is about the data path: processing on hardware you control. Sovereign AI adds jurisdiction and dependency, meaning whose law governs the system, whose supply chain it rests on, and whether it keeps running if a foreign supplier withdraws. A deployment can be private and still depend on a vendor outside your jurisdiction.
Related briefings
Deploying private AI
- Offline AI Assistant: What It Can Do for Your Staff
- Private AI Deployment Options: Workstation to Air Gap
- On-Premise AI Server Requirements for a Normal Office
- How Sovereign AI Integrates With Your Existing Systems
- From Data to Answers, Without the Data Leaving
Documents and retrieval
- What Is RAG? Retrieval-Augmented Generation Explained
- How to Prepare Documents for a Private AI Knowledge Base
Part of a series of 60 briefings on deploying and governing AI in UK regulated organisations, archived with a DOI at 10.5281/zenodo.22975756.
Evaluating AI for a regulated organisation? Mickai runs on hardware you own, offline. Consequential actions wait for a named person to approve them, and what the AI did is sealed into a signed record an auditor can check without us. Applications for the invitation-only closed beta are open. Apply for the closed beta.
Written by Micky Irons, founder and chief executive of Mickai LTD.
Top comments (0)