Why the decisive questions about AI in ITSM are not technical but a matter of control — and are already being answered today, whether deliberately or not.
Few technologies move into service management as fast as artificial intelligence. An assistant that pre-sorts tickets, drafts answers, resolves entire incidents on its own — it looks like magic. It is not. Behind every seemingly magical capability sits a decision about what the AI may see, say and do. These are not technical details but governance decisions. And they are being made right now — in many organisations by no one in particular.
1. The illusion of magic
Anyone who watches an AI assistant produce a clean answer to a tricky request in seconds is impressed. Understandably. But the impression obscures the essential point. The AI did not perform magic. It accessed data that someone released to it. It generated text for whose accuracy someone is answerable. And when it acts on its own, it does so within rights that someone granted it.
Each of those "someones" is a decision. Together they form the governance of your AI use. The uncomfortable part: these decisions are made even when no one makes them deliberately. Roll out a copilot without rules, and the answer to "Which data may it see?" becomes "all the data the logged-in user can access". That is a governance decision too — just a poor one, because no one examined it.
It helps to see AI in ITSM not as one thing but as three stages of rising consequence: AI that predicts. AI that phrases. AI that acts. Each stage poses its own governance question. If you do not answer it, you have answered it anyway.
2. Predictive: who owns the prediction?
The first stage is the quietest and has often been in use the longest. Predictive AI recognises patterns: it prioritises tickets, routes them automatically to the right group, forecasts outages before the first user calls. This is useful and rarely contested — which is exactly why governance slips away here fastest.
Because a prediction is never neutral. It rests on historical data, and that data carries the distortions of the past. If requests from a particular department were always prioritised low in the past, the model learns to perpetuate precisely that. So the question is not "Does the prediction work?" but "Who is answerable when it is wrong?". If a critical incident is left lying because the model rated it "low", "the AI decided that" is not an acceptable answer. In ITIL terms, prioritisation belongs to Incident Management, and responsibility for it cannot be delegated to a model.
The governance task is therefore clearly defined: which data the model is trained on, how transparent the classification is to users, and who regularly checks whether the predictions are still fair and accurate. None of this is magic. All of it is a decision.
3. Generative: who is liable for the answer?
The second stage is the one everyone now means when they say "AI". Generative AI phrases: draft replies for the service desk, knowledge articles, summaries of long ticket histories. The productivity gain is real. But with the phrasing comes a new operational risk — the hallucination.
A generative model produces plausible-sounding text even when it does not know the answer. In service management that is not a curiosity but a question of liability: what happens when the assistant gives a customer an answer that is wrong yet convincingly worded? The answer carries your company's logo, not the model provider's.
This is exactly where the governance decision lies, and it has two levers. The first is source binding: an assistant that draws its answers from the released knowledge base (the principle behind retrieval-augmented generation) invents less than one that draws freely from its training. That ties AI directly to Knowledge Management — poor knowledge base, poor AI answers. The second lever is release: does the AI draft something a human reviews, or does it reply to the customer directly on autopilot? Either can be right. But it has to be a deliberate decision, not a default setting.
4. Agentic: who may let it act?
The third stage is the one most talked about and least thought through. Agentic AI acts on its own: an agent resets a password, grants an access, starts a change, restarts a service. No longer suggesting — doing. With that, the AI leaves the role of assistant and becomes an actor in the system.
And here ITIL has long had the answer, only under a different name. When a person wants to trigger a change, they pass through an approval chain: defined authority, documented consent, a traceable record, a way back. Change Enablement is the one discipline you must not abolish simply because an AI is now at the controls. On the contrary — an agent that acts in seconds and around the clock needs those controls more urgently than any human.
Before an agent is allowed to act on its own, three questions should be answered:
Boundary: What may it do alone, and where does its autonomy have to end at a human approval?
Trail: Is every action logged and attributable to an identity?
Way back: Can every action be undone if it was wrong?
Anyone who leaves those three questions unanswered has not introduced an autonomous agent but an uncontrolled risk with a friendly interface. The appeal of autonomy is precisely that no one has to watch any more. That is exactly why the control has to be built in beforehand, not afterwards.
5. The framework already exists: ITIL AI Governance
The good news: you do not have to reinvent governance for AI. ITIL has always thought in roles, authorities and controlled hand-overs — precisely the categories that AI use demands. With «ITIL AI Governance», PeopleCert has published a dedicated volume that structures how AI is handled in service management. Worth knowing: it is a supplement, not part of the ITIL core — a steering framework, not a tool catalogue.
The underlying idea is simple and effective: AI is a new actor in service management, and for actors ITIL already has a way of working. You give them defined roles, clear rights and a traceable responsibility. Treat the AI like a new team member — one that is incredibly fast, never sleeps and does exactly what its brief says, for better or worse. No team member gets full access to everything on day one. Why should the AI?
6. The Swiss context: limits that matter
For Swiss organisations a further layer applies that concretely bounds the room for manoeuvre. Tickets and prompts regularly contain personal data, and the revised Data Protection Act (revDSG) requires you to know where that data flows. An AI assistant that sends ticket content to a model in a foreign cloud is, in data-protection terms, not a neutral aid but a disclosure of data that needs to be justified and safeguarded.
Anyone serving customers or processes with an EU nexus additionally falls within the reach of the EU AI Act, which classifies AI applications by risk and, depending on the classification, triggers transparency and documentation obligations. For most ITSM applications this means no bans, but a duty to demonstrate: you must be able to explain what your AI does and on what basis. Data residency and sovereignty are therefore not academic questions but selection criteria for the model.
From all of this, three lines can be drawn that you should not cross: no personal data into unvetted models, no agent without an approval chain, no AI answer without a traceable source. Hold those three lines and you already have the bulk of governance under control.
Conclusion: you make the decision either way
AI does not change service management through sorcery. It changes it through a chain of decisions about what the AI may see, say and do. These decisions are made in every organisation that uses AI — the only open question is whether you make them deliberately or leave them to chance.
So the question is not whether AI enters your ITSM. It is already there or on its way. The question is whether you shape the governance behind it before it shapes itself. This is exactly where we at Qudits come in: we help organisations treat AI in service management not as magic, but as what it is — a steerable capability that needs clear rules.
Our practical tip: For every planned AI use in the service desk, ask three things before you switch it on: Which data may the AI see? Who is liable for what it says? What may it do on its own — and where does its autonomy end at a human approval? If you cannot answer those three questions clearly, the AI is not yet in production — it is merely unsupervised.
Request a no-obligation conversation
Florian Nitz is a Consultant at Qudits AG and an ITIL 4 Managing Professional. He is responsible for technical and digital projects — from IT service management to the further development of digital platforms — and combines strategic clarity with pragmatic execution.
Thomas is Executive Partner at Qudits AG and an ITIL V3 Expert. His focus lies in managing complex IT programmes and projects — particularly in the life sciences — as well as in building and continuously improving IT service management organisations. He develops teams and people with passion.