The road to Autonomous networks: why the industry is debating the DevSecOps model for AI at scale

How network operations work today?

Today, most network software is operated within customer-controlled environments, where stability, predictability, and strict change control remain the dominant principles. Upgrade windows are typically limited, carefully planned, and executed at a relatively low frequency compared with cloud-native software environments. This approach has helped CSPs manage operational risk in mission-critical networks, but it also means that change cycles are often slower and more constrained than the continuous delivery models now common in digital software domains.

Automation already exists across many network operations, but AI-driven continuous adaptation is not yet the dominant operating paradigm. As AI capabilities become more embedded in operational applications, this traditional model comes under pressure. Security requirements, model lifecycle management, monitoring, validation, and governance all demand a faster and more continuous cadence, changing both the risk profile and the operating discipline required for network operations.

Why this debate is emerging now?

The debate is intensifying because the telecom industry is moving from AI experimentation toward trusted, production-scale AI-based automation aligned with the broader TM Forum mission for autonomous networks.

TM Forum’s AI Mission helps frame this shift around three connected priorities: leadership-level governance and business transformation, broader democratization of AI across the organization, and the technology foundations needed for AI-native operations. Together, these priorities point to the same conclusion: AI at scale cannot rely on isolated pilots or fragmented delivery models. It requires an operating model that can deliver AI capabilities rapidly, securely, and consistently while preserving governance, compliance, and trust. This is where DevSecOps becomes a critical enabler, providing the shared platforms, automated pipelines, security controls, policy enforcement, and reusable practices needed to turn AI ambition into operational reality.

Figure 1: TM Forum AI and Data Mission Projects, Image courtesy: TM Forum

Recent market analysis such as “How rApps are accelerating the journey to autonomous RAN operations” from Analysys Mason (March 2026), shows that rApps hosted on SMO platforms are one important route for introducing AI-based automation capabilities, support more complex use cases, and advance towards higher levels of autonomous RAN operations. At the same time, broader telecom AI discussions are shifting from isolated pilots to questions of production-scale governance, infrastructure design, and sovereign control.

• AI-based automations are moving closer to production-scale use, raising the bar for repeatable deployment, lifecycle governance, and operational accountability across multi-vendor environments.
• Operators are under structural cost pressure, making AI-based automation not only a technical ambition but a business imperative tied to efficiency, resilience, and faster returns on network investments.
• As AI adoption moves toward real-time operational use, CSPs need stronger governance for model oversight, trust boundaries, policy compliance, and risk ownership.
• Sovereignty is becoming a more visible board-level issue as CSPs evaluate how to balance centralized automation with strict control over data, policies, and operational decision-making.

In this context, the industry is moving beyond whether AI-based automation matters and toward a harder question: what operating model can enable trusted AI to scale under real production conditions?

Supporters of central cloud operating models argue that fragmented local practices are no longer sufficient when AI-based automations require continuous monitoring, controlled human access, standardized deployment pipelines, model lifecycle governance, and policy-driven oversight. That is why the debate feels more urgent now: the commercial and operational stakes are rising at the same time as the technology becomes more deployable.

The industry trade-off: scale versus local control

A DevSecOps model approach is gaining support because traditional operational models often rely on fragmented tooling, regional processes, and specialized local expertise. This can result in slower troubleshooting, inconsistent quality, uneven patching, and duplicated effort across the footprint.

For proponents of DevSecOps model, the answer is to industrialize software delivery through shared pipelines, standardized processes, and expert teams so that benefits can be reused at scale. For others, the counterargument is that some decision rights, operational tuning, and accountability may still need to remain closer to the customer environment. The real issue, therefore, is not simply efficiency, but how to define the right balance between global consistency and local operational control.

For supporters of a cloud operating model, the business case is compelling across four familiar dimensions:

• Reduced operational expenditure
• Increased agility and faster time to value
• Improved return on investment
• Enhanced service performance and user experience

These outcomes are typically linked to high-cadence automated releases, proactive observability, standardized security controls, and economies of scale. However, the industry debate is not only about the upside. This model also depends on organizational alignment, clear operating boundaries, and confidence that standardization will not come at the expense of flexibility where it still matters.

One of the most contested points in this discussion is sovereignty. Advocates of this model argue that role-based access control, strict data boundaries, and customer-governed policies allow CSPs to retain full control over access and data handling. Skeptics, however, often ask whether these safeguards are sufficient in practice once operations, monitoring, and lifecycle processes become increasingly centralized. 

Figure 2: Why DevSecOps model is gaining momentum in the industry debate

What a DevSecOps model is designed to solve

In industry terms, a robust DevSecOps model is intended to address four recurring operational challenges that become more visible as AI adoption scales:

• Automated software delivery: Pipelines orchestrate testing, validation, deployment, and rollback processes with consistent governance frameworks.
• Proactive observability: Continuous monitoring of logs, metrics, and alerts enables early anomaly detection and faster incident response.
• Secure connectivity: Controlled access mechanisms ensure secure interaction between operational teams, systems, and network data. 
• Lifecycle governance: Operational insights drive continuous improvement, refine quality gates, and standardize best practices across deployments.

