OSS Provisioning Architectures for Modern Service Providers

Provisioning architecture, not model quality, decides whether AI works reliably in telecom operations. The choice service providers face isn't which large language model to buy; it's whether the underlying OSS can hold shared state across qualification, design, order management, and activation, so that AI, or a human, can act on a coherent picture of the network rather than a fragment of one. Everything else in this piece follows from that single structural fact.

What the OSS modernization market reveals about where the industry actually is

The OSS market sits at roughly $13.42 billion in 2025, growing at a 4.33% CAGR through 2033. That's steady, not fast. Modernization spending specifically is moving quicker: from $16.34 billion in 2025 to a projected $18.66 billion in 2026, a 14.2% CAGR, which tells you the market has started splitting maintenance spend from transformation spend, and putting real money behind the latter.

But scale that against total telecom opex and capex, forecast at $1.68 trillion in 2025, and next-gen OSS/BSS spend of $18.25 billion looks like what it is: about 1% of the total, according to an Appledore Research white paper from October 2025. Appledore's analysis of 20 major global operators found return on capital employed fell from 10.7% between 2012 and 2014 to 8.5% between 2021 and 2023, over the same stretch that hyperscalers grew theirs. Legacy operating models are not fixing themselves through organic improvement.

Roughly 80% of OSS spending at most operators still goes toward maintaining and upgrading systems that already exist, per Appledore. Modernization, in other words, is the minority use of the budget, even as the market for it grows. Operators know what needs to happen. Capital is still tied up in what already happened. That's the condition most readers of this piece are actually working within: not a blank slate, but a decision about how much of the legacy stack to carry forward, and how much to replace at the provisioning layer specifically.

How legacy OSS provisioning architecture was built and why it resists AI integration

Legacy OSS grew up as a reactive toolkit. It was built hardware-bound, split by function, and designed around human operators handing work from one system to the next. Provisioning, in most of these environments, spans separate inventory systems, separate order management systems, and separate activation systems, each with its own schema and none of them talking to the others in real time.

That fragmentation is exactly what breaks AI. Omdia's 2026 report, cited by Blue Planet, states that AI agents working across siloed systems run into fragmented, inaccessible data and can't build a coherent operational picture from it. Static rules and predefined policies govern the decision logic in these systems, so AI can get bolted onto a specific step, flagging an anomaly here, triaging a ticket there, but it can't reshape the flow around it. The flow was fixed before the AI arrived.

Data volume makes this worse every year. Telecom data load is projected to grow from 3.4 million petabytes in 2022 to 9.7 million petabytes by 2027, according to World Economic Forum and Accenture estimates. Legacy systems were built for far lower throughput, well below what machine agents trying to reason over it in real time now demand.

The deeper issue lies in the design intent. Legacy OSS was built for human operators navigating known, mapped-out workflows. AI needs something different: machine-readable state, unified context, and control surfaces reachable through APIs. None of that was a design goal when these systems were built, so none of it shows up by accident now. And the provisioning layer feels this most acutely, because it sits at the intersection of every service delivery function. Fragmented data at provisioning doesn't stay contained there; it propagates upstream into qualification and downstream into assurance.

The architectural divide between AI-augmented and AI-native OSS provisioning

Ericsson offers the sharpest definition available for what comes next: AI-native means having "intrinsic trustworthy AI capabilities, where AI is a natural part of the functionality, in terms of design, deployment, operation, and maintenance." Not added later. Designed in from the start.

Set that against AI-augmented systems, where intelligence assists at discrete steps, order fallout detection, anomaly alerting, ticket triage, but detection and decision-making stay boxed in by the same static rules that governed the system before AI arrived. Pull the AI out of an augmented system and it still runs. Pull the AI out of a native one, and the architecture doesn't function the way it was built to.

Getting this distinction wrong carries a real cost. McKinsey's State of AI 2025 findings show organizations that bolt AI onto an unmodernized data stack face maintenance costs two to three times higher than organizations running cloud-native, modular architectures. There's a subtler risk too, one procurement teams tend to miss: AI agents can actually lower the switching costs of staying on an incumbent OSS or BSS platform, since money spent layering AI onto a legacy system becomes, over time, an argument inside the organization for keeping that system around. Worth knowing before a contract gets signed, not after.

