AI can optimise a poorly engineered network, but it can’t replace the engineering that should have been there in the first place. 

At Mobile World Congress this year, JSA TV sat down with Jana Sedivy, VP of Customer Experience & Product at InkBridge Networks, for a conversation about AI and digital infrastructure.  

What followed was a grounded take on a thorny industry question: when does AI help a network, and when is it papering over an engineering problem that should have been solved at the design stage? 

Watch the full interview below, then read on for more context on the ideas Jana raises. 

Jana Sedivy, VP Customer Experience & Product at InkBridge Networks, speaking with JSA TV at Mobile World Congress.

The network capacity planning question  

Network capacity planning needs to address bandwidth: how much throughput do you have, where are the bottlenecks, how do you scale WAN links ahead of demand?  

But if you stop there, you miss the layer where capacity failures tend to be both most catastrophic and least anticipated: the authentication layer. 

In the interview, Jana uses a concrete example to make this point: what happens to your authentication infrastructure when a data centre goes down and every user tries to reconnect at the same time?  

Under normal conditions, authentication requests arrive in a predictable, manageable stream. An outage followed by recovery creates something very different - a sharp, sudden spike that can be orders of magnitude above the steady-state load. If you’ve planned for that scenario, your infrastructure handles it. If you haven’t, no amount of AI-assisted load balancing bails you out in the moment. 

This is the principle we apply in every engagement around network design for multi-site RADIUS systems: disaster should be the expected case, not the exceptional one. Build for the worst-case scenario, test against it, and the day-to-day steady state takes care of itself. 

Where AI does and doesn’t belong in the network stack 

Jana argues that AI applied on top of poor engineering doesn’t fix the engineering - it just delays the reckoning. 

The uses she endorses are specific: error detection, self-healing networks, and traffic optimisation in environments that have already been correctly engineered at the foundational level.  

AI network monitoring tools that surface anomalies, predict saturation points, and flag degraded links before customers notice – these add genuine value. They work because they’re operating on well-structured, well-instrumented infrastructure that gives them meaningful signals to interpret. 

The uses she challenges are the ones where AI is positioned as a substitute for capacity planning, where organisations deploy AI-assisted load balancing or signal optimisation as a workaround for networks that were never designed to handle the loads being placed on them.  

This is a pattern worth watching, particularly in telecom and enterprise environments where the pressure to adopt AI tooling is high and the incentive to revisit foundational design decisions is low. 

For a deeper look at the real-world limitations of AI and the specific conditions under which it earns its place, see our post on AI in network management. 

Worth subscribing to.
Worth reading.

Our weekly newsletter covers network authentication tips, how-tos, security vulnerabilities, free resources, standards updates, and industry news. (All stuff you should stay up to date on!)

Thanks for registering!

SIGN UP Générer un nouvel aliasGénérer un nouvel aliasGénérer un nouvel aliasGénérer un nouvel aliasGénérer un nouvel aliasGénérer un nouvel aliasGénérer un nouvel aliasGénérer un nouvel aliasGénérer un nouvel aliasGénérer un nouvel aliasGénérer un nouvel aliasGénérer un nouvel aliasGénérer un nouvel aliasGénérer un nouvel aliasGénérer un nouvel aliasGénérer un nouvel aliasGénérer un nouvel aliasGénérer un nouvel aliasGénérer un nouvel aliasGénérer un nouvel aliasGénérer un nouvel aliasGénérer un nouvel aliasGénérer un nouvel aliasGénérer un nouvel aliasGénérer un nouvel aliasGénérer un nouvel aliasGénérer un nouvel aliasGénérer un nouvel aliasGénérer un nouvel aliasGénérer un nouvel aliasGénérer un nouvel aliasGénérer un nouvel aliasGénérer un nouvel aliasGénérer un nouvel alias

Engineering first, always 

The practical implication of Jana’s argument is straightforward, even if it’s not always what organisations want to hear: thoughtful engineering at the design stage reduces (and often eliminates) the need for AI-assisted remediation later. Networks built with accurate capacity models, proper redundancy, and realistic worst-case planning don’t need AI to bail them out during an outage. They recover predictably, because recovery was part of the design. 

Need more help? 

If your team is wrestling with network configuration, a troubleshooting problem you cannot resolve, or a system that needs to be more resilient, we can help. InkBridge Networks has 25 years of expertise - we wrote the standards, maintain FreeRADIUS, and have seen every failure mode there is. Reach out to request a quote. 

Related Articles

AI in network management: A hard look at real-world limitations

Today, AI sits at the peak of the hype cycle, but AI in network management faces fundamental challenges that the industry seems reluctant to acknowledge. While it's revolutionizing certain fields, network security isn't necessarily one of them—at least not yet. 

Network design for multi-site RADIUS systems

Some organizations and network operators such as ISPs can use a central RADIUS service for all of their RADIUS needs. This configuration is possible when there are a small number of users, or system load is low. However, when there are a large number of users spread across a wide geographic region, it may be beneficial to use a multi-site approach. As with all solutions, this approach has benefits and costs.