heygrc
Gids

EU AI Act voor ontwikkelaars: Artikel 50 is actief, high-risk komt later

Vanaf 2 augustus 2026 gelden de transparantieverplichtingen van Artikel 50. De Digital Omnibus (Verordening (EU) 2026/1744) heeft de meeste high-risk-verplichtingen uit Hoofdstuk III uitgesteld tot december 2027 en augustus 2028. Wat deze kalender betekent in een pull request, met een voorbeeld van een onjuiste verwijdering van een openbaarmaking.

het heygrc team

Status per 11 augustus 2026. Artikel 50 van de EU AI Act (transparantie voor bepaalde systemen die met mensen communiceren, synthetische inhoud genereren, emotieherkenning of biometrische categorisatie uitvoeren, of deepfakes publiceren) is van toepassing vanaf 2 augustus 2026. De Europese Commissie is begonnen met de handhaving van deze transparantieverplichtingen. Dit is de huidige wetgeving voor applicatiecode, geen toekomstige deadline.

Het grootste deel van de high-risk systeemverplichtingen uit Hoofdstuk III (Artikelen 8 tot en met 15: risicobeheer, databeheer, technische documentatie, archivering, instructies voor implementatie, menselijk toezicht, en nauwkeurigheid, robuustheid en cybersecurity) golden niet voor de oude deadline van 2 augustus 2026. Verordening (EU) 2026/1744, de Digital Omnibus over AI, is gepubliceerd in het Publicatieblad op 24 juli 2026 en in werking getreden op 27 juli 2026. Hiermee zijn de high-risk-verplichtingen verplaatst naar 2 december 2027 voor systemen die als high-risk zijn geclassificeerd onder Artikel 6(2) en Bijlage III (zelfstandige systemen zoals systemen voor werkgelegenheid, essentiële diensten en handhavingsinstrumenten), en naar 2 augustus 2028 voor systemen die onder Artikel 6(1) en Bijlage I vallen (AI geïntegreerd in producten die elders al zijn gereguleerd, zoals medische apparaten of machines). Plannen die 2 augustus 2026 nog steeds als de high-risk-compliance-deadline behandelen, plannen tegen een datum die al is verplaatst.

Deze gids is bedoeld voor ontwikkelaars. Hij classificeert uw product niet als high-risk, voert geen conformiteitsbeoordeling uit of vervangt geen juridisch advies. Hij noemt de kalender, de Artikel 50-verplichtingen die nu als UI-tekst en metadata in een diff verschijnen, en hoe een compliance-lezing van een pull request de meest voorkomende fout opspoort: een opschoning die de openbaarmaking verwijdert.

Wat nu actief is (Artikel 50)

Artikel 50 beschrijft vier hoofdcategorieën van transparantieverplichtingen, verdeeld tussen aanbieders (de organisatie die het systeem bouwt) en implementatoren (de organisatie die het in gebruik neemt), met uitzonderingen zoals gespecificeerde handhavingsgebruiken. Deze verplichtingen komen vaak voor in uitvoerende code, niet alleen in documentatie. Art. 50(1): een systeem dat door een aanbieder is ontworpen om direct met een persoon te communiceren, moet die persoon erop wijzen dat hij/zij met een AI spreekt, tenzij dit voor een redelijk goed geïnformeerde persoon duidelijk is. Een chatwidget, een spraakassistent of een ondersteuningsbot heeft een openbaarmaking nodig die daadwerkelijk zichtbaar is. Art. 50(2): een aanbieder wiens systeem synthetisch geluid, afbeeldingen, video of tekst genereert, moet deze uitvoer markeren in een machine-leesbaar formaat dat als AI-gegenereerd herkenbaar is. Voor systemen die al op de markt waren voor 2 augustus 2026, wordt de machine-leesbare markering onder Art. 50(2) vaak beschreven met een overgangsperiode tot 2 december 2026. Controleer de exacte overgangstekst tegen de Omnibus en de richtlijnen van de Commissie voor uw productlijn, omdat andere Artikel 50-verplichtingen deze overgangsperiode niet delen. Art. 50(3): een implementator die emotieherkenning of biometrische categorisatie op mensen uitvoert, moet de betrokkenen hierover informeren. Art. 50(4): een implementator die een deepfake publiceert, moet nog steeds openbaar maken dat deze kunstmatig is gegenereerd of bewerkt. Voor inhoud die deel uitmaakt van een duidelijk artistiek, creatief, satirisch, fictief of vergelijkbaar werk, is de openbaarmakingsverplichting beperkt tot een wijze die de weergave of het genot van het werk niet belemmert, in plaats van te worden kwijtgescholden. Afzonderlijk moet AI-gegenereerde of bewerkte tekst die wordt gepubliceerd om het publiek te informeren over een zaak van openbaar belang, op dezelfde manier worden openbaar gemaakt, tenzij de inhoud een menselijke review of redactionele controle heeft ondergaan en een persoon of organisatie de redactionele verantwoordelijkheid draagt voor de publicatie.

