Juridisch

Er is iets misgegaan door AI. Wat nu?

Er is iets misgegaan door AI: een verkeerde offerte, een fout antwoord aan een klant. Wat je nu doet in de eerste uren, plus aansprakelijkheid en datalek.

AI WorkTalent Redactie · 1 augustus 2026 · 11 min leestijd

Er is iets misgegaan door AI: dat is het moment waarop een systeem dat je vertrouwde een fout naar buiten heeft gebracht. Een verkeerde offerte die de deur uit is. Een chatbot die een klant iets beloofde wat niet klopt. Een e-mail die nooit verstuurd had mogen worden, maar wel is verstuurd. Over het voorkómen van AI-fouten is al genoeg geschreven. Dit artikel gaat over het moment daarna: de fout is al gebeurd, en je moet nu iets doen. Geen paniek, geen bangmakerij — een rustig, praktisch stappenplan voor de eerste uren en de weken erna.

Er is iets misgegaan door AI: de eerste vier stappen

Zodra duidelijk is dat een AI-systeem een fout heeft gemaakt die klanten of derden raakt, tel je in uren, niet in dagen. Onderstaande volgorde is bewust zo gekozen: eerst stoppen dat het opnieuw gebeurt, dan pas de rest.

• 1. Zet het systeem uit of terug naar handmatig. Niet om het probleem te verstoppen, maar om te voorkomen dat de fout zich herhaalt terwijl jij nog aan het uitzoeken bent wat er gebeurde. Kan het systeem niet in zijn geheel uit, beperk dan in elk geval de taak waarin de fout optrad tot handmatige controle. Liever een paar uur trager werken dan een tiende geval erbij terwijl je nog aan het tellen bent.
• 2. Breng de omvang in kaart. Over welke periode liep dit, en hoeveel gevallen zijn er? Dit is de stap waar de meeste bedrijven te snel overheen gaan. Het is ook de belangrijkste van de vier — zie de volgende paragraaf voor hoe je dat concreet aanpakt.
• 3. Informeer wie het moet weten. Eerst intern: wie is eigenaar van dit proces, wie moet mee beslissen, is er een jurist of vertrouwenspersoon nodig. Dan naar buiten: de klanten of partijen die geraakt zijn, in de vorm die past bij de ernst — zie het kopje hieronder over wat je wel en niet zegt.
• 4. Herstel de schade. Een verkeerde offerte corrigeren, een verkeerd verstuurd bericht rechtzetten, een fout bedrag terugstorten. Doe dit zodra je de omvang kent, niet pas nadat je klaar bent met de analyse van de oorzaak — dat kan best gelijktijdig.

Merk op wat er ontbreekt in deze lijst: de diepgaande analyse van waarom het misging. Die komt, maar niet eerst. In de eerste uren gaat het om stoppen, meten, informeren en herstellen. De oorzaak zoeken doe je zodra de acute situatie onder controle is — daarover verderop meer.

Waarom "hoeveel gevallen zijn er nog meer" de belangrijkste vraag is

Het is verleidelijk om een AI-fout te behandelen als een uniek incident: dit ene gesprek, deze ene offerte, dit ene bericht. Dat is bijna nooit de realiteit. Een AI-systeem volgt een patroon — dezelfde prompt (de instructie die aan het systeem wordt gegeven), hetzelfde werkproces, dezelfde regels. Leidde dat patroon één keer tot een verkeerd antwoord, dan is de kans groot dat het bij een vergelijkbare vraag of situatie al vaker misging. De klant die zich meldde, is vaak niet het enige geval, maar wel de enige die tot nu toe iets zei.

Concreet ga je op zoek naar het patroon in plaats van naar het incident:

