AI Solutions for Telecom: Where Operators Get Value and Where They Take Risk

You are the account recovery system for the rest of the economy

A phone number resets a bank login, an email account, a payroll portal, and a crypto exchange. Whatever else an operator sells, it also operates the credential that most of the internet falls back on when everything else fails.

That makes one control decisive: who is allowed to move a number to a new SIM or a new provider. A fraudulent SIM swap hands an attacker the passcodes for accounts an operator has never heard of, and the loss lands on a bank, an employer or a customer rather than on the operator that approved the change.

Now consider what most operators are deploying this year: an AI assistant in the care channel that can act on accounts. If it can be talked into a SIM change, a port authorisation, an address update or adding a line, it is a social engineering target that never gets tired, works at scale, and reads instructions from whatever a customer types into it.

That is the risk worth leading with, because it is specific to telecom and it is being built right now.

Score informs, authentication authorises

The principle is short enough to put in a design document.

A model may rank a SIM swap request as suspicious using signals an operator holds: a device seen for the first time, an unusual location, recent account changes, the channel the request arrived through. That score should route the request, add friction, or trigger a hold. It should never be the thing that approves the change.

Approval comes from authentication performed outside the model, through a channel an attacker is unlikely to control, which specifically rules out a passcode sent to the number being taken over. Identity-sensitive actions run from an explicit allowlist; every one is logged, and anything outside the list goes to a person. The assistant drafts, retrieves, and summarises; it does not hold authority over identity.

This is the same separation that belongs in any system where a model sits near something valuable: the component that proposes and the component that authorises are not the same component, and the second one is auditable.

Two things extend the principle. The identity checks an operator already performs at SIM registration, under know your customer rules in many markets, are the enrolment side of the same control, and an automated channel that can bypass them is a gap rather than a feature. And the signal is worth sharing: operators increasingly expose SIM swap and number verification checks to banks through network APIs, so a bank can pause a large transfer when the number behind it changed SIM an hour ago.

Sort every use case by what it is allowed to change

Widen the same question across the rest of the estate. Every telecom AI use case sits at one of three levels of authority:

Advisory. A person acts on the output: a churn list, a fraud alert, a proposed root cause.
Gated. The system acts within limits and asks for approval outside them.
Closed loop. The system changes the production network with no person in the path.

Customer analytics mostly sits at the first level, where an error wastes a retention budget. Network automation is moving toward the third, where an error affects every customer on the cells it touches, emergency calls included.

Closed-loop systems need a bounded blast radius, meaning few sites at first and hard limits on how far any parameter can move, automatic rollback when service indicators degrade, change records like any change an engineer makes, and a stop mechanism that still works while the automation platform itself is failing.

They also need to be treated as privileged infrastructure. A platform with write access to network configuration is a high value target, so its credentials deserve the handling you give privileged human access, and independent review should cover that platform and its integrations rather than the model alone. In the EU, AI used as a safety component in managing critical digital infrastructure is classed as high risk, with those obligations applying from December 2027 following amendments adopted in 2026. Whether a given system qualifies depends on what it controls, so classify use case by use case.

The value is in a join nobody wants to fund

Operators can measure something no other industry can: the calls that dropped, the sessions that failed and the throughput each customer actually received, at the places and times they used the service.

Every distinctive telecom AI use case depends on connecting that to the customer. Experience-driven churn, proactive service recovery when a known fault has affected someone, prioritising capital investment by revenue at risk rather than by cell utilisation, all of it needs network data keyed to cells and network elements to meet customer data keyed to accounts and contracts.

That join is an engineering project with no demo, and it is the thing most AI proposals assume already exists. It is also where the legal work lives, because traffic and location data carry rules specific to electronic communications on top of general data protection law, and a churn model may need a basis that network operations never did.

Scoping honestly means saying this at the start. If the join does not exist, the first phase builds it, and a vendor who prices a model on top of data nobody has inspected is transferring risk to the buyer.

Where a distributed ledger does not help

We build blockchain systems, so this is worth stating plainly. The pitch that recurs here is decentralised identity on a ledger, offered as the fix for exactly the SIM swap problem above.

It misreads where the failure is. Numbers get stolen through social engineering of retail staff and contact centre agents, insider access, and weak recovery flows. None of that is a defect in the credential format, and a ledger does not make a persuadable human harder to persuade. Self-custodied credentials also make recovery harder rather than easier, and the people most often targeted by SIM swap are not the people best placed to keep a recovery phrase safe.

Fix enrolment, authentication, and staff authority first. If there is still an identity problem after that, it will be a different one.

What you should hold at the end

If someone builds this for you, the deliverable is not a model file. It is the feature definitions, the pipelines that produce the join, the guardrail configuration, the evaluation design, and the documentation of limitations.

The build-to-own principle matters more here than in most industries. A system that scores SIM swaps or adjusts live network parameters will be asked about by a regulator, a bank, or an incident review, and an operator that cannot explain, revalidate, or retrain it without the original supplier has put a dependency inside a control it is accountable for.

RWaltz is a blockchain and enterprise software development company building custom smart contracts, dApps and tokenization platforms that integrate with existing business systems. We work to a build-to-own model: clients hold their keys, repositories and intellectual property; engagements are scoped honestly, including the cases where a simpler approach is the better answer, and security review is treated as continuous rather than a single sign-off.

📖 Read the full blog: https://www.rwaltz.com/blogs/ai-solutions-for-telecom-where-operators-get-value-and-where-they-take-risk

Connect with RWaltz:

LinkedIn: https://www.linkedin.com/company/rwaltzsoftware
X (Twitter): https://twitter.com/rwaltzsoftware
Facebook: https://www.facebook.com/RWaltz-Software-PvtLtd-255590135349493
Telegram: https://t.me/RWaltzCrypto
GitHub: https://github.com/rwaltzsoftware
Clutch: https://clutch.co/profile/rwaltz-software
Website: https://www.rwaltz.com