Een conform AI-model kopen ontslaat je niet van EU AI Act-plichten

Het kopen van een conform AI-model lost de EU AI Act-verantwoordelijkheden van een organisatie niet op. Meer bepalend is wat de organisatie rond dat model bouwt, welke beslissingen het systeem ondersteunt en of doelwijzigingen de organisatie in de providerrol brengen. EU AI Act-verplichtingen gelden voor specifieke systemen, toepassingen en operatorrollen, niet voor het gekochte model. Een verdedigbaar compliance-programma begint daarom met classificatie en verantwoordelijkheid, en koppelt documentatie-, toezicht-, transparantie- en beoordelingsplichten aan elke implementatie. Professionele gebruikers hebben ook wijzigingsbeheer nodig: een workflow die is goedgekeurd voor documentondersteuning kan een andere beoordeling vereisen bij hergebruik voor werving, geschiktheid of een andere ingrijpende beslissing. Verificatie kan een bewijsspoor ondersteunen, maar bepaalt niet de juridische classificatie en vervangt geen conformiteitsbeoordeling. Waar officiële implementatiematerialen tegenstrijdige data geven, is het verantwoord de onzekerheid vast te leggen en de wettekst te verifiëren voordat een kalender wordt goedgekeurd.

Welke EU AI Act-verplichtingen gelden voor elk risiconiveau?

De EU AI Act wordt gewoonlijk toegelicht aan de hand van vier risiconiveaus, met strengere controles voor toepassingen met een hoger risico, hoewel transparantieverplichtingen en verplichtingen voor modelproviders niet netjes in één enkele ladder passen.

EU AI Act-risiconiveaus en de belangrijkste verplichting voor elk

• Onaanvaardbaar risico, verboden — Typische voorbeelden: Social scoring door overheidsinstanties; manipulatie die kwetsbaarheden uitbuit, waar aan de wettelijke voorwaarden is voldaan; Belangrijkste vereiste: Verboden praktijken mogen niet worden ingezet
• Hoog risico, Annex III — Typische voorbeelden: Wervingsscreening; kredietwaardigheidsbeoordeling; toegang tot essentiële diensten; onderwijsbeoordeling; rechtshandhaving; migratie; Belangrijkste vereiste: Risicobeheer, datagovernance, technische documentatie, logging, menselijk toezicht, nauwkeurigheid, robuustheid en cyberbeveiliging
• Hoog risico, Annex I — Typische voorbeelden: AI als veiligheidscomponent van machines of medische hulpmiddelen, waar de relevante productbeoordelingsvoorwaarden van toepassing zijn; Belangrijkste vereiste: Kernvereisten voor hoog risico geïntegreerd met sectorale productwetgeving
• Beperkt risico, transparantie — Typische voorbeelden: Chatbots die met mensen interageren; synthetische audio, beeld, video of tekst; deepfakes; Belangrijkste vereiste: Bekendmaking aan gebruikers en machineleesbare markering waar van toepassing
• Minimaal risico — Typische voorbeelden: Spamfilters; AI in videogames; Belangrijkste vereiste: Geen conformiteitsregime voor hoog risico uitsluitend omdat AI wordt gebruikt; maatregelen voor AI-geletterdheid blijven relevant, met vrijwillige codes beschikbaar

De wettekst van de EU AI Act stelt de verboden praktijken, classificatieroutes voor hoog risico en specifieke transparantieverplichtingen vast die in deze vergelijking worden weergegeven. Deze labels zijn een handige verkorting, geen vervanging voor het controleren van de wettelijke voorwaarden en uitzonderingen.

Verboden en hoogrisicotoepassingen

Onaanvaardbaar risico betreft praktijken die de wetgeving verbiedt, in plaats van systemen die na aanvullende documentatie kunnen worden voortgezet. De reikwijdte is van belang: niet elke overtuigende interface vormt verboden manipulatie, en het verbod op social scoring is niet beperkt tot overheidsinstanties.

Classificatie als hoog risico kent verschillende routes. Een systeem kan onder een vermeld gebruiksgeval vallen, of in aanmerking komen via wetgeving voor gereguleerde producten. Niet elke toepassing die in een ziekenhuis wordt gebruikt is een medisch hulpmiddel met hoog risico, en niet elk administratief hulpmiddel dat door een werkgever wordt gebruikt vervult een werkgelegenheidsfunctie met hoog risico.

Transparantie en toepassingen met lager risico