Applied to provisioning specifically, an AI-augmented system still runs provisioning as a series of hand-offs between separate tools, with AI spotting the exceptions as they surface. An AI-native system runs provisioning on a single unified data model, where AI has full-context visibility and the ability to act across the entire workflow rather than at isolated checkpoints. The real decision facing operators isn't which AI vendor to shortlist. It's whether the provisioning layer can hold shared state that any operator, human or machine, can act on directly.

What a unified data model requires and what it enables at the provisioning layer

A unified data model means qualification, design, provisioning, and activation all read from and write to the same record of the network. No translation layer between systems. No reconciliation lag while one system catches up to another. No context lost at the handoff points that used to require a person to bridge the gap.

Modern OSS integration depends on the substrate that lets a unified model hold together across a distributed system rather than collapsing back into silos with better branding. For fiber-to-the-home specifically, zero-touch provisioning needs orchestration that works across vendors and technologies, tying together network elements, management applications, and OSS/BSS components spanning assurance and inventory. Without a unified model underneath, that orchestration turns into a bespoke integration project for every vendor combination, which is exactly what zero-touch is supposed to eliminate.

Northbound APIs capture what an operator actually wants, at a high level, and tie that intent to the service definitions sitting in the service catalog. The data model is the bridge connecting operator intent to what happens on the device. Core lifecycle functions in service activation all need to resolve against that same underlying record for AI to act on state changes with any reliability.

Service catalog design matters more than it usually gets credit for. A catalog with built-in definitions for the relevant service types lets automation start working from day one instead of requiring ad-hoc workflow coding for every new service type. The catalog isn't a configuration file sitting off to the side; it's a first-class piece of the architecture. And the unified model does something else worth naming directly: it makes AI's decisions auditable. When every action resolves against a shared record, every change leaves a trace. Without that shared record, AI actions leave behind no coherent trail at all, which becomes a serious problem the moment something goes wrong and someone needs to know why.

Why governed automation is an architectural requirement, not a compliance addition

The architectural logic states it without qualification: deploying agentic AI in telecom requires strong governance control, and transparency and auditability aren't optional guardrails bolted on for regulators. They're load-bearing.

The requirement follows directly from the architecture itself. If AI operates through the same APIs and the same permission structures as human operators, its actions fall under the same audit trail those operators are already subject to. That parity is what makes autonomous operation trustworthy instead of opaque. Ungoverned automation, by contrast, is a straightforward liability: when AI agents act outside the permission and audit structures that govern human operators, there's no basis for holding anyone, or anything, accountable when the outcome is wrong. Shadow automation at the provisioning layer has direct, immediate service impact, not an abstract compliance risk.

Blue Planet's framework includes a secure LLM gateway that lets communications service providers pick models based on their own compliance requirements, with access control, observability, and explainability built into that layer. Every agentic process stays transparent and auditable, so added autonomy doesn't come at the cost of oversight. ServiceNow's AI Control Tower approaches the same problem from the enforcement side, positioning governance as the mechanism that turns agent policy into rules that actually get applied and audited. The broader principle is that autonomous decisions need to stay traceable and accountable through governance structures built into the architecture itself, not layered on after the fact. Apply that to provisioning agents making decisions with real operational and financial consequences, and the logic holds just as tightly.

None of this constrains what AI can do. It's what makes it safe to grant AI more room to act. The stronger the audit trail, the more confidently a human operator can hand over decisions without losing the ability to explain them later. AI-native doesn't mean AI-only: it means AI and human operators working inside the same governed, transparent system, with the architecture enforcing consistent oversight by design rather than by policy memo.

How multi-agent AI changes provisioning workflows when the architecture supports it

Multi-agent AI is starting to change how complex OSS and BSS workflows actually get executed, with Ericsson's published work confirming that agents can collaborate to configure products faster, working across functions instead of in isolated sequence.

