When the Network Runs Itself: The Account Telecoms Regulators Will Demand

A control room with no transcript

Picture a national mobile network at three in the morning. A fibre cut in one region shifts a wave of traffic onto neighbouring sites. An artificial intelligence (AI) controller notices the congestion, reshapes routing, throttles a class of low-priority traffic, spins up reserved capacity, and quietly de-prioritises a software update that was about to push to ten thousand base stations. By the time the duty engineer has finished their coffee, the network has made several thousand decisions. None of them were wrong, exactly. But when a hospital paging system drops for ninety seconds inside that window, and the regulator asks what happened and why, the honest answer from most operators today is a shrug dressed up as a dashboard.

I run a company that builds the opposite of a shrug, so I have skin in this argument and I will say so plainly. The problem is real whether or not you ever buy anything from me. The networks that carry emergency calls, banking, power-grid telemetry, and the ordinary texture of daily life are increasingly run by software that decides faster than any human can supervise. We have automated the decisions. We have not automated the account of those decisions. That is the gap, and it is the gap a telecoms regulator will eventually stand in front of you and demand you close. Everything that follows is an argument about that one missing thing, the record, and why the next decade of running critical infrastructure turns on it.

Artificial intelligence did not creep into the network, it took over the control loop

It is tempting to think of AI in telecoms as a layer of clever analytics bolted onto a network that humans still drive. That framing is a decade out of date. In a modern radio access network and core, machine-learning models now sit inside the live control loop. They predict traffic and pre-position capacity. They tune the thousands of parameters in a self-organising network that no human team could tune by hand. They detect anomalies and trigger remediation before a person has read the first alert. They schedule maintenance windows, balance energy against performance, and in the more advanced deployments they decide, autonomously, to reroute, to scale, to isolate a misbehaving element.

This is not a future to brace for. It is the present, and it exists for a good reason. A network with millions of cells and billions of daily sessions cannot be operated at human speed. The economics of fifth-generation (5G) mobile networks, and the looming complexity of what comes after, make autonomy a requirement, not a luxury. I am not here to argue against it. Closed-loop automation is one of the genuinely good ideas of the last ten years, and the engineers who built it deserve credit, not suspicion. The point I want to make is narrower and harder to dodge. The more the network decides for itself, the more the question of accountability moves from the human operator to the machine, and our tools for holding a machine to account are embarrassingly thin. We have spent a fortune teaching the network to act. We have spent almost nothing teaching it to answer for what it did.

The outage is when the questions arrive, and they arrive in a specific order

Every serious outage in critical infrastructure ends in the same place: a room, a regulator, and a sequence of questions. What failed. When. Who or what decided to do the thing that made it worse, or that failed to make it better. Was the decision within policy. Could it have been foreseen. Has it been fixed so it cannot recur. These questions are not hostile. They are the minimum a society asks of the systems it depends on. The trouble is that they assume a record exists that can answer them truthfully, and that the record can be trusted by someone who has every reason not to trust you.

When the decision-maker was a human shift engineer, that record existed in a rough form: change tickets, a runbook, a phone log, a person who could be asked under oath. None of it was perfect, but it was anchored to a human being who could be held responsible. When the decision-maker is a model running inside an orchestration platform, the record is usually a pile of logs. And logs, let me be blunt, are not evidence. They are a story the system tells about itself, written by the same system, mutable by anyone with the right credentials, and almost never structured around the one thing the regulator actually cares about, which is the decision and its justification at the moment it was taken.

I have watched too many post-incident reviews collapse into archaeology. Engineers grep through terabytes of telemetry trying to reconstruct a causal chain that was never recorded as a causal chain. They find correlation and call it cause because the deadline is tomorrow. The model that made the call has since been retrained, so even rerunning it proves nothing about what it would have done that night. This is not negligence by the engineers. It is the predictable result of treating accountability as something you reconstruct afterwards rather than something you capture in the moment. You cannot dig a true account out of data that was never written to be an account in the first place.

Why the usual answers do not survive contact with a regulator

The industry has three standard responses to this problem, and all three fail in the same way. The first is better observability: more dashboards, more tracing, more retained telemetry. This is useful for engineering and useless for accountability, because none of it is tamper-evident. A determined insider, or an attacker who has reached the logging pipeline, can edit the story after the fact, and you cannot prove they did not. The second is explainable artificial intelligence, meaning tools that produce a human-readable rationale for a model's output. Valuable, but an explanation generated after the event, by a system with an interest in the answer, is exactly the kind of evidence a serious investigation discounts. The third is to keep a human in the loop. Necessary for the highest-stakes calls, but it does not scale to thousands of automated decisions a minute, and a human rubber-stamp is not the same as a human decision.

