Zo beoordeel je of Europese AI-software aan de EU AI-verordening voldoet

De EU AI-verordening is geen productcertificeringsregeling die een tool na een eenmalige beoordeling als "conform" bestempelt. Het is een horizontaal regelgevingskader dat van toepassing is op alle sectoren en verplichtingen oplegt op basis van wat een systeem doet en hoe het wordt gebruikt – ongeacht het marketinglabel of de productcategorie.

Juridisch gezien wordt een "AI-systeem" functioneel gedefinieerd: het is een machinegebaseerd systeem dat is ontworpen om met verschillende niveaus van autonomie te werken en om op basis van input af te leiden hoe outputs zoals voorspellingen, content, aanbevelingen of beslissingen gegenereerd moeten worden. Conventionele software die slechts door mensen gespecificeerde regels uitvoert, valt niet onder deze definitie, simpelweg omdat het scores berekent of automatisering uitvoert. Waar het om gaat, is hoe het systeem daadwerkelijk werkt – het marketinglabel "AI-gestuurd" is irrelevant voor de classificatie.

De wet wordt vaak uitgelegd aan de hand van een risicomodel met vier niveaus, hoewel deze categorieën niet alle regelgevende aspecten van de wetgeving volledig weergeven:

1. Onacceptabel risico – Praktijken die ronduit verboden zijn, waaronder bepaalde vormen van sociale scoring en biometrische categorisatie op basis van bijzonder gevoelige kenmerken.
2. Hoog risico – In het bijzonder systemen die worden gebruikt in bepaalde gebieden die worden vermeld in Bijlage III, En ook AI-systemen die fungeren als veiligheidscomponenten van producten die onder specifieke EU-productwetgeving vallen. Deze systemen zijn onderworpen aan de meest uitgebreide documentatie- en conformiteitseisen.
3. Beperkt risico Bepaalde systemen, zoals chatbots, zijn primair onderworpen aan transparantieverplichtingen jegens eindgebruikers. Systemen voor emotieherkenning kunnen ook onderworpen zijn aan transparantievereisten, hoewel het gebruik ervan in bepaalde contexten, waaronder werkplekken en onderwijsinstellingen, over het algemeen verboden is.
4. Minimaal risico De meeste alledaagse AI-toepassingen vallen in deze categorie, waaronder veel interne analysetools en standaard SaaS-automatiseringen. Ze zijn niet onderworpen aan de uitgebreide eisen die gelden voor systemen met een hoog risico. Algemene verplichtingen, zoals maatregelen met betrekking tot AI-geletterdheid, kunnen echter nog steeds relevant zijn voor leveranciers en implementeerders.

De wet maakt ook onderscheid tussen verschillende rollen voor operators met verschillende verantwoordelijkheden, waaronder de provider (die een AI-systeem ontwikkelt, of er een laat ontwikkelen, en het onder eigen naam op de markt brengt), de implementeerder (waarbij een AI-systeem in een professionele context wordt gebruikt), evenals importeurs, distributeurs en geautoriseerde vertegenwoordigers. Een bedrijf kan meerdere rollen tegelijk vervullen – bijvoorbeeld als het een AI-functie ontwikkelt en deze ook intern gebruikt.

Hoe bepaalt een bedrijf of zijn software als AI met een hoog risico geldt?

De classificatie als hoog risico hangt voornamelijk af van het beoogde doel van een systeem en de context waarin het wordt gebruikt – niet van de vraag of het gebruikmaakt van machine learning of dat de term 'AI' in de productbeschrijving voorkomt.

In principe moeten twee afzonderlijke routes worden overwogen. Ten eerste kan een AI-systeem als hoog risico worden beschouwd als het een veiligheidscomponent is van een product dat onder een bepaalde regelgeving valt. Bijlage I, of als het AI-systeem zelf een dergelijk gereguleerd product is. Ten tweede, bepaalde beoogde toepassingen die worden vermeld in Bijlage III kan resulteren in een classificatie als hoog risico.

Bijlage III omvat gebieden zoals biometrische systemen, het beheer van kritieke infrastructuur, onderwijs en beroepsopleiding, werkgelegenheid en personeelsbeheer (inclusief werving, promotie en ontslag), toegang tot essentiële particuliere en openbare diensten, waaronder bepaalde kredietwaardigheidsbeoordelingen, wetshandhaving, migratie en grenscontrole, evenals de rechtspleging en democratische processen.

Een gebruiksscenario dat in bijlage III is opgenomen, wordt echter niet automatisch in alle omstandigheden als een hoog risico beschouwd. Onder bepaalde voorwaarden kan een systeem worden vrijgesteld als het geen significant risico vormt voor de gezondheid, veiligheid of fundamentele rechten van natuurlijke personen. Systemen die profielen van natuurlijke personen opstellen, zijn in dit opzicht onderworpen aan strengere regels.

