Op 22 mei 2026 publiceerde Northeastern University een stuk met een botte kop: ChatGPT staat een lawine aan rechtszaken te wachten. Tot en met maart waren er tegen OpenAI alleen al minstens 11 zaken aangespannen, plus nog meer tegen Character.AI en Google. De juridische theorieën escaleren snel -- dood door schuld, productontwerpfout, waarschuwingsplicht geschonden. In januari trof de spraakmakende Setzer-zaak een schikking, nadat een rechter iets deed wat nog geen enkele rechter eerder had gedaan: de output van een AI-chatbot werd geclassificeerd als een "product" in plaats van beschermde meningsuiting.
Als je een chatbot op je website draait, is het verleidelijk om die koppen te lezen en achterover te leunen. Dat zijn zaken tegen de labs die de modellen bouwen, over tragische randgevallen met companion-AI. Jij beantwoordt alleen vragen over verzending. Niets daarvan is op jou van toepassing.
Dat is de verkeerde conclusie. De rechtszaken die de krantenkoppen halen, gaan over de makers van foundation models en catastrofale schade. Het juridische risico dat op jouw bedrijf van toepassing is, is ouder, stiller en veel steviger verankerd in de rechtspraak. Het heeft een naam die de meeste mensen in support al kennen: het Air Canada-precedent.
De zaak die elke eigenaar van een bedrijfschatbot uit zijn hoofd zou moeten kennen
In februari 2024 deed een Canadees tribunaal uitspraak in een geschil dat triviaal leek. Een rouwende klant had de website-chatbot van Air Canada gevraagd naar rouwtarieven. De bot vertelde hem dat hij nu kon boeken en binnen 90 dagen een terugbetaling kon aanvragen. Dat beleid bestond niet. De bot verzon het.
Toen de klant om de terugbetaling vroeg, weigerde Air Canada en voerde schriftelijk aan dat de chatbot "een aparte juridische entiteit is die verantwoordelijk is voor zijn eigen handelen." Het tribunaal verwierp dat botweg. De uitspraak bevat de zin die je op je monitor zou moeten plakken:
"Het maakt geen verschil of de informatie van een statische pagina komt of van een chatbot."
Air Canada werd verplicht het verzonnen beleid na te komen en schadevergoeding, rente en kosten te betalen. Het bedrag was klein. Het principe niet. Een toezichthouder keek naar een hallucinerende bot en zei: dit is het bedrijf zelf dat spreekt. Je bent gebonden aan wat het zegt.
Dat principe is sindsdien alleen maar steviger geworden. Het "product"-kader van de Setzer-schikking betekent dat chatbotoutput kan worden beoordeeld als elk ander ding dat een bedrijf op de markt brengt -- onderhevig aan theorieën van productaansprakelijkheid wanneer het gebrekkig is. Amerikaanse rechtbanken legden in het eerste kwartaal van 2026 meer dan $145,000 aan sancties op voor AI-hallucinaties, inclusief een recordboete van $110,000 in Oregon en een unieke schorsing van een beroepslicentie in Nebraska. De spraakmakende zaken kunnen jaren duren en veranderen de sector misschien niet, zoals John Wihbey van Northeastern waarschuwde -- bewijzen dat een specifieke technologie een specifiek persoon schade toebracht, is lastig. Maar voor het Air Canada-precedent is geen nieuwe juridische theorie nodig. Het werkt vandaag al, in tribunalen voor kleine geschillen en consumentenbeschermingsklachten.
Dit artikel gaat over die alledaagse blootstelling, niet over de spraakmakende rechtszaken. Niets hiervan is juridisch advies -- praat met een advocaat over jouw situatie. Het doel hier is smaller en nuttiger: precies begrijpen hoe een website-chatbot aansprakelijkheid creëert, en welke controls die daadwerkelijk verkleinen.
De zeven manieren waarop een supportbot je een rechtszaak bezorgt
"Hallucinatie" is één woord voor minstens zeven verschillende faalpatronen, en elk brengt een ander soort bedrijfsrisico met zich mee. Een bot die een terugbetalingstermijn verzint, is een ander probleem dan een bot die een veiligheidsinstructie verzint.
| Type hallucinatie | Wat de bot doet | Aansprakelijkheid die het creëert |
|---|---|---|
| Beleid | Verzint een retour-, terugbetalings- of garantietermijn | Je kunt gebonden zijn om het na te komen (het Air Canada-precedent) |
| Prijzen | Noemt een prijs, korting of vergoeding die niet bestaat | Risico op misleidende prijsstelling en consumentenbescherming |
| Accountspecifiek | Geeft een verkeerd feit over de bestelling of het saldo van deze specifieke klant | Contractbreuk, onjuiste voorstelling van zaken |
| Actie | Beweert iets te hebben gedaan ("je bestelling is geannuleerd") wat niet is gebeurd | Niet-nakoming; schade door gerechtvaardigd vertrouwen |
| Bronvermelding | Citeert een bron, wet of document dat niet bestaat | Sancties in gereguleerde context; verlies van vertrouwen |
| Capaciteit | Belooft iets wat het product niet kan | Misleidende reclame |
| Veiligheid | Geeft een verkeerde instructie met fysieke gevolgen | Onzorgvuldigheid, productaansprakelijkheid, de ernstigste categorie |
De rode draad: het maakt de wet niet uit dat een AI de uitspraak genereerde. De FTC en Amerikaanse consumentenbeschermingswetten verbieden oneerlijke of misleidende praktijken, ongeacht of een mens of een model ze produceerde. Zoals een aansprakelijkheidsanalyse het stelde: als je AI optreedt als vertegenwoordiger van je bedrijf, draag jij de verantwoordelijkheid voor wat hij communiceert.
Waarom een kale LLM een aansprakelijkheidsmachine is
Hier is het ongemakkelijke technische feit achter dit alles. Een groot taalmodel is geoptimaliseerd om vloeiende, aannemelijke, zelfverzekerde tekst te produceren. Het is niet geoptimaliseerd om ware tekst te produceren. Die twee doelen overlappen meestal, en dat is precies wat de storingen zo gevaarlijk maakt -- het verkeerde antwoord komt in dezelfde kalme, gezaghebbende toon als het juiste antwoord. Er zit geen trilling in de stem wanneer het je terugbetalingsbeleid verzint.
Mensen gaan ervan uit dat retrieval dit oplost. Het helpt enorm, maar het is geen garantie. Een Stanford-onderzoek uit 2025 naar retrieval-intensieve juridische onderzoekstools vond dat de beste tool op slechts 65% van de vragen correct en gegrond was; concurrenten kwamen uit op 41% en 19%. Dit zijn dure, speciaal gebouwde producten met het model gericht op een gecureerd corpus, en toch hallucineerden ze bij een derde van de vragen. Een algemeen model op je website plakken met een systeemprompt die zegt "wees behulpzaam" bevindt zich niet in hetzelfde universum van veiligheid.
De les is niet "gebruik geen chatbot." Genoeg bedrijven lossen het merendeel van hun supportvolume op met AI en komen nooit in de problemen, omdat ze de bot correct hebben ingeperkt. De les is dat de veiligheid zit in de architectuur rond het model, niet in het model zelf. Een chatbot is alleen zo verdedigbaar als de beheersmaatregelen die je tussen het taalmodel en je klant plaatst.
De beheersmaatregelen die je blootstelling daadwerkelijk verkleinen
Koppel elke beheersmaatregel aan het risico dat hij aanpakt. Dit is het deel dat ertoe doet, en hier houdt platformkeuze op cosmetisch te zijn.
| Beheersmaatregel | Wat het doet | Risico dat het verkleint |
|---|---|---|
| Retrieval-grounding | Antwoordt alleen vanuit je trainingscontent, niet uit het geheugen van het model | Beleids-, prijs- en capaciteitshallucinaties |
| Gezaghebbende Q&A-paren | Exacte, handgeschreven antwoorden die alles overschrijven | De vragen met hoge inzet die je niet fout mag hebben |
| Bronvermelding | Toont uit welk document een antwoord komt | Bronhallucinaties; maakt review mogelijk |
| Realtime acties | Zoekt live bestel-/accountgegevens op via API in plaats van te gokken | Accountspecifieke hallucinaties |
| Vertrouwensgebaseerde overdracht | Stuurt onzekere of hoogrisico-intenties door naar een mens | Actie- en veiligheidshallucinaties |
| Outputguardrails | Blokkeert verzonnen kortingen, nep-URL's, onbevestigde claims | Prijs- en actiehallucinaties |
| Gesprekslogs | Een controleerbaar record van elk antwoord dat de bot gaf | Bewijs, controle, snelle correctie |
Een paar hiervan verdienen extra aandacht, omdat teams er vaak te weinig in investeren.
Grounding is de ondergrens, niet het plafond. Je chatbot trainen op je eigen website, documenten en helpcenter is het verschil tussen een bot die antwoordt vanuit jouw werkelijkheid en een bot die antwoordt vanuit het gemiddelde van het internet. Bij Agentkit is dat de standaard: een chatbot antwoordt vanuit de content waarop je hem traint -- gecrawlde pagina's, geüploade pdf's en documenten, en tekstfragmenten. Het model krijgt de instructie om vanuit dat corpus te werken in plaats van te improviseren. Voor supportvolume met veel documenten houdt chatten met je eigen documenten antwoorden gebonden aan het werkelijke beleidsdocument, niet aan een parafrase ervan.
Q&A-paren zijn je gordel voor de vragen die niet fout mogen gaan. Grounding vermindert verzinsels, maar sluit ze niet uit. Voor de handvol vragen waarbij een fout antwoord een rechtszaak betekent -- je terugbetalingstermijn, je annuleringsvoorwaarden, een veiligheidskritieke instructie -- wil je een hardgecodeerd antwoord, geen gegenereerd antwoord. De Q&A-paren van Agentkit doen precies dit: een exact, door mensen geschreven antwoord dat voorrang krijgt boven elke andere bron. Het model krijgt geen stem in de vraag of je retourbeleid 30 dagen is. Jij hebt het opgeschreven; de bot leest het terug. Identificeer je tien vragen met het hoogste aansprakelijkheidsrisico en leg ze vast als Q&A-paren voordat je live gaat.
Realtime acties vervangen gokken door opzoeken. Accountspecifieke hallucinaties -- "je bestelling is gisteren verzonden" terwijl dat niet zo was -- ontstaan wanneer een bot vragen beantwoordt waar hij geen data voor heeft. De oplossing is hem data te geven. Met aangepaste API-acties kan de chatbot je bestelsysteem, CRM of voorraad in realtime aanroepen en antwoorden vanuit het echte record. Als de data niet beschikbaar is, zegt een goed gebouwde bot dat, in plaats van een status te verzinnen.
Overdracht is een aansprakelijkheidsbeheersmaatregel, geen UX-extraatje. De belangrijkste architecturale beslissing is wat de bot doet wanneer hij onzeker is. Een verdedigbare chatbot escaleert antwoorden met lage betrouwbaarheid en hoogrisico-intenties -- terugbetalingen, facturering, annuleringen, alles wat veiligheidsgerelateerd is -- naar een mens. Die grens goed ontwerpen is een vak op zich; we behandelden het uitgebreid in ontwerp voor overdracht naar een mens. De bot die "laat me een teamgenoot erbij halen" zegt bij een terugbetalingsgeschil, is de bot die nooit een terugbetalingsbeleid verzint.
Instructies en guardrails bepalen de standaardwaarden van de bot. Je systeemprompt moet de bot vertellen te weigeren te speculeren, nooit prijzen of kortingen te verzinnen, toe te geven wanneer hij het niet weet, en strikt binnen je domein te blijven. Goede promptengineering verandert "wees behulpzaam" in "wees behulpzaam, maar verzin nooit een beleid, en escaleer alles waar je niet zeker van bent." Combineer dat met domeinbeperkingen zodat de widget alleen op je eigen pagina's draait, en ratelimiet zodat één gebruiker de bot niet kan uitlokken tot wangedrag, zoals de chatbot van DPD in 2024 beroemd werd getriggerd om klanten uit te schelden.
Logs zijn je bewijs en je vroegtijdige waarschuwingssysteem. Elk Agentkit-gesprek wordt gelogd. Dat record doet twee dingen: het laat je bekijken wat de bot mensen daadwerkelijk vertelde (en een slecht patroon corrigeren voordat het een klacht wordt), en het is de documentatie die je wilt hebben als een klant ooit beweert dat de bot iets beloofde. Bekijk wekelijks het percentage gegronde antwoorden en de vragen die tot overdracht leidden. De bot die stilletjes afdrijft, verschijnt eerder in de logs dan in een tribunaal.
Nog één, makkelijk over het hoofd te zien: houd de kennisbank actueel. De helft van de aansprakelijkheid ontstaat niet door verzinsels, maar door zelfverzekerd een beleid te noemen dat vroeger wel klopte. Automatisch hertrainen (vanaf het Standard-abonnement) crawlt je content periodiek opnieuw, zodat de bot niet de prijzenpagina van vorig kwartaal citeert.
Een checklist voor aansprakelijkheid vóór lancering
Loop deze lijst door voordat je een chatbot insluit op een pagina waar klanten beslissingen nemen:
- Is hij gegrond? De bot antwoordt vanuit je content, niet vanuit het open model. Controleer dit door iets te vragen dat niet in je documentatie staat -- hij zou moeten weigeren, niet improviseren.
- Liggen de antwoorden met hoge inzet vast? Terugbetaling, annulering, garantie, prijzen en elke veiligheidskritieke instructie zijn Q&A-paren, geen gegenereerde tekst.
- Zoekt hij op in plaats van te gokken? Account- en bestelspecifieke vragen raken een live API of worden overgedragen -- nooit beantwoord uit het niets.
- Escaleert hij wanneer hij onzeker is? Antwoorden met lage betrouwbaarheid en hoogrisico-intenties gaan naar een mens. Je hebt getest dat die grens ook echt afgaat.
- Is hij afgebakend? Domeinbeperkingen houden hem beperkt tot je site; ratelimiet blokkeert misbruik; instructies verbieden verzonnen prijzen en beloftes.
- Kun je het controleren? Gesprekslogs staan aan, en iemand bekijkt ze op een vast ritme.
- Is de kennis actueel? Verouderd-maar-zelfverzekerd is een faalmodus op zich. Automatisch opnieuw trainen of een handmatig vernieuwingsschema houdt de content actueel.
Insluiten is het makkelijke deel zodra de controls op hun plek staan:
<script src="https://cdn.agentkit.ai/widget.js" data-chatbot="your-chatbot-id" async> </script>
Een kanttekening over reikwijdte: dit gaat over civielrechtelijke aansprakelijkheid voor wat je bot zegt -- iets anders dan de golf aan AI-specifieke regelgeving die door de Amerikaanse deelstaten trekt, wat we apart hebben behandeld in de gids voor chatbotwetten van 2026. Je moet aan beide denken. Een bot kan volledig voldoen aan meldingswetten en je toch binden aan een verzonnen terugbetalingsbeleid.
De conclusie
De rechtszaken tegen OpenAI en Character.AI zullen jarenlang worden uitgevochten, en de meeste bedrijven met een supportbot zullen nooit partij worden bij iets vergelijkbaars. Maar elk van die bedrijven leeft onder het Air Canada-precedent: je chatbot spreekt namens jou, en jij bent verantwoordelijk voor wat hij zegt. Dat is geen reden om AI-support te vermijden. Bedrijven lossen het grootste deel van hun supportvolume op met chatbots en besparen daarmee echt geld -- die economie staat niet ter discussie. Het is een reden om de bot te behandelen voor wat hij juridisch is: een vertegenwoordiger van je bedrijf, ingezet met dezelfde zorg die je een menselijke vertegenwoordiger zou geven.
Het verschil tussen een aansprakelijkheid en een aanwinst is de architectuur rond het model. Grond hem in je content. Leg je antwoorden met hoge inzet vast. Draag over wanneer hij onzeker is. Log alles. Een chatbot die zo is gebouwd, vermijdt niet alleen de rechtszaal -- het is de chatbot die klanten daadwerkelijk vertrouwen, omdat hij ze de waarheid vertelt of vertelt dat hij het niet weet.
Geen creditcard nodig.
