In the telecom projects I’m working on now, the most important network conversation has not started with autonomous networks.
It started with bad data.
Not useless data. Telecom is full of data. Logs, tickets, inventories, specifications, network events, customer records, monitoring feeds, configuration histories and documentation are everywhere. The problem is that much of it was created for different systems, different teams, different eras and different operational purposes.
Some of it is modern telemetry. Some of it is trapped in systems built for another time. Last week, I found a scanned document in one of our databases that looked old enough to have been written by Alexander Graham Bell. That’s funny until you realize this is part of the same operational history we now expect AI systems to interpret.
In real projects, the mess shows up quickly. Log files arrive in dozens of formats. Databases do not quite agree. Documentation lags production. Specifications describe how something was supposed to work, but not always how it behaves now. Tribal knowledge sits in people’s heads because no system captured the operational nuance.
This is where many AI efforts struggle.
A simple RAG system can fetch documents, but retrieval isn’t understanding. If the underlying domain is fragmented, inconsistent or stale, the AI may return something plausible without being operationally useful. Worse, it may confidently connect things that shouldn’t be connected, or miss relationships that every experienced engineer knows matter.
The first job isn’t teaching AI to run the network. It’s teaching AI what the network means. That may become the real bottleneck in autonomous networks: not whether AI can act, but whether operators know which version of network reality the AI is acting on.
We’ve been using AI to help curate the mess: compare conflicting sources, normalize formats, identify missing relationships, surface inconsistencies and accelerate the cleanup work that engineers often do manually. AI doesn’t get the final vote. Engineers have to test the interpretation, challenge the first plausible answer and decide what becomes validated operational context.
An AI system can’t safely recommend remediation, adjust a service or act on a live network without a domain it can reason over. Operators need confidence in the data, definitions, constraints and relationships before they allow the system to act on its own.
Making the domain legible
The industry wants to talk about autonomy. The first serious engineering shift is curation.
AI can speed the cleanup, but speed isn’t the same as operational confidence. The industry needs to change the sequence: curation before autonomy.
Someone must decide which sources deserve authority, which exceptions matter and which relationships need to survive into the operational context AI will use later.
That’s engineering work, not clerical cleanup. It’s how operators build the context AI needs before it can support serious network decisions.
In practice, that means creating a reviewed map between systems that were never designed to agree. Engineers need to reconcile conflicting alarm names, inventory fields, local exceptions and legacy documents before AI can treat the material as operational context. Sometimes the right answer is that the evidence isn’t good enough yet. Retrieval can surface the pieces, but domain curation is what makes them usable for network reasoning.
And the work doesn’t end once the map is built. Operational context decays as networks change, documentation falls behind and exceptions become routine practice.
This is the part autonomy programs tend to understate. Curation is slow, expensive and organizationally unglamorous. No one wants to tell the board that the autonomous network roadmap depends on reconciling alarm taxonomies, cleaning up stale documentation and deciding which system of record is actually telling the truth. But skipping that work doesn’t remove the cost. It moves the cost into production risk.
Speed isn’t evidence
AI makes the work faster, but it also changes the failure mode. A clean answer can move a team past uncertainty before the evidence deserves that confidence.
Engineers still have to slow the answer down. They must test competing explanations, look for contradictions and decide whether the evidence is strong enough to become part of the operational context. AI can accelerate that work, but it mustn’t be allowed to launder uncertainty into confidence.
There’s a major difference between an AI assistant that summarizes alarms for an engineer and an AI agent that changes network behavior.
Summarizing alarms can mislead an operator. Changing network behavior can affect customers.
My teams are moving in that direction: AI accelerates the messy work of domain curation, while human judgment decides what is reliable enough to use.
Once the domain is strong enough to support decisions, the question changes: How much authority should this system have?
Telecom has never treated confidence as binary. An AI system may be useful as an observer or advisor long before it is safe as an operator. Execution should come later, inside defined boundaries, with rollback conditions, audit trails and human escalation when the risk exceeds the operating boundary.
The autonomy assurance engineer
Recent coverage on Fierce Network of Telstra’s automation strategy underscored the point. The interesting part isn’t only that automation can remove operational drag. It’s that engineers still have to set policy, handle exceptions and evaluate customer impact.
Some operators may spread that responsibility across existing engineering, automation, reliability and governance roles. That may work for early automation, but it becomes harder as systems gain permission to act. At that point, telecom will need the function whether or not it adopts the title: the autonomy assurance engineer.
Rather than owning every tool, this engineer defines the system’s authority: what it can know, what it can recommend, what it can change, when it must stop and when a human must enter the loop.
On a practical day, that may mean deciding whether an AI system can close a low-risk ticket automatically, recommend a configuration change for engineering approval, or stop entirely because the customer impact, evidence quality or rollback path isn’t clear enough.
The engineer’s job doesn’t shrink. It moves to the judgment calls the system can’t safely make for itself.
Edge AI raises the stakes
Moving intelligence closer to the edge makes the assurance problem harder.
Low-latency 5G makes more edge AI use cases practical, but latency is only one part of readiness. Cameras, sensors, gateways, meters, vehicles and industrial systems are no longer just receiving intelligence from the cloud. They are sending events, telemetry and exceptions upstream.
Orchestration becomes harder too. Decisions may move across the device, the edge, regional cloud, central cloud and human operations teams. Edge AI turns the network from a transport layer into a coordination layer for intelligence and assurance must move closer to the decisions.
The risk isn’t only hallucination - It’s authority
A lot of AI conversations focus on hallucinations. That concern is real, but telecom has a sharper version of the problem.
The danger isn’t simply that AI may be wrong. It is that the wrong answer may have authority.
In telecom, guardrails are not just about what the system says. They are about what the system is allowed to do.
Operators need to define the boundary between recommendation and execution, the evidence required before action, the escalation point for customer risk and the rollback path when the system gets it wrong. The hard part is that these boundaries won’t be universal. They will vary by service, customer impact, failure mode, regulatory exposure and the operator’s confidence in the underlying data.
At that point, governance stops being a policy exercise and becomes part of network engineering.
The point isn’t to build a network where humans disappear. It’s to remove repetitive work while preserving human judgment wherever risk, resilience and customer impact are at stake.
That judgment needs to move upstream, into the operational context, evidence standards and boundaries that determine when autonomous systems can proceed.
Autonomous networks must start with validated context before they are allowed to act on their own. The next great telecom job starts there: making messy operational reality legible enough for AI to reason over, then defining when the evidence is strong enough to let the system act.
Before networks can run themselves, engineers have to teach AI what the network means, what authority it has and where that authority ends.
Alan V. Nekhom is an AI strategist, cloud and compliance executive, and technology architect with decades of experience across telecom, data, and enterprise systems. He advises organizations on AI adoption, operational resilience, and responsible decision-making in complex, high-consequence environments.
Opinion pieces from industry experts, analysts or our editorial staff do not represent the opinions of Fierce Network.