Niemand. Dat is het eerlijke antwoord in de meeste organisaties van 250 tot 5.000 medewerkers, en het is geen slordigheid in iemands proces. Een fout AI-antwoord is geen incident volgens ITIL, geen fout volgens de Nederlandse standaardvoorwaarden voor IT, en geen schending van enige garantie van een modelleverancier. Drie definities, elk op zichzelf redelijk, en daartussen komt het ticket nooit tot stand.
Dit stuk is geschreven voor de IT-manager, IT-directeur of CIO die net een assistent met retrieval in productie heeft gezet naast een bestaande ICT-partner. U heeft een servicedesk, een CMDB, een prioriteitsmatrix en een leverancierscontract dat ouder is dan elk model dat u nu draait. De vraag is wat die instrumenten doen als de storing geen storing is.
Waarom is niemand verantwoordelijk als een AI-systeem een fout antwoord geeft?
Om twee uur 's nachts vertelt een planningsassistent aan de nachtploeg dat het contract van een klant levering binnen 48 uur toestaat. Het contract zegt 24. De API gaf HTTP 200 terug in 900 milliseconden, de dashboards staan op groen en er is niemand gebeld. De fout komt elf dagen later boven water in een creditnota.
Begin bij uw eigen proces. ITIL 4 definieert een incident, in de AXELOS-praktijkgids voor incidentmanagement, als een ongeplande onderbreking van een dienst of een vermindering van de kwaliteit van een dienst. De dienst is niet onderbroken. “Kwaliteit” klinkt alsof die term de rest afvangt, maar in de meeste prioriteitsmatrices in de praktijk valt kwaliteit uiteen in beschikbaarheid en responstijd, omdat dat is wat een monitoringstack kan meten zonder de inhoud te lezen.
Dan het contract van de ICT-partner. De meeste Nederlandse IT-leveranciers contracteren op de NLdigital Voorwaarden↗, de standaardvoorwaarden van de branche, gedeponeerd bij de rechtbank Midden-Nederland in Utrecht. De versie van 2025 verving die van 2020. Artikel 39.1 zegt onomwonden dat de leverancier er niet voor instaat dat de SaaS-dienst foutloos is en zonder onderbrekingen functioneert. Artikel 44.3 bepaalt vervolgens wat een fout is: het substantieel niet voldoen van de software aan de door de leverancier schriftelijk uitdrukkelijk kenbaar gemaakte functionele of technische specificaties, en bij maatwerk aan de schriftelijk uitdrukkelijk overeengekomen specificaties.
Twee zinnen in dat artikel beslissen over uw ticket. Van een fout is alleen sprake als de klant die kan aantonen en die bovendien reproduceerbaar is. En de leverancier heeft geen enkele verplichting ten aanzien van andere onvolkomenheden in de software, alleen ten aanzien van fouten in de zin van die voorwaarden. Artikel 44.2 zet de acceptatiebepalingen aan zodra een acceptatietest is overeengekomen, maar 39.1 verwijst zelfstandig naar 44.3, dus de definitie bereikt u hoe dan ook.
Leg dat naast een taalmodel. Niemand heeft een functionele specificatie geschreven waarin staat dat het antwoord juist zal zijn. En een model dat op een temperatuur boven nul draait, bij een aanbieder die een nieuw checkpoint kan uitrollen zonder u te informeren, kan zijn eigen misser een uur later vaak niet herhalen. Het foute antwoord is dus geen fout. Het is een “andere onvolkomenheid”, en de verplichting daarvoor is volgens de voorwaarden nul.
Artikel 39.1 sluit ook de tweede route af: de leverancier staat er niet voor in dat fouten in een SaaS-dienst die hij niet zelf heeft ontwikkeld, zullen worden verholpen. Een foundation model van een derde is per definitie niet zelf ontwikkeld, dus zelfs een echte, reproduceerbare fout tegen de specificatie valt in de modellaag buiten de herstelplicht.
Tot slot de modelleverancier. De Commercial Terms of Service↗ van Anthropic sluiten uit dat de diensten of uitkomsten juist, volledig of foutloos zijn, en onderdeel D.3 legt de beoordeling bij de klant: het is aan de klant om te bepalen of uitkomsten geschikt zijn, inclusief waar menselijke controle nodig is. Elke voorwaardenset die wij hebben gelezen voert een variant van die bepaling.
Drie partijen, drie definities, en het foute antwoord valt door alle drie heen. Geen samenzwering: drie redelijke definities, geschreven voor drie verschillende doelen, en geen van die doelen was de juistheid van de uitkomst.
Wat leggen de NLdigital Voorwaarden 2025 al voor u vast?
De versie van 2025 bevat voor het eerst bepalingen over AI. ICTRecht schreef op 24 oktober 2025 dat het evenwicht nauwelijks is verschoven: de leverancier behoudt een sterke positie en de klant krijgt meer verantwoordelijkheden↗. Meerdere Nederlandse kantoren hebben goede juridische analyses van die bepalingen gepubliceerd. Wat geen van die analyses doet, is de lijn doortrekken naar de servicedesk, en juist daar landt het werk.
Artikel 37 opent met “als leverancier AI ter beschikking stelt”, dus het bindt overal waar AI wordt geleverd en wacht niet op een SaaS-constructie. Lees het als een verdeling van operationeel werk en niet als juridisch meubilair:
- 37.2 benoemt non-determinisme en zet het buiten de garantie. Uitkomsten kunnen variëren met input en context, het systeem kan model drift vertonen en bij herhaalde toepassing andere resultaten genereren, en de leverancier staat er daarom niet voor in dat de resultaten onder alle omstandigheden of na verloop van tijd doeltreffend of juist zijn.
- 37.5 maakt u de eerste melder. Zodra u zich bewust wordt van een ernstig incident, of van mening bent dat de AI-toepassing een risico vormt als bedoeld in artikel 79 van de AI Act, meldt u dat onmiddellijk en als eerste bij de aanbieder of leverancier. Alleen als u kunt aantonen dat u de aanbieder niet binnen de meldingstermijn kon bereiken, mag u bij de bevoegde autoriteit melden.
- 37.7 maakt u verantwoordelijk voor voldoende menselijk toezicht.
- 37.8 maakt u verantwoordelijk voor een toereikend niveau van AI-geletterdheid bij uw personeel.
Niets daarvan is onredelijk. Het is allemaal operationeel werk met een eigenaar, en die eigenaar is de klant. Als niemand in uw organisatie 37.5 heeft vertaald naar een benoemde mailbox, een benoemde persoon en een afspraak over buiten kantooruren, dan draagt u een contractuele meldplicht zonder proces erachter.
Vier manieren waarop een AI-systeem faalt, en wie er eigenaar van is
Vier, met opzet: een matrix met zeven rijen komt nooit van zijn slide af.
1. Het model staat aan en het antwoord klopt niet
Er ligt niets plat, niets is traag en er wordt geen drempel overschreden. Detectie gebeurt via steekproeven en een terugkoppelroute, niet via monitoring. Eigenaar: u. De verplichtingen van beide leveranciers bewegen niet mee, en geen van beiden hoort ervan tenzij u het meldt. We schreven eerder over hoe fout een geautomatiseerd proces mag zijn↗ en waar u die grens legt.
2. De retrieval is verouderd
Een procedure is aangepast, de index niet, en het systeem antwoordt keurig uit een document dat niet meer geldt. Qua bouw hoort dit meestal bij de AI-leverancier, qua hosting bij de ICT-partner en contractueel bij niemand. Beleg deze vóór livegang schriftelijk: beide leveranciers hebben een verdedigbare reden om te denken dat het aan de ander was.
3. De kosten schieten omhoog
Een retry-lus, een langer contextvenster, een agent die besluit de hele map te lezen. Dit is de enige faalwijze die het gereedschap van de ICT-partner mogelijk wél opmerkt, omdat de kosten landen op de cloudfactuur die de ICT-partner beheert. Alleen staat die uitgave op een abonnement waarvoor uw financiële systeem geen kostenplaats kent, dus gaat de waarschuwing naar een mailbox zonder eigenaar. Eigenaar: IT, met een plafond dat vóór livegang is afgesproken en een waarschuwingsgrens daaronder. Heeft niemand doorgerekend wat draaien kost, begin dan bij wat maatwerk-AI kost om te bouwen en te draaien↗.
4. Prompt injection via inhoud die het systeem leest
Een inkoopfactuur, een webpagina, een binnenkomende e-mail. Er ligt niets plat, niets is traag, en de agent deed precies wat de verkeerde auteur hem opdroeg. Eigenaar: security. Prompt injection heeft een eigen categorie nodig binnen uw bestaande incidenttaxonomie, geen proces ernaast, anders wordt het weggezet als loos alarm door iemand die naar een storing zoekt.
Waarom kan uw servicedesk dit vandaag niet registreren?
Vier redenen, alle vier dit kwartaal op te lossen.
- De AI-dienst is geen configuratie-item in uw CMDB, dus er is niets om een ticket tegen aan te maken.
- Uw prioriteitsmatrix is impact maal urgentie, en beide zijn geijkt op uitval.
- Uw eerstelijnsscript kent geen vraag die onderscheid maakt tussen “de tool ligt plat” en “de tool heeft stellig ongelijk”.
- Degene die het opmerkt is een planner of een controller die niet werd geblokkeerd. Mensen melden stilstand, geen antwoorden.
Drie wijzigingen kosten niets en nemen het grootste deel van de onduidelijkheid weg. Registreer de AI-dienst als configuratie-item met een benoemde eigenaar. Voeg één incidentcategorie toe, uitkomstkwaliteit, met prioriteitsregels die beschikbaarheid negeren. Voeg één triagevraag toe aan het eerstelijnsscript. Doe dat en het antwoord van twee uur 's nachts kan ergens naartoe, en dat is de hele bedoeling. De instrumentatie die zo'n categorie bruikbaar maakt, is apart werk: zie wat een AI-systeem moet uitzenden voordat u kunt debuggen↗.
Wat legt u vast voordat het volgende AI-systeem live gaat?
Artikel 1.2 zegt dat alles in deze voorwaarden alleen geldt als geen expliciete schriftelijke afspraak anders bepaalt. Ze zijn een vertrekpunt en geen lot, en vier zinnen zijn effectiever dan een heronderhandeling.
- Een acceptatiecriterium op papier. Artikel 44.3 hangt alles op aan schriftelijk kenbaar gemaakte specificaties, dus schrijf er één: op deze set van 200 echte casussen beantwoordt het systeem er minstens zoveel juist, en die set wordt opnieuw gedraaid bij elke model- of promptwijziging. Die ene zin maakt van een categorie foute antwoorden een contractuele fout.
- Een bewijsnorm die non-determinisme overleeft. Reproduceerbaarheid is de valkuil in 44.3. Spreek af dat een vastgelegde invoer, uitvoer, modelversie en opgehaalde context samen bewijs vormen, of een herhaling de fout nu reproduceert of niet.
- Één escalatiepad waarin beide leveranciers bij naam staan, met een regel over wie wie belt. Uw AI-leverancier en uw ICT-partner hebben vrijwel nooit een contract met elkaar, en daarom moet de klant de routeringslaag zijn.
- Een maandelijks kostenplafond met een benoemde eigenaar, en een waarschuwingsgrens erónder in plaats van erop.
Over onze eigen plek: Crux Digits bouwt AI-systemen náást uw bestaande ICT-partner en is zelf geen ICT-partner. Wij draaien uw servicedesk niet, uw infrastructuur niet en uw helpdesk niet. Wat wij wél doen is toegepaste AI voor middelgrote organisaties↗ en AI-implementatie in Nederland↗. Waar wij een door onszelf gebouwd systeem draaiend houden, is dat een afgebakende en geprijsde dienst, AI-beheer↗, geschaald voor een kleine organisatie en niet voor een landschap van uw omvang. Het is ondersteuning op het AI-systeem, geen beheer van uw IT.
Welke klok loopt al, die van het contract of die van de AI Act?
Niet op het tijdpad dat de meeste mensen aannemen. De Digital Omnibus over AI, Verordening (EU) 2026/1744, trad op 27 juli 2026 in werking en verschoof de verplichtingen voor hoog risico naar 2 december 2027 voor zelfstandige systemen uit bijlage III en naar 2 augustus 2028 voor AI in gereguleerde producten uit bijlage I. Artikel 73, de melding van ernstige incidenten↗, valt binnen dat regime.
Voor de meeste systemen is de wettelijke meldklok dus nog niet gaan lopen. De contractuele wel. Artikel 37.5 bindt vanaf de dag dat de voorwaarden gelden en niet vanaf december 2027, en de organisaties die in 2027 klaar zijn, zijn de organisaties die dit jaar het meldpad bouwen omdat een contract er al om vroeg. Het uitstel kocht tijd, geen vrijstelling.
De ongemakkelijke versie van het antwoord
Wie wordt gebeld als de AI stukgaat, heeft een saai antwoord en een ongemakkelijk antwoord. Het saaie antwoord is: degene die u aanwijst. Het ongemakkelijke is dat niemand is aangewezen, omdat elk contract in de keten deze faalwijze buiten scope definieert en definities worden geschreven vóór livegang terwijl incidenten lang daarna gebeuren. Het werk is klein en hoort standaard van niemand, en om precies dezelfde reden blijft het in jaar twee liggen: zie wat er na livegang echt stukgaat↗.
Laatst bijgewerkt op 23 september 2026.
Een consultant zegt waar AI loont; Crux Digits bouwt het ook. Vaste prijs per stap, één vaste expert, vanuit Utrecht.
AI-consultancy in Nederland →
