Every analytics platform now has an AI story. The useful question is not whether AI is present; it is which engineering task it performs, what evidence it uses and what happens when it is wrong.
Layer one: detection
Models can learn cell-, sector- or service-specific baselines and identify departures that static thresholds miss. But a model trained on an already misconfigured network may learn that misconfiguration as normal. Detection tells us what changed—not automatically what is correct.
Layer two: correlation
The valuable question is rarely “is this KPI bad?” It is whether the behavior originates in RF, configuration, device, transport, core or application. Correlation requires normalized counters, topology, engineering parameters, UE observations, events and time/location alignment. Much of “AI value” is disciplined data integration wearing a smarter interface.
Layer three: recommendation
A useful recommendation exposes scope, evidence, time window, confidence, assumptions and credible alternatives. It should be possible to trace the proposal back to deterministic network facts and reproduce the reasoning without trusting fluent language.
Actuation is a governance decision
Recommendation is not authorization. Writing tilt, power or mobility parameters into a production RAN requires ownership, change control, validation, rollback and a clearly accountable operator. Private networks may permit tighter control loops, but that is a different operating context—not a footnote.
Four questions for any AI vendor
- Which data sources are correlated, specifically?
- What happens when the model has never seen this cell or condition?
- Show a recommendation that was wrong and how it was detected.
- If “autonomous” appears in the pitch, who signs the change?