Wijzigingsbeheer voor AI-systemen: clausules 6.3 en 8.1 van ISO 42001

Een klassiek wijzigingsproces gaat uit van code. Er wordt iets aangepast, iemand keurt het goed, het gaat naar productie en de release is vastgelegd. Bij AI-systemen klopt die aanname niet meer. Een model kan zich anders gaan gedragen zonder dat er één regel code is veranderd: doordat het opnieuw is getraind op recentere data, doordat een drempelwaarde is bijgesteld, of doordat de leverancier van het onderliggende model een nieuwe versie heeft uitgerold. ISO/IEC 42001 raakt dit onderwerp op twee plaatsen, en organisaties die alleen naar de ene kijken, lopen bij de audit tegen de andere aan.

Twee soorten wijzigingen, twee clausules

Clausule 6.3 gaat over wijzigingen aan het managementsysteem zelf. Als je bepaalt dat het AIMS moet veranderen, voer je die wijziging gepland uit. Je kijkt naar het doel van de wijziging en de mogelijke gevolgen, naar de integriteit van het systeem als geheel, naar de middelen die nodig zijn en naar de verdeling van verantwoordelijkheden en bevoegdheden die eventueel mee moet schuiven.

Clausule 8.1 gaat over de uitvoering. Je plant en beheerst de processen die nodig zijn om aan de AIMS-eisen te voldoen, je stelt criteria vast voor die processen, je beheerst ze conform die criteria en je bewaart vastleggingen waarmee je kunt aantonen dat ze zijn uitgevoerd zoals gepland. Wijzigingen aan AI-systemen in productie vallen hieronder: hertraining, een andere databron, een andere deployment-omgeving, een aangepaste prompt of een nieuwe modelversie van de leverancier.

Wat hier anders is dan bij regulier wijzigingsbeheer

Bij traditionele applicaties zijn de triggers voor een wijziging goed bekend en zit er meestal een change management proces omheen dat werkt. Bij AI-systemen komen er triggers bij die in dat proces niet zijn voorzien.

De eerste is hertraining. Het model wordt opnieuw getraind op data van de laatste maanden, de nauwkeurigheid blijft gelijk of gaat licht omhoog, en niemand ziet aanleiding voor een change request. Dat de foutverdeling over subgroepen is verschoven, valt pas op als iemand daarop meet. De tweede is de externe modelversie. Wie via een API op een model van een leverancier draait, krijgt updates die hij niet zelf plant en soms niet eens ziet. De derde is de configuratie: een drempelwaarde, een systeemprompt of een filter dat iemand op dinsdagmiddag aanpast omdat de uitkomsten te streng waren. Technisch is dat geen release. Voor het gedrag van het systeem is het dat wel.

Criteria vastleggen: wanneer is iets een wijziging

Hier ligt het zwaartepunt van clausule 8.1. Je legt vast wanneer je hertraint, wanneer een driftalarm wordt geëscaleerd, wanneer een systeem wordt uitgefaseerd en welke wijzigingen aanleiding zijn om de risicobeoordeling opnieuw te doen. Ontbreken die criteria, dan is elke beslissing achteraf een kwestie van interpretatie, en dat is precies wat een auditor als afwijking noteert.

Een werkbare indeling maakt onderscheid in drie categorieën. Wijzigingen die het gedrag van het model kunnen veranderen, zoals hertraining, een nieuwe databron of een nieuwe modelversie, vragen om herbeoordeling van de risico's en om hertesten voordat ze naar productie gaan. Wijzigingen die de toepassing raken maar het model niet, zoals een aangepaste gebruikersinterface, volgen het reguliere proces. Wijzigingen die alleen de infrastructuur betreffen, worden gelogd. Zet die indeling op papier en houd hem kort genoeg dat teams hem gebruiken.

Wijzigingen aan het AIMS zelf

