AI Adoption Maturity Stages for Telecom Operators
Legacy OSS architecture, not AI models, determines how far telecom operators can advance.
Every telecom operator will tell you AI is a priority. That shared conviction hides a much wider spread in what operators can actually do with it. The HTEC State of AI in Telecommunications 2025-2026 report, based on 255 C-level telecom executives, found that more than half of surveyed organizations remain in fragmented stages: limited deployments, pilots, or early exploration, with no clear path past that point. The spread is not random. It clusters into bands that a technical leader can name and locate on, and that clustering is what makes a maturity model useful: it is a diagnostic for what is blocking an operator's progress, not a league table for ranking one operator against another. Read correctly, the question an operator should ask is not "are we behind," but "what specifically is stopping us from moving to the next stage."
The TM Forum Autonomous Network Levels and Why Most Operators Are Stuck Below Level 3
TM Forum's autonomous network levels give the industry a shared yardstick for this progression, and the distribution along that yardstick is skewed hard toward the bottom. The levels do not grade how advanced an operator's AI models are. None of those three problems is a modeling problem. All three point back to the same place: the systems that store and move the data the AI needs to act on.
Legacy OSS Architecture as the Binding Constraint at Every Stage of the Maturity Curve
The architecture underneath an operator sets the ceiling on what stage it can reach, not its AI budget or its model choice. That separation was manageable when a person reviewed every transaction by hand. AI responds poorly: when the inputs it draws on are inconsistent or arrive late, it produces recommendations that cannot be trusted, or it fails. An agent that pulls from both without reconciling the two speeds ends up acting on whichever timestamp happens to be newer, not the one that reflects reality. Multi-vendor inheritance makes the problem worse. Operators often run several OSS stacks next to BSS layers picked up through acquisitions, not chosen on purpose, and you cannot just reverse the integration debt that results. Procurement is already responding to this. Buyers increasingly judge AI platforms on how well they fit existing OSS/BSS environments, whether their AI functions can be explained, and whether they produce measurable operational savings, and the market for single, isolated AI applications is giving way to demand for platforms built to work across several operational domains on one shared analytics architecture.
The four practical stages telecom operators move through as AI capability matures
The stage an operator occupies is set by what its architecture can support, not by which AI models it has bought. An operator running capable models on top of fragmented data is still at Stage 1, whatever its vendor contracts say.
Stage 1 is isolated pilots: AI pointed at one bounded problem, such as fraud detection, a customer service chatbot, or a network fault prediction model, with no data integration linking it to anything else. Most mid-sized operators begin here.
Stage 2 is domain automation: AI now runs inside one domain, whether that is network operations, customer care, or provisioning, and closed-loop automation can work within that domain's boundaries. A person or a batch job still has to carry the handoff to any adjacent domain. The constraint that holds operators at this stage is the same timing mismatch described above: real-time network telemetry and batch-cycle billing do not line up, so an agent trying to act across both ends up unreliable.
Stage 3 is connected workflows with governed handoffs: AI agents now operate across domains, with qualification feeding design, provisioning triggering activation, and network events updating billing, all running on shared data with human approval built in at defined checkpoints. The constraint here is subtler than it looks. Without a genuinely unified data model, "connected" really means "synchronized," and synchronization introduces its own lag and its own conflicts between systems that each think they hold the current state.
Operators often misjudge their own position on this ladder. An operator with cross-domain dashboards may think it has reached Stage 3, but if its agents cannot act across domains without a person re-entering data by hand, it is still at Stage 2. To move from Stage 2 to Stage 3, you need data unification and governance infrastructure, not a sharper model. Moving from Stage 3 to Stage 4 takes that governance to be built into the architecture itself, not run as a procedure layered on top of it.
What Separates AI-Native OSS from AI-Augmented OSS
An AI-augmented stack adds intelligence on top of systems that were not built for it. The AI agents call interfaces built alongside the production system rather than the same interfaces human operators already use, so every handoff between agent and system crosses a seam, and that seam introduces translation, lag, and the chance of inconsistency creeping in. This is a legitimate place to start, and a great many operators are there today, but it carries a cost that compounds quietly. Capital spent layering AI tooling onto a legacy platform turns, over time, into an organizational case for keeping that platform around. AI agents can end up raising the switching cost of the incumbent OSS and BSS they were meant to work around, so augmentation can end up entrenching the very systems it was supposed to supplement.
An AI-native platform takes a different starting point: qualification, design, provisioning, and activation all run on one underlying data model. An AI agent in that environment carries the complete state of a service because there was never a seam between those functions at the data layer to begin with, not because the data has been synchronized across several systems. The chain changes outcomes concretely in FTTH, dedicated internet, and Carrier Ethernet environments. You need an OSS built to consume those APIs directly, so you can act on them without manual steps in between. An AI-augmented system, by its nature, reinserts those manual steps at every handoff, no matter how good the external standard is.
Tekonyx President Sid Nag describes the logical endpoint of AI-native architecture as one where OSS/BSS systems become "a sort of executive back end while the real control plane moves to an AI agentic-driven orchestration engine." That description is a picture of Stage 4, and it is only reachable if the data model was unified from the start. Augmented stacks are not a mistake, but they carry a structural ceiling that only a change in architecture, not a better model, raises.
Governance as an Architectural Requirement at Stage 3 and Above
Governance for autonomous agents lags badly behind deployment. Only one in five companies has a mature model for governing autonomous AI agents, even as agentic AI moves into customer care, provisioning, and network operations faster than sector frameworks can keep pace with, according to Deloitte's State of AI in the Enterprise survey. Most existing telecom compliance frameworks assume a person reads a screen before anything happens: before data moves, before a provisioning action fires, before a network change gets committed. An agent that chains tool calls across provisioning, billing, customer, and network-management systems within milliseconds breaks that assumption.
Regulators are tightening the requirement. Singapore's Infocomm Media Development Authority launched, in January 2026, the first governance framework written specifically for autonomous AI agents. Both are signals that compliance built around human review does not reach an operation where agents, not people, are making the moment-to-moment decisions.
A single question during OSS evaluation tests an operator's governance: are AI agent actions captured in the same audit log as human operator actions? Most legacy stacks cannot answer yes to that question today. The Analysys Mason Telco AI Readiness Index 2026 calls for investing in "a new wave of AI-specific data transformation, model-ready datasets, common data models and unified platforms across domains" as a decisive next step for operators, and that instruction applies equally to governing the data plane and governing the agent plane. The audit-log gap and the agent-governance gap are the same problem at two different layers of the stack.
The unified data model as the foundation that makes Stage 3 and Stage 4 operationally possible for fiber, DIA, and Carrier Ethernet operators
For FTTH, dedicated internet, and Carrier Ethernet operators, the chain from qualification through design, provisioning, and activation is an operational requirement with real consequences when it breaks. The activation event has to trigger billing automatically, and the network resource records involved need to be accurate the moment they are created during design, not corrected after the fact, because an error that enters at qualification travels through every downstream step and gets worse by the time it reaches activation.
If the data plane is not unified, any insight an AI agent produces inherits whatever inconsistencies already exist in the source systems it draws from. Engineers at Telstra and Amdocs are currently debating an ontology for the industry, and that debate frames a standardized knowledge plane as the "ultimate driver" for reaching higher levels of network autonomy. It also names the specific failure that occurs when the data plane is fragmented: "agent drift," where different agents interpret the same business logic in different ways, because each is reading from a slightly different version of the truth.
TM Forum's Open Digital Architecture, together with its Information Framework (SID), gives the industry a shared reference, so it can solve this at scale. Adopting them reduces vendor lock-in, simplifies data exchange between systems that different companies built, and lets AI and analytics tools work across an environment that is genuinely mixed. These standards exist because the fragmentation problem is an industry-wide one, not a one-operator problem. The Analysys Mason Telco AI Readiness Index 2026 reinforces this at the level of strategy, naming the treatment of open network transformation and AI readiness as a single, unified strategy, because the two are inseparable, as one of its explicit calls to action for operators planning both at once.
How Operators Advance Between Stages Without a Full Rip-and-Replace
The accepted modernization path does not ask you to freeze operations for years and rebuild from scratch. If operators layer event-driven infrastructure over what already exists, using a data streaming platform to modernize the OSS piece by piece, they can cut time-to-market and move toward real-time operations without a full replacement cycle. Apache Kafka and Flink are a specific, proven technology pattern for doing exactly this.
Legacy OSS/BSS environments carry real structural costs: provisioning cycles that run weeks or months, billing systems driven by batch jobs, and data architectures split into silos. Cloud-native migration addresses all three. The Analysys Mason Telco AI Readiness Index 2026 notes that operators who build open, AI-ready infrastructure from scratch can move faster, because they align both from the start and skip the integration debt that earlier movers had to work through. That does not leave brownfield operators stuck: the same index notes that deliberate architectural investment lets them close the gap.
For a brownfield operator, the sequence matters. If you move toward API standards aligned with MEF Lifecycle Service Orchestration or TM Forum ODA, you can add new capability without another round of custom point-to-point integration.
One risk sits specifically with private cloud deployments. The Analysys Mason index says operators need to close the operational capability gap in private clouds if they want to fully capitalize on sovereign AI infrastructure investments. Deploying private cloud AI infrastructure without the operational tooling to run it fails to capture the value that infrastructure was bought for.
A Self-Assessment Checklist for a Stage 4 Operation
Stage 4 is not a telecom operation with the people removed from it. It is one where human operators and AI agents work inside the same governed, transparent system, sharing the same APIs, the same audit logs, and the same permission structures, with AI handling whatever closed-loop automation can handle and human operators keeping authority at the specific points where policy, risk, or judgment genuinely require a person.
For a fiber, DIA, or Carrier Ethernet operator, that operation has a recognizable signature. Every agent action along that chain is logged with the same detail as a human operator's action would be: who initiated it, what changed, and what the state was before and after. That audit log can be queried in real time, not reconstructed after an incident from several separate system logs that do not agree with each other.
Before an operator claims Stage 3 or Stage 4, you can ask a short set of questions to surface the actual gap. Can an AI agent complete a provisioning action through the same API a human operator uses, or does it call a separate interface built just for it? Are agent actions recorded in the same audit log as human actions, or do they sit in a separate system that someone has to reconcile by hand? Does a qualification record carry through to activation as one single object, or does it get re-created or re-synchronized at each stage along the way? If an agent made an incorrect provisioning decision last Tuesday, can the exact data it acted on, and the reason it acted that way, be reconstructed within five minutes? Do the AI agents running network operations, provisioning, and billing share one definition of "subscriber," "service," and "account," or does each system run on its own schema?
The Analysys Mason Telco AI Readiness Index 2026 names the choice of partners as one of its calls to action, recommending operators choose partners who span technology, operations, and commercial strategy rather than single point solutions, because the integration surface at Stage 4 is too wide for any one vendor working in a single domain to cover on its own. The questions above are simple to ask. The honest answers are often uncomfortable, but they are what make the questions worth asking.
