How Telecoms Operators Meet the Telecommunications Security Act With AI That Never Leaves the Network
Running AI entirely inside the security-critical boundary keeps configuration and signalling data within operator control, aligning with the code of practice by design.

Telecoms operators meet the Telecommunications Security Act code of practice by running artificial intelligence inside the security-critical boundary, on operator-owned hardware, behind a zero-egress perimeter, so network configuration and signalling data never cross out to a third party. The code treats configuration data, signalling and the management plane as security-critical, so any assistant that sends this data to a public cloud service moves a sensitive function outside the operator's control and sits in direct tension with the code. Mickai is a Sovereign Intelligence Operating System, a SIOS, that runs offline and seals every action to a post-quantum signed audit ledger.
In 2026 the pressure is practical. Ofcom is actively assessing compliance, Tier 1 and Tier 2 providers have passed their first implementation milestones, and operators increasingly want generative AI in the network operations centre. The market answer so far points at private cloud regions, but a private region still moves data to a vendor's infrastructure and often within reach of foreign legal process. The code does not ask where the region is. It asks whether security-critical data stays under the operator's control.
What does the Telecommunications Security Act code of practice actually require?
The Telecommunications Security Act 2021 amended the Communications Act 2003 and is given detail by the Electronic Communications (Security Measures) Regulations 2022 and the Telecommunications Security Code of Practice. The duty is to identify and reduce the risk of security compromises. The code names a specific category of data that must be protected because it would let an attacker understand or reconfigure the network. That category includes:
- network configuration and architecture data
- signalling data and the signalling plane
- management plane traffic and privileged administrative access
- credentials, keys and network oversight function data
Sending any of this to an external service is exactly the exposure the code is written to prevent.
Why can public cloud AI services not meet the code?
Public cloud AI services are useful, but they are inference services reached over the internet. To answer a question about a fault, they must receive the data that describes the fault. For a telecoms operator that data is configuration and signalling, which the code classes as security-critical. A private cloud region narrows the blast radius but does not remove it: the data still leaves operator premises, still sits on vendor-operated infrastructure, and, under the United States CLOUD Act, can remain reachable by foreign legal process regardless of the region's physical location. The architecture, not the marketing, decides compliance.
How does AI that never leaves the network work?
A SIOS inverts the usual flow. Instead of sending data out to a model, the model runs where the data already lives, on hardware the operator owns and controls. The design rests on a small number of concrete mechanisms:
- a zero-egress inbound perimeter, so the system can receive prompts but has no route to send data out
- sovereign models that run entirely on local compute, with no external inference call
- hardware-attested identity, so each action is bound to a verified device and operator
- a post-quantum signed audit ledger, where every action is sealed under FIPS 204, the ML-DSA signature standard, with FIPS 205 available as a second scheme
- cross-model consensus, where several local models must agree before a high-impact action proceeds
Every action is cryptographically sealed and verifiable offline. The architecture is protected by 104 filed UK patent applications, approximately 2,340 claims, owned by Mickai LTD, patent pending.
“When security-critical data cannot physically leave the network, keeping it under the operator's control stops being a promise and becomes a property of the architecture.”
Which measures in the code does this map to?
The code is organised around protecting security-critical functions, controlling privileged access, and monitoring the network. Running AI inside the boundary maps to each. Sensitive data is kept within the security-critical boundary because there is no egress path. Privileged access is constrained because the assistant acts through hardware-attested identity, not a shared cloud credential. Monitoring and forensic readiness improve because every action is written to a sealed ledger rather than a vendor's opaque logs. The operator can demonstrate, rather than assert, that AI activity stayed inside the network.
What can an Ofcom auditor check?
Ofcom can request information, inspect, and impose penalties of up to ten per cent of turnover, or £100,000 per day for a continuing contravention, so evidence matters. Offline verifiability is the test. An auditor can take the signed audit ledger, verify the FIPS 204 signatures on a machine with no network connection, and confirm the chain is unbroken. A second test is the egress test: inspect the perimeter and confirm there is no outbound route for security-critical data. Both are checkable facts, not statements of intent.
How does this sit with DORA, NIS2 and the EU AI Act timeline?
The same architecture answers more than one regime. DORA, in force since 17 January 2025, demands operational resilience and control over third-party ICT risk, which a self-contained system reduces by removing the third party from the data path. NIS2 covers essential and important entities, including many telecoms operators, with similar duties on risk management and incident handling. 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 Article 50 transparency duties largely unchanged. We read that as a build window, not a reprieve. ISO/IEC 42001 gives a management-system framework to evidence the governance around all of it.
Frequently asked questions
Does the Telecommunications Security Act allow AI in a private cloud region?
The code does not name private cloud regions. It requires that security-critical data, including configuration and signalling, stays under the operator's control. A private region can help, but the data still leaves operator premises onto vendor infrastructure and may be reachable under the United States CLOUD Act. AI that runs inside the network avoids the exposure entirely.
Is signalling data classed as security-critical under the code?
Yes. Signalling data and the signalling plane describe how the network routes and manages traffic, so an attacker with that data can understand and disrupt the network. The Telecommunications Security Code of Practice treats it, along with configuration and management plane traffic, as data that must be protected. Sending it to an external AI service is the exposure the code is written to prevent.
What is a zero-egress AI deployment?
A zero-egress deployment can receive prompts but has no route to send data out of the network. The AI runs on operator-owned hardware, uses local models only, and never calls an external inference service. Because there is no outbound path for security-critical data, the data cannot cross the boundary even if something is misconfigured.
How does an operator prove to Ofcom that data never left the network?
Through offline verifiability. Every action is written to a post-quantum signed audit ledger sealed under FIPS 204. An auditor can verify those signatures on a disconnected machine, confirm the chain is unbroken, and separately inspect the perimeter to show there is no egress route. This is checkable evidence rather than a vendor assurance.
Does running AI inside the network also help with DORA and NIS2?
Yes. DORA, in force since 17 January 2025, and NIS2, which covers essential and important entities, both push operators to control third-party ICT risk and evidence resilience. Removing the external AI service from the data path reduces third-party exposure directly. The same sealed ledger provides the incident and forensic evidence both regimes expect.