Een agent die leveranciersfacturen koppelt en een agent die sollicitanten filtert, kunnen op hetzelfde platform draaien. Toch gelden voor hen niet dezelfde verplichtingen onder de EU AI Act. Het doel van het werk telt, net als de rol van jullie organisatie bij het aanbieden of gebruiken van het systeem.
Voor een operationeel team zijn de eerste vragen praktisch. Zijn we gebruiksverantwoordelijke, aanbieder of allebei? Is dit gebruik high-risk? Wat moeten we nu doen en welk bewijs hebben we nodig wanneer de overige regels gaan gelden?
Het bredere beeld bespraken we in de spelregels die rond AI ontstaan. Dit artikel kiest het perspectief van de gebruiksverantwoordelijke: de organisatie die een AI-systeem onder haar verantwoordelijkheid gebruikt. De focus ligt op terugkerend bedrijfswerk, niet op specialistische regels voor rechtshandhaving of alle productveiligheidsregimes.
Ben je gebruiksverantwoordelijke of aanbieder?
Een gebruiksverantwoordelijke gebruikt een AI-systeem onder eigen verantwoordelijkheid, buiten zuiver persoonlijke en niet-professionele activiteiten. Koop je een systeem van een leverancier en gebruik je het voor het gedocumenteerde doel, dan valt jullie organisatie vaak in die rol.
Een aanbieder ontwikkelt een systeem of laat het ontwikkelen en brengt het onder eigen naam of merk op de markt of stelt het in gebruik. Daarvoor hoef je het onderliggende model niet zelf te trainen of software aan andere bedrijven te verkopen. Ook opdracht geven voor een systeem voor eigen gebruik kan relevant zijn. Dit zijn de definities uit artikel 3.
De rollen horen bij het systeem en de activiteit. Een organisatie kan gebruiksverantwoordelijke zijn voor het ene systeem en aanbieder van het andere. De aankoop van een agentplatform bepaalt niet vanzelf de status van alles wat erop wordt gebouwd.
Artikel 25 noemt drie situaties waarin een gebruiksverantwoordelijke of andere partij de verplichtingen van een aanbieder van een high-risksysteem overneemt:
- Een eigen naam of merk op een bestaand high-risksysteem zetten, met inachtneming van de bepaling over contractuele verdeling van verplichtingen.
- Een bestaand high-risksysteem wezenlijk wijzigen, waarbij het high-risk blijft.
- Het beoogde doel van een niet-high-risksysteem zo veranderen dat het high-risk wordt.
Routineconfiguratie is niet automatisch een wezenlijke wijziging. Omgekeerd kan iets dat intern “alleen een nieuwe workflow” heet, het beoogde doel wel veranderen. Breid je een documentassistent uit naar sollicitantenscreening, beoordeel de classificatie dan opnieuw vóór go-live.
Leg het vast in het contract
Het contract moet benoemen wie het systeem aanbiedt, wat het beoogde doel is, welke wijzigingen zijn toegestaan, wie toegang krijgt tot documentatie en wat er gebeurt bij een andere rol of classificatie. Artikel 25 erkent contractuele verdeling in het geval van naam en merk. Dat is geen algemeen recht om de wet contractueel buiten werking te zetten.
Is het werk high-risk?
Een agent is niet automatisch high-risk omdat hij autonoom handelt. En menselijke goedkeuring van de output plaatst hem niet automatisch buiten de high-riskregels.
Artikel 6 kent twee hoofdroutes. De eerste betreft bepaalde producten en veiligheidscomponenten onder de wetgeving in Bijlage I, wanneer de relevante conformiteitsbeoordeling door een derde vereist is. De tweede betreft toepassingen uit Bijlage III, waaronder specifieke vormen van inzet bij werk, onderwijs, essentiële diensten, biometrie en kritieke infrastructuur.
Voor veel operationele teams is Bijlage III de meest directe vraag. Sollicitanten screenen, de kredietwaardigheid van personen beoordelen en risico of prijs bepalen voor levens- en zorgverzekeringen staan op de lijst. Leveranciersfacturen koppelen of achter een leverdatum aangaan valt op basis van die omschrijving normaal gesproken niet in die categorieën.
Artikel 6(3) bevat beperkte uitzonderingen voor sommige systemen uit Bijlage III, waaronder bepaalde smalle procedurele of voorbereidende taken zonder significant risico. Dit zijn voorwaarden om zorgvuldig te toetsen, geen labels om losjes toe te passen. Systemen uit Bijlage III die natuurlijke personen profileren, worden onder deze bepaling altijd als high-risk behandeld.
Vraag de aanbieder om het beoogde doel en de classificatie en vergelijk die met wat jullie werkelijk van plan zijn. Leg de beslissing en redenen vast. Verandert het werk, beoordeel dan opnieuw.
Dit hangt samen met, maar staat los van, de geschiktheid van het werk voor een AI-agent. Een proces kan juridisch toegestaan zijn en toch te duur om te controleren of te moeilijk om te begeleiden.
Wat geldt nu en wat is uitgesteld?
De Digital Omnibus voor AI, Verordening (EU) 2026/1744, wijzigde de AI Act in juli 2026. Specifieke high-riskbepalingen zijn uitgesteld, niet de hele wet. De door de Raad aangenomen tekst beschrijft de wijzigingen in artikelen 111 en 113.
| Bepaling | Geldt vanaf | Wat te controleren |
|---|---|---|
| Artikel 4 AI-geletterdheid | 2 feb 2025 | Tekst gewijzigd in juli 2026. Maatregelen die AI-geletterdheid ondersteunen van medewerkers en anderen die namens jullie AI gebruiken |
| Artikel 5 verboden | 2 feb 2025 | Of een praktijk verboden is, vóórdat controls of openbaarmaking worden overwogen |
| Artikel 50 transparantie | 2 aug 2026 | Welke plicht geldt en of die bij jullie of de aanbieder ligt. Sommige kennen uitzonderingen |
| Hoofdstuk III Afdelingen 1 t/m 3 | 2 dec 2027 | High-risksystemen uit Bijlage III, behalve artikel 6(5). Classificatie, systeemeisen en plichten uit artikelen 26 en 27 |
| Hoofdstuk III Afdelingen 1 t/m 3 | 2 aug 2028 | Dezelfde bepalingen voor artikel 6(1) en systemen uit Bijlage I, met de toepasselijke productregels |
Dit zijn algemene data. Het gewijzigde artikel 111 bevat overgangsregels voor high-risksystemen die vóór de relevante datum uit Hoofdstuk III al op de markt of in gebruik waren, met voorwaarden rond ingrijpende ontwerpwijzigingen. Stel per systeem vast welke regels gelden. Behandel december 2027 niet als universele deadline voor elke bestaande inzet.
AI-geletterdheid vraagt nu al actie
Het gewijzigde artikel 4 vereist maatregelen die de ontwikkeling van AI-geletterdheid ondersteunen. Het eist geen gegarandeerd niveau voor ieder individu. Training en begeleiding moeten passen bij de mensen, systemen en gebruikscontext. Leg vast wat is aangeboden en waarom dat passend was. De vragen en antwoorden over AI-geletterdheid van de Commissie lichten de gewijzigde aanpak toe.
Transparantie hangt af van gebruik en rol
Artikel 50 scheidt plichten van aanbieders en gebruiksverantwoordelijken. Aanbieders moeten systemen voor rechtstreekse interactie met mensen zo ontwerpen dat duidelijk is dat zij met AI te maken hebben, tenzij dat uit de omstandigheden al vanzelf spreekt. Ook dragen aanbieders de plicht voor machineleesbare markering van synthetische content.
Gebruiksverantwoordelijken hebben specifieke plichten voor emotieherkenning en biometrische categorisering, deepfakes en door AI gegenereerde of gemanipuleerde tekst die het publiek informeert over zaken van algemeen belang. Voor die laatste categorie geldt een uitzondering bij menselijke review of redactionele controle, mits een persoon of organisatie redactioneel verantwoordelijk is. Voor duidelijk artistieke, creatieve, satirische of fictieve deepfakes gelden bijzondere regels. Zie artikel 50.
Voor een bestaand generatief systeem dat vóór 2 augustus 2026 op de markt kwam, is de markeringsdeadline voor de aanbieder uit artikel 50(2) 2 december 2026. Die overgang stelt de eigen openbaarmakingsplichten van de gebruiksverantwoordelijke niet uit.
De Omnibus voegt per 2 december 2026 ook verboden toe voor bepaalde seksuele of intieme content zonder toestemming en materiaal van seksueel misbruik van kinderen. Openbaarmaking maakt verboden gebruik niet rechtmatig.
De AVG, arbeidsregels en toepasselijke sectoreisen blijven naast de AI Act gelden. Het high-riskuitstel schort die niet op.
Wat vereist artikel 26 van een high-riskgebruiksverantwoordelijke?
Zodra artikel 26 op jullie systeem van toepassing is, gaan de belangrijkste eisen over gebruik, menselijke controle en monitoring. Hieronder staat een praktische samenvatting, geen vervanging van de volledige bepaling of sectorspecifieke voorwaarden.
| Gebied | Wat de gebruiksverantwoordelijke moet doen | Artikel |
|---|---|---|
| Gebruik | Technische en organisatorische maatregelen nemen om het systeem volgens de instructies van de aanbieder te gebruiken | 26(1) |
| Menselijke controle | Die beleggen bij mensen met de competentie, training, bevoegdheid en ondersteuning om haar uit te oefenen | 26(2) |
| Inputdata | Waar de gebruiksverantwoordelijke de inputdata beheert, zorgen dat die relevant en voldoende representatief is voor het beoogde doel | 26(4) |
| Monitoring | De werking monitoren, handelen bij relevante risico's, gebruik waar vereist opschorten en de nodige meldingen doen | 26(5) |
| Logs | Automatisch gegenereerde logs onder eigen controle passend en minstens zes maanden bewaren, tenzij toepasselijk recht anders bepaalt | 26(6) |
| Werknemers | Betrokken werknemers en hun vertegenwoordigers vóór gebruik op de werkplek informeren dat zij aan het high-risksysteem worden onderworpen | 26(7) |
| Registratie | Als overheidsinstantie of namens een overheid, de toepasselijke registratie- en databankcontroles uitvoeren | 26(8) |
| Gegevensbescherming | Bij een verplichte DPIA de informatie van de aanbieder gebruiken ter ondersteuning | 26(9) |
| Betrokken personen | Bij relevante systemen uit Bijlage III die beslissingen over personen nemen of ondersteunen, die personen informeren over het gebruik | 26(11) |
| Autoriteiten | Meewerken met bevoegde autoriteiten aan maatregelen rond het systeem | 26(12) |
De volledige tekst staat in artikel 26. Iemand beschikbaar hebben om output goed te keuren is niet genoeg als die persoon de beperkingen niet begrijpt, de relevante informatie niet kan verkrijgen of het werk niet kan stoppen.
Artikel 27 voegt voor bepaalde gebruiksverantwoordelijken en toepassingen een grondrechteneffectbeoordeling toe. Dit geldt voor publiekrechtelijke instellingen, private partijen die publieke diensten leveren en gebruiksverantwoordelijken van de genoemde systemen voor kredietwaardigheid en levens- of zorgverzekeringen. De categorie kritieke infrastructuur uit Bijlage III is uitgezonderd. Niet elke private organisatie met high-risk-AI hoeft deze beoordeling uit te voeren.
Waar vereist, vindt de beoordeling vóór het eerste gebruik plaats, blijft ze actueel en worden de resultaten zoals voorgeschreven gemeld. De Omnibus staat kruisverwijzingen naar relevante delen van een bestaande DPIA toe, of opname daarvan in de grondrechtenbeoordeling. De beoordeling zelf vervalt niet. Zie artikel 27 en de wijzigingen.
Zes maanden is een bewaartermijn
Artikel 26(6) bepaalt hoelang relevante logs moeten worden bewaard zodra de plicht geldt. Het vereist niet dat op de eerste dag al zes maanden historie bestaat.
Eerder beginnen kan helpen monitoring te testen en fouten te onderzoeken, maar moet een bewuste operationele beslissing zijn. Stel bewaartermijn, toegangsrechten en verwijderregels samen vast, rekening houdend met toepasselijke eisen voor persoonsgegevens.
Wat gebeurt er wanneer een incident wordt ontdekt?
Wanneer artikel 26(5) geldt, moet een gebruiksverantwoordelijke die een ernstig incident vaststelt onmiddellijk de aanbieder informeren, vervolgens de importeur of distributeur en de relevante markttoezichtautoriteiten. Is de aanbieder niet bereikbaar, dan geldt artikel 73 met de nodige aanpassingen voor de gebruiksverantwoordelijke.
Bij een risico zoals genoemd in artikel 26(5) omvat de plicht het zonder onnodige vertraging informeren van de relevante partijen en het opschorten van gebruik. Niet elke onjuiste output is juridisch een ernstig incident. Het team heeft wel een route nodig om dat direct te beoordelen, zonder op de maandelijkse review te wachten.
Artikel 73 bevat vooral de meldingsplichten van de aanbieder. De algemene uiterste termijn is 15 dagen na kennisname, met kortere termijnen van tien dagen bij overlijden en twee dagen bij een wijdverbreide inbreuk of de genoemde ernstige verstoring van kritieke infrastructuur. Deze termijnen staan naast plichten om bij de relevante trigger onmiddellijk te melden. Ze geven een gebruiksverantwoordelijke geen toestemming om met een melding onder artikel 26 te wachten.
Het materiaal van de Commissie over incidentmeldingen omvat conceptrichtlijnen. Baseer de incidentprocedure op de wettelijke triggers en controleer de status van richtlijnen voordat je erop vertrouwt.
Spreek vóór de lancering af wie een waarschuwing ontvangt, wie het systeem kan opschorten, hoe de aanbieder wordt bereikt en wie verplichte meldingen doet. Test die route. Logs kunnen vaststellen wat er gebeurde, maar nemen niet zelfstandig contact op met de juiste mensen.
Kan iemand vragen waarom AI een beslissing beïnvloedde?
Artikel 86 geeft getroffen personen onder bepaalde omstandigheden recht op een duidelijke en betekenisvolle uitleg. Het gaat om beslissingen op basis van output van high-risksystemen uit Bijlage III, behalve kritieke infrastructuur, met juridische of vergelijkbaar aanzienlijke gevolgen die volgens de persoon nadelig zijn voor gezondheid, veiligheid of grondrechten.
De uitleg moet de rol van het AI-systeem en de belangrijkste elementen van de beslissing omvatten. De bepaling kent uitzonderingen en geldt alleen voor zover dat recht niet al uit ander EU-recht volgt.
Artikel 86 is niet uitdrukkelijk opgenomen in het uitstel van Hoofdstuk III, Afdelingen 1 tot en met 3. Alleen op basis van die wijziging blijft de algemene datum van 2 augustus 2026 dus staan. Hoe de bepaling samenwerkt met uitgestelde classificatieregels en overgangsrecht moet per systeem worden beoordeeld. Neem niet aan dat de latere datum voor artikel 26 ook elke uitlegplicht uitstelt.
Bewaar operationeel de informatie die nodig is om de beslissing uit te leggen: relevante feiten, criteria, systeemoutput en menselijke betrokkenheid. Een technisch eventlog kan helpen dat bewijs te vinden, maar is niet vanzelf een betekenisvolle uitleg voor de getroffen persoon.
Wat moet de operationele vastlegging bevatten?
Neem één agentrol en vraag of iemand buiten het team uit jullie vastlegging het volgende kan vaststellen:
Wat aantoonbaar moet zijn
Eén agentrol · zes controles
- Doel en rollen.Waarvoor de agent wordt gebruikt, de classificatie en wie hem aanbiedt en inzet.
- Menselijke controle.Wie toezicht houdt, welke training die persoon kreeg en welke bevoegdheid er is om in te grijpen.
- De case.Wat in een specifieke case gebeurde, welke controles liepen en wat een mens goedkeurde of wijzigde.
- Informatie en beoordelingen.Welke vereist waren en of ze zijn afgerond.
- Incidenten.Wat gebeurde nadat een risico of incident werd ontdekt, inclusief opschorting en meldingen waar nodig.
- Wijzigingen.Wat veranderde in het systeem of doel en wat vóór inwerkingtreding is beoordeeld.
Dit is een operationele checklist, geen claim dat de wet één standaardbestand met alle zes onderdelen eist. Sommige records horen bij het agentplatform, andere bij de proceseigenaar of teams voor HR, privacy en legal.
Hier past het werk van Aitonomy. De Scan en ons team stellen het beoogde werk, de betrokken systemen en gaten in het bewijs vast. Waar classificatie of een gewijzigde juridische rol moet worden beoordeeld, bereiden we de technische en operationele informatie voor de klant en adviseurs voor.
In productie bewaart Aitonomy Control het operationele bewijs: agentactiviteit, goedkeuringen, controles en de historie van wijzigingen en supervision-beslissingen. Ons team gebruikt die vastlegging om problemen te onderzoeken en beslissingen voor te leggen aan de verantwoordelijke proceseigenaar. De supervision levels bepalen hoe bevoegdheid wordt verdiend en verlaagd. Ze ondersteunen menselijke controle, maar vervangen artikel 26 niet.
Control voert niet zelfstandig een effectbeoordeling uit, informeert geen werknemers en bepaalt niet of een configuratie iemand tot aanbieder maakt. Ook vereiste logs, toegang en bewaartermijnen moeten voor de daadwerkelijke inzet worden gecontroleerd. Wijs die verantwoordelijkheden toe; neem niet aan dat de aankoop van een platform ze afdekt.
Begin bij de agent die jullie al runnen of overwegen. Leg het doel en de rollen van partijen vast, bepaal welke plichten gelden en test of de verantwoordelijke mensen het bewijs kunnen vinden en erop kunnen handelen. Dat werk is al vóór een deadline nuttig, omdat het ook nodig is om een agent verantwoord in productie te runnen.
Veelgestelde vragen
Geldt de EU AI Act ook voor een organisatie die AI alleen gebruikt?+
Kan een organisatie zowel AI-aanbieder als gebruiksverantwoordelijke zijn?+
Zijn AI-agents automatisch high-risk onder de AI Act?+
Welke plichten voor gebruiksverantwoordelijken zijn uitgesteld?+
Hoelang moet een gebruiksverantwoordelijke AI-systeemlogs bewaren?+
Bronnen en reikwijdte
- Regulation (EU) 2024/1689, the Artificial Intelligence Act, as amended by Regulation (EU) 2026/1744.
- Council of the EU, adopted Digital Omnibus text, particularly the amendments to Articles 4, 25, 27, 111 and 113, and its adoption announcement.
- European Commission AI Act Service Desk, the article texts linked above. Some pages carry an explicit warning that they have not yet incorporated the Omnibus amendments; those passages must be read with the amending text.
- European Commission, AI literacy questions and answers and draft serious-incident reporting guidance.
- Sources checked 4 September 2026. This is an operational guide, not legal advice or an exhaustive compliance checklist. Application to a particular system depends on its purpose, the parties’ roles, transitional provisions and other applicable law. The interpretation of Article 86’s timing is identified separately above.