ISO 42001 Annex A controls: complete uitwerking per categorie.
Annex A van ISO/IEC 42001:2023 bevat 38 controls in negen categorieën (A.2 tot en met A.10), waaruit je per organisatie selecteert welke van toepassing zijn en dat vastlegt in een Statement of Applicability. De controls vormen het operationele deel van een AI Management System; vijf van de negen categorieën overlappen sterk met AI Act-verplichtingen voor high-risk AI. Per control staan het doel, wat de standaard vraagt en een MKB-implementatie; onderaan volgen een mapping naar AI Act-artikelen en een prioriteitsmatrix voor MKB.
Dit is het uitgebreide referentiewerk bij onze ISO 42001 basisgids. Waar die gids de volledige standaard overzichtelijk maakt, gaat deze pagina de diepte in op elke Annex A control. Onderdeel van de AI compliance-aanpak van Prometheus21.
Leeswijzer: deze pagina is bewust zeer uitgebreid. Gebruik de categorie-secties als naslagwerk per Annex A-onderdeel. Elke control wordt uitgelegd met: doel, wat de standaard vraagt, en een concrete MKB-implementatie-aanpak.
Nummering: de standaard nummert categorieen A.2 t/m A.10 (A.1 bevat de inleiding). De exacte controle-nummering (bijv, a.6.2.4) volgt de officiele ISO-nummering.
Annex A is het controle-kader. Clauses 4-10 zijn het management-systeem.
Annex A van ISO 42001 bevat een catalogus van controls specifiek voor AI-systemen. Het werkt hetzelfde als Annex A in ISO 27001 (informatiebeveiliging): je selecteert welke controls toepasselijk zijn voor jouw organisatie, implementeert ze, en documenteert je keuzes in een Statement of Applicability (SoA). De controls zijn geen afvinklijst waar alles verplicht is. Ze zijn een menu waaruit je kiest op basis van context, risico-profiel en de aard van je AI-inzet.
De 9 categorieen bestrijken het volledige spectrum van AI-management: van organisatorisch beleid (A.2-A.3) via technische lifecycle en data (A.6-A.7) tot transparantie en derde-partij-beheer (A.8-A.10). Annex B van de standaard geeft per control informatieve implementatie-guidance. Annex B is niet verplicht maar geeft concrete richting aan hoe je een control kunt invullen. In deze gids verwerken we de Annex B-inzichten in de praktische MKB-implementatie per control.
Voor wie is dit referentiewerk bedoeld? Voor AI Officers, compliance-verantwoordelijken, kwaliteitsmanagers en directieleden die ISO 42001-implementatie aansturen of evalueren. Ook waardevol voor organisaties die nog geen ISO 42001-traject doorlopen maar Annex A als structurerend kader gebruiken voor hun AI-governance. Koppeling met onze implementatie-gids voor het bredere traject.
De controls worden hieronder per categorie uitgewerkt. Per control geven we: de officieel vereiste actie, de achterliggende rationale, de praktische MKB-implementatie (wat moet je concreet doen), en een indicatie van implementatie-complexiteit. Onderaan vind je een mapping-tabel die elke categorie koppelt aan relevante AI Act-artikelen, een implementatie-prioriteitsmatrix voor MKB, en een FAQ-sectie.
Beleid voor AI
2 controls · Fundament voor alle andere categorieen
Categorie A.2 vormt de beleidsmatige basis van het AI Management System. Zonder helder AI-beleid ontbreekt de richting voor alle andere controls. Deze categorie eist dat de organisatie expliciet vastlegt hoe zij AI wil inzetten, welke principes daarbij gelden, en hoe verantwoordelijkheden zijn verdeeld. Het AI-beleid is het document waarnaar alle andere controls terugverwijzen. De directie moet het beleid goedkeuren en actief ondersteunen; het is geen document dat alleen op papier staat.
A.2.2 AI-beleid Control
Wat de standaard vraagt: de organisatie stelt een AI-beleid vast dat past bij het doel van de organisatie, een kader biedt voor het stellen van AI-objectieven, commitment bevat om aan toepasselijke eisen te voldoen, en commitment bevat voor continue verbetering van het AIMS. Het beleid moet beschikbaar zijn als gedocumenteerde informatie, gecommuniceerd worden binnen de organisatie, en beschikbaar zijn voor relevante belanghebbenden.
Achtergrond: het AI-beleid is vergelijkbaar met het informatiebeveiligingsbeleid in ISO 27001 of het kwaliteitsbeleid in ISO 9001. Het stelt de toon voor de hele organisatie. Zonder dit document is er geen formele basis om AI-gerelateerde beslissingen te sturen. De auditor controleert of het beleid actueel is, door de directie is goedgekeurd, en daadwerkelijk gecommuniceerd is.
MKB-implementatie
Stel een AI-beleidsdocument op van twee tot vier pagina's. Inhoud: visie op AI-inzet, ethische principes (eerlijkheid, transparantie, menselijke controle), verwijzing naar toepasselijke wetgeving (AI Act, AVG), rolverdeling (wie is verantwoordelijk), en review-cyclus (minimaal jaarlijks). Laat de directie ondertekenen. Publiceer intern (intranet, handboek) en communiceer actief in teamvergadering. Voor externe stakeholders: maak een samenvatting beschikbaar op de website of in contracten.
A.2.3 Beleid voor verantwoord AI-gebruik Control
Wat de standaard vraagt: de organisatie definieert beleid specifiek gericht op het verantwoorde gebruik van AI-systemen. Dit beleid adresseert de specifieke AI-gerelateerde aspecten zoals eerlijkheid, transparantie, verantwoordelijkheid en menselijk toezicht. Het is specifieker dan het overkoepelende AI-beleid en richt zich op concrete gedragsregels voor het werken met AI.
Achtergrond: waar A.2.2 het strategische kader is, gaat A.2.3 over operationele principes. Denk aan: welke AI-toepassingen zijn niet acceptabel (verboden lijst), welke voorwaarden gelden voor het inzetten van AI in klantcontact, hoe om te gaan met AI-output die beslissingen beinvloedt. Dit beleid vertaalt abstracte principes naar dagelijkse praktijk.
MKB-implementatie
Maak een aanvullend document of hoofdstuk bij het AI-beleid dat concrete richtlijnen geeft. Voorbeelden: 'AI-output wordt altijd door een mens geverifieerd voordat het naar klanten gaat', 'Persoonsgegevens worden niet ingevoerd in publieke AI-tools', 'Automatische besluitvorming over personen vereist menselijke review'. Houd het praktisch en herkenbaar voor medewerkers. Koppel aan een AI-gedragscode die medewerkers ondertekenen. Dit raakt direct aan de AI literacy-verplichting uit de AI Act.
Interne organisatie
3 controls · Rollen, verantwoordelijkheden en governance-structuur
Categorie A.3 regelt de organisatorische inrichting rondom AI. Wie is verantwoordelijk, wie rapporteert aan wie, hoe is de governance-structuur ingericht? Zonder heldere rolverdeling lopen controls uit andere categorieen vast: niemand weet wie actie moet ondernemen. Deze categorie is de organisatorische ruggengraat van het AIMS.
A.3.2 Rollen en verantwoordelijkheden voor AI Control
Wat de standaard vraagt: alle relevante rollen en verantwoordelijkheden met betrekking tot AI-systemen worden gedefinieerd en toegewezen. Dit omvat wie verantwoordelijk is voor AI-beslissingen, wie de operationele uitvoering doet, wie toezicht houdt, en hoe verantwoording wordt afgelegd.
Achtergrond: in de praktijk zien auditors vaak dat verantwoordelijkheden niet expliciet zijn toegewezen. 'Iedereen is verantwoordelijk' betekent 'niemand is verantwoordelijk'. ISO 42001 eist dat je concrete namen of functies koppelt aan AI-verantwoordelijkheden. Dit kan een dedicated AI Officer zijn, maar ook een bestaande rol (CTO, CISO, kwaliteitsmanager) die AI-taken erbij krijgt.
MKB-implementatie
Maak een RACI-matrix (Responsible, Accountable, Consulted, Informed) voor AI-activiteiten. Wijs minimaal toe: wie beslist over nieuwe AI-tools (directie), wie implementeert (IT/operations), wie monitort (kwaliteit/compliance), wie evalueert impact (AI Officer of equivalent). Bij MKB 5-20 FTE kan dit een persoon zijn die meerdere rollen combineert. Documenteer in het AIMS-handboek. Update bij organisatiewijzigingen.
A.3.3 Rapportage over AI-systemen Control
Wat de standaard vraagt: de organisatie zorgt dat relevante informatie over AI-systemen wordt gerapporteerd aan het management en aan relevante functies. Dit omvat periodieke rapportage over de status, prestaties, incidenten en risico's van AI-systemen.
Achtergrond: rapportage zorgt dat het management zichtbaarheid heeft op wat er met AI gebeurt in de organisatie. Zonder rapportage kan het management geen geinformeerde beslissingen nemen over AI-beleid, risico-acceptatie of resource-allocatie. De rapportage sluit aan bij Clause 5 (leiderschap) en Clause 9 (performance evaluation).
MKB-implementatie
Voer een kwartaalrapportage in over AI. Inhoud: welke AI-systemen zijn actief, eventuele incidenten of klachten, resultaten van monitoring, geplande wijzigingen, compliance-status. Format: een een-pagina-dashboard of korte notitie aan de directie. Bij MKB kan dit meeliften op bestaande management-rapportage (MT-vergadering). Documenteer dat de rapportage is besproken (notulen).
A.3.4 Verantwoordelijkheden binnen AI-systeem-teams Control
Wat de standaard vraagt: binnen teams die direct werken aan of met AI-systemen worden specifieke verantwoordelijkheden toegewezen. Dit gaat verder dan organisatie-brede rollen en richt zich op operationele teams: wie doet wat in het dagelijkse werk met AI?
Achtergrond: bij AI-ontwikkeling en -gebruik zijn diverse disciplines betrokken: data engineers, ML engineers, domeinexperts, testers, operationeel beheer. Wie is verantwoordelijk voor datakwaliteit? Wie voor model-validatie? Wie voor monitoring na deployment? Deze control zorgt dat dit op teamniveau helder is.
MKB-implementatie
Beschrijf per AI-systeem of AI-project wie welke taak heeft. Bij MKB waar teams klein zijn: leg vast in een projectcharter of teamafsprakenlijst. Voorbeeld: 'Jan beheert de data-input, Lisa monitort output-kwaliteit, de directeur beslist over incidentescalaties.' Formeel genoeg om te auditen, praktisch genoeg om te gebruiken. Bewaar in het AIMS-dossier per AI-systeem.
Middelen voor AI-systemen
6 controls · Mensen, tools, infrastructuur en kennis
Categorie A.4 adresseert de middelen die een organisatie nodig heeft om AI-systemen verantwoord te ontwikkelen, in te zetten en te onderhouden. Dit gaat verder dan financiele middelen: het omvat menselijk kapitaal, technische infrastructuur, tools, rekenkracht en kennisontwikkeling. Voor MKB is dit vaak de categorie waar de meeste spanning zit: beperkte middelen versus de vereisten van de standaard. De sleutel is proportionaliteit: de standaard verwacht niet dat elk MKB een volledig AI-lab heeft, maar wel dat de beschikbare middelen passen bij de schaal en risico's van de AI-inzet.
A.4.2 Middelen voor AI-systemen Control
Wat de standaard vraagt: de organisatie bepaalt en voorziet de middelen die nodig zijn voor de ontwikkeling, het gebruik en het onderhoud van AI-systemen. Dit is een overkoepelende control die ervoor zorgt dat er een bewuste afweging is gemaakt over resource-allocatie.
Achtergrond: zonder voldoende middelen kunnen andere controls niet effectief werken. Een impact assessment uitvoeren (A.5) vereist tijd en expertise. Data-governance (A.7) vereist tooling. Monitoring (A.9) vereist infrastructuur. Deze control eist dat de organisatie een bewust besluit neemt over wat er nodig is en dat ook beschikbaar stelt.
MKB-implementatie
Maak een jaarlijks AI-resource-plan. Omvat: hoeveel FTE (of deel-FTE) beschikbaar is voor AI-gerelateerd werk, welke tools en licenties nodig zijn, welk budget beschikbaar is voor externe expertise (consultants, training). Bij MKB 5-20 FTE is dit typisch 0,2-0,5 FTE intern plus budget voor externe ondersteuning. Documenteer het besluit en koppel aan de jaarlijkse begroting.
A.4.3 Competenties voor AI Control
Wat de standaard vraagt: de organisatie bepaalt de benodigde competenties voor personen die werk doen dat de prestatie van het AIMS beinvloedt, zorgt dat deze personen competent zijn op basis van opleiding, training of ervaring, en bewaart passend bewijs van competentie.
Achtergrond: AI-systemen inzetten zonder dat medewerkers begrijpen wat ze doen, hoe ze werken en wat de risico's zijn, is een kernrisico. Deze control sluit nauw aan bij Clause 7.2 (competentie) en bij de AI literacy-verplichting uit Artikel 4 van de AI Act.
MKB-implementatie
Identificeer per AI-gerelateerde rol welke competenties nodig zijn. Voorbeeld: AI-gebruikers moeten AI-output kritisch kunnen beoordelen; AI-beheerders moeten monitoring-tools kunnen inrichten; directie moet AI-risico's kunnen afwegen. Organiseer training (intern of extern), documenteer deelname en evalueer jaarlijks. Bewaar certificaten, trainingsregistraties en evaluatieformulieren. De AI Act eist dit ook; combineer beide verplichtingen in een trainingsplan.
A.4.4 Bewustzijn over AI Control
Wat de standaard vraagt: personen die werk doen onder het beheer van de organisatie moeten zich bewust zijn van het AI-beleid, hun bijdrage aan de effectiviteit van het AIMS, de gevolgen van het niet voldoen aan AIMS-vereisten, en de risico's en kansen van AI-systemen.
Achtergrond: bewustzijn is breder dan competentie. Een medewerker kan technisch competent zijn maar zich niet bewust van het beleid of de risico's. Deze control zorgt dat iedereen weet dat er een AI-beleid is, wat het inhoudt, en wat er van hen verwacht wordt.
MKB-implementatie
Voer een jaarlijkse AI-bewustzijnssessie in voor alle medewerkers (30-60 minuten). Bespreek het AI-beleid, geef voorbeelden van do's en don'ts, bespreek recente incidenten of veranderingen. Bij onboarding van nieuwe medewerkers: voeg AI-bewustzijn toe aan het introductieprogramma. Documenteer aanwezigheid. Dit kan gecombineerd worden met de AI literacy-training voor de AI Act.
A.4.5 Communicatie over AI Control
Wat de standaard vraagt: de organisatie bepaalt de interne en externe communicatie die relevant is voor het AIMS, inclusief: waarover gecommuniceerd wordt, wanneer, met wie, en hoe.
Achtergrond: AI-gerelateerde communicatie omvat zowel intern (medewerkers informeren over AI-beleid, incidenten, veranderingen) als extern (klanten, partners, toezichthouders). Ongestructureerde communicatie leidt tot inconsistente boodschappen en risico's. Een woordvoerder die iets anders zegt dan het beleid voorschrijft, creert aansprakelijkheid.
MKB-implementatie
Stel een communicatie-matrix op: wie communiceert wat, aan wie, wanneer, via welk kanaal. Minimaal: interne updates via teamvergadering of intranet bij beleidswijzigingen; externe communicatie via website (privacy/AI-verklaring) en contracten. Wijs een woordvoerder aan voor AI-gerelateerde externe vragen. Bij incidenten: volg een vaste communicatie-procedure (wie informeert klanten, wanneer, met welke boodschap).
A.4.6 Tools en frameworks voor AI Control
Wat de standaard vraagt: de organisatie identificeert en voorziet passende tools, technieken en frameworks voor de ontwikkeling, het testen, de implementatie en het beheer van AI-systemen.
Achtergrond: AI-systemen vereisen specifieke tooling: ontwikkelomgevingen, test-frameworks, monitoring-dashboards, versiebeheersystemen voor modellen en data. Zonder passende tooling is het vrijwel onmogelijk om andere controls (lifecycle A.6, data A.7, monitoring A.9) adequaat in te vullen.
MKB-implementatie
Maak een inventaris van gebruikte AI-tools en -platforms. Beoordeel per tool: is het geschikt voor het doel, voldoet het aan beveiligings- en privacy-eisen, wordt het ondersteund en onderhouden. Voor MKB-deployers die AI als SaaS afnemen: documenteer de leverancier, het contract, de SLA en de exit-strategie. Voor MKB die AI ontwikkelt: documenteer de development-stack, test-tools en deployment-pipeline.
A.4.7 Gedocumenteerde informatie over AI Control
Wat de standaard vraagt: de organisatie beheert gedocumenteerde informatie over AI-systemen conform de vereisten van het AIMS. Dit omvat creatie, distributie, opslag, versiebeheer en archivering van AI-gerelateerde documenten.
Achtergrond: documentatiebeheer is een kernelement van elk ISO-management-systeem. Bij AI komt daar een specifieke dimensie bij: documentatie over modellen, trainingsdata, testresultaten, deployment-configuraties en monitoring-output. Dit moet traceerbaar en reproduceerbaar zijn.
MKB-implementatie
Richt een eenvoudig documentbeheersysteem in (SharePoint, Notion, of vergelijkbaar). Stel een documentconventie vast: naamgeving, versienummering, goedkeuringsprocedure. Per AI-systeem: maak een dossier met beleidsdocumenten, impact assessments, testresultaten, configuratie-documenten, incidentrapporten. De auditor wil traceerbare versiehistorie zien. Tip: gebruik een template per documenttype zodat alle AI-systemen consistent gedocumenteerd zijn.
AI-systeemimpact-beoordeling
5 controls · Systematische beoordeling van impact op individuen en samenleving
Categorie A.5 is een van de zwaarste categorieen in Annex A. Het gaat over het systematisch beoordelen van de impact die AI-systemen hebben op individuen, groepen en de bredere samenleving. Dit is vergelijkbaar met een Fundamental Rights Impact Assessment (FRIA) onder de AI Act, maar breder: ISO 42001 kijkt niet alleen naar fundamentele rechten maar naar alle mogelijke impacts. Voor MKB is dit vaak de categorie die de meeste moeite kost omdat het een gestructureerde methodiek vereist die veel organisaties nog niet hebben.
A.5.2 AI-systeemimpact-assessment-proces Control
Wat de standaard vraagt: de organisatie stelt een proces vast voor het beoordelen van de impact van AI-systemen op individuen, groepen en de samenleving. Het proces omvat criteria voor wanneer een impact assessment nodig is, de methodiek, de rollen die betrokken zijn, en hoe resultaten worden verwerkt.
Achtergrond: het gaat hier om het proces, niet om de individuele assessments zelf. De organisatie moet een herhaalbare, consistente methodiek hebben die op elk AI-systeem kan worden toegepast. Dit voorkomt dat assessments ad-hoc en inconsistent worden uitgevoerd.
MKB-implementatie
Ontwerp een impact-assessment-template. Inhoud: systeembeschrijving, beoogd gebruik, categorieen van betrokkenen (gebruikers, personen waarover beslissingen worden genomen, bredere samenleving), mogelijke positieve en negatieve impacts per categorie, ernst en waarschijnlijkheid van negatieve impacts, mitigerende maatregelen. Stel een drempelwaarde vast: wanneer voer je een assessment uit (bij elk nieuw AI-systeem, bij significante wijzigingen). Koppel aan de AI-risicoanalyse-methode.
A.5.3 Uitvoeren van impact assessments Control
Wat de standaard vraagt: de organisatie voert impact assessments uit conform het vastgestelde proces voor alle AI-systemen in scope. Resultaten worden gedocumenteerd en gecommuniceerd aan relevante belanghebbenden.
Achtergrond: het hebben van een proces (A.5.2) zonder dat het wordt uitgevoerd, is een typische audit-bevinding. Deze control eist dat assessments daadwerkelijk worden gedaan, niet alleen dat de methodiek bestaat. Per AI-systeem in scope moet een ingevuld assessment beschikbaar zijn.
MKB-implementatie
Voer per AI-systeem in scope de impact assessment uit met de template uit A.5.2. Betrek minimaal: de systeemeigenaar, een domeinexpert die de context begrijpt, en iemand met compliance-kennis. Documenteer het ingevulde assessment, de deelnemers, de datum, en het goedkeuringsbesluit. Bewaar in het AI-systeem-dossier. Plan herhalingsfrequentie: minimaal jaarlijks of bij significante wijzigingen.
A.5.4 Documentatie van impact-assessment-resultaten Control
Wat de standaard vraagt: resultaten van impact assessments worden gedocumenteerd, onderhouden en beschikbaar gesteld aan relevante partijen. De documentatie omvat de bevindingen, de afwegingen, de besluiten en de geplande acties.
Achtergrond: documentatie is het bewijs dat het assessment is uitgevoerd en dat de organisatie op basis van de resultaten actie heeft ondernomen. Zonder documentatie kan een auditor niet verifieren dat het proces werkt. De documentatie dient ook als referentie bij toekomstige herbeoordelingen.
MKB-implementatie
Sla elk ingevuld impact assessment op in het AI-systeem-dossier met versiebeheer. Voeg toe: samenvatting van bevindingen, lijst van geidentificeerde risico's, genomen of geplande mitigerende maatregelen, goedkeuring door bevoegd persoon, datum volgende herbeoordeling. Gebruik een registratiesysteem (spreadsheet of documentmanagement) om overzicht te houden over alle assessments en hun status.
A.5.5 Monitoring van impact-assessment-acties Control
Wat de standaard vraagt: de organisatie monitort of de mitigerende maatregelen die voortkomen uit impact assessments daadwerkelijk worden geimplementeerd en of ze effectief zijn.
Achtergrond: een assessment dat risico's identificeert maar waarbij de aanbevolen maatregelen niet worden uitgevoerd, heeft geen waarde. Deze control sluit de cirkel: van identificatie naar actie naar verificatie. Het is een onderdeel van de PDCA-cyclus op control-niveau.
MKB-implementatie
Maak per impact assessment een actielijst met: maatregel, eigenaar, deadline, status. Neem deze op in de kwartaalrapportage aan het management (zie A.3.3). Controleer bij elke herbeoordelingsronde of eerder geidentificeerde maatregelen zijn uitgevoerd en of ze het beoogde effect hebben. Documenteer de verificatie. Bij MKB kan dit een eenvoudige checklist zijn die per kwartaal wordt doorgelopen.
A.5.6 Betrekken van belanghebbenden bij impact assessments Control
Wat de standaard vraagt: de organisatie betrekt relevante belanghebbenden bij het impact-assessment-proces. Dit kan betrokkenen zijn (personen die geraakt worden door het AI-systeem), domeinexperts, gebruikers, of externe partijen.
Achtergrond: een impact assessment dat alleen intern wordt uitgevoerd, mist het perspectief van degenen die daadwerkelijk geraakt worden. Door stakeholders te betrekken, worden blinde vlekken verkleind en is de beoordeling realistischer. De mate van stakeholder-betrokkenheid hangt af van het risico-niveau van het AI-systeem.
MKB-implementatie
Identificeer per AI-systeem de belangrijkste stakeholders. Bij een AI-systeem voor klantbeoordeling: betrek een klantvertegenwoordiger of klantenservice-medewerker. Bij een intern HR-AI-systeem: betrek een werknemervertegenwoordiger. Bij beperkt risico kan betrokkenheid bestaan uit een feedbackmechanisme. Bij hoog risico: directe deelname aan het assessment-proces. Documenteer wie betrokken is geweest en hoe hun input is verwerkt.
AI-systeemlevenscyclus
6 controls · Van ontwerp tot uitfasering
Categorie A.6 bestrijkt de volledige levenscyclus van AI-systemen: ontwerp, ontwikkeling, testen, validatie, deployment, operationeel beheer, en uiteindelijk uitfasering (retirement). Dit is de meest technische categorie en is vooral relevant voor organisaties die AI zelf ontwikkelen of significant aanpassen. MKB-deployers die AI als kant-en-klare dienst afnemen, hoeven niet alle controls in deze categorie te implementeren, maar moeten wel de controls die betrekking hebben op deployment en operationeel beheer adresseren.
A.6.2.2 AI-systeem-ontwerp en -specificatie Control
Wat de standaard vraagt: AI-systemen worden ontworpen en gespecificeerd volgens vastgestelde vereisten, inclusief functionele vereisten, prestatie-eisen, veiligheids- en beveiligingseisen, ethische overwegingen en wettelijke eisen.
Achtergrond: goed ontwerp voorkomt problemen later in de levenscyclus. Door vooraf helder te specificeren wat het AI-systeem moet doen, binnen welke grenzen, en aan welke eisen het moet voldoen, wordt het fundament gelegd voor verantwoorde ontwikkeling. Dit is vergelijkbaar met 'security by design' bij informatiebeveiliging, maar dan voor alle AI-aspecten.
MKB-implementatie
Bij eigen AI-ontwikkeling: maak per AI-systeem een specificatie-document vooraf. Omvat: beoogd gebruik, niet-beoogd gebruik, prestatie-criteria, eerlijkheidscriteria, maximale foutmarges, escalatieprocedure bij onverwacht gedrag. Bij inkoop van AI: neem deze specificaties op als eisen in het selectieproces en contract met de leverancier. Reviewen bij significante wijzigingen.
A.6.2.3 AI-systeem-ontwikkeling Control
Wat de standaard vraagt: de ontwikkeling van AI-systemen volgt vastgestelde processen die kwaliteit, traceerbaarheid en reproduceerbaarheid waarborgen. Dit omvat versiebeheer van modellen en data, documentatie van ontwikkelbeslissingen, en naleving van de ontwerpspecificaties.
Achtergrond: AI-ontwikkeling is vaak experimenteel en iteratief. Zonder discipline in het ontwikkelproces is het achteraf niet te achterhalen hoe een model tot stand is gekomen, welke data is gebruikt, of welke keuzes zijn gemaakt. Dit maakt het onmogelijk om verantwoording af te leggen of problemen te diagnosticeren.
MKB-implementatie
Als je AI ontwikkelt: gebruik versiebeheer voor code, modellen en trainingsdata (Git, DVC of vergelijkbaar). Documenteer per iteratie: welke data is gebruikt, welke hyperparameters, welke resultaten, welke beslissing (doorgaan, aanpassen, stoppen). Maak een logboek van significante ontwikkelbeslissingen. Bij gebruik van SaaS-AI: niet direct toepasselijk, maar documenteer wijzigingen in configuratie en gebruik van het systeem.
A.6.2.4 Testen en validatie van AI-systemen Control
Wat de standaard vraagt: AI-systemen worden getest en gevalideerd voordat ze in productie worden genomen. Testen omvat functionele testen, prestatie-testen, veiligheids- en beveiligingstesten, eerlijkheidstesten (bias-testing) en testen onder uitzonderlijke omstandigheden.
Achtergrond: een AI-systeem dat niet adequaat is getest, kan onverwacht gedrag vertonen met potentieel ernstige gevolgen. Bias-testing is specifiek voor AI: het systeem moet worden gecontroleerd op systematische ongelijkheden in de output voor verschillende groepen. Dit sluit aan bij AI Act Artikel 10 (data governance) en Artikel 9 (risk management).
MKB-implementatie
Stel een testprotocol op per AI-systeem. Minimaal: test op juistheid/nauwkeurigheid met representatieve testdata, test op bias als het systeem beslissingen over personen maakt, test met randgevallen en onverwachte input. Documenteer testresultaten, acceptatiecriteria en het go/no-go-besluit. Bij SaaS-AI: voer acceptatietesten uit op basis van eigen data en use cases. Herhaal testen na significante updates van het systeem of de onderliggende data.
A.6.2.5 Deployment van AI-systemen Control
Wat de standaard vraagt: de organisatie beheert het deployment-proces van AI-systemen op een gecontroleerde manier. Dit omvat criteria voor deployment-gereedheid, goedkeuringsprocedures, rollback-procedures en communicatie naar gebruikers.
Achtergrond: de overgang van test naar productie is een kritiek moment. Zonder gecontroleerd deployment-proces kan een AI-systeem in productie terechtkomen dat niet adequaat is getest, of worden gebruikers niet geinformeerd over veranderingen. Rollback-procedures zijn essentieel: als het misgaat, moet je snel terug kunnen.
MKB-implementatie
Maak een deployment-checklist per AI-systeem. Inhoud: zijn alle testen doorlopen en goedgekeurd, is de impact assessment actueel, zijn gebruikers geinformeerd, is er een rollback-plan, wie geeft de go-ahead. Bij SaaS-AI: documenteer het besluit om een nieuwe versie of functionaliteit te activeren. Bij eigen AI: implementeer een gecontroleerd deployment-proces (staging/productie-scheiding, canary releases waar mogelijk).
A.6.2.6 Operationeel beheer van AI-systemen Control
Wat de standaard vraagt: AI-systemen in productie worden continu bewaakt en beheerd. Dit omvat monitoring van prestaties, detectie van afwijkingen, onderhoud, en aanpassing aan veranderende omstandigheden (model drift, data drift).
Achtergrond: AI-systemen zijn niet statisch. Na deployment kan de prestatie verslechteren doordat de input-data verandert (data drift) of doordat de relatie tussen input en output verschuift (model drift). Zonder actieve monitoring wordt dit niet opgemerkt totdat het problemen veroorzaakt.
MKB-implementatie
Richt monitoring in per AI-systeem in productie. Minimaal: controleer periodiek (wekelijks of maandelijks) of de output nog klopt door steekproeven te nemen, houd foutmeldingen en klachten bij, monitor gebruikspatronen op afwijkingen. Bij kritieke AI-systemen: automatiseer monitoring waar mogelijk (alerts bij prestatie-daling). Documenteer monitoringresultaten en actie-opvolging. Dit sluit aan bij AI Act Artikel 72 (monitoring na ingebruikname).
A.6.2.7 Uitfasering van AI-systemen Control
Wat de standaard vraagt: de organisatie beheert de uitfasering (retirement) van AI-systemen op een gecontroleerde manier. Dit omvat criteria voor uitfasering, communicatie naar betrokkenen, data-archivering of -vernietiging, en documentatie van het uitfaseringsbesluit.
Achtergrond: AI-systemen worden vervangen, overbodig of verouderd. Zonder gecontroleerde uitfasering kunnen data-residuen achterblijven, afhankelijkheden worden doorbroken, of blijven gebruikers vertrouwen op een systeem dat niet meer wordt onderhouden. Uitfasering is vaak vergeten in AI-governance; deze control maakt het expliciet.
MKB-implementatie
Stel een uitfaseringsprocedure op. Inhoud: besluitvormingsproces (wie beslist dat een AI-systeem wordt uitgefaseerd), communicatieplan (gebruikers, klanten, partners informeren), data-afhandeling (archiveren of vernietigen conform AVG en bewaartermijnen), documentatie van het besluit en de uitvoering. Zorg dat er een alternatief beschikbaar is of dat processen zijn aangepast. Bewaar het uitfaseringsdossier voor audit-doeleinden.
Data voor AI-systemen
4 controls · Datakwaliteit, herkomst, governance en privacy
Categorie A.7 adresseert een van de meest kritieke aspecten van AI: de data. De kwaliteit van AI-output hangt direct samen met de kwaliteit, representativiteit en betrouwbaarheid van de input-data. Deze categorie eist dat organisaties bewust omgaan met data: waar komt het vandaan, is het geschikt, is het representatief, hoe wordt het beheerd? Voor MKB dat AI als SaaS afneemt, zijn delen van deze categorie indirect toepasselijk (je moet begrijpen wat de leverancier met data doet). Voor MKB dat AI ontwikkelt, is dit een van de meest intensieve categorieen. Koppeling met onze AI Act-vergelijking voor de overlap met Artikel 10 data governance.
A.7.2 Data voor AI-systemen - beleid Control
Wat de standaard vraagt: de organisatie stelt beleid en processen vast voor het beheer van data die wordt gebruikt door of in relatie tot AI-systemen. Dit omvat data-acquisitie, voorbereiding, labeling, opslag, gebruik, delen en vernietiging.
Achtergrond: data is de brandstof van AI. Zonder beleid over hoe data wordt verzameld, bewerkt en gebruikt, ontbreekt de basis voor betrouwbare AI-output. Dit beleid overlapt met AVG-compliance (als persoonsgegevens betrokken zijn) maar gaat breder: het omvat ook niet-persoonlijke data die voor AI wordt gebruikt.
MKB-implementatie
Breid bestaand data-beleid (AVG/privacy) uit met AI-specifieke bepalingen. Voeg toe: welke data mag voor AI-doeleinden worden gebruikt, onder welke voorwaarden, hoe wordt datakwaliteit gewaarborgd, welke data-bronnen zijn goedgekeurd. Bij gebruik van SaaS-AI: documenteer welke data je naar de AI-dienst stuurt en wat de leverancier ermee doet (bewaren, trainen, verwijderen). Koppel aan de AI governance-gids.
A.7.3 Datakwaliteit voor AI Control
Wat de standaard vraagt: de organisatie definieert en past datakwaliteitscriteria toe voor data die door AI-systemen wordt gebruikt. Kwaliteitscriteria omvatten nauwkeurigheid, volledigheid, actualiteit, consistentie, representativiteit en relevantie.
Achtergrond: slechte datakwaliteit leidt direct tot slechte AI-output: 'garbage in, garbage out'. Maar bij AI gaat het verder: niet-representatieve data leidt tot bias. Verouderde data leidt tot beslissingen op basis van achterhaalde patronen. Onvolledige data leidt tot blinde vlekken. Deze control eist dat je datakwaliteit bewust meet en bewaakt.
MKB-implementatie
Definieer per AI-systeem de datakwaliteitscriteria die relevant zijn. Voorbeeld: voor een AI-systeem dat klantgedrag voorspelt, moeten de gegevens actueel zijn (maximaal 6 maanden oud), compleet (minimaal 95% van velden ingevuld) en representatief (alle klantgroepen vertegenwoordigd). Meet periodiek of de data aan de criteria voldoet. Documenteer afwijkingen en corrigerende acties. Bij SaaS-AI: beoordeel de kwaliteit van de data die je aanlevert en stel kwaliteitseisen aan de leverancier.
A.7.4 Dataherkomst (provenance) Control
Wat de standaard vraagt: de organisatie documenteert en beheert de herkomst van data die door AI-systemen wordt gebruikt. Dit omvat: waar de data vandaan komt, hoe het is verzameld, welke bewerkingen zijn toegepast, en door wie.
Achtergrond: data-provenance is essentieel voor traceerbaarheid en verantwoording. Als een AI-systeem een verkeerde beslissing neemt, moet je kunnen achterhalen welke data eraan ten grondslag lag en hoe die data tot stand is gekomen. Provenance is ook relevant voor compliance: bij persoonsgegevens moet je kunnen aantonen op welke grondslag je de data verwerkt.
MKB-implementatie
Maak een data-inventaris per AI-systeem. Per databron: beschrijf de herkomst (intern systeem, externe leverancier, scraping, handmatige invoer), de verzamelmethode, de datum van verzameling, de bewerkingen die zijn toegepast (opschoning, transformatie, anonimisering), en de verantwoordelijke. Bij SaaS-AI: documenteer welke eigen data je invoert en wat de leverancier als trainingsdata gebruikt (indien bekend). Een eenvoudig spreadsheet volstaat voor MKB.
A.7.5 Datavoorbereiding Control
Wat de standaard vraagt: de organisatie voert datavoorbereidingsactiviteiten uit op een gecontroleerde en gedocumenteerde manier. Dit omvat data-opschoning, transformatie, labeling, annotatie en augmentatie.
Achtergrond: datavoorbereiding is een van de meest tijdrovende stappen in AI-ontwikkeling en heeft directe impact op de kwaliteit van het resultaat. Fouten in datavoorbereiding (verkeerde labels, inconsistente transformaties) worden onzichtbaar versterkt door het AI-model. Documentatie zorgt dat fouten kunnen worden getraceerd en gecorrigeerd.
MKB-implementatie
Als je data voorbereidt voor AI: documenteer elke stap in de datapipeline. Welke opschoningsregels zijn toegepast, welke records zijn verwijderd en waarom, welke transformaties zijn uitgevoerd. Gebruik versiebeheer voor datasets (DVC of vergelijkbaar). Bij SaaS-AI: documenteer hoe je de data voorbereidt voordat je het naar de dienst stuurt (bijvoorbeeld: welke velden worden geselecteerd, welke records worden gefilterd). Bij gebruik van kant-en-klare AI zonder eigen datavoorbereiding: mogelijk niet toepasselijk (documenteer in SoA).
Informatie voor betrokkenen
4 controls · Transparantie, communicatie en uitleg
Categorie A.8 gaat over transparantie: hoe informeert de organisatie betrokkenen (gebruikers, klanten, partners, toezichthouders) over haar AI-systemen? Dit is een categorie die direct raakt aan AI Act-verplichtingen rondom transparantie (Artikel 13 en 50). Voor MKB is dit relevant ongeacht of je AI zelf ontwikkelt of inkoopt: als je AI inzet richting klanten of medewerkers, heb je een informatieplicht.
A.8.2 Transparantie over AI-systemen Control
Wat de standaard vraagt: de organisatie zorgt dat relevante informatie over AI-systemen beschikbaar is voor belanghebbenden. Dit omvat informatie over het bestaan van AI-systemen, het beoogde gebruik, de beperkingen, en hoe betrokkenen kunnen reageren.
Achtergrond: personen die interacteren met of geraakt worden door AI-systemen, hebben recht op informatie. Dit is een ethisch principe dat ook wettelijk is verankerd (AI Act Artikel 50: aanbieders van AI-systemen die met personen interacteren moeten dit kenbaar maken). Transparantie bouwt vertrouwen en vermindert het risico op klachten en juridische aanspraken.
MKB-implementatie
Maak op de website een pagina of sectie die beschrijft welke AI-systemen de organisatie gebruikt die klanten raken. Per systeem: wat doet het, waarvoor wordt het gebruikt, welke data verwerkt het, wat zijn de beperkingen. Voorbeeld: 'Onze klantenservice gebruikt AI-chatbot X voor initieel klantcontact. De chatbot beantwoordt veelgestelde vragen en escaleert naar een mens bij complexe vragen.' Voeg een contactmogelijkheid toe voor vragen. Bij B2B: neem transparantie-bepalingen op in contracten en SLA's.
A.8.3 Informatie over AI-interacties Control
Wat de standaard vraagt: personen die interacteren met een AI-systeem worden geinformeerd dat ze met een AI-systeem interacteren, tenzij dit duidelijk is uit de context.
Achtergrond: dit is een directe parallel met AI Act Artikel 50 lid 1: deployers van AI-systemen die met personen interacteren (bijv. chatbots, virtuele assistenten) moeten deze personen informeren dat ze met AI communiceren. De standaard voegt toe: 'tenzij duidelijk uit de context', waarmee wordt erkend dat sommige AI-toepassingen (zoals spellingscontrole) geen expliciete melding nodig hebben.
MKB-implementatie
Identificeer alle AI-systemen die direct met personen interacteren (chatbots, virtuele assistenten, geautomatiseerde e-mails, AI-gegenereerde content). Zorg bij elk contactpunt voor een heldere melding. Voorbeeld: 'U spreekt met een AI-assistent. Een medewerker neemt het over als u dat wenst.' Bij AI-gegenereerde content: label als zodanig. Bij geautomatiseerde beslissingen: informeer dat AI betrokken is en bied een menselijk alternatief. Dit is tegelijkertijd AI Act-compliance.
A.8.4 Uitlegbaarheid van AI-output Control
Wat de standaard vraagt: de organisatie zorgt dat AI-systeem-output uitlegbaar is op een niveau dat past bij de context en de betrokkenen. De mate van uitlegbaarheid hangt af van het risico-niveau en de impact van de AI-output.
Achtergrond: uitlegbaarheid (explainability) is een kernthema in AI-governance. Betrokkenen die geraakt worden door AI-beslissingen moeten kunnen begrijpen waarom een bepaalde uitkomst tot stand is gekomen. Dit is niet hetzelfde als technische transparantie (hoe het model werkt) maar functionele uitleg (waarom deze uitkomst voor deze persoon in deze situatie).
MKB-implementatie
Bepaal per AI-systeem het gewenste uitlegbaarheidsniveau. Bij hoog-risico-beslissingen (kredietbeoordeling, sollicitatiescreening): gedetailleerde uitleg van de factoren die hebben bijgedragen. Bij laag-risico (productaanbevelingen): globale uitleg volstaat ('op basis van eerdere aankopen'). Documenteer de uitlegbaarheidsstrategie per systeem. Implementeer uitlegmechanismen: feature importance, decision rules, of menselijke interpretatie. Bij SaaS-AI: eis van de leverancier dat uitlegfunctionaliteit beschikbaar is.
A.8.5 Communicatie met betrokkenen over AI-beslissingen Control
Wat de standaard vraagt: de organisatie stelt processen vast voor communicatie met betrokkenen over AI-gerelateerde beslissingen, inclusief klachtenprocedures en de mogelijkheid om menselijke review aan te vragen.
Achtergrond: betrokkenen moeten niet alleen geinformeerd worden (A.8.2-A.8.3) maar ook de mogelijkheid hebben om te reageren, bezwaar te maken of menselijke review te vragen. Dit sluit aan bij het AVG-recht op menselijke tussenkomst bij geautomatiseerde besluitvorming (Artikel 22 AVG) en bij AI Act-vereisten voor menselijk toezicht.
MKB-implementatie
Richt een klachten- en bezwaarprocedure in voor AI-gerelateerde beslissingen. Publiceer op de website hoe betrokkenen contact kunnen opnemen als ze vragen hebben over AI-beslissingen die hen raken. Zorg dat er een menselijk escalatiepunt is: iemand die de AI-beslissing kan reviewen en indien nodig overrulen. Documenteer ontvangen klachten, de afhandeling en de doorlooptijd. Neem procedure op in contracten en algemene voorwaarden.
Gebruik van AI-systemen
4 controls · Verantwoord operationeel gebruik en monitoring
Categorie A.9 richt zich op het dagelijkse, operationele gebruik van AI-systemen. Waar A.6 de levenscyclus bestrijkt (van ontwerp tot uitfasering), gaat A.9 specifiek over hoe AI-systemen in de praktijk worden ingezet, hoe gebruikers worden begeleid, en hoe menselijk toezicht is ingericht. Dit is voor elke organisatie die AI inzet relevant, ongeacht of je aanbieder of deployer bent.
A.9.2 Beleid voor het gebruik van AI-systemen Control
Wat de standaard vraagt: de organisatie stelt beleid vast voor het verantwoorde gebruik van AI-systemen door medewerkers en andere gebruikers. Dit omvat: toegestaan gebruik, niet-toegestaan gebruik, escalatieprocedures en verantwoordelijkheden van gebruikers.
Achtergrond: gebruikers van AI-systemen handelen vaak op basis van eigen interpretatie als er geen heldere richtlijnen zijn. Zonder gebruiksbeleid kan een medewerker klantdata in een publieke AI-tool invoeren, of AI-output zonder controle als eigen werk presenteren. Gebruiksbeleid voorkomt dit door heldere grenzen te stellen.
MKB-implementatie
Maak een AI-gebruiksrichtlijn voor medewerkers. Inhoud: welke AI-tools zijn goedgekeurd, wat mag je wel/niet invoeren (geen persoonsgegevens in publieke tools), hoe ga je om met AI-output (altijd controleren voor extern gebruik), wanneer escaleer je (bij onverwachte of verontrustende output). Houd het beknopt (een tot twee pagina's) en praktisch. Laat medewerkers de richtlijn ondertekenen. Dit is ook de invulling van de AI Act Artikel 4 literacy-verplichting.
A.9.3 Menselijk toezicht op AI-systemen Control
Wat de standaard vraagt: de organisatie zorgt voor passend menselijk toezicht op AI-systemen, afgestemd op het risico-niveau en de impact van het systeem. Dit omvat: human-in-the-loop, human-on-the-loop, of human-in-command, afhankelijk van de context.
Achtergrond: menselijk toezicht is een kernprincipe van verantwoorde AI en wordt ook door de AI Act geeis (Artikel 14). De vorm van toezicht hangt af van het risico: bij hoog-risico AI moet een mens elke beslissing kunnen beoordelen en overrulen (human-in-the-loop); bij lager risico kan monitoring achteraf volstaan (human-on-the-loop). De organisatie moet bewust kiezen en documenteren.
MKB-implementatie
Bepaal per AI-systeem het passende niveau van menselijk toezicht. Drie niveaus: (1) human-in-the-loop: mens beoordeelt en beslist bij elke AI-output (bijv. bij sollicitatiescreening), (2) human-on-the-loop: mens monitort en kan ingrijpen maar AI opereert autonoom (bijv. bij automatische e-mailclassificatie), (3) human-in-command: mens stelt kaders en monitort op systeemniveau (bijv. bij productaanbevelingen). Documenteer het gekozen niveau met rechtvaardiging. Train de toezichthouders. Evalueer periodiek of het niveau nog past.
A.9.4 Monitoring van AI-systemen in gebruik Control
Wat de standaard vraagt: de organisatie monitort AI-systemen die in gebruik zijn om te waarborgen dat ze blijven functioneren zoals beoogd, dat prestaties binnen acceptabele grenzen blijven, en dat ongewenste effecten tijdig worden gedetecteerd.
Achtergrond: monitoring na ingebruikname is waar veel organisaties tekortschieten. Een AI-systeem dat bij deployment goed presteerde, kan na verloop van tijd verslechteren door veranderende data, veranderende context of systeemwijzigingen. Zonder monitoring wordt dit pas opgemerkt als er klachten komen of als het te laat is.
MKB-implementatie
Stel per AI-systeem een monitoringplan op. Definieer: welke prestatie-indicatoren worden bewaakt (nauwkeurigheid, responstijd, gebruikerstevredenheid, klachten), hoe vaak wordt gemeten (dagelijks, wekelijks, maandelijks), welke drempelwaarden activeren actie (bijv. nauwkeurigheid onder 90% triggert review), wie is verantwoordelijk voor monitoring. Bij MKB: begin met handmatige steekproeven en bouw uit naar geautomatiseerde monitoring naarmate het AI-gebruik groeit. Documenteer bevindingen in de kwartaalrapportage.
A.9.5 Incidentbeheer voor AI-systemen Control
Wat de standaard vraagt: de organisatie stelt een proces vast voor het afhandelen van incidenten gerelateerd aan AI-systemen. Dit omvat: detectie, melding, analyse, correctieve actie en preventieve maatregelen.
Achtergrond: AI-incidenten zijn situaties waarin een AI-systeem ongewenst gedrag vertoont: verkeerde beslissingen, discriminerende output, privacy-schendingen, systeem-uitval. Zonder een gestructureerd incidentproces worden incidenten ad-hoc afgehandeld, worden lessen niet geleerd, en herhaalt het probleem zich. Dit sluit ook aan bij AI Act-meldplichten voor ernstige incidenten.
MKB-implementatie
Maak een AI-incidentprocedure. Inhoud: definitie van AI-incident (wanneer is iets een incident vs. een normale fout), meldingskanaal (intern loket of e-mailadres), triage-criteria (ernst-classificatie), analyse-proces (root cause analyse), corrigerende actie, rapportage aan management, en eventuele externe melding (aan toezichthouder bij ernstige incidenten conform AI Act). Oefen het proces jaarlijks met een scenario. Houd een incidentregistratie bij als bewijs voor de auditor.
Relaties met derden
4 controls · Leveranciers, partners en de AI supply chain
Categorie A.10 adresseert de relaties met externe partijen die betrokken zijn bij AI-systemen: leveranciers van AI-tools, cloud-providers, data-leveranciers, consultants, outsourcing-partners. Voor MKB dat AI als SaaS afneemt, is dit een van de meest relevante categorieen: je bent afhankelijk van derden en moet die afhankelijkheid beheren. De AI Act stelt ook eisen aan de keten (Artikel 25: deployer-verplichtingen ten opzichte van aanbieders); deze controls helpen om aan die eisen te voldoen.
A.10.2 Beleid voor derde-partij-relaties Control
Wat de standaard vraagt: de organisatie stelt beleid vast voor het beheer van relaties met derden die betrokken zijn bij AI-systemen. Dit omvat: criteria voor leveranciersselectie, contractuele vereisten, monitoring van leveranciersprestaties en exit-strategieen.
Achtergrond: AI-systemen van derden zijn een black box: je hebt beperkt zicht op hoe ze werken, welke data ze gebruiken en hoe ze worden onderhouden. Zonder beleid voor derde-partij-management neem je risico's die je niet kunt overzien. Dit is vergelijkbaar met vendor management bij ISO 27001 maar specifiek voor AI-leveranciers.
MKB-implementatie
Stel een AI-leveranciersbeleid op. Minimale eisen bij selectie: de leverancier kan uitleggen hoe het AI-systeem werkt, de leverancier geeft duidelijkheid over data-gebruik (wordt jouw data gebruikt voor training?), de leverancier biedt adequate beveiligingsmaatregelen, er is een SLA die prestatie-eisen vastlegt, er is een exit-strategie (data-export, contractbeeindiging). Evalueer leveranciers jaarlijks. Documenteer de evaluatie. Koppel aan AI Act compliance-roadmap voor leverancierseisen.
A.10.3 Contractuele vereisten voor AI-diensten Control
Wat de standaard vraagt: contracten met derden die AI-gerelateerde diensten leveren, bevatten vereisten die consistent zijn met het AI-beleid en het AIMS van de organisatie. Dit omvat: prestatie-eisen, compliance-eisen, data-afspraken, auditrechten en incident-meldplicht.
Achtergrond: het contract is het primaire instrument om invloed uit te oefenen op leveranciers. Zonder contractuele verankering van AI-vereisten heb je geen formele basis om actie te ondernemen als de leverancier niet aan je verwachtingen voldoet. De AI Act verplicht deployers om bepaalde verplichtingen contractueel door te leggen aan aanbieders (en vice versa).
MKB-implementatie
Neem AI-specifieke clausules op in contracten met AI-leveranciers. Essentieel: prestatie-SLA's (uptime, nauwkeurigheid), data-bepalingen (wie is eigenaar van input/output-data, wordt data gebruikt voor training), meldplicht bij incidenten of significante systeemwijzigingen, auditrecht (of recht op compliance-certificaat), exit-clausule (data-export-mogelijkheid bij contractbeeindiging). Bij bestaande contracten: heronderhandel of voeg een addendum toe. Maak een standaard-clausuleset die je bij elke AI-leverancier toepast.
A.10.4 Monitoring van derde-partij AI-diensten Control
Wat de standaard vraagt: de organisatie monitort de prestaties en compliance van derden die AI-diensten leveren. Dit omvat: periodieke evaluatie van leveranciersprestaties, controle op naleving van contractuele afspraken, en beoordeling van veranderingen bij de leverancier die impact kunnen hebben.
Achtergrond: leveranciers veranderen: ze updaten hun modellen, wijzigen hun dataverwerking, worden overgenomen door andere partijen, of verslechteren in servicekwaliteit. Zonder monitoring merk je dit te laat op. Veel SaaS-AI-leveranciers werken met voortdurende model-updates die je output beinvloeden zonder dat je het weet.
MKB-implementatie
Voer per AI-leverancier een jaarlijkse evaluatie uit. Controleer: voldoet de dienst nog aan de SLA, zijn er incidenten geweest, zijn er significante wijzigingen doorgevoerd, is de leverancier nog financieel stabiel, zijn er compliance-veranderingen (bijv. verlies van certificering). Gebruik de output van je eigen monitoring (A.9.4) als input: als de AI-prestatie daalt, kan dat aan de leverancier liggen. Documenteer de evaluatie en neem actie bij bevindingen (aanspreken, contractaanpassing, leverancierswisseling).
A.10.5 Informatie-uitwisseling met derden Control
Wat de standaard vraagt: de organisatie beheert de uitwisseling van informatie met derden in relatie tot AI-systemen. Dit omvat: welke informatie wordt gedeeld, onder welke voorwaarden, hoe de vertrouwelijkheid wordt gewaarborgd, en hoe de ontvanger de informatie mag gebruiken.
Achtergrond: bij het gebruik van AI-diensten vindt continu informatie-uitwisseling plaats: input-data wordt naar de leverancier gestuurd, output-data wordt ontvangen, logs worden gedeeld voor troubleshooting. Zonder afspraken over informatie-uitwisseling kan gevoelige bedrijfsinformatie of persoonsgegevens onbedoeld bij derden terechtkomen.
MKB-implementatie
Breng per AI-leverancier in kaart welke informatie wordt uitgewisseld. Classificeer de gevoeligheid: bevat het persoonsgegevens, bedrijfsvertrouwelijke informatie, intellectueel eigendom? Stel per classificatie vast: welke beveiligingsmaatregelen gelden (encryptie, toegangscontrole), welke contractuele afspraken er zijn (geheimhouding, data-verwerking), en wie toestemming geeft voor uitwisseling. Bij persoonsgegevens: sluit een verwerkersovereenkomst af conform AVG. Documenteer de informatie-uitwisseling in het leveranciersdossier.
Mapping: Annex A controls en AI Act-artikelen
Welke Annex A-categorieen raken aan welke AI Act-verplichtingen? Deze tabel toont de belangrijkste verbindingen. Gebruik het voor een gecombineerde compliance-aanpak. Zie ook onze uitgebreide vergelijking.
| Annex A categorie | Kernonderwerp | AI Act artikelen | Overlap-niveau |
|---|---|---|---|
| A.2 Beleid voor AI | AI-beleid, verantwoord gebruik | Art. 4 Art. 17 | Gemiddeld. AI Act eist geen formeel beleidsdocument maar wel quality management (Art. 17) en literacy (Art. 4). |
| A.3 Interne organisatie | Rollen, verantwoordelijkheden, rapportage | Art. 17 Art. 26 | Gemiddeld. AI Act eist verantwoordelijkheden als onderdeel van QMS (Art. 17) en deployer-verplichtingen (Art. 26). |
| A.4 Middelen voor AI | Competenties, tools, documentatie | Art. 4 Art. 17 | Gemiddeld. AI literacy (Art. 4) overlapt met competenties. QMS-vereisten raken aan middelen en documentatie. |
| A.5 Impact assessments | Systematische impact-beoordeling | Art. 9 Art. 27 | Hoog. AI Act eist risk management (Art. 9) en FRIA door deployers (Art. 27). Sterke overlap in methodiek en scope. |
| A.6 AI-systeem lifecycle | Ontwerp, test, deployment, monitoring | Art. 9 Art. 15 Art. 17 | Hoog. Lifecycle-management overlapt sterk met technische vereisten (Art. 9, 15) en QMS (Art. 17). |
| A.7 Data voor AI | Datakwaliteit, herkomst, governance | Art. 10 | Hoog. AI Act Art. 10 (data governance) is een directe parallel. Kwaliteitseisen en representativiteit overlappen. |
| A.8 Informatie betrokkenen | Transparantie, uitleg, communicatie | Art. 13 Art. 50 Art. 86 | Hoog. Transparantie-vereisten (Art. 13, 50) en recht op uitleg (Art. 86) zijn directe parallellen. |
| A.9 Gebruik van AI | Menselijk toezicht, monitoring, incidenten | Art. 14 Art. 26 Art. 72 | Hoog. Human oversight (Art. 14), deployer-monitoring (Art. 26) en post-market monitoring (Art. 72) overlappen. |
| A.10 Derde-partij-relaties | Leveranciersbeheer, supply chain | Art. 25 Art. 26 | Gemiddeld. AI Act regelt verantwoordelijkheden in de keten (Art. 25) en deployer-verplichtingen (Art. 26). |
Prioriteitsmatrix voor MKB
Niet alle controls hebben dezelfde urgentie. Deze matrix helpt MKB-organisaties om te prioriteren op basis van impact, haalbaarheid en wettelijke druk. Begin met de hoge prioriteit en bouw uit.
Hoge prioriteit
Eerste 3 maanden · Fundament en wettelijke vereisten
- A.2.2 + A.2.3 AI-beleid en verantwoord-gebruik-beleid. Zonder beleid is er geen basis voor het AIMS.
- A.3.2 Rolverdeling. Iemand moet verantwoordelijk zijn; anders stopt elke control.
- A.5.2 + A.5.3 Impact-assessment-proces en uitvoering. Wettelijk relevant (AI Act FRIA) en basis voor risico-afwegingen.
- A.8.2 + A.8.3 Transparantie en AI-interactie-melding. AI Act Artikel 50 vereist dit al per februari 2025.
- A.9.2 Gebruiksbeleid. Voorkomt dagelijkse risico's bij AI-gebruik door medewerkers.
- A.9.3 Menselijk toezicht. Kernvereiste van zowel ISO 42001 als AI Act.
Gemiddelde prioriteit
Maand 3-6 · Operationele verdieping
- A.3.3 + A.3.4 Rapportage en teamverantwoordelijkheden. Bouwt voort op het fundament van A.3.2.
- A.4.2 + A.4.3 Resource-planning en competenties. Nodig om controls effectief te implementeren.
- A.7.2 + A.7.3 Data-beleid en datakwaliteit. Essentieel als je data aanlevert aan AI-systemen.
- A.9.4 + A.9.5 Monitoring en incidentbeheer. Nodig zodra AI-systemen in productie draaien.
- A.10.2 + A.10.3 Leveranciersbeleid en contracten. Urgent als je AI als SaaS afneemt.
- A.8.4 Uitlegbaarheid. Relevant bij AI-beslissingen die personen raken.
Lagere prioriteit
Maand 6-9 · Verdieping en verfijning
- A.4.4 + A.4.5 Bewustzijn en communicatie. Waardevol maar bouwt voort op eerdere controls.
- A.4.6 + A.4.7 Tools/frameworks en documentatiebeheer. Kan groeien met het AIMS.
- A.5.4 + A.5.5 + A.5.6 Documentatie, monitoring en stakeholder-betrokkenheid bij assessments. Verfijning van A.5.
- A.6.2.2 t/m A.6.2.7 Lifecycle-controls. Alleen hoge prioriteit als je AI zelf ontwikkelt.
- A.7.4 + A.7.5 Data-herkomst en -voorbereiding. Relevant bij eigen data-pipelines.
- A.8.5 Klachtenprocedure. Bouw uit nadat basistrransparantie op orde is.
- A.10.4 + A.10.5 Leveranciersmonitoring en informatie-uitwisseling. Verfijning van A.10.
Let op: deze prioritering geldt voor een gemiddeld MKB dat AI als deployer inzet. Als je AI-aanbieder bent, schuiven de A.6 (lifecycle) en A.7 (data) controls naar hoge prioriteit. Laat Prometheus21 een op maat gemaakte gap-analyse uitvoeren op basis van jouw specifieke situatie. Koppel met onze implementatie-gids voor het volledige traject.
Veelgestelde vragen over Annex A controls
Tien vragen over het selecteren, implementeren en onderhouden van ISO 42001 Annex A controls. Voor de bredere standaard, zie onze ISO 42001 basisgids.
Stel je vraagGerelateerde gidsen
Annex A gap-analyse en implementatie
Laat Prometheus21 een Annex A gap-analyse uitvoeren: per control beoordelen we je huidige situatie, identificeren gaps en bouwen een implementatieplan op maat. Voor MKB dat ISO 42001 wil of Annex A als governance-kader gebruikt.