Nobody. That is the honest answer in most organisations of 250 to 5,000 people, and it is not a lapse in anyone's process. A wrong AI answer is not an incident under ITIL, not an error under the Dutch standard IT terms, and not a breach of any model provider's warranty. Three definitions, each reasonable on its own, and between them the ticket never opens.
This is written for the IT manager, IT director or CIO who has just put a retrieval-backed assistant into production next to an existing ICT partner. You have a service desk, a CMDB, a priority matrix and a supplier contract that predates every model you are now running. The question is what those instruments do when the failure is not an outage.
Why is nobody responsible when an AI system gives a wrong answer?
At two in the morning a planning assistant tells a night shift that a customer's contract allows 48-hour delivery. It allows 24. The API returned HTTP 200 in 900 milliseconds, the dashboards are green, and nothing paged. The mistake surfaces eleven days later in a credit note.
Start with your own process. ITIL 4, in the AXELOS incident management practice guide, defines an incident as an unplanned interruption to a service or a reduction in the quality of a service. The service was not interrupted. “Quality” sounds like it should catch the rest, but in most priority matrices in practice it resolves to availability and response time, because those are what a monitoring stack can measure without reading the content.
Now the ICT partner's contract. Most Dutch IT suppliers contract on the NLdigital Voorwaarden↗, the sector's standard terms, deposited at the rechtbank Midden-Nederland in Utrecht. The 2025 revision replaced the 2020 set. Article 39.1 says plainly that the supplier does not warrant that the SaaS service is error-free and runs without interruption. Article 44.3 then defines what an error is: a substantial failure of the software to meet the functional or technical specifications the supplier has expressly made known in writing, or, for custom software, the specifications expressly agreed in writing.
Two sentences in that article decide your ticket. An error exists only if the customer can demonstrate it and it is moreover reproducible. And the supplier has no obligation of any kind regarding other imperfections in the software, only regarding errors within the meaning of these terms. Article 44.2 switches on the acceptance-test provisions where a test was agreed, but 39.1 cross-references 44.3 on its own account, so the definition reaches you either way.
Read that against a language model. Nobody wrote a functional specification saying the answer will be correct. And a model running at a non-zero temperature, behind a provider that can ship a new checkpoint without telling you, often cannot reproduce its own mistake an hour later. So the wrong answer is not an error. It is an “other imperfection”, and the stated obligation for those is nil.
Article 39.1 closes the second route as well: the supplier does not warrant that errors in a SaaS service it did not itself develop will be repaired. A third-party foundation model is by definition not self-developed, so even a real, reproducible, specification-breaching error in the model layer sits outside the repair obligation.
Finally the model provider. Anthropic's Commercial Terms of Service↗ disclaim that the services or outputs are accurate, complete or error-free, and section D.3 puts the evaluation on the customer: it is the customer's responsibility to decide whether outputs are appropriate, including where human review is needed. Every provider's terms we have read carry a version of that clause.
Three parties, three definitions, and the wrong answer falls through all of them. Not a conspiracy: three reasonable definitions written for three different purposes, none of which was output correctness.
What do the NLdigital Voorwaarden 2025 already decide for you?
The 2025 revision added provisions on AI for the first time. ICTRecht's reading, published on 24 October 2025, is that the balance barely shifted: the supplier keeps a strong position while the customer picks up more duties↗. Several Dutch firms have published good legal analyses of those provisions. What none of them does is carry them through to the service desk, which is where they land.
Article 37 opens with “if the supplier makes AI available”, so it binds wherever AI is supplied and does not wait for a SaaS arrangement. Read it as an allocation of operational work rather than as legal furniture:
- 37.2 names non-determinism and puts it outside the warranty. Results may vary with input and context, the system may show model drift and may produce different results on repeated use, and the supplier therefore does not warrant that the results are effective or correct under all circumstances or over time.
- 37.5 makes you the first reporter. As soon as you become aware of a serious incident, or consider that the AI application presents a risk within the meaning of article 79 of the AI Act, you report it immediately and first to the provider or supplier, and you may only report to the competent authority if you can demonstrate that the provider could not be reached within the reporting window.
- 37.7 puts sufficient human oversight on you.
- 37.8 puts an adequate level of AI literacy among your staff on you.
None of that is unreasonable. All of it is operational work with an owner, and the owner is the customer. If nobody in your organisation has turned 37.5 into a named mailbox, a named person and a working-hours rule, you are carrying a contractual reporting duty with no process behind it.
Four ways an AI system fails, and who owns each one
Four, deliberately: a matrix with seven rows never leaves its slide.
1. The model is up and the answer is wrong
Nothing is down, nothing is slow, and no threshold is crossed. Detection is sampling and a feedback path, not monitoring. Owner: you. Neither supplier's obligations move, and neither of them will learn about it unless you tell them. We have written separately about how wrong an automated process is allowed to be↗ and where to set that number.
2. Retrieval has gone stale
A procedure was updated, the index was not, and the system answers correctly from a document that no longer applies. By build this usually belongs to the AI supplier, by hosting to the ICT partner, and by contract to nobody. Name this one in writing before go-live: each supplier has a defensible reason to believe it was the other's job.
3. Cost spikes
A retry loop, a longer context window, an agent that decided to read the whole folder. This is the one failure the ICT partner's tooling may actually catch, because the spend lands in the cloud bill they manage. But it sits in a subscription your finance system has no cost centre for, so the alert goes to a mailbox nobody owns. Owner: IT, with a ceiling agreed before go-live and an alert threshold set below it. If nobody has modelled what running this costs, start from the build and run cost of custom AI↗.
4. Prompt injection through content the system reads
A supplier invoice, a web page, an inbound email. Nothing is down, nothing is slow, and the agent did exactly what the wrong author instructed. Owner: security. It needs a category inside your existing incident taxonomy rather than a parallel process, or it will be triaged as a false positive by someone looking for an outage.
Why can your service desk not log this today?
Four reasons, all fixable this quarter.
- The AI service is not a configuration item in your CMDB, so there is nothing to raise a ticket against.
- Your priority matrix is impact times urgency and both are calibrated on downtime.
- Your first-line script has no question that separates “the tool is down” from “the tool is confidently wrong”.
- The person who notices is a planner or a controller who was not blocked. People raise tickets for stoppages, not for answers.
Three changes cost nothing and remove most of the ambiguity. Register the AI service as a configuration item with a named owner. Add one incident category, output quality, with priority rules that ignore availability. Add one triage question to the first-line script. Do that and the 02:00 answer has somewhere to go, which is the whole point. The instrumentation that makes the category usable is a separate build: see what an AI system has to emit before you can debug it↗.
What should you write down before the next AI system goes live?
Article 1.2 says everything in these terms applies only where no explicit written agreement says otherwise. They are a default, not a fate, and four sentences beat a renegotiation.
- An acceptance criterion in writing. Article 44.3 keys everything to specifications expressly made known in writing, so write one: on this set of 200 real cases the system answers at least N of them correctly, with N written into the order form, and the set is re-run on every model or prompt change. That single sentence converts a class of wrong answers into a contractual error.
- An evidence standard that survives non-determinism. Reproducibility is the trap in 44.3. Agree that a logged input, output, model version and retrieved context together constitute evidence, whether or not a rerun reproduces the fault.
- One escalation path with both suppliers named in it and a rule for who calls whom. Your AI supplier and your ICT partner almost never have a contract with each other, which is why the customer has to be the routing layer.
- A monthly cost ceiling with a named owner, and an alert threshold below it rather than at it.
On where we sit: Crux Digits builds AI systems alongside your existing ICT partner and is not an ICT partner. We do not run your service desk, your infrastructure or your helpdesk. What we do is applied AI for mid-sized organisations↗ and AI implementation in the Netherlands↗. Where we keep running a system we built ourselves, that is a defined and priced service, managed AI support↗, scoped for a small organisation rather than an estate of your size. It is support for the AI system, not management of your IT.
Which clock has already started, the contract's or the AI Act's?
Not on the timetable most people assume. The Digital Omnibus on AI, Regulation (EU) 2026/1744, entered into force on 27 July 2026 and moved the high-risk obligations to 2 December 2027 for stand-alone Annex III systems and to 2 August 2028 for AI embedded in regulated products under Annex I. Article 73, serious incident reporting↗, sits inside that regime.
So for most systems the statutory reporting clock has not started. The contractual one has. Article 37.5 binds from the day the terms apply, not from December 2027, and the organisations that will be ready in 2027 are the ones building the reporting path this year because a contract already asked for it. The deferral bought time, not an exemption.
The uncomfortable version of the answer
Who gets paged when the AI breaks has a boring answer and an uncomfortable one. The boring answer is whoever you name. The uncomfortable one is that nobody has been named, because every contract in the chain defines this failure out of scope, and definitions get written before a system goes live while incidents happen long after. The work is small and nobody's by default, which is the same reason it is still undone in year two: see what actually breaks after go-live↗.
Last updated 23 September 2026.
A consultant tells you where AI pays off; Crux Digits also builds it. A fixed price per step, one named expert, from Utrecht.
AI consultancy in the Netherlands →
