Data voor AI-systemen: de vijf controls van ISO 42001 Annex A.7

Een model dat traint op scheve, verouderde of onrechtmatig verkregen data, levert uitkomsten op met precies die gebreken. Daar helpt geen mooie architectuur tegen. Annex A.7 van ISO 42001 pakt dit bij de bron aan met vijf controls over data voor AI-systemen: datamanagement bij ontwikkeling (A.7.2), verwerving van data (A.7.3), datakwaliteit (A.7.4), dataherkomst (A.7.5) en datavoorbereiding (A.7.6). In dit artikel lopen we ze langs zoals een auditor dat doet: wat wordt er gevraagd, welke vragen kun je verwachten en waar gaat het in de praktijk mis.

Waar Annex A.7 over gaat

Annex A van ISO 42001 is opgedeeld in domeinen. Het datadomein zit tussen de controls over de levenscyclus van AI-systemen (A.6) en de informatievoorziening aan belanghebbenden (A.8) in, en dat is geen toeval. De data bepaalt wat het systeem kan, en de documentatie erover bepaalt wat je aan gebruikers en toezichthouders kunt uitleggen. Zoals bij alle Annex A-controls bepaal je via de risicobeoordeling en de Statement of Applicability welke controls van toepassing zijn. Voor organisaties die AI-systemen ontwikkelen of aanpassen, vallen alle vijf vrijwel altijd binnen scope. Wie alleen kant-en-klare AI-diensten afneemt, komt er niet volledig onderuit: ook een gekoppelde kennisbank of een set finetune-voorbeelden is data voor een AI-systeem.

A.7.2: datamanagement voor ontwikkeling

De eerste control vraagt om gedocumenteerde en werkende processen voor het beheren van data waarmee AI-systemen worden ontwikkeld of verbeterd. In een interview vraagt een auditor bijvoorbeeld hoe trainings-, validatie- en testdata worden gescheiden en hoe wordt voorkomen dat testdata in de training lekt. Dat klinkt technisch, maar de consequentie is heel praktisch: wie datalekkage tussen die sets heeft, meet prestaties die in productie niet waargemaakt worden.

Een tweede terugkerende vraag gaat over reproduceerbaarheid. Kun je een training herhalen met exact dezelfde data? Daarvoor is versiebeheer op datasets nodig, met een vastgelegde koppeling tussen dataversie en modelversie. Bij organisaties waar datamanagement informeel is geregeld, zien we steeds dezelfde afwijking terug: er bestaat geen procedure voor het samenstellen en splitsen van datasets, en niemand kan achteraf reconstrueren op welke data een model precies getraind is. De geschiktheid van de data hoort daarnaast per project beoordeeld te worden: is deze data relevant voor het doel, representatief voor de doelgroep en gecontroleerd op schadelijke vertekening?

A.7.3: verwerving van data

De tweede control gaat over de vraag waar je data vandaan haalt en of dat mag. Voor elke databron hoort een rechtsgrond vastgelegd te zijn, zeker wanneer er persoonsgegevens in het spel zijn. Bij data van derden verwacht de norm due diligence: waar komt deze data vandaan, hoe is die verzameld, wat is de kwaliteit en voldoet de verzameling aan de wet? Contracten met dataleveranciers horen gebruiksrechten, beperkingen en kwaliteitsafspraken te bevatten.

Het scherpste voorbeeld in de praktijk is gescrapete of publiek beschikbare data. Publiek vindbaar betekent niet vrij bruikbaar. Een auditor wil zien dat het gebruik van zulke bronnen juridisch en ethisch beoordeeld is voordat de data een trainingspipeline in gaat. De veelvoorkomende afwijking is hier voorspelbaar: data wordt ad hoc verzameld, zonder vastgelegde rechtsgrond en zonder beoordeling vooraf. Dat is niet alleen een auditbevinding. Het kan ook betekenen dat een model opnieuw getraind moet worden omdat de basis eronder niet houdbaar is.

A.7.4: kwaliteit van data

Control A.7.4 vraagt om gedefinieerde kwaliteitseisen voor de data die AI-systemen gebruiken, en om aantoonbare naleving daarvan. Bruikbare criteria zijn juistheid, volledigheid, consistentie tussen bronnen, actualiteit en representativiteit. Het venijn zit in het woord aantoonbaar. Kwaliteitscriteria op papier zijn snel geschreven; de auditor vraagt door naar metingen, drempelwaarden en wat er gebeurt als een drempel wordt overschreden.

