AI is digging deeper into telecom networks, promising faster anomaly detection, automated optimization and eventually networks capable of operating with minimal human intervention. However, moving from impressive AI models to trusted network autonomy is far more complicated than deploying another layer of software.
According to Srinivasa Maringanti, Senior AI/ML Engineer at T-Mobile, the challenge begins with understanding the network itself. Telecom data is shaped by topology, protocol states, location, traffic patterns and changing operating conditions, meaning an anomaly on paper may be completely normal in context.
A model that fails to understand that difference can create more problems than it solves.
In this Q&A with Inside Telecom, Maringanti discusses why telecom-specific expertise still matters in AI development. What causes machine learning systems to lose trust in production, where operators should draw the line on autonomous decision-making, and why truly autonomous RAN will depend as much on guardrails, explainability and operational evidence as on increasingly powerful models.
You moved from building SIP stacks, eNodeB systems and O-RAN architectures into machine learning for network operations. Was there a particular problem you kept encountering as a telecom engineer that conventional automation could not solve, and that convinced you ML was necessary rather than simply another layer of complexity?
The pattern that kept showing up was that the problems worth catching were invisible at the resolution most systems actually measure. Rule-based automation is fine once you know the failure mode and can write a threshold for it.
What kept tripping me up were degradations that only existed relative to a specific location, a specific time window, a specific combination of conditions. Average across a cell or a sector and they disappear completely.
You can’t write a fixed rule for something that only looks broken in context. That’s a pattern-recognition problem, not a threshold problem, and it’s the real reason I moved toward ML instead of writing more rules.
You argue that AI in telecom needs telecom-native engineers rather than generic AI or data science expertise. What is the most dangerous mistake a technically competent ML engineer could make when working with RAN or network telemetry simply because they do not understand the underlying telecom system? Can you provide us with a failure scenario?
Treating network telemetry like generic tabular data is the big one. You end up assuming every record is independent when it’s actually shaped by topology, protocol state, time of day, all of it.
Here’s a scenario I think about: a model flags a spike as anomalous because it’s rare in the training window, with no idea the spike lines up with a stadium game or a holiday travel surge near a specific set of cells. To the model, it’s an outlier.
To anyone who actually knows the system, it’s Tuesday. Wire that model into an automated response and you end up ‘fixing’ something that was never broken. That’s worse than doing nothing at all.
A model can score extremely well in a lab and still fail once it enters a carrier network. What tends to break first in production: the data assumptions, latency requirements, changing network conditions, interoperability across vendors, or the model’s understanding of what an anomaly actually means? And what should operators measure before trusting that model with live network decisions?
Data assumptions and changing network conditions, usually come together. A model trained on one slice of traffic and device mix starts drifting the moment any of that shifts in the live network, and it’s always shifting.
That drift shows up as false positives, and that is what actually kill trust. A model that’s slow but right gets tolerated.
One that cries wolf gets muted within a few weeks. Before I’d trust a model with live decisions, I’d want its false positive rate measured under real production load, not an offline benchmark, and some way to see exactly which signal triggered a call.
If you can’t explain why it fired, you can’t trust it when it matters.
Your previous work on self-healing orchestration emphasized bounded actions, human confirmation, verification and rollback. As O-RAN moves toward increasingly AI-native and real-time control, where would you draw the line today between decisions an AI system can safely make autonomously and decisions that should still remain deterministic or require human approval?
Blast radius and reversibility matter more than how smart the model is. Small, fast, reversible actions -a minor threshold tweak, a load-balancing change that auto-reverts if it doesn’t help within minutes- are reasonable to hand off today, because being wrong costs little and doesn’t last.
Anything with a wide blast radius, anything slow to reverse, or anything the system hasn’t seen before should still need a human to sign off. That line shouldn’t move because the model gets smarter.
It moves because you’ve built up a track record of bounded actions actually behaving. That’s trust earned over time, not a software upgrade.
The telecom industry is now talking seriously about Level 4 autonomy, AI-native networks and eventually networks capable of self-optimizing and self-healing with minimal intervention. What part of that vision is genuinely working in production today, and what part is still being presented as more mature than it really is? What technical breakthrough or operational change has to happen before truly autonomous RAN becomes credible at scale?
What’s real today is narrow, closed-loop automation: a well-understood failure pattern gets detected, a pre-verified fix gets applied inside tight guardrails. That part works and it’s genuinely useful.
What’s oversold is the jump from that to broad, hands-off autonomy across situations the system has never actually seen. Most of the industry isn’t there yet, whatever the conference slides say. I don’t think one breakthrough gets us there.
More likely it’s standardized telemetry across vendors so systems aren’t reasoning off inconsistent data, real audit and rollback tooling so every autonomous action can be explained afterward, and time: racking up enough verified bounded decisions that the industry has actual evidence for where the line can move, instead of assuming it because the models got bigger.
Inside Telecom provides you with an extensive list of content covering all aspects of the tech industry. Keep an eye on our Interviews to stay informed and up-to-date with our daily articles.
