Data Academy · Tutorial 9 of 10 · Telecom

Governed AI in telecom

Operators are moving AI from chat assistants into the network operations centre, the fraud desk and the field, where agents now triage alarms, bar fraudulent traffic and plan technician visits. What decides whether this scales is not the model but whether every action on the network, a subscriber line or a work order is checked against policy, approved where it matters and recorded.

01 What is changing

Where AI in telecom is heading

From copilots that summarise tickets to agents that correlate alarms, open work orders and act on subscriber lines inside OSS and BSS.
From scattered pilots to a few domains run end to end, with network fault management and service assurance going first, then field service and fraud.
From adding AI on top of old workflows to redesigning the workflow itself, because agents bolted onto unchanged processes add running cost rather than remove it.
From aiming for full autonomy everywhere to agreed autonomy levels per domain, with people approving the actions that touch customers, safety or revenue.

02 Use cases

Three use cases on the governed path

Each use case runs the same path: a business question, governed context, a deterministic rule, specialist agents, a policy check, an action and a record. How the path works →

Illustrative: names and figures are invented to show the flow.

Use case 1

Cell site outage triage and dispatch

A single power fault floods the NOC with alarms, and engineers lose time finding the root cause and deciding whether a truck roll is needed. Correlating alarms and dispatching only when a visit is genuinely required means faster restoration and fewer wasted visits.

“Site KX-2214 is down: what is the root cause, who is affected, and do we send someone now?”Asked by a NOC shift lead

Context: Fault management: 46 alarms from site KX-2214 correlated to one root alarm, rectifier failure; 3 sectors off-air for 38 minutes
Power telemetry: site running on batteries with about 22 minutes of backup left
Network inventory and CRM: 1,240 subscribers in the footprint, including a hospital enterprise account with a 4-hour restoration SLA
Field service management: nearest power-qualified technician is 52 minutes away with a portable generator on the van
Rule: If the root cause is a power fault and battery backup is under 60 minutes, or an enterprise restoration SLA is at risk, dispatch a power-qualified technician with a generator; a remote reset is not attempted on a power fault.
Decision: Dispatch technician with generator Severity: High
Agents: Alarm correlation agent Groups the alarm storm by topology from network inventory and names the single root alarm with its evidence.
Service impact agent Maps the off-air sectors to subscribers, enterprise circuits and SLA clocks held in the BSS.
Dispatch planning agent Finds the nearest technician with the right skill and kit, and drafts the work order with site access notes.
Policy: NOC engineers may raise field work orders; a generator dispatch needs dispatcher approval before the technician is sent. Enterprise customers are notified under their contract terms, and the incident record is kept ready for any NIS2 significant-incident assessment.
Action: Work order created in the field service management system in pending approval state; the enterprise SLA clock is flagged in the BSS and the outage linked to the incident record.
Data: Fault and performance management (OSS)Network inventory and topologySite power telemetryField service and workforce managementCRM and enterprise SLA contracts

Use case 2

International revenue share fraud bar

Hacked business phone systems can pump calls to premium international ranges overnight, and the operator still owes the interconnect charges. Stopping the traffic within minutes, without cutting the customer off, means fewer write-offs and fewer disputed bills.

“Why is this business trunk calling premium international numbers at 2am, and should we stop it?”Asked by a fraud analyst

Context: Mediation and CDRs: PBX trunk on the account of Halden Freight Ltd made 312 calls to one premium international range between 01:00 and 03:00
Customer history: 30-day average of 4 international calls a day, none to this range
Fraud management system: the range is on the operator's high-risk IRSF list
Charging: unbilled international usage on the trunk has reached €3,800 since 01:00; the customer's site is closed overnight
Rule: If a business trunk with no history to a listed high-risk range makes more than 50 calls an hour to it, bar international premium destinations on that trunk; domestic and emergency calling are never touched.
Decision: Temporary premium-destination bar Severity: High
Agents: Traffic pattern agent Compares the burst with the trunk's own baseline and with the high-risk range list.
Account context agent Pulls the customer's contract, site hours and named contacts from CRM so the bar is explained, not just applied.
Case drafting agent Writes the fraud case with the call evidence and drafts the customer notification.
Policy: Fraud policy pre-authorises reversible destination bars on business trunks; full line suspension, credit notes and interconnect disputes need a fraud analyst. Emergency calls are never barred, and call records are processed under GDPR and ePrivacy rules for fraud prevention.
Action: Premium international bar applied to the trunk in the network and BSS, released automatically within policy; fraud case opened, customer notified, and the bar queued for analyst review in the morning.
Data: Mediation and call detail recordsFraud management and high-risk range listsOnline charging and billingCRM and enterprise contractsInterconnect and wholesale billing

Use case 3

SIM swap protection

A SIM swap hands a fraudster the customer's number and every one-time passcode sent to it. Checking the request against recent account changes stops account takeovers while genuine customers still get a replacement SIM the same day.