Het label beperkt risico kan een belangrijk onderscheid verhullen: transparantie is een op triggers gebaseerde verplichting, niet noodzakelijkerwijs een exclusieve categorie. Een systeem met hoog risico kan ook rechtstreeks met mensen interageren of synthetische inhoud genereren.

Evenzo betekent minimaal risico niet de afwezigheid van governance. AI-geletterdheid en andere toepasselijke wetten kunnen relevant blijven, zelfs wanneer de vereisten voor hoog risico niet van toepassing zijn.

Voor besluitvormers zijn de praktische beginvragen concreet:

• Doel: Welke taak of beslissing voert het systeem uit?
• Context: In welke sector, en met welke gevolgen, wordt het gebruikt?
• Productrelatie: Is het een gereguleerd product of een veiligheidscomponent daarbinnen?

De onderliggende technologie alleen beantwoordt die vragen niet. Hetzelfde model kan materieel verschillende regelgevende uitkomsten ondersteunen.

Wanneer beginnen de EU AI Act-verplichtingen van toepassing te zijn?

De Act is in fasen van toepassing, dus een organisatie heeft een kalender per verplichting nodig, geen enkele compliance-deadline.

De implementatietijdlijn van de AI Act van de Commissie identificeert de onderstaande mijlpalen voor inwerkingtreding, geletterdheid, governance en standaard hoog risico. Een afzonderlijke pagina over het regelgevend kader van de Commissie geeft latere overgangsdata voor bepaalde systemen met hoog risico. De implementatiematerialen van de AI Act van de Commissie identificeren de onderstaande mijlpalen voor inwerkingtreding, geletterdheid, governance, transparantie en hoog risico. Huidige materialen van de Commissie stellen dat de regels voor hoog risico uit Annex III van toepassing zijn vanaf 2 december 2027 en de in producten ingebedde regels voor hoog risico uit Annex I vanaf 2 augustus 2028.

EU AI Act-toepassingsmijlpalen en verificatiestatus

• 1 augustus 2024 — Wat van toepassing wordt: De verordening treedt in werking; Verificatiestatus: Bevestigd in de aangehaalde materialen van de Commissie
• 2 februari 2025 — Wat van toepassing wordt: Verbodsbepalingen en de verplichting inzake AI-geletterdheid; Verificatiestatus: Bevestigd in de aangehaalde materialen van de Commissie
• 2 augustus 2025 — Wat van toepassing wordt: Governanceregels, sancties en verplichtingen voor aanbieders van AI-modellen voor algemene doeleinden; Verificatiestatus: Bevestigd in de aangehaalde materialen van de Commissie
• 2 augustus 2026 — Wat van toepassing wordt: Het merendeel van de resterende regels, waaronder de transparantieverplichtingen van artikel 50 en handhaving voor de toepasselijke bepalingen; Verificatiestatus: Bevestigd. De regels voor hoog risico uit bijlage III zijn gepland voor 2 december 2027. — Wat van toepassing wordt: Hoofdregels; eisen voor hoog risico uit bijlage III volgens het standaardtijdschema; Verificatiestatus: Tegenstrijdig tijdschema voor hoog risico; controleer aan de hand van de tekst in het Publicatieblad
• 2 augustus 2027 — Wat van toepassing wordt: Lidstaten moeten ten minste één AI-regelgevingssandbox operationeel hebben; Verificatiestatus: Bevestigd in het implementatietijdschema van de Commissie — Wat van toepassing wordt: Hoog-risico-AI die is ingebed in gereguleerde producten uit bijlage I; Verificatiestatus: Niet-geverifieerde plandatum omdat de materialen van de Commissie tegenstrijdig zijn
• 2 december 2027 — Wat van toepassing wordt: Overgangsdatum voor bepaalde gebruiksgevallen uit bijlage III in de tweede weergave van de Commissie; Verificatiestatus: Tegenstrijdig; controleer juridische status en reikwijdte
• 2 augustus 2028 — Wat van toepassing wordt: Overgang voor veiligheidscomponenten van producten die onder productveiligheidswetgeving vallen in de tweede weergave van de Commissie; Verificatiestatus: Tegenstrijdig; controleer juridische status en reikwijdte

Behandel tegenstrijdige data als een onopgeloste controle

De tabel maakt onderscheid tussen de algemene toepassingsdatum van 2 augustus 2026 en de latere data voor hoog-risicosystemen uit bijlage III en bijlage I. Teams moeten nog steeds de operatieve tekst in het Publicatieblad en de overgangsbepalingen controleren voor het specifieke systeem en de feitelijke implementatie. Het stelt niet vast dat een voorgestelde of gerapporteerde verlenging toepasselijk recht is geworden.

