Je websitechatbot moet vanaf augustus 2026 eerlijk zeggen dat het AI is

Als jouw websitebezoeker denkt dat hij met een medewerker chat terwijl er eigenlijk een AI-bot achter zit, krijg je vanaf augustus 2026 niet alleen een complianceprobleem. Je beschadigt ook vertrouwen op het slechtst mogelijke moment: het eerste contact. Precies daar raakt de EU AI Act straks veel meer mkb-sites dan nu nog wordt gedacht.

Veel bedrijven zien die wet nog als iets voor modelbouwers, grote techpartijen of juridische afdelingen. Ondertussen hebben ze zelf allang een AI-chatwidget, supportbot of ‘slimme assistent’ op hun site gezet. Vaak snel ingeplugd, vaak zonder veel nadenken over hoe die bot zich presenteert. En juist daar zit het risico. Niet alleen omdat de regels transparantie vragen, maar ook omdat een onduidelijke chatbot goedkoop en glad aanvoelt zodra een bezoeker doorheeft dat hij niet met een mens praat.

De relevante vraag is dus niet alleen of je een chatbot op je site wilt. De betere vraag is of die chatbot vanaf de eerste interactie eerlijk, duidelijk en technisch netjes werkt.

Wat er op 2 augustus 2026 concreet verandert

Op 2 augustus 2026 gaan bredere transparantieverplichtingen uit de EU AI Act gelden. Een belangrijk praktisch punt voor websites: gebruikers moeten weten wanneer ze met een AI-systeem communiceren, tenzij dat al overduidelijk is door de context. Juist dat laatste overschatten veel bedrijven. Een chatvenster met een vriendelijke naam, een menselijk avatar-icoon en zinnen als ‘Hoi, waarmee kan ik je helpen?’ voelt voor bezoekers al snel als contact met een medewerker.

Dat maakt dit geen detail voor juristen, maar een vraag voor je website en interface. Als jouw bezoeker redelijkerwijs kan denken dat hij met een mens praat, moet jij dat misverstand actief weghalen. Niet in een privacyverklaring. Niet pas na drie berichten. Op of vlak vóór het eerste echte chatmoment.

Voor ondernemers is dat de kern. De wet vraagt niet alleen om formele compliance. Ze dwingt je om eerlijker na te denken over hoe jouw chatbot zich presenteert en welke verwachtingen je in de eerste seconden van een gesprek wekt.

Voor welke websitechatbots dit waarschijnlijk wel geldt

De regel is vooral relevant voor chatwidgets, assistenten en supportflows waarbij een bezoeker een gesprek start en menselijke hulp zou kunnen verwachten. Denk aan een bot op je contactpagina, een supportwidget rechtsonder in beeld of een AI-assistent die productvragen beantwoordt, intakevragen stelt of leads probeert te kwalificeren.

Juist in die categorie ontstaat het probleem. Veel tools zijn bewust ontworpen om soepel, vriendelijk en menselijk te voelen. Dat lijkt goed voor conversie, maar het maakt duidelijke disclosure juist belangrijker. Hoe menselijker je flow oogt, hoe minder ruimte je hebt om te doen alsof de context voor zichzelf spreekt.

Heb je een simpele zoekfunctie of een bot die voor iedereen zichtbaar als geautomatiseerde FAQ werkt, dan ligt het anders. Maar veel mkb-websites zitten niet in die veilige hoek. Ze gebruiken een chatvenster dat eruitziet als klantenservice, terwijl er op de achtergrond vooral een taalmodel wat standaardreacties afvuurt. Dan moet je niet hopen dat bezoekers het verschil zelf wel doorhebben.

Waarom een cookiebanner of privacytekst hier niets oplost

Veel bedrijven lossen websitecompliance graag op met extra tekst onderaan de site. Dat werkt hier niet. Een bezoeker die op een chatknop klikt, leest geen privacyverklaring voordat hij zijn vraag stelt. Die reageert op wat hij op dat moment ziet.

Daarom is AI-disclosure geen papierwerkprobleem maar een UX-probleem. Als de eerste ervaring menselijk oogt, moet de eerste uitleg ook zichtbaar in die ervaring zitten. Bijvoorbeeld in de widgetkop, de openingsregel of het eerste botbericht. Gewoon in normale taal: je chat met onze AI-assistent, niet met een medewerker.

Dat is ook commercieel slimmer. Een chatbot die pas later verraadt wat hij is, voelt niet geavanceerd. Hij voelt oneerlijk. Zeker als het gesprek misloopt, de bot context mist of de bezoeker merkt dat hij in een scriptje vastzit. Dan krijg je niet het effect van slimme automatisering, maar van digitale misleiding.

Hoe een goede disclosure eruitziet zonder je conversie te slopen

Veel bedrijven zijn bang dat eerlijkheid de conversie schaadt. Alsof een bezoeker meteen afhaakt zodra je zegt dat er AI achter de chat zit. In de praktijk werkt het vaak andersom. Bezoekers haken sneller af als ze denken dat ze met een medewerker praten en later ontdekken dat de bot alleen halve antwoorden of standaardtekst geeft.

Een goede disclosure hoeft niet zwaar of juridisch te klinken. Hij moet vooral helder zijn. Bijvoorbeeld: ‘Je chat met onze AI-assistent. Voor complexe vragen kijkt een medewerker mee of nemen we contact op.’ Dan weet een bezoeker waar hij aan toe is. Je combineert eerlijkheid met verwachtingsmanagement, zonder de flow kapot te maken.

