AI Act artikel 50: wat moeten bedrijven vóór en vanaf 2 augustus regelen?

Luister een podcast over wat we bespreken:

AI Act artikel 50 begint voor veel bedrijven niet bij een juridisch document, maar bij de eerste chatregel waarin een bezoeker moet kunnen zien dat er geen medewerker aan de andere kant zit. Vanaf 2 augustus 2026 moeten organisaties daarom niet alleen beleid maken, maar ook hun chatbot, CMS, contentworkflow en technische architectuur aanpassen.

Deze praktische Nederlandstalige gids vertaalt de transparantieverplichtingen naar UX, zichtbare labels, machineleesbare provenance, verantwoordelijkheden, logging en technische tests. De nadruk ligt op wat organisaties concreet kunnen inbouwen voor chatbots, voicebots, AI-agents en gegenereerde content. De uitleg is technisch en organisatorisch bedoeld, niet als juridisch advies. Uitzonderingen en de precieze toepassing moeten door een specialist worden gevalideerd.

Wat regelt AI Act artikel 50 precies en waarom is 2 augustus 2026 belangrijk?

Een chatbot kan vandaag al overtuigend klinken als een medewerker. Precies daar begint het transparantieprobleem. Wie denkt met een mens te praten, kan een antwoord anders wegen dan wanneer duidelijk is dat een AI-systeem reageert.

De AI Act trad in werking op 1 augustus 2024. De transparantieverplichtingen uit artikel 50 zijn van toepassing vanaf 2 augustus 2026. De verplichtingen gelden niet alleen voor hoogrisicosystemen. Ook een klantenservicechatbot, voicebot, AI-agent, contentgenerator of systeem dat een gezicht of stem manipuleert, kan ermee te maken krijgen. De officiële tekst van artikel 50 vormt daarbij het juridische vertrekpunt.

Vier transparantieblokken, vijf praktische situaties

De Europese Commissie groepeert de verplichtingen rond vier onderwerpen:

• directe interactie tussen AI en mensen;
• AI gegenereerde of gemanipuleerde content;
• emotieherkenning en biometrische categorisatie;
• deepfakes en AI gegenereerde tekst over onderwerpen van algemeen belang.

Voor organisaties vertaalt dat zich in vijf herkenbare situaties: een chatbot of voicebot, synthetische audio en beelden, synthetische tekst, biometrische toepassingen en deepfakes of publieke AI content. Die indeling helpt bij de inventarisatie, omdat één systeem in meerdere categorieën kan vallen.

De datum 2 december 2026 komt in sommige tijdlijnen terug als overgangs of handhavingsmoment voor andere onderdelen van de AI Act. Dat is geen goede reden om artikel 50 tot die datum te laten liggen. De technische keuzes, contracten en contentprocessen moeten vóór 2 augustus 2026 zijn getest. De precieze betekenis van eventuele overgangsregels hoort een specialist te beoordelen.

De rol bepaalt wie iets moet bouwen

Een provider, of aanbieder, ontwikkelt een AI systeem of laat het ontwikkelen en brengt het onder eigen naam of merk op de markt of in gebruik. Een organisatie kan ook provider zijn wanneer zij een oplossing laat bouwen en die onder haar eigen naam aanbiedt. Een deployer, of gebruiksresponsable, gebruikt een AI systeem onder eigen verantwoordelijkheid.

Dezelfde organisatie kan beide rollen hebben. Een bedrijf dat zelf een AI-agent laat bouwen en die via de eigen website aanbiedt, moet dus niet alleen naar de leverancier wijzen. De rolverdeling moet per systeem, kanaal en output worden vastgelegd.

Chatbots en AI agents: wat moet de gebruiker zien bij de eerste interactie?

De eerste chatregel is geen detail. Het is het moment waarop de gebruiker bepaalt of de interactie menselijk, geautomatiseerd of gemengd is. Artikel 50 vraagt daarom om een duidelijke mededeling wanneer een AI systeem rechtstreeks met natuurlijke personen communiceert. Denk aan een chatbot op een website, een AI-agent in Teams, een WhatsApp-bot, een voicebot of een geautomatiseerde klachtenlijn.

Een melding die alleen in de privacyverklaring staat, is daarvoor in de praktijk niet geschikt. De gebruiker moet de informatie op het juiste moment kunnen zien of horen. Een bruikbare tekst voor een webchat is bijvoorbeeld:

Voor een voicebot hoort de melding aan het begin van het gesprek hoorbaar te zijn. In een interface kan de disclosure daarnaast zichtbaar blijven bij de naam van de assistent of in een vast informatiepaneel. De tekst moet begrijpelijk zijn, voldoende opvallen en toegankelijk werken op mobiel en met ondersteunende technologie.

Een naam als AI-assistent is niet altijd genoeg

