Er bestaat een demo waarin alles werkt. Iemand typt een vraag, de agent doet zeven dingen achter elkaar, en aan het eind staat er een net antwoord op het scherm. Ik heb er tientallen gezien en ik heb er zelf ook een paar gemaakt.
Wat in zo’n demo nooit voorkomt is het geval waarin het misgaat. Niet omdat het niet gebeurt, maar omdat het de demo bederft. En precies daar zit het verschil tussen iets laten zien en iets in productie hebben.
In het eerste deel van deze serie ging het over wat er van je werk overblijft als een leverancier wegvalt. Dit deel gaat over iets wat dichterbij ligt en vaker voorkomt: je agent blijft gewoon draaien, en zegt iets wat niet waar is.
De zaak die het beslecht
Een man boekte een vlucht bij Air Canada na het overlijden van een familielid. De chatbot van de luchtvaartmaatschappij vertelde hem dat hij achteraf korting kon aanvragen. Dat beleid bestond niet. De bot had het bedacht.
Toen de man later om zijn geld vroeg, kreeg hij nul op het rekest en stapte hij naar het tribunaal. Air Canada voerde daar aan dat de chatbot een zelfstandige juridische entiteit was, verantwoordelijk voor zijn eigen handelingen. Het tribunaal noemde dat een opmerkelijke stelling, en oordeelde dat een klant niet verantwoordelijk is voor het onderling controleren van informatie op verschillende delen van dezelfde website.
Daarmee ligt de lijn er. Wat jouw agent zegt, zeg jij. Er is geen tussenlaag waar de aansprakelijkheid blijft hangen, ook niet als het model iets verzon dat nergens in je documentatie staat.
En sinds 2 augustus staat er ook een boete op zwijgen
Artikel 50 van de AI-verordening is sinds 2 augustus 2026 van kracht. Het verplicht je om duidelijk te maken dat iemand met een AI-systeem praat, en om synthetische inhoud als zodanig te markeren. Boetes lopen op tot 15 miljoen euro of 3 procent van de wereldwijde jaaromzet, waarbij voor kleinere bedrijven het lagere bedrag geldt.
Hier zit een misverstand dat ik in het webinar dat de aanleiding voor deze serie was ook langs hoorde komen, en dat ik daarna nog een paar keer ben tegengekomen. Het Digital Omnibus-pakket heeft de termijn voor hoog-risicosystemen uit Annex III verschoven naar 2 december 2027. Artikel 50 is daar bewust buiten gehouden. Wie die twee door elkaar haalt, denkt dat hij nog anderhalf jaar heeft terwijl de transparantieplicht al geldt.
Twee sporen, twee data. Dat is saai om te onthouden en duur om te verwarren.
| Wat | Vanaf wanneer | Waarover |
|---|---|---|
| Artikel 50, transparantie | 2 augustus 2026 | Melden dat het AI is, synthetische inhoud markeren |
| Annex III, hoog risico | 2 december 2027 | Zwaardere verplichtingen voor risicovolle toepassingen |
Vijf poorten
Het raamwerk dat de sprekers hiervoor gebruiken bestaat uit vijf stappen: zien, beperken, onderbreken, beoordelen, herstellen. Het aardige eraan is dat het geen abstracte principes zijn maar dingen die je kunt aanwijzen in een systeem.
Het scharnier is een beslissingslog per handeling van de agent, met vijf velden: wie het deed, wat erin ging, welke actie volgde, wat het resultaat was, en bij welke waarde het naar een mens moet.
Uit dat ene log volgt de rest bijna vanzelf.
Zien is het log zelf. Zonder log weet je niet wat er gebeurd is, en dan zijn de andere vier poorten theoretisch.
Beperken hangt aan het veld met de actor. Als je weet welke identiteit de handeling deed, kun je daar rechten aan koppelen: welke gegevens, welk gereedschap, welke handelingen wel en niet.
Onderbreken hangt aan het escalatiecriterium. De sprekers gaven een drempel als voorbeeld: onder een waarde van 250 beslist de agent zelf, daarboven moet een mens akkoord geven.
Beoordelen is periodiek meelezen. Niet steekproefsgewijs op het moment dat het misgaat, maar als vaste gewoonte.
Herstellen is beleid dat klaarligt voor het moment waarop je in die beoordeling iets ziet wat niet had gemogen. Melden, opschalen, terugdraaien.
Mijn eigen inschatting: bij de meeste organisaties die ik van dichtbij zie is poort één redelijk op orde, want logging hoort bij het vak. Poort vijf is meestal het dunst. Er is wel een incidentproces, maar dat is geschreven voor systemen die kapotgaan, niet voor systemen die iets doen wat mocht van de techniek en niet van de organisatie.
De vraag die inkopers nu stellen
Wat me opviel is dat de sprekers dit brachten als iets waar ze in gesprekken op worden bevraagd. De twee vragen die volgens hen steeds terugkomen bij inkoopafdelingen: laat zien hoe je de agent stopt, en laat zien welk werk de agent heeft gedaan.
Dat zijn poort drie en poort één, en het zijn precies de twee waar een demo je niets over vertelt. Wie een agent wil verkopen aan een organisatie die hier scherp op is, kan dus niet volstaan met een filmpje waarin het goed gaat.
Tegelijk is dit ook waar het raamwerk zichzelf verkoopt. Het kwam uit een leverancierswebinar, en een lijst poorten waar jij op faalt is een prima aanleiding om iets te kopen dat ze voor je invult. Het maakt de indeling niet minder bruikbaar, maar het is wel goed om te weten wiens gereedschapskist je aan het lenen bent.
De kanttekening
Het log verplaatst het probleem naar de mens die het leest. Vijf poorten zien er op papier uit als vijf controles, maar poort vier is een gewoonte en geen mechanisme. Een systeem dat alles vastlegt en dat niemand nakijkt is niet gecontroleerd, het is gedocumenteerd. Dat verschil verdwijnt makkelijk in een auditrapport waarin staat dat er logging aanwezig is.
De drempel is een keuze die zich voordoet als een feit. Onder de 250 mag de agent zelf beslissen, daarboven niet. Waar dat getal vandaan komt, is een afweging tussen schade en gemak, en zodra het in een configuratiebestand staat leest het als beleid. Bij mij is de grens geen bedrag maar een handeling: publiceren doe ik zelf, plannen laat ik automatiseren. Dat is even arbitrair, alleen kan ik het uitleggen.
En dan het deel dat naar de gebruiker verschuift. Artikel 50 verplicht je te melden dat er een machine aan de andere kant zit. Dat is winst, en tegelijk verplaatst het werk: iemand die weet dat hij met een AI praat, wordt geacht daar zelf rekening mee te houden. De zaak tegen Air Canada wees precies de andere kant op, namelijk dat de klant het niet hoeft na te lopen. Die twee lijnen bijten elkaar nog niet, maar de dag dat een bedrijf betoogt dat de melding op het scherm de klant medeverantwoordelijk maakte, komt eraan.
Wat ik zelf doe
Ik heb geen klantagent draaien, dus artikel 50 raakt me niet direct. Wat wel op deze site staat, is werk waar een model aan meehielp, en daar heb ik een eigen regel voor: de aanpak staat in het artikel zelf, niet in een voetnoot achteraf.
De poort die ik voor mezelf serieus neem is de derde. In mijn projectinstructies staat hard dat er niets direct live gaat: alles wordt ingepland, publiceren is handwerk, en een geplande publicatie kan ik nog tegenhouden. Dat is precies één menselijke onderbreking op de plek waar een fout zichtbaar wordt voor anderen.
Poort vijf is bij mij ook het dunst, en dat is eerlijker om op te schrijven dan te doen alsof ik daar een procedure voor heb. Als er iets fout live gaat, is mijn herstel een commit en een cache-purge. Dat werkt voor een blog. Het is geen incidentproces.
Veelgestelde vragen
Geldt artikel 50 ook voor een kleine site of een eenmanszaak?
Ja, de transparantieplicht kijkt naar de toepassing en niet naar de omvang van het bedrijf. Voor kleinere bedrijven en starters geldt bij een boete wel het lagere van de twee bedragen. Praktisch: als bezoekers met een chatfunctie praten die door een model wordt aangedreven, hoort dat er gewoon bij te staan.
Is een beslissingslog niet gewoon logging die we al hebben?
Deels. Het verschil zit in de velden. Gewone applicatielogging legt vast dat er een aanroep was en of die slaagde. Een beslissingslog legt vast wie handelde, waarop, met welk resultaat en wanneer het naar een mens had gemoeten. Dat laatste veld is degene die je meestal niet hebt.
Wat als de agent iets belooft dat wel in ons beleid staat maar verouderd is?
Dan is de uitkomst waarschijnlijk niet anders. De redenering in de Air Canada-zaak ging erover dat een klant niet hoeft uit te zoeken welk deel van je informatie klopt. Verouderd beleid is jouw informatie, dus dat argument helpt niet.
Waarom staat hoog risico nu op december 2027?
Het Digital Omnibus-pakket heeft die termijn verschoven. Artikel 50 is bewust niet meeverschoven, dus de transparantieverplichtingen zijn eerder van kracht dan de zwaardere verplichtingen voor risicovolle toepassingen.
Bronnen
- Webinar “Sovereign AI in the enterprise: from data residency to operational control”, Freeday, 20 augustus 2026 — linkedin.com/events
- Moffatt tegen Air Canada, British Columbia Civil Resolution Tribunal, geraadpleegd 20 augustus 2026 — bccrt.ca
- Transparantieverplichtingen artikel 50 AI-verordening, van kracht sinds 2 augustus 2026, geraadpleegd 20 augustus 2026 — digital-strategy.ec.europa.eu
Gecontroleerd op 20 augustus 2026. De vijf poorten en het beslissingslog komen uit het webinar, dat ik heb gelezen via het Engelse ondertitelbestand dat LinkedIn erbij levert; dat bestand bevat machinale fouten in namen, dus letterlijke citaten van de sprekers staan hier niet. De ingangsdatum van artikel 50, de boetebedragen en de verschuiving van de Annex III-termijn naar 2 december 2027 heb ik apart nagetrokken. De uitspraak van het tribunaal in de zaak tegen Air Canada is publiek en dateert uit 2024; de weergave hierboven volgt de kern van die uitspraak en niet de formulering uit het webinar. Wat ik niet heb kunnen controleren is de bewering dat inkoopafdelingen deze twee vragen structureel stellen: dat is de ervaring van de sprekers, gedeeld zonder aantallen, en ik heb er geen tweede bron voor. De koppeling tussen de vijf poorten en specifieke artikelen in de AI-verordening werd in het webinar wel genoemd maar niet uitgewerkt, dus die staat hierboven niet.