ITIL AI Capability Model: The 6 Capabilities

The ITIL AI Capability Model is the most immediately useful thing in ITIL 5, and it is not what most coverage suggests. It is not a maturity ladder and not a list of tools. It is a functional classification of what an AI system actually does, and its purpose is governance: knowing which of six capabilities a use case falls into tells you how much human oversight it needs.

That is a far more answerable question than “is this AI risky?”, which is why the model is worth adopting even if you never sit an ITIL exam.

The six capabilities in the ITIL AI Capability Model

The framework describes six functional capabilities. They are not mutually exclusive — most real use cases combine two or three — and they are ordered here roughly by the distance between the AI and a human decision.

Capability	What the AI does	Service management example
Creation	Produces outputs that did not previously exist.	Drafting release notes from release records; composing a stakeholder update
Curation	Improves quality and organisation of existing information.	Flagging stale knowledge articles; de-duplicating configuration records
Clarification	Helps a person find, understand or navigate content.	Summarising a long incident record; explaining a policy in context
Cognition	Finds patterns, anomalies and relationships across data.	Detecting an incident trend indicating a problem; forecasting capacity
Communication	Acts as a natural-language interface to a system.	A support chatbot; a virtual agent taking a service request
Coordination	Executes or orchestrates action across systems.	Auto-triage and assignment; triggering a remediation workflow

Why the ITIL AI Capability Model is a governance tool

Classification is not the point. What the classification buys you is a defensible answer to the oversight question.

Compare the two ends. Clarification summarises an incident record for a human who then decides — if the summary is wrong, a person is positioned to notice before anything happens. Coordination triages a ticket and assigns it, or triggers a remediation workflow, with nobody in the loop — if it is wrong, the action has already occurred.

Those two need completely different controls, and yet a risk register that lists both as “AI in the service desk” treats them identically. The model gives you the vocabulary to say why they are different, and to set proportionate controls rather than blanket ones.

The framework also notes something easy to miss: the classification helps tailor controls to what an AI does beyond its intended use. A tool sold as a summariser that can also trigger actions has a coordination capability whether or not anyone bought it for that.

Mapping capability to oversight

The framework classifies; it does not prescribe controls. Here is a workable mapping, drawn from how the capabilities actually fail rather than from their labels.

• Creation — human approval before publication. The characteristic failure is confident invention. Anything generated and then published, sent to a customer or relied on for a decision needs a named person to approve it first.
• Curation — approval before deletion or overwrite. Reversibility matters more than accuracy here. An AI that archives the wrong knowledge article is recoverable; one that deletes it may not be.
• Clarification — lowest inherent risk, with one caveat. Watch for confidently wrong summaries of records that carry obligations. A misread of an SLA clause is not a low-risk error.
• Cognition — human interpretation before action. The characteristic failure is correlation presented as cause. A detected pattern is a candidate for investigation, not a finding.
• Communication — disclose and provide an exit. Users must know they are talking to a system and be able to reach a person, without having to fail three times first.
• Coordination — bounded actions, audit trail, tested stop control. The highest-risk class. The AI may only perform actions from an explicit list, every action is logged in the same trail as human actions, and there is a stop mechanism that has actually been tested.

The last point deserves emphasis because it is the one organisations skip. An untested stop control is not a control. Neither is oversight whose only mechanism is “the operator will notice” — vigilance-based oversight degrades within weeks. Pair it with a threshold, a sampling rate or an alert.

Using the model in practice

Adopting the ITIL AI Capability Model is mostly an inventory exercise, and the inventory is where the value shows up.

Record every use case, including the ones you did not buy. The AI features switched on inside an ITSM or monitoring platform you already licence are in scope from the day they are enabled. This is the category organisations consistently miss, because nobody procured them.

Classify by primary capability, and note the others. Where a use case combines capabilities, govern it at the level of the highest-risk one. A chatbot that can also reset a password is not communication; it is coordination wearing a friendly interface.

Record the oversight control by name. Not “human in the loop” — the specific mechanism, the role that exercises it, and the evidence it operates.

Re-classify on model change. A vendor model update can move a use case between capabilities without anyone requesting it. Treat model and configuration changes as changes under your change enablement practice.

Worked example: classifying one service desk

Abstract capabilities are easier to argue about than to apply, so here is a mid-sized service desk classified end to end. Seven AI use cases, all of them live, most of them arriving as platform features rather than purchases.

Use case	Primary capability	Also	Oversight
Draft summaries for major incident reviews	Clarification	Creation	Reviewer confirms before circulation
Detect recurring incident patterns	Cognition	—	Problem manager interprets before raising
Chatbot handling access queries	Communication	Clarification	Disclosed; escalation to a person on demand
Auto-triage and assign requests	Coordination	Cognition	Confidence threshold; misroute rate watched weekly
Trigger remediation on error conditions	Coordination	—	Bounded action list; audit trail; tested stop
Flag obsolete knowledge articles	Curation	—	Author approves; no automatic deletion
Generate release notes	Creation	—	Release manager approves before publication

Two observations from doing this exercise. The chatbot looks like the risky one and is not — it is disclosed, bounded and has an exit to a human. The two coordination use cases are the ones carrying real exposure, and both arrived quietly as configuration rather than as projects. And the release-notes generator, which nobody would flag in a risk workshop, is a creation capability publishing to customers: low impact, but it needs the approval step precisely because nobody thinks of it as AI.

What the model does not give you

Worth being straight about the limits. The framework provides the classification and the reasoning for why it helps; it does not provide a control set, a risk methodology or a compliance mapping.

For those, the model pairs naturally with material designed for the job: ISO/IEC 42001 for an AI management system, the NIST AI Risk Management Framework for risk method, and the EU AI Act where its obligations apply. The capability classification is the front door — it tells you which use cases need the heavier machinery and which do not.

Our companion piece on AI governance in ITSM covers that control layer in detail, and our overview of what changed in ITIL 5 puts the model in the context of the wider edition.

Frequently asked questions

What are the six capabilities?

Creation, curation, clarification, cognition, communication and coordination. They describe what an AI system functionally does rather than what technology it uses.

Can a use case be more than one capability?

Yes, and most are. The capabilities are explicitly not mutually exclusive. Govern the use case at the level of its highest-risk capability and record the others.

Is this a maturity model?

No. There is no progression through the six and no capability is more advanced than another. Coordination is not a graduation from clarification; it is a different function with a different risk profile.

Does the model tell me which AI is compliant?

No. It classifies function, which lets you scale oversight proportionately. Compliance obligations come from regulation and from standards such as ISO/IEC 42001, not from the classification itself.

Where does the model sit in ITIL?

Within the information and technology dimension, one of the four dimensions of product and service management. The organisations and people dimension picks up the accountability side separately.

Documenting AI governance for service management

Turning the ITIL AI Capability Model into something auditable means a use case register keyed to the six capabilities, a risk assessment that maps capability and impact to an oversight level, and named oversight controls you can evidence. Our ITIL Toolkit includes all three — an AI governance policy, a capability and use case register, a risk assessment and oversight procedure, a human oversight standard with eight named controls, and operating rules mapped to eight practices — as part of 57 templates built against the current edition.