Do You Need an AI Team to Run Sovereign AI On-Premise?

No. You do not need to hire a bench of machine-learning engineers to run sovereign AI on your own premises. Running Mickai on hardware you own is an IT task, not a data-science project. If your organisation already keeps a server patched, manages user accounts, and runs a backup, it already has the skills to own and operate the Sovereign Intelligence Operating System (SIOS). The hard machine-learning work, the part that genuinely needs specialists, is the part we do before the software ever reaches you, and the part the operating system is designed to keep doing on its own.

The staffing question is the one that quietly stalls the buying decision. A leader looks at on-premise AI, pictures a new team of PhDs, a GPU cluster to babysit, and a permanent line on the budget, and parks the whole idea. That fear is reasonable. It is also aimed at the wrong thing. Here is the honest split of what owning your AI asks of you, and what it does not.

The short version

• You do not train, tune, or serve the model. We do that. The model is prepared before it reaches you.
• Installing, running, updating, and backing it up are ordinary IT tasks, not machine-learning ones.
• The operating system is built to update from signed packages and to check and repair its own health, without a data-science team on hand.
• The one specialist worth naming is a governance owner, usually someone you already have, not a new hire.

Why the "you will need an AI team" fear is real for everyone else

The fear comes from the do-it-yourself route, and on that route it is entirely justified. Assembling on-premise AI from open parts means downloading a raw model, standing up an inference server, wiring in a vector database, keeping accelerators fed, matching driver versions, getting quantisation right, and watching for the model to drift. That is genuine machine-learning and MLOps work, and it does need engineers who do it for a living.

That picture is the one most buyers carry into the room, and it is why the staffing objection lands so hard. The mistake is assuming every on-premise deployment looks like that. Mickai is not a model you have to operate. It is an operating system that operates the model for you. The difference is the whole point of buying a product rather than building a stack.

What owning it actually asks of your IT function

Everything on this list is the day job of a competent IT or infrastructure team. None of it is machine learning.

• Install it. You run an installer on a workstation-class machine. Poros, our sovereign inference engine, detects the hardware and configures itself, from newer GPUs down to older cards and plain CPU. There is no cluster to design and no datacentre to provision.
• Run it. You manage users, roles, and access the way you manage any internal system. The studios sit behind your existing identity and permission model, so the people who already administer accounts administer this too.
• Keep it. You back it up and keep the host patched, exactly as you would any on-premise server. Because nothing leaves the building, there is no external service to reconcile and no data-residency puzzle to solve.
• Govern it. You decide who may use which studio and you review the audit record. That is a compliance and governance task, closer to your existing controls than to any line of code.

If those four verbs already live somewhere in your organisation, the operator you need is already on the payroll.

What it explicitly does not ask for

Being precise about the absences matters more than the presences, because the absences are what the fear is built on.

• No model training. We prepare the models. You never touch a training pipeline, a dataset, or a fine-tuning run.
• No MLOps bench. There is no serving stack for you to assemble, no inference server to hand-tune, no quantisation to get right. Poros is built to serve as the engine, so there is nothing for you to stand up.
• No GPU cluster to babysit. It is built to run on a single workstation-class machine you can put in a locked cabinet, not a rack estate you have to design, power, and cool.
• No prompt-engineering team. The studios are built around real jobs: drafting, analytics over your own governed data, compliance work, help desk, and security operations, rather than a blank box someone has to learn to coax.
• No data-science hire to keep it current. Staying up to date is an install step, covered next, not a retraining project you run in-house.

How it updates and self-checks without a bench of engineers

This is the part the objection never accounts for, so it is worth spelling out. The intelligence needed to keep the system running is built into the operating system, not into a job description you have to fill.

Updates arrive as signed packages. When a new version is available, the operating system verifies it against a cryptographic signature before it applies anything, then installs it. Because everything stays offline, you bring the package in rather than opening a pipe to the outside world. Updating is an IT action, an approve-and-apply, not a rebuild.

