De scope van je AIMS bepalen: clausule 4.3 van ISO 42001 in de praktijk

Elke beslissing in een ISO 42001-traject hangt af van één document: de scopeverklaring. De scope bepaalt welke AI-systemen onder je risicobeoordelingen vallen, welke afdelingen worden geaudit en waar je certificaat straks iets over zegt. Te ruim gekozen wordt het traject onwerkbaar, te krap gekozen levert het afwijkingen op bij de certificeringsaudit en een certificaat dat weinig waard is. Clausule 4.3 van ISO/IEC 42001 stelt de eisen aan die keuze. In dit artikel lopen we door wat de clausule vraagt, wat je opneemt, wat je kunt uitsluiten en welke fouten wij in de praktijk tegenkomen.

Wat clausule 4.3 vraagt

Clausule 4.3 verplicht je om de grenzen en de toepasselijkheid van het AI-managementsysteem te bepalen en zo de scope vast te stellen. Die bepaling staat niet op zichzelf. De norm wil dat je de scope baseert op de contextanalyse uit clausule 4.1 (welke externe en interne factoren zijn relevant, welke rol vervul je: aanbieder, ontwikkelaar of gebruiker van AI) en op de eisen van belanghebbenden uit clausule 4.2, inclusief wettelijke en contractuele verplichtingen. De scope moet beschikbaar zijn als gedocumenteerde informatie. Een mondelinge afspraak of een zin in een offerte volstaat niet.

In de praktijk betekent dit dat een goede scopeverklaring drie vragen beantwoordt. Welke AI-systemen vallen eronder? Welke organisatieonderdelen en locaties zijn betrokken? En welke eisen, intern en extern, zijn daarbij van toepassing?

Begin met een inventarisatie

Je kunt geen scope bepalen over systemen die je niet kent. De eerste stap is daarom een AI-inventarisatie: een register van alle AI-systemen die de organisatie ontwikkelt, inkoopt of gebruikt. Vergeet daarbij drie categorieën niet. AI-functionaliteit die als onderdeel van ingekochte SaaS-diensten binnenkomt, bijvoorbeeld een scoringsfunctie in je CRM. Generatieve AI-tools die medewerkers zelf zijn gaan gebruiken zonder centraal besluit, ook wel shadow AI. En experimentele modellen van eigen teams die nog niet in productie draaien maar wel met echte data werken.

Pas als dat register er ligt, kun je onderbouwd kiezen wat binnen de scope valt. Overigens is zo'n register ook los van de scopebepaling nuttig: de auditor gebruikt het om te toetsen of de scope de werkelijkheid dekt.

Wat je opneemt in de scopeverklaring

Een scopeverklaring die bij een audit standhoudt, benoemt de AI-systemen concreet: bij naam, met het type systeem (bijvoorbeeld machine learning voor kredietscoring, een taalmodel-toepassing voor klantcontact, regelgebaseerde besliskunde) en met de levenscyclusfasen die eronder vallen, van ontwikkeling en inzet tot beheer en uitfasering. Daarnaast beschrijft de verklaring de betrokken organisatieonderdelen (het datateam, IT-beheer, de businessafdelingen die AI gebruiken), de locaties en de toepasselijke eisen, zoals de EU AI Act of contractuele afspraken met klanten.

De rol die je per systeem vervult hoort daar expliciet bij. Ben je aanbieder, ontwikkelaar of gebruiker? Die rol bepaalt later welke Annex A-maatregelen zwaar wegen en hoe je risicobeoordelingen inricht. Een organisatie die alleen AI van derden inzet heeft een ander risicoprofiel dan een partij die zelf modellen traint, en de scopeverklaring is de plek waar dat onderscheid begint. De directie stelt de scope formeel vast; leg die goedkeuring vast.

Wat je mag uitsluiten

Uitsluiten mag, mits onderbouwd en gedocumenteerd. Een gangbaar voorbeeld is een experimenteel prototype dat nog niet in productie draait en geen echte persoonsgegevens verwerkt: dat kun je buiten de scope houden met een duidelijke redenering, inclusief het moment waarop het alsnog binnen de scope komt (bijvoorbeeld bij livegang).

Twee uitsluitingen gaan in de praktijk vaak mis. De eerste is ingekochte AI. Dat een leverancier het systeem heeft gebouwd, betekent niet dat het buiten jouw AIMS valt: jij zet het in, jij bent verantwoordelijk richting gebruikers en betrokkenen. AI-systemen van derden die je inzet of integreert in je eigen diensten horen binnen de scope. De tweede is shadow AI. Tools die afdelingen zelf hebben geadopteerd vallen buiten het zicht van de scopeverklaring, terwijl daar juist risico zit. Een scope die alleen de officieel goedgekeurde systemen dekt, beschrijft een papieren werkelijkheid.

De scope actueel houden

Een scopeverklaring is geen eenmalig document. De norm verwacht dat je de scope herziet wanneer de situatie verandert. Concrete aanleidingen: een nieuw AI-systeem gaat in productie, een bestaand systeem wordt ingrijpend gewijzigd, er komt nieuwe regelgeving bij, of de organisatiegrenzen verschuiven door een overname of reorganisatie. Koppel de scopeherziening aan een bestaand ritme, bijvoorbeeld de managementreview, en aan het wijzigingsproces voor AI-systemen, zodat een nieuwe toepassing niet pas bij de volgende jaarcyclus opvalt.

Veelvoorkomende afwijkingen

Bij audits op clausule 4.3 zien wij steeds dezelfde patronen terugkomen. De scopeverklaring is vaag: "alle AI-activiteiten van de organisatie", zonder te benoemen welke systemen, levenscyclusfasen of afdelingen daaronder vallen. Ingekochte AI-systemen die de organisatie inzet, zijn niet in de scope opgenomen. Shadow AI valt volledig buiten beeld. De scope is niet bijgewerkt na de komst van nieuwe systemen, met name generatieve AI-tools. En voor uitgesloten systemen ontbreekt een gedocumenteerde onderbouwing.

Elk van deze punten is bij een certificeringsaudit een reële bron van afwijkingen, en elk ervan is te voorkomen met een goede inventarisatie en een concreet geformuleerde verklaring.

Welke documenten de auditor verwacht

Reken erop dat een auditor rond clausule 4.3 vraagt naar: de scopeverklaring zelf, het AI-register of de AI-inventarisatie, een organogram waaruit de AI-gerelateerde functies blijken, het AIMS-handboek of beleidsdocument waarin de scope terugkomt, en de vastlegging van de directiegoedkeuring. Sluit de scopeverklaring aan op wat de auditor in interviews en systeemdocumentatie aantreft, dan is clausule 4.3 doorgaans snel afgerond. Wringt het daar, dan werkt dat door in de rest van de audit.

Hulp nodig bij het afbakenen van je AIMS? Het Secure Audit platform bevat een interne-auditmodule met per ISO 42001-clausule concrete criteria, interviewvragen en voorbeelden van goede invulling en veelvoorkomende afwijkingen, ook voor de scopebepaling. Neem contact op voor een vrijblijvend gesprek.