• Bepaal de periode. Sinds wanneer draait deze versie van het systeem, deze prompt of deze stap in het werkproces? Vanaf dat moment is elk geval potentieel besmet, niet alleen het geval dat is opgevallen.
• Doorzoek de logs of geschiedenis. De meeste AI-systemen en chatbots houden gesprekken of verwerkingen ergens vast. Zoek naar vergelijkbare situaties: dezelfde vraag, hetzelfde type verzoek, hetzelfde soort resultaat dat fout bleek.
• Reconstrueer wat het systeem zag. Als je de exacte invoer van het foute geval hebt, gebruik die om te zoeken naar vergelijkbare invoer in de rest van de periode. Vaak zit de fout niet in een uitzonderlijk geval maar in een veelvoorkomend type vraag dat toevallig nu pas opviel.
• Tel door, maar laat de klok niet lopen. Geef de klant een reëel beeld van de omvang, geen voorlopige onderschatting die je een dag later moet bijstellen. Gaat het om persoonsgegevens, dan geldt richting de Autoriteit Persoonsgegevens het omgekeerde: daar is de termijn van 72 uur leidend. Meld dus op tijd, ook als je nog aan het tellen bent, en vul de melding later aan.

Deze stap is precies waarom "het was maar één geval" zo vaak een voorbarige conclusie is. Ontdek je bij het doorzoeken dat het patroon breder speelde? Dan verandert dat niet alleen de omvang van het herstel. Het verandert ook wat je aan de klant en eventueel aan de toezichthouder moet melden.

Een voorbeeld ter illustratie

Het volgende voorbeeld is bedacht om de aanpak te laten zien, geen gerapporteerde praktijkcasus. Een groothandel in technisch installatiemateriaal gebruikt een AI-tool die automatisch prijsoffertes opstelt op basis van een ingevoerde onderdelenlijst. Een klant belt boos: de offerte die hij kreeg, was 40 procent te laag. Het systeem paste een kortingsregel verkeerd toe op een combinatie van artikelen die klanten zelden samen bestellen. Eerste actie: het bedrijf zet het systeem terug naar handmatige controle van elke offerte boven een bepaald bedrag. Vervolgens doorzoekt het bedrijf de offertes van de afgelopen zes weken, sinds de laatste aanpassing aan de kortingsregels. Het vindt drie andere offertes met dezelfde combinatie van artikelen. Eén daarvan is al geaccepteerd, en de bijbehorende factuur is al verstuurd. De klant die belde, krijgt een eerlijke uitleg en een gecorrigeerde offerte. Het bedrijf benadert de klant met de al verzonden factuur apart, met een aangepast voorstel — de fout lag namelijk niet redelijkerwijs bij die klant. Pas daarna gaat het bedrijf op zoek naar waarom de kortingsregel dit combinatiegeval niet goed afving.

Naar de klant: wat je zegt en wat je niet zegt

De toon naar de klant bepaalt vaak meer over het vertrouwen dat overblijft dan de fout zelf. Een paar concrete uitgangspunten:

• Zeg wat er is gebeurd, in gewone taal. "Bij het opstellen van uw offerte is een fout opgetreden waardoor het bedrag niet klopte" werkt beter dan vaag blijven of technisch jargon gebruiken. De klant hoeft niet te weten hoe het systeem precies werkt, wel wat er misging in zijn of haar situatie.
• Zeg wat je eraan doet. Concreet en met een termijn: "We passen dit voor u recht binnen twee werkdagen" is sterker dan "we kijken ernaar".
• Zeg niet "de computer deed het" of "het lag aan de AI". Dat klinkt voor een klant al snel als een smoes, en het is er ook een: het bedrijf heeft het systeem gekozen, ingericht en losgelaten op klantcontact. De verantwoordelijkheid verschuift niet naar het systeem.
• Vermijd te vroeg juridische stelligheid. Zeg niet "u heeft hier geen recht op" of juist "u heeft hier absoluut recht op" voordat je dat hebt uitgezocht. "We komen hier zo snel mogelijk op terug met een voorstel" laat ruimte zonder loze beloftes.
• Overdrijf de fout niet, maar bagatelliseer hem ook niet. "Er ging iets mis en dat nemen we serieus" is eerlijker en geloofwaardiger dan het incident wegwuiven als "een kleinigheid".

Waarom "de computer deed het" geen verweer is, verdient een aparte uitleg. Een klant heeft namelijk een relatie met jouw bedrijf, niet met het model of de tool die je op de achtergrond gebruikt. Kwam de fout door een onoplettende medewerker of door een AI-systeem dat je hebt ingezet? In beide gevallen is het bedrijf de partij die de klant een dienst heeft toegezegd — en die dienst niet naar behoren heeft geleverd. Intern kun je best uitzoeken of het aan het model, het proces of de configuratie lag — naar de klant toe verandert dat de verantwoordelijkheid niet.