In een volwassen inrichting zitten geautomatiseerde kwaliteitscontroles in de datapipeline, met signalering richting het team als de kwaliteit onder de afgesproken grens zakt. De meest voorkomende afwijking is dat kwaliteit alleen tijdens de ontwikkeling wordt beoordeeld. Na livegang verandert de instroom van data, en een systeem dat vorig jaar op goede data draaide, kan nu op vervuilde invoer werken zonder dat iemand het merkt. Kwaliteitsbewaking hoort daarom door te lopen in de beheerfase, en gevonden problemen horen gedocumenteerd te worden inclusief het effect op de uitkomsten van het systeem.

A.7.5: herkomst van data

Dataherkomst wordt nogal eens verward met datakwaliteit, maar het is een eigen onderwerp. Herkomst gaat over de geschiedenis van de data: uit welke bron komt die, hoe is die verzameld, welke bewerkingen zijn toegepast en wie heeft er wanneer aan gezeten. De norm vraagt om een vastgelegd proces om die herkomst bij te houden gedurende de hele levensduur van de data en het AI-systeem.

De lakmoesproef die wij als auditor gebruiken: pak een willekeurige dataset uit de trainingspipeline en vraag het team die terug te herleiden naar de oorspronkelijke bron, inclusief alle tussenliggende stappen zoals opschoning, aggregatie en anonimisering. Lukt dat niet, dan is er werk te doen. Herkomstregistratie hoort ook bij te blijven wanneer data wordt aangevuld of gecorrigeerd; een register dat na de eerste oplevering nooit meer is bijgewerkt, telt bij een audit niet als werkend proces. Goede herkomstregistratie maakt het mogelijk om vanuit een modeluitkomst terug te redeneren naar de brondata, wat bij incidenten en bij vragen van toezichthouders veel tijd scheelt.

A.7.6: voorbereiding van data

De laatste control gaat over alles wat er met data gebeurt voordat een model die ziet: opschonen, labelen, verrijken en het construeren van kenmerken. De norm vraagt om vastgelegde criteria voor de keuze van voorbereidingstechnieken. Waarom zijn ontbrekende waarden op deze manier behandeld? Waarom deze labelinginstructies?

Labeling verdient hier aparte aandacht. Wie handmatig laat labelen, hoort labelrichtlijnen te hebben, getrainde beoordelaars en een kwaliteitscontrole, bijvoorbeeld door de overeenstemming tussen beoordelaars te meten. Zonder die controle is het label de mening van een individuele beoordelaar, en die mening traint het model. Ook dataverrijking hoort beoordeeld te worden op het risico dat er artefacten of vertekening insluipen. De afwijking die we hier het vaakst zien: de voorbereiding is wel gebeurd, maar nergens gedocumenteerd. Het resultaat is een model waarvan niemand meer kan uitleggen hoe de trainingsdata tot stand kwam.

Wat de auditor opvraagt

De rode draad door alle vijf de controls is dezelfde: procedures op papier, en bewijs dat ze werken. Concreet gaat het om een datamanagementprocedure voor AI-ontwikkeling, documentatie per dataset zoals datasheets of data cards, vastgelegde rechtsgronden en due-diligencedossiers voor externe databronnen, kwaliteitscriteria met bijbehorende meetresultaten, herkomstregistratie met bewerkingslogs, en documentatie van labeling- en voorbereidingskeuzes. In de interne-auditmodule van ons platform is deze guidance per control beschikbaar, met interviewvragen en verwachte documenten, zodat je de interne audit op A.7 kunt draaien voordat de certificerende instelling langskomt.

Begin bij het model dat er al is

Ons advies voor wie hiermee start: neem het belangrijkste AI-systeem dat nu draait en beantwoord voor dat ene systeem de vijf vragen van dit domein. Waar komt de data vandaan, mag dat, is de kwaliteit gemeten, is de herkomst herleidbaar en is de voorbereiding gedocumenteerd? De gaten die dan zichtbaar worden, zijn vrijwel altijd dezelfde gaten die voor de andere systemen gelden. Dat maakt de aanpak voor de rest van het portfolio een kwestie van herhalen in plaats van opnieuw uitvinden.