De betere implementaties doen nog iets extra’s. Ze zeggen niet alleen wat de bot is, maar ook waar hij wél goed in is. Snelle vragen beantwoorden. Een intake doen. De juiste vervolgstap voorstellen. Dan voelt disclosure niet als een waarschuwing, maar als nette onboarding. Dat is precies waar compliance, UX en webbouw samenkomen.

• noem expliciet dat het om AI gaat
• zet dat in of direct rond de chatinterface
• zeg waar de bot wel en niet voor bedoeld is
• maak de route naar een mens zichtbaar als dat relevant is

Een snelle check voor je huidige chatwidget

Als je al een chatbot op je site hebt staan, kun je vrij snel zien of je setup kwetsbaar is. Loop deze punten langs:

• staat er bij het openen van de chat meteen dat het om AI gaat?
• kan een bezoeker de bot makkelijk verwarren met een medewerker?
• legt de chat uit waarvoor de bot bedoeld is en waarvoor niet?
• is er een duidelijke route naar menselijk contact als de vraag complex wordt?
• sluit de bot aan op echte interne processen, of vangt hij vooral tijd op zonder iets netjes af te handelen?

Als je op meerdere punten twijfelt, heb je geen klein tekstprobleem maar een zwakke implementatie.

Waar veel websites nu al de fout in gaan

De grootste fout is schijnmenselijkheid. Een generieke widget uit WordPress of een SaaS-tool krijgt een naam, een avatar en een paar vriendelijke standaardzinnen, en daarmee moet het dan voelen als klantenservice. Alleen: technisch is het vaak een losse laag bovenop een rommelige serviceflow. De bot kent je processen niet goed, heeft geen nette escalatie en vangt vooral vragen af zonder ze echt op te lossen.

Daarmee krijg je twee problemen tegelijk. Juridisch zit je kwetsbaar als je niet duidelijk genoeg bent over AI-gebruik. Commercieel maak je ook schade, omdat de ervaring goedkoop voelt. Iemand met een serieuze vraag wil geen toneelstukje. Die wil snel weten of hij met software praat, wat die software kan en hoe hij verder komt als het antwoord tekortschiet.

Vooral los ingeplugde chattools op standaardwebsites lopen hier tegenaan. Ze zijn vaak bedacht als snelle leadhack, niet als goed ontworpen gebruikerslaag. Dan zie je steeds dezelfde fouten terug: geen duidelijke disclosure, geen scherpe afbakening, geen menselijke fallback en geen aansluiting op echte interne processen.

Waarom dit niet alleen compliance is maar ook vertrouwen

Je kunt deze verandering benaderen als een wettelijke verplichting waar je even aan moet voldoen. Dat is de smalle blik. De zinvollere blik is dat websitebezoekers steeds sneller voelen wanneer een digitale ervaring klopt en wanneer niet. AI op je site hoeft geen probleem te zijn. Onduidelijkheid wel.

Een eerlijke chatbot kan prima werken. Soms zelfs beter dan een halfbereikbare inbox of een trage contactflow. Maar dan moet de ervaring eerlijk ontworpen zijn. Zeg wat het is, zet grenzen neer, laat zien waar de bot helpt en waar een mens nodig is. Daarmee haal je frictie weg en voorkom je dat je vertrouwen verspilt op het eerste contactmoment.

Voor bedrijven die AI serieus willen inzetten, is dit dus geen vervelende disclaimeroefening. Het is een ontwerpkwestie. Een goede chatbotinterface laat niet alleen zien dát je automatiseert, maar ook dat je begrijpt waar automatisering helpt en waar niet.

Wanneer maatwerk slimmer is dan een los ingeplugde bot

Als je chatbot alleen simpele openingsvragen opvangt en verder weinig schade kan doen, kom je met een nette disclosure en wat goede UX-aanpassingen al een heel eind. Maar zodra de bot leads kwalificeert, supportvragen afvangt, klantdata verwerkt of namens je bedrijf verwachtingen wekt, wordt een losse plug-in snel te dun.

Dan heb je meer nodig dan een tekstregel boven een widget. Dan moet de hele flow kloppen: welke informatie de bot ophaalt, wanneer hij doorzet naar een mens, hoe hij antwoorden afbakent en hoe duidelijk de interface blijft voor de gebruiker. Dat vraagt vaak om maatwerk of op zijn minst om een veel scherpere implementatie dan de gemiddelde standaardtool biedt.

Precies daar wordt BLB relevant. Een chatbot op je website is niet alleen een AI-vraag. Het is ook een website-, UX- en procesvraag. Als je dat netjes wilt doen, moet je niet alleen kijken naar wat de tool kan, maar naar wat jouw site, team en klantreis aankunnen. Dan bouw je geen glad laagje AI bovenop oude rommel, maar een digitale flow die eerlijk werkt en vertrouwen vasthoudt.

Referenties

• Jorijn. EU AI Act: your website chatbot needs an AI disclosure by August 2026.
• Compliance & Risks. EU AI Act Compliance Requirements for Companies: What to Prepare for 2026.

Praktische volgende stap

Heb je al een chatbot of AI-assistent op je website staan, dan is dit een goed moment om die flow kritisch te laten bekijken. Niet alleen op wetstekst, maar op eerlijkheid, UX en techniek. BLB helpt bedrijven met websites, maatwerk en AI-implementaties die niet alleen slim lijken, maar ook helder en betrouwbaar werken.