Bronherleidbare verbindingen van AI Act-wijzigingen en verplichtingen naar actoren, acties, bewijs, controls en publieke hulpmiddelen.
Vingerafdruk van ons bronrecord (URL, uitgaveversie, controledatum). Geen archiefkopie of inhoudshash van het externe document.
Vragen en antwoorden over AI-geletterdheid
Ontwerprichtsnoeren over de classificatie van hoog-risico AI-systemen
CEN-CENELEC JTC 21: Europese normen onder normalisatieverzoek M/613
Richtsnoeren over verboden AI-praktijken, C(2025) 5052 final
Richtsnoeren over de definitie van een AI-systeem, C(2025) 5053 final
Levend repository van AI-geletterdheidspraktijken
Praktijkcode voor AI voor algemene doeleinden
Praktijkcode over transparantie van door AI gegenereerde inhoud
ISO/IEC JTC 1/SC 42: internationale normen voor artificiele intelligentie
Motiveer de Artikel 6 lid 3-uitzondering per afzonderlijke voorwaarde
Benoem welke van de vier voorwaarden van Artikel 6 lid 3 u inroept, met feiten, en onderbouw apart waarom het systeem geen significant risico op schade voor gezondheid, veiligheid of grondrechten oplevert en de uitkomst van besluitvorming niet wezenlijk beïnvloedt.
Het bedoelde doel van het systeem valt onder een usecase in Bijlage III.
Niettegenstaande de eerste alinea van Artikel 6 lid 3 wordt een in Bijlage III genoemd AI-systeem altijd als hoog-risico beschouwd wanneer het profilering van natuurlijke personen verricht.
Classificeer de usecase en documenteer de uitkomst
Toets Artikel 5, Artikel 6 en Bijlage III in die volgorde en leg doel, context en eventuele uitzondering uit Artikel 6 lid 3 vast.
Toets op profilering voordat u de Artikel 6 lid 3-uitzondering inroept
Stel als eerste vraag vast of het systeem profilering van natuurlijke personen verricht; is het antwoord ja, dan vervalt de route via Artikel 6 lid 3 en blijft het systeem hoog-risico, ongeacht de vier voorwaarden.
U overweegt een beroep op Artikel 6 lid 3 voor een systeem dat onder Bijlage III valt.
Wijs het menselijk toezicht toe en geef die personen mandaat
Benoem per hoog-risico systeem met naam wie toezicht houdt, en zorg dat die persoon bekwaamheid, opleiding, autoriteit en ondersteuning heeft om de uitkomst daadwerkelijk terzijde te kunnen schuiven.
Uit te voeren vóór ingebruikname en opnieuw bij elke wijziging van het beoogde doel of van de gebruiksaanwijzingen van de aanbieder.
Beoordeel herkomst, representativiteit, fouten en volledigheid en onderzoek mogelijke bias met passende mitigatie.
Bouw het technisch dossier volgens Bijlage IV
Documenteer systeembeschrijving, ontwikkelproces, data, toezichtsmaatregelen, prestaties en risicobeheer vóór marktintroductie.
Zorg dat het systeem gebeurtenissen automatisch registreert die relevant zijn voor risico-identificatie en post-market monitoring.
Beschrijf capaciteiten, beperkingen, nauwkeurigheid, toezichtsmaatregelen en verwachte levensduur in begrijpelijke vorm.
Ontwerp en beleg effectief menselijk toezicht
Bepaal per systeem de toezichtsmaatregelen, wijs bekwame personen aan en geef hun mandaat om in te grijpen of te stoppen.
Stel prestatie- en beveiligingsniveaus vast en test ze
Bepaal passende nauwkeurigheid, test robuustheid tegen fouten en misbruik, en tref AI-specifieke beveiligingsmaatregelen.
Richt een AI-kwaliteitsmanagementsysteem in
Beschrijf strategieën, procedures en verantwoordelijkheden voor naleving, van ontwerp en data tot post-market monitoring.
Neem rol- en contextgerichte AI-geletterdheidsmaatregelen
Bepaal per rol, systeem en gebruikscontext welke combinatie van instructie, begeleiding, oefening of training passend is.
Bepaal per rol welke kennis nodig is om het concrete systeem verantwoord te gebruiken
Zet rollen af tegen de AI-systemen die zij gebruiken en noteer per combinatie wat iemand moet kunnen beoordelen: wat het systeem doet, waar het faalt, op wie het wordt toegepast en wanneer iemand moet ingrijpen of escaleren.
Uw organisatie is aanbieder of gebruiksverantwoordelijke van ten minste een AI-systeem binnen het toepassingsgebied.
Artikel 4 schrijft geen specifiek cursusformat, examen of certificaat voor en verlangt geen gegarandeerd individueel niveau.
Geef instructie op het moment dat een nieuwe tool of een nieuwe medewerker binnenkomt
Koppel de geletterdheidsmaatregel aan twee vaste momenten in bestaande processen: de uitrol van een nieuwe AI-tool en de onboarding van iemand die toegang krijgt tot een bestaande tool.
Er komt een nieuwe AI-tool in gebruik of iemand krijgt toegang tot een bestaande AI-tool.
Controleer vóór inkoop, bouw of ingebruikname of de toepassing onder een verboden praktijk valt en staak of herontwerp bij twijfel niet pas achteraf.
Implementeer de toepasselijke melding, markering of label
Bepaal eerst welk lid van Artikel 50 geldt en implementeer daarna de specifieke transparantiemaatregel.
Leg per publicatiekanaal vast wanneer AI-tekst een melding krijgt en wie redactioneel verantwoordelijk is
Bepaal per kanaal of het gaat om tekst die wordt gepubliceerd om het publiek te informeren over aangelegenheden van algemeen belang, wie de menselijke review uitvoert, wie de redactionele verantwoordelijkheid draagt, en welke standaardformulering u gebruikt wanneer de melding wel nodig is.
U bent gebruiksverantwoordelijke en publiceert inhoud die geheel of gedeeltelijk door een AI-systeem is gegenereerd of gemanipuleerd.
De plicht van Artikel 50 lid 4 geldt niet wanneer het gebruik bij wet is toegestaan om strafbare feiten te detecteren, te voorkomen, te onderzoeken of te vervolgen.
Toets elk systeem in uw AI-register tegen de vijf Artikel 50-scenario's
Loop per AI-systeem de onderscheiden scenario's van Artikel 50 langs (directe interactie, synthetische output, emotieherkenning of biometrische categorisatie, deepfake, gepubliceerde tekst van algemeen belang) en noteer per lid of het geldt, niet geldt of onder een uitzondering valt, met de reden erbij.
Het systeem staat in uw AI-register en wordt in de Unie aangeboden, in gebruik genomen of gebruikt.
Artikel 50 lid 1 geldt niet wanneer het voor een redelijk geinformeerde, oplettende en omzichtige persoon, gelet op de omstandigheden en de gebruikscontext, duidelijk is dat hij met een AI-systeem interageert. Daarnaast kennen de leden 1 tot en met 4 elk een uitzondering voor AI-systemen die bij wet zijn toegestaan om strafbare feiten te detecteren, te voorkomen, te onderzoeken of te vervolgen, met passende waarborgen voor de rechten en vrijheden van derden. In lid 1 geldt die laatste uitzondering niet voor systemen die voor het publiek beschikbaar zijn om een strafbaar feit te melden.
Voer modelevaluaties en risicomitigatie uit
Evalueer het model inclusief adversarial testen, beoordeel en mitigeer systeemrisico’s, meld ernstige incidenten en beveilig het model.
Toetreden tot een testomgeving en het testomgevingsplan overeenkomen
Dien een aanvraag in bij de bevoegde autoriteit, kom een specifiek testomgevingsplan overeen en leg vast welke onzekerheid over de verordening u binnen de testomgeving wilt oplossen.
Van toepassing zodra u besluit toe te treden tot een AI-testomgeving voor regelgeving als aanbieder of potentiele aanbieder, eventueel in partnerschap met een gebruiksverantwoordelijke of andere derde.
Artikel 58 lid 2, punt d), schrijft voor dat de uitvoeringshandelingen kosteloze toegang voor kmo's en start-ups waarborgen, behoudens uitzonderlijke kosten die de autoriteit billijk en evenredig mag terugvorderen. Voor grotere ondernemingen kent de verordening die kosteloosheid niet toe. Controleer bij de betrokken autoriteit welk kostenregime zij nu hanteert, zolang de uitvoeringshandelingen niet zijn vastgesteld.
Testplan indienen, goedkeuring verkrijgen en de test registreren
Stel een plan voor tests onder reele omstandigheden op, dien het in bij de markttoezichtautoriteit, wacht op goedkeuring, registreer de test met een Uniebreed uniek identificatienummer en leg de rolverdeling met uw gebruiksverantwoordelijke vast.
Van toepassing voordat u begint met testen onder reele omstandigheden buiten een testomgeving. Alle voorwaarden van artikel 60 lid 4 moeten cumulatief zijn vervuld; het is geen keuzemenu.
De stilzwijgende goedkeuring na dertig dagen geldt alleen indien het nationale recht daarin voorziet. Voorziet het nationale recht daar niet in, dan blijft uitdrukkelijke toestemming vereist. Voor de in bijlage III, punten 1, 6 en 7, bedoelde systemen op de gebieden rechtshandhaving, migratie, asiel en grenstoezicht verloopt de registratie via het beveiligde niet-openbare gedeelte van de EU-databank op grond van artikel 49 lid 4, punt d). Voor de in bijlage III, punt 2, bedoelde systemen, kritieke infrastructuur, geldt een andere route: artikel 49 lid 5 schrijft registratie op nationaal niveau voor.
Verzamel en analyseer systematisch praktijkdata over de prestaties en naleving van het systeem gedurende zijn levensduur.
Richt een incidentproces met meldroutes in
Definieer wat een ernstig incident is, beleg de meldroute naar de toezichthouder en oefen het proces.
Richt een iteratief risicobeheerproces in
Identificeer en analyseer bekende en redelijkerwijs te voorziene risico’s, evalueer ze en tref maatregelen, telkens opnieuw bij wijzigingen.
Wijs per punt van artikel 16 een interne eigenaar en een datum aan
Vertaal de twaalf punten a) tot en met l) naar twaalf benoemde eigenaren met een startdatum, zodat geen enkel punt blijft hangen tussen productmanagement, kwaliteit en legal.
Uit te voeren zodra vaststaat dat u aanbieder bent van een systeem dat onder artikel 6 als hoog risico geldt, ruim vóór de beoogde datum van het in de handel brengen.
Doorloop de conformiteitsroute vóór marktintroductie
Kies de juiste beoordelingsprocedure, stel de EU-conformiteitsverklaring op, breng de CE-markering aan en registreer in de EU-databank.
Breng de geraakte groepen en hun specifieke schaderisico's in kaart
Benoem de categorieën natuurlijke personen en groepen die door het gebruik in deze concrete context waarschijnlijk worden geraakt, en werk per categorie de specifieke schaderisico's uit, met gebruik van de informatie die de aanbieder op grond van Artikel 13 heeft verstrekt.
U bent een publiekrechtelijke instantie, een private aanbieder van publieke diensten, of gebruiksverantwoordelijke van een systeem uit Bijlage III punt 5(b) of 5(c), en u zet een hoog-risico systeem via Artikel 6 lid 2 in.
Hoog-risico AI-systemen die bedoeld zijn voor het in Bijlage III punt 2 genoemde gebied vallen buiten de FRIA-plicht van Artikel 27 lid 1.
Beoordeel proces, duur, betrokken personen, risico’s, toezicht, mitigatie en klachtmechanismen en meld de resultaten waar vereist.
Richt het klachtmechanisme en de interne governance in voordat het systeem draait
Beschrijf welke maatregelen u neemt als een risico zich voordoet, wie intern beslist, langs welke route een geraakte persoon kan klagen, binnen welke termijn u reageert en wie bevoegd is het gebruik stil te leggen.
Voor het systeem geldt de FRIA-plicht van Artikel 27 lid 1.
Onderhoud GPAI-documentatie en transparantie-informatie
Onderhoud technische documentatie, informatie voor downstream-aanbieders, een auteursrechtenbeleid en een publieke samenvatting van trainingsinhoud.
Stel het downstream-informatiepakket samen volgens Bijlage XII
Bouw een pakket voor aanbieders die uw model integreren, met de taken en integratiemogelijkheden, het toegestane gebruiksbeleid, releasedatum en distributiemethoden, interactie met externe hardware of software, softwareversies, architectuur en parameteraantal, modaliteit en formaat van in- en uitvoer inclusief maximale omvang, licentie, benodigde technische middelen en informatie over de gebruikte trainings-, test- en validatiedata.
U bent aanbieder van een AI-model voor algemene doeleinden dat op de Uniemarkt wordt aangeboden.
Artikel 53 lid 2 stelt aanbieders van modellen die onder een vrije en opensource-licentie zijn vrijgegeven en waarvan onder meer de parameters publiek beschikbaar zijn, vrij van de punten a en b van lid 1. Die uitzondering geldt niet voor GPAI-modellen met systeemrisico.
Implementeer detectie van rechtenvoorbehouden in uw auteursrechtenbeleid
Leg vast met welke technieken u een voorbehoud van rechten in de zin van Artikel 4 lid 3 van Richtlijn (EU) 2019/790 opspoort bij het verzamelen van trainingsdata, hoe vaak u dat opnieuw controleert, en hoe u dat voorbehoud vervolgens naleeft.
De opensource-vrijstelling van Artikel 53 lid 2 ziet uitsluitend op de punten a en b van lid 1 en laat het auteursrechtenbeleid van punt c dus in stand.
Richt de afhandeling van een verzoek om uitleg in
Zorg dat uw klachten- of bezwaarloket een verzoek om uitleg over een AI-ondersteund besluit herkent, dat er per besluit terug te vinden is welk systeem in welke versie eraan bijdroeg, en dat iemand is aangewezen die de uitleg kan geven.
In te richten voordat een bijlage III-systeem bijdraagt aan besluiten over natuurlijke personen, en opnieuw te bezien bij elke wijziging van dat besluitproces.
Zorg dat u een klacht met stukken kunt beantwoorden
Leg per AI-systeem vast welke beoordeling is gedaan, door wie, op welke datum en tegen welke systeemversie, en spreek af wie een vraag van de toezichthouder aanneemt en binnen welke termijn.
Voer de controle van artikel 24, lid 1, uit vóór u aanbiedt
Controleer de CE-markering, de aanwezigheid van de EU-conformiteitsverklaring en de gebruiksinstructies, en of aanbieder en importeur hun plichten uit artikel 16, punten b) en c), en artikel 23, lid 3, zijn nagekomen.
Uit te voeren vóór elk op de markt aanbieden, ook wanneer u het systeem gratis of als onderdeel van een dienstenbundel verstrekt (artikel 3, punt 10).
Doorloop de vier verificaties van artikel 23, lid 1, vóór import
Controleer en leg vast: de conformiteitsbeoordeling is uitgevoerd, de technische documentatie bestaat, de CE-markering en de verklaring plus gebruiksaanwijzingen zijn aanwezig, en er is een gemachtigde aangewezen.
Uit te voeren vóór elk eerste in de handel brengen van een hoog-risico AI-systeem van een aanbieder uit een derde land.
Beoordeel de waardeketenrol per systeem en wijziging
Toets bij white-labeling, wezenlijke wijziging of doelverandering of uw organisatie aanbieder wordt, en regel de gemachtigde bij levering van buiten de EU.
Het bureau van de Commissie dat toeziet op aanbieders van AI-modellen voor algemene doeleinden. Handhaving door het AI Office is actief sinds 2 augustus 2026.
De gemachtigde is de in de Unie gevestigde partij die op basis van een schriftelijke machtiging namens een aanbieder van buiten de EU de verplichtingen en procedures van de verordening nakomt en uitvoert. De definitie van artikel 3, punt 5, geldt nu al, zodat u de rol vandaag al kunt vaststellen. De aanwijsplicht zelf gaat gelden op 2 december 2027 voor de standalone-route van bijlage III en op 2 augustus 2028 voor de ingebedde route van bijlage I. Vanaf die data mag een aanbieder uit een derde land zonder aangewezen gemachtigde geen hoog-risico AI-systeem in de Unie in de handel brengen.
Verplicht voor aanbieders van hoog-risico AI-systemen die in een derde land zijn gevestigd, voordat zij die systemen in de Unie in de handel brengen (artikel 22, lid 1). Deze plicht gaat gelden op 2 december 2027 voor de standalone-route van bijlage III (artikel 6, lid 2) en op 2 augustus 2028 voor de ingebedde route van bijlage I (artikel 6, lid 1). De definitie en de rolbepaling van artikel 3, punt 5, gelden nu al.
Artikel 22 ziet op de route voor hoog-risico AI-systemen. De definitie in artikel 3, punt 5, noemt daarnaast AI-modellen voor algemene doeleinden; die route kent een eigen regeling die hier niet is uitgewerkt.
Krediet- of verzekeringsgebruiksverantwoordelijke
Een gebruiksverantwoordelijke van de relevante kredietwaardigheids- of levens- en ziektekostenverzekeringssystemen in Bijlage III punt 5(b) of 5(c).
Een organisatie die een AI-systeem onder haar gezag gebruikt, buiten persoonlijk niet-professioneel gebruik.
U bent distributeur als u een AI-systeem op de Uniemarkt aanbiedt zonder aanbieder of importeur te zijn. Dit raakt resellers, systeemintegratoren en managed service providers die andermans AI doorleveren.
Van toepassing wanneer u in de toeleveringsketen zit, geen aanbieder of importeur bent, en het systeem in het kader van een handelsactiviteit verstrekt. Gratis verstrekken telt uitdrukkelijk mee.
Zet u uw eigen naam of merk op een reeds in de handel gebracht hoog-risico systeem, of wijzigt u het substantieel of het beoogde doel ervan, dan wordt u op grond van artikel 25, lid 1, als aanbieder beschouwd. Punt a) geldt daarbij onverminderd contractuele regelingen waarin de verplichtingen anders worden toegewezen. De rolomslag kunt u nu al vaststellen; de plichten van artikel 16 gaan gelden op 2 december 2027 voor de standalone-route van bijlage III en op 2 augustus 2028 voor de ingebedde route van bijlage I.
Een partij die een AI-model voor algemene doeleinden op de Uniemarkt aanbiedt.
U bent importeur zodra u vanuit de EU een AI-systeem voor het eerst op de Uniemarkt aanbiedt dat de naam of het merk draagt van een partij buiten de EU. Niet uw inkooprol telt, maar wiens merk erop staat en wie het systeem als eerste de markt op brengt.
Van toepassing wanneer u in de Unie gevestigd bent of zich daar bevindt en een AI-systeem van een aanbieder uit een derde land voor het eerst op de Uniemarkt aanbiedt onder de naam of het merk van die aanbieder.
U bent geen importeur maar aanbieder zodra u uw eigen naam of merk op het systeem zet, een substantiele wijziging aanbrengt, of het beoogde doel zo wijzigt dat het systeem hoog risico wordt (artikel 25, lid 1, punten a), b) en c)). Punt a) geldt uitdrukkelijk onverminderd contractuele regelingen waarin de verplichtingen anders worden toegewezen. De rolomslag kunt u nu al vaststellen; de twaalf plichten van artikel 16 gaan gelden op 2 december 2027 voor de standalone-route van bijlage III en op 2 augustus 2028 voor de ingebedde route van bijlage I.
De nationale autoriteit die op de naleving van de verordening toeziet en aan wie ernstige incidenten en risicomeldingen worden gemeld. Welke instantie deze rol per lidstaat vervult staat niet in de graph.
Een partij die een AI-systeem ontwikkelt of laat ontwikkelen en het onder eigen naam aanbiedt.
Een gebruiksverantwoordelijke die een publiekrechtelijke instantie is.
Een private gebruiksverantwoordelijke die publieke diensten aanbiedt.
De verordening is op 1 augustus 2024 in werking getreden; de plichten volgden daarna gefaseerd.
Verordening (EU) 2024/1689 is op 12 juli 2024 in het Publicatieblad verschenen en op 1 augustus 2024 in werking getreden. Artikel 113 legt vast dat de meeste bepalingen pas later van toepassing worden.
Verboden praktijken en AI-geletterdheid gelden
Sinds 2 februari 2025 gelden het verbod van artikel 5 en de AI-geletterdheidsplicht van artikel 4.
Hoofdstuk I en hoofdstuk II werden op 2 februari 2025 van toepassing. Daarmee zijn de verboden praktijken de eerste categorie met handhaafbare plichten.
De vrijwillige praktijkcode geeft GPAI-modelaanbieders een route om naleving aan te tonen.
De Commissie publiceerde de praktijkcode voor AI voor algemene doeleinden op 10 juli 2025. Ondertekenen is vrijwillig; wie tekent kan zich erop beroepen om naleving van de GPAI-plichten aan te tonen.
Praktijkcode voor AI voor algemene doeleinden, 10 juli 2025
Richtsnoeren over de reikwijdte van de GPAI-plichten
De Commissie legt uit wanneer iemand aanbieder van een GPAI-model wordt, onder meer bij finetuning.
Richtsnoeren C(2025) 5045 final van 18 juli 2025 beschrijven de reikwijdte van de plichten voor aanbieders van GPAI-modellen, waaronder de vraag wanneer een partij die een model aanpast zelf aanbieder wordt.
Commission Guidelines C(2025) 5045 final, 18.7.2025
Richtsnoeren over de definitie van een AI-systeem
De Commissie trekt de grens tussen software die wel en niet onder de verordening valt.
Richtsnoeren C(2025) 5053 final van 29 juli 2025 leggen artikel 3, punt 1 uit aan de hand van grensgevallen, zoals klassieke optimalisatie, statistische schattingen en expertsystemen.
Commission Guidelines C(2025) 5053 final, 29.7.2025
Richtsnoeren over verboden AI-praktijken
Uitgewerkte voorbeelden bij elk verbod van artikel 5, met de grens tussen toegestaan en verboden.
Richtsnoeren C(2025) 5052 final van 29 juli 2025 werken elk verbod van artikel 5 uit met voorbeelden. De richtsnoeren zijn niet bindend: de uiteindelijke uitleg is aan het Hof van Justitie.
Commission Guidelines C(2025) 5052 final, 29.7.2025
Sinds 2 augustus 2025 gelden de plichten voor aanbieders van AI-modellen voor algemene doeleinden.
Hoofdstuk V werd op 2 augustus 2025 van toepassing. Modellen die voor die datum op de markt waren, moeten uiterlijk 2 augustus 2027 aan de plichten voldoen.
Artikelen 53 tot en met 55 en artikel 111, lid 3
Ontwerprichtsnoeren classificatie hoog-risico AI
De Commissie legt in consultatie uit wanneer een systeem onder Bijlage I of Bijlage III valt.
Op 19 mei 2026 publiceerde de Commissie ontwerprichtsnoeren over de classificatie van hoog-risico AI-systemen voor stakeholderconsultatie, met aparte bijlagen over Bijlage I en Bijlage III. De tekst is niet bindend en nog niet definitief.
Ontwerprichtsnoeren van 19 mei 2026, bijlagen over Bijlage I en Bijlage III
Praktijkcode transparantie AI-content gepubliceerd
Een vrijwillige route om te voldoen aan delen van artikel 50, in twee los te ondertekenen secties.
De praktijkcode over transparantie van door AI gegenereerde inhoud verscheen op 10 juni 2026. Na een positieve adequaatheidsbeoordeling kunnen ondertekenaars zich erop beroepen voor artikel 50, tweede, derde en vijfde lid. Sectie 1 richt zich op aanbieders, sectie 2 op gebruiksverantwoordelijken.
Praktijkcode transparantie AI-gegenereerde inhoud, 10 juni 2026
EN 18286:2026 over het kwaliteitsmanagementsysteem is de eerste voltooide norm onder het normalisatieverzoek.
CEN-CENELEC keurde EN 18286:2026 op 12 juli 2026 goed. Het is de eerste deliverable van JTC 21 onder normalisatieverzoek M/613 die het publicatiestadium bereikt.
EN 18286:2026, CEN/CLC/JTC 21 onder normalisatieverzoek M/613
De Commissie werkt de transparantieplichten uit en bevestigt dat zij vanaf 2 augustus 2026 gelden.
Richtsnoeren C(2026) 5054 final van 20 juli 2026 werken de meldings- en markeringsplichten van artikel 50 uit, met uitgewerkte voorbeelden voor chatbots, deepfakes en AI-teksten van publiek belang.
Commission Guidelines C(2026) 5054 final, 20.7.2026
Bijlage III-kernregels verschoven naar 2 december 2027
De gewijzigde toepassingsdatum is geldend recht sinds 27 juli 2026.
Verordening (EU) 2026/1744 stelt de toepassing voor Artikel 6 lid 2 en Bijlage III vast op 2 december 2027.
Artikel 4 gewijzigd naar maatregelenplicht
Sinds 27 juli 2026 ondersteunt de organisatieplicht de ontwikkeling van AI-geletterdheid zonder een individueel niveau te garanderen.
Verordening (EU) 2026/1744 wijzigde Artikel 4 met ingang van 27 juli 2026.
Wijziging van artikel 4 en inwerkingtreding
FRIA volgt nieuwe datum en kan naar een DPIA verwijzen
De FRIA voor de relevante Bijlage III-route volgt 2 december 2027 en mag relevante DPIA-delen opnemen of daarnaar verwijzen.
De wijzigingsverordening verbindt de relevante FRIA-route aan de nieuwe toepassingskalender en maakt hergebruik via een DPIA expliciet mogelijk.
Wijziging van artikel 27 en gewijzigd artikel 113
De transparantieverplichtingen gelden sinds 2 augustus 2026.
Artikel 50 werd op 2 augustus 2026 van toepassing en is niet uitgesteld door de Digital Omnibus.
Sinds 2 augustus 2026 kan de Commissie GPAI-informatie opvragen, evaluaties uitvoeren en maatregelen eisen.
De handhavingsbevoegdheden van de Commissie voor GPAI en het boeteregime van Artikel 101 zijn sinds 2 augustus 2026 actief.
Overgangstermijn machineleesbare markering loopt af
Systemen die voor 2 augustus 2026 op de markt waren, moeten uiterlijk 2 december 2026 aan artikel 50 lid 2 voldoen.
Artikel 50 geldt sinds 2 augustus 2026 voor alle systemen in scope. Voor de machineleesbare markering en detecteerbaarheid van lid 2 geldt een overgangstermijn tot 2 december 2026, en alleen voor systemen die voor 2 augustus 2026 op de markt waren.
Commission Guidelines C(2026) 5054 final, overgangsregime bij artikel 50 lid 2
Nieuwe verboden vragen technische waarborgen
De Digital Omnibus verbiedt AI voor materiaal van seksueel kindermisbruik en niet-consensuele intieme beelden.
Verordening (EU) 2026/1744 voegt een verbod toe op AI die is bedoeld voor het genereren van materiaal van seksueel kindermisbruik of niet-consensuele intieme beelden. De vereiste technische waarborgen moeten uiterlijk 2 december 2026 zijn getroffen.
Verordening (EU) 2026/1744, wijziging van artikel 5
Modellen die voor 2 augustus 2025 op de markt kwamen, krijgen tot 2 augustus 2027 de tijd.
Artikel 111 lid 3 geeft aanbieders van GPAI-modellen die voor 2 augustus 2025 op de markt zijn gebracht tot 2 augustus 2027 om aan hoofdstuk V te voldoen.
Hoog-risico AI in gereguleerde producten
AI als veiligheidscomponent van producten onder Bijlage I volgt op 2 augustus 2028.
Voor AI-systemen onder artikel 6 lid 1 en Bijlage I, dus AI als veiligheidscomponent van producten die al onder EU-productwetgeving vallen, gelden de hoog-risico eisen vanaf 2 augustus 2028.
Verordening (EU) 2026/1744, gewijzigde toepassingsdata bij artikel 113
Herclassificatie bij doel- of contextwijziging
Heropen de classificatie wanneer bedoeld doel, gebruikscontext of systeemfunctionaliteit materieel verandert.
Inkoopgate: geen handtekening zonder ingevuld classificatieantwoord
Blokkeer ondertekening van een AI-contract totdat de leverancier schriftelijk heeft geantwoord onder welk punt van Bijlage III het bedoelde doel valt, of hij zich op Artikel 6 lid 3 beroept, en of het systeem natuurlijke personen profileert.
U koopt, verlengt of vernieuwt een contract voor een AI-systeem of een AI-component.
Herhaal de datakwaliteitstoets vóór elke hertraining of dataset-wijziging.
Werk het dossier bij vóór elke release en bewaar eerdere versies herleidbaar.
Controleer periodiek of de logging werkt, volledig is en bewaard blijft volgens het regime.
Controleer bij elke ingebruikname en update of de instructies aanwezig, actueel en intern doorvertaald zijn.
Test vóór livegang dat ingrijpen, stoppen en negeren van output daadwerkelijk werkt en belegd is.
Monitor of het systeem in productie binnen de gedeclareerde niveaus blijft en escaleer bij afwijking.
Vrijgavepoort vóór het in de handel brengen
Een harde blokkade in uw release- of leveringsproces: geen levering zonder afgeronde conformiteitsbeoordeling, getekende EU-conformiteitsverklaring, aangebrachte CE-markering en voltooide registratie.
Geldt bij elke eerste levering aan de markt en opnieuw na een substantiele wijziging in de zin van artikel 3, punt 23, dat wil zeggen een wijziging na het in de handel brengen of in gebruik stellen die niet in de oorspronkelijke conformiteitsbeoordeling was voorzien en die de overeenstemming met hoofdstuk III, afdeling 2, raakt of leidt tot een wijziging van het beoordeelde beoogde doel. Artikel 43, lid 4, schrijft in dat geval een nieuwe conformiteitsbeoordelingsprocedure voor.
Toets periodiek of de praktijk het beschreven systeem volgt en registreer afwijkingen en verbeteracties.
Dekkingscontrole: iedere persoon met AI-toegang staat in de registratie
Leg periodiek de lijst van accounts en licenties met toegang tot AI-systemen naast de deelname- en instructieregistratie, en werk de verschillenlijst weg met een eigenaar en een termijn.
Er zijn personen buiten de vaste personeelslijst die namens u met AI-systemen werken.
Artikel 4 schrijft geen dekkingspercentage, registratievorm of frequentie voor. De afstemming is een middel om aan te tonen dat de maatregelen de in Artikel 4 lid 1 bedoelde personen bereiken, niet zelf een wettelijke verplichting.
Controleer bij nieuwe systemen, rollen of risico’s of de gekozen maatregelen nog passend zijn.
Herhaal de toets bij elk nieuw systeem, elke inkoop en elke materiële wijziging van doel of context; een eerder akkoord dekt een nieuwe inzet niet.
Kwartaalsteekproef op live meldingen en markeringen in productie
Trek elk kwartaal een steekproef uit de systemen met een Artikel 50-scenario en controleer in de productieomgeving of de melding nog verschijnt en de markering nog in de daadwerkelijke output zit, met bevinding, eigenaar en hersteltermijn.
Uw AI-register bevat ten minste een systeem waarvoor een Artikel 50-scenario van toepassing is.
Test vóór livegang dat de toepasselijke melding, markering of label tijdig, duidelijk en technisch werkzaam is.
Bewaak de cumulatieve trainingsrekenkracht en meld de Commissie wanneer de drempel bereikt wordt.
Toezicht binnen de testomgeving en de voorwaardelijke boetebescherming
De autoriteit houdt haar toezichts- en correctiebevoegdheden en kan uw test of deelname schorsen. Blijft u binnen het plan en volgt u de begeleiding te goeder trouw op, dan leggen de autoriteiten geen administratieve geldboete op voor inbreuken op deze verordening.
Van toepassing gedurende uw hele deelname aan een AI-testomgeving voor regelgeving, vanaf toetreding tot uitschrijving of beeindiging.
De boetebescherming is voorwaardelijk en vervalt zodra u afwijkt van het specifieke plan of van de voorwaarden voor deelname, of de begeleiding niet te goeder trouw opvolgt. Voor ander Unie- of nationaal recht geldt zij alleen wanneer de daarvoor bevoegde autoriteiten actief bij het toezicht in de testomgeving waren betrokken en begeleiding gaven. Artikel 57 lid 12 noemt uitsluitend deelnemende aanbieders en potentiele aanbieders. Doet u als gebruiksverantwoordelijke mee als partner op grond van artikel 58 lid 2, punt b), ga er dan niet van uit dat de bescherming zonder meer ook uw eigen plichten dekt.
Toezicht tijdens de test, incidentmelding en terugroepprocedure
De markttoezichtautoriteit mag onaangekondigd inspecteren. Bij een ernstig incident meldt u, treft u onmiddellijk maatregelen of schort u op, en u moet vooraf een procedure hebben om het systeem onmiddellijk terug te roepen.
Van toepassing gedurende de gehele looptijd van het testen onder reele omstandigheden, en bij de afronding, opschorting of beeindiging daarvan.
De verordening kent geen uitzondering op de meldplicht bij een ernstig incident of op de inspectiebevoegdheden. De meldingsroute zelf loopt via artikel 73, dat de termijnen en de wijze van melden regelt.
Borg dat praktijksignalen (afwijkingen, klachten, incidenten) aantoonbaar tot analyse en zo nodig maatregelen leiden.
Test periodiek of een incident binnen de wettelijke termijnen gemeld kán worden, inclusief de keten gebruiksverantwoordelijke naar aanbieder.
Herbeoordeling bij elke materiële wijziging
Heropen het risicobeheerproces bij wijzigingen in doel, data, model of gebruikscontext en vóór elke release.
Doorloop de conformiteitsroute opnieuw wanneer het systeem wezenlijk wijzigt.
Opschortings- en meldingsregel bij risico of ernstig incident
Een vaste regel die het gebruik onderbreekt en in de juiste volgorde meldt zodra u redenen hebt om aan te nemen dat het systeem een risico vormt of zodra u een ernstig incident vaststelt.
Treedt in werking bij de drempel redenen hebben om aan te nemen dat het gebruik tot een risico kan leiden, en afzonderlijk bij het vaststellen van een ernstig incident. Voor financiele instellingen geldt de monitoringsplicht als vervuld via de interne-governance-regels uit het Unierecht inzake financiele diensten.
Corrigerende maatregelen, uit de handel nemen en terugroepen door de distributeur
Een vooraf ingerichte capaciteit om een reeds geleverd systeem in overeenstemming te brengen, uit de handel te nemen of terug te roepen, en om onmiddellijk te melden aan aanbieder of importeur en aan de bevoegde autoriteiten.
Treedt in werking zodra u op grond van de informatie waarover u beschikt redenen hebt om aan te nemen dat het systeem niet aan afdeling 2 voldoet, ook wanneer die informatie van een klant komt en niet van de aanbieder.
Doorzetten en termijnbewaking van een verzoek om uitleg
De borging dat een binnengekomen verzoek binnen een vastgelegde termijn bij een aanwijsbare persoon landt en beantwoord wordt, in plaats van in een algemene postbus te blijven liggen.
Actualiteitscontrole op de FRIA-elementen tijdens gebruik
Controleer periodiek en bij elke wijziging in proces, gebruiksduur, geraakte groepen, risico's of toezichtsmaatregelen of de vastgelegde elementen nog kloppen, en werk de informatie bij zodra dat niet zo is.
Het systeem is in gebruik en er is een beoordeling op grond van Artikel 27 lid 1 uitgevoerd of overgenomen.
Blokkeer ingebruikname totdat toepasselijkheid, beoordeling, mitigatie en melding zijn afgehandeld.
Halfjaarlijkse toets of uw gekozen nalevingsroute nog dekkend is
Stel elk half jaar vast of u naleving aantoont via een praktijkcode, via een gepubliceerde geharmoniseerde norm, of via alternatieve passende middelen, en of het onderliggende dossier bij die keuze past.
Werk documentatie en downstream-informatie bij wanneer model, mogelijkheden of risico’s wijzigen.
Stopregel en meldroute bij twijfel over conformiteit
Zodra u afdoende redenen hebt om aan te nemen dat een systeem niet conform of vervalst is, gaat het niet de markt op, en bij een risico meldt u aan aanbieder, gemachtigde en markttoezichtautoriteiten.
Treedt in werking bij de drempel afdoende redenen om aan te nemen, dus bij een gegrond signaal en niet pas bij zekerheid of bevestiging door een derde.
Herhaal de rolbeoordeling bij elke naamsvoering, wijziging of nieuwe inzet van een bestaand systeem.
De rol met de zwaarste verplichtingen, en de rol waarin organisaties het vaakst per ongeluk terechtkomen.
Artikel 3, punt 3 omschrijft een aanbieder als een natuurlijke of rechtspersoon, overheidsinstantie, agentschap of ander orgaan die of dat een AI-systeem of een AI-model voor algemene doeleinden ontwikkelt of laat ontwikkelen en dat systeem of model in de handel brengt of het AI-systeem in gebruik stelt onder de eigen naam of merk, al dan niet tegen betaling.
Veel organisaties denken dat zij aanbieder zijn omdat zij een model gebruiken. Gebruik alleen is niet de toets: het onderscheid zit in onder de eigen naam of merk in de handel brengen of in gebruik stellen. Wie daarentegen een AI-model voor algemene doeleinden wijzigt of verfijnt en het resultaat in de handel brengt, wordt wel aanbieder van dat gewijzigde model; overweging 109 beperkt de verplichtingen dan tot die wijziging of verfijning. Omgekeerd denken organisaties ten onrechte dat zij nooit aanbieder kunnen zijn omdat zij niets verkopen: laat ontwikkelen telt mee, gratis telt mee, en een intern gebouwde tool die u onder eigen naam voor eigen gebruik in gebruik stelt maakt u aanbieder naast gebruiksverantwoordelijke. Artikel 25, lid 1 laat een distributeur, importeur, gebruiksverantwoordelijke of derde bovendien in de rol van aanbieder van een hoogrisicosysteem stappen wanneer hij zijn naam of merk erop zet, een substantiele wijziging aanbrengt, of het beoogde doel zo wijzigt dat het systeem hoog risico wordt.
Beoordeel de rolvraag per systeem en niet per organisatie, en leg het antwoord vast met de reden. Neem in het register drie velden op: onder wiens naam of merk wordt het systeem aangeboden of in gebruik gesteld, wie heeft het ontwikkeld of laten ontwikkelen, en is het beoogde doel of de configuratie sinds ingebruikname gewijzigd. Herbeoordeel die velden bij elke substantiele wijziging.
Een conformiteitsbeoordelingsinstantie die overeenkomstig deze verordening en andere relevante harmonisatiewetgeving van de Unie is aangemeld. Alleen aangemelde instanties mogen de externe beoordelingen onder de AI Act uitvoeren.
Artikel 3, punt 22, definieert een aangemelde instantie als een conformiteitsbeoordelingsinstantie die overeenkomstig deze verordening en andere relevante harmonisatiewetgeving van de Unie is aangemeld.
Het grootste misverstand is dat elk systeem met een hoog risico langs een aangemelde instantie moet. Dat is onjuist: voor het merendeel van de Bijlage III-systemen volstaat interne controle door de aanbieder zelf. Externe betrokkenheid is vooral aan de orde bij biometrie en bij producten die al onder de harmonisatiewetgeving van Bijlage I vallen, waar de bestaande productkeuring de AI-eisen meeneemt. Wie standaard om een certificaat van een aangemelde instantie vraagt in een aanbesteding, vraagt vaak om iets dat voor dat systeem niet bestaat, en sluit daarmee geschikte leveranciers uit.
Bepaal per systeem met een hoog risico of externe beoordeling wettelijk vereist is voordat u die eis in een contract of aanbesteding opneemt, en leg die analyse vast. Vraagt u wel om betrokkenheid van een aangemelde instantie, noteer dan het identificatienummer en de scope van de instantie en controleer die in de officiele Uniedatabank.
De nationale autoriteit die de procedures opzet en uitvoert voor de beoordeling, aanwijzing en kennisgeving van conformiteitsbeoordelingsinstanties, en die daarop toezicht houdt.
Artikel 3, punt 19, definieert de aanmeldende autoriteit als de nationale autoriteit die verantwoordelijk is voor het opzetten en uitvoeren van de noodzakelijke procedures voor de beoordeling, aanwijzing en kennisgeving van de conformiteitsbeoordelingsinstanties en de monitoring hiervan.
De aanmeldende autoriteit is niet uw aanspreekpunt en houdt geen toezicht op u. Zij keurt de keurmeesters. Dat verschil wordt in de markt vaak gemist: bedrijven zoeken contact met de aanmeldende autoriteit terwijl zij bij de markttoezichtautoriteit moeten zijn. Voor de meeste organisaties is de praktische betekenis indirect maar reeel: zolang lidstaten weinig instanties hebben aangewezen, is er beperkte capaciteit voor de systemen die wel externe beoordeling nodig hebben.
Leg in uw dossier vast welke nationale instanties voor uw sector relevant zijn en welke rol zij hebben, zodat u bij een melding of vraag niet bij de verkeerde partij aanklopt. Onderscheid daarbij expliciet de aanmeldende autoriteit, de markttoezichtautoriteit en de eventuele aangemelde instantie van uw leverancier.
Geen zelfstandige autoriteit maar een functie binnen de Europese Commissie. Voor AI-modellen voor algemene doeleinden is het AI-bureau uw toezichthouder, voor gewone AI-systemen niet.
Artikel 3, punt 47 definieert het AI-bureau als de taak van de Commissie waarbij zij bijdraagt aan de uitvoering van, de monitoring van en het toezicht op AI-systemen en AI-modellen voor algemene doeleinden, en AI-governance, als bepaald in het besluit van de Commissie van 24 januari 2024. Verwijzingen in de verordening naar het AI-bureau worden begrepen als verwijzingen naar de Commissie.
De slotzin is het belangrijkst: het AI-bureau is juridisch de Commissie. Er is dus geen apart agentschap waar u bezwaar tegen maakt, en de bevoegdheden zijn die van de Commissie. Praktisch gevolg: voor aanbieders van AI-modellen voor algemene doeleinden is het AI-bureau de handhaver. De verplichtingen van artikel 53 gelden sinds 2 augustus 2025 en zijn sinds 2 augustus 2026 handhaafbaar. Voor gewone AI-systemen loopt uw contact niet via het AI-bureau maar via de nationale markttoezichtautoriteit. Organisaties sturen hun vragen regelmatig naar het verkeerde loket en verliezen daar tijd mee.
Leg in uw escalatie- en contactschema vast wie waar aanklopt: vragen en meldingen over AI-modellen voor algemene doeleinden bij het AI-bureau, vragen over AI-systemen bij de nationale markttoezichtautoriteit. Wijs één interne eigenaar per route aan.
Vaardigheden, kennis en begrip die aanbieders, gebruiksverantwoordelijken en betrokken personen in staat stellen AI-systemen geinformeerd in te zetten en zich bewust te worden van de kansen, de risico's en de mogelijke schade van AI.
Artikel 3, punt 56, definieert AI-geletterdheid als vaardigheden, kennis en begrip die aanbieders, gebruiksverantwoordelijken en betrokken personen, rekening houdend met hun respectieve rechten en plichten in het kader van deze verordening, in staat stellen geinformeerd AI-systemen in te zetten en zich bewuster te worden van de kansen en risico's van AI en de mogelijke schade die zij kan veroorzaken.
De definitie is rolgebonden: geletterdheid moet passen bij de rechten en plichten van de betrokkene, dus bij een recruiter iets anders betekenen dan bij een ontwikkelaar of een compliance lead. Daar gaat het in de praktijk mis. Organisaties kopen een algemene e-learning voor iedereen en denken klaar te zijn, terwijl de definitie vraagt om begrip dat aansluit op wat iemand feitelijk met AI doet. Artikel 4 is sinds 2 februari 2025 van toepassing en is met de Digital Omnibus, Verordening (EU) 2026/1744 die op 27 juli 2026 in werking is getreden, een maatregelenplicht geworden zonder gegarandeerd individueel niveau. Dat verlaagt de lat voor het resultaat, maar niet voor het bewijs: u moet nog steeds laten zien welke maatregelen u heeft genomen en waarom die passend zijn.
Leg vast welke rollen in uw organisatie met AI werken, welk niveau van kennis en begrip bij elke rol hoort, welke maatregel u daarvoor heeft getroffen en wanneer. Bewaar per persoon de deelname en de datum, en herhaal de maatregel wanneer iemand van rol wisselt of wanneer een nieuw AI-systeem in gebruik wordt genomen, zodat u op elk moment kunt tonen wie aantoonbaar is voorbereid.
AI-model voor algemene doeleinden (GPAI-model)
Het model is iets anders dan het systeem, en dat onderscheid bepaalt welk hoofdstuk met verplichtingen op u van toepassing is.
AI-modellen die worden gebruikt voor onderzoek, ontwikkeling of prototypingactiviteiten alvorens zij in de handel worden gebracht, vallen buiten de definitie.
Artikel 3, punt 63 omschrijft een AI-model voor algemene doeleinden als een AI-model, ook wanneer het is getraind met een grote hoeveelheid data met behulp van self-supervision op grote schaal, dat een aanzienlijk algemeen karakter vertoont en in staat is op competente wijze een breed scala aan verschillende taken uit te voeren, ongeacht de wijze waarop het model in de handel wordt gebracht, en dat kan worden geintegreerd in een verscheidenheid aan systemen verder in de AI-waardeketen of toepassingen verder in de AI-waardeketen, met uitzondering van AI-modellen die worden gebruikt voor onderzoek, ontwikkeling of prototypingactiviteiten alvorens zij in de handel worden gebracht. Punt 66 omschrijft daarnaast een AI-systeem voor algemene doeleinden als een AI-systeem dat is gebaseerd op een AI-model voor algemene doeleinden en dat verschillende doeleinden kan dienen, zowel voor direct gebruik als voor integratie in andere AI-systemen.
Model en systeem worden in de praktijk als synoniemen gebruikt, en dat is de kern van de verwarring. Punt 63 gaat over het model, punt 66 over het systeem daarbovenop. De verplichtingen voor GPAI-modellen rusten op de aanbieder van het model; de organisatie die dat model in een eigen toepassing verwerkt, heeft in beginsel te maken met het regime voor AI-systemen. Twee dingen worden verder gemist. De definitie sluit uitdrukkelijk modellen uit die worden gebruikt voor onderzoek, ontwikkeling of prototyping voordat zij in de handel worden gebracht, dus de uitzondering vervalt op het moment van in de handel brengen. En de zinsnede ongeacht de wijze waarop het model in de handel wordt gebracht betekent dat ook open beschikbaar gestelde modellen binnen de definitie kunnen vallen. Voor de tijdlijn: artikel 53 is van kracht sinds 2 augustus 2025, de handhavingsbevoegdheden van de Commissie en het AI Office en de boetes van artikel 101 zijn actief sinds 2 augustus 2026, en voor modellen die voor 2 augustus 2025 in de handel waren gebracht loopt de termijn tot 2 augustus 2027.
Onderscheid in uw register expliciet de laag model en de laag systeem, en noteer per toepassing welk onderliggend model wordt gebruikt, van welke aanbieder, en of uw organisatie dat model zelf in de handel brengt. Leg bij eigen modelontwikkeling het moment vast waarop het onderzoeks- of prototypestadium eindigt, want daar begint het regime.
De poortdefinitie van het systeemspoor van de verordening: valt uw applicatie hier niet onder, dan gelden de verplichtingen voor AI-systemen niet. Voor AI-modellen voor algemene doeleinden loopt een eigen spoor op grond van artikel 3, punt 63, met eigen verplichtingen in artikel 53.
Artikel 3, punt 1 omschrijft een AI-systeem als een op een machine gebaseerd systeem dat is ontworpen om met verschillende niveaus van autonomie te werken en dat na het inzetten ervan aanpassingsvermogen kan vertonen, en dat, voor expliciete of impliciete doelstellingen, uit de ontvangen input afleidt hoe output te genereren zoals voorspellingen, inhoud, aanbevelingen of beslissingen die van invloed kunnen zijn op fysieke of virtuele omgevingen.
Twee spiegelbeeldige fouten. De eerste: alleen generatieve AI en taalmodellen als AI-systeem aanmerken, waardoor klassieke scoringsmodellen, matchingalgoritmen en voorspelmodellen buiten het register blijven terwijl zij juist afleiden hoe output te genereren. De tweede: elk stuk software AI noemen, waardoor het register onbruikbaar wordt. Het scharnier is het woord afleidt: een systeem dat uitsluitend een door mensen vastgelegde regel uitvoert, leidt niets af. Let ook op het woord kan in kan vertonen: aanpassingsvermogen na inzet is een mogelijkheid, geen voorwaarde. Een model dat na training bevroren is, blijft een AI-systeem.
Leg per applicatie in uw AI-register drie antwoorden vast met datum en naam van de beoordelaar: werkt het met enige mate van autonomie, leidt het uit input af hoe output tot stand komt, en wat is die output. Bewaar bij een negatieve uitkomst de motivering, want dat is het document waarmee u later verklaart waarom het systeem niet in scope is.
Een door een bevoegde autoriteit opgezet gecontroleerd kader waarin u een innovatief AI-systeem tijdelijk mag ontwikkelen, trainen, valideren en testen onder begeleiding van de toezichthouder, volgens een testomgevingsplan.
Artikel 3, punt 55 omschrijft een AI-testomgeving voor regelgeving als een door een bevoegde autoriteit opgezet gecontroleerd kader dat aanbieders of toekomstige aanbieders van AI-systemen de mogelijkheid biedt een innovatief AI-systeem te ontwikkelen, trainen, valideren en testen, zo nodig onder reële omstandigheden, volgens een testomgevingsplan, voor een beperkte periode en onder begeleiding van een toezichthouder.
De grootste misvatting is dat een testomgeving vrijstelling geeft van de verordening. Dat is niet zo. Het kader is gecontroleerd en tijdelijk, en het staat onder begeleiding van een toezichthouder; het schort de verplichtingen niet op. Bovendien noemt de definitie uitdrukkelijk toekomstige aanbieders, zodat ook partijen die nog niets in de handel hebben gebracht kunnen deelnemen. Wie de testomgeving gebruikt als marketingterm zonder toelating door een bevoegde autoriteit, gebruikt het begrip onjuist.
Leg vast of uw deelname formeel is toegelaten door een bevoegde autoriteit, welke periode geldt, welk testomgevingsplan van toepassing is en welke verplichtingen tijdens de deelname gewoon blijven gelden. Neem de uitkomsten van de testomgeving op in uw technische documentatie.
Het door de aanbieder vastgelegde gebruik waar de hele risicoclassificatie en beoordeling op rusten.
Artikel 3, punt 12 omschrijft het beoogde doel als het gebruik waarvoor een AI-systeem door de aanbieder is bedoeld, met inbegrip van de specifieke context en voorwaarden van het gebruik, zoals gespecificeerd in de informatie die door de aanbieder in de gebruiksinstructies, reclame- of verkoopmaterialen en verklaringen, alsook in de technische documentatie is verstrekt.
Twee dingen worden structureel gemist. Ten eerste: het beoogde doel wordt bepaald door de aanbieder, niet door wat u er als gebruiksverantwoordelijke mee doet. Ten tweede, en dit raakt aanbieders hard: het beoogde doel wordt niet alleen uit de handleiding afgeleid, maar ook uit reclame- en verkoopmateriaal en uit verklaringen. Een marketingclaim dat het systeem ook geschikt is voor werving of voor kredietbeoordeling verruimt daarmee het beoogde doel en kan de risicoclassificatie verschuiven. Voor gebruiksverantwoordelijken geldt de spiegelbeeldige waarschuwing: gebruik buiten het beoogde doel is niet vrij. Het kan redelijkerwijs te voorzien misbruik opleveren, en het kan op grond van artikel 25, lid 1, punt c) een wijziging van het beoogde doel zijn die u zelf tot aanbieder maakt, maar dat laatste alleen wanneer het systeem daardoor een AI-systeem met een hoog risico wordt overeenkomstig artikel 6.
Laat marketing en productmanagement de claims over toepassingsgebieden expliciet afstemmen op de gebruiksinstructies en de technische documentatie, en leg vast dat die drie bronnen dezelfde afbakening bevatten. Noteer als gebruiksverantwoordelijke per systeem het beoogde doel zoals de leverancier het beschrijft naast uw feitelijke gebruik, en markeer elk verschil als beslispunt.
De gevoelige gegevenscategorieen uit de AVG en de aanverwante Europese regels, hier overgenomen omdat de AI Act er zowel een verbod als een nauwe uitzondering aan ophangt.
Artikel 3(37) definieert bijzondere categorieen persoonsgegevens als de categorieen persoonsgegevens als bedoeld in artikel 9, lid 1, van Verordening (EU) 2016/679, artikel 10 van Richtlijn (EU) 2016/680 en artikel 10, lid 1, van Verordening (EU) 2018/1725.
De definitie verwijst door, maar de AI Act geeft haar twee zelfstandige gevolgen. Ten eerste raakt zij artikel 5, handhaafbaar sinds 2 februari 2025: biometrische categorisering die individueel gevoelige kenmerken afleidt, zoals ras, politieke opvattingen, vakbondslidmaatschap, religie, seksleven of seksuele gerichtheid, is verboden. Ten tweede bevat artikel 10, lid 5, een uitzondering die verwerking van bijzondere gegevens toestaat wanneer dat strikt noodzakelijk is om vertekening in high-risk systemen op te sporen en te corrigeren. Die uitzondering wordt structureel te ruim gelezen. Zij geldt alleen voor high-risk systemen, alleen wanneer andere middelen aantoonbaar niet volstaan, met technische beperkingen op hergebruik en doorgifte, en met wissing zodra de vertekening is verholpen. Zij is dus geen algemene grondslag om gevoelige kenmerken te gaan verzamelen omdat u aan eerlijkheidsmetingen wilt doen.
Leg vast of u zich op artikel 10, lid 5, beroept, voor welk high-risk systeem, waarom synthetische of geanonimiseerde data niet volstaan, welke technische en organisatorische waarborgen gelden, wie toegang heeft, en op welk moment de gegevens worden gewist. Stem dit af met uw functionaris voor gegevensbescherming en verwijs vanuit uw AI-dossier naar de bijbehorende gegevensbeschermingseffectbeoordeling.
De AI Act hanteert een eigen, ruimere omschrijving dan de AVG, en dat verschil bepaalt of u in bijlage III of in artikel 5 belandt.
Artikel 3, punt 34 omschrijft biometrische gegevens als persoonsgegevens die het resultaat zijn van een specifieke technische verwerking met betrekking tot de fysieke, fysiologische of gedragsgerelateerde kenmerken van een natuurlijk persoon, zoals gezichtsafbeeldingen of vingerafdrukgegevens.
Vrijwel iedereen leest hier de AVG-definitie overheen. Dat gaat mis op een punt dat juridisch beslissend is: artikel 4, punt 14 AVG eist dat de verwerking eenduidige identificatie mogelijk maakt of bevestigt, en die eis staat niet in punt 34 van de AI-verordening. Gegevens over gedragsgerelateerde kenmerken, zoals typeritme, looppatroon of stemkenmerken, kunnen daardoor binnen de AI Act biometrische gegevens zijn ook wanneer identificatie niet het doel is. Wie zijn AI-inventarisatie baseert op de AVG-kwalificatie loopt daarmee het risico systemen te missen die onder artikel 5 of bijlage III vallen. Voor de AVG-kant van dezelfde verwerking blijft die verordening onverkort gelden.
Beoordeel biometrie in uw AI-register apart van de AVG-beoordeling en leg beide uitkomsten naast elkaar vast. Neem daarbij ook systemen mee die gedragskenmerken verwerken zonder identificatiedoel, zoals fraudedetectie op typegedrag of stemanalyse in de klantcontactketen.
Een op veel vergelijking tegen een databank, te onderscheiden van de een op een verificatie van punt 36.
Artikel 3, punt 35 omschrijft biometrische identificatie als de geautomatiseerde herkenning van fysieke, fysiologische, gedragsgerelateerde of psychologische menselijke kenmerken om de identiteit van een natuurlijk persoon vast te stellen door biometrische gegevens van die persoon te vergelijken met in een databank opgeslagen biometrische gegevens van personen. Punt 36 omschrijft biometrische verificatie daarnaast als de geautomatiseerde een op een verificatie, met inbegrip van de authenticatie, van de identiteit van natuurlijke personen door hun biometrische gegevens te vergelijken met eerder verstrekte biometrische gegevens.
Identificatie en verificatie worden in gesprekken met leveranciers door elkaar gebruikt, terwijl het verschil bepalend is voor het regime. Identificatie is een op veel: het systeem zoekt wie iemand is door te vergelijken met een databank met gegevens van personen. Verificatie is een op een: het systeem bevestigt of iemand is wie hij zegt te zijn. Toegangscontrole met een gezichtsscan tegen het eigen personeelspasje is verificatie; een camera die gezichten langs een watchlist haalt is identificatie. Een detail dat zelden wordt opgemerkt: punt 35 noemt ook psychologische kenmerken, terwijl de definitie van biometrische gegevens in punt 34 die niet noemt.
Leg per biometrietoepassing schriftelijk vast of de vergelijking een op een of een op veel is, met welke databank wordt vergeleken en wie die databank beheert. Vraag dat bij aanbesteding uit als harde eis, want leveranciersmateriaal spreekt zelden in deze termen en het antwoord bepaalt of u in artikel 5 of in bijlage III uitkomt.
Systeem voor biometrische identificatie op afstand achteraf
De restcategorie: elke identificatie op afstand die niet in real time gebeurt. Niet verboden, wel hoog risico, en bij rechtshandhaving met een eigen toestemmingsregime.
Artikel 3, punt 43 definieert dit als een ander systeem voor biometrische identificatie op afstand dan een systeem voor biometrische identificatie op afstand in real time.
Een restcategorie is geen vrijplaats. Achteraf beelden doorzoeken op personen valt niet onder het verbod van artikel 5, maar is wel hoog risico op grond van bijlage III, punt 1, letter a, vanaf 2 december 2027. Voor rechtshandhaving geldt bovendien artikel 26, lid 10: gebruik vereist in beginsel voorafgaande of onverwijld ingediende toestemming van een rechterlijke of onafhankelijke administratieve autoriteit, gekoppeld aan een concreet strafbaar feit. Organisaties die "we kijken alleen achteraf terug" als geruststelling gebruiken, verwarren het ontbreken van een verbod met het ontbreken van verplichtingen.
Leg per zoekopdracht vast wie toestemming heeft gegeven, op welk strafbaar feit of welke grondslag de zoekactie berust, welke periode en welke beelden zijn doorzocht, en wat het resultaat was.
Systeem voor biometrische identificatie op afstand in real time
Identificatie op afstand waarbij vastleggen, vergelijken en identificeren zonder significante vertraging gebeuren. De wetgever heeft de ontsnappingsroute van een kunstmatige vertraging expliciet dichtgezet.
Artikel 3, punt 42 definieert dit als een systeem voor biometrische identificatie op afstand waarbij het vastleggen van biometrische gegevens, de vergelijking en de identificatie zonder significante vertraging plaatsvinden, waarbij niet alleen onmiddellijke identificatie eronder valt maar ook identificatie met beperkte korte vertragingen, om omzeiling te voorkomen.
De zinsnede over beperkte korte vertragingen staat er niet voor niets. Zij sluit de constructie af waarbij men bewust een buffer van seconden of minuten inbouwt om te kunnen zeggen dat het systeem niet in real time werkt. Het onderscheid doet er zwaar toe: het gebruik van real-time identificatie op afstand in voor het publiek toegankelijke ruimten voor rechtshandhaving is sinds 2 februari 2025 in beginsel verboden op grond van artikel 5, lid 1, punt h, met smalle uitzonderingen die vooraf toestemming en een nationale wettelijke basis vergen.
Leg de verwerkingsarchitectuur en de feitelijke latency van het systeem vast, inclusief meetresultaten. Een verklaring dat u "bufferet" is geen verdediging als de identificatie in de praktijk binnen enkele seconden of minuten bruikbaar wordt.
De markering waarmee een aanbieder aangeeft dat een AI-systeem voldoet aan de voorschriften van hoofdstuk III, afdeling 2, en aan andere toepasselijke harmonisatiewetgeving van de Unie die in het aanbrengen ervan voorziet.
Artikel 3, punt 24, definieert de CE-markering als een markering waarmee een aanbieder aangeeft dat een AI-systeem in overeenstemming is met de voorschriften van hoofdstuk III, afdeling 2, en andere toepasselijke harmonisatiewetgeving van de Unie die in het aanbrengen ervan voorziet.
De CE-markering is een verklaring van de aanbieder zelf, geen keurmerk van een toezichthouder en geen kwaliteitslabel. Zij hoort uitsluitend bij AI-systemen met een hoog risico, dus een leverancier die CE-markering opvoert als verkoopargument voor een gewone chatbot verkoopt u een verkeerd verhaal. Omgekeerd is de afwezigheid van CE-markering geen tekortkoming bij een systeem dat geen hoog risico is. Voor systemen met een hoog risico wordt dit relevant vanaf 2 december 2027 voor Bijlage III en 2 augustus 2028 voor Bijlage I.
Vraag bij elk AI-systeem met een hoog risico om de EU-conformiteitsverklaring die achter de CE-markering hoort te zitten en bewaar die in uw dossier, met de versie van het systeem waarop zij betrekking heeft. Accepteer een CE-verwijzing zonder onderliggende verklaring niet als bewijs.
Het proces waarbij wordt aangetoond dat een AI-systeem met een hoog risico voldoet aan de voorschriften van hoofdstuk III, afdeling 2. Het is de bewijsstap voor systemen met een hoog risico, en niet voor alle AI.
Artikel 3, punt 20, definieert conformiteitsbeoordeling als het proces waarbij de naleving wordt aangetoond van de voorschriften van hoofdstuk III, afdeling 2, in verband met een AI-systeem met een hoog risico.
Twee misverstanden domineren. Het eerste is dat elke AI-toepassing een conformiteitsbeoordeling nodig heeft: de definitie beperkt het uitdrukkelijk tot systemen met een hoog risico. Het tweede is dat conformiteitsbeoordeling gelijkstaat aan een externe audit: voor het merendeel van de Bijlage III-systemen volstaat de interne controle van artikel 43, waarbij de aanbieder zelf aantoont dat aan de voorschriften is voldaan. Wie geen hoog risico heeft, doet er goed aan die conclusie schriftelijk te onderbouwen in plaats van er stilzwijgend van uit te gaan. De verplichtingen gelden voor Bijlage III-systemen vanaf 2 december 2027 en voor Bijlage I-producten vanaf 2 augustus 2028.
Leg per AI-systeem uw risicoclassificatie schriftelijk vast met de motivering, ook wanneer de uitkomst is dat er geen hoog risico is. Bij een hoog risico legt u daarnaast vast welke route u volgt, interne controle of betrokkenheid van een aangemelde instantie, en welk bewijs per voorschrift van hoofdstuk III, afdeling 2, in het technisch dossier zit.
Een instantie die als derde partij conformiteitsbeoordelingsactiviteiten verricht, zoals testen, certificeren en inspecteren.
Artikel 3, punt 21, definieert een conformiteitsbeoordelingsinstantie als een instantie die als derde partij conformiteitsbeoordelingsactiviteiten verricht, zoals onder meer testen, certificeren en inspecteren.
Het kernwoord is derde partij. Een interne auditafdeling, een adviesbureau of uw eigen kwaliteitsteam is geen conformiteitsbeoordelingsinstantie, hoe grondig het werk ook is. En let op het verschil met de aangemelde instantie in punt 22: elke aangemelde instantie is een conformiteitsbeoordelingsinstantie, maar niet andersom. Pas na aanmelding mag een instantie de wettelijke beoordelingen onder deze verordening uitvoeren. Certificaten van niet aangemelde partijen hebben commerciele waarde maar geen wettelijke status onder de AI Act.
Controleer voordat u een externe beoordeling inkoopt of de partij daadwerkelijk is aangemeld voor de relevante scope en leg het bewijs daarvan vast in uw dossier. Bewaar bij elk extern rapport welke rol de partij had, adviseur of aangemelde instantie, zodat later niet de indruk ontstaat dat een adviesrapport een wettelijke beoordeling was.
Veel ruimer dan nepvideo's van bekende personen: ook voorwerpen, plaatsen, entiteiten en gebeurtenissen vallen eronder.
Artikel 3, punt 60 omschrijft een deepfake als door AI gegenereerd of gemanipuleerd beeld-, audio- of videomateriaal dat een gelijkenis vertoont met bestaande personen, voorwerpen, plaatsen, entiteiten of gebeurtenissen, en door een persoon ten onrechte voor authentiek of waarheidsgetrouw zou worden aangezien.
De naam stuurt de lezing de verkeerde kant op. Een deepfake is in deze verordening niet beperkt tot nepbeelden van bekende personen: de definitie noemt uitdrukkelijk ook voorwerpen, plaatsen, entiteiten en gebeurtenissen. Een AI-gegenereerde foto van een bestaand pand, een niet-plaatsgevonden demonstratie of een productafbeelding die als echte opname overkomt kan dus een deepfake zijn. Twee grenzen zijn belangrijk. De definitie noemt beeld, audio en video; zuivere tekst valt er niet onder, al kent artikel 50 voor bepaalde publicaties een eigen regel. En materiaal dat gelijkt op een niet-bestaand persoon valt buiten punt 60, terwijl het wel onder de markeringsplicht voor synthetische output kan vallen. Artikel 50 is van kracht sinds 2 augustus 2026; de enige overgang betreft de machineleesbare markering van artikel 50, lid 2 voor systemen die voor 2 augustus 2026 op de markt waren, en die loopt tot 2 december 2026.
Breng in kaart welke afdelingen AI-gegenereerd beeld, audio of video publiceren, inclusief marketing, communicatie, opleidingen en klantcontact, en leg per uitingskanaal vast hoe de kunstmatige oorsprong kenbaar wordt gemaakt. Neem daarbij ook gegenereerde afbeeldingen van bestaande locaties en producten mee, want juist die worden zelden als deepfake herkend.
Elke schakel in de keten die een AI-systeem op de Uniemarkt aanbiedt en die geen aanbieder of importeur is.
Alleen van toepassing op een partij in de toeleveringsketen die niet de aanbieder en niet de importeur is.
Artikel 3, punt 7 omschrijft een distributeur als een andere natuurlijke persoon of rechtspersoon in de toeleveringsketen dan de aanbieder of de importeur, die een AI-systeem in de Unie op de markt aanbiedt.
Resellers, systeemintegratoren, marktplaatsen en detacheerders die software meeleveren gaan er vaak van uit dat zij buiten de verordening vallen omdat zij niets bouwen. De definitie is een restcategorie: bent u in de keten geen aanbieder en geen importeur, en biedt u het systeem in de Unie op de markt aan, dan bent u distributeur. Let daarbij op punt 10: op de markt aanbieden betekent verstrekken in het kader van een handelsactiviteit, al dan niet tegen betaling. Gratis doorleveren of een proefversie beschikbaar stellen valt er dus ook onder. Zet u er uw eigen naam of merk op, dan verschuift de rol naar aanbieder.
Breng in kaart welke AI-systemen uw organisatie aan derden doorlevert, ook gratis en ook als bijproduct van een dienst, en leg per systeem vast wiens naam of merk erop staat. Neem in uw doorleveringscontracten op wie welke rol vervult, zodat later niet ter discussie staat wie de aanbieder was.
Aanbieder verder in de AI-waardeketen (downstreamaanbieder)
Een aanbieder van een AI-systeem, ook een AI-systeem voor algemene doeleinden, waarin een AI-model is geïntegreerd, ongeacht of hij dat model zelf levert en verticaal heeft geïntegreerd of het op contractuele basis van een andere partij betrekt.
Artikel 3, punt 68 omschrijft een aanbieder verder in de AI-waardeketen als een aanbieder van een AI-systeem, met inbegrip van een AI-systeem voor algemene doeleinden, waarin een AI-model is geïntegreerd, ongeacht of het AI-model door hemzelf wordt verstrekt en verticaal geïntegreerd is of door een andere entiteit wordt aangeboden op basis van contractuele betrekkingen.
Dit is de definitie waarmee organisaties zich het vaakst vergissen in hun eigen rol. Wie een bestaand model van een derde in een eigen product of dienst integreert en dat onder eigen naam aanbiedt, is aanbieder verder in de AI-waardeketen en dus zelf aanbieder, niet slechts gebruiksverantwoordelijke. De woorden ongeacht of maken duidelijk dat het niet uitmaakt of u het model zelf hebt gebouwd. Uw positie bepaalt welke informatie u van de modelaanbieder moet kunnen krijgen: aanbieders van AI-modellen voor algemene doeleinden moeten op grond van artikel 53 documentatie beschikbaar stellen aan aanbieders verder in de keten, verplicht sinds 2 augustus 2025 en handhaafbaar sinds 2 augustus 2026.
Leg per AI-systeem vast welk onderliggend model is geïntegreerd, van welke partij, en of u daarmee optreedt als aanbieder verder in de AI-waardeketen. Neem in het contract met de modelaanbieder op welke documentatie uit artikel 53 u ontvangt en houd die documentatie in uw eigen dossier.
Op de werkplek en in het onderwijs verboden sinds 2 februari 2025; daarbuiten geldt sinds 2 augustus 2026 een informatieplicht onder artikel 50.
Het verbod van artikel 5, lid 1, punt f) geldt niet wanneer het gebruik van het AI-systeem is bedoeld om uit medische of veiligheidsoverwegingen te worden ingevoerd of in de handel te worden gebracht.
Artikel 3, punt 39 omschrijft een systeem voor het herkennen van emoties als een AI-systeem dat is bedoeld voor het vaststellen of afleiden van de emoties of intenties van natuurlijke personen op basis van hun biometrische gegevens. Artikel 5, lid 1, punt f) verbiedt het in de handel brengen, het voor dit specifieke doel in gebruik stellen of het gebruiken van AI-systemen om emoties van een natuurlijke persoon op de werkplek en in het onderwijs af te leiden, behalve wanneer het gebruik van het AI-systeem is bedoeld om uit medische of veiligheidsoverwegingen te worden ingevoerd of in de handel te worden gebracht.
Twee afbakeningsfouten. De eerste: aannemen dat elke vorm van sentimentanalyse hieronder valt. De definitie eist dat het afleiden gebeurt op basis van biometrische gegevens. Sentimentanalyse op geschreven tekst, zonder biometrie, valt buiten punt 39, ook al voelt het vergelijkbaar. De tweede: alleen aan gezichtsuitdrukkingen denken, terwijl stemanalyse in een callcenter en houdingsanalyse via camerabeelden er evengoed onder vallen. Let ook op het woord intenties naast emoties: systemen die verkoopbereidheid of agressie voorspellen uit biometrie vallen binnen de definitie. Buiten de werkplek en het onderwijs is emotieherkenning niet verboden, maar zij staat wel in bijlage III, punt 1, onder c), en geldt daar dus als AI-systeem met een hoog risico zodra artikel 6, lid 2 op 2 december 2027 van toepassing wordt. Daarnaast rust sinds 2 augustus 2026 op de gebruiksverantwoordelijke de informatieplicht van artikel 50, lid 3 richting de blootgestelde personen, behalve voor systemen die bij wet zijn toegestaan om strafbare feiten op te sporen, te voorkomen, te onderzoeken of te vervolgen.
Inventariseer waar in uw organisatie stem-, gezichts- of houdingsanalyse draait, ook als onderdeel van een groter pakket zoals kwaliteitsmonitoring in klantcontact, toegangscontrole of proctoring. Beoordeel per toepassing of biometrische gegevens de basis vormen en of de context werkplek of onderwijs is; leg die beoordeling vast, want dit is de categorie waar een boete tot 35 miljoen euro of 7 procent van de wereldwijde omzet aan hangt.
Vier categorieën gevolgen, waaronder de schending van grondrechtenbescherming. Er hoeft geen fysieke schade te zijn voordat een meldplicht ontstaat.
Artikel 3, punt 49 definieert een ernstig incident als een incident of gebrekkig functioneren van een AI-systeem dat direct of indirect leidt tot: (a) het overlijden van een persoon of ernstige schade voor de gezondheid van een persoon, (b) een ernstige en onomkeerbare verstoring van het beheer of de exploitatie van kritieke infrastructuur, (c) een schending van de uit het recht van de Unie voortvloeiende verplichtingen ter bescherming van de grondrechten, of (d) ernstige schade aan eigendommen of het milieu.
Onderdeel c is de bepaling die organisaties het vaakst missen. Een schending van Unierechtelijke grondrechtenbescherming telt als ernstig incident, ook zonder één gewonde. Systematische discriminatie in een selectiesysteem voor sollicitanten, in kredietbeoordeling of in de toekenning van voorzieningen kan daarmee meldplichtig zijn. Ook "indirect" telt: het gaat niet alleen om de directe output maar om het gevolg verderop in het proces. Aanbieders van hoogrisicosystemen melden op grond van artikel 73 aan de markttoezichtautoriteit, met korte termijnen: in beginsel uiterlijk 15 dagen na bekendwording, 2 dagen bij wijdverbreide inbreuk of ernstige verstoring van kritieke infrastructuur en 10 dagen bij overlijden. Die plicht wordt scherp met de hoogrisicodata, bijlage III per 2 december 2027 en bijlage I per 2 augustus 2028, maar het registreren van incidenten begint u nu.
Richt nu een incidentregister in dat de vier categorieën van punt 49 apart uitvraagt, met een tijdstempel op het moment van bekendwording. Test één keer of u binnen twee dagen een volledige melding kunt indienen; dat is de scherpste termijn en die haalt u niet met een ad-hocproces.
De informatie die de aanbieder verstrekt om de gebruiksverantwoordelijke te informeren over met name het beoogde doel en het juiste gebruik van een AI-systeem. Dit is het scharnier tussen de plichten van de aanbieder en die van de afnemer.
Artikel 3, punt 15, definieert gebruiksinstructies als de door de aanbieder verstrekte informatie om de gebruiksverantwoordelijke te informeren over met name het beoogde doel en juiste gebruik van een AI-systeem.
Hier gaat het in de praktijk mis in twee richtingen. Aanbieders leveren marketingmateriaal of een technische handleiding in plaats van instructies die het beoogde doel en de grenzen van correct gebruik benoemen. En gebruiksverantwoordelijken slaan die instructies op zonder ze te lezen, terwijl artikel 26 hen verplicht het systeem juist volgens die instructies te gebruiken. Wie buiten de gebruiksinstructies om gaat gebruiken, kan onder artikel 25 zelf als aanbieder worden aangemerkt en daarmee het hele pakket aanbiedersplichten binnenhalen.
Bewaar per AI-systeem de actuele gebruiksinstructies in uw dossier, met versienummer en datum van ontvangst. Leg daarnaast vast wie binnen uw organisatie de instructies heeft gelezen, welk gebruik u daaruit als toegestaan afleidt en welk gebruik u expliciet heeft verboden in uw eigen werkinstructie.
De rol waarin vrijwel elke organisatie zit die AI inkoopt en gebruikt.
Gebruik in het kader van een persoonlijke niet-beroepsactiviteit valt buiten de definitie.
Artikel 3, punt 4 omschrijft een gebruiksverantwoordelijke als een natuurlijke of rechtspersoon, overheidsinstantie, agentschap of ander orgaan die of dat een AI-systeem onder eigen verantwoordelijkheid gebruikt, tenzij het AI-systeem wordt gebruikt in het kader van een persoonlijke niet-beroepsactiviteit.
De Nederlandse term gebruiksverantwoordelijke wordt in de praktijk versimpeld tot gebruiker, en daar gaat het mis. De individuele medewerker die de tool bedient is niet de gebruiksverantwoordelijke; dat is de rechtspersoon die het systeem onder eigen verantwoordelijkheid inzet. De tweede val zit in de uitzondering: die geldt alleen voor persoonlijk niet-beroepsmatig gebruik. Een medewerker die op eigen initiatief een AI-tool inzet voor werk valt niet onder die uitzondering, en de organisatie blijft gebruiksverantwoordelijke, ook zonder inkoopcontract. Schaduw-AI is daarmee geen grijs gebied maar gewoon een niet-geregistreerd systeem.
Leg per systeem vast welke rechtspersoon het onder eigen verantwoordelijkheid gebruikt, inclusief tools die een afdeling zelf heeft aangeschaft of via een bestaande licentie heeft aangezet. Vul dat aan met een periodieke inventarisatie van AI-functies die leveranciers binnen bestaande software hebben geactiveerd, want die komen zelden via inkoop binnen.
Een Europese norm die in het Publicatieblad is bekendgemaakt en die, als u haar toepast, een vermoeden van conformiteit oplevert. Dit is de snelste route naar aantoonbaarheid, maar de AI Act-normen zijn nog niet af.
Artikel 3(27) definieert een geharmoniseerde norm als een geharmoniseerde norm zoals gedefinieerd in artikel 2, lid 1, punt c), van Verordening (EU) nr. 1025/2012.
Puur tekstueel is dit een doorverwijzing, maar de praktische lading zit in artikel 40: past u een geharmoniseerde norm toe waarvan de referentie in het Publicatieblad is bekendgemaakt, dan wordt aangenomen dat u aan het bijbehorende vereiste voldoet. Dat scheelt enorm veel bewijslast. Het probleem op de peildatum is dat het normalisatiewerk bij CEN en CENELEC nog niet volledig is afgerond en gepubliceerd, waardoor organisaties nu niet kunnen leunen op een kant-en-klaar vermoeden van conformiteit. Wie wacht op de normen loopt vast, want de verplichtingen voor Bijlage III komen per 2 december 2027 en die voor Bijlage I per 2 augustus 2028. U moet de aantoonbaarheid dus zelf inrichten en later aansluiten.
Houd een register bij waarin u per vereiste uit hoofdstuk III vastlegt op welke norm, welk raamwerk of welke interne beheersmaatregel u zich baseert, en waarom die keuze het vereiste dekt. Richt dat register zo in dat u een regel kunt vervangen zodra de geharmoniseerde norm wordt bekendgemaakt, zonder uw hele dossier te hoeven herschrijven.
De vrijelijk gegeven, specifieke, ondubbelzinnige en vrijwillige uiting van een proefpersoon dat hij of zij aan een bepaalde test onder reële omstandigheden wil deelnemen, na te zijn geïnformeerd over alle aspecten die voor die beslissing van belang zijn.
Artikel 3, punt 59 omschrijft geïnformeerde toestemming als de vrijelijk gegeven, specifieke, ondubbelzinnige en vrijwillige uiting door een proefpersoon van zijn of haar bereidheid deel te nemen aan een bepaalde test onder reële omstandigheden, na geïnformeerd te zijn over alle aspecten van de test die van belang zijn voor zijn of haar beslissing om deel te nemen.
Let op het woord bepaalde: toestemming geldt voor één specifieke test, niet voor uw testprogramma als geheel en niet voor een volgende versie van het systeem. Een algemene clausule in gebruiksvoorwaarden of een arbeidsovereenkomst voldoet daar niet aan. Dit is bovendien een eigen begrip van de AI-verordening en niet hetzelfde als toestemming als grondslag onder de AVG; u kunt de twee dus niet met één formulier afdoen. Verandert de opzet van de test wezenlijk, dan hebt u nieuwe toestemming nodig.
Gebruik per test een eigen toestemmingsformulier met de informatie die voor de beslissing van belang is, en leg vast wanneer en hoe de toestemming is gegeven en hoe iemand die kan intrekken. Documenteer apart dat de toestemming vrijwillig was, zeker bij medewerkers.
Het Europese aanspreekpunt van een aanbieder van buiten de Unie, alleen geldig op basis van een schriftelijke machtiging.
De gemachtigde bevindt zich of is gevestigd in de Unie en heeft een schriftelijke machtiging gekregen en aanvaard.
Artikel 3, punt 5 omschrijft een gemachtigde als een natuurlijke of rechtspersoon die zich bevindt of gevestigd is in de Unie en die een schriftelijke machtiging heeft gekregen en aanvaard van een aanbieder van een AI-systeem of een AI-model voor algemene doeleinden om namens die aanbieder de verplichtingen en procedures van deze verordening respectievelijk na te komen en uit te voeren.
De veelgemaakte fout is dat een Europese verkooppartner, reseller of dochteronderneming zichzelf vanzelf als gemachtigde beschouwt. Dat volgt niet uit de handelsrelatie. De definitie stelt twee cumulatieve eisen: de machtiging is schriftelijk, en zij is niet alleen gegeven maar ook aanvaard. Zonder dat document is er geen gemachtigde en heeft de toezichthouder in de Unie geen formeel aanspreekpunt voor die aanbieder. Een tweede misvatting is dat de aanwijzing van een gemachtigde de rol van aanbieder overneemt. Dat doet zij niet: de gemachtigde handelt namens de aanbieder, de aanbieder blijft de aanbieder.
Vraag bij elke leverancier van buiten de Unie naar naam, vestigingsadres en contactgegevens van de gemachtigde en naar een kopie of bevestiging van de aanvaarde schriftelijke machtiging. Bewaar dat bij het systeemdossier, want het is het eerste dat u nodig heeft zodra een toezichthouder informatie opvraagt over een systeem dat u van buiten de Unie betrekt.
Technische specificaties die de Commissie zelf kan vaststellen wanneer geharmoniseerde normen ontbreken of tekortschieten. De terugvaloptie die voorkomt dat de AI Act stilvalt door vertraging in de normalisatie.
Artikel 3(28) definieert een gemeenschappelijke specificatie als een reeks technische specificaties zoals gedefinieerd in artikel 2, punt 4, van Verordening (EU) nr. 1025/2012, die middelen bieden om te voldoen aan bepaalde in deze verordening vastgelegde voorschriften.
Deze definitie bestaat omdat de wetgever voorzag dat de normalisatie niet op tijd klaar zou zijn. Artikel 41 geeft de Commissie de mogelijkheid om via uitvoeringshandelingen gemeenschappelijke specificaties vast te stellen, met hetzelfde effect: toepassing levert een vermoeden van conformiteit op. Het misverstand is dat een gemeenschappelijke specificatie vrijblijvend zou zijn. Dat is zij niet in de praktijk: wie ervan afwijkt moet aantonen dat zijn eigen technische oplossing ten minste gelijkwaardig is aan het beoogde beschermingsniveau, en die onderbouwing moet in de technische documentatie staan. Afwijken mag dus wel, maar het is duurder in documentatie dan volgen.
Volg de uitvoeringshandelingen van de Commissie en leg vast welke gemeenschappelijke specificaties voor uw systeem gelden. Kiest u een eigen oplossing, documenteer dan expliciet welk onderdeel u niet volgt, welke alternatieve maatregel u treft, en op basis van welke analyse u concludeert dat het beschermingsniveau gelijkwaardig is.
Operationele gegevens rond opsporing en vervolging waarvan openbaarmaking strafprocedures kan schaden. Het begrip waarop de rechtshandhavingsuitzonderingen op transparantie rusten.
Artikel 3(38) definieert gevoelige operationele gegevens als operationele gegevens met betrekking tot activiteiten op het gebied van preventie, opsporing, onderzoek of vervolging van strafbare feiten waarvan de openbaarmaking de integriteit van strafprocedures in het gedrang zou kunnen brengen.
Dit is de sleutel waarmee de AI Act de transparantieplichten voor rechtshandhaving afzwakt zonder ze te schrappen. Registratie van high-risk systemen die door rechtshandhavingsinstanties worden gebruikt gebeurt in een beveiligd, niet-openbaar deel van de EU-databank, en bepaalde informatie hoeft niet publiek te worden gemaakt wanneer zij gevoelige operationele gegevens betreft. Waar het misgaat: het begrip wordt soms opgerekt tot alles wat een overheidsorganisatie liever niet deelt. Dat houdt geen stand, want de definitie is dubbel begrensd, namelijk door de strafrechtelijke context en door het concrete risico voor de integriteit van strafprocedures. Buiten die context is dit geen grond om documentatie achter te houden; voor bedrijfsvertrouwelijke informatie loopt een aparte route. Ook belangrijk: het beperkt de openbaarheid, niet de toegang van de bevoegde markttoezichtautoriteit.
Leg per systeem vast welke onderdelen van uw registratie en documentatie u als gevoelige operationele gegevens aanmerkt, op welke concrete grond openbaarmaking de integriteit van een strafprocedure zou kunnen schaden, wie die beoordeling maakt en wanneer zij wordt herzien. Houd een niet-gevoelige samenvatting beschikbaar, zodat u wel kunt verantwoorden zonder lopende procedures te raken.
Wie in de Unie een systeem op de markt brengt dat de naam of het merk van een partij uit een derde land draagt.
Artikel 3, punt 6 omschrijft een importeur als een natuurlijke of rechtspersoon die zich bevindt of gevestigd is in de Unie en die een AI-systeem in de handel brengt dat de naam of het merk van een in een derde land gevestigde natuurlijke of rechtspersoon draagt.
De praktijkval is de gedachte dat importeur iets met douane of met de factuurstroom te maken heeft. De toets is anders: brengt u in de Unie een systeem voor het eerst op de markt dat de naam of het merk van een partij uit een derde land draagt. Wie een Amerikaanse dienst alleen zelf afneemt en gebruikt is geen importeur maar gebruiksverantwoordelijke. Wie datzelfde systeem onder de eigen naam of het eigen merk doorlevert is geen importeur maar aanbieder. De rol van importeur zit precies daartussen: doorleveren met het merk van de derde partij er nog op.
Zet in uw leveranciersregister per AI-systeem drie gegevens: het land van vestiging van de partij wiens naam of merk het systeem draagt, of uw organisatie het systeem in de Unie voor het eerst op de markt aanbiedt, en onder welke naam dat gebeurt. Die drie velden bepalen samen of u importeur, distributeur of aanbieder bent.
Het eerste moment waarop een systeem of model op de Uniemarkt wordt aangeboden, en daarmee het startschot voor veel verplichtingen.
Artikel 3, punt 9 omschrijft in de handel brengen als het voor het eerst in de Unie op de markt aanbieden van een AI-systeem of een AI-model voor algemene doeleinden. Punt 10 vult aan dat op de markt aanbieden betekent: het in het kader van een handelsactiviteit, al dan niet tegen betaling, verstrekken van een AI-systeem of een AI-model voor algemene doeleinden met het oog op distributie of gebruik op de markt van de Unie.
De hardnekkigste fout is de aanname dat er een verkoop of een prijs aan te pas moet komen. Punt 10 zegt uitdrukkelijk al dan niet tegen betaling. Een gratis proefversie, een open beschikbaar model of een kosteloze pilot bij een klant kan in de handel brengen zijn. De tweede fout is het verwarren van dit begrip met in gebruik stellen. In de handel brengen ziet op de markt; een systeem dat u uitsluitend intern bouwt en intern inzet brengt u niet in de handel, maar stelt u wel in gebruik, en ook dat is een zelfstandig aanknopingspunt.
Leg per systeem en per model de datum van eerste beschikbaarstelling in de Unie vast, met de vorm ervan: verkoop, gratis proef, open beschikbaarstelling of pilot. Die datum bepaalt welk regime en welke overgangstermijn van toepassing zijn, en is het eerste dat een toezichthouder naast uw dossier legt.
Het begrip waardoor ook intern gebouwde systemen die nooit verkocht worden binnen de verordening vallen.
Artikel 3, punt 11 omschrijft in gebruik stellen als de directe levering van een AI-systeem aan de gebruiksverantwoordelijke voor het eerste gebruik of voor eigen gebruik in de Unie voor het beoogde doel.
Hier zit de val voor organisaties die zelf bouwen. De redenering luidt: wij verkopen niets, dus wij brengen niets in de handel, dus de aanbiedersverplichtingen gelden niet. De woorden of voor eigen gebruik sluiten die route af. Zodra u een zelfgebouwd systeem in de Unie voor het beoogde doel in gebruik neemt, heeft u het in gebruik gesteld, en bent u op grond van punt 3 aanbieder naast gebruiksverantwoordelijke. Let ook op voor het eerste gebruik: een systeem dat nog in een testomgeving draait en niet voor zijn beoogde doel wordt ingezet, is nog niet in gebruik gesteld.
Registreer voor elk intern ontwikkeld AI-systeem de datum waarop het voor het beoogde doel in productie ging, en noteer daarbij expliciet dat uw organisatie zowel aanbieder als gebruiksverantwoordelijke is. Koppel aan die datum de start van uw dossieropbouw, en beoordeel meteen of het systeem hoog risico is, want dan gelden de technische documentatie van artikel 11 en de logging van artikel 12 vanaf dat moment en hoeft het dossier niet achteraf te worden gereconstrueerd.
De data die het systeem binnenkomen of die het zelf verwerft en waarop het zijn output baseert. Dit is de datadefinitie die de gebruiksverantwoordelijke raakt, niet alleen de aanbieder.
Artikel 3(33) definieert inputdata als data die in een AI-systeem worden ingevoerd of direct door een AI-systeem worden verworven en op basis waarvan het systeem een output genereert.
Dit is het punt waar de verantwoordelijkheid verschuift naar uw kant van de tafel. Artikel 26, lid 4, verplicht de gebruiksverantwoordelijke om ervoor te zorgen dat de inputdata relevant en voldoende representatief zijn voor het beoogde doel, voor zover hij daarover controle heeft. De hardnekkigste misvatting is dat datakwaliteit een probleem van de leverancier is. Prompts, geuploade cv's, sensormetingen, klantdossiers en gekoppelde bronsystemen zijn allemaal inputdata, en een uitstekend gebouwd systeem levert onbruikbare uitkomsten wanneer u het voedt met verouderde of scheve gegevens. Let ook op de tweede helft van de definitie: data die het systeem zelf verwerft, bijvoorbeeld via een camera of een API, zijn eveneens inputdata en vallen dus binnen uw zorgplicht.
Leg per AI-systeem vast welke inputdata worden gebruikt, uit welke bronsystemen zij komen, wie eigenaar is van de kwaliteit en de representativiteit, hoe vaak die wordt gecontroleerd, en hoe lang de input in de logs bewaard blijft. Benoem expliciet welke inputbronnen u niet in de hand hebt, want dat markeert de grens van uw zorgplicht.
Kritieke infrastructuur zoals gedefinieerd in artikel 2, punt 4, van Richtlijn (EU) 2022/2557, de CER-richtlijn. De AI-verordening geeft hier geen eigen omschrijving maar sluit aan bij dat kader.
Artikel 3, punt 62 bepaalt dat onder kritieke infrastructuur wordt verstaan kritieke infrastructuur zoals gedefinieerd in artikel 2, punt 4, van Richtlijn (EU) 2022/2557.
Deze verwijzing lijkt een formaliteit maar heeft directe gevolgen voor de risicoklasse. Bijlage III, punt 2, merkt AI-systemen aan als hoog risico wanneer zij bedoeld zijn als veiligheidscomponent bij het beheer en de exploitatie van kritieke digitale infrastructuur, wegverkeer of de levering van water, gas, verwarming of elektriciteit. Wie wil weten of hij daaronder valt, moet dus de CER-richtlijn en de nationale aanwijzing van kritieke entiteiten raadplegen en niet zelf een definitie bedenken. Nederlandse organisaties vergissen zich hier omdat de aanwijzing per lidstaat verschilt.
Leg vast of uw organisatie of uw afnemer is aangewezen als kritieke entiteit onder de nationale omzetting van Richtlijn (EU) 2022/2557, en koppel die vaststelling aan uw risicoclassificatie onder Bijlage III, punt 2, met datum en bron.
De nationale toezichthouder die de AI Act handhaaft op de markt, met de bevoegdheden uit de algemene markttoezichtverordening. Dit is de partij die bij u aanklopt en documentatie opvraagt.
Artikel 3(26) definieert de markttoezichtautoriteit als de nationale autoriteit die de activiteiten verricht en de maatregelen neemt als bedoeld in Verordening (EU) 2019/1020.
De verwarring zit in het onderscheid met twee andere spelers. De aanmeldende autoriteit wijst aangemelde instanties aan en doet niets aan handhaving richting u; het AI-bureau van de Commissie houdt toezicht op AI-modellen voor algemene doeleinden onder artikel 53, dat sinds 2 augustus 2025 geldt en sinds 2 augustus 2026 handhaafbaar is. De markttoezichtautoriteit is uw feitelijke handhavingscontactpunt voor AI-systemen: zij kan technische documentatie en logs opvragen, toegang tot de trainings- en testdatasets eisen, en een systeem beperken, uit de handel laten nemen of laten terugroepen. De verwijzing naar Verordening (EU) 2019/1020 is geen formaliteit, want daarmee erft de toezichthouder een fors bevoegdhedenpakket dat niet opnieuw in de AI Act hoefde te worden opgeschreven.
Leg per AI-systeem vast welke markttoezichtautoriteit bevoegd is (dat verschilt per sector en per lidstaat waar u aanbiedt), wie binnen uw organisatie het aanspreekpunt is, en binnen hoeveel werkdagen u de technische documentatie, de logs en de datasetbeschrijvingen kunt aanleveren. Test die levertijd een keer droog, want de termijn die de toezichthouder stelt is kort.
Een verzamelnaam voor twee heel verschillende rollen: de aanmeldende autoriteit en de markttoezichtautoriteit. Voor EU-instellingen treedt de Europese Toezichthouder voor gegevensbescherming in hun plaats.
Artikel 3, punt 48 definieert een nationale bevoegde autoriteit als een aanmeldende autoriteit of een markttoezichtautoriteit. Wat betreft AI-systemen die door instellingen, organen en instanties van de Unie in gebruik worden gesteld of worden gebruikt, worden verwijzingen naar nationale bevoegde autoriteiten of markttoezichtautoriteiten begrepen als verwijzingen naar de Europese Toezichthouder voor gegevensbescherming.
De definitie bundelt twee rollen die u niet moet verwarren. De aanmeldende autoriteit wijst conformiteitsbeoordelingsinstanties aan en houdt daar toezicht op; met die autoriteit heeft u als gebruikende organisatie zelden te maken. De markttoezichtautoriteit controleert u, vraagt documentatie op, ontvangt meldingen van ernstige incidenten en legt maatregelen op. Lidstaten moesten deze autoriteiten uiterlijk 2 augustus 2025 aanwijzen en bekendmaken. Dat die aanwijzing in sommige lidstaten nog niet volledig is afgerond, verandert niets aan uw verplichtingen: de plichten rusten op u, niet op de toezichthouder.
Houd per markt waar u actief bent bij welke markttoezichtautoriteit voor uw sector bevoegd is, wie binnen uw organisatie het contact voert en wie bevoegd is meldingen te doen. Vermeld dat contactpunt in uw technische documentatie.
Alles wat geen persoonsgegeven is. De categorie bestaat om duidelijk te maken dat de AI Act ook geldt wanneer er geen persoonsgegevens in het spel zijn.
Artikel 3, punt 51 definieert niet-persoonsgebonden gegevens als andere gegevens dan persoonsgegevens zoals gedefinieerd in artikel 4, punt 1, van Verordening (EU) 2016/679.
Deze restcategorie is het bewijs dat de AI Act geen privacywet is. De eisen aan data en datagovernance in artikel 10, de technische documentatie in artikel 11 en de logging in artikel 12 gelden ook wanneer u uitsluitend met machinedata, sensordata of synthetische data werkt. "Er zitten geen persoonsgegevens in" is dus hooguit een argument onder de AVG en nooit een vrijstelling onder de AI Act. In de praktijk gebruiken technische teams dit argument om documentatieverplichtingen te ontlopen bij industriële en infrastructurele toepassingen, precies de toepassingen die onder bijlage I en bijlage III kunnen vallen.
Noteer per dataset of die persoonsgegevens bevat, maar laat die uitkomst nooit bepalen of u de AI Act-documentatie opstelt. Beoordeel documentatieplichten op de risicoclassificatie van het systeem, niet op de aard van de data.
Elke fysieke plek, publiek of privaat eigendom, die toegankelijk is voor een onbepaald aantal mensen. Toegangsvoorwaarden en capaciteitsgrenzen doen er niet toe.
Artikel 3, punt 44 definieert openbare ruimte als een fysieke plek die in publieke of private handen is en toegankelijk is voor een onbepaald aantal natuurlijke personen, ongeacht of bepaalde voorwaarden voor de toegang van toepassing zijn en ongeacht eventuele capaciteitsbeperkingen.
Het veelgehoorde argument "het is ons eigen terrein, dus geen openbare ruimte" houdt geen stand. Winkels, stations, luchthavens, stadions, bioscopen, ziekenhuiswachtkamers en winkelcentra zijn openbare ruimte, ook als er kaartcontrole, huisregels of een maximale bezetting geldt. Bepalend is of de kring van bezoekers onbepaald is. Een kantoorvloer die alleen voor eigen personeel toegankelijk is valt er doorgaans buiten, want die kring is bepaald. Dit begrip schakelt het verbod op real-time identificatie op afstand in artikel 5 aan of uit, en werkt door in de classificatie van bijlage III.
Markeer in uw camera- en biometrieregister per locatie of het een openbare ruimte in de zin van punt 44 betreft, met een korte motivering. Doe dat voordat u een systeem aanschaft, niet erna.
De verzamelterm voor alle zes de rollen in de keten, en niet de persoon die de knoppen bedient.
Artikel 3, punt 8 omschrijft een operator als een aanbieder, productfabrikant, gebruiksverantwoordelijke, gemachtigde, importeur of distributeur.
Operator wordt gelezen als degene die het systeem dagelijks bedient. Dat is precies wat het niet betekent. Het is een verzamelbegrip: waar een bepaling operatoren aanspreekt, spreekt zij alle zes de genoemde rollen tegelijk aan. Wie in een gap-analyse de verplichtingen voor operatoren overslaat omdat hij denkt alleen gebruiksverantwoordelijke te zijn, mist bepalingen die wel degelijk op hem zien. Merk daarnaast op dat productfabrikant in deze opsomming wel als rol wordt genoemd maar in artikel 3 niet apart wordt gedefinieerd.
Maak in uw compliance-overzicht een kolom operator die de zes rollen expliciet uitschrijft, zodat bij elke bepaling zichtbaar is welke rollen worden geraakt. Registreer per AI-systeem alle rollen die uw organisatie voor dat specifieke systeem vervult, want dat zijn er vaak meer dan een.
De AI Act maakt hier bewust geen eigen begrip van en verwijst naar de AVG. Uw AVG-administratie en uw AI Act-dossier moeten dus over dezelfde gegevens gaan.
Artikel 3, punt 50 definieert persoonsgegevens als persoonsgegevens zoals gedefinieerd in artikel 4, punt 1, van Verordening (EU) 2016/679.
De verwijzing lijkt saai maar heeft een praktisch gevolg: er is geen ruimte voor een eigen AI Act-interpretatie van wat een persoonsgegeven is. Waar de AI Act extra ruimte biedt, zoals artikel 10, lid 5 dat het verwerken van bijzondere categorieën toestaat om vertekening in hoogrisicosystemen op te sporen en te corrigeren, gelden de AVG-waarborgen onverkort en gelden aanvullende voorwaarden. Organisaties die AI-governance en privacy in gescheiden dossiers beheren, lopen tegen tegenstrijdige beschrijvingen van dezelfde verwerking aan, precies op het moment dat een toezichthouder beide opvraagt.
Koppel elk AI-systeem in uw AI-register aan de bijbehorende verwerking in uw AVG-verwerkingsregister, met één gedeeld identificatienummer, zodat één wijziging beide dossiers bijwerkt.
Plan voor testen onder reële omstandigheden
Het document waarin u vooraf vastlegt hoe u een AI-systeem buiten het lab gaat testen: doel, methode, reikwijdte, wie eraan meedoet, hoe lang en hoe u het bewaakt. Zonder dit plan is testen onder reële omstandigheden niet toegestaan.
Artikel 3, punt 53 omschrijft een plan voor testen onder reële omstandigheden als een document waarin de doelstellingen, methode, geografische reikwijdte, betrokken personen, duur, monitoring, organisatie en wijze van uitvoering van een test onder reële omstandigheden worden omschreven.
Hier gaat het in de praktijk mis doordat organisaties een pilot met echte gebruikers een pilot blijven noemen en denken dat er dan niets geldt. Zodra u een AI-systeem met echte mensen in een echte omgeving beproeft, valt u onder het regime van artikel 57 of 60 en hoort daar een vooraf opgesteld en toetsbaar plan bij. Een testplan dat achteraf wordt geschreven om een dossier te vullen, voldoet niet aan de omschrijving, want de kern van het begrip is dat de opzet vooraf vastligt.
Leg per test onder reële omstandigheden één document vast met de acht elementen uit de definitie: doelstelling, methode, geografische reikwijdte, de groep betrokken personen, de duur, de monitoring, de organisatie en de wijze van uitvoering. Koppel dat document aan de registratie van de test en bewaar het met de datum van goedkeuring.
Het vermogen van een AI-systeem om het beoogde doel te verwezenlijken. Prestaties worden dus gemeten tegen het beoogde doel, niet tegen een losse technische score.
Artikel 3, punt 18, definieert de prestaties van een AI-systeem als het vermogen van een AI-systeem om het beoogde doel te verwezenlijken.
De definitie koppelt prestaties hard aan het beoogde doel uit punt 12. Daarmee is een nauwkeurigheid van 94 procent geen antwoord op de vraag of het systeem presteert, zolang niet vaststaat waarvoor het bedoeld is en voor welke groep mensen die score geldt. Een model dat gemiddeld goed scoort maar structureel slechter presteert voor een deelgroep, verwezenlijkt het beoogde doel voor die groep niet. Dat is precies waar artikel 15 over nauwkeurigheid en robuustheid en artikel 10 over datakwaliteit op aangrijpen.
Leg per AI-systeem vast welke prestatiemaatstaven u hanteert, welke drempelwaarde acceptabel is voor het beoogde doel, en hoe die maatstaven uitpakken per relevante deelgroep. Herhaal de meting periodiek en bewaar de uitkomsten, zodat u afname in prestaties kunt aantonen voordat een toezichthouder ernaar vraagt.
In het kader van tests onder reële omstandigheden is een proefpersoon een natuurlijk persoon die aan zo'n test deelneemt. De term komt uit het testregime en niet uit het gegevensbeschermingsrecht.
Artikel 3, punt 58 omschrijft proefpersoon, in het kader van tests onder reële omstandigheden, als een natuurlijk persoon die deelneemt aan een test onder reële omstandigheden.
De definitie lijkt triviaal maar bepaalt wie er beschermd wordt. Wie proefpersoon is, heeft recht op geïnformeerde toestemming volgens punt 59 en op de waarborgen van artikel 57 en 60. Het misverstand zit in de aanname dat alleen externe testdeelnemers proefpersoon zijn. Ook medewerkers die tijdens hun werk met een testsysteem werken, kunnen proefpersoon zijn, en juist bij hen is vrijwilligheid van de toestemming een gevoelig punt vanwege de gezagsverhouding.
Houd per test een lijst bij van de proefpersonen of van de duidelijk afgebakende groep waaruit zij komen, met de datum van hun toestemming en de wijze waarop zij zijn geïnformeerd. Beoordeel apart of medewerkers als proefpersoon deelnemen en hoe u de vrijwilligheid borgt.
Overgenomen uit de AVG, maar in de AI Act de beslissende factor: een systeem uit bijlage III dat profileert blijft altijd hoog risico.
Artikel 3, punt 52 definieert profilering als profilering zoals gedefinieerd in artikel 4, punt 4, van Verordening (EU) 2016/679.
Dit is de belangrijkste van de drie AVG-verwijzingen. Artikel 6, lid 3 biedt een uitzondering waarmee een systeem uit bijlage III toch niet als hoog risico geldt, bijvoorbeeld omdat het een enge procedurele taak uitvoert of alleen voorbereidend werk doet. Die uitzondering vervalt volledig zodra het systeem profileert in de zin van de AVG. Dat betekent: geautomatiseerde verwerking om persoonlijke aspecten te evalueren, zoals prestaties, betrouwbaarheid, gedrag, gezondheid of voorkeuren. In de praktijk profileert het merendeel van de werving-, kredietbeoordelings- en fraudedetectietoepassingen, waardoor de uitzondering die veel organisaties inroepen zelden opgaat.
Leg per systeem uit bijlage III expliciet vast of het profileert in de zin van artikel 4, punt 4 AVG, met de motivering en de datum. Bewaar die motivering bij uw beoordeling onder artikel 6, lid 3; het is het eerste stuk dat een toezichthouder opvraagt.
De activiteit, niet de instantie. Werk dat namens een rechtshandhavingsinstantie wordt verricht valt er ook onder, ook als een private partij het uitvoert.
Artikel 3, punt 46 definieert rechtshandhaving als activiteiten die worden verricht door of namens rechtshandhavingsinstanties met het oog op de voorkoming van, het onderzoek naar, de opsporing of de vervolging van strafbare feiten of de uitvoering van straffen, met inbegrip van de bescherming tegen en de voorkoming van gevaren voor de openbare veiligheid.
Het woord "namens" is doorslaggevend. Een leverancier, forensisch analysebureau of ingehuurde dataspecialist die voor de politie werkt, opereert binnen het rechtshandhavingsregime, met de bijbehorende waarborgen en registratieplichten. Omgekeerd geldt: fraudeonderzoek door een verzekeraar, interne integriteitsonderzoeken en particuliere beveiliging zijn geen rechtshandhaving. Die organisaties kunnen de uitzonderingen dus niet gebruiken en vallen gewoon onder het reguliere regime, inclusief het volledige verbod op real-time identificatie op afstand zoals dat voor hen uitwerkt.
Leg per inzet vast of die binnen of buiten rechtshandhaving valt, met vermelding van de opdrachtgever en de opdrachtdocumenten. Neem die kwalificatie op in het contract, zodat leverancier en opdrachtgever hetzelfde regime hanteren.
Niet alleen politie en openbaar ministerie. Ook elk ander orgaan dat naar nationaal recht openbaar gezag uitoefent voor opsporing, vervolging of openbare veiligheid.
Artikel 3, punt 45 omvat (a) iedere overheidsinstantie die bevoegd is voor de voorkoming van, het onderzoek naar, de opsporing en de vervolging van strafbare feiten of de uitvoering van straffen, met inbegrip van de bescherming tegen en de voorkoming van gevaren voor de openbare veiligheid, en (b) ieder ander orgaan of iedere andere entiteit die krachtens het recht van de lidstaten is gemachtigd openbaar gezag en openbare bevoegdheden uit te oefenen met het oog op diezelfde doeleinden.
Onderdeel b trekt de kring veel breder dan mensen verwachten. Buitengewoon opsporingsambtenaren, bijzondere opsporingsdiensten, delen van gemeentelijke handhaving en private partijen met een wettelijke publieke taak kunnen eronder vallen. Dat is geen etiket zonder gevolgen: de status verandert het regime. Rechtshandhavingsinstanties kunnen zich onder strikte voorwaarden beroepen op uitzonderingen in artikel 5, registreren hun hoogrisicogebruik in een niet-openbaar deel van de EU-databank op grond van artikel 49, lid 4, en kennen eigen waarborgen in artikel 26. Wie zich ten onrechte als rechtshandhavingsinstantie beschouwt, bouwt een compliancedossier op een verkeerde grondslag.
Leg per team en per AI-systeem vast op welke wettelijke grondslag u handhaaft en of u daarmee als rechtshandhavingsinstantie geldt. Laat die kwalificatie juridisch toetsen voordat u zich op een uitzondering beroept.
Gebruik buiten het beoogde doel dat de aanbieder had kunnen zien aankomen, en daarom zelf moet meewegen.
Artikel 3, punt 13 omschrijft redelijkerwijs te voorzien misbruik als het gebruik van een AI-systeem op een wijze die niet in overeenstemming is met het beoogde doel, maar die kan voortvloeien uit redelijkerwijs te voorzien menselijk gedrag of redelijkerwijs te voorziene interactie met andere systemen, waaronder andere AI-systemen.
Het woord misbruik doet vermoeden dat het om kwade opzet gaat, of om een fout van de gebruiker. Dat is de verkeerde lezing. Het gaat om gedrag dat gewoon voorspelbaar is: een medewerker die een samenvattingstool ook voor besluitvorming gebruikt, een chatbot die vragen krijgt waarvoor hij niet bedoeld is, een model dat via een koppeling input krijgt van een ander systeem. De tweede fout is de gedachte dat het uitsluiten van een gebruik in de handleiding het risico wegneemt. Niet vermeld staan in de handleiding is niet hetzelfde als niet te voorzien. Let ook op de expliciete vermelding van interactie met andere systemen, waaronder andere AI-systemen: geketende en agentische opstellingen vallen daar rechtstreeks onder.
Houd per systeem een korte lijst bij van voorzienbaar afwijkend gebruik, gevoed door incidenten, helpdeskvragen en signalen van eindgebruikers, en noteer per punt welke maatregel is genomen. Neem de koppelingen met andere systemen expliciet in die lijst op, want daar ontstaat het gebruik dat niemand heeft ontworpen.
Risico is de combinatie van de kans op schade en de ernst van die schade. Het is de rekeneenheid onder de hele verordening, van verboden praktijken tot het risicobeheersysteem van artikel 9.
Artikel 3, punt 2, definieert risico als de combinatie van de kans op schade en de ernst van die schade.
Deze definitie lijkt triviaal maar bepaalt wie gelijk krijgt in een discussie. Veel organisaties beoordelen AI-risico als kans op een technische storing, terwijl de verordening kijkt naar schade aan gezondheid, veiligheid en grondrechten van mensen. Een model dat zelden faalt maar bij falen iemand ten onrechte uitsluit van werk of een uitkering, scoort in AI Act-termen hoog, niet laag. Wie de kans en de ernst niet apart onderbouwt, houdt geen risicobeoordeling over maar een mening.
Leg per AI-toepassing in uw register vast welke schade u voor ogen heeft, voor wie, hoe groot u de kans acht en hoe ernstig het gevolg is, met de bron van die inschatting. Gebruik een vaste schaal voor kans en ernst over alle toepassingen, zodat u scores kunt vergelijken en kunt aantonen dat de indeling niet ad hoc is.
Een verandering van een AI-systeem na het in de handel brengen of in gebruik stellen die de aanbieder niet had voorzien in de initiele conformiteitsbeoordeling, en die de overeenstemming met hoofdstuk III, afdeling 2, raakt of het beoogde doel wijzigt.
Artikel 3, punt 23, definieert een substantiele wijziging als een verandering van een AI-systeem nadat dit in de handel is gebracht of in gebruik is gesteld, die door de aanbieder niet is voorzien of gepland in de initiele conformiteitsbeoordeling en als gevolg waarvan de overeenstemming van het AI-systeem met de voorschriften van hoofdstuk III, afdeling 2, wordt beinvloed, of die leidt tot een wijziging van het beoogde doel waarvoor het AI-systeem is beoordeeld.
Dit is de definitie die bepaalt wanneer u opnieuw moet beoordelen, en zij bevat een ontsnapping die vaak wordt gemist: veranderingen die de aanbieder vooraf heeft voorzien en gepland in de conformiteitsbeoordeling, zijn geen substantiele wijziging. Een systeem dat blijft leren binnen vooraf vastgelegde grenzen valt daar dus in beginsel niet onder, een model dat u laat hertrainen op een nieuwe populatie of dat u voor een ander doel gaat gebruiken wel. Let ook op de koppeling met artikel 25: verandert u het beoogde doel, dan kunt u als gebruiksverantwoordelijke zelf aanbieder worden. De juridische term is substantiele wijziging, niet wezenlijke wijziging.
Voer per AI-systeem een wijzigingslogboek met datum, aard van de wijziging, de reden en de beoordeling of het een substantiele wijziging betreft, met wie dat heeft vastgesteld. Leg vooraf met uw aanbieder vast welke wijzigingen al in de conformiteitsbeoordeling zijn voorzien, zodat u achteraf niet hoeft te discussieren over de vraag of hernieuwde beoordeling nodig was.
Systeem voor biometrische categorisering
Een AI-systeem dat mensen op basis van biometrische gegevens in categorieën indeelt. De uitzondering voor functies die een andere commerciële dienst ondersteunen is smal en wordt in de praktijk veel te ruim uitgelegd.
Artikel 3, punt 40 definieert een systeem voor biometrische categorisering als een AI-systeem dat is bedoeld voor het indelen van natuurlijke personen in specifieke categorieën op basis van hun biometrische gegevens, tenzij dit een aanvulling vormt op een andere commerciële dienst en om objectieve technische redenen strikt noodzakelijk is.
Categoriseren is iets anders dan identificeren: u stelt niet vast wie iemand is, u plakt er een label op. Dat maakt het niet onschuldiger. Indelen naar gevoelige kenmerken zoals ras, politieke overtuiging, vakbondslidmaatschap, geloof of seksuele gerichtheid is sinds 2 februari 2025 verboden op grond van artikel 5, en sinds 2 augustus 2026 moet u op grond van artikel 50, lid 3 de betrokkenen informeren wanneer u zo'n systeem op hen toepast. De uitzondering geldt alleen als de categorisering technisch strikt noodzakelijk is voor een andere dienst, bijvoorbeeld een beeldfilter dat gezichtskenmerken moet plaatsen. Dat het u commercieel goed uitkomt is geen technische noodzaak.
Leg per systeem vast welke categorieën het toekent, op welke biometrische kenmerken dat gebeurt en met welk doel. Documenteer bij een beroep op de uitzondering de technische noodzaak in de systeembeschrijving, en neem de informatieplicht uit artikel 50, lid 3 op in uw gebruikersinformatie.
Systeem voor biometrische identificatie op afstand
Een AI-systeem dat mensen identificeert zonder dat zij daar actief aan meewerken, doorgaans op afstand, door vergelijking met een referentiedatabank. Het woord dat alles bepaalt is "actief betrokken".
Artikel 3, punt 41 definieert een systeem voor biometrische identificatie op afstand als een AI-systeem dat is bedoeld voor het identificeren van natuurlijke personen, zonder dat zij daar actief bij betrokken zijn en doorgaans van een afstand, door middel van vergelijking van de biometrische gegevens van een persoon met de biometrische gegevens die zijn opgenomen in een referentiedatabank.
Het scharnierpunt is de actieve betrokkenheid van de persoon. Een medewerker die zijn vinger op een lezer legt of zijn gezicht voor de camera houdt om binnen te komen, werkt actief mee: dat is biometrische verificatie in de zin van punt 36 en geen identificatie op afstand. Een camera die passanten stilzwijgend matcht met een databank valt er wel onder, en die systemen zijn hoe dan ook hoog risico op grond van bijlage III, punt 1, met alle verplichtingen van dien vanaf 2 december 2027. Leveranciers verkopen dit vaak als "slimme toegangscontrole", terwijl de databank en het ontbreken van medewerking de doorslag geven.
Bepaal per camera- of biometriesysteem twee dingen en leg ze schriftelijk vast: hangt er een referentiedatabank aan, en werkt de betrokkene actief mee. Die twee antwoorden bepalen of u in bijlage III belandt en of het verbod uit artikel 5 in beeld komt.
Systeem voor monitoring na het in de handel brengen
Het geheel aan activiteiten waarmee een aanbieder na de lancering blijft volgen hoe zijn AI-systeem zich in de praktijk gedraagt, zodat hij tijdig kan bijsturen. Conformiteit is een startpunt, geen eindpunt.
Artikel 3(25) definieert dit als alle door aanbieders van AI-systemen verrichte activiteiten voor het verzamelen en evalueren van ervaringen met door hen in de handel gebrachte of in gebruik gestelde AI-systemen, teneinde te kunnen vaststellen of er onmiddellijk corrigerende dan wel preventieve maatregelen nodig zijn.
Hier gaat het bijna altijd mis op hetzelfde punt: organisaties behandelen de conformiteitsbeoordeling als eindstreep en organiseren daarna niets meer. De definitie legt juist een doorlopende verplichting vast die de hele levensduur van het systeem beslaat en die in artikel 72 wordt uitgewerkt in een verplicht monitoringplan. Het gaat niet om passief afwachten tot iemand klaagt, maar om actief verzamelen en evalueren. Voor high-risk systemen wordt dit scherp vanaf 2 december 2027 (Bijlage III) en 2 augustus 2028 (Bijlage I), maar het monitoringsysteem moet al in het ontwerp meelopen, omdat u anders geen historische gegevens hebt om drift of degradatie mee aan te tonen.
Leg per AI-systeem vast welke signalen u verzamelt (klachten, supporttickets, afwijkende uitkomsten, prestatiemetingen over de tijd), wie ze beoordeelt, met welke frequentie, en welke drempel een corrigerende maatregel of een melding van een ernstig incident in gang zet. Bewaar de evaluatieverslagen met datum en modelversie, zodat u later kunt laten zien dat u het niet pas na een incident bent gaan meten.
Een begrip dat uitsluitend op GPAI-modellen ziet, en dat losstaat van de hoogrisicoclassificatie van AI-systemen.
Artikel 3, punt 65 omschrijft systeemrisico als een risico dat specifiek is voor de capaciteiten met een grote impact van AI-modellen voor algemene doeleinden, die aanzienlijke gevolgen hebben voor de markt van de Unie vanwege hun bereik, of vanwege feitelijke of redelijkerwijs te voorziene negatieve gevolgen voor de gezondheid, de veiligheid, de openbare veiligheid, de grondrechten of de samenleving als geheel, en dat op grote schaal in de hele waardeketen kan worden verspreid. Punt 64 omschrijft capaciteiten met een grote impact als capaciteiten die overeenkomen met of groter zijn dan de capaciteiten die worden opgetekend bij de meest geavanceerde AI-modellen voor algemene doeleinden. Artikel 51, lid 2 bepaalt dat een model wordt geacht dergelijke capaciteiten te hebben wanneer de cumulatieve hoeveelheid berekeningen voor de training, gemeten in zwevendekommabewerkingen, groter is dan 10 tot de macht 25.
Artikel 3, punten 64 en 65, en artikel 51, leden 1 en 2
Systeemrisico wordt in gesprekken vaak gebruikt als synoniem voor hoog risico, en soms vanuit de financiele sector als synoniem voor systeemrelevantie. Beide zijn onjuist. Systeemrisico is in deze verordening uitsluitend een kwalificatie van een AI-model voor algemene doeleinden, nooit van een AI-systeem en nooit van een organisatie. Een tweede misvatting is dat de drempel van 10 tot de macht 25 zwevendekommabewerkingen de definitie is. Dat is zij niet: die drempel staat in artikel 51, lid 2 en werkt als vermoeden, terwijl de Commissie op grond van artikel 51, lid 1, punt b) een model ook ambtshalve of na een gekwalificeerde waarschuwing van het wetenschappelijk panel kan classificeren wanneer het vergelijkbare capaciteiten of een vergelijkbare impact heeft, met inachtneming van de criteria in bijlage XIII. Voor vrijwel elke organisatie geldt dat dit begrip haar leverancier raakt en niet haarzelf; de relevante vraag is dan welk model u gebruikt en wat de aanbieder daarover documenteert.
Noteer per AI-toepassing welk onderliggend GPAI-model wordt gebruikt en of de aanbieder dat model aanmerkt als model met systeemrisico, en bewaar de documentatie of modelkaart waarop u dat baseert. Gebruik die informatie in leveranciersgesprekken en niet als eigen classificatie, want de kwalificatie hoort thuis bij de aanbieder van het model.
Een maatregel gericht op het retourneren aan de aanbieder, het buiten gebruik stellen of het onbruikbaar maken van een AI-systeem dat al aan gebruiksverantwoordelijken ter beschikking is gesteld. Terugroepen raakt systemen die al in gebruik zijn.
Artikel 3, punt 16, definieert het terugroepen van een AI-systeem als een maatregel gericht op het retourneren aan de aanbieder, het buiten gebruik stellen of het onbruikbaar maken van een AI-systeem dat aan gebruiksverantwoordelijken ter beschikking is gesteld.
Het verschil met uit de handel nemen is het punt in de keten. Terugroepen grijpt in bij de afnemer die het systeem al draait, uit de handel nemen stopt alleen wat nog niet is uitgeleverd. Bij software is terugroepen zelden fysiek: het is een uitgeschakelde functie, een ingetrokken licentiesleutel of een geblokkeerde API. Organisaties onderschatten dat een aanbieder onder artikel 20 verplicht kan zijn een systeem terug te roepen dat u operationeel nodig heeft, en dat u dus vandaag al moet weten wat u doet als een kernsysteem morgen wordt uitgezet.
Leg per AI-systeem vast wie bij de aanbieder een terugroepactie kan aankondigen, via welk kanaal u dat bericht ontvangt en welke terugvaloptie u heeft als het systeem per direct onbruikbaar wordt. Neem deze afspraken op in het contract en test minimaal jaarlijks of het meldkanaal werkt.
Data voor een onafhankelijke evaluatie die de verwachte prestaties bevestigt, en die vooraf moet plaatsvinden: voordat het systeem in de handel wordt gebracht of in gebruik wordt gesteld.
Artikel 3(32) definieert testdata als data die worden gebruikt voor het verrichten van een onafhankelijke evaluatie van het AI-systeem om de verwachte prestaties van dat systeem te bevestigen voordat het in de handel wordt gebracht of in gebruik wordt gesteld.
Twee woorden dragen deze definitie: onafhankelijk en voordat. Onafhankelijk betekent dat de testdata niet mogen zijn gebruikt bij het trainen of het afstemmen; zodra u op basis van de testresultaten teruggaat en het model bijstelt, is uw testset besmet en moet u een nieuwe set aanleggen. Voordat betekent dat de bevestiging vooraf plaatsvindt, niet als reconstructie achteraf omdat een toezichthouder ernaar vraagt. In de praktijk gaat het vooral mis bij systemen die doorlopend worden bijgewerkt: elke substantiële wijziging vraagt om een nieuwe onafhankelijke bevestiging, niet om een verwijzing naar de meting van vorig jaar. Voor high-risk systemen wordt dit hard vanaf 2 december 2027 (Bijlage III) en 2 augustus 2028 (Bijlage I).
Houd de testset afgeschermd en gescheiden van het ontwikkelteam, en leg de meetresultaten vast per relevante subgroep, met datum, modelversie en de gebruikte metriek. Koppel elke substantiële wijziging aan een nieuwe testronde en noteer wie de evaluatie heeft uitgevoerd.
Het tijdelijk testen van een AI-systeem voor zijn beoogde doel buiten het lab, om betrouwbare gegevens te verzamelen en de conformiteit te beoordelen. Het geldt niet als in de handel brengen of in gebruik stellen, mits u aan alle voorwaarden van artikel 57 of 60 voldoet.
Artikel 3, punt 57 omschrijft testen onder reële omstandigheden als het tijdelijk testen van een AI-systeem voor zijn beoogde doel onder reële omstandigheden buiten een laboratorium of anderszins gesimuleerde omgeving teneinde betrouwbare en robuuste gegevens te verkrijgen en te beoordelen en te verifiëren of het AI-systeem overeenstemt met de voorschriften van deze verordening; het wordt niet aangemerkt als het in de handel brengen of in gebruik stellen van het AI-systeem in de zin van deze verordening, mits aan alle in artikel 57 of artikel 60 vastgestelde voorwaarden is voldaan.
De uitzondering staat of valt met het woord mits. Voldoet u niet aan alle voorwaarden van artikel 57 of 60, dan is uw test geen test meer maar een in gebruik stellen, met alle verplichtingen die daarbij horen en met een handhavingsrisico dat u niet had zien aankomen. In de praktijk ziet u dit bij pilots die stilletjes doorlopen, bij tests die worden uitgebreid naar meer gebruikers of vestigingen, en bij systemen die na de pilotperiode gewoon in productie blijven draaien. Tijdelijk betekent tijdelijk.
Leg per test de begin- en einddatum vast, het beoogde doel dat wordt getest, de rechtsgrond in artikel 57 of 60, en een expliciet besluitmoment aan het einde: stoppen, verlengen onder dezelfde voorwaarden, of overgaan naar in gebruik stellen met de volledige verplichtingen.
De afspraak tussen u en de toezichthouder over wat u in een AI-testomgeving voor regelgeving gaat doen: doelen, voorwaarden, tijdschema, methode en eisen. Het is een tweezijdig document, geen intern plan.
Artikel 3, punt 54 omschrijft een testomgevingsplan als een tussen de deelnemende aanbieder en de bevoegde autoriteit overeengekomen document waarin de doelstellingen, de voorwaarden, het tijdschema, de methode en de vereisten voor de in de testomgeving uitgevoerde activiteiten worden beschreven.
Het onderscheid met punt 53 wordt vaak gemist. Het plan voor testen onder reële omstandigheden is uw eigen testopzet, het testomgevingsplan is een overeengekomen document met de bevoegde autoriteit. Dat betekent dat u het niet eenzijdig kunt wijzigen en dat afwijken van de afgesproken voorwaarden uw deelname aan de testomgeving raakt. Het is bovendien het document waarmee u later kunt aantonen dat de toezichthouder wist wat u deed.
Bewaar het ondertekende of schriftelijk bevestigde testomgevingsplan met versiebeheer en leg elke wijziging vast met de instemming van de bevoegde autoriteit. Neem in uw dossier op welke activiteiten binnen de afgesproken reikwijdte vielen en welke daarbuiten zijn gebleven.
Data die worden gebruikt om de leerbare parameters van een AI-systeem aan te passen. Smal gedefinieerd, en precies daarom bepalend voor wie welke datagovernanceplicht draagt.
Artikel 3(29) definieert trainingsdata als data die worden gebruikt voor het trainen van een AI-systeem door de leerbare parameters hiervan aan te passen.
De definitie is opzettelijk technisch: het gaat alleen om data die de leerbare parameters daadwerkelijk aanpassen. Data die u in een prompt meegeeft of in een retrieval-index zet zijn geen trainingsdata, en dat verschil bepaalt of artikel 10 over datagovernance op u van toepassing is. Waar het misgaat: organisaties die een bestaand model fine-tunen met eigen data denken dat zij louter gebruiker blijven, terwijl zij de leerbare parameters aanpassen en daarmee al snel aanbieder verder in de AI-waardeketen worden, met eigen documentatieplichten. Voor AI-modellen voor algemene doeleinden speelt daarnaast de publieke samenvatting van de gebruikte trainingsinhoud onder artikel 53, dat geldt sinds 2 augustus 2025 en handhaafbaar is sinds 2 augustus 2026.
Leg per dataset vast wat de herkomst is, op welke grondslag u de data mag gebruiken, over welke periode zij zijn verzameld, welke bewerkingen zijn uitgevoerd en welke bekende beperkingen of scheefheden erin zitten. Houd trainingsdata administratief gescheiden van validatie- en testdata, en registreer expliciet elke keer dat u een extern model fine-tunet.
Een maatregel waarmee wordt beoogd te voorkomen dat een AI-systeem dat zich in de toeleveringsketen bevindt, op de markt wordt aangeboden. Het stopt de distributie, niet het gebruik bij bestaande afnemers.
Artikel 3, punt 17, definieert het uit de handel nemen van een AI-systeem als een maatregel waarmee wordt beoogd te voorkomen dat een AI-systeem dat zich in de toeleveringsketen bevindt, op de markt wordt aangeboden.
Dit is het lichtere broertje van terugroepen en wordt daarmee vaak verward, ook in contracten. Uit de handel nemen raakt alleen exemplaren die nog in de keten zitten bij importeurs en distributeurs. Wie het systeem al gebruikt, merkt er niets van tot er ook wordt teruggeroepen. Voor uw eigen inkoop is de praktische vraag: als een leverancier zijn product uit de handel neemt, krijgt u dan nog updates, patches en ondersteuning, of blijft u achter met een systeem dat commercieel dood is maar operationeel draait.
Neem in inkoopcontracten op dat de aanbieder u informeert zodra hij een AI-systeem uit de handel neemt, ook als u het al gebruikt, en leg vast welke onderhouds- en beveiligingsupdates u daarna nog ontvangt en voor hoelang.
Data waarmee u het getrainde systeem evalueert en afstemt, onder meer de niet-leerbare parameters, om underfitting en overfitting te voorkomen. Bedoeld om te sleutelen, niet om het eindcijfer mee te geven.
Artikel 3(30) definieert validatiedata als data die worden gebruikt voor het verrichten van een evaluatie van het getrainde AI-systeem en voor het afstemmen van onder andere de niet-leerbare parameters en het leerproces ervan, om underfitting of overfitting te voorkomen.
De wetgever heeft validatie en test bewust uit elkaar getrokken, omdat de klassieke fout is dat dezelfde data zowel voor het afstemmen van hyperparameters als voor het rapporteren van de eindprestatie worden gebruikt. Dan meet u uw eigen keuzes terug en overschat u de nauwkeurigheid, terwijl artikel 15 juist vraagt om een reëel niveau van nauwkeurigheid dat in de gebruiksinstructies wordt vermeld. In toezichtgesprekken is dit een van de eerste dingen die opvalt: een indrukwekkend nauwkeurigheidscijfer zonder aparte, ongebruikte testset.
Leg vast welke afstemmingsbeslissingen op validatiedata zijn genomen, hoeveel evaluatierondes er zijn geweest en welke configuratie uiteindelijk is gekozen. Zorg dat de validatiedata nooit worden gebruikt voor het cijfer dat u in de gebruiksinstructies en de technische documentatie noemt.
De vorm waarin validatiedata mogen bestaan: een aparte dataset of een deel van de trainingsdataset, met een vaste of een variabele opdeling. De wet laat de methode vrij, maar niet de uitlegbaarheid.
Artikel 3(31) definieert een validatiedataset als een afzonderlijke dataset of een deel van de trainingsdataset, als vaste of variabele opdeling.
Deze definitie lijkt overbodig maar voorkomt een concrete discussie: mag u kruisvalidatie gebruiken in plaats van een vaste holdout. Het antwoord is ja, want een variabele opdeling is uitdrukkelijk toegestaan. De keerzijde is dat de bewijslast verschuift naar reproduceerbaarheid. Als uw opdeling per run verandert en u legt de splitsingsregel niet vast, kunt u achteraf niet aantonen dat uw gerapporteerde prestaties niet het resultaat zijn van een gelukkige splitsing. Bij datasets met tijdsvolgorde of met sterk vertegenwoordigde subgroepen is een willekeurige opdeling bovendien misleidend, terwijl artikel 10 juist vraagt om representativiteit.
Leg in de technische documentatie vast welke opdeling u gebruikt, of die vast of variabel is, welke splitsingsregel of seed geldt, en waarom die opdeling past bij de aard van de data. Bewaar dit per modelversie, zodat een latere hertest reproduceerbaar is.
Een van de twee ingangen naar de hoogrisico-classificatie van artikel 6, lid 1, en vaak over het hoofd gezien buiten de maakindustrie.
Artikel 3, punt 14 omschrijft een veiligheidscomponent als een component van een product of van een AI-systeem die een veiligheidsfunctie voor dat product of AI-systeem vervult of waarvan het falen of gebrekkig functioneren de gezondheid en veiligheid van personen of eigendom in gevaar brengt.
De definitie bevat twee zelfstandige toetsen die door een of worden verbonden, en de tweede wordt bijna altijd vergeten. Een component hoeft geen aanwijsbare veiligheidsfunctie te hebben: het is al genoeg dat falen of gebrekkig functioneren gezondheid en veiligheid van personen of eigendom in gevaar brengt. Ook eigendom telt dus mee, niet alleen letsel. De tweede misvatting is dat dit begrip alleen speelt bij machines en medische hulpmiddelen. Het is de ingang naar artikel 6, lid 1, en dus naar de hoogrisicoroute via bijlage I, die op 2 augustus 2028 van toepassing wordt voor AI die is ingebed in gereguleerde producten. Veiligheidscomponent zijn is op zichzelf overigens niet genoeg. Artikel 6, lid 1 stelt twee cumulatieve voorwaarden: naast punt a) eist punt b) dat voor het product, of voor het AI-systeem als product, op grond van de in bijlage I opgenomen harmonisatiewetgeving een conformiteitsbeoordeling door een derde partij moet worden uitgevoerd.
Loop per AI-systeem beide toetsen apart langs en leg beide antwoorden vast: vervult het een veiligheidsfunctie, en wat gebeurt er bij falen of gebrekkig functioneren. Betrek daar de productveiligheidsdeskundige of de fabrikant van het product bij, want die beoordeling hoort thuis naast de bestaande conformiteitsbeoordeling van het product en niet in een los AI-spoor.
Een handeling of omissie in strijd met Unierecht dat de belangen van natuurlijke personen beschermt, die de collectieve belangen schaadt van personen in ten minste twee andere lidstaten, of die met gemeenschappelijke kenmerken gelijktijdig door dezelfde operator in ten minste drie lidstaten wordt begaan.
Artikel 3, punt 61 omschrijft een wijdverbreide inbreuk als alle handelingen of omissies die in strijd zijn met het Unierecht ter bescherming van de belangen van natuurlijke personen, waarbij a) schade is veroorzaakt of waarschijnlijk zal worden veroorzaakt aan de collectieve belangen van natuurlijke personen met verblijfplaats in ten minste twee andere lidstaten dan de lidstaat waar i) de handeling of omissie haar oorsprong vond of plaatshad, ii) de betrokken aanbieder of, waar van toepassing, diens gemachtigde zich bevindt of is gevestigd, of iii) de gebruiksverantwoordelijke is gevestigd indien de inbreuk door de gebruiksverantwoordelijke is gepleegd; of b) schade is veroorzaakt, wordt veroorzaakt of waarschijnlijk zal worden veroorzaakt aan de collectieve belangen van natuurlijke personen die gemeenschappelijke kenmerken hebben, waaronder dezelfde onrechtmatige praktijk of een inbreuk op hetzelfde belang, en die zich gelijktijdig voordoen en door dezelfde operator worden begaan in ten minste drie lidstaten.
Dit begrip bepaalt niet wat verboden is maar hoe toezicht wordt georganiseerd. Zodra een tekort in uw AI-systeem in meerdere lidstaten hetzelfde uitpakt, wordt het geen serie losse nationale dossiers maar één gecoördineerd handhavingstraject. Dat is precies het risico van gestandaardiseerde software: één instelling, één model of één fout in de logica raakt overal tegelijk en voldoet daarmee bijna vanzelf aan het criterium gemeenschappelijke kenmerken. Merk op dat de tweede variant expliciet spreekt van dezelfde operator, waardoor ook gebruiksverantwoordelijken in beeld komen en niet alleen aanbieders.
Breng in kaart in welke lidstaten hetzelfde AI-systeem of dezelfde configuratie wordt gebruikt en houd bij welke incidenten en klachten grensoverschrijdend dezelfde oorzaak hebben. Zorg dat een correctie in één land aantoonbaar ook in de andere landen wordt doorgevoerd.
Elke wiskundige bewerking of toewijzing met zwevendekommagetallen. Dit is de rekeneenheid waarmee de verordening de omvang van de training van een AI-model voor algemene doeleinden meet.
Artikel 3, punt 67 omschrijft een zwevendekommabewerking, floating-point operation of FLOP, als elke wiskundige bewerking of toewijzing met zwevendekommagetallen, die een subset vormen van de reële getallen die gewoonlijk op computers worden gerepresenteerd door een geheel getal met een vaste precisie, geschaald door een gehele exponent van een vaste basis.
Een technische definitie met juridische scherpte: FLOP is de maatstaf waarmee wordt bepaald of een AI-model voor algemene doeleinden wordt vermoed capaciteiten met een grote impact te hebben en daarmee een systeemrisico, met de drempel voor de cumulatieve rekenkracht van de training uit artikel 51. Dat maakt van een engineeringgetal een compliancefeit. In de praktijk zit het probleem in de administratie: veel organisaties weten achteraf niet meer hoeveel rekenkracht in de training is gegaan, terwijl juist dat getal bepaalt in welk regime u valt en welke kennisgeving aan de Commissie nodig is.
Registreer voor elk model dat u traint of aanzienlijk verder traint de cumulatieve hoeveelheid rekenkracht in FLOP, de meetmethode en de gebruikte hardware, en bewaar die vastlegging bij de technische documentatie van het model.
Registratiedossier onder Artikel 49 lid 2 voor het als niet-hoog-risico beoordeelde systeem
Het bewijs dat het systeem waarvoor u de Artikel 6 lid 3-uitzondering inroept, is geregistreerd zoals Artikel 49 lid 2 voorschrijft, met het registratienummer gekoppeld aan de onderliggende beoordeling.
U roept voor een Bijlage III-systeem de uitzondering van Artikel 6 lid 3 in.
Gedateerde Artikel 6 lid 3-beoordeling van vóór marktintroductie
De schriftelijke beoordeling met datum, opsteller en onderbouwing, opgesteld voordat het systeem op de markt wordt gebracht of in gebruik wordt genomen, gereed om op verzoek aan de nationale bevoegde autoriteit te verstrekken.
U bent aanbieder en concludeert dat een Bijlage III-systeem via Artikel 6 lid 3 niet hoog-risico is.
Classificatiedossier Artikel 6 en Bijlage III
Herleidbare motivering van bedoeld doel, Bijlage III-categorie, Artikel 6 lid 3-toets en registratiebesluit.
Vastlegging per dataset van herkomst, keuzes, aannames, biasonderzoek en mitigaties.
Actueel gehouden technische documentatie per systeemversie, gereed voor een verzoek van een toezichthouder.
Logbestanden met een bewaartermijn passend bij het doel en ten minste zes maanden voor gebruiksverantwoordelijken (Artikel 19 en 26).
De ontvangen gebruiksinstructies plus de interne vertaling daarvan naar werkinstructies per rol.
Vastlegging van toezichtsmaatregelen, aangewezen personen, hun training en de momenten waarop is ingegrepen.
Gedeclareerde nauwkeurigheidsniveaus, testresultaten, en maatregelen tegen onder meer data poisoning en adversarial aanvallen.
Aanbiedersdossier per hoog-risico AI-systeem
Eén dossier per systeem met de documentatie, de logs, de EU-conformiteitsverklaring en het registratiebewijs, in de versie die gold op het moment van het in de handel brengen.
Aan te leggen per afzonderlijk hoog-risico AI-systeem, niet per productlijn of per leverancier.
Het beschreven kwaliteitssysteem met procedures, rolverdeling en verwijzingen naar de onderliggende dossiers.
Versieerbare registratie van rollen, context, maatregelen, deelname of instructie en evaluatiemomenten.
Registratie van deelname en instructie per persoon, systeem en datum
Interne registratie waaruit blijkt wie welke instructie, werksessie, training of begeleiding heeft gekregen, voor welk systeem, op welke datum en op welke grond, inclusief nieuwe medewerkers, inhuur en externen.
Er zijn maatregelen uitgevoerd op grond van Artikel 4 lid 1.
Rol-systeemmatrix met de vastgestelde geletterdheidsbehoefte
De vastgelegde matrix van rollen tegen AI-systemen, met per combinatie de gebruikscontext, de geraakte personen, het risico en de gekozen maatregel, gedateerd en met een eigenaar per regel.
Er is geen voorgeschreven format en geen verplichte AI-functionaris; de vorm mag passen bij de omvang van de organisatie.
Vastlegging per systeem dat de Artikel 5-toets is uitgevoerd, met de uitkomst en motivering. Ook de conclusie "geen verboden praktijk" is bewijs.
Testrapport per contactmoment: melding zichtbaar, tijdig en toegankelijk
Gedateerde vastlegging per interface en kanaal dat de melding uiterlijk bij de eerste interactie of blootstelling verschijnt, duidelijk en onderscheidbaar is, en de toegankelijkheidscontrole heeft doorstaan, met schermopname, versienummer en testerid.
Voor het systeem geldt een van de plichten uit Artikel 50 lid 1 tot en met 4.
Vastlegging van scenario, actor, gekozen melding of markering, technische implementatie, test en eigenaar.
Leveranciersverklaring over de machineleesbare markering van de output
Schriftelijke opgave van de leverancier welke markering op de output wordt aangebracht, in welk machineleesbaar formaat, hoe robuust en interoperabel de oplossing is, en of de markering behouden blijft na bewerking of export.
Het systeem genereert synthetische audio-, beeld-, video- of tekstinhoud.
De plicht geldt niet voor zover het AI-systeem een assisterende functie voor standaardbewerking vervult of de door de gebruiksverantwoordelijke verstrekte inputdata of de betekenis daarvan niet wezenlijk wijzigt, of wanneer het gebruik bij wet is toegestaan om strafbare feiten te detecteren, te voorkomen, te onderzoeken of te vervolgen. Volgens de gewijzigde toepassingskalender in Verordening (EU) 2026/1744 geldt voor systemen die vóór 2 augustus 2026 op de markt waren een overgangstermijn tot 2 december 2026 voor deze machineleesbare markering.
Evaluatieresultaten, risicobeoordelingen, mitigaties, incidentmeldingen en beveiligingsmaatregelen per modelversie.
Schriftelijk bewijs van deelname en het eindverslag
Op verzoek verstrekt de bevoegde autoriteit een schriftelijk bewijs van de met succes uitgevoerde activiteiten, plus een eindverslag met resultaten en leerresultaten. U kunt die documentatie inzetten bij de conformiteitsbeoordeling en bij markttoezicht.
Van toepassing wanneer u als aanbieder of potentiele aanbieder deelneemt aan of uitschrijft uit een AI-testomgeving voor regelgeving. Het schriftelijk bewijs krijgt u uitsluitend op verzoek; het eindverslag verstrekt de autoriteit uit zichzelf. Neemt u als gebruiksverantwoordelijke deel als partner op grond van artikel 58 lid 2, punt b), dan blijft het schriftelijk bewijs een recht van de aanbieder of potentiele aanbieder; leg contractueel vast dat u een afschrift ontvangt.
Openbaarmaking van het eindverslag via het centrale informatieplatform gebeurt alleen als u en de nationale bevoegde autoriteit daar allebei uitdrukkelijk mee instemmen. Ook toegang van de Commissie en de AI-board vereist uw instemming en blijft onderworpen aan de vertrouwelijkheidsbepalingen van artikel 78.
Gedateerde en gedocumenteerde geinformeerde toestemming van proefpersonen
Voor elke proefpersoon legt u vrijwillig gegeven geinformeerde toestemming vast, met vijf voorgeschreven informatie-elementen, gedateerd, gedocumenteerd en met een kopie voor de proefpersoon.
Van toepassing op iedere natuurlijke persoon die proefpersoon is bij testen onder reele omstandigheden op grond van artikel 60, voorafgaand aan diens deelname.
Artikel 60 lid 4, punt i), kent een uitzondering voor rechtshandhaving: indien het vragen om geinformeerde toestemming het testen van het AI-systeem onmogelijk zou maken, mag zonder toestemming worden getest, mits de test zelf en het resultaat geen negatieve gevolgen voor de proefpersonen hebben en hun persoonsgegevens na de uitvoering van de test worden gewist. Buiten die specifieke context bestaat geen uitzondering op de toestemming.
Het plan als onderdeel van de technische documentatie plus de periodieke analyses en opvolgacties.
Vastlegging van incidenten, analyses, meldingen aan toezichthouders en corrigerende maatregelen.
Versieerbare vastlegging van risicoanalyses, gekozen maatregelen, restrisico’s en testresultaten per systeemversie.
De beoordeling, EU-conformiteitsverklaring, CE-markering en het registratiebewijs, per systeemversie.
Gebruiksdossier: logs, informatie aan werknemers en informatie aan betrokken personen
Het dossier waarmee u laat zien dat u de logs bewaart, dat u werknemers en hun vertegenwoordigers tijdig hebt geïnformeerd en dat de personen over wie beslissingen worden genomen dat weten.
Aan te leggen per hoog-risico AI-systeem. De logbewaring geldt alleen voor zover de logs onder uw controle vallen; de informatie uit lid 7 geldt alleen als u werkgever bent en het systeem op de werkplek wordt ingezet.
Log van controles en corrigerende maatregelen van de distributeur
Een doorlopende registratie van wat u hebt gecontroleerd, wanneer, met welke uitkomst en welke maatregel daarop volgde, omdat de toezichthouder naar uw handelen vraagt en niet naar het systeem.
Bij te houden per aangeboden systeem en per klant, gedurende de periode dat het systeem via u op de markt is en zolang u corrigerende maatregelen kunt moeten treffen.
Per verzoek: wie het deed, over welk besluit, welk systeem en welke versie eraan bijdroeg, welke uitleg is gegeven en wanneer. Dit is ook het dossier waarmee u laat zien dat u het recht niet stilzwijgend hebt genegeerd.
Kennisgeving aan de markttoezichtautoriteit met het ingevulde sjabloon
Het verzonden bericht waarmee u de resultaten van de beoordeling aan de markttoezichtautoriteit meldt, met het ingevulde sjabloon als bijlage, plus verzenddatum en ontvangstbevestiging.
De beoordeling op grond van Artikel 27 lid 1 is uitgevoerd.
In het in Artikel 46 lid 1 bedoelde geval kunnen gebruiksverantwoordelijken van de kennisgevingsplicht zijn vrijgesteld; de beoordeling zelf vervalt daarmee niet.
Kruisverwijzing waarin de FRIA de DPIA aanvult in plaats van herhaalt
Een overzicht dat per element van Artikel 27 lid 1 aangeeft of het al in de gegevensbeschermingseffectbeoordeling is behandeld en waar, zodat zichtbaar is welke elementen uitsluitend in de FRIA staan.
Voor dezelfde inzet is een gegevensbeschermingseffectbeoordeling uitgevoerd of vereist.
Gedateerde effectbeoordeling, maatregelen, resterende risico’s en waar vereist de melding aan de markttoezichtautoriteit.
Actuele technische documentatie, downstream-informatie, auteursrechtenbeleid en publieke trainingssamenvatting.
Versieregister van het model met per versie de gewijzigde Bijlage XI- en XII-elementen
Een register met een regel per modelversie: releasedatum, distributiemethode, architectuur en parameteraantal, gebruikte rekenkracht, en de vermelding welke elementen van Bijlage XI en Bijlage XII ten opzichte van de vorige versie zijn gewijzigd.
U brengt meer dan een versie van hetzelfde GPAI-model op de Uniemarkt of stelt die beschikbaar.
Publieke samenvatting van de trainingsinhoud volgens het sjabloon van het AI Office
De gepubliceerde, voldoende gedetailleerde samenvatting van de inhoud die is gebruikt voor het trainen van het model, opgesteld volgens het door het AI Office verstrekte sjabloon, met publicatiedatum en bijbehorende modelversie.
De opensource-vrijstelling van Artikel 53 lid 2 ziet uitsluitend op de punten a en b van lid 1 en laat de publieke trainingssamenvatting dus in stand.
Uw eigen archief van het certificaat van de aangemelde instantie, de gebruiksaanwijzing en de EU-conformiteitsverklaring, tien jaar lang beschikbaar en in een taal die de autoriteit gemakkelijk begrijpt.
De termijn van tien jaar loopt vanaf het in de handel brengen of het in gebruik stellen, en dus per systeem en per versie, niet per leveranciersrelatie.
Vastlegging per systeem van rol, contractuele afspraken over informatie en medewerking, en de aanwijzing van een gemachtigde waar vereist.
Aanbeveling van een kandidaat die automatisch een besluit wordt
Een werkgever gebruikt een systeem dat sollicitanten rangschikt en een kandidaat voor aanname aanbeveelt. In de ene inrichting weegt een recruiter die aanbeveling mee in een eigen beoordeling; in de andere inrichting wordt de uitkomst automatisch toegepast en valt een kandidaat af zonder dat iemand ernaar kijkt.
De ontwerprichtsnoeren van de Commissie van 19 mei 2026 behandelen dit geval bij de vraag of een toepassing onder Bijlage III valt. Het document is een consultatieversie: niet bindend en nog niet definitief.
Ontwerprichtsnoeren classificatie hoog-risico AI, 19 mei 2026, bijlage over Bijlage III
Toets uw wervingssysteem op het beoogde doel en niet op de vraag of een recruiter meekijkt, want het toevoegen of weglaten van menselijke tussenkomst verandert de indeling als hoog risico niet.
AI-artikelen over EU-beleid zonder inhoudelijke toetsing
Een website publiceert automatisch AI-gegenereerde artikelen over Europees beleid. Er is een redactiestatuut op papier, maar niemand toetst de inhoud. Voor publicatie draait alleen een spellingcontrole, en een tweede AI-model kijkt de tekst na.
De finale richtsnoeren van de Commissie over artikel 50 behandelen dit geval als uitgewerkt voorbeeld bij de transparantieplichten. Het document is niet bindend.
Commission Guidelines C(2026) 5054 final, 20.7.2026, uitgewerkte voorbeelden bij artikel 50
Een redactiestatuut op papier, een spellingcontrole en een tweede AI-model tellen niet als menselijke toetsing, dus zonder inhoudelijke feitencontrole door een mens moet u de publicatie labelen.
AI-samenvatting van een raadsbesluit onder eindredactie
Een nieuwssite zet onder een door een journalist geschreven artikel over een recent raadsbesluit een AI-gegenereerde samenvatting. De eindredacteur leest die samenvatting inhoudelijk na, controleert de feiten en geeft akkoord voor publicatie.
Leun niet op de redactie-uitzondering zonder inhoudelijke toetsing door een deskundige en een vindbaar genoemde eindverantwoordelijke, en bedenk dat de uitzondering vervalt zodra AI na de akkoordverklaring opnieuw in de tekst ingrijpt.
AI-speelgoed beloont kinderen voor gevaarlijke challenges
Een fabrikant brengt interactief AI-speelgoed op de markt dat kinderen geboeid houdt met steeds risicovollere opdrachten, zoals op meubels klimmen, hoge planken verkennen of met scherpe voorwerpen omgaan, in ruil voor digitale beloningen en virtuele complimenten.
De richtsnoeren van de Commissie over verboden AI-praktijken behandelen dit geval als uitgewerkt voorbeeld bij artikel 5. Het document is niet bindend: de uiteindelijke uitleg is aan het Hof van Justitie.
Commission Guidelines C(2025) 5052 final, 29.7.2025, uitgewerkte voorbeelden bij artikel 5
Richt uw product zich mede op kinderen, beoordeel dan elk beloningsmechanisme apart, want wat bij volwassenen nog acceptabele prikkeling heet, kan bij kinderen al uitbuiting van hun nieuwsgierigheid en beloningsdrang zijn.
Gezichtsherkenning bij toegangscontrole: de beveiliger achter de camera telt mee
Een organisatie beveiligt de ingang van haar panden met gezichtsherkenning en gebruikt die biometrische toegangscontrole ook om bezoekers te registreren. Geeft het systeem geen match, dan beoordeelt een beveiliger de beelden van de camera en beslist hij zelf of iemand naar binnen mag. De vraag is wiens maatregelen die beveiliger moeten bereiken: die van de leverancier van het model, die van de afdeling die het systeem inzet, of allebei.
Artikel 4, lid 1 bepaalt dat aanbieders en gebruiksverantwoordelijken van AI-systemen maatregelen nemen om de ontwikkeling van AI-geletterdheid van hun personeel en andere personen die namens hen AI-systemen exploiteren en gebruiken te ondersteunen. Zij houden daarbij rekening met technische kennis, ervaring, onderwijs en opleiding en de context waarin de AI-systemen zullen worden gebruikt, evenals met de personen of groepen personen ten aanzien van wie de AI-systemen zullen worden gebruikt. Dezelfde bepaling stelt dat deze verplichting niet inhoudt dat aanbieders of gebruiksverantwoordelijken een bepaald niveau van AI-geletterdheid voor personen moeten waarborgen.
Wij lezen de zinsnede over de personen ten aanzien van wie het systeem wordt gebruikt als het zwaartepunt bij biometrie: wie voor de camera staat ondergaat de uitkomst en heeft daar zelf weinig tegenwicht tegen. Dat pleit ervoor de beveiliger die na een uitblijvende match zelf beslist inhoudelijker toe te rusten dan de collega die het systeem alleen aan- en uitzet. Het artikel zegt zelf niet welk niveau volstaat en bepaalt uitdrukkelijk dat u geen niveau hoeft te waarborgen, dus waar de ondergrens per rol ligt blijft open. Naar onze inschatting is een dossier per rol, met de gemaakte keuze en de reden daarvoor, beter verdedigbaar dan een organisatiebrede sessie met alleen een aanwezigheidslijst.
Politie met AI in de opsporing: de context bepaalt hoe zwaar u opleidt
Een politiedienst gebruikt AI om grote hoeveelheden opsporingsdossiers te doorzoeken en verbanden te laten opvallen die een rechercheur anders zou missen. De uitkomsten wegen mee in de keuze welke verdachte verder wordt onderzocht en belanden uiteindelijk in stukken die het strafrecht in gaan. De vraag is of dezelfde basisinstructie volstaat voor de analist die het model bedient en voor de rechercheur die op de uitkomst afgaat.
Artikel 4, lid 1 verplicht aanbieders en gebruiksverantwoordelijken van AI-systemen maatregelen te nemen om de ontwikkeling van AI-geletterdheid van hun personeel en andere personen die namens hen AI-systemen exploiteren en gebruiken te ondersteunen. De bepaling schrijft voor dat zij daarbij rekening houden met technische kennis, ervaring, onderwijs en opleiding en met de context waarin de AI-systemen zullen worden gebruikt, evenals met de personen of groepen personen ten aanzien van wie de AI-systemen zullen worden gebruikt. Zij bepaalt tegelijk dat deze verplichting niet inhoudt dat een bepaald niveau van AI-geletterdheid voor personen moet worden gewaarborgd.
Artikel 4 verlangt dat u de context van gebruik meeweegt en ook de mensen op wie het systeem wordt toegepast, en in de rechtshandhaving lopen beide factoren naar onze lezing hoog op. Of een algemene introductie over de mogelijkheden van AI dan volstaat voor wie een uitkomst overneemt in een dossier dat iemands positie als verdachte raakt, betwijfelen wij, maar de bepaling zegt uitdrukkelijk niet welk niveau u moet waarborgen, zodat u die ondergrens zelf moet onderbouwen. Wij zouden per rol vastleggen wat iemand moet kunnen herkennen, bijvoorbeeld dat een gevonden verband nog geen bewijs is, en die keuze periodiek opnieuw wegen.
Redactie met generatieve AI: tellen freelancers mee in uw maatregelen?
Een nieuwsredactie zet generatieve AI in om samenvattingen, koppen en beeld voor te bereiden, waarna een eindredacteur het stuk afmaakt en de redactie besluit te publiceren. Een deel van dat werk ligt bij freelancers, en een extern bureau maakt met dezelfde tools de content voor marketing. De vraag is of uw maatregelen voor AI-geletterdheid ook die freelancers en dat bureau moeten raken, of alleen de mensen op de loonlijst.
Artikel 4, lid 1 richt zich tot aanbieders en gebruiksverantwoordelijken van AI-systemen en verplicht hen maatregelen te nemen om de ontwikkeling van AI-geletterdheid te ondersteunen van hun personeel en van andere personen die namens hen AI-systemen exploiteren en gebruiken. De bepaling verlangt dat zij daarbij rekening houden met technische kennis, ervaring, onderwijs en opleiding en met de context waarin de AI-systemen zullen worden gebruikt, evenals met de personen of groepen personen ten aanzien van wie de AI-systemen zullen worden gebruikt. Zij houdt niet in dat een bepaald niveau van AI-geletterdheid voor personen moet worden gewaarborgd.
De wettekst noemt naast personeel uitdrukkelijk andere personen die namens u AI-systemen exploiteren en gebruiken, en wij lezen dat als een functionele en niet als een contractuele afbakening. Een freelance eindredacteur die uw tool in uw workflow en op uw aanwijzing gebruikt hoort in die lezing binnen uw maatregelen, ook zonder arbeidsovereenkomst. Bij het externe bureau ligt het minder eenvoudig: werkt het in uw omgeving en op uw aanwijzing, dan is verdedigbaar dat het namens u handelt, maar zet het voor eigen rekening zijn eigen tools in, dan is het zelf gebruiksverantwoordelijke en zegt artikel 4 niet dat uw maatregelen dat werk moeten dekken. Praktisch betekent dat naar onze inschatting: leg in de opdrachtafspraken vast wie in welke rol werkt en welke instructie u meegeeft, in plaats van erop te vertrouwen dat de ander het zelf regelt.
AI-chat bij werving en selectie: wat de sollicitant moet weten
Een recruiter zet een AI-chat in die kandidaten na hun reactie op een vacature een eerste screeningsgesprek laat voeren en hun cv aanvult met de antwoorden. De chat presenteert zich met een voornaam en schrijft in vlotte spreektaal. De vraag is of deze sollicitanten redelijkerwijs doorhebben dat zij met een AI-systeem praten.
Artikel 50 lid 1 verplicht aanbieders ervoor te zorgen dat AI-systemen die voor directe interactie met natuurlijke personen zijn bedoeld zodanig worden ontworpen en ontwikkeld dat de betrokken natuurlijke personen worden geinformeerd dat zij interageren met een AI-systeem, tenzij dit duidelijk is vanuit het oogpunt van een normaal geinformeerde en redelijk omzichtige en oplettende natuurlijke persoon, rekening houdend met de omstandigheden en de gebruikscontext. Artikel 50 lid 5 bepaalt dat die informatie uiterlijk op het moment van de eerste interactie op duidelijke en te onderscheiden wijze aan de betrokken natuurlijke personen wordt verstrekt en aan de toepasselijke toegankelijkheidseisen voldoet.
Wij lezen de duidelijkheidstoets als een vraag over het publiek dat het systeem feitelijk tegenkomt, en dat publiek is bij werving en selectie geen getrainde beroepsgroep maar een brede groep sollicitanten die onder druk staat en de organisatie nog niet kent. Een menselijke voornaam en spreektaal duwen die beoordeling in onze ogen de verkeerde kant op, hoe handig ze conversioneel ook zijn. Koopt u de chat in plaats van hem te bouwen, dan richt artikel 50 lid 1 zich naar de letter tot de aanbieder terwijl u de persona en het instapmoment kiest; of u met een eigen naam op zo'n chat zelf in de rol van aanbieder schuift, beantwoordt artikel 50 niet. Maak de melding in het eerste bericht daarom een inkoopeis en controleer bij oplevering dat die er ook echt staat.
Camera bij de ingang: toegangscontrole versus biometrische categorisatie
Een organisatie laat medewerkers binnen via gezichtsherkenning bij de toegangscontrole en gebruikt in de bezoekersruimte daarnaast een camera die gezichten in leeftijdsgroepen indeelt. Beide toepassingen draaien op dezelfde biometrische infrastructuur en dezelfde beelden. De vraag is bij welke van de twee de betrokken personen actief geinformeerd moeten worden.
De richtsnoeren van de Commissie van 20 juli 2026 rekenen geautomatiseerde toegangscontrole met gezichtsherkenning tot de systemen die alleen passief gegevens verzamelen en niet tot een uitwisseling met natuurlijke personen in staat zijn, en dus niet interageren in de zin van artikel 50 lid 1. Voor artikel 50 lid 3 stellen zij dat de informatieplicht, behoudens gebruik dat op grond van artikel 5, lid 1, punt g, verboden is, geldt voor elk systeem voor biometrische categorisering, ook buiten hoog risico, en noemen zij indeling naar leeftijd of geslacht op basis van biometrische gegevens als voorbeeld. Artikel 50 lid 3 zelf kent daarnaast een eigen uitzondering voor systemen die bij wet zijn toegestaan om strafbare feiten op te sporen, te voorkomen of te onderzoeken. Als wijze van informeren noemen de richtsnoeren een zichtbare mededeling bij elke mogelijke ingang van een tentoonstellingsruimte dat gezichtsopnamen worden gemaakt om bezoekers aan een leeftijdsgroep toe te wijzen, uiterlijk op het moment van de eerste blootstelling.
Commission Guidelines C(2026) 5054 final, 20.7.2026, randnummer (30) en randnummers (104) tot en met (108)
Onze lezing is dat u niet per camera maar per verwerkingsdoel moet inventariseren: dezelfde lens die bij de toegangscontrole buiten lid 1 valt, brengt u binnen lid 3 zodra dezelfde beelden mensen in een categorie plaatsen. Leg daarom per opstelling vast wat er met de opname gebeurt en wie de gebruiksverantwoordelijke is, want dat bepaalt of er een bordje bij de ingang hoort te hangen. De richtsnoeren schrijven geen vaste vorm voor, maar zij binden wel het moment: de mededeling moet er zijn voordat iemand het beeld in loopt, en een verwijzing in het privacystatement haalt dat moment in onze lezing zelden.
Code-assistent voor ontwikkelaars: uitzondering, tot hij naar buiten praat
Een softwarebedrijf gebruikt een AI-assistent voor codesuggesties en code review, alleen beschikbaar voor professionele ontwikkelaars. Datzelfde bedrijf zet ook een helpdeskchatbot in voor klanten.
De richtsnoeren van de Commissie van 20 juli 2026 noemen code-assistentie- en code-reviewchatbots die alleen beschikbaar zijn voor professionele ontwikkelaars als voorbeeld waarin de evidentie-uitzondering opgaat. Chatbots in online platforms of helpdesks waarbij gebruikers uitkomsten kunnen aanzien voor menselijk werk, noemen zij juist als voorbeeld waarin de meldplicht wel geldt.
Commission Guidelines C(2026) 5054 final, 20.7.2026, randnummer (45), lijsten met en zonder evidentie-uitzondering
Twee AI-assistenten bij hetzelfde bedrijf, twee uitkomsten. Beoordeel per toepassing wie de gebruiker is en wat die redelijkerwijs verwacht, in plaats van een organisatiebreed standpunt in te nemen over chatbots.
Fraudemeldportaal van een bank: waarom de opsporingsuitzondering hier afvalt
Een bank opent een AI-gestuurd meldportaal waar klanten vermoedelijke fraude rond hun betaalrekening of lening kunnen doorgeven. Het systeem stelt vervolgvragen, categoriseert de melding en zet die door naar fraudedetectie en, bij witwassignalen, naar het interne meldteam. Omdat het portaal over strafbare feiten gaat, gaat de bank ervan uit dat de meldplicht bij directe AI-interactie niet speelt.
De richtsnoeren van de Commissie van 20 juli 2026 noemen door financiele instellingen of overheidsinstanties beheerde AI-ondersteunde fraudemeldlijnen en meldportalen, waar gebruikers vermoedelijke financiele misdrijven kunnen melden, uitdrukkelijk als voorbeeld dat niet is vrijgesteld en binnen het toepassingsbereik van artikel 50 lid 1 valt. Zij lichten toe dat de uitzondering niet opgaat wanneer het systeem voor het publiek beschikbaar is en het gebruikers de mogelijkheid biedt een strafbaar feit te melden. Dat het systeem de melding alleen uitvraagt, categoriseert en prioriteert terwijl menselijke onderzoekers de informatie valideren voordat er actie volgt, verandert dat in de richtsnoeren niet.
Commission Guidelines C(2026) 5054 final, 20.7.2026, randnummers (48) en (49), voorbeeldenlijst bij de opsporingsuitzondering
In onze lezing is dit de plek waar banken het vaakst verkeerd afslaan: het meldportaal hangt organisatorisch onder fraude en compliance, waardoor de opsporingsuitzondering vanzelfsprekend aanvoelt terwijl juist het publieke meldkanaal is uitgezonderd van die uitzondering. Daar komt bij dat de uitzondering is geschreven voor gebruik dat bij wet is toegestaan voor opsporing, en de richtsnoeren rekken haar niet verder op dan tot andere overheidsinstanties met zo'n wettelijke grondslag, zodat een private bank er in onze lezing zelden in staat nog voordat het publieke meldkanaal ter sprake komt. Behandel het portaal daarom als een gewone publieksfacing chat en zet de mededeling in het eerste scherm van het gesprek. Een zin in de algemene voorwaarden of in een productbijsluiter is voor dit kanaal een zwakke keuze, omdat de melder op dat moment al aan het vertellen is.
AI-tekst van een gemeente: wanneer telt een eindcheck als redactionele controle
Een gemeente laat een AI-systeem de webteksten schrijven over een gewijzigde regeling voor bijstand en toeslagen, bedoeld om burgers uit te leggen waar zij recht op hebben. Een communicatiemedewerker leest de tekst na op stijl en spelling en zet hem online. De vraag is of deze publieke dienst daarmee onder de uitzondering op de labelplicht valt.
De richtsnoeren van de Commissie van 20 juli 2026 rekenen openbaar bestuur en publieke dienstverlening tot de aangelegenheden van algemeen belang waarop de bekendmakingsplicht voor gepubliceerde AI-tekst uit artikel 50 lid 4 ziet. Voor de uitzondering moeten volgens de richtsnoeren twee voorwaarden cumulatief zijn vervuld: de door AI gegenereerde of bewerkte tekst heeft menselijke toetsing of redactionele controle ondergaan, en een natuurlijke of rechtspersoon draagt redactionele verantwoordelijkheid voor de bekendmaking. Zij stellen daarbij dat menselijke toetsing een bewuste inhoudelijke beoordeling is met feitencontrole als minimum, en dat oppervlakkige, louter formele of procedurele controles zoals spelling- of grammaticacorrectie daarvoor niet volstaan. Voor de tweede voorwaarde verlangen zij dat de identiteit of de functie van degene die de redactionele verantwoordelijkheid draagt op een eenvoudig vindbare plaats openbaar is.
Commission Guidelines C(2026) 5054 final, 20.7.2026, randnummer (131), randnummers (133) tot en met (136) en randnummer (138)
Onze lezing is dat veel gemeenten wel een publicatieproces hebben maar geen aanwijsbare persoon die inhoudelijke eindverantwoordelijkheid draagt, en dat is precies het scharnierpunt van deze uitzondering. Wijs die rol expliciet toe, maak vindbaar wie hem draagt en leg per pagina vast wie de feiten heeft gecontroleerd, of kies anders voor de eenvoudiger route en label de tekst gewoon. Let daarbij op de volgorde in uw werkproces, want een AI-hulpmiddel dat de tekst na de menselijke goedkeuring nog inhoudelijk herschrijft haalt de grond onder die goedkeuring vandaan.
Interne assistent voor HR en compliance: uitzondering met een randvoorwaarde
Een organisatie geeft medewerkers een interne AI-assistent voor HR-, juridische, inkoop-, compliance- en IT-vragen. Moet die assistent bij elk gesprek melden dat hij AI is?
De richtsnoeren van de Commissie van 20 juli 2026 noemen een interne, op medewerkers gerichte assistent voor geschoold en AI-geletterd personeel dat weet dat het AI-systemen gebruikt voor interne organisatiedoeleinden, als voorbeeld waarin de evidentie-uitzondering van artikel 50 lid 1 opgaat.
De richtsnoeren koppelen deze uitzondering uitdrukkelijk aan geschoold en AI-geletterd personeel. Uw beroep op de uitzondering staat of valt dus met wat u onder artikel 4 aan geletterdheid hebt geregeld en kunt aantonen: zonder dat dossier leunt u op een aanname over uw eigen mensen.
Diagnoseondersteuning voor artsen: geen meldplicht, wel zorgvuldigheid
Een ziekenhuis zet een interactief AI-systeem in dat uitsluitend door geschoolde zorgprofessionals wordt gebruikt om een medische diagnose te ondersteunen en behandelingen voor te stellen. De vraag is of de patient of de arts moet horen dat het AI is.
De richtsnoeren van de Commissie van 20 juli 2026 noemen interactieve AI-systemen die uitsluitend bedoeld zijn voor geschoolde zorgprofessionals ter ondersteuning van diagnose en behandelvoorstellen als voorbeeld waarin de evidentie-uitzondering van artikel 50 lid 1 opgaat: voor die gebruiker is het AI-karakter duidelijk.
De uitzondering hangt aan de gebruiker, niet aan het systeem. Zodra hetzelfde model ook patienten te woord staat, valt die grond weg en geldt de meldplicht gewoon. En de uitzondering op artikel 50 zegt niets over de rest: gaat het om een medisch hulpmiddel of een hoog-risicotoepassing, dan blijven die regimes onverkort gelden.
Opsporingsdienst: vrijgesteld van de meldplicht, met waarborgen
Een dienst die bij wet bevoegd is strafbare feiten op te sporen, wil een interactief AI-systeem inzetten zonder aan betrokkenen te melden dat zij met AI communiceren.
Artikel 50 lid 1 zondert aanbieders van interactieve AI-systemen uit van de meldplicht wanneer zij bij wet gemachtigd zijn strafbare feiten op te sporen, te voorkomen, te onderzoeken of te vervolgen, onder passende waarborgen voor de rechten en vrijheden van derden. De richtsnoeren van de Commissie van 20 juli 2026 werken die uitzondering uit.
Commission Guidelines C(2026) 5054 final, 20.7.2026, randnummer (46), uitzondering voor rechtshandhaving
De uitzondering is smal en voorwaardelijk: zij vraagt een wettelijke grondslag voor de opsporingstaak en passende waarborgen voor derden. Een publieke taak op zich is niet genoeg, en de waarborgen zijn geen bijzin maar onderdeel van de grond waarop u zich beroept.
Uitlegsessie bij de klant op het moment van ingebruikname
Asimov AI is een micro-organisatie met maximaal vijftien medewerkers die AI-diensten levert voor wetgevingswerk aan overheidsinstellingen en bedrijven. Bij elk nieuw contract organiseert het bedrijf een of meer inductiecalls met de teamleiders en ambtenaren die het platform gaan gebruiken, waarin het uitlegt hoe het platform en de onderliggende modellen werken en hoe hallucinaties in dit domein ontstaan en beperkt kunnen worden.
Deze praktijk is door de betrokken organisatie zelf aangeleverd aan het levend repository van de Commissie. Het repository verzamelt en deelt praktijken, maar keurt ze niet goed en stelt ze niet vast als norm.
Levend repository van AI-geletterdheidspraktijken, ingediende praktijk van de betrokken organisatie
Deze praktijk legt de geletterdheid waar het risico ontstaat: bij de mensen die het systeem straks gebruiken, op het moment dat zij ermee beginnen. Voor een kleine aanbieder is dat ook het enige haalbare moment, omdat er geen opleidingsafdeling is om het later over te doen. Wie dit overneemt, moet wel vastleggen wie erbij was en wat er is uitgelegd, want anders bestaat de inspanning na een jaar alleen nog in de herinnering van de deelnemers.
Beoordelingssysteem voor personeel gaat de fout in: melden of niet
Een werkgever gebruikt een AI-systeem dat het functioneren van medewerkers scoort en die score meeweegt bij promotie en ontslag. Na een wijziging aan het model blijkt een groep werknemers maandenlang te laag te zijn beoordeeld, en op die beoordelingen zijn al besluiten genomen. Personeelszaken vraagt zich af of dit een ernstig incident is en wie er dan moet melden.
Artikel 3, punt 49 omschrijft een ernstig incident als een incident of gebrekkig functioneren van een AI-systeem dat direct of indirect leidt tot onder meer een schending van de uit het recht van de Unie voortvloeiende verplichtingen ter bescherming van de grondrechten. Artikel 73, lid 1 legt de meldplicht voor ernstige incidenten bij de aanbieder van het in de Unie in de handel gebrachte hoog-risico AI-systeem, tegenover de markttoezichtautoriteiten van de lidstaat waarin het incident heeft plaatsgevonden. Lid 2 verlangt dat de melding wordt gedaan onmiddellijk nadat de aanbieder een oorzakelijk verband tussen het AI-systeem en het ernstige incident of de redelijke waarschijnlijkheid van een dergelijk verband heeft vastgesteld, en in ieder geval uiterlijk vijftien dagen nadat de aanbieder of, in voorkomend geval, de gebruiksverantwoordelijke zich bewust wordt van het ernstige incident, waarbij bij die termijn rekening wordt gehouden met de ernst van het incident. Lid 6 verplicht de aanbieder na de melding onverwijld het nodige onderzoek te verrichten in verband met het ernstige incident en het betrokken AI-systeem, met inbegrip van een risicobeoordeling en corrigerende maatregelen, en daarbij samen te werken met de bevoegde autoriteiten en, in voorkomend geval, met de betrokken aangemelde instantie. Artikel 26, lid 5 verplicht de gebruiksverantwoordelijke die een ernstig incident vaststelt daarvan onmiddellijk eerst de aanbieder in kennis te stellen en vervolgens de importeur of distributeur en de betreffende markttoezichtautoriteiten.
Artikel 3, punt 49, artikel 26, lid 5, en artikel 73, leden 1, 2 en 6
Op de werkvloer zit het lastige punt in de bewustwording uit lid 2: schade die dun is uitgesmeerd over veel medewerkers komt niet binnen als alarm, maar druppelt binnen via klachten, een beoordelingsgesprek of de ondernemingsraad. Of stelselmatig te lage scores met gevolgen voor promotie en ontslag een ernstig incident opleveren, hangt naar onze lezing af van de vraag of daarmee verplichtingen ter bescherming van grondrechten zijn geschonden in de zin van artikel 3, punt 49, onder c; die weging maakt artikel 73 niet voor u. Bepaal daarom vooraf welk signaal uit personeelszaken telt als incidentsignaal en wie het diezelfde week bij de aanbieder neerlegt, in plaats van dat achteraf te reconstrueren; artikel 26, lid 5 verlangt van u als gebruiksverantwoordelijke bovendien dat u bij een vastgesteld ernstig incident onmiddellijk eerst de aanbieder informeert en vervolgens de importeur of distributeur en de markttoezichtautoriteit. Let er ten slotte op dat de corrigerende maatregelen van lid 6 op het systeem zien; wat er met de al genomen besluiten over promotie of ontslag moet gebeuren, leest u naar onze lezing niet in dit artikel en loopt via andere regels, waaronder het arbeidsrecht.
Politieke voorkeur afleiden uit geuploade foto's
Een platform analyseert de biometrische gegevens uit foto's die gebruikers hebben geupload om hun vermoedelijke politieke voorkeur af te leiden en hen gerichte politieke boodschappen te sturen. Een vergelijkbaar systeem leidt de vermoedelijke seksuele gerichtheid af om advertenties te tonen.
Beroept u zich op de uitzondering voor een nevenfunctie, dan moet die functie ook technisch strikt noodzakelijk zijn voor de hoofddienst, want beide voorwaarden gelden samen en advertentiedoelen halen die drempel niet.
Gezichtsvergelijking bij de grenspoort: verificatie of identificatie
Een geautomatiseerde grenspoort gebruikt biometrische gezichtsherkenning om het gezicht van een reiziger te vergelijken met de foto in de chip van het paspoort. Dezelfde camera kan technisch ook tegen een opsporingsdatabank vergelijken, en juist dat verschil bepaalt of deze biometrie hoog risico is.
De ontwerprichtsnoeren van de Commissie van 19 mei 2026 stellen dat biometrische verificatie buiten de hoog-risicoclassificatie valt: het een-op-een vergelijken van aangeboden biometrie met eerder vastgelegde biometrie, uitsluitend om te bevestigen dat iemand is wie hij zegt te zijn. Wordt dezelfde opname daarnaast tegen een opsporingsdatabank vergeleken, dan is het wel biometrische identificatie op afstand. Het document is een consultatieversie: niet bindend en nog niet definitief.
Ontwerprichtsnoeren classificatie hoog-risico AI, 19 mei 2026, bijlage over Bijlage III, randnummer (136)
Toets uw biometrische toepassing op het doel en niet op de techniek: dezelfde camera en hetzelfde model vallen buiten de hoog-risicoroute zolang de vergelijking een-op-een is en alleen de identiteit bevestigt, en vallen erbinnen zodra dezelfde opname ook tegen een databank wordt gehouden. Leg daarom per toepassing vast waartegen wordt vergeleken, want die ene ontwerpkeuze verplaatst het hele regime.
Training in drie delen voor juristen en public affairs
Booking.com bouwde voor de juridische en public affairs teams een training in drie delen: eerst de basisbegrippen en het verschil tussen klassieke machine learning en taalmodellen, dan hoe AI binnen het eigen bedrijf werkt, dan het regelgevend kader en de raakvlakken met het recht dat zij al beoefenen. Het materiaal verscheen ook als video- en podcastserie met ondertiteling en uitgeschreven hand-outs.
De opbouw is het interessante deel: eerst de techniek, dan de eigen organisatie, dan pas het recht. Juristen die die volgorde omdraaien leren de verordening uit hun hoofd zonder te kunnen beoordelen waar hun eigen systemen in vallen. Dat een training in meerdere vormen beschikbaar is helpt bovendien bij het aantonen dat zij daadwerkelijk bereikbaar was voor iedereen die haar nodig had.
Callcenter meet de boosheid van medewerkers
Een callcenter gebruikt webcams en spraakherkenning om emoties van medewerkers te volgen, zoals boosheid. Hetzelfde bedrijf gebruikt spraakanalyse ook om te herkennen wanneer een klant geirriteerd raakt.
Het verbod volgt de gezagsverhouding en niet de techniek: dezelfde spraakanalyse op medewerkers is verboden en op klanten niet, en werkplek omvat ook sollicitanten en de proeftijd.
Een werkgever laat een extern wervingssysteem alle binnengekomen sollicitaties scoren en rangschikken, waarna recruiters alleen de bovenste twintig procent nog met de hand bekijken. De leverancier brengt het systeem onder eigen naam op de markt, de werkgever gebruikt het in zijn eigen selectieproces.
Dat recruiters de eindkeuze houden helpt u niet, want zodra het systeem sollicitanten scoort of rangschikt en zo de shortlist stuurt, blijft het hoog risico en geldt geen uitzondering.
Databasequery en standaard spreadsheet zonder AI-functies
Een klantenserviceafdeling draait in het databasesysteem de opdracht om alle klanten te vinden die vorige maand een bepaald product kochten, en berekent in een standaard spreadsheet het gemiddelde uit een klanttevredenheidsenquete. Alle stappen volgen vooraf vastgelegde instructies.
De richtsnoeren van de Commissie over de definitie van een AI-systeem gebruiken dit geval om de grens te trekken tussen software die wel en niet onder de verordening valt. Het document is niet bindend.
Commission Guidelines C(2025) 5053 final, 29.7.2025, grensgevallen bij de definitie van artikel 3, punt 1
Beroept u zich op de categorie basale gegevensverwerking, kijk dan naar de hele levenscyclus en niet alleen naar het gebruik, want die categorie veronderstelt dat in geen enkele fase wordt geleerd, geredeneerd of gemodelleerd.
Juristen leren techniek, ontwikkelaars leren recht
Dedalus Healthcare, dat onder meer AI levert die complicaties bij ziekenhuispatiënten voorspelt, traint zijn juristen, de functionaris gegevensbescherming, compliance en de afdeling kwaliteit en regelgeving juist op de technische kant. Ontwikkelaars en ingenieurs krijgen omgekeerd training die is toegespitst op de juridische en compliance-aspecten van de AI-verordening. De directie kreeg een eigen sessie op maat van haar rol.
Zoek de kennis bewust buiten een enkele discipline, want het register noemt samenwerking tussen bedrijfsleven en wetenschap als een van de vormen waarin organisaties AI-geletterdheid opbouwen.
Deepfake op een kerstkaart: aanbieder markeert, particulier niet
Een particulier maakt met een generatieve AI-dienst een deepfake van zichzelf en zijn huisgenoten voor op de eigen kerstkaart, puur privé en zonder enig zakelijk doel.
De uitsluiting voor privégebruik raakt alleen de plichten van de gebruiker, dus levert u de generatieve dienst dan markeert u de uitvoer machineleesbaar, en zodra er een zakelijk doel bijkomt keert de labelplicht terug.
Echte auto tegen een AI-achtergrond is geen deepfake
Een autobedrijf fotografeert een bestaand model en plaatst het in een advertentie tegen een volledig AI-gegenereerde achtergrond met een verzonnen landschap. De auto zelf is niet bewerkt.
De ruimte hangt aan het product zelf, dus zolang uiterlijk, eigenschappen en gebruik ongewijzigd blijven volstaat een AI-achtergrond, maar raakt de bewerking het product wel, dan moet u alsnog labelen.
Medische uitzondering: toegankelijkheid mag, burn-outdetectie niet
Een werkgever wil emotieherkenning inzetten. In het ene scenario ondersteunt het systeem medewerkers met autisme en verbetert het de toegankelijkheid voor blinde en dove collega's. In het andere scenario meet het stressniveaus om burn-out, verveling of motivatieverlies te signaleren.
De medische uitzondering is smal: ondersteuning van een concrete beperking valt eronder, algemene monitoring van welzijn, stress of motivatie niet, en gegevens uit een toegestane inzet mag u niet hergebruiken.
Ernstig incident aan de productielijn: wie meldt en binnen welke termijn
Een fabrikant levert een AI-systeem dat als veiligheidscomponent in een machine op de productielijn meedraait en tegelijk de kwaliteitscontrole aanstuurt. In de fabriek van een afnemer raakt een operator ernstig gewond nadat de machine bij een afwijking niet tot stilstand kwam. De vraag is wie de melding doet, aan wie, en welke klok op dat moment al loopt.
Artikel 73, lid 1 legt de melding van ernstige incidenten bij de aanbieder van het in de Unie in de handel gebrachte hoog-risico AI-systeem, gericht aan de markttoezichtautoriteiten van de lidstaat waarin het incident heeft plaatsgevonden. Lid 2 bepaalt dat die melding wordt gedaan onmiddellijk nadat de aanbieder een oorzakelijk verband tussen het AI-systeem en het ernstige incident of de redelijke waarschijnlijkheid van een dergelijk verband heeft vastgesteld, en in ieder geval uiterlijk vijftien dagen nadat de aanbieder of, in voorkomend geval, de gebruiksverantwoordelijke zich bewust wordt van het incident, waarbij bij die termijn rekening wordt gehouden met de ernst ervan. Lid 4 verkort dat bij overlijden van een persoon tot uiterlijk tien dagen. Lid 6 verplicht de aanbieder na de melding onverwijld het nodige onderzoek te verrichten, met inbegrip van een risicobeoordeling en corrigerende maatregelen, en geen onderzoek te verrichten waarbij het AI-systeem wordt gewijzigd op een wijze die van invloed kan zijn op de latere evaluatie van de oorzaken, zonder de bevoegde autoriteiten daarvan vooraf in kennis te stellen. Artikel 26, lid 5 verplicht de gebruiksverantwoordelijke die een ernstig incident vaststelt daarvan onmiddellijk eerst de aanbieder in kennis te stellen en vervolgens de importeur of distributeur en de betreffende markttoezichtautoriteiten, en verklaart artikel 73 van overeenkomstige toepassing wanneer de gebruiksverantwoordelijke de aanbieder niet kan bereiken.
Artikel 73, leden 1, 2, 4 en 6, en artikel 26, lid 5
Wij lezen lid 2 zo dat de termijn al kan gaan lopen bij de gebruiksverantwoordelijke op de werkvloer van de fabriek, terwijl de melding van lid 1 bij u als aanbieder van het AI-systeem ligt. Dat betekent niet dat uw afnemer stil kan blijven zitten: artikel 26, lid 5 geeft de gebruiksverantwoordelijke een eigen kennisgevingsroute langs u, de importeur of distributeur en de markttoezichtautoriteit, en laat artikel 73 van overeenkomstige toepassing zijn wanneer u niet bereikbaar bent. Leg die route daarom vast in het contract en in de servicelijn voordat er iets gebeurt. Bij een zwaargewonde operator zonder dodelijke afloop is naar onze lezing de buitengrens van lid 2 aan de orde en niet de tien dagen van lid 4; hoeveel eerder dan die buitengrens gemeld moet worden, laat de tekst open en hangt af van de ernst. Houd er daarnaast rekening mee dat de reflex om de machine direct te herstellen en de productie te hervatten kan botsen met lid 6, omdat onderzoek waarbij het systeem wordt gewijzigd eerst een bericht aan de bevoegde autoriteit vraagt. Wie dat pas tijdens het incident uitzoekt, verliest dagen die er binnen deze termijnen niet zijn.
Expertsysteem dat uit vastgelegde kennis een conclusie trekt
Een ziekenhuis gebruikt een ouder diagnose-ondersteunend expertsysteem waarin artsen kennis, feiten en regels hebben vastgelegd. Op basis van de symptomen die een arts invoert, trekt het systeem zelfstandig een conclusie over mogelijke aandoeningen.
Machine learning is geen vereiste, dus u kunt zich er niet op beroepen dat uw systeem alleen met door experts vastgelegde regels werkt; ook logica- en kennisgebaseerde systemen die zelfstandig concluderen vallen eronder.
AI-contactpersoon per afdeling bij een telecombedrijf
Fastweb beheert meer dan negentig AI-systemen en benoemt in elke afdeling formeel een AI-SPOC, een getrainde contactpersoon voor AI-vragen uit het eigen team. Deze contactpersonen krijgen aparte instructie over verboden praktijken en hoog-risicosystemen en mogen zelfstandig de AI-risicobeoordeling van hun afdeling uitvoeren.
Neem een praktijk uit dit register niet klakkeloos over, want overname levert volgens de Commissie geen automatisch vermoeden van naleving op; toets eerst of de opzet past bij uw eigen systemen en rollen.
Wie zwaar finetunet wordt zelf modelaanbieder
Een Europese scale-up finetunet een bestaand model voor algemene doeleinden voor het eigen product en zet daarbij meer rekenkracht in dan een derde van de rekenkracht waarmee het oorspronkelijke model getraind is.
De richtsnoeren van de Commissie over de reikwijdte van de GPAI-plichten behandelen dit geval bij de vraag wanneer iemand zelf modelaanbieder wordt. Het document is niet bindend.
Commission Guidelines C(2025) 5045 final, 18.7.2025, reikwijdte van de plichten voor GPAI-modelaanbieders
Reken voor de finetuning uit hoeveel rekenkracht u inzet ten opzichte van het oorspronkelijke model, want boven een derde daarvan wordt u zelf aanbieder en gelden de documentatie-, auteursrecht- en samenvattingsplichten voor uw aanpassing.
Aangiften screenen op strafbare feiten met alleen een profiel
Een belastingdienst gebruikt een voorspellend AI-model op alle aangiften om mogelijke fiscale misdrijven te signaleren. Dat gebeurt uitsluitend op basis van het profiel dat het systeem opbouwt, met persoonlijkheidskenmerken als dubbele nationaliteit, geboorteplaats en aantal kinderen, en met afgeleide variabelen die moeilijk te verifieren zijn.
Om buiten dit verbod te blijven moet uw systeem steunen op echte, verifieerbare feiten die aan een concreet strafbaar feit raken; extra variabelen aan een profiel toevoegen volstaat daarvoor niet.
Fraudeprofilering bij kinderopvangtoeslag
Een belastingdienst zet een AI-systeem in om fraude met kinderopvangtoeslag op te sporen door ontvangers te profileren en in categorieen als opzet of grove nalatigheid in te delen, met criteria als laag inkomen, dubbele nationaliteit en sociaal gedrag. Op basis van de risicoscore wordt het dossier onderzocht, de toeslag stopgezet en terugbetaling geeist.
Fraudebestrijding blijft toegestaan, maar toets bij elk kenmerk of het werkelijk bij het doel hoort en of het gevolg in verhouding staat, want onverwante persoonskenmerken plus zware gevolgen maken van uw controle sociale scoring.
Toekenning van bijstand door een gemeente: de FRIA en de kennisgeving
Een gemeente wil een AI-systeem in gebruik nemen dat aanvragen voor een uitkering uit de bijstand ordent en aangeeft welke dossiers extra onderzoek verdienen voordat een klantmanager beslist. De toepassing staat al in het algoritmeregister. De vraag is wat er geregeld moet zijn voordat de eerste burger door dit systeem gaat.
Artikel 27, lid 1 verlangt van gebruiksverantwoordelijken die publiekrechtelijke organen zijn of particuliere entiteiten die openbare diensten verlenen, dat zij voor de ingebruikname van een hoog-risico AI-systeem als bedoeld in artikel 6, lid 2 een beoordeling uitvoeren van de gevolgen die het gebruik voor de grondrechten kan opleveren, met uitzondering van systemen die bedoeld zijn om te worden gebruikt op het in punt 2 van bijlage III vermelde gebied. Die beoordeling omvat onder meer de categorieen natuurlijke personen en groepen die naar verwachting gevolgen ondervinden, de specifieke risico's op schade voor die categorieen, de uitvoering van maatregelen voor menselijk toezicht en de maatregelen die moeten worden genomen wanneer die risico's zich voordoen, met inbegrip van de regelingen voor interne governance en klachtenregelingen. Lid 3 bepaalt dat de gebruiksverantwoordelijke, zodra de beoordeling is uitgevoerd, de markttoezichtautoriteit in kennis stelt van de resultaten en als onderdeel van die kennisgeving het in lid 5 bedoelde ingevulde sjabloon indient, en dat in het in artikel 46, lid 1, bedoelde geval vrijstelling van de kennisgevingsplicht kan gelden. Lid 5 bepaalt dat het AI-bureau een sjabloon voor een vragenlijst ontwikkelt, onder meer via een geautomatiseerd instrument, om gebruiksverantwoordelijken te helpen hun verplichtingen uit hoofde van dit artikel op vereenvoudigde wijze na te komen.
Wij lezen artikel 27 zo dat een gemeente hier de meest voor de hand liggende gebruiksverantwoordelijke is en dat de beoordeling af moet zijn voordat de eerste aanvraag door het systeem loopt, niet als verantwoording achteraf. Die plicht hangt wel eerst aan de vraag of dit systeem hoog risico is: beoordeelt het de aanspraak op bijstand mede, of blijft het bij een voorbereidende of eng procedurele taak in de zin van artikel 6, lid 3, dat zijn eigen uitzondering weer sluit zodra het systeem burgers profileert? Die vraag beantwoordt u voordat u aan lid 1 begint. Een vermelding in het algoritmeregister is in onze lezing iets anders dan de beoordeling van lid 1, en zij vervangt de kennisgeving van de resultaten aan de markttoezichtautoriteit niet. Praktisch loont het om de klachtenroute voor de burger en de ruimte van de klantmanager om van het signaal af te wijken in hetzelfde dossier vast te leggen, omdat lid 1 juist naar die twee onderdelen vraagt.
Inschatting van recidive bij de politie: wanneer de beoordeling opnieuw moet
Een politiedienst neemt een AI-systeem in gebruik dat bij een verdachte een inschatting van recidive maakt, als hulpmiddel bij de afweging die het openbaar ministerie en de rechter later maken. Later wordt het model hertraind op nieuwere opsporingsgegevens en breidt de dienst het gebruik uit naar een tweede regio. De vraag is of de beoordeling van het eerste gebruik daarmee toereikend blijft.
Artikel 27, lid 1 verlangt dat gebruiksverantwoordelijken die publiekrechtelijke organen zijn, voor de ingebruikname van een hoog-risico AI-systeem als bedoeld in artikel 6, lid 2 een beoordeling uitvoeren van de gevolgen die het gebruik voor de grondrechten kan opleveren, met uitzondering van systemen die bedoeld zijn om te worden gebruikt op het in punt 2 van bijlage III vermelde gebied. Die beoordeling bestaat uit een beschrijving van de processen waarin het systeem wordt gebruikt, van de periode en de frequentie van gebruik, van de categorieen natuurlijke personen en groepen die naar verwachting gevolgen ondervinden, van de specifieke risico's op schade waarbij rekening wordt gehouden met de door de aanbieder op grond van artikel 13 verstrekte informatie, van de uitvoering van maatregelen voor menselijk toezicht overeenkomstig de gebruiksaanwijzing, en van de maatregelen bij het intreden van die risico's. Lid 2 bepaalt dat de verplichting van toepassing is op het eerste gebruik, dat in soortgelijke gevallen eerder uitgevoerde effectbeoordelingen of bestaande effectbeoordelingen van de aanbieder kunnen worden gebruikt, en dat de gebruiksverantwoordelijke die tijdens het gebruik ziet dat een van de in lid 1 vermelde elementen is gewijzigd of niet langer actueel is, de nodige maatregelen neemt om de informatie te actualiseren. Lid 3 bepaalt dat de resultaten met het ingevulde sjabloon aan de markttoezichtautoriteit worden gemeld en dat in het in artikel 46, lid 1, bedoelde geval vrijstelling van die kennisgevingsplicht kan gelden.
Wij lezen artikel 27 zo dat een politiedienst als publiekrechtelijk orgaan onder lid 1 valt en dat de beoordeling niet aan het eerste gebruik blijft hangen: hertrainen op nieuwere opsporingsgegevens of uitbreiden naar een tweede regio raakt de elementen van lid 1 en vraagt in onze lezing om actualisering van het dossier. Bij dat hertrainen speelt bovendien een vraag die artikel 27 zelf niet beantwoordt, namelijk of die ingreep zo ver gaat dat zij een substantiele wijziging is en u op grond van artikel 25 zelf als aanbieder wordt aangemerkt. Houd daarnaast in de gaten dat de uitzondering van lid 3 in onze lezing over de kennisgeving gaat en niet over de beoordeling zelf. Begin ten slotte pas aan die beoordeling nadat u hebt vastgesteld dat de inzet als zodanig is toegestaan, want artikel 5 sluit bepaalde voorspellende toepassingen in de opsporing uit.
Selectie bij de inschrijving van studenten: een DPIA is nog geen FRIA
Een hogeschool laat een AI-systeem de aanmeldingen voor een beroepsopleiding rangschikken en gebruikt daarbij de toetsresultaten van eerdere studenten om die rangorde te ijken. Voor deze verwerking ligt er al een gegevensbeschermingseffectbeoordeling. De vraag die de school stelt is of daarmee ook de grondrechtenkant van de inschrijving is afgedekt.
Artikel 27, lid 1 bepaalt dat gebruiksverantwoordelijken die publiekrechtelijke organen zijn of particuliere entiteiten die openbare diensten verlenen, en gebruiksverantwoordelijken van hoog-risico AI-systemen als bedoeld in bijlage III, punt 5, b) en c), voor de ingebruikname van een hoog-risico AI-systeem als bedoeld in artikel 6, lid 2 een beoordeling uitvoeren van de gevolgen voor de grondrechten, met uitzondering van systemen die bedoeld zijn om te worden gebruikt op het in punt 2 van bijlage III vermelde gebied. Die beoordeling bestaat uit een beschrijving van de processen waarin het systeem overeenkomstig het beoogde doel wordt gebruikt, van de periode en de frequentie van gebruik, van de categorieen natuurlijke personen en groepen die naar verwachting gevolgen ondervinden, van de specifieke risico's op schade voor die categorieen, van de uitvoering van maatregelen voor menselijk toezicht en van de maatregelen bij het intreden van die risico's, met inbegrip van de regelingen voor interne governance en klachtenregelingen. Lid 2 bepaalt dat de verplichting van toepassing is op het eerste gebruik, dat de gebruiksverantwoordelijke in soortgelijke gevallen eerder uitgevoerde effectbeoordelingen of bestaande effectbeoordelingen van de aanbieder kan gebruiken, en dat de gebruiksverantwoordelijke die tijdens het gebruik ziet dat een van de in lid 1 vermelde elementen is gewijzigd of niet langer actueel is, de nodige maatregelen neemt om de informatie te actualiseren. Lid 4 bepaalt dat wanneer een van de verplichtingen uit dit artikel al is nagekomen door de gegevensbeschermingseffectbeoordeling op grond van artikel 35 van Verordening (EU) 2016/679 of artikel 27 van Richtlijn (EU) 2016/680, de beoordeling van lid 1 een aanvulling vormt op die gegevensbeschermingseffectbeoordeling.
Wij lezen artikel 27 zo dat de onderwijsinstelling die deze selectie zelf inzet hier de gebruiksverantwoordelijke is, maar daarmee staat de plicht nog niet vast. Lid 1 wijst publiekrechtelijke organen aan en particuliere entiteiten die openbare diensten verlenen, en of een bekostigde dan wel een private hogeschool onder een van die twee omschrijvingen valt, is de vraag die u eerst moet beantwoorden. Valt zij eronder, dan is een bestaande gegevensbeschermingseffectbeoordeling in onze lezing het vertrekpunt en niet het sluitstuk: lid 4 laat de grondrechtenbeoordeling ernaast staan, en sinds Verordening (EU) 2026/1744 mag zij relevante delen daarvan overnemen of daarnaar verwijzen, zodat de vraag vooral is welke onderdelen van lid 1 nog ontbreken. Voor u betekent dat vastleggen welke groepen studenten geraakt kunnen worden, hoe de toelatingscommissie of de docent een uitkomst kan corrigeren en waar een afgewezen aanmelder met een klacht terechtkan. Verandert de selectieregel of het toetsonderdeel waarop de rangorde steunt, dan is dat in onze lezing het moment om het dossier bij te werken, en niet het begin van het volgende studiejaar.
Zorgverzekeraar met AI voor risicobeoordeling: publiek of privaat maakt niet uit
Een zorgverzekeraar gebruikt AI voor risicobeoordeling en prijsstelling bij zorg- en levensverzekeringen. De vraag is of dit onder punt 5(c) van Bijlage III valt, en daarmee of de FRIA-plicht van artikel 27 in beeld komt.
De ontwerprichtsnoeren van de Commissie van 19 mei 2026 stellen dat de zorg- en levensverzekering van punt 5(c) zowel privaat als publiekrechtelijk kan zijn: ook een publiekrechtelijke zorgverzekeraar valt eronder zolang het systeem is bedoeld voor risicobeoordeling of prijsstelling ten aanzien van natuurlijke personen. Private zorgverzekering geldt als essentiele private dienst, ook in een lidstaat met een publiek zorgstelsel. Anders dan punt 5(b) kent punt 5(c) geen uitzondering voor fraudedetectie. Het document is een consultatieversie: niet bindend en nog niet definitief.
Ontwerprichtsnoeren classificatie hoog-risico AI, 19 mei 2026, bijlage over Bijlage III, randnummers (319) tot en met (321)
Voor de FRIA-vraag telt punt 5(c) dubbel: het maakt het systeem hoog risico en het maakt u als gebruiksverantwoordelijke tot een van de partijen die artikel 27 aanwijst. Een publiekrechtelijke vorm of een publiek zorgstelsel in uw lidstaat verandert daar niets aan. Reken uzelf ook niet rijk met de fraudedetectie-uitzondering van punt 5(b): die geldt hier niet, en een fraudefunctie naast risicobeoordeling haalt het systeem er niet uit.
Weersimulatie waarin machine learning natuurkundige processen benadert
Een meteorologisch instituut draait natuurkundige weermodellen en zet machine learning in om complexe atmosferische processen zoals wolkenmicrofysica en turbulentie te benaderen. De geschatte waarden gaan vervolgens als invoer het gevestigde natuurkundige model in, dat de eigenlijke voorspelling doet.
Dat uw model uit invoer kan afleiden, brengt het niet vanzelf binnen de definitie: de richtsnoeren motiveren de uitsluiting van zulke versnellende systemen juist met het feit dat zij de basale gegevensverwerking niet overstijgen.
Het historische gemiddelde als voorspelling
Een vermogensbeheerder bouwt een eenvoudig referentiemodel dat de toekomstige koers voorspelt door steeds het historische gemiddelde te nemen, om te toetsen of een geavanceerder model werkelijk waarde toevoegt. Een weerdienst doet hetzelfde door de temperatuur van morgen te voorspellen met het gemiddelde van vorige week.
Een eenvoudig referentiemodel dat u naast een geavanceerder model zet, valt op zijn prestaties buiten de definitie, maar dat oordeel zegt niets over het geavanceerdere model, dat u apart moet beoordelen.
Drie kennisniveaus en interne vakscholen bij een verzekeraar
Generali biedt alle medewerkers basiscursussen aan over wat AI is en hoe de groep het gebruikt, verdiepende modules voor wie AI-systemen dagelijks gebruikt, en gevorderde sessies met externe experts voor wie ze bouwt of onderhoudt. Daarnaast bestaan interne vakscholen voor rollen als data scientist, actuaris en accountant, opgezet met universiteiten en onderzoeksinstellingen.
Hang gelaagde AI-scholing aan een bestaand opleidingsprogramma en leerplatform, zodat u niveaus en doelgroepen kunt uitbreiden zonder eerst een nieuwe leerinfrastructuur te moeten bouwen.
Gepersonaliseerde reclame is niet vanzelf verboden manipulatie
Een adverteerder gebruikt AI om advertenties af te stemmen op de voorkeuren van gebruikers. De vraag is of dat het manipulatieverbod raakt.
Personalisatie blijft buiten het verbod zolang u transparant bent en keuzevrijheid respecteert; toets uw advertentietechniek daarom aan de AVG, het consumentenrecht en de DSA in plaats van aan te nemen dat reclame altijd mag.
Gezichtsherkenningsbedrijf bouwt databank uit sociale media
Een softwarebedrijf laat een geautomatiseerde scraper het internet afzoeken naar afbeeldingen met menselijke gezichten op sociale media, slaat die op met bron-URL, geolocatie en soms namen, en zet de gezichtskenmerken om in wiskundige representaties waarmee een geuploade foto kan worden vergeleken.
Dat beelden openbaar op sociale media staan betekent geen toestemming, en het onderscheid zit in de gerichtheid: ongericht verzamelen voor een database waarmee gezichten vergeleken kunnen worden blijft verboden, ook stapsgewijs.
AI-geletterdheid in werving en onboarding bij een verzekeraar
Gjensidige Forsikring geeft alle medewerkers een verplichte e-learning als basisniveau en bouwt daarop rolgerichte verdieping: analisten krijgen modelrisico en datagovernance, medewerkers in schadebehandeling krijgen training over de systemen die zij zelf bedienen. Waar relevant wordt AI-geletterdheid al bij de werving getoetst en maakt training over AI-systemen deel uit van de onboarding.
Bepaal wie u opleidt aan de hand van de tekst die het document citeert: artikel 4 noemt naast het eigen personeel ook iedereen die de systemen namens u gebruikt.
Helpdeskchatbot van een webshop moet zich melden
Een webshop zet een AI-chatbot in voor vragen over bestellingen, bezorging en retouren. De bot schrijft vloeiende volzinnen, draagt een profielfoto van een medewerker en nergens staat dat er geen mens meeleest.
Rekent u niet op de uitzondering voor evidente AI, want hoe menselijker uw klantenbot oogt, hoe eerder u een expliciete melding bij de eerste beurt moet inbouwen in plaats van alleen in de voorwaarden.
Dossierverwerking bij inschrijvingen van een onderwijsinstelling
Een onderwijsinstelling gebruikt AI voor dossierbehandeling bij aanmeldingen: indexeren, zoeken, tekst- en spraakverwerking, vertaling van meegestuurde documenten, en het uittrekken, omzetten en ordenen van de verzamelde gegevens tot een bruikbaar formaat.
Indexeren, zoeken, vertalen en herordenen van aanmeldingsdossiers blijft voorbereidend werk, zolang het systeem het inhoudelijke oordeel over de aanmelding volledig bij de instelling laat.
Landbouw: AI-systeem dat bepaalt waar chemicalien worden gespoten
Een AI-systeem bepaalt welke delen van landbouwgrond met chemicalien worden bespoten. Het beoogde doel dat de aanbieder eraan geeft is het optimaliseren van het gebruik van chemicalien.
De ontwerprichtsnoeren van de Commissie van 19 mei 2026 behandelen dit geval bij de vraag of AI als veiligheidscomponent onder de productwetgeving van Bijlage I valt. Het document is een consultatieversie: niet bindend en nog niet definitief.
Ontwerprichtsnoeren classificatie hoog-risico AI, 19 mei 2026, bijlage over Bijlage I en productwetgeving
Beperk uw faalanalyse niet tot het product zelf maar betrek de omgeving waarin het werkt, want personen die zich in de buurt bevinden bepalen mede of een storing gevaar oplevert.
Landbouw: AI voor opbrengstvoorspelling en irrigatieoptimalisatie
Een AI-systeem is geintegreerd in een drone of robot en wordt gebruikt voor agronomische doeleinden zoals het voorspellen van de opbrengst of het optimaliseren van irrigatie.
Leg per toepassing vast waarom een storing in uw opstelling geen gevaar oplevert, want dezelfde agronomische functie kan in een ander productontwerp wel een veiligheidscomponent worden.
Systeem dat een menselijk besluit of ontwerp toetst en een wezenlijk andere oplossing geeft
Een AI-systeem controleert een besluit, plan of constructie die door een mens is gemaakt en levert vervolgens een wezenlijk andere oplossing aan.
Vraag uzelf af of uw systeem het menselijke werk verfijnt of vervangt, want een wezenlijk andere oplossing aanreiken is geen verbetering en sluit een beroep op artikel 6, lid 3, onder b, uit.
Witwasdetectie door een accountantskantoor onder eigen wettelijke plicht
Een accountantskantoor zet een AI-systeem in dat witwassen detecteert, om te voldoen aan zijn eigen verplichtingen op grond van de Europese antiwitwaswetgeving.
Ga na of u een eigen wettelijke plicht uitvoert of een taak van een overheidsinstantie overneemt, want alleen in het tweede geval handelt u namens die instantie en komt het rechtshandhavingsregime in beeld.
ATEX: AI-systeem dat gasconcentraties bewaakt en afschakelt
Apparatuur voor plaatsen met ontploffingsgevaar bevat een AI-systeem dat bedoeld is om gasconcentraties te bewaken en bij overschrijding een afschakeling te commanderen.
Zodra u een systeem aanbiedt dat een gevaarlijke waarde bewaakt en zelf een ingreep commandeert, volgt de veiligheidsfunctie uit uw eigen beoogde doel en niet uit hoe betrouwbaar het systeem presteert.
Chatbot die feitelijke vragen van een uitkeringsbehandelaar beantwoordt
Een chatbot beantwoordt feitelijke vragen van een behandelaar over de beoordeling van een aanvraag voor zorgtoeslagen of zorgvoorzieningen, bijvoorbeeld over de leeftijd van de aanvrager. De behandelaar kan de aanvraag toe- of afwijzen op basis van die antwoorden.
Een chatbot die uitsluitend bestaande feiten gestructureerd teruggeeft valt onder de uitzondering, maar zodra hij juridische vragen per dossier beantwoordt, stuurt hij het besluit en is hij hoog risico.
Kredietwaardigheid van ondernemingen op basis van bedrijfscijfers
Een aanbieder ontwikkelt een systeem dat de kredietwaardigheid van ondernemingen beoordeelt aan de hand van bedrijfsgegevens, balansen en jaarrekeningen. In een variant wordt de eigenaar van een rechtspersoon beoordeeld ter dekking van een bedrijfslening.
Bepaal vooraf of natuurlijke personen tot uw beoogde doel behoren, want een systeem dat ook hun persoonlijke financien beoordeelt valt in zijn geheel binnen punt 5(b), ongeacht de zakelijke hoofdmoot.
Kredietwaardigheid van bedrijven op basis van balans en jaarrekening
Een aanbieder ontwikkelt een AI-systeem dat de kredietwaardigheid van bedrijven beoordeelt aan de hand van bedrijfsgegevens, balansen en jaarrekeningen. Ook de situatie waarin de eigenaar van een rechtspersoon wordt beoordeeld als dekking voor een bedrijfslening komt aan de orde.
Een beoordeling blijft zakelijk zolang het krediet aan de onderneming toekomt, dus ook de eigenaar die een bedrijfslening dekt maakt uw systeem niet tot een beoordeling van een natuurlijke persoon.
Kredietscore van een ondernemer op basis van uitsluitend bedrijfsgegevens
Een aanbieder ontwikkelt een AI-systeem dat de kredietscore vaststelt van de eigenaar van een kleine onderneming of van een bedrijf dat geen rechtspersoon is. Het systeem gebruikt daarbij uitsluitend zakelijke of bedrijfsgegevens.
Beperk uw systeem aantoonbaar tot zakelijke gegevens als u buiten punt 5(b) wilt blijven, want zodra het ook de persoonlijke financien van de ondernemer betrekt, beoordeelt u een natuurlijke persoon.
Douanerisicoanalyse op goederen aan de buitengrens
Een AI-systeem wordt door douaneautoriteiten gebruikt om het risico te beoordelen dat goederen die de EU binnenkomen niet voldoen aan de wetgeving die aan de grens van toepassing is, op basis van informatie over de betrokken marktdeelnemers, zoals containernummer, omschrijving van de goederen, routering, vervoer en betaalmethode.
Bepaal waar uw risicomodel zich werkelijk op richt, want gaat het om zendingen en goederenstromen en niet om persoonlijke kenmerken van mensen, dan is er geen profilering die de vrijstelling blokkeert.
AI die kandidaten helpt hun cv af te stemmen op een vacature
Het systeem analyseert het cv van de kandidaat samen met de door de kandidaat aangeleverde vacaturetekst en beveelt wijzigingen aan om de kans op een uitnodiging te vergroten. Die aanbevelingen worden uitsluitend met de kandidaat gedeeld.
Wie de tool start bepaalt hier de uitkomst, want een hulpmiddel dat de kandidaat zelf inzet en waarvan het resultaat alleen bij hem terechtkomt, valt buiten het wervingsgebruik.
Onvolledige formulieren signaleren en terugsturen naar de aanvrager
Een AI-systeem detecteert en signaleert onvolledig ingevulde formulieren, zodat die kunnen worden teruggestuurd naar de aanvrager om ze correct aan te vullen.
Een signaleringsfunctie die alleen constateert dat gegevens ontbreken en het stuk terugstuurt, kunt u als nauwe procedurele taak behandelen zolang zij niets zegt over de inhoud of de kwaliteit van de aanvraag.
Gastoestellen: AI dat de verbrandingsefficientie optimaliseert
Een AI-systeem optimaliseert de verbrandingsefficientie in een gasverbrandingstoestel voor huishoudelijk gebruik. Het beoogde doel is energie-efficientie.
Of een efficiencysysteem veiligheidscomponent is, hangt af van het productontwerp: leidt een storing tot brand, explosie of koolmonoxide, dan telt het mee, blijft het bij een hogere energierekening dan niet.
Retrospectieve audit van wervingspatronen op geanonimiseerde data
Een systeem controleert afgeronde wervingsbeslissingen door geanonimiseerde wervingsdata te analyseren, waaronder cv-scores, interviewnotities en aannameresultaten, en gebruikt statistische modellering om mogelijke vertekening of inconsistenties op te sporen. Het speelt geen rol in lopende werving en beoordeelt geen identificeerbare recruiters of sollicitanten.
Anonimiseer de data en houd de analyse volledig retrospectief, dan kunt u wervingspatronen op vertekening onderzoeken zonder dat het systeem als hoog risico wordt aangemerkt.
Het systeem coördineert afspraken met sollicitanten door agenda's en opgegeven beschikbaarheid te combineren, stelt tijdvakken voor op basis van logistieke beperkingen zoals tijdzones en het maximumaantal gesprekken per dag, verstuurt herinneringen, en verwerkt toegankelijkheidswensen zoals gebarentolk, langere gespreksduur of alternatieve communicatievormen.
Zuiver logistieke ondersteuning blijft buiten de zware verplichtingen, mits uw planningstool geen enkele beoordeling initieert of beinvloedt en toegankelijkheidswensen alleen praktisch verwerkt.
Systeem dat wetsartikelen en interne richtlijnen aanreikt bij besluiten over uitkeringen
Een AI-systeem wordt gebruikt bij het beoordelen van gegevens die relevant zijn voor een besluit, bijvoorbeeld over publieke uitkeringen, en geeft de behandelaar verwijzingen naar de relevante wettelijke bepalingen, informatie over de bevoegde instantie en eventueel bestaande interne richtlijnen die relevant zijn voor het besluitvormingsproces.
Algemene verwijzingen naar wetgeving en interne richtlijnen blijven voorbereidend, maar zodra uw systeem het concrete dossier analyseert of een aanbeveling per zaak geeft, verliest u die kwalificatie.
Liften: AI-systeem dat deursluiting en obstakeldetectie regelt
Een AI-systeem in een lift regelt de timing van het sluiten van de deuren en de detectie van obstakels. Het beoogde doel dat de aanbieder eraan geeft is een efficiente liftwerking, niet veiligheid.
Noemt u efficiency als doel, dan blijft de tweede route open: kan een storing iemand verwonden, dan is het systeem alsnog veiligheidscomponent, dus laat uw doelomschrijving niet de eindconclusie zijn.
Machines: camerasysteem dat mensen in een robotcel detecteert
Een op AI gebaseerd computervisiesysteem detecteert de aanwezigheid van een mens in een robotcel en activeert een veilige stop of een snelheidsreductie. Het beoogde doel dat de aanbieder eraan geeft is het voorkomen van letsel.
Legt u in de gebruiksaanwijzing, technische documentatie of het verkoopmateriaal vast dat een systeem letsel moet voorkomen, dan bepaalt u daarmee zelf dat het een veiligheidsfunctie vervult.
Patroonanalyse op afgeronde rechtmatigheidstoetsen in de publieke sector
Een AI-systeem analyseert eerder afgeronde rechtmatigheidstoetsen van ambtenaren om besluitvormingspatronen of afwijkingen te detecteren, voor kwaliteitsborging en rapportage. Het systeem stelt geen uitkomsten voor in lopende zaken en beoordeelt niet het functioneren van medewerkers, bijvoorbeeld in de jaarlijkse beoordelingscyclus.
Patroonanalyse blijft binnen de uitzondering zolang zij achteraf plaatsvindt, geen uitkomst in lopende zaken voorstelt en niet het functioneren van uw medewerkers beoordeelt.
Drukapparatuur: AI-systeem dat drukopbouw voorspelt en ingrijpt
Een AI-systeem in drukapparatuur is bedoeld om een ongecontroleerde drukopbouw te voorspellen en beschermende maatregelen in werking te stellen, bijvoorbeeld door een afschakeling te activeren die is gekoppeld aan veiligheidsappendages.
Een model dat op zichzelf alleen voorspelt vervult toch een veiligheidsfunctie zodra die voorspelling een beschermende maatregel in werking stelt, dus beoordeel wat er met de uitvoer gebeurt en niet alleen wat het model berekent.
Schrijfassistent die afgeronde promotiebeoordelingen aanscherpt
Een adviesbureau gebruikt een AI-schrijfassistent om promotierapporten van managers te verfijnen nadat de beoordelingen volledig zijn afgerond. Managers hebben de aanbeveling, de motivering en de scores al vastgelegd; het systeem verbetert de helderheid van de formulering, bewaakt consistentie met de huisstijl en signaleert mogelijk vertekende woordkeuze, waarna de manager de aangepaste tekst verplicht nakijkt.
Laat de manager de aanbeveling, de motivering en de scores eerst volledig vastleggen en beperk het systeem tot formulering en consistentie, dan blijft het een verbetering achteraf.
Kwaliteitscontrole op afgerond menselijk werk zonder het oordeel te vervangen
Drie soorten hulpsystemen: systemen die fouten of tegenstrijdigheden signaleren in afgerond menselijk werk als kwaliteitscontrole, systemen die conclusies koppelen aan bewijsstukken om de traceerbaarheid van een besluit te versterken zonder het menselijk oordeel te vervangen, en systemen die door mensen gevalideerde inhoud omzetten voor interoperabiliteit of toegankelijkheid.
Houd uw hulpsysteem strikt na het menselijke besluit en zonder eigen oordeel over de uitkomst, dan blijft het een verbetering die de rechten en de positie van betrokkenen ongemoeid laat.
Spoor: AI-systeem in een trein dat snelheidslimieten bewaakt
Een AI-systeem in een trein is bedoeld om snelheidslimieten te bewaken en botsingen en ontsporingen te voorkomen.
Werkt u in een sector met een eigen veiligheidsregime, houd dan aan dat uitsluitend de definitie uit artikel 3, punt 14 van de AI-verordening telt en niet de sectorale omschrijving van veiligheidscomponent.
Afwijkingsdetectie in werving die de recruiters zelf beoordeelt
Een systeem signaleert afwijkingen van eerdere wervingspatronen vóórdat de werving is afgerond, om inconsistenties met het bedrijfsbeleid op te sporen, en beoordeelt daarbij de persoonlijke kenmerken van de recruiters die de gesprekken voeren.
Wilt u de uitzondering behouden, richt de afwijkingsanalyse dan uitsluitend op de besluiten zelf en niet op de personen die ze namen, en laat haar pas draaien nadat de werving is afgerond.
AI-achtergrondonderzoek met risicoscores voor sollicitanten
Het systeem bundelt officiële registers, arbeidsverleden, sociale netwerken en waar toegestaan financiële gegevens, plus open bronnen, en levert samengestelde risicoscores of categorieën als laag, midden en hoog risico met signalen zoals onverklaarde hiaten in het cv. In hoogvolume-werving worden kandidaten met een hoog risico al vóór dossierbeoordeling terzijde gelegd.
Achtergrondonderzoek met samengestelde risicoscores is profilering, en dat sluit elke uitzondering uit, ook wanneer u formeel een menselijke beoordeling in het proces heeft ingebouwd.
Afwijkingsdetectie in werving die ook de recruiters zelf beoordeelt
Een AI-systeem wordt ingezet bij de werving van medewerkers. Het identificeert afwijkingen van eerdere wervingsbesluiten om mogelijke inconsistenties met het wervingsbeleid op te sporen, en beoordeelt daarbij ook de persoonlijke kenmerken van de recruiters die de sollicitatiegesprekken voeren. Het systeem draait voordat de werving is afgerond.
Een systeem dat afwijkingen in besluitvorming opspoort kan onder de uitzondering vallen, maar zodra het daarbij persoonlijke kenmerken van uw eigen medewerkers weegt, is er profilering en vervalt die route.
Geautomatiseerde schooltoewijzing door gemeenten
Gemeenten of regionale autoriteiten wijzen leerlingen automatisch toe aan openbare scholen op basis van gestructureerde gegevens zoals thuisadres, de grenzen van voedingsgebieden en beschikbare capaciteit, waarbij ook aanwezigheid van broers en zussen en de status van ouders meewegen om gezinnen bij elkaar te houden of reisafstand te beperken.
Ook een toewijzing op ogenschijnlijk objectieve gegevens als adres en capaciteit geldt hier als profilering, zodat u zich als overheid niet op de uitzondering van artikel 6, lid 3, kunt beroepen.
AI die antwoorden van sollicitanten scoort en rangschikt
Een systeem beoordeelt geschreven of gesproken antwoorden van sollicitanten in een online assessment, kent op basis van taalkundige en inhoudelijke criteria een cijfermatige score toe en genereert daaruit een ranglijst die bepaalt wie wordt uitgenodigd voor het interview.
Zodra uw assessment antwoorden omzet in een cijfer en daarmee bepaalt wie op gesprek komt, vervult het systeem een kernbeoordeling en helpt geen enkele uitzondering u eruit.
Slimme thermostaat die comfort en energieverbruik optimaliseert
Een slimme thermostaat die onder de radioapparatuurregelgeving valt, leert de routines van het huishouden en optimaliseert de temperatuurinstellingen. Het beoogde doel is meer comfort en een lager energieverbruik.
Dat een product voor de consument of het huishouden bestemd is, sluit niets uit; onderbouw dat een storing hooguit ongemak of een hogere energierekening geeft, en let extra op kinderen en kwetsbare gebruikers.
Sorteren van aanmeldingen voor school of universiteit op niveau
Een AI-systeem sorteert binnenkomende aanmeldingen voor toelating tot een school of universiteit op het cijfer of het onderwijsniveau waarvoor is aangemeld, en plaatst ze in vooraf bepaalde categorieën zoals basisonderwijs, voortgezet onderwijs of specifieke leerjaren, op basis van informatie in de aanmelding.
Sorteren op een gegeven dat de aanvrager zelf heeft opgegeven blijft een nauwe procedurele taak, mits uw systeem daarbij geen oordeel velt over geschiktheid en geen toelatingsbesluit voorbereidt.
Speelgoed: AI dat muziek aanbeveelt in verbonden speelgoed
Een AI-systeem in verbonden speelgoed doet muziekaanbevelingen aan het kind dat ermee speelt.
Niet elk AI-onderdeel in een gereguleerd product telt mee; ontbreken zowel een veiligheidsbedoeling als een gevaarlijk faalgevolg, dan valt het onderdeel buiten het begrip veiligheidscomponent en buiten artikel 6, lid 1.
Speelgoed: fabrikant kiest interne controle op basis van normen
Een fabrikant van speelgoed met een AI-systeem als veiligheidscomponent past geharmoniseerde normen toe en kiest daarmee voor een conformiteitsbeoordelingsprocedure zonder betrokkenheid van een derde partij.
Kiest u met geharmoniseerde normen voor interne controle zonder derde partij, dan verandert dat uw procedure maar niet de indeling: het systeem blijft hoog-risico en de bijbehorende verplichtingen blijven staan.
Voertuigen: AI-systeem voor rijstrookassistentie
Een AI-systeem voor rijstrookassistentie in een voertuig. Het beoogde doel dat de aanbieder eraan geeft is het verbeteren van de gebruikerservaring.
Bij de faalroute weegt uw eigen doelomschrijving nauwelijks mee; onderbouw de beoordeling met de systeemarchitectuur, de faalwijzen en de gevolgen daarvan, want daar wordt naar gekeken.
Visumdossiers scannen, indelen en dubbele bijlagen markeren
Een systeem in migratie en grenstoezicht scant elk ingediend visumdossier, zet gescande documenten om in tekst voor indexering, plaatst stukken automatisch in vaste, vooraf bepaalde mappen zoals identiteitsdocumenten, reisschema, bewijsstukken en vertalingen, en herkent exacte dubbele bijlagen om die als duplicaat te markeren.
Ook wanneer uw dossierverwerking de uitzondering haalt, moet u de beoordeling vooraf vastleggen en het systeem registreren, zodat de toezichthouder uw keuze op elk moment kan controleren.
Visumdossiers scannen, indexeren en dubbele bijlagen markeren
Een AI-systeem in de context van migratie en grensbeheer scant ieder ingediend visumdossier, zet gescande documenten om in tekst voor indexering, plaatst stukken automatisch in vaste vooraf bepaalde mappen zoals identiteitsdocumenten, reisschema, bewijsstukken en vertalingen, en detecteert exacte dubbele bijlagen en markeert die als duplicaat.
Leg de grenzen van uw dossierverwerking hard vast, want de vrijstelling vervalt zodra het systeem stukken rangschikt, als nuttig of minder nuttig bestempelt, verbergt of een vervolgstap suggereert.
Bewustwording die uitmondt in een harde gebruiksregel
INECO, een groot Spaans ingenieursbedrijf dat voor overheden werkt aan spoor, luchthavens en digitalisering, hield in 2024 ruim twintig AI-trainingen met meer dan vierhonderd deelnemers en zette een AI Master Classroom op het intranet met korte modules, audio en ondertiteling. Nadat medewerkers bewust waren gemaakt van het risico op datalekken, beperkte de organisatie het gebruik van publieke taalmodellen en stapte zij over op een beveiligde chatbotoplossing.
Combineer korte online modules met echte sessies, want de Commissie beschrijft de verzamelde initiatieven als een mix van e-learningplatforms en trainingen op locatie in plaats van een vaste vorm.
Interne AI-assistent voor getrainde medewerkers hoeft geen melding
Een organisatie stelt een interne AI-assistent beschikbaar voor vragen over HR, inkoop, ICT en compliance. De assistent is alleen bereikbaar achter de eigen inlog en de medewerkers zijn getraind in het gebruik van AI.
De uitzondering steunt op een afgesloten en getraind publiek, dus leg vast wie toegang heeft en welke AI-training zij kregen, want zodra de assistent buiten die kring beschikbaar komt vervalt de vrijstelling.
Kredietreclame gericht op postcodes met lage inkomens
Een aanbieder van financiele producten gebruikt een voorspellend AI-model om reclame voor dure, risicovolle leningen te richten op mensen die in postcodegebieden met lage inkomens wonen en in geldnood zitten.
Stuurt u bewust op proxyvariabelen als postcode die samenvallen met een kwetsbare sociaaleconomische groep, dan geldt dat als uitbuiting, terwijl onbedoelde vertekening dat pas wordt zodra u die kent en niet corrigeert.
Kredietscore en fraudedetectie bij dezelfde bank
Een kredietverstrekker gebruikt een model dat particuliere aanvragers een score geeft waarop de acceptatiebeslissing rust. Datzelfde huis gebruikt daarnaast een apart model dat verdachte transacties markeert voor fraudeonderzoek.
Beoordeel elk model apart op zijn eigen beoogde doel, want een model dat de kredietwaardigheid van een natuurlijke persoon scoort is hoog risico, terwijl een model waarvan fraudedetectie de hoofdfunctie is daarbuiten valt.
Kredietscoring en telematicapremies blijven toegestaan
Een kredietverstrekker beoordeelt kredietwaardigheid op basis van inkomsten, uitgaven en andere financiele en economische omstandigheden. Een verzekeraar verhoogt de premie van een bestuurder die volgens telematicagegevens structureel te hard rijdt.
Scoren mag wanneer u alleen gegevens gebruikt die voor het doel relevant zijn en het gevolg proportioneel blijft, en sectorale regels die voorschrijven welke gegevens relevant zijn vormen daarbij uw sterkste onderbouwing.
Lichte finetuning maakt u geen modelaanbieder
Een bank finetunet een bestaand model voor algemene doeleinden op de eigen productdocumentatie en klantvragen, met een fractie van de oorspronkelijke rekenkracht, en bouwt daaromheen een klantenchatbot die zij onder eigen naam aanbiedt.
Blijft uw finetuning ver onder een derde van de oorspronkelijke rekenkracht, dan wordt u geen modelaanbieder, maar gelden voor u nog wel de plichten voor het AI-systeem dat u onder eigen naam aanbiedt.
Predictive policing op wijkniveau valt buiten het verbod
Een politiekorps gebruikt een AI-systeem dat op basis van eerdere criminaliteitscijfers per gebied, stratenkaarten en aanvullende informatie aangeeft waar de kans op bijvoorbeeld inbraken of steekincidenten hoger ligt, om te bepalen waar meer wordt gesurveilleerd.
Plaatsgebonden voorspellingen vallen buiten het verbod, maar alleen zolang de gebiedsscore geen bouwsteen wordt in het profiel van een persoon, want dan beoordeelt u alsnog individuen en verschuift het regime.
Logging bij aanmelding en toetsing: wat de hogeschool zelf in handen houdt
Een hogeschool gebruikt een ingekocht AI-systeem dat de aanmelding van studenten rangschikt en daarnaast signalen afgeeft bij digitale toetsing. De logs staan in de omgeving van de leverancier, die ze op verzoek aanlevert. Het onderwijsteam vraagt zich af of de school daarmee klaar is of dat er een eigen bewaarplicht overblijft.
Artikel 12 lid 1 vereist dat een AI-systeem met een hoog risico technisch zo is vormgegeven dat gebeurtenissen gedurende de levenscyclus automatisch worden geregistreerd, en lid 2 verbindt die registratie aan een niveau van traceerbaarheid dat passend is voor het beoogde doel van het systeem. Artikel 26 lid 6 bepaalt dat gebruiksverantwoordelijken de automatisch gegenereerde logs bewaren voor zover die logs onder hun controle vallen, gedurende een periode die passend is voor het beoogde doel of ten minste zes maanden, tenzij toepasselijk Unierecht of nationaal recht anders bepaalt, meer in het bijzonder het Unierecht over de bescherming van persoonsgegevens. Artikel 19 lid 1 legt een overeenkomstige bewaarplicht op aan aanbieders voor de door hun systemen gegenereerde logs die onder hun controle vallen, eveneens voor ten minste zes maanden.
Artikel 12 lid 1 en 2, artikel 19 lid 1 en artikel 26 lid 6
Onze lezing is dat het hosten van de logs door de leverancier de school niet zonder meer buiten artikel 26 lid 6 plaatst: bepalend is of de logs onder haar controle vallen. De verordening definieert dat begrip niet, en in onze lezing is de serverlocatie op zichzelf niet doorslaggevend; het gaat om de vraag of u feitelijk en contractueel over die logs kunt beschikken, en die vraag moet u per inkoop beantwoorden. Spreek daarom bij inkoop af dat de hogeschool de logs kan opvragen, exporteren en gedurende de gekozen termijn zelf kan bewaren, en leg vast welke gebeurtenissen rond aanmelding en toetsing daaronder vallen. Betrek daarbij meteen de gegevensbescherming, want dezelfde bepaling laat toe dat ander Unierecht of nationaal recht de bewaartermijn juist begrenst.
Logging op de productielijn: welke logs bewaart de fabrikant en welke de fabriek
Een fabrikant levert een AI-systeem dat als veiligheidscomponent meedraait in de machines van een productielijn en tegelijk de kwaliteitscontrole aanstuurt. De fabriek die de lijn draait, bewaart alleen de meldingen die in de lokale besturing zichtbaar zijn; de rest van de registratie loopt naar de omgeving van de leverancier. De vraag is wie welke logs moet bewaren wanneer achteraf moet worden gereconstrueerd waarom de lijn is stilgelegd.
Artikel 12 lid 1 bepaalt dat AI-systemen met een hoog risico dusdanig technisch zijn vormgegeven dat gebeurtenissen gedurende de levenscyclus van het systeem automatisch worden geregistreerd. Volgens lid 2 maken die loggingfuncties het mogelijk gebeurtenissen te registreren die relevant zijn voor de identificatie van situaties die ertoe kunnen leiden dat het systeem een risico vormt in de zin van artikel 79 lid 1 of dat er een substantiële wijziging optreedt, voor de facilitering van de monitoring na het in de handel brengen bedoeld in artikel 72, en voor de monitoring van de werking van de in artikel 26 lid 5 bedoelde AI-systemen met een hoog risico. Artikel 19 lid 1 verplicht aanbieders die automatisch gegenereerde logs te bewaren voor zover zij onder hun controle vallen, gedurende een periode die passend is voor het beoogde doel van het systeem, van ten minste zes maanden, tenzij toepasselijk Unierecht of nationaal recht anders bepaalt. Artikel 26 lid 6 legt een overeenkomstige bewaarplicht op aan gebruiksverantwoordelijken voor de logs die onder hun controle vallen, met dezelfde ondergrens van zes maanden.
Wij lezen artikel 19 en artikel 26 lid 6 zo dat de fabrikant, die hier als aanbieder optreedt, en de fabriek als gebruiksverantwoordelijke ieder een eigen bewaarplicht houden voor de logs die onder hun controle vallen. De verordening omschrijft niet wanneer logs onder uw controle vallen, en de plek waar de registratie technisch landt is in onze lezing niet vanzelf beslissend; die open vraag moet u per systeem beantwoorden. Voor een productielijn betekent dat in onze lezing dat u vastlegt welke gebeurtenissen in de machinebesturing blijven en welke naar de leverancier gaan, en dat u toegang tot dat tweede deel contractueel regelt voordat u het nodig heeft. Regelt u dat niet, dan loopt u het risico dat u een stilstand of een afkeuring in de kwaliteitscontrole achteraf niet meer kunt herleiden tot het gedrag van het systeem.
Logging bij taakverdeling op de werkvloer: bewijs over het systeem of dossier over de werknemer
Een werkgever zet een AI-systeem in dat op de werkvloer taken toewijst aan medewerkers en het functioneren samenvat ten behoeve van het beoordelingsgesprek. Personeelszaken wil weten welke registratie van die uitkomsten bewaard moet blijven wanneer een werknemer maanden later bezwaar maakt tegen een besluit over promotie.
Artikel 12 lid 1 vereist dat AI-systemen met een hoog risico dusdanig technisch zijn vormgegeven dat gebeurtenissen gedurende de levenscyclus automatisch worden geregistreerd. Lid 2, punt c, noemt als een van de doelen van die loggingfuncties de monitoring van de werking van systemen als bedoeld in artikel 26 lid 5, en dat lid verplicht gebruiksverantwoordelijken de werking te monitoren op basis van de gebruiksaanwijzing en in voorkomend geval de aanbieder in kennis te stellen overeenkomstig artikel 72. Artikel 26 lid 6 verplicht gebruiksverantwoordelijken de automatisch gegenereerde logs te bewaren voor zover die onder hun controle vallen, gedurende een periode die passend is voor het beoogde doel of ten minste zes maanden, tenzij toepasselijk Unierecht of nationaal recht anders bepaalt. Artikel 19 lid 1 bevat een overeenkomstige bewaarplicht voor aanbieders, met dezelfde ondergrens van zes maanden.
Artikel 12 lid 1 en lid 2, punt c, artikel 19 lid 1 en artikel 26 lid 5 en 6
Wij lezen artikel 12 lid 2 zo dat de loggingfuncties er in de eerste plaats zijn om risico's, substantiële wijzigingen en de werking van het systeem te kunnen volgen, en niet om individuele medewerkers scherper te beoordelen. Of die doelomschrijving ook begrenst waarvoor de bewaarde logs later mogen worden gebruikt, zegt artikel 12 niet: die grens moet u in onze lezing uit het gegevensbeschermingsrecht halen, waarnaar artikel 26 lid 6 zelf verwijst. Voor personeelszaken volgt daaruit een praktische lijn: bewaar wat nodig is om een uitkomst te kunnen herleiden en het toezicht van artikel 26 lid 5 waar te maken, en leg vooraf schriftelijk vast of dezelfde bestanden wel of niet als prestatieregistratie mogen dienen. Houd er daarbij rekening mee dat de ondergrens van zes maanden korter kan zijn dan de termijn waarbinnen een werknemer bezwaar maakt tegen een besluit over promotie; die bewijspositie regelt de verordening niet.
Een verzekeraar zet een getraind model in dat schadeclaims op complexiteit rangschikt. Na de uitrol leert het model niets meer bij; de leverancier hertraint alleen periodiek in een gecontroleerde release, zodat het gedrag tussen releases volledig stabiel is.
Zelflerend gedrag na uitrol is facultatief en geen uitsluitingsgrond, dus een bevroren model dat tussen releases volledig stabiel blijft ontkomt daarmee niet aan de definitie.
Een model met systeemrisico aanpassen trekt de zwaarste plichten naar u toe
Een downstreampartij past een bestaand model met systeemrisico zo ingrijpend aan dat de aanpassing boven de drempel uitkomt en publiceert het resultaat als eigen model.
Ligt de aanpassing van een model met systeemrisico boven de drempel, dan wordt uw resultaat verondersteld capaciteiten met grote impact te hebben, dus schat de rekenkracht vooraf en meld binnen twee weken bij de Commissie.
Aparte sessie over verboden praktijken voor het ontwikkelteam
Mural gaf in 2024 een verplichte AI-training aan alle medewerkers, met een afrondingspercentage van 93 procent, en organiseerde daarnaast een live interactieve sessie voor het AI-team specifiek over verboden praktijken en hoog-risicocategorieën. Voor dat team maakte het juridische team een visuele mindmap op een digitaal whiteboard, met sjablonen en directe verwijzingen naar de bepalingen.
Twee lagen naast elkaar: een basis voor iedereen en een verdieping voor het team dat de keuzes maakt. Die tweede laag is waar Artikel 4 zijn nut bewijst, want verboden praktijken en hoog-risicocategorieen zijn ontwerpvragen en geen bewustwordingsvragen. Het afrondingspercentage is daarbij geen doel op zich, maar het is wel het soort gegeven waarmee u later kunt laten zien dat de maatregel de organisatie ook echt heeft bereikt.
Navigatiesysteem in de auto: lichtere markering volstaat
Een autofabrikant bouwt een generatief AI-systeem in het navigatiesysteem dat gesproken en geschreven route-instructies opstelt. De uitvoer blijft binnen het voertuig en technische maatregelen voorkomen dat die uitvoer wordt geexporteerd of gedeeld.
De lichtere markering is voorwaardelijk, want zij geldt alleen zolang technische maatregelen aantoonbaar voorkomen dat de uitvoer het product verlaat, dus documenteer die maatregelen voordat u op deze route vertrouwt.
Eye-tracking bij online tentamens versus emotiedetectie
Een onderwijsinstelling gebruikt bij online tentamens software die de blikrichting en oogbewegingen van studenten volgt, om te zien of zij ongeoorloofd materiaal raadplegen.
Meten waar iemand kijkt is geen emotieherkenning, maar zodra u daar een gemoedstoestand als spanning of nervositeit uit afleidt valt hetzelfde systeem onder het verbod, dus begrens de functionaliteit expliciet.
Open source in naam, maar niet in de zin van de verordening
Drie aanbieders noemen hun model open source. De eerste licentie staat alleen niet-commercieel onderzoek toe. De tweede vraagt een aparte commerciele licentie zodra het aantal maandelijkse gebruikers boven een drempel komt. De derde geeft het model gratis weg, maar host het uitsluitend op het eigen platform waar bezoekers betaalde advertenties te zien krijgen.
Een gebruiksbeperking is niet vanzelf fataal: specifieke, proportionele en niet-discriminatoire veiligheidsbepalingen mag u opnemen, terwijl een drempel op maandelijkse gebruikers of een aparte commerciële licentie de licentie diskwalificeert.
Wat de opensource-uitzondering wel en niet dekt
Een onderzoeksgroep publiceert een model voor algemene doeleinden onder een vrije en opensourcelicentie en maakt de gewichten, de architectuur en de gebruiksinformatie openbaar. Het model heeft geen systeemrisico.
Een vrije en opensourcerelease zonder systeemrisico ontslaat u van de technische documentatie en van de vertegenwoordiger in de Unie, maar het auteursrechtbeleid en de openbare samenvatting van de trainingsinhoud blijven onverkort gelden.
Machine learning die alleen een bestaande optimalisatieberekening versnelt
Een netbeheerder laat een machine-learningmodel parameters benaderen in een klassieke optimalisatieberekening die op lineaire en logistische regressie is gebouwd. Het model verandert niets aan de beslisregels zelf, het maakt de al jaren gebruikte rekenmethode alleen sneller en goedkoper.
Als uw model uitsluitend een al jaren gevestigde rekenmethode sneller maakt en de beslisregels ongemoeid laat, leg dat dan vast, want juist die twee punten dragen de conclusie dat u buiten de definitie valt.
Politie traint een model bij voor opsporing: eerst de rolvraag, dan artikel 53
Een politiedienst traint een open general-purpose model bij op eigen dossiers uit lopende opsporingsonderzoeken, zodat rechercheurs sneller verbanden tussen verdachten en zaken zien. Het bijgetrainde model blijft binnen de dienst en wordt aan niemand anders beschikbaar gesteld. De vraag is of de dienst daarmee zelf aanbieder van een AI-model voor algemene doeleinden wordt, en dus onder artikel 53 valt.
Artikel 53 lid 1 verplicht aanbieders van AI-modellen voor algemene doeleinden tot vier dingen: de technische documentatie van het model opstellen en up-to-date houden, inclusief het trainings- en testproces en de evaluatieresultaten, met ten minste de informatie uit bijlage XI, zodat die op verzoek aan het AI-bureau en de nationale bevoegde autoriteiten kan worden verstrekt; informatie en documentatie opstellen, up-to-date houden en beschikbaar stellen voor aanbieders van AI-systemen die het model willen integreren, met ten minste de elementen uit bijlage XII; beleid opstellen ter naleving van het Unierecht inzake auteursrechten en naburige rechten; en een voldoende gedetailleerde samenvatting over de voor het trainen gebruikte content opstellen en openbaar maken volgens een door het AI-bureau verstrekt sjabloon. Artikel 53 lid 2 bepaalt dat de plichten onder a) en b) niet gelden voor aanbieders van modellen die worden vrijgegeven onder een vrije en opensource licentie die raadpleging, gebruik, wijziging en distributie mogelijk maakt en waarvan de parameters, met inbegrip van de wegingen, de informatie over de modelarchitectuur en de informatie over het gebruik openbaar worden gemaakt, en dat die uitzondering niet geldt voor modellen met systeemrisico's.
Bepaal eerst uw rol, want wie een extern model alleen gebruikt is daarmee nog geen modelaanbieder; artikel 53 zegt zelf niet wanneer een dienst die bijtraint die grens overschrijdt, en dat verdient een expliciet antwoord in plaats van een aanname. Aan artikel 53 gaat bovendien de vraag vooraf of uw bijgetrainde opsporingsmodel in de zin van de verordening in de handel is gebracht, en dat het model de dienst nooit verlaat beslist dat niet vanzelf: de richtsnoeren van de Commissie over de reikwijdte van de verplichtingen voor aanbieders van AI-modellen voor algemene doeleinden rekenen ook intern gebruik dat de rechten van natuurlijke personen raakt daartoe. Wij lezen lid 2 zo dat de opensource-uitzondering aan uw eigen model hangt en niet automatisch meeverhuist van het model waarvan u bent uitgegaan: publiceert u de wegingen en de architectuur van uw bijgetrainde model niet, wat in het strafrecht voor de hand ligt, dan kunt u zich in die lezing niet op de uitzondering beroepen, en de plichten onder c) en d) blijven hoe dan ook staan omdat lid 2 alleen a) en b) uitzondert. Leg daarom per versie vast wat u precies hebt gewijzigd, op welke data en met welk doel, want juist dat dossier bepaalt of u hier als gebruiker of als aanbieder staat.
Beoordeling van medewerkers: signalen van de werkvloer terug naar de aanbieder
Een aanbieder levert een systeem dat prestatiegegevens van werknemers samenvat en personeelszaken ondersteunt bij beslissingen over promotie. Na een jaar in gebruik blijkt dat afdelingen het anders inzetten dan bedoeld, en dat leidinggevenden de uitkomsten meenemen in het beoordelingsgesprek over functioneren. De vraag is wat de aanbieder daarvan hoort te weten.
Artikel 72 lid 1 verplicht aanbieders een systeem voor monitoring na het in de handel brengen vast te stellen en te documenteren, op een manier die evenredig is aan de aard van de AI-technologieen en de risico's van het AI-systeem met een hoog risico. Lid 2 vereist dat dat systeem actief en systematisch relevante data verzamelt, documenteert en analyseert, die door gebruiksverantwoordelijken kunnen zijn verstrekt of via andere bronnen kunnen zijn verzameld, over de prestaties gedurende de hele levensduur, en die de aanbieder in staat stellen na te gaan of het systeem blijvend voldoet aan de in hoofdstuk III, afdeling 2, vermelde voorschriften. Lid 3 bepaalt dat het systeem berust op een plan dat deel uitmaakt van de technische documentatie bedoeld in bijlage IV, en draagt de Commissie op een uitvoeringshandeling vast te stellen met gedetailleerde bepalingen voor een model voor dat plan en de lijst van elementen die erin moeten worden opgenomen; de verordening noemt daarvoor de datum 2 februari 2026.
Onze lezing is dat afwijkend gebruik op de werkvloer precies het soort praktijkdata is waar lid 2 op doelt, omdat het raakt aan het menselijk toezicht en het beoogde doel die in afdeling 2 zijn vastgelegd. Lid 3 verwijst naar een model van de Commissie waarvoor de verordening 2 februari 2026 als datum noemt; ga na of dat model inmiddels is vastgesteld en sluit er dan bij aan, want lid 4 verwijst er ook naar. Wij zouden de opzet van uw monitoring er intussen niet op laten wachten: welke gegevens u nodig hebt volgt al uit de eisen waaraan het systeem blijvend moet voldoen. Spreek daarom met de organisaties die het systeem gebruiken af langs welke weg klachten van werknemers en afwijkingen in beoordelingen bij u terechtkomen.
Proctoring bij tentamens: welke praktijkdata de hogeschool terugmeldt
Een leverancier biedt proctoringsoftware aan die tijdens tentamens signaleert wanneer een student mogelijk spiekt. Verschillende hogescholen gebruiken het systeem, elk met eigen toetsvormen en eigen studentenpopulaties. De leverancier wil weten welke praktijkdata hij na de uitrol moet blijven verzamelen, en van wie.
Artikel 72 lid 1 verplicht aanbieders een systeem voor monitoring na het in de handel brengen vast te stellen en te documenteren, evenredig aan de aard van de AI-technologieen en de risico's van het systeem. Lid 2 bepaalt dat dat systeem actief en systematisch relevante data verzamelt, documenteert en analyseert die door gebruiksverantwoordelijken kunnen zijn verstrekt of via andere bronnen kunnen zijn verzameld, over de prestaties van AI-systemen met een hoog risico gedurende hun hele levensduur, en die de aanbieder in staat stellen na te gaan of die systemen blijvend voldoen aan de in hoofdstuk III, afdeling 2, vermelde voorschriften. In voorkomend geval omvat de monitoring een analyse van de interactie met andere AI-systemen. Lid 3 bepaalt dat het systeem berust op een plan dat deel uitmaakt van de technische documentatie bedoeld in bijlage IV.
De verplichting ligt bij de aanbieder, maar de bruikbare signalen ontstaan in het onderwijs zelf: onterechte verdenkingen, klachten van studenten, verschillen tussen opleidingen en toetsvormen. Onze lezing is dat lid 2 toestaat dat gebruiksverantwoordelijken die data verstrekken, maar de plicht om ze te verzamelen en te analyseren bij de aanbieder laat. Wat het artikel niet regelt is langs welke weg u ze krijgt, en of de hogescholen tot aanlevering gehouden zijn; dat is een vraag die u met hen moet beleggen en niet uit artikel 72 kunt afleiden. Wij zouden die route daarom vastleggen voordat het systeem live gaat, en in het plan ook opnemen hoe u prestaties per toetsvorm en per groep uitsplitst, omdat een gemiddelde over alle scholen precies het patroon verbergt dat u zoekt.
Veiligheidscomponent op de productielijn: de fabrikant blijft na oplevering meekijken
Een fabrikant levert een AI-veiligheidscomponent die op een productielijn de bewegingen van machines stillegt zodra iemand te dicht bij de robot komt. Het onderdeel valt al onder de productwetgeving voor machines, en de fabrikant voert daarvoor kwaliteitscontrole en incidentopvolging uit. De vraag is wat artikel 72 daar nog bovenop vraagt.
Artikel 72 lid 1 verplicht aanbieders een systeem voor monitoring na het in de handel brengen vast te stellen en te documenteren, op een manier die evenredig is aan de aard van de AI-technologieen en de risico's van het AI-systeem met een hoog risico. Lid 3 bepaalt dat dat systeem berust op een plan voor monitoring na het in de handel brengen, en dat dit plan deel uitmaakt van de technische documentatie bedoeld in bijlage IV. Lid 4 geeft aanbieders van hoog-risico AI-systemen die onder de in afdeling A van bijlage I vermelde harmonisatiewetgeving van de Unie vallen en waarvoor krachtens die wetgeving al een systeem en een plan voor monitoring na het in de handel brengen zijn vastgesteld, de keuze om de noodzakelijke in de leden 1, 2 en 3 beschreven elementen daarin te integreren, met gebruikmaking van het in lid 3 bedoelde model, mits dat een gelijkwaardig beschermingsniveau garandeert.
Onze lezing is dat artikel 72 hier niet dwingt tot een tweede, losstaande monitoringstructuur: lid 4 geeft u de keuze om de elementen onder te brengen in het systeem en het plan die u onder de productwetgeving al voert, met gebruikmaking van het model uit lid 3 en zolang het beschermingsniveau gelijkwaardig blijft. Die route staat of valt met een vraag die het artikel niet voor u beantwoordt: bestaat er onder de toepasselijke productwetgeving werkelijk al een systeem en een plan voor monitoring na het in de handel brengen, of voert u kwaliteitscontrole en incidentopvolging die niet als zodanig zijn vastgesteld. Wat u daarnaast moet kunnen laten zien is dat de signalen uit de fabriek ook echt gaan over de blijvende naleving van de eisen aan hoog-risico AI, en niet alleen over de mechanische veiligheid van de machine. Wij zouden daarom per signaal uit de productie vastleggen welk voorschrift het raakt, zodat de integratie geen verdunning wordt.
Toezichtsoftware bij een online tentamen
Een hogeschool zet tijdens online tentamens software in die via webcam en muisbewegingen signaleert wanneer een student mogelijk spiekt. Bij een signaal gaat er automatisch een melding naar de examencommissie.
Kijk bij toezichtsoftware naar het moment, want live meekijken tijdens een toets die tot een cijfer leidt valt onder punt 3(d), terwijl controle achteraf op ingeleverd werk daarbuiten blijft.
Proctoring bij een tentamen slaat door: van signaal naar meldplicht
Een hogeschool zet proctoringsoftware in bij een online tentamen en merkt dat een groep studenten stelselmatig onterecht als verdacht wordt gemarkeerd, waarna cijfers zijn ingetrokken. Docenten en de examencommissie willen weten of dit patroon een ernstig incident is en, zo ja, wie het moet melden en binnen welke tijd.
Artikel 3, punt 49 omschrijft een ernstig incident als een incident of gebrekkig functioneren van een AI-systeem dat direct of indirect leidt tot onder meer een schending van de uit het recht van de Unie voortvloeiende verplichtingen ter bescherming van de grondrechten. Artikel 73, lid 1 verplicht de aanbieder van een in de Unie in de handel gebracht hoog-risico AI-systeem ernstige incidenten te melden bij de markttoezichtautoriteiten van de lidstaat waarin het incident heeft plaatsgevonden. Lid 2 bepaalt dat de melding wordt gedaan onmiddellijk nadat de aanbieder het oorzakelijk verband of de redelijke waarschijnlijkheid daarvan heeft vastgesteld, en in ieder geval uiterlijk vijftien dagen nadat de aanbieder of, in voorkomend geval, de gebruiksverantwoordelijke zich bewust wordt van het ernstige incident. Lid 5 staat toe dat, indien dit nodig is om tijdige melding te waarborgen, een eerste, onvolledige melding wordt gedaan die wordt gevolgd door een volledige melding. Lid 7 bepaalt dat de markttoezichtautoriteit na ontvangst van een melding over een ernstig incident als bedoeld in artikel 3, punt 49, onder c, de in artikel 77, lid 1, bedoelde nationale overheidsinstanties of organen in kennis stelt. Artikel 26, lid 5 verplicht de gebruiksverantwoordelijke die een ernstig incident vaststelt daarvan onmiddellijk eerst de aanbieder in kennis te stellen en vervolgens de importeur of distributeur en de betreffende markttoezichtautoriteiten.
Artikel 3, punt 49, artikel 26, lid 5, en artikel 73, leden 1, 2, 5 en 7
Wij lezen artikel 73 zo dat een incident in het onderwijs zelden een enkel dramatisch moment is: het signaal zit in het patroon in de toetsuitslagen, en dat patroon ziet de hogeschool eerder dan de leverancier van de software. Of dat patroon ook een ernstig incident is, staat daarmee nog niet vast: dat hangt ervan af of het onterecht markeren en het intrekken van cijfers valt aan te merken als een schending van grondrechtenbeschermende verplichtingen in de zin van artikel 3, punt 49, onder c, en die weging maakt artikel 73 niet voor u. Wie die vraag openhoudt tot het eigen onderzoek rond is, neemt wel een risico, want de termijn van lid 2 loopt vanaf bewustwording. Richt uw examen- en klachtenproces daarom zo in dat een dergelijk patroon binnen dagen bij de aanbieder ligt; artikel 26, lid 5 legt op de school als gebruiksverantwoordelijke bovendien een eigen kennisgevingsplicht richting aanbieder, importeur of distributeur en markttoezichtautoriteit. De eerste, onvolledige melding uit lid 5 is daarbij het drukventiel; wachten op een afgerond onderzoeksrapport is dat niet.
Live gezichtsherkenning bij een voetbalstadion
De politie zet een busje met mobiele camera's en live gezichtsherkenning neer bij de hoofdingang van een stadion tijdens een EK-wedstrijd. De watchlist bevat personen die verdacht worden van uiteenlopende strafbare feiten, van zware criminaliteit tot fraude en inbraak, plus personen van mogelijk inlichtingenbelang en kwetsbare personen met psychische problemen. Er is geen aanwijzing dat een specifiek persoon bij deze wedstrijd aanwezig is.
Een watchlist die verschillende soorten verdenkingen mengt en niet aan de concrete gebeurtenis is gekoppeld is te onbepaald, en dat er iemand op staat voor wie inzet wel zou mogen maakt de hele inzet niet rechtmatig.
Inschatting van herhalingsrisico bij een politiedienst
Een politiedienst gebruikt een model dat per verdachte inschat hoe groot de kans is dat hij opnieuw een strafbaar feit pleegt, op basis van het dossier en eerder vastgesteld gedrag. Die uitkomst weegt mee bij de prioritering van lopende onderzoeken.
Leg vast op welke verifieerbare feiten uw risico-inschatting steunt, want een inschatting die aansluit bij een reeds vastgestelde betrokkenheid bij een strafbaar feit is hoog risico, terwijl een inschatting louter op profilering verboden is.
Satellietnetwerk dat bandbreedte verdeelt met een voorspellend model
Een satellietoperator verdeelt vermogen en bandbreedte over transponders en gebruikt daarvoor een machine-learningmodel dat het netwerkverkeer voorspelt, omdat klassieke optimalisatie moeite heeft met vraag die per regio en per moment sterk wisselt. De prestaties zijn vergelijkbaar met de gevestigde methoden in het vakgebied.
Automatische zelfaanpassing hoeft uw systeem niet binnen de definitie te brengen wanneer die aanpassing vooral de rekenprestaties verbetert, al zeggen de richtsnoeren enkel dat zulke systemen onder die omstandigheden uitgesloten kunnen worden.
Satirische deepfake van een politicus: lichter, niet vrijgesteld
Een satirisch platform publiceert een AI-bewerkte afbeelding van een bestaande politicus, geplaatst in een scene die op humoristische wijze een beleidsbesluit bekritiseert. De stijl en de context maken meteen duidelijk dat het om satire gaat.
Satire verlicht alleen de vorm van de openbaarmaking en niet de plicht zelf, dus zorg dat het satirische karakter voor uw publiek evident is en respecteer de rechten van de afgebeelde persoon.
Schaakprogramma met minimax en heuristische evaluatie
Een softwarehuis brengt een schaakprogramma uit dat stellingen beoordeelt met een minimax-algoritme en heuristische evaluatiefuncties. Het programma heeft nooit uit partijdata geleerd; het past vooraf geprogrammeerde regels en zoekstrategieen toe om een sterke zet te vinden.
Dat uw systeem nooit uit data heeft geleerd, beslist de vraag niet, want de richtsnoeren rekenen ook logica- en kennisgebaseerde benaderingen tot de AI-technieken en laten de definitie niet afhangen van een gekozen techniek.
Securitymonitoring van een saas-bedrijf: alleen cyberbeveiliging is geen veiligheidscomponent
Een softwarebedrijf levert een saas-platform dat netwerkverkeer bewaakt bij een beheerder van kritieke digitale infrastructuur en afwijkende patronen meldt aan het securityteam van die klant. De ontwikkelaars zien dat het gebruik bij zo'n beheerder onder punt 2 van Bijlage III kan vallen en vragen zich af of hun eigen product daarmee een hoog-risico AI-systeem wordt.
De ontwerprichtsnoeren van de Commissie van 19 mei 2026 stellen dat punt 2 van Bijlage III AI-systemen aanwijst die bedoeld zijn om te worden gebruikt als veiligheidscomponent bij het beheer en de exploitatie van onder meer kritieke digitale infrastructuur, en dat overweging 55 een duidelijk onderscheid maakt tussen een veiligheidscomponent en een cyberbeveiligingscomponent. Om onder punt 2 te vallen mag een AI-systeem niet uitsluitend voor cyberbeveiligingsdoeleinden worden gebruikt; zonder rechtstreekse veiligheidsrol kan het geen veiligheidscomponent in kritieke infrastructuur zijn en dus niet als hoog risico worden geclassificeerd op grond van artikel 6 lid 2. Als voorbeelden van systemen die uitsluitend voor cyberbeveiliging worden gebruikt en daarom buiten punt 2 vallen, noemen zij een AI-honeypot die cyberdreigingen realtime identificeert en neutraliseert, technologie die actief met potentiele aanvallers interacteert om nieuwe aanvalspatronen te leren, een systeem dat ongeoorloofde toegang helpt detecteren en een systeem dat verdachte e-mailadressen detecteert en gestolen data identificeert. Zij voegen daaraan toe dat een AI-systeem alleen als veiligheidscomponent in kritieke infrastructuur wordt aangemerkt als het wordt gebruikt door een entiteit die een lidstaat onder de CER-richtlijn als kritieke entiteit heeft aangewezen, en dat die uitleg niet verlangt dat die status aan een externe aanbieder bekend wordt gemaakt. Het document is een consultatieversie: niet bindend en nog niet definitief.
Ontwerprichtsnoeren classificatie hoog-risico AI, 19 mei 2026, bijlage over Bijlage III, randnummers (187), (188), (190) en (191)
Wij lezen deze passage als een grens die per functie loopt en niet per klant: dat uw afnemer kritieke digitale infrastructuur beheert, maakt uw monitoringproduct nog geen veiligheidscomponent. Wat wij uit de tekst niet met zekerheid kunnen afleiden, is waar enkel signaleren ophoudt en een veiligheidsfunctie begint, want dezelfde richtsnoeren rekenen ook het monitoren en detecteren van situaties die rechtstreeks tot fysieke schade kunnen leiden tot de veiligheidsfuncties. De open vraag is dus of uw saas-platform losstaat van de systemen die de fysieke besturing voeren, of daar in de praktijk onderdeel van wordt. Leg daarom per productfunctie vast wat het systeem uitvoert en wat het uitdrukkelijk aan de operator laat, want dat onderscheid draagt uw hele classificatie en is achteraf moeilijk te reconstrueren.
Rolprofielen en een startsessie per AI-project bij een overheids-ICT-dienst
Smals, dat ICT levert aan Belgische overheidsdiensten, beschrijft per rol welke kennis nodig is: alle medewerkers kennen mogelijkheden, grenzen en interne richtlijnen, AI-ambassadeurs herkennen en prioriteren toepassingen, AI-experts kennen governance en techniek, en juristen en de functionaris gegevensbescherming krijgen aparte verdieping. Voor elk nieuw AI-project volgt bovendien een sessie voor alle betrokkenen over de capaciteiten, grenzen, risico's en governance van juist dat systeem.
Zoek in het register eerst praktijken van organisaties die qua sector, omvang en rol als aanbieder of gebruiksverantwoordelijke op de uwe lijken, voordat u een opzet voor uw eigen medewerkers kiest.
Spamfilter dat is getraind op gelabelde e-mail
Een organisatie neemt een e-mailfilter af dat in de bouwfase is getraind op een verzameling berichten die mensen hebben gelabeld als spam of geen spam. Eenmaal in gebruik beoordeelt het filter zelfstandig nieuwe binnenkomende e-mail en classificeert die op basis van de geleerde patronen.
Een herkenbaar leerpatroon in uw systeem levert nog geen kant-en-klare kwalificatie op: de richtsnoeren verlangen dat u de concrete architectuur en functionaliteit langs alle zeven elementen van artikel 3(1) legt.
Spellingcorrectie hoeft niet gemarkeerd, een AI-samenvatting wel
Een uitgever gebruikt hetzelfde AI-hulpmiddel voor twee dingen: het corrigeren van spelfouten en het opschonen van de opmaak in aangeleverde stukken, en het maken van samenvattingen en herschrijvingen van diezelfde stukken.
De uitzondering hangt aan de functie en niet aan het hulpmiddel, dus beoordeel per toepassing of de betekenis, stijl of structuur verandert en markeer alleen die uitvoer waarbij dat gebeurt.
Statische schatting van oplostijd en dagafzet
Een servicedesk toont klanten een verwachte oplostijd die is berekend als het gemiddelde uit historische tickets. Een winkelketen voorspelt met een triviale voorspeller hoeveel stuks van een product er per dag verkocht worden, als vertrekpunt voor de inkoopplanning.
Blijf toetsen of uw schatting werkelijk niet meer doet dan een gemiddelde teruggeven, want zodra u er complexere verbanden in verwerkt, verliest u de grond onder deze uitzondering.
Synthetische avatar van de eigen CEO is een deepfake
Een bedrijf laat een realistische synthetische avatar van de eigen CEO een nieuwjaarsboodschap uitspreken waarin hij medewerkers bedankt voor het resultaat van het afgelopen jaar. De video gaat naar het intranet en naar de socialemediakanalen van het bedrijf.
Toestemming van de betrokken bestuurder en een welwillend doel doen niet ter zake, want de toets is objectief; zet dus een zichtbaar of hoorbaar label op de video voordat die wordt verspreid.
Toelatingssysteem bij een hogeschool: wie registreert wat in de EU-databank
Een hogeschool koopt een AI-systeem in dat de aanmelding en inschrijving van studenten ordent en per kandidaat een toelatingsadvies geeft voor haar beroepsopleidingen. De leverancier laat weten dat hij de conformiteitsbeoordeling zelf afhandelt en de CE-markering aanbrengt. De vraag die daarna blijft liggen is of de hogeschool zelf nog iets moet doen voordat het systeem in het onderwijsproces in gebruik gaat.
Artikel 43 lid 2 bepaalt dat aanbieders voor AI-systemen met een hoog risico als bedoeld in de punten 2 tot en met 8 van bijlage III de conformiteitsbeoordelingsprocedure op basis van interne controle van bijlage VI volgen, waarvoor de betrokkenheid van een aangemelde instantie niet nodig is. Artikel 47 lid 1 verplicht de aanbieder voor elk hoog-risicosysteem een schriftelijke, machineleesbare, fysieke of elektronisch ondertekende EU-conformiteitsverklaring op te stellen en die tot tien jaar na het in de handel brengen of in gebruik stellen ter beschikking van de nationale bevoegde autoriteiten te houden. Artikel 49 lid 1 verplicht de aanbieder of in voorkomend geval de gemachtigde om zichzelf en zijn systeem te registreren in de EU-databank als bedoeld in artikel 71, voordat een in bijlage III vermeld hoog-risicosysteem in de handel wordt gebracht of in gebruik wordt gesteld, met uitzondering van de systemen van punt 2 van bijlage III. Artikel 49 lid 3 bepaalt dat gebruiksverantwoordelijken die overheidsinstanties of instellingen, organen of instanties van de Unie zijn, of personen die namens hen optreden, zichzelf registreren, het systeem selecteren en het gebruik ervan registreren in diezelfde databank voordat zij zo een systeem in gebruik stellen of gebruiken, opnieuw met uitzondering van de systemen van punt 2 van bijlage III.
Artikel 43 lid 2, artikel 47 lid 1 en artikel 49 lid 1 en lid 3
Wij lezen artikel 49 als twee losstaande registraties: lid 1 gaat over de aanbieder en zijn systeem, lid 3 gaat over uw eigen gebruik, en in die lezing ontslaat de eerste u niet van de tweede. De scharniervraag voor de hogeschool is daarom niet of de leverancier zijn werk doet, maar of zij een overheidsinstantie is in de zin van lid 3. De verordening omschrijft dat begrip niet, en zolang dat niet vaststaat blijft open of de instelling zelf zichtbaar moet worden in de EU-databank. In de praktijk zouden wij het opvragen van de EU-conformiteitsverklaring en van het registratienummer al in de aanbesteding beleggen, zodat die vraag niet vlak voor een aanmeldperiode alsnog een blokkade wordt.
Triagesysteem op de spoedeisende hulp: twee routes naar hoog risico
Een ziekenhuis zet AI in om binnenkomende patienten op de spoedeisende hulp te prioriteren. De vraag is niet of het systeem hoog risico is, maar via welke route: als medisch hulpmiddel onder de productwetgeving, of rechtstreeks via Bijlage III.
De ontwerprichtsnoeren van de Commissie van 19 mei 2026 stellen dat een triagesysteem voor spoedeisende hulp als medisch hulpmiddel kan kwalificeren; voldoet het dan aan artikel 6 lid 1, dan is het hoog risico via Bijlage I en gelden de sectorale regels. Een triagesysteem dat geen medisch hulpmiddel is, is hoog risico via artikel 6 lid 2 en punt 5(d) van Bijlage III. Het document is een consultatieversie: niet bindend en nog niet definitief.
Ontwerprichtsnoeren classificatie hoog-risico AI, 19 mei 2026, bijlage over Bijlage III, randnummers (334) en (335)
Stel eerst vast of uw triagesysteem een medisch hulpmiddel is, want die vraag bepaalt de hele route: via Bijlage I loopt de beoordeling mee met de medische conformiteitsbeoordeling en de bijbehorende datum, via Bijlage III geldt het eigen tijdpad van artikel 6 lid 2. De uitkomst is in beide gevallen hoog risico, dus uitstellen van die vaststelling levert alleen onduidelijkheid op over welk regime u moet inrichten.
Twee AI-systemen bij één netbeheerder, twee regimes
Een netbeheerder gebruikt een AI-model dat automatisch de belasting verdeelt en delen van het elektriciteitsnet afschakelt om uitval te voorkomen. Dezelfde organisatie gebruikt daarnaast een chatbot die klanten helpt bij vragen over hun factuur.
Inventariseer uw AI per functie en niet per organisatie, want alleen systemen die de fysieke integriteit van de infrastructuur rechtstreeks beschermen zijn veiligheidscomponent en ondersteunende of klantgerichte toepassingen vallen erbuiten.
Verkoopdashboard dat wel samenvat maar niets aanbeveelt
Een commercieel team gebruikt rapportagesoftware die met statistische methoden de totale omzet, de gemiddelde omzet per regio en de trend over de tijd berekent en in grafieken toont. Het dashboard doet geen enkele suggestie over hoe de verkoop verbeterd kan worden of welke producten gepromoot moeten worden.
Zou uw dashboard wel suggesties gaan doen, dan is het daarmee nog geen AI-systeem, want de richtsnoeren stellen uitdrukkelijk dat ook systemen zonder AI aanbevelingen kunnen voortbrengen.
Webshop bouwt zelf een kredietcheck voor consumenten: wat het dossier moet bevatten
Een keten in de non-food retail laat klanten in de webshop achteraf betalen en beoordeelt bij het afrekenen zelf of een consument daarvoor in aanmerking komt. Het team bouwt dat beoordelingssysteem in eigen huis, boven op een voorgetraind model van een leverancier. De vraag is wat er vastligt voordat de functie live gaat, en wie dat moet vastleggen.
Artikel 11 lid 1 bepaalt dat de technische documentatie van een AI-systeem met een hoog risico wordt opgesteld voordat dat systeem in de handel wordt gebracht of in gebruik wordt gesteld, en wordt geactualiseerd. Die documentatie moet aantonen dat het systeem in overeenstemming is met de eisen van deze afdeling en nationale bevoegde autoriteiten en aangemelde instanties op heldere en begrijpelijke wijze in staat stellen die overeenstemming te beoordelen; zij omvat ten minste de in bijlage IV uiteengezette elementen. Bijlage IV somt die elementen op voor zover zij van toepassing zijn op het betreffende AI-systeem en vraagt onder meer om de uitgevoerde methoden en stappen voor de ontwikkeling, met inbegrip van, indien relevant, het gebruik van door derden geleverde vooraf getrainde systemen of hulpmiddelen en hoe die zijn gebruikt, geïntegreerd of aangepast door de aanbieder, om de gebruikte validatie- en testprocedures, en om een beschrijving van relevante wijzigingen die de aanbieder gedurende de levenscyclus aan het systeem aanbrengt. Kmo's, met inbegrip van start-ups, kunnen die elementen op vereenvoudigde wijze verstrekken; kiezen zij daarvoor, dan gebruiken zij het vereenvoudigde formulier dat de Commissie daartoe opstelt.
Artikel 11 legt de documentatieplicht bij de aanbieder, dus de vraag die in dit geval eerst open ligt is wie dat hier is. Als de beoordeling van kredietwaardigheid van consumenten in uw situatie hoog risico oplevert, dan pleit er in onze lezing veel voor dat een webshop die het systeem zelf samenstelt en onder eigen naam in gebruik stelt niet langer alleen gebruiksverantwoordelijke is maar aan de aanbiederskant terechtkomt, met de documentatieplicht die daarbij hoort. Artikel 11 zelf beslecht die rolverdeling niet, dus toets dat aan de definities en aan artikel 25 voordat u ervan uitgaat dat het dossier bij uw leverancier ligt. Het lastigste deel in retail is in onze lezing niet de eerste versie van het dossier maar het tempo daarna, omdat een webshop vaak per release aanpast terwijl het dossier blijft staan bij de stand van ingebruikname. Regel daarom bij de inkoop van het voorgetrainde model dat u de informatie over herkomst, training en tests krijgt die bijlage IV van u vraagt, en beleg per release wie het dossier bijwerkt.
Welzijnschatbot duwt gebruikers naar gevaarlijk gedrag
Een aanbieder brengt een AI-chatbot op de markt die gebruikers moet helpen gezonder te leven, met advies over beweging en mentale rust. In de praktijk speelt de chatbot in op persoonlijke kwetsbaarheden en zet hij mensen aan tot extreem sporten zonder rust of water.
Goede bedoelingen vrijwaren u niet: zodra uw systeem gebruikers voorspelbaar richting ernstige schade kan duwen en u geen preventieve of beperkende maatregelen trof, geldt het verbod ook zonder opzet.
Geen verplicht cursusformat, geen certificaat, geen examen en geen AI-officer
Artikel 4 schrijft geen vorm voor. De Commissie bevestigt dat er geen certificaat nodig is, geen plicht om kennis te meten, geen verplichte training en geen voorgeschreven governancestructuur.
Geldt voor aanbieders en gebruiksverantwoordelijken van AI-systemen, die maatregelen nemen die AI-geletterdheid ondersteunen bij hun personeel en bij andere personen die namens hen met de werking en het gebruik van AI-systemen te maken hebben.
Voor gebruiksverantwoordelijken van hoogrisico-AI-systemen komt daar later de afzonderlijke verplichting uit artikel 26 bij om te waarborgen dat het personeel dat met het systeem werkt voldoende is opgeleid om het te bedienen en menselijk toezicht te verzekeren. Die plicht gaat verder dan artikel 4, maar geldt nog niet: zij wordt van toepassing op 2 december 2027 voor zelfstandige hoogrisicosystemen uit bijlage III en op 2 augustus 2028 voor hoogrisicosystemen die zijn ingebed in producten onder bijlage I.
De Q&A van de Commissie over AI-geletterdheid stelt dat er geen pasklare aanpak bestaat en dat er geen strikte vereisten of verplichte trainingen worden opgelegd. Over certificering vermeldt de Q&A letterlijk dat er geen certificaat nodig is en dat organisaties een interne registratie van trainingen of andere begeleidende initiatieven kunnen bijhouden. Over toetsing vermeldt zij dat artikel 4 van de AI-verordening geen verplichting inhoudt om de AI-kennis van werknemers te meten. Over governance vermeldt zij dat er geen specifieke governancestructuur is voorgeschreven om aan artikel 4 te voldoen, zodat er anders dan bij de functionaris voor gegevensbescherming onder de AVG geen AI-functionaris hoeft te worden aangesteld. Over het niveau vermeldt de Q&A dat AI-geletterdheid na de wijziging door de Digital Omnibus een verplichting blijft voor aanbieders en gebruiksverantwoordelijken van AI-systemen, maar dat er geen specifiek of toereikend niveau wordt voorgeschreven en dat de verordening niet vereist dat enig specifiek niveau van AI-geletterdheid van enig individu wordt gegarandeerd. Daartegenover stelt de Q&A dat het enkel vertrouwen op de gebruiksaanwijzing van het AI-systeem of het aan personeel vragen die te lezen, mogelijk niet doeltreffend is, en dat organisaties bij het bepalen van hun aanpak rekening moeten houden met het algemene begrip van AI binnen de organisatie, met de vraag of zij aanbieder of gebruiksverantwoordelijke zijn, met de risico's van de gebruikte systemen, met kennislacunes bij personeel gelet op technische kennis, ervaring, opleiding en training, en met contextuele factoren zoals sector, doel en getroffen bevolkingsgroepen. De Q&A vermeldt verder dat organisaties verschillende niveaus van training of leeraanpakken kunnen hanteren naargelang kennis, ervaring, opleiding en rol, en dat personeel met een opleiding of ervaring in AI-ontwikkeling normaal gesproken als AI-geletterd wordt beschouwd, waarbij de organisatie nog wel moet nagaan of die personen de specifieke AI-systemen van de organisatie begrijpen, weten hoe zij daarmee moeten omgaan en zich van alle risico's bewust zijn.
Commission Q&A on AI literacy, secties over het vereiste niveau, opleidingsvormen, certificaten, toetsing van kennis en governancestructuren (geraadpleegd op 9 augustus 2026)
Deze guidance snijdt twee kanten op en beide worden misbruikt. De aanbodkant van de markt verkoopt certificaten en examens als wettelijke eis: dat is aantoonbaar onjuist, want de Commissie zegt letterlijk dat een certificaat niet nodig is en dat er geen plicht bestaat om kennis te meten. De andere kant is de organisatie die uit hetzelfde antwoord afleidt dat er dus niets hoeft. Ook dat klopt niet. De Commissie zegt in dezelfde Q&A dat het enkel doorsturen van de gebruiksaanwijzing mogelijk niet doeltreffend is, en zij verwacht een onderbouwde keuze op basis van uw rol, uw risico's en de kennislacunes van uw mensen. De juiste lezing is dus: geen voorgeschreven vorm, wel een aantoonbare maatregel. Dat maakt de interne registratie die de Q&A noemt tot het praktische hart van uw dossier. En let op de nuance over technische mensen: een datascientist is niet automatisch klaar, want de organisatie moet nog steeds nagaan of die persoon de eigen systemen en de bijbehorende risico's kent.
Stop met sturen op certificaten en stuur op een aantoonbare, gemotiveerde maatregel. Leg vast wat u heeft gedaan, voor welke groepen, waarom die vorm past bij hun rol en bij de risico's van de systemen die zij gebruiken, en houd daar een eenvoudige interne registratie van bij zoals de Q&A voorstelt. Differentieer daarbij naar rol in plaats van iedereen dezelfde module te geven, en neem ook uw technisch personeel mee met een specifiek onderdeel over de eigen systemen en risico's. Vervang het enkel doorsturen van gebruiksaanwijzingen door iets wat aantoonbaar wordt gelezen en begrepen.
Artikel 4 reikt verder dan uw eigen personeel, en de nationale toezichthouder handhaaft
De maatregelenplicht dekt ook opdrachtnemers, dienstverleners en soms clienten. Toezicht ligt niet bij het AI Office maar bij de nationale markttoezichtautoriteiten, die sinds 2 augustus 2026 handhaven.
Geldt ongeacht vestigingsplaats, zolang het AI-systeem op de Uniemarkt wordt gebracht, in de Unie wordt gebruikt, of het gebruik ervan gevolgen heeft voor personen in de Unie.
De Q&A van de Commissie over AI-geletterdheid vermeldt dat artikel 4 geldt voor aanbieders en gebruiksverantwoordelijken van AI-systemen en daarnaast voor andere personen die namens hen met de werking en het gebruik van AI-systemen te maken hebben, en dat het daarbij gaat om personen die in brede zin binnen de organisatorische invloedssfeer vallen, met als voorbeelden een opdrachtnemer, een dienstverlener en een client. Over clienten vermeldt de Q&A dat zij afhankelijk van het specifieke risico AI-geletterdheid nodig kunnen hebben, met als redenering dat getroffen personen moeten begrijpen hoe met behulp van AI genomen besluiten hen raken. Over het geografische bereik vermeldt de Q&A dat het juridische kader van de AI-verordening geldt voor zowel publieke als private partijen binnen en buiten de Unie, zolang het AI-systeem op de Uniemarkt wordt gebracht, in de Unie wordt gebruikt, of het gebruik ervan gevolgen heeft voor personen die zich in de Unie bevinden. Over toezicht vermeldt de Q&A dat het toezicht op en de handhaving van artikel 4 niet bij het AI Office ligt maar onder de bevoegdheid van de nationale markttoezichtautoriteiten valt, en dat toezicht en handhaving zijn aangevangen op 2 augustus 2026, terwijl artikel 4 zelf van toepassing is geworden op 2 februari 2025. Over sancties vermeldt de Q&A dat nationale markttoezichtautoriteiten boetes en andere handhavingsmaatregelen kunnen opleggen bij inbreuken op artikel 4, dat dit gebeurt op grond van nationale wetgeving die de lidstaten uiterlijk 2 augustus 2025 moesten vaststellen, dat elke sanctie evenredig moet zijn en moet worden gebaseerd op het individuele geval, rekening houdend met factoren zoals de aard en de ernst van de inbreuk en het opzettelijke of nalatige karakter ervan, en dat een sanctie waarschijnlijker is wanneer er bewijs is van een incident dat is ontstaan door een gebrek aan passende training en begeleiding. Artikel 4 wordt niet genoemd in de opsomming van artikel 99 lid 4 van de AI-verordening, die uitsluitend ziet op de artikelen 16, 22, 23, 24, 26, 31, 33 lid 1, 3 en 4, 34 en 50, zodat de hoogte van een sanctie wegens artikel 4 uit het nationale recht volgt en niet uit de boeteplafonds van de verordening zelf. De Q&A vermeldt verder dat artikel 4 de bepalingen over transparantie in artikel 13 en over menselijk toezicht in artikel 14 versterkt en indirect bijdraagt aan de bescherming van getroffen personen, en dat voor gebruiksverantwoordelijken van hoogrisicosystemen de verplichting uit artikel 26 om te waarborgen dat personeel is opgeleid voor menselijk toezicht een afzonderlijke eis vormt; die eis wordt van toepassing op 2 december 2027 voor zelfstandige systemen uit bijlage III en op 2 augustus 2028 voor systemen uit bijlage I.
Commission Q&A on AI literacy, secties over doelgroepen, geografisch bereik, toezicht en handhaving, en sancties (geraadpleegd op 9 augustus 2026)
Twee dingen worden hier consequent te klein gedacht. Het eerste is de kring van personen. Veel organisaties vertalen artikel 4 naar een personeelsprogramma en vergeten de detacheerders, het callcenter, het implementatiebureau en de freelancers die dagelijks met dezelfde systemen werken. De Q&A trekt die kring uitdrukkelijk breder naar iedereen binnen de organisatorische invloedssfeer, en laat zelfs de deur open voor clienten wanneer het risico daarom vraagt. Het tweede is wie er langskomt. Omdat het AI Office alle aandacht krijgt, denken organisaties dat artikel 4 een Brussels dossier is. Dat is het niet: dit loopt via de nationale markttoezichtautoriteit. Het meest bruikbare zinnetje voor uw eigen prioritering is dat een sanctie waarschijnlijker is wanneer er bewijs is van een incident dat is ontstaan door gebrekkige training en begeleiding. Handhaving zal dus zelden beginnen met een steekproef op uw opleidingsplan, en veel vaker met een incident waarna men terugkijkt of de betrokken medewerker was voorbereid. Dat maakt het dossier reactief bruikbaar en dus de moeite waard om nu al op orde te hebben.
Breid uw doelgroepenlijst uit van vast personeel naar iedereen die onder uw regie met uw AI-systemen werkt, dus ook inhuur, opdrachtnemers en implementatiepartners, en neem de verwachting daarover op in uw inkoop- en inhuurvoorwaarden. Beoordeel per systeem of ook clienten of betrokkenen uitleg nodig hebben over hoe met AI ondersteunde besluiten hen raken. Richt uw registratie zo in dat u na een incident binnen een dag kunt laten zien welke maatregelen de betrokken persoon had gekregen en wanneer. Zoek ten slotte uit welke nationale markttoezichtautoriteit voor u bevoegd is, want dat is uw gesprekspartner en niet het AI Office.
AI-agents moeten zowel hun AI-aard als hun opdrachtgever bekendmaken
Een AI-agent die boekingen doet, correspondentie afhandelt of contracten sluit, moet zich kenbaar maken als AI en daarbij vermelden namens wie hij handelt, ook richting de persoon die hem opdracht geeft.
Geldt zodra de agent kan communiceren met de persoon die hem instrueert of met andere natuurlijke personen bij de uitvoering van de taak.
Zuivere machine-naar-machinecommunicatie tussen agents waarvan de output niet bedoeld is om een natuurlijke persoon te bereiken, valt buiten de meldplicht van artikel 50 lid 1, en tussenliggende redeneerstappen en niet-waarneembare handelingen vallen buiten de markeringsplicht van artikel 50 lid 2.
Punt (31) van de richtsnoeren van 20 juli 2026 bepaalt dat AI-agents onder artikel 50 lid 1 vallen wanneer zij kunnen communiceren met de personen die hen instrueren of met andere natuurlijke personen bij de uitvoering van hun taken, met als voorbeelden het maken van boekingen, het beheren van correspondentie, het onderhandelen over of sluiten van contracten en het uitvoeren van aankopen. Volgens datzelfde punt moeten AI-agents zo worden ontworpen en ontwikkeld dat zij zowel hun kunstmatige aard bekendmaken als de persoon namens wie zij handelen, gelet op de noodzaak van transparantie over de oorsprong en over de delegatie van bevoegdheid en verantwoording voor de gevolgen van hun handelen. Dit geldt ook in complexe multi-agentarchitecturen waarin andere agents rechtstreeks met natuurlijke personen communiceren. Wanneer de aanbieder voor het in de handel brengen of in gebruik stellen niet betrouwbaar kan vaststellen of de agent rechtstreeks met een natuurlijke persoon zal communiceren, moet de agent op architectuurniveau zo worden ontworpen en geinstrueerd dat hij zich in elke situatie bekendmaakt waarin het redelijkerwijs waarschijnlijk is dat hij met een natuurlijke persoon in contact komt, ook wanneer die persoon een rechtspersoon vertegenwoordigt. Verder moeten agents zich ook bekendmaken aan de personen die hen instrueren, op belangrijke momenten zoals autorisatie, rapportage en validatie, mede wanneer de agent output verwerkt of gebruikt die door andere AI-systemen is voortgebracht in plaats van door een natuurlijke persoon, en bij iedere nieuwe interactie. Punt (63) voegt toe dat artikel 50 lid 2 op AI-agents van toepassing kan zijn wanneer de handeling van de agent leidt tot AI-gegenereerde of gemanipuleerde content die door natuurlijke personen waarneembaar is, terwijl tussenliggende verwerkingsstappen zoals redeneerketens en niet-waarneembare handelingen zoals een webverzoek of browseractie daarbuiten vallen.
Commission Guidelines C(2026) 5054 final, sectie 3.1.1, randnummer (31), en sectie 4.1.2, randnummer (63)
Hier gaat de richtsnoer verder dan de meeste organisaties verwachten. De verplichting is dubbel: niet alleen 'ik ben AI', maar ook 'ik handel namens deze partij'. Dat maakt agentische e-mail, inkoop en onderhandeling tot een ontwerpvraagstuk en niet tot een tekstje in de footer. Twee zaken worden stelselmatig gemist. Ten eerste geldt de meldplicht ook richting de eigen opdrachtgever, op sleutelmomenten zoals autorisatie en validatie, en met name wanneer de agent voortbouwt op output van andere AI-systemen in plaats van op menselijke input. Ten tweede lost het niet-weten van de aanbieder niets op: kan de aanbieder vooraf niet bepalen of de agent bij een mens uitkomt, dan is het antwoord niet 'dan hoeft het niet' maar 'dan bouwt u de bekendmaking standaard in de architectuur in'. De agent die zich stilhoudt totdat hij zeker weet dat er een mens meeleest, is dus niet de bedoeling.
Behandel de bekendmaking van uw agent als een architectuurvereiste, niet als een promptinstructie die per taak kan worden overschreven. Zorg dat elk uitgaand kanaal van de agent, dus e-mail, chat, telefonie en formulieren, standaard zowel de AI-oorsprong als de opdrachtgevende organisatie meegeeft. Bouw daarnaast bevestigingsmomenten in richting de eigen gebruiker bij autorisatie, rapportage en validatie, en markeer daarin expliciet wanneer de agent voortbouwt op output van een ander AI-systeem. Markeer ten slotte de waarneembare content die de agent produceert conform artikel 50 lid 2, maar niet de interne redeneerstappen.
Artistiek of satirisch werk is niet vrijgesteld, alleen verlicht, en informatief wint altijd
Voor deepfakes in evident artistiek, creatief, satirisch of fictief werk mag de bekendmaking het werk niet in de weg zitten, maar zij blijft verplicht. Bij een mengvorm met informatieve of commerciele content geldt het gewone label.
De deepfake moet evident deel uitmaken van een artistiek, creatief, satirisch, fictief of vergelijkbaar werk of programma, beoordeeld per geval door de gebruiksverantwoordelijke.
Bij content die meerdere karakters combineert, gaat het informatieve karakter altijd voor en gelden de gewone labelvereisten; content die uitsluitend informatief of commercieel is en als zodanig herkenbaar is, zoals nieuwsverslaggeving, valt buiten het lichtere regime.
Punt (119) van de richtsnoeren van 20 juli 2026 spreekt van een verzwakte transparantieverplichting voor deepfakes die deel uitmaken van evident artistieke, creatieve, satirische, fictieve of vergelijkbare werken of programma's, waarbij de verplichting beperkt is tot bekendmaking op een passende wijze die de weergave of het genot van het werk niet belemmert. Punt (120) omschrijft de categorieen: artistieke werken zijn werken gemaakt met het oog op kunst, waaronder muziek, cinematografische werken en beeldende kunst; creatieve werken vergen creatieve keuzes, waarbij werken die vooral door functionele of technische overwegingen zijn ingegeven niet als creatief gelden; satirische werken beogen samenleving, politiek, bedrijfsleven of publieke figuren te bekritiseren met humoristische technieken; fictieve werken betreffen personen, objecten, plaatsen, entiteiten of gebeurtenissen in een verbeelde maar geloofwaardige setting; vergelijkbare werken delen kernkenmerken met die categorieen zonder er precies in te passen. Punt (122) bepaalt dat het voor de natuurlijke personen die eraan worden blootgesteld evident moet zijn dat de content in een van die categorieen valt, dat de categorieen daarom strikt moeten worden uitgelegd gelet op het lichtere bekendmakingsregime en de belangen van de vrijheid van meningsuiting en van kunst en wetenschap, en dat content waarvan de aard voor het publiek mogelijk onduidelijk of dubbelzinnig is buiten dit lichtere regime valt. Relevante factoren zijn volgens datzelfde punt of de content vormen of stijlen vertoont die kenmerkend zijn voor de categorie, de context waarin de content wordt gepresenteerd, en de verwachtingen van het publiek. Datzelfde punt sluit content uit waarvan de aard uitsluitend informatief of commercieel is en als zodanig herkenbaar is, met nieuwsverslaggeving als voorbeeld, merkt op dat advertenties of documentaires in bepaalde specifieke situaties wel en in andere niet als evident creatief of fictief kunnen gelden omdat de beoordeling per geval plaatsvindt, en bepaalt dat wanneer de deepfake meerdere karakters combineert, bijvoorbeeld informatief en creatief, het informatieve karakter altijd voorgaat en de gewone labelvereisten gelden. Punt (123) benadrukt dat deze deepfakes niet zijn uitgesloten van de verplichting: de gebruiksverantwoordelijke moet de AI-oorsprong of de manipulatie nog steeds bekendmaken, maar mag dat doen op een passende wijze, en moet in elk geval voldoen aan artikel 50 lid 5. Punt (124) bepaalt dat het beroep op de verlichte verplichting geen rechtvaardiging kan zijn om de grondrechten van individuen of de rechten van rechthebbenden op grond van het Unierecht inzake intellectuele eigendom of gegevensbescherming niet te eerbiedigen. Als voorbeelden binnen de categorieen noemt het document films met door AI verjongde bestaande acteurs of digitale replica's van overleden acteurs, door AI gegenereerde muziek in de stijl van bestaande artiesten, en een door AI gemanipuleerde afbeelding van een bestaande politicus in een scene die duidelijk bedoeld is als humoristische kritiek. Buiten de categorieen vallen volgens het document onder meer een door AI gemanipuleerde video in de stijl van een teleshoppingkanaal, door AI gegenereerde beelden van beroemdheden die suggereren dat zij betrokken waren bij activiteiten die nooit hebben plaatsgevonden, en een door AI gemanipuleerde video met een realistische synthetische influencer die uitsluitend de functionaliteiten van een gesponsord product toont.
Commission Guidelines C(2026) 5054 final, sectie 6.1.3, randnummers (119) tot en met (124), en de bijbehorende voorbeeldenlijsten
Twee misverstanden domineren hier. Het eerste is dat 'creatief werk' een vrijstelling zou zijn. Dat is het niet: u moet nog steeds bekendmaken, alleen op een manier die het werk niet kapotmaakt, bijvoorbeeld in de aftiteling, in een begeleidende vermelding of aan het begin van de video in plaats van als permanent blok over het beeld. Het tweede misverstand is ernstiger en raakt marketing rechtstreeks. Reclame is niet automatisch creatief werk. De richtsnoer noemt teleshoppingachtige video's en synthetische influencers die een product demonstreren juist als voorbeelden die buiten de categorie vallen, en bepaalt bovendien dat bij menging het informatieve karakter altijd voorgaat. Wie dus een grappige, duidelijk gestileerde campagne maakt maar er een productclaim in verwerkt, valt terug op het gewone label. Let ten slotte op de eis van evidentie: als het publiek kan twijfelen of het satire of echt nieuws ziet, is het per definitie niet evident en geldt het lichtere regime niet.
Beoordeel per productie of het werk voor uw publiek onmiskenbaar artistiek, satirisch of fictief is, en leg die beoordeling met de drie factoren uit punt (122) kort vast: stijlkenmerken, context van publicatie en publieksverwachting. Ga bij campagnes en commerciele video's standaard uit van het gewone label en beroep u alleen bij hoge uitzondering op het lichtere regime. Kies bij evident creatief werk een bekendmaking die het werk intact laat, bijvoorbeeld bij aanvang of in de aftiteling, en houd daarbij rekening met de eis dat de informatie duidelijk en onderscheidbaar moet zijn en dat wie later instapt de melding ook moet kunnen waarnemen.
De gedragscode ondertekenen is vrijwillig, maar niet-tekenen betekent zelf bewijzen
Ondertekening van de gedragscode transparantie AI-gegenereerde content is vrijwillig en niet-ondertekenen is op zichzelf geen overtreding. Wie niet tekent, moet zelf aantonen hoe hij voldoet, onder meer met een gapanalyse tegen de code.
Geldt voor aanbieders en gebruiksverantwoordelijken van generatieve AI-systemen die binnen het bereik van artikel 50 lid 2 en lid 4 vallen.
De Q&A van de Commissie over het ondertekenen van de gedragscode transparantie AI-gegenereerde content vermeldt dat ondertekening vrijwillig is en dat het niet ondertekenen ervan geen niet-naleving van de AI-verordening oplevert. Diezelfde Q&A vermeldt dat de code twee delen kent, een deel voor aanbieders over het markeren van door AI gegenereerde of gemanipuleerde content in machineleesbare vorm en de bijbehorende detectiemechanismen, en een deel voor gebruiksverantwoordelijken over de bekendmaking en labeling van deepfakes en van bepaalde door AI gegenereerde of gemanipuleerde tekst over aangelegenheden van algemeen belang. Zij vermeldt verder dat ondertekenaars, na een positieve beoordeling door de Commissie en het AI-Comite, zich op de code kunnen beroepen om naleving van hun verplichtingen onder artikel 50 aan te tonen, ongeacht hun plaats van vestiging, en dat de sluitingsdatum voor opname in de eerste lijst van ondertekenaars 27 juli 2026 om 18:00 uur CEST was, waarbij latere ondertekening mogelijk blijft maar niet op die eerste lijst verschijnt. De richtsnoeren van de Commissie van 20 juli 2026 bepalen in punt (146) dat aanbieders en gebruiksverantwoordelijken binnen het bereik van artikel 50 lid 2 en lid 4 hun naleving kunnen aantonen door zich te houden aan een gedragscode die op grond van artikel 50 lid 7 als toereikend is beoordeeld, en dat zo'n code de verordening en de richtsnoeren niet vervangt maar aanvult als het enige Uniebreed erkende praktische kader daarvoor. Punt (147) bepaalt dat naleving ook via andere passende middelen kan worden aangetoond, dat toezichthouders zich bij ondertekenaars zullen richten op de vraag of zij de code hebben nageleefd en de daarin opgenomen maatregelen hebben uitgevoerd, en dat een opt-out uit onderdelen van de code ertoe leidt dat die aanbieders en gebruiksverantwoordelijken voor dat onderdeel het voordeel van het vergemakkelijkt aantonen verliezen. Punt (148) bepaalt dat wie geen ondertekenaar is, wordt geacht via andere passende middelen aan te tonen hoe hij aan artikel 50 lid 2, lid 4 en lid 5 voldoet en uit te leggen hoe zijn maatregelen naleving waarborgen, bijvoorbeeld door een gapanalyse uit te voeren die de eigen maatregelen vergelijkt met de maatregelen uit een als toereikend beoordeelde code, en dat die partijen waarschijnlijk meer verzoeken om informatie en om toegang zullen ontvangen. Punt (149) bepaalt dat bevoegde autoriteiten toezeggingen die in lijn met een als toereikend beoordeelde code zijn uitgevoerd, kunnen meewegen als verzachtende omstandigheid bij het bepalen van de hoogte van boetes. Punt (150) bepaalt dat de Commissie, als een code niet als toereikend wordt beoordeeld, een uitvoeringshandeling kan vaststellen met gemeenschappelijke regels voor de uitvoering van artikel 50 lid 2, lid 4 en lid 5.
Commission Guidelines C(2026) 5054 final, sectie 8.1, randnummers (146) tot en met (150); Commission Q&A on signing the Code of Practice on Transparency of AI-generated Content (geraadpleegd op 9 augustus 2026)
De vrijwilligheid is echt, maar zij is niet kosteloos. De richtsnoer verschuift de bewijslast: ondertekenaars worden getoetst op of zij doen wat de code zegt, niet-ondertekenaars moeten uitleggen waarom hun eigen aanpak volstaat. Dat verschil vertaalt zich in werk. Punt (148) verwacht van niet-ondertekenaars een gapanalyse tegen de code, wat betekent dat u de code hoe dan ook moet lezen en uw maatregelen ertegen moet afzetten. Niet tekenen bespaart u dus geen inhoud, alleen de ondertekening. Daar staat tegenover dat punt (149) naleving conform de code expliciet als verzachtende omstandigheid bij boetes noemt, wat de code ook commercieel interessant maakt voor partijen met veel gegenereerde content. Let ten slotte op de opt-outregel: gedeeltelijk tekenen is mogelijk, maar voor de overgeslagen onderdelen valt u terug in de zwaardere bewijspositie. Voor wie de eerste lijst heeft gemist, blijft ondertekening open; alleen de vermelding op die eerste lijst is verstreken.
Bepaal bewust of u tekent en leg de afweging vast. Tekent u niet, voer dan alsnog de gapanalyse uit die punt (148) noemt en bewaar die als kern van uw dossier, samen met een beschrijving van hoe uw eigen maatregelen artikel 50 lid 2, lid 4 en lid 5 afdekken. Houd er rekening mee dat u als niet-ondertekenaar meer informatie- en toegangsverzoeken kunt krijgen en richt uw documentatie daarop in. Tekent u wel maar met een opt-out op onderdelen, behandel die onderdelen dan als niet-ondertekenaar en documenteer ze afzonderlijk.
De gebruiksverantwoordelijke kan niet leunen op de machineleesbare markering van de aanbieder
Wie een deepfake publiceert, moet zelf een voor mensen waarneembaar label aanbrengen. Het watermerk of de metadata die de aanbieder meegeeft, dekt die plicht niet af.
Geldt voor gebruiksverantwoordelijken van AI-systemen die deepfakes in de vorm van beeld, audio of video genereren of manipuleren.
Voor deepfakes die deel uitmaken van evident artistieke, creatieve, satirische, fictieve of vergelijkbare werken geldt een verlichte vorm van bekendmaking, en voor bij wet toegestaan gebruik voor het opsporen, voorkomen, onderzoeken of vervolgen van strafbare feiten geldt een uitzondering.
Punt (117) van de richtsnoeren van 20 juli 2026 bepaalt dat gebruiksverantwoordelijken van AI-systemen die deepfakecontent genereren of manipuleren, duidelijk en onderscheidbaar moeten bekendmaken dat de content kunstmatig is gemaakt of gemanipuleerd, door de output als zodanig te labelen en de kunstmatige oorsprong ervan te vermelden. Volgens datzelfde punt moeten de gehanteerde label- of bekendmakingsmethoden begrijpelijk en waarneembaar zijn voor natuurlijke personen, bijvoorbeeld met zichtbare of hoorbare labels, zonder dat die personen op specifieke technische hulpmiddelen hoeven te vertrouwen of daartoe aparte handelingen moeten verrichten. Het punt sluit uitdrukkelijk af met de vaststelling dat gebruiksverantwoordelijken zich niet kunnen beroepen op de machineleesbare markering die de aanbieder onder artikel 50 lid 2 in de content heeft ingebed, omdat die markeringen niet onmiddellijk duidelijk en onderscheidbaar zijn voor de natuurlijke personen die aan de deepfakecontent worden blootgesteld. Punt (12) voegt daaraan toe dat gebruiksverantwoordelijken in complexe ketens van contentproductie en -distributie evenredige maatregelen moeten nemen om te waarborgen dat het door hen aangebrachte label onder artikel 50 lid 4 daadwerkelijk duidelijk en onderscheidbaar wordt getoond aan het beoogde en voorzienbare publiek op het moment van de eerste blootstelling, bijvoorbeeld via contractuele voorwaarden met distributiepartners en via instellingen en interfaces van de gebruikerservaring. Punt (14) bepaalt dat een rechtspersoon gebruiksverantwoordelijke blijft ook wanneer hij derden zoals opdrachtnemers of freelancers namens hem en onder zijn gezag bij de werking van het systeem betrekt, en dat individuele werknemers die onder diens instructies en toezicht handelen niet als aparte gebruiksverantwoordelijken gelden.
Commission Guidelines C(2026) 5054 final, 20.7.2026, sectie 6.1.2, randnummer (117), en sectie 2.3, randnummers (12) en (14)
Dit is de scherpste rolverwarring in de hele transparantieketen. Aanbieder en gebruiksverantwoordelijke hebben twee verschillende plichten met twee verschillende doelgroepen: de aanbieder markeert machineleesbaar voor systemen en toezichthouders, de gebruiksverantwoordelijke labelt waarneembaar voor mensen. De veelgemaakte fout is dat een marketingafdeling of communicatiebureau ervan uitgaat dat het gegenereerde beeld 'al gemarkeerd is' door de tool en dat er dus niets meer hoeft te gebeuren bij publicatie. Dat klopt niet. Even belangrijk is de doorwerking in de keten: de plicht eindigt niet bij het aanbrengen van het label, maar bij de vraag of het publiek het label bij eerste blootstelling ook echt ziet. Verdwijnt uw label doordat een platform de video hercodeert, bijsnijdt of automatisch afspeelt zonder begintitel, dan is het label er formeel wel maar functioneel niet. Daarom noemt de richtsnoer contractuele afspraken met distributiepartners expliciet als middel. En let op de laatste zin van punt (14): u schuift de rol van gebruiksverantwoordelijke niet door naar het bureau of de freelancer die de content voor u maakt.
Neem in uw publicatieproces een aparte stap op waarin een voor mensen zichtbaar of hoorbaar label wordt toegevoegd aan deepfakecontent, los van wat de generatietool zelf in de bestanden schrijft. Controleer per distributiekanaal of dat label na uploaden, hercoderen en automatisch afspelen nog steeds zichtbaar is bij het eerste contact. Leg de labelvereiste vast in uw voorwaarden met bureaus, productiepartners en distributieplatforms, en ga er niet van uit dat het inschakelen van een extern bureau de rol van gebruiksverantwoordelijke verplaatst.
Melding uiterlijk bij de eerste interactie, en bij elke nieuwe persoon opnieuw
De melding dat iemand met een AI-systeem te maken heeft, moet uiterlijk op het moment van de eerste interactie worden gegeven. Dat moment geldt per natuurlijke persoon, niet eenmalig per systeem.
Geldt voor aanbieders van AI-systemen die bedoeld zijn om rechtstreeks met natuurlijke personen te communiceren, en voor de horizontale eisen van artikel 50 lid 5 op alle meldingen onder artikel 50 lid 1 tot en met lid 4.
De informatieplicht vervalt als de interactie evident is voor een redelijk geinformeerde, opmerkzame en omzichtige persoon, of als het systeem bij wet is toegestaan voor het opsporen, voorkomen, onderzoeken of vervolgen van strafbare feiten, tenzij het systeem publiek toegankelijk is om een strafbaar feit te melden.
De finale richtsnoeren van de Commissie van 20 juli 2026 (C(2026) 5054 final) bepalen in punt (33) dat het informatiemechanisme in het ontwerp van het systeem moet zijn ingebed en dat de melding moet worden gegeven tijdens de werking van het systeem en uiterlijk op het moment van de eerste interactie met de natuurlijke persoon, zoals artikel 50 lid 5 voorschrijft. Punt (143) verduidelijkt dat 'eerste interactie of blootstelling' niet alleen ziet op de eerste persoon die met het systeem in aanraking komt, maar ook op elke daaropvolgende eerste interactie of blootstelling van iedere andere natuurlijke persoon. Bij een interactief systeem moet de informatie ten minste eenmaal aan het begin van een sessie worden gegeven. Voor content onder artikel 50 lid 2 en lid 4 geldt de informatieplicht per output ten opzichte van iedere natuurlijke persoon die eraan wordt blootgesteld. Punt (40) voegt toe dat een enkele prominente melding voorafgaand aan de eerste interactie in de meeste gevallen volstaat, maar dat in risicovollere contexten periodieke herinneringen en contextgevoelige meldingen waarschijnlijk noodzakelijk zijn, met name bij kwetsbare personen, bij langdurige of immersieve interacties, bij financieel, verzekerings-, juridisch of medisch advies en klachtbehandeling, en bij AI-companions. Volgens datzelfde punt moet het systeem zo zijn ontworpen dat het altijd opening van zaken geeft wanneer het naar zijn aard of naar de oorsprong van de interactie wordt gevraagd, of wanneer uit de uitwisseling redelijkerwijs kan worden afgeleid dat de persoon misleid of in verwarring is over de AI-oorsprong.
Commission Guidelines C(2026) 5054 final, 20.7.2026, sectie 3.1.2, randnummers (33) en (40), en sectie 7.2, randnummer (143)
De praktijkval zit in het woord 'eerste'. Veel organisaties lezen dat als een eenmalige mededeling bij de lancering van de chatbot, of als een zin in een welkomstmail die iedere bezoeker geacht wordt te hebben gezien. De richtsnoer leest het als een verplichting die opnieuw ontstaat bij iedere natuurlijke persoon die voor het eerst met het systeem of met de output ervan in aanraking komt. Een tweede veelgemaakte fout is aannemen dat een melding aan het begin van de sessie de hele klantreis afdekt. Wisselt de rol van het systeem tijdens de sessie, of duurt de interactie lang en gaat het over geld, gezondheid of recht, dan verwacht de Commissie herhaling. De derde val is het systeem laten ontwijken wanneer de gebruiker rechtstreeks vraagt of hij met een mens spreekt. Dat mag niet: die vraag moet altijd eerlijk worden beantwoord, ongeacht welke melding er eerder is gegeven.
Leg per klantcontactkanaal vast op welk moment de melding verschijnt en test dat met een verse sessie vanuit een nieuw apparaat, zodat u ziet wat een eerste bezoeker ziet en niet wat een ingelogde medewerker ziet. Bouw daarnaast een harde regel in de systeemprompt of de conversatielogica die het systeem verplicht zijn AI-oorsprong te bevestigen zodra daarnaar wordt gevraagd of zodra de gebruiker het systeem als mens aanspreekt. Bepaal ten slotte voor uw risicovolle kanalen, zoals financieel advies, schadebehandeling, zorg en klachten, of een enkele openingsmelding volstaat of dat u een blijvend label of periodieke herinnering nodig heeft, en leg die afweging schriftelijk vast.
De redactie-uitzondering: inhoudelijke toetsing plus een aanwijsbare verantwoordelijke
Labelen hoeft niet als de AI-tekst inhoudelijk door een mens is getoetst en iemand de redactionele verantwoordelijkheid draagt. Een spellingscheck of een redactiebeleid op papier is niet genoeg, en elke AI-ingreep na de goedkeuring laat de uitzondering vervallen.
Beide voorwaarden moeten samen zijn vervuld: inhoudelijke menselijke toetsing of redactionele controle, en een aanwijsbare natuurlijke of rechtspersoon met redactionele verantwoordelijkheid voor de publicatie.
Punt (133) van de richtsnoeren van 20 juli 2026 stelt twee cumulatieve voorwaarden: de door AI gegenereerde of gemanipuleerde tekst moet menselijke toetsing of redactionele controle hebben ondergaan, en een natuurlijke of rechtspersoon moet de redactionele verantwoordelijkheid voor de publicatie dragen. Punt (134) omschrijft menselijke toetsing als het weloverwogen onderzoek van de inhoud door een of meer natuurlijke personen met relevante kennis en professioneel oordeelsvermogen over het onderwerp, met academische peer review en professionele validatieketens als voorbeelden, en bepaalt dat het controleren van de juistheid van de inhoud een minimumvereiste is dat deel van die toetsing moet uitmaken. Redactionele controle omschrijft datzelfde punt als de in de praktijk uitgeoefende controle door een verantwoordelijke redactionele entiteit, bijvoorbeeld een hoofdredacteur, met de bevoegdheid om de inhoud op inhoudelijke gronden goed te keuren, te wijzigen of af te wijzen, waaronder feitencontrole en het waarborgen van de betrouwbaarheid van bronnen. Punt (135) bepaalt dat oppervlakkige, louter formele of procedurele controles zoals spelling- of grammaticacontrole, het enkele bestaan van een redactiebeleid, geautomatiseerde toetsingsprocessen, en vluchtige redactionele goedkeuring zonder inhoudelijke betrokkenheid van de menselijke toetser of de redactionele entiteit niet aan de voorwaarden voldoen. Punt (136) bepaalt dat wanneer AI-systemen worden gebruikt om content te wijzigen, aan te vullen of te herformuleren nadat de redactionele goedkeuring heeft plaatsgevonden, de resulterende content als door AI gegenereerd of gemanipuleerd moet worden behandeld, en dat elke inhoudelijke AI-ingreep na de menselijke toetsing of redactionele controle de uitzondering doet vervallen. Punt (138) bepaalt dat de persoon met redactionele verantwoordelijkheid de uiteindelijke verantwoordelijkheid voor de publicatie draagt, inclusief de menselijke toetsing of redactionele controle, en dat de identiteit en contactgegevens van die rechtspersoon, natuurlijke persoon of functie publiek beschikbaar moeten worden gemaakt op een eenvoudig vindbare plek, online bijvoorbeeld via de voorwaarden of andere juridische informatie op de website, offline bijvoorbeeld in het colofon. Als voorbeelden die aan de voorwaarden voldoen noemt het document onder meer een door AI gemanipuleerd krantenartikel of een door AI gemaakte samenvatting die onder redactionele controle van de hoofdredacteur is gekomen, een door AI gemanipuleerde academische blog met interne peer review, door AI gegenereerde publieke veiligheidswaarschuwingen die door een ambtenaar zijn goedgekeurd, en door AI gegenereerde duurzaamheidsrapportages die door professionals in relevante functies zijn getoetst. Als voorbeelden die niet voldoen noemt het document een website waar door AI gegenereerde artikelen over Uniebeleid zonder enige weloverwogen menselijke toetsing worden geplaatst, en door AI gegenereerde artikelen die door een ander AI-systeem worden nagekeken en waarbij een menselijke redacteur voor publicatie slechts een oppervlakkige grammaticale controle doet.
Commission Guidelines C(2026) 5054 final, sectie 6.2.3, randnummers (133) tot en met (138), en de bijbehorende voorbeeldenlijsten
Deze uitzondering is de reden dat de meeste redacties en communicatieafdelingen niet hoeven te labelen, maar zij is smaller dan hij oogt. Drie valkuilen. Ten eerste de volgorde: veel organisaties laten de tekst eerst goedkeuren en vervolgens door een AI-tool 'nog even oppoetsen' voor SEO, lengte of toon. Punt (136) zegt letterlijk dat elke inhoudelijke AI-ingreep na de goedkeuring de uitzondering doet vervallen. De AI-stap moet dus voor de menselijke toetsing komen, niet erna. Ten tweede de diepte: het moet gaan om weloverwogen onderzoek van de inhoud met feitencontrole als minimum. Een redacteur die alleen leest of het lekker loopt, voldoet niet, en een AI die een andere AI nakijkt al helemaal niet. Ten derde de zichtbaarheid: er moet ergens publiek vindbaar staan wie de redactionele verantwoordelijkheid draagt. Een colofon of een duidelijke vermelding in de juridische informatie op de site is geen formaliteit maar een voorwaarde voor de uitzondering. Opvallend is dat de richtsnoer deze uitzondering uitdrukkelijk ook buiten de media plaatst, met duurzaamheidsrapportages en overheidswaarschuwingen als voorbeelden. Uw compliance- of communicatiefunctie kan dus de rol van toetser vervullen, mits de toetsing echt inhoudelijk is.
Zet uw AI-stap altijd voor de menselijke goedkeuring in de workflow en blokkeer technisch dat er na de goedkeuring nog een AI-bewerking overheen gaat, ook geen automatische SEO-optimalisatie of inkorting. Leg per publicatiestroom vast wie de inhoudelijke toetsing doet, dat feitencontrole daar deel van uitmaakt, en wie de redactionele verantwoordelijkheid draagt. Publiceer die verantwoordelijke functie of persoon met contactgegevens op een eenvoudig vindbare plek, bijvoorbeeld in het colofon of bij de juridische informatie van de site. Bewaar per publicatie een kort spoor van wie wanneer inhoudelijk heeft getoetst, zodat u het beroep op de uitzondering kunt onderbouwen.
Wat op zichzelf niet volstaat als AI-melding
Een regel in de algemene voorwaarden, een verborgen metadata-markering of een vaag woord als 'assistent' voldoen niet. De richtsnoeren benoemen vijf methoden die alleen gebruikt onvoldoende zijn.
Geldt voor elke melding onder artikel 50, omdat artikel 50 lid 5 eist dat informatie duidelijk en onderscheidbaar wordt verstrekt en voldoet aan de toepasselijke toegankelijkheidseisen.
Punt (38) van de richtsnoeren van 20 juli 2026 somt de technieken op die niet noodzakelijk zijn en die, alleen gebruikt, onvoldoende zijn om aan artikel 50 lid 1 en lid 5 te voldoen. Het gaat om: meldingen die uitsluitend in algemene voorwaarden, in URL's of in documentatie staan, waarbij het document toevoegt dat zulke meldingen de melding in de interactie zelf mogen aanvullen maar niet vervangen; machineleesbare markeringen zoals metadata of watermerken die de gebruiker op het moment van interactie niet kan waarnemen, wat losstaat van de geschiktheid daarvan voor artikel 50 lid 2; onduidelijke of dubbelzinnige signalen, waarbij het document uitdrukkelijk een generieke verwijzing naar 'assistent' noemt, en mensachtige weergaven die gebruikers kunnen misleiden; algemene meldingen die onvoldoende specifiek zijn voor de output en de interacties van het systeem, waarbij het document als ontoereikend voorbeeld noemt dat op een platform met uiteenlopende diensten wordt vermeld 'Services on this website use AI'; en technische of capaciteitsgerichte beschrijvingen die alleen naar de onderliggende technologie verwijzen, zoals 'dit systeem gebruikt LLM's', zonder de functie of de gevolgen voor de gebruiker en de kunstmatige oorsprong toe te lichten. Punt (142) vult aan dat informatie niet duidelijk en onderscheidbaar is wanneer zij bij normale blootstelling of gebruik gemakkelijk over het hoofd kan worden gezien, bijvoorbeeld doordat zij alleen in een handleiding staat, verstopt zit onder lagen menuopties in een online interface, of onderdeel is van gebruiksvoorwaarden die gebruikers vaak niet lezen.
Commission Guidelines C(2026) 5054 final, sectie 3.1.2, randnummer (38), en sectie 7.1, randnummer (142)
Dit is de lijst die de meeste bestaande implementaties omvergooit. Drie patronen komen structureel voor en sneuvelen alle drie. Ten eerste de juridische afdekking: een zin in de algemene voorwaarden of in het privacystatement waarin staat dat de organisatie AI gebruikt. Ten tweede de technische afdekking: het argument dat de output een C2PA-markering of watermerk draagt en dat de gebruiker dus geinformeerd is. De richtsnoer scheidt die twee sporen strikt, want een machineleesbare markering telt voor artikel 50 lid 2 maar niet als melding aan de mens. Ten derde de merkgedreven afdekking: de chatbot een vriendelijke naam geven en hem 'uw digitale assistent' noemen. Juist die formulering wordt genoemd als voorbeeld van een dubbelzinnig signaal. Ook het populaire generieke bannertje op de homepage dat de site AI gebruikt, wordt expliciet als onvoldoende bestempeld omdat het niet specifiek genoeg is voor de concrete output.
Inventariseer waar uw huidige AI-melding staat. Staat zij uitsluitend in de algemene voorwaarden, het privacystatement, een cookiebanner of een helppagina, dan voldoet zij niet en moet zij verhuizen naar de interactie zelf, dicht bij het invoer- en uitvoerveld. Vervang omschrijvingen als 'digitale assistent' of 'virtuele medewerker' door een expliciete vermelding dat het om een AI-systeem gaat. Houd de machineleesbare markering in stand voor artikel 50 lid 2, maar reken haar niet mee als melding aan de gebruiker.
Bestaande systemen en oude content: wat wel en niet met terugwerkende kracht moet
Alleen de machineleesbare markering onder artikel 50 lid 2 kent een overgangstermijn voor systemen die er al waren. Oude content hoeft niet met terugwerkende kracht te worden gelabeld, maar oude tekst die u nu publiceert wel.
De overgangstermijn tot 2 december 2026 geldt uitsluitend voor de markerings- en detectieplicht van artikel 50 lid 2 en uitsluitend voor generatieve systemen die voor 2 augustus 2026 in de handel waren gebracht of in gebruik waren gesteld.
Content die voor 2 augustus 2026 is gegenereerd of gemanipuleerd, en tekst over aangelegenheden van algemeen belang die voor die datum is gegenereerd en gepubliceerd, hoeft niet met terugwerkende kracht te worden gemarkeerd of gelabeld.
Punt (153) van de richtsnoeren van 20 juli 2026 stelt vast dat artikel 50 op grond van artikel 113 van toepassing is vanaf 2 augustus 2026 en dat alle systemen die binnen het bereik vallen en in de Unie in de handel zijn gebracht of in gebruik gesteld op die datum aan de bepaling moeten voldoen, ongeacht de datum waarop zij in de handel zijn gebracht of in gebruik zijn gesteld. Datzelfde punt beschrijft dat de wijzigingsverordening op de AI-verordening in een gerichte overgangsregeling voorziet die uitsluitend ziet op de markerings- en detectieverplichtingen van artikel 50 lid 2 voor generatieve AI-systemen die voor 2 augustus 2026 in de handel zijn gebracht of in gebruik zijn gesteld, met een overgangstermijn om die bestaande systemen uiterlijk op 2 december 2026 in overeenstemming te brengen. Punt (153) bepaalt uitdrukkelijk dat systemen die deels interactief en deels generatief zijn alleen voor de markeringsverplichting van artikel 50 lid 2 van die overgangstermijn kunnen profiteren, terwijl de naleving van de bekendmakingsverplichting voor systemen die rechtstreeks met natuurlijke personen communiceren vanaf 2 augustus 2026 moet zijn gewaarborgd. Punt (154) bepaalt dat door AI gegenereerde of gemanipuleerde output binnen het bereik van artikel 50 lid 2 en deepfakes binnen het bereik van artikel 50 lid 4, eerste alinea, die voor 2 augustus 2026 zijn gegenereerd of gemanipuleerd, niet met terugwerkende kracht hoeven te worden gemarkeerd of gelabeld, en dat hetzelfde geldt voor teksten over aangelegenheden van algemeen belang die voor die datum door AI zijn gegenereerd of gemanipuleerd en gepubliceerd. Datzelfde punt bepaalt daartegenover dat teksten die voor 2 augustus 2026 zijn gegenereerd of gemanipuleerd maar op of na die datum worden gepubliceerd, wel moeten worden gelabeld. Punt (154) voegt toe dat gebruiksverantwoordelijken en andere actoren die bestaande, ongelabelde deepfakes bezitten of verspreiden niettemin worden aangemoedigd deze te labelen, zonder dat van hen onevenredige inspanningen worden verwacht zoals het doorlichten van bestaande contentdatabases of het aanpassen van reeds gedrukte productverpakkingen. Een voetnoot bij punt (153) verduidelijkt dat de bijzondere overgangsregeling van artikel 111 lid 2 voor hoogrisico-AI-systemen niet doorwerkt naar artikel 50, omdat de verplichtingen voor hoogrisicosystemen en de transparantieverplichtingen cumulatief gelden.
Commission Guidelines C(2026) 5054 final, sectie 8.4, randnummers (153) en (154)
Hier worden twee dingen door elkaar gehaald. Het eerste is de veronderstelling dat de overgangstermijn tot 2 december 2026 een algemeen uitstel van artikel 50 zou zijn. Dat is niet zo: hij dekt uitsluitend de machineleesbare markering en detectie van artikel 50 lid 2. Draait uw systeem ook een chatinterface, dan moest de melding aan de gebruiker al op 2 augustus 2026 staan, ook al mag de markering van de output nog tot december wachten. Het tweede is de aanname dat oude content veilig is. Dat klopt voor gepubliceerde content, maar niet voor de voorraad. Heeft u vorig jaar een reeks AI-teksten laten maken die u nu pas publiceert, dan gaat de labelplicht wel gelden. Datzelfde geldt voor een campagnebeeld dat al maanden op de plank ligt. Praktisch gezien is het onderscheid dus niet oud versus nieuw, maar het moment van publicatie. De aanmoediging om oude deepfakes alsnog te labelen is geen plicht, maar wel de plek waar een toezichthouder naar de redelijkheid van uw keuzes kan kijken.
Splits uw inventarisatie in drie: systemen die rechtstreeks met mensen communiceren en dus al sinds 2 augustus 2026 moeten melden, generatieve systemen die van de overgangstermijn tot 2 december 2026 gebruikmaken voor de machineleesbare markering, en systemen die beide doen en dus per verplichting een andere datum kennen. Doorloop daarnaast uw contentvoorraad: alles wat nog gepubliceerd moet worden en door AI is gemaakt of wezenlijk bewerkt, krijgt een label bij publicatie, ongeacht wanneer het is gegenereerd. Leg vast waarom u bestaande, al gepubliceerde content niet met terugwerkende kracht labelt, zodat u die keuze kunt uitleggen.
Wanneer is het evident AI? De uitzondering geldt alleen bij vrijwel geen twijfel
De uitzondering voor evidente AI-interactie moet restrictief worden uitgelegd. Zij geldt pas als er voor een gemiddeld lid van het beoogde en redelijkerwijs voorzienbare publiek vrijwel geen twijfel meer bestaat over de aard van de interactie.
Beoordeling per systeem en per gebruikscontext, uit te voeren en te documenteren door de aanbieder.
Uit de informatieverplichtingen van het EU-consumentenrecht kunt u zich niet loswerken met deze uitzondering: de richtsnoeren bepalen dat die verplichtingen gelden ongeacht of de interactie onder artikel 50 lid 1 als evident wordt aangemerkt.
De richtsnoeren van de Commissie van 20 juli 2026 leggen in punt (42) op de aanbieder de last om de evidente kunstmatige aard van de interactie te beoordelen en aan te tonen ten opzichte van een persoon die redelijk geinformeerd, opmerkzaam en omzichtig is, rekening houdend met de omstandigheden en de gebruikscontext. Punt (43) verankert die maatstaf in het begrip 'gemiddelde consument' uit het EU-consumentenrecht. Punt (44) schrijft een beoordeling in twee stappen voor: eerst bepaalt de aanbieder met welk publiek het systeem bedoeld is en redelijkerwijs waarschijnlijk zal communiceren, daarna hoe geinformeerd, opmerkzaam en omzichtig een gemiddeld lid van dat publiek is. Datzelfde punt bepaalt dat het blootgestelde publiek niet altijd gelijk is aan het beoogde publiek, dat het verwachte niveau lager ligt wanneer personen met een beperking, ouderen of minderjarigen deel uitmaken van het publiek, en dat het niveau hoger kan liggen bij een uitsluitend professioneel of gespecialiseerd publiek. Punt (45) bepaalt dat de uitzondering restrictief moet worden uitgelegd omdat zij natuurlijke personen het recht op duidelijke en onderscheidbare informatie ontneemt, dat de algemene bekendheid dat AI-systemen bestaan niet betekent dat mensen ze in een interactie herkennen, en dat de uitzondering beperkt moet blijven tot gevallen waarin er vrijwel geen twijfel meer bestaat over de aard van de interactie. Als voorbeelden waarin de uitzondering wel opgaat noemt het document onder meer codeassistenten die uitsluitend voor professionele ontwikkelaars beschikbaar zijn, een interne medewerkersassistent voor daartoe opgeleid en AI-geletterd personeel, systemen voor uitsluitend daartoe opgeleide zorgprofessionals, ambient AI in huishoudelijke apparaten en niet-speelbare personages in een singleplayergame. Als voorbeelden waarin de uitzondering niet opgaat noemt het document een robotgezelschapsdier dat sterk op het natuurlijke equivalent lijkt, AI in immersieve omgevingen met realistische avatars of stemmen, en chatbots op online platforms of helpdesks waarvan gebruikers de output als door mensen gemaakt kunnen ervaren.
Commission Guidelines C(2026) 5054 final, sectie 3.2.1, randnummers (42) tot en met (45), en de bijbehorende voorbeeldenlijsten
Dit is de uitzondering waar het vaakst ten onrechte een beroep op wordt gedaan. De redenering 'iedereen weet toch dat dit een chatbot is' wordt door de richtsnoer expliciet verworpen: algemene bekendheid met het bestaan van AI is niet hetzelfde als herkenning in het concrete gesprek. Beslissend is niet wat uw gemiddelde klant weet, maar wie er redelijkerwijs bij uw systeem terecht kan komen. Zodra uw systeem publiek toegankelijk is, zit het bredere publiek met ouderen, kinderen en mensen met een lagere digitale geletterdheid daar per definitie in, en dan valt de uitzondering weg. Het spiegelbeeld is even belangrijk en wordt vaak over het hoofd gezien: voor een strikt interne assistent voor getraind personeel erkent de Commissie de uitzondering wel uitdrukkelijk. Let daarbij op de voorwaarde in het voorbeeld zelf, namelijk dat het personeel daadwerkelijk is opgeleid en AI-geletterd is. Dat koppelt deze uitzondering rechtstreeks aan uw artikel 4-maatregelen: zonder aantoonbaar AI-geletterd personeel valt het fundament onder uw beroep op de uitzondering weg.
Beroep u alleen op deze uitzondering voor systemen met een gesloten, professioneel gebruikerspubliek, en leg de tweestapsbeoordeling schriftelijk vast: wie is het beoogde publiek, wie kan er nog meer bij, en waarom bestaat er voor een gemiddeld lid daarvan vrijwel geen twijfel. Voor alles wat publiek toegankelijk is, gaat u uit van wel melden. Koppel een intern beroep op de uitzondering aan uw artikel 4-dossier, zodat u kunt aantonen dat de betrokken medewerkers daadwerkelijk zijn voorbereid op het gebruik van dat systeem.
Standaardbewerking versus betekenisverandering bij de markeringsplicht
Spellingscorrectie, opmaak en kleine beeldcorrecties vallen buiten de markeringsplicht. Een AI-samenvatting, herschrijving of gezichtsvervanging valt er wel onder.
Geldt voor aanbieders van AI-systemen die synthetische audio, beeld, video of tekst genereren of manipuleren, in het kader van de machineleesbare markerings- en detectieplicht van artikel 50 lid 2.
Naast standaardbewerking en niet-wezenlijke wijziging geldt een derde uitzondering voor generatieve systemen die bij wet zijn toegestaan om synthetische content te genereren of te manipuleren voor het opsporen, voorkomen, onderzoeken of vervolgen van strafbare feiten.
Punt (90) van de richtsnoeren van 20 juli 2026 omschrijft standaardbewerking als het gereedmaken van bestaande content voor publicatie of verspreiding, zoals kleine aanpassingen ter verbetering van leesbaarheid, grammatica, kwaliteit en opmaak, waarbij geen nieuwe content wordt gegenereerd. Bewerking gaat volgens datzelfde punt verder dan standaardbewerking wanneer de content op materiele wijze wordt gewijzigd door inhoudelijke of structurele aanpassingen die de betekenis, stijl of bedoeling raken. Punt (91) behandelt de tweede uitzondering, voor systemen die de door de gebruiksverantwoordelijke aangeleverde invoergegevens of de semantiek daarvan niet wezenlijk wijzigen, en bepaalt dat een wijziging wezenlijk is wanneer de invoer of de semantiek daarvan tijdens de outputgeneratie aanzienlijk is gemanipuleerd, te beoordelen aan de hand van onder meer formaat, mediatype, stijl en wijzigingen die de betekenis, stijl of bedoeling raken. Punt (92) bepaalt dat wanneer een systeem zowel voor generatie of manipulatie als voor kleine, niet-wezenlijke wijzigingen kan worden gebruikt, de verplichting niet geldt voor de op kleine, niet-wezenlijke wijze gewijzigde content. Als voorbeelden die onder de uitzondering vallen noemt het document onder meer grammatica- en spellingscorrectie, kleine stilistische polijsting zonder verandering van substantie of boodschap, door AI gemaakte vertalingen, opmaak en formaatconversie, ruisonderdrukking, kleine bijsnijdingen en kleurcorrecties, verwijdering van stofvlekken en rode ogen, het onscherp maken van gezichten, herschaling van videofragmenten en transcripties van gesprekken. Als voorbeelden van betekenisveranderingen die wel markering vereisen noemt het document onder meer door AI gegenereerde samenvattingen van tekst, parafraseren of herschrijven dat stijl, structuur en betekenis verandert, het verwijderen, vervangen of invoegen van objecten of personen, gezichtsvervanging, de synthese van realistische spraak in de stem van een specifieke persoon en het samenstellen van composietbeelden.
Commission Guidelines C(2026) 5054 final, sectie 4.3, randnummers (90) tot en met (92), en de bijbehorende voorbeeldenlijsten
De scheidslijn ligt bij betekenis, niet bij moeite of bij de vraag of er een mens aan te pas kwam. Dat leidt tot twee uitkomsten die veel organisaties verrassen. De eerste: een door AI gemaakte samenvatting staat expliciet aan de markeringskant. Samenvatten voelt als bewerken, maar de richtsnoer schaart het bij semantische verandering. Wie automatisch samenvattingen genereert bij artikelen, verslagen of dossiers, zit dus in de markeringsplicht. De tweede, spiegelbeeldig: een door AI gemaakte vertaling staat aan de vrijgestelde kant, net als transcriptie. Dat is precies andersom dan de intuitie van veel redacties. Let ten slotte op punt (92): de vraag is niet wat uw tool kan, maar wat er in het concrete geval met de content is gebeurd. Dezelfde tool kan bij het ene gebruik buiten de plicht vallen en bij het andere erbinnen.
Deel uw AI-toepassingen in twee bakken in: bewerken zonder betekenisverandering en produceren of veranderen van betekenis. Zet daarbij samenvatten, herschrijven, beeldbewerking waarbij personen of objecten verdwijnen of verschijnen, en stemklonen uitdrukkelijk in de tweede bak, en spellingscorrectie, opmaak, vertaling en transcriptie in de eerste. Leg de indeling per toepassing vast met een korte motivering, want de richtsnoer eist een beoordeling per geval en niet per tool.
Welke AI-tekst labelplichtig is: gepubliceerd, publiek informerend en van publiek belang
De labelplicht voor AI-tekst geldt alleen bij drie samenlopende elementen: de tekst is gepubliceerd, is bedoeld om het publiek te informeren, en gaat over een aangelegenheid van algemeen belang.
De drie elementen zijn cumulatief: pas als de tekst gepubliceerd is, het publiek wil informeren en een aangelegenheid van algemeen belang betreft, ontstaat de bekendmakingsplicht.
De plicht vervalt wanneer de door AI gegenereerde of gemanipuleerde tekst menselijke toetsing of redactionele controle heeft ondergaan en een natuurlijke of rechtspersoon de redactionele verantwoordelijkheid voor de publicatie draagt, en bij bij wet toegestaan gebruik voor het opsporen, voorkomen, onderzoeken of vervolgen van strafbare feiten.
Punt (131) van de richtsnoeren van 20 juli 2026 splitst het toepassingsbereik van artikel 50 lid 4, tweede alinea, in drie elementen. Gepubliceerde tekst betekent dat de tekst gelijktijdig of achtereenvolgens toegankelijk is voor een onbepaald, tamelijk groot aantal niet met elkaar verbonden potentiele lezers, al dan niet tegen betaling zoals bij een abonnement. Tekst geldt niet als gepubliceerd wanneer de toegang beperkt is tot specifieke personen binnen een gesloten, private groep, bijvoorbeeld een kleine gesloten groep in een berichtenapp of een groep die te klein of te onbeduidend is; het document noemt als voorbeelden van niet-gepubliceerde tekst private, interpersoonlijke correspondentie voor professionele doeleinden en organisatie-interne teksten of communicatie zoals publicaties op een intern bedrijfsnetwerk. Het publiek informeren betekent dat de tekst kennis, meningen of feiten wil overbrengen; korte teksten die niet wezenlijk kennis, meningen of feiten overbrengen, informeren het publiek niet. Aangelegenheden van algemeen belang zijn volgens datzelfde punt in het algemeen aangelegenheden die relevant zijn voor de samenleving als geheel, op lokaal, nationaal, Unie- of internationaal niveau, en die publiek debat of publieke toetsing verdienen; het document rekent daartoe teksten over politiek en democratische processen, openbaar bestuur en publieke dienstverlening, rechtspleging en rechtshandhaving, de bescherming van grondrechten, openbare veiligheid, volksgezondheid, milieubescherming, consumentenveiligheid, en elke economische, financiele, politieke, wetenschappelijke of culturele ontwikkeling die onderwerp van publiek debat kan zijn, met de opmerking dat wat als algemeen belang geldt in de loop van de tijd en per context kan veranderen. Als voorbeelden binnen het bereik noemt het document een door AI gegenereerde samenvatting van een door een mens geschreven artikel op een krantenwebsite over een recent besluit van een gemeenteraad, door AI gemanipuleerde delen van een artikel op een lifestylewebsite over de effecten van diverse dieten op een bepaalde ziekte, door AI gemanipuleerde bedrijfsrapportages met beleggersinformatie op de website van een beursgenoteerde onderneming, en een door AI gegenereerd bericht op het socialemediaprofiel van een meteorologisch instituut waarin burgers voor storm en voorzorgsmaatregelen worden gewaarschuwd. Buiten het bereik vallen volgens het document onder meer door AI gegenereerde fantasyromans, door AI gemanipuleerde tekst in advertenties of productbeschrijvingen zonder claims over bijvoorbeeld gezondheid, consumentenveiligheid of duurzaamheid, een nieuwssamenvatting van een chatbot die alleen zichtbaar is voor de gebruiker die erom vroeg, en door AI gemanipuleerde tekst van een adviseur met advies aan een client over na te leven regelgeving.
Commission Guidelines C(2026) 5054 final, sectie 6.2.1, randnummer (131), en de bijbehorende voorbeeldenlijsten
De reflex is om dit als een mediaregel te lezen die alleen redacties raakt. De voorbeelden laten iets anders zien. Een beursgenoteerde onderneming met AI-bewerkte beleggersinformatie op de eigen website zit erin. Een meteorologisch instituut met een stormwaarschuwing op social media zit erin. Een lifestylesite met gezondheidsclaims zit erin. Wat die gevallen bindt is niet dat het journalistiek is, maar dat een breed publiek er informatie uit haalt over iets dat de samenleving raakt. De tweede nuance zit in de andere kant: een advertentie of productbeschrijving valt erbuiten, maar alleen zolang er geen claims in staan over gezondheid, consumentenveiligheid of duurzaamheid. Duurzaamheidsclaims in commerciele teksten schuiven dus wel in het bereik. De derde nuance is de scheiding tussen intern en gepubliceerd: uw intranet en uw een-op-eencorrespondentie vallen erbuiten, ook als de inhoud maatschappelijk relevant is. En let op: dat de door AI gegenereerde samenvatting van een menselijk artikel in de voorbeeldenlijst staat, betekent dat de automatische samenvattingsfunctie onder een nieuwsartikel op zichzelf al labelplichtig kan zijn.
Loop uw publicatiekanalen langs en markeer waar AI tekst genereert of wezenlijk bewerkt: nieuwsberichten, kennisartikelen, jaarverslagen en beleggersinformatie, voorlichting en waarschuwingen aan burgers, en duurzaamheids- of gezondheidsclaims. Beoordeel per kanaal of de tekst gepubliceerd is in de betekenis van de richtsnoer, dus toegankelijk voor een onbepaald en tamelijk groot publiek. Behandel automatische samenvattingsfuncties bij artikelen als een aparte, zelfstandige beoordeling en niet als onderdeel van het onderliggende artikel.
Wanneer een downstream-partij die finetunet zelf GPAI-aanbieder wordt
Niet elke aanpassing maakt u aanbieder. De indicatieve grens ligt bij een aanpassing die meer dan een derde van de trainingscompute van het oorspronkelijke model gebruikt, en uw plichten blijven dan beperkt tot de aanpassing.
Geldt voor downstream-partijen die losstaan van de oorspronkelijke aanbieder en niet namens hem handelen, en die een AI-model voor algemene doeleinden aanpassen of finetunen, met of zonder integratie in een AI-systeem.
Wordt u aanbieder van het aangepaste model, dan blijven de verplichtingen beperkt tot de aanpassing zelf: de technische documentatie ziet op de wijziging, en het auteursrechtbeleid en de samenvatting van trainingsinhoud zien alleen op de data die in de aanpassing zijn gebruikt.
De richtsnoeren van de Commissie van 18 juli 2025 (C(2025) 5045 final) over het toepassingsbereik van de verplichtingen voor aanbieders van AI-modellen voor algemene doeleinden stellen in punt (61) dat het niet nodig is dat elke aanpassing van zo'n model ertoe leidt dat de downstream-partij als aanbieder van het aangepaste model wordt aangemerkt, in lijn met de Blue Guide die bepaalt dat een product dat belangrijke wijzigingen of revisies heeft ondergaan met het oog op wijziging van de oorspronkelijke prestaties, het doel of het type, als een nieuw product kan worden beschouwd. Punt (62) bepaalt dat de Commissie een downstream-partij pas als aanbieder van het aangepaste model beschouwt wanneer de aanpassing leidt tot een aanzienlijke verandering in de algemeenheid, de capaciteiten of het systeemrisico van het model. Punt (63) formuleert het indicatieve criterium: een downstream-partij wordt geacht aanbieder te zijn wanneer de voor de aanpassing gebruikte trainingscompute groter is dan een derde van de trainingscompute van het oorspronkelijke model. Punt (64) bepaalt dat wanneer de downstream-partij die waarde niet kan kennen, bijvoorbeeld omdat de aanbieder van het oorspronkelijke model haar niet heeft meegedeeld, en haar evenmin kan schatten, de drempel wordt vervangen door een derde van 10 tot de macht 25 FLOP wanneer het oorspronkelijke model een model met systeemrisico is, en anders door een derde van 10 tot de macht 23 FLOP. Punt (65) licht toe dat een aanpassing van die omvang naar verwachting een aanzienlijke verandering oplevert die de transparantieverplichtingen van artikel 53 lid 1, punten a en b, rechtvaardigt, dat zo'n aanpassing naar verwachting een aanzienlijke hoeveelheid data heeft gebruikt wat van belang is voor het auteursrechtbeleid en de openbare samenvatting van de trainingsinhoud onder artikel 53 lid 1, punten c en d, en dat bij een oorspronkelijk model met systeemrisico het aangepaste model naar verwachting een aanzienlijk ander systeemrisico vertoont. Punt (67) merkt op dat momenteel weinig aanpassingen aan dit criterium voldoen, dat het aantal downstream-partijen dat aanbieder wordt in de loop van de tijd kan toenemen, en dat het criterium daarmee vooral toekomstgericht is. Punt (68) bepaalt dat de verplichtingen bij een aanpassing beperkt blijven tot die aanpassing: de documentatie onder artikel 53 lid 1, punten a en b, is beperkt tot informatie over de aanpassing, en het auteursrechtbeleid onder punt c en de samenvatting van de gebruikte trainingsinhoud onder punt d zijn beperkt tot de data die als onderdeel van de aanpassing zijn gebruikt. Punt (69) bepaalt dat de downstream-partij die aanbieder wordt ook aan artikel 54 moet voldoen, wat neerkomt op het aanwijzen van een in de Unie gevestigde gemachtigde voor zover die partij zelf buiten de Unie is gevestigd. Punt (70) bepaalt dat wanneer een downstream-partij een als systeemrisicomodel geclassificeerd model zodanig aanpast dat zij aanbieder van het aangepaste model wordt, het resulterende model eveneens wordt vermoed capaciteiten met grote impact te hebben en dus als model met systeemrisico geldt, en punt (71) bepaalt dat die partij dan moet voldoen aan de verplichtingen voor aanbieders van modellen met systeemrisico en de Commissie moet informeren overeenkomstig artikel 52 lid 1.
Commission Guidelines C(2025) 5045 final, 18.7.2025, sectie 3.2, randnummers (60) tot en met (67), en secties 3.2.1 en 3.2.2, randnummers (68) tot en met (71)
De praktische boodschap is geruststellender dan de meeste organisaties denken, maar met een addertje. Gewoon finetunen op uw eigen documenten, RAG, promptengineering of een LoRA-adapter komt niet in de buurt van een derde van de trainingscompute van een groot basismodel. De Commissie zegt zelf dat momenteel weinig aanpassingen aan het criterium voldoen. Wie een model aanpast voor eigen gebruik wordt dus in de regel geen GPAI-aanbieder. Het addertje zit in punt (64): weet u de trainingscompute van het oorspronkelijke model niet en kunt u die ook niet schatten, dan valt u terug op een absolute drempel van een derde van 10 tot de macht 23 FLOP. Dat is een aanzienlijk lagere lat dan een derde van een groot model, en juist bij gesloten modellen waarvan de compute niet wordt gepubliceerd is dat het scenario waar u in zit. De tweede val is de systeemrisicoketen: past u een model aan dat al als systeemrisicomodel is aangemerkt en wordt u daardoor aanbieder, dan erft u dat label en de meldplicht bij de Commissie. Positief is dat de plichten in dat geval beperkt blijven tot uw eigen aanpassing: u hoeft niet de documentatie of de trainingsdatasamenvatting van het oorspronkelijke model over te doen.
Leg per aangepast model vast welk basismodel u gebruikt, welke aanpassingsmethode u toepast en hoeveel compute die aanpassing heeft gekost, zodat u het criterium kunt toetsen in plaats van erover te speculeren. Vraag bij de aanbieder van het basismodel naar de trainingscompute en documenteer het antwoord, want als u die waarde niet kunt kennen valt u terug op de aanzienlijk lagere absolute drempel. Controleer daarnaast of het basismodel als model met systeemrisico is aangemerkt, want dat verandert zowel de drempel als de gevolgen wanneer u die overschrijdt. Herbeoordeel deze inschatting bij elke substantiele hertraining, omdat de Commissie zelf aangeeft dat het aantal downstream-partijen dat aanbieder wordt naar verwachting toeneemt.
Bijlage I somt wetgeving op, geen producten
Bijlage I bevat geen lijst van hoog-risico producten maar een uitputtende lijst van harmonisatiewetgeving. De AI Act breidt de reikwijdte van die productwetgeving niet uit en verandert het risicoprofiel van een product niet.
De concept-richtsnoeren van 19 mei 2026, gepubliceerd voor consultatie en uitdrukkelijk niet bindend, verduidelijken dat Bijlage I AI Act geen individuele producten opsomt die als hoog-risico moeten worden aangemerkt, maar harmonisatiewetgeving van de Unie die de veiligheidsaspecten van bepaalde producten regelt. Of een AI-systeem binnen de reikwijdte van Bijlage I valt hangt dus af van de vraag of het systeem, of het product waarvan het systeem een veiligheidscomponent is, binnen het materiele toepassingsgebied van een van de opgesomde wetgevingshandelingen valt. De lijst in Bijlage I is volgens de concept-richtsnoeren uitputtend; producten kunnen alleen worden toegevoegd of verwijderd door de reikwijdte van de harmonisatiewetgeving zelf te wijzigen of door nieuwe harmonisatiewetgeving aan Bijlage I toe te voegen. De concept-richtsnoeren stellen tevens dat de AI Act via artikel 6 lid 1 de reikwijdte van de harmonisatiewetgeving niet uitbreidt naar nieuwe of aanvullende producten, en dat de AI Act het risicoprofiel van een product niet bepaalt of wijzigt maar voortbouwt op de sectorale risicoclassificatie. Genoemd worden onder meer machines, speelgoed, liften, apparatuur en beveiligingssystemen voor plaatsen met ontploffingsgevaar, radioapparatuur, drukapparatuur, pleziervaartuigen, kabelbaaninstallaties, gasverbrandingstoestellen, medische hulpmiddelen, medische hulpmiddelen voor in-vitrodiagnostiek, en producten in de automobiel- en luchtvaartsector.
Concept-richtsnoeren Annex I, punten (23) tot en met (26)
Uw startpunt is dus niet de AI Act maar uw bestaande productdossier. De vraag is niet of uw product op een AI-lijst staat, want die lijst bestaat niet. De vraag is of uw product al onder een van de opgesomde verordeningen of richtlijnen viel voordat er AI in zat. Zo niet, dan komt u via deze route niet in het hoog-risico regime terecht, hoe geavanceerd het AI-systeem ook is. Wel wijzen de concept-richtsnoeren erop dat het begrip veiligheidscomponent voor deze classificatie mag worden gelezen als exclusief de publieke belangen in de sectorale wetgeving die verder gaan dan gezondheid, veiligheid en grondrechten, zoals risico's rond radiospectrumgebruik of elektromagnetische compatibiliteit. Die belangen dragen dus niet bij aan de kwalificatie.
Begin uw classificatie met een inventarisatie van de productwetgeving die vandaag al op uw portfolio van toepassing is, en leg per productlijn vast onder welke verordening of richtlijn u valt. Dat overzicht is herbruikbaar en voorkomt dat u per AI-functionaliteit opnieuw de hele analyse moet doen.
Sectie A en Sectie B van Bijlage I geven een ander eisenpakket
Bij producten onder Sectie A van Bijlage I geldt het volledige eisenpakket voor hoog-risico systemen. Bij Sectie B gelden alleen artikel 6 lid 1, de artikelen 102 tot en met 109 en artikel 112.
De concept-richtsnoeren van de Commissie van 19 mei 2026, die niet bindend zijn zolang de definitieve versie niet is vastgesteld, maken een onderscheid dat in de praktijk vaak wordt gemist. AI-systemen die als hoog-risico zijn aangemerkt onder artikel 6 lid 1 voor producten die vallen onder de harmonisatiewetgeving in Sectie A van Bijlage I zijn onderworpen aan de eisen voor hoog-risico systemen van afdeling 2 van hoofdstuk III AI Act. Daarentegen gelden voor AI-systemen die als hoog-risico zijn aangemerkt onder artikel 6 lid 1 voor producten die vallen onder de harmonisatiewetgeving in Sectie B van Bijlage I alleen artikel 6 lid 1, de artikelen 102 tot en met 109 en artikel 112 AI Act. De concept-richtsnoeren verwijzen hiervoor naar artikel 2 lid 2 AI Act. Sectie A bevat de harmonisatiewetgeving die is gebaseerd op het nieuwe wetgevingskader, Sectie B de overige harmonisatiewetgeving van de Unie.
Concept-richtsnoeren Annex I, punt (60), met verwijzing naar artikel 2 lid 2 AI Act
Dit onderscheid bepaalt de omvang van uw project. Twee organisaties kunnen allebei terecht concluderen dat zij een hoog-risico AI-systeem hebben en toch een totaal verschillend werkpakket voor zich hebben. Zit u in Sectie A, dan komt de volledige set aan de orde: risicobeheersysteem, datakwaliteit, technische documentatie, logging, transparantie richting gebruiksverantwoordelijken, menselijk toezicht, nauwkeurigheid en robuustheid. Zit u in Sectie B, dan is het eisenpakket wezenlijk beperkter. Controleer dus als eerste in welke sectie uw wetgeving staat, voordat u budget en planning vaststelt.
Noteer in uw classificatienotitie niet alleen dat u onder Bijlage I valt, maar ook onder welke sectie. Koppel daar direct het bijbehorende eisenpakket aan, zodat uw projectplan van meet af aan de juiste omvang heeft.
Twee cumulatieve voorwaarden voor hoog-risico onder Bijlage I
Een AI-systeem is pas hoog-risico via artikel 6 lid 1 als aan twee voorwaarden tegelijk is voldaan: het systeem is zelf een gereguleerd product of een veiligheidscomponent daarvan, en dat product moet een conformiteitsbeoordeling door een derde partij ondergaan.
De concept-richtsnoeren van de Europese Commissie van 19 mei 2026, die uitdrukkelijk niet bindend en niet definitief zijn, lezen artikel 6 lid 1 als twee cumulatieve voorwaarden. Ten eerste moet het AI-systeem bestemd zijn om te worden gebruikt als veiligheidscomponent van een product, of moet het AI-systeem zelf een product zijn, dat valt onder de harmonisatiewetgeving van de Unie die in Bijlage I is opgesomd. Ten tweede moet dat product, of het AI-systeem zelf wanneer dat het product is, verplicht een conformiteitsbeoordeling door een derde partij ondergaan. De concept-richtsnoeren stellen daarbij uitdrukkelijk dat niet alle AI-systemen die onderdeel zijn van gereguleerde producten hoog-risico zijn, maar alleen een deelverzameling die aan beide criteria voldoet.
Concept-richtsnoeren Annex I, punten (27) en (21)
Dit is een filter met twee zeven, en beide moeten passeren. In de praktijk zien wij dat organisaties bij de eerste zeef blijven hangen en concluderen dat hun product hoog-risico is omdat er sectorale productwetgeving op van toepassing is. Dat is te snel. De tweede zeef, de verplichte betrokkenheid van een derde partij, snijdt een aanzienlijk deel weg. Omgekeerd geldt ook: wie alleen naar het CE-traject kijkt en de veiligheidscomponent-vraag overslaat, mist juist systemen die pas via de faalroute binnenkomen. U moet dus beide vragen los stellen en beide antwoorden vastleggen.
Leg voor elk AI-systeem in een gereguleerd product een tweeledige classificatienotitie vast: eerst de vraag of het systeem product of veiligheidscomponent is, daarna de vraag of voor dat product een derde partij moet worden ingeschakeld. Bewaar beide antwoorden met onderbouwing in uw technische documentatie, zodat u bij een audit niet achteraf hoeft te reconstrueren waarom u tot uw conclusie kwam.
Het filter van artikel 6 lid 3: vier limitatieve gronden, eng uit te leggen
Een systeem dat onder Bijlage III valt, kan toch buiten hoog-risico blijven als aan één van vier gronden is voldaan en het systeem geen profilering verricht. De aanbieder doet dat zelf, moet de beoordeling vóór het in de handel brengen documenteren en het systeem registreren in de EU-databank.
Volgens de niet-bindende concept-richtsnoeren van 19 mei 2026 over de classificatie van hoog-risico AI kent artikel 6 lid 3 vier gronden waarop een aanbieder een systeem van hoog-risico kan uitzonderen: een enge procedurele taak, het verbeteren van het resultaat van een eerder afgeronde menselijke activiteit, het detecteren van besluitvormingspatronen of afwijkingen daarvan zonder de eerdere menselijke beoordeling te vervangen of te beïnvloeden zonder deugdelijke menselijke toetsing, en het verrichten van een voorbereidende taak. Randnummer (88) van dit concept stelt dat deze gronden limitatief maar alternatief zijn, dat er geen zelfstandige aanvullende risicotoets bestaat, en dat de gronden eng moeten worden uitgelegd omdat artikel 6 lid 3 een uitzondering vormt op regels die mede grondrechten beschermen. Randnummer (87) stelt dat het filter alleen geldt voor systemen onder artikel 6 lid 2 en niet voor systemen onder artikel 6 lid 1. Randnummer (89) stelt dat een systeem altijd hoog-risico blijft wanneer het profilering verricht. Randnummer (90) voegt toe dat het filter niet geldt wanneer het systeem deel uitmaakt van een complex systeem waarvan het gecombineerde beoogde doel of de gezamenlijke output een individueel besluit wezenlijk beïnvloedt, ook bij agentic AI. De randnummers (113) tot en met (116) van dit concept beschrijven dat het om een zelfbeoordeling door de aanbieder gaat, dat artikel 6 lid 4 verplicht tot documentatie van die beoordeling vóór het in de handel brengen en tot registratie in de EU-databank van artikel 71, en dat de beoordeling ten minste het beoogde doel, de reden waarom het systeem onder artikel 6 lid 2 valt, welke grond van artikel 6 lid 3 van toepassing is en waarom, en waarom er geen profilering plaatsvindt moet bevatten. Randnummer (117) van deze concept-richtsnoeren wijst op artikel 80 en artikel 99 wanneer een autoriteit vaststelt dat een systeem ten onrechte als niet hoog-risico is ingedeeld om de regels te omzeilen.
Concept-richtsnoeren classificatie hoog-risico AI (19 mei 2026), hoofdstuk Bijlage III, secties 2.7, 2.7.1, 2.7.3 en 2.7.4, randnummers (84) tot en met (90) en (113) tot en met (117)
Het filter is geen zachte uitweg maar een gedocumenteerd en zichtbaar besluit. U verlaat de hoog-risico verplichtingen van hoofdstuk III, maar u komt in ruil daarvoor in de openbare EU-databank te staan en uw motivering moet op elk moment aan de toezichthouder kunnen worden getoond. Voor afnemers is dat een geschenk: de concept-richtsnoeren moedigen gebruiksverantwoordelijken expliciet aan om in die databank te controleren of een leverancier zich op de uitzondering beroept.
Schrijf het filterdossier in vier vaste blokken: beoogd doel, waarom het onder Bijlage III valt, welke grond u inroept met onderbouwing, en waarom er geen profilering is. Beroep u nooit op het filter op basis van een gevoel dat het risico laag is, want die zelfstandige toets bestaat niet. Controleer bij inkoop altijd de EU-databank voordat u een leverancier gelooft die zegt dat zijn systeem niet hoog-risico is.
Artikel 6 kent twee gescheiden routes naar hoog-risico
Een AI-systeem is op twee manieren hoog-risico. Ofwel het is zelf een product of een veiligheidscomponent van een product onder de productwetgeving van Bijlage I en dat product moet een conformiteitsbeoordeling door een derde partij ondergaan (artikel 6 lid 1). Ofwel het valt onder een van de gebruikssituaties in Bijlage III (artikel 6 lid 2). De twee routes hebben eigen criteria en eigen toepassingsdatums.
De concept-richtsnoeren van de Europese Commissie over de classificatie van hoog-risico AI van 19 mei 2026, die uitdrukkelijk niet bindend zijn, stellen in randnummer (7) dat een AI-systeem in twee scenario's als hoog-risico geldt: ten eerste wanneer het bedoeld is om te worden gebruikt als veiligheidscomponent van een product, of zelf een product is, dat onder de in Bijlage I genoemde harmonisatiewetgeving van de Unie valt en waarvoor een conformiteitsbeoordeling door een derde partij is vereist, en ten tweede wanneer het valt onder een van de gebruikssituaties in de gebieden van Bijlage III. Randnummer (448) van diezelfde concept-richtsnoeren vermeldt dat de toepassingsdatums van artikel 113 met de AI Omnibus zijn verschoven naar 2 december 2027 voor de route van artikel 6 lid 2 en 2 augustus 2028 voor de route van artikel 6 lid 1.
Concept-richtsnoeren classificatie hoog-risico AI (19 mei 2026), hoofdstuk Algemene beginselen, sectie II, randnummer (7); sectie V, randnummer (448)
De twee routes zijn niet inwisselbaar. Bij de Bijlage I-route draait alles om de productwetgeving en om de vraag of een derde partij de conformiteit moet beoordelen, niet om de vraag of het systeem mensen beoordeelt. Bij de Bijlage III-route draait alles om het beoogde doel en de gebruikssituatie. Een systeem kan in theorie aan beide routes raken, maar u moet ze apart doorlopen. Ook het uitzonderingsmechanisme verschilt: het filter van artikel 6 lid 3 geldt volgens de concept-richtsnoeren alleen voor de Bijlage III-route en niet voor de Bijlage I-route.
Leg per AI-systeem in uw register vast welke route u heeft beoordeeld en met welke uitkomst. Begin bij de Bijlage I-vraag als er hardware, machines, medische hulpmiddelen of speelgoed in het spel zijn, en bij de Bijlage III-vraag als het systeem mensen of toegang tot voorzieningen raakt. Plan uw programma op de vroegste van de twee datums die op u van toepassing is.
Breed gepositioneerde en general purpose AI-systemen: een disclaimer is niet genoeg
Wie een systeem breed in de markt zet zonder de toepassing consequent te beperken, krijgt hoog-risico gebruikssituaties in het beoogde doel meegerekend. Alleen in de gebruiksvoorwaarden schrijven dat hoog-risico gebruik is uitgesloten, is onvoldoende als de rest van uw presentatie dat gebruik juist mogelijk maakt of aanmoedigt.
Volgens de niet-bindende concept-richtsnoeren van 19 mei 2026 over de classificatie van hoog-risico AI geldt, blijkens randnummer (12), dat wanneer de gebruiksaanwijzing, contractuele afspraken, gebruiksvoorwaarden, gebruiksbeleid, promotie- en verkoopmateriaal of technische documentatie het AI-systeem presenteren als breed toepasbaar over een veelheid van contexten en functies, en de toepassing niet consequent beperken of hoog-risico gebruik niet uitsluiten, het beoogde doel van het systeem geacht wordt ook hoog-risico gebruikssituaties te omvatten, waardoor het systeem als hoog-risico kwalificeert. Dat geldt volgens deze concept-richtsnoeren in het bijzonder wanneer dergelijk gebruik haalbaar en redelijkerwijs te voorzien is gezien de functionaliteiten en capaciteiten van het systeem. Hetzelfde randnummer stelt dat het enkel beweren, bijvoorbeeld in de gebruiksvoorwaarden, dat hoog-risico gebruik is uitgesloten, onvoldoende is wanneer de algehele presentatie, voorbeelden of productpositionering van de aanbieder dat gebruik feitelijk mogelijk maakt of bevordert, en dat beperkingen duidelijk, concreet en coherent in al het materiaal moeten worden beschreven.
Concept-richtsnoeren classificatie hoog-risico AI (19 mei 2026), hoofdstuk Algemene beginselen, sectie II.2, randnummer (12)
Dit raakt vooral aanbieders van brede assistenten, agents en platformen die zeggen dat ze niet voor HR, onderwijs of kredietbeoordeling zijn bedoeld, maar wel demo's, sjablonen of klantverhalen in precies die contexten tonen. De concept-richtsnoeren kijken naar het geheel van uw uitingen, niet naar de strengste zin in de kleine lettertjes. Voor afnemers betekent dit dat een leverancier die zich achter een clausule verschuilt, u niet ontslaat van uw eigen beoordeling.
Als u hoog-risico gebruik echt wilt uitsluiten, maak dat dan waar in het product en niet alleen op papier. Verwijder demo's en voorbeelden in uitgesloten domeinen, bouw technische of contractuele blokkades, en zorg dat sales, website en documentatie dezelfde grens trekken. Kunt u dat niet volhouden, ga dan uit van hoog-risico en richt uw dossier daarop in.
Hoog-risico betekent niet verboden, en niet hoog-risico betekent niet toegestaan
Classificatie beantwoordt één vraag: welke plichten uit hoofdstuk III gelden. Zij zegt niets over de vraag of het gebruik zelf rechtmatig is. Verboden praktijken, gegevensbescherming, consumentenrecht, productveiligheid en nationaal recht blijven onverkort gelden.
De concept-richtsnoeren van 19 mei 2026 over de classificatie van hoog-risico AI, die niet bindend zijn, stellen in randnummer (3) dat het feit dat een AI-systeem in deze richtsnoeren als voorbeeld is opgenomen niet betekent dat het gebruik ervan automatisch als rechtmatig moet worden beschouwd, aangezien dat gebruik nog steeds moet voldoen aan andere toepasselijke wetgeving, en in randnummer (4) dat het bereik van deze richtsnoeren beperkt is tot de vraag of een systeem hoog-risico is of niet. In het Bijlage III-hoofdstuk van dit concept stelt randnummer (68) dat het als hoog-risico kwalificeren onder artikel 6 lid 2 niet betekent dat het gebruik verboden is, maar dat die systemen aan passende vereisten zijn onderworpen. De randnummers (82) en (83) van dit concept lichten de woorden voor zover het gebruik is toegestaan op grond van toepasselijk Unierecht of nationaal recht toe en stellen dat het vallen onder een gebruikssituatie niet automatisch betekent dat het systeem rechtmatig in dat geval kan worden gebruikt, dat naast de verboden ook andere bepalingen van Unierecht of nationaal recht het gebruik kunnen beperken, en dat de AI-verordening op grond van artikel 2 lid 9 geldt onverminderd regels over consumentenbescherming, productveiligheid en gegevensbescherming.
Concept-richtsnoeren classificatie hoog-risico AI (19 mei 2026), hoofdstuk Algemene beginselen, randnummers (3) en (4); hoofdstuk Bijlage III, randnummer (68) en sectie 2.6, randnummers (82) en (83)
Er zijn twee denkfouten die u hiermee wegneemt. De eerste is dat een hoog-risico stempel gelijkstaat aan een verbod, waardoor projecten onnodig worden gestopt. De tweede, en de gevaarlijkste, is dat een uitkomst niet hoog-risico betekent dat u vrij baan heeft. Een systeem kan buiten hoog-risico vallen en tegelijk een verboden praktijk zijn, of stuklopen op gegevensbescherming of sectorregels.
Voer de classificatietoets en de rechtmatigheidstoets als twee gescheiden stappen uit en leg beide uitkomsten apart vast. Toets altijd eerst aan de verboden praktijken van artikel 5, die al sinds 2 februari 2025 handhaafbaar zijn, en pas daarna aan artikel 6. Sluit af met een korte toets op gegevensbescherming en sectorspecifiek recht, ook als het systeem niet hoog-risico blijkt.
Opgeknipte en agentische architecturen worden als geheel beoordeeld
U kunt de classificatie niet omzeilen door een hoog-risicofunctie in losse modules op te delen. Het concept beoordeelt de gecombineerde configuratie.
De niet-bindende concept-richtsnoeren van 19 mei 2026 bepalen in randnummers 75, 76 en 90 dat wanneer meerdere AI-systemen deel uitmaken van een complexer geheel en hun gecombineerde beoogde doel of gezamenlijke output een individuele beslissing wezenlijk beïnvloedt, die configuratie voor de classificatie als één AI-systeem wordt behandeld. Het concept stelt uitdrukkelijk dat opgeknipte architecturen als geheel worden beoordeeld om omzeiling door systeemontwerp te voorkomen, dat vrijstellingen voor afzonderlijke modules niet gelden wanneer de totale configuratie kernaspecten van de beslissing beïnvloedt, en dat dit ook geldt voor complexe onderling verbonden opstellingen zoals agentische AI-systemen waarvan de gekoppelde handelingen samen een hoog-risicodoel dienen. Volgens hetzelfde concept blijven strikt procedurele of voorbereidende functies wel vrijstelbaar wanneer zij werkelijk scheidbaar zijn van het systeem en geen output structureren of aanleveren die het onderzoek van een individueel geval wezenlijk beïnvloedt.
Sectie IV.2.3, randnummers 75 en 76, en sectie IV.2.7.1 randnummer 90
Dit raakt precies de moderne bouwwijze: een keten van agents, tools en modelaanroepen. Vier deelsystemen die elk afzonderlijk keurig voorbereidend zijn, vormen samen alsnog een hoog-risicosysteem zodra de keten in de praktijk de beslissing stuurt.
Beoordeel op ketenniveau, niet op componentniveau. Leg vast waar de scheidbaarheid werkelijk zit, en toon aan dat de vrijgestelde module los in gebruik kan worden gesteld zonder aan het hoog-risicodoel bij te dragen.
Wie de uitzondering inroept, moet dat vastleggen en registreren
De uitzondering is een zelfbeoordeling door de aanbieder, maar niet vrijblijvend. Het concept geeft vier verplichte onderdelen voor de beoordeling en koppelt daar registratie en toezicht aan.
De concept-richtsnoeren van 19 mei 2026 zijn niet bindend en beschrijven in randnummers 113 tot 117 dat toepassing van het filtermechanisme afhangt van een zelfbeoordeling door de aanbieder, dat de beoordeling moet worden gedocumenteerd voordat het systeem in de handel wordt gebracht of in gebruik wordt gesteld, en dat het systeem moet worden geregistreerd in de EU-databank van artikel 71 met het oog op traceerbaarheid van vrijgestelde systemen. De beoordeling moet volgens het concept vier onderdelen bevatten: een beschrijving van het beoogde doel, een beschrijving waarom het systeem onder artikel 6 lid 2 als hoog-risico zou kwalificeren, een beschrijving welke voorwaarde of voorwaarden van artikel 6 lid 3 van toepassing zijn en waarom, en een beschrijving waarom het systeem geen profilering verricht. De vastlegging moet op elk moment beschikbaar zijn voor de markttoezichtautoriteit, en het concept moedigt afnemers aan om het gebruik van de uitzondering in de artikel 71-databank te controleren als onderdeel van hun due diligence. Het concept wijst er verder op dat markttoezichtautoriteiten op grond van artikel 80 de classificatie kunnen evalueren, correctie kunnen eisen, en bij bewuste misclassificatie boetes op grond van artikel 99 kunnen opleggen.
Sectie IV.2.7.3 en 2.7.4, randnummers 113 tot 117
De vrijstelling verplaatst het werk, het neemt het niet weg. U ruilt het volledige hoofdstuk III-regime in voor een gedocumenteerde en openbaar traceerbare motivering die een toezichthouder kan opvragen en betwisten. Voor afnemers is de databank omgekeerd een controlemiddel bij inkoop.
Maak één vast sjabloon met de vier verplichte onderdelen en dateer de beoordeling vóór marktintroductie. Neem in inkooptrajecten standaard de vraag op of de leverancier zich op artikel 6 lid 3 beroept en of dat in de artikel 71-databank staat.
Het filtermechanisme van artikel 6 lid 3: vier alternatieve voorwaarden, eng uit te leggen
Een systeem dat onder een Bijlage III-usecase valt, kan toch buiten de hoog-risicoclassificatie blijven als het aan één van vier voorwaarden voldoet. De concept-richtsnoeren maken duidelijk dat dit geen brede ontsnappingsroute is.
Volgens de concept-richtsnoeren van de Europese Commissie van 19 mei 2026, die niet bindend zijn en zijn gepubliceerd voor stakeholderconsultatie, geldt het volgende (randnummers 84 tot 90): het filtermechanisme werkt alleen voor systemen die via artikel 6 lid 2 en Bijlage III hoog-risico zouden zijn en niet voor systemen die via artikel 6 lid 1 en Bijlage I hoog-risico zijn; de vier voorwaarden (nauwe procedurele taak, verbeteren van het resultaat van een afgeronde menselijke activiteit, detecteren van besluitvormingspatronen of afwijkingen zonder de eerdere menselijke beoordeling te vervangen of te beïnvloeden zonder deugdelijke menselijke toetsing, en voorbereidende taak) zijn uitputtend maar alternatief; er bestaat naast die voorwaarden geen zelfstandige extra risicotoets; en omdat artikel 6 lid 3 een uitzondering is op regels die mede grondrechten beschermen, moeten de voorwaarden eng worden uitgelegd en steeds worden gelezen in het licht van de eis dat het systeem de uitkomst van de besluitvorming niet wezenlijk beïnvloedt.
Sectie IV.2.7 en 2.7.1, randnummers 84 tot 90
De praktische vraag is niet of uw systeem gevoelsmatig risicoarm is, maar of het aantoonbaar binnen één van de vier omschreven taaktypen past. Het ontbreken van een aparte risicotoets snijdt twee kanten op: u hoeft geen algemene risicoafweging te maken, maar u kunt zich er ook niet op beroepen als geen van de vier voorwaarden past.
Werk per systeem uit welke van de vier voorwaarden u inroept en waarom, in de taal van het document zelf. Kiest u er meerdere, benoem ze dan afzonderlijk. Voelt de redenering gezocht, ga er dan van uit dat de enge uitleg tegen u werkt en behandel het systeem als hoog-risico.
Een mens in de lus maakt een systeem niet laag-risico
Menselijke betrokkenheid verandert het beoogde doel niet en heeft daarom geen invloed op de classificatie onder artikel 6 lid 2. Menselijk toezicht is een nalevingsvereiste voor hoog-risico systemen, geen ontsnapping aan de kwalificatie.
De concept-richtsnoeren van 19 mei 2026 over de classificatie van hoog-risico AI, die niet bindend zijn, stellen in randnummer (70) dat de enige relevante bepalende factor voor kwalificatie onder artikel 6 lid 2 is of het beoogde doel van het systeem een van de in Bijlage III genoemde gebruikssituaties omvat, dat menselijke betrokkenheid het doel en het gebied waarin een systeem wordt gebruikt niet kan veranderen, en dat menselijke betrokkenheid dus geen effect heeft op de kwalificatie. Datzelfde randnummer stelt dat menselijk toezicht juist een voorwaarde is voor naleving van de regels voor hoog-risico systemen op grond van artikel 14. Randnummer (71) van dit concept voegt toe dat de aard en mate van menselijke betrokkenheid wel een rol kunnen spelen bij het filter van artikel 6 lid 3, maar uitsluitend om aan te tonen dat de taken eng procedureel of voorbereidend zijn of dat het systeem alleen een eerder afgeronde menselijke activiteit verbetert, en dat een aanbieder een systeem niet als laag risico kan bestempelen door er simpelweg een eis van menselijke betrokkenheid aan toe te voegen.
Concept-richtsnoeren classificatie hoog-risico AI (19 mei 2026), hoofdstuk Bijlage III, sectie 2.1, randnummers (70) en (71)
Dit ontkracht het meest gebruikte verweer in de praktijk, namelijk dat er toch altijd een mens naar kijkt. Die zin verandert niets aan de kwalificatie. Menselijke betrokkenheid is pas relevant wanneer u kunt laten zien dat het systeem zelf slechts een enge procedurele of voorbereidende rol speelt, en dat is een veel zwaardere test dan een goedkeuringsknop.
Schrap de zin dat er een mens in de lus zit uit uw classificatiemotivering. Beschrijf in plaats daarvan wat het systeem precies doet in de besluitvorming en op welk moment. Gebruik de mate van menselijke betrokkenheid alleen als onderbouwing binnen een van de vier gronden van artikel 6 lid 3, en bewaar bewijs dat die toetsing ook echt inhoudelijk is.
Menselijk toezicht is een nalevingseis voor hoog-risicosystemen, geen manier om aan de classificatie te ontkomen. Menselijke betrokkenheid telt alleen mee bij de vraag welke taak het systeem verricht.
In de niet-bindende concept-richtsnoeren van 19 mei 2026 stelt de Commissie in randnummers 70 en 71 dat voor de classificatie onder artikel 6 lid 2 uitsluitend beslissend is of het beoogde doel van het systeem onder een Bijlage III-usecase valt. Menselijke betrokkenheid kan het doel en het gebied van beoogd gebruik niet veranderen en heeft daarom geen invloed op die classificatie; menselijk toezicht is juist een voorwaarde voor naleving op grond van artikel 14. De aard en mate van menselijke betrokkenheid kunnen volgens het concept wél een rol spelen bij het filtermechanisme, maar alleen om aan te tonen dat de taken van het systeem nauw procedureel of voorbereidend zijn of enkel een eerder afgeronde menselijke activiteit verbeteren. Het concept voegt uitdrukkelijk toe dat een aanbieder een systeem niet als laag-risico kan bestempelen door er eenvoudigweg een eis van menselijke betrokkenheid aan toe te voegen.
De veelgehoorde geruststelling dat er altijd een mens meekijkt, verandert niets aan de classificatie. Sterker nog, in de voorbeelden in het document wordt formeel menselijk toezicht juist afgeserveerd wanneer de output in de praktijk zwaar doorweegt in de uitkomst.
Onderbouw uw classificatie op het beoogde doel en niet op uw werkproces. Wilt u menselijke betrokkenheid gebruiken in de argumentatie, koppel die dan aan het taaktype van het systeem en toon aan dat de menselijke beoordeling inhoudelijk en volledig is, niet een formaliteit.
Verbeteren is bewust iets anders dan herzien
De tweede voorwaarde eist een afgeronde menselijke activiteit met een resultaat, dat het systeem alleen verfijnt. Een wezenlijk andere uitkomst valt er niet onder.
De concept-richtsnoeren van 19 mei 2026 zijn een niet-bindend concept en stellen in randnummers 94 tot 96 dat voor artikel 6 lid 3 onder b drie cumulatieve elementen aanwezig moeten zijn: een menselijke activiteit die is afgerond, een resultaat dat daaruit voortkwam, en verbetering van dat resultaat door het AI-systeem. Het systeem mag de menselijke activiteit dus niet vervangen of zelfstandig uitvoeren. Het concept wijst erop dat de Uniewetgever bewust het woord verbeteren koos in plaats van herzien, zodat het systeem niet bedoeld mag zijn om een wezenlijk ander resultaat te leveren maar om de activiteit te verifiëren of te verfijnen, en dat elke verbetering de rechten, bescherming, juridische of economische positie van de betrokken personen niet mag veranderen. Als voorbeeld dat níet onder de uitzondering valt noemt het concept een systeem dat een door een mens gemaakt besluit, plan of ontwerp controleert en een wezenlijk andere oplossing aandraagt. Als voorbeelden die wel een hulpfunctie vervullen noemt het concept systemen die fouten of tegenstrijdigheden in afgerond menselijk werk signaleren als kwaliteitsborging, systemen die conclusies koppelen aan bewijsstukken om de navolgbaarheid van een beslissing te versterken zonder het menselijk oordeel te vervangen, en systemen die door mensen gevalideerde inhoud omzetten voor interoperabiliteit of toegankelijkheid.
Sectie IV.2.7.1 onder b, randnummers 94 tot 96
Deze voorwaarde is smaller dan zij klinkt. Een schrijfassistent die de formulering van een afgerond oordeel aanscherpt past erin; een tweede-meningmodel dat het oordeel overdoet niet, hoe nuttig dat inhoudelijk ook is.
Zorg dat de volgorde in uw proces aantoonbaar is: het menselijk oordeel is eerst vastgelegd, daarna komt het systeem eraan te pas. Leg vast dat scores, conclusies en uitkomsten niet door het systeem worden gewijzigd.
Het beoogde doel is het anker van de classificatie
Het beoogde doel bepaalt of een systeem hoog-risico is. Dat doel wordt niet alleen bepaald door de technische documentatie, maar ook door de gebruiksaanwijzing, promotiemateriaal, verkoopmateriaal en uitspraken van de aanbieder. Redelijkerwijs te voorzien misbruik valt per definitie buiten het beoogde doel.
De concept-richtsnoeren van 19 mei 2026 over de classificatie van hoog-risico AI, die niet bindend zijn, stellen in randnummer (10) dat het beoogde doel van een AI-systeem een belangrijke rol speelt bij de kwalificatie als hoog-risico en dat het beoogde doel volgens artikel 3 lid 12 het gebruik is waarvoor de aanbieder het systeem bedoelt, inclusief de specifieke context en gebruiksomstandigheden, zoals gespecificeerd in de gebruiksaanwijzing, promotie- of verkoopmateriaal, uitspraken en technische documentatie. Randnummer (11) van dat concept voegt toe dat aanbieders het beoogde gebruik duidelijk moeten beschrijven, inclusief de functionaliteiten, zonder enige ambiguïteit over reikwijdte en beoogd gebruik. Randnummer (13) van deze concept-richtsnoeren legt de beoordeling bij de aanbieder, onder toezicht van de bevoegde markttoezichtautoriteiten.
Concept-richtsnoeren classificatie hoog-risico AI (19 mei 2026), hoofdstuk Algemene beginselen, sectie II.2, randnummers (10), (11) en (13)
Marketing is hier juridisch materiaal. Wat uw website, salesdeck of demo belooft, telt mee bij het vaststellen van het beoogde doel, ook als de technische documentatie voorzichtiger is geformuleerd. Een verschil tussen wat het systeem in de praktijk doet en hoe het doel is beschreven, beschermt u niet.
Laat één persoon de beschrijving van het beoogde doel beheren en laat gebruiksaanwijzing, technische documentatie, website, salesmateriaal en demoscripts jaarlijks tegen elkaar controleren. Beschrijf ook uitdrukkelijk welke contexten en toepassingen wel en niet zijn beoogd, en houd die tekst identiek in alle kanalen.
Eerst de definitievraag: is het wel een AI-systeem?
Voordat u aan classificatie toekomt, moet het systeem voldoen aan de definitie van AI-systeem in artikel 3 lid 1. Niet elke softwaretoepassing en niet elk geautomatiseerd besluitvormingssysteem valt onder de AI-verordening.
Volgens de niet-bindende concept-richtsnoeren van 19 mei 2026 over de classificatie van hoog-risico AI moet een systeem, voordat het als hoog-risico kan worden aangemerkt, eerst kwalificeren als AI-systeem in de zin van artikel 3 lid 1 van de AI-verordening (randnummer 8). Randnummer (9) van dat concept stelt uitdrukkelijk dat niet elke softwaretoepassing of elk geautomatiseerd besluitvormingssysteem binnen het bereik van de verordening valt, en verwijst voor de uitleg van de definitie naar de afzonderlijke richtsnoeren over de definitie van een AI-systeem (C(2025) 5053).
Concept-richtsnoeren classificatie hoog-risico AI (19 mei 2026), hoofdstuk Algemene beginselen, sectie II.1, randnummers (8) en (9)
Dit is een echte voorvraag en geen formaliteit. Klassieke regelgebaseerde software, vaste rekenregels en eenvoudige automatisering die niet uit input afleidt hoe output te genereren, komen niet aan de classificatievraag toe. Tegelijk is dit geen ontsnappingsroute: de definitierichtsnoeren zijn ruim en de bewijslast dat iets buiten de definitie valt ligt praktisch bij u.
Neem in uw AI-register een expliciet veld op voor de definitietoets, met de motivering waarom een systeem wel of niet een AI-systeem is. Doe die toets voordat u tijd steekt in de Bijlage I- of Bijlage III-analyse, en leg het resultaat vast zodat u het bij een controle kunt tonen.
Alleen de beoordeling van natuurlijke personen valt binnen deze usecases
Systemen die uitsluitend rechtspersonen beoordelen, vallen buiten de betrokken Bijlage III-usecases. Zelfstandigen en eenmanszaken tellen echter wel als natuurlijke personen.
De concept-richtsnoeren van 19 mei 2026, gepubliceerd als niet-bindend concept, verduidelijken in randnummers 72 tot 74 dat een natuurlijke persoon iets anders is dan een rechtspersoon en dat het begrip niet beperkt is tot consumenten: eenmanszaken, vrije beroepen en andere zelfstandigen gelden ook als natuurlijke personen ten aanzien van hun commerciële activiteit, waaronder personen die beroepsmatig optreden zoals consultants, ontwerpers en journalisten. Een systeem dat natuurlijke personen beoordeelt valt binnen de usecase ongeacht of het daarnaast ook rechtspersonen beoordeelt; systemen die uitsluitend rechtspersonen of ondernemingen beoordelen vallen erbuiten. Het concept geeft daarbij als voorbeeld dat een systeem dat de kredietwaardigheid van ondernemingen beoordeelt op basis van bedrijfsgegevens, balansen en jaarrekeningen niet als beoordeling van een natuurlijke persoon geldt, en dat ook de eigenaar die wordt beoordeeld ter dekking van een bedrijfslening buiten punt 5(b) valt omdat de onderneming en niet het individu de primaire begunstigde van het krediet is.
De grens loopt niet langs sector of gevoeligheid, maar langs de vraag wie er wordt beoordeeld. Let op de valkuil aan de andere kant: zodra uw B2B-systeem ook zzp'ers en eenmanszaken beoordeelt, zit u alsnog binnen de usecase.
Leg in het beoogde doel eenduidig vast of natuurlijke personen tot de te beoordelen populatie behoren. Sluit dat gebruik contractueel en technisch uit als u buiten de usecase wilt blijven, want gemengd gebruik trekt het geheel naar binnen.
Voorbereidend of beslissend: algemene input mag, een concrete aanbeveling niet
De voorbereidende taak van artikel 6 lid 3 onder d gaat vooraf aan de beoordeling. Zodra het systeem het concrete dossier evalueert of een aanbeveling doet, is de uitzondering weg.
Volgens de niet-bindende concept-richtsnoeren van 19 mei 2026 verwijst het begrip voorbereidend in artikel 6 lid 3 onder d naar taken die plaatsvinden vóór het eigenlijke beoordelingsproces, wat het onderscheidt van de nauwe procedurele taak van punt a die ook tijdens de beoordeling mag plaatsvinden zolang zij duidelijk afgebakend is (randnummers 103 en 104). Het concept noemt als voorbeelden uit overweging 53 het indexeren, zoeken, verwerken en koppelen van gegevens: taken die structuur toevoegen aan de input maar zelf geen beoordeling met een uitkomst leveren (randnummer 106). Doorslaggevend is volgens randnummer 107 de rol van de taak in het besluitvormingsproces en de nabijheid tot de uiteindelijke menselijke beslissing. Randnummer 108 voegt toe dat output die de beoordeling van een menselijke behandelaar voedt alleen voorbereidend kan zijn als het gaat om algemene input of aanvullende informatie, en dat een systeem dat een concrete aanbeveling of evaluatie van het geval produceert een beslissende rol speelt en daarom niet voorbereidend is.
Sectie IV.2.7.1 onder d, randnummers 103 tot 108
De scheidslijn is bruikbaar in de praktijk: informatie klaarzetten mag, het geval duiden niet. Een systeem dat wetsartikelen, jurisdictie en interne richtlijnen aanreikt blijft voorbereidend; hetzelfde systeem dat daaruit een conclusie voor dit dossier trekt, is dat niet meer.
Test uw systeem op één vraag: produceert de output iets dat specifiek is voor dit dossier en de kant van de uitkomst op wijst? Zo ja, ga uit van hoog-risico. Bouw waar mogelijk een harde scheiding tussen informatieontsluiting en beoordelingslogica.
Profilering blokkeert de uitzondering altijd, ook als een voorwaarde wel past
Zodra het systeem profileert, is de vrijstelling van artikel 6 lid 3 uitgesloten. De concept-richtsnoeren geven drie cumulatieve elementen waaraan u dat toetst.
De concept-richtsnoeren van 19 mei 2026, die een niet-bindend conceptdocument zijn, lichten in randnummers 89 en 109 tot 112 toe dat een in Bijlage III genoemd systeem altijd hoog-risico blijft wanneer het profilering verricht in de zin van artikel 4 lid 4 AVG, artikel 3 lid 4 van Richtlijn (EU) 2016/680 of artikel 3 lid 5 van Verordening (EU) 2018/1725. Profilering bestaat volgens het concept uit drie cumulatieve elementen: geautomatiseerde verwerking, verwerking van persoonsgegevens, en het doel om persoonlijke aspecten van een natuurlijke persoon te evalueren. Het eerste element is bij AI-systemen volgens het concept altijd vervuld, zodat de aanbieder vooral moet vaststellen of er persoonsgegevens de invoer vormen en of persoonlijke aspecten worden geëvalueerd. Het concept voegt toe dat een eenvoudige indeling op kenmerken zoals leeftijd, geslacht of lengte niet zonder meer profilering oplevert, omdat er een vorm van voorspelling, beoordeling of gevolgtrekking bij moet komen.
Sectie IV.2.7.1 randnummer 89 en sectie IV.2.7.2, randnummers 109 tot 112
Het profileringsverbod is de scherpste rem op het filtermechanisme. Veel systemen die op het eerste gezicht een nette voorbereidende of procedurele taak doen, sneuvelen hier alsnog omdat zij onderweg iets voorspellen of beoordelen over een mens. Let op: dat kan ook een ander mens zijn dan de betrokkene van de beslissing, bijvoorbeeld de beoordelaar zelf.
Beschrijf in uw dossier expliciet welke gegevens het systeem inleest, of dat persoonsgegevens zijn, en of er ergens een voorspelling, score of gevolgtrekking over een persoon ontstaat. Overweeg anonimisering of aggregatie aan de bron als u de uitzondering wilt behouden.
Veiligheidscomponent is een zelfstandig AI Act-begrip
Voor de classificatie telt uitsluitend de definitie van veiligheidscomponent in artikel 3 lid 14 AI Act. Definities van datzelfde begrip in de sectorale productwetgeving zijn hier niet relevant.
Volgens de concept-richtsnoeren van 19 mei 2026, die niet bindend zijn en nog kunnen wijzigen, is de definitie van veiligheidscomponent in artikel 3 lid 14 AI Act een autonome definitie met een eigen betekenis, los van definities van veiligheidscomponent in andere harmonisatiewetgeving van de Unie. De concept-richtsnoeren stellen dat deze definitie een uniforme uitleg van het begrip in alle sectoren van Bijlage I waarborgt, en dat bij de beoordeling of een AI-systeem een veiligheidscomponent is uitsluitend artikel 3 lid 14 AI Act relevant is en niet de definitie in enige in Bijlage I opgesomde wetgeving. Artikel 3 lid 14 omschrijft een veiligheidscomponent als een onderdeel van een product of van een AI-systeem dat een veiligheidsfunctie voor dat product of AI-systeem vervult, of waarvan het uitvallen of gebrekkig functioneren de gezondheid en veiligheid van personen of eigendom in gevaar brengt.
Concept-richtsnoeren Annex I, punten (32) en (33)
Dit is de meest onderschatte valkuil van het hele hoofdstuk. Veel technische teams werken al jaren met het begrip veiligheidscomponent zoals hun eigen sectorale norm dat definieert, bijvoorbeeld in de machinerichtlijn-traditie of de medische-hulpmiddelenwereld. Die reflex leidt tot een verkeerde uitkomst. Het AI Act-begrip is breder dan menig sectorale definitie, juist omdat de faalroute erin zit. Een component die in uw sectordossier nooit als veiligheidscomponent is aangemerkt, kan dat onder de AI Act wel zijn.
Voer de veiligheidscomponent-toets opnieuw uit met alleen de tekst van artikel 3 lid 14 in de hand, ook als uw product al jaren een sectoraal veiligheidsdossier heeft. Laat een tweede persoon die niet in de sectorale traditie zit meelezen, want die ziet eerder waar de AI Act ruimer is dan uw gewoonte.
Twee routes naar veiligheidscomponent: bedoeling of gevolg
Een AI-systeem is veiligheidscomponent langs twee alternatieve routes. Ofwel het is bedoeld om een veiligheidsfunctie te vervullen, ofwel het uitvallen of gebrekkig functioneren ervan brengt gezondheid, veiligheid of eigendom in gevaar.
De concept-richtsnoeren van 19 mei 2026 zijn een conceptdocument zonder bindende werking en lezen artikel 3 lid 14 als twee alternatieve scenario's. In het eerste scenario vervult het AI-systeem een veiligheidsfunctie, wat betekent dat het beoogde doel, zoals bepaald door de aanbieder, is om risico's voor de gezondheid en veiligheid van personen of eigendom te voorkomen of te beperken. De concept-richtsnoeren merken daarbij op dat het enkele feit dat een AI-systeem is geintegreerd in of werkt binnen een product dat aan veiligheidsregelgeving is onderworpen, op zichzelf niet betekent dat het een veiligheidsfunctie vervult. In het tweede scenario is het systeem veiligheidscomponent omdat het uitvallen of gebrekkig functioneren ervan de gezondheid en veiligheid van personen of eigendom in gevaar kan brengen. De concept-richtsnoeren vatten dit samen in een tabel: de veiligheidsfunctie is intentiegebaseerd en sterk door de aanbieder gestuurd, met als bewijs de gebruiksaanwijzing, technische documentatie en promotiemateriaal, terwijl de faalroute gevolg- en risicogebaseerd is en minder door de aanbieder wordt gestuurd, met als bewijs de systeemarchitectuur en de faalwijzen en hun effecten.
Concept-richtsnoeren Annex I, punten (34) tot en met (44), inclusief tabel 1
De eerste route kunt u sturen, de tweede niet. Dat is het hele punt. Een aanbieder bepaalt zelf het beoogde doel en kan dus in de documentatie kiezen om geen veiligheidsfunctie te claimen. De concept-richtsnoeren sluiten die uitweg af met de faalroute, die kijkt naar wat er gebeurt als het misgaat, ongeacht wat u opschreef. De richtsnoeren noemen als vormen van falen onder meer onjuiste uitkomsten zoals fout-positieven en fout-negatieven, functieverlies, prestatie-instabiliteit of drift, timing- of latentiefouten, en verkeerde classificatie die tot gevaarlijke besturingsbeslissingen leidt. Let ook op de ondergrens: de kans op falen mag geen louter theoretische mogelijkheid zijn, en reputatieschade, zuiver financieel verlies, geringe dienstverslechtering of ongemak zonder veiligheidsgevaar tellen niet mee.
Documenteer de twee routes apart. Voor de veiligheidsfunctie legt u vast wat u in gebruiksaanwijzing, technische documentatie en verkoopmateriaal als beoogd doel communiceert, en houdt u die drie consistent. Voor de faalroute maakt u een faalwijzenanalyse waarin u per faalvorm noteert of er een pad naar letsel of schade aan eigendom bestaat. Die analyse is ook uw bewijsstuk richting een markttoezichthouder.
AI Act-eisen integreren in bestaande risico- en kwaliteitssystemen
De AI Act laat toe dat u AI-specifieke risico's toevoegt aan uw bestaande risicobeheer- en kwaliteitsmanagementsystemen, zodat u binnen een enkel compliance-raamwerk kunt werken.
Volgens de concept-richtsnoeren van 19 mei 2026, die uitdrukkelijk als concept voor stakeholderfeedback zijn gepubliceerd en geen bindende werking hebben, voorziet de AI Act in mechanismen om de nalevingslast voor marktdeelnemers te beperken. De concept-richtsnoeren noemen artikel 8 lid 2 AI Act over het samenspel met de sectorale wetgeving, artikel 9 lid 10 AI Act over risicobeheer en artikel 17 lid 3 AI Act over kwaliteitsbeheer, die marktdeelnemers toestaan om, waar nodig en passend, een beoordeling van AI-specifieke risico's toe te voegen aan reeds bestaande risico- en kwaliteitsmanagementsystemen. Artikel 40 AI Act vereist daarnaast dat geharmoniseerde normen onder de AI Act consistent zijn met normen die zijn ontwikkeld onder de harmonisatiewetgeving van Bijlage I. De concept-richtsnoeren stellen dat deze mechanismen marktdeelnemers in staat stellen om binnen een enkel nalevingskader te voldoen aan zowel de AI Act als de harmonisatiewetgeving, waarmee dubbel werk wordt vermeden terwijl een hoog beschermingsniveau voor gezondheid, veiligheid en grondrechten behouden blijft.
Concept-richtsnoeren Annex I, punten (61) en (62)
Dit is het meest geruststellende punt van het hele hoofdstuk, en tegelijk het meest onderbenutte. Fabrikanten die al een volwassen kwaliteitsmanagementsysteem hebben, bijvoorbeeld onder een sectorale norm, hoeven daar geen tweede systeem naast te zetten. U breidt uit wat er staat. Dat scheelt niet alleen kosten, het scheelt vooral de fragmentatie waarbij uw AI-dossier los komt te staan van uw productdossier en de twee elkaar gaan tegenspreken bij een audit. De praktische winst zit in een gezamenlijke risicoregistratie waarin AI-risico's als categorie zijn opgenomen, niet als apart document.
Breid uw bestaande risicoregister en kwaliteitshandboek uit met een AI-hoofdstuk in plaats van een parallel AI-managementsysteem op te tuigen. Wijs een eigenaar aan die zowel het sectorale dossier als het AI-dossier beheert, zodat wijzigingen aan het product automatisch de AI-beoordeling raken.
Ook losse software, updates en remote diensten kunnen hoog-risico zijn
Artikel 6 lid 1 geldt ongeacht of het AI-systeem in het product is ingebed of zelfstandig op de markt komt. Een software-update, add-on of remote dienst kan daardoor zelfstandig hoog-risico zijn.
De concept-richtsnoeren van 19 mei 2026 zijn niet bindend en nog in consultatie, en verduidelijken dat artikel 6 lid 1 AI Act van toepassing is ongeacht of het AI-systeem in het product is ingebed dan wel zelfstandig in de handel wordt gebracht of in gebruik wordt gesteld. Een AI-systeem dat bijvoorbeeld wordt geleverd als software-update, als add-on of als remote dienst kan daarom als hoog-risico worden aangemerkt op grond van artikel 6 lid 1, mits aan alle voorwaarden van die bepaling is voldaan. De concept-richtsnoeren onderscheiden daarnaast het geval waarin het AI-systeem zelf het product is: dat is het geval wanneer het zelfstandig in de handel wordt gebracht, een eigen beoogd doel heeft en rechtstreeks wordt gereguleerd door de in Bijlage I opgesomde harmonisatiewetgeving. Als voorbeeld noemen de concept-richtsnoeren Verordening (EU) 2023/1230, de machineverordening, waarin de definitie van machineproducten uitdrukkelijk bepaalde software omvat, die daarmee zelf een gereguleerd product kan zijn en als hoog-risico kan worden aangemerkt mits een conformiteitsbeoordeling door een derde partij vereist is. Verder stellen de concept-richtsnoeren dat een AI-systeem dat een veiligheidscomponent is van een gereguleerd product moet worden beoordeeld als onderdeel van de algehele veiligheidsbeoordeling van dat product, ook wanneer het daarnaast zelfstandig in de handel wordt gebracht.
Concept-richtsnoeren Annex I, punten (22), (30) en (31)
Dit raakt een groeiende groep leveranciers die zichzelf buiten het regime waant omdat zij geen fysiek product maken. Wie een AI-module levert die achteraf in een machine, lift of voertuig wordt geladen, kan wel degelijk aanbieder van een hoog-risico AI-systeem zijn. Hetzelfde geldt voor over-the-air updates die een bestaande veiligheidsfunctie wijzigen of toevoegen. De keerzijde is dat uw beoordeling niet losstaat van het product: de concept-richtsnoeren vragen dat uw component wordt meegewogen in de algehele veiligheidsbeoordeling van het product waarin het landt. Dat vraagt afstemming met de fabrikant en heldere afspraken over informatie-uitwisseling.
Breng in kaart in welke gereguleerde producten uw software terechtkomt en welke veiligheidsrelevante functies uw updates raken. Leg contractueel vast welke informatie u aan de productfabrikant levert voor diens veiligheidsbeoordeling, en behandel een update die een veiligheidsfunctie wijzigt als een moment om de classificatie opnieuw te toetsen.
Wanneer een afnemer of distributeur zelf aanbieder wordt
Distributeurs, importeurs, gebruiksverantwoordelijken en andere derden kunnen de plichten van een aanbieder krijgen. Dat gebeurt bij het aanbrengen van uw eigen naam of merk, bij een wezenlijke wijziging van een hoog-risico systeem, en bij het wijzigen van het beoogde doel van een niet hoog-risico systeem waardoor het alsnog hoog-risico wordt.
De concept-richtsnoeren van 19 mei 2026 over de classificatie van hoog-risico AI, die niet bindend zijn, wijzen er in randnummer (14) op dat distributeurs, importeurs, gebruiksverantwoordelijken of andere derden op grond van artikel 25 lid 1 onderworpen kunnen raken aan de plichten van een aanbieder wanneer zij, ten eerste, hun naam of merk aanbrengen op een reeds in de handel gebracht of in gebruik gesteld hoog-risico AI-systeem, ten tweede, een wezenlijke wijziging aanbrengen in een reeds in de handel gebracht of in gebruik gesteld hoog-risico AI-systeem zodanig dat het een hoog-risico AI-systeem blijft, of ten derde, het beoogde doel wijzigen van een AI-systeem, met inbegrip van een AI-systeem voor algemene doeleinden, dat niet als hoog-risico was geclassificeerd, zodanig dat het systeem daardoor wel een hoog-risico AI-systeem wordt onder artikel 6. In een voetnoot bij dat randnummer kondigt dit concept aan dat de Commissie afzonderlijke richtsnoeren voorbereidt over de verantwoordelijkheden in de AI-waardeketen onder artikel 25.
Concept-richtsnoeren classificatie hoog-risico AI (19 mei 2026), hoofdstuk Algemene beginselen, sectie II.2, randnummer (14) en bijbehorende voetnoot 6
De derde situatie is de meest onderschatte. Een organisatie die een breed inzetbaar model of assistent inkoopt en dat vervolgens richt op werving, beoordeling van medewerkers of toegang tot voorzieningen, verandert daarmee het beoogde doel en kan zo zelf aanbieder van een hoog-risico systeem worden, met het volledige pakket verplichtingen. Ook white labelling onder eigen merk is voldoende, zonder dat u een regel code aanpast.
Voer een vaste toets in voordat u een ingekocht AI-systeem herbrandt, aanpast of op een nieuw doel richt. Beoordeel per wijziging of u in een van de drie situaties van artikel 25 lid 1 terechtkomt en leg die beoordeling vast. Maak dit onderdeel van uw inkoop- en wijzigingsproces, niet van een eenmalige projectcheck.
Modulekeuze verandert de classificatie niet
Dat de fabrikant mag kiezen voor interne controle op basis van geharmoniseerde normen, doet niets af aan de hoog-risico classificatie. De classificatie volgt de mate van verhoogd toezicht die de productwetgeving eist, niet de gekozen procedure.
De concept-richtsnoeren van 19 mei 2026 hebben de status van niet-bindend concept en verduidelijken de tweede voorwaarde als volgt. De AI Act bepaalt niet zelf welke conformiteitsbeoordelingsprocedures gelden, maar steunt op de keuze van procedures in de harmonisatiewetgeving van Bijlage I. Besluit 768/2008/EG kent acht hoofdmodules A tot en met H. Voor alle modules behalve module A is betrokkenheid van een aangemelde instantie vereist; module C vereist die betrokkenheid niet maar wordt altijd gecombineerd met modules die dat wel doen; bij modules A1 en A2 is een aangemelde instantie of geaccrediteerde interne instantie alleen in de productiefase vereist. De concept-richtsnoeren stellen vervolgens uitdrukkelijk dat het feit dat de harmonisatiewetgeving een fabrikant toestaat te steunen op interne controle op basis van geharmoniseerde normen, als een van de procedurele opties, de classificatie van een AI-systeem als hoog-risico onder artikel 6 lid 1 niet raakt. De keuze van de module geeft de fabrikant procedurele flexibiliteit om conformiteit aan te tonen, maar geeft hem geen bevoegdheid om de risicoclassificatie onder de AI Act te bepalen. Doorslaggevend is dat het product volgens de wetgeving van Bijlage I aan verhoogd regelgevend toezicht is onderworpen voordat het rechtmatig in de handel mag worden gebracht, welk toezicht wordt verzekerd door de eis van een conformiteitsbeoordeling door een derde partij of gelijkwaardige mechanismen, waaronder interne controle onder verplichte toepassing van in het Publicatieblad bekendgemaakte geharmoniseerde normen. De concept-richtsnoeren wijzen erop dat de Uniewetgever deze logica uitdrukkelijk heeft bevestigd in overweging 15 van Verordening (EU) 2025/2509 inzake de veiligheid van speelgoed.
Concept-richtsnoeren Annex I, punten (50) tot en met (59)
Hier sluiten de concept-richtsnoeren de meest voor de hand liggende ontsnappingsroute af. De redenering die veel fabrikanten hoopten te voeren luidde: wij passen geharmoniseerde normen toe, dus wij gebruiken module A, dus er komt geen derde partij aan te pas, dus wij zijn niet hoog-risico. De Commissie draait dat om. Niet de gekozen procedure is bepalend, maar het beschermingsniveau dat de wetgever voor dat producttype nodig achtte. Wie in zijn compliance-planning op de module-A route heeft gerekend, moet die aanname nu herzien. De speelgoed- en machineverordeningen worden expliciet genoemd als sectoren waar dit speelt.
Toets uw classificatie niet op de module die u feitelijk gebruikt, maar op de vraag of de wetgever voor uw producttype verhoogd toezicht heeft voorgeschreven. Als uw sectorale wetgeving interne controle alleen toestaat onder verplichte toepassing van geharmoniseerde normen, ga er dan van uit dat u in het hoog-risico regime valt en plan uw AI Act-traject daarop in.
Classificatieroute voor zelfstandige hoog-risico AI-systemen onder Artikel 6 lid 2 en Bijlage III.
Het bedoelde doel valt onder een usecase in Bijlage III.
De classificatie loopt via Artikel 6 lid 2.
Een in Bijlage III genoemd systeem kan onder strikte voorwaarden buiten hoog-risico vallen via Artikel 6 lid 3, behalve wanneer het profileert. De beoordeling en registratie moeten worden vastgelegd.
De kernregels van Hoofdstuk III, afdelingen 1 tot en met 3, voor systemen onder Artikel 6 lid 2 en Bijlage III worden van toepassing op 2 december 2027.
Gewijzigd artikel 113, artikel 6, lid 2, en de toepassingsdatum van Bijlage III
De latere toepassingsdatum verandert de classificatievraag niet. Een vroeg classificatiedossier voorkomt dat ontwerp- en inkoopbesluiten zonder bewijs worden genomen.
Leg nu bedoeld doel, Bijlage III-punt, Artikel 6 lid 3-toets, profiling en gekozen registratiepad vast.
Artikel 6, leden 2 tot en met 4, artikel 49 en Bijlage III
Kwaliteits- en governance-eisen aan trainings-, validatie- en testdata van hoog-risico AI.
Het hoog-risico systeem wordt getraind met data; de aanbieder stelt de datasets samen, de gebruiksverantwoordelijke bewaakt relevante inputdata.
Voor bijzondere categorieën persoonsgegevens geldt de strikte uitzondering van Artikel 10 lid 5 (biasdetectie en -correctie onder voorwaarden).
Artikel 10 vereist datasets die passen bij het beoogde doel, met governance over herkomst en samenstelling, aandacht voor representativiteit, fouten en volledigheid, en onderzoek naar mogelijke bias met passende maatregelen.
Voor de Bijlage III-route geldt deze eis vanaf 2 december 2027; voor hoog-risico AI in gereguleerde producten (Bijlage I) vanaf 2 augustus 2028.
De dataset-keuzes van nu bepalen of naleving straks haalbaar is: data die u vandaag inkoopt of verzamelt zonder herkomst-registratie is in 2027 niet meer te repareren.
Leg per dataset herkomst en aannames vast en neem datakwaliteit op als eis in elk inkoopcontract voor AI of data.
Het technisch dossier dat vóór marktintroductie aantoont dat een hoog-risico systeem aan de eisen voldoet.
De aanbieder brengt een hoog-risico AI-systeem op de markt of in gebruik.
Kleine aanbieders (kmo’s) mogen de documentatie vereenvoudigd aanleveren volgens het door de Commissie vastgestelde formulier.
Artikel 11 vereist technische documentatie die vóór marktintroductie is opgesteld, actueel wordt gehouden en de elementen van Bijlage IV bevat, zodat naleving van afdeling 2 aantoonbaar is voor toezichthouders.
Artikel 11, leden 1 tot en met 3, en Bijlage IV
Voor inkopende organisaties is Bijlage IV de checklist van wat u contractueel bij uw leverancier moet kunnen opvragen; zonder dat dossier kunt u uw eigen artikel 26-plichten niet waarmaken.
Neem het recht op inzage in de technische documentatie nu op in inkoop- en leverancierscontracten voor AI.
Automatische registratie van gebeurtenissen over de levensduur van een hoog-risico AI-systeem.
Het systeem is hoog-risico; de aanbieder ontwerpt de logging, aanbieder en gebruiksverantwoordelijke bewaren de logs binnen hun controle.
De bewaartermijn kan worden begrensd door Unierecht of nationaal recht, waaronder gegevensbescherming.
Artikel 12 vereist dat hoog-risico AI-systemen technisch geschikt zijn om gebeurtenissen automatisch te registreren gedurende hun levensduur, ten behoeve van traceerbaarheid, risicosignalering en post-market monitoring; Artikel 19 en Artikel 26 lid 6 regelen het bewaren van de logs.
Artikel 12, artikel 19 en artikel 26, lid 6
Logging is de ruggengraat van elk ander bewijs: zonder logs valt een incident niet te reconstrueren en een monitoringplicht niet in te vullen. Inkopers moeten nu al toetsen of een systeem dit technisch kan.
Neem loggingcapaciteit en logtoegang op als eis bij elke AI-inkoop en beleg het bewaarregime (wie, waar, hoe lang) per systeem.
Artikel 13: transparantie richting gebruiksverantwoordelijken
Begrijpelijke gebruiksinstructies en systeeminformatie zodat gebruiksverantwoordelijken het systeem correct kunnen inzetten.
De aanbieder levert een hoog-risico systeem; de gebruiksverantwoordelijke gebruikt het volgens de instructies.
De mate van detail mag passen bij de kennis van de beoogde gebruiksverantwoordelijke; bedrijfsgeheimen hoeven niet prijsgegeven.
Artikel 13 vereist dat hoog-risico systemen zo transparant zijn ontworpen dat gebruiksverantwoordelijken de output kunnen interpreteren en gebruiken, met gebruiksinstructies die onder meer doel, nauwkeurigheid, beperkingen, menselijk toezicht en onderhoud beschrijven.
De gebruiksinstructie is het scharnier tussen aanbieder- en gebruikersplichten: wat de aanbieder hier niet levert, kan de gebruiksverantwoordelijke onder artikel 26 niet waarmaken. Vraag er bij inkoop expliciet naar.
Vertaal ontvangen gebruiksinstructies per systeem naar interne werkinstructies per rol en leg vast wie ze heeft ontvangen.
Hoog-risico AI moet zo zijn ontworpen dat mensen er effectief toezicht op kunnen houden en kunnen ingrijpen.
Het systeem is hoog-risico; de aanbieder bouwt toezichtsmaatregelen in, de gebruiksverantwoordelijke belegt het toezicht bij bekwame personen.
Voor biometrische identificatie op afstand geldt de verzwaarde eis van verificatie door ten minste twee bevoegde personen (Artikel 14 lid 5), met de daar genoemde uitzonderingen.
Artikel 14 vereist dat hoog-risico systemen effectief door natuurlijke personen kunnen worden overzien, met maatregelen die het mogelijk maken het systeem te begrijpen, output juist te interpreteren, automation bias te onderkennen, en te besluiten het systeem niet te gebruiken, te negeren of te stoppen.
Toezicht op papier is geen toezicht: de wet noemt automation bias expliciet, dus een mens die alleen mag doorklikken telt niet. Effectief toezicht vergt begrip, tijd en mandaat, en dat raakt direct aan de artikel 4-geletterdheidsmaatregelen.
Wijs nu per (aankomend) hoog-risico systeem de toezichthoudende personen aan, train ze gericht en leg hun mandaat om in te grijpen schriftelijk vast.
Artikel 15: nauwkeurigheid, robuustheid en cyberbeveiliging
Passende prestatie-, robuustheids- en beveiligingsniveaus over de hele levenscyclus van hoog-risico AI.
Systemen die na uitrol doorleren kennen aanvullende eisen om feedback-loops en afwijkend gedrag te beheersen.
Artikel 15 vereist dat hoog-risico systemen een passend niveau van nauwkeurigheid, robuustheid en cyberbeveiliging bereiken en dat gedurende de levenscyclus behouden, inclusief weerbaarheid tegen fouten en tegen AI-specifieke aanvallen zoals data poisoning en adversarial voorbeelden.
Nauwkeurigheid is hier geen marketinggetal maar een gedeclareerde, testbare waarde die in de gebruiksinstructies staat en waar u in productie aan gehouden wordt.
Vraag leveranciers nu al om gedeclareerde nauwkeurigheidsniveaus en testrapporten, en richt productie-monitoring op die niveaus in.
Artikel 16: de twaalf plichten van de aanbieder van een hoog-risico AI-systeem
Artikel 16 is het samenvattende plichtenoverzicht voor aanbieders: twaalf punten die doorverwijzen naar het kwaliteitsbeheersysteem, de documentatie, de logs, de conformiteitsbeoordeling, de EU-conformiteitsverklaring, de CE-markering, de registratie, de corrigerende maatregelen en de toegankelijkheidseisen.
Van toepassing op aanbieders van AI-systemen met een hoog risico. Voor de standalone-route van bijlage III (artikel 6, lid 2) geldt 2 december 2027. Voor systemen die als veiligheidscomponent zijn ingebed in producten onder de harmonisatiewetgeving van bijlage I (artikel 6, lid 1) geldt 2 augustus 2028.
Een aanbieder die meent dat een in bijlage III bedoeld systeem geen hoog risico inhoudt, documenteert die beoordeling vóór het in de handel brengen en blijft onderworpen aan de registratieverplichting van artikel 49, lid 2 (artikel 6, lid 4). Voert een in bijlage III bedoeld systeem profilering van natuurlijke personen uit, dan geldt het altijd als hoog risico (artikel 6, lid 3, laatste alinea).
Artikel 16 verplicht aanbieders van AI-systemen met een hoog risico tot twaalf zaken. Zij zorgen ervoor dat hun systemen in overeenstemming zijn met de eisen van hoofdstuk III, afdeling 2 (punt a); vermelden op het systeem of, wanneer dat niet mogelijk is, op de verpakking of in de begeleidende documentatie hun naam, geregistreerde handelsnaam of geregistreerd merk en hun contactadres (punt b); beschikken over een systeem voor kwaliteitsbeheer conform artikel 17 (punt c); bewaren de documentatie van artikel 18 (punt d); bewaren de automatisch gegenereerde logs van artikel 19 wanneer zij daarover de controle hebben (punt e); zorgen ervoor dat de conformiteitsbeoordelingsprocedure van artikel 43 wordt uitgevoerd vóórdat het systeem in de handel wordt gebracht of in gebruik wordt gesteld (punt f); stellen een EU-conformiteitsverklaring op conform artikel 47 (punt g); brengen de CE-markering aan conform artikel 48 (punt h); leven de registratieverplichtingen van artikel 49, lid 1, na (punt i); nemen de noodzakelijke corrigerende maatregelen en verstrekken de informatie die artikel 20 vereist (punt j); tonen op een met redenen omkleed verzoek van een nationale bevoegde autoriteit de overeenstemming met de eisen van afdeling 2 aan (punt k); en zorgen ervoor dat het systeem voldoet aan de toegankelijkheidseisen van de Richtlijnen (EU) 2016/2102 en (EU) 2019/882 (punt l).
Artikel 16 leest als een inhoudsopgave en wordt daarom vaak als één regel op de roadmap gezet. Het zijn twaalf zelfstandige plichten met sterk uiteenlopende doorlooptijden: een kwaliteitsbeheersysteem opzetten kost maanden, een CE-markering aanbrengen kost een dag. De grotere val zit in artikel 25, lid 1: wie zijn eigen merk op een bestaand hoog-risico systeem zet, het systeem substantieel wijzigt, of het beoogde doel van een niet-hoog-risico systeem zo verandert dat het hoog risico wordt, geldt als aanbieder en krijgt alle twaalf punten op zijn bord zonder ooit iets gebouwd te hebben. Bij het merknaam-scenario van punt a) geldt dat onverminderd contractuele regelingen waarin de verplichtingen anders worden toegewezen, maar die afspraken moet u dan wel vooraf hebben gemaakt en kunnen tonen. Dat overkomt in de praktijk vooral partijen die AI whitelabelen of een algemeen model inzetten voor een bijlage III-toepassing.
Bepaal eerst of u aanbieder bent of dat u het door artikel 25 wordt, en werk daarna de twaalf punten uit als twaalf afzonderlijke werkpakketten met eigenaar en datum. Begin met punt c) en punt f), omdat die de doorlooptijd van het hele traject bepalen.
Het gedocumenteerde kwaliteitssysteem waarmee een aanbieder van hoog-risico AI naleving structureel borgt.
De aanbieder brengt hoog-risico AI-systemen op de markt of in gebruik.
Aanbieders die al onder sectorale kwaliteitsregimes vallen mogen de AI-elementen integreren in dat bestaande systeem; kmo’s mogen elementen vereenvoudigd invullen.
Artikel 17 vereist een gedocumenteerd kwaliteitsmanagementsysteem met onder meer een nalevingsstrategie, ontwerp- en ontwikkelprocedures, data-management, risicobeheer, post-market monitoring, incidentmelding en verantwoordingsstructuur.
Het KMS is de paraplu boven alle andere aanbiedersplichten: wie de losse dossiers heeft maar geen systeem dat ze verbindt, faalt op precies dit artikel bij een audit.
Bouw het KMS niet als apart document maar als index bovenop de bestaande dossiers (risico, data, documentatie, monitoring) met eigenaren per procedure.
Artikel 23: de plichten van de importeur
Vóór het in de handel brengen verifieert de importeur vier dingen bij de aanbieder, en daarna draagt hij een eigen bewaar-, informatie- en meldpakket met een termijn van tien jaar.
Van toepassing op importeurs van AI-systemen met een hoog risico. Voor de standalone-route van bijlage III (artikel 6, lid 2) geldt 2 december 2027; voor de ingebedde route van bijlage I (artikel 6, lid 1) geldt 2 augustus 2028.
Zet u uw eigen naam of merk op het systeem, wijzigt u het substantieel of wijzigt u het beoogde doel zo dat het hoog risico wordt, dan wordt u op grond van artikel 25, lid 1, als aanbieder beschouwd en gelden de plichten van artikel 16 in plaats van die van artikel 23.
Artikel 23, lid 1, verplicht importeurs om vóór het in de handel brengen van een hoog-risico AI-systeem na te gaan of de relevante conformiteitsbeoordelingsprocedure van artikel 43 door de aanbieder is uitgevoerd (punt a), of de aanbieder de technische documentatie heeft opgesteld conform artikel 11 en bijlage IV (punt b), of de vereiste CE-markering is aangebracht en het systeem vergezeld gaat van de EU-conformiteitsverklaring van artikel 47 en van gebruiksaanwijzingen (punt c), en of de aanbieder een gemachtigde heeft aangewezen conform artikel 22, lid 1 (punt d). Lid 2 bepaalt dat een importeur met afdoende redenen om aan te nemen dat het systeem niet conform is, vervalst is of vergezeld gaat van vervalste documenten, het systeem niet in de handel brengt voordat het in overeenstemming is gebracht, en dat hij bij een risico in de zin van artikel 79, lid 1, de aanbieder, de gemachtigden en de markttoezichtautoriteiten in kennis stelt. Lid 3 vraagt vermelding van naam, geregistreerde handelsnaam of geregistreerd merk en contactadres. Lid 4 vraagt opslag- en vervoersomstandigheden die de overeenstemming met afdeling 2 niet in het gedrang brengen. Lid 5 verplicht tot het gedurende tien jaar bewaren van een kopie van het door de aangemelde instantie afgegeven certificaat en, waar van toepassing, van de gebruiksaanwijzing en van de EU-conformiteitsverklaring van artikel 47. Lid 6 verplicht tot het op met redenen omkleed verzoek verstrekken van alle nodige informatie en documentatie in een voor de autoriteit gemakkelijk te begrijpen taal, en tot het beschikbaar kunnen stellen van de technische documentatie. Lid 7 verplicht tot samenwerking met de bevoegde autoriteiten.
Artikel 23 wordt onderschat omdat het op documentcontrole lijkt, en dat is het grotendeels ook: u hoeft het model niet opnieuw te valideren, u moet kunnen laten zien dat u de vier punten hebt gecontroleerd. De pijn zit ergens anders. Punt d) valt in de praktijk het vaakst om: veel aanbieders van buiten de EU hebben geen gemachtigde aangewezen, en dan mag u het systeem simpelweg niet in de handel brengen, hoe ver de deal ook is. En lid 5 legt de tienjaarstermijn bij u neer, niet bij de leverancier: als die leverancier over vijf jaar niet meer bestaat, moet u de stukken nog steeds kunnen tonen.
Verplaats de vier verificaties van artikel 23, lid 1, naar het moment vóór contractondertekening in plaats van vóór levering. Vraag de conformiteitsverklaring, de technische documentatie, het bewijs van de artikel 43-procedure en de gegevens van de gemachtigde op als opschortende voorwaarde in het inkoopcontract.
Artikel 24: de plichten van de distributeur
De distributeur controleert vóór het op de markt aanbieden de markering, de verklaring en de gebruiksinstructies plus de naleving door aanbieder en importeur, en moet daarna kunnen corrigeren, uit de handel nemen of terugroepen.
Van toepassing op distributeurs van AI-systemen met een hoog risico. Voor de standalone-route van bijlage III (artikel 6, lid 2) geldt 2 december 2027; voor de ingebedde route van bijlage I (artikel 6, lid 1) geldt 2 augustus 2028.
Zet u uw eigen naam of merk op het systeem, wijzigt u het substantieel of wijzigt u het beoogde doel zo dat het hoog risico wordt, dan wordt u op grond van artikel 25, lid 1, als aanbieder beschouwd en gelden de plichten van artikel 16 in plaats van die van artikel 24.
Artikel 24, lid 1, verplicht distributeurs om vóór het op de markt aanbieden van een hoog-risico AI-systeem te controleren of daarop de vereiste CE-markering is aangebracht, of het systeem vergezeld gaat van de EU-conformiteitsverklaring van artikel 47 en van gebruiksinstructies, en of de aanbieder en de importeur, naargelang het geval, hun verplichtingen uit artikel 16, punten b) en c), en artikel 23, lid 3, hebben nageleefd. Lid 2 verbiedt het in de handel brengen zolang de distributeur op grond van de informatie waarover hij beschikt meent of redenen heeft om aan te nemen dat het systeem niet aan afdeling 2 voldoet, en verplicht bij een risico in de zin van artikel 79, lid 1, tot kennisgeving aan de aanbieder of de importeur. Lid 3 vraagt opslag- en vervoersomstandigheden die de overeenstemming niet in het gedrang brengen. Lid 4 verplicht een distributeur die meent of redenen heeft om aan te nemen dat een reeds aangeboden systeem niet aan afdeling 2 voldoet tot de noodzakelijke corrigerende maatregelen om het in overeenstemming te brengen, uit de handel te nemen of terug te roepen, dan wel ervoor te zorgen dat de aanbieder, de importeur of een andere betrokken operator die maatregelen treft; bij een risico in de zin van artikel 79, lid 1, stelt hij de aanbieder of importeur en de bevoegde autoriteiten onmiddellijk in kennis met een uitvoerige beschrijving van de non-conformiteit en de getroffen corrigerende maatregelen. Lid 5 verplicht tot het op met redenen omkleed verzoek verstrekken van alle informatie en documentatie over de op grond van de leden 1 tot en met 4 genomen maatregelen. Lid 6 verplicht tot samenwerking met de bevoegde autoriteiten.
De controle van lid 1 lijkt licht, maar bevat een lastig element: u moet ook nagaan of de aanbieder zijn verplichting uit artikel 16, punt c), is nagekomen, en dat is het hebben van een kwaliteitsbeheersysteem conform artikel 17. Dat ziet u niet aan de verpakking. In de praktijk verankert u dat in leveranciersvoorwaarden met een verklaring van de aanbieder en legt u vast wat u hebt gecontroleerd. Het zwaartepunt van artikel 24 ligt echter bij lid 4: veel resellers gaan ervan uit dat terugroepen een zaak van de fabrikant is, terwijl de bepaling die actie ook bij u neerlegt, met de mogelijkheid om ervoor te zorgen dat een ander hem uitvoert. Dat zorgen dat vraagt om contractuele grip die u vooraf regelt, niet tijdens een incident.
Neem de drie controles van lid 1 op in uw resell- of leveringsproces en bewaar per contract wat u hebt gezien. Zorg daarnaast dat u binnen een dag weet welke klant welk systeem in welke versie gebruikt, want zonder dat overzicht kunt u lid 4 niet uitvoeren.
Artikel 26: de plichten van de gebruiksverantwoordelijke van een hoog-risico AI-systeem
Twaalf leden die het dagelijkse gebruik regelen: gebruik volgens de gebruiksaanwijzing, menselijk toezicht door bevoegde personen, inputdata, monitoring en melding, logbewaring, informeren van werknemers vóór ingebruikname, registratie door overheden en informeren van de personen over wie beslissingen worden genomen.
Van toepassing zodra u een hoog-risico AI-systeem onder eigen verantwoordelijkheid gebruikt (artikel 3, punt 4), ongeacht of u het zelf hebt gebouwd of ingekocht. Voor de standalone-route van bijlage III (artikel 6, lid 2) geldt 2 december 2027; voor de ingebedde route van bijlage I (artikel 6, lid 1) geldt 2 augustus 2028.
Artikel 2, lid 10, sluit natuurlijke personen uit die een AI-systeem gebruiken in het kader van een louter persoonlijke, niet-beroepsmatige activiteit. Voor gebruiksverantwoordelijken die financiele instellingen zijn met interne-governance-eisen uit het Unierecht inzake financiele diensten geldt de monitoringsplicht van lid 5 als vervuld door naleving van die regels, en worden de logs van lid 6 bewaard als onderdeel van de documentatie uit dat recht.
Artikel 26 legt gebruiksverantwoordelijken van hoog-risico AI-systemen twaalf leden op. Lid 1 vraagt passende technische en organisatorische maatregelen om het systeem te gebruiken in overeenstemming met de bijgeleverde gebruiksaanwijzingen. Lid 2 verplicht het menselijk toezicht op te dragen aan natuurlijke personen die over de nodige bekwaamheid, opleiding en autoriteit beschikken en de nodige ondersteuning krijgen. Lid 3 laat andere verplichtingen en de vrijheid om de eigen middelen te organiseren onverlet. Lid 4 vraagt, voor zover u controle hebt over de inputdata, dat die relevant en voldoende representatief zijn voor het beoogde doel. Lid 5 verplicht tot monitoring op basis van de gebruiksaanwijzingen en tot kennisgeving aan de aanbieder overeenkomstig artikel 72; bij redenen om aan te nemen dat het gebruik leidt tot een risico in de zin van artikel 79, lid 1, stelt u zonder onnodige vertraging de aanbieder of distributeur en de betreffende markttoezichtautoriteit in kennis en onderbreekt u het gebruik, en bij een ernstig incident stelt u onmiddellijk eerst de aanbieder in kennis en vervolgens de importeur of distributeur en de markttoezichtautoriteiten. Lid 6 verplicht tot het bewaren van de automatisch gegenereerde logs die onder uw controle vallen gedurende een periode die past bij het beoogde doel en ten minste zes maanden, tenzij het Unie- of nationaal recht anders bepaalt. Lid 7 verplicht gebruiksverantwoordelijken die werkgever zijn om werknemersvertegenwoordigers en de betrokken werknemers vóór ingebruikname of gebruik op de werkplek mee te delen dat zij aan het gebruik van het systeem zullen worden onderworpen. Lid 8 legt overheidsinstanties en instellingen, organen en instanties van de Unie de registratieverplichtingen van artikel 49 op en verbiedt gebruik van een systeem dat niet in de EU-databank van artikel 71 is geregistreerd. Lid 9 koppelt de informatie uit artikel 13 aan de gegevensbeschermingseffectbeoordeling van artikel 35 van Verordening (EU) 2016/679. Lid 10 stelt aanvullende voorwaarden aan biometrische identificatie op afstand achteraf in het kader van rechtshandhaving. Lid 11 begint met de woorden onverminderd artikel 50 van deze verordening en verplicht gebruiksverantwoordelijken van in bijlage III bedoelde systemen die beslissingen over natuurlijke personen nemen of helpen nemen, die personen te informeren dat het systeem op hen wordt toegepast; voor hoog-risico AI-systemen die voor rechtshandhaving worden gebruikt is artikel 13 van Richtlijn (EU) 2016/680 van toepassing. De transparantieplichten van artikel 50 gelden sinds 2 augustus 2026 en staan los van de datum waarop lid 11 gaat gelden. Lid 12 vraagt samenwerking met de bevoegde autoriteiten.
De datum van 2 december 2027 verleidt tot uitstel, maar twee onderdelen zijn nu al voorbereidingswerk. Lid 7 verplicht u werknemersvertegenwoordigers en de betrokken werknemers te informeren vóórdat het systeem op de werkplek in gebruik wordt gesteld, en die informatie verstrekt u waar van toepassing volgens de bestaande regels en praktijk inzake informatie van werknemers. Dat raakt medezeggenschap, en zo'n traject duurt in de praktijk maanden en niet weken, dus een systeem dat in 2027 live moet, bespreekt u in 2026. Lid 2 sluit daarnaast aan op het menselijk toezicht dat artikel 14 aan het systeemontwerp stelt: u moet natuurlijke personen aanwijzen met bekwaamheid, opleiding, autoriteit en ondersteuning. Dat is nadrukkelijk iets anders dan de maatregelenplicht van artikel 4. Artikel 4 vraagt maatregelen die AI-geletterdheid ondersteunen en verplicht u niet een bepaald niveau bij individuen te waarborgen; artikel 26, lid 2, vraagt aanwijsbare toezichthouders met mandaat. Wie die twee door elkaar haalt, denkt met een algemene e-learning klaar te zijn en heeft dan nog steeds geen toezichthouder met beslisruimte. Een derde onderschat onderdeel is lid 11: het informeren van de mensen over wie een bijlage III-systeem beslissingen neemt of helpt nemen, is een zichtbare klant- of sollicitantcommunicatie die u door uw eigen organisatie heen moet ontwerpen.
Maak nu een lijst van de systemen die per 2 december 2027 waarschijnlijk als hoog risico gelden en zet daar drie kolommen naast: wie houdt menselijk toezicht en met welk mandaat, wanneer informeert u de ondernemingsraad en de betrokken werknemers, en hoe krijgen de betrokken personen de mededeling uit lid 11. Plan het medezeggenschapstraject een jaar vooruit.
Grondrechteneffectbeoordeling vóór het inzetten van bepaalde hoog-risico AI-systemen.
Het gaat om een hoog-risico AI-systeem via Artikel 6 lid 2 en Bijlage III, met uitzondering van Bijlage III punt 2.
De gebruiksverantwoordelijke is een publiekrechtelijke instantie, private aanbieder van publieke diensten of gebruikt een relevant systeem uit Bijlage III punt 5(b) of 5(c).
In de situatie van Artikel 46 lid 1 kan een uitzondering op de kennisgeving gelden. Dit heft de beoordeling zelf niet generiek op.
De genoemde gebruiksverantwoordelijken moeten vóór ingebruikname een FRIA uitvoeren. De verplichting volgt voor deze Bijlage III-route de toepassingsdatum van 2 december 2027.
Gewijzigd toepassingsschema en de verwijzing naar de DPIA in artikel 27
Een FRIA is geen generieke risicoanalyse voor ieder AI-systeem. Eerst moeten systeemroute, Bijlage III-categorie en type gebruiksverantwoordelijke zijn vastgesteld.
Koppel de FRIA aan het AI-register en, waar relevant, aan de DPIA. Bewaar scope, betrokken groepen, mitigaties, resterende risico’s en kennisgeving als één versieerbaar dossier.
Wijziging van artikel 27 over opname in of verwijzing naar de DPIA
Aanbieders en gebruiksverantwoordelijken nemen maatregelen die de ontwikkeling van AI-geletterdheid ondersteunen.
De organisatie is aanbieder of gebruiksverantwoordelijke van een AI-systeem binnen het toepassingsgebied.
De bepaling verlangt niet dat een specifiek individueel niveau wordt gegarandeerd.
Sinds 27 juli 2026 moeten aanbieders en gebruiksverantwoordelijken maatregelen nemen die de ontwikkeling van AI-geletterdheid ondersteunen. De bepaling verlangt geen gegarandeerd individueel niveau.
Wijziging van artikel 4; inwerkingtreding 27 juli 2026
De aantoonbaarheid zit vooral in een passend dossier van genomen maatregelen per rol en gebruikscontext, niet in één voorgeschreven cursus of certificaat.
Vragen over maatregelen, vormen, certificaten en vastlegging
Inventariseer rollen en AI-systemen, kies passende maatregelen en leg keuze, uitvoering en periodieke evaluatie vast.
Uitvoeringsvoorbeelden en aanwijzingen over bewijs
Het verbod op AI-praktijken met onaanvaardbaar risico, zoals manipulatie, social scoring en bepaalde biometrische toepassingen.
Het op de markt brengen, in gebruik stellen of gebruiken van AI valt onder een van de praktijken in Artikel 5 lid 1, waaronder schadelijke manipulatie of uitbuiting van kwetsbaarheden, social scoring, risicovoorspelling van strafbare feiten op basis van profilering, het ongericht scrapen van gezichtsopnamen, emotieherkenning op de werkplek of in het onderwijs, biometrische categorisering naar gevoelige kenmerken en realtime biometrische identificatie op afstand in de openbare ruimte voor rechtshandhaving.
De uitzonderingen zijn eng: onder meer emotieherkenning om medische of veiligheidsredenen, en de limitatief omschreven rechtshandhavingssituaties met machtiging voor realtime biometrische identificatie in Artikel 5 leden 2 tot en met 7. De uitzondering moet vooraf worden vastgesteld en gedocumenteerd.
De verboden praktijken van Artikel 5 gelden sinds 2 februari 2025 en zijn de enige AI Act-categorie die al die hele periode handhaafbaar is. Overtreding kent het hoogste boeteplafond van de verordening: tot 35 miljoen euro of 7 procent van de wereldwijde jaaromzet.
Artikel 5, artikel 99, lid 3, en artikel 113, punt a
De Digital Omnibus voegt een verbod toe rond AI voor materiaal van seksueel kindermisbruik en niet-consensuele intieme synthetische content; de bijbehorende technische waarborgen zijn vereist per 2 december 2026.
Wijziging van artikel 5 en overgang naar 2 december 2026
De grens zit vaak in de details van de definitie: dezelfde techniek kan verboden zijn op de werkplek en toegestaan in een andere context. Toets daarom per concrete inzet en context, niet per technologie, en doe dat vóór inkoop of livegang.
Maak de Artikel 5-toets de eerste stap van elke classificatie en leg de uitkomst per systeem vast in het register, inclusief de motivering waarom een praktijk niet onder het verbod valt.
Artikel 5, gelezen in samenhang met de classificatievolgorde van artikel 6
Specifieke meldings-, markerings- en labelplichten voor bepaalde AI-systemen en synthetische inhoud.
Een AI-systeem is bedoeld voor directe interactie met natuurlijke personen.
Het systeem genereert of manipuleert synthetische audio-, beeld-, video- of tekstinhoud, of de inzet betreft de specifiek genoemde deployerscenario’s.
De melding bij directe AI-interactie is niet vereist wanneer dit voor een redelijk geïnformeerde, oplettende en omzichtige persoon duidelijk is, gelet op omstandigheden en context.
Alleen Artikel 50 lid 2 heeft voor systemen die vóór 2 augustus 2026 op de markt kwamen een overgang tot 2 december 2026.
Artikel 50 geldt sinds 2 augustus 2026. De precieze plicht verschilt per scenario: directe AI-interactie, machineleesbare markering, emotieherkenning of biometrische categorisatie, deepfakes en bepaalde tekst van publiek belang.
Artikel 50, leden 1 tot en met 5, en artikel 113
Een generieke regel dat alle AI-content altijd zichtbaar moet worden gelabeld is te breed. Classificeer eerst het concrete Artikel 50-scenario.
Definitieve richtsnoeren, reikwijdte per lid van artikel 50
Leg per systeem vast welk lid geldt, wie verantwoordelijk is, welke melding of markering is geïmplementeerd en hoe deze is getest.
Uitvoeringsaanwijzingen voor aanbieders en gebruiksverantwoordelijken
Documentatie-, informatie-, auteursrechten- en transparantieplichten voor aanbieders van AI-modellen voor algemene doeleinden.
De partij is aanbieder van een GPAI-model dat op de Uniemarkt wordt aangeboden.
Voor modellen die vanaf 2 augustus 2025 op de markt zijn gebracht gelden de plichten vanaf dat moment. Modellen die vóór 2 augustus 2025 op de markt waren moeten uiterlijk 2 augustus 2027 voldoen.
De open-source-uitzondering is beperkt en laat onder meer het auteursrechtenbeleid en de publieke samenvatting van trainingsinhoud in stand. Voor modellen met systeemrisico gelden aanvullende plichten.
Artikel 53 geldt sinds 2 augustus 2025 voor nieuwe GPAI-modellen. Aanbieders onderhouden technische documentatie, geven informatie aan downstream-aanbieders, voeren een Unierechtelijk auteursrechtenbeleid en publiceren een voldoende gedetailleerde samenvatting van trainingsinhoud.
Artikel 53, lid 1, Bijlage XI en Bijlage XII
Aanbieders van GPAI-modellen die vóór 2 augustus 2025 op de markt waren, moeten uiterlijk 2 augustus 2027 aan de toepasselijke verplichtingen voldoen.
Een organisatie die alleen een extern GPAI-model gebruikt is niet daardoor automatisch GPAI-modelaanbieder. De rol in de waardeketen moet eerst worden vastgesteld.
Aanwijzingen over reikwijdte en kwalificatie als aanbieder
Leg modelversies, rolkwalificatie, documentatie-eigenaren, downstream-informatie, auteursrechtenbeleid en trainingssamenvatting in één wijzigingsgestuurd dossier vast.
Artikel 55: GPAI-modellen met systeemrisico
Aanvullende plichten voor de zwaarste AI-modellen voor algemene doeleinden, bovenop Artikel 53.
Het GPAI-model heeft capaciteiten met grote impact, vermoed bij cumulatieve trainingsrekenkracht boven 10^25 FLOPs, of is door de Commissie aangewezen.
De GPAI Code of Practice kan na de adequaatheidsbeoordeling dienen als middel om naleving aan te tonen.
Artikel 55 verplicht aanbieders van GPAI-modellen met systeemrisico tot modelevaluaties met adversarial testen, beoordeling en mitigatie van systeemrisico’s op Unieniveau, registratie en melding van ernstige incidenten, en passende cyberbeveiliging van model en infrastructuur. De verplichtingen gelden sinds 2 augustus 2025; de handhaving door het AI Office is sinds 2 augustus 2026 actief.
Artikel 55, leden 1 en 2, in samenhang met artikel 51 en artikel 52
De 10^25 FLOPs-drempel is een vermoeden, geen grens waar u zich achter kunt verschuilen: de Commissie kan modellen ook op capaciteiten aanwijzen, en finetuning bovenop een bestaand model kan onder omstandigheden een eigen kwalificatie opleveren.
Modelaanbieders in de buurt van de drempel: richt de drempelbewaking nu in en sluit aan bij de Code of Practice om de bewijslast te dragen.
Artikel 57: AI-testomgevingen voor regelgeving
Lidstaten moeten ten minste een nationale AI-testomgeving voor regelgeving aanbieden. Voor u is dat een vrijwillige route: u ontwikkelt, traint, test en valideert een innovatief AI-systeem in een gecontroleerde omgeving onder toezicht, volgens een plan dat u met de bevoegde autoriteit overeenkomt, voordat u het in de handel brengt of in gebruik stelt.
Relevant wanneer u aanbieder of potentiele aanbieder bent van een innovatief AI-systeem dat u wilt ontwikkelen, trainen, testen of valideren voordat u het in de handel brengt of in gebruik stelt, en u vooraf zekerheid wilt over classificatie of over de wijze waarop u aan de eisen van deze verordening voldoet.
Deelname is vrijwillig. Artikel 57 legt de plicht bij de lidstaat om een testomgeving aan te bieden, niet bij u om eraan deel te nemen. De lidstaat kan die plicht ook vervullen door aan te sluiten bij een bestaande testomgeving met gelijkwaardige nationale dekking. Artikel 57 lid 4 laat andere testomgevingen voor regelgeving op grond van Unie- of nationaal recht onverlet.
Artikel 57 lid 1 verplicht de lidstaten ervoor te zorgen dat hun bevoegde autoriteiten ten minste een AI-testomgeving voor regelgeving op nationaal niveau opzetten. De in het Publicatieblad bekendgemaakte tekst van Verordening (EU) 2024/1689 bepaalt dat die testomgeving uiterlijk op 2 augustus 2026 operationeel is, en die formulering staat op 9 augustus 2026 nog ongewijzigd in de artikeltekst die de Europese Commissie publiceert. De tijdlijn die de Europese Commissie publiceert na de inwerkingtreding van de Digital Omnibus, Verordening (EU) 2026/1744, op 27 juli 2026, plaatst deze mijlpaal daarentegen op 2 augustus 2027 met de vermelding "Member States should have at least one AI regulatory sandbox per country operational". De geconsolideerde tekst van artikel 57 lid 1 na de Omnibus is niet op artikelniveau geverifieerd; ga voor de exacte datum uit van de geconsolideerde versie op EUR-Lex. Hoofdstuk VI, waarin artikel 57 staat, valt niet onder de uitzonderingen van artikel 113 en is dus van toepassing sinds 2 augustus 2026. Artikel 57 lid 1 bepaalt verder dat aan de verplichting ook kan worden voldaan door deel te nemen aan een bestaande testomgeving, voor zover dat een gelijkwaardig niveau van nationale dekking biedt. Artikel 57 lid 5 omschrijft de testomgeving als een gecontroleerde omgeving die innovatie bevordert en het ontwikkelen, trainen, testen en valideren van innovatieve AI-systemen voor beperkte duur vergemakkelijkt, volgens een specifiek testomgevingsplan dat tussen de aanbieder of potentiele aanbieder en de bevoegde autoriteit is overeengekomen, voordat het systeem in de handel wordt gebracht of in gebruik wordt gesteld. Zulke testomgevingen kunnen ook testen onder reele omstandigheden onder toezicht binnen de testomgeving omvatten. Artikel 57 lid 15 verplicht het AI-bureau een openbare, actuele lijst van geplande en bestaande testomgevingen bij te houden.
Artikel 57, leden 1 tot en met 17, artikel 58 en artikel 113; zoals gewijzigd bij Verordening (EU) 2026/1744
De veelgemaakte fout is de testomgeving lezen als uitstel of als vrijstelling. Dat is zij niet. Artikel 57 lid 11 laat de toezichts- en correctiebevoegdheden van de bevoegde autoriteit volledig in stand en geeft haar uitdrukkelijk de bevoegdheid uw test of uw deelname tijdelijk of permanent te schorsen als risico's niet effectief kunnen worden beperkt. Een testomgeving is nuttig voor precies een profiel: u bouwt zelf een AI-systeem dat vermoedelijk onder bijlage III valt, u twijfelt over de classificatie of over hoe u aan hoofdstuk III, afdeling 2, voldoet, en u wilt die twijfel wegnemen voordat u in de handel brengt. Bent u uitsluitend gebruiksverantwoordelijke die een systeem inkoopt, dan is de testomgeving niet uw route: u kunt hooguit meedoen als partner van de aanbieder op grond van artikel 58 lid 2, punt b). Tweede val: de datum van 2 augustus 2027 is een plicht van de lidstaat, niet van u. De datum in dit item is daarom 2 augustus 2026: vanaf dat moment is hoofdstuk VI van toepassing en staat de route voor u open. U kunt uw eigen voorbereiding niet aan die datum ophangen, en de datum zegt niets over de vraag of uw nationale testomgeving dan ook daadwerkelijk plaatsen heeft. Derde val: mensen verwarren de testomgeving van artikel 57 met het testen onder reele omstandigheden van artikel 60. Dat zijn twee verschillende routes met verschillende voorwaarden. Testen onder reele omstandigheden kan binnen de testomgeving (artikel 57 lid 5 en artikel 58 lid 4) of daarbuiten onder artikel 60, en de waarborgen verschillen.
Bepaal eerst uw rol: alleen aanbieders en potentiele aanbieders kunnen zelfstandig toetreden. Zoek daarna in de door het AI-bureau gepubliceerde lijst van geplande en bestaande testomgevingen (artikel 57 lid 15) welke testomgeving voor u openstaat, in uw lidstaat of gezamenlijk met andere lidstaten. Formuleer voordat u aanklopt exact welke onzekerheid u wilt oplossen, bij voorkeur toegespitst op classificatie onder artikel 6 of op een specifieke eis uit hoofdstuk III, afdeling 2. Reken op de beslistermijn van drie maanden die artikel 58 lid 2, punt a), aan de uitvoeringshandelingen voorschrijft, zet die in uw productplanning en vraag de bevoegde autoriteit vooraf schriftelijk welke termijn zij op dit moment hanteert. Leg bij toetreding schriftelijk vast wat het testomgevingsplan omvat, en vraag bij uitschrijving zowel het schriftelijk bewijs als het eindverslag op.
Artikel 60: testen onder reele omstandigheden buiten een testomgeving
Wilt u een AI-systeem met een hoog risico uit bijlage III met echte mensen en echte uitkomsten testen voordat u het in de handel brengt, dan geldt een volwaardig regime: een plan, voorafgaande goedkeuring van de markttoezichtautoriteit, registratie, geinformeerde toestemming en een maximale duur.
Van toepassing wanneer u aanbieder of potentiele aanbieder bent van een AI-systeem met een hoog risico uit bijlage III en u dat systeem buiten een AI-testomgeving voor regelgeving onder reele omstandigheden wilt testen voordat u het in de handel brengt of in gebruik stelt. Bent u buiten de Unie gevestigd, dan eist artikel 60 lid 4, punt d), dat u een in de Unie gevestigde wettelijke vertegenwoordiger aanwijst; dat is een andere figuur dan de gemachtigde van artikel 22.
Artikel 60 lid 1, derde alinea, laat Unie- en nationaal recht over testen onder reele omstandigheden van systemen met een hoog risico bij producten onder de harmonisatiewetgeving van bijlage I onverlet. Artikel 60 lid 4, punt i), kent een uitzondering voor rechtshandhaving: indien het vragen om geinformeerde toestemming het testen onmogelijk zou maken, mag zonder toestemming worden getest, mits de test zelf en het resultaat geen negatieve gevolgen voor de proefpersonen hebben en hun persoonsgegevens na de test worden gewist. Voor de in bijlage III, punten 1, 6 en 7, bedoelde systemen op de gebieden rechtshandhaving, migratie, asiel en grenstoezicht verloopt de registratie via het beveiligde niet-openbare gedeelte van de EU-databank op grond van artikel 49 lid 4, punt d). Voor de in bijlage III, punt 2, bedoelde systemen geldt op grond van artikel 49 lid 5 registratie op nationaal niveau.
Artikel 60 lid 1 bepaalt dat het testen van AI-systemen met een hoog risico onder reele omstandigheden buiten AI-testomgevingen voor regelgeving mag worden uitgevoerd door aanbieders of potentiele aanbieders van in bijlage III vermelde AI-systemen met een hoog risico, in overeenstemming met dit artikel en het plan voor tests onder reele omstandigheden, onverminderd de verbodsbepalingen van artikel 5. De Commissie specificeert de precieze onderdelen van dat plan bij uitvoeringshandeling. De derde alinea van lid 1 bepaalt dat dit lid geen afbreuk doet aan Unie- of nationaal recht voor het testen onder reele omstandigheden van systemen met een hoog risico die verband houden met producten die onder de in bijlage I vermelde harmonisatiewetgeving vallen. Artikel 60 lid 2 staat toe dat aanbieders of potentiele aanbieders op elk moment voor het in de handel brengen of in gebruik nemen testen, zelf of in samenwerking met een of meer gebruiksverantwoordelijken of potentiele gebruiksverantwoordelijken. Artikel 60 lid 3 bepaalt dat dit testen geen afbreuk doet aan de ethische toetsing die op grond van Unie- of nationaal recht is vereist. Artikel 60 lid 4, punt f), begrenst de duur: niet langer dan nodig is om de doelstellingen te verwezenlijken en in geen geval langer dan zes maanden, met een mogelijke verlenging van nog eens zes maanden na voorafgaande kennisgeving aan de markttoezichtautoriteit met uitleg over de noodzaak. Artikel 60 lid 4, punt g), eist dat proefpersonen die tot kwetsbare groepen behoren vanwege leeftijd of handicap naar behoren worden beschermd. Artikel 60 lid 9 stelt uitdrukkelijk vast dat de aanbieder of potentiele aanbieder voor schade die in de loop van het testen onder reele omstandigheden wordt veroorzaakt onverkort onder het toepasselijke Unie- en nationale recht daarover valt. Hoofdstuk VI, waarin artikel 60 staat, valt niet onder de uitzonderingen van artikel 113 en is van toepassing sinds 2 augustus 2026.
Artikel 60, leden 1 tot en met 4, artikel 60, lid 9, en artikel 113
Veel organisaties noemen wat zij doen een pilot en gaan ervan uit dat zij daarmee buiten de verordening blijven. Artikel 60 laat zien dat dat niet opgaat zodra u een systeem uit bijlage III onder reele omstandigheden test met echte mensen en echte uitkomsten. Dan geldt een volwaardig regime: een plan, voorafgaande goedkeuring, registratie met een Uniebreed uniek identificatienummer, geinformeerde toestemming, en een harde klok van zes maanden met een verlenging van maximaal zes maanden. De zwaarste eis in de praktijk is artikel 60 lid 4, punt k): de voorspellingen, aanbevelingen of beslissingen van het systeem moeten daadwerkelijk kunnen worden teruggedraaid en genegeerd. Test u een selectie-, scoring- of triagesysteem waarvan de uitkomst rechtstreeks in de werkstroom doorwerkt zonder dat iemand die kan terugdraaien, dan voldoet uw opzet niet, hoe zorgvuldig uw toestemmingsformulier ook is. Let ook op de timing, want die is commercieel interessant. Hoofdstuk VI geldt sinds 2 augustus 2026, terwijl de kernverplichtingen voor zelfstandige bijlage III-systemen pas op 2 december 2027 van toepassing worden. De testroute staat dus al open voordat de eisen zelf bijten, en dat is precies het venster om uw ontwerp te valideren in plaats van het achteraf te moeten herbouwen. Tot slot: artikel 60 lid 3 laat ethische toetsing die op grond van ander recht is vereist volledig staan, en artikel 60 lid 9 stelt uitdrukkelijk vast dat u voor schade die tijdens het testen wordt veroorzaakt onverkort onder het toepasselijke recht valt.
Inventariseer welke lopende of geplande proeven feitelijk testen onder reele omstandigheden zijn: echte gebruikers, echte data, uitkomsten die in de werkstroom doorwerken. Toets die eerst op artikel 60 lid 4, punt k): kunt u de uitkomst daadwerkelijk terugdraaien en negeren? Zo niet, herontwerp de proef voordat u iets indient. Kies vervolgens bewust tussen twee routes: testen binnen een testomgeving onder toezicht op grond van artikel 57 lid 5 en artikel 58 lid 4, of buiten een testomgeving onder artikel 60. Plan de zes maanden realistisch en beslis vooraf op welk moment u een verlenging aanvraagt, want die vereist voorafgaande kennisgeving met onderbouwing. Controleer of voor uw domein een ethische toetsing verplicht is en start die parallel, want artikel 60 lid 3 stelt u daar niet van vrij.
Systematische bewaking van hoog-risico AI in de praktijk, na marktintroductie.
De aanbieder heeft een hoog-risico systeem op de markt; gebruiksverantwoordelijken leveren via monitoring en signalen de praktijkdata.
Het plan mag proportioneel zijn aan de aard van het systeem en aansluiten bij bestaande sectorale monitoringregimes.
Artikel 72 verplicht aanbieders tot een post-market monitoringsysteem met een plan dat deel uitmaakt van de technische documentatie, om relevante praktijkdata te verzamelen en de blijvende naleving van afdeling 2 te evalueren.
Compliance stopt niet bij livegang: dit artikel maakt van naleving een doorlopende toestand. Voor gebruiksverantwoordelijken is dit ook de basis om afwijkingen bij de leverancier af te dwingen.
Ontwerp de monitoring samen met de logging van Artikel 12: dezelfde datastromen voeden beide plichten.
Artikel 73: melding van ernstige incidenten
De meldplicht bij ernstige incidenten met hoog-risico AI, met strakke termijnen.
Een ernstig incident doet zich voor met een hoog-risico systeem: overlijden of ernstige schade aan gezondheid, ernstige en onomkeerbare verstoring van kritieke infrastructuur, schending van grondrechtenbeschermende verplichtingen of ernstige schade aan eigendom of milieu.
Voor systemen onder sectorale meldregimes met gelijkwaardige plichten kan de melding via dat regime lopen om dubbele meldingen te voorkomen.
Artikel 73 verplicht aanbieders ernstige incidenten te melden bij de markttoezichthouder: onmiddellijk na het vaststellen van het causale verband en uiterlijk binnen 15 dagen, verkort tot 10 dagen bij overlijden en tot 2 dagen bij wijdverbreide inbreuk of ernstige verstoring van kritieke infrastructuur. Gebruiksverantwoordelijken informeren de aanbieder onverwijld.
De termijnen zijn te kort om het proces tijdens het incident te ontwerpen: wie pas bij het eerste incident bedenkt wie er meldt, haalt 15 dagen niet, laat staan 2. Dit is het AVG-datalek-draaiboek, maar dan voor AI.
Sluit het AI-incidentproces aan op het bestaande datalek- en securityproces en voeg de AI-specifieke definities en termijnen toe.
Artikel 85: klachtrecht bij de markttoezichthouder
Iedereen die redenen heeft om aan te nemen dat de verordening is geschonden, kan daarover een klacht indienen bij de bevoegde markttoezichthouder. Voor een organisatie betekent dat: uw eigen medewerkers, klanten en sollicitanten hebben een route naar de toezichthouder die niet langs u loopt.
Van toepassing zodra iemand redenen heeft om aan te nemen dat de verordening is geschonden. Er is geen drempel van belanghebbendheid: het recht komt toe aan eenieder, en de klacht gaat naar de markttoezichthouder van de betreffende lidstaat.
Onverminderd andere administratieve of gerechtelijke rechtsmiddelen kan eenieder die redenen heeft om aan te nemen dat er sprake is van een inbreuk op de bepalingen van deze verordening, klachten indienen bij de betreffende markttoezichthouder. Overeenkomstig Verordening (EU) 2019/1020 worden dergelijke klachten in aanmerking genomen bij het verrichten van markttoezichtactiviteiten en behandeld overeenkomstig de daartoe door de markttoezichthouders vastgestelde specifieke procedures.
De praktische betekenis van dit artikel zit niet in wat het u opdraagt maar in wie het een route geeft. Een medewerker die vindt dat het roosterings- of beoordelingssysteem niet deugt, een sollicitant die is afgewezen, een klant die zich onjuist behandeld voelt: zij hoeven u niet eerst te overtuigen en hoeven geen belang aan te tonen. De klacht komt binnen bij de toezichthouder, en de eerste vraag die u dan krijgt gaat over vastlegging: welk systeem, welke versie, welke beoordeling is er gedaan en wanneer. Dat is dezelfde vastlegging die artikel 26 en artikel 72 al van u vragen, en dat is precies het punt. Wie dat dossier op orde heeft, beantwoordt een klacht met stukken; wie het niet heeft, beantwoordt hem met een reconstructie achteraf, en dat leest bij een toezichthouder anders. Merk ook op dat dit recht niet aan een schade of een besluit hangt, waar het recht op uitleg van artikel 86 dat wel doet.
Ga ervan uit dat een klacht bij de toezichthouder begint en niet bij u. Zorg dat u per AI-systeem kunt laten zien welke beoordeling is gedaan, door wie, op welke datum en op welke systeemversie, en houd dat bij als lopend dossier in plaats van als eenmalig document. Spreek daarnaast intern af wie een vraag van een toezichthouder aanneemt en binnen welke termijn.
Artikel 86: recht op uitleg bij een besluit
Wie wordt geraakt door een besluit dat een gebruiksverantwoordelijke neemt op basis van de uitvoer van een hoog-risico AI-systeem uit bijlage III, kan uitleg vragen over de rol van dat systeem in de besluitvorming en over de hoofdelementen van het besluit.
Van toepassing wanneer een gebruiksverantwoordelijke een besluit over een natuurlijke persoon neemt op basis van de uitvoer van een hoog-risico AI-systeem uit bijlage III, met uitzondering van punt 2 van die bijlage, en dat besluit rechtsgevolgen heeft of die persoon op vergelijkbare wijze aanmerkelijk treft op een manier die hij als nadelig ziet voor zijn gezondheid, veiligheid of grondrechten.
Lid 2 sluit het recht uit voor AI-systemen waarvoor uitzonderingen op of beperkingen van deze plicht volgen uit het Unierecht of het nationale recht in overeenstemming met het Unierecht. Lid 3 beperkt het recht bovendien tot gevallen waarin het niet al langs andere weg in het Unierecht is geregeld, wat het onderscheid met artikel 22 van de AVG tot een vraag per geval maakt.
Lid 1 geeft elke geraakte persoon die onderworpen is aan een besluit dat de gebruiksverantwoordelijke neemt op basis van de uitvoer van een in bijlage III opgenomen hoog-risico AI-systeem, met uitzondering van punt 2 van die bijlage, en dat rechtsgevolgen heeft of hem op vergelijkbare wijze aanmerkelijk treft op een manier die hij als nadelig beschouwt voor zijn gezondheid, veiligheid of grondrechten, het recht om van de gebruiksverantwoordelijke duidelijke en zinvolle uitleg te verkrijgen over de rol van het AI-systeem in de besluitvormingsprocedure en over de hoofdelementen van het genomen besluit. Lid 2 bepaalt dat lid 1 niet geldt voor het gebruik van AI-systemen waarvoor uitzonderingen op of beperkingen van die plicht voortvloeien uit het Unierecht of het nationale recht in overeenstemming met het Unierecht. Lid 3 bepaalt dat dit artikel alleen geldt voor zover het in lid 1 bedoelde recht niet anderszins in het Unierecht is vastgelegd.
Dit recht komt bij u binnen langs een ander kanaal dan de rest van de verordening. Een toezichthouder schrijft u aan; een sollicitant of een burger belt of mailt, en meestal bij uw bestaande klachten- of bezwaarloket. Dat loket weet vandaag niet dat er een AI-systeem in het proces zat, laat staan welke rol het speelde, en dat is precies waar het misgaat. Twee dingen zijn daarom belangrijker dan de juridische diepte van de uitleg zelf: dat uw eerstelijns kanaal een verzoek herkent, en dat er per besluit terug te vinden is welk systeem in welke versie eraan heeft bijgedragen. Zonder dat tweede kunt u uitleggen hoe uw systeem in het algemeen werkt, maar niet wat er in dit geval is gebeurd, en dat is wat er wordt gevraagd. Let ook op de verhouding tot artikel 22 van de AVG: waar dat artikel al een recht geeft, wijkt artikel 86 terug, maar de reikwijdte verschilt genoeg dat u die vraag niet in het algemeen kunt afdoen.
Leg vast, per bijlage III-systeem dat aan besluiten over personen bijdraagt, welk besluit door welke systeemversie is ondersteund, en zorg dat uw klachten- of bezwaarloket een verzoek om uitleg herkent en doorzet naar iemand die die vraag kan beantwoorden. Bepaal daarnaast per proces of artikel 22 van de AVG al een recht geeft, want dan wijkt artikel 86 terug.
Een doorlopend, gedocumenteerd risicobeheersysteem over de hele levenscyclus van een hoog-risico AI-systeem.
Het systeem is hoog-risico via Artikel 6 en de aanbieder brengt het op de markt of in gebruik.
Risico’s die alleen bij misbruik buiten elk redelijkerwijs te voorzien gebruik optreden vallen buiten de verplichte scope.
Artikel 9 vereist een risicobeheersysteem als doorlopend en iteratief proces over de hele levenscyclus, met identificatie, analyse, evaluatie en mitigatie van risico’s voor gezondheid, veiligheid en grondrechten, en testen om de meest passende maatregelen te bepalen.
Dit is geen eenmalige risicoanalyse maar een levend proces: de meeste organisaties hebben wel een assessment, maar geen cyclus die bij elke wijziging opnieuw draait. De cyclus is wat een toezichthouder zal opvragen.
Start het risicobeheerdossier nu voor systemen die richting 2 december 2027 hoog-risico worden: ontwerp- en inkoopkeuzes van vandaag bepalen de restrisico’s van morgen.
Artikel 43-49: conformiteitsbeoordeling, CE en registratie
De route van beoordeling naar CE-markering en registratie in de EU-databank vóór marktintroductie van hoog-risico AI.
De aanbieder brengt een hoog-risico systeem op de markt; publieke gebruiksverantwoordelijken registreren ook hun gebruik.
Voor de meeste Bijlage III-systemen volstaat interne controle (Bijlage VI); een aangemelde instantie is vereist voor bepaalde biometrie en waar geharmoniseerde normen ontbreken.
Artikel 43 regelt de conformiteitsbeoordeling, Artikel 47 de EU-conformiteitsverklaring, Artikel 48 de CE-markering en Artikel 49 de registratie in de EU-databank vóór marktintroductie of ingebruikname, inclusief registratie van de Artikel 6 lid 3-beoordeling.
Voor inkopers is dit de eenvoudigste leverancierscheck die er bestaat: vraag naar de conformiteitsverklaring en het registratienummer. Geen verklaring betekent dat het systeem er per 2 december 2027 niet mag zijn.
Plan de conformiteitsroute terug vanaf 2 december 2027: normkeuze, beoordeling, verklaring en registratie kosten samen maanden, geen weken.
Artikel 22-25: waardeketen en gemachtigde
Rolverschuivingen in de AI-waardeketen en de verplichte gemachtigde voor aanbieders buiten de EU.
Een hoog-risico systeem wordt geleverd, gewijzigd, van naam voorzien of van buiten de EU op de Uniemarkt gebracht.
Wie uitsluitend als distributeur of importeur optreedt zonder de triggers van Artikel 25 blijft in die lichtere rol, met eigen controleplichten.
Artikel 25 bepaalt dat een distributeur, importeur, gebruiksverantwoordelijke of derde als aanbieder geldt wanneer die zijn naam op een hoog-risico systeem zet, het wezenlijk wijzigt of het beoogde doel zodanig verandert dat het hoog-risico wordt; Artikel 22 verplicht aanbieders uit derde landen tot een schriftelijk gemachtigde in de Unie.
De gevaarlijkste rolwissel is de onbedoelde: een eigen laag bovenop een ingekocht model, een eigen merknaam op een tool, en u draagt opeens de volledige aanbiedersplichten. Dit hoort als vaste vraag in elk AI-project.
Neem de rolvraag op in het AI-register en in projectgates, en leg contractueel vast wie bij wijzigingen welke informatie en medewerking levert.
EN 18286:2026: kwaliteitsmanagementsysteem voor AI Act-doeleinden
De eerste voltooide Europese norm onder het AI Act-standaardisatieverzoek: het kwaliteitsmanagementsysteem dat artikel 17 van aanbieders van hoog-risico AI-systemen verlangt.
Relevant voor aanbieders van hoog-risico AI-systemen, die uiterlijk 2 december 2027 (Annex III, standalone) of 2 augustus 2028 (Annex I, ingebed in gereguleerde producten) een kwaliteitsmanagementsysteem moeten hebben.
Volgens diezelfde dekkingsverklaring geeft de norm geen dekking voor artikel 17 leden 2 tot en met 4 en artikel 72; die verplichtingen onderbouwt u zelfstandig.
EN 18286:2026 (Artificial intelligence: Quality management system for EU AI Act regulatory purposes) is opgesteld door CEN/CLC/JTC 21 onder standaardisatieverzoek M/613 en is op 12 juli 2026 door CEN-CENELEC goedgekeurd. Het is de eerste JTC 21-deliverable die het publicatiestadium bereikt. Volgens een gepubliceerde dekkingsverklaring bij de norm, die nog niet door een tweede onafhankelijke bron is bevestigd, ziet de norm op artikel 17 lid 1 punten a tot en met m en op artikel 11 lid 1 eerste zin, en uitdrukkelijk niet op artikel 17 leden 2 tot en met 4 en artikel 72. De norm is op dit moment NIET met referentie in het Publicatieblad bekendgemaakt. Het vermoeden van conformiteit van artikel 40 treedt pas in na die bekendmaking.
Dit is de eerste keer dat u de AI Act-kwaliteitseisen als een auditeerbare normtekst in handen heeft, en dat is meer waard dan de juridische status suggereert. De praktijkval is de omgekeerde: mensen lezen "eerste geharmoniseerde norm" en denken dat naleving nu bewijskracht heeft. Zolang de referentie niet in het Publicatieblad staat, is EN 18286 gewoon een goed gestructureerd document zonder wettelijk vermoeden. U blijft zelf aantonen dat uw systeem aan artikel 17 voldoet. Omgekeerd geldt: wie nu al op deze structuur bouwt, hoeft na de bekendmaking niets te herbouwen.
Gebruik de clausulestructuur van EN 18286 als inhoudsopgave van uw kwaliteitsdossier: splits organisatorische clausules (governance, leiderschap, planning, ondersteuning, directiebeoordeling) van de systeemgebonden clausules (levenscyclus, operatie, post-market monitoring, incidentafhandeling). Leg per clausule vast welk intern document het bewijs levert. Noteer expliciet dat artikel 17 leden 2 tot en met 4 en artikel 72 buiten de norm vallen en dus apart moeten worden onderbouwd.
EN ISO/IEC 42001: managementsysteem voor kunstmatige intelligentie
Het certificeerbare AI-managementsysteem op organisatieniveau, sinds 2026 ook Europese norm, maar geen geharmoniseerde norm onder de AI-verordening.
Bruikbaar voor zowel aanbieders als gebruiksverantwoordelijken die AI-governance organisatiebreed willen inrichten.
Certificering tegen ISO/IEC 42001 vervangt geen enkele verplichting uit de AI-verordening en verschuift de bewijslast niet.
ISO/IEC 42001:2023 is de eerste certificeerbare internationale norm voor een AI-managementsysteem, gepubliceerd op 18 december 2023 en opgebouwd volgens de plan-do-check-act-cyclus. De tekst is ongewijzigd overgenomen als EN ISO/IEC 42001:2026, goedgekeurd door CEN op 13 maart 2026, met nationale invoering door de aangesloten normalisatie-instituten. Deze adoptie is geen deliverable onder standaardisatieverzoek M/613: de norm is niet met referentie in het Publicatieblad bekendgemaakt en geeft dus geen vermoeden van conformiteit onder artikel 40. Voor artikel 17 is EN 18286:2026 de aangewezen deliverable onder M/613; ook die norm is niet met referentie in het Publicatieblad bekendgemaakt.
EN ISO/IEC 42001:2026, Europese overname via CEN-CENELEC
Hier zit de duurste misvatting in de hele normenlaag: een ISO/IEC 42001-certificaat is geen AI Act-conformiteit. Het certificaat toont aan dat u een besturingsstructuur heeft, niet dat een specifiek hoog-risico systeem aan de verordening voldoet. Gedocumenteerde lacunes ten opzichte van artikel 17 zijn onder meer het ontbreken van een nalevingsstrategie per systeem, van vooraf bepaald wijzigingsbeheer voor blijvend lerende systemen, van de meldtermijnen voor ernstige incidenten uit artikel 73, en van een gestructureerde grondrechtenbeoordeling. Verkopers die "ISO 42001 gecertificeerd, dus AI Act-proof" zeggen, verkopen u een certificaat en niet uw dossier.
Gebruik ISO/IEC 42001 als de organisatorische laag (beleid, rollen, directiebeoordeling, interne audit) en zet daar de systeemgebonden laag bovenop: per hoog-risico systeem een eigen dossier langs de clausules van EN 18286. Vul de hierboven genoemde lacunes bewust aan: nalevingsstrategie per systeem, vooraf bepaald wijzigingsbeheer, incidentmeldproces met de termijnen van artikel 73, en grondrechtenbeoordeling. Vraag bij inkoop niet naar het certificaat maar naar de toepassingsverklaring en de auditrapportage.
ISO/IEC 12792: transparantietaxonomie van AI-systemen
De internationale taxonomie van informatie-elementen voor transparantie, bruikbaar als checklist voor de gebruiksaanwijzing onder artikel 13.
ISO/IEC 12792:2025 (Information technology: Artificial intelligence: Transparency taxonomy of AI systems) is in november 2025 gepubliceerd door ISO/IEC JTC 1/SC 42. De norm specificeert een taxonomie van informatie-elementen waarmee betrokkenen kunnen bepalen welke transparantie-informatie nodig is, en beschrijft de betekenis van die elementen en hun relevantie voor de doelen van verschillende belanghebbenden. De tekst is als Europese norm overgenomen als EN ISO/IEC 12792:2025. De norm is niet met referentie in het Publicatieblad bekendgemaakt en geeft dus geen vermoeden van conformiteit onder artikel 40 AI-verordening. Voor artikel 13 is prEN 18229-3 de aangewezen deliverable.
De waarde zit in de volledigheidscontrole: de taxonomie laat zien welke informatie-elementen u kunt vergeten, en dat is precies waar gebruiksaanwijzingen in de praktijk tekortschieten. Wat het niet is: een sjabloon dat aan artikel 13 voldoet. De verordening bepaalt zelf welke informatie de gebruiksaanwijzing moet bevatten, waaronder de gegevens van de aanbieder, de kenmerken en beperkingen, de nauwkeurigheidsmaatstaven, de toezichtsmaatregelen en de verwachte levensduur. Let ook op de verwarring met artikel 50: die transparantieverplichtingen gelden sinds 2 augustus 2026 en rusten op aanbieders van AI-systemen die rechtstreeks met natuurlijke personen communiceren of synthetische inhoud genereren, en op gebruiksverantwoordelijken van emotieherkenning, biometrische categorisering en deepfakes. Zij staan los van de hoog-risico-indeling. Voor systemen die al voor 2 augustus 2026 op de markt waren, geldt voor de machineleesbare markering van artikel 50 lid 2 een overgangstermijn tot 2 december 2026.
Bouw uw gebruiksaanwijzing op als een genummerde lijst die één op één de elementen van artikel 13 lid 3 volgt, en gebruik de taxonomie van ISO/IEC 12792 daarnaast als controlelijst op ontbrekende elementen. Houd de transparantie-informatie van artikel 50 apart, want die richt zich op de eindgebruiker en niet op de gebruiksverantwoordelijke.
ISO/IEC 23894: leidraad voor risicomanagement van AI
De internationale leidraad voor AI-specifiek risicomanagement, bruikbaar als tussenoplossing zolang prEN 18228 nog in ontwerp is.
ISO/IEC 23894:2023 (Information technology: Artificial intelligence: Guidance on risk management) is in februari 2023 gepubliceerd en is de eerste internationale norm die specifiek ingaat op risicomanagement voor AI. De norm is niet-voorschrijvend en is opgebouwd op de structuur van ISO 31000. De tekst is door CEN-CENELEC overgenomen als EN ISO/IEC 23894:2024. De norm is niet met referentie in het Publicatieblad bekendgemaakt en geeft dus geen vermoeden van conformiteit onder artikel 40 AI-verordening. De deliverable die dat wel beoogt te doen voor artikel 9 is prEN 18228.
EN ISO/IEC 23894:2024, Europese overname via CEN-CENELEC
ISO/IEC 23894 geeft u de woordenschat en de procesgang van AI-risicomanagement, en dat is nu al bruikbaar. Waar het niet toereikend is: de norm is een leidraad, niet een eisenset, en zij is geschreven vanuit organisatierisico terwijl artikel 9 uitgaat van risico voor gezondheid, veiligheid en grondrechten van anderen. Een risicoregister dat volledig volgens ISO/IEC 23894 is opgebouwd, dekt artikel 9 dus niet automatisch. Gebruik de norm als steiger, niet als bewijs.
Neem de procesgang van ISO/IEC 23894 over (context, identificatie, analyse, evaluatie, behandeling, monitoring, registratie) en voeg per risico twee AI Act-specifieke velden toe: wie buiten uw organisatie geraakt kan worden, en welk restrisico u aanvaardbaar acht met welke onderbouwing. Zo kunt u het register straks zonder herbouw aansluiten op de definitieve EN 18228.
ISO/IEC 24029-reeks: beoordeling van de robuustheid van neurale netwerken
De internationale reeks die robuustheid van neurale netwerken toetsbaar maakt, bruikbaar als methodiek onder artikel 15 zolang prEN 18229-2 in ontwerp is.
Vooral relevant voor hoog-risico systemen die op neurale netwerken zijn gebaseerd.
ISO/IEC TR 24029-1:2021 (Assessment of the robustness of neural networks, Part 1: Overview) is een technisch rapport dat het onderwerp en de beschikbare beoordelingsmethoden in kaart brengt. ISO/IEC 24029-2:2023 (Part 2: Methodology for the use of formal methods) beschrijft de toepassing van formele methoden bij het beoordelen van robuustheid. De reeks is bedoeld voor AI-ontwikkelaars en gebruikers om robuustheid gedurende de levenscyclus te beoordelen. Geen van beide delen is met referentie in het Publicatieblad bekendgemaakt; er is dus geen vermoeden van conformiteit onder artikel 40 AI-verordening. Voor artikel 15 is prEN 18229-2 de aangewezen deliverable, die naar de stand van juni 2026 nog in drafting was.
Deel 1 is een technisch rapport en dus geen eisenset: het geeft overzicht, geen toetssteen. Deel 2 is inhoudelijk het scherpst, maar formele methoden zijn alleen haalbaar bij relatief afgebakende modellen. Voor grote generatieve modellen loopt u snel tegen de grenzen aan, en dan blijft empirisch testen over. De praktijkval is een robuustheidsclaim doen die alleen op de gemiddelde testset is gemeten: artikel 15 gaat juist over gedrag bij fouten, storingen en onverwachte invoer.
Kies per systeem bewust tussen formele verificatie (bij afgebakende modellen) en empirische stresstests, en leg de keuze en de motivering vast. Test expliciet op afwijkende invoer, ontbrekende velden en randgevallen, en documenteer de prestatiedaling die u dan ziet. Voeg die resultaten toe aan de technische documentatie en aan de gebruiksaanwijzing waar zij de gebruiksgrenzen bepalen.
ISO/IEC 5259-reeks: datakwaliteit voor analytics en machine learning
De vijfdelige internationale reeks over datakwaliteit, in de praktijk de bruikbaarste structuur voor het datagovernance-dossier onder artikel 10.
De ISO/IEC 5259-reeks (Artificial intelligence: Data quality for analytics and machine learning) bestaat uit vijf delen: deel 1 (overzicht, terminologie en voorbeelden), deel 2 (maatstaven voor datakwaliteit), deel 3 (eisen en richtlijnen voor datakwaliteitsmanagement) en deel 4 (procesraamwerk voor datakwaliteit), alle gepubliceerd in 2024, plus deel 5 (governanceraamwerk voor datakwaliteit), gepubliceerd in februari 2025. CEN-CENELEC heeft delen overgenomen als Europese norm, waaronder EN ISO/IEC 5259-4:2025 en EN ISO/IEC 5259-3:2025. Geen enkel deel is met referentie in het Publicatieblad bekendgemaakt; er is dus geen vermoeden van conformiteit onder artikel 40. De deliverable die dat voor artikel 10 beoogt is prEN 18284.
Dit is op dit moment de meest concrete hulp die er is voor artikel 10, omdat deel 2 datakwaliteit daadwerkelijk meetbaar maakt in plaats van er alleen over te spreken. Wat het niet is: een dekking van artikel 10. De verordening vraagt zaken die de reeks niet kent, zoals het onderzoek naar mogelijke vooringenomenheid met het oog op grondrechten en de representativiteit voor de specifieke beoogde gebruikspopulatie in de EU. Een dataset die op alle 5259-maatstaven goed scoort, kan nog steeds structureel een bevolkingsgroep ondervertegenwoordigen.
Gebruik deel 2 om per dataset een klein aantal harde kwaliteitsmaatstaven vast te leggen en deel 4 om het proces te beschrijven waarmee die maatstaven worden bewaakt. Voeg daar twee AI Act-velden aan toe die de reeks niet dekt: representativiteit voor de beoogde gebruikspopulatie, en de uitkomst van het vooringenomenheidsonderzoek met de genomen maatregelen. Bewaar de meetresultaten per datasetversie, niet alleen voor de laatste versie.
prEN 18228: AI-risicomanagement voor hoog-risico systemen
De ontwerp-Europese norm die het risicomanagementsysteem van artikel 9 invult, met een productveiligheidsbenadering in plaats van een bedrijfsrisicobenadering.
Van belang voor aanbieders die zich voorbereiden op de hoog-risico verplichtingen per 2 december 2027 (Annex III) of 2 augustus 2028 (Annex I).
prEN 18228 (AI risk management) is de JTC 21-deliverable onder M/613 die is bedoeld om vermoeden van conformiteit te geven met artikel 9 AI-verordening: het risicomanagementsysteem dat aanbieders van hoog-risico AI-systemen gedurende de gehele levenscyclus moeten opzetten, uitvoeren, documenteren en onderhouden. De publieke Enquiry liep tot 30 juli 2026. De norm is nog niet als EN gepubliceerd en is niet met referentie in het Publicatieblad bekendgemaakt. De aanduiding prEN betekent dat het om een ontwerptekst gaat.
prEN 18228 (ontwerpnorm), CEN/CLC/JTC 21 onder M/613
Het onderscheidende punt is de invalshoek. prEN 18228 is geschreven vanuit productveiligheid: het gaat om risico's voor gezondheid, veiligheid en grondrechten van derden, niet om risico's voor uw organisatie. Wie zijn artikel 9-dossier vult met een bestaand ISO 31000- of ERM-register maakt precies de fout die deze norm blootlegt: dat register kijkt naar binnen, artikel 9 kijkt naar buiten. Een ontwerpnorm is bovendien nog geen bewijs: u kunt de systematiek overnemen, maar u kunt er nu niets mee bewijzen tegenover een toezichthouder.
Zet uw artikel 9-risicoregister nu al op met de blik naar buiten: per voorzienbaar gebruik en voorzienbaar misbruik benoemt u welke persoon of groep geraakt kan worden, welke maatregel het risico verkleint en welk restrisico blijft. Houd de structuur los van uw ERM-register, zodat u de definitieve EN 18228 er straks overheen kunt leggen zonder de inhoud te herschrijven.
prEN 18229-1: AI-betrouwbaarheidskader deel 1, logging
De ontwerp-Europese norm voor de automatische registratie van gebeurtenissen die artikel 12 van hoog-risico AI-systemen verlangt.
Aanbieders bouwen de logmogelijkheid in (artikel 12) en bewaren de logs die onder hun controle staan (artikel 19); gebruiksverantwoordelijken bewaren de door het systeem gegenereerde logs (artikel 26 lid 6).
prEN 18229-1 (AI trustworthiness framework, Part 1: Logging) is de JTC 21-deliverable onder M/613 voor artikel 12 AI-verordening: hoog-risico AI-systemen moeten technisch in staat zijn gebeurtenissen gedurende hun levensduur automatisch te registreren. De deliverable bevond zich naar de stand van juni 2026 in het Enquiry-stadium. De norm is nog niet als EN gepubliceerd en is niet met referentie in het Publicatieblad bekendgemaakt.
prEN 18229-1 (ontwerpnorm), CEN/CLC/JTC 21 onder M/613
Artikel 12; artikel 19; artikel 26, lid 6; artikel 40
Logging is de verplichting die het goedkoopst is om nu goed te doen en het duurst om achteraf te repareren, want een systeem dat niet logt, kan niet met terugwerkende kracht gaan loggen. Let op de rolverdeling: de aanbieder moet de logmogelijkheid inbouwen, de gebruiksverantwoordelijke moet de logs bewaren. Wie een systeem inkoopt zonder te controleren of het logt, koopt een gat in zijn eigen dossier. Deze norm is nog een ontwerptekst en geeft dus nog geen bewijskracht.
Neem de logvereiste op in uw inkoopvoorwaarden en in de acceptatietest: welke gebeurtenissen worden geregistreerd, met welke tijdstempel, hoe lang blijven ze bewaard en hoe exporteert u ze naar een toezichthouder. Documenteer die antwoorden nu per systeem, zodat de definitieve EN 18229-1 later alleen nog hoeft te worden gespiegeld aan wat u al vastlegt.
prEN 18229-2: AI-betrouwbaarheidskader deel 2, nauwkeurigheid en robuustheid
De ontwerp-Europese norm die het passende niveau van nauwkeurigheid en robuustheid uit artikel 15 meetbaar moet maken.
prEN 18229-2 (AI trustworthiness framework, Part 2: Accuracy and robustness) is de JTC 21-deliverable onder M/613 voor artikel 15 AI-verordening, dat van hoog-risico AI-systemen een passend niveau van nauwkeurigheid, robuustheid en cyberbeveiliging verlangt en de opgave van nauwkeurigheidsmaatstaven in de gebruiksaanwijzing vereist. De deliverable bevond zich naar de stand van juni 2026 in het drafting-stadium. De norm is nog niet als EN gepubliceerd en is niet met referentie in het Publicatieblad bekendgemaakt.
prEN 18229-2 (ontwerpnorm), CEN/CLC/JTC 21 onder M/613
Artikel 15 laat open wat "passend" is, en juist die open norm zou deze deliverable invullen. Zolang hij niet af is, moet u zelf motiveren welk nauwkeurigheidsniveau bij uw toepassing hoort en waarom. De praktijkval is een enkel percentage in de gebruiksaanwijzing zetten zonder te vermelden op welke populatie en onder welke omstandigheden het is gemeten: dat is geen maatstaf, dat is een marketingcijfer. Een toezichthouder vraagt naar de meetopzet.
Leg per hoog-risico systeem een testprotocol vast: welke maatstaf, welke testpopulatie, welke subgroepen apart gemeten, welke prestatiedaling onder afwijkende omstandigheden aanvaardbaar is. Gebruik de ISO/IEC 24029-reeks voor de robuustheidsmethodiek en bewaar de ruwe testresultaten, niet alleen de samenvatting.
prEN 18229-3: AI-betrouwbaarheidskader deel 3, transparantie en menselijk toezicht
De ontwerp-Europese norm voor de transparantie- en toezichtseisen van de artikelen 13 en 14 voor hoog-risico AI-systemen.
Aanbieders ontwerpen de toezichtsmaatregelen in op grond van artikel 14; gebruiksverantwoordelijken wijzen op grond van artikel 26 lid 2 personen aan met de nodige bekwaamheid, opleiding en bevoegdheid en geven hun het benodigde mandaat.
prEN 18229-3 (AI trustworthiness framework, Part 3: Transparency and human oversight) is de JTC 21-deliverable onder M/613 die ziet op de artikelen 13 en 14 AI-verordening: transparantie en informatieverstrekking aan gebruiksverantwoordelijken, en het ontwerp voor doeltreffend menselijk toezicht op hoog-risico AI-systemen. De deliverable bevond zich naar de stand van juni 2026 in het drafting-stadium. De norm is nog niet als EN gepubliceerd en is niet met referentie in het Publicatieblad bekendgemaakt. Deze deliverable ziet op artikel 14 (hoog-risico) en niet op de transparantieverplichtingen van artikel 50, die sinds 2 augustus 2026 van kracht zijn.
prEN 18229-3 (ontwerpnorm), CEN/CLC/JTC 21 onder M/613
Artikelen 13 en 14; artikel 26, lid 2; artikel 40
Menselijk toezicht is de verplichting die het vaakst op papier bestaat en in de praktijk niet werkt. Artikel 14 verlangt dat de aangewezen persoon de uitkomst daadwerkelijk kan begrijpen, negeren en terugdraaien. Een medewerker die per dossier dertig seconden heeft en geen mandaat om af te wijken, is geen menselijk toezicht maar een handtekening. De veelgemaakte fout is deze norm afwachten terwijl het knelpunt niet technisch is maar organisatorisch: mandaat, tijd en escalatieroute.
Beschrijf per hoog-risico systeem wie het toezicht uitvoert, welke informatie die persoon op het beslismoment ziet, hoeveel tijd daarvoor staat, welk mandaat er is om af te wijken en hoe die afwijking wordt vastgelegd. Die vier antwoorden zijn de kern van uw artikel 14-bewijs en veranderen niet door de definitieve normtekst.
prEN 18284: kwaliteit en governance van datasets in AI
De ontwerp-Europese norm die de datagovernance-eisen van artikel 10 voor trainings-, validatie- en testdata operationeel maakt.
Geldt voor aanbieders van hoog-risico AI-systemen die met data worden getraind.
prEN 18284 (Artificial intelligence: Quality and governance of datasets in AI) is de JTC 21-deliverable onder M/613 voor artikel 10 AI-verordening, dat eisen stelt aan trainings-, validatie- en testdatasets van hoog-risico AI-systemen. De deliverable bevond zich naar de stand van juni 2026 in het drafting-stadium. De norm is nog niet als EN gepubliceerd en is niet met referentie in het Publicatieblad bekendgemaakt.
prEN 18284 (ontwerpnorm), CEN/CLC/JTC 21 onder M/613
Artikel 10 is de bepaling waar de meeste organisaties feitelijk stuklopen, omdat zij de herkomst en de bewerkingsgeschiedenis van hun data nooit hebben vastgelegd. prEN 18284 zal dat vastleggen tot norm verheffen. De veelgemaakte fout is te wachten met datalineage tot de norm er is: die documentatie is retroactief bijna niet te reconstrueren. Wat u nu niet vastlegt, kunt u over twee jaar niet alsnog bewijzen.
Begin nu met een dataset-paspoort per hoog-risico systeem: herkomst, verzamelmethode, verwerkingsstappen, representativiteit voor de beoogde gebruikspopulatie, bekende hiaten en de uitgevoerde vooringenomenheidscontrole. Gebruik de ISO/IEC 5259-reeks als voorlopige structuur en houd de velden generiek, zodat u ze kunt hernoemen naar de terminologie van de definitieve EN 18284.
prEN 18285: raamwerk voor conformiteitsbeoordeling van AI-systemen
De ontwerp-Europese norm die de conformiteitsbeoordelingsprocedure van artikel 43 en bijlage VII operationeel maakt.
De conformiteitsbeoordeling van artikel 43 rust op de aanbieder. De in de Unie gevestigde gemachtigde houdt op grond van artikel 22 de EU-conformiteitsverklaring en de technische documentatie beschikbaar voor de toezichthouder en werkt met hem samen.
prEN 18285 (Conformity assessment framework) is de JTC 21-deliverable onder M/613 die ziet op de conformiteitsbeoordeling van hoog-risico AI-systemen op grond van artikel 43 en bijlage VII AI-verordening. De deliverable bevond zich naar de stand van juni 2026 in het drafting-stadium. De norm is nog niet als EN gepubliceerd en is niet met referentie in het Publicatieblad bekendgemaakt. Het standaardisatieverzoek M/613 is bij Uitvoeringsbesluit C(2025)3871 van 23 juni 2025 gewijzigd en loopt af op 28 februari 2027.
prEN 18285 (ontwerpnorm), CEN/CLC/JTC 21 onder M/613
Artikel 43 en Bijlage VII; artikel 22; artikel 40
Dit is de deliverable die bepaalt hoe zwaar de rest weegt. Voor de meeste Annex III-systemen mag de aanbieder zelf beoordelen (interne controle), maar dat betekent niet dat er niets hoeft: het betekent dat u zelf het volledige dossier moet kunnen tonen. De praktijkval is denken dat zelfbeoordeling licht is. De aangemelde instantie ontbreekt, de bewijslast niet. Zolang prEN 18285 in ontwerp is, is er geen erkende blauwdruk voor die zelfbeoordeling en moet u de structuur zelf verantwoorden.
Bepaal nu per systeem welke beoordelingsroute geldt (interne controle of aangemelde instantie) en bouw uw dossier op als een dossier dat een externe partij zou moeten kunnen lezen, ook als u zelf beoordeelt. Plan achterwaarts vanaf 2 december 2027 voor standalone Annex III-systemen en 2 augustus 2028 voor systemen die in gereguleerde producten zijn ingebed.
Publieke classifier voor de hoog-risico usecases in Bijlage III.
De volledige wettekst in de publieke AI Act Explorer.
Publieke route om maatregelen per rol en context te structureren.
De volledige wettekst van de verboden praktijken met alle categorieën en uitzonderingen, in de publieke AI Act Explorer.
Publieke beslisroute voor de afzonderlijke transparantieverplichtingen.
Publieke generator voor het structureren van een grondrechteneffectbeoordeling.
Publieke gids voor GPAI-modelverplichtingen en uitzonderingen.
Source-traceable links from AI Act changes and obligations to actors, actions, evidence, controls and public tools.
EU Artificial Intelligence Act 2024/1689
Fingerprint of our source record (URL, edition version, verification date). Not an archive copy or content hash of the external document.
Draft guidelines on the classification of high-risk AI systems
CEN-CENELEC JTC 21: European standards under standardisation request M/613
Guidelines on prohibited AI practices, C(2025) 5052 final
Guidelines on the definition of an AI system, C(2025) 5053 final
Living repository of AI literacy practices
Code of Practice on transparency of AI-generated content
ISO/IEC JTC 1/SC 42: international standards for artificial intelligence
Justify the Article 6(3) exception against each individual condition
Name which of the four Article 6(3) conditions you invoke, with facts, and separately justify why the system poses no significant risk of harm to health, safety or fundamental rights and does not materially influence the outcome of decision making.
The intended purpose of the system falls within a use case listed in Annex III.
Notwithstanding the first subparagraph of Article 6(3), an AI system referred to in Annex III shall always be considered high-risk where it performs profiling of natural persons.
Classify the use case and document the outcome
Assess Article 5, Article 6 and Annex III in that order and document purpose, context and any Article 6(3) exception.
Run the profiling test before invoking the Article 6(3) exception
Establish as the first question whether the system performs profiling of natural persons; if yes, the Article 6(3) route falls away and the system remains high-risk, regardless of the four conditions.
You are considering relying on Article 6(3) for a system falling under Annex III.
Assign human oversight and give those people a mandate
Name, per high-risk system, who exercises oversight, and ensure that person has the competence, training, authority and support to actually set the output aside.
To be carried out before putting into service and again on every change to the intended purpose or to the provider's instructions for use.
Assess origin, representativeness, errors and completeness and examine possible bias with appropriate mitigation.
Document system description, development process, data, oversight measures, performance and risk management before market placement.
Ensure the system automatically records events relevant to risk identification and post-market monitoring.
Describe capabilities, limitations, accuracy, oversight measures and expected lifetime in comprehensible form.
Design and assign effective human oversight
Determine oversight measures per system, appoint competent persons and give them the mandate to intervene or stop.
Set and test performance and security levels
Determine appropriate accuracy, test robustness against errors and misuse, and take AI-specific security measures.
Describe strategies, procedures and responsibilities for compliance, from design and data to post-market monitoring.
Take role- and context-specific AI literacy measures
Determine for each role, system and context which combination of instruction, guidance, practice or training is appropriate.
Determine per role which knowledge is needed to use the specific system responsibly
Map roles against the AI systems they use and record per combination what a person must be able to judge: what the system does, where it fails, who it is applied to, and when to intervene or escalate.
Your organisation is a provider or deployer of at least one AI system within scope.
Article 4 prescribes no specific course format, exam or certificate and does not require a guaranteed individual level.
Deliver instruction at the moment a new tool or a new employee arrives
Attach the literacy measure to two fixed moments in existing processes: the rollout of a new AI tool and the onboarding of anyone gaining access to an existing tool.
A new AI tool is put into use or a person gains access to an existing AI tool.
Screen every use case against Article 5 first
Before procurement, build or deployment, check whether the use case falls under a prohibited practice and stop or redesign early rather than after the fact.
Implement the applicable disclosure, marking or label
First determine which paragraph of Article 50 applies, then implement the specific transparency measure.
Record per publication channel when AI text carries a disclosure and who holds editorial responsibility
Determine per channel whether the text is published to inform the public on matters of public interest, who performs the human review, who holds editorial responsibility, and which standard wording you use when the disclosure is required.
You are a deployer and publish content generated or manipulated, wholly or partly, by an AI system.
The Article 50(4) duty does not apply where the use is authorised by law to detect, prevent, investigate or prosecute criminal offences.
Test every system in your AI register against the five Article 50 scenarios
For each AI system, walk through the distinct Article 50 scenarios (direct interaction, synthetic output, emotion recognition or biometric categorisation, deep fake, published text on matters of public interest) and record per paragraph whether it applies, does not apply or falls under an exception, with the reason.
The system is in your AI register and is placed on the market, put into service or used in the Union.
Article 50(1) does not apply where it is obvious, from the point of view of a reasonably well-informed, observant and circumspect natural person and taking into account the circumstances and the context of use, that the person is interacting with an AI system. In addition, paragraphs 1 to 4 each contain an exception for AI systems authorised by law to detect, prevent, investigate or prosecute criminal offences, subject to appropriate safeguards for the rights and freedoms of third parties. In paragraph 1 that latter exception does not apply to systems available for the public to report a criminal offence.
Perform model evaluations and risk mitigation
Evaluate the model including adversarial testing, assess and mitigate systemic risks, report serious incidents and secure the model.
Apply to a sandbox and agree the sandbox plan
Apply to the competent authority, agree a specific sandbox plan, and record which uncertainty about the Regulation you want resolved inside the sandbox.
Applies as soon as you decide to enter an AI regulatory sandbox as a provider or prospective provider, possibly in partnership with a deployer or another third party.
Article 58(2), point (d), requires the implementing acts to ensure access free of charge for SMEs and start-ups, subject to exceptional costs that the authority may recover in a fair and proportionate manner. The Regulation does not extend that free access to larger undertakings. Check with the authority concerned which cost regime it applies for as long as the implementing acts have not been adopted.
Submit the testing plan, obtain approval and register the test
Draw up a real-world testing plan, submit it to the market surveillance authority, obtain approval, register the test with a Union-wide unique single identification number, and record the division of roles with your deployer.
Applies before you start testing in real world conditions outside a sandbox. All conditions in Article 60(4) must be met cumulatively; it is not a menu.
Tacit approval after 30 days applies only where national law provides for it. Where national law does not, express authorisation remains required. For the systems referred to in Annex III, points 1, 6 and 7, in law enforcement, migration, asylum and border control, registration runs through the secure non-public section of the EU database under Article 49(4), point (d). For the systems referred to in Annex III, point 2, critical infrastructure, a different route applies: Article 49(5) requires registration at national level.
Systematically collect and analyse real-world data on the system’s performance and compliance throughout its lifetime.
Set up an incident process with reporting routes
Define what a serious incident is, assign the reporting route to the supervisor and rehearse the process.
Set up an iterative risk management process
Identify and analyse known and reasonably foreseeable risks, evaluate them and take measures, repeating the cycle on every change.
Assign an internal owner and a date to each point of Article 16
Translate the twelve points (a) to (l) into twelve named owners with a start date, so that no point falls between product management, quality and legal.
To be carried out as soon as it is established that you are the provider of a system classified as high-risk under Article 6, well before the intended date of placing on the market.
Complete the conformity route before market placement
Select the correct assessment procedure, draw up the EU declaration of conformity, affix the CE marking and register in the EU database.
Map the affected groups and their specific risks of harm
Name the categories of natural persons and groups likely to be affected by the use in this specific context, and work out the specific risks of harm per category, using the information the provider supplied under Article 13.
You are a body governed by public law, a private entity providing public services, or a deployer of a system under Annex III point 5(b) or 5(c), and you deploy a high-risk system under Article 6(2).
High-risk AI systems intended for the area listed in Annex III point 2 fall outside the Article 27(1) FRIA duty.
Assess process, duration, affected persons, risks, oversight, mitigation and complaint mechanisms and notify results where required.
Set up the complaint mechanism and internal governance before the system runs
Describe the measures taken if a risk materialises, who decides internally, through which route an affected person can complain, within which deadline you respond, and who is authorised to stop the use.
The Article 27(1) FRIA duty applies to the system.
Maintain GPAI documentation and transparency information
Maintain technical documentation, information for downstream providers, a copyright policy and a public summary of training content.
Assemble the downstream information package under Annex XII
Build one package for providers integrating your model, covering the intended tasks and integration options, acceptable use policies, release date and distribution methods, interaction with external hardware or software, software versions, architecture and parameter count, modality and format of inputs and outputs including maximum size, licence, required technical means, and information on the training, testing and validation data used.
You are a provider of a general-purpose AI model placed on the Union market.
Article 53(2) exempts providers of models released under a free and open-source licence whose parameters and related information are publicly available from points (a) and (b) of paragraph 1. That exception does not apply to GPAI models with systemic risk.
Implement rights-reservation detection inside your copyright policy
Record which techniques you use to identify a reservation of rights within the meaning of Article 4(3) of Directive (EU) 2019/790 when collecting training data, how often you recheck, and how you then comply with that reservation.
The open-source exemption in Article 53(2) covers only points (a) and (b) of paragraph 1 and therefore leaves the point (c) copyright policy intact.
Set up how you handle a request for an explanation
Ensure your complaints or objections desk recognises a request for an explanation of an AI-supported decision, that it can be traced per decision which system in which version contributed to it, and that someone is designated to give the explanation.
To be set up before an Annex III system contributes to decisions about natural persons, and to be revisited on every change to that decision process.
Make sure you can answer a complaint with documents
Record per AI system which assessment was carried out, by whom, on what date and against which system version, and agree who receives a question from the authority and within what period.
Perform the Article 24(1) check before making available
Verify the CE marking, the presence of the EU declaration of conformity and the instructions for use, and whether the provider and importer complied with Article 16, points (b) and (c), and Article 23(3).
To be carried out before every making available on the market, including where you supply the system free of charge or as part of a service bundle (Article 3(10)).
Run the four verifications of Article 23(1) before importing
Check and record: the conformity assessment has been carried out, the technical documentation exists, the CE marking plus declaration and instructions for use are present, and an authorised representative has been appointed.
To be carried out before every first placing on the market of a high-risk AI system from a third-country provider.
Assess the value-chain role per system and change
On white-labelling, substantial modification or purpose change, assess whether your organisation becomes the provider, and arrange the representative for non-EU supply.
The Commission office that supervises providers of general-purpose AI models. AI Office enforcement is active since 2 August 2026.
The authorised representative is the party located in the Union that, on the basis of a written mandate, performs and carries out the obligations and procedures of the Regulation on behalf of a provider established outside the EU. The definition in Article 3(5) already applies today, so the role can be determined now. The appointment duty itself starts on 2 December 2027 for the standalone Annex III route and on 2 August 2028 for the embedded Annex I route. From those dates, a third-country provider may not place a high-risk AI system on the Union market without an appointed representative.
Mandatory for providers of high-risk AI systems established in a third country, before they place those systems on the Union market (Article 22(1)). This duty starts on 2 December 2027 for the standalone Annex III route (Article 6(2)) and on 2 August 2028 for the embedded Annex I route (Article 6(1)). The definition and role determination in Article 3(5) already apply today.
Article 22 covers the high-risk AI system route. The definition in Article 3(5) also mentions general-purpose AI models; that route has its own regime, which is not elaborated here.
A deployer of the relevant creditworthiness or life and health insurance systems in Annex III point 5(b) or 5(c).
An organisation using an AI system under its authority, excluding personal non-professional use.
You are a distributor if you make an AI system available on the Union market without being the provider or the importer. This catches resellers, systems integrators and managed service providers that pass on someone else's AI.
Applies where you sit in the supply chain, are neither provider nor importer, and supply the system in the course of a commercial activity. Supply free of charge expressly counts.
If you put your own name or trade mark on a high-risk system already placed on the market, or make a substantial modification, or change its intended purpose, Article 25(1) treats you as a provider. Point (a) applies without prejudice to contractual arrangements stipulating that the obligations are otherwise allocated. The role switch can be determined today; the duties of Article 16 start to apply on 2 December 2027 for the standalone Annex III route and on 2 August 2028 for the embedded Annex I route.
A party that places a general-purpose AI model on the Union market.
You are an importer as soon as you, from within the EU, first place an AI system on the Union market that bears the name or trade mark of a party established outside the EU. What counts is not your purchasing role but whose brand is on the system and who first brings it to market.
Applies where you are located or established in the Union and are the first to place an AI system from a third-country provider on the Union market under that provider's name or trade mark.
You are not an importer but a provider as soon as you put your own name or trade mark on the system, make a substantial modification, or change the intended purpose so that the system becomes high-risk (Article 25(1)(a), (b) and (c)). Point (a) expressly applies without prejudice to contractual arrangements stipulating that the obligations are otherwise allocated. The role switch can be determined today; the twelve duties of Article 16 start to apply on 2 December 2027 for the standalone Annex III route and on 2 August 2028 for the embedded Annex I route.
The national authority that supervises compliance with the Regulation and receives serious incident and risk notifications. Which body fills this role per Member State is not recorded in the graph.
A party that develops or has an AI system developed and places it on the market under its own name.
A deployer that is a body governed by public law.
A private deployer providing public services.
The regulation entered into force on 1 August 2024, after which the obligations followed in phases.
Regulation (EU) 2024/1689 appeared in the Official Journal on 12 July 2024 and entered into force on 1 August 2024. Article 113 sets out that most provisions only become applicable later.
Prohibited practices and AI literacy apply
Since 2 February 2025 the Article 5 prohibition and the Article 4 AI literacy duty apply.
Chapter I and Chapter II became applicable on 2 February 2025. That makes the prohibited practices the first category with enforceable duties.
Article 113, second paragraph, point (a)
General-Purpose AI Code of Practice published
The voluntary code of practice gives GPAI model providers a route to demonstrate compliance.
The Commission published the General-Purpose AI Code of Practice on 10 July 2025. Signing is voluntary; signatories can rely on it to demonstrate compliance with the GPAI obligations.
Code of Practice for General-Purpose AI, 10 July 2025
Guidelines on the scope of the GPAI obligations
The Commission explains when someone becomes the provider of a GPAI model, including through fine-tuning.
Guidelines C(2025) 5045 final of 18 July 2025 describe the scope of the obligations for providers of GPAI models, including when a party modifying a model becomes a provider itself.
Guidelines on the definition of an AI system
The Commission draws the line between software that does and does not fall under the regulation.
Guidelines C(2025) 5053 final of 29 July 2025 explain Article 3(1) through borderline cases, such as classical optimisation, statistical estimation and expert systems.
Worked examples for each Article 5 prohibition, with the line between permitted and prohibited.
Guidelines C(2025) 5052 final of 29 July 2025 work out each Article 5 prohibition with examples. The guidelines are non-binding: authoritative interpretation rests with the Court of Justice.
Since 2 August 2025 the obligations for providers of general-purpose AI models apply.
Chapter V became applicable on 2 August 2025. Models placed on the market before that date must comply by 2 August 2027 at the latest.
Draft guidelines on high-risk classification
The Commission explains in consultation when a system falls under Annex I or Annex III.
On 19 May 2026 the Commission published draft guidelines on the classification of high-risk AI systems for stakeholder consultation, with separate annexes on Annex I and Annex III. The text is non-binding and not yet final.
Draft guidelines of 19 May 2026, annexes on Annex I and Annex III
A voluntary route to comply with parts of Article 50, in two separately signable sections.
The Code of Practice on transparency of AI-generated content appeared on 10 June 2026. After a positive adequacy assessment, signatories can rely on it for Article 50(2), (3) and (5). Section 1 addresses providers, section 2 deployers.
Code of Practice on Transparency of AI-generated Content, 10 June 2026
EN 18286:2026 on the quality management system is the first completed standard under the standardisation request.
CEN-CENELEC approved EN 18286:2026 on 12 July 2026. It is the first JTC 21 deliverable under standardisation request M/613 to reach the publication stage.
EN 18286:2026, CEN/CLC/JTC 21 under standardisation request M/613
The Commission works out the transparency duties and confirms they apply from 2 August 2026.
Guidelines C(2026) 5054 final of 20 July 2026 work out the notification and marking duties of Article 50, with worked examples for chatbots, deep fakes and AI texts of public interest.
Annex III core rules moved to 2 December 2027
The amended application date has been binding law since 27 July 2026.
Regulation (EU) 2026/1744 sets application for Article 6(2) and Annex III on 2 December 2027.
Article 4 amended to a duty to take measures
Since 27 July 2026 the organisational duty supports the development of AI literacy without guaranteeing an individual level.
Regulation (EU) 2026/1744 amended Article 4 with effect from 27 July 2026.
Article 4 amendment and entry into force
FRIA follows new date and may cross-reference a DPIA
The FRIA for the relevant Annex III route follows 2 December 2027 and may include or cross-reference relevant DPIA elements.
The amending regulation links the relevant FRIA route to the new application calendar and expressly enables reuse through a DPIA.
Article 27 amendment and amended Article 113
The transparency duties apply since 2 August 2026.
Article 50 became applicable on 2 August 2026 and was not postponed by the Digital Omnibus.
Since 2 August 2026 the Commission can request GPAI information, conduct evaluations and require measures.
Commission enforcement powers for GPAI and the Article 101 fine regime have been active since 2 August 2026.
Grace period for machine-readable marking ends
Systems placed on the market before 2 August 2026 must comply with Article 50(2) by 2 December 2026.
Article 50 has applied to all systems in scope since 2 August 2026. For the machine-readable marking and detectability of paragraph 2 a transition period runs to 2 December 2026, and only for systems placed on the market before 2 August 2026.
Commission Guidelines C(2026) 5054 final, transitional regime under Article 50(2)
New prohibitions require technical safeguards
The Digital Omnibus prohibits AI for child sexual abuse material and non-consensual intimate imagery.
Regulation (EU) 2026/1744 adds a prohibition on AI intended to generate child sexual abuse material or non-consensual intimate imagery. The required technical safeguards must be in place by 2 December 2026.
Regulation (EU) 2026/1744, amendment of Article 5
Models placed on the market before 2 August 2025 have until 2 August 2027.
Article 111(3) gives providers of GPAI models placed on the market before 2 August 2025 until 2 August 2027 to comply with Chapter V.
High-risk AI embedded in regulated products
AI as a safety component of products under Annex I follows on 2 August 2028.
For AI systems under Article 6(1) and Annex I, that is AI as a safety component of products already covered by EU product legislation, the high-risk requirements apply from 2 August 2028.
Regulation (EU) 2026/1744, amended application dates under Article 113
Reclassification on purpose or context change
Reopen classification when intended purpose, use context or system functionality changes materially.
Procurement gate: no signature without a completed classification answer
Block signature of an AI contract until the supplier has answered in writing which Annex III point the intended purpose falls under, whether it relies on Article 6(3), and whether the system profiles natural persons.
You purchase, renew or extend a contract for an AI system or an AI component.
Repeat the data quality assessment before every retraining or dataset change.
Update the file before every release and retain earlier versions traceably.
Periodically verify that logging works, is complete and is retained according to the regime.
At every deployment and update, verify instructions are present, current and internally translated.
Before go-live, test that intervening, stopping and disregarding output actually works and is assigned.
Monitor whether the system stays within declared levels in production and escalate on deviation.
Release gate before placing on the market
A hard block in your release or delivery process: no delivery without a completed conformity assessment, a signed EU declaration of conformity, an affixed CE marking and a completed registration.
Applies at every first supply to the market and again after a substantial modification within the meaning of Article 3(23), that is, a change after placing on the market or putting into service which was not foreseen in the initial conformity assessment and which affects compliance with Chapter III, Section 2, or results in a modification of the assessed intended purpose. Article 43(4) requires a new conformity assessment procedure in that case.
Periodically audit whether practice follows the described system and record deviations and improvements.
Coverage reconciliation: every person with AI access appears in the register
Periodically reconcile the list of accounts and licences with access to AI systems against the participation and instruction register, and clear the gap list with an owner and a deadline.
There are persons outside the standing payroll dealing with AI systems on your behalf.
Article 4 prescribes no coverage percentage, record format or frequency. The reconciliation is a means of showing that the measures reach the persons referred to in Article 4(1); it is not itself a legal obligation.
Check when systems, roles or risks change whether the selected measures remain appropriate.
Repeat the screening for every new system, procurement and material change of purpose or context; an earlier clearance does not cover a new use.
Quarterly sampling of live disclosures and markings in production
Each quarter, sample the systems carrying an Article 50 scenario and verify in the production environment that the disclosure still appears and the marking is still present in the actual output, recording finding, owner and remediation deadline.
Your AI register contains at least one system to which an Article 50 scenario applies.
Before release, test that the applicable disclosure, marking or label is timely, clear and technically effective.
Monitor cumulative training compute and notify the Commission when the threshold is reached.
Supervision inside the sandbox and the conditional fine shield
The authority retains its supervisory and corrective powers and can suspend your testing or participation. If you stay within the plan and follow the guidance in good faith, authorities impose no administrative fines for infringements of this Regulation.
Applies throughout your participation in an AI regulatory sandbox, from entry to exit or termination.
The fine shield is conditional and lapses as soon as you depart from the specific plan or from the terms and conditions of participation, or fail to follow the guidance in good faith. For other Union or national law it applies only where the authorities responsible for that law were actively involved in supervision inside the sandbox and provided guidance. Article 57(12) refers only to participating providers and prospective providers. If you take part as a deployer in partnership under Article 58(2), point (b), do not assume the protection automatically covers your own obligations.
Oversight during the test, incident reporting and recall procedure
The market surveillance authority may inspect unannounced. On a serious incident you report, take immediate mitigation or suspend, and you must have a procedure in place in advance for prompt recall of the system.
Applies throughout the entire duration of the testing in real world conditions, and on its completion, suspension or termination.
The Regulation provides no exception to the duty to report a serious incident or to the inspection powers. The reporting route itself runs through Article 73, which governs the deadlines and the manner of reporting.
Ensure real-world signals (deviations, complaints, incidents) demonstrably lead to analysis and, where needed, measures.
Periodically test whether an incident can be reported within the legal deadlines, including the deployer-to-provider chain.
Reopen the risk management process on changes in purpose, data, model or use context and before every release.
Reassessment on substantial modification
Rerun the conformity route whenever the system is substantially modified.
Suspension and incident notification control
A fixed rule that suspends use and notifies in the correct order as soon as you have reason to consider the system presents a risk or as soon as you identify a serious incident.
Triggered at the threshold of having reason to consider that use may result in a risk, and separately upon identifying a serious incident. For financial institutions the monitoring obligation is deemed fulfilled through the internal governance rules under Union financial services law.
Distributor corrective action, withdrawal and recall control
A pre-arranged capability to bring an already supplied system into conformity, withdraw it or recall it, and to immediately notify the provider or importer and the competent authorities.
Triggered as soon as, on the basis of the information in your possession, you have reason to consider that the system does not comply with Section 2, including where that information comes from a customer rather than the provider.
Routing and deadline tracking of a request for an explanation
The control that ensures an incoming request reaches an identifiable person within a set period and is answered, instead of sitting in a general inbox.
Currency check on the FRIA elements during use
Periodically and on every change in process, duration of use, affected groups, risks or oversight measures, check whether the recorded elements still hold, and update the information as soon as they do not.
The system is in use and an assessment under Article 27(1) has been performed or relied upon.
Block deployment until applicability, assessment, mitigation and notification have been completed.
Half-yearly review of whether your chosen compliance route still covers you
Establish every six months whether you demonstrate compliance through a code of practice, through a published harmonised standard, or through alternative adequate means, and whether the underlying file matches that choice.
Update documentation and downstream information when the model, capabilities or risks change.
Stop rule and notification route on doubts about conformity
As soon as you have sufficient reason to consider a system non-conforming or falsified, it does not go to market, and where there is a risk you notify the provider, the authorised representative and the market surveillance authorities.
Triggered at the threshold of sufficient reason to consider, meaning on a well-founded signal and not only upon certainty or third-party confirmation.
Repeat the role assessment on every rebranding, modification or new use of an existing system.
The role carrying the heaviest obligations, and the role organisations most often end up in by accident.
Article 3(3) defines a provider as a natural or legal person, public authority, agency or other body that develops an AI system or a general-purpose AI model or that has an AI system or a general-purpose AI model developed and places it on the market or puts the AI system into service under its own name or trademark, whether for payment or free of charge.
Many organisations believe they are a provider because they use a model. Use alone is not the test: the dividing line is placing on the market or putting into service under your own name or trademark. Someone who modifies or fine-tunes a general-purpose AI model and places the result on the market does, however, become a provider of that modified model; recital 109 then limits the obligations to that modification or fine-tuning. Conversely, organisations wrongly assume they can never be a provider because they sell nothing: having a system developed counts, free of charge counts, and an internally built tool that you put into service under your own name for your own use makes you a provider alongside being a deployer. Article 25(1) also moves a distributor, importer, deployer or third party into the provider role for a high-risk system when it puts its name or trademark on it, makes a substantial modification, or changes the intended purpose so that the system becomes high risk.
Assess the role question per system, not per organisation, and record the answer with its reasoning. Include three fields in the register: under whose name or trademark the system is offered or put into service, who developed it or had it developed, and whether the intended purpose or configuration has changed since deployment. Reassess those fields on every substantial modification.
A conformity assessment body notified in accordance with this regulation and other relevant Union harmonisation legislation. Only notified bodies may carry out the external assessments under the AI Act.
Article 3(22) defines a notified body as a conformity assessment body notified in accordance with this Regulation and other relevant Union harmonisation legislation.
The biggest misconception is that every high-risk system must pass through a notified body. That is wrong: for most Annex III systems, internal control by the provider itself suffices. External involvement mainly arises for biometrics and for products already covered by the Annex I harmonisation legislation, where existing product certification absorbs the AI requirements. Anyone who routinely demands a notified body certificate in a tender is often demanding something that does not exist for that system, and thereby excludes suitable suppliers.
For each high-risk system, determine whether external assessment is legally required before writing that requirement into a contract or tender, and record the analysis. If you do require notified body involvement, note the body's identification number and scope and verify them in the official Union database.
The national authority responsible for setting up and carrying out the procedures for assessing, designating and notifying conformity assessment bodies, and for monitoring them.
Article 3(19) defines notifying authority as the national authority responsible for setting up and carrying out the necessary procedures for the assessment, designation and notification of conformity assessment bodies and for their monitoring.
The notifying authority is not your point of contact and does not supervise you. It approves the assessors. That distinction is often missed in the market: companies approach the notifying authority when they should be dealing with the market surveillance authority. For most organisations the practical significance is indirect but real: as long as Member States have designated few bodies, capacity is limited for the systems that do require external assessment.
Record in your dossier which national bodies are relevant for your sector and what role each has, so that a notification or question does not go to the wrong party. Explicitly distinguish the notifying authority, the market surveillance authority and any notified body used by your supplier.
Not a standalone authority but a function within the European Commission. For general-purpose AI models the AI Office is your supervisor; for ordinary AI systems it is not.
Article 3(47) defines the AI Office as the Commission's function of contributing to the implementation, monitoring and supervision of AI systems and general-purpose AI models, and AI governance, provided for in the Commission Decision of 24 January 2024. References in the Regulation to the AI Office are to be construed as references to the Commission.
The final sentence matters most: in law the AI Office is the Commission. There is no separate agency to appeal to, and the powers are the Commission's powers. In practice, for providers of general-purpose AI models the AI Office is the enforcer. The Article 53 obligations have applied since 2 August 2025 and have been enforceable since 2 August 2026. For ordinary AI systems your contact is not the AI Office but the national market surveillance authority. Organisations routinely send questions to the wrong desk and lose time doing so.
Set out in your escalation and contact map who approaches whom: questions and notifications about general-purpose AI models go to the AI Office, questions about AI systems go to the national market surveillance authority. Assign one internal owner per route.
Skills, knowledge and understanding that enable providers, deployers and affected persons to deploy AI systems in an informed way and to become aware of the opportunities, risks and possible harm of AI.
Article 3(56) defines AI literacy as skills, knowledge and understanding that allow providers, deployers and affected persons, taking into account their respective rights and obligations under this Regulation, to make an informed deployment of AI systems and to gain awareness of the opportunities and risks of AI and the possible harm it can cause.
The definition is role-bound: literacy must match the rights and obligations of the person concerned, so it means something different for a recruiter than for a developer or a compliance lead. That is where practice goes wrong. Organisations buy one generic e-learning for everyone and consider themselves done, whereas the definition asks for understanding that matches what a person actually does with AI. Article 4 has applied since 2 February 2025 and, following the Digital Omnibus, Regulation (EU) 2026/1744 which entered into force on 27 July 2026, has become an obligation to take measures without a guaranteed individual level. That lowers the bar for the outcome, not for the evidence: you must still show which measures you took and why they are appropriate.
Record which roles in your organisation work with AI, what level of knowledge and understanding each role requires, which measure you put in place for it and when. Retain participation and dates per person, and repeat the measure when someone changes role or a new AI system is taken into use, so you can show at any moment who is demonstrably prepared.
The model is not the system, and that distinction determines which chapter of obligations applies to you.
AI models used for research, development or prototyping activities before they are placed on the market fall outside the definition.
Article 3(63) defines a general-purpose AI model as an AI model, including where such a model is trained with a large amount of data using self-supervision at scale, that displays significant generality and is capable of competently performing a wide range of distinct tasks regardless of the way the model is placed on the market and that can be integrated into a variety of downstream systems or applications, except AI models used for research, development or prototyping activities before they are placed on the market. Point 66 separately defines a general-purpose AI system as an AI system which is based on a general-purpose AI model and which has the capability to serve a variety of purposes, both for direct use as well as for integration in other AI systems.
Model and system are used interchangeably in practice, and that is the heart of the confusion. Point 63 concerns the model, point 66 the system built on top of it. Obligations for GPAI models rest on the model provider; an organisation embedding that model in its own application is in principle dealing with the regime for AI systems. Two further things are missed. The definition expressly excludes models used for research, development or prototyping before they are placed on the market, so the exception lapses at the moment of placing on the market. And the phrase regardless of the way the model is placed on the market means that openly released models can fall within the definition too. On timing: Article 53 has applied since 2 August 2025, the enforcement powers of the Commission and the AI Office and the fines of Article 101 have been active since 2 August 2026, and for models placed on the market before 2 August 2025 the period runs until 2 August 2027.
Distinguish the model layer and the system layer explicitly in your register, and record per application which underlying model is used, from which provider, and whether your organisation itself places that model on the market. When developing your own models, record the moment the research or prototyping stage ends, because that is where the regime begins.
The gateway definition of the Regulation's system track: if your application falls outside it, the obligations for AI systems do not apply. General-purpose AI models run on a separate track under Article 3(63), with their own obligations in Article 53.
Article 3(1) defines an AI system as a machine-based system that is designed to operate with varying levels of autonomy and that may exhibit adaptiveness after deployment, and that, for explicit or implicit objectives, infers, from the input it receives, how to generate outputs such as predictions, content, recommendations, or decisions that can influence physical or virtual environments.
Two mirror-image errors. First, treating only generative AI and language models as AI systems, which leaves classic scoring models, matching algorithms and predictive models out of the register even though they clearly infer how to generate outputs. Second, calling every piece of software AI, which makes the register useless. The hinge is the word infers: a system that merely executes a rule written by a human infers nothing. Note also the word may in may exhibit adaptiveness: adaptiveness after deployment is a possibility, not a condition. A model frozen after training is still an AI system.
For every application, record three answers in your AI register with a date and the name of the assessor: does it operate with some degree of autonomy, does it infer from input how to generate output, and what is that output. When the outcome is negative, keep the reasoning, because that is the document with which you later explain why the system is out of scope.
A controlled framework set up by a competent authority in which you may temporarily develop, train, validate and test an innovative AI system under regulatory supervision, following a sandbox plan.
Article 3(55) defines an AI regulatory sandbox as a controlled framework set up by a competent authority which offers providers or prospective providers of AI systems the possibility to develop, train, validate and test, where appropriate in real-world conditions, an innovative AI system, pursuant to a sandbox plan for a limited time under regulatory supervision.
The biggest misconception is that a sandbox grants an exemption from the Regulation. It does not. The framework is controlled and time-limited and operates under regulatory supervision; it does not suspend obligations. The definition also expressly names prospective providers, so parties that have not yet placed anything on the market can take part. Anyone using the term as marketing language without admission by a competent authority is using it incorrectly.
Record whether your participation has been formally admitted by a competent authority, which period applies, which sandbox plan governs it and which obligations continue to apply during participation. Include the sandbox outcomes in your technical documentation.
The use set by the provider on which the entire risk classification and assessment rest.
Article 3(12) defines intended purpose as the use for which an AI system is intended by the provider, including the specific context and conditions of use, as specified in the information supplied by the provider in the instructions for use, promotional or sales materials and statements, as well as in the technical documentation.
Two things are structurally missed. First, the intended purpose is set by the provider, not by what you as a deployer do with the system. Second, and this hits providers hard: the intended purpose is derived not only from the manual but also from promotional and sales materials and from statements. A marketing claim that the system is also suitable for recruitment or for creditworthiness assessment therefore widens the intended purpose and can shift the risk classification. For deployers the mirror-image warning applies: use outside the intended purpose is not free. It can amount to reasonably foreseeable misuse, and under Article 25(1)(c) it can amount to a change of intended purpose that makes you the provider yourself, but only where the system thereby becomes a high-risk AI system in accordance with Article 6.
Have marketing and product management align claims about application areas explicitly with the instructions for use and the technical documentation, and record that those three sources carry the same scope. As a deployer, record per system the intended purpose as described by the supplier alongside your actual use, and flag every difference as a decision point.
The sensitive data categories from the GDPR and related European rules, imported here because the AI Act attaches both a prohibition and a narrow exception to them.
Article 3(37) defines special categories of personal data as the categories of personal data referred to in Article 9(1) of Regulation (EU) 2016/679, Article 10 of Directive (EU) 2016/680 and Article 10(1) of Regulation (EU) 2018/1725.
The definition cross-refers, but the AI Act gives it two independent consequences. First, it touches Article 5, enforceable since 2 February 2025: biometric categorisation that infers individually sensitive attributes such as race, political opinions, trade union membership, religion, sex life or sexual orientation is prohibited. Second, Article 10(5) contains an exception permitting processing of special category data where strictly necessary to detect and correct bias in high-risk systems. That exception is consistently read too broadly. It applies only to high-risk systems, only where other means demonstrably do not suffice, with technical limits on reuse and transmission, and with deletion once the bias has been addressed. It is not a general basis for starting to collect sensitive attributes because you want to run fairness measurements.
Record whether you rely on Article 10(5), for which high-risk system, why synthetic or anonymised data do not suffice, which technical and organisational safeguards apply, who has access, and at what point the data are deleted. Align this with your data protection officer and cross-reference from your AI dossier to the corresponding data protection impact assessment.
The AI Act uses its own, broader wording than the GDPR, and that difference decides whether you land in Annex III or Article 5.
Article 3(34) defines biometric data as personal data resulting from specific technical processing relating to the physical, physiological or behavioural characteristics of a natural person, such as facial images or dactyloscopic data.
Almost everyone reads the GDPR definition into this one. That goes wrong on a point that is legally decisive: Article 4(14) GDPR requires that the processing allows or confirms unique identification, and that requirement does not appear in point 34 of the AI Act. Data on behavioural characteristics such as keystroke rhythm, gait or voice features can therefore be biometric data under the AI Act even where identification is not the aim. Anyone basing their AI inventory on the GDPR qualification risks missing systems falling under Article 5 or Annex III. For the GDPR side of the same processing, that Regulation continues to apply in full.
Assess biometrics in your AI register separately from the GDPR assessment and record both outcomes side by side. Include systems that process behavioural characteristics without an identification purpose, such as fraud detection on typing behaviour or voice analysis in the customer contact chain.
A one-to-many comparison against a database, to be distinguished from the one-to-one verification of point 36.
Article 3(35) defines biometric identification as the automated recognition of physical, physiological, behavioural, or psychological human features for the purpose of establishing the identity of a natural person by comparing biometric data of that individual to biometric data of individuals stored in a database. Point 36 separately defines biometric verification as the automated, one-to-one verification, including authentication, of the identity of natural persons by comparing their biometric data to previously provided biometric data.
Identification and verification are used interchangeably in conversations with suppliers, while the difference determines the regime. Identification is one-to-many: the system searches for who someone is by comparing against a database holding data on individuals. Verification is one-to-one: the system confirms whether someone is who they claim to be. Access control with a face scan against the employee's own badge record is verification; a camera running faces past a watchlist is identification. A detail that is rarely noticed: point 35 also mentions psychological features, while the definition of biometric data in point 34 does not.
Record in writing for each biometric application whether the comparison is one-to-one or one-to-many, which database is compared against and who controls that database. Ask for this as a hard requirement during procurement, because vendor material rarely speaks in these terms and the answer determines whether you end up in Article 5 or in Annex III.
Post-remote biometric identification system
The residual category: any remote identification that is not real-time. Not prohibited, but high-risk, and subject to its own authorisation regime in law enforcement.
Article 3(43) defines this as a remote biometric identification system other than a real-time remote biometric identification system.
A residual category is not a free zone. Searching recorded footage for individuals after the fact does not fall under the Article 5 prohibition, but it is high-risk under Annex III, point 1(a) from 2 December 2027. For law enforcement, Article 26(10) applies as well: use requires, in principle, prior authorisation, or authorisation requested without undue delay, from a judicial or independent administrative authority, tied to a specific criminal offence. Organisations that offer "we only look back afterwards" as reassurance are confusing the absence of a prohibition with the absence of obligations.
For each search, record who authorised it, which offence or legal basis it rests on, which period and which footage were searched, and what the outcome was.
Real-time remote biometric identification system
Remote identification where capture, comparison and identification happen without significant delay. The legislator explicitly closed the escape route of an artificial delay.
Article 3(42) defines this as a remote biometric identification system whereby the capturing of biometric data, the comparison and the identification all occur without a significant delay, comprising not only instant identification but also limited short delays, in order to avoid circumvention.
The reference to limited short delays is deliberate. It shuts down the design in which a buffer of seconds or minutes is added so the operator can claim the system is not real-time. The distinction matters enormously: the use of real-time remote identification in publicly accessible spaces for law enforcement has been prohibited in principle since 2 February 2025 under Article 5(1)(h), with narrow exceptions requiring prior authorisation and a national legal basis.
Document the processing architecture and the measured latency of the system, including test results. A statement that you "buffer" is not a defence if identification becomes actionable within seconds or minutes in practice.
The marking by which a provider indicates that an AI system conforms to the requirements of Chapter III, Section 2 and to other applicable Union harmonisation legislation providing for its affixing.
Article 3(24) defines CE marking as a marking by which a provider indicates that an AI system is in conformity with the requirements set out in Chapter III, Section 2 and other applicable Union harmonisation legislation providing for its affixing.
The CE marking is a declaration by the provider itself, not a regulator's seal and not a quality label. It belongs solely to high-risk AI systems, so a supplier presenting CE marking as a selling point for an ordinary chatbot is telling you the wrong story. Conversely, the absence of CE marking is not a shortcoming for a system that is not high-risk. For high-risk systems this becomes relevant from 2 December 2027 for Annex III and 2 August 2028 for Annex I.
For every high-risk AI system, request the EU declaration of conformity that must sit behind the CE marking and keep it in your dossier, together with the system version it relates to. Do not accept a reference to CE marking without the underlying declaration as evidence.
The process of demonstrating that a high-risk AI system meets the requirements of Chapter III, Section 2. It is the evidence step for high-risk systems, not for all AI.
Article 3(20) defines conformity assessment as the process of demonstrating whether the requirements set out in Chapter III, Section 2 relating to a high-risk AI system have been fulfilled.
Two misconceptions dominate. The first is that every AI application needs a conformity assessment: the definition expressly limits it to high-risk systems. The second is that conformity assessment equals an external audit: for most Annex III systems the internal control route of Article 43 suffices, with the provider itself demonstrating that the requirements are met. If you conclude you are not high-risk, substantiate that conclusion in writing rather than assuming it silently. The obligations apply to Annex III systems from 2 December 2027 and to Annex I products from 2 August 2028.
Record your risk classification in writing for each AI system, including the reasoning, even where the outcome is that it is not high-risk. Where it is high-risk, also record which route you follow, internal control or involvement of a notified body, and which evidence per requirement of Chapter III, Section 2 sits in the technical documentation.
A body that performs third-party conformity assessment activities, including testing, certification and inspection.
Article 3(21) defines a conformity assessment body as a body that performs third-party conformity assessment activities, including testing, certification and inspection.
The key phrase is third party. An internal audit function, a consultancy or your own quality team is not a conformity assessment body, however thorough the work. Note also the difference from a notified body in point 22: every notified body is a conformity assessment body, but not the reverse. Only after notification may a body carry out the statutory assessments under this regulation. Certificates from bodies that are not notified have commercial value but no legal status under the AI Act.
Before purchasing an external assessment, verify that the body is in fact notified for the relevant scope and record the evidence in your dossier. For every external report, note the role the party had, adviser or notified body, so it never later appears that an advisory report was a statutory assessment.
Far broader than fake videos of famous people: objects, places, entities and events are covered too.
Article 3(60) defines a deep fake as AI-generated or manipulated image, audio or video content that resembles existing persons, objects, places, entities or events and would falsely appear to a person to be authentic or truthful.
The name pushes the reading in the wrong direction. Under this Regulation a deep fake is not limited to fake footage of famous people: the definition expressly also names objects, places, entities and events. An AI-generated photo of an existing building, a demonstration that never happened, or a product image that reads as a real photograph can therefore be a deep fake. Two boundaries matter. The definition names image, audio and video; pure text is not covered, although Article 50 has its own rule for certain publications. And content resembling a non-existent person falls outside point 60, while it may still fall under the marking duty for synthetic output. Article 50 has applied since 2 August 2026; the only transition concerns the machine-readable marking of Article 50(2) for systems already on the market before 2 August 2026, running until 2 December 2026.
Map which departments publish AI-generated image, audio or video content, including marketing, communications, training and customer contact, and record per channel how the artificial origin is disclosed. Include generated images of existing locations and products, because those are precisely the ones rarely recognised as deep fakes.
Any link in the supply chain that makes an AI system available on the Union market and is neither provider nor importer.
Applies only to a party in the supply chain that is neither the provider nor the importer.
Article 3(7) defines a distributor as a natural or legal person in the supply chain, other than the provider or the importer, that makes an AI system available on the Union market.
Resellers, systems integrators, marketplaces and staffing firms that ship software along with their service often assume they fall outside the Regulation because they build nothing. The definition is a residual category: if you are neither provider nor importer in the chain, and you make the system available on the Union market, you are a distributor. Note point 10: making available on the market means supply in the course of a commercial activity, whether for payment or free of charge. Passing something on free or offering a trial version is covered too. Put your own name or trademark on it and the role shifts to provider.
Map which AI systems your organisation passes on to third parties, including free of charge and as a by-product of a service, and record per system whose name or trademark it carries. Set out in your resale contracts who holds which role, so that it is not disputed later who the provider was.
A provider of an AI system, including a general-purpose AI system, which integrates an AI model, regardless of whether that model is provided by themselves and vertically integrated or obtained from another entity on a contractual basis.
Article 3(68) defines a downstream provider as a provider of an AI system, including a general-purpose AI system, which integrates an AI model, regardless of whether the AI model is provided by themselves and vertically integrated or provided by another entity based on contractual relations.
This is the definition organisations most often get wrong about their own role. Anyone integrating a third party model into their own product or service and offering it under their own name is a downstream provider and therefore a provider, not merely a deployer. The words regardless of whether make clear that it does not matter whether you built the model yourself. Your position determines what information you must be able to obtain from the model provider: providers of general-purpose AI models must under Article 53 make documentation available to downstream providers, an obligation applying since 2 August 2025 and enforceable since 2 August 2026.
For each AI system, record which underlying model is integrated, from which party, and whether that makes you a downstream provider. Include in the contract with the model provider which Article 53 documentation you receive, and keep that documentation in your own file.
Prohibited in the workplace and in education since 2 February 2025; elsewhere an information duty under Article 50 applies since 2 August 2026.
The Article 5(1)(f) prohibition does not apply where the use of the AI system is intended to be put in place or into the market for medical or safety reasons.
Article 3(39) defines an emotion recognition system as an AI system for the purpose of identifying or inferring emotions or intentions of natural persons on the basis of their biometric data. Article 5(1)(f) prohibits placing on the market, putting into service for this specific purpose, or using AI systems to infer emotions of a natural person in the areas of workplace and education institutions, except where the use of the AI system is intended to be put in place or into the market for medical or safety reasons.
Two scoping errors. First, assuming that every form of sentiment analysis is covered. The definition requires the inference to be made on the basis of biometric data. Sentiment analysis on written text, without biometrics, falls outside point 39 even though it feels comparable. Second, thinking only of facial expressions, while voice analysis in a call centre and posture analysis from camera footage are equally covered. Note also the word intentions alongside emotions: systems predicting purchase readiness or aggression from biometrics fall within the definition. Outside the workplace and education, emotion recognition is not prohibited, but it is listed in Annex III, point 1(c) and therefore counts as a high-risk AI system there once Article 6(2) becomes applicable on 2 December 2027. In addition, since 2 August 2026 the deployer carries the Article 50(3) duty to inform the exposed persons, except for systems permitted by law to detect, prevent, investigate or prosecute criminal offences.
Map where voice, facial or posture analysis runs in your organisation, including as part of a larger package such as quality monitoring in customer contact, access control or proctoring. Assess per application whether biometric data forms the basis and whether the context is workplace or education; record that assessment, because this is the category carrying a fine of up to EUR 35 million or 7 percent of worldwide turnover.
Four categories of consequence, one of which is an infringement of fundamental rights protection. No physical harm is needed before a notification duty arises.
Article 3(49) defines a serious incident as an incident or malfunctioning of an AI system that directly or indirectly leads to: (a) the death of a person or serious harm to a person's health, (b) a serious and irreversible disruption of the management or operation of critical infrastructure, (c) the infringement of obligations under Union law intended to protect fundamental rights, or (d) serious harm to property or the environment.
Point (c) is the provision organisations miss most often. An infringement of Union law protecting fundamental rights counts as a serious incident, even with no one physically injured. Systematic discrimination in a candidate screening system, in credit scoring or in the allocation of benefits can therefore be notifiable. "Indirectly" counts too: what matters is not only the direct output but the consequence further down the process. Providers of high-risk systems report to the market surveillance authority under Article 73, on short deadlines: in principle within 15 days of becoming aware, 2 days for a widespread infringement or serious disruption of critical infrastructure and 10 days in the event of death. That duty bites from the high-risk dates, Annex III on 2 December 2027 and Annex I on 2 August 2028, but incident logging should start now.
Set up an incident register now that captures the four categories of point 49 separately, with a timestamp at the moment of awareness. Run one drill to confirm you can file a complete notification within two days; that is the tightest deadline and an ad hoc process will not meet it.
The information the provider supplies to inform the deployer about, in particular, the intended purpose and proper use of an AI system. It is the hinge between the provider's obligations and the deployer's.
Article 3(15) defines instructions for use as the information provided by the provider to inform the deployer of, in particular, an AI system's intended purpose and proper use.
In practice this goes wrong in two directions. Providers deliver marketing material or a technical manual instead of instructions that state the intended purpose and the limits of correct use. And deployers file those instructions without reading them, even though Article 26 requires them to use the system in accordance with them. A deployer operating outside the instructions for use can be treated as a provider under Article 25 and thereby take on the full set of provider obligations.
Keep the current instructions for use for each AI system in your dossier, with version number and date of receipt. Also record who in your organisation has read them, which uses you derive as permitted, and which uses you have explicitly prohibited in your own internal work instruction.
The role that virtually every organisation buying and using AI ends up in.
Use in the course of a personal non-professional activity falls outside the definition.
Article 3(4) defines a deployer as a natural or legal person, public authority, agency or other body using an AI system under its authority, except where the AI system is used in the course of a personal non-professional activity.
The role is routinely reduced to user, and that is where it goes wrong. The individual employee operating the tool is not the deployer; the legal entity using the system under its authority is. The second trap is the exception: it covers only personal non-professional use. An employee who takes up an AI tool on their own initiative for work does not fall under that exception, and the organisation remains the deployer even without a procurement contract. Shadow AI is therefore not a grey area but simply an unregistered system.
Record per system which legal entity uses it under its authority, including tools a department procured itself or switched on within an existing licence. Add a periodic inventory of AI features that vendors have activated inside existing software, because those rarely arrive through procurement.
A European standard published in the Official Journal which, if you apply it, produces a presumption of conformity. This is the fastest route to demonstrability, but the AI Act standards are not finished yet.
Article 3(27) defines a harmonised standard as a harmonised standard as defined in Article 2(1), point (c), of Regulation (EU) No 1025/2012.
Textually this is a cross-reference, but the practical weight sits in Article 40: if you apply a harmonised standard whose reference has been published in the Official Journal, you are presumed to comply with the corresponding requirement. That removes a great deal of evidentiary burden. The problem as of the reference date is that the standardisation work at CEN and CENELEC is not yet fully completed and published, so organisations cannot currently lean on a ready-made presumption of conformity. Waiting for the standards is not viable, because the Annex III obligations arrive on 2 December 2027 and the Annex I ones on 2 August 2028. You therefore have to build demonstrability yourself and align later.
Maintain a register recording, per requirement from Chapter III, which standard, framework or internal control you rely on and why that choice covers the requirement. Structure that register so you can replace a row once the harmonised standard is published, without having to rewrite your entire dossier.
A subject's freely given, specific, unambiguous and voluntary expression of willingness to take part in a particular real-world test, after having been informed of all aspects relevant to that decision.
Article 3(59) defines informed consent as a subject's freely given, specific, unambiguous and voluntary expression of his or her willingness to participate in a particular testing in real-world conditions, after having been informed of all aspects of the testing that are relevant to the subject's decision to participate.
Note the word particular: consent applies to one specific test, not to your testing programme as a whole and not to a next version of the system. A general clause in terms of use or an employment contract does not meet this. It is also a concept of its own under the AI Act and not the same as consent as a legal basis under the GDPR, so you cannot cover both with a single form. If the design of the test changes materially, you need fresh consent.
Use a separate consent form for each test containing the information relevant to the decision, and record when and how consent was given and how it can be withdrawn. Document separately that consent was voluntary, particularly for employees.
The European point of contact for a provider from outside the Union, valid only on the basis of a written mandate.
The authorised representative is located or established in the Union and has received and accepted a written mandate.
Article 3(5) defines an authorised representative as a natural or legal person located or established in the Union who has received and accepted a written mandate from a provider of an AI system or a general-purpose AI model to, respectively, perform and carry out on its behalf the obligations and procedures established by this Regulation.
The common error is that a European sales partner, reseller or subsidiary assumes it is automatically the authorised representative. That does not follow from the commercial relationship. The definition sets two cumulative requirements: the mandate is written, and it is not only given but also accepted. Without that document there is no authorised representative and the supervisory authority in the Union has no formal point of contact for that provider. A second misconception is that appointing an authorised representative transfers the provider role. It does not: the representative acts on behalf of the provider, and the provider remains the provider.
Ask every supplier from outside the Union for the name, registered address and contact details of the authorised representative and for a copy or confirmation of the accepted written mandate. Store it with the system file, because it is the first thing you need once a supervisory authority requests information about a system you source from outside the Union.
Technical specifications the Commission can adopt itself when harmonised standards are missing or fall short. The fallback that prevents the AI Act from stalling because standardisation is delayed.
Article 3(28) defines a common specification as a set of technical specifications as defined in Article 2, point (4), of Regulation (EU) No 1025/2012, providing means to comply with certain requirements established under this Regulation.
This definition exists because the legislator anticipated that standardisation would not be ready in time. Article 41 allows the Commission to adopt common specifications through implementing acts, with the same effect: applying them creates a presumption of conformity. The misunderstanding is that a common specification would be optional in practice. It is not: anyone deviating must show that their own technical solution is at least equivalent to the intended level of protection, and that reasoning must sit in the technical documentation. Deviating is allowed, but it costs more documentation than following.
Track the Commission's implementing acts and record which common specifications apply to your system. If you choose your own solution, explicitly document which element you do not follow, which alternative measure you take, and on the basis of which analysis you conclude the level of protection is equivalent.
Operational data around detection and prosecution whose disclosure could harm criminal proceedings. The concept on which the law enforcement exceptions to transparency rest.
Article 3(38) defines sensitive operational data as operational data related to activities of prevention, detection, investigation or prosecution of criminal offences, the disclosure of which could jeopardise the integrity of criminal proceedings.
This is the key with which the AI Act softens transparency obligations for law enforcement without removing them. Registration of high-risk systems used by law enforcement authorities takes place in a secure, non-public section of the EU database, and certain information need not be made public where it concerns sensitive operational data. Where it goes wrong: the concept is sometimes stretched to cover anything a public body would rather not share. That does not hold, because the definition is doubly bounded, namely by the criminal law context and by a concrete risk to the integrity of criminal proceedings. Outside that context it is no basis for withholding documentation; commercially confidential information follows a separate route. Equally important: it limits publication, not the access of the competent market surveillance authority.
Record per system which parts of your registration and documentation you designate as sensitive operational data, on what concrete ground disclosure could harm the integrity of criminal proceedings, who makes that assessment and when it is reviewed. Keep a non-sensitive summary available, so you can still account for the system without touching ongoing proceedings.
Whoever places on the Union market a system bearing the name or trademark of a party established in a third country.
Article 3(6) defines an importer as a natural or legal person located or established in the Union that places on the market an AI system that bears the name or trademark of a natural or legal person established in a third country.
The practical trap is the assumption that importer has to do with customs or with the invoice flow. The test is different: do you place on the Union market for the first time a system bearing the name or trademark of a party from a third country. Someone who only takes a US service for their own use is not an importer but a deployer. Someone who passes on that same system under their own name or trademark is not an importer but a provider. The importer role sits exactly in between: passing it on with the third party's mark still on it.
Record three data points per AI system in your supplier register: the country of establishment of the party whose name or trademark the system bears, whether your organisation is the first to make the system available on the Union market, and under which name that happens. Those three fields together determine whether you are an importer, a distributor or a provider.
The first moment a system or model is made available on the Union market, and therefore the trigger for many obligations.
Article 3(9) defines placing on the market as the first making available of an AI system or a general-purpose AI model on the Union market. Point 10 adds that making available on the market means the supply of an AI system or a general-purpose AI model for distribution or use on the Union market in the course of a commercial activity, whether in return for payment or free of charge.
The most persistent error is assuming that a sale or a price must be involved. Point 10 explicitly says whether in return for payment or free of charge. A free trial, an openly available model or a no-cost pilot at a customer can amount to placing on the market. The second error is confusing this concept with putting into service. Placing on the market concerns the market; a system you build and use purely internally is not placed on the market, but it is put into service, and that is an independent trigger in its own right.
Record for each system and model the date of first making available in the Union, together with its form: sale, free trial, open release or pilot. That date determines which regime and which transitional period apply, and it is the first thing a supervisory authority will put next to your file.
The concept that brings internally built systems which are never sold within the scope of the Regulation.
Article 3(11) defines putting into service as the supply of an AI system for first use directly to the deployer or for own use in the Union for its intended purpose.
This is the trap for organisations that build their own systems. The reasoning runs: we sell nothing, so we place nothing on the market, so provider obligations do not apply. The words or for own use close off that route. As soon as you start using a self-built system in the Union for its intended purpose, you have put it into service, and under point 3 you are a provider as well as a deployer. Note also for first use: a system still running in a test environment and not used for its intended purpose has not yet been put into service.
Register for every internally developed AI system the date on which it went into production for its intended purpose, and note explicitly that your organisation is both provider and deployer. Tie the start of your file-building to that date, and assess immediately whether the system is high risk, because the technical documentation of Article 11 and the logging of Article 12 then apply from that moment and the file need not be reconstructed after the fact.
The data entering the system or acquired by it, on the basis of which it produces its output. This is the data definition that touches the deployer, not just the provider.
Article 3(33) defines input data as data provided to or directly acquired by an AI system on the basis of which the system produces an output.
This is where responsibility moves to your side of the table. Article 26(4) requires the deployer to ensure that input data are relevant and sufficiently representative in view of the intended purpose, to the extent it exercises control over them. The most persistent misconception is that data quality is the supplier's problem. Prompts, uploaded CVs, sensor readings, customer files and connected source systems are all input data, and an excellently built system produces unusable outcomes when you feed it outdated or skewed data. Note the second half of the definition as well: data the system acquires itself, for instance through a camera or an API, are equally input data and therefore fall within your duty of care.
Record per AI system which input data are used, which source systems they come from, who owns their quality and representativeness, how often that is checked, and how long the input is retained in the logs. Explicitly name the input sources you do not control, since that marks the boundary of your duty of care.
Critical infrastructure as defined in Article 2, point (4), of Directive (EU) 2022/2557, the CER Directive. The AI Act gives no definition of its own here but aligns with that framework.
Article 3(62) provides that critical infrastructure means critical infrastructure as defined in Article 2, point (4), of Directive (EU) 2022/2557.
This cross-reference looks like a formality but has direct consequences for the risk class. Annex III, point 2, classifies AI systems as high risk where they are intended to be used as safety components in the management and operation of critical digital infrastructure, road traffic, or the supply of water, gas, heating or electricity. Anyone wanting to know whether they fall within that scope must consult the CER Directive and the national designation of critical entities rather than invent a definition of their own. Organisations get this wrong because designation differs per Member State.
Record whether your organisation or your customer has been designated as a critical entity under the national transposition of Directive (EU) 2022/2557, and link that determination to your risk classification under Annex III, point 2, with date and source.
The national supervisor that enforces the AI Act on the market, with the powers from the general market surveillance regulation. This is the party that comes knocking and requests your documentation.
Article 3(26) defines the market surveillance authority as the national authority carrying out the activities and taking the measures pursuant to Regulation (EU) 2019/1020.
The confusion lies in distinguishing it from two other players. The notifying authority designates notified bodies and does no enforcement towards you; the Commission's AI Office supervises general-purpose AI models under Article 53, which has applied since 2 August 2025 and has been enforceable since 2 August 2026. The market surveillance authority is your actual enforcement contact point for AI systems: it can request technical documentation and logs, demand access to training and testing data sets, and restrict, withdraw or recall a system. The reference to Regulation (EU) 2019/1020 is not a formality, because through it the supervisor inherits a substantial toolkit of powers that did not need restating in the AI Act.
Record per AI system which market surveillance authority is competent (this differs per sector and per Member State where you offer it), who inside your organisation is the point of contact, and within how many working days you can supply the technical documentation, the logs and the data set descriptions. Rehearse that delivery once, because the deadline the supervisor sets is short.
An umbrella term for two very different roles: the notifying authority and the market surveillance authority. For EU institutions the European Data Protection Supervisor takes their place.
Article 3(48) defines a national competent authority as a notifying authority or a market surveillance authority. As regards AI systems put into service or used by Union institutions, agencies, offices and bodies, references to national competent authorities or market surveillance authorities are to be construed as references to the European Data Protection Supervisor.
The definition bundles two roles that should not be confused. The notifying authority designates and supervises conformity assessment bodies; as a deploying organisation you will rarely deal with it. The market surveillance authority supervises you, requests documentation, receives serious incident reports and imposes measures. Member States were required to designate and publish these authorities by 2 August 2025. The fact that designation is not fully settled in some Member States changes nothing about your obligations: the duties rest on you, not on the supervisor.
For every market in which you operate, track which market surveillance authority is competent for your sector, who inside your organisation handles contact and who is authorised to file notifications. State that contact point in your technical documentation.
Everything that is not personal data. The category exists to make clear that the AI Act applies even when no personal data is involved.
Article 3(51) defines non-personal data as data other than personal data as defined in Article 4, point (1), of Regulation (EU) 2016/679.
This residual category is the proof that the AI Act is not a privacy law. The data and data governance requirements in Article 10, the technical documentation in Article 11 and the logging in Article 12 apply equally where you work only with machine data, sensor data or synthetic data. "There is no personal data in it" is at most a GDPR argument and never an AI Act exemption. In practice, technical teams use this argument to avoid documentation duties in industrial and infrastructure applications, which are exactly the applications that can fall under Annex I and Annex III.
Record for each dataset whether it contains personal data, but never let that answer determine whether you produce the AI Act documentation. Assess documentation duties on the system's risk classification, not on the nature of the data.
Any physical place, publicly or privately owned, accessible to an undetermined number of people. Access conditions and capacity limits are irrelevant.
Article 3(44) defines a publicly accessible space as any publicly or privately owned physical place accessible to an undetermined number of natural persons, regardless of whether certain conditions for access may apply and regardless of potential capacity restrictions.
The familiar argument "it is our own premises, so not a public space" does not hold. Shops, stations, airports, stadiums, cinemas, hospital waiting rooms and shopping centres are publicly accessible spaces, even where ticketing, house rules or a capacity cap apply. What matters is whether the circle of visitors is undetermined. An office floor open only to your own staff normally falls outside, because that circle is determined. This concept switches the Article 5 prohibition on real-time remote identification on or off, and feeds through into Annex III classification.
In your camera and biometrics register, mark for each location whether it is a publicly accessible space within the meaning of point 44, with a short justification. Do this before you procure a system, not after.
The umbrella term for all six roles in the chain, and not the person operating the controls.
Article 3(8) defines an operator as a provider, product manufacturer, deployer, authorised representative, importer or distributor.
Operator is read as the person who operates the system day to day. That is precisely what it does not mean. It is an umbrella term: where a provision addresses operators, it addresses all six listed roles at once. Anyone who skips operator obligations in a gap analysis because they believe they are only a deployer misses provisions that do apply to them. Note also that product manufacturer appears in this list as a role but is not separately defined in Article 3.
Add an operator column to your compliance overview that spells out the six roles explicitly, so that for each provision it is visible which roles are affected. Record per AI system every role your organisation holds for that specific system, because there is usually more than one.
The AI Act deliberately creates no separate concept here and refers to the GDPR. Your GDPR records and your AI Act file must therefore cover the same data.
Article 3(50) defines personal data as personal data as defined in Article 4, point (1), of Regulation (EU) 2016/679.
The cross-reference looks dull but has a practical effect: there is no room for a separate AI Act reading of what constitutes personal data. Where the AI Act does open space, such as Article 10(5) permitting processing of special categories to detect and correct bias in high-risk systems, GDPR safeguards apply in full and additional conditions attach. Organisations that keep AI governance and privacy in separate files end up with conflicting descriptions of the same processing, precisely when a supervisor asks for both.
Link every AI system in your AI register to the corresponding processing activity in your GDPR record, using one shared identifier, so that a single change updates both files.
The document in which you set out in advance how you will test an AI system outside the lab: objective, methodology, scope, who takes part, for how long and how you monitor it. Without this plan, testing in real-world conditions is not permitted.
Article 3(53) defines a real-world testing plan as a document that describes the objectives, methodology, geographical, population and temporal scope, monitoring, organisation and conduct of testing in real-world conditions.
In practice this goes wrong because organisations keep calling a pilot with real users a pilot and assume nothing applies. As soon as you trial an AI system with real people in a real environment, you fall under the regime of Article 57 or 60, and that requires a plan drawn up in advance that can be reviewed. A test plan written after the fact to fill a file does not meet the definition, because the essence of the concept is that the design is fixed beforehand.
For every real-world test, record a single document containing the eight elements from the definition: objective, methodology, geographical scope, the population involved, duration, monitoring, organisation and conduct. Link that document to the registration of the test and retain it with the date of approval.
The ability of an AI system to achieve its intended purpose. Performance is therefore measured against the intended purpose, not against a standalone technical score.
Article 3(18) defines performance of an AI system as the ability of an AI system to achieve its intended purpose.
The definition ties performance firmly to the intended purpose in point 12. An accuracy of 94 percent is therefore no answer to whether the system performs, as long as it is not established what it is meant for and for which group of people that score holds. A model that scores well on average but performs structurally worse for a subgroup does not achieve the intended purpose for that group. That is exactly what Article 15 on accuracy and robustness and Article 10 on data quality target.
For each AI system, record which performance metrics you use, which threshold is acceptable for the intended purpose, and how those metrics break down per relevant subgroup. Repeat the measurement periodically and retain the results, so you can demonstrate performance drift before a supervisory authority asks.
For the purpose of real-world testing, a subject is a natural person who participates in such a test. The term comes from the testing regime, not from data protection law.
Article 3(58) defines subject, for the purpose of real-world testing, as a natural person who participates in testing in real-world conditions.
The definition looks trivial but determines who is protected. Whoever is a subject is entitled to informed consent under point 59 and to the safeguards of Articles 57 and 60. The misunderstanding lies in assuming that only external test participants are subjects. Employees who work with a test system during their job can also be subjects, and precisely for them the voluntariness of consent is a sensitive point given the hierarchical relationship.
For each test, keep a record of the subjects or of the clearly delimited group they come from, with the date of their consent and how they were informed. Assess separately whether employees participate as subjects and how you safeguard voluntariness.
Taken from the GDPR, but decisive in the AI Act: an Annex III system that profiles always remains high-risk.
Article 3(52) defines profiling as profiling as defined in Article 4, point (4), of Regulation (EU) 2016/679.
This is the most important of the three GDPR cross-references. Article 6(3) offers an exception under which an Annex III system is nonetheless not treated as high-risk, for instance because it performs a narrow procedural task or only preparatory work. That exception falls away entirely once the system profiles within the meaning of the GDPR: automated processing to evaluate personal aspects such as performance, reliability, behaviour, health or preferences. In practice most recruitment, credit scoring and fraud detection applications do profile, so the exception many organisations invoke rarely holds.
For each Annex III system, record explicitly whether it profiles within the meaning of Article 4(4) GDPR, with the reasoning and the date. Keep that reasoning with your Article 6(3) assessment; it is the first document a supervisor will ask for.
The activity, not the authority. Work carried out on behalf of a law enforcement authority is covered as well, including where a private party performs it.
Article 3(46) defines law enforcement as activities carried out by law enforcement authorities or on their behalf for the prevention, investigation, detection or prosecution of criminal offences or the execution of criminal penalties, including safeguarding against and preventing threats to public security.
The words "on their behalf" are decisive. A vendor, forensic analysis firm or contracted data specialist working for the police operates inside the law enforcement regime, with the corresponding safeguards and registration duties. Conversely, fraud investigation by an insurer, internal integrity investigations and private security are not law enforcement. Those organisations cannot use the exceptions and fall squarely under the ordinary regime, including the prohibition on real-time remote identification as it applies to them.
For each deployment, record whether it falls inside or outside law enforcement, naming the commissioning authority and the contractual documents. Put that qualification in the contract so vendor and client apply the same regime.
Not just the police and prosecution service. Also any other body entrusted under national law with public authority for detection, prosecution or public security.
Article 3(45) covers (a) any public authority competent for the prevention, investigation, detection or prosecution of criminal offences or the execution of criminal penalties, including safeguarding against and preventing threats to public security, and (b) any other body or entity entrusted by Member State law to exercise public authority and public powers for those same purposes.
Point (b) draws the circle far wider than people expect. Special enforcement officers, specialised investigation services, parts of municipal enforcement and private bodies with a statutory public task can all fall within it. This is not a label without consequences: the status changes the regime. Law enforcement authorities may rely, under strict conditions, on exceptions in Article 5, register their high-risk use in a non-public section of the EU database under Article 49(4), and are subject to their own safeguards in Article 26. An organisation that wrongly treats itself as a law enforcement authority builds its compliance file on the wrong footing.
For each team and each AI system, record the statutory basis on which you enforce and whether that makes you a law enforcement authority. Have that qualification reviewed legally before you rely on any exception.
Use outside the intended purpose that the provider could have seen coming, and must therefore anticipate.
Article 3(13) defines reasonably foreseeable misuse as the use of an AI system in a way that is not in accordance with its intended purpose, but which may result from reasonably foreseeable human behaviour or interaction with other systems, including other AI systems.
The word misuse suggests bad intent, or a user error. That is the wrong reading. It concerns behaviour that is simply predictable: an employee who also uses a summarisation tool for decision-making, a chatbot receiving questions it was not built for, a model fed input by another system through an integration. The second error is the belief that excluding a use in the manual removes the risk. Not being mentioned in the manual is not the same as not being foreseeable. Note also the explicit mention of interaction with other systems, including other AI systems: chained and agentic set-ups fall squarely within it.
Keep a short list per system of foreseeable deviating use, fed by incidents, helpdesk questions and end-user signals, and note for each entry which measure was taken. Include the integrations with other systems explicitly in that list, because that is where use nobody designed emerges.
Risk is the combination of the probability of harm occurring and the severity of that harm. It is the unit of measurement underpinning the entire regulation, from prohibited practices to the Article 9 risk management system.
Article 3(2) defines risk as the combination of the probability of an occurrence of harm and the severity of that harm.
This definition looks trivial but decides who is right in a dispute. Many organisations assess AI risk as the chance of a technical failure, whereas the regulation looks at harm to people's health, safety and fundamental rights. A model that rarely fails but that, when it does, wrongly excludes someone from a job or a benefit scores high in AI Act terms, not low. Without separately substantiating probability and severity, you have an opinion rather than a risk assessment.
For each AI application, record in your register what harm you foresee, to whom, how likely you consider it, how severe the consequence is, and the source of that estimate. Use one fixed scale for probability and severity across all applications so scores are comparable and you can show the classification was not ad hoc.
A change to an AI system after it has been placed on the market or put into service that the provider did not foresee in the initial conformity assessment, and that affects compliance with Chapter III, Section 2 or changes the intended purpose.
Article 3(23) defines substantial modification as a change to an AI system after its placing on the market or putting into service which was not foreseen or planned by the provider in the initial conformity assessment and as a result of which compliance with the requirements set out in Chapter III, Section 2 is affected, or which results in a modification of the intended purpose for which the AI system was assessed.
This definition decides when you must reassess, and it contains an escape route that is often missed: changes the provider foresaw and planned in the conformity assessment are not substantial modifications. A system that keeps learning within predefined boundaries therefore falls outside it in principle, while a model you retrain on a new population or repurpose does not. Note also the link with Article 25: if you change the intended purpose, you as deployer can become the provider. The legal term is substantial modification, not material change.
Keep a change log per AI system with the date, nature of the change, the reason, and the assessment of whether it is a substantial modification, including who determined that. Agree with your provider in advance which changes were already foreseen in the conformity assessment, so you do not have to argue afterwards about whether reassessment was required.
An AI system that assigns people to categories on the basis of their biometric data. The carve-out for functions ancillary to another commercial service is narrow and is routinely read far too broadly in practice.
Article 3(40) defines a biometric categorisation system as an AI system for the purpose of assigning natural persons to specific categories on the basis of their biometric data, unless it is ancillary to another commercial service and strictly necessary for objective technical reasons.
Categorising is not the same as identifying: you are not establishing who someone is, you are attaching a label. That does not make it harmless. Sorting people by sensitive attributes such as race, political opinion, trade union membership, religion or sexual orientation has been prohibited under Article 5 since 2 February 2025, and since 2 August 2026 Article 50(3) requires you to inform the people the system is applied to. The carve-out only applies where the categorisation is strictly necessary on technical grounds for another service, for example an image filter that has to locate facial features. Commercial convenience is not technical necessity.
Record for each system which categories it assigns, which biometric features it uses and for what purpose. If you rely on the carve-out, document the technical necessity in the system description, and build the Article 50(3) information duty into your user-facing notices.
An AI system that identifies people without their active involvement, typically at a distance, by comparing them against a reference database. The decisive words are "active involvement".
Article 3(41) defines a remote biometric identification system as an AI system for the purpose of identifying natural persons, without their active involvement, typically at a distance, through the comparison of a person's biometric data with the biometric data contained in a reference database.
The hinge is whether the person actively participates. An employee placing a finger on a reader or presenting their face to gain entry is actively involved: that is biometric verification within the meaning of point 36, not remote identification. A camera that silently matches passers-by against a database does fall within scope, and such systems are high-risk under Annex III, point 1 in any event, with all attendant obligations from 2 December 2027. Vendors often sell this as "smart access control", while the reference database and the absence of cooperation are what actually decide the classification.
For every camera or biometric system, establish and document two things: is there a reference database behind it, and does the person actively cooperate. Those two answers determine whether you land in Annex III and whether the Article 5 prohibition comes into play.
The set of activities through which a provider keeps following how its AI system behaves in practice after launch, so it can intervene in time. Conformity is a starting point, not an end point.
Article 3(25) defines this as all activities carried out by providers of AI systems to collect and review experience gained from the use of AI systems they place on the market or put into service, for the purpose of identifying any need to immediately apply necessary corrective or preventive actions.
This is where organisations consistently slip: they treat the conformity assessment as the finish line and organise nothing afterwards. The definition instead establishes a continuous obligation covering the entire lifetime of the system, elaborated in Article 72 into a mandatory monitoring plan. It is not about waiting passively for a complaint, but about actively collecting and reviewing. For high-risk systems this bites from 2 December 2027 (Annex III) and 2 August 2028 (Annex I), but the monitoring system must be designed in from the start, since otherwise you have no historical data to demonstrate drift or degradation.
Record per AI system which signals you collect (complaints, support tickets, anomalous outcomes, performance measurements over time), who reviews them, at what frequency, and which threshold triggers a corrective action or a serious incident report. Keep the review records with date and model version, so you can later show that you did not start measuring only after an incident.
A concept that applies exclusively to GPAI models, and that is unrelated to the high-risk classification of AI systems.
Article 3(65) defines systemic risk as a risk specific to the high-impact capabilities of general-purpose AI models, having a significant impact on the Union market due to their reach, or due to actual or reasonably foreseeable negative effects on public health, safety, public security, fundamental rights, or society as a whole, that can be propagated at scale across the value chain. Point 64 defines high-impact capabilities as capabilities that match or exceed the capabilities recorded in the most advanced general-purpose AI models. Article 51(2) provides that a model is presumed to have such capabilities when the cumulative amount of computation used for its training, measured in floating point operations, is greater than 10 to the power of 25.
Systemic risk is often used in conversation as a synonym for high risk, and sometimes, borrowed from the financial sector, as a synonym for systemic importance. Both are wrong. Under this Regulation systemic risk is exclusively a qualification of a general-purpose AI model, never of an AI system and never of an organisation. A second misconception is that the threshold of 10 to the power of 25 floating point operations is the definition. It is not: that threshold sits in Article 51(2) and operates as a presumption, while under Article 51(1)(b) the Commission may also classify a model, on its own initiative or following a qualified alert from the scientific panel, where it has capabilities or an impact equivalent to those in point (a), having regard to the criteria in Annex XIII. For virtually every organisation this concept concerns their supplier rather than themselves; the relevant question is then which model you use and what the provider documents about it.
Record per AI application which underlying GPAI model is used and whether the provider designates that model as one with systemic risk, and keep the documentation or model card on which you base that. Use this information in supplier conversations rather than as your own classification, because the qualification belongs to the model provider.
A measure aimed at returning an AI system to the provider, taking it out of service, or disabling its use, where that system has already been made available to deployers. A recall reaches systems already in use.
Article 3(16) defines recall of an AI system as any measure aiming to achieve the return to the provider, the taking out of service, or the disabling of the use of an AI system made available to deployers.
The difference from withdrawal is the point in the chain. A recall reaches the customer already running the system, while withdrawal only stops what has not yet been delivered. For software a recall is rarely physical: it is a disabled feature, a revoked licence key or a blocked API. Organisations underestimate that a provider may be required under Article 20 to recall a system you depend on operationally, so you need to know today what you will do if a core system is switched off tomorrow.
For each AI system, record who at the provider can announce a recall, through which channel you will receive that notice, and what fallback you have if the system becomes unusable immediately. Put these arrangements in the contract and test at least annually that the notification channel works.
Data for an independent evaluation confirming expected performance, which must take place beforehand: before the system is placed on the market or put into service.
Article 3(32) defines testing data as data used for providing an independent evaluation of the AI system in order to confirm the expected performance of that system before its placing on the market or putting into service.
Two words carry this definition: independent and before. Independent means the testing data must not have been used in training or tuning; the moment you go back and adjust the model based on the test results, your test set is contaminated and you need a new one. Before means the confirmation happens in advance, not as a reconstruction after a supervisor asks. In practice this fails most often with continuously updated systems: every substantial modification calls for a fresh independent confirmation, not a reference to last year's measurement. For high-risk systems this bites from 2 December 2027 (Annex III) and 2 August 2028 (Annex I).
Keep the test set sealed off and separated from the development team, and record the measurement results per relevant subgroup, with date, model version and the metric used. Tie every substantial modification to a fresh testing round and note who performed the evaluation.
Temporarily testing an AI system for its intended purpose outside the lab, in order to gather reliable data and assess conformity. It does not count as placing on the market or putting into service, provided you meet all conditions of Article 57 or 60.
Article 3(57) defines testing in real-world conditions as the temporary testing of an AI system for its intended purpose in real-world conditions outside a laboratory or otherwise simulated environment, with a view to gathering reliable and robust data and to assessing and verifying the conformity of the AI system with the requirements of this Regulation; it does not qualify as placing the AI system on the market or putting it into service within the meaning of this Regulation, provided that all the conditions laid down in Article 57 or 60 are fulfilled.
The exception stands or falls on the word provided. If you do not meet all conditions of Article 57 or 60, your test is no longer a test but a putting into service, with all the obligations that entails and an enforcement exposure you did not see coming. In practice this shows up in pilots that quietly continue, tests that are extended to more users or sites, and systems that simply stay in production after the pilot period. Temporary means temporary.
For each test, record the start and end dates, the intended purpose being tested, the legal basis in Article 57 or 60, and an explicit decision point at the end: stop, extend under the same conditions, or move to putting into service with the full set of obligations.
The agreement between you and the supervisory authority about what you will do in an AI regulatory sandbox: objectives, conditions, timeframe, methodology and requirements. It is a two-sided document, not an internal plan.
Article 3(54) defines a sandbox plan as a document agreed between the participating provider and the competent authority describing the objectives, conditions, timeframe, methodology and requirements for the activities carried out within the sandbox.
The distinction from point 53 is often missed. The real-world testing plan is your own test design; the sandbox plan is a document agreed with the competent authority. That means you cannot change it unilaterally, and departing from the agreed conditions affects your participation in the sandbox. It is also the document with which you can later demonstrate that the supervisor knew what you were doing.
Keep the signed or confirmed sandbox plan under version control and record every change together with the competent authority's agreement. Record in your file which activities fell within the agreed scope and which were kept outside it.
Data used to fit the learnable parameters of an AI system. Narrowly defined, and precisely for that reason decisive for who carries which data governance obligation.
Article 3(29) defines training data as data used for training an AI system through fitting its learnable parameters.
The definition is deliberately technical: it covers only data that actually fit the learnable parameters. Data you pass in a prompt or place in a retrieval index are not training data, and that distinction determines whether Article 10 on data governance applies to you. Where it goes wrong: organisations that fine-tune an existing model with their own data assume they remain mere users, while they are fitting learnable parameters and quickly become a downstream provider with documentation obligations of their own. For general-purpose AI models there is additionally the public summary of training content under Article 53, applicable since 2 August 2025 and enforceable since 2 August 2026.
Record per data set its origin, the basis on which you may use it, the period over which it was collected, which processing steps were applied, and which known limitations or skews it contains. Keep training data administratively separate from validation and testing data, and explicitly log every occasion on which you fine-tune an external model.
A measure aimed at preventing an AI system that is in the supply chain from being made available on the market. It stops distribution, not use by existing customers.
Article 3(17) defines withdrawal of an AI system as any measure aiming to prevent an AI system in the supply chain being made available on the market.
This is the lighter counterpart to a recall and is frequently confused with it, including in contracts. Withdrawal only affects units still in the chain at importers and distributors. Anyone already using the system notices nothing until a recall follows. For your own procurement the practical question is whether a supplier that withdraws its product still delivers updates, patches and support, or whether you are left with a system that is commercially dead but operationally live.
Include in procurement contracts that the provider informs you as soon as it withdraws an AI system, even if you already use it, and record which maintenance and security updates you will still receive afterwards and for how long.
Data with which you evaluate and tune the trained system, including its non-learnable parameters, to prevent underfitting and overfitting. Meant for tuning, not for producing the final score.
Article 3(30) defines validation data as data used for providing an evaluation of the trained AI system and for tuning its non-learnable parameters and its learning process in order, inter alia, to prevent underfitting or overfitting.
The legislator deliberately separated validation from testing, because the classic error is using the same data both for tuning hyperparameters and for reporting final performance. You then measure your own choices back and overstate accuracy, while Article 15 requires a realistic level of accuracy that is stated in the instructions for use. In supervisory conversations this is one of the first things that stands out: an impressive accuracy figure without a separate, untouched test set.
Record which tuning decisions were made on validation data, how many evaluation rounds took place and which configuration was ultimately chosen. Ensure the validation data are never used for the figure you cite in the instructions for use and the technical documentation.
The form validation data may take: a separate data set or part of the training data set, as a fixed or variable split. The law leaves the method open, but not the explainability.
Article 3(31) defines a validation data set as a separate data set or part of the training data set, either as a fixed or variable split.
This definition looks redundant but settles a concrete argument: may you use cross-validation instead of a fixed holdout. The answer is yes, because a variable split is expressly allowed. The flip side is that the burden shifts to reproducibility. If your split changes per run and you do not record the splitting rule, you cannot afterwards show that your reported performance is not the result of a lucky split. For data sets with a time ordering or with heavily represented subgroups, a random split is moreover misleading, while Article 10 specifically demands representativeness.
Record in the technical documentation which split you use, whether it is fixed or variable, which splitting rule or seed applies, and why that split suits the nature of the data. Keep this per model version, so a later retest is reproducible.
One of the two routes into the high-risk classification of Article 6(1), and often overlooked outside manufacturing.
Article 3(14) defines a safety component as a component of a product or of an AI system which fulfils a safety function for that product or AI system, or the failure or malfunctioning of which endangers the health and safety of persons or property.
The definition contains two independent tests joined by an or, and the second is almost always forgotten. A component need not have an identifiable safety function: it is enough that its failure or malfunctioning endangers the health and safety of persons or property. Property counts too, not only injury. The second misconception is that this concept only matters for machinery and medical devices. It is the gateway to Article 6(1), and therefore to the high-risk route via Annex I, which becomes applicable on 2 August 2028 for AI embedded in regulated products. Being a safety component is not sufficient in itself. Article 6(1) sets two cumulative conditions: alongside point (a), point (b) requires that the product, or the AI system as a product, must undergo third-party conformity assessment under the Annex I Union harmonisation legislation.
Run both tests separately for each AI system and record both answers: does it fulfil a safety function, and what happens on failure or malfunctioning. Involve the product safety specialist or the product manufacturer, because that assessment belongs alongside the existing product conformity assessment and not in a separate AI track.
An act or omission contrary to Union law protecting the interests of individuals that harms the collective interests of persons in at least two other Member States, or that, with common features, occurs concurrently and is committed by the same operator in at least three Member States.
Article 3(61) defines a widespread infringement as any act or omission contrary to Union law protecting the interest of individuals which: (a) has harmed or is likely to harm the collective interests of individuals residing in at least two Member States other than the Member State in which (i) the act or omission originated or took place, (ii) the provider concerned or, where applicable, its authorised representative is located or established, or (iii) the deployer is established, where the infringement is committed by the deployer; or (b) has caused, causes or is likely to cause harm to the collective interests of individuals and has common features, including the same unlawful practice or the same interest being infringed, and is occurring concurrently, committed by the same operator, in at least three Member States.
This concept does not determine what is prohibited but how supervision is organised. Once a shortcoming in your AI system plays out the same way in several Member States, it stops being a series of separate national files and becomes one coordinated enforcement track. That is exactly the exposure of standardised software: one setting, one model or one flaw in the logic hits everywhere at once and therefore almost automatically meets the common features criterion. Note that the second limb expressly refers to the same operator, which brings deployers into scope and not only providers.
Map the Member States in which the same AI system or configuration is used and track which incidents and complaints share the same root cause across borders. Ensure that a correction made in one country is demonstrably rolled out in the others as well.
Any mathematical operation or assignment involving floating-point numbers. This is the unit of computation with which the Regulation measures the scale of training of a general-purpose AI model.
Article 3(67) defines a floating-point operation as any mathematical operation or assignment involving floating-point numbers, which are a subset of the real numbers typically represented on computers by an integer of fixed precision scaled by an integer exponent of a fixed base.
A technical definition with legal bite: FLOP is the yardstick for determining whether a general-purpose AI model is presumed to have high-impact capabilities and therefore systemic risk, using the cumulative training compute threshold in Article 51. That turns an engineering number into a compliance fact. In practice the problem is record keeping: many organisations can no longer establish afterwards how much compute went into training, while that very figure determines which regime applies and whether notification to the Commission is required.
For every model you train or significantly further train, record the cumulative amount of compute in FLOP, the measurement method and the hardware used, and keep that record with the model's technical documentation.
Article 49(2) registration record for the system assessed as not high-risk
Proof that the system for which you invoke the Article 6(3) exception is registered as Article 49(2) requires, with the registration number linked to the underlying assessment.
You invoke the Article 6(3) exception for an Annex III system.
Dated Article 6(3) assessment made before market placement
The written assessment with date, author and rationale, drawn up before the system is placed on the market or put into service, ready to be provided to the national competent authority on request.
You are the provider and conclude that an Annex III system is not high-risk via Article 6(3).
Article 6 and Annex III classification record
Traceable rationale covering intended purpose, Annex III category, Article 6(3) assessment and registration decision.
Record per dataset of origin, choices, assumptions, bias examination and mitigations.
Technical documentation kept current per system version, ready for a supervisor’s request.
Log files with a retention period appropriate to the purpose and at least six months for deployers (Articles 19 and 26).
The received instructions for use plus their internal translation into work instructions per role.
Record of oversight measures, appointed persons, their training and the moments of intervention.
Declared accuracy levels, test results, and measures against data poisoning and adversarial attacks among others.
Provider dossier per high-risk AI system
One dossier per system holding the documentation, the logs, the EU declaration of conformity and the registration record, in the version that applied at the moment of placing on the market.
To be maintained per individual high-risk AI system, not per product line or per supplier.
The documented quality system with procedures, role assignment and references to the underlying files.
Versioned record of roles, context, measures, participation or instruction and review moments.
Register of participation and instruction per person, system and date
Internal register showing who received which instruction, working session, training or guidance, for which system, on which date and on what basis, including new joiners, contractors and external staff.
Measures have been carried out under Article 4(1).
Role-system matrix with the established literacy need
The recorded matrix of roles against AI systems, with the context of use, affected persons, risk and selected measure per combination, dated and with an owner per row.
There is no prescribed format and no mandatory AI officer; the form may match the size of the organisation.
A record per system that the Article 5 screening was performed, with outcome and reasoning. The conclusion "no prohibited practice" is evidence too.
Test report per touchpoint: disclosure visible, timely and accessible
Dated record per interface and channel showing that the disclosure appears at the latest at first interaction or exposure, is clear and distinguishable, and passed the accessibility check, with screenshot, version number and tester identity.
One of the duties in Article 50(1) to (4) applies to the system.
Record of scenario, actor, disclosure or marking, technical implementation, test and owner.
Supplier statement on machine-readable marking of output
Written statement from the supplier describing which marking is applied to the output, in which machine-readable format, how robust and interoperable the solution is, and whether the marking survives editing or export.
The system generates synthetic audio, image, video or text content.
The duty does not apply to the extent the AI system performs an assistive function for standard editing or does not substantially alter the input data provided by the deployer or its semantics, or where authorised by law to detect, prevent, investigate or prosecute criminal offences. Under the amended application calendar in Regulation (EU) 2026/1744, systems placed on the market before 2 August 2026 have a transition until 2 December 2026 for this machine-readable marking.
Evaluation results, risk assessments, mitigations, incident reports and security measures per model version.
Written proof of participation and the exit report
On request, the competent authority provides written proof of the activities successfully carried out, plus an exit report with results and learning outcomes. You can use that documentation in conformity assessment and in market surveillance.
Applies where you participate in or exit an AI regulatory sandbox as a provider or prospective provider. The written proof is provided only upon request; the exit report is provided by the authority on its own initiative. If you participate as a deployer in partnership under Article 58(2), point (b), the written proof remains a right of the provider or prospective provider; agree contractually that you receive a copy.
Publication of the exit report through the single information platform only occurs where you and the national competent authority both explicitly agree. Access by the Commission and the Board likewise requires your agreement and remains subject to the confidentiality provisions in Article 78.
Dated and documented informed consent of test subjects
For every test subject you record freely given informed consent, covering five prescribed information elements, dated, documented, with a copy provided to the subject.
Applies to every natural person who is a subject of testing in real world conditions under Article 60, prior to their participation.
Article 60(4), point (i), contains a law enforcement carve-out: where seeking informed consent would prevent the AI system from being tested, testing may proceed without consent, provided that the testing and its outcome have no negative effect on the subjects and that their personal data are deleted after the test is performed. Outside that specific context there is no exception to consent.
The plan as part of the technical documentation plus the periodic analyses and follow-up actions.
Record of incidents, analyses, reports to supervisors and corrective measures.
Versioned record of risk analyses, chosen measures, residual risks and test results per system version.
The assessment, EU declaration of conformity, CE marking and registration proof, per system version.
Deployment dossier: logs, worker information and information to affected persons
The dossier that shows you retain the logs, that you informed workers and their representatives in time, and that the people about whom decisions are made are aware of it.
To be maintained per high-risk AI system. Log retention applies only to the extent the logs are under your control; the information under paragraph 7 applies only where you are an employer and the system is used at the workplace.
Distributor log of checks and corrective actions
A running record of what you checked, when, with what outcome and which action followed, because the supervisor asks about your conduct rather than about the system.
To be maintained per system made available and per customer, for as long as the system is on the market through you and you may still have to take corrective action.
Per request: who made it, about which decision, which system and which version contributed to it, what explanation was given and when. This is also the file that shows you did not silently ignore the right.
Notification to the market surveillance authority with the completed template
The sent notification through which you report the assessment results to the market surveillance authority, with the completed template attached, plus date of dispatch and acknowledgement of receipt.
The assessment under Article 27(1) has been performed.
In the case referred to in Article 46(1), deployers may be exempt from the notification duty; the assessment itself does not fall away.
Crosswalk showing the FRIA complements rather than repeats the DPIA
An overview indicating per Article 27(1) element whether it is already covered in the data protection impact assessment and where, so it is visible which elements exist only in the FRIA.
A data protection impact assessment has been carried out or is required for the same deployment.
Dated impact assessment, measures, residual risks and, where required, notification to the market surveillance authority.
Current technical documentation, downstream information, copyright policy and public training summary.
Model version register listing the changed Annex XI and XII elements per version
A register with one row per model version: release date, distribution method, architecture and parameter count, compute used, and a note of which Annex XI and Annex XII elements changed relative to the previous version.
You place or make available more than one version of the same GPAI model on the Union market.
Public summary of training content following the AI Office template
The published, sufficiently detailed summary of the content used to train the model, drawn up according to the template provided by the AI Office, with publication date and the corresponding model version.
The open-source exemption in Article 53(2) covers only points (a) and (b) of paragraph 1 and therefore leaves the public training summary intact.
Importer dossier with ten-year retention
Your own archive of the notified body certificate, the instructions for use and the EU declaration of conformity, available for ten years and in a language the authority easily understands.
The ten-year term runs from placing on the market or putting into service, and therefore per system and per version, not per supplier relationship.
Record per system of role, contractual arrangements on information and cooperation, and the appointment of a representative where required.
Candidate recommendation that automatically becomes a decision
An employer uses a system that ranks applicants and recommends a candidate to hire. In one setup a recruiter weighs that recommendation in their own assessment; in the other the outcome is applied automatically and a candidate is rejected without anyone looking at it.
The Commission draft guidelines of 19 May 2026 address this case when determining whether an application falls under Annex III. The document is a consultation version: non-binding and not yet final.
Draft guidelines on high-risk AI classification, 19 May 2026, annex on Annex III
Assess a recruitment system on its intended purpose rather than on whether a recruiter reviews the output, because adding or removing human involvement does not change its high-risk classification.
AI articles on EU policy without substantive review
A website automatically publishes AI-generated articles about European policy. There is an editorial charter on paper, but nobody reviews the substance. Before publication only a spell check runs, and a second AI model reviews the text.
The final Commission guidelines on Article 50 treat this case as a worked example under the transparency obligations. The document is non-binding.
Commission Guidelines C(2026) 5054 final, 20.7.2026, worked examples under Article 50
An editorial charter on paper, a spell check and a second AI model do not count as human review, so without substantive fact checking by a person you must label the publication.
AI summary of a council decision under editorial control
A news site places an AI-generated summary beneath a journalist's article about a recent town council decision. The editor in chief reads the summary on substance, checks the facts and signs off for publication.
Do not rely on the editorial exception without substantive review by a competent person and a publicly identifiable holder of editorial responsibility, and note that any AI intervention after sign-off voids it.
AI toy rewards children for dangerous challenges
A manufacturer markets an AI-powered toy that keeps children engaged by encouraging increasingly risky challenges, such as climbing furniture, exploring high shelves or handling sharp objects, in exchange for digital rewards and virtual praise.
The Commission guidelines on prohibited AI practices treat this case as a worked example under Article 5. The document is non-binding: authoritative interpretation rests with the Court of Justice.
Commission Guidelines C(2025) 5052 final, 29.7.2025, worked examples under Article 5
If children are among your users, assess every engagement and reward mechanism separately, because what counts as acceptable stimulation for adults can already be exploitation of children's curiosity and desire for rewards.
Facial recognition at access control: the guard behind the camera counts too
An organisation secures the entrances to its buildings with facial recognition and uses that biometric access control to register visitors as well. When the system returns no match, a security officer reviews the camera images and decides personally whether someone may enter. The question is whose measures have to reach that officer: those of the supplier of the model, those of the department that deploys the system, or both.
Article 4(1) provides that providers and deployers of AI systems shall take measures to support the development of AI literacy of their staff and other persons dealing with the operation and use of AI systems on their behalf. In doing so they must take into account technical knowledge, experience, education and training and the context the AI systems are to be used in, and consider the persons or groups of persons on whom the AI systems are to be used. The same provision states that this obligation does not require providers or deployers to guarantee any specific level of AI literacy of any individual.
We read the phrase about the persons on whom the system is used as the centre of gravity for biometrics: whoever stands in front of the camera is subject to the outcome and has little to set against it. That argues for equipping the officer who decides for himself when no match comes back more substantively than the colleague who merely switches the system on and off. The article itself names no sufficient level and expressly states that you need not guarantee one, so where the floor lies for each role stays open. In our assessment a record kept per role, stating the choice made and the reason for it, is easier to defend than one organisation-wide session backed only by an attendance list.
Police using AI in investigations: context sets how deep the training goes
A police force uses AI to search large volumes of investigation files and surface connections a detective would otherwise miss. The outputs feed into the choice of which suspect is pursued further and end up in documents that enter the criminal process. The question is whether one and the same basic instruction is enough for the analyst operating the model and for the detective who acts on its output.
Article 4(1) requires providers and deployers of AI systems to take measures supporting the development of AI literacy of their staff and other persons dealing with the operation and use of AI systems on their behalf. The provision prescribes that they take into account technical knowledge, experience, education and training and the context the AI systems are to be used in, as well as the persons or groups of persons on whom the AI systems are to be used. It also states that this obligation does not require any specific level of AI literacy of any individual to be guaranteed.
Article 4 requires you to weigh the context of use and the people the system is applied to, and in law enforcement both factors run high on our reading. Whether a general introduction to what AI can do is then enough for someone carrying an output into a file that affects a person's position as a suspect, we doubt, but the provision expressly names no level you must guarantee, so that floor is yours to justify. We would record for each role what someone must be able to recognise, for instance that a discovered connection is not yet evidence, and revisit that choice periodically.
Newsroom with generative AI: do freelancers count within your measures?
A newsroom uses generative AI to prepare summaries, headlines and imagery, after which an editor finishes the piece and the desk decides to publish. Part of that work sits with freelancers, and an outside agency produces marketing content with the same tools. The question is whether your AI literacy measures must reach those freelancers and that agency, or only the people on the payroll.
Article 4(1) is addressed to providers and deployers of AI systems and requires them to take measures supporting the development of AI literacy of their staff and of other persons dealing with the operation and use of AI systems on their behalf. The provision requires them to take into account technical knowledge, experience, education and training and the context the AI systems are to be used in, as well as the persons or groups of persons on whom the AI systems are to be used. It does not require any specific level of AI literacy of any individual to be guaranteed.
Alongside staff, the text expressly names other persons dealing with the operation and use of AI systems on your behalf, and we read that as a functional boundary rather than a contractual one. On that reading a freelance editor using your tool inside your workflow and on your instruction sits within your measures, employment contract or not. The outside agency is a harder case: if it works in your environment and on your instruction, the argument that it acts on your behalf holds up, but if it runs its own tools on its own account it is a deployer in its own right, and Article 4 does not say your measures must cover that work. In practice, in our assessment, that means recording in your agreements who works in which role and what instruction you give, rather than trusting the other side to arrange it.
AI chat in recruitment and selection: what the applicant must be told
A recruiter deploys an AI chat that puts candidates through a first screening conversation after they respond to a job posting, and adds their answers to their CV. The chat introduces itself with a first name and writes in a casual conversational tone. The question is whether these applicants reasonably realise that they are talking to an AI system.
Article 50(1) requires providers to ensure that AI systems intended to interact directly with natural persons are designed and developed in such a way that the natural persons concerned are informed that they are interacting with an AI system, unless this is obvious from the point of view of a natural person who is reasonably well-informed, observant and circumspect, taking into account the circumstances and the context of use. Article 50(5) provides that this information must be given to the natural persons concerned in a clear and distinguishable manner at the latest at the time of the first interaction, and must conform to the applicable accessibility requirements.
We read the obviousness test as a question about the audience the system actually meets, and in recruitment and selection that audience is not a trained professional group but a broad set of applicants under pressure who do not yet know the organisation. A human first name and a casual tone push that assessment the wrong way in our view, however well they convert. If you buy the chat rather than build it, Article 50(1) is by its wording addressed to the provider, while you are the one choosing the persona and the entry point; whether putting your own name on such a chat moves you into the provider role is a question Article 50 does not answer. So make the disclosure in the first message a procurement requirement and verify at delivery that it is genuinely there.
Camera at the entrance: access control versus biometric categorisation
An organisation admits staff through facial recognition at its access control gate and additionally runs a camera in the visitor area that sorts faces into age groups. Both applications run on the same biometric infrastructure and the same images. The question is which of the two requires the people involved to be actively informed.
The Commission guidelines of 20 July 2026 count automated facial-recognition access controls among the systems that merely collect data passively and are not capable of an exchange with natural persons, and therefore do not interact within the meaning of Article 50(1). For Article 50(3) they state that, unless the use is prohibited under Article 5(1)(g), the information duty applies to any biometric categorisation system, including outside the high-risk scope, and they give classification by age or gender on the basis of biometric data as an example. Article 50(3) itself carries a further exception for systems permitted by law to detect, prevent or investigate criminal offences. As a way of informing people the guidelines describe a visible notice at each possible entrance to an exhibition room stating that facial images are captured to assign visitors to an age group, provided at the latest at the moment of first exposure.
Commission Guidelines C(2026) 5054 final, 20.7.2026, point (30) and points (104) to (108)
Our reading is that you should map this per processing purpose rather than per camera: the same lens that stays outside Article 50(1) at the access control gate moves inside Article 50(3) as soon as those images place people in a category. Record for each setup what happens to the capture and who the deployer is, because that decides whether a notice belongs at the entrance. The guidelines prescribe no fixed form, but they do fix the moment: the notice has to be there before someone walks into frame, and a line in the privacy statement rarely makes that moment, in our reading.
Code assistant for developers: an exception, until it faces outward
A software company uses an AI assistant for code suggestions and code review, available only to professional developers. The same company also runs a helpdesk chatbot for customers.
The Commission guidelines of 20 July 2026 list code assistance and code review chatbots available only to professional developers as an example where the obviousness exception applies. Chatbots embedded in online platforms or helpdesks, where users may perceive outputs as human-generated, they list as an example where the disclosure duty does apply.
Commission Guidelines C(2026) 5054 final, 20.7.2026, paragraph (45), lists with and without the obviousness exception
Two AI assistants at the same company, two outcomes. Assess per application who the user is and what they reasonably expect, rather than taking one organisation-wide position on chatbots.
Fraud reporting portal at a bank: why the law enforcement exception drops out
A bank opens an AI-driven reporting portal where customers can flag suspected fraud around their payment account or loan. The system asks follow-up questions, categorises the report and routes it to fraud detection and, where money laundering signals appear, to the internal reporting team. Because the portal concerns criminal offences, the bank assumes the disclosure duty for direct AI interaction does not apply.
The Commission guidelines of 20 July 2026 expressly list AI-assisted fraud reporting hotlines and digital portals operated by financial institutions or public authorities, where users can report suspected financial crimes, as an example that is not exempted and falls within the scope of Article 50(1). They explain that the exception does not apply where the system is available to the public and offers individuals the functionality to report a criminal offence. The fact that the system only gathers details, categorises and prioritises the report while human investigators validate the information before any action is taken does not change that in the guidelines.
Commission Guidelines C(2026) 5054 final, 20.7.2026, points (48) and (49), list of examples under the law enforcement exception
In our reading this is where banks most often take the wrong turn: the reporting portal sits organisationally under fraud and compliance, which makes the law enforcement exception feel natural, while it is precisely the public reporting channel that is carved out of that exception. On top of that, the exception is written for use authorised by law for law enforcement purposes, and the guidelines stretch it no further than to other public authorities holding such a legal basis, so in our reading a private bank rarely stands in it at all, before the public reporting channel even comes up. Treat the portal as an ordinary public-facing chat and put the disclosure in the first screen of the conversation. A line in the terms and conditions or a product leaflet is a weak choice for this channel, because by then the person is already telling their story.
AI text from a municipality: when a final check counts as editorial control
A municipality has an AI system write the web pages about a changed scheme for social assistance and allowances, meant to explain to citizens what they are entitled to. A communications officer reads the text for style and spelling and publishes it. The question is whether this public service thereby falls under the exception to the labelling duty.
The Commission guidelines of 20 July 2026 count public administration and public services among the matters of public interest covered by the disclosure duty for published AI text in Article 50(4). For the exception, the guidelines require two cumulative conditions: the AI-generated or manipulated text has undergone human review or editorial control, and a natural or legal person holds editorial responsibility for the publication. They add that human review means a deliberate examination of the substance with fact-checking as a minimum requirement, and that superficial, purely formal or procedural checks such as spell-checking or grammatical correction do not meet it. For the second condition they expect the identity or the function carrying editorial responsibility to be publicly available in an easily findable place.
Commission Guidelines C(2026) 5054 final, 20.7.2026, point (131), points (133) to (136) and point (138)
Our reading is that many municipalities do have a publication process but no identifiable person carrying substantive final responsibility, and that is exactly the hinge of this exception. Assign that role explicitly, make it findable who holds it, and record per page who checked the facts, or otherwise take the simpler route and label the text. Watch the order of steps in your workflow, because an AI tool that substantively rewrites the text after human sign-off removes the ground from under that sign-off.
Internal assistant for HR and compliance: an exception with a condition
An organisation gives staff an internal AI assistant for HR, legal, procurement, compliance and IT questions. Must that assistant disclose at every turn that it is AI?
The Commission guidelines of 20 July 2026 list an internal employee-facing assistant for properly trained, AI-literate staff who are aware they are using AI systems for internal organisational purposes as an example where the obviousness exception in Article 50(1) applies.
The guidelines tie this exception explicitly to properly trained, AI-literate staff. Relying on it therefore stands or falls with what you have arranged and can demonstrate on literacy under Article 4: without that record you are leaning on an assumption about your own people.
Diagnostic support for clinicians: no disclosure duty, still due care
A hospital deploys an interactive AI system used exclusively by properly trained health professionals to support medical diagnosis and suggest treatments. The question is whether the patient or the clinician must be told it is AI.
The Commission guidelines of 20 July 2026 list interactive AI systems intended only for properly trained health professionals to support medical diagnosis and suggest treatments as an example where the obviousness exception in Article 50(1) applies: for that user the AI nature is clear.
The exception attaches to the user, not to the system. The moment the same model also speaks to patients, that ground falls away and the disclosure duty applies as normal. And an exception to Article 50 says nothing about the rest: where it is a medical device or a high-risk application, those regimes continue to apply in full.
Law enforcement: exempt from the disclosure duty, with safeguards
An authority empowered by law to detect criminal offences wants to deploy an interactive AI system without telling those involved that they are communicating with AI.
Article 50(1) exempts providers of interactive AI systems from the disclosure duty where they are authorised by law to detect, prevent, investigate or prosecute criminal offences, subject to appropriate safeguards for the rights and freedoms of third parties. The Commission guidelines of 20 July 2026 elaborate that exception.
Commission Guidelines C(2026) 5054 final, 20.7.2026, paragraph (46), law-enforcement exception
The exception is narrow and conditional: it requires a legal basis for the law-enforcement task and appropriate safeguards for third parties. A public task by itself is not enough, and the safeguards are not a footnote but part of the ground you are relying on.
An induction call with the customer at the moment of go-live
Asimov AI is a micro organisation of at most fifteen people that supplies AI services for legislative work to government institutions and companies. With every new contract it holds one or more induction calls with the team leads and officials who will use the platform, explaining how the platform and the underlying models work and how hallucinations arise in this domain and can be mitigated.
This practice was submitted by the organisation itself to the Commission living repository. The repository collects and shares practices; it does not approve them or set them as a standard.
Living repository of AI literacy practices, practice submitted by the organisation concerned
This practice puts literacy where the risk arises: with the people who will operate the system, at the moment they start. For a small provider that is also the only workable moment, because there is no training department to redo it later. Anyone adopting it should record who attended and what was explained, because otherwise the effort survives only in the participants memory a year on.
Performance scoring for staff goes wrong: report or not
An employer uses an AI system that scores employee performance and lets that score weigh in promotion and dismissal. After a change to the model it turns out that a group of staff was scored too low for months, and decisions have already been taken on those scores. HR wonders whether this is a serious incident and who would have to report it.
Article 3, point (49) defines a serious incident as an incident or malfunctioning of an AI system that directly or indirectly leads to, among other things, the infringement of obligations under Union law intended to protect fundamental rights. Article 73(1) places the duty to report serious incidents on the provider of the high-risk AI system placed on the Union market, towards the market surveillance authorities of the Member State where the incident occurred. Article 73(2) requires the report to be made immediately after the provider has established a causal link between the AI system and the serious incident, or the reasonable likelihood of such a link, and in any event no later than 15 days after the provider or, where applicable, the deployer becomes aware of the serious incident, with the period taking account of the severity of the incident. Article 73(6) obliges the provider, after reporting, to perform the necessary investigations without delay in relation to the serious incident and the AI system concerned, including a risk assessment and corrective action, cooperating with the competent authorities and, where relevant, with the notified body concerned. Article 26(5) requires a deployer that has identified a serious incident to inform, immediately, first the provider and then the importer or distributor and the relevant market surveillance authorities.
Article 3(49), Article 26(5) and Article 73(1), (2) and (6)
In the workplace the hard part is the awareness trigger in Article 73(2): harm spread thinly across many employees does not arrive as an alarm but trickles in through complaints, a performance review or the works council. Whether systematically low scores that feed into promotion and dismissal amount to a serious incident depends, on our reading, on whether obligations protecting fundamental rights have thereby been infringed within the meaning of Article 3, point (49)(c); Article 73 does not make that assessment for you. Decide in advance which HR signal counts as an incident signal and who puts it in front of the provider that same week, rather than reconstructing that afterwards; Article 26(5) also requires you as deployer, once you have identified a serious incident, to inform the provider immediately and then the importer or distributor and the market surveillance authority. Note finally that the corrective action in Article 73(6) concerns the system; what should happen to promotion or dismissal decisions already taken is, on our reading, not answered by this article and runs through other rules, employment law among them.
Inferring political opinions from uploaded photos
A platform analyses the biometric data in photos users have uploaded to infer their assumed political orientation and serve them targeted political messages. A comparable system infers assumed sexual orientation in order to serve advertisements.
Relying on the ancillary feature exception requires that the feature is also strictly necessary for objective technical reasons alongside the main service, since both conditions apply cumulatively and advertising purposes do not meet that bar.
Face comparison at the border gate: verification or identification
An automated border gate uses biometric facial recognition to compare a traveller’s face with the photo in the passport chip. The same camera could technically also compare against a law-enforcement database, and exactly that difference decides whether this biometrics is high-risk.
The Commission draft guidelines of 19 May 2026 state that biometric verification falls outside the high-risk classification: one-to-one comparison of presented biometrics with previously stored biometrics, for the sole purpose of confirming that a person is who they claim to be. Where the same capture is additionally compared against a law-enforcement database, it does become remote biometric identification. The document is a consultation version: non-binding and not yet final.
Draft guidelines on high-risk AI classification, 19 May 2026, annex on Annex III, paragraph (136)
Test your biometric application on purpose rather than technology: the same camera and the same model stay outside the high-risk route as long as the comparison is one-to-one and only confirms identity, and fall inside it as soon as that same capture is also held against a database. Record per application what the comparison runs against, because that single design choice moves the entire regime.
A three-part training for legal and public affairs staff
Booking.com built a three-part training for its legal and public affairs teams: first basic terminology and the difference between classic machine learning and language models, then how AI works inside the company, then the regulatory landscape and where it meets the law they already practise. The material was also released as a video and podcast series with subtitles and written handouts.
The sequence is the interesting part: first the technology, then the organisation itself, and only then the law. Lawyers who reverse that order memorise the Regulation without being able to judge where their own systems land. That the training exists in several formats also helps to show it was genuinely reachable for everyone who needed it.
A call centre uses webcams and voice recognition to track employees' emotions, such as anger. The same company also uses voice analysis to detect when a customer becomes irritated.
The prohibition follows the relationship of authority rather than the technique: the same voice analysis is prohibited on employees but not on customers, and workplace also covers applicants and probation periods.
An employer has an external recruitment system score and rank every incoming application, after which recruiters only review the top twenty percent by hand. The vendor puts the system on the market under its own name, and the employer uses it in its own selection process.
Recruiters keeping the final say does not help you, because once the system scores or ranks applicants and thereby shapes the shortlist it stays high-risk and no exemption applies.
Database query and standard spreadsheet without AI features
A customer service department runs a database query to find all customers who purchased a specific product last month, and calculates the average from a satisfaction survey in a standard spreadsheet. Every step follows predefined instructions.
The Commission guidelines on the definition of an AI system use this case to draw the line between software that does and does not fall under the regulation. The document is non-binding.
Commission Guidelines C(2025) 5053 final, 29.7.2025, borderline cases under the definition in Article 3(1)
If you rely on the basic data processing category, look at the whole lifecycle rather than the use phase alone, because that category assumes no learning, reasoning or modelling at any stage.
Lawyers learn the technology, developers learn the law
Dedalus Healthcare, which among other things supplies AI that predicts complications for hospital patients, trains its legal staff, data protection officer, compliance function and quality and regulatory affairs department on the technical side. Developers and engineers conversely receive training focused on the legal and compliance aspects of the AI Act. The executive committee received its own session tailored to its role.
Look for knowledge deliberately outside a single discipline, because the repository names collaboration between industry and academia as one of the ways organisations build AI literacy.
Deep fake on a Christmas card: the provider marks, the private person does not
A private individual uses a generative AI service to create a deep fake of themselves and their household for their own Christmas card, purely personal and with no business purpose.
The personal-use exclusion touches only the user duties, so if you supply the generative service you still mark outputs machine-readably, and any professional purpose brings the labelling duty back.
A real car against an AI background is not a deep fake
A car company photographs an existing model and places it in an advertisement against a fully AI-generated background with an invented landscape. The car itself is untouched.
The leeway hangs on the product itself, so an AI background is fine as long as appearance, characteristics and use stay unchanged, but once the editing touches the product, labelling returns.
Medical exception: accessibility yes, burnout detection no
An employer wants to deploy emotion recognition. In one scenario the system assists employees with autism and improves accessibility for blind and deaf colleagues. In the other it measures stress levels to flag burnout, boredom or loss of motivation.
The medical exception is narrow: supporting a specific impairment qualifies, general monitoring of wellbeing, stress or motivation does not, and data gathered under a permitted use may not be reused for other purposes.
Serious incident on the production line: who reports and within what deadline
A manufacturer supplies an AI system that runs as a safety component in a machine on the production line and at the same time drives quality control. At a customer's factory an operator is seriously injured after the machine failed to stop on an anomaly. The question is who reports, to whom, and which clock is already running at that moment.
Article 73(1) places the reporting of serious incidents on the provider of the high-risk AI system placed on the Union market, addressed to the market surveillance authorities of the Member State where the incident occurred. Article 73(2) requires that report to be made immediately after the provider has established a causal link between the AI system and the serious incident, or the reasonable likelihood of such a link, and in any event no later than 15 days after the provider or, where applicable, the deployer becomes aware of the incident, with the reporting period taking account of the severity of the incident. Article 73(4) shortens that to no later than 10 days in the event of the death of a person. Article 73(6) obliges the provider, following the report, to perform the necessary investigations without delay, including a risk assessment and corrective action, and not to perform any investigation involving alteration of the AI system in a way that may affect the subsequent evaluation of the causes of the incident without first informing the competent authorities. Article 26(5) requires a deployer that has identified a serious incident to inform, immediately, first the provider and then the importer or distributor and the relevant market surveillance authorities, and makes Article 73 apply mutatis mutandis where the deployer cannot reach the provider.
We read Article 73(2) as meaning that the clock can already start at the deployer on the factory floor, while the report under Article 73(1) sits with you as the provider of the AI system. That does not leave your customer free to sit still: Article 26(5) gives the deployer a notification route of its own, running past you, the importer or distributor and the market surveillance authority, and makes Article 73 apply mutatis mutandis if you cannot be reached. Fix that route in the contract and in the service line before anything happens. Where an operator is seriously injured but does not die, we read the outer limit of Article 73(2) as the one in play rather than the 10 days of Article 73(4); how much sooner than that outer limit you must report is left open by the text and turns on severity. Bear in mind as well that the reflex to repair the machine immediately and resume production can collide with Article 73(6), because an investigation that alters the system first requires notice to the competent authority. Working that out only during the incident costs days that these deadlines do not allow.
Expert system that draws a conclusion from encoded knowledge
A hospital uses an older diagnostic support expert system in which physicians encoded knowledge, facts and rules. Based on the symptoms a doctor enters, the system independently draws a conclusion about possible conditions.
Machine learning is not a requirement, so you cannot argue that your system merely applies rules encoded by experts; logic and knowledge based systems that draw conclusions on their own are covered too.
A trained AI contact person in every department at a telecom company
Fastweb operates more than ninety AI systems and formally appoints an AI-SPOC in every department, a trained point of contact for AI questions from that team. These people receive separate instruction on prohibited practices and high-risk systems and are allowed to run their department's AI risk assessment themselves.
Do not copy a practice from this repository as is, since the Commission states that replication grants no automatic presumption of compliance; first test whether the setup fits your own systems and roles.
Heavy fine-tuning makes you the model provider
A European scale-up fine-tunes an existing general-purpose AI model for its own product, using more compute than one third of the compute used to train the original model.
The Commission guidelines on the scope of the GPAI obligations address this case when determining when someone becomes a model provider themselves. The document is non-binding.
Commission Guidelines C(2025) 5045 final, 18.7.2025, scope of the obligations for GPAI model providers
Estimate your fine-tuning compute against the original model before you start, because exceeding one third of it makes you the provider, with documentation, copyright and training-content duties limited to your modification.
Screening tax returns for criminal offences on a profile alone
A tax authority runs a predictive AI tool over all tax returns to flag potential criminal tax offences. This is done solely on the profile built by the system, using personality traits such as dual nationality, place of birth and number of children, together with inferred variables that are hard to verify.
To stay outside this prohibition a system must rest on real, verifiable facts directly linked to a specific criminal activity, since simply adding further variables to a profile is not enough.
A tax authority uses an AI system to detect childcare benefit fraud by profiling beneficiaries and assigning them to categories such as deliberate intent or gross negligence, using criteria such as low income, dual nationality and social behaviour. Based on the risk score, files are inspected, benefits are stopped and repayment is demanded.
Fraud detection remains legitimate, but check for each variable whether it genuinely belongs to the purpose and whether the consequence is proportionate, since unrelated personal characteristics plus severe consequences turn a control into social scoring.
Awarding social assistance in a municipality: the FRIA and the notification
A municipality wants to deploy an AI system that sorts applications for social assistance benefits and indicates which files merit extra scrutiny before a case worker decides. The application is already listed in the public algorithm register. The question is what has to be in place before the first citizen passes through this system.
Article 27(1) requires deployers which are bodies governed by public law, or private entities providing public services, to perform an assessment of the impact on fundamental rights that the use of a high-risk AI system referred to in Article 6(2) may produce, prior to deploying it, with the exception of systems intended to be used in the area listed in point 2 of Annex III. That assessment covers, among other elements, the categories of natural persons and groups likely to be affected, the specific risks of harm to those categories, the implementation of human oversight measures, and the measures to be taken if those risks materialise, including the arrangements for internal governance and complaint mechanisms. Article 27(3) provides that once the assessment has been performed, the deployer shall notify the market surveillance authority of its results and submit the filled-out template referred to in paragraph 5 as part of that notification, and that in the case referred to in Article 46(1) deployers may be exempt from that obligation to notify. Article 27(5) provides that the AI Office shall develop a template for a questionnaire, including through an automated tool, to facilitate deployers in complying with their obligations under this Article in a simplified manner.
We read Article 27 as making the municipality the most obvious deployer here, and as requiring the assessment to be complete before the first application runs through the system, not as an account rendered afterwards. That duty does depend first on whether this system is high-risk at all: does it help decide entitlement to social assistance, or does it stay within a preparatory or narrowly procedural task under Article 6(3), which closes its own exception again once the system profiles citizens? Answer that question before you start on paragraph 1. An entry in the public algorithm register is on our reading something different from the assessment under paragraph 1, and it does not replace notifying the market surveillance authority of the results. In practice it pays to record the citizen's complaint route and the case worker's room to depart from the signal in the same file, because paragraph 1 asks for precisely those two elements.
Recidivism scoring in police work: when the assessment must be redone
A police service deploys an AI system that estimates the recidivism risk of a suspect, as an aid to the judgements later made by the prosecution service and the court. The model is subsequently retrained on newer investigative data and use is extended to a second region. The question is whether the assessment made for first use remains adequate.
Article 27(1) requires deployers which are bodies governed by public law to perform, prior to deploying a high-risk AI system referred to in Article 6(2), an assessment of the impact on fundamental rights that its use may produce, with the exception of systems intended to be used in the area listed in point 2 of Annex III. That assessment consists of a description of the processes in which the system will be used, of the period and frequency of use, of the categories of natural persons and groups likely to be affected, of the specific risks of harm taking into account the information given by the provider pursuant to Article 13, of the implementation of human oversight measures according to the instructions for use, and of the measures to be taken if those risks materialise. Article 27(2) provides that the obligation applies to the first use, that previously conducted impact assessments or existing assessments carried out by the provider may be relied on in similar cases, and that a deployer who considers during use that any element listed in paragraph 1 has changed or is no longer up to date shall take the necessary steps to update the information. Article 27(3) provides that the results are notified to the market surveillance authority together with the filled-out template, and that in the case referred to in Article 46(1) an exemption from that notification duty may apply.
We read Article 27 as covering a police service as a body governed by public law under paragraph 1, and as an assessment that does not stop at first use: retraining on newer investigative data or extending use to a second region touches the elements of paragraph 1 and, on our reading, calls for updating the record. That retraining also raises a question Article 27 itself does not answer, namely whether the change goes far enough to count as a substantial modification, which would make you a provider in your own right under Article 25. Bear in mind as well that the exception in paragraph 3 concerns, on our reading, the notification and not the assessment itself. Finally, start that assessment only after establishing that the deployment as such is permitted, because Article 5 rules out certain predictive applications in criminal investigation.
Selection at student admission: a DPIA is not yet a FRIA
A university of applied sciences has an AI system rank applications for a vocational programme, using the exam results of earlier students to calibrate that ranking. A data protection impact assessment already exists for this processing. The question the school asks is whether that also covers the fundamental rights side of admission.
Article 27(1) provides that deployers which are bodies governed by public law, or private entities providing public services, and deployers of high-risk AI systems referred to in points 5(b) and (c) of Annex III, shall perform an assessment of the impact on fundamental rights prior to deploying a high-risk AI system referred to in Article 6(2), with the exception of systems intended to be used in the area listed in point 2 of Annex III. That assessment consists of a description of the deployer's processes in which the system will be used in line with its intended purpose, of the period and frequency of use, of the categories of natural persons and groups likely to be affected, of the specific risks of harm to those categories, of the implementation of human oversight measures, and of the measures to be taken if those risks materialise, including the arrangements for internal governance and complaint mechanisms. Article 27(2) provides that the obligation applies to the first use, that the deployer may in similar cases rely on previously conducted impact assessments or existing assessments carried out by the provider, and that a deployer who considers during use that any element listed in paragraph 1 has changed or is no longer up to date shall take the necessary steps to update the information. Article 27(4) provides that where an obligation under this Article is already met through the data protection impact assessment conducted pursuant to Article 35 of Regulation (EU) 2016/679 or Article 27 of Directive (EU) 2016/680, the assessment under paragraph 1 complements that data protection impact assessment.
We read Article 27 as placing the education institution that runs this selection itself in the deployer role, but that alone does not settle the duty. Paragraph 1 names bodies governed by public law and private entities providing public services, and whether a state-funded or a private university of applied sciences answers to either description is the question you have to settle first. If it does, an existing data protection impact assessment is on our reading the starting point rather than the last word: paragraph 4 has the fundamental rights assessment sit alongside it, and since Regulation (EU) 2026/1744 that assessment may incorporate or cross-refer to relevant parts of it, so the real question is which elements of paragraph 1 are still missing. For you that means recording which groups of students may be affected, how the admissions committee or the teacher can correct an outcome, and where a rejected applicant can lodge a complaint. If the selection rule or the assessment component underpinning the ranking changes, that is on our reading the moment to update the record, rather than the start of the next academic year.
Health insurer using AI for risk assessment: public or private makes no difference
A health insurer uses AI for risk assessment and pricing of health and life insurance. The question is whether this falls under point 5(c) of Annex III, and with that whether the Article 27 FRIA duty comes into play.
The Commission draft guidelines of 19 May 2026 state that the health and life insurance in point 5(c) may be offered on a private or a public basis: a health insurer governed by public law also falls within it, so long as the system is intended for risk assessment or pricing with regard to natural persons. Privately serviced health insurance counts as an essential private service, even in a Member State with a public healthcare system. Unlike point 5(b), point 5(c) provides no exception for fraud detection. The document is a consultation version: non-binding and not yet final.
Draft guidelines on high-risk AI classification, 19 May 2026, annex on Annex III, paragraphs (319) to (321)
For the FRIA question point 5(c) counts twice: it makes the system high-risk and it makes you, as deployer, one of the parties Article 27 names. A public-law form or a public healthcare system in your Member State changes nothing there. Do not count on the fraud-detection exception from point 5(b) either: it does not apply here, and a fraud feature alongside risk assessment does not take the system out.
Weather simulation where machine learning approximates physical processes
A meteorological institute runs physics based weather models and uses machine learning to approximate complex atmospheric processes such as cloud microphysics and turbulence. The estimated values are then fed into the established physics model, which produces the actual forecast.
That your model can infer from input does not by itself bring it within the definition, since the guidelines justify excluding such accelerating systems precisely because they do not transcend basic data processing.
The historical average used as a prediction
An asset manager builds a simple baseline model that predicts future prices by always taking the historical average, in order to test whether a more advanced model genuinely adds value. A weather service does the same by predicting tomorrow's temperature using last week's average.
A simple baseline you place alongside a more advanced model falls outside the definition on its performance, but that verdict says nothing about the advanced model, which you must assess separately.
Three knowledge levels and internal role academies at an insurer
Generali offers all staff basic courses on what AI is and how the group uses it, intermediate modules for people who use AI systems daily, and advanced sessions with external experts for those who build or maintain them. On top of that it runs internal role academies for data scientists, actuaries and accountants, set up with universities and research institutes.
Attach layered AI training to an existing upskilling programme and learning platform, so you can extend levels and audiences without having to build a new learning infrastructure first.
Personalised advertising is not automatically prohibited manipulation
An advertiser uses AI to tailor ads to user preferences. The question is whether that touches the manipulation prohibition.
Personalisation stays outside the prohibition as long as it is transparent and respects free choice, so test your advertising technique against the GDPR, consumer law and the DSA rather than assuming advertising is always allowed.
Facial recognition company builds a database from social media
A software company runs an automated image scraper across the internet to detect images containing human faces on social media, stores them with source URL, geolocation and sometimes names, and converts the facial features into mathematical representations against which an uploaded photo can be matched.
Images published publicly on social media do not amount to consent, and the decisive point is targeting: untargeted collection for a database capable of matching faces stays prohibited even when done step by step.
AI literacy in recruitment and onboarding at an insurer
Gjensidige Forsikring gives all employees a mandatory e-learning as a baseline and builds role-based depth on top: analysts get model risk and data governance, claims handlers get training on the systems they operate themselves. Where relevant, AI literacy is checked during recruitment and training on AI systems is part of onboarding.
Decide whom you train using the wording the document quotes: Article 4 names your own staff as well as anyone using the systems on your behalf.
A webshop helpdesk chatbot must announce itself
A webshop runs an AI chatbot for questions about orders, delivery and returns. The bot writes fluent prose, carries a staff profile picture, and nowhere does it say that no human is reading along.
Do not count on the obviousness exception, because the more human your customer-facing bot looks, the more you must disclose its artificial nature at the first turn rather than only in the terms.
Application file handling at an educational institution
An educational institution uses AI for application file handling: indexing, searching, text and speech processing, translation of documents submitted with applications, and extracting, transforming and organising the collected data into a usable format.
Indexing, searching, translating and reorganising application files remains preparatory work, as long as the system leaves the substantive judgment on the application entirely to the institution.
Agriculture: AI system targeting land areas for chemical spraying
An AI system determines which areas of agricultural land are sprayed with chemicals. The intended purpose given to it by the provider is optimising the use of chemicals.
The Commission draft guidelines of 19 May 2026 address this case when determining whether AI as a safety component falls under the Annex I product legislation. The document is a consultation version: non-binding and not yet final.
Draft guidelines on high-risk AI classification, 19 May 2026, annex on Annex I and product legislation
Do not limit your failure analysis to the product itself but include the environment in which it operates, because people nearby help determine whether a malfunction creates danger.
Agriculture: AI for yield forecasting and irrigation optimisation
An AI system is integrated into a drone or robot and used for agronomic purposes such as yield forecasting or irrigation optimisation.
Record per application why a malfunction in your setup creates no danger, because the same agronomic function can become a safety component in a different product design.
System that checks a human decision or design and provides a substantially different solution
An AI system checks a decision, plan or construction made by a human and then provides a substantially different solution.
Ask whether your system refines or replaces the human work, because delivering a substantially different solution is not an improvement and rules out reliance on Article 6(3)(b).
Money laundering detection by an accounting firm under its own legal duty
An accounting firm deploys an AI system that detects money laundering, in order to comply with its own obligations under EU anti-money laundering legislation.
Check whether you are meeting your own legal duty or taking over a task from a public authority, because only in the second case do you act on its behalf and enter the law enforcement regime.
ATEX: AI system monitoring gas concentrations and commanding shutdown
Equipment for potentially explosive atmospheres contains an AI system intended to monitor gas concentrations and command shutdown when thresholds are exceeded.
Once you offer a system that monitors a dangerous value and itself commands an intervention, the safety function follows from your stated intended purpose, not from how reliably the system performs.
Chatbot answering factual questions from a benefits case handler
A chatbot answers a case handler's factual questions relating to the evaluation of a natural person's application for healthcare benefits, for instance the applicant's age. The case handler can grant or deny the benefits based on those answers.
A chatbot that only returns existing facts in structured form falls under the exemption, but once it answers case-specific legal questions it steers the decision and is high-risk.
Company creditworthiness based on corporate financials
A provider develops a system assessing the creditworthiness of companies by evaluating their company data, balance sheets and financial statements. In a variant, the owner of a legal entity is assessed to back a company loan.
Decide in advance whether natural persons form part of your intended purpose, because a system that also evaluates their personal finances falls within point 5(b) as a whole, regardless of its corporate focus.
Corporate creditworthiness based on balance sheets and financial statements
A provider develops an AI system that assesses the creditworthiness of companies using company data, balance sheets and financial statements. The situation where the owner of a legal entity is assessed as backing for a company loan is also addressed.
An assessment remains corporate as long as the credit accrues to the company, so even an owner backing a company loan does not turn your system into an evaluation of a natural person.
Credit score of a business owner based solely on business data
A provider develops an AI system that establishes the credit score of the owner of a small business or of a company that is not a legal entity. The system uses only business or company data.
Limit your system demonstrably to business data if you want to stay outside point 5(b), because the moment it also draws on the owner personal finances you are evaluating a natural person.
Customs risk assessment of goods at the external border
An AI system is used by customs authorities to assess the risk that goods entering the EU do not comply with legislation applicable at the border, based on information about the economic operators concerned, such as container number, description of goods, routing, transport and payment method.
Determine what your risk model actually targets, because if it concerns consignments and goods flows rather than personal aspects of individuals, there is no profiling to block the exemption.
AI helping candidates tailor their CV to a vacancy
The system analyses the candidate's CV together with the job description supplied by the candidate and recommends changes to increase the likelihood of being selected for an interview. Those recommendations are shared exclusively with the candidate.
Who initiates the tool decides the outcome here, because an aid started by the candidate whose results reach only the candidate falls outside the recruitment use case.
Flagging incomplete forms and returning them to the applicant
An AI system detects and flags incompletely filled-in forms so that they can be returned to the applicant to be completed correctly.
A flagging function that merely notes missing data and returns the form can be treated as a narrow procedural task, as long as it says nothing about the substance or quality of the application.
Gas appliances: AI optimising combustion efficiency
An AI system optimises combustion efficiency in a household gas appliance. The intended purpose is energy efficiency.
Whether an efficiency system is a safety component depends on the product design: if a malfunction can cause fire, explosion or carbon monoxide it counts, if it only raises the energy bill it does not.
Retrospective audit of hiring patterns on anonymised data
A system audits completed hiring decisions by analysing anonymised recruitment data, including CV scores, interview notes and hiring outcomes, using statistical modelling to detect potential bias or inconsistencies. It plays no role in ongoing recruitment and does not assess identified or identifiable recruiters or applicants.
Anonymise the data and keep the analysis entirely retrospective, and you can examine hiring patterns for bias without the system being treated as high-risk.
The system coordinates appointments with applicants by combining calendars and stated availability, proposes time slots based on logistical constraints such as time zones and maximum daily meetings, sends reminders, and processes accessibility needs such as sign language interpretation, extended interview duration or alternative communication formats.
Purely logistical support stays clear of the heavy obligations, provided your scheduling tool initiates or influences no assessment and merely processes accessibility needs in practical terms.
System that surfaces legal provisions and internal guidance for benefits decisions
An AI system is used in assessing data relevant to a decision, for example on public benefits, and provides the human operator with references to the relevant legal provisions, information on jurisdiction and possibly existing internal guidelines relevant to the decision-making process.
General references to legislation and internal guidance remain preparatory, but the moment your system analyses the concrete file or gives a case-specific recommendation you lose that qualification.
Lifts: AI system managing door closing timing and obstacle detection
An AI system in a lift manages door closing timing and obstacle detection. The intended purpose given to it by the provider is efficient lift operation, not safety.
Naming efficiency as the purpose leaves the second route open: if a malfunction could injure someone, the system still qualifies as a safety component, so your stated purpose is not the final answer.
Machinery: vision system detecting humans in a robot cell
An AI-based computer vision system detects human presence in a robot cell and triggers a safe stop or speed reduction. The intended purpose given to it by the provider is to prevent injury.
If your instructions for use, technical documentation or sales materials state that a system exists to prevent injury, you have yourself established that it performs a safety function.
Pattern analysis on completed eligibility checks in the public sector
An AI system analyses previously completed eligibility checks by public administrators to detect decision-making patterns or deviations, for quality assurance and reporting. It does not propose outcomes on live cases and does not evaluate the performance of staff members, for example in the annual appraisal.
Pattern analysis stays within the exemption as long as it runs afterwards, proposes no outcome in live cases and does not evaluate the performance of your own staff.
Pressure equipment: AI system predicting runaway pressure and actuating protection
An AI system in pressure equipment is intended to predict runaway pressure and actuate protective measures, for instance by triggering a shutdown linked to safety accessories.
A model that merely predicts still performs a safety function once that prediction actuates a protective measure, so assess what happens with the output and not only what the model calculates.
Writing assistant refining completed promotion evaluations
A consultancy firm uses an AI writing assistant to refine managers' promotion reports after evaluations are fully completed. Managers have already recorded the recommendation, justification and ratings; the system improves clarity of language, ensures consistency with corporate style and flags potentially biased wording, after which the manager is required to double-check the revised text.
Have the manager fully record the recommendation, justification and ratings first and restrict the system to wording and consistency, and it remains an after-the-fact improvement.
Quality assurance on finalised human work without replacing the judgment
Three kinds of auxiliary systems: systems that flag errors or contradictions in finalised human work as a quality-assurance function, systems that map conclusions to evidentiary records to strengthen the traceability of a decision without substituting human judgment, and systems that convert human-validated content for interoperability or accessibility purposes.
Keep your auxiliary system strictly after the human decision and without a view of its own on the outcome, and it remains an improvement that leaves the rights and position of those affected untouched.
Rail: AI system in a train monitoring speed limits
An AI system in a train is intended to monitor speed limits and to prevent collisions and derailments.
If you work in a sector with its own safety regime, note that only the definition in Article 3(14) of the AI Act counts, not the sectoral notion of safety component.
Deviation detection in recruitment that assesses the recruiters themselves
A system identifies deviations from previous recruitment decision-making patterns before recruitment is completed, to detect inconsistencies with corporate recruitment policy, while evaluating the personal characteristics of the recruiters conducting the interviews.
To keep the exemption, aim the deviation analysis solely at the decisions themselves rather than at the people who made them, and run it only after recruitment has been completed.
AI background checks producing applicant risk scores
The system aggregates official records, employment history, social network history and, where legally permissible, financial data, plus open-source information, and returns composite risk scores or categories such as low, medium and high risk with alerts such as unexplained employment gaps. In high-volume hiring, candidates flagged as high risk are deprioritised before a caseworker reviews the file.
Background checking with composite risk scores is profiling, and that rules out every exemption, even where you have formally built a human review into the process.
Deviation detection in recruitment that also evaluates the recruiters themselves
An AI system is used in the recruitment of employees. It identifies deviations from previous recruitment decision-making patterns to detect potential inconsistencies with corporate recruitment policies, and in doing so also evaluates the personal characteristics of the recruiters conducting the job interviews. The system runs before recruitment is completed.
A system detecting deviations in decision-making can fall under the exemption, but once it also weighs personal characteristics of your own staff there is profiling and that route closes.
Automated school assignment by municipalities
Municipalities or regional authorities automatically assign pupils to public schools based on structured data such as home address, school catchment boundaries and available capacity, also factoring in sibling attendance and parental status to keep families together or minimise commuting distance.
Even an assignment on seemingly objective data such as address and capacity counts as profiling here, so as a public body you cannot rely on the Article 6(3) exemption.
AI scoring and ranking applicant answers
A system evaluates written or oral responses given by job applicants in an online assessment, assigns a numerical score based on linguistic and substantive criteria, and generates a ranking used to determine who is invited to the interview stage.
Once your assessment turns answers into a score that decides who is invited to interview, the system performs a core evaluation and no exemption gets you out.
Smart thermostat optimising comfort and energy use
A smart thermostat covered by the radio equipment rules learns household routines and optimises temperature settings. The intended purpose is greater comfort and lower energy use.
Being a consumer or household product excludes nothing; substantiate that a malfunction leads at most to discomfort or a higher energy bill, and pay particular attention to children and vulnerable users.
Sorting school or university admission applications by level
An AI system sorts incoming applications for admission to a school or university by the grade or educational level applied for, placing them into predefined categories such as primary, secondary or specific grades, based on information supplied in the application.
Sorting on a datum the applicant supplied stays a narrow procedural task, provided your system passes no judgment on suitability and prepares no admission decision.
Toys: AI recommending music in a connected toy
An AI system in a connected toy makes music recommendations to the child playing with it.
Not every AI component inside a regulated product counts; where both a safety purpose and a hazardous failure consequence are absent, the component falls outside the notion of safety component and outside Article 6(1).
Toys: manufacturer opts for internal control based on standards
A toy manufacturer whose product contains an AI system as a safety component applies harmonised standards and thereby opts for a conformity assessment procedure without third-party involvement.
Opting for internal control based on harmonised standards without a third party changes your procedure but not the classification: the system remains high-risk and the accompanying obligations still apply.
An AI system for lane assistance in a vehicle. The intended purpose given to it by the provider is enhancement of the user experience.
On the failure route your own stated purpose carries little weight; support the assessment with system architecture, failure modes and their effects, because that is what will be examined.
Scanning visa files, filing them and marking duplicate attachments
A system in migration and border management scans each submitted visa file, converts scanned documents into text for indexing, automatically files items into fixed, predefined folders such as identity documents, travel itinerary, supporting evidence and translations, and detects exact duplicate attachments and marks them as duplicates.
Even where your file processing qualifies for the exemption, you must document the assessment beforehand and register the system, so the supervisory authority can check your choice at any time.
Scanning, indexing visa files and marking duplicate attachments
An AI system in the migration and border management context scans each submitted visa file, converts scanned documents into text for indexing, automatically files items into fixed predefined folders such as identity documents, travel itinerary, supporting evidence and translations, and detects exact duplicate attachments and marks them as duplicates.
Fix the boundaries of your file processing tightly, because the exemption falls away as soon as the system ranks items, labels them useful or less useful, hides them or suggests a next step.
Awareness that turns into a hard usage rule
INECO, a large Spanish engineering firm working for public authorities on rail, airports and digitalisation, ran over twenty AI trainings with more than four hundred participants in 2024 and set up an AI Master Classroom on the intranet with short modules, audio and subtitles. After making staff aware of data leakage risk, the organisation limited the use of public language models and moved to a secured chatbot solution.
Combine short online modules with real sessions, because the Commission describes the collected initiatives as a mix of e-learning platforms and in person trainings rather than one fixed format.
Internal AI assistant for trained staff needs no notice
An organisation makes an internal AI assistant available for HR, procurement, IT and compliance questions. It sits behind the company login only, and staff have been trained in using AI.
The exception rests on a closed and trained audience, so record who has access and what AI training they received, because once the assistant reaches beyond that circle the exemption falls away.
Credit advertising targeted at low-income postcodes
A financial services provider uses a predictive AI model to target advertising for predatory financial products at people living in low-income postcodes who are in dire financial straits.
Deliberately targeting proxy variables such as postcodes that coincide with a vulnerable socio-economic group counts as exploitation, while unintended bias only becomes exploitation once you know about it and fail to correct it.
Credit scoring and fraud detection at the same bank
A lender uses a model that gives individual applicants a score on which the acceptance decision rests. The same institution also runs a separate model that flags suspicious transactions for fraud investigation.
Assess each model separately against its own intended purpose, since a model scoring a natural person creditworthiness is high-risk while a model whose main intended use is fraud detection falls outside.
Credit scoring and telematics premiums remain permitted
A lender assesses creditworthiness on the basis of income, expenses and other financial and economic circumstances. An insurer raises the premium of a driver whose telematics data show persistent speeding.
Scoring is allowed where you use only data relevant to the purpose and the consequence stays proportionate, and sectoral rules prescribing which data count as relevant provide your strongest justification.
Light fine-tuning does not make you a model provider
A bank fine-tunes an existing general-purpose AI model on its own product documentation and customer questions, using a fraction of the original compute, and builds a customer chatbot around it that it offers under its own name.
If your fine-tuning stays well below one third of the original compute you do not become the model provider, but the obligations for the AI system you offer under your own name still apply.
Place-based predictive policing falls outside the prohibition
A police force uses an AI system that scores the likelihood of crime in different areas of a city, based on past crime rates per area, street maps and supporting information, to decide where to deploy more patrols.
Place-based prediction falls outside the prohibition, but only as long as the area score does not become an element in the profile of an individual, because that turns the assessment person-based.
Logging in admission and assessment: what the institution keeps in its own hands
A university of applied sciences uses a purchased AI system that ranks student admissions and also raises flags during digital assessment. The logs sit in the supplier environment, which hands them over on request. The teaching organisation wonders whether that settles the matter or whether the school retains a duty of its own.
Article 12(1) requires a high-risk AI system to technically allow for the automatic recording of events (logs) over the lifetime of the system, and Article 12(2) ties that recording to a level of traceability appropriate to the intended purpose of the system. Article 26(6) provides that deployers keep the automatically generated logs to the extent those logs are under their control, for a period appropriate to the intended purpose, of at least six months, unless applicable Union or national law provides otherwise, in particular Union law on the protection of personal data. Article 19(1) places a corresponding retention duty on providers for the logs generated by their systems that are under their control, likewise for at least six months.
Article 12(1) and (2), Article 19(1) and Article 26(6)
On our reading, the fact that the supplier hosts the logs does not by itself place the school outside Article 26(6): what matters is whether the logs are under its control. The Regulation does not define that notion, and on our reading server location is not decisive in itself; the question is whether you can actually and contractually dispose of those logs, and it has to be answered for each procurement. So agree at procurement that the institution can request, export and itself retain the logs for the chosen period, and record which admission and assessment events that covers. Take data protection into account at the same time, because the same provision allows other Union or national law to cap the retention period.
Logging on the production line: which logs the manufacturer keeps and which the factory keeps
A manufacturer supplies an AI system that runs as a safety component inside the machinery of a production line and also drives quality control. The factory operating the line keeps only the alerts visible in the local controller; the rest of the recording flows to the supplier environment. The question is who has to keep which logs when it later has to be reconstructed why the line was halted.
Article 12(1) requires high-risk AI systems to technically allow for the automatic recording of events (logs) over the lifetime of the system. Under Article 12(2), those logging capabilities must enable the recording of events relevant for identifying situations that may result in the system presenting a risk within the meaning of Article 79(1) or in a substantial modification, for facilitating the post-market monitoring referred to in Article 72, and for monitoring the operation of the high-risk AI systems referred to in Article 26(5). Article 19(1) obliges providers to keep those automatically generated logs to the extent they are under their control, for a period appropriate to the intended purpose of the system, of at least six months, unless applicable Union or national law provides otherwise. Article 26(6) places a corresponding retention duty on deployers for the logs under their control, with the same six-month floor.
We read Article 19 together with Article 26(6) as leaving the manufacturer, acting here as the provider, and the factory, acting as the deployer, each with a retention duty of its own for the logs under its control. The Regulation does not say when logs count as being under your control, and on our reading the place where the recording physically lands does not settle that by itself; the question has to be answered system by system. For a production line that means recording which events stay in the machinery controller and which travel to the supplier, and securing access to that second set contractually before you need it. Leave that unarranged and you risk being unable to trace a line stoppage or a quality control rejection back to the behaviour of the system.
Logging in task allocation at work: evidence about the system or a file on the employee
An employer deploys an AI system that handles task allocation among staff and summarises their performance for the performance review. HR wants to know what record of those outcomes has to be retained when an employee objects months later to a promotion decision.
Article 12(1) requires high-risk AI systems to technically allow for the automatic recording of events (logs) over the lifetime of the system. Article 12(2)(c) names, as one of the purposes of those logging capabilities, monitoring the operation of the systems referred to in Article 26(5), and that paragraph obliges deployers to monitor operation on the basis of the instructions for use and, where relevant, to inform the provider in accordance with Article 72. Article 26(6) obliges deployers to keep the automatically generated logs to the extent they are under their control, for a period appropriate to the intended purpose, of at least six months, unless applicable Union or national law provides otherwise. Article 19(1) sets out a corresponding retention duty for providers, with the same six-month floor.
Article 12(1) and (2)(c), Article 19(1) and Article 26(5) and (6)
We read Article 12(2) as putting the logging capabilities there first of all to follow risks, substantial modifications and the operation of the system, not to sharpen judgements about individual staff. Whether that statement of purpose also limits what the retained logs may later be used for is something Article 12 does not say: on our reading that limit has to come from data protection law, to which Article 26(6) itself refers. For HR a practical line follows: keep what is needed to trace an outcome and to carry out the monitoring under Article 26(5), and settle in writing beforehand whether those same files may double as a performance record. Bear in mind that the six-month floor can be shorter than the period within which an employee challenges a promotion decision; the Regulation does not govern that evidential position.
Model that stops learning after deployment
An insurer deploys a trained model that ranks claims by complexity. After deployment the model learns nothing new; the supplier retrains only periodically in a controlled release, so its behaviour is entirely stable between releases.
Self learning behaviour after deployment is optional and not a ground for exclusion, so a frozen model that stays entirely stable between releases does not escape the definition on that basis.
Modifying a systemic-risk model pulls the heaviest duties to you
A downstream actor modifies an existing systemic-risk model so substantially that the change exceeds the threshold, and publishes the result as its own model.
Where a modification of a systemic-risk model crosses the threshold, the result is presumed to have high-impact capabilities, so estimate the compute in advance and notify the Commission within two weeks.
A dedicated session on prohibited practices for the development team
In 2024 Mural ran a mandatory AI training for all staff with a 93 percent completion rate, and additionally organised a live interactive session for the AI team specifically on prohibited practices and high-risk categories. For that team the legal function built a visual mind map on a digital whiteboard, with templates and direct references to the provisions.
Two layers side by side: a baseline for everyone and a deeper session for the team that makes the choices. That second layer is where Article 4 earns its keep, because prohibited practices and high-risk categories are design questions rather than awareness questions. The completion rate is not a goal in itself, but it is the kind of figure that later lets you show the measure actually reached the organisation.
In-car navigation: lighter marking is enough
A car manufacturer builds a generative AI system into the navigation unit that composes spoken and written route instructions. The output stays inside the vehicle and technical measures prevent it from being exported or shared.
The lighter marking is conditional, because it holds only while technical measures demonstrably prevent the output from leaving the product, so document those measures before relying on this route.
Eye tracking in online exams versus emotion detection
An education institution uses eye tracking software during online exams to follow students' gaze point and eye movement, to detect whether unauthorised material is being used.
Measuring where someone looks is not emotion recognition, but the moment the same system infers a state such as arousal or anxiety it becomes prohibited, so bound the functionality explicitly.
Open source in name, but not within the meaning of the Regulation
Three providers call their model open source. The first licence allows non-commercial research only. The second requires a separate commercial licence once monthly active users pass a threshold. The third gives the model away for free but hosts it exclusively on its own platform where visitors are served paid advertisements.
A usage restriction is not automatically fatal: you may include specific, proportionate and non-discriminatory safety terms, whereas a monthly active user threshold or a separate commercial licence disqualifies the licence.
What the open-source exemption does and does not cover
A research group publishes a general-purpose AI model under a free and open-source licence and makes the weights, architecture and usage information publicly available. The model carries no systemic risk.
A free and open-source release without systemic risk lifts the technical documentation duties and the authorised representative, but the copyright policy and the public training-content summary continue to apply in full.
Machine learning that only speeds up an existing optimisation calculation
A grid operator uses a machine learning model to approximate parameters inside a classical optimisation calculation built on linear and logistic regression. The model changes nothing about the decision rules themselves, it only makes a long established calculation method faster and cheaper.
If your model only makes a long established calculation method faster and leaves the decision rules untouched, record both points, because they are what carries the conclusion that you fall outside the definition.
Police fine-tuning a model for investigations: settle the role question first
A police service fine-tunes an open general-purpose model on its own files from ongoing criminal investigations, so that detectives can see links between suspects and cases sooner. The fine-tuned model stays inside the service and is not made available to anyone else. The question is whether the service thereby becomes a provider of a general-purpose AI model itself, and so falls under Article 53.
Article 53(1) requires providers of general-purpose AI models to do four things: draw up and keep up-to-date the technical documentation of the model, including its training and testing process and the results of its evaluation, containing at a minimum the information set out in Annex XI so that it can be provided on request to the AI Office and the national competent authorities; draw up, keep up-to-date and make available information and documentation to providers of AI systems who intend to integrate the model, containing at a minimum the elements set out in Annex XII; put in place a policy to comply with Union law on copyright and related rights; and draw up and make publicly available a sufficiently detailed summary about the content used for training, according to a template provided by the AI Office. Article 53(2) provides that the obligations under points (a) and (b) do not apply to providers of models released under a free and open-source licence that allows for the access, usage, modification and distribution of the model, and whose parameters, including the weights, the information on the model architecture and the information on model usage, are made publicly available, and that this exception does not apply to general-purpose AI models with systemic risks.
Start with your role, because merely using someone else's model does not by itself make you a model provider; Article 53 does not say at what point a service that fine-tunes crosses that line, and the point deserves an explicit answer rather than an assumption. A further question comes before Article 53: whether your fine-tuned investigation model has been placed on the market within the meaning of the Regulation. That it never leaves the service does not settle this on its own, since the Commission's guidelines on the scope of the obligations for providers of general-purpose AI models also treat internal use affecting the rights of natural persons as placing on the market. We read paragraph 2 as attaching the open-source exception to your own model rather than carrying it over automatically from the model you started out with: if you do not publish the weights and architecture of the fine-tuned model, which is the obvious course in criminal matters, then on that reading the exception is not open to you, and the duties under points (c) and (d) remain in place in any event, since paragraph 2 lifts only points (a) and (b). So record, version by version, exactly what you changed, on which data and to what end, because that record is what decides whether you stand here as a user or as a provider.
Assessing staff: signals from the workplace flowing back to the provider
A provider supplies a system that summarises employee performance data and supports HR in promotion decisions. After a year in use, departments turn out to apply it differently than intended, and managers factor the outputs into the performance review. The question is what the provider is supposed to know about that.
Article 72(1) requires providers to establish and document a post-market monitoring system in a manner proportionate to the nature of the AI technologies and the risks of the high-risk AI system. Article 72(2) requires that system to actively and systematically collect, document and analyse relevant data, which may be provided by deployers or collected through other sources, on performance throughout the system's lifetime, allowing the provider to evaluate continuous compliance with the requirements set out in Chapter III, Section 2. Article 72(3) provides that the system is based on a plan forming part of the technical documentation referred to in Annex IV, and instructs the Commission to adopt an implementing act laying down detailed provisions establishing a template for that plan and the list of elements to be included in it; the Regulation sets 2 February 2026 as the date for that act.
Our reading is that use which departs from what was intended is exactly the kind of real-world data paragraph 2 has in mind, because it bears on the human oversight and the intended purpose laid down in Section 2. Paragraph 3 points to a Commission template for which the Regulation sets 2 February 2026 as the date; check whether that template has since been adopted and align with it if so, since paragraph 4 refers to it as well. In the meantime we would not put the design of your monitoring on hold for it: which data you need already follows from the requirements the system must continue to meet. Agree with the organisations using the system on the route by which employee complaints and deviations in assessments reach you.
Proctoring during exams: which real-world data the institution reports back
A vendor offers proctoring software that flags possible cheating during exams. Several universities of applied sciences use the system, each with its own assessment formats and its own student populations. The vendor wants to know which real-world data it must keep collecting after roll-out, and from whom.
Article 72(1) requires providers to establish and document a post-market monitoring system, proportionate to the nature of the AI technologies and the risks of the system. Article 72(2) provides that this system actively and systematically collects, documents and analyses relevant data which may be provided by deployers or collected through other sources on the performance of high-risk AI systems throughout their lifetime, and which allow the provider to evaluate the continuous compliance of those systems with the requirements set out in Chapter III, Section 2. Where relevant, monitoring includes an analysis of the interaction with other AI systems. Article 72(3) provides that the system is based on a plan forming part of the technical documentation referred to in Annex IV.
The duty sits with the provider, but the useful signals arise in education itself: unfounded suspicions, student complaints, differences between programmes and assessment formats. Our reading is that paragraph 2 allows deployers to supply that data while leaving the duty to collect and analyse it with the provider. What the article does not settle is the route by which the data reaches you, or whether the institutions are bound to supply it; that is something you have to arrange with them and cannot read out of Article 72. We would therefore fix that route before the system goes live, and would also set out in the plan how you break performance down by assessment format and by group, since an average across all schools hides precisely the pattern you are looking for.
Safety component on the production line: the manufacturer keeps watching after delivery
A manufacturer supplies an AI safety component that halts machinery on a production line as soon as someone comes too close to the robot. The component already falls under product legislation for machinery, and the manufacturer runs quality control and incident follow-up for it. The question is what Article 72 adds on top of that.
Article 72(1) requires providers to establish and document a post-market monitoring system in a manner proportionate to the nature of the AI technologies and the risks of the high-risk AI system. Article 72(3) provides that this system is based on a post-market monitoring plan, and that the plan forms part of the technical documentation referred to in Annex IV. Article 72(4) gives providers of high-risk AI systems covered by the Union harmonisation legislation listed in Section A of Annex I, where a post-market monitoring system and plan are already established under that legislation, the choice of integrating the necessary elements described in paragraphs 1, 2 and 3 into those systems and plans, using the template referred to in paragraph 3, provided this achieves an equivalent level of protection.
Our reading is that Article 72 does not force a second, separate monitoring structure here: paragraph 4 gives you the choice of housing the elements in the system and plan you already run under product legislation, using the template from paragraph 3 and as long as the level of protection remains equivalent. That route stands or falls on a question the article does not answer for you: does the applicable product legislation genuinely have an established post-market monitoring system and plan, or do you run quality control and incident follow-up that were never established as such. Beyond that, you need to be able to show that the signals coming off the factory floor genuinely speak to continued compliance with the high-risk AI requirements, and not only to the mechanical safety of the machine. We would therefore record, for each production signal, which requirement it touches, so that integration does not become dilution.
Proctoring software during an online exam
A university of applied sciences uses software during online exams that flags possible cheating from webcam images and mouse movement. A flag triggers an automatic notification to the exam board.
With proctoring software the timing decides: live monitoring during a graded test falls under point 3(d), while checking submitted work afterwards stays outside that use case.
Proctoring during an exam overshoots: from signal to reporting duty
A university of applied sciences uses proctoring software during an online exam and finds that a group of students is systematically and wrongly flagged as suspicious, after which grades were withdrawn. Teaching staff and the examination board want to know whether this pattern is a serious incident and, if so, who has to report it and within what time.
Article 3, point (49) defines a serious incident as an incident or malfunctioning of an AI system that directly or indirectly leads to, among other things, the infringement of obligations under Union law intended to protect fundamental rights. Article 73(1) obliges the provider of a high-risk AI system placed on the Union market to report serious incidents to the market surveillance authorities of the Member State where the incident occurred. Article 73(2) requires the report to be made immediately after the provider has established the causal link or the reasonable likelihood of such a link, and in any event no later than 15 days after the provider or, where applicable, the deployer becomes aware of the serious incident. Article 73(5) allows an initial, incomplete report followed by a complete report where this is necessary to ensure timely reporting. Article 73(7) provides that upon receiving a report concerning a serious incident as referred to in Article 3, point (49)(c), the market surveillance authority informs the national public authorities or bodies referred to in Article 77(1). Article 26(5) requires a deployer that has identified a serious incident to inform, immediately, first the provider and then the importer or distributor and the relevant market surveillance authorities.
Article 3(49), Article 26(5) and Article 73(1), (2), (5) and (7)
We read Article 73 as meaning that an incident in education is rarely a single dramatic moment: the signal sits in the pattern in exam results, and the institution sees that pattern before the software supplier does. Whether that pattern amounts to a serious incident is a separate question: it turns on whether the wrongful flagging and the withdrawal of grades count as an infringement of obligations protecting fundamental rights within the meaning of Article 3, point (49)(c), and Article 73 does not make that assessment for you. Leaving the question open until your own investigation is finished carries a risk, because the Article 73(2) period runs from awareness. Set up your examination and complaints process so that such a pattern reaches the provider within days; Article 26(5) also puts a notification duty on the institution itself as deployer, towards the provider, the importer or distributor and the market surveillance authority. The initial, incomplete report of Article 73(5) is the pressure valve here; waiting for a finished investigation report is not.
Live facial recognition at a football stadium
Police install a van with mobile cameras and live facial recognition at the main entrance of a stadium during a European Championship match. The watchlist covers people suspected of offences ranging from serious crime to fraud and burglary, plus people of possible intelligence interest and vulnerable persons with mental health issues. There is no information linking a specific person to this event.
A watchlist that mixes different kinds of suspicion and is not tied to the specific event is too unspecific, and the presence of one person for whom deployment would be allowed does not legitimise the whole operation.
Reoffending risk assessment at a police force
A police force uses a model that estimates, per suspect, the likelihood of committing another offence, based on the case file and previously established behaviour. That outcome feeds into the prioritisation of ongoing investigations.
Record which verifiable facts your risk assessment rests on, because an assessment tied to established involvement in a criminal offence is high-risk, whereas one resting solely on profiling is prohibited.
Satellite network allocating bandwidth with a predictive model
A satellite operator allocates power and bandwidth across transponders using a machine learning model that predicts network traffic, because classical optimisation struggles with demand that varies sharply by region and by moment. Performance is comparable to established methods in the field.
Automatic self-adjustment need not bring your system within the definition where it mainly improves computational performance, although the guidelines say only that such systems may be excluded under those conditions.
Satirical deep fake of a politician: lighter, not exempt
A satirical outlet publishes an AI-manipulated image of an existing politician, placed in a scene that humorously criticises a policy decision. Style and context make it immediately clear that this is satire.
Satire only lightens the form of the disclosure and not the duty itself, so make sure the satirical character is evident to your audience and respect the rights of the person depicted.
Chess program using minimax and heuristic evaluation
A software company releases a chess program that assesses board positions using a minimax algorithm with heuristic evaluation functions. The program has never learned from game data; it applies pre-programmed rules and search strategies to find a strong move.
That your system never learned from data does not settle the question, because the guidelines also count logic and knowledge based approaches as AI techniques and do not tie the definition to a chosen technique.
Security monitoring by a SaaS company: cybersecurity alone is not a safety component
A software company supplies a SaaS platform that monitors network traffic at an operator of critical digital infrastructure and reports anomalous patterns to that customer's security team. Its developers see that use at such an operator may fall under point 2 of Annex III and wonder whether their own product therefore becomes a high-risk AI system.
The Commission draft guidelines of 19 May 2026 state that point 2 of Annex III lists AI systems intended to be used as safety components in the management and operation of, among other things, critical digital infrastructure, and that Recital 55 draws a clear distinction between a safety component and a cybersecurity component. To fall within point 2, an AI system must not be used solely for cybersecurity purposes; without a direct safety role it cannot be a safety component in critical infrastructure and therefore cannot be classified as high-risk under Article 6(2). As examples of systems used solely for cybersecurity and thus falling outside point 2, they list an AI honeypot that identifies and neutralises cyber threats in real time, technology that actively engages with potential attackers to learn new attack patterns, a system supporting the detection of unauthorised access, and a system that detects suspicious email addresses and identifies stolen data. They add that an AI system is classified as a safety component in critical infrastructure only where it is used by an entity identified as a critical entity by a Member State under the CER Directive, and that this interpretation does not require that status to be disclosed to a third-party provider. The document is a consultation version: non-binding and not yet final.
Draft guidelines on the classification of high-risk AI systems, 19 May 2026, annex on Annex III, paragraphs (187), (188), (190) and (191)
We read this passage as a line drawn function by function rather than customer by customer: the fact that your client operates critical digital infrastructure does not by itself turn your monitoring product into a safety component. What we cannot settle from the text is where mere flagging ends and a safety function begins, because the same guidelines also count monitoring and detecting situations that may directly lead to physical harm among the safety functions. The open question is therefore whether your SaaS platform stands apart from the systems that drive physical control, or in practice becomes part of them. So record, per product function, what the system performs and what it expressly leaves to the operator, because that distinction carries your entire classification and is hard to reconstruct after the fact.
Role profiles and a kick-off session per AI project at a public sector IT provider
Smals, which supplies IT to Belgian public administrations, describes the knowledge each role needs: all staff know capabilities, limits and internal guidelines, AI ambassadors spot and prioritise use cases, AI experts know governance and technique, and legal staff and the data protection officer get separate deep dives. Before every new AI project there is also a session for all stakeholders on the capabilities, limits, risks and governance of that specific system.
In the repository, first look for practices from organisations that resemble yours in sector, size and role as provider or deployer, before choosing a setup for your own staff.
An organisation adopts an email filter that was trained during its building phase on a set of messages humans labelled as spam or not spam. Once in use, the filter independently assesses new incoming email and classifies it based on the patterns it learned.
A recognisable learning pattern in your system yields no ready made qualification, because the guidelines ask you to assess the specific architecture and functionality against all seven elements of Article 3(1).
Spell checking needs no marking, an AI summary does
A publisher uses the same AI tool for two things: correcting spelling and cleaning up formatting in submitted pieces, and producing summaries and rewrites of those same pieces.
The exception attaches to the function and not to the tool, so assess per use whether meaning, style or structure changes and mark only the outputs where it does.
Static estimation of resolution time and daily sales
A service desk shows customers an expected resolution time calculated as the mean from historical tickets. A retail chain uses a trivial predictor to estimate how many units of a product it will sell each day, as a starting point for purchasing planning.
Keep testing whether your estimate really does no more than return an average, because as soon as you build in more complex relationships you lose the basis for this exception.
A synthetic avatar of your own CEO is a deep fake
A company has a realistic synthetic avatar of its own CEO deliver a new year message thanking employees for last year's results. The video goes to the intranet and to the company's social media channels.
Consent from the executive depicted and a benign purpose are irrelevant because the test is objective, so apply a visible or audible label to the video before it is distributed.
Admission system at a higher education institution: who registers in the EU database
A higher education institution procures an AI system that organises student applications and enrolment and produces an admission recommendation for each candidate in its vocational programmes. The supplier says it handles the conformity assessment itself and affixes the CE marking. What is left unresolved is whether the institution still has a step of its own to take before the system goes into use in its teaching.
Article 43(2) provides that for high-risk AI systems referred to in points 2 to 8 of Annex III, providers follow the conformity assessment procedure based on internal control set out in Annex VI, which does not provide for the involvement of a notified body. Article 47(1) requires the provider to draw up, for each high-risk AI system, a written machine-readable, physical or electronically signed EU declaration of conformity and to keep it at the disposal of the national competent authorities for ten years after the system has been placed on the market or put into service. Article 49(1) requires the provider or, where applicable, the authorised representative to register themselves and their system in the EU database referred to in Article 71 before an Annex III high-risk system is placed on the market or put into service, with the exception of the systems listed in point 2 of Annex III. Article 49(3) provides that deployers that are public authorities or Union institutions, bodies, offices or agencies, or persons acting on their behalf, register themselves, select the system and register its use in that same database before putting such a system into service or using it, again with the exception of the systems listed in point 2 of Annex III.
Article 43(2), Article 47(1) and Article 49(1) and (3)
We read Article 49 as two separate registrations: paragraph 1 covers the provider and its system, paragraph 3 covers your own use, and on that reading the first does not relieve you of the second. The hinge question for the institution is therefore not whether the supplier does its job, but whether it is a public authority within the meaning of paragraph 3. The Regulation does not define that term, and until that is settled it remains open whether the institution must itself appear in the EU database. In practice we would move the request for the EU declaration of conformity and the registration number into the procurement stage, so that the question does not turn into a blocker just before an application period opens.
Emergency triage system: two routes to high risk
A hospital uses AI to prioritise incoming patients at the emergency department. The question is not whether the system is high-risk but by which route: as a medical device under product legislation, or directly under Annex III.
The Commission draft guidelines of 19 May 2026 state that an emergency healthcare patient triage system may qualify as a medical device; where it then meets Article 6(1), it is high-risk via Annex I and sectoral rules apply. A triage system that is not a medical device is high-risk via Article 6(2) and point 5(d) of Annex III. The document is a consultation version: non-binding and not yet final.
Draft guidelines on high-risk AI classification, 19 May 2026, annex on Annex III, paragraphs (334) and (335)
First establish whether your triage system is a medical device, because that question decides the whole route: via Annex I the assessment travels with the medical conformity assessment and its date, via Annex III the separate timeline of Article 6(2) applies. Either way the outcome is high-risk, so postponing that determination only creates uncertainty about which regime to set up.
Two AI systems at one grid operator, two regimes
A grid operator uses an AI model that automatically balances load and disconnects parts of the electricity network to prevent outages. The same organisation also runs a chatbot that helps customers with billing questions.
Map your AI function by function rather than organisation-wide, because only systems that directly protect the physical integrity of the infrastructure are safety components, while supportive and customer-facing tools fall outside.
Sales dashboard that summarises but recommends nothing
A commercial team uses reporting software that applies statistical methods to calculate total sales, average sales per region and trends over time, and displays them in charts. The dashboard makes no suggestion about how to improve sales or which products to promote.
If your dashboard did start making suggestions, that alone would not turn it into an AI system, since the guidelines state that non-AI systems can generate recommendations as well.
Webshop builds its own consumer credit check: what belongs in the file
A non-food retail chain lets customers pay later in its webshop and decides at checkout whether a consumer qualifies. The team builds that assessment system in house, on top of a pre-trained model supplied by a vendor. The question is what has to be on record before the feature goes live, and who has to put it there.
Article 11(1) requires the technical documentation of a high-risk AI system to be drawn up before that system is placed on the market or put into service, and to be kept up to date. It must be drawn up so as to demonstrate compliance with the requirements of that Section and to give national competent authorities and notified bodies the necessary information, in a clear and comprehensive form, to assess that compliance; it contains at a minimum the elements set out in Annex IV. Annex IV lists those elements as applicable to the AI system concerned, and asks among other things for the methods and steps performed for development, including, where relevant, recourse to pre-trained systems or tools provided by third parties and how those were used, integrated or modified by the provider, for the validation and testing procedures used, and for a description of relevant changes made by the provider to the system through its lifecycle. SMEs, including start-ups, may supply those elements in a simplified manner; where they take that route, they must use the simplified form the Commission is to establish for that purpose.
Article 11 puts the documentation duty on the provider, so the first open question here is who that provider is. If the creditworthiness assessment of consumers counts as high-risk in your situation, then in our reading there is a strong case that a webshop assembling the system itself and putting it into service under its own name is no longer merely a deployer but ends up on the provider side, carrying the documentation duty that comes with it. Article 11 does not settle that allocation of roles, so test it against the definitions and against Article 25 before assuming the file is your vendor's problem. In our reading the hard part in retail is not the first version of the file but the pace afterwards, because a webshop often ships changes per release while the file stays frozen at the state it had when the feature went into service. So contract for the provenance, training and testing information that Annex IV expects from you when you buy the pre-trained model, and assign per release who updates the file.
Well-being chatbot pushes users toward dangerous behaviour
A provider markets an AI chatbot meant to help users maintain a healthy lifestyle, with tailored advice on exercise and mental rest. In practice the chatbot exploits individual vulnerabilities and pushes people into dangerous habits, such as excessive sport without rest or water.
Good intentions offer no protection: once a system can foreseeably push users toward serious harm and no preventive or mitigating measures were taken, the prohibition applies even without intent.
No mandatory course format, no certificate, no exam and no AI officer
Article 4 prescribes no form. The Commission confirms that no certificate is required, no obligation to measure knowledge exists, no training is mandatory and no governance structure is prescribed.
Applies to providers and deployers of AI systems, who take measures to support AI literacy among their staff and other persons dealing with the operation and use of AI systems on their behalf.
For deployers of high-risk AI systems, a separate obligation under Article 26 will apply in addition, requiring them to ensure that staff working with the system are sufficiently trained to handle it and ensure human oversight. That duty goes beyond Article 4, but it does not apply yet: it becomes applicable on 2 December 2027 for standalone high-risk systems under Annex III and on 2 August 2028 for high-risk systems embedded in products under Annex I.
The Commission Q&A on AI literacy states that there is no one size fits all when it comes to AI literacy and that no strict requirements or mandatory trainings are imposed. On certification, the Q&A states literally that there is no need for a certificate and that organisations can keep an internal record of trainings or other guiding initiatives. On assessment, it states that Article 4 of the AI Act does not entail an obligation to measure the AI knowledge of employees. On governance, it states that no specific governance structure is mandated to comply with Article 4, so that unlike the data protection officer under the GDPR, no AI officer needs to be appointed. On the level, the Q&A states that following the Digital Omnibus amendment AI literacy remains an obligation for providers and deployers of AI systems, but that no specific or sufficient level is mandated and that the Regulation does not require guaranteeing any specific level of AI literacy of any individual. Against that, the Q&A states that simply relying on the AI systems' instructions for use or asking staff to read them might be ineffective, and that organisations should take into account general AI understanding within the organisation, whether they are a provider or a deployer, the risks associated with the systems deployed, staff knowledge gaps considering technical knowledge, experience, education and training, and contextual factors such as sector, purpose and affected populations. The Q&A further states that organisations may implement different levels of training or learning approaches depending on knowledge, experience, education and role, and that staff with a degree or experience in AI development are normally considered AI literate, while the organisation must still verify that those persons understand the specific AI systems of the organisation, know how to deal with them and are aware of all risks.
Commission Q&A on AI literacy, sections on required level, training formats, certificates, assessment of knowledge and governance structures (consulted 9 August 2026)
This guidance cuts both ways and both are abused. The supply side of the market sells certificates and exams as a legal requirement: that is demonstrably wrong, because the Commission states literally that no certificate is needed and that there is no obligation to measure knowledge. The other side is the organisation that concludes from the same answer that nothing is required. That is equally wrong. In the same Q&A the Commission says that merely forwarding the instructions for use might be ineffective, and it expects a reasoned choice based on your role, your risks and your people's knowledge gaps. The correct reading is therefore: no prescribed format, but a demonstrable measure. That makes the internal record named in the Q&A the practical heart of your file. And note the nuance about technical staff: a data scientist is not automatically done, because the organisation must still verify that this person knows its own systems and the associated risks.
Stop steering on certificates and steer on a demonstrable, reasoned measure. Record what you did, for which groups, why that format fits their role and the risks of the systems they use, and keep a simple internal record as the Q&A suggests. Differentiate by role rather than giving everyone the same module, and include your technical staff with a specific component on your own systems and risks. Replace the mere forwarding of instructions for use with something that is demonstrably read and understood.
Article 4 reaches beyond your own staff, and the national supervisor enforces it
The duty to take measures also covers contractors, service providers and sometimes clients. Supervision lies not with the AI Office but with national market surveillance authorities, enforcing since 2 August 2026.
Applies regardless of place of establishment, as long as the AI system is placed on the Union market, used in the Union, or its use has an impact on people located in the Union.
The Commission Q&A on AI literacy states that Article 4 applies to providers and deployers of AI systems and in addition to other persons dealing with the operation and use of AI systems on their behalf, covering persons broadly within the organisational remit, with a contractor, a service provider and a client given as examples. On clients, the Q&A states that they may need AI literacy depending on the specific risk, reasoning that affected persons should understand how decisions taken with the assistance of AI will have an impact on them. On geographic scope, the Q&A states that the AI Act's legal framework applies to both public and private actors inside and outside the EU as long as the AI system is placed on the Union market, used in the Union, or its use has an impact on people located in the EU. On supervision, the Q&A states that the supervision and enforcement of Article 4 is not with the AI Office but under the remit of national market surveillance authorities, and that supervision and enforcement began on 2 August 2026, while Article 4 itself entered into application on 2 February 2025. On sanctions, the Q&A states that national market surveillance authorities could impose penalties and other enforcement measures for infringements of Article 4, that this will be based on national laws that Member States were due to adopt by 2 August 2025, that any sanction must be proportionate and based on the individual case taking into account factors such as the nature and gravity of the infringement and its intentional or negligent character, and that sanctions are more likely if there is proof of an incident due to a lack of appropriate training and guidance. Article 4 is not listed in the enumeration in Article 99(4) of the AI Act, which covers only Articles 16, 22, 23, 24, 26, 31, 33(1), (3) and (4), 34 and 50, so the level of any penalty for Article 4 follows from national law rather than from the Regulation's own ceilings. The Q&A further states that Article 4 reinforces the transparency provisions of Article 13 and the human oversight provisions of Article 14 and indirectly contributes to the protection of affected persons, and that for deployers of high-risk systems the Article 26 obligation to ensure staff are trained to ensure human oversight is a distinct requirement; that requirement becomes applicable on 2 December 2027 for standalone Annex III systems and on 2 August 2028 for Annex I systems.
Commission Q&A on AI literacy, sections on target groups, geographic scope, supervision and enforcement, and sanctions (consulted 9 August 2026)
Two things are consistently underestimated here. The first is the circle of people. Many organisations translate Article 4 into a staff programme and forget the seconded workers, the call centre, the implementation agency and the freelancers who use the same systems daily. The Q&A expressly widens that circle to everyone within the organisational remit, and even leaves the door open to clients where the risk calls for it. The second is who will come knocking. Because the AI Office gets all the attention, organisations assume Article 4 is a Brussels file. It is not: this runs through the national market surveillance authority. The most useful sentence for your own prioritisation is that a sanction is more likely where there is proof of an incident caused by a lack of appropriate training and guidance. Enforcement will therefore rarely start with a spot check on your training plan, and far more often with an incident after which the question becomes whether the person involved was prepared. That makes the file reactively useful, and therefore worth having in order now.
Extend your target list from permanent staff to everyone working with your AI systems under your direction, including contingent workers, contractors and implementation partners, and write that expectation into your procurement and hiring terms. Assess per system whether clients or affected persons also need an explanation of how AI-assisted decisions affect them. Structure your records so that after an incident you can show within a day which measures the person involved had received and when. Finally, establish which national market surveillance authority is competent for you, because that is your counterpart, not the AI Office.
AI agents must disclose both their AI nature and on whose behalf they act
An AI agent that makes bookings, handles correspondence or concludes contracts must identify itself as AI and state on whose behalf it is acting, including towards the person instructing it.
Applies as soon as the agent is capable of interacting with the person instructing it or with other natural persons in the execution of the task.
Purely machine-to-machine communication between agents whose outputs are not intended to reach a natural person falls outside the disclosure duty of Article 50(1), and intermediate reasoning steps and non-perceptible actions fall outside the marking duty of Article 50(2).
Point (31) of the guidelines of 20 July 2026 states that AI agents are covered by Article 50(1) if they are capable of interacting with the persons instructing them or with other natural persons in the execution of their tasks, citing as examples making bookings, managing correspondence, negotiating or concluding contracts and executing purchases. That same point requires AI agents to be designed and developed so that they disclose both their artificial nature and the person on whose behalf they are acting, given the need for transparency of the origin and of the delegation of authority and accountability for the consequences of their actions. This also applies in complex multi-agent architectures in which other agents interact directly with natural persons. Where the provider cannot reliably determine before placing on the market or putting into service whether the agent will directly interact with a natural person, the agent should be designed at the architecture level and instructed to disclose itself in every situation where it is reasonably likely to interact with a natural person, including where that person represents a legal entity. Agents should also disclose themselves to the persons instructing them at key steps such as authorisation, reporting and validation, including where the agent receives, processes or relies upon outputs generated by other AI systems rather than by a natural person, and at every new interaction. Point (63) adds that Article 50(2) may apply to AI agents where the agent takes an action whose output is AI-generated or manipulated content perceptible by natural persons, while intermediate processing steps such as reasoning and chain of thought and non-perceptible actions such as a web request or browser action fall outside that scope.
Commission Guidelines C(2026) 5054 final, Section 3.1.1 point (31) and Section 4.1.2 point (63)
Here the guidelines go further than most organisations expect. The obligation is twofold: not only 'I am AI', but also 'I act on behalf of this party'. That turns agentic email, procurement and negotiation into a design question rather than a line in a footer. Two things are systematically missed. First, the disclosure duty also runs towards your own instructing party, at key steps such as authorisation and validation, and particularly where the agent builds on outputs from other AI systems rather than on human input. Second, the provider's uncertainty resolves nothing: if the provider cannot determine in advance whether the agent will reach a human, the answer is not 'then it does not apply' but 'then you build the disclosure into the architecture by default'. An agent that stays quiet until it is certain a human is reading is not what is intended.
Treat your agent's disclosure as an architecture requirement, not a prompt instruction that can be overridden per task. Ensure every outbound channel of the agent, meaning email, chat, telephony and forms, carries both the AI origin and the instructing organisation by default. Also build confirmation moments towards your own user at authorisation, reporting and validation, and flag explicitly there when the agent is building on output from another AI system. Finally, mark the perceptible content the agent produces in line with Article 50(2), but not the internal reasoning steps.
Artistic or satirical work is not exempt but attenuated, and the informative character always prevails
For deep fakes in evidently artistic, creative, satirical or fictional work, the disclosure must not hamper the work, but it remains mandatory. Where the content mixes in an informative or commercial character, the standard label applies.
The deep fake must evidently form part of an artistic, creative, satirical, fictional or analogous work or programme, assessed case by case by the deployer.
Where content combines multiple characters, the informative character always prevails and the standard labelling requirements apply; content that is exclusively informative or commercial and recognisable as such, such as news reporting, falls outside the lighter regime.
Point (119) of the guidelines of 20 July 2026 describes an attenuated transparency obligation for deep fakes forming part of evidently artistic, creative, satirical, fictional or analogous works or programmes, where the obligation is limited to disclosure in an appropriate manner that does not hamper the display or enjoyment of the work. Point (120) describes the categories: artistic works are created for the purpose of art, including music, cinematographic works and visual arts; creative works involve creative choices, while works mainly motivated by functional or technical considerations cannot be regarded as creative; satirical works are intended to criticise society, politics, business or public figures through humoristic techniques; fictional works involve persons, objects, places, entities or events in an imaginary but verisimilitude setting; analogous works share core traits with those categories without fitting neatly into one. Point (122) states that it must be evident to the natural persons exposed to it that the content falls within one of those categories, that the categories must therefore be interpreted strictly given the lighter disclosure regime and the interests of freedom of expression and freedom of the arts and sciences, and that content whose nature is potentially unclear or ambiguous to the audience falls outside this lighter regime. Relevant factors, per that same point, are whether the content displays formats or styles characteristic of the category, the context in which it is presented, and audience expectations. That same point excludes content whose nature is exclusively informative or commercial and recognisable as such, citing news reporting, notes that advertisements or documentaries may be regarded as evidently creative or fictional in certain specific situations but not in others because the assessment is case-specific, and states that where the deep fake combines multiple characters, for example informative and creative, the informative character should always prevail and the standard labelling requirements apply. Point (123) stresses that these deep fakes are not excluded from the obligation: the deployer must still disclose the AI origin or manipulation, but may do so in an appropriate manner, and must in any case comply with Article 50(5). Point (124) states that reliance on the attenuated obligation cannot justify failing to respect the fundamental rights of individuals or the rights of rightsholders under Union intellectual property or data protection law. As examples within the categories the document cites movies featuring AI de-aged existing actors or digital replicas of deceased actors, AI-generated music in the style of existing artists, and an AI-manipulated image of an existing politician in a scene clearly meant as humorous criticism. Outside the categories the document places among others an AI-manipulated video in the style of a teleshopping channel, AI-generated images of celebrities implying involvement in activities that never happened, and an AI-manipulated video featuring a realistic synthetic influencer focused solely on displaying a sponsored product's functionalities.
Commission Guidelines C(2026) 5054 final, Section 6.1.3, points (119) to (124) and the accompanying example lists
Two misconceptions dominate here. The first is that 'creative work' is an exemption. It is not: you must still disclose, only in a way that does not ruin the work, for example in the credits, in an accompanying notice, or at the start of the video rather than as a permanent block across the image. The second misconception is more serious and hits marketing directly. Advertising is not automatically creative work. The guidelines cite teleshopping-style videos and synthetic influencers demonstrating a product precisely as examples falling outside the category, and further state that where characters mix, the informative one always prevails. So anyone making a funny, clearly stylised campaign that also carries a product claim falls back on the standard label. Finally, note the evidence requirement: if the audience could doubt whether it is seeing satire or real news, it is by definition not evident and the lighter regime does not apply.
Assess per production whether the work is unmistakably artistic, satirical or fictional for your audience, and briefly record that assessment against the three factors in point (122): stylistic features, publication context and audience expectation. For campaigns and commercial video, default to the standard label and rely on the lighter regime only in rare cases. For evidently creative work, choose a disclosure that leaves the work intact, for example at the start or in the credits, bearing in mind that the information must be clear and distinguishable and that people joining later must also be able to perceive it.
Signing the code of practice is voluntary, but not signing means proving it yourself
Signing the code of practice on transparency of AI-generated content is voluntary and not signing is not in itself non-compliance. Those who do not sign must demonstrate compliance by other means, including a gap analysis against the code.
Applies to providers and deployers of generative AI systems within the scope of Article 50(2) and (4).
The Commission Q&A on signing the Code of Practice on Transparency of AI-generated Content states that signing is voluntary and that not signing does not constitute non-compliance with the AI Act. That same Q&A states that the code has two sections, one for providers on marking AI-generated or manipulated content in machine-readable formats and the related detection mechanisms, and one for deployers on the disclosure and labelling of deep fakes and of certain AI-generated or manipulated text on matters of public interest. It further states that signatories may, subject to a positive assessment by the Commission and the AI Board, rely on the code to demonstrate compliance with their obligations under Article 50 regardless of their place of establishment, and that the deadline for inclusion in the initial list of signatories was 27 July 2026 at 18:00 CEST, with later signature remaining possible but not appearing on that initial list. The Commission guidelines of 20 July 2026 state in point (146) that providers and deployers within the scope of Article 50(2) and (4) may demonstrate compliance by adhering to a code of practice assessed as adequate under Article 50(7), and that such a code does not replace the Regulation or the guidelines but complements them as the only Union-wide recognised practical framework for that purpose. Point (147) states that compliance may also be demonstrated through other adequate means, that for signatories supervisory activities will focus on whether they have adhered to the code and implemented the measures it contains, and that opting out of sections results in losing the benefit of facilitated demonstration of compliance for that part. Point (148) states that non-signatories are expected to demonstrate through other adequate means how they comply with Article 50(2), (4) and (5) and to explain how their measures ensure compliance, for instance by carrying out a gap analysis comparing their measures with those set out in a code assessed as adequate, and that they will likely face more requests for information and for access. Point (149) states that competent authorities may take commitments implemented in line with a code assessed as adequate into account as a mitigating factor when setting the amount of fines. Point (150) states that if a code is not deemed adequate, the Commission may adopt an implementing act specifying common rules for the implementation of Article 50(2), (4) and (5).
Commission Guidelines C(2026) 5054 final, Section 8.1, points (146) to (150); Commission Q&A on signing the Code of Practice on Transparency of AI-generated Content (consulted 9 August 2026)
The voluntariness is real, but it is not free. The guidelines shift the burden of proof: signatories are assessed on whether they do what the code says, non-signatories must explain why their own approach suffices. That difference translates into work. Point (148) expects non-signatories to run a gap analysis against the code, which means you have to read the code and benchmark your measures against it either way. Not signing therefore saves you the signature, not the substance. On the other side, point (149) explicitly names adherence in line with the code as a mitigating factor for fines, which makes the code commercially interesting for parties producing large volumes of generated content. Finally, note the opt-out rule: partial signature is possible, but for the sections you skip you fall back into the heavier evidential position. For anyone who missed the initial list, signature remains open; only the listing on that first list has passed.
Decide deliberately whether to sign and record the reasoning. If you do not sign, still carry out the gap analysis named in point (148) and keep it as the core of your file, together with a description of how your own measures cover Article 50(2), (4) and (5). Account for the fact that as a non-signatory you may receive more information and access requests, and structure your documentation accordingly. If you sign but opt out of sections, treat those sections as a non-signatory would and document them separately.
The deployer cannot rely on the provider's machine-readable marking
Whoever publishes a deepfake must apply a label perceivable by humans. The watermark or metadata supplied by the provider does not discharge that duty.
Applies to deployers of AI systems that generate or manipulate deep fakes in the form of image, audio or video content.
An attenuated form of disclosure applies to deep fakes forming part of evidently artistic, creative, satirical, fictional or analogous works, and an exception applies to use authorised by law to detect, prevent, investigate or prosecute criminal offences.
Point (117) of the guidelines of 20 July 2026 states that deployers of AI systems generating or manipulating deep fake content must clearly and distinguishably disclose that the content has been artificially created or manipulated, by labelling the output accordingly and disclosing its artificial origin. According to that same point, the labelling or disclosure methods used must be understandable and perceivable by natural persons, for example with visible or audible labels, without those persons needing to rely on any specific technical tools or performing dedicated actions. The point closes expressly by stating that deployers cannot rely on the machine-readable marking embedded in the content by the provider under Article 50(2), since those markings are not immediately clear and distinguishable for the natural persons exposed to the deep fake content. Point (12) adds that deployers involved in complex content production and distribution value chains must take proportionate measures to ensure that the labelling they have implemented under Article 50(4) is actually displayed in a clear and distinguishable manner to the targeted and foreseeable audience at the point of first exposure, for example via contractual conditions with distributing partners and via user experience settings and interfaces. Point (14) states that a legal person remains the deployer even where it involves third parties such as contractors or freelancers in the operation of the system on its behalf and under its authority, and that individual employees acting under its instructions and control are not considered separate deployers.
Commission Guidelines C(2026) 5054 final, 20.7.2026, Section 6.1.2 point (117) and Section 2.3 points (12) and (14)
This is the sharpest role confusion in the whole transparency chain. Provider and deployer carry two different duties aimed at two different audiences: the provider marks machine-readably for systems and supervisors, the deployer labels perceptibly for humans. The common error is that a marketing department or agency assumes the generated image is 'already marked' by the tool and that nothing further is needed at publication. That is wrong. Equally important is how the duty travels down the chain: it does not end with applying the label, but with whether the audience actually sees the label at first exposure. If your label disappears because a platform re-encodes, crops or auto-plays the video without the opening title, the label formally exists but functionally does not. That is why the guidelines expressly name contractual arrangements with distribution partners as a means. And note the last sentence of point (14): you do not pass the deployer role on to the agency or freelancer producing the content for you.
Add a separate step to your publication process in which a label visible or audible to humans is applied to deep fake content, independent of whatever the generation tool writes into the files. Verify per distribution channel that the label is still visible at first contact after uploading, re-encoding and auto-play. Write the labelling requirement into your terms with agencies, production partners and distribution platforms, and do not assume that engaging an external agency moves the deployer role.
Disclosure at the latest at first interaction, and again for every new person
The notice that a person is dealing with an AI system must be given at the latest at the time of the first interaction. That moment applies per natural person, not once per system.
Applies to providers of AI systems intended to interact directly with natural persons, and through the horizontal requirements of Article 50(5) to all notices under Article 50(1) to (4).
The information obligation falls away if the interaction is obvious to a reasonably well-informed, observant and circumspect person, or if the system is authorised by law to detect, prevent, investigate or prosecute criminal offences, unless the system is available to the public to report a criminal offence.
The final Commission guidelines of 20 July 2026 (C(2026) 5054 final) state in point (33) that the notification mechanism must be embedded in the design of the system and that the notice must be provided during operation of the system and at the latest at the time of the first interaction with the natural person, as required by Article 50(5). Point (143) clarifies that 'first interaction or exposure' refers not only to the first person who encounters the system, but also to any subsequent first interaction with or exposure to the system by any other natural person. For an interactive system, the information must be provided at least once at the start of an interactive session. For content under Article 50(2) and (4), the information obligation applies to each output with respect to any natural person exposed to it. Point (40) adds that a single prominent notification before the first interaction is likely to suffice in most instances, but that in riskier contexts periodic reminders and context-aware disclosures are likely to be necessary, in particular for vulnerable persons, sustained or immersive interactions, financial, insurance, legal or health advice and complaints handling, and AI companions. That same point requires the system to be designed so that it always discloses where it is asked about its nature or the origin of the interaction, or where it can reasonably be assumed from the exchange that the person is likely to be misled or confused about the AI origin.
Commission Guidelines C(2026) 5054 final, 20.7.2026, Section 3.1.2 points (33) and (40), and Section 7.2 point (143)
The trap is the word 'first'. Many organisations read it as a one-off announcement when the chatbot launches, or as a line in a welcome email that every visitor is assumed to have seen. The guidelines read it as an obligation that arises anew for each natural person who encounters the system or its output for the first time. A second common error is assuming that a notice at the start of the session covers the whole customer journey. If the role of the system changes mid-session, or the interaction is long and concerns money, health or law, the Commission expects repetition. The third trap is letting the system dodge the question when a user directly asks whether they are speaking to a human. That is not permitted: the question must always be answered honestly, whatever notice was given earlier.
Document for each customer contact channel at what moment the notice appears, and test it with a fresh session from a new device so you see what a first-time visitor sees rather than what a logged-in employee sees. Also build a hard rule into the system prompt or conversation logic that forces the system to confirm its AI origin as soon as it is asked or as soon as the user addresses it as a human. Finally, decide for your higher-risk channels, such as financial advice, claims handling, care and complaints, whether a single opening notice suffices or whether you need a persistent label or periodic reminders, and record that assessment in writing.
The editorial exception: substantive review plus an identifiable responsible person
No label is needed where the AI text has been substantively reviewed by a human and someone holds editorial responsibility. A spellcheck or a written editorial policy is not enough, and any AI intervention after sign-off voids the exception.
Both conditions must be met together: substantive human review or editorial control, and an identifiable natural or legal person holding editorial responsibility for the publication.
Point (133) of the guidelines of 20 July 2026 sets two cumulative conditions: the AI-generated or manipulated text must have undergone human review or editorial control, and a natural or legal person must hold editorial responsibility for the publication. Point (134) describes human review as the deliberate examination of the substance of the content by one or more natural persons possessing relevant knowledge and professional judgement on the subject matter, citing academic peer review and professional validation chains as examples, and states that fact-checking the accuracy of the content is a minimum requirement that must form part of that review. Editorial control is described in that same point as the control exercised in practice by a responsible editorial entity, for example an editor-in-chief, with the authority to approve, alter or reject the substance of the text on substantive grounds, including fact-checking and ensuring the trustworthiness of sources. Point (135) states that superficial, solely formal or procedural checks such as spell-checking or grammatical correction, the mere existence of an editorial policy, automated review processes, and cursory editorial approval without substantive engagement by the human reviewer or the editorial entity cannot fulfil the conditions. Point (136) states that where AI systems are used to modify, supplement or reformulate content following editorial sign-off, the resulting content must be treated as AI-generated or manipulated, and that any substantive AI intervention occurring after the human review or editorial control will cause the exception to become void. Point (138) states that the person holding editorial responsibility must hold the ultimate responsibility over the publication, including the human review or editorial control, and that the identity and contact details of that legal person, natural person or function should be made publicly available in an easily findable location, online for example through a website's terms and conditions or other user-facing legal information, offline for example in a colophon. As examples meeting the conditions the document cites among others an AI-manipulated newspaper article or AI-generated summary subject to the editorial control of the editor-in-chief, an AI-manipulated academic blog that has undergone internal peer review, AI-generated public safety warnings approved by a public official, and AI-generated sustainability reports reviewed by professionals in relevant functions. As examples failing the conditions the document cites a website where AI-generated articles on Union policy are posted without any deliberate human review, and AI-generated articles reviewed and edited by another AI system where a human editor performs a mere superficial grammatical check before publication.
Commission Guidelines C(2026) 5054 final, Section 6.2.3, points (133) to (138) and the accompanying example lists
This exception is why most newsrooms and communications departments do not have to label, but it is narrower than it looks. Three pitfalls. First, sequence: many organisations have the text approved and then let an AI tool 'polish it a bit' for SEO, length or tone. Point (136) states literally that any substantive AI intervention after sign-off voids the exception. The AI step must therefore come before the human review, not after it. Second, depth: it must be deliberate examination of the substance with fact-checking as a minimum. An editor who only reads for flow does not qualify, and an AI reviewing another AI certainly does not. Third, visibility: it must be publicly findable who holds editorial responsibility. A colophon or a clear statement in the site's legal information is not a formality but a condition of the exception. Notably, the guidelines expressly place this exception outside the media as well, citing sustainability reports and government warnings. Your compliance or communications function can therefore act as the reviewer, provided the review is genuinely substantive.
Always place your AI step before human approval in the workflow, and technically block any AI edit running after sign-off, including automatic SEO optimisation or shortening. Record per publication stream who performs the substantive review, that fact-checking forms part of it, and who holds editorial responsibility. Publish that responsible function or person with contact details in an easily findable location, for example in the colophon or with the site's legal information. Keep a short record per publication of who reviewed the substance and when, so you can substantiate reliance on the exception.
What does not suffice on its own as an AI disclosure
A line in the terms and conditions, a hidden metadata mark or a vague word like 'assistant' will not do. The guidelines name five methods that are insufficient when used alone.
Applies to every disclosure under Article 50, because Article 50(5) requires information to be provided in a clear and distinguishable manner and to conform to applicable accessibility requirements.
Point (38) of the guidelines of 20 July 2026 lists techniques that are not necessary and that, when used alone, are insufficient to satisfy Article 50(1) and (5). These are: disclosures contained only in terms and conditions, URLs or documentation, with the document adding that such disclosures may complement but not replace in-context disclosure; machine-readable markings such as metadata or watermarks that are not perceivable by users at the point of interaction, which does not affect their appropriateness for Article 50(2); unclear or ambiguous signals, with the document expressly naming a generic reference to 'assistant', and human-like representations that may mislead users; generalised disclosures that are not sufficiently specific to the system's outputs and interactions, with the document citing as inadequate a statement on a platform offering a variety of services that 'Services on this website use AI'; and technical or capability-based descriptions referring solely to the underlying technology, such as 'this system uses LLMs', without explaining the function or the implications for the user and the artificial origin. Point (142) adds that information is not clear and distinguishable where it can be easily overlooked or missed under normal exposure or interaction conditions, for example where it is included only in a manual, hidden under layers of menu options in an online interface, or part of terms of use that users often do not read.
Commission Guidelines C(2026) 5054 final, Section 3.1.2 point (38) and Section 7.1 point (142)
This is the list that topples most existing implementations. Three patterns occur structurally and all three fail. First, the legal cover: a line in the terms and conditions or privacy statement saying the organisation uses AI. Second, the technical cover: the argument that the output carries a C2PA mark or watermark and that the user is therefore informed. The guidelines keep those two tracks strictly separate, because a machine-readable mark counts for Article 50(2) but not as a disclosure to the human. Third, the brand-driven cover: giving the chatbot a friendly name and calling it 'your digital assistant'. That precise formulation is named as an example of an ambiguous signal. The popular generic site-wide banner stating that the site uses AI is likewise explicitly labelled insufficient, because it is not specific enough to the actual output.
Inventory where your current AI disclosure sits. If it lives only in the terms and conditions, the privacy statement, a cookie banner or a help page, it does not comply and must move into the interaction itself, close to the input and output field. Replace phrasings such as 'digital assistant' or 'virtual colleague' with an explicit statement that this is an AI system. Keep the machine-readable marking in place for Article 50(2), but do not count it towards the disclosure to the user.
Existing systems and legacy content: what does and does not apply retroactively
Only the machine-readable marking under Article 50(2) has a transitional period for systems already on the market. Legacy content need not be labelled retroactively, but legacy text you publish now must be.
The transitional period to 2 December 2026 applies only to the marking and detection obligation of Article 50(2) and only to generative systems placed on the market or put into service before 2 August 2026.
Content generated or manipulated before 2 August 2026, and text on matters of public interest generated and published before that date, need not be marked or labelled retroactively.
Point (153) of the guidelines of 20 July 2026 states that under Article 113, Article 50 applies from 2 August 2026 and that all in-scope AI systems placed on the market or put into service in the Union must comply on that date, regardless of their date of placing on the market or putting into service. That same point describes that the regulation amending the AI Act provides a targeted transitional rule concerning only the marking and detection obligations under Article 50(2) for generative AI systems placed on the market or put into service before 2 August 2026, giving providers of those existing systems a transitional period to bring them into conformity by 2 December 2026. Point (153) states expressly that systems that are partly interactive and partly generative may benefit from that transitional period only with regard to the marking obligation under Article 50(2), while compliance with the disclosure obligation for AI systems directly interacting with natural persons must be ensured as of 2 August 2026. Point (154) states that AI-generated or manipulated outputs within the scope of Article 50(2) and deep fakes within the scope of Article 50(4), first subparagraph, generated or manipulated before 2 August 2026 do not need to be marked or labelled retroactively, and that the same applies to texts on matters of public interest that were AI-generated or manipulated and published before that date. That same point states conversely that texts generated or manipulated before 2 August 2026 but published on or after that date must be labelled. Point (154) adds that deployers and other actors in possession of or disseminating pre-existing unlabelled deep fakes are nonetheless encouraged to label them, without being expected to engage in disproportionate efforts such as auditing pre-existing content databases or modifying already printed product packaging. A footnote to point (153) clarifies that the special grandfathering rule of Article 111(2) for high-risk AI systems does not extend to Article 50, because the high-risk obligations and the transparency obligations apply cumulatively.
Commission Guidelines C(2026) 5054 final, Section 8.4, points (153) and (154)
Two things get conflated here. The first is the assumption that the transitional period to 2 December 2026 is a general postponement of Article 50. It is not: it covers only the machine-readable marking and detection of Article 50(2). If your system also runs a chat interface, the disclosure to the user had to be in place on 2 August 2026, even though marking of the output may wait until December. The second is the assumption that legacy content is safe. That holds for already published content, but not for your stock. If you had a batch of AI texts produced last year and are only publishing them now, the labelling duty does apply. The same goes for a campaign visual that has been sitting on the shelf for months. Practically, the distinction is not old versus new, but the moment of publication. The encouragement to label pre-existing deep fakes is not a duty, but it is where a supervisor can look at the reasonableness of your choices.
Split your inventory into three: systems interacting directly with people, which have had to disclose since 2 August 2026; generative systems relying on the transitional period to 2 December 2026 for machine-readable marking; and systems doing both, which therefore carry a different date per obligation. Also walk through your content stock: anything still to be published that was AI-generated or substantially edited gets a label at publication, regardless of when it was generated. Record why you are not retroactively labelling already published legacy content, so you can explain that choice.
When is AI obvious? The exception applies only where almost no doubt remains
The exception for obvious AI interaction must be interpreted restrictively. It applies only where almost no doubt remains for an average member of the intended and reasonably foreseeable audience.
Assessment per system and per context of use, to be carried out and documented by the provider.
This exception does not release you from the information obligations under EU consumer protection law: the guidelines state that those obligations apply irrespective of whether the interaction is considered obvious under Article 50(1).
The Commission guidelines of 20 July 2026 place on the provider, in point (42), the burden of assessing and demonstrating the obvious artificial nature of the interaction to a person who is reasonably well-informed, observant and circumspect, taking into account the circumstances and the context of use. Point (43) anchors that standard in the notion of the 'average consumer' in EU consumer protection law. Point (44) prescribes a two-step assessment: first the provider considers the audience with whom the system is intended and reasonably likely to interact, then how well-informed, observant and circumspect an average member of that audience is. That same point states that the exposed audience does not always equal the target audience, that expected levels are lower where persons with disabilities, elderly people or minors are likely to be part of the audience, and that levels may be higher for an exclusively professional or specialised audience. Point (45) states that the exception should be interpreted restrictively because it deprives natural persons of the right to clear and distinguishable disclosure, that general awareness that AI systems exist does not imply that people recognise them in interactions, and that the exception should be limited to cases where there is almost no doubt left about the nature of the interaction. As examples where the exception does apply, the document lists among others code assistance chatbots available only to professional developers, an internal employee-facing assistant for properly trained and AI-literate staff, systems used only by properly trained health professionals, ambient AI embedded in home appliances, and non-playable characters in a single-player video game. As examples where the exception does not apply, the document lists a robotic companion pet closely resembling its natural equivalent, AI in immersive environments using realistic avatars or voices, and chatbots on online platforms or helpdesks whose outputs users may perceive as human-generated.
Commission Guidelines C(2026) 5054 final, Section 3.2.1, points (42) to (45) and the accompanying example lists
This is the most frequently over-claimed exception. The reasoning 'everyone knows this is a chatbot' is explicitly rejected by the guidelines: general awareness that AI exists is not the same as recognition in the actual conversation. What matters is not what your average customer knows, but who could reasonably end up at your system. As soon as your system is publicly accessible, the broader audience of elderly people, children and people with lower digital literacy is by definition included, and the exception falls away. The mirror image matters just as much and is often missed: for a strictly internal assistant used by trained staff, the Commission does expressly recognise the exception. Note the condition embedded in that example, namely that the staff are actually trained and AI-literate. That ties this exception directly to your Article 4 measures: without demonstrably AI-literate staff, the foundation for relying on the exception falls away.
Rely on this exception only for systems with a closed, professional user base, and record the two-step assessment in writing: who is the target audience, who else could reach it, and why almost no doubt remains for an average member of that audience. For anything publicly accessible, assume you must disclose. Link any internal reliance on the exception to your Article 4 file, so you can show that the staff concerned were genuinely prepared for the use of that system.
Standard editing versus semantic change under the marking obligation
Spellchecking, formatting and minor image corrections fall outside the marking obligation. An AI summary, rewrite or face replacement falls inside it.
Applies to providers of AI systems generating or manipulating synthetic audio, image, video or text content, in the context of the machine-readable marking and detection obligation of Article 50(2).
Alongside standard editing and non-substantial alteration, a third exception applies to generative systems authorised by law to generate or manipulate synthetic content to detect, prevent, investigate or prosecute criminal offences.
Point (90) of the guidelines of 20 July 2026 describes standard editing as the process of preparing existing content for publication or distribution, such as small edits to improve readability, grammar, quality and format, without generating new content. According to that same point, editing goes beyond standard editing where the content is changed in a material way through substantive or structural modifications that affect its meaning, style or intent. Point (91) addresses the second exception, for systems that do not substantially alter the input data provided by the deployer or the semantics thereof, and states that an alteration is substantial where the input data or its semantics have been manipulated significantly during output generation, to be assessed against factors including format, media content type, style and changes affecting meaning, style or intent. Point (92) provides that where a system can be used both for generation or manipulation and for minor non-substantial alterations, the obligation does not apply to the content altered in a minor non-substantial manner. As examples falling under the exception the document lists among others grammar correction and spellchecking, minor stylistic polishing that does not change substance or messaging, AI-generated translations, formatting and format conversion, noise reduction, minor cropping and colour corrections, removal of dust spots and red-eye, blurring of faces, rescaling of video clips and transcriptions of conversations. As examples of semantic changes that do require marking the document lists among others AI-generated summaries of text, paraphrasing or rewriting that changes style, structure and meaning, removal, replacement or insertion of objects or persons, face replacement, synthesis of realistic speech in a specific person's voice and the creation of composite images.
Commission Guidelines C(2026) 5054 final, Section 4.3, points (90) to (92) and the accompanying example lists
The dividing line is meaning, not effort and not whether a human was involved. That produces two outcomes that surprise many organisations. The first: an AI-generated summary sits explicitly on the marking side. Summarising feels like editing, but the guidelines classify it as semantic change. Anyone auto-generating summaries of articles, reports or case files is therefore inside the marking obligation. The second, mirror-image: an AI-generated translation sits on the exempt side, as does transcription. That is the opposite of what many editorial teams assume. Finally, note point (92): the question is not what your tool can do, but what actually happened to the content in the specific case. The same tool can fall outside the obligation in one use and inside it in another.
Sort your AI applications into two buckets: editing without semantic change, and producing or changing meaning. Put summarising, rewriting, image editing where persons or objects disappear or appear, and voice cloning explicitly into the second bucket, and spellchecking, formatting, translation and transcription into the first. Record the classification per application with a short justification, because the guidelines require a case-by-case assessment rather than a per-tool one.
Which AI text needs a label: published, informing the public, on a matter of public interest
The labelling duty for AI text applies only where three elements coincide: the text is published, is intended to inform the public, and concerns a matter of public interest.
The three elements are cumulative: only where the text is published, seeks to inform the public and concerns a matter of public interest does the disclosure duty arise.
The duty falls away where the AI-generated or manipulated text has undergone human review or editorial control and a natural or legal person holds editorial responsibility for the publication, and where use is authorised by law to detect, prevent, investigate or prosecute criminal offences.
Point (131) of the guidelines of 20 July 2026 splits the scope of Article 50(4), second subparagraph, into three elements. Published text means the text is accessible by an indeterminate, fairly large number of unrelated potential readers simultaneously or successively, whether or not against payment such as a subscription. Text is not considered published where access is restricted to specific individuals within a closed, private group, for example a small closed group on an instant messaging app or a group that is too small or insignificant; the document cites as examples of unpublished text private interpersonal correspondence for professional purposes and organisation-internal texts or communications such as publications on internal corporate networks. Informing the public means the text intends to communicate knowledge, opinions or facts; short texts that do not materially communicate knowledge, opinions or facts cannot be deemed to inform the public. Matters of public interest are, according to that same point, generally those relevant to society at large, at local, national, Union or international level, and meriting public debate or scrutiny; the document includes texts on politics and democratic processes, public administration and services, the administration of justice and law enforcement, the protection of fundamental rights, public security, public health, environmental protection, consumer safety, and any economic, financial, political, scientific or cultural development that may be a relevant subject of public debate, noting that what counts as public interest can evolve over time and across contexts. As examples within scope the document cites an AI-generated summary of a human-authored article on a newspaper's website discussing a recent town council decision, AI-manipulated parts of a lifestyle-website article comparing the effects of various diets on a particular disease, AI-manipulated corporate reports containing investor information published on a listed company's website, and an AI-generated message on a meteorological institute's social media profile warning citizens about stormy weather and precautionary measures. Outside scope the document places among others AI-generated fantasy novels, AI-manipulated text that is part of a company's advertisement or product descriptions without claims relating to for example health, consumer safety or sustainability, a news summary generated by a chatbot that is only available to the user who prompted it, and AI-manipulated text by a consultant advising a client on measures for regulatory compliance.
Commission Guidelines C(2026) 5054 final, Section 6.2.1 point (131) and the accompanying example lists
The reflex is to read this as a media rule that only concerns newsrooms. The examples show otherwise. A listed company with AI-edited investor information on its own website is inside. A meteorological institute posting a storm warning on social media is inside. A lifestyle site with health claims is inside. What binds those cases is not that they are journalism, but that a broad audience draws information from them about something that affects society. The second nuance sits on the other side: an advertisement or product description falls outside, but only as long as it carries no claims about health, consumer safety or sustainability. Sustainability claims in commercial copy therefore move into scope. The third nuance is the split between internal and published: your intranet and your one-to-one correspondence fall outside, even where the content is socially relevant. And note: the presence of the AI-generated summary of a human-authored article in the example list means the automatic summary feature under a news article can by itself trigger the labelling duty.
Walk through your publication channels and flag where AI generates or substantially edits text: news items, knowledge articles, annual reports and investor information, public information and citizen warnings, and sustainability or health claims. Assess per channel whether the text is published in the sense of the guidelines, meaning accessible to an indeterminate and fairly large audience. Treat automatic summary features on articles as a separate, standalone assessment rather than as part of the underlying article.
When a downstream party that fine-tunes becomes a GPAI provider itself
Not every modification makes you a provider. The indicative threshold is a modification using more than a third of the original model's training compute, and your obligations are then limited to the modification.
Applies to downstream actors distinct from the original provider and not acting on its behalf, who modify or fine-tune a general-purpose AI model, with or without integrating it into an AI system.
If you become the provider of the modified model, obligations remain limited to the modification itself: the technical documentation covers the change, and the copyright policy and training-content summary cover only the data used in the modification.
The Commission guidelines of 18 July 2025 (C(2025) 5045 final) on the scope of the obligations for providers of general-purpose AI models state in point (61) that it is not necessary for every modification of such a model to lead to the downstream modifier being considered the provider of the modified model, in line with the Blue Guide, which states that a product subject to important changes or overhauls aiming to modify its original performance, purpose or type may be considered a new product. Point (62) states that the Commission considers a downstream modifier to become the provider of the modified model only if the modification leads to a significant change in the model's generality, capabilities or systemic risk. Point (63) sets the indicative criterion: a downstream modifier is considered to be the provider where the training compute used for the modification is greater than a third of the training compute of the original model. Point (64) states that where the downstream modifier cannot be expected to know that value, for example because it has not been communicated by the provider of the original model, and cannot estimate it, the threshold is replaced by a third of 10 to the power of 25 FLOP where the original model is a model with systemic risk, and otherwise by a third of 10 to the power of 23 FLOP. Point (65) explains that a modification of that size is expected to display a significant change justifying the transparency obligations of Article 53(1)(a) and (b), that such a modification can be expected to have used a significant amount of data relevant to the copyright policy and the public summary of training content under Article 53(1)(c) and (d), and that where the original model has systemic risk the modified model can be expected to present significantly different systemic risk. Point (67) notes that currently few modifications meet this criterion, that the number of downstream modifiers becoming providers may increase over time, and that the criterion is thus primarily forward-looking. Point (68) states that in the case of a modification the obligations are limited to that modification: the documentation under Article 53(1)(a) and (b) is limited to information on the modification, and the copyright policy under point (c) and the summary of training content under point (d) are limited to the data used as part of the modification. Point (69) states that a downstream modifier who becomes a provider must also comply with Article 54, which means appointing an authorised representative established in the Union to the extent that the modifier is itself established outside the Union. Point (70) states that where a downstream actor modifies a model classified as having systemic risk in such a way that they become the provider of the modified model, the resulting model is presumed to have high-impact capabilities and is therefore considered a model with systemic risk, and point (71) states that the modifier must then comply with the obligations for providers of models with systemic risk and notify the Commission in line with Article 52(1).
Commission Guidelines C(2025) 5045 final, 18.7.2025, Section 3.2 points (60) to (67) and Sections 3.2.1 and 3.2.2, points (68) to (71)
The practical message is more reassuring than most organisations expect, with one catch. Ordinary fine-tuning on your own documents, RAG, prompt engineering or a LoRA adapter comes nowhere near a third of the training compute of a large base model. The Commission itself says that few modifications currently meet the criterion. Anyone adapting a model for their own use therefore generally does not become a GPAI provider. The catch sits in point (64): if you do not know the original model's training compute and cannot estimate it, you fall back on an absolute threshold of a third of 10 to the power of 23 FLOP. That is a considerably lower bar than a third of a large model, and with closed models whose compute is not published, that is exactly the scenario you are in. The second trap is the systemic-risk chain: if you modify a model already designated as having systemic risk and thereby become a provider, you inherit that label and the duty to notify the Commission. On the positive side, obligations in that case remain limited to your own modification: you do not have to reproduce the original model's documentation or training-content summary.
Record per modified model which base model you use, which modification method you apply and how much compute that modification consumed, so you can test the criterion rather than speculate about it. Ask the base model's provider for the training compute and document the answer, because if you cannot know that value you fall back on the considerably lower absolute threshold. Also check whether the base model is designated as having systemic risk, because that changes both the threshold and the consequences of crossing it. Reassess this judgement at every substantial retraining, since the Commission itself indicates that the number of downstream modifiers becoming providers is expected to grow.
Annex I contains no list of high-risk products but an exhaustive list of harmonisation legislation. The AI Act does not extend the scope of that product legislation and does not change a product's risk profile.
The draft guidelines of 19 May 2026, published for consultation and expressly non-binding, clarify that Annex I AI Act does not list individual products to be classified as high-risk, but Union harmonisation legislation regulating the safety aspects of certain products. Whether an AI system falls within the scope of Annex I therefore depends on whether the system, or the product of which it is a safety component, falls within the material scope of one of the listed legislative acts. According to the draft guidelines the list in Annex I is exhaustive; products can only be added or removed by amending the scope of the harmonisation legislation itself or by adding new harmonisation legislation to Annex I. The draft guidelines also state that through Article 6(1) the AI Act does not itself extend the scope of harmonisation legislation to new or additional products, and that the AI Act does not determine or change the risk profile of a product but builds on the sectoral risk classification. Products mentioned include machinery, toys, lifts, equipment and protective systems for potentially explosive atmospheres, radio equipment, pressure equipment, recreational craft, cableway installations, appliances burning gaseous fuels, medical devices, in vitro diagnostic medical devices, and products in the automotive and aviation sectors.
Draft guidelines Annex I, points (23) to (26)
Your starting point is therefore not the AI Act but your existing product file. The question is not whether your product appears on an AI list, because no such list exists. The question is whether your product already fell under one of the listed regulations or directives before AI was added to it. If not, this route does not bring you into the high-risk regime, however advanced the AI system is. The draft guidelines do note that for this classification the concept of safety component may be read as excluding public interests in the sectoral legislation that go beyond health, safety and fundamental rights, such as risks relating to radio spectrum use or electromagnetic compatibility. Those interests therefore do not contribute to the qualification.
Start your classification with an inventory of the product legislation that already applies to your portfolio today, and record per product line which regulation or directive covers you. That overview is reusable and prevents you from redoing the entire analysis for each AI feature.
Section A and Section B of Annex I trigger different requirement sets
For products under Section A of Annex I the full set of high-risk requirements applies. For Section B only Article 6(1), Articles 102 to 109 and Article 112 apply.
The Commission draft guidelines of 19 May 2026, which are non-binding as long as the final version has not been adopted, draw a distinction that is often missed in practice. AI systems classified as high-risk under Article 6(1) in respect of products covered by the harmonisation legislation in Section A of Annex I are subject to the requirements for high-risk systems in Section 2 of Chapter III AI Act. By contrast, for AI systems classified as high-risk under Article 6(1) in respect of products covered by the harmonisation legislation in Section B of Annex I, only Article 6(1), Articles 102 to 109 and Article 112 AI Act apply. The draft guidelines refer to Article 2(2) AI Act for this. Section A contains harmonisation legislation based on the New Legislative Framework, Section B the other Union harmonisation legislation.
Draft guidelines Annex I, point (60), referring to Article 2(2) AI Act
This distinction determines the size of your project. Two organisations can both correctly conclude they have a high-risk AI system and still face a completely different work package. If you are in Section A, the full set applies: risk management system, data quality, technical documentation, logging, transparency towards deployers, human oversight, accuracy and robustness. If you are in Section B, the requirement set is materially narrower. So check first which section your legislation sits in, before you set budget and planning.
In your classification note, record not only that you fall under Annex I but also under which section. Attach the corresponding requirement set immediately, so that your project plan is correctly sized from the outset.
Two cumulative conditions for high-risk under Annex I
An AI system only becomes high-risk under Article 6(1) when two conditions are met at the same time: the system is itself a regulated product or a safety component of one, and that product must undergo third-party conformity assessment.
The European Commission draft guidelines of 19 May 2026, which are expressly non-binding and not final, read Article 6(1) as two cumulative conditions. First, the AI system must be intended to be used as a safety component of a product, or the AI system must itself be a product, covered by the Union harmonisation legislation listed in Annex I. Second, that product, or the AI system itself where it is the product, must be required to undergo a third-party conformity assessment. The draft guidelines state explicitly that not all AI systems that are components of regulated products are high-risk, but only the subset that satisfies both criteria.
Draft guidelines Annex I, points (27) and (21)
This is a filter with two screens, and both must be passed. In practice organisations stop at the first screen and conclude their product is high-risk simply because sectoral product legislation applies to it. That is premature. The second screen, mandatory third-party involvement, removes a substantial share. The reverse also holds: anyone who looks only at the CE route and skips the safety component question will miss systems that only enter through the failure route. You must therefore ask both questions separately and record both answers.
For every AI system in a regulated product, record a two-part classification note: first whether the system is a product or a safety component, then whether a third party must be involved for that product. Keep both answers with their reasoning in your technical documentation, so that during an audit you do not have to reconstruct after the fact why you reached your conclusion.
The Article 6(3) filter: four exhaustive grounds, to be read narrowly
A system falling within Annex III can still stay outside high-risk if one of four grounds is met and the system does not perform profiling. The provider makes that call itself, must document the assessment before placing the system on the market, and must register the system in the EU database.
According to the non-binding draft guidelines of 19 May 2026 on the classification of high-risk AI, Article 6(3) sets out four grounds on which a provider may exempt a system from high-risk classification: performing a narrow procedural task, improving the result of a previously completed human activity, detecting decision-making patterns or deviations from prior patterns without replacing or influencing the previously completed human assessment absent proper human review, and performing a preparatory task. Paragraph (88) of this draft states these grounds are exhaustive but alternative, that there is no separate independent risk test, and that they must be interpreted narrowly because Article 6(3) is an exception to rules that among other things protect fundamental rights. Paragraph (87) states the filter applies only to systems under Article 6(2) and not to systems under Article 6(1). Paragraph (89) states a system always remains high-risk where it performs profiling. Paragraph (90) adds that the filter does not apply where the system forms part of a complex system whose combined intended purpose or joint outputs materially influence an individual decision, including agentic AI. Paragraphs (113) to (116) of this draft describe that this is a self-assessment by the provider, that Article 6(4) requires documenting the assessment before placing on the market and registering in the Article 71 EU database, and that the assessment must contain at least the intended purpose, why the system falls under Article 6(2), which Article 6(3) condition applies and why, and why the system does not perform profiling. Paragraph (117) of these draft guidelines points to Articles 80 and 99 where an authority finds a system was misclassified as non high-risk to circumvent the rules.
Draft guidelines on high-risk AI classification (19 May 2026), Annex III chapter, sections 2.7, 2.7.1, 2.7.3 and 2.7.4, paragraphs (84) to (90) and (113) to (117)
The filter is not a soft way out but a documented and visible decision. You leave the Chapter III high-risk obligations, but in exchange you appear in the public EU database and your reasoning must be available to the regulator at any time. For buyers that is a gift: the draft guidelines expressly encourage deployers to check that database to see whether a vendor relies on the exception.
Write the filter file in four fixed blocks: intended purpose, why it falls under Annex III, which ground you invoke with reasoning, and why there is no profiling. Never rely on the filter because the risk feels low, since that free-standing test does not exist. When procuring, always check the EU database before believing a vendor who says its system is not high-risk.
Article 6 has two separate routes to high-risk
An AI system can be high-risk in two ways. Either it is itself a product, or a safety component of a product, covered by the Annex I product legislation and that product must undergo third-party conformity assessment (Article 6(1)). Or it falls within one of the use cases listed in Annex III (Article 6(2)). The two routes have their own criteria and their own application dates.
The European Commission's draft guidelines on the classification of high-risk AI of 19 May 2026, which are expressly non-binding, state in paragraph (7) that an AI system is high-risk in two scenarios: first, where it is intended to be used as a safety component of a product, or is itself a product, covered by the Union harmonisation legislation listed in Annex I and required to undergo third-party conformity assessment; and second, where it falls within one of the use cases in the areas listed in Annex III. Paragraph (448) of those same draft guidelines notes that the Article 113 application dates have been postponed by the AI Omnibus to 2 December 2027 for the Article 6(2) route and 2 August 2028 for the Article 6(1) route.
Draft guidelines on high-risk AI classification (19 May 2026), General principles chapter, section II, paragraph (7); section V, paragraph (448)
The two routes are not interchangeable. The Annex I route turns on product legislation and on whether a third party must assess conformity, not on whether the system assesses people. The Annex III route turns on intended purpose and use case. A system can in theory touch both routes, but you must work through them separately. The exemption mechanism also differs: under the draft guidelines the Article 6(3) filter applies only to the Annex III route and not to the Annex I route.
For each AI system, record in your register which route you assessed and with what outcome. Start with the Annex I question where hardware, machinery, medical devices or toys are involved, and with the Annex III question where the system touches people or access to services. Plan your programme against the earlier of the two dates that applies to you.
Broadly positioned and general purpose AI systems: a disclaimer is not enough
If you market a system broadly without consistently limiting its application, high-risk use cases will be read into its intended purpose. Merely stating in the terms of service that high-risk uses are excluded is insufficient where the rest of your presentation in fact enables or promotes such uses.
According to the non-binding draft guidelines of 19 May 2026 on the classification of high-risk AI, paragraph (12) provides that where the instructions for use, contractual arrangements, terms of service, usage policy, promotional and sales materials or technical documentation present the AI system as broadly applicable across a generality of contexts and functions, and do not consistently limit its application or exclude high-risk uses, the system's intended purpose will be deemed to also encompass high-risk use cases and therefore qualify as high-risk. Under these draft guidelines this applies in particular where such uses are feasible and reasonably foreseeable given the system's functionalities and capabilities. The same paragraph states that merely asserting, for example in the terms of service, that high-risk uses are excluded is insufficient where the provider's overall presentation, examples or product positioning effectively provides for or promotes such uses, and that any limitations of use must be described clearly, concretely and coherently across all materials.
Draft guidelines on high-risk AI classification (19 May 2026), General principles chapter, section II.2, paragraph (12)
This mainly affects providers of broad assistants, agents and platforms who say the product is not meant for HR, education or credit assessment, but show demos, templates or customer stories in exactly those contexts. The draft guidelines look at the whole of your communications, not at the strictest sentence in the small print. For buyers it means a vendor hiding behind a clause does not relieve you of your own assessment.
If you genuinely want to exclude high-risk use, make that real in the product and not only on paper. Remove demos and examples in excluded domains, build technical or contractual blocks, and make sure sales, website and documentation draw the same line. If you cannot sustain that, assume high-risk and build your evidence file accordingly.
High-risk does not mean prohibited, and not high-risk does not mean permitted
Classification answers one question: which Chapter III obligations apply. It says nothing about whether the use itself is lawful. Prohibited practices, data protection, consumer law, product safety and national law continue to apply in full.
The draft guidelines of 19 May 2026 on the classification of high-risk AI, which are not binding, state in paragraph (3) that the fact an AI system is listed as an example in these guidelines does not mean its use should automatically be considered lawful, since such use would still need to comply with other applicable legislation, and in paragraph (4) that the scope of these guidelines is limited to whether an AI system is high-risk or not. In the Annex III chapter of this draft, paragraph (68) states that classifying systems as high-risk under Article 6(2) does not mean their use is prohibited, but that those systems are subject to appropriate requirements. Paragraphs (82) and (83) of this draft explain the wording in so far as their use is permitted under relevant Union or national law and state that falling within a use case does not necessarily mean the system may lawfully be used in those cases, that in addition to the prohibitions other provisions of Union or national law may restrict use, and that under Article 2(9) the AI Act applies without prejudice to rules on consumer protection, product safety and data protection.
Draft guidelines on high-risk AI classification (19 May 2026), General principles chapter, paragraphs (3) and (4); Annex III chapter, paragraph (68) and section 2.6, paragraphs (82) and (83)
This removes two errors of reasoning. The first is that a high-risk label equals a ban, which stops projects unnecessarily. The second, and the more dangerous one, is that an outcome of not high-risk means you have a free hand. A system can fall outside high-risk and at the same time be a prohibited practice, or fail on data protection or sector rules.
Run the classification test and the lawfulness test as two separate steps and record both outcomes separately. Always test first against the Article 5 prohibited practices, enforceable since 2 February 2025, and only then against Article 6. Finish with a short check on data protection and sector-specific law, even where the system turns out not to be high-risk.
Split and agentic architectures are assessed as a whole
You cannot avoid classification by splitting a high-risk function into separate modules. The draft assesses the combined configuration.
The non-binding draft guidelines of 19 May 2026 provide in paragraphs 75, 76 and 90 that where several AI systems form part of a more complex whole and their combined intended purpose or joint outputs materially influence an individual decision, that configuration is treated as a single AI system for classification. The draft expressly states that split architectures are assessed as a whole to prevent circumvention by system design, that exemptions for individual modules do not apply where the overall configuration influences key aspects of the decision, and that this also extends to complex interconnected setups such as agentic AI systems whose linked actions jointly serve a high-risk purpose. Under the same draft, strictly procedural or preparatory functions do remain eligible for exemption where they are genuinely separable from the system and do not structure or feed outputs that materially influence the examination of an individual case.
Section IV.2.3, paragraphs 75 and 76, and section IV.2.7.1 paragraph 90
This hits modern architecture head-on: a chain of agents, tools and model calls. Four subsystems that are each neatly preparatory on their own still form a high-risk system once the chain in practice drives the decision.
Assess at chain level, not component level. Record where separability genuinely lies, and show the exempted module can be put into service independently without contributing to the high-risk purpose.
Relying on the exception requires documentation and registration
The exception is a provider self-assessment, but not a free pass. The draft sets out four mandatory components of the assessment and links registration and supervision to it.
The draft guidelines of 19 May 2026 are not binding and describe in paragraphs 113 to 117 that applying the filter mechanism depends on a provider self-assessment, that the assessment must be documented before the system is placed on the market or put into service, and that the system must be registered in the EU database under Article 71 to ensure traceability of exempted systems. Under the draft, the assessment must contain four components: a description of the intended purpose, a description of why the system would qualify as high-risk under Article 6(2), a description of which condition or conditions of Article 6(3) are considered to apply and why, and a description of why the system does not perform profiling. The record must be available at any time on request of the market surveillance authority, and the draft encourages deployers to verify use of the exception in the Article 71 database as part of their due diligence. The draft further notes that market surveillance authorities may under Article 80 evaluate the classification, require the system to be brought into compliance and demand corrective action, and may impose penalties under Article 99 where a system was misclassified to circumvent the high-risk requirements.
Sections IV.2.7.3 and 2.7.4, paragraphs 113 to 117
The exemption shifts the work, it does not remove it. You trade the full Chapter III regime for a documented and publicly traceable justification that a supervisor can request and challenge. For deployers, the database is conversely a procurement check.
Build one fixed template covering the four mandatory components and date the assessment before market introduction. In procurement, always ask whether the supplier relies on Article 6(3) and whether that appears in the Article 71 database.
The Article 6(3) filter: four alternative conditions, to be read narrowly
A system that falls within an Annex III use case can still escape high-risk classification if it meets one of four conditions. The draft guidelines make clear this is not a broad escape route.
According to the European Commission's draft guidelines of 19 May 2026, which are not binding and were published for stakeholder consultation, the following applies (paragraphs 84 to 90): the filter mechanism only works for systems that would be high-risk under Article 6(2) and Annex III, not for systems that are high-risk under Article 6(1) and Annex I; the four conditions (narrow procedural task, improving the result of a previously completed human activity, detecting decision-making patterns or deviations without replacing or influencing the previously completed human assessment without proper human review, and preparatory task) are exhaustive but alternative; there is no separate, independent risk test alongside those conditions; and because Article 6(3) is an exception to rules that also protect fundamental rights, the conditions must be interpreted narrowly and always read in light of the requirement that the system does not materially influence the outcome of decision-making.
Sections IV.2.7 and 2.7.1, paragraphs 84 to 90
The practical question is not whether your system feels low risk, but whether it demonstrably fits one of the four described task types. The absence of a separate risk test cuts both ways: you do not need to make a general risk assessment, but you also cannot invoke one when none of the four conditions fits.
For each system, set out which of the four conditions you rely on and why, in the document's own vocabulary. If you rely on more than one, name each separately. If the reasoning feels strained, assume the narrow reading works against you and treat the system as high-risk.
A human in the loop does not make a system low-risk
Human involvement does not change the intended purpose and therefore has no effect on classification under Article 6(2). Human oversight is a compliance requirement for high-risk systems, not an escape from the classification.
The draft guidelines of 19 May 2026 on the classification of high-risk AI, which are not binding, state in paragraph (70) that the only relevant determinant for qualification under Article 6(2) is whether the intended purpose of the system includes one of the use cases listed in Annex III, that human involvement cannot change the purpose and area in which a system is intended to be used, and that human involvement therefore has no effect on classification. The same paragraph states that human oversight is instead a prerequisite for compliance with the rules for high-risk systems under Article 14. Paragraph (71) of this draft adds that the type and degree of human involvement may play a role for the Article 6(3) filter, but only to demonstrate that the tasks are narrow procedural or preparatory in nature or that the system only improves a previously completed human activity, and that a provider cannot categorise a system as low risk simply by adding a requirement of human involvement.
Draft guidelines on high-risk AI classification (19 May 2026), Annex III chapter, section 2.1, paragraphs (70) and (71)
This defeats the most common defence in practice, namely that a human always looks at it anyway. That sentence changes nothing about the classification. Human involvement only becomes relevant when you can show that the system itself plays no more than a narrow procedural or preparatory role, and that is a far heavier test than an approval button.
Delete the sentence that a human is in the loop from your classification reasoning. Instead describe exactly what the system does in the decision process and at what moment. Use the degree of human involvement only as support within one of the four Article 6(3) grounds, and keep evidence that the review is genuinely substantive.
Human oversight is a compliance requirement for high-risk systems, not a way to escape classification. Human involvement only counts when determining what task the system performs.
In the non-binding draft guidelines of 19 May 2026, the Commission states in paragraphs 70 and 71 that classification under Article 6(2) depends solely on whether the system's intended purpose falls within an Annex III use case. Human involvement cannot change the purpose and area of intended use and therefore has no effect on that classification; human oversight is instead a condition for compliance under Article 14. Under the draft, the type and degree of human involvement can play a role in the filter mechanism, but only to demonstrate that the system's tasks are narrow procedural or preparatory in nature, or merely improve a previously completed human activity. The draft expressly adds that a provider cannot label a system as low-risk simply by adding a human involvement requirement to it.
The common reassurance that a human always reviews the output changes nothing about classification. In fact, the document's examples dismiss formal human review precisely where the output in practice weighs heavily on the outcome.
Base your classification on the intended purpose, not on your workflow. If you want to use human involvement in the argument, tie it to the system's task type and show the human assessment is substantive and complete, not a formality.
Improving is deliberately different from reviewing
The second condition requires a completed human activity with a result that the system only refines. A materially different outcome does not qualify.
The draft guidelines of 19 May 2026 are a non-binding draft and state in paragraphs 94 to 96 that Article 6(3)(b) requires three cumulative elements: a human activity that has been completed, a result flowing from it, and improvement of that result by the AI system. The system may therefore not replace or autonomously perform the human activity. The draft notes the EU legislature deliberately chose the word improve rather than review, so the system must not be intended to provide a materially different result but to verify or refine the activity, and that any improvement must not change the rights, protection, legal or economic position of the persons affected. As an example that does not qualify, the draft cites a system that checks a human-made decision, plan or construction and provides a substantially different solution. As examples serving an auxiliary improvement function, the draft cites systems that flag errors or contradictions in finalised human work as quality assurance, systems that map conclusions to evidentiary records to strengthen traceability of a decision without substituting human judgment, and systems that convert human-validated content for interoperability or accessibility purposes.
Section IV.2.7.1(b), paragraphs 94 to 96
This condition is narrower than it sounds. A writing assistant that sharpens the wording of a completed judgment fits; a second-opinion model that redoes the judgment does not, however useful it may be substantively.
Make the sequence in your process demonstrable: the human judgment is recorded first, only then does the system act. Record that scores, conclusions and outcomes are not altered by the system.
Intended purpose is the anchor of classification
Intended purpose determines whether a system is high-risk. That purpose is set not only by the technical documentation but also by the instructions for use, promotional materials, sales materials and statements by the provider. Reasonably foreseeable misuse falls by definition outside the intended purpose.
The draft guidelines of 19 May 2026 on the classification of high-risk AI, which are not binding, state in paragraph (10) that the intended purpose of an AI system plays an important role in its classification as high-risk, and that under Article 3(12) intended purpose is the use for which the provider intends the system, including the specific context and conditions of use, as specified in the instructions for use, promotional or sales materials, statements and technical documentation. Paragraph (11) of that draft adds that providers must clearly describe the envisaged use, including the system's functionalities, leaving no ambiguity as to scope and intended use. Paragraph (13) of these draft guidelines places the assessment with the provider, supervised by the competent market surveillance authorities.
Draft guidelines on high-risk AI classification (19 May 2026), General principles chapter, section II.2, paragraphs (10), (11) and (13)
Marketing is legal material here. What your website, sales deck or demo promises counts towards establishing the intended purpose, even if the technical documentation is more cautious. A gap between what the system does in practice and how its purpose is described will not protect you.
Have one owner for the intended-purpose description and review the instructions for use, technical documentation, website, sales material and demo scripts against each other annually. Also describe explicitly which contexts and applications are and are not intended, and keep that wording identical across all channels.
First the definition question: is it an AI system at all?
Before classification comes into play, the system must meet the definition of an AI system in Article 3(1). Not every software application and not every automated decision-making system falls within the AI Act.
According to the non-binding draft guidelines of 19 May 2026 on the classification of high-risk AI, before a system can be classified as high-risk it must first qualify as an AI system within the meaning of Article 3(1) of the AI Act (paragraph 8). Paragraph (9) of that draft states expressly that not every software application or automated decision-making system falls within the scope of the regulation, and refers for the interpretation of the definition to the separate guidelines on the definition of an AI system (C(2025) 5053).
Draft guidelines on high-risk AI classification (19 May 2026), General principles chapter, section II.1, paragraphs (8) and (9)
This is a genuine preliminary question, not a formality. Classic rule-based software, fixed calculation rules and simple automation that does not infer from input how to generate output never reach the classification question. At the same time this is not an escape route: the definition guidelines are broad and in practice the burden of showing that something falls outside the definition rests on you.
Include an explicit definition-test field in your AI register, with the reasoning why a system is or is not an AI system. Run that test before you invest time in the Annex I or Annex III analysis, and record the result so you can show it during an inspection.
Only the assessment of natural persons falls within these use cases
Systems assessing only legal persons fall outside the relevant Annex III use cases. Self-employed people and sole traders do count as natural persons, however.
The draft guidelines of 19 May 2026, published as a non-binding draft, clarify in paragraphs 72 to 74 that a natural person is distinct from a legal person and that the notion is not limited to consumers: sole traders, independent professions and other self-employed persons also count as natural persons in relation to their commercial activity, including persons acting in a professional capacity such as consultants, designers and journalists. A system that assesses natural persons falls within the use case regardless of whether it also assesses legal persons; systems intended only to assess legal persons or companies fall outside it. The draft gives as an example that a system assessing the creditworthiness of companies based on company data, balance sheets and financial statements does not qualify as evaluating a natural person, and that an owner assessed to back a company loan also falls outside point 5(b) because the company, not the individual, is the primary beneficiary of the credit.
The boundary does not run along sector or sensitivity, but along who is being assessed. Watch the trap on the other side: as soon as your B2B system also assesses freelancers and sole traders, you are back inside the use case.
State unambiguously in the intended purpose whether natural persons are part of the assessed population. Exclude that use contractually and technically if you want to stay outside the use case, because mixed use pulls the whole system in.
Preparatory or decisive: general input is allowed, a specific recommendation is not
The preparatory task under Article 6(3)(d) precedes the assessment. Once the system evaluates the specific case or makes a recommendation, the exception is gone.
According to the non-binding draft guidelines of 19 May 2026, the notion of preparatory in Article 6(3)(d) refers to tasks occurring prior to the actual assessment process, which distinguishes it from the narrow procedural task in point (a) that may also occur during the assessment as long as it is clearly delimited (paragraphs 103 and 104). The draft cites as examples from Recital 53 indexing, searching, processing and linking: tasks that add structure to the input but do not themselves provide an assessment leading to an outcome (paragraph 106). Under paragraph 107, the decisive factor is the task's role in the decision-making process and its proximity to the final human decision. Paragraph 108 adds that output feeding a human operator's assessment can only be preparatory if it is a general input or supplementary information, and that a system producing a specific recommendation or evaluation of the case plays a decisive role and is therefore not preparatory.
Section IV.2.7.1(d), paragraphs 103 to 108
The dividing line is workable in practice: laying out information is allowed, interpreting the case is not. A system that surfaces legal provisions, jurisdiction and internal guidance stays preparatory; the same system drawing a conclusion for this file no longer is.
Test your system on one question: does the output produce anything specific to this case that points towards an outcome? If so, assume high-risk. Where possible, build a hard separation between information retrieval and assessment logic.
Profiling always blocks the exception, even when a condition would otherwise fit
As soon as the system profiles, the Article 6(3) exemption is ruled out. The draft guidelines give three cumulative elements against which you test this.
The draft guidelines of 19 May 2026, which are a non-binding draft document, explain in paragraphs 89 and 109 to 112 that a system listed in Annex III always remains high-risk where it performs profiling within the meaning of Article 4(4) GDPR, Article 3(4) of Directive (EU) 2016/680 or Article 3(5) of Regulation (EU) 2018/1725. Under the draft, profiling consists of three cumulative elements: automated processing, carried out on personal data, with the objective of evaluating personal aspects relating to a natural person. The draft states the first element is always satisfied for AI systems, so the provider must mainly establish whether personal data form the input and whether personal aspects are being evaluated. The draft adds that a simple classification on characteristics such as age, sex or height does not automatically amount to profiling, because a form of prediction, assessment or inference must be present.
Section IV.2.7.1 paragraph 89 and section IV.2.7.2, paragraphs 109 to 112
The profiling bar is the sharpest brake on the filter mechanism. Many systems that at first sight perform a tidy preparatory or procedural task still fail here because along the way they predict or judge something about a person. Note that this may be a person other than the subject of the decision, for example the assessor themselves.
State explicitly in your file which data the system ingests, whether those are personal data, and whether a prediction, score or inference about a person arises anywhere. Consider anonymisation or aggregation at source if you want to preserve the exception.
Safety component is an autonomous AI Act concept
For classification purposes only the definition of safety component in Article 3(14) AI Act counts. Definitions of the same term in sectoral product legislation are not relevant here.
According to the draft guidelines of 19 May 2026, which are non-binding and may still change, the definition of safety component in Article 3(14) AI Act is an autonomous definition with its own meaning, independent of definitions of safety component in other Union harmonisation legislation. The draft guidelines state that this definition ensures uniform interpretation of the concept across all sectors covered by Annex I, and that in assessing whether an AI system is a safety component only Article 3(14) AI Act is relevant, not the definition in any legislation listed in Annex I. Article 3(14) describes a safety component as a component of a product or of an AI system which fulfils a safety function for that product or AI system, or the failure or malfunctioning of which endangers the health and safety of persons or property.
Draft guidelines Annex I, points (32) and (33)
This is the most underestimated pitfall in the entire chapter. Many technical teams have worked for years with the notion of safety component as defined by their own sectoral standard, for instance in the machinery tradition or the medical devices world. That reflex produces the wrong outcome. The AI Act concept is broader than many sectoral definitions, precisely because it includes the failure route. A component that has never been designated a safety component in your sectoral file may well be one under the AI Act.
Run the safety component test again using only the text of Article 3(14), even if your product has had a sectoral safety file for years. Have a second reviewer who is not steeped in the sectoral tradition read along, because that person will more readily spot where the AI Act is broader than your habit.
Two routes to safety component: intent or consequence
An AI system is a safety component via two alternative routes. Either it is intended to fulfil a safety function, or its failure or malfunctioning endangers health, safety or property.
The draft guidelines of 19 May 2026 are a draft document without binding force and read Article 3(14) as two alternative scenarios. In the first scenario the AI system fulfils a safety function, meaning that its intended purpose, as determined by the provider, is to prevent or mitigate risks to the health and safety of persons or property. The draft guidelines note that the mere fact that an AI system is integrated into or operates within a product subject to safety regulation does not in itself mean it fulfils a safety function. In the second scenario the system is a safety component because its failure or malfunctioning could endanger the health and safety of persons or property. The draft guidelines summarise this in a table: the safety function is intent-based and strongly provider-controlled, evidenced by instructions of use, technical documentation and promotional materials, while the failure route is consequence-based and risk-based with lower provider control, evidenced by system architecture, failure modes and effects.
Draft guidelines Annex I, points (34) to (44), including table 1
You can steer the first route, not the second. That is the whole point. A provider determines the intended purpose and can therefore choose not to claim a safety function in the documentation. The draft guidelines close that exit with the failure route, which looks at what happens when things go wrong, regardless of what you wrote down. The guidelines list forms of failure including incorrect outputs such as false positives and false negatives, loss of function or availability, performance instability or drift, timing or latency errors, and misclassification leading to hazardous control decisions. Note the lower bound as well: the likelihood of failure must not be a merely theoretical possibility, and reputational harm, purely financial loss, minor service degradation or inconvenience without a safety hazard do not count.
Document the two routes separately. For the safety function, record what you communicate as intended purpose in the instructions of use, technical documentation and sales materials, and keep those three consistent. For the failure route, produce a failure mode analysis noting for each failure form whether there is a path to injury or damage to property. That analysis is also your evidence towards a market surveillance authority.
Integrating AI Act requirements into existing risk and quality systems
The AI Act allows you to add AI-specific risks to your existing risk management and quality management systems, so that you can work within a single compliance framework.
According to the draft guidelines of 19 May 2026, which are expressly published as a draft for stakeholder feedback and have no binding force, the AI Act provides mechanisms to reduce the compliance burden for economic operators. The draft guidelines cite Article 8(2) AI Act on the interplay with sectoral legislation, Article 9(10) AI Act on risk management and Article 17(3) AI Act on quality management, which allow economic operators to add, where necessary and appropriate, an assessment of AI-specific risks to already existing risk and quality management systems. Article 40 AI Act further requires that harmonised standards under the AI Act be consistent with standards developed under the Annex I harmonisation legislation. The draft guidelines state that these mechanisms enable economic operators to meet both the AI Act and the harmonisation legislation within a single compliance framework, thereby avoiding duplication of effort while maintaining a high level of protection of health, safety and fundamental rights.
Draft guidelines Annex I, points (61) and (62)
This is the most reassuring point in the entire chapter, and at the same time the most underused. Manufacturers who already have a mature quality management system, for instance under a sectoral standard, do not need to set up a second system alongside it. You extend what is already there. That saves not only cost but above all the fragmentation in which your AI file becomes detached from your product file and the two start contradicting each other during an audit. The practical gain lies in a shared risk register in which AI risks are included as a category, not as a separate document.
Extend your existing risk register and quality manual with an AI chapter instead of building a parallel AI management system. Appoint an owner who manages both the sectoral file and the AI file, so that changes to the product automatically touch the AI assessment.
Standalone software, updates and remote services can also be high-risk
Article 6(1) applies regardless of whether the AI system is embedded in the product or placed on the market independently. A software update, add-on or remote service can therefore be high-risk in its own right.
The draft guidelines of 19 May 2026 are non-binding and still under consultation, and clarify that Article 6(1) AI Act applies irrespective of whether the AI system is embedded within the product or placed on the market or put into service independently. An AI system supplied for example as a software update, an add-on or a remote service may therefore be classified as high-risk under Article 6(1), provided all conditions of that provision are met. The draft guidelines also distinguish the case where the AI system is the product itself: that is so where it is independently placed on the market, has its own intended purpose, and is directly regulated by the harmonisation legislation listed in Annex I. As an example the draft guidelines cite Regulation (EU) 2023/1230, the Machinery Regulation, whose definition of machinery-related products explicitly includes certain software, which may therefore itself be a regulated product and be classified as high-risk provided third-party conformity assessment is required. The draft guidelines further state that an AI system which is a safety component of a regulated product should be evaluated as part of that product's overall safety assessment, even where it is also placed on the market independently of that product.
Draft guidelines Annex I, points (22), (30) and (31)
This affects a growing group of suppliers who believe they are outside the regime because they do not make a physical product. Anyone supplying an AI module that is later loaded into a machine, lift or vehicle may well be a provider of a high-risk AI system. The same holds for over-the-air updates that change or add an existing safety function. The flip side is that your assessment is not detached from the product: the draft guidelines require your component to be weighed in the overall safety assessment of the product it lands in. That requires coordination with the manufacturer and clear arrangements on information exchange.
Map which regulated products your software ends up in and which safety-relevant functions your updates touch. Set out contractually what information you supply to the product manufacturer for their safety assessment, and treat an update that changes a safety function as a trigger to re-test the classification.
When a customer or distributor itself becomes the provider
Distributors, importers, deployers and other third parties can take on provider obligations. That happens when you put your own name or trademark on a system, when you make a substantial modification to a high-risk system, and when you change the intended purpose of a non high-risk system so that it becomes high-risk.
The draft guidelines of 19 May 2026 on the classification of high-risk AI, which are not binding, note in paragraph (14) that distributors, importers, deployers or other third parties may become subject to provider obligations under Article 25(1) where they, first, put their name or trademark on a high-risk AI system already placed on the market or put into service; second, make a substantial modification to a high-risk AI system already placed on the market or put into service in such a way that it remains a high-risk AI system; or third, modify the intended purpose of an AI system, including a general-purpose AI system, which had not been classified as high-risk, in such a way that the system becomes a high-risk AI system under Article 6. A footnote to that paragraph announces that the Commission is preparing separate guidelines on responsibilities along the AI value chain under Article 25.
Draft guidelines on high-risk AI classification (19 May 2026), General principles chapter, section II.2, paragraph (14) and its footnote 6
The third situation is the most underestimated. An organisation that buys a broadly deployable model or assistant and then aims it at recruitment, employee evaluation or access to services changes the intended purpose and can thereby become the provider of a high-risk system, with the full set of obligations. White labelling under your own brand is also enough, without changing a single line of code.
Introduce a standing check before you rebrand, modify or repurpose a procured AI system. Assess for each change whether you land in one of the three Article 25(1) situations and record that assessment. Make this part of your procurement and change process, not a one-off project check.
Module choice does not change the classification
The fact that a manufacturer may opt for internal control based on harmonised standards does not affect the high-risk classification. Classification follows the level of enhanced scrutiny required by the product legislation, not the procedure chosen.
The draft guidelines of 19 May 2026 have the status of a non-binding draft and clarify the second condition as follows. The AI Act does not itself determine the applicable conformity assessment procedures but relies on the choice of procedures established under the Annex I harmonisation legislation. Decision 768/2008/EC sets out eight main modules A to H. For all modules except module A the involvement of a notified body is required; module C does not require such involvement but is always combined with modules that do; for modules A1 and A2 a notified body or accredited in-house body is required only in the production phase. The draft guidelines then state explicitly that the fact that harmonisation legislation may allow a manufacturer to rely on internal control based on harmonised standards, as one procedural option, does not affect the classification of an AI system as high-risk under Article 6(1). The choice of module gives the manufacturer procedural flexibility to demonstrate compliance but confers no discretion to determine the risk classification under the AI Act. The decisive factor is that the product, under the Annex I legislation, is subject to enhanced regulatory scrutiny before it may lawfully be placed on the market, scrutiny ensured through the requirement of third-party conformity assessment or equivalent mechanisms, including internal control subject to mandatory application of harmonised standards published in the Official Journal. The draft guidelines point out that the Union legislature expressly confirmed this logic in recital 15 of Regulation (EU) 2025/2509 on the safety of toys.
Draft guidelines Annex I, points (50) to (59)
Here the draft guidelines close the most obvious escape route. The reasoning many manufacturers hoped to use ran: we apply harmonised standards, therefore we use module A, therefore no third party is involved, therefore we are not high-risk. The Commission reverses that. What matters is not the chosen procedure but the level of protection the legislature considered necessary for that product type. Anyone who has built the module A route into their compliance planning must now revisit that assumption. The toys and machinery regulations are explicitly named as sectors where this plays out.
Test your classification not against the module you actually use, but against whether the legislature prescribed enhanced scrutiny for your product type. If your sectoral legislation permits internal control only subject to mandatory application of harmonised standards, assume you fall within the high-risk regime and plan your AI Act track accordingly.
Classification route for standalone high-risk AI systems under Article 6(2) and Annex III.
The intended purpose falls within a use case listed in Annex III.
A listed Annex III system may fall outside high-risk under the strict conditions in Article 6(3), except where it profiles. The assessment and registration must be documented.
The core rules in Chapter III, Sections 1 to 3, for systems under Article 6(2) and Annex III become applicable on 2 December 2027.
Amended Article 113, Article 6(2) and Annex III application date
The later application date does not remove the classification question. An early classification record avoids design and procurement decisions without evidence.
Document now the intended purpose, Annex III point, Article 6(3) assessment, profiling and selected registration path.
Article 6(2)-(4), Article 49 and Annex III
Quality and governance requirements for training, validation and test data of high-risk AI.
The high-risk system is trained with data; the provider composes the datasets, the deployer controls relevant input data.
For special categories of personal data the strict exception of Article 10(5) applies (bias detection and correction under conditions).
Article 10 requires datasets appropriate to the intended purpose, with governance over origin and composition, attention to representativeness, errors and completeness, and examination of possible bias with appropriate measures.
For the Annex III route this requirement applies from 2 December 2027; for high-risk AI in regulated products (Annex I) from 2 August 2028.
Today’s dataset choices determine whether compliance is feasible later: data bought or collected today without provenance records cannot be repaired in 2027.
Record origin and assumptions per dataset and include data quality as a requirement in every AI or data procurement contract.
The technical file demonstrating before market placement that a high-risk system meets the requirements.
The provider places a high-risk AI system on the market or puts it into service.
Small providers (SMEs) may provide the documentation in the simplified form established by the Commission.
Article 11 requires technical documentation drawn up before market placement, kept up to date and containing the Annex IV elements, so that compliance with Section 2 is demonstrable to supervisors.
For buying organisations, Annex IV is the checklist of what you must be able to request contractually from your supplier; without that file you cannot meet your own Article 26 duties.
Include the right to access the technical documentation in AI procurement and supplier contracts now.
Automatic recording of events over the lifetime of a high-risk AI system.
The system is high-risk; the provider designs the logging, provider and deployer retain the logs under their control.
The retention period may be limited by Union or national law, including data protection.
Article 12 requires high-risk AI systems to be technically capable of automatically recording events over their lifetime, for traceability, risk signalling and post-market monitoring; Article 19 and Article 26(6) govern log retention.
Article 12, Article 19 and Article 26(6)
Logging is the backbone of all other evidence: without logs an incident cannot be reconstructed and a monitoring duty cannot be fulfilled. Buyers should already test whether a system is technically capable of this.
Include logging capability and log access as a requirement in every AI purchase and assign the retention regime (who, where, how long) per system.
Article 13: transparency towards deployers
Comprehensible instructions for use and system information so deployers can operate the system correctly.
The provider supplies a high-risk system; the deployer uses it according to the instructions.
The level of detail may match the intended deployer’s knowledge; trade secrets need not be disclosed.
Article 13 requires high-risk systems to be designed transparently enough for deployers to interpret and use the output, with instructions covering purpose, accuracy, limitations, human oversight and maintenance.
The instructions are the hinge between provider and deployer duties: what the provider fails to supply here, the deployer cannot deliver under Article 26. Ask for it explicitly at procurement.
Translate received instructions per system into internal work instructions per role and record who received them.
High-risk AI must be designed so that humans can effectively oversee it and intervene.
The system is high-risk; the provider builds in oversight measures, the deployer assigns oversight to competent persons.
For remote biometric identification the reinforced requirement of verification by at least two authorised persons applies (Article 14(5)), with the exceptions listed there.
Article 14 requires high-risk systems to be effectively overseeable by natural persons, with measures enabling them to understand the system, correctly interpret output, remain aware of automation bias, and decide not to use, to disregard or to stop the system.
Oversight on paper is not oversight: the law names automation bias explicitly, so a human who may only click through does not count. Effective oversight requires understanding, time and mandate, which ties directly into the Article 4 literacy measures.
Appoint the overseeing persons per (upcoming) high-risk system now, train them specifically and record their mandate to intervene in writing.
Article 15: accuracy, robustness and cybersecurity
Appropriate levels of performance, robustness and security across the lifecycle of high-risk AI.
Systems that continue learning after deployment carry additional requirements to control feedback loops and drift.
Article 15 requires high-risk systems to achieve and maintain appropriate levels of accuracy, robustness and cybersecurity throughout the lifecycle, including resilience against errors and AI-specific attacks such as data poisoning and adversarial examples.
Accuracy here is not a marketing number but a declared, testable value stated in the instructions for use and held against you in production.
Ask suppliers now for declared accuracy levels and test reports, and set up production monitoring against those levels.
Article 16: the twelve duties of a provider of a high-risk AI system
Article 16 is the summary list of duties for providers: twelve points that route onward to the quality management system, the documentation, the logs, the conformity assessment, the EU declaration of conformity, the CE marking, the registration, corrective actions and accessibility requirements.
Applies to providers of high-risk AI systems. For the standalone Annex III route (Article 6(2)) the date is 2 December 2027. For systems embedded as a safety component in products covered by the Annex I harmonisation legislation (Article 6(1)) the date is 2 August 2028.
A provider that considers an Annex III system not to be high-risk must document that assessment before placing it on the market and remains subject to the registration obligation of Article 49(2) (Article 6(4)). Where an AI system referred to in Annex III performs profiling of natural persons it is always considered high-risk (Article 6(3), final subparagraph).
Article 16 requires providers of high-risk AI systems to do twelve things. They must ensure their systems comply with the requirements of Chapter III, Section 2 (point (a)); indicate on the system or, where that is not possible, on its packaging or accompanying documentation, their name, registered trade name or registered trade mark and the address at which they can be contacted (point (b)); have a quality management system in place complying with Article 17 (point (c)); keep the documentation referred to in Article 18 (point (d)); keep the automatically generated logs referred to in Article 19 when under their control (point (e)); ensure the system undergoes the conformity assessment procedure referred to in Article 43 prior to being placed on the market or put into service (point (f)); draw up an EU declaration of conformity in accordance with Article 47 (point (g)); affix the CE marking in accordance with Article 48 (point (h)); comply with the registration obligations referred to in Article 49(1) (point (i)); take the necessary corrective actions and provide the information required under Article 20 (point (j)); upon a reasoned request of a national competent authority, demonstrate conformity with the requirements of Section 2 (point (k)); and ensure the system complies with the accessibility requirements of Directives (EU) 2016/2102 and (EU) 2019/882 (point (l)).
Article 16 reads like a table of contents and is therefore often planned as a single roadmap line. It is twelve separate duties with widely differing lead times: building a quality management system takes months, affixing a CE marking takes a day. The bigger trap sits in Article 25(1): anyone who puts their own brand on an existing high-risk system, substantially modifies it, or changes the intended purpose of a non-high-risk system so that it becomes high-risk counts as a provider and inherits all twelve points without ever having built anything. In the branding scenario of point (a) this applies without prejudice to contractual arrangements stipulating that the obligations are otherwise allocated, but you must have made and be able to show those arrangements in advance. In practice this catches parties that white-label AI or apply a general-purpose model to an Annex III use case.
First determine whether you are a provider or whether Article 25 makes you one, then work out the twelve points as twelve separate work packages with an owner and a date. Start with points (c) and (f), because they set the lead time of the whole track.
The documented quality system through which a high-risk AI provider structurally assures compliance.
The provider places high-risk AI systems on the market or puts them into service.
Providers already under sectoral quality regimes may integrate the AI elements into that existing system; SMEs may implement elements in simplified form.
Article 17 requires a documented quality management system covering a compliance strategy, design and development procedures, data management, risk management, post-market monitoring, incident reporting and an accountability structure.
The QMS is the umbrella over all other provider duties: those with the separate files but no system connecting them fail exactly this article in an audit.
Build the QMS not as a separate document but as an index on top of the existing files (risk, data, documentation, monitoring) with owners per procedure.
Before placing a system on the market the importer verifies four things about the provider, and afterwards carries its own retention, information and notification package with a ten-year term.
Applies to importers of high-risk AI systems. For the standalone Annex III route (Article 6(2)) the date is 2 December 2027; for the embedded Annex I route (Article 6(1)) the date is 2 August 2028.
If you put your own name or trade mark on the system, substantially modify it, or change the intended purpose so that it becomes high-risk, Article 25(1) treats you as a provider and the duties of Article 16 apply instead of those of Article 23.
Article 23(1) requires importers, before placing a high-risk AI system on the market, to verify that the relevant conformity assessment procedure referred to in Article 43 has been carried out by the provider (point (a)), that the provider has drawn up the technical documentation in accordance with Article 11 and Annex IV (point (b)), that the system bears the required CE marking and is accompanied by the EU declaration of conformity referred to in Article 47 and instructions for use (point (c)), and that the provider has appointed an authorised representative in accordance with Article 22(1) (point (d)). Article 23(2) provides that an importer with sufficient reason to consider that the system is not in conformity, is falsified or is accompanied by falsified documentation shall not place it on the market until it has been brought into conformity, and that where the system presents a risk within the meaning of Article 79(1) the importer shall inform the provider, the authorised representative and the market surveillance authorities. Paragraph 3 requires indication of name, registered trade name or registered trade mark and contact address. Paragraph 4 requires storage and transport conditions that do not jeopardise compliance with Section 2. Paragraph 5 requires keeping, for 10 years, a copy of the certificate issued by the notified body and, where applicable, of the instructions for use and of the EU declaration of conformity referred to in Article 47. Paragraph 6 requires providing all necessary information and documentation upon a reasoned request in a language easily understood by the authority, and ensuring the technical documentation can be made available. Paragraph 7 requires cooperation with the competent authorities.
Article 23 gets underestimated because it looks like document control, and largely it is: you do not have to revalidate the model, you have to be able to show that you checked the four points. The pain sits elsewhere. Point (d) is the one that most often fails in practice: many providers outside the EU have not appointed an authorised representative, and then you simply may not place the system on the market, however far along the deal is. And paragraph 5 puts the ten-year term on you, not on the supplier: if that supplier no longer exists in five years, you still have to produce the documents.
Move the four verifications of Article 23(1) to the moment before contract signature instead of before delivery. Request the declaration of conformity, the technical documentation, proof of the Article 43 procedure and the authorised representative's details as a condition precedent in the purchase contract.
Before making a system available on the market the distributor verifies the marking, the declaration and the instructions for use plus compliance by provider and importer, and must afterwards be able to correct, withdraw or recall.
Applies to distributors of high-risk AI systems. For the standalone Annex III route (Article 6(2)) the date is 2 December 2027; for the embedded Annex I route (Article 6(1)) the date is 2 August 2028.
If you put your own name or trade mark on the system, substantially modify it, or change the intended purpose so that it becomes high-risk, Article 25(1) treats you as a provider and the duties of Article 16 apply instead of those of Article 24.
Article 24(1) requires distributors, before making a high-risk AI system available on the market, to verify that it bears the required CE marking, that it is accompanied by a copy of the EU declaration of conformity referred to in Article 47 and instructions for use, and that the provider and the importer of that system, as applicable, have complied with their obligations laid down in Article 16, points (b) and (c), and Article 23(3). Paragraph 2 prohibits making the system available while the distributor considers or has reason to consider, on the basis of the information in its possession, that it does not comply with the requirements of Section 2, and requires notification of the provider or the importer where the system presents a risk within the meaning of Article 79(1). Paragraph 3 requires storage and transport conditions that do not jeopardise compliance. Paragraph 4 requires a distributor that considers or has reason to consider that a system already made available does not comply with Section 2 to take the corrective actions necessary to bring it into conformity, to withdraw it or recall it, or to ensure that the provider, the importer or any relevant operator takes those actions; where the system presents a risk within the meaning of Article 79(1) it shall immediately inform the provider or importer and the competent authorities, giving details of the non-compliance and of any corrective actions taken. Paragraph 5 requires providing, upon a reasoned request, all information and documentation regarding actions taken under paragraphs 1 to 4. Paragraph 6 requires cooperation with the competent authorities.
The check in paragraph 1 looks light but contains an awkward element: you must also verify that the provider has complied with Article 16, point (c), which is having a quality management system in place under Article 17. You cannot see that on the packaging. In practice you anchor it in supplier terms with a statement from the provider and record what you checked. The centre of gravity of Article 24 sits in paragraph 4 though: many resellers assume recall is the manufacturer's business, while the provision also places that action on you, with the option of ensuring another party carries it out. That ensuring requires contractual grip arranged in advance, not during an incident.
Include the three checks of paragraph 1 in your resell or delivery process and keep a record per contract of what you saw. Also make sure you can tell within a day which customer uses which system in which version, because without that overview you cannot execute paragraph 4.
Article 26: obligations of deployers of high-risk AI systems
Twelve paragraphs governing day-to-day use: use in line with the instructions, human oversight by competent people, input data, monitoring and notification, log retention, informing workers before deployment, registration by public authorities and informing the people about whom decisions are made.
Applies as soon as you use a high-risk AI system under your own authority (Article 3(4)), whether you built it yourself or procured it. For the standalone Annex III route (Article 6(2)) the date is 2 December 2027; for the embedded Annex I route (Article 6(1)) the date is 2 August 2028.
Article 2(10) excludes natural persons using an AI system in the course of a purely personal, non-professional activity. For deployers that are financial institutions subject to internal governance requirements under Union financial services law, the monitoring obligation in paragraph 5 is deemed fulfilled by complying with those rules, and the logs under paragraph 6 are maintained as part of the documentation kept under that law.
Article 26 imposes twelve paragraphs on deployers of high-risk AI systems. Paragraph 1 requires appropriate technical and organisational measures to ensure use in accordance with the accompanying instructions for use. Paragraph 2 requires assigning human oversight to natural persons who have the necessary competence, training and authority, as well as the necessary support. Paragraph 3 leaves other obligations and the freedom to organise one's own resources unaffected. Paragraph 4 requires, to the extent the deployer exercises control over the input data, that such data is relevant and sufficiently representative in view of the intended purpose. Paragraph 5 requires monitoring on the basis of the instructions for use and informing the provider in accordance with Article 72; where there is reason to consider that use may result in a risk within the meaning of Article 79(1), the deployer shall without undue delay inform the provider or distributor and the relevant market surveillance authority and suspend use, and upon identifying a serious incident shall immediately inform first the provider and then the importer or distributor and the market surveillance authorities. Paragraph 6 requires keeping the automatically generated logs under the deployer's control for a period appropriate to the intended purpose and of at least six months, unless Union or national law provides otherwise. Paragraph 7 requires deployers who are employers to inform workers' representatives and the affected workers, before putting into service or using the system at the workplace, that they will be subject to its use. Paragraph 8 imposes the registration obligations of Article 49 on public authorities and Union institutions, bodies, offices and agencies and prohibits use of a system not registered in the EU database referred to in Article 71. Paragraph 9 links the information provided under Article 13 to the data protection impact assessment under Article 35 of Regulation (EU) 2016/679. Paragraph 10 sets additional conditions for post-remote biometric identification in law enforcement. Paragraph 11 opens with the words without prejudice to Article 50 of this Regulation and requires deployers of Annex III systems that make or assist in making decisions related to natural persons to inform those persons that they are subject to the use of the system; for high-risk AI systems used for law enforcement purposes Article 13 of Directive (EU) 2016/680 applies. The transparency obligations of Article 50 have applied since 2 August 2026 and are separate from the date on which paragraph 11 starts to apply. Paragraph 12 requires cooperation with the competent authorities.
The 2 December 2027 date invites postponement, but two elements are preparation work today. Paragraph 7 requires you to inform workers' representatives and the affected workers before the system is put into service at the workplace, and that information is provided, where applicable, in line with existing rules and practice on informing workers. That touches employee participation, and such a process takes months rather than weeks in practice, so a system that must go live in 2027 is discussed in 2026. Paragraph 2 also connects to the human oversight that Article 14 imposes on system design: you must designate natural persons with competence, training, authority and support. That is emphatically not the same as the measures obligation in Article 4. Article 4 requires measures supporting AI literacy and does not require you to guarantee a particular level for individuals; Article 26(2) requires identifiable overseers with a mandate. Conflating the two leaves you believing a generic e-learning is enough while still having no overseer with room to decide. A third underestimated element is paragraph 11: informing the people about whom an Annex III system makes or helps make decisions is visible customer or candidate communication that you have to design across your own organisation.
Draw up now a list of the systems likely to qualify as high-risk from 2 December 2027 and add three columns: who exercises human oversight and with what mandate, when you will inform the works council and the affected workers, and how the persons concerned will receive the notice under paragraph 11. Plan the employee participation process a year ahead.
Fundamental rights impact assessment before deploying certain high-risk AI systems.
The system is high-risk under Article 6(2) and Annex III, excluding Annex III point 2.
The deployer is a body governed by public law, a private provider of public services or uses a relevant system in Annex III point 5(b) or 5(c).
In the situation covered by Article 46(1), an exemption from notification may apply. This does not generally remove the assessment itself.
The listed deployers must perform a FRIA before deployment. For this Annex III route, the obligation follows the application date of 2 December 2027.
Amended application schedule and Article 27 DPIA cross-reference
A FRIA is not a generic risk assessment for every AI system. First establish the system route, Annex III category and type of deployer.
Link the FRIA to the AI inventory and, where relevant, the DPIA. Keep scope, affected groups, mitigations, residual risks and notification in one versioned record.
Article 27 amendment on DPIA inclusion or cross-reference
Providers and deployers take measures that support the development of AI literacy.
The organisation is a provider or deployer of an AI system within scope.
The provision does not require a specific individual level to be guaranteed.
Since 27 July 2026, providers and deployers must take measures supporting the development of AI literacy. The provision does not require a guaranteed individual level.
Amendment of Article 4; entry into force 27 July 2026
Evidence is primarily a proportionate record of measures by role and context, not one prescribed course or certificate.
Questions on measures, formats, certificates and records
Inventory roles and AI systems, select appropriate measures and record the choice, implementation and periodic review.
Implementation examples and evidence guidance
The prohibition of AI practices carrying unacceptable risk, such as manipulation, social scoring and certain biometric applications.
Placing on the market, putting into service or using AI falls under one of the practices in Article 5(1), including harmful manipulation or exploitation of vulnerabilities, social scoring, predicting criminal offences based on profiling, untargeted scraping of facial images, emotion recognition in the workplace or education, biometric categorisation by sensitive characteristics and real-time remote biometric identification in publicly accessible spaces for law enforcement.
The exceptions are narrow: among others, emotion recognition for medical or safety reasons, and the exhaustively defined law-enforcement situations with authorisation for real-time remote biometric identification in Article 5(2) to (7). The exception must be established and documented in advance.
The prohibited practices of Article 5 apply since 2 February 2025 and are the only AI Act category enforceable for that entire period. Violations carry the highest fine ceiling in the regulation: up to 35 million euro or 7 percent of worldwide annual turnover.
Article 5, Article 99(3) and Article 113(a)
The Digital Omnibus adds a prohibition on AI for child sexual abuse material and non-consensual intimate synthetic content; the accompanying technical safeguards are required by 2 December 2026.
Amendment to Article 5 and transition to 2 December 2026
The line often sits in the definitional details: the same technique can be prohibited in the workplace and permitted in another context. Screen per concrete use and context, not per technology, and do so before procurement or go-live.
Make the Article 5 screening the first step of every classification and record the outcome per system in the register, including the reasoning why a practice does not fall under the prohibition.
Article 5 read with Article 6 classification order
Specific disclosure, marking and labelling duties for certain AI systems and synthetic content.
An AI system is intended to interact directly with natural persons.
The system generates or manipulates synthetic audio, image, video or text, or the use concerns a specifically listed deployer scenario.
The direct-interaction disclosure is not required where this is obvious to a reasonably well-informed, observant and circumspect person, considering circumstances and context.
Only Article 50(2) has a transition until 2 December 2026 for systems placed on the market before 2 August 2026.
Article 50 applies since 2 August 2026. The precise duty differs by scenario: direct AI interaction, machine-readable marking, emotion recognition or biometric categorisation, deepfakes and certain public-interest text.
A generic rule that all AI content must always carry a visible label is too broad. First classify the specific Article 50 scenario.
Final guidelines, scope by Article 50 paragraph
For each system, record the applicable paragraph, responsible actor, implemented disclosure or marking and how it was tested.
Implementation guidance for providers and deployers
Documentation, information, copyright and transparency duties for providers of general-purpose AI models.
The party is a provider of a GPAI model placed on the Union market.
For models placed on the market from 2 August 2025, the duties apply from that time. Models placed on the market before 2 August 2025 must comply by 2 August 2027.
The open-source exception is limited and retains, among other things, the copyright policy and public training-content summary. Additional duties apply to models with systemic risk.
Article 53 applies since 2 August 2025 to new GPAI models. Providers maintain technical documentation, provide information to downstream providers, operate a Union copyright policy and publish a sufficiently detailed summary of training content.
Providers of GPAI models placed on the market before 2 August 2025 must comply with the applicable obligations by 2 August 2027.
An organisation merely using an external GPAI model does not thereby automatically become a GPAI model provider. First determine its role in the value chain.
Scope and provider qualification guidance
Record model versions, role qualification, documentation owners, downstream information, copyright policy and training summary in one change-controlled file.
Article 55: GPAI models with systemic risk
Additional duties for the most capable general-purpose AI models, on top of Article 53.
The GPAI model has high-impact capabilities, presumed above 10^25 FLOPs of cumulative training compute, or is designated by the Commission.
The GPAI Code of Practice can, following the adequacy assessment, serve as a means to demonstrate compliance.
Article 55 obliges providers of GPAI models with systemic risk to perform model evaluations including adversarial testing, assess and mitigate systemic risks at Union level, track and report serious incidents, and ensure adequate cybersecurity of model and infrastructure. The duties apply since 2 August 2025; AI Office enforcement is active since 2 August 2026.
Article 55(1)-(2) with Article 51 and Article 52
The 10^25 FLOPs threshold is a presumption, not a shield: the Commission can also designate models on capabilities, and fine-tuning on top of an existing model can in some circumstances trigger a qualification of its own.
Model providers near the threshold: set up compute monitoring now and join the Code of Practice to carry the burden of proof.
Member States must provide at least one national AI regulatory sandbox. For you this is a voluntary route: you develop, train, test and validate an innovative AI system in a controlled, supervised environment under a plan agreed with the competent authority, before placing it on the market or putting it into service.
Relevant where you are a provider or prospective provider of an innovative AI system that you want to develop, train, test or validate before placing it on the market or putting it into service, and you want up-front certainty about classification or about how you meet the requirements of this Regulation.
Participation is voluntary. Article 57 places the duty on the Member State to provide a sandbox, not on you to join one. A Member State may also fulfil that duty by participating in an existing sandbox with equivalent national coverage. Article 57(4) leaves other regulatory sandboxes established under Union or national law unaffected.
Article 57(1) requires Member States to ensure that their competent authorities establish at least one AI regulatory sandbox at national level. The text of Regulation (EU) 2024/1689 as published in the Official Journal provides that the sandbox shall be operational by 2 August 2026, and that wording still stands unchanged on 9 August 2026 in the article text published by the European Commission. The timeline the European Commission publishes after the Digital Omnibus, Regulation (EU) 2026/1744, entered into force on 27 July 2026 places the milestone at 2 August 2027 instead, stating "Member States should have at least one AI regulatory sandbox per country operational". The consolidated text of Article 57(1) after the Omnibus has not been verified at article level; rely on the consolidated version on EUR-Lex for the exact date. Chapter VI, which contains Article 57, is not among the exceptions in Article 113 and therefore applies since 2 August 2026. Article 57(1) further provides that the obligation may also be fulfilled by participating in an existing sandbox, in so far as that participation provides an equivalent level of national coverage. Article 57(5) defines the sandbox as a controlled environment that fosters innovation and facilitates the development, training, testing and validation of innovative AI systems for a limited time, pursuant to a specific sandbox plan agreed between the provider or prospective provider and the competent authority, before the system is placed on the market or put into service. Such sandboxes may include testing in real world conditions supervised therein. Article 57(15) requires the AI Office to make publicly available, and keep up to date, a list of planned and existing sandboxes.
Article 57(1)-(17), Article 58, Article 113; as amended by Regulation (EU) 2026/1744
The common mistake is to read the sandbox as a delay or an exemption. It is neither. Article 57(11) leaves the competent authority's supervisory and corrective powers fully intact and expressly empowers it to suspend your testing or your participation, temporarily or permanently, where risks cannot be effectively mitigated. A sandbox is useful for exactly one profile: you are building an AI system that is likely to fall under Annex III, you are uncertain about its classification or about how to meet Chapter III, Section 2, and you want that uncertainty resolved before you go to market. If you are purely a deployer buying a system, the sandbox is not your route: at most you can join as a partner of the provider under Article 58(2), point (b). Second trap: 2 August 2027 is a duty on the Member State, not on you. The date on this item is therefore 2 August 2026: from that moment Chapter VI applies and the route is open to you. You cannot hang your own preparation on that date, and the date says nothing about whether your national sandbox will actually have capacity by then. Third trap: people confuse the Article 57 sandbox with Article 60 real-world testing. These are two distinct routes with different conditions. Real-world testing can take place inside the sandbox (Article 57(5) and Article 58(4)) or outside it under Article 60, and the safeguards differ.
First establish your role: only providers and prospective providers can enter on their own. Then use the AI Office's published list of planned and existing sandboxes (Article 57(15)) to find the sandbox open to you, in your Member State or jointly with others. Before you apply, state exactly which uncertainty you want resolved, ideally focused on classification under Article 6 or on a specific requirement in Chapter III, Section 2. Plan for the three-month decision period that Article 58(2), point (a), requires the implementing acts to ensure, build it into your product timeline, and ask the competent authority in writing which period it currently applies. On entry, record in writing what the sandbox plan covers, and on exit request both the written proof and the exit report.
Article 60: testing in real world conditions outside a sandbox
If you want to test an Annex III high-risk AI system with real people and real outcomes before placing it on the market, a full regime applies: a plan, prior approval by the market surveillance authority, registration, informed consent and a maximum duration.
Applies where you are a provider or prospective provider of an Annex III high-risk AI system and you want to test it in real world conditions outside an AI regulatory sandbox, before placing it on the market or putting it into service. If you are established outside the Union, Article 60(4), point (d), requires you to appoint a legal representative established in the Union; that is a different figure from the authorised representative under Article 22.
Article 60(1), third subparagraph, leaves Union and national law on real-world testing of high-risk systems related to products under the Annex I harmonisation legislation unaffected. Article 60(4), point (i), contains a law enforcement carve-out: where seeking informed consent would prevent the system from being tested, testing may proceed without consent, provided the testing and its outcome have no negative effect on the subjects and their personal data are deleted after the test. For the systems referred to in Annex III, points 1, 6 and 7, in law enforcement, migration, asylum and border control, registration runs through the secure non-public section of the EU database under Article 49(4), point (d). For the systems referred to in Annex III, point 2, Article 49(5) requires registration at national level.
Article 60(1) provides that testing of high-risk AI systems in real world conditions outside AI regulatory sandboxes may be conducted by providers or prospective providers of high-risk AI systems listed in Annex III, in accordance with that Article and the real-world testing plan, without prejudice to the prohibitions under Article 5. The Commission specifies the detailed elements of that plan by implementing act. The third subparagraph of paragraph 1 provides that the paragraph is without prejudice to Union or national law on the testing in real world conditions of high-risk AI systems related to products covered by the Union harmonisation legislation listed in Annex I. Article 60(2) allows providers or prospective providers to test at any time before placing on the market or putting into service, on their own or in partnership with one or more deployers or prospective deployers. Article 60(3) provides that such testing is without prejudice to any ethical review required by Union or national law. Article 60(4), point (f), caps the duration: no longer than necessary to achieve its objectives and in any case no longer than six months, which may be extended by an additional six months subject to prior notification to the market surveillance authority with an explanation of the need. Article 60(4), point (g), requires that subjects belonging to vulnerable groups due to age or disability are appropriately protected. Article 60(9) expressly states that the provider or prospective provider remains fully subject to applicable Union and national law on any damage caused in the course of their testing in real world conditions. Chapter VI, which contains Article 60, is not among the exceptions in Article 113 and applies since 2 August 2026.
Article 60(1)-(4), Article 60(9), Article 113
Many organisations call what they do a pilot and assume that keeps them outside the Regulation. Article 60 shows that this does not hold once you test an Annex III system in real world conditions with real people and real outcomes. A full regime then applies: a plan, prior approval, registration with a Union-wide unique single identification number, informed consent, and a hard six-month clock with a maximum six-month extension. The heaviest requirement in practice is Article 60(4), point (k): the predictions, recommendations or decisions of the system must be capable of being effectively reversed and disregarded. If you are testing a selection, scoring or triage system whose output feeds straight into the workflow with nobody able to reverse it, your design does not qualify, however careful your consent form is. Note the timing too, because it is commercially interesting. Chapter VI applies since 2 August 2026, while the core obligations for standalone Annex III systems only apply from 2 December 2027. The testing route is therefore open before the requirements themselves bite, and that is exactly the window in which to validate your design rather than rebuild it later. Finally, Article 60(3) leaves any ethical review required under other law fully in place, and Article 60(9) expressly states that you remain fully subject to the applicable law on damage caused during the testing.
Inventory which running or planned trials are in fact real-world testing: real users, real data, outputs that feed into the workflow. Test those first against Article 60(4), point (k): can the output genuinely be reversed and disregarded? If not, redesign the trial before you submit anything. Then choose deliberately between two routes: supervised testing inside a sandbox under Article 57(5) and Article 58(4), or outside a sandbox under Article 60. Plan the six months realistically and decide in advance at which point you will request an extension, since that requires prior notification with a reasoned explanation. Check whether an ethical review is mandatory in your domain and start it in parallel, because Article 60(3) does not exempt you from it.
Systematic monitoring of high-risk AI in real use, after market placement.
The provider has a high-risk system on the market; deployers supply the real-world data via monitoring and signals.
The plan may be proportionate to the nature of the system and align with existing sectoral monitoring regimes.
Article 72 obliges providers to operate a post-market monitoring system with a plan forming part of the technical documentation, collecting relevant real-world data to evaluate continued compliance with Section 2.
Compliance does not stop at go-live: this article turns compliance into a continuous state. For deployers it is also the basis to force suppliers to act on deviations.
Design the monitoring together with the Article 12 logging: the same data flows feed both duties.
The duty to report serious incidents with high-risk AI, under strict deadlines.
A serious incident occurs with a high-risk system: death or serious harm to health, serious and irreversible disruption of critical infrastructure, infringement of fundamental-rights protections or serious damage to property or environment.
For systems under sectoral reporting regimes with equivalent duties, reporting may run through that regime to avoid duplication.
Article 73 obliges providers to report serious incidents to the market surveillance authority: immediately after establishing the causal link and at the latest within 15 days, shortened to 10 days in the event of death and to 2 days for widespread infringement or serious disruption of critical infrastructure. Deployers inform the provider without delay.
The deadlines are too short to design the process during the incident: those who decide who reports at the first incident will not make 15 days, let alone 2. This is the GDPR breach playbook, but for AI.
Connect the AI incident process to the existing breach and security process and add the AI-specific definitions and deadlines.
Article 85: right to lodge a complaint with the market surveillance authority
Anyone with grounds to consider that the Regulation has been infringed may lodge a complaint with the relevant market surveillance authority. For an organisation that means your own staff, customers and candidates have a route to the regulator that does not run through you.
Applies as soon as anyone has grounds to consider that the Regulation has been infringed. There is no standing threshold: the right belongs to any person, and the complaint goes to the market surveillance authority of the Member State concerned.
Without prejudice to other administrative or judicial remedies, any natural or legal person having grounds to consider that there has been an infringement of the provisions of this Regulation may submit complaints to the relevant market surveillance authority. In accordance with Regulation (EU) 2019/1020, such complaints shall be taken into account for the purpose of conducting market surveillance activities, and shall be handled in line with the dedicated procedures established therefor by the market surveillance authorities.
The practical meaning of this article lies not in what it instructs you to do but in whom it gives a route. An employee who thinks the scheduling or appraisal system is wrong, a rejected candidate, a customer who feels mishandled: they do not have to convince you first and do not have to show standing. The complaint arrives at the authority, and the first question you then face is about record keeping: which system, which version, which assessment was carried out and when. That is the same record keeping Articles 26 and 72 already require of you, and that is exactly the point. Whoever has that file answers a complaint with documents; whoever does not answers it with a reconstruction after the fact, and a regulator reads that differently. Note too that this right does not depend on harm or on a decision, whereas the right to an explanation in Article 86 does.
Assume a complaint starts at the authority and not with you. Make sure that per AI system you can show which assessment was carried out, by whom, on what date and against which system version, and keep that as a living file rather than a one-off document. Also agree internally who receives a question from an authority and within what period.
Article 86: right to an explanation of a decision
A person affected by a decision that a deployer takes on the basis of the output of a high-risk AI system listed in Annex III may request an explanation of the role of that system in the decision-making procedure and of the main elements of the decision taken.
Applies where a deployer takes a decision about a natural person on the basis of the output of a high-risk AI system listed in Annex III, with the exception of point 2 of that Annex, and that decision produces legal effects or similarly significantly affects that person in a way they consider to have an adverse impact on their health, safety or fundamental rights.
Paragraph 2 excludes the right for AI systems where exceptions from, or restrictions to, that obligation follow from Union or national law in compliance with Union law. Paragraph 3 further limits the right to cases where it is not otherwise provided for under Union law, which makes the boundary with Article 22 GDPR a case-by-case question.
Paragraph 1 gives any affected person subject to a decision taken by the deployer on the basis of the output of a high-risk AI system listed in Annex III, with the exception of point 2 of that Annex, and which produces legal effects or similarly significantly affects that person in a way that they consider to have an adverse impact on their health, safety or fundamental rights, the right to obtain from the deployer clear and meaningful explanations of the role of the AI system in the decision-making procedure and of the main elements of the decision taken. Paragraph 2 provides that paragraph 1 does not apply to the use of AI systems for which exceptions from, or restrictions to, that obligation follow from Union or national law in compliance with Union law. Paragraph 3 provides that this Article applies only to the extent that the right referred to in paragraph 1 is not otherwise provided for under Union law.
This right reaches you through a different channel than the rest of the Regulation. A regulator writes to you; a candidate or a citizen calls or emails, usually at your existing complaints or objections desk. That desk does not know today that an AI system was in the process, let alone what role it played, and that is where it goes wrong. Two things therefore matter more than the legal depth of the explanation itself: that your front line recognises such a request, and that it can be traced per decision which system in which version contributed to it. Without the second you can explain how your system works in general but not what happened in this case, and the latter is what is being asked. Note also the relationship with Article 22 GDPR: where that article already grants a right, Article 86 steps back, but the scope differs enough that you cannot settle the question in the abstract.
Record, per Annex III system that contributes to decisions about people, which decision was supported by which system version, and make sure your complaints or objections desk recognises a request for an explanation and routes it to someone who can answer it. Also determine per process whether Article 22 GDPR already grants a right, because Article 86 then steps back.
A continuous, documented risk management system across the entire lifecycle of a high-risk AI system.
The system is high-risk under Article 6 and the provider places it on the market or puts it into service.
Risks arising only from misuse beyond any reasonably foreseeable use fall outside the mandatory scope.
Article 9 requires a risk management system as a continuous, iterative process across the entire lifecycle, with identification, analysis, evaluation and mitigation of risks to health, safety and fundamental rights, and testing to determine the most appropriate measures.
This is not a one-off risk analysis but a living process: most organisations have an assessment, but no cycle that reruns on every change. The cycle is what a supervisor will request.
Start the risk management file now for systems that will become high-risk towards 2 December 2027: today’s design and procurement choices determine tomorrow’s residual risks.
Articles 43-49: conformity assessment, CE and registration
The route from assessment to CE marking and EU database registration before market placement of high-risk AI.
The provider places a high-risk system on the market; public deployers also register their use.
For most Annex III systems internal control suffices (Annex VI); a notified body is required for certain biometrics and where harmonised standards are lacking.
Article 43 governs the conformity assessment, Article 47 the EU declaration of conformity, Article 48 the CE marking and Article 49 the registration in the EU database before market placement or putting into service, including registration of the Article 6(3) assessment.
For buyers this is the simplest supplier check there is: ask for the declaration of conformity and the registration number. No declaration means the system may not be there by 2 December 2027.
Plan the conformity route backwards from 2 December 2027: standards selection, assessment, declaration and registration together take months, not weeks.
Articles 22-25: value chain and authorised representative
Role shifts in the AI value chain and the mandatory representative for non-EU providers.
A high-risk system is supplied, modified, rebranded or placed on the Union market from outside the EU.
Those acting solely as distributor or importer without the Article 25 triggers remain in that lighter role, with their own verification duties.
Article 25 provides that a distributor, importer, deployer or third party becomes the provider when it puts its name on a high-risk system, substantially modifies it or changes its intended purpose so it becomes high-risk; Article 22 obliges third-country providers to appoint a written authorised representative in the Union.
The most dangerous role switch is the unintended one: your own layer on top of a procured model, your own brand on a tool, and you suddenly carry the full provider duties. This belongs as a standing question in every AI project.
Include the role question in the AI register and in project gates, and contractually define who supplies which information and cooperation on changes.
EN 18286:2026: quality management system for EU AI Act regulatory purposes
The first completed European standard under the AI Act standardisation request: the quality management system that Article 17 requires from providers of high-risk AI systems.
Relevant to providers of high-risk AI systems, who must have a quality management system in place by 2 December 2027 (Annex III standalone) or 2 August 2028 (Annex I embedded in regulated products).
According to that same coverage statement the standard does not cover Article 17(2) to (4) or Article 72; those obligations must be substantiated independently.
EN 18286:2026 (Artificial intelligence: Quality management system for EU AI Act regulatory purposes) was drafted by CEN/CLC/JTC 21 under standardisation request M/613 and approved by CEN-CENELEC on 12 July 2026. It is the first JTC 21 deliverable to reach publication. According to a published coverage statement accompanying the standard, not yet confirmed by a second independent source, it addresses Article 17(1) points (a) to (m) and Article 11(1) first sentence, and expressly not Article 17(2) to (4) or Article 72. The standard is NOT currently cited in the Official Journal. The Article 40 presumption of conformity only attaches after that citation.
This is the first time the AI Act quality requirements exist as an auditable normative text, which is worth more than its legal status suggests. The common trap runs the other way: people read "first harmonised standard" and assume compliance now carries evidentiary weight. As long as the reference is not in the Official Journal, EN 18286 is simply a well-structured document with no legal presumption. You still carry the burden of showing your system meets Article 17. Conversely, anyone building on this structure now will not have to rebuild after citation.
Use the clause structure of EN 18286 as the table of contents for your quality dossier: separate the organisational clauses (governance, leadership, planning, support, management review) from the per-system clauses (lifecycle, operations, post-market monitoring, incident handling). Record which internal document evidences each clause. Note explicitly that Article 17(2) to (4) and Article 72 fall outside the standard and must be substantiated separately.
EN ISO/IEC 42001: artificial intelligence management system
The certifiable organisation-level AI management system, a European standard since 2026, but not a harmonised standard under the AI Act.
Usable by both providers and deployers seeking to structure AI governance organisation-wide.
Certification against ISO/IEC 42001 replaces no AI Act obligation and does not shift the burden of proof.
ISO/IEC 42001:2023 is the first certifiable international standard for an AI management system, published on 18 December 2023 and structured on the plan-do-check-act cycle. The text was adopted unchanged as EN ISO/IEC 42001:2026, approved by CEN on 13 March 2026, with national implementation by the member standards bodies. This adoption is not a deliverable under standardisation request M/613: the standard is not cited in the Official Journal and therefore confers no presumption of conformity under Article 40. For Article 17, the designated deliverable under M/613 is EN 18286:2026; that standard is likewise not cited in the Official Journal.
EN ISO/IEC 42001:2026, European adoption via CEN-CENELEC
This is the most expensive misconception in the whole standards layer: an ISO/IEC 42001 certificate is not AI Act conformity. The certificate shows you have a governance structure, not that a specific high-risk system meets the regulation. Documented gaps against Article 17 include the absence of a per-system regulatory compliance strategy, of predetermined change management for continuously learning systems, of the Article 73 serious incident reporting timelines, and of a structured fundamental rights assessment. Vendors saying "ISO 42001 certified, therefore AI Act ready" are selling you a certificate, not your dossier.
Use ISO/IEC 42001 as the organisational layer (policy, roles, management review, internal audit) and put the per-system layer on top: a dedicated dossier per high-risk system along the clauses of EN 18286. Deliberately close the gaps named above: per-system compliance strategy, predetermined change management, incident reporting process with the Article 73 timelines, and fundamental rights assessment. In procurement, ask not for the certificate but for the statement of applicability and the audit report.
ISO/IEC 12792: transparency taxonomy of AI systems
The international taxonomy of transparency information elements, usable as a checklist for the Article 13 instructions for use.
ISO/IEC 12792:2025 (Information technology: Artificial intelligence: Transparency taxonomy of AI systems) was published in November 2025 by ISO/IEC JTC 1/SC 42. It specifies a taxonomy of information elements to help stakeholders identify and address transparency needs, and describes the semantics of those elements and their relevance to different stakeholders' objectives. The text was adopted as a European standard as EN ISO/IEC 12792:2025. It is not cited in the Official Journal and therefore confers no presumption of conformity under Article 40. For Article 13 the designated deliverable is prEN 18229-3.
The value lies in the completeness check: the taxonomy shows which information elements you can forget, and that is exactly where instructions for use fall short in practice. What it is not: a template that satisfies Article 13. The regulation itself determines what the instructions for use must contain, including the provider's details, characteristics and limitations, accuracy metrics, oversight measures and expected lifetime. Also watch the confusion with Article 50: those transparency obligations have applied since 2 August 2026 and fall on providers of AI systems that interact directly with natural persons or generate synthetic content, and on deployers of emotion recognition, biometric categorisation and deepfakes. They apply regardless of high-risk classification. For systems already placed on the market before 2 August 2026, the machine-readable marking under Article 50(2) has a transition until 2 December 2026.
Structure your instructions for use as a numbered list following the elements of Article 13(3) one for one, and use the ISO/IEC 12792 taxonomy alongside it as a checklist for missing elements. Keep Article 50 transparency information separate, since it addresses the end user rather than the deployer.
ISO/IEC 23894: guidance on risk management for AI
The international guidance for AI-specific risk management, usable as an interim structure while prEN 18228 remains in draft.
ISO/IEC 23894:2023 (Information technology: Artificial intelligence: Guidance on risk management) was published in February 2023 and is the first international standard dealing specifically with risk management for AI. It is non-prescriptive and built on the ISO 31000 structure. The text was adopted by CEN-CENELEC as EN ISO/IEC 23894:2024. It is not cited in the Official Journal and therefore confers no presumption of conformity under Article 40 of the AI Act. The deliverable intended to do so for Article 9 is prEN 18228.
EN ISO/IEC 23894:2024, European adoption via CEN-CENELEC
ISO/IEC 23894 gives you the vocabulary and process flow of AI risk management, and that is usable today. Where it falls short: it is guidance, not a requirements set, and it is written from organisational risk while Article 9 starts from risk to the health, safety and fundamental rights of others. A risk register built entirely along ISO/IEC 23894 therefore does not automatically cover Article 9. Use it as scaffolding, not as evidence.
Adopt the ISO/IEC 23894 process flow (context, identification, analysis, evaluation, treatment, monitoring, recording) and add two AI Act-specific fields per risk: who outside your organisation can be affected, and what residual risk you deem acceptable on what justification. That lets you connect the register to the final EN 18228 without rebuilding it.
ISO/IEC 24029 series: assessment of the robustness of neural networks
The international series making neural network robustness testable, usable as methodology under Article 15 while prEN 18229-2 remains in draft.
Particularly relevant to high-risk systems based on neural networks.
ISO/IEC TR 24029-1:2021 (Assessment of the robustness of neural networks, Part 1: Overview) is a technical report mapping the topic and available assessment methods. ISO/IEC 24029-2:2023 (Part 2: Methodology for the use of formal methods) describes the application of formal methods in assessing robustness. The series is aimed at AI developers and users assessing robustness across the lifecycle. Neither part is cited in the Official Journal, so no presumption of conformity under Article 40 arises. For Article 15 the designated deliverable is prEN 18229-2, which as at June 2026 was still in drafting.
Part 1 is a technical report and therefore not a requirements set: it gives an overview, not a benchmark. Part 2 is the sharper text substantively, but formal methods are only feasible for relatively bounded models. For large generative models you hit the limits quickly, leaving empirical testing. The trap is making a robustness claim measured only on the average test set: Article 15 is specifically about behaviour under errors, faults and unexpected input.
Choose deliberately per system between formal verification (for bounded models) and empirical stress testing, and record the choice and its justification. Test explicitly on out-of-distribution input, missing fields and edge cases, and document the performance degradation observed. Add those results to the technical documentation and to the instructions for use where they define the limits of use.
ISO/IEC 5259 series: data quality for analytics and machine learning
The five-part international series on data quality, in practice the most usable structure for the Article 10 data governance dossier.
The ISO/IEC 5259 series (Artificial intelligence: Data quality for analytics and machine learning) comprises five parts: part 1 (overview, terminology and examples), part 2 (data quality measures), part 3 (data quality management requirements and guidelines) and part 4 (data quality process framework), all published in 2024, plus part 5 (data quality governance framework), published in February 2025. CEN-CENELEC has adopted parts as European standards, including EN ISO/IEC 5259-4:2025 and EN ISO/IEC 5259-3:2025. No part is cited in the Official Journal, so no presumption of conformity under Article 40 arises. The deliverable intended to do so for Article 10 is prEN 18284.
ISO/IEC 5259 series, ISO/IEC JTC 1/SC 42
This is currently the most concrete help available for Article 10, because part 2 actually makes data quality measurable rather than merely discussing it. What it is not: coverage of Article 10. The regulation asks for things the series does not address, such as examination for possible bias with a view to fundamental rights and representativeness for the specific intended user population in the EU. A dataset scoring well on every 5259 measure can still structurally under-represent a population group.
Use part 2 to fix a small number of hard quality measures per dataset and part 4 to describe the process that maintains them. Add two AI Act fields the series does not cover: representativeness for the intended user population, and the outcome of the bias examination with the measures taken. Retain the measurement results per dataset version, not only for the latest version.
prEN 18228: AI risk management for high-risk systems
The draft European standard filling in the Article 9 risk management system, built on a product-safety logic rather than an enterprise-risk logic.
Relevant to providers preparing for the high-risk obligations applying from 2 December 2027 (Annex III) or 2 August 2028 (Annex I).
prEN 18228 (AI risk management) is the JTC 21 deliverable under M/613 intended to confer presumption of conformity with Article 9 of the AI Act: the risk management system that providers of high-risk AI systems must establish, implement, document and maintain across the full lifecycle. The public Enquiry ran until 30 July 2026. The standard has not yet been published as an EN and is not cited in the Official Journal. The prEN designation means it is a draft text.
prEN 18228 (draft standard), CEN/CLC/JTC 21 under M/613
The distinguishing feature is the perspective. prEN 18228 is written from product safety: it concerns risks to the health, safety and fundamental rights of third parties, not risks to your organisation. Anyone filling an Article 9 dossier with an existing ISO 31000 or ERM register makes exactly the mistake this standard exposes: that register looks inward, Article 9 looks outward. And a draft standard is not yet evidence: you can adopt the method, but you cannot prove anything with it towards a supervisory authority today.
Build your Article 9 risk register now with an outward view: for each foreseeable use and foreseeable misuse, name the person or group who can be affected, the measure that reduces the risk, and the residual risk that remains. Keep the structure separate from your ERM register so the final EN 18228 can be mapped over it later without rewriting the content.
prEN 18229-1: AI trustworthiness framework part 1, logging
The draft European standard for the automatic event recording that Article 12 requires of high-risk AI systems.
Providers build in the logging capability (Article 12) and keep the logs under their control (Article 19); deployers retain the logs generated by the system (Article 26(6)).
prEN 18229-1 (AI trustworthiness framework, Part 1: Logging) is the JTC 21 deliverable under M/613 for Article 12 of the AI Act: high-risk AI systems must technically allow for the automatic recording of events over their lifetime. As at June 2026 the deliverable was at the Enquiry stage. It has not yet been published as an EN and is not cited in the Official Journal.
prEN 18229-1 (draft standard), CEN/CLC/JTC 21 under M/613
Article 12; Article 19; Article 26(6); Article 40
Logging is the obligation that is cheapest to get right now and most expensive to repair later, because a system that does not log cannot start logging retroactively. Mind the split of roles: the provider must build in the logging capability, the deployer must retain the logs. Buying a system without checking whether it logs means buying a hole in your own dossier. This standard is still a draft text and therefore carries no evidentiary weight yet.
Put the logging requirement in your procurement terms and in the acceptance test: which events are recorded, with what timestamp, how long they are retained, and how you export them to a supervisory authority. Document those answers per system now, so the final EN 18229-1 only needs to be mapped against what you already record.
prEN 18229-2: AI trustworthiness framework part 2, accuracy and robustness
The draft European standard meant to make the appropriate level of accuracy and robustness under Article 15 measurable.
prEN 18229-2 (AI trustworthiness framework, Part 2: Accuracy and robustness) is the JTC 21 deliverable under M/613 for Article 15 of the AI Act, which requires high-risk AI systems to achieve an appropriate level of accuracy, robustness and cybersecurity and to declare accuracy metrics in the instructions for use. As at June 2026 the deliverable was at the drafting stage. It has not yet been published as an EN and is not cited in the Official Journal.
prEN 18229-2 (draft standard), CEN/CLC/JTC 21 under M/613
Article 15 leaves open what "appropriate" means, and that open norm is precisely what this deliverable would fill in. Until it is finished, you must justify yourself which accuracy level fits your application and why. The common trap is putting a single percentage in the instructions for use without stating on which population and under which conditions it was measured: that is not a metric, it is a marketing figure. A supervisory authority will ask about the measurement setup.
Record a test protocol per high-risk system: which metric, which test population, which subgroups measured separately, and what performance degradation under out-of-distribution conditions is acceptable. Use the ISO/IEC 24029 series for robustness methodology and retain the raw test results, not only the summary.
prEN 18229-3: AI trustworthiness framework part 3, transparency and human oversight
The draft European standard for the transparency and oversight requirements of Articles 13 and 14 for high-risk AI systems.
Providers design in the oversight measures under Article 14; under Article 26(2) deployers assign natural persons with the necessary competence, training and authority and give them the mandate they need.
prEN 18229-3 (AI trustworthiness framework, Part 3: Transparency and human oversight) is the JTC 21 deliverable under M/613 addressing Articles 13 and 14 of the AI Act: transparency and provision of information to deployers, and the design for effective human oversight of high-risk AI systems. As at June 2026 the deliverable was at the drafting stage. It has not yet been published as an EN and is not cited in the Official Journal. This deliverable concerns Article 14 (high-risk) and not the Article 50 transparency obligations, which apply since 2 August 2026.
prEN 18229-3 (draft standard), CEN/CLC/JTC 21 under M/613
Articles 13 and 14; Article 26(2); Article 40
Human oversight is the obligation that most often exists on paper and fails in practice. Article 14 requires the designated person to be able to genuinely understand, override and reverse the output. A staff member with thirty seconds per case and no mandate to deviate is not human oversight, only a signature. The common mistake is waiting for this standard while the bottleneck is not technical but organisational: mandate, time and escalation route.
Describe per high-risk system who exercises oversight, what information that person sees at the decision moment, how much time is allotted, what mandate exists to deviate, and how a deviation is recorded. Those four answers are the core of your Article 14 evidence and will not change with the final normative text.
prEN 18284: quality and governance of datasets in AI
The draft European standard operationalising the Article 10 data governance requirements for training, validation and testing data.
Applies to providers of high-risk AI systems that are trained on data.
prEN 18284 (Artificial intelligence: Quality and governance of datasets in AI) is the JTC 21 deliverable under M/613 for Article 10 of the AI Act, which sets requirements for the training, validation and testing datasets of high-risk AI systems. As at June 2026 the deliverable was at the drafting stage. It has not yet been published as an EN and is not cited in the Official Journal.
prEN 18284 (draft standard), CEN/CLC/JTC 21 under M/613
Article 10 is where most organisations actually fail, because they never recorded the provenance and processing history of their data. prEN 18284 will turn that recording into a normative requirement. The common mistake is waiting for the standard before starting data lineage: that documentation is almost impossible to reconstruct retroactively. What you do not record now cannot be proven two years from now.
Start a dataset passport per high-risk system now: provenance, collection method, processing steps, representativeness for the intended user population, known gaps and the bias examination performed. Use the ISO/IEC 5259 series as an interim structure and keep the fields generic so they can be renamed to the terminology of the final EN 18284.
prEN 18285: conformity assessment framework for AI systems
The draft European standard operationalising the conformity assessment procedure of Article 43 and Annex VII.
The Article 43 conformity assessment rests on the provider. The authorised representative established in the Union keeps the EU declaration of conformity and the technical documentation available to the supervisory authority and cooperates with it under Article 22.
prEN 18285 (Conformity assessment framework) is the JTC 21 deliverable under M/613 covering the conformity assessment of high-risk AI systems under Article 43 and Annex VII of the AI Act. As at June 2026 the deliverable was at the drafting stage. It has not yet been published as an EN and is not cited in the Official Journal. Standardisation request M/613 was amended by Implementing Decision C(2025)3871 of 23 June 2025 and expires on 28 February 2027.
prEN 18285 (draft standard), CEN/CLC/JTC 21 under M/613
Article 43 and Annex VII; Article 22; Article 40
This is the deliverable that determines how heavily the rest weighs. For most Annex III systems the provider may self-assess (internal control), but that does not mean nothing is required: it means you must be able to show the complete dossier yourself. The trap is thinking self-assessment is light. The notified body is absent, the burden of proof is not. While prEN 18285 remains in draft, there is no recognised blueprint for that self-assessment and you must justify the structure yourself.
Determine per system which assessment route applies (internal control or notified body) and build your dossier as one an external party would have to be able to read, even where you self-assess. Plan backwards from 2 December 2027 for standalone Annex III systems and 2 August 2028 for systems embedded in regulated products.
Public classifier for the high-risk use cases in Annex III.
The full legal text in the public AI Act Explorer.
Public route for structuring measures by role and context.
The full legal text of the prohibited practices with all categories and exceptions, in the public AI Act Explorer.
Public decision route for the distinct transparency obligations.
Public generator for structuring a fundamental rights impact assessment.
Public guide to GPAI model obligations and exceptions.