De uitzondering voor interacties die voor een redelijk oplettende persoon evident kunstmatig zijn, moet niet te ruim worden opgevat. Een avatar, een roboticoon of de naam “digitale assistent” maakt niet automatisch duidelijk dat er geen mens reageert. Documenteer daarom per kanaal waarom een expliciete melding wel of niet wordt getoond.

Bij een custom AI-agent op maat hoort die keuze al in het ontwerp te zitten. Een agent die alleen informatie geeft, heeft een andere UX nodig dan een agent die klantgegevens ophaalt, een CRM bijwerkt of een vervolgstap uitvoert. In beide gevallen moet de gebruiker begrijpen met welk systeem hij communiceert en wanneer menselijke overdracht mogelijk is.

De verplichting ligt primair bij de provider. De deployer kan de disclosure in de praktijk wel onzichtbaar maken door een eigen interface, white label of kanaalintegratie. Daarom hoort in het contract te staan wie de tekst beheert, wie wijzigingen test en wie verantwoordelijk is als een nieuwe modelversie de openingsinteractie verandert.

Labels, provenance en machineleesbare AI content: waarom een zichtbaar label niet genoeg is

Een zichtbaar label helpt de persoon die de content bekijkt. Een machineleesbare markering helpt systemen die de content verder verwerken. Dat zijn twee verschillende functies.

Bij gegenereerde audio, beelden, video en tekst moet de provider zorgen voor een effectieve, robuuste, betrouwbare en interoperabele markering, voor zover dat technisch haalbaar is. De Europese Commissie beschrijft de transparantieverplichtingen en verwijst daarbij ook naar de vrijwillige Code of Practice voor AI gegenereerde content. Die code is een praktisch hulpmiddel, maar het volgen ervan vervangt de wettelijke verplichting niet.

Provenance moet de hele keten overleven

Een workflow kan bijvoorbeeld een gegenereerde afbeelding voorzien van provenance metadata of Content Credentials. Vervolgens haalt een CMS de metadata weg, comprimeert een CDN het bestand, maakt een social platform een nieuwe versie en blijft alleen een zichtbaar label over. De gebruiker ziet dan misschien nog “gemaakt met AI”, terwijl een ander systeem de herkomst niet meer kan uitlezen.

Daarom moet een organisatie niet alleen controleren of een tool kan watermarken of metadata kan toevoegen. De volledige keten moet worden getest:

• generatie door het model of de contenttool;
• opslag in DAM of CMS;
• verwerking door beeldoptimalisatie en compressie;
• levering via CDN;
• export naar social platforms, nieuwsbrieven of marketplaces;
• download en herpublicatie door derden.

Voor beelden en video kan een provenance standaard zoals C2PA een technische optie zijn. Voor tekst is de oplossing minder uniform. Denk aan metadata in het CMS, een gestandaardiseerd veld in de content API of een interne contentstatus die bij publicatie naar een zichtbaar label wordt vertaald.

Een label is geen volledige compliance

Een label op een webpagina bewijst niet dat de provider de juiste machineleesbare markering heeft toegevoegd. Het zegt ook niets over de vraag of de juiste organisatie het label heeft geplaatst, of een uitzondering terecht is toegepast en of de content later ongemerkt is gewijzigd.

Een headless CMS kan bijvoorbeeld velden bevatten als ai_status, generation_source, model_version, reviewer, public_interest en provenance_status. De frontend toont vervolgens een begrijpelijk label, terwijl de API de technische status beschikbaar houdt voor downstream systemen. In een RAG chatbot die zoekt in honderden tot duizenden documenten is een vergelijkbare scheiding nuttig: broninformatie, antwoord en technische metadata moeten niet in één oncontroleerbare tekststroom verdwijnen.

Deepfakes, emotieherkenning en AI tekst over publieke belangen: waar ligt de verantwoordelijkheid?

Niet elke AI output heeft dezelfde transparantieverplichting. Een intern concept voor een presentatie is iets anders dan een video die een bestuurder iets laat zeggen wat nooit is gezegd. Het risico zit niet alleen in de technologie, maar in de manier waarop de content wordt verspreid en gebruikt.

Bij deepfakes moet de deployer duidelijk bekendmaken dat beeld, audio of video kunstmatig is gegenereerd of gemanipuleerd. Dat geldt bijvoorbeeld voor een campagnevideo met een synthetische stem, een realistische avatar van een bestaand persoon of een video waarin iemands gezicht digitaal is vervangen. De bekendmaking moet zichtbaar zijn bij de eerste blootstelling, niet alleen in een technische bestandsbeschrijving.

Publieke AI tekst vraagt om een redactionele beslissing

