Het artikel 50 praktijkpakket

Waarom dit pakket bestaat

Wij maken een compliancetool. We leveren er ook AI-functies in uit, en we verkopen aan bedrijven in de EU. Dus toen artikel 50 van de EU AI Act (de AI-verordening) op 2 augustus 2026 van toepassing werd, was dat voor ons geen abstracte regelgeving. Het was een zondag.

We hebben de verordening gelezen, de definitieve richtsnoeren van de Commissie en de nieuwe Code of Practice on Transparency of AI-generated Content, zodat jij niet bij een leeg vel hoeft te beginnen. En hier is de verrassing: artikel 50 is een van de redelijkere stukken van de AI Act. De plichten zijn smal. De uitzonderingen zijn verstandig. En bijna alles laat zich netjes omzetten in de werkvorm die wij het liefst hebben: een control, een stuk evidence en een eigenaar.

Dat is dit pakket. Geen juridische analyse (we zijn geen juristen, en het zal je opluchten dat we dat weten). Een operationele vertaling: wat er echt geldt voor een typisch klein softwarebedrijf, wat je eraan doet en wat je bewaart, zodat je je werk later kunt laten zien.

De vijf-minuten-versie

Op 2 augustus 2026 werd artikel 50 van de EU AI Act van toepassing. Als je product via AI met gebruikers praat, of tekst, beelden, audio of video genereert, en iemand in de EU gebruikt het, dan geldt een deel hiervan nu voor jou. Waar je bedrijf zit maakt niet uit. Landt de output voor de ogen van mensen in de EU, dan val je binnen de reikwijdte.

Het hele artikel komt neer op één idee: laat mensen AI niet aanzien voor een mens, en AI-content niet voor echt. Zie het als een ingrediëntenlijst voor AI. Niemand verbiedt het product. Ze willen alleen het etiket op de pot.

Zes operationele onderdelen, de zes secties van dit pakket:

1. Interactiemeldingen: vertel mensen wanneer ze met AI praten.
2. Markering en detectie: gegenereerde content draagt een machineleesbare markering, en jij test dat die het overleeft.
3. Labelbeslissingen: deepfakes en bepaalde AI-teksten krijgen een zichtbaar label.
4. Menselijke redactionele controle: de uitzondering waarmee je gecontroleerde content het tekstlabel mag overslaan.
5. Code-alignment of eigen middelen: kies je complianceroute en zet hem op papier.
6. Herbeoordeling bij verandering: kijk opnieuw als er iets verandert, niet als kalenderritueel.

En hier de eerlijke reikwijdtecheck die de meeste gidsen je niet geven: voor een typisch B2B SaaS-bedrijf gelden in de praktijk meestal alleen punt 1 en 2, met punt 3 en 4 relevant als je marketingteam met AI geschreven content publiceert. Dat is alles. De eng klinkende stukken (emotieherkenning, biometrische categorisering) vallen buiten de reikwijdte van vrijwel elk softwarebedrijf dat we spreken.

Twee data om te onthouden:

• 2 augustus 2026: artikel 50 is live. Nu.
• 2 december 2026: de overgangsperiode eindigt voor één specifieke plicht, de machineleesbare markering van gegenereerde content, en alleen voor systemen die al vóór 2 augustus 2026 op de markt waren. Content van vóór 2 augustus heeft geen labels met terugwerkende kracht nodig.

Boetes kunnen oplopen tot 15 miljoen euro of 3% van de wereldwijde jaaromzet, welke van de twee hoger is; voor mkb draait de regel om naar welke lager is. Handhaving ligt bij de nationale markttoezichthouders. Dat is de ene kalme zin over boetes die je van ons krijgt. Angst is geen compliancestrategie.

Stap 0: geldt dit überhaupt voor jou?

Voordat je iets doet: bepaal welke pet je op hebt. Artikel 50 verdeelt plichten over twee rollen, en ze verwarren is de grootste bron van verspild werk.

Aanbieder. Jij bouwde het AI-systeem (of liet het bouwen) en levert het onder je eigen naam of merk. Belangrijke nuance voor SaaS-oprichters: als je een model van een derde partij (OpenAI, Anthropic, Google, wie dan ook) achter je eigen merk in je product inbouwt, ben je vrijwel zeker de aanbieder van dat AI-systeem. "Maar het model is niet van mij" verplaatst de plicht niet stroomopwaarts. Jouw naam op de deur, jouw plichten.

