The 60% Problem

Two figures, published a few lines apart, explain most of what is happening in enterprise AI right now.

Through 2026, organisations will abandon 60% of AI projects unsupported by AI-ready data. — Gartner

63% of organisations either do not have, or are unsure whether they have, the right data management practices for AI. — Gartner, both cited in ServiceNow's Modernize IT services and operations with AI

Read them together and the shape of the problem is clear: most buyers are unsure their data is fit for purpose, and most of the projects that proceed anyway are expected to be abandoned.

It is worth saying that ServiceNow published both numbers in a document arguing for its own agents. A vendor is under no obligation to surface a statistic that complicates its own pitch, and most do not. The contradiction is not hypocrisy — it is the honest state of a market that is buying capability faster than it is fixing the inputs.

What the numbers are, and what they are not

I want to be careful here, because this is exactly the kind of statistic that gets repeated until it sounds like a measurement.

• 60% abandonment is a prediction from an analyst firm, about AI projects generally rather than IT service management specifically. It is directional rather than precise, and like most figures in this space it reaches us second-hand — which is a reason to check the primary source, not a reason to dismiss it.
• 63% / 60% — lacking or unsure about AI-ready data practices — is from a Gartner survey, again surfaced through the same source.
• 44% have formalised AI governance, down from last year, comes from ServiceNow's own maturity index. It is a vendor surveying its own customers, so treat it as directional — though the direction of travel, governance going backwards while adoption goes forwards, matches what most operators see.
• More than 75% of enterprises use AI in at least one business function, from McKinsey's 2025 State of AI, is the least contentious of the set and the one I would defend in a meeting.

None of these are measurements of your service desk, and that is the point: they describe a pattern, and the pattern is testable locally in a way the percentages are not.

The larger vendors are not the problem here. They are building genuine capability, and the platforms most readers already own will keep getting better. The problem is a data one, and it sits with whoever owns the tickets — which, on most desks, is the customer rather than the platform supplier.

What "AI-ready" means on a service desk

The phrase is doing a lot of vague work in marketing material. In practice, an agent asked to triage and resolve tickets depends on five classes of data, and each fails in a recognisable way.

1. Resolution notes. The single most valuable asset a service desk owns, and usually the most degraded. "Resolved by user." "Fixed." "Done — see Teams." An agent trained on these learns that the correct response to most problems is a short, confident non-answer.

2. Category and priority fields. Frequently free-text in practice, or a taxonomy that has drifted so far from the work that engineers pick whatever gets the ticket out of their queue. An agent routing on these fields inherits a decade of queue-management behaviour rather than any real signal about the problem.

3. Entitlements and the CMDB. Who is allowed what, and what actually exists. Configuration management databases drift because discovery misses things and humans add things by hand. An agent that believes the CMDB will confidently tell a contractor they have no access to a system they use daily.

4. Change records. Whether the thing that just broke was touched on purpose. Without reliable change linkage, every incident looks novel, and root-cause suggestions become guesswork dressed as analysis.

5. Closure behaviour. Auto-closure rules, bulk closures at month end, and tickets closed to hit a service-level target. This is the data that teaches an agent the wrong lesson most efficiently, because it looks like a labelled example.

An agent does not need perfect data. It needs data whose failures are visible. The trouble with all five of these is that their failures are invisible until something confidently wrong happens in front of a user.

Why agents amplify bad data rather than averaging it out

The intuitive hope is that a sufficiently good model shrugs off messy inputs. That is not how it works in practice, for three reasons.

Confidence scales with fluency, not accuracy. A model given an empty resolution note does not produce an empty answer. It produces a plausible one, in the same tone as its correct answers. Human engineers develop suspicion when a ticket looks thin; models do not, unless you build the suspicion in.

Bad labels are indistinguishable from good ones at training time. An auto-closed ticket marked "resolved" is a labelled example of success. A thousand of them teach a clear lesson, and the lesson is wrong. The damage is not random noise, which averages out — it is a consistent bias, which compounds.