Een planningsteam moet de operatieve tekst in het Publicatieblad, relevante wijzigingen en overgangsbepalingen controleren voordat het op een verlenging vertrouwt. Waar een werkelijk systeemspecifiek juridisch vraagstuk onopgelost blijft, markeer de betreffende deadline als niet-geverifieerd, wijs een eigenaar aan en leg de volgende evaluatie vast.

Planningsregel: Een betwiste deadline is een reden om het implementatiewerk te behouden, niet om het op te schorten.

Leg voor elk systeem de verplichting, de verantwoordelijke operator, de juridische bron, de toepasselijke overgang en de interne gereedheidsdatum vast. De classificatie bepaalt welke agenda-items ertoe doen; het neemt niet de noodzaak weg om uitzonderingen of bepalingen voor bestaande systemen te onderzoeken.

Hoe classificeert u een AI-systeem onder de EU AI Act?

Classificeer de geïmplementeerde functie en het beoogde doel en leg vervolgens de redenen voor de uitkomst vast. Een label van verificatie of beslissingsondersteuning maakt een ingrijpende workflow niet automatisch laag-risico.

De classificatie- en hoog-risicobepalingen van de verordening ondersteunen een doelgerichte beoordeling, met inbegrip van het onderzoek van genoemde toepassingen, verantwoordelijkheden van operators en relevante documentatie.

1. Formuleer het beoogde doel in één zin. Benoem wie het systeem gebruikt, welke gegevens erbij betrokken zijn en welke taak of beslissing wordt ondersteund. Dit bepaalt de grens waartegen latere wijzigingen kunnen worden beoordeeld.

1. Screen op verboden praktijken. Vergelijk de werkelijke functie met de wettelijke voorwaarden, niet alleen met de omschrijving van de leverancier. Als het voorgestelde gebruik onder een verbod valt, maken gewone hoog-risicomaatregelen het niet geoorloofd.

1. Vergelijk het doel met de genoemde hoog-risicocontexten. Onderzoek biometrie, kritieke infrastructuur, onderwijs, werkgelegenheid, essentiële diensten, rechtshandhaving, migratie en justitie. Controleer relevante uitzonderingen en kwalificaties in plaats van een sectorlabel als doorslaggevend te beschouwen.

1. Controleer de route via gereguleerde producten. Bepaal of het systeem zelf een gedekt product of een veiligheidscomponent is, en of aan de vereiste voorwaarden voor productbeoordeling is voldaan.

1. Identificeer de rol van de organisatie. Leg de status van aanbieder, deployer, importeur of distributeur vast, met inbegrip van de vraag of wijziging of herbestemming die positie verandert. Contractterminologie alleen is geen toereikende classificatiemethode.

1. Breng transparantietriggers in kaart. Identificeer directe interactie, synthetische content, emotieherkenning en biometrische categorisering waar relevant. Deze verplichtingen vereisen een afzonderlijke controle, zelfs wanneer het systeem niet hoog-risico is.

1. Bewaar de classificatiebeslissing en de onderbouwende redenen. Neem de systeemgrens, aannames, uitsluitingen, degene die goedkeurt en de evaluatietrigger op. Waar een systeem met een genoemd gebruik onder de relevante uitzondering als niet-hoog-risico wordt beoordeeld, bewaar de vereiste rechtvaardiging voor toetsing door de autoriteit.

De volgende afbeelding ondersteunt de eerste inventarisatie- en classificatiebespreking.

Toets de beslissing verderop in het proces

Denk aan een tool die de redenering achter aanbevelingen voor uitkeringsgerechtigdheid controleert. De verificatiefunctie ervan beslecht niet de classificatie van de volledige workflow voor gerechtigdheid.

Een nuttige interne toets is of het team een beknopt classificatieformulier kan opstellen dat door de onderliggende analyse wordt onderbouwd. Een kort document kan een beslissing toetsbaar maken; beknoptheid alleen maakt het niet verdedigbaar.

Welke verplichtingen rusten op aanbieders, deployers en wijzigers?

De rol ligt niet vast door aankoop. Onder artikel 25 van de AI Act kan een distributeur, importeur, deployer of andere derde partij de aanbieder van een hoog-risicosysteem worden door rebranding, substantiële wijziging of een verandering van het beoogde doel die het systeem hoog-risico maakt.