The shift that matters most: agents built on a shared data model hand off context to each other, not raw data. Each agent picks up exactly where the last one left off, without a reconciliation step and without losing information at the boundary. In provisioning terms, a qualification agent, a design agent, and an activation agent can run as a coordinated pipeline, each reading from the same network record, each bound by the same governance rules as the others. Human oversight has to be built into that orchestration layer structurally, not tacked on afterward as a monitoring dashboard someone checks once a week. Intent-driven orchestration becomes possible under these conditions: instead of an operator configuring individual parameters by hand, they express the outcome they want, and the agent framework works out the control actions needed to get there. That only works if the unified data model carries enough context to make the intent unambiguous in the first place.

Adoption numbers back up how fast this is moving in principle. NVIDIA's Annual Telecom AI Study for 2025 found 97% of telecom organizations were assessing or adopting AI that year, up from 90% in 2024. Adoption, as an intention, is close to universal.

Execution tells a different story. While research shows 57% of telecom executives consider cloud and AI critical enablers for autonomous networks, research also shows only 19% of CSPs have successfully embedded AI in more than three OSS or network functions. That gap between intent and execution is architectural: the 19% who crossed the threshold are the operators whose data model, APIs, and governance structure were ready to support it before the AI arrived.

Vendor approaches to AI-native OSS provisioning architecture and what distinguishes them

Amdocs announced aOS on February 3, 2026, describing it as a purpose-built agentic operating system for telecom that runs on top of any BSS or OSS stack. It is designed to automate network operations, with compliance, observability, and governance guardrails built in for mission-critical use at scale. Gartner, on December 8, 2025, called Amdocs "the company to beat in the communications service provider business support systems AI race," pointing to its shift toward an AI-native architecture built on a unified data platform. For operators evaluating depth of commitment, aOS sits as a layer on top of the existing BSS/OSS stack rather than replacing it, which is a meaningfully different proposition than full architectural consolidation.

Blue Planet, from Ciena, takes a governance-first approach, built around a secure LLM gateway with access control, observability, and explainability embedded directly into it, positioning every agentic process as transparent and auditable by design. This governance-first approach is designed to keep every agentic process transparent and auditable as autonomy increases.

Ericsson defines AI-native explicitly as intrinsic and designed in from the start, not layered on. Its June 2025 material confirms a multi-agent approach to product configuration and workflow orchestration, and Appledore Research's October 2025 white paper, co-sponsored by Ericsson and AWS, documents the collaboration as one pathway toward agentic AI transformation in OSS/BSS.

ServiceNow's AI Control Tower approaches the problem from the enforcement side: it governs agent registration, enforces policy, monitors execution, and produces audit evidence, turning agentic AI policy into something that actually gets applied inside BSS transformations, relevant directly to operators working under the EU AI Act.

Taken together, these approaches point to the same architectural standard for FTTH, dedicated internet, and Carrier Ethernet delivery specifically: a unified data model spanning qualification through activation, purpose-built for these service types rather than generic network management software stretched to fit them, with AI and human operators working through the same APIs, the same audit logs, and the same permission structures. That parity is what lets an autonomous provisioning action carry the same accountability as one a person initiated by hand.

What service providers should evaluate when assessing provisioning architecture readiness for AI

Start with data model coverage. Does qualification, design, provisioning, and activation share one record, or does every handoff require translation between systems? Every other AI capability an operator wants depends on the answer to this question, so it has to come first.

Check the audit surface next. Can every action, whether taken by a human or an AI agent, be traced against a shared log with consistent permissions applied to both? If AI agents operate outside the governance structure that already applies to human operators, the architecture is ungoverned, full stop, regardless of what any vendor's marketing material says about it.

API accessibility matters just as much. Are provisioning functions exposed through machine-readable APIs that AI agents can call with the same operational authority as a human operator, not read-only visibility into data, but actual control within governed limits? And look closely at the service catalog: does it treat xPON, MEF 3.0 Carrier Ethernet, and dedicated internet as built-in, first-class service definitions, or does each new service type require custom workflow coding before automation can touch it? The answer to that last question tends to say more about how AI-native a platform really is than anything in its pitch deck.