AI in Telecom: Where It Helps, Where It Does Not, and Why
Telecom has been automating networks for thirty years. What changed is not that networks became automated, but that some decisions became too high-dimensional for anyone to write the rules by hand.
Telecom has an unusually long history of automation, and an unusually short memory of it. Self-organising networks were doing automatic neighbour relations and load balancing well before anyone described a network as intelligent, and much of what is now presented as AI is a rebranding of control loops that have been running for years.
That is worth saying up front, because it sets the right question. It is not whether networks should be automated — they already are. It is which decisions have outgrown the rules people can write by hand, and what to do about those.
Where rules stop working
A rule is the right answer when the decision depends on a small number of variables with a stable relationship. Shut down the capacity cell when its load stays below a threshold for a set period. Trigger the handover when the neighbour's reference signal power exceeds the serving cell's by an offset. These are legible, testable and easy to defend when something goes wrong.
They break when the relationship stops being stable. The threshold that saves energy on a Tuesday night strands users on a Saturday afternoon. The offset that works downtown ping-pongs devices on a motorway. Each individual fix is easy; the problem is that there are thousands of cells, each wanting a slightly different answer, changing with the season.
That is the regime where learning earns its keep — not because it is more sophisticated, but because the function being approximated has too many inputs to write down. AI-RAN works through this with concrete examples of where the crossover actually sits.
The three places AI lands in a network
Prediction
The most mature category, and the least glamorous. Traffic forecasting, mobility prediction, failure prediction from degradation trends. These have abundant historical data, tolerate occasional errors gracefully, and produce a number that feeds an existing control loop rather than replacing it. Most production machine learning in mobile networks today is here.
Optimisation
Choosing configurations across a space too large to search by hand — beam patterns, scheduling weights, energy-saving policies that respect coverage constraints. Higher value, and considerably harder, because the feedback loop runs through the live network. This is where the question of where to evaluate a policy before deploying it becomes pressing.
Comprehension
The newest category and the one generative models opened. Operations generates enormous quantities of text — alarms, tickets, change records, vendor documentation, configuration dumps — in formats that do not agree with each other. Generative AI in network operations covers where language models genuinely help here, and the specific failure mode that makes them dangerous: fluent output is trusted more than it has earned.
Designing for it rather than around it
There is a real difference between a network that accommodates machine learning and one designed on the assumption of it. In 5G, most of what limits learned components is not model quality but access — to data at the right granularity, through interfaces that expose the right state, on a timescale where a decision still matters.
AI-native networks is about closing that gap by design: making the data pipeline, the model lifecycle and the interfaces that carry model outputs part of the architecture rather than something bolted on afterwards. It is the main thread connecting this section to the 6G material, where the same argument appears as a design principle for the next system.
The evaluation problem
Every proposal to let a learned policy control something real runs into the same objection: where do you try it first? A model that has never seen a configuration cannot be trusted with it, and the live network is a poor place to find out.
Digital twins in telecom is the honest treatment of the usual answer. A twin is genuinely useful for testing policy against scenarios you can construct deliberately — the ones that are rare in production and therefore absent from training data. It is also only as good as its models, and the fidelity trade-off between a twin fast enough to be useful and one accurate enough to be trusted is the whole engineering problem.
Where the control logic runs
Any of this needs somewhere to execute with access to the network state. In practice that increasingly means the RIC, which is why this section and Open RAN keep meeting: the near-real-time and non-real-time controllers are the most concrete answer available to where a learned policy would run, what it can see, and what it is permitted to change.
How to read this section
Start with AI-RAN if you want the concrete engineering case, or with generative AI in operations if your interest is the operational side. AI-native networks is the architectural argument and reads well after either. Digital twins fits naturally last, since it is mostly about how you would ever validate the rest.
None of it requires a machine learning background. The articles are written for network engineers, and the modelling is explained where it matters rather than assumed.
Frequently asked questions
Has AI actually improved mobile networks, or is it mostly marketing?
Both, in different places. Traffic forecasting, anomaly detection, energy-saving cell shutdown and configuration audit are areas where learned models measurably beat hand-written rules and are deployed at scale today. Claims about end-to-end autonomous networks are, so far, mostly aspiration. The useful discriminator is whether the problem has abundant labelled data and a tolerance for occasional wrong answers.
Why not just use rules? They are predictable and auditable.
For many problems you should, and operators still do. Rules fail when the decision depends on many interacting variables whose relationship shifts with traffic, season and deployment — the point at which a threshold that is correct on Tuesday is wrong on Saturday. That is the regime where learning earns its complexity. Below it, a threshold is cheaper, faster and far easier to defend after an incident.
What does AI-RAN mean, and how is it different from using AI in the RAN?
Using AI in the RAN means applying models to a network designed without them, working through whatever the existing interfaces expose. AI-RAN describes designing the radio access network around learned components — sharing compute between AI workloads and signal processing, and treating model inference as a first-class part of the pipeline rather than an add-on. The distinction is architectural, not a difference in model quality.
Where does generative AI genuinely fit in network operations?
In the places where the bottleneck is human comprehension rather than machine decision: summarising incidents across systems that do not share a schema, drafting configuration changes for a human to review, answering questions about documentation nobody has read in years. It fits poorly wherever an answer must be provably correct, because a fluent wrong answer is more dangerous in operations than an obvious one.
What is the hardest part of deploying machine learning in a live network?
Not the model. It is the data pipeline and the lifecycle around it — getting consistent labelled data out of a multi-vendor estate, detecting when a model has drifted because the network changed underneath it, and having somewhere safe to evaluate a new policy. That last problem is most of the argument for digital twins.
Will AI replace network engineers?
It has been steadily replacing specific tasks for a decade — manual parameter tuning, first -line alarm triage — and creating others, particularly around data quality, model evaluation and deciding what a system is allowed to do unsupervised. The judgement about what should be automated has not become less valuable. If anything it is the scarcer skill.