Een aanbieder ontwikkelt een systeem, laat het ontwikkelen, of brengt het onder eigen naam op de markt of neemt het in gebruik onder de relevante voorwaarden. Een deployer gebruikt een systeem onder zijn gezag. Importeurs en distributeurs vervullen rollen in de toeleveringsketen, maar die omschrijvingen beschermen hen niet tegen een latere rolwijziging.

Hoe een rolverschuiving eruitziet

• Inzet bij advocatenkantoor: Een kantoor gebruikt een model om documenten samen te vatten en configureert vervolgens een workflow voor triage van aanspraakgerechtigdheid. Het nieuwe doel rechtvaardigt een nieuwe beoordeling; routinematige documentondersteuning en ingrijpende beoordeling van aanspraakgerechtigdheid zijn niet uitwisselbaar.
• Klinische aanpassing: Een kliniek zet een triagetool opnieuw in voor een andere patiëntengroep. De relevante vragen betreffen het toegestane doel, de oorspronkelijke beoordeling en het effect van de wijziging, en niet of medewerkers het configuratie noemen.
• Integratie in de publieke sector: Een overheidsinstantie finetunet een model en integreert het in beslissingen over uitkeringen. De verantwoordelijkheden ervan vereisen onderzoek op systeemniveau, inclusief de workflow die het in gebruik neemt.
• Rebranding in de toeleveringsketen: Een distributeur brengt een hoogrisicosysteem onder zijn eigen naam op de markt. Commerciële presentatie kan daarom de regelgevende verantwoordelijkheid beïnvloeden.

Niet elke retrieval-augmented prompt, workflow-integratie of gecontroleerde bewerking vormt een substantiële wijziging. Het antwoord hangt af van de juridische toets, de oorspronkelijke beoordeling en de feiten; de interpretatie door de bevoegde autoriteit kan ook van invloed zijn op de uitvoering.

Geletterdheid hoort thuis in het operationele model

De AI-geletterdheidsrichtlijnen van de Commissie gaan over maatregelen door aanbieders en gebruiksverantwoordelijken voor medewerkers en anderen die namens hen AI bedienen. Dat is niet hetzelfde als het opleggen van een identieke opleidingsverplichting aan elke actor in de toeleveringsketen.

Een verdedigbaar programma koppelt rolgebaseerde training aan toegestane toepassingen, verificatiestappen, vertrouwelijkheid, onzekerheid en escalatie. Een cursuscertificaat alleen toont niet aan dat die beheersmaatregelen werken.

In onze analyse is de sterkste waarborg tegen een onopgemerkte rolverschuiving een change-control-dossier dat naast het classificatiedossier wordt bijgehouden.

Dat dossier zou het oorspronkelijke doel, elke wijziging, validatieresultaten, menselijke beheersmaatregelen en het besluit om de wijziging goed te keuren of te escaleren moeten vastleggen.

Wat moeten hoogrisicosystemen documenteren en bewaren?

Hoogrisicodocumentatie zou elke wettelijke eis moeten koppelen aan bewijs dat een met naam genoemde persoon kan produceren en toelichten.

Hoogrisico-eisen en de te bewaren dossiers

• Risicomanagementsysteem — Artikel: Artikel 9; Wat te bewaren in het dossier: Risico-identificatie, mitigatiemaatregelen en besluiten over restrisico's gedurende de levenscyclus
• Datagovernance — Artikel: Artikel 10; Wat te bewaren in het dossier: Herkomst, voorbereiding, geschiktheid van data, onderzoek op bias en vastgestelde beperkingen
• Technische documentatie — Artikel: Artikel 11 en Bijlage IV; Wat te bewaren in het dossier: Systeembeschrijving, ontwerpkeuzes, beoogd doel en prestatiemetrieken
• Registratie en logs — Artikel: Artikel 12; Wat te bewaren in het dossier: Automatische logs die traceerbaarheid en monitoring ondersteunen
• Transparantie naar gebruiksverantwoordelijken — Artikel: Artikel 13; Wat te bewaren in het dossier: Gebruiksinstructies, nauwkeurigheidsinformatie en bekende beperkingen
• Menselijk toezicht — Artikel: Artikel 14; Wat te bewaren in het dossier: Maatregelen die mensen in staat stellen het systeem te begrijpen, te overrulen of te stoppen
• Nauwkeurigheid, robuustheid en cyberbeveiliging — Artikel: Artikel 15; Wat te bewaren in het dossier: Testresultaten, prestatiegrenzen en veerkrachtmaatregelen
• Kwaliteitsmanagementsysteem — Artikel: Artikel 17; Wat te bewaren in het dossier: Schriftelijke beleidslijnen, procedures en verantwoordelijkheidstoewijzingen
• Bewaring van documentatie en logs — Artikel: Artikelen 18 en 19; Wat te bewaren in het dossier: Vereiste documentatie en conformiteitsdossiers; door de aanbieder beheerde logs volgens de toepasselijke bewaarregels