Elk van deze verplichtingen wordt vaak geïmplementeerd als een UI-element, een metadata-schrijfbewerking of een tekststring, wat elk precies het soort ding is dat een refactor kan verwijderen zonder dat iemand het als een compliance-wijziging markeert. Vanaf augustus 2026 is deze verwijdering niet 'vroeg', het is een actieve transparantie-leemte.

Praktijkvoorbeeld: een UI-opschoning verwijdert de openbaarmaking

Stel dat een ondersteuningschatbot is geleverd met een vaste regel onder het eerste bericht: 'Je chat met een AI-assistent.' Een latere pull request ontwerpt de widget opnieuw voor een schonere eerste weergave en verwijdert, door wat een ontwerper als onboarding-clutter heeft gemarkeerd, die regel samen met drie andere inleidingsteksten. Het ontwerp is op zichzelf niet verkeerd: de widget ziet er schoner uit en de andere drie regels waren inderdaad overbodig. Maar de openbaarmaking van Art. 50(1) was geïmplementeerd als een van die regels, dus door deze te verwijderen, is de openbaarmaking verwijderd, niet alleen de overbodige tekst. Er is niets ongebruikelijks aan de diff: een tekstverwijdering in een chatcomponent is niet het soort ding dat een bugscanner, een QA-controle of een ontwerpreview is ontworpen om op te vangen.

Dit is waar een compliance-controle een diff op leest: wanneer een wijziging een element verwijdert of verzwakt dat gekoppeld is aan een controle die een team bijhoudt, vermeld dan Art. 50(1) in de pull request zelf, in plaats van dit achteraf te ontdekken via een klacht of een handhavingscontact.

High-risk is uitgesteld, niet geannuleerd

Het uitstellen van de high-risk-verplichtingen voor zelfstandige systemen uit Bijlage III tot december 2027 maakt de onderliggende vraag, of een systeem als high-risk wordt geclassificeerd onder Bijlage III, niet eenvoudiger om later te beantwoorden dan nu. De controles achter Artikelen 8 tot en met 15 zijn van hetzelfde type 'wijzigingen in een diff'-probleem waar het framework-hub al naar kijkt: een risicomitigatie verzwakt, een dataset-governance-controle verwijderd, een menselijke override als dode code verwijderd. Het opbouwen van deze gewoonten nu is goedkoper dan het ontdekken van leemtes onder een deadline in 2027.

Twee andere dataclusters blijven ongewijzigd door deze omnibus en gelden al: de verboden praktijken en AI-geletterdheidsverplichtingen vanaf 2 februari 2025, en de GPAI-modelregels en governanceverplichtingen vanaf 2 augustus 2025. Nog een wijziging uit hetzelfde pakket die het waard is om te kennen: een nieuw verbod voor aanbieders van systemen die bedoeld zijn om niet-consensuele intieme inhoud of kindermisbruikmateriaal te genereren of te manipuleren, of systemen waarbij dit een redelijkerwijs voorspelbaar en reproduceerbaar resultaat is zonder significante technische wijzigingen en zonder redelijke en adequate waarborgen daartegen, alsmede implementatoren die een systeem voor dit doel gebruiken. Dit is toegevoegd aan de lijst van verboden praktijken van de Act en geldt vanaf 2 december 2026.

Waar heygrc past, en de eerlijkheidsgrens

heygrc is gebouwd om elke pull request te controleren op de door u geselecteerde frameworks, inclusief de EU AI Act als u deze hebt ingeschakeld, en om het artikel te noemen dat een wijziging lijkt aan te raken (bijvoorbeeld Art. 50(1) bij een verwijderde chat-openbaarmaking). De bevinding is een review-opmerking met het betreffende artikel eraan gekoppeld, zodat de auteur en reviewer met volledige informatie kunnen beslissen. Het certificeert geen AI Act-compliance, classificeert geen high-risk-status, voert geen conformiteitsbeoordeling uit, doet geen meldingen aan toezichthouders of vervangt geen juridisch advies. Een groene heygrc-review is geen goedkeuring van de Commissie, het is een vroege, op artikelen gebaseerde signalering dat een wijziging iets heeft aangeraakt waar deze programma's om geven.

Als uw team al een bug- of kwaliteitsreviewer gebruikt op dezelfde pull request, houd deze dan aan. Die tools controleren of de code correct en veilig is. Artikel 50-vragen gaan over of een persoon nog steeds weet dat hij/zij met een AI spreekt, of synthetische inhoud nog steeds is gemarkeerd. De hierboven beschreven opschoning kan schoon, getypt en goed getest zijn, maar Art. 50(1) toch onvolledig laten. Voer beide lagen uit, geen van beide vervangt de andere.