What skills does your team need to run sovereign AI?

Far fewer than the objection assumes. Running sovereign AI takes four ordinary roles: a system owner accountable for approvals, an IT administrator with ordinary server skills, a data steward who decides what the AI may see, and engaged process owners in the teams that use it. It does not take a research lab, because the models arrive as signed artefacts and the operating system carries the engineering.

The question matters in 2026 because staffing fear is now one of the main reasons regulated organisations default to cloud AI against their own data-protection instincts. The fear dates from the era when on-premise AI meant assembling a stack by hand, and it deserves re-examination against what deployment actually involves today.

Why did on-premise AI once need specialists?

Because there was no operating system. A team wanting AI on its own hardware had to choose a model, build a serving layer, wire up retrieval, bolt on access control, add logging and keep the whole assembly compatible through every upgrade. Each seam was a failure point, and the organisation needed machine-learning operations engineers because a human had to be the integration. An operating system approach packages model serving, retrieval, governance and audit as one installable substrate, and the specialist work collapses into administration.

Which four roles actually run a sovereign deployment?

• The system owner: accountable for what the system is allowed to do, approves changes and new uses, and answers for it to the board and, where relevant, the regulator. A business role, not a technical one.
• The IT administrator: installs, monitors, applies signed updates and manages storage and access. The same person who runs the organisation's other infrastructure.
• The data steward: decides which document stores the system may see, for which teams and roles, and owns the line between useful and inappropriate access.
• Process owners: one in each team that uses the system, defining the workflows, reviewing output quality and feeding problems back.

Smaller organisations combine these roles in fewer people, and larger ones separate them. What matters is that each is named, because an unowned decision is a bigger operational risk than any technical gap.

What skills does the administrator actually need?

Ordinary ones. Server installation, monitoring, storage management, user and access administration, applying signed and versioned updates, and reading health dashboards. A GPU server administers like any other server, and because inference is selectable between CPU and GPU, a deployment can begin on hardware the team already understands. What the administrator never does is the work a machine-learning curriculum teaches: no training runs, no fine-tuning pipelines and no cluster research.

Which skills can you cross off the list?

The expensive ones the objection assumes.

• Model training and fine-tuning expertise, because models arrive as signed, versioned artefacts, validated before release.
• GPU cluster research skills, because inference runs on a single capable machine and is selectable between CPU and GPU.
• A data science team, because the substrate handles serving, retrieval and evaluation plumbing rather than leaving it to be built.
• A dedicated machine-learning operations function, because the operating system, not a bespoke pipeline, is the thing being operated.

What is the hardest skill, honestly?

Governance judgement. Deciding what the system may see, what it may do, what is logged, what is reviewed and who approves change is harder than any technical task on the list, and it determines whether the deployment is defensible. The good news for regulated organisations is that this is a skill they already exercise in records management, information security and financial or clinical governance; sovereign AI asks them to apply it to a new system, not to acquire it from scratch. The EU AI Act's Article 4 AI-literacy duty, in force since 2 February 2025, points the same way: staff who operate and use AI need role-appropriate, documented understanding, which is what good governance produces anyway.

How do you test readiness before deploying?

Run the naming test. Write down the four roles and put a real name against each one. If all four names exist, the organisation is ready to plan; if any box stays empty, the gap is organisational rather than technical, and hiring a machine-learning engineer would not fill it. Then run a governance rehearsal: take one real workflow, and have the named people decide what data it may touch, what gets logged and who reviews the output. On Mickai, a Sovereign Intelligence Operating System running offline on operator-owned hardware, those decisions become enforced configuration, and we seal every action to the audit record, which is why the judgement, once made, does not depend on anyone's memory.

“The scarce skill in sovereign AI is not machine learning, it is the judgement to decide what a system may see, do and record.”

What a team of this shape actually operates is set out at /sovereign-ai, and the film at /film shows the working environment those four roles run day to day.

Frequently asked questions

Do I need to hire a machine learning engineer to run sovereign AI?

No. Models arrive as signed, versioned artefacts and the operating system handles serving and retrieval, so the technical work is administration rather than engineering. The hiring question worth asking is whether the four operating roles have names against them, not whether the organisation employs anyone with a research background.

Can the person who runs our servers really manage AI infrastructure?

Yes. The daily tasks are the ones that person already performs: monitoring, storage, access control and applying signed updates. A GPU server is still a server, and where accelerators feel unfamiliar, CPU-selectable inference lets the deployment start on hardware the team knows before any new equipment arrives.

Who should own sovereign AI, IT or the business?

Accountability belongs with a business-side system owner, and operation belongs with IT, mirroring how organisations already run their other critical record systems. The split matters because the hard decisions are about permission and review rather than uptime, and those are business judgements the owner must be able to defend.

What if my team has no AI experience at all?

Experience accumulates fastest in role: process owners learn what the system does well by reviewing its output in their own workflows, and literacy grows from documented, role-appropriate use rather than abstract training. The transferable foundation, governance judgement over data and records, is one regulated teams already hold.

How large does a team need to be before sovereign AI is realistic?

The honest determinant is named accountability, not headcount. The four roles are hats rather than hires, and small organisations wear several on one head, while larger ones separate them formally. A deployment becomes unrealistic only when no one can be named for a role, and that problem is organisational, not a matter of size.