Sovereign AI for Telecommunications
Operators hold the network everyone else's sovereignty runs over, and the subscriber data Europe protects most strictly. AI on either has to stay inside the operator. The platform is built so that it can.
Network as a graph
Sites, elements, links and the services on top, modelled once. Alarm storms collapse to the element that explains them.
Subscriber data stays home
Service agents read account, traffic and location data inside the operator, under scoped identities, and hand over when policy says so.
NIS2 with evidence
Incidents opened with the affected services identified, notifications drafted from the record, reviews logged.
A national operator sees hundreds of thousands of alarms a day, serves millions of subscribers whose traffic and location data may not leave the country, and is an essential entity under NIS2 with a regulator that expects incidents reported and explained. AI can shorten fault resolution, resolve routine customer cases and prepare the NIS2 record, but only if the network data and the subscriber data never go to a third-party model.
Read this if you're running network operations, customer operations, security or IT at a fixed, mobile or wholesale operator, or accountable for its NIS2 and telecommunications-law obligations.
For telecommunications operators, Scrydon is the sovereign AI and data platform that models the network and its services as one graph, correlates alarms and predicts faults on it, runs subscriber-facing agents inside the operator's own infrastructure, and produces the incident and audit records NIS2 requires.
It runs on the operator's own infrastructure, in a national sovereign cloud or disconnected for the most sensitive network segments, with open-weight models served locally, so no alarm, topology or subscriber record is ever sent outside.
Too many alarms, too little correlation, and data that cannot travel
A network operations centre is an exercise in triage. Hundreds of thousands of alarms a day arrive from radio, transport, core and fixed access, and when a fibre is cut every service riding it raises its own. The engineer's job is to find the one failure that explains the wall of red, and how quickly that happens depends on who is on shift. Customers usually notice first.
On the other side of the business, the contact centre resolves billing, activation and fault cases that need an agent to read account, traffic and sometimes location records, which ePrivacy rules and national telecommunications law protect more strictly than ordinary personal data. Both problems are natural for AI, and both are closed to any AI service that would take the data outside the operator. Add NIS2's essential-entity obligations, and a multi-vendor network that rules out tying the AI layer to any one supplier, and the requirements for the platform are set.
Alarm floods — One fibre cut raises an alarm for every service on it. Finding the cause depends on who is on shift.
Customer cases that need protected data — Resolving a billing or fault case means reading records ePrivacy and national law protect more than ordinary personal data.
Essential-entity obligations — NIS2 deadlines, security-of-network rules and lawful-request handling all need a record that explains itself.
Vendor-neutral by necessity — Multi-vendor networks and a strategic-autonomy mandate rule out tying the AI layer to a single foreign provider.
One model of the network and the customer, and agents that work on both
The platform models the network as a graph of sites, elements, links and the services layered on top, mapped from inventory and the operations-support systems, and it models the customer on the same graph from the business-support systems. Alarms and performance counters land on that model in real time, so correlation becomes a graph traversal: the alarms are grouped under the element whose failure explains them, with the affected services and customers listed alongside. Models trained on the operator's own history flag the links and cells whose counters look like the days before earlier failures.
On the customer side, service agents read subscriber records inside the perimeter, reason over the same model, and act through the existing billing and provisioning systems under an identity scoped to that customer and that case. A request outside policy is routed to a person with the context attached. When an event becomes a NIS2 incident, the record is already there: the affected services from the network model, the evidence from the alarms, and a drafted early warning for a named person to review.
- 1
Model
An ontology of sites, elements, links, services, products and subscribers, mapped from inventory, OSS and BSS.
- 2
Fuse
Alarms, performance counters, tickets and change records land on the model in real time; a failing element lists the services and customers it affects.
- 3
Predict and resolve
Models trained on your own history flag degrading links; service agents resolve routine cases through the existing BSS.
- 4
Report
The NIS2 early warning and notification are drafted from the incident record, reviewed by a named person and sent.
The operator is the perimeter
For a telecommunications operator the perimeter is the operator itself. Topology, performance data and subscriber records all describe either critical infrastructure or protected personal data, and a strategic-autonomy mandate rules out a foreign provider in the loop. The platform runs on the operator's own infrastructure, in a national sovereign cloud or disconnected for the segments that require it, with open-weight models served locally.
Agents carry scoped identities: a service agent is limited to one customer and one case, a network agent to reading telemetry rather than writing configuration, and every read and every change is attributed and logged. That attribution is what a regulator, a lawful-request auditor or a customer will ask to see, and it is what the platform's observability and governance produce as a matter of course.
Runs where the network is — On the operator's own infrastructure, in a national sovereign cloud, or disconnected for the segments that require it.
Open-weight models, locally served — No subscriber record or topology detail leaves in a prompt. Model choice stays with the operator.
Scoped agent identity — A service agent is scoped to one customer and one case; a network agent to read telemetry, not write configuration.
Attribution and audit — Every read and every change by an agent is attributed and logged, which is what a regulator or a customer will ask to see.
Keep an eye on this space
What changed for your sector in European AI sovereignty, and what we learned in the field. A few times a year, no drip campaign.
Use cases for telecommunications
Network operations and customer operations on one sovereign platform.
5G Network Slicing
Telecommunications
Challenge
Allocating bandwidth dynamically for emergency services versus consumer streaming during crises is manual and slow.
Solution
Network-embedded agents automatically prioritise critical communications traffic during declared emergencies, enforcing QoS policies at the packet level.
Read more
Uninterrupted communication for first responders during high-load events.
AI-Ready Sensor & OT Data Foundation
Data Engineering
Challenge
Grid, water and transport operators sit on years of SCADA and sensor history, but it is too fragmented and poorly labelled for AI models to use reliably.
Solution
An AI-ready data pipeline cleans, contextualises and grounds OT and sensor data in the ontology before it reaches any model, so agents reason over trustworthy, well-described data rather than raw tag soup.
Read more
Predictive models and agents reach production readiness faster, built on a data foundation operators can actually trust.
Scoped Agent Identity for OT Systems
Security & Access Control
Challenge
Giving an AI agent access to SCADA or historian systems is high-risk when every agent shares one broad service account instead of its own scoped identity.
Solution
Each agent authenticates under its own federated identity with least-privilege, time-boxed permissions, so an agent that reads sensor telemetry can never also write control setpoints unless explicitly authorised.
Read more
Agents operate safely alongside OT systems with a fully attributable permission model, closing off a major class of agentic-AI risk in operational environments.
Human-Agent Outage Response Coordination
Incident Response
Challenge
An outage response spans multiple teams and shift changes, and each handoff between an agent's triage and an operator's decision restarts the coordination from scratch, costing minutes that matter during an active incident.
Solution
The AI OS runs outage response as one coordinated process: agents triage telemetry and stage response actions, operators approve or override at defined checkpoints, and the full incident state carries across shift changes automatically.
Read more
Faster, better-coordinated outage response with a single continuous incident record instead of fragmented handoffs between teams and shifts.
Ontology-Based Asset & Network Model
Asset Management
Challenge
A single substation or pipeline segment is represented differently in the GIS, the asset management system and the SCADA historian, so answering "what do we know about this asset" means manually cross-referencing systems that were never built to agree.
Solution
An ontology models every asset and network connection as a single entity, mapped from GIS, EAM and historian data, so agents and operators reason over one consistent asset model.
Read more
A unified, queryable asset and network model that replaces manual cross-referencing across disconnected systems.
NIS2 Incident Detection & 24-Hour Reporting
Security Operations
Challenge
NIS2 gives essential entities 24 hours to send an early warning and 72 hours to file an incident notification, but the evidence is spread across SIEM alerts, OT alarms, ticketing and change logs, and the first day is spent assembling it by hand.
Solution
Agents correlate security and operational signals against a model of the operator's own services and assets, open the incident with the affected services already identified, and draft the early warning and notification from the record for a human to review and send.
Read more
The 24-hour clock starts with a draft in hand instead of an empty template, and every notification is traceable to the events behind it.
What Telecommunications has to comply with
The regulations that decide whether AI can run on this data at all. Each page lists what the framework asks and which platform controls answer it — properties and refusals, not a checklist.
NIS2 · NIS2 Directive
Applies to: Essential and important entities across critical sectors — energy, transport, water, health, digital infrastructure, public administration, manufacturing and more — and their supply chains.
How the platform supports itGDPR · General Data Protection Regulation
Applies to: Any organisation that processes the personal data of people in the EU/EEA, whether established in the Union or offering goods, services or monitoring from outside it.
How the platform supports itCRA · Cyber Resilience Act
Applies to: Manufacturers, importers and distributors of products with digital elements — hardware and software — placed on the EU market, including software vendors and the organisations that build connected products on top of them.
How the platform supports itAI Act · EU AI Act
Applies to: Providers, deployers, importers and distributors placing AI systems on the EU market or whose AI output is used in the EU.
How the platform supports it
What these outcomes actually run on
A telecommunications architect asks how the network is modelled, how agents are scoped and observed, and where the platform runs. These pages answer those questions.
Sovereign Foundations
The zero-trust foundation the whole platform sits on — the same stack from air-gapped to cloud.
AI OS
The runtime that maps a process to steps, routes each step to a system, an agent or a person, and gives it the context to act.
Ontology Based Data Platform
The semantic layer that turns tables into the entities your business talks about.
AI Observability
Monitoring, tracing and evaluation for agents and AI workflows, so failures are diagnosable.
Identity
Federated identity and zero-trust access — for people and for agents, under the same policy.
On-Premises
The platform in your own datacentre, on your own hardware.
Frequently asked questions
How does the platform reduce alarm noise in the network operations centre?+
Can AI agents handle customer cases without subscriber data leaving the operator?+
How does this support NIS2 for a telecommunications operator?+
We run a multi-vendor network. Is the platform tied to any vendor's equipment or cloud?+
Can the most sensitive network segments be kept disconnected?+
How is this different from the AI features our network vendors already sell?+
Do you partner on tenders and framework contracts?+
Prefer to write? Email hello [at] scrydon.com and we will get back to you.
Keep going
Three routes from here: the rules you will be measured against, the platform these outcomes run on, and the sessions where we walk through them.
The rules that apply
Each regulation, what it asks, and the controls the platform provides for it.
The platform behind it
The AI Operating System, Analytics and Sovereign Foundations, page by page.
Every use case
All of them in one place, grouped by the sector that knows them best.
How – Inside the AI OS: running governed agents on your own cluster, live
17 Sept 2026, 09:00
Part 2 of the Sovereign AI series, for engineers and architects. No slides after minute five: an agent gets an identity and scoped permissions, calls tools over governed MCP, retrieves from the ontology rather than raw tables, runs inside the sandbox and is stopped when it steps outside policy, and everything lands in the audit trail — then the same stack brought up on a disconnected network. Properties and refusals, shown rather than claimed.
Other parts of Critical Infrastructure
The other dedicated pages under Critical Infrastructure, and the sector overview they hang off.
Utilities
Energy, water and gas operators: feeder-level forecasting, NIS2 incident reporting and OT data that stays inside the perimeter.
Read the pageTransport
Rail, ports, airports, roads and public transport: one model of the network, predictive maintenance, flow optimisation and incident response on OT data that stays inside the operator.
Read the page
Partners