De documentatie- en bewaarbepalingen van de AI Act vereisen dat aanbieders gespecificeerde documentatie, waaronder de technische documentatie en de EU-conformiteitsverklaring, 10 jaar bewaren na het in de handel brengen of in gebruik nemen, en door de aanbieder beheerde automatische logs gedurende een passende periode van ten minste zes maanden, tenzij het toepasselijke recht anders bepaalt.

Bouw dossiers die verbanden leggen

Wijs elke beheersmaatregel een met naam genoemde eigenaar, versie en datum toe. Koppel voor risicomanagement een gevaar aan de mitigatie- en validatieresultaten ervan; verbind voor toezicht de schriftelijke procedure aan een beschikbaar interventiemechanisme en bewijs van het gebruik ervan.

Datagovernance-dossiers zouden relevante voorbereidingskeuzes en beperkingen moeten toelichten, in plaats van slechts datasets op te sommen. Technische documentatie zou een beoordelaar in staat moeten stellen het systeem te begrijpen zonder het ontwerp te reconstrueren uit verspreide berichten.

Voor ingrijpende runs kan een praktisch bewijsspoor onveranderbare run-identificaties, metadata over modelversie en prompt, opgehaalde bronnen, uitkomsten van beoordelaars, correcties, meningsverschillen, toegangslogs en incidentregistraties omvatten. Pas toegangs- en bewaarmaatregelen toe op het spoor zelf, aangezien logs vertrouwelijk materiaal kunnen bevatten.

De operationele overwegingen voor hoogrisico-AI die vertrouwelijke documenten verwerkt zijn bijzonder relevant waar volledigheid van bewijs en beperkte toegang naast elkaar moeten bestaan.

Houd contract- en agentregisters bij

Onze bewijslijn voor AI-contracten is een contractregister waarin elk AI-contract, de eigenaar ervan, de uitgewisselde rechten, beschikbare logs en toegang, hiaten en een hersteldeadline worden vermeld.

Onze bewijslijn voor AI-agents is een agentregister waarin de identiteit van elke agent, de eigenaar, de toegestane reikwijdte, de goedkeurder en de locatie van de logs worden vermeld.

Dit zijn werkende governancestructuren, geen vervanging voor de vereiste technische documentatie. Ze helpen een praktisch probleem bloot te leggen: een organisatie kan traceerbaarheid beloven terwijl zij contractuele toegang mist tot de dossiers die nodig zijn om dit aan te tonen.

De doorslaggevende toets is of het dossier aantoont dat beheersmaatregelen werken zoals ontworpen, inclusief tekortkomingen, interventies en correcties, in plaats van slechts aan te tonen dat beleidslijnen zijn goedgekeurd.

Welke route voor conformiteitsbeoordeling is op uw systeem van toepassing?

De beoordelingsroute volgt de wettelijke categorie en productcontext van het systeem, niet het door de organisatie geprefereerde certificeringsproces.

Routes voor conformiteitsbeoordeling vergeleken

• Interne controle onder bijlage VI — Doorgaans van toepassing op: De meeste op zichzelf staande AI-systemen met een hoog risico uit bijlage III, onderworpen aan de toepasselijke categoriespecifieke regels; Wie beoordeelt: Aanbieder met behulp van zijn kwaliteitsmanagementsysteem en technische documentatie; Resultaat: EU-conformiteitsverklaring en CE-markering
• Beoordeling door aangemelde instantie onder bijlage VII — Doorgaans van toepassing op: Relevante biometrische systemen waarbij toepasselijke normen of specificaties niet worden gebruikt, niet volledig worden toegepast, of waarbij de wettelijke voorwaarden dit anderszins vereisen; Wie beoordeelt: Aangewezen externe aangemelde instantie; Resultaat: Certificaat, gevolgd door de toepasselijke verklaring en CE-markering
• Sectorale productroute onder bijlage I — Doorgaans van toepassing op: Kwalificerende AI met een hoog risico binnen gereguleerde producten, zoals machines of medische hulpmiddelen; Wie beoordeelt: De door de productwetgeving vereiste beoordelingsdeelnemers; Resultaat: Beoordeling onder het productregime waarin de AI Act-vereisten zijn geïntegreerd
• Systemen zonder hoog risico — Doorgaans van toepassing op: Systemen buiten de classificatie met een hoog risico; Wie beoordeelt: Geen AI Act-conformiteitsbeoordeling voor hoog risico; Resultaat: Toepasselijke transparantie- en andere verplichtingen blijven bestaan