Een veelvoorkomende misvatting is dat elk B2B SaaS-product met een ingebouwde AI-functie automatisch een hoog risico vormt. Dat is niet het geval. De classificatie hangt af van de specifieke functie binnen het product, niet van de algehele productcategorie. Een CRM-systeem met AI-gebaseerde leadscoring is bijvoorbeeld niet automatisch een hoog risico, tenzij die scoring wordt gebruikt in een gereguleerde context om beslissingen te nemen die natuurlijke personen aangaan.

Een praktisch classificatieproces zou er als volgt uit kunnen zien:

• Stap 1 – Beoordeel de functie, niet het product. Identificeer het specifieke kenmerk dat een op inferentie gebaseerde taak uitvoert en beschrijf de output en de potentiële impact ervan op natuurlijke personen.
• Stap 2 – Controleer beide risicovolle routes. Bepaal eerst of het systeem binnen de productgerelateerde regels van bijlage I valt en beoordeel vervolgens of het beoogde doel overeenkomt met een categorie die in bijlage III is opgenomen.
• Stap 3 – Overweeg mogelijke uitzonderingen. Bepaal voor systemen die onder Bijlage III vallen of de voorwaarden voor een vrijstelling van de classificatie als hoog risico van toepassing kunnen zijn.
• Stap 4 – Documenteer de redenering. Een schriftelijke, gedateerde zelfevaluatie is een verstandige eerste stap en biedt een traceerbare basis voor toekomstige evaluaties.
• Stap 5 – Herbeoordeel na materiële wijzigingen. Als het beoogde doel, de functionaliteit of de implementatiecontext van het systeem aanzienlijk verandert, moet de classificatie ervan worden herzien.

Praktische voorbeelden zijn een SaaS-analysedashboard met een voorspellingsfunctie, dat doorgaans niet als hoog risico wordt beschouwd; een ingebed machine-learningmodel dat wordt gebruikt om de kredietwaardigheid van natuurlijke personen op een fintechplatform te beoordelen, wat wel als hoog risico kan worden beschouwd; en bepaalde AI-componenten die worden gebruikt in industriële besturingshardware, mits deze relevante veiligheidscomponenten vormen in de zin van de productveiligheidswetgeving waarnaar in de wet wordt verwezen.

Welke nalevingstermijnen gelden onder de EU AI-verordening?

De verplichtingen onder de EU AI-verordening treden gefaseerd in werking. De ingangsdatum hangt af van de specifieke vereisten en de rol van het betreffende bedrijf. Sinds de inwerkingtreding van de wet zijn sommige overgangsperioden aangepast.

De geldende termijnen variëren ook afhankelijk van de rol van de operator. Aanbieders hebben over het algemeen uitgebreidere verplichtingen, omdat zij verantwoordelijk zijn voor zaken als technische documentatie, conformiteit en systeemontwerp. Implementeerders daarentegen hebben operationele verantwoordelijkheden, zoals menselijk toezicht en monitoring waar dit nodig is voor het betreffende systeem. Importeurs en distributeurs zijn onderworpen aan hun eigen verificatie- en informatieverplichtingen.

Er kunnen speciale overgangsbepalingen gelden voor systemen en modellen die al in gebruik waren of op de markt waren voordat de relevante eisen van kracht werden. Teams moeten daarom beoordelen welke regels van toepassing zijn op hun specifieke bestaande producten. Naarmate het regelgevingskader verder wordt verduidelijkt door middel van richtlijnen en aanvullende maatregelen, moeten de huidige termijnen ook worden gecontroleerd aan de hand van het Officiële Journal van de Europese Unie of het portaal voor de digitale strategie van de Europese Commissie.

Welke documentatie moeten softwareleveranciers bijhouden voor naleving van de EU AI-verordening?

De documentatievereisten variëren aanzienlijk, afhankelijk van de risicoclassificatie van het systeem en de rol van de organisatie. Systemen met een hoog risico zijn onderworpen aan de meest uitgebreide vereisten. Voor systemen die voornamelijk onderworpen zijn aan transparantieverplichtingen, is de documentatielast aanzienlijk lichter.

Vereist voor aanbieders van systemen met een hoog risico:

