De AI system life cycle in ISO 42001: wat Annex A.6 per fase van je vraagt

Van alle Annex A-domeinen in ISO/IEC 42001 is A.6 het domein dat het dichtst op het ontwikkelwerk zit. Waar het beleid (A.2) en de rollen (A.3) over de organisatie gaan, volgt A.6 het AI-systeem zelf: van de doelstellingen die je vooraf stelt tot de logbestanden die je bijhoudt als het systeem draait. Teams die al jaren modellen bouwen, hebben veel van deze stappen informeel op orde. De norm vraagt iets anders: dat je per fase kunt laten zien hoe je het doet en waarom. Dit artikel loopt de controls van A.6 langs in de volgorde van de levenscyclus, in eigen woorden en met de afwijkingen die wij als auditor het vaakst tegenkomen.

Voordat er code is: doelstellingen en ontwerpprocessen (A.6.1.2 en A.6.1.3)

De levenscyclus begint niet bij de eerste regel code. Control A.6.1.2 vraagt om gedocumenteerde doelstellingen voor verantwoorde ontwikkeling, en die moeten meetbaar zijn. "Wij ontwikkelen AI verantwoord" is een intentie, geen doelstelling. Een bruikbare doelstelling luidt bijvoorbeeld: elk model met impact op personen doorloopt vóór uitrol een biastest op vooraf vastgelegde kenmerken, met gedocumenteerde acceptatiecriteria. Zulke doelstellingen moeten aansluiten op het AI-beleid, gecommuniceerd zijn aan de ontwikkelteams en gevolgd worden, bijvoorbeeld via een dashboard of periodieke rapportage.

Control A.6.1.3 vraagt vervolgens om een gedocumenteerd proces voor verantwoord ontwerp. In de praktijk betekent dit dat je ontwerpfase een aantal vaste stappen kent: een ethische screening aan het begin, het vertalen van fairnesseisen naar concrete ontwerpcriteria, het bepalen van de benodigde uitlegbaarheid en het ontwerpen van menselijk toezicht (human-in-the-loop of human-on-the-loop). De afwijking die wij hier het vaakst zien: de ethische toets vindt pas plaats als het systeem al gebouwd is, en toezichtmechanismen worden achteraf ingebouwd. Dat werkt zelden goed. Wie pas na de bouw bedenkt dat een mens moet kunnen ingrijpen, ontdekt dat de architectuur daar niet op is ingericht.

Eisen vastleggen (A.6.2.2)

Voor elk nieuw AI-systeem, en voor elke wezenlijke wijziging, vraagt de norm gedocumenteerde eisen. De valkuil is hier dat eisen alleen functioneel en technisch zijn: wat het systeem moet doen, hoe snel en hoe accuraat. Een auditor kijkt of er ook eisen staan over fairness (welke metriek, welke drempel), uitlegbaarheid, menselijk toezicht en datakwaliteit, en of de uitkomsten van de AI-risicobeoordeling (6.1.2) en de impactassessment (6.1.4) in de eisen terugkomen. Herleidbaarheid is het sleutelwoord: bij elke eis moet duidelijk zijn waar hij vandaan komt. Een risicobeoordeling die een biasrisico benoemt terwijl de systeemeisen daar niets over zeggen, is een klassieke bevinding.

Het ontwerp documenteren (A.6.2.3)

Ontwerpdocumentatie beantwoordt twee vragen: wat is er gekozen en waarom. Denk aan de modelarchitectuur en de reden voor die keuze, de opbouw van de datapijplijn, de trainingsaanpak en de evaluatiemethodiek. Bij veel organisaties bestaat het ontwerp alleen in de code en in de hoofden van de ontwikkelaars. Dat wreekt zich bij personeelsverloop en bij elke audit. De norm verwacht bovendien dat de documentatie meegroeit: een ontwerpdocument dat de situatie van twee hertrainingen geleden beschrijft, telt niet als actueel.

Verificatie en validatie (A.6.2.4)