Interne controle betekent geen afwezigheid van beoordeling

Voor de meeste op zichzelf staande toepassingen met een hoog risico draait de route van de aanbieder om zijn eigen gedocumenteerde beoordeling. Dat vereist nog steeds een samenhangend technisch dossier, een functionerend kwaliteitsmanagement en bewijs dat aan de toepasselijke vereisten is voldaan.

Een interne goedkeuringsvergadering staat niet gelijk aan een conformiteitsbeoordeling. De verantwoordelijke ondertekenaar heeft een basis nodig voor de verklaring, inclusief onopgeloste beperkingen en de relatie tussen tests, controles en beoogd gebruik.

De biometrische route vereist bijzondere zorg. Biometrische identificatie op afstand kan betrokkenheid van een aangemelde instantie vereisen wanneer de relevante geharmoniseerde normen of gemeenschappelijke specificaties niet of niet volledig worden toegepast; een generieke aanname van interne controle is daarom onveilig.

Controleer normen en aanwijzing

Geharmoniseerde normen die in het Publicatieblad zijn gepubliceerd, kunnen een vermoeden van conformiteit ondersteunen uitsluitend voor de vereisten die zij dekken. Teams zouden elke aangehaalde norm aan specifieke vereisten moeten koppelen en de toepasselijke status ervan moeten verifiëren.

ISO/IEC 42001 is een managementsysteemnorm. Certificering daartegen stelt op zichzelf geen conformiteit met de systeemspecifieke vereisten van de AI Act vast.

Beoordelingsvraag: Welk bewijs rechtvaardigt de verklaring voor dit systeem, deze versie en dit beoogde doel?

Stel voordat u de route goedkeurt vast wie de verklaring ondertekent, of een aangemelde instantie nodig is en welke normen onopgelost blijven. Coördineer die beslissing voor gereguleerde producten met het productconformiteitsteam in plaats van een afzonderlijke, losstaande AI-goedkeuring te creëren.

Welke transparantie- en GPAI-verplichtingen gelden voor modellen van derden?

Systeemtransparantie en upstream modelverplichtingen zijn afzonderlijke verantwoordelijkheden. Het koppelen van een model van een derde partij aan de workflow van een organisatie draagt niet alle verantwoordelijkheid over aan de modelaanbieder.

Een beleidsevaluatie zou zowel de interface die mensen tegenkomen als de upstream documentatie die voor de organisatie beschikbaar is moeten onderzoeken.

De AI Act maakt onderscheid tussen het informeren van mensen dat zij met AI interacteren, machineleesbare markering van synthetische output, en openbaarmakingen door gebruiksverantwoordelijken voor gespecificeerde gegenereerde of gemanipuleerde inhoud. Een label op het scherm en technische outputmarkering vervullen verschillende functies; men mag niet aannemen dat het ene het andere vervangt.

Verkrijg het upstream bewijs

De verplichtingen voor aanbieders van AI-modellen voor algemene doeleinden betreffen technische documentatie, downstream informatie, auteursrechtbeleid en een openbare samenvatting van de trainingsinhoud. Modellen met een systeemrisico brengen aanvullende verplichtingen met zich mee op het gebied van evaluatie, risicobeoordeling, risicobeperking en cyberbeveiliging.

Voor inkoop en integratie omvat een verdedigbaar documentatiepakket:

• Modelidentiteit: Aanbieder, modelversie en wijzigingen die relevant zijn voor de implementatie.
• Toegestaan gebruik: Gebruiksbeperkingen en informatie die nodig is voor downstream implementatie.
• Operationele samenwerking: Toezeggingen omtrent incidentmelding en beschikbaar beveiligings- of evaluatiebewijs.
• Bekende hiaten: Ontbrekende documenten, ontoegankelijke testinformatie en contractuele beperkingen op bijstand.