Deployer (gebruiksverantwoordelijke). Je gebruikt een AI-systeem in je bedrijf. Je marketingteam dat posts schrijft met ChatGPT? Deployer. Je supportteam met een AI-tool die iemand anders bouwde? Deployer.

De meeste kleine softwarebedrijven zijn allebei tegelijk: aanbieder van de AI-functies in hun product, deployer van de AI-tools die het team intern gebruikt. Dat is normaal. Het betekent alleen dat je twee keer triageert.

Zet nu de vier plichten op de twee petten:

• Artikel 50(1), interactiemelding. Aanbiedersplicht. De chatbots, assistenten en spraakinterfaces van je product moeten mensen vertellen dat ze AI zijn.
• Artikel 50(2), machineleesbare markering. Aanbiedersplicht. Generatieve output (tekst, beeld, audio, video) moet zo gemarkeerd zijn dat machines kunnen detecteren dat hij synthetisch is.
• Artikel 50(3), emotieherkenning en biometrische categorisering. Deployer-plicht. Zet je deze systemen in op mensen, dan moet je ze informeren. Voor vrijwel elk SaaS-bedrijf: niet van toepassing. Geldt het wel voor jou, sluit dan deze PDF en bel een advocaat. Vriendelijk bedoeld.
• Artikel 50(4), zichtbaar labelen. Deployer-plicht. Deepfakes krijgen een zichtbaar label. AI-gegenereerde tekst die wordt gepubliceerd om het publiek te informeren over zaken van publiek belang ook, tenzij een mens hem redactioneel controleert (sectie 4 van dit pakket).

De typische B2B SaaS-triage, eerlijk gedaan:

• Support- of in-product AI-chatbot: ja, 50(1) geldt.
• Generatieve AI-functies in je product: ja, 50(2) geldt.
• Met AI geschreven marketing- en blogcontent: 50(4) geldt misschien, en redactionele controle maakt de vraag grotendeels overbodig.
• Emotieherkenning of biometrische categorisering: vrijwel zeker niet.

Schrijf deze triage op, met een datum erop. Eén memo van één pagina. Het is je eerste stuk evidence, en het is het document waar elke latere beslissing naar terugwijst.

Sectie 1: interactiemeldingen

Wat de wet zegt, in gewone taal

Als iemand redelijkerwijs zou kunnen denken dat hij met een mens praat, moet je zeggen dat het AI is. De uitzondering: wanneer het toch al duidelijk is. Maar de lat voor "duidelijk" is een redelijk geïnformeerd, opmerkzaam en oplettend persoon, beoordeeld in context. Een robotavatar en een grappige botnaam halen die lat mogelijk niet. Een spraakinterface haalt hem bijna nooit.

De melding moet helder en herkenbaar zijn en uiterlijk bij de eerste interactie komen. Niet in alinea 14 van je voorwaarden. Op het moment dat het gesprek begint.

Wat je concreet doet

1. Inventariseer elk AI-naar-mens contactpunt. Supportwidget, assistent in het product, onboardingbot, spraakinterface, elke e-mailautomatisering die een gesprek voert in plaats van alleen te notificeren. Schrijf de lijst op, met datum.
2. Schrijf de melding. Eén eerlijke zin verslaat een alinea juridisch jargon. "Je chat met een AI-assistent." Klaar. Weersta de neiging hem af te zwakken tot hij niets meer betekent.
3. Zet hem bij de eerste interactie. In het chatvenster zelf, vóór of bij het eerste bericht. Zichtbaar, niet verstopt achter een hover.
4. Leun je ergens op de uitzondering "het is toch duidelijk", schrijf dan op waarom. Een beslissing waarvan je de redenering niet kunt laten zien, is een beslissing die je onder druk opnieuw gaat uitvechten, waarschijnlijk op het slechtst denkbare moment.

Sectie 2: markering en detectie

Wat de wet zegt, in gewone taal

Genereert je systeem synthetische audio, beelden, video of tekst, dan moet de output een machineleesbare markering dragen, zodat tools kunnen detecteren dat de content AI-gegenereerd of gemanipuleerd is. Dit is iets anders dan een zichtbaar label. De markering mag onzichtbaar zijn voor mensen; het punt is dat machines hem kunnen vinden. Dit is een aanbiedersplicht.

