Sovereign AI for Telecoms and Network Operators
Network operators need AI that runs inside their own estate with a verifiable record, because once inference leaves the network they lose provable control.
Sovereign AI for telecoms is artificial intelligence that runs entirely inside a network operator's own estate, on hardware the operator controls, with every inference and action recorded in an audit trail the operator can verify without trusting the vendor. Network operators need it because they hold subscriber data, carry lawful-intercept obligations and sit inside critical national infrastructure, so the moment inference leaves the network the operator loses the ability to prove who saw what and why. Mickai is a Sovereign Intelligence Operating System, a SIOS, that runs offline on operator-owned hardware with every action cryptographically sealed.
In 2026 the pressure on operators is regulatory and structural at once. NIS2 raises the bar for essential-service security across the EU, DORA has been in force for financial-adjacent operations since January 2025, and lawful-intercept and data-retention duties sit on top of GDPR. Public cloud AI services such as ChatGPT, Claude and Gemini process data on infrastructure the operator does not control, which is the exact posture these duties are written to guard against.
What is sovereign AI for a network operator?
Sovereign AI means the model, the data and the audit record never leave the operator's control. The intelligence runs on the operator's own silicon, inside the operator's own security perimeter, under the operator's own keys. Nothing is streamed to an external endpoint for processing. A SIOS is the operating layer that makes this practical: it hosts sovereign models, routes work between them and seals every step. The distinction from a private cloud tenancy is control of the keys and the ledger, not just the location of a server.
What breaks if inference leaves the network?
Three things break the moment a prompt leaves the estate. First, the chain of custody. Lawful-intercept material and subscriber records handled on infrastructure the operator does not control can no longer be shown to a regulator with a clean, unbroken record. Second, jurisdiction. Data processed on foreign-operated cloud may fall within reach of the US CLOUD Act regardless of where the server physically sits, which creates exposure under GDPR and national retention law. A contractual promise from a cloud vendor is not a technical guarantee. Third, availability. Critical national infrastructure that depends on an external inference endpoint inherits that endpoint's outages and its kill switch.
How does a zero-egress SIOS work inside the estate?
The design starts with a zero-egress inbound perimeter. The SIOS accepts work from inside the network and returns answers inside the network, and it holds no outbound path to the public internet for inference. Every operator, service account and device is given a hardware-attested identity, and that identity is bound to the audit chain so each action carries a provable actor. Every inference, retrieval and tool call is written to an append-only ledger. The ledger is signed with a post-quantum signature scheme, ML-DSA, standardised as FIPS 204, so the record stays verifiable even against a future quantum adversary.
What can an auditor or regulator actually check?
The named test is offline verifiability. An auditor should be able to take the sealed ledger, on the operator's premises, with no call to the vendor, and confirm three things:
- that each entry is signed by a key bound to real hardware;
- that the sequence has no gaps and no edits;
- that every model action maps to an authorised actor and a stated purpose.
Because the signatures use ML-DSA under FIPS 204, verification needs only the public keys and the operator's own equipment. Key material for confidentiality uses ML-KEM, standardised as FIPS 203, which protects data in transit and does not sign the record. Trust rests on mathematics the operator can check, not on a vendor's word.
“For a network operator, the only defensible position is intelligence that cannot leave the estate and a record that anyone can verify without trusting the people who built it.”
Which rules make this necessary in 2026?
Several duties point the same way. NIS2 requires essential and important entities, telecoms included, to manage supply-chain and processing risk and to report incidents on tight timelines. DORA, in force since January 2025, holds financial-adjacent operations to strict operational-resilience and third-party oversight standards. GDPR governs subscriber data and cross-border transfer. On the EU AI Act, the high-risk Annex III obligations once due on 2 August 2026 were deferred by the Digital Omnibus to 2 December 2027, with embedded Annex I high-risk duties moving to 2 August 2028 and the Article 50 transparency rules largely unchanged. We read that as a build window, not a reprieve. ISO/IEC 42001 gives operators a management-system standard for the AI itself. A SIOS supports these duties by keeping processing in-estate and by producing the evidence each one asks for. It does not certify compliance, and no architecture should claim to.
How is this different from a private cloud deployment?
A private cloud tenancy still runs on someone else's infrastructure, under someone else's keys, often with a support path that reaches back to the vendor. A SIOS removes that dependency. Mickai runs offline on operator-owned hardware, seals every action, and uses cross-model consensus so that high-stakes outputs are checked by more than one sovereign model before they are trusted. The architecture is the subject of 104 filed UK patent applications, approximately 2,340 claims, owned by Mickai LTD; these are patent pending and never granted or patented. The design goal is plain: the operator keeps the intelligence, the data and the proof.
Frequently asked questions
Can telecoms use ChatGPT or other public cloud AI for network operations?
They can for low-stakes, non-personal tasks, but not for anything touching subscriber data, lawful-intercept material or network control. Public services such as ChatGPT, Claude and Gemini process data on infrastructure the operator does not control, which creates exposure under GDPR, NIS2 and national retention duties, and may bring the data within reach of the US CLOUD Act. The safer posture is to keep that work inside the estate.
Does sovereign AI mean the operator loses access to frontier capability?
No. A sovereign approach runs capable models on the operator's own hardware. Mickai hosts sovereign models and routes work between them, and it uses cross-model consensus so critical answers are cross-checked before they are trusted. The trade is not capability for control; it is location and provability that change.
How does a sovereign AI ledger help with lawful intercept?
Lawful intercept demands an unbroken, provable chain of custody. When AI assists that workflow inside the estate, every access and action is written to an append-only ledger signed with a post-quantum scheme, ML-DSA under FIPS 204. An investigator or regulator can later verify who touched the material and when, on the operator's own equipment, without trusting the vendor. That supports the duty; it does not replace the operator's legal obligations.
Is a post-quantum signed audit ledger necessary now?
The signature standard, ML-DSA under FIPS 204, protects records against a future quantum adversary who could forge older signatures. Telecoms retain data and audit records for years, so a record signed today may need to stand up a decade from now. Signing the ledger with a post-quantum scheme now avoids re-signing an entire history later. Note that FIPS 203, ML-KEM, protects confidentiality and does not sign anything.
Does running AI in-estate satisfy NIS2 or the EU AI Act?
It supports those duties; it does not satisfy them on its own. NIS2 and the EU AI Act impose organisational and legal obligations that no architecture can discharge by itself. Keeping inference in-estate and producing a verifiable audit record gives an operator strong evidence for the technical parts of those duties. On the EU AI Act, the high-risk deadline moved from 2 August 2026 to 2 December 2027, which is a window to build that evidence properly.