Change Management Practices in Telecom OSS Environments

Change management in telecom OSS depends on one question: can every configuration change, regardless of who or what initiated it, be traced to an actor, an authorization, and a timestamp. The answer for most operators today is no, and the reason is that AI agents have become active participants in OSS workflows without inheriting the governance structure built for human operators.

Structural drivers of harder change management in telecom OSS

For decades, change control in OSS rested on one quiet assumption: every configuration change had a human author who could be found, questioned, and held to account. That assumption is gone. AI agents now detect faults, reroute traffic, restart failing elements, and trigger remediation steps across the network, and when they act without the same governance structure applied to human operators, the accountability chain simply breaks. Amdocs framed this shift at MWC 2026 through its aOS architecture: the relevant question is no longer whether AI can assist with a task, but how it coordinates end-to-end execution across business, IT, and network domains, with governance and human oversight built into that coordination rather than added afterward.

Data in most OSS environments still sits scattered across network domains, OSS and BSS platforms, customer care, billing, and field operations, often with inconsistent definitions and unclear ownership. If you make an automated change against that fragmented picture, it can act on stale or incomplete state even when the agent behind it works exactly as designed.

Operators have a fair objection here: change management is not new, and AI is one more system to bring under an existing process. The answer is a matter of scale and speed. AI agents act across multiple domains at machine speed, so if a governance gap would cause one bad change from one person, it instead multiplies into many simultaneous changes, and no review cycle can catch them fast enough. That difference in scale is what makes the old assumptions insufficient, not any claim that AI itself is unusually dangerous.

Requirements for governed change across AI and human workflows

Governed change means every actor, human or automated, works under the same permission structure, the same audit trail, and the same approval thresholds. That is an operational requirement, not a philosophical stance: if an AI agent can modify a live configuration through any path that bypasses the change control system, the change control system is not actually controlling anything.

What this looks like in production is specific. Agents today operate under guardrails that separate low-risk, reversible actions from high-impact ones. Changing radio parameters, modifying a live configuration, or initiating site-level maintenance still requires explicit human sign-off, while customer-facing workflows let agents resolve routine issues on their own; billing, identity, and policy-sensitive actions stay under human control throughout reference pattern. The mechanism that holds this tiering in place is intent-based orchestration: a deterministic, model-driven layer that keeps automation predictable and auditable even as the system's intelligence and flexibility grow.

HCLTech's 2026 telecom trends analysis makes a point worth sitting beside this: guardrails for agentic AI cannot be generic. They need to be built for the specific use case, governed by the data they touch, and contained within the system they operate in. That requirement spans several layers at once: a risk management framework such as NIST's AI RMF, a certifiable management system standard such as ISO/IEC 42001, published in December 2023, and the telecom sector's own shared framework, the GSMA Responsible AI Maturity Roadmap, launched in September 2024 with 19 mobile network operators committed at launch. At the industry level, TM Forum used MWC 2026 to launch the first three projects under its AI-Native Blueprint, Model as a Service, Data Products Lifecycle Management, and Agentic Interactions Security, aimed squarely at moving operators out of isolated pilots and into trusted, production-scale operations.

The distance between that standard and where most operators actually sit is wide. Only one in five companies has a mature model for governing autonomous AI agents, even as agentic AI use is set to climb sharply, and that figure lines up with TM Forum's separate finding that only 19% of communications service providers have embedded AI successfully in more than three OSS or network functions.

Why legacy OSS architectures cannot enforce consistent governance

Legacy OSS platforms were built around the idea that a human operator sits behind every action, and that assumption is load-bearing. It cannot be patched by bolting an AI module onto the side. Legacy OSS treats AI as an add-on analytic layer sitting outside the system of record, while AI-native systems treat AI as part of how the stack executes changes in the first place, making these categorically different architectures, not points on the same maturity scale.

AI agents need event-driven access to data and a consistent view of network state, but legacy systems were not built to give them either. When data stays siloed across domains, with different definitions in each silo, an agent operating across those boundaries runs into different representations of what is supposed to be the same underlying network, and that fragmentation is what makes change control unreliable in practice. Research from the World Economic Forum and TM Forum, cited in HCLTech's Telecom Trends 2026 analysis, places 2025 and 2026 as the years autonomous networks moved from pilot projects to operational priority, and that shift is exposing exactly where systems built for a human-only operating model run out of road.

TM Forum has been direct about where the limit sits: inconsistent processes and inconsistent data are constraints that an agentic layer cannot paper over. Adding agents on top of a fragmented data model does not fix the fragmentation, it inherits every contradiction already built into it.

You see the sharpest version of this problem when an AI agent's actions run through an execution path that the change management system never sees. In that case there is no audit trail, no rollback anchor, and no way to attribute what happened to anyone, a condition best described as shadow automation. Greenfield operators sidestep this problem entirely when they build AI-native foundations from the ground up, because then there is no legacy path left ungoverned. Established operators face a harder choice, carrying years of accumulated tooling and process, but the architectural decision still has to be made rather than deferred.

How a unified data model makes change governance enforceable

A unified data model is the condition that makes it possible to apply one governance rule consistently across every phase of service delivery, from qualification through design, provisioning, and activation. Without it, the same physical network resource can appear differently in the qualification system, the design tool, the provisioning engine, and the activation record, so a change approved in one phase can execute inconsistently in another with no system positioned to notice the divergence.

