Implementation & operations when the AI is actually live.

1 Assisted vs. Agentic

What's the difference between "assisted" and "agentic" AI in ITSM, and which should we adopt first?

The vendor narrative on agentic AI in 2026 is heavy. Every major ITSM platform is shipping or marketing autonomous agents, AI that doesn't just suggest replies but sends them, doesn't just propose categories but applies them, doesn't just identify root causes but takes corrective action. The capability is real. The readiness for it is not.

The distinction that matters operationally:

Why assisted AI should come first, in nearly every case:

• Failures are recoverable. A wrong suggestion the agent ignores costs nothing. A wrong action the AI took requires investigation, communication, and rollback.
• Data quality reveals itself. Assisted AI surfaces which suggestions agents accept and which they don't. That signal tells you where data is supporting AI and where it isn't, invaluable input before automating anything.
• Trust builds gradually. Teams that have spent six months seeing assisted AI work well are willing to grant agentic AI controlled scope. Teams that get agentic AI on day one and see it fail will block the entire AI programme for 18 months.
• Governance matures with use. The HITL frameworks, audit logs, rollback procedures, and oversight roles all develop through assisted AI operation. Skipping that phase means agentic AI deploys into governance gaps.

The exceptions where agentic AI in ITSM may be appropriate from earlier:

• Narrowly-scoped, low-risk action classes, auto-categorisation against a stable taxonomy, auto-tagging, automatic creation of standard knowledge captures. Failures are easily detected and reversed.
• Internal-only effects with no customer-facing consequence and no production system change. Internal routing within a single team is lower-stakes than customer communication.

2 Predictive Operations

Can AI actually predict and prevent IT outages, or is that still hype?

Predictive operations, AI that anticipates incidents before they're reported, identifies cascading failures, and recommends preventative action, has been on every ITSM vendor roadmap for at least three years. The capability genuinely exists. The conditions under which it produces operational value are narrower than vendors imply.

Three honest truths about predictive AI in ITSM:

• Prediction quality is bounded by data quality. AI cannot predict patterns it has never seen represented in clean form. Organisations with inconsistent categorisation, sparse CMDB relationships, or ambiguous resolution data will see prediction features produce false positives at rates that train teams to ignore them.
• Most "predictions" are detections of patterns already in flight. A spike in network tickets in the last 15 minutes isn't a prediction, it's a detection. Real prediction (warnings hours before symptoms) requires sustained instrumentation and clean historical data.
• Observability vendors are ahead of ITSM vendors here. Datadog, Dynatrace, and similar tools detect anomalies in infrastructure metrics with much higher signal-to-noise than ITSM predictive features. ITSM is catching up but isn't the leading edge.

Where ITSM predictive features genuinely help today:

3 Team Trust

How do we get our team to actually trust and adopt AI features?

Adoption resistance in ITSM AI rollouts is rarely irrational. It usually reflects accurate observations about how the feature is performing, how leadership is framing it, or how the agent's job is shifting. Treating resistance as a training problem, "we'll do another lunch and learn", almost always misses the cause.

The four levers that genuinely move adoption:

The fourth lever is the one most often missed: leadership framing. Teams adopt AI when they believe AI expands what they can do. They resist AI when they believe AI replaces what they currently do. The same feature, with the same accuracy, produces opposite adoption outcomes depending on the framing leadership chose six months earlier.

Frames that produce adoption:

• "AI helps us tackle the customer experience improvements we never had bandwidth for"
• "AI makes new starters productive in weeks instead of months"
• "AI handles the repetitive parts so you can focus on the work that needs your judgement"

Frames that produce resistance:

• "AI helps us reduce overhead in service operations"
• "AI takes care of the simple tickets so we need fewer agents"
• "AI improves our cost-per-ticket metrics"

The technology in both cases is the same. The trust outcome differs by an order of magnitude.

4 New Roles

What new skills and roles does an AI-driven service desk need?

The roles aren't new in the sense of needing fresh hires. They're new in the sense of being responsibilities someone needs to own, explicitly, with named accountability, once AI is in production. Most rollouts leave these informal, which works for the first quarter and then degrades quietly.

Why these shouldn't all be one person, even when the team is small:

• Conflict of interest. The person tuning the AI for higher acceptance has an incentive to lower the bar. The person doing oversight needs independence from that pressure.
• Single point of failure. AI ops responsibilities accumulate institutional knowledge that's hard to transfer. One person leaving creates a months-long capability gap.
• Bandwidth in failure cases. When an AI feature misbehaves, multiple workstreams fire simultaneously, investigation, vendor escalation, comms to the team, governance review. One person cannot cover all of these without something dropping.

Skills that matter across the three roles, regardless of who holds them:

• Critical reading of AI outputs. Spotting where suggestions are subtly wrong before agents act on them. Hardest to teach.
• Prompt and configuration literacy. Vendor AI features expose increasing configuration surface. Knowing what to tune and what to leave alone is a skill.
• Statistical intuition. Acceptance rates, false positive rates, drift indicators. Not deep statistics, but enough to read the dashboards intelligently.
• Vendor management. AI vendors update features constantly. Following release notes, raising tickets, lobbying for fixes, the relationship is more active than conventional SaaS.

5 Model Maintenance

How often should AI models be retrained or updated for ITSM?

The retraining question often reflects an assumption that doesn't match how most ITSM AI actually works in 2026. Few mainstream ITSM AI features fine-tune custom models on customer data. Most use retrieval-augmented generation: a general-purpose model is given access to your specific data (KB articles, past tickets, configuration records) at inference time, and it generates outputs grounded in that data.

That changes what "keeping the AI current" means:

Three signals that warrant immediate review of AI configuration:

• A vendor model update has shipped. Acceptance rates can shift either direction by 10-30% after a model update. Don't wait for monthly review, re-baseline within two weeks of any major version change.
• A significant change in your data composition. A new client onboarded, a new product line introduced, a major incident pattern emerging. The AI was tuned to the old composition; it may underperform on the new.
• A drop in suggestion acceptance over consecutive weeks. Three consecutive weekly drops is a signal to investigate, not normal variance. Could be data drift, model regression, or a change in agent behaviour. All three warrant attention.

The maintenance discipline most often skipped: KB freshness as a continuous habit. Most teams treat KB articles as documents to write at project end. AI-driven service desks need them updated as resolution practice, every novel issue resolution should produce or update an article. Without that, AI knowledge surfacing degrades against a stagnant content base while ticket volume grows around new issues.