Sovereign AI on the shopfloor:
the maintenance assistant that never leaves your walls

In September 2025, Roland Berger and Aleph Alpha published "AI sovereignty — A strategic imperative for European industry."¹ Its argument is not the usual abstraction about European champions. It is concrete and uncomfortable: European industry runs on digital technology it does not control, the regulatory bar for using AI in high-risk industrial settings is rising fast, and the only durable answer is sovereign AI — systems that are auditable, explainable, domain-tuned, company-owned, and deployed on infrastructure the enterprise controls.

The report grounds the urgency in the Draghi competitiveness analysis: the EU "relies on foreign countries for over 80% of digital products, services, infrastructure and intellectual property."² The capability gap is just as stark — by Roland Berger's count, Europe produced three major AI models in 2024, against forty in the United States and fifteen in China.¹ Layer the EU AI Act on top — high-risk obligations binding, fines reaching the tens of millions — and "where does the AI run, and can we prove what it did" stops being an architecture preference. It becomes the precondition for being allowed to use AI on the industrial core at all.

The report names four requirements for sovereign AI, and a build pattern that satisfies them.¹ We'll take them at face value — and then show what it actually takes to honor them in a working system, using the report's own flagship example: the maintenance assistant on the shopfloor.

The four requirementsWhat "sovereign" has to mean in practice

Stripped to essentials, the report's four requirements (its Exhibit C) are a checklist any serious industrial deployment can be measured against:

• Trust by design — auditability, explainability, and EU AI Act compliance built in, not bolted on. Every output must be traceable to its evidence.
• Modular control — company-owned data and on-premise deployment, with no lock-in to a single provider's model or cloud.
• Domain fit — tuned to the enterprise's own machines, manuals and history, not a generic model answering from the open web.
• Infrastructure fit — works with the legacy IT and OT estate already on the floor, rather than demanding a rip-and-replace.

Notice what these have in common. Not one of them is a statement about model quality. They are all statements about the system around the model — where the data lives, who can audit the output, whether a citation backs every claim, who holds the controls. That is the recurring lesson of enterprise AI, and it is exactly where most deployments come up short.

The use caseThe maintenance assistant, examined honestly

The report's headline industrial example is a GenAI maintenance assistant that "generates repair guides tailored to machine type, failure history and technician language," "fuses historical tickets, sensor data and documentation into situational answers," and — the line that matters most — "includes source links for every step."¹ A technician describes a fault; the assistant returns a step-by-step, cited repair procedure, a likely root cause, and a draft service ticket with suggested spare parts.

It is a genuinely valuable pattern — unplanned downtime and slow first-time fixes are among the most expensive problems on any line. But it is also where the gap between a demo and a sovereign system is widest. A maintenance assistant is reading attacker-reachable text (a "manual" or a ticket can carry hidden instructions), it influences a safety-relevant action, and under the AI Act it may sit in a high-risk category. Three properties decide whether it is an asset or a liability:

The lawFor high-risk industrial AI, audit is an obligation

The report is right to put compliance at the centre. Breaching the EU AI Act's high-risk obligations carries a fine of up to €15 million or 3% of global annual turnover (the €35 million / 7% ceiling is reserved for the gravest prohibited-use breaches), with high-risk obligations applying from August 2026.⁴ Two of those obligations land directly on a maintenance assistant:

• Human oversight (Article 14). High-risk systems must be built so a person can effectively oversee them — and "disregard, override or reverse the output," guarding against automation bias.⁵
• Record-keeping (Article 12). High-risk systems "shall technically allow for the automatic recording of events (logs) over the lifetime of the system," so any decision is traceable after the fact.⁵

The U.S. NIST AI Risk Management Framework arrives at the same place from a different direction — its four functions are Govern, Map, Measure, Manage, with Govern "infused throughout."⁶ And the sovereignty instinct is widely shared: Cisco's 2025 Data Privacy Benchmark Study found 90% of organizations believe local storage of data is inherently safer, with 64% worried about inadvertently sharing sensitive information with AI.⁷ For machine manuals, fault histories and OT data, "on-premise" is not a comfort blanket — it is the answer to a compliance question.

The synthesisSovereignty is a platform property, not a model choice

Put the four requirements together and the conclusion is the same one the security and governance worlds keep reaching: the hard part is not the model. It is the system around it — keeping the corpus inside your walls, grounding every claim in a citation, treating every input as hostile until scanned, keeping a human on every consequential action, and logging all of it immutably. Solve those once, as platform capabilities, and the next use case inherits them. Solve them per-pilot, and each one re-litigates sovereignty from scratch.

That is the design stance behind flow8. The same non-negotiables apply to every process it runs, whether reconciling an invoice or diagnosing a pump fault:

And it runs self-hosted — on-premise, private cloud or air-gapped — so the data on your shopfloor never crosses a boundary you don't own. That is the infrastructure-fit and modular-control half of the report's checklist, satisfied by where the platform runs rather than by a promise.

flow8 in practiceThe maintenance assistant, as two governed flows

We built the report's shopfloor case as two flow8 flows. The first owns the corpus; the second retrieves over it and drafts. Both write to one audited maint.diagnoses ledger, and nothing they produce is dispatched without a human. The architecture, not the prose:

Two design choices make this sovereign rather than merely clever. First, the corpus is the system of record: the vector store is a derived index, rebuildable from a provenance mirror in your own database, so a citation always resolves to a human-readable source without trusting the index. Second, the gate that suppresses a draft is deterministic, not the model's self-assessment — low confidence, a weak retrieval, an ungrounded citation, or a detected injection all force the output into a review queue. The model proposes; the platform decides whether a human must look first.

The takeawayBuild the sovereign core once

Roland Berger and Aleph Alpha are right that sovereign AI is a strategic imperative for European industry, and the maintenance assistant is a sharp example of why. But the value is not captured by the model that drafts the guide. It is captured by the system that keeps the corpus inside your walls, grounds every step in a citation, scans every input for injection, keeps a technician on every dispatch, and logs all of it on infrastructure you own. Get that sovereign core right, and the next shopfloor use case is a fast, safe addition. Get it wrong, and you have shipped a confident, ungovernable assistant onto a line where mistakes cost real money — and, increasingly, real fines.