• Technische documentatie conform bijlage IV, waarbij onderwerpen zoals systeemontwerp, beoogd doel, relevante gegevens en prestatiemaatstaven aan bod komen.
• Documenten met betrekking tot het risicomanagementsysteem, waarbij de geïdentificeerde risico's, de genomen maatregelen ter beperking van de risico's en de beslissingen met betrekking tot het resterende risico gedurende de gehele levenscyclus van het systeem worden gedocumenteerd.
• Documentatie over gegevensbeheer, waarbij trainings-, validatie- en testgegevens relevant zijn voor het systeem.
• Bepalingen inzake menselijk toezicht, waarbij wordt gedefinieerd hoe verantwoordelijke personen het systeem op passende wijze kunnen monitoren en waar nodig kunnen ingrijpen.
• Bewijsmateriaal met betrekking tot conformiteitsbeoordeling, inclusief de conformiteitsverklaring en, indien vereist, de betrokkenheid van een aangemelde instantie.

De doorlopende vereisten omvatten:

• Monitoring na de marktintroductie om de prestaties van het systeem te volgen en potentiële problemen na de implementatie te identificeren.
• Registraties van ernstige incidenten, waar overeenkomstige rapportageverplichtingen van toepassing zijn.
• Wijzigingslogboeken Het documenteren van materiële wijzigingen aan het model, het systeem of het beoogde doel.

Voor systemen die onderworpen zijn aan transparantieverplichtingen:

• Transparantieberichten, Bijvoorbeeld wanneer gebruikers moeten worden geïnformeerd dat ze met een AI-systeem communiceren.
• Afhankelijk van het systeem kunnen er aanvullende eisen gelden voor het labelen of detecteren van door AI gegenereerde of gemanipuleerde inhoud.

Software met een minimaal risico vereist over het algemeen niet de volledige technische documentatie zoals beschreven in Bijlage IV. Desondanks kan het nuttig zijn om intern een kort overzicht bij te houden van de redenen voor de classificatie. Bedrijven moeten ook beoordelen of meer algemene vereisten, zoals verplichtingen op het gebied van AI-kennis, van toepassing zijn op hun rol.

Aanbieders van algemene AI-modellen zijn onderworpen aan een apart regelgevings- en documentatieregime.

Geldt de EU AI-verordening ook voor softwareleveranciers buiten de EU?

De EU-wetgeving inzake kunstmatige intelligentie (AI) heeft ook een extraterritoriale werking. Een bedrijf hoeft geen juridische aanwezigheid in de EU te hebben om onder de wet te vallen. Relevante triggers kunnen zijn: het in de handel brengen van een AI-systeem of -model in de EU, het in gebruik nemen van een AI-systeem in de EU, of het gebruik binnen de EU van een output die door een systeem is gegenereerd.

Dit is grotendeels vergelijkbaar met de extraterritoriale logica van de AVG, hoewel geen van beide regimes gebaseerd is op het EU-burgerschap. Wat telt, zijn de territoriale aanknopingspunten zoals gedefinieerd in de betreffende wetgeving.

Voor SaaS-aanbieders in de VS of het VK betekent dit dat het aanbieden van een AI-systeem op de Europese markt ertoe kan leiden dat het bedrijf onder de wet valt, zelfs als het geen lokaal kantoor heeft. De precieze omvang van de verplichtingen hangt dan af van het type systeem, het beoogde gebruik en de rol van het bedrijf.

Aanbieders die buiten de EU gevestigd zijn, moeten over het algemeen een aanstellen geautoriseerde vertegenwoordiger binnen de EU voordat een AI-systeem met een hoog risico op de Europese markt wordt gebracht. Bepaalde niet-EU-aanbieders van GPAI-modellen zijn ook onderworpen aan vertegenwoordigingsvereisten. Aanbieders van andere soorten systemen zijn echter niet automatisch onderworpen aan een algemene verplichting om een EU-vertegenwoordiger aan te stellen.

Bedrijven die al een bedrijf hebben opgericht GDPR-nalevingskader – inclusief gedocumenteerde gegevensstromen, duidelijke verantwoordelijkheden en vastgestelde governanceprocessen – kan een structureel voordeel opleveren, omdat een aantal organisatorische vereisten elkaar overlappen.

Welke sancties gelden bij niet-naleving van de EU AI-verordening?

De sancties onder de EU AI-verordening zijn getrapt naar de ernst van de overtreding. De onderstaande bedragen zijn wettelijke maximumbedragen, geen automatische boetes.

• Schendingen met betrekking tot verboden AI-praktijken kan leiden tot boetes van maximaal €35 miljoen of 71.800 biljoen aan wereldwijde jaaromzet.
• Andere schendingen van verplichtingen onder de AI-verordening kan leiden tot boetes van maximaal €15 miljoen of 3% aan wereldwijde jaaromzet.
• Het verstrekken van onjuiste, onvolledige of misleidende informatie aan bevoegde autoriteiten. kan leiden tot boetes van maximaal €7,5 miljoen of 1% aan wereldwijde jaaromzet.
• Behandeling van het mkb: Voor kleine en middelgrote ondernemingen is het toepasselijke maximum doorgaans het laagste bedrag van het vaste bedrag en het percentage van de jaaromzet. Voor andere ondernemingen geldt over het algemeen het hogere bedrag.