Voor AI gegenereerde of gemanipuleerde tekst die wordt gepubliceerd met het doel het publiek te informeren over onderwerpen van algemeen belang, geldt een afzonderlijke nuance. Een nieuwsachtig artikel, publieke verklaring of uitleg over een maatschappelijke kwestie vraagt om een beoordeling van de publicatiecontext.

Er kan een uitzondering gelden wanneer de tekst menselijke beoordeling of daadwerkelijke redactionele controle heeft ondergaan en een natuurlijke of rechtspersoon de redactionele verantwoordelijkheid draagt. Dat betekent niet dat elke tekst automatisch buiten de verplichting valt zodra iemand er vluchtig naar kijkt. De organisatie moet kunnen uitleggen wat de menselijke beoordeling inhield en wie de eindverantwoordelijkheid droeg.

Ook artistieke, satirische en fictieve uitingen hebben specifieke nuances. Een fictieve video in een theatercontext vraagt een andere beoordeling dan een gemanipuleerde video die als echt nieuws wordt verspreid. De grens is contextafhankelijk. Laat deze uitzonderingen door een juridisch specialist valideren en leg de beslissing vast in het contentproces.

Biometrie is geen gewone personalisatie

Bij emotieherkenning en biometrische categorisatie moet de deployer de personen die aan het systeem worden blootgesteld informeren. Een voorbeeld is een recruitmenttoepassing die stem, gezicht of gedrag analyseert om emoties of kenmerken af te leiden. Het gaat dan niet om een onschuldige UX test, maar om een toepassing waarbij de aard van de verwerking en de mogelijke gevolgen duidelijk moeten zijn.

Voor law enforcement situaties geldt een specifieke uitzondering binnen artikel 50. Die uitzondering moet niet zonder meer worden doorgetrokken naar beveiliging, recruitment of fraudepreventie in de private sector. Ook de AVG, arbeidswetgeving, grondrechten en sectorspecifieke regels kunnen een rol spelen.

Van verplichting naar implementatie: checklist, logging en technische architectuur

De snelste route is niet beginnen met losse labels. Begin met een inventaris waarin per toepassing staat wat het systeem doet, met wie het communiceert, welke content het maakt en wie de provider of deployer is. Een organisatie die die basis niet heeft, weet ook niet welke disclosure op welk kanaal moet verschijnen.

Een bruikbaar implementatieplan bestaat uit vijf stappen:

• Inventariseer systemen en kanalen. Neem websites, apps, Teams, WhatsApp, e-mail, voicebots, interne tools en contentplatforms mee.
• Categoriseer de toepassing. Markeer directe interactie, synthetische content, biometrie, deepfake en publieke AI tekst.
• Leg verantwoordelijkheden vast. Noteer provider, deployer, leverancier, producteigenaar, contenteigenaar en goedkeurder.
• Bouw disclosure en labels in. Maak vaste UX componenten, CMS velden, API statussen en fallbackgedrag.
• Test en bewaar bewijs. Test mobiele toegankelijkheid, voiceflows, metadata na compressie, modelupdates en uitzonderingen.

Logging moet aantonen wat er is besloten

Artikel 50 schrijft geen specifiek logformaat voor. Toch is logging nodig om later te kunnen reconstrueren waarom een melding zichtbaar was, welke versie van een model content maakte en wie een uitzondering goedkeurde. Log niet automatisch volledige chatinhoud voor onbepaalde tijd. Beperk persoonsgegevens, toegangsrechten en bewaartermijnen volgens de AVG.

Een AI implementatie waarbij data en processen centraal staan voorkomt dat transparantie als losse frontendtekst wordt behandeld. In de architectuur hoort een onderscheid te bestaan tussen modeloutput, menselijke bewerking, publicatiestatus en technische provenance. Bij een maatwerkoplossing kunnen guardrails, logging, monitoring en menselijke overdracht vanaf het ontwerp worden meegenomen. Wie de use case eerst wil afbakenen, kan beginnen met een AI-prototype in drie weken, zonder een demo meteen als productieoplossing te beschouwen.

Van beoordelen naar laten doen

De lastigste stap is meestal niet de tekst “Je chat met AI”. Het is het samenbrengen van UX, CMS, leveranciers, contentverantwoordelijkheid, metadata en bewijsvoering in één werkende keten. Wie dat zelf over meerdere teams en tools moet organiseren, loopt vooral risico op stille fouten: een label dat verdwijnt bij publicatie, een modelupdate zonder nieuwe test of een uitzondering die nergens is vastgelegd.

Metbyte combineert strategie, UX, development en AI in maatwerkoplossingen voor organisaties die verder moeten dan een losse chatbot of demo. Voor een concrete beoordeling van kanalen, data, rollen en beheer kan de volgende stap een gesprek via de contactpagina van Metbyte zijn. Dan begint artikel 50 niet bij een checklist in een map, maar bij de plek waar een gebruiker straks werkelijk klikt, luistert of leest.