Resources voor AI-systemen: wat Annex A.4 van ISO 42001 vraagt en hoe je het documenteert

Vraag een organisatie welke AI-systemen ze gebruikt en je krijgt meestal wel een lijst. Vraag vervolgens op welke datasets een van die systemen is getraind, welke versie van welk framework eronder ligt en wie het model kan bijtrainen als de huidige data scientist vertrekt, en het wordt stil. Precies dat gat adresseert Annex A.4 van ISO 42001. De controls in dit domein vragen om documentatie van de resources die een AI-systeem nodig heeft, over de hele levenscyclus. In dit artikel lopen we de vijf controls langs, in eigen woorden en met de afwijkingen die wij in de auditpraktijk het vaakst tegenkomen.

Waarom de norm een apart domein wijdt aan resources

Een AI-systeem is meer dan een stuk software. Het gedrag wordt bepaald door de data waarop het is getraind, de tooling waarmee het is gebouwd, de infrastructuur waarop het draait en de mensen die het onderhouden. Valt een van die vier weg of verandert die ongemerkt, dan verandert het systeem mee. Een leverancier die een pretrained model stilletjes bijwerkt, een databron die wegvalt, een GPU-budget dat halverwege het jaar op is: het zijn allemaal gebeurtenissen die de werking van AI raken zonder dat er ook maar één regel eigen code wijzigt.

Documentatie van resources is daarmee de basis onder bijna alles wat het AI-managementsysteem verder doet. Een risicobeoordeling van een AI-systeem waarvan je de databronnen niet kent, is giswerk. Een impactassessment zonder zicht op de traindata kan bias niet serieus beoordelen. En een incidentanalyse zonder versiebeheer van tooling en modellen komt niet verder dan symptoombestrijding.

A.4.2: het overzicht per levenscyclusfase

De eerste control, A.4.2, vraagt om het identificeren en documenteren van de resources die nodig zijn per fase van de levenscyclus van een AI-systeem, en voor de overige AI-activiteiten van de organisatie. Denk aan een resourceoverzicht per systeem dat de vier categorieën afdekt: data, tooling, reken- en opslagcapaciteit en mensen. Dat overzicht ontstaat bij het ontwerp, groeit mee tijdens ontwikkeling en uitrol en blijft actueel tijdens beheer, tot en met de uitfasering.

De vorm is vrij. Een organisatie met drie AI-systemen kan dit prima kwijt in de systeemdocumentatie per systeem; een organisatie met dertig systemen heeft meer aan een centraal register dat aan de AI-inventaris hangt. De valkuil zit in de dekking: wij zien geregeld documentatie die alleen de rekencapaciteit beschrijft en data, tooling en mensen overslaat, of die stopt bij de livegang en de beheerfase negeert.

A.4.3: data als resource

Voor data vraagt de norm om vastlegging van de databronnen die het AI-systeem gebruikt: trainingsdata, validatiedata, testdata en operationele data. Documenteren is hier meer dan opsommen. Een auditor wil zien dat de geschiktheid van de data is beoordeeld: is de dataset representatief voor de doelgroep, volledig, relevant voor het beoogde gebruik en gecontroleerd op bias? Daarnaast horen kwaliteit en beschikbaarheid erbij. Kwaliteit met concrete criteria, zoals juistheid, volledigheid, consistentie en actualiteit. Beschikbaarheid met de vraag wat er gebeurt als een databron wegvalt of de toegang wordt ingetrokken.

Veelvoorkomende afwijking: de dataselectie is informeel verlopen en achteraf niet meer te reconstrueren. Het team weet nog ongeveer welke data in het model zit, maar een beoordeling van representativiteit of bias is nooit vastgelegd. Bij een systeem dat beslissingen over mensen ondersteunt, weegt zo'n bevinding zwaar.

A.4.4: tooling

De toolingcontrol vraagt om documentatie van de tools waarmee AI-systemen worden ontwikkeld, uitgerold en beheerd: ML-frameworks, ontwikkelomgevingen, MLOps-platforms, CI/CD-pijplijnen en monitoringtools. Per tool horen versie, doel, licentievoorwaarden en bekende beperkingen in beeld te zijn. Ook de selectie verdient aandacht: kiest de organisatie tooling op basis van criteria als beveiliging, ondersteuning en volwassenheid, of op basis van wat een individuele ontwikkelaar toevallig kent?