Aansprakelijkheid in gewone taal

Dit is een onderwerp waar voorzichtigheid op zijn plaats is, want de uitkomst hangt sterk af van de precieze omstandigheden, de gemaakte afspraken en het type schade. In grote lijnen geldt dit: zegt een AI-systeem namens je bedrijf iets toe aan een klant — een prijs, een levertijd, een garantie — dan kan je bedrijf daaraan gehouden zijn. Dat geldt ongeveer net zo als wanneer een medewerker diezelfde toezegging telefonisch had gedaan. Dat een systeem in plaats van een mens de toezegging deed, merkt de klant op het moment zelf meestal niet, en het maakt voor hem ook geen verschil.

Wat dit voor jouw situatie concreet betekent, hangt af van een paar dingen:

• wat er precies is toegezegd;
• of die toezegging redelijk was, of overduidelijk een vergissing;
• wat je algemene voorwaarden hierover zeggen;
• welke schade de klant heeft geleden.

Dat is precies het punt waarop dit artikel je niet verder kan en ook niet moet willen helpen. Bij een offerte van een paar tientjes verschil is een coulante oplossing meestal voldoende. Bij een grotere som geld, een zakelijke klant met een eigen juridische afdeling, of een toezegging met verstrekkende gevolgen, is het verstandig om een jurist te betrekken voordat je iets toezegt of afwijst. Zie ook hoe je aansprakelijkheid en verantwoordelijkheid vastlegt als je met een externe partij werkt — diezelfde vraag speelt namelijk ook tussen jouw bedrijf en de bouwer of leverancier van het AI-systeem.

Als er persoonsgegevens bij betrokken zijn

Raakt de fout persoonsgegevens? Denk aan een verkeerd document dat naar de verkeerde persoon ging, gegevens die zijn prijsgegeven aan wie ze niet had mogen zien, of gegevens die onbedoeld zijn gewijzigd of verwijderd. Beoordeel in zo'n geval altijd serieus of er sprake is van een datalek. Een datalek is, kort gezegd, een beveiligingsincident waarbij persoonsgegevens verloren zijn gegaan of onrechtmatig zijn verwerkt. Let op de norm: melden is de hoofdregel. Artikel 33 van de AVG verplicht je een datalek binnen 72 uur na ontdekking te melden bij de Autoriteit Persoonsgegevens, tenzij het onwaarschijnlijk is dat het lek een risico oplevert voor de betrokkenen. Die 72 uur begint te lopen zodra je van het lek op de hoogte raakt, niet zodra je de oorzaak volledig hebt uitgezocht. Weet je nog niet alles? Meld dan alvast en vul de melding later aan. Levert het lek waarschijnlijk een hoog risico op voor de betrokkenen, dan moet je die mensen op grond van artikel 34 van de AVG ook zelf informeren.

Deze beoordeling verschilt per geval en is niet iets om zelf even af te vinken met een onderbuikgevoel. Leg in elk geval vast:

• wat er precies is gebeurd;
• welke gegevens het betrof;
• hoeveel mensen het raakte;
• wanneer je het ontdekte.

Die vastlegging heb je sowieso nodig, ongeacht of je uiteindelijk meldt. Twijfel je of de situatie meldingsplichtig is? Betrek dan iemand die dit vaker beoordeelt — zeker als het om meer dan een handjevol mensen gaat, of om gevoelige gegevens zoals financiële gegevens of gezondheidsinformatie.

De analyse achteraf: waar zat de fout echt

Pas nadat de acute situatie onder controle is, ga je op zoek naar de oorzaak. Daarbij helpt het om drie soorten fouten uit elkaar te houden, want elk vraagt een ander soort aanpassing:

• Het model deed iets fout. De AI gaf een onjuist antwoord, verzon iets, of paste een regel verkeerd toe binnen zijn eigen werking. Dat is een technisch gegeven van de manier waarop het systeem is gebouwd of ingesteld.
• Het proces had geen controle. Het model deed misschien precies waarvoor het was ingericht, maar er was geen stap waarin een mens het resultaat bekeek voordat dat de klant bereikte. De fout zat dan niet primair in het model, maar in het ontbreken van een vangnet eromheen.
• Een mens vertrouwde te veel. Er was wel een controlestap. Maar degene die moest controleren, klikte het resultaat door zonder echt te kijken — omdat het meestal goed ging, omdat de tijd ontbrak, of omdat het vertrouwen in het systeem inmiddels te groot was geworden.