The operational result of that divergence is configuration drift: the live network moves away from the design state it was supposed to match, and the OSS loses its claim to being the authoritative record of what has actually been provisioned. Research from the i2CAT Foundation on AI-native orchestration across the 6G continuum arrives at the same requirement from the network architecture side: autonomous orchestration across distributed domains depends on an orchestration layer that maintains persistent service context and supports closed-loop control, and both of those depend on a shared, consistent data layer underneath.

TM Forum backed this at DTW Ignite 2026, when its members introduced AI-native extensions to the Open Digital Architecture and added a governed execution layer for AI agents inside the existing framework rather than outside it. The stated goal is a standardized, executable reference framework, so operators can move past fragmented pilots toward something that functions as an autonomous enterprise.

The clearest illustration of what this means day to day comes from fiber and Carrier Ethernet provisioning. When an order is placed, the platform generates a provisioning profile that includes VLAN assignments, speed parameters, voice settings, and subscriber-specific customizations, tied to a specific device serial number. If the qualification record and the provisioning profile disagree on any of those details, because they live in separate data stores with separate definitions, the result is a misconfigured activation, and the change management system built on a fragmented model may never catch it. A unified data model closes exactly that gap, because qualification, design, provisioning, and activation all read from and write to the same authoritative record rather than four approximations of it.

Change control practices when AI agents operate within the same governed system as human operators

When AI agents and human operators work through the same APIs, the same audit logs, and the same permission structures, the system itself enforces change management as a continuous discipline rather than a periodic review exercise. Every change, whether a person or an agent initiated it, runs through the same approval workflow, lands in the same audit trail, and carries the same rollback capability. If the actor is human or automated, that does not create a separate governance tier.

The tiering of autonomy that production systems use today follows a consistent logic. Agents can act without waiting for approval on changes that are low-impact and reversible: detecting a fault, rerouting traffic, restarting a failing element. Anything impactful or hard to reverse, changing a radio parameter, modifying a live configuration, scheduling site-level maintenance, still requires a human to sign off. That split has to be built into the system's permission layer directly, rather than left to informal team convention, because a convention can be skipped under pressure and a permission layer cannot.

This same structure extends naturally into compliance. AI-driven compliance automation can monitor workflows and configurations continuously against regulatory requirements, flag deviations before they turn into violations, and generate audit-ready documentation as a byproduct of normal operation. That turns compliance from a labor-heavy periodic cycle into something closer to a running system function.

Amdocs' aOS architecture offers a concrete, production-scale example of what this looks like in practice: an agentic operating system that coordinates AI agents and workflows across BSS, OSS, and network domains, with governance and human oversight designed into the system from the start rather than layered on after deployment. Optinet's architecture follows the same underlying principle: AI agents there operate on the same APIs, audit trails, and permission structures as human operators. AI is held to the same accountability standard as the people it works alongside, rather than running as a separate, less visible system beside the human-facing one.

The next challenge sits past any single operator's deployment. Once many intelligent systems are participating in change decisions at the same time, the governance framework has to specify how those systems resolve conflicts with each other, and that coordination problem is the one TM Forum and the broader standards community have identified as the next architectural question for AI-native operations.

Evaluating change management posture against these requirements

A service provider's change management posture is only as strong as its weakest governance path, and for most operators today that weak point runs through ungoverned automation or tooling that was never brought into the main audit and approval system. You can assess that posture with a small set of direct questions. An operator should be able to trace every configuration change made in recent months, whether a human or an automated process carried it out, back to a specific actor, an authorization event, and a timestamped record. You should be able to tell whether AI agents and automated scripts in the environment run through the same APIs and permission structures as human operators, or whether they follow separate execution paths that the main system cannot see. There should be one authoritative record of network state spanning qualification, design, provisioning, and activation, rather than separate stores that have to be reconciled by hand on some recurring schedule. And the approval thresholds that govern automated changes should be built into the system's permission layer, not managed through an informal process that depends on someone remembering to follow it.

TM Forum's own framing for legacy estates lays out three paths: modernizing around what already exists, adding an agentic layer on top of current systems, or replacing fragmented systems over time. Whichever path an operator chooses, the governance architecture needs to be settled before agentic workloads scale up, not afterward, because retrofitting accountability onto a system already running autonomous changes is far harder than building it in from the start. Ericsson's April 2026 analysis of AI-native operator growth adds a useful corrective here: operators do not need a perfect AI-native rebuild before they improve change governance, but they do need to find and close the ungoverned automation paths in their current environment as a first step before scaling agentic operations further.

The cost of leaving that work undone is concrete: operational complexity itself becomes a competitive disadvantage, and the operators treating OSS as a strategic, AI-ready platform, rather than a back-office cost center, are the ones positioned to deliver faster and more reliable service as demand for fiber and carrier-grade connectivity keeps growing. That exposure is most visible in FTTH, dedicated internet, and Carrier Ethernet services, where a misconfigured change or an untracked automated action becomes a customer-facing outage or service fault rather than a problem buried somewhere in back-end infrastructure.

The realistic starting point for most operators is a governance audit: map every path through which a configuration change can reach the live network, identify which of those paths lack the audit and approval controls applied to human operators, and treat every gap found that way as the first item on the remediation list.