Externe modelroutering kan ontvangers buiten de Europese Economische Ruimte betreffen, dus onze aanbieder- en klantafspraken hebben een toepasselijk doorgiftemechanisme nodig waar hoofdstuk V van de GDPR van toepassing is.

Documenteer voor een implementatiebeoordeling wat elke ontvanger ontvangt, in plaats van aan te nemen dat getransformeerde context elke privacyvraag wegneemt. De bespreking van AI Act-transparantie en Digital Omnibus-ontwikkelingen vereist ook een zorgvuldige scheiding van vastgestelde vereisten en onopgeloste wijzigingen.

De bijbehorende video kan naast de schriftelijke beleidsevaluatie worden bekeken.

Verwar overeenstemming niet met conformiteit

Het vergelijken van output van onafhankelijke modellen kan professionele evaluatie ondersteunen. Overeenstemming tussen meerdere modellen is geen conformiteitsbeoordeling, levert geen ontbrekende aanbiederdocumentatie op en stelt niet vast dat een antwoord juist is.

De inkoopvraag is daarom specifiek: wat heeft elke upstream aanbieder gedocumenteerd, wat kan de organisatie verifiëren, en wat blijft onbekend?

Wat zijn de boetes voor overtreding van de EU AI Act?

Voor ondernemingen kunnen overtredingen van de regels inzake verboden praktijken boetes opleveren van EUR 35 miljoen of 7% van de totale wereldwijde jaaromzet over het voorgaande boekjaar, afhankelijk van welk bedrag hoger is, onder de sanctiebepalingen van de AI Act.

Dezelfde bepalingen stellen andere plafonds vast:

• EUR 15 miljoen of 3%: Maximale blootstelling voor gespecificeerde andere inbreuken.
• EUR 7,5 miljoen of 1%: Maximale blootstelling voor het verstrekken van onjuiste, onvolledige of misleidende informatie aan autoriteiten of aangemelde instanties.

Dit zijn maximale plafonds, geen automatische sancties. De toepasselijke berekening weerspiegelt ook de behandeling door de Verordening van kleine en middelgrote ondernemingen, waaronder start-ups; de formulering met het hoogste bedrag zou niet zonder onderscheid op hen mogen worden toegepast.

De infographic vat het belangrijkste plafond voor verboden praktijken voor ondernemingen samen, onderworpen aan die wettelijke voorbehouden.

Lees blootstelling via de daadwerkelijke verplichting

Nationale bevoegde autoriteiten maken deel uit van het handhavingskader, terwijl het AI Office van de Commissie verantwoordelijkheden heeft met betrekking tot general-purpose AI-modellen. Bij de vaststelling van sancties worden factoren meegewogen zoals de aard, ernst en duur van de inbreuk en de medewerking met autoriteiten.

Verkeerde classificatie, ontbrekende registraties, ineffectief toezicht en misleidende indieningen leveren verschillende juridische vragen op. Ze zouden niet allemaal moeten worden omschreven als vallend onder het maximumbedrag uit de kop.

Het onderscheid tussen systeemovertredingen en sancties die aanbieders van GPAI-modellen treffen is van belang voor de rapportage aan het bestuur. De leiding zou de relevante verplichting, de verantwoordelijke entiteit en de potentiële omzetblootstelling moeten identificeren, in plaats van aan elk AI-risico één enkel boetebedrag te koppelen.

Hoe ziet een compliancechecklist er in de praktijk uit?

Voer een gedocumenteerde releasechecklist uit vóór de ingebruikname en telkens wanneer het doel, het model of een materiële workflow verandert. Beschouw dit als een aanbevolen beheersingskader, niet als een verklaring dat elk item voor elk systeem een identieke wettelijke verplichting is.

1. Wijs eigenaarschap toe. Benoem de verantwoordelijke systeemeigenaar en de goedkeurende functie.
2. Leg het beoogde doel en de toegestane grenzen vast.
3. Voltooi de screening op verboden praktijken en de relevante Annex-controles.
4. Bevestig de operatorstatus, inclusief een eventuele aanbiedersverschuiving door wijzigingen.
5. Keur transparantietriggers en de bijbehorende openbaarmakingstekst goed.
6. Archiveer documentatie van upstream-aanbieders, modelidentiteit, beperkingen en incidenttoezeggingen.
7. Leg beslissingen over risicobeheer en datagovernance vast met versie en datum.
8. Bevestig de technische documentatie, het ontwerp van de logging en de toepasselijke bewaring.
9. Bepaal wie beoordeelt, wie kan ingrijpen en wie ingrijpende outputs goedkeurt.
10. Vereis passende menselijke beoordeling voordat erop wordt vertrouwd, gearchiveerd of extern verzonden. Gebruikers behouden hun professionele oordeel en de eindbeslissing, en zouden de output moeten beoordelen voordat zij erop vertrouwen, ernaar handelen, deze archiveren of naar een derde sturen.
11. Houd rolspecifieke registraties van AI-geletterdheid bij.
12. Onderhoud een incident- en correctielogboek met een escalatieroute.
13. Identificeer waar van toepassing de conformiteitsroute en de eigenaar van de verklaring.
14. Stel een datum voor herclassificatiebeoordeling en wijzigingstriggers vast.