Deze drie lopen in de praktijk vaak door elkaar, maar het onderscheid is niet alleen theoretisch. Een fout in het model vraagt om een andere prompt, andere brondata of een ander model. Een fout in het proces vraagt om een controlestap die er nog niet was. En te veel vertrouwen vraagt om een aanpassing in gedrag en verwachting, niet om nieuwe techniek. Wie alleen het model bijstelt terwijl het echte probleem was dat niemand meer meekeek, lost niets structureels op.

Wat je structureel verandert

Na de analyse volgt de aanpassing. Drie dingen komen na vrijwel elk incident terug, en ze zijn allemaal concreet uit te voeren zonder het hele systeem opnieuw te bouwen:

• Zet een controlestap terug. Was er een menselijke controle die is afgeschaft "omdat het toch altijd goed ging"? Of was er nooit een geweest voor dit type resultaat? Zet die controle dan terug — al is het maar tijdelijk, of gericht op de gevallen die het meest risico dragen.
• Verlaag wat het systeem zelfstandig mag doen. Verstuurde de AI voorheen zelf offertes? Laat hem dan voortaan alleen een concept klaarzetten dat een mens bevestigt. Dat is precies het onderscheid tussen AI die voorbereidt en een mens die beslist over wat gevolgen heeft.
• Meet of het beter gaat. Spreek een concrete manier af om te volgen of de aanpassing werkt — een steekproef, een teller van foutmeldingen, een vast controlemoment. Zonder meting weet je over een paar maanden niet of het incident echt is opgelost of dat je alleen geluk hebt gehad dat het zich niet herhaalde.

Dit sluit aan bij hoe je een AI-oplossing sowieso klaarmaakt voor dagelijks gebruik: foutafhandeling, kwaliteitsbewaking en menselijk toezicht horen daar structureel bij, niet alleen na een incident. Zie wat een proef nog mist om klaar te zijn voor dagelijks gebruik. En hoeveel een systeem zelfstandig mag beslissen? Dat is een vraag die je idealiter al vooraf beantwoordt, niet pas na een fout. Zie het stappenplan voor AI in het mkb.

Waarom je dit vooraf één keer doordenkt

Alles in dit artikel is uit te voeren tijdens een incident, onder tijdsdruk, met een boze klant aan de telefoon. Het gaat alleen een stuk beter als je van tevoren al een paar dingen hebt bedacht:

• wie er dan aan zet is;
• waar je de logs of de geschiedenis van het systeem terugvindt;
• bij wie je moet zijn voor een juridische inschatting.

Een noodplan bedenken tijdens het noodgeval zelf kost tijd die je in die eerste uren niet hebt. Het leidt eerder tot half doordachte beslissingen dan tot een rustige, praktische aanpak. Het is dezelfde logica als een ontruimingsplan: je hoopt het nooit nodig te hebben, maar je wilt niet pas bij de eerste rookmelding bedenken wie de nooduitgang opent. Leg daarom voor de belangrijkste AI-toepassingen in je bedrijf een paar dingen vast: wie je als eerste belt en waar je de geschiedenis van het systeem terugvindt. Leg ook vast welke externe partij je belt bij twijfel over aansprakelijkheid of een datalek. Wie binnen je bedrijf dit soort verantwoordelijkheid draagt, hoort ook helder te zijn buiten het moment van een incident. Zie wat een AI-agent wel en niet zelfstandig doet als achtergrond bij het bepalen van die grenzen.

Overzicht: soort fout, eerste actie, structurele aanpassing

Geen enkele situatie is precies hetzelfde, maar onderstaande indeling geeft een startpunt voor de meest voorkomende soorten AI-fouten in een mkb-context.

Een AI-fout in een echt proces is geen reden voor paniek, maar wel voor een rustige en volledige reactie: stoppen, de omvang kennen, informeren, herstellen — en pas dan analyseren en structureel bijsturen. Wil je vooraf laten meekijken hoe je AI-toepassingen zo inricht dat een incident behapbaar blijft? Op AI WorkTalent vind je specialisten die dat traject kennen.