De uiteindelijke sanctie hangt af van de aard, ernst, duur en andere omstandigheden van de specifieke overtreding. Aanbieders van algemene AI-modellen zijn bovendien onderworpen aan een apart handhavings- en sanctieregime.

Voor kleinere SaaS-aanbieders betekent dit echter niet dat compliance zomaar genegeerd kan worden. Een traceerbaar classificatieproces, duidelijk gedocumenteerde verantwoordelijkheden en passende monitoringprocedures kunnen helpen om regelgevingsrisico's vroegtijdig te identificeren en een verdedigbaar verslag te leveren van hoe compliancebeslissingen zijn genomen.

Zo pakken softwareteams naleving van de EU AI-verordening gestructureerd aan

De meest verstandige eerste stap voor een softwareleverancier is een gedocumenteerde en gedateerde zelfclassificatie van het AI-systeem – niet direct een certificeringsdienst van een derde partij aanschaffen of een abonnement op compliance-software nemen. Zowel de productgerelateerde route naar een classificatie als hoog risico als de categorieën in Bijlage III moeten worden beoordeeld.

Zelfs een korte interne memo waarin individuele productkenmerken en beoogde toepassingen worden gekoppeld aan de relevante wettelijke categorieën, kan een duidelijke en traceerbare basis vormen voor toekomstige evaluaties naarmate het product of de wettelijke richtlijnen zich ontwikkelen.

Classificatie, documentatie en het bijhouden van deadlines moeten als een terugkerend intern proces gekoppeld aan materiële productwijzigingen in plaats van als een eenmalig nalevingsproject met één deadline. Als het beoogde doel, de functionaliteit of de implementatiecontext van een systeem aanzienlijk verandert, moeten teams opnieuw beoordelen of de bestaande classificatie nog steeds geldig is.

Veelgestelde vragen

Leidt het gebruik van open-source AI-modellen tot extra aansprakelijkheid onder de AI-verordening?

Het integreren van een AI-model van een derde partij of een open-sourcemodel in een product ontslaat een organisatie niet automatisch van wettelijke verplichtingen. Een bedrijf kan nog steeds worden beschouwd als de leverancier van zijn eigen AI-systeem, zelfs als het onderliggende model van een derde partij zonder aanpassingen is geïntegreerd.

Tegelijkertijd bevat de AI-verordening specifieke bepalingen en in sommige gevallen uitzonderingen voor vrij gelicentieerde en open-source systemen en modellen. Deze uitzonderingen gelden niet onbeperkt, met name voor bepaalde risicovolle systemen of GPAI-modellen met systeemrisico. Aanbieders dienen daarom te documenteren welke componenten afkomstig zijn van derden en hun eigen rol binnen de AI-waardeketen te bepalen.

Wordt een chatbot automatisch als beperkt risico geclassificeerd?

Veel chatbots zijn in de eerste plaats onderworpen aan transparantievereisten en moeten gebruikers bijvoorbeeld laten weten dat ze met een AI-systeem communiceren.

Als een chatbot echter wordt gebruikt om beslissingen te nemen in een risicovolle context – zoals het beoordelen van sollicitanten of het bepalen van de toegang tot bepaalde publieke of private diensten – kan de onderliggende functie zelf als risicovol worden beschouwd. Wat er dus toe doet, is niet de chatinterface, maar het daadwerkelijke beoogde doel van het systeem.

Kan een bedrijf een AI-systeem met een hoog risico zelf certificeren zonder externe audit?

Een interne conformiteitsbeoordeling is mogelijk voor diverse risicovolle toepassingen. In bepaalde situaties – met name voor specifieke biometrische systemen of systemen die gekoppeld zijn aan gereguleerde producten – kunnen echter andere conformiteitsbeoordelingsprocedures of de tussenkomst van een aangemelde instantie vereist zijn.

De toepasselijke procedure hangt derhalve af van het specifieke systeem en de relevante regelgeving.

Hoe verhoudt de EU AI-verordening zich tot ISO 42001 en het NIST AI RMF?

ISO 42001 en het NIST AI Risk Management Framework zijn vrijwillige beheers- en risicobeheerskaders, terwijl de EU AI-verordening bindende wetgeving is met afdwingbare verplichtingen en sancties.

Organisaties die dergelijke beheersystemen al hebben geïmplementeerd, zullen vaak aanzienlijke overlappingen vinden op gebieden zoals risicobeheer, governance en documentatie. Dit kan de extra inspanning die nodig is voor naleving van de AI-verordening verminderen, maar het vervangt niet een beoordeling van de specifieke wettelijke vereisten.