The Hidden Risks of AI in ITSM: When Innovation Outpaces the Foundations

Artificial intelligence has firmly entered the strategic vocabulary of IT Service Management. And for very good reasons. Its promises are highly concrete: accelerating processes, improving support quality, increasing operational efficiency, lightening the load on IT teams, and triggering continuous improvement.

All true… provided we don’t underestimate the decisive point: AI does not generate value automatically, as though its introduction alone were enough to produce results. When adopted in contexts where processes are unclear, data is inconsistent, and governance is fragile, artificial intelligence can transform into an extremely dangerous vulnerability multiplier.

So, what should be done? The essential first step is to identify risks precisely, so they can be managed effectively and potential dead ends, or worse, catastrophic missteps, can be avoided.

That is what we will do in this article, in which we have grouped the main Risk of AI in ITSM around four core areas. Let us proceed in order, concluding with a more realistic approach – the only one that truly allows us to harness the opportunities of this unprecedented technological revolution.

The first risk: automating disorder

Artificial Intelligence, among other things, is an extremely powerful accelerator. But an accelerator, on its own, does not distinguish between what works and what doesn’t. What does this mean in ITSM practice? It means that, for example, if the incident management process is poorly standardised, if ticket categorisation varies from team to team, if priorities are assigned inconsistently, then AI does not correct the system – it amplifies the errors. This is one of the most intuitive yet underestimated risks.

An organisation can introduce a virtual assistant, automatic ticket classification, or a knowledge base suggestion engine and achieve, at least in appearance, greater speed. But if the upstream workflows are unclear, the results will inevitably be inconsistent. Two similar requests may receive different treatment. A critical ticket may be misrouted. A recommendation may seem plausible yet be based on dirty data or outdated documentation.

The end result is paradoxical: more automation, but less reliability. In other words, before even asking where to introduce AI, one should ask how mature the organisation’s ITSM processes are. Because artificial intelligence works well when it encounters readable structures: well-designed workflows, consistent taxonomies, defined SLAs, well-maintained knowledge bases, clear ownership. Without these foundations, the risk is not just making mistakes, but making them faster and on a larger scale.

The second risk: the consequences of poor data quality

We come now to a decisive juncture, which we have already touched upon: data quality. In contemporary ITSM, data arrives from many different sources: tickets, CMDB, monitoring tools, knowledge articles, service requests, assets, logs, surveys, escalations. If these sources are not reliable, up to date, and consistent, even the most sophisticated AI will be working on unstable foundations.

This is a less conspicuous issue than automation, but an even more important one. Because a model — at least for now — does not interpret context the way an experienced professional would: it identifies patterns in the available data. And if the patterns are distorted, incomplete, or contradictory, the output will tend to be as well. This is why many AI initiatives appear convincing during the demonstration phase and far less so in the day-to-day reality of the service desk.

Beware! The problem is not only technical, but also cultural. When users and operators begin receiving inconsistent suggestions, poorly understood classifications, or inaccurate responses, trust erodes rapidly. And once lost, regaining it is far more difficult than introducing a new feature.

In short, AI does not only fail when it produces glaring errors; it also fails when it generates a constant, subtle noise that makes the system less credible. This is one of the most concrete faces of the Risk of AI in ITSM.

The third risk: where is the proof of value?

The third risk is a particularly serious trap, especially at the managerial level. Many organizations introduce AI because they perceive it as an inevitable priority, because everyone around them is doing it. But they do not define in advance what should actually improve, for them, in their specific context. Average resolution time? First contact resolution? Ticket volume reduction? Knowledge base quality? User experience? Agent productivity?

Without a baseline and without shared metrics, the benefits remain blurry. Movement is visible, new tools are noticed, enthusiasm is generated. But when the time comes to justify investments, roadmaps, and priorities, the proof of value is missing. It is one of the typical paradoxes of hype: the more a technology is talked about, the harder it becomes to demonstrate its real impact, if the project was not anchored from the outset to measurable outcomes.

For this reason, in a mature strategy, AI should never be an end in itself. It should be a lever in service of clear service improvement objectives. To put it another way: the focus must shift from technology to governance.

The fourth risk: uncontrolled proliferation of tools

Finally, we close with a risk that is less operational but broader and increasingly relevant: fragmentation. When AI enters an organization without clear policies, without defined ownership, and without shared usage criteria, the result can be a new form of shadow IT: faster, more accessible, and harder to monitor.

It is enough for individual teams to use different tools to classify tickets, generate responses, build workflows, or produce knowledge management content, and in a short time divergences, duplications, and new risk surfaces emerge. At that point, the problem is no longer just the quality of individual AI responses, but the loss of overall coherence in the ITSM system.

This scenario is particularly delicate because it develops gradually and insidiously. At first it seems like an innocuous phenomenon, even a positive one: more experimentation, more initiative, more speed. But then the operational consequences emerge. Different languages, different rules, different automations, different quality levels. And what was supposed to simplify things ends up irreversibly increasing complexity.

Before scaling AI, ITSM must be put in order

We have examined the main risks. At this point, the right question is not whether to adopt AI in ITSM or not. But rather: on what foundations? With what precautions?

Organizations that genuinely want to reduce the Risk of AI in ITSM should focus first and foremost on certain structural elements: standardised processes, reliable data, clear roles, governance, metrics, documentation quality, knowledge base maintenance, and integration between service desk, incident management, request management, and monitoring. This is not the most “spectacular” part of the journey, but it is the part that makes AI truly scalable.

Let us be very clear about this: artificial intelligence works well when it finds an orderly ecosystem. When it can read consistent signals. When the CMDB is not a forgotten archive. When tickets are not a jungle of improvised categories. When teams share a common operational language. Only then does intelligent automation stop being a rather vague and “miraculous” promise and begin to become a concrete asset.

Conclusion: A more realistic approach, and therefore a more strategic one

So, how do we move beyond the AI hype and truly harness its enormous potential? The first step is to stop thinking of AI as a shortcut. In ITSM, it is not. Rather, it is a multiplier. And multipliers, by definition, amplify what they find: if they find solidity, they increase value; if they find chaos, they increase noise.

AI in ITSM should neither be slowed down out of fear, nor accelerated out of fashion. It must be placed within a serious strategy, tailored to one’s own organization and the context in which it operates. Because the real hidden risk is not that AI won’t work. It is that it will seem to work well enough to convince us that the foundations no longer matter… when in fact they matter more than ever.

To explore these aspects further, we refer you to the recordings of the EasyVista webinar “AI in ITSM: What’s Real. What’s Hype. What’s Next”, which addresses precisely the boundary between concrete possibilities, inflated expectations, and more mature adoption scenarios.

FAQ

#1 Why can an overly rapid approach to AI be problematic?

Because it often pushes teams to use artificial intelligence without starting from concrete problems to solve. This generates disconnected experiments, redundant projects, and results that are difficult to scale or measure.

#2 What are the main risks of AI in ITSM?

The main risks are four: automating disorganised processes, obtaining unreliable results due to poor data, failing to demonstrate the real value of AI, and creating fragmentation between tools and workflows in the absence of clear governance.

#3 How are the risks of AI in ITSM reduced?

By first securing the foundations: process standardisation, governance, data quality, clear metrics, up-to-date documentation, and a well-maintained knowledge base. Only then does it make sense to scale AI.