Testen voor uitrol is meer dan controleren of het model accuraat is. De norm vraagt gedefinieerde verificatie- en validatiemaatregelen met vooraf vastgelegde criteria. In een volwassen inrichting omvat dat functionele tests, prestatietests, fairnesstests per gedefinieerde groep, robuustheidstests met randgevallen en adversarial input, en veiligheidstests binnen vastgestelde grenzen. Twee punten verdienen aandacht. Ten eerste onafhankelijkheid: bij systemen met een hoger risico hoort de validatie niet bij hetzelfde team te liggen dat het model bouwde. Ten tweede de slaag-zakcriteria: zonder vooraf gedefinieerde drempels wordt de uitrolbeslissing een gevoelskwestie. En wijzigt het systeem wezenlijk, dan moet de validatie opnieuw.

Uitrol (A.6.2.5)

Voor de uitrol vraagt de norm een gedocumenteerd plan en een controle dat aan de voorwaarden is voldaan. Praktisch betekent dit een pre-deploymentchecklist: is de risicobeoordeling actueel, is de impactassessment afgerond, is de validatie geslaagd, staat de documentatie (model card, datasheet) klaar, is de monitoring ingericht en is de terugvalprocedure getest? Wie mag goedkeuren, moet vastliggen. De afwijking die wij hier tegenkomen is voorspelbaar: elke ontwikkelaar kan naar productie deployen, zonder gate. Gefaseerd uitrollen (canary releases, schaduwdraaien naast het oude model) beperkt het risico van een nieuwe modelversie aanzienlijk, en een geteste rollback zorgt dat je binnen minuten terug kunt naar de vorige versie.

Beheer en monitoring (A.6.2.6)

Na de uitrol begint het echte werk. De norm vraagt dat je de elementen voor de doorlopende werking vastlegt, waaronder monitoring, onderhoud, updates en support. Monitoring die alleen uptime en foutpercentages meet, mist waar het bij AI om draait: drift. Data drift (de invoer verandert), model drift (de prestaties lopen terug) en concept drift (de werkelijkheid waar het model op is getraind verschuift) blijven zonder detectiemechanisme onzichtbaar tot gebruikers gaan klagen. Volwassen monitoring volgt daarnaast fairnessmetrieken in de tijd en het percentage keren dat een mens de uitkomst overruled. Minstens zo belangrijk als het meten is de terugkoppeling: aanhoudende drift moet ergens toe leiden, zoals hertraining, een nieuwe risicobeoordeling of in het uiterste geval uitfasering van het systeem.

Technische documentatie voor belanghebbenden (A.6.2.7)

Control A.6.2.7 vraagt te bepalen welke technische documentatie elke categorie belanghebbenden nodig heeft: gebruikers, partners, toezichthouders. De twee bekendste vormen zijn de model card (doel, architectuur, trainingsdata, prestaties, beperkingen, fairnessevaluaties en beoogd gebruik van het model) en de datasheet (herkomst, verzamelmethode, bewerkingen en bekende beperkingen van een dataset). Voor hoog-risico-AI-systemen onder de EU AI Act sluit dit direct aan op de technische-documentatieverplichtingen daar; wie A.6.2.7 goed inricht, legt dat fundament meteen. Versiebeheer en een centrale vindplaats zijn geen luxe: documentatie verspreid over persoonlijke schijven telt bij een audit nauwelijks mee.

Logging (A.6.2.8)

De laatste control in de keten vraagt om vastlegging van gebeurtenissen, minimaal zolang het systeem in gebruik is. Goede AI-logging legt per beslissing vast: de invoer, de uitvoer, de gebruikte modelversie, de confidencescore en eventuele menselijke overrides. De toets die wij als auditor hanteren is eenvoudig: kun je van een specifieke beslissing van drie maanden geleden reconstrueren hoe die tot stand kwam? Infrastructuurlogs (toegang, errors) beantwoorden die vraag niet. Logs horen bovendien beschermd te zijn tegen manipulatie en een bewaartermijn te hebben die past bij de regelgeving; voor hoog-risicosystemen onder de EU AI Act gelden daar eigen eisen.

De rode draad

A.6 komt neer op één eis: dat de levenscyclus van je AI-systemen bestaat uit gedefinieerde stappen met bewijs, in plaats van uit de goede gewoonten van je beste ontwikkelaars. De interne-auditmodule van het Secure Audit platform bevat per A.6-control het criterium, de interviewvragen die een auditor stelt, een voorbeeld van een goede invulling en de documenten die je klaar wilt hebben. Daarmee toets je je eigen levenscyclus voordat de certificerende instelling het doet. Neem contact op voor een vrijblijvend gesprek.