Open source vraagt hier extra zorg. Veel AI-stacks leunen zwaar op open-sourcebibliotheken, en dat is prima, zolang er iemand naar kwetsbaarheden en licenties kijkt. De afwijking die wij hier het vaakst zien: verschillende teams gebruiken verschillende versies van dezelfde frameworks, zonder centraal beeld en zonder proces voor updates en uitfasering van tooling.

A.4.5: systeem- en rekencapaciteit

AI-workloads stellen andere eisen aan infrastructuur dan klassieke applicaties. Trainen vraagt piekcapaciteit aan GPU's of TPU's, inference vraagt voorspelbare latency, en beide vreten opslag voor datasets, modelartefacten en logging. A.4.5 vraagt om documentatie van die behoeften per systeem: verwerkingscapaciteit voor training en inference, opslag en netwerkeisen.

In de praktijk hoort daar meer omheen: monitoring van gebruik en beschikbaarheid, capaciteitsplanning die meegroeit met de workload en maatregelen voor beschikbaarheid en herstel bij productiesystemen. En kostenbeheersing, want cloudkosten voor AI kunnen hard oplopen. Een organisatie die haar GPU-uitgaven niet volgt, ontdekt het probleem meestal pas op de factuur.

A.4.6: mensen

De laatste control in het domein gaat over menselijke resources: documenteer welke mensen en competenties nodig zijn voor ontwikkeling, uitrol, beheer, wijzigingsbeheer, onderhoud, overdracht en uitfasering van het AI-systeem, en voor verificatie en integratie. Dat klinkt als een doublure met clausule 7.2, maar de invalshoek verschilt. Clausule 7.2 borgt dat mensen competent zijn; A.4.6 koppelt de benodigde rollen en competenties aan het systeem zelf.

Het gevoeligste punt is hier de sleutelpersoonafhankelijkheid. Bij veel organisaties rust de kennis van een model bij één of twee mensen. Vertrekt die ene data scientist, dan kan niemand het model nog bijtrainen of de pijplijn repareren. A.4.6 dwingt je die afhankelijkheid zichtbaar te maken, zodat je er iets aan kunt doen met kennisdeling, documentatie of opvolgingsplanning.

Afwijkingen op een rij

De rode draad in de afwijkingen die wij bij audits op dit domein zien: resources worden ad hoc geregeld en de documentatie ontbreekt of veroudert. Concreet: er is geen resourceoverzicht per AI-systeem. De documentatie beslaat alleen rekencapaciteit. Datageschiktheid is nooit beoordeeld op representativiteit of bias. Er is geen toolinginventaris en geen versiebeheer over teams heen. Open-sourcecomponenten zijn niet beoordeeld op kwetsbaarheden en licenties. Capaciteitsplanning ontbreekt, kosten worden niet gevolgd. En sleutelpersoonrisico's zijn bekend bij iedereen behalve op papier.

Welke documenten een auditor verwacht

Reken op de volgende stukken: een resourceregister of resourceoverzicht per AI-systeem, een datainventaris met geschiktheids- en kwaliteitsbeoordelingen, een toolinginventaris met versies en beperkingen, specificaties en capaciteitsplannen voor infrastructuur, en een overzicht van benodigde rollen en competenties per systeem, inclusief maatregelen tegen sleutelpersoonafhankelijkheid. Bestaande documenten tellen mee: een DPIA die databronnen beschrijft of een CMDB die infrastructuur vastlegt, hoeft niet overgedaan te worden, zolang de koppeling met het AI-systeem gelegd is.

Praktische aanpak

Begin bij je AI-inventaris en werk per systeem de vier categorieën af. Voor de meeste organisaties is dat een kwestie van bestaande kennis vastleggen in plaats van nieuw onderzoek doen: de teams weten welke data, tooling en infrastructuur ze gebruiken, alleen staat het nergens bij elkaar. Plan daarna de actualisatie in: koppel het bijwerken van het resourceoverzicht aan wijzigingsbeheer, zodat een nieuwe databron of frameworkupgrade automatisch een update van de documentatie betekent.

In het Secure Audit platform hangt de guidance voor A.4.2 tot en met A.4.6 direct aan de normelementen, met per control de interviewvragen, verwachte documenten en veelvoorkomende afwijkingen. Wie zijn interne audit op het AIMS voorbereidt, ziet daarmee vooraf waar een auditor op gaat letten.