Vendor implementations can help illustrate how these capabilities may be realized in practice. For example, secure connectivity and controlled access mechanisms show how human and machine interactions can be supported while still meeting audit, security, and governance requirements. Even so, the broader industry question remains how far such models can be standardized across different CSP environments, maturity levels, and sovereignty expectations.

Key business value resides mainly in 4 categories: OPEX avoidance, transformation agility, increased ROI and enhanced customer experience. This chart explains how a centralized and automated operating model for rApps drives value for a CSP beyond simple OPEX reduction. While cost efficiency is important, it is not the primary value driver once automation and DevSecOps practices are in place. These figures represent an estimated three‑year total value contribution based on a Tier‑1 CSP, medium automation maturity, and the deployment of 7 rApps in year one, 6 in year two, and 2 in year three. So the message here is about value distribution and direction, not an exact financial forecast. Reading the chart from left to right “Starting on the left, we see the baseline CSP operational cost structure. With centralized operations, we first address OPEX avoidance, which represents roughly 6% of the total value contribution.” “This includes improved cost efficiency through: Fewer manual operational tasks Reduced duplicated tooling and processes Centralized delivery tools, licensing, and infrastructure” “OPEX avoidance is real, but it is not the dominant source of value in a mature automation scenario.” Transformation Agility – the main value driver “The largest value block comes from Transformation Agility, contributing around 44% of total value.” “This reflects the impact of: Faster innovation cycles Reduced time to market for rApps Higher frequency of releases, upgrades, and testing Industrialized deployment and lifecycle management” “In practice, this is what allows CSPs to scale automation safely while keeping pace with network evolution and vendor innovation.” Increased ROI “Next, we have Increased ROI, accounting for about 23% of the total value.” “This comes from: Lower upfront investment per rApp Shorter payback periods Better reuse of centralized DevSecOps capabilities across multiple rApps and regions” “Instead of building and maintaining bespoke operational setups per application, the CSP benefits from economies of scale.” Customer Experience impact “Finally, Customer Experience contributes roughly 27% of the overall value.” “This is driven by: More stable and predictable rApp operations Faster issue resolution and patching On‑time security updates and vulnerability remediation Consistent service quality across regions” “The key point is that improved user experience is a consequence of better operational agility and security—not an isolated initiative.” Key takeaway “The main takeaway from this chart is that centralized operations shift value creation: Away from pure cost cutting Toward agility, speed, security, and business outcomes” “In a Tier‑1 CSP with moderate automation maturity, the majority of value over three years comes from how fast and safely innovation can be delivered at scale, rather than from operational cost reduction alone.” And with that, the next slide looks at what customers need to have in place to unlock the full value of centralized DevSecOps – from deployment to monitoring to complete lifecycle management.

Figure 3: Benefits from DevSecOps model in deployment, monitoring, and security at scale

What determines whether DevSecOps works in practice

One reason this remains a debate rather than a settled answer is that the value of DevSecOps depends heavily on readiness. To realize the benefits in practice, CSPs need foundational capabilities in place across connectivity, automation, governance, and cross-functional alignment.

• Secure remote access for operational teams
• Machine-to-machine connectivity for continuous telemetry (logs and metrics)
• Automated deployment and lifecycle pipelines 
• Alignment between customer governance and operational teams 

Figure 4: Operational readiness requirements for making centralization work in practice

When these enablers are established, CSPs are in a stronger position to support continuous monitoring, rapid updates, and scalable lifecycle management across rApps (and, more broadly, autonomous operations across IT and networks).  When they are not, the DevSecOps can risk becoming a governance aspiration without the operating discipline needed to deliver value consistently.

Why security and sovereignty stay central to the debate

Security is one of the strongest arguments for DevSecOps, but it is also one of the reasons operators scrutinize the model most closely. As AI-driven operational applications move closer to live network decision loops, security can no longer be treated as a separate control layer. It must be embedded across the full lifecycle, from access and deployment to monitoring and incident response.

Key controls typically include:

• Strong access management and RBAC (Rule-based Access Control)
• Data encryption and secure transport
• Network protection mechanisms such as firewalls and intrusion detection
• Continuous auditing and incident response processes

These controls are essential to resilience, but they do not remove the need for trust, policy clarity, and clearly defined accountability. This is why the debate over this model is often inseparable from a broader debate about governance, sovereignty, and who ultimately owns operational risk in an increasingly autonomous environment.

Figure 5: Security strategy within the DevSecOps debate

Conclusion

The industry is increasingly aligned on one point: operating AI at scale requires more than technical innovation. It requires an operating model capable of supporting repeatable delivery, governance, security, and lifecycle accountability across increasingly complex environments.

A DevSecOps model is emerging as a strong answer to that challenge, particularly for organizations seeking industrialized operations, faster innovation cycles, and more consistent control frameworks. But the debate is not fully settled. Its success will depend on how well CSPs and vendors can balance scale with sovereignty, standardization with flexibility, and automation with clear accountability. In that sense, the industry discussion is now moving beyond architecture and into the harder question of operating-model design.

Read more

• rApps for Intelligent Automation
• Intelligent RAN Automation for network operations
• The intelligent choice for telecom networks
• Intelligent Automation Platform (EIAP)
• Agentic AI-powered rApp as a Service with AWS
• Assessing the impact of rApps in autonomous networks
• Agentic AI: Pathway to autonomous network level 5