Clausule 6.3 wordt vaak vergeten omdat het systeem zelf zelden verandert. Toch komt het vaker voor dan gedacht: de scope uitbreiden met generatieve AI, governanceprocessen aanpassen aan nieuwe regelgeving, of AI-teams herverdelen na een overname. In al die gevallen verwacht de norm dat er vooraf is nagedacht over het doel, de gevolgen voor bestaande beheersmaatregelen, de benodigde middelen en de vraag wie na afloop waarvoor verantwoordelijk is.

Praktisch betekent dat een kort wijzigingsvoorstel, goedkeuring door de AI-governancefunctie of de directie voordat de wijziging ingaat, en een evaluatie achteraf of het gewenste effect is bereikt. Reactief aanpassen aan nieuwe wetgeving zonder transitieplan is een van de afwijkingen die auditors bij deze clausule vaststellen.

Wat een auditor opvraagt

Kies een AI-systeem in productie en volg één wijziging van begin tot eind. Welke versie draait er nu, en welke draaide er drie maanden geleden? Welk experiment ligt ten grondslag aan de huidige versie, en waar staan de resultaten? Wie heeft de wijziging goedgekeurd en op basis waarvan? Is er getest voordat de wijziging live ging, en wat was het terugvalscenario? En de vraag die het meeste oplevert: is de risicobeoordeling na die wijziging bijgewerkt, of staat daar nog de beoordeling van de vorige modelversie in?

Wanneer een organisatie op deze reeks vlot antwoord geeft, zit het proces goed. Blijft het bij een verwijzing naar een ticket zonder inhoudelijke onderbouwing, dan bestaat het wijzigingsbeheer voor AI alleen in naam.

Updates die je niet zelf plant

Uitbestede AI verdient aparte aandacht. Een leverancier die zijn model bijwerkt, wijzigt in feite jouw systeem. Regel drie dingen contractueel: notificatie vooraf bij versiewijzigingen, de mogelijkheid om op een specifieke versie te blijven of een overgangsperiode te krijgen, en een testomgeving waarin je de nieuwe versie kunt beoordelen voordat hij in jouw productieproces landt. Uitbestede AI-processen die buiten de eigen beheersing worden gehouden, is een van de vaste afwijkingen bij clausule 8.1.

Waar het bewijs zit

Voor de audit heb je nodig: de procedure voor wijzigingsbeheer van AI-systemen, de criteria voor hertraining, escalatie en uitfasering, experimentlogs en deploymentvastleggingen, goedkeuringsrecords, de bijgewerkte verantwoordelijkheidsmatrix na organisatorische wijzigingen, en de evaluaties achteraf. Voor het AIMS zelf komen daar de wijzigingsvoorstellen met impactanalyse en de goedkeuringen bij.

Afwijkingen die auditors regelmatig noteren

Modellen worden hertraind en opnieuw uitgerold zonder formele wijzigingsbeheersing. Er zijn geen gedocumenteerde criteria voor de beslissingen die ertoe doen, zoals wanneer je hertraint of wanneer je escaleert bij drift. Operationele vastleggingen zoals experimentlogs en deploymentrecords ontbreken of zijn onvolledig, waardoor niet aantoonbaar is dat processen zijn uitgevoerd zoals gepland. Ontwikkelprocessen verschillen per team zonder gemeenschappelijke standaard. En aan de kant van clausule 6.3: wijzigingen aan het AIMS worden ad hoc doorgevoerd, zonder impactanalyse en zonder dat gewijzigde rollen ergens worden vastgelegd.

Bouw geen apart proces voor AI-wijzigingen naast het bestaande wijzigingsbeheer. Voeg één vraag toe aan het formulier dat je al gebruikt: kan deze wijziging het gedrag van het model veranderen? Is het antwoord ja, dan volgt herbeoordeling van de risico's en hertesten. Dat is een kleinere ingreep dan een tweede proces, en het houdt het bij de mensen die de wijziging daadwerkelijk doorvoeren.