It watches and mends itself. SIOS is designed for self-diagnosis and self-repair. It checks its own health, catches a component that has drifted or failed, and repairs or rolls back to a known-good state rather than waiting for a human to notice. A built-in doctor routine reports what is wrong in plain language, so the person on the other end is triaging in ordinary IT terms, not reading model internals. Sentinel, the operating system's internal watch layer, is designed to flag anomalous behaviour as it happens.

The audit record does the proving for you. Every action is sealed under post-quantum cryptography to the Offline Attestation Record (OAR), a tamper-evident, independently verifiable log. You do not need an engineer to establish which model ran, on which machine, for a given action. You read the record, and a verifier can confirm the live chain against a signed checkpoint held off-box, with no network required. The OAR is tamper-evident, not unbreakable: what it rules out is silent, unnoticed alteration, which is exactly what an auditor or a board wants ruled out.

Between signed updates, self-repair, and a record that verifies itself, the routine operation of the system is designed to sit inside the software, not inside a hiring plan.

Where a specialist genuinely helps, and it is not an ML team

We would rather be honest than oversell the point. There are places a specialist adds value. None of them is a standing machine-learning function.

• A named owner. Someone accountable for who has access and for reviewing the audit trail. In almost every organisation this is an existing IT or compliance lead who takes on the responsibility, not a new appointment.
• A first-time rollout. Sizing the hardware and mapping studios to teams benefits from a short conversation with us or a delivery partner. That is a project with an end, not a permanent post.
• The model side, which stays with us by design. Model selection, preparation, and improvement are ours to carry. That is a deliberate line. We patent the mechanism, not the model, across 104 filed UK patent applications carrying 2,340 claims, and we keep the machine-learning burden on our side of that line so you can keep it off yours.

The line we drew on purpose

We built SIOS, held by Mickai LTD (Companies House 17166618) under the registered UK trademark MICKAI, so that ownership would not come with a recruitment drive attached. The first ten studios are the initial ones designed to reach organisations, with the remaining fifty-three of sixty-three in active development, and every one of them is built on the same engine and seals to the same audit record. The promise underneath is simple: you keep custody of your data and your AI, and you run it with the team you already have. Sovereignty was never meant to be a staffing problem. We designed it not to be one.

Frequently asked questions

Do you need machine-learning engineers to run on-premise AI?

No. Running Mickai on your own hardware is an IT task, not a data-science one. Installing, running, updating, backing up, and governing access are all skills an existing IT or infrastructure function already has. The machine-learning work, training and preparing the model, is done by us before the software reaches you, and the operating system is built to update and check itself without a specialist on hand.

What skills does my IT team actually need?

The ordinary ones. Running an installer, managing user accounts and roles, keeping a host patched, taking backups, and reviewing an access and audit trail. Poros, the inference engine, detects the hardware and configures itself, so there is no cluster to design and no serving stack to assemble. If your team keeps an internal server healthy today, it can own SIOS.

How does it get updated without a data-science team?

Updates arrive as signed packages. The operating system verifies each one against a cryptographic signature before applying it, and because everything stays offline you bring the package in rather than opening a connection out. Updating is an approve-and-apply step, not a retraining project or a rebuild, so no machine-learning specialist is required to keep the system current.

Who handles the AI model itself?

We do, by design. Model selection, preparation, and improvement stay on our side of the line. You never train, tune, or serve a model. This is deliberate: we patent the mechanism rather than the model, and we carry the machine-learning burden so your organisation does not have to build a team to shoulder it.

What happens if something breaks outside working hours?

SIOS is designed for self-diagnosis and self-repair. It checks its own health, catches a component that has drifted or failed, and repairs or rolls back to a known-good state rather than waiting for someone to notice. A built-in doctor routine reports issues in plain terms, so any follow-up is ordinary IT triage rather than model debugging. Routine break-fix maintenance is an IT-grade task, not a machine-learning one.

Is one person enough to own it in a small organisation?

For many organisations, yes. A single named owner, usually an existing IT or compliance lead, can be accountable for access and for reviewing the audit record, with the same team that runs the rest of the infrastructure handling install, updates, and backups. The point of the design is that owning your AI does not add a hiring plan to the budget.