“Should this store go ahead with a SIM replacement for this number?”Asked by a retail store adviser

Context: CRM: replacement SIM requested in a store for a 6-year customer with no previous SIM change
Identity and access: app password reset and contact email changed 2 hours before the request
Network data (HSS/UDM): the line has been active on the customer's usual cells all day, 180 km from the requesting store
Account settings: port-out protection switched off during the same session as the email change
Rule: If a SIM change is requested within 24 hours of a credential or contact-detail change, block the swap until a step-up check passes: a one-time code to the existing SIM or in-person photo ID matched to the account holder.
Decision: Block SIM swap pending step-up check Severity: High
Agents: Account change agent Lines up recent credential, contact and port-out setting changes into one timeline.
Location consistency agent Compares where the line is active with where the request is being made.
Customer contact agent Sends the one-time code to the existing SIM and explains to the store adviser what is needed next.
Policy: Store staff cannot override a block; the fraud team may release it once the step-up check passes. Secure authentication before SIM changes reflects regulator expectations such as the FCC SIM-swap and port-out rules in the US, and only the data needed for the check is used under GDPR.
Action: SIM change order held in the BSS, blocked pending the check; no change is made to the subscriber record in the HSS/UDM, and the port-out lock is restored.
Data: CRM and customer identityIdentity and access logsSubscriber data (HLR/HSS/UDM)Order management (BSS)Retail point-of-sale records

03 The foundation

What the agents need to understand

Core entities in the ontology

SubscriberAccountServiceLine (MSISDN)SIMCell siteNetwork elementAlarmWork orderEnterprise SLA

Systems they come from

OSS fault and performance management: Alarms, KPIs and incidents across radio, transport and core.
Network inventory: Sites, network elements, circuits and how they connect.
BSS: CRM, order management, billing: Customers, contracts, orders, invoices and SLA terms.
Mediation and charging: Call detail records, usage events and real-time balances.
Subscriber data (HLR/HSS/UDM): SIM, number and service profile for every line.
Field service and fraud management: Technicians, skills and work orders; fraud rules, cases and risk lists.

04 Guardrails

The controls that let it scale

Emergency calling is untouchable

No agent action may restrict emergency calls on any line, whatever the fraud signal.

Reversible first

Automatic actions are limited to reversible steps such as destination bars; suspensions and credits need a person.

Customer data minimisation

Call records and location data are used only for the stated purpose, in line with GDPR and the ePrivacy rules.

Network change control

Configuration changes on live network elements follow the operator's change process and security duties under NIS2.

Recorded and explainable

Every alarm correlation, bar and block is logged with the rule, evidence and approver, ready for EU AI Act and regulator queries.

05 Rollout

From the first use case to many

1
Pick one domain with clear rules
Start with network fault management, where alarms, topology and restoration targets are already well defined.
2
Build the business model before the agents
Connect inventory, OSS, BSS and field service into one model of sites, services and customers so agents reason over the same facts.
3
Agree autonomy per action
Write down which actions run automatically, which need approval and which are never automated, and get sign-off from network, fraud and legal.
4
Run alongside people
Let agents recommend while engineers decide, compare outcomes, and tune rules before switching any action to automatic.
5
Extend to fraud and field service
Reuse the same model, policy checks and audit trail for fraud bars, SIM protection and dispatch rather than building each anew.

06 What to measure

Outcomes, not activity

Mean time to restoreAvoidable truck rollsFirst-time fix rateFraud losses written offAccount takeover incidentsEnterprise SLA breaches

07 Pitfalls

What usually goes wrong

Agents on top of old workflows. Adding agents without redesigning the process adds running cost; redesign the workflow and retire manual steps as agents take them on.
Inventory that does not match the network. Root cause and impact are wrong when inventory is stale; reconcile inventory with live network data before trusting correlation.
Blocking genuine customers. Over-tight fraud rules cut off real customers; prefer reversible, narrow actions and give customers a fast path to clear a block.
Chasing full autonomy. Aiming for no human involvement everywhere slows delivery; most value comes from high autonomy in a few domains with people approving the rest.

08 Diagnostics

Questions to ask your team

1
Which network and customer actions are our agents allowed to take today without a person, and where is that written down?
2
Does our inventory match what is actually live on the network well enough to trust automated root cause?
3
Can we show, for any bar, block or dispatch, which rule fired, what evidence was used and who approved it?
4
Which manual steps have we actually retired since agents arrived, rather than added to?

09 Keep going

Frequently asked

Will agents make changes on the live network?

Only within agreed autonomy levels and the operator's change process. Most actions start as recommendations or pending work orders, and a person approves anything that affects service, customers or revenue.

Why not let the model decide on fraud?

Fraud actions affect a customer's ability to call and pay, so a deterministic rule decides and the agent explains. That keeps decisions consistent, reversible and defensible to the customer and the regulator.

Where should an operator start?

With one domain where rules are clear and data already exists, usually network fault management. The shared model, policy checks and audit trail built there are then reused for fraud and field service.