What all three miss is that the regulator is not asking for cleverness. The regulator is asking for a record that is true, complete, ordered, and impossible to quietly rewrite. That is a different engineering problem from observability, from explainability, and from human oversight. It is the problem of the verifiable account: proving, to a sceptical outsider with no reason to trust you, exactly what the system decided, in what order, against what policy, before the consequences unfolded. Notice that each of the three usual answers improves how well you understand your own network, and none of them improves how well a stranger can verify your story. Those are not the same goal, and conflating them is how operators end up confident right up until the moment their confidence is worth nothing in a tribunal.

What a regulator-grade account actually has to do

Let me be concrete about the properties such a record needs, because vague calls for transparency help no one. First, it must be captured before the action executes, not narrated afterwards. An account written after the fact is a confession or an alibi, and a regulator treats it as neither evidence of intent nor proof of state. Second, it must be ordered and unbroken, so that you can prove no entry was deleted from the middle. Third, it must be tamper-evident in a way that does not depend on trusting the operator, because the operator is the party under investigation. Fourth, it must be verifiable by the regulator independently, ideally without special tools and without phoning the vendor for help. And fifth, given that records of critical-infrastructure decisions may need to stand up for years, it must be secured against the cryptography of the future as well as the present.

That last point is not theoretical hand-waving. The migration to post-quantum cryptography is underway across serious institutions precisely because a record signed today with conventional cryptography could be forged tomorrow once a sufficiently capable quantum computer exists. The United States National Institute of Standards and Technology (NIST) has standardised post-quantum signature schemes for exactly this reason. If you are building an evidentiary record that must hold up in a dispute a decade from now, signing it with cryptography you already expect to break is not a sensible plan. You would not store legal records on paper you knew would dissolve in five years, and a cryptographic signature with a known expiry date is the digital equivalent.

Notice what this list does not require. It does not require the regulator to trust the operator. It does not require the operator's logging stack to be honest. It does not even require the original system to still exist when the question is asked. A properly constructed account stands on its own mathematics, which means it survives the very conditions under which a normal log collapses: a hostile investigation, a compromised insider, a model long since retrained out of existence. That is the bar, and almost nothing deployed in telecoms operations today clears it.

The regulatory weather is changing, and it is not changing back

You can feel the direction of travel even where the specific rules are still being drafted. The European Union (EU) Artificial Intelligence Act brings a tranche of high-risk obligations into force in 2026, and the spirit of those obligations is record-keeping, traceability, and human oversight of consequential automated systems. Telecoms sits squarely in the category of critical infrastructure that lawmakers worry about. Network resilience rules across major jurisdictions are tightening, with mandatory incident reporting and growing expectations that operators can demonstrate, not merely assert, what happened during a disruption. And the broader climate of AI liability is shifting toward the operator: if your autonomous system caused harm, the burden increasingly falls on you to show it behaved within its mandate.

I am deliberately not quoting precise figures or inventing a study, because the trend matters more than any number I could cite, and the trend is unambiguous. Regulators are moving from asking operators to be careful to asking operators to be provable. The era of taking a telecom's word for what its automation did is closing. When it closes fully, the operators who treated the audit record as an afterthought will be the ones explaining to a tribunal why they cannot account for their own network. The uncomfortable part for boards is the lead time. You cannot retrofit a tamper-evident account onto last year's incidents. The record either existed at the moment the decision was taken or it never will, which means the time to build it is before the rules land and before the outage, not after either.

A worked example: the night the model throttled the wrong traffic

Return to that three-in-the-morning incident and run it twice. In the first version, the operator has world-class observability and nothing else. After the hospital paging drop, the investigation pulls logs, traces, and model telemetry. The engineers can show that traffic was throttled, but they cannot prove which policy the model was applying at that instant, whether that policy had been changed earlier that day, or that the logs they are showing the regulator are the logs that actually existed at three in the morning and not a cleaned-up version. The model has been retrained twice since. The investigation drags on for months and ends in an expensive settlement and a remediation order, because the operator could not produce a trustworthy account. Notice that the operator here is not even dishonest. They are simply unable to prove they are honest, and in an investigation that amounts to the same thing.

In the second version, every consequential decision the controller took was recorded as a signed entry the instant before it executed: the inputs the model saw, the action it chose, the policy it was acting under, the identity of the model version, all sealed and chained to the entries before and after it. When the regulator arrives, the operator hands over the relevant slice of the record and a verifier. The regulator checks the signatures and the chain themselves, on their own laptop, without trusting a single claim the operator makes. They can see that the throttle was applied under a policy that, in hindsight, mis-ranked emergency-services traffic, that the policy had not been tampered with, and that the operator's account is complete and unaltered. The fault is real and the operator still owns it. But the investigation is hours, not months, and it turns on the actual decision rather than on whether anyone can be believed.

That second version is not a fantasy of perfect networks. The network still failed. The point is that accountability became a matter of checkable fact instead of contested narrative. That is the whole game. A verifiable account does not make your automation correct. It makes your automation answerable, which is the thing a regulator, a court, and frankly your own board actually need. The difference between the two versions is not a smarter model or a faster network. It is whether the record was built to be believed by someone who starts out not believing you.

What we built, and why it is shaped this way

Mickai is a Sovereign Intelligence Operating System (SIOS), built and in production, and the reason I keep returning to the word account is that the account is the architectural centre of the whole thing, not a feature stapled to the side. At its core is what we call the Open Audit Record. Every action the system's intelligence takes is signed before it executes. The entries are hash-chained and append-only, so the order is fixed and nothing can be quietly removed from the middle without the chain breaking. The signatures use a post-quantum scheme, specifically the United States NIST FIPS 204 ML-DSA-65 standard, so the record is built to outlast the cryptography we use today. And, critically, the record is verifiable offline in an ordinary browser, with no trust placed in us as the vendor. You do not have to believe Mickai. You have to check the mathematics, and anyone can.

The intelligence itself is organised as fifty specialised brains, twenty-five domain and twenty-five operational, running on a silicon substrate we call Poseidon. We are actively training our own models now, fine-tuning and specialising open foundations such as Llama 3.2 and Qwen 2.5 and building a sealed corpus, with the roadmap scaling toward fully native weights as funding allows. Above that sits Pantheon, a sovereign Layer 1 chain that anchors the audit root to Bitcoin, so that the integrity of the record is witnessed by something outside any single operator's control, with a fixed supply token, PAN, of five billion. I will be honest that the Pantheon chain is the one part of the stack still in build. The audit record, the signing, the offline verification, those are live today.

None of this is abstract intellectual property for its own sake. We hold one hundred and one filed United Kingdom patent applications, roughly two thousand two hundred and thirty-four claims, owned by Mickai LTD with myself as the named inventor, and a meaningful share of them concern exactly this problem: how an autonomous system can produce an account of itself that an adversary cannot forge and a regulator can verify alone. We filed because we believe this is the part of AI infrastructure that the next decade turns on, and we wanted it built properly rather than improvised after the first disaster. The signing-before-execution discipline, the hash-chained append-only structure, the offline verifier, the post-quantum choice, all of it exists because we worked backwards from the question a regulator will one day ask and built the answer first.

The honest caveats, because a security realist owes you them

A signed, verifiable account is necessary. It is not sufficient, and I will not pretend otherwise. The record tells you truthfully what the system decided and under what policy. It does not, by itself, tell you whether the policy was wise. A controller can be perfectly accountable and perfectly wrong, faithfully logging a sequence of decisions that, in aggregate, took the network down. Accountability and correctness are different virtues, and an operator who confuses the two will get a nasty surprise. The record also depends on capturing the right inputs at the moment of decision; garbage faithfully signed is still garbage, just garbage you can prove you produced. And the verifier, the policy definitions, and the model identities all have to be managed with the same rigour as the record itself, or you have built a strong lock on a door with a weak frame.

There is a cultural caveat too. An honest account is uncomfortable, because it removes the ambiguity an operator can hide behind. Some organisations will resist verifiable auditing for precisely that reason, and they will dress the resistance up as concern about cost or complexity. I would rather operators choose this because they understand that the alternative, an opaque autonomous network nobody can hold to account, is a liability that grows every quarter. The regulator is going to take the choice out of their hands soon enough. Better to build the account because it is right than to bolt it on because you were ordered to. And do not mistake my candour about the limits for hedging. The fact that a verifiable record does not solve everything is not a reason to keep running networks that record nothing worth trusting. It is a reason to get the foundation right first and then argue about the rest.

The record is the new licence to operate

Here is where I think this lands. For a century, the licence to run critical infrastructure rested on a basic bargain: you operate the thing, and in return you can answer for it. The water company can show what it did. The power utility can account for the grid. The telecom could put a human on the stand. Autonomy has quietly broken that bargain, because the entity making the decisions can no longer answer for itself, and the humans nominally in charge increasingly cannot either. The verifiable account is how you restore the bargain in a world where the network runs itself. It puts an answerable party back at the centre of an unanswerable system, not by slowing the machine down to human speed, but by making the machine keep a record a human can stand behind.

So when the next significant outage drags an operator into that room with the regulator, the decisive question will not be whether the AI was sophisticated. Everyone's is. It will be whether the operator can produce a true, complete, ordered, tamper-evident, independently checkable account of what the network decided and why, signed before the fact and standing up to scrutiny years later. The operators who can will be inconvenienced. The operators who cannot will be in serious trouble. I built Mickai around the conviction that this question is coming for the whole industry, and that the right answer was never a better dashboard. It was a record you do not have to be trusted to believe.