Telecom AI Needs Data Curation Before Network Autonomy

The hidden prerequisite for autonomous networks

Telecom operators pursuing autonomous networks face a problem that precedes the technology itself: their operational data is a mess. Logs, tickets, inventories, and configuration histories exist in dozens of formats across systems built in different eras for different purposes. Some sources contradict each other. Documentation lags behind production reality. Critical operational knowledge remains undocumented in engineers' heads.

This fragmented foundation creates a fundamental challenge for AI systems. Retrieval-augmented generation can fetch documents, but retrieval isn't understanding. When underlying data is inconsistent or stale, AI may return plausible answers that aren't operationally useful—or worse, confidently connect things that shouldn't be connected while missing relationships experienced engineers know matter.

AI strategist Alan Nekhom, writing in Fierce Network, argues the industry has the sequence wrong. "The first job isn't teaching AI to run the network," he writes. "It's teaching AI what the network means."

Why it matters

The push toward autonomous networks assumes AI can safely act on operational data. But if that data reflects conflicting versions of network reality, automation becomes a production risk rather than an efficiency gain. Operators who skip data curation work don't eliminate the cost—they convert it into customer-impacting failures when AI systems act on unreliable information.

Curation as engineering work

Nekhom describes using AI to accelerate data cleanup: comparing conflicting sources, normalizing formats, identifying missing relationships, and surfacing inconsistencies. But AI doesn't get final authority. Engineers must test interpretations, challenge initial answers, and validate what becomes operational context.

This curation work is engineering, not clerical cleanup. Someone must decide which sources deserve authority, which exceptions matter, and which relationships need to survive into the operational context AI will use later. The work includes reconciling conflicting alarm names, inventory fields, local exceptions, and legacy documents before AI can treat the material as reliable.

Operational context also decays as networks change and documentation falls behind. Curation isn't a one-time project but ongoing maintenance—work that's slow, expensive, and organizationally unglamorous.

From recommendation to execution

Once operators establish validated context, the next question becomes authority boundaries. Nekhom distinguishes between AI that summarizes alarms for engineers and AI that changes network behavior. The former can mislead an operator; the latter can affect customers.

He suggests telecom will need a new function—whether formally titled or not—that he calls the autonomy assurance engineer. This role defines what AI systems can know, recommend, change, and when they must stop for human judgment. The engineer sets boundaries based on customer impact, evidence quality, and rollback paths.

Nekhom points to Telstra's automation strategy as an example where engineers still set policy, handle exceptions, and evaluate customer impact even as automation removes operational drag.

Edge AI complicates assurance

Moving intelligence to the edge makes assurance harder. Cameras, sensors, gateways, and industrial systems now send events and telemetry upstream. Decisions may move across devices, edge infrastructure, regional cloud, central cloud, and human operations teams. The network becomes a coordination layer for distributed intelligence, and assurance must follow decisions closer to where they're made.

Authority over hallucination

Nekhom argues the real risk isn't that AI may be wrong—it's that wrong answers may have authority to act. Operators need guardrails defining the boundary between recommendation and execution, evidence required before action, escalation points for customer risk, and rollback paths when systems fail. These boundaries will vary by service, customer impact, failure mode, and regulatory exposure.

"The point isn't to build a network where humans disappear," Nekhom writes. "It's to remove repetitive work while preserving human judgment wherever risk, resilience and customer impact are at stake."

The analysis was first reported by Alan Nekhom in Fierce Network.