Volume hides the error rate. At 80% deflection, a 5% error rate means one in twenty users gets a confidently wrong answer, and those are the interactions that reach a human. The aggregate metric looks excellent while the experience degrades, which is precisely the failure mode service desks spent the last decade learning to detect in offshore transitions.

None of this is an argument against agents. It is an argument that the order of operations matters: fix enough of the data that errors become visible, then let the agent scale.

The afternoon test

Before buying anything, an operator can run six checks in a single afternoon with read-only access. None require a vendor, a licence, or a data team.

1. Sample 200 closed tickets. Count how many resolution notes run longer than twenty words and actually describe what was done. My expectation from most desks is under a third. If it is under a fifth, you have a note-quality problem before you have an AI problem.
2. Count closures that changed category. If tickets routinely arrive as one thing and close as another, your routing label is whatever the last person felt like — and an agent trained on it inherits the habit.
3. Find the auto-closures. Count tickets closed by rule rather than by a person. This is your contaminated training set, and it is usually larger than anyone expects.
4. Reconcile the CMDB against discovery. Take 50 assigned assets and check whether discovery agrees with the record. Every disagreement is an incident waiting to be triaged wrongly.
5. Check change linkage. What proportion of incidents in the last quarter are linked to a change? If it is near zero, either your change process is invisible or your linkage is broken; both matter to an agent doing root-cause work.
6. Measure the duplicate rate. How many incidents in the last month describe a problem already open? This is also the quickest way to estimate your deflection headroom, since duplicates are the easiest thing for an agent to catch.

Two of those checks — resolution notes and closure behaviour — will tell you more about whether an agent will work on your desk than any demo will.

What good looks like on the other side

The standard I would hold a vendor to is not accuracy on a benchmark. It is this: every suggestion carries its evidence, and the record of what the agent did is readable by someone who was not there.

Concretely, when an agent proposes a resolution, it should be able to name the tickets, knowledge articles and change records it drew on. When it acts, the log should state what it changed, on whose authority, and what it saw before and after. Not a transcript — a record an auditor or an incident reviewer can follow.

That standard has a useful side effect: it makes the data problem impossible to hide. An agent that has to cite its sources will fail loudly on a desk with empty resolution notes, instead of quietly guessing. Failing loudly in a pilot is a gift.

What this means for the next purchase

If the 60% figure is even half right, the scarce resource is not model capability. It is the willingness to spend three weeks on the boring layer before spending three quarters on the exciting one.

So the practical order is:

1. Run the afternoon test. It costs nothing and it changes what you ask vendors.
2. Fix the two classes that matter most for your chosen workflow — for triage, that is resolution notes and closure behaviour.
3. Then buy, and hold the vendor to the evidence standard rather than to a deflection number.

The organisations that get value from agents in IT operations over the next two years will not be the ones that bought first. They will be the ones whose tickets were worth learning from.

Next in this series: what an agent actually needs before it can close a ticket — the four data dependencies, in order, and how to test each one before you commit.

Sources

• Gartner, "Lack of AI-Ready Data Puts AI Projects at Risk" (press release), as cited in ServiceNow, Modernize IT services and operations with AI, p.5. The 60% abandonment figure is a prediction for projects through 2026, not a measurement of ITSM outcomes.
• ServiceNow, Modernize IT services and operations with AI (18pp), archived 9 Oct 2026 — projects/market-research/sources/ct-modernize-it-services-operations-ai.pdf. Contains the Gartner-derived figures and ServiceNow's 2025 Enterprise AI Maturity Index (44% governance).
• McKinsey, The State of AI: How organizations are rewiring to capture value, 2025 — >75% of enterprises using AI in at least one function.
• BCG, How Agentic AI is Transforming Enterprise Platforms, 2025 — 20–30% faster workflow cycles among early adopters. Consultancy survey of early adopters; treat as directional.

Vendor-sourced figures are labelled as such. Where a number is a prediction or a vendor index rather than an independent measurement, the text says so.