AI-Assisted Operations and Transformation
Last updated 12 Oct 2026
At a glance
AI in operations reads the same metrics, logs, traces and inventory as everything else, so it is only as good as the telemetry beneath it. An alert becomes an owned incident through event management, CMDB enrichment and rules, and observability has to be designed into a transformation before go-live, not added after.
The picture
How it works
What AI can do with the signals
| Capability | What it needs | Where it fails |
|---|---|---|
| Anomaly detection | Long, clean metric history; seasonality (bill runs, launches) | Alert fatigue: every change is an anomaly |
| Event correlation | Topology and inventory; timestamps that agree | Correlates by time alone and joins unrelated faults |
| Root-cause suggestion | Traces that join across systems; a deployment log | Blames the last deploy, every time |
| Incident summarisation | Logs with order and customer ids; the ticket | Confidently summarises the wrong incident |
| Predictive detection | SLOs defined; the metrics behind them | Predicts from a metric nobody acts on |
| Remediation recommendation | Idempotent, safe actions; an approval gate | An automated fix applied to a mis-diagnosed cause |
None of these works on a green/red dashboard. The AI use-cases in the Academy, such as AI-driven service assurance and closed-loop self-healing, sit on top of this list. An AI that triages incidents is itself a system in the chain: its recommendations, confidence, changes and outcomes are signals to collect, or the first wrong automated remediation is the last time anyone trusts it.
From detection to action
A SOM slowdown, end to end
Monitor
Observability platformThe platform collects SOM metrics, traces across COM → SOM → ROM, and activation gateway logs.
Detect
Alert rulesp95 latency on the TMF641 service-order API exceeds 5 seconds for 10 minutes. The threshold came from the order-completion SLO.
Send
IntegrationA webhook posts the alert, configuration item, severity, trace id and a dashboard link to the ITSM platform.
Event management
ITSM — event managementValidated and de-duplicated. It is now an event with a source, a CI and a time, not yet an incident.
Correlation and enrichment
ITSM — CMDBThe CMDB says this SOM node serves consumer broadband fulfilment, owned by the fulfilment platform team. Related network events are linked.
Rules
ITSM — rulesCustomer-facing, orders in flight: Priority 2. An open incident on the same service exists, so the event attaches to it.
Incident and action
Resolver groupThe resolver group is paged with the trace attached, finds a certificate renewal on the activation gateway, rolls it back and closes against the evidence.
The value is not in the webhook. Steps 5 and 6 turn technical data into operational insight, and both read the CMDB. A CMDB that does not know which service a SOM node serves produces a Priority 4 ticket for a customer-facing outage. This is the automated front half of T2R; the service assurance module covers the same flow from a network alarm, and both should land in one incident queue.
The operating model: a centre of excellence with federated teams
One platform and one CMDB do not, on their own, end the fragmentation described in 19.1. Departments own different estates, and that ownership is legitimate. The model that works keeps it and adds a small central function that owns what has to be common.
| The centre of excellence owns | The departments keep |
|---|---|
| Standards: what every system emits, the identifiers it carries, alert-rule conventions | Instrumenting their own systems to those standards |
| Architecture: the platform, the ITSM integration, the CMDB model | Their dashboards, alert rules and runbooks |
| Service mapping: technology → service → owner, reconciled to inventory | Keeping their CIs and services current in it |
| Automation: correlation and enrichment rules, allowed closed-loop actions | Deciding which of their incidents may be auto-remediated |
| Governance: SLO definitions and the service reports the business sees | Their operational reporting beneath those |
Who owns what
| Entity | System of Record | System of Engagement | System of Reference | Notes |
|---|---|---|---|---|
| Metrics, logs and traces | Observability platform | — | AI and correlation tooling | The input every AI capability reads |
| Alert rules and thresholds | Observability platform | Owning department | — | Conventions set by the centre of excellence; thresholds derived from SLOs |
| Events and incidents | ITSM platform | Resolver groups | — | Event becomes incident only after enrichment and rules |
| CI → service → owner mapping | ITSM CMDB | — | Service and resource inventory | Model owned by the centre of excellence; entries kept current by departments |
| SLO definitions | Centre of excellence governance (held in the observability or service-quality platform) | Service owners | — | Where they are stored varies; who defines them should not |
| AI recommendations and automated actions | AIOps or ITSM automation (wherever the action executes) | — | Observability platform | Fed back as telemetry: what was recommended, what changed, whether it helped |
In practice
Six weeks after a go-live, care calls rise on a Monday: Friday’s orders have no service, every dashboard is green and the programme team has rolled off. CRM shows orders submitted, COM in progress, SOM 300 tasks “awaiting”, and nobody can join the views by customer. An engineer greps SOM logs for one order id and finds a timeout to ROM: a certificate on the activation gateway expired on Saturday. The affected-customer list is built from a spreadsheet. Trace propagation, a fallout state that pages and one order-completion SLO were all in the original design, cut in month nine to make the date.
- Observability cannot be added after go-live. Trace and order-id propagation is interface design; retrofitting it means changing every integration.
- Coexistence doubles the surface. The trace has to cross the legacy boundary too; correlate on the order id there and accept timing gaps.
- Vendor packages emit what they emit. Make OpenTelemetry a procurement requirement; where absent, log the order id.
- Migration is the first real load test. Bulk loads run through the same order APIs at ten times the rate, so SLOs and dashboards must exist first.
- Hypercare is short. Runbooks have to be written against the traces and SLOs, not the programme’s tribal knowledge.
The trade-off
What it solves
Observability designed into the transformation, with AI on top and a centre of excellence owning standards and the service model, lets operations detect, route and explain incidents from the first day after go-live.
What it does not solve
- AI does not compensate for telemetry that does not join or a CMDB that does not know which service a component serves.
- A centre of excellence does not remove the network/IT ownership boundary; it makes the CMDB decide the assignment before the argument starts.
What it adds
- AI outputs and automated actions become signals that themselves need observing.
- Closed-loop remediation needs idempotent actions and an approval gate per incident type.
- The centre of excellence needs authority over what must be common, not only a platform budget.
Architecture decision
Centre of excellence with federated teams, or a fully centralised observability function?
Centre of excellence with federated teams
Choose when Several departments own real estates and will not give them up; the centre is small, owns standards and the service model, and has authority over what must be common
Fully centralised
Choose when The operator is small enough that one platform team can instrument everything, which is rare beyond a few hundred systems
Breaks if The centre becomes a tooling team that runs the platform while nobody owns the CMDB model, or the platform is bought before anyone decides who owns the service model. Either way departments revert to their own consoles within a year.
Takeaways
Key Takeaways
- AI in operations reads the same signals; without correlated telemetry it has nothing to reason over.
- An alert becomes an incident through event management, CMDB enrichment and rules; the value is in the CMDB, not the webhook.
- Identifiers and fallout states are design; dashboards are tooling. Defer the second if the date demands it, never the first.
- Migration and hypercare are when observability earns its cost, which is why it must exist before them. See the readiness assessment.
- A centre of excellence owns the standards and the service model; the departments keep their estates.
Check yourself
An observability alert reaches ITSM as a Priority 4 ticket during a customer-facing outage. Where did the process fail?Show answerHide
At enrichment and rules: the CMDB did not map the configuration item to the customer-facing service and its owner, so the rules could not set impact and priority correctly.
The programme is late and the sponsor wants to descope observability. What do you keep?Show answerHide
The design: trace ids, order ids in every log, a fallout state and at least one order-completion SLO. These cost days and cannot be retrofitted cheaply. The platform and dashboards can follow in hypercare.
An AI correlation tool keeps merging unrelated faults into one incident. What is it probably missing?Show answerHide
Topology and inventory to correlate against, and possibly timestamps that agree. Correlating by time alone joins faults that merely happened together.