De visual biedt een compacte samenvatting van de release-gate.

Pas de checklist toe op de workflow

Voor klantondersteuningsimplementaties kunnen de inzichten van SupportGPT-1 over het bouwen van supportagents implementatiecontext bieden, maar ze vormen geen gezaghebbende bron voor professionele of regelgevende verplichtingen in de EU.

Volgens onze analyse verdient upstream-documentatie een expliciete release-gate, omdat het downstream-team anders een workflow kan goedkeuren zonder over de informatie te beschikken die nodig is om deze te beoordelen. Dat is een risicogebaseerde aanbeveling, geen gemeten bewering over welke omissie het vaakst voorkomt.

De checklist ondersteunt de beoordeling. Hij vervangt geen juridisch advies over de specifieke feiten van de implementatie.

Welke beslissing zou uw team eerst moeten nemen?

De eerste beslissing is of elk systeem binnen het toepassingsgebied valt, hoe het is geclassificeerd en wie eigenaar is van die conclusie. De leiding kan vervolgens de beoordelingsroute en het implementatieplan goedkeuren aan de hand van geverifieerde wettelijke vereisten.

De meest bruikbare indiening bij het bestuur is niet een algemene verklaring dat de organisatie compliant AI gebruikt. Het is een systeemregister dat wordt ondersteund door onderbouwde beslissingen en toegankelijk bewijs.

Vraag om beslissingen die kunnen worden beoordeeld

• Classificatiegoedkeuring: Welke systemen zijn kandidaten voor hoog risico, wie heeft elke conclusie goedgekeurd en welke aannames zouden deze kunnen veranderen?
• Verantwoordelijkheidstoewijzing: Welke entiteit draagt de verplichtingen van aanbieder of gebruiksverantwoordelijke, en welke wijzigingen vereisen escalatie?
• Beoordelingsgoedkeuring: Welke conformiteitsroute is van toepassing, wie ondertekent de verklaring en welke externe beoordeling is nodig?
• Gereedheidsgoedkeuring: Welke documentatie- en toezichtmaatregelen zijn operationeel, en welke blijven onvolledig?
• Deadlinezekerheid: Wat is de bron voor de ingangsdatum van elke verplichting, en welke overgangen blijven ongeverifieerd?
• Toegang tot bewijs: Kan de organisatie upstream-documentatie en het bewijsspoor voor ingrijpende outputs overleggen?

Het onderliggende governance-inzicht is dat classificatie en wijzigingsbeheer bij elkaar horen. Een zorgvuldig beoordeeld systeem kan een andere compliance-propositie worden wanneer het doel ervan verandert, zelfs als inkoop geen nieuw model heeft aangeschaft.

Het ondersteunt beoordeling en controle voor professionals die werken waar nauwkeurigheid, vertrouwelijkheid en verantwoording van belang zijn, waaronder juridische teams, notarissen, zorginstellingen, journalisten, onderzoekers, complianceteams en beveiligingsgevoelige organisaties.

Verificatie garandeert geen juistheid, bepaalt niet de juridische classificatie en vervangt geen juridisch advies. Waar data of normen onzeker blijven, behoud de tegenstrijdige standpunten, benoem de persoon die verantwoordelijk is voor de oplossing en stel de volgende beoordeling vast.

Meer artikelen over dit onderwerp zijn gebundeld in het overzicht EU AI Act en compliance.

Bronnen: Risiconiveaus, verboden praktijken, routes voor hoog risico en transparantieplichten zijn ontleend aan de juridische tekst van de EU AI Act op EUR-Lex; toepassingsmijlpalen komen uit de implementatietijdlijn van de Commissie en haar pagina over het regelgevingskader, die op bepaalde data voor hoog risico tegenstrijdig zijn; rollen in de waardeketen verwijzen naar Article 25.