De technieken die meespelen: metadatastandaarden (C2PA content credentials zijn de opkomende standaard), watermerken en fingerprinting. De wet vraagt om oplossingen die effectief, interoperabel, robuust en betrouwbaar zijn voor zover technisch haalbaar, met expliciete aandacht voor het contenttype, de kosten en de stand van de techniek. Vertaling: niemand verwacht onbreekbare watermerken. Ze verwachten een serieuze, gedocumenteerde poging.

Twee nuttige uitzonderingen: systemen die alleen helpen bij gewone bewerking (een grammaticachecker is geen deepfakefabriek, en dat weet de wet), en systemen die je invoer niet substantieel veranderen.

De vraag die elke oprichter stelt

"Ik bouw op GPT, Claude of Gemini. Regelt de modelaanbieder dit niet?"

Deels, soms, en je moet er je compliance niet op verwedden. Lever jij het AI-systeem onder jouw merk, dan ligt de plicht bij jou. Markeringen van de modelaanbieder helpen (sommige beeldgeneratie-API's stoppen er al C2PA-metadata in), maar alleen als ze jouw pipeline overleven. Je beeldverkleiningsstap, je PDF-export, je CDN-optimalisatie kunnen metadata geruisloos strippen. De markering die er in het API-antwoord nog was en in je buildstap stierf, telt niet.

Dus: testen. Niet aannemen. Dit is de operationele kern van deze sectie.

De markerings- en detectietest, stap voor stap

1. Inventariseer elke generatieve output die je product levert. Tekst die de gebruiker exporteert, beelden, gegenereerde documenten, PDF's, audio. Alles.
2. Bepaal het markeringsmechanisme per outputtype. Doorgegeven metadata van de modelaanbieder, je eigen watermerk, allebei, of eerlijk "nog geen".
3. Haal elke output door je echte productiepipeline en controleer of de markering het overleeft. Download het bestand zoals een gebruiker dat zou doen. Bekijk de metadata. Leg vast wat je vindt, met data en voorbeeldbestanden.
4. Waar markering voor een contenttype oprecht nog niet haalbaar is, schrijf je een korte memo: wat je hebt onderzocht, waarom het vandaag niet haalbaar is, en wanneer je opnieuw kijkt. Een gedocumenteerde beperking verslaat stil hopen, bij een auditor net zo goed als bij een toezichthouder.

Herinnering aan de overgangsperiode: was je systeem vóór 2 augustus 2026 op de markt, dan geldt deze specifieke plicht vanaf 2 december 2026. Dat is aanloop, geen vrijstelling. Vier maanden verdampen snel als de fix je exportpipeline raakt.

Sectie 3: labelbeslissingen

Markering vs labelen, één keer goed uit elkaar

Mensen halen ze voortdurend door elkaar, dus laten we het één keer rechtzetten. Markering (sectie 2) is machineleesbaar, mag onzichtbaar zijn en is het werk van de aanbieder. Labelen (deze sectie) is zichtbaar voor mensen, zit op het publicatiepunt en is het werk van de deployer. Je kunt voor allebei verantwoordelijk zijn, voor één, of voor geen van beide, afhankelijk van wat je bouwt en wat je publiceert.

Wat de wet zegt, in gewone taal

Twee labelplichten:

• Deepfakes. AI-gegenereerde of gemanipuleerde beelden, audio of video die echte personen, plekken of gebeurtenissen authentiek ogend weergeven, moeten een zichtbare melding dragen dat de content AI-gegenereerd of gemanipuleerd is. Is de content onderdeel van een duidelijk artistiek, satirisch of fictief werk, dan meld je het nog steeds, maar mag dat op een manier die het werk niet bederft (aftiteling, beschrijving, enzovoort).
• Tekst van publiek belang. AI-gegenereerde of gemanipuleerde tekst die wordt gepubliceerd om het publiek te informeren over zaken van publiek belang moet melden dat hij AI-gegenereerd is. Tenzij een mens hem heeft gecontroleerd en een persoon of bedrijf de redactionele verantwoordelijkheid voor de publicatie draagt. Die uitzondering krijgt hierna haar eigen sectie, want het is praktisch de nuttigste zin van het hele artikel.

De beslisboom

Vraag voor elk stuk AI-ondersteunde content dat je publiceert, in deze volgorde:

1. Geeft het echte personen, plekken of gebeurtenissen authentiek ogend weer? Ja: zichtbaar label, bij de eerste blootstelling, niet achter een klik. "Deze afbeelding is gegenereerd met AI" is genoeg.
2. Is het tekst bedoeld om het publiek te informeren over zaken van publiek belang (nieuwsachtige content, analyse, verslaggeving)? Ja: label hem, of haal hem door gedocumenteerde redactionele controle (volgende sectie).
3. Is het je marketingcopy over je eigen product? "Zaken van publiek belang" is voor een feature-aankondiging flink opgerekt, maar de grens is oprecht vaag, en dat geven we liever toe dan te doen alsof hij scherp is. Onze pragmatische standaard: draai toch het redactionele controleproces. Het is goedkoop, het maakt je content beter en het maakt de vage juridische vraag grotendeels irrelevant.

Hoe een label eruitziet

Gewoon, zichtbaar, aanwezig bij de eerste blootstelling. "Deze afbeelding is gegenereerd met AI." "Delen van deze audio zijn AI-gegenereerd." Geen eufemismen ("digitaal verbeterd" is geen melding), niets onder de vouw begraven.

Sectie 4: menselijke redactionele controle

De nuttigste uitzondering in artikel 50

De gewone versie: als een mens met AI geschreven tekst vóór publicatie controleert, en een persoon of bedrijf draagt er de redactionele verantwoordelijkheid voor, dan hoeft er geen "AI-gegenereerd"-label op die tekst.

Waarom dit ertoe doet: het is het verschil tussen elke blogpost bestempelen met "geschreven door AI" en simpelweg een redacteur hebben. Die goede contentteams, laten we eerlijk zijn, toch al hebben. De wet beloont stilletjes een gewoonte die je toch al zou moeten willen: een mens die het ding leest, het ding repareert en zijn naam eronder zet.

Het addertje, en het is hetzelfde addertje als overal in compliance: een controle die geen spoor achterlaat is een controle die je niet kunt bewijzen.

Maak het echt in vier stappen

1. Benoem de redactioneel verantwoordelijke persoon, op schrift. In een klein bedrijf is dat één zin in een beleid van één pagina. "De redactionele verantwoordelijkheid voor gepubliceerde content ligt bij [naam/rol]."
2. Definieer wat controle betekent. Helemaal lezen, feitelijke claims verifiëren, echt redigeren, goedkeuren. Scannen terwijl de koffie doorloopt telt niet, en dat weet je zelf ook.
3. Log het. Datum, content-ID, beoordelaar, akkoord. Een spreadsheet werkt echt. Een bevestiging met timestamp in het systeem dat je toch al gebruikt werkt beter.
4. Bewaar de concepten, of op zijn minst de diff. Kunnen laten zien dat een mens dingen veranderde is stilletjes sterk bewijs dat de controle echt plaatsvond.

Wat deze uitzondering niet doet

Ze haalt de machineleesbare markeringsplicht aan de aanbiederskant niet weg (sectie 2 blijft bij wie het genererende systeem aanbiedt). Ze dekt geen beelden, audio of video. Ze dekt het zichtbare label op tekst. Baken haar goed af en ze dient je prima; rek haar op en dat doet ze niet.

Sectie 5: Code-alignment of eigen middelen

Twee routes, één opgeschreven beslissing

De Commissie heeft definitieve richtsnoeren over artikel 50 gepubliceerd, en de Code of Practice on Transparency of AI-generated Content, opgesteld door onafhankelijke experts, is nu definitief. Dat geeft je twee routes voor de markerings- en labelplichten:

Route A: aansluiten bij de Code. De praktijken zijn voor je uitgeschreven, toezichthouders herkennen de route, en je bewijslast wordt "wij volgen de Code, hier is de mapping". Voor een klein team is dit meestal minder werk in totaal, omdat iemand anders al heeft bedacht hoe een nette oplossing eruitziet.

Route B: je eigen middelen. Volledig toegestaan. Maar jij draagt de last om te laten zien dat jouw aanpak hetzelfde resultaat bereikt: documentatie van wat je doet, en onderbouwing waarom het gelijkwaardig is.

Geen van beide routes is iets om je voor te schamen. Behoorlijk beschamend (operationeel gesproken) is geen van beide kiezen, wat in de praktijk betekent dat je per ongeluk route B kiest, zonder documentatie.

Het eindproduct

Een memo van één pagina. Welke route, waarom, wie besloot, en wanneer. Bij route A: een korte mapping van je werkelijke praktijken op de afspraken van de Code. Bij route B: je gelijkwaardigheidsonderbouwing. Zet er een reviewdatum bij, want zowel de richtsnoeren als de Code gaan evolueren.

En nu je toch bezig bent: lees de richtsnoeren van de Commissie echt. Dichter bij een toezichthouder die zelf uitlegt hoe hij de vage stukken gaat interpreteren kom je niet. En ze zijn gratis.

Sectie 6: herbeoordeling bij verandering

Toestand is ruis, verandering is het signaal

Compliance-momentopnames verouderen. De triage die je in augustus 2026 deed klopt precies tot de dinsdag waarop iemand een nieuwe AI-functie uitrolt zonder het je te vertellen. Dit geldt voor elk framework waar we ooit mee werkten, en artikel 50 is geen uitzondering.

Onze stellige mening, na jaren in complianceland: bouw geen groot jaarlijks herbeoordelingsritueel. Bouw een korte triggerlijst. Gaat een trigger af, doe dan de triage van dertig minuten uit stap 0 opnieuw. Dat is het hele proces.

De triggerlijst

• Je rolt een nieuwe AI-functie uit, of een nieuwe plek waar gebruikers met AI praten.
• Je wisselt of voegt een model of AI-leverancier toe.
• Je leverancier verandert hoe hij gegenereerde content markeert.
• Marketing neemt een nieuwe generatieve AI-tool in gebruik.
• Je betreedt een nieuwe markt, taal of contentkanaal.
• Je content- of leveringspipeline verandert (nieuw exportformaat, nieuwe CDN, nieuwe beeldverwerking: draai de overlevingstests van de markering opnieuw).
• De Commissie werkt de richtsnoeren of de Code of Practice bij.
• Eén trigger kun je nu al inplannen: 2 december 2026, de dag waarop de markeringsovergangsperiode eindigt voor systemen van vóór 2 augustus 2026.

Het proces, helemaal

Een trigger gaat af. De eigenaar doet de triage en de bijbehorende checklistsectie. De eigenaar logt de datum, de uitkomst en eventuele acties. Klaar. Dertig minuten, echt, zodra de eerste volledige ronde er staat.

De checklist van één pagina

Print dit. Hang het op. Werk het van boven naar beneden af.

Van PDF naar praktijk

Alles hierboven is bewust tool-agnostisch. Een map en een spreadsheet krijgen je oprecht door artikel 50 heen. Wat telt is de vorm van het werk: een controlverklaring, evidence eraan vast, een eigenaar, een reviewritme en een geschiedenis die je later aan iemand kunt laten zien.

Draai je al SOC 2 of ISO 27001, weersta dan de neiging een aparte "AI-compliance"-silo te bouwen. Artikel 50 schuift in de machinerie die je hebt: voeg de controls toe, hang de evidence eraan, wijs de eigenaren aan, plan de reviews. Eén systeem, één gewoonte en minder documenten die stilletjes verouderen.

En is die machinerie op dit moment een spreadsheet die begint te kraken: dat is precies het probleem waarvoor we AuditBadger bouwden. Eigen controls, evidence met versiegeschiedenis, documentworkflows met reviewherinneringen, bevestigingen met timestamp. We gebruikten het om onszelf SOC 2 Type II te certificeren, nul consultants, en onze eigen artikel 50-evidence draait er ook in, omdat we ons anders nogal dom zouden voelen. $250 per maand, vast, zonder kosten per gebruiker. Landt jouw compliancewerk in dezelfde overvolle spreadsheet als al het andere, kom dan even kijken: auditbadger.com

Eerlijke grenzen, en verder lezen

Wij zijn oprichters en engineers, geen juristen. Dit pakket is een operationele vertaling van artikel 50, geen juridisch advies, en het dekt bewust het gewone geval: een klein softwarebedrijf dat AI op gewone manieren levert en gebruikt. Draai je emotieherkenning of biometrische categorisering, opereer je ergens in de buurt van opsporingstoepassingen, of kun je oprecht niet zeggen of jouw content "het publiek informeert over zaken van publiek belang", geef het geld dan uit aan een advocaat. Dat is goedkoper dan het mis hebben.

De moeite waard, en allemaal gratis:

• Artikel 50, volledige tekst (EU AI Act Service Desk)
• Richtsnoeren van de Commissie over de transparantieplichten voor aanbieders en deployers van AI-systemen (definitief)
• Code of Practice on Transparency of AI-generated Content
• FAQ van de Commissie over de transparantieplichten van artikel 50

AuditBadger is een complianceplatform voor kleine teams die SOC 2 en ISO 27001 doen zonder complianceafdeling. We certificeerden onszelf ermee: SOC 2 Type II, nul consultants. $250 per maand, vast. auditbadger.com