The Governance Gap Holding Operators Back from Level 4 Autonomy

By Michael Behan, Solution Architect at Zinkworks, with 30+ years at Alcatel, Ericsson and Dell Technologies and an active contributor to the O-RAN Alliance and AI-RAN Alliance

Over the past few years Zinkworks engineers have worked inside the RAN operations of large European operators and operator groups. They all want a higher level of network autonomy, because it lets them introduce new services faster and improve quality of service at a pace that manual operations cannot match.

Their problem is also consistent. RAN engineers each look after hundreds of nodes and know where AI would help, for example in anomaly detection, energy management and QoS prediction. What they lack is a fast way to turn an idea into automation running on the network. A new rApp or SON application typically takes months of specialist handoffs, vendor dependencies, integration, testing and packaging, and by the time it is live the problem it was built for has often changed.

This has three consequences. The speed of automation is set by suppliers rather than by the operator’s own engineers. AI stays in isolated use cases, because each use case is a separate project. Operators also lack a benchmark or evaluation method for how an automated system behaves, which makes trust in it hard to measure.

What Changes Between Level 3 and Level 4

TM Forum’s Autonomous Networks levels, and the matching definitions in 3GPP TS 28.100, run from Level 0 (fully manual) to Level 5 (fully autonomous). At Level 3 the system performs all execution and awareness tasks and shares analysis and decision-making with people, who define the control information it works from. At Level 4 the system performs analysis and decision-making itself, and people and the system start to share the handling of intent. In practice a person no longer approves each action, because a policy does, and that changes who is accountable for a decision on a live network.

The figures show how far the industry has to go. TM Forum’s latest survey found 21% of respondents operating at Level 3 or above, up from 19% a year earlier, and at DTW Ignite in June TM Forum reported 40 validations awarded to 17 operators and found that 81% of operators are aiming for Level 4 or above by 2030. The Level 4 validations so far cover selected scenarios within a single domain, such as energy saving or fault management. TM Forum’s CTO, George Glass, has put the industry average at between about 1.5 and 2.1 and has warned: “If you leave your legacy and just start putting agents on top, you will not get to level four.”

Five Problems that Make the Gap Wide

1. Level 3 closed loops are narrow by design. An rApp or SON function optimises the KPIs it was built to monitor and only detects problems in the measurements it uses, so a QoS rApp can meet every throughput target while premium customers complain about latency that was never one of its inputs.
2. Level 4 needs context from outside the network. Subscriber tiers, SLA definitions, trouble tickets and planned works are held in BSS, CRM and ITSM systems, and deciding whether an anomaly matters means reasoning across those sources and across network domains.
3. Intent is hard to translate. “Premium fixed wireless customers must keep their guaranteed experience at evening peak” is a clear business objective, but turning it into target cells, thresholds and priority weights, and then proving that the objective was met, is skilled work for optimisation engineers today.
4. Accountability has to be designed in. When a system makes a decision, the operator still needs to know who or what approved each change, why it was made and how to reverse it. Stefan Pongratz of Dell’Oro described the move to Level 4 as “as much a human challenge as a technical one”, and operators are right to be cautious about handing control of critical national infrastructure to software.
5. The technology best suited to the reasoning brings new risks. Agents built on large language models handle contextual, multi-source reasoning well, but they are probabilistic, and OWASP’s Top 10 for Agentic Applications lists tool misuse, goal hijacking and cascading failures among the main risks of agentic systems. Giving an agent direct write access to network functions would close one gap and open another.

The gap between Level 3 and Level 4 is therefore a governance problem as well as a capability problem. It is about who is allowed to act, through which path, under which policy and with what record.

Why this is Urgent

In July the RAN Intelligence and Automation subgroup of TIP’s OpenRAN Project Group published a white paper on SMO evolution and agentic AI. It states the objective as “governed autonomy: greater operational speed and coordination without removing accountability or control”, and it argues that agentic AI should be considered during the 6G study phase rather than added afterwards. That study work is under way now, so an operator that wants Level 4 operations, with a credible path to Level 5, needs to start building the governance layer before the next vendor release rather than after it.

Earning Autonomy in Stages

Our view, based on work with operators on live networks, is that autonomy should be added in stages. Each increase in what the system may decide needs a matching increase in the controls around it: the policy that limits it, the path it may act through and the audit record that lets a person replay what happened.

Operators can start benefiting before they reach a fully autonomous network. They need a starting point that matches their current maturity and a path that keeps what they build along the way.

In the next article, James McNamara describes that path: five tiers of use case, from observe and explain to evolving the automation itself, with the controls each tier needs.

Zinkworks is at FYUZ 2026 in Seattle on 3–5 November, at booth #14. If you are working on the same step, come and talk to the engineers who built rApp Studio.