AI and machine learning in networking
Generative and predictive AI use cases in network operations, and the limits and validation discipline these tools require.
AI/ML use cases
Machine learning finds patterns in network data to predict or classify: baselines for 'normal' traffic, anomaly scores for deviations, forecasts for capacity. Generative AI produces new artifacts — configs, documentation, incident summaries — from prompts. The blueprint treats both at concept level: what they do for operations and what they cannot guarantee.
AI/ML in network operations
| Capability | Type | Operations use |
|---|---|---|
| Anomaly detection | Predictive ML | Flag unusual traffic/error patterns vs learned baseline |
| Forecasting | Predictive ML | Capacity and failure prediction from trends |
| Correlation | Predictive ML | Group thousands of alerts into one probable root cause |
| Config/doc drafting | Generative AI | Draft configs, explain outputs, summarize incidents |
| Natural-language queries | Generative AI | 'Show me APs with high retries' translated into a real query |
Limits and validation
Limits that matter: models are probabilistic — they can be confidently wrong. Generative output must be validated before deployment (a plausible-looking config can still be incorrect); predictive alerts need human judgment because false positives waste the most expensive resource (operator attention). Training data bias and drift mean yesterday's model may misjudge today's network.
Using AI output safely
| Step | Practice |
|---|---|
| Validate | Treat generated config like untrusted code — review and lab-test |
| Ground | Check claims against device output, not vibes |
| Bound | Use for drafting/triage; humans own the change decision |
| Review drift | Re-check models as the network changes |
- Prompt result
- An AI-drafted ACL that also permits `ip any any` at the end
- The specific denies still apply — first-match is honored — but the final
permit ip any anyadmits everything the earlier permits did not cover, silently broadening an allow-list policy. - Only a read of the generated lines catches it: evaluate each rule against intent.
- The deny rules did not disappear — the generated file changed the policy at the tail. This is the failure mode 'validation before deployment' exists for.
Plausible syntax ≠ correct semantics — verify generated artifacts like any change.
Verification and mistakes
Verification discipline
- Cross-check an AI claim against primary evidence (show output, logs) before acting.
- Treat anomaly alerts as hypotheses to confirm, not incidents to remediate.
- Test generated configs in a lab or dry-run path first.
Common mistakes
- Assuming AI output is authoritative — it's generated, not verified.
- Believing anomaly detection eliminates false positives — it trades them for tuning effort.
- Deploying generative configs without review — syntactically valid can still be functionally wrong.
- Ignoring data drift — a model trained before an expansion may flag normal growth as anomalies.
Observation: The new ML platform raises hundreds of anomaly alerts in week one.
- Baseline window too short — normal peaks flagged
- Model hasn't learned this network's real patterns
- Threshold too sensitive for the environment
| Check | Indicates |
|---|---|
| Alert distribution vs business cycles | Alerts clustering at known peak times = baseline problem. |
| Sampled alerts for true/false positive ratio | Quantifies whether tuning or noise dominates. |
Correction: Extend the learning window and tune sensitivity; treat the first weeks as calibration.
Alert rate settles and precision improves on sampled review.
Related resources
Sources
- Cisco CCNA 200-301 v1.1 Exam Topics (official PDF) — reviewed 2026-11-02
Targets CCNA 200-301 v1.1 objectives. Supplemental blocks are labeled beyond exam scope.