AI-leveranciersbeoordeling onder ISO 42001: due diligence op AI die je inkoopt

Vraag een willekeurige organisatie naar haar AI-systemen en het antwoord gaat al snel over eigen modellen of een pilot met een taalmodel. Maar in vrijwel elke AI-inventarisatie die wij uitvoeren, blijkt het merendeel van de AI ingekocht te zijn: SaaS-tools met ingebouwde AI-functies, een chatbot van een externe partij, HR-software met kandidaatselectie, of een leverancier die stilletjes AI aan een bestaand product heeft toegevoegd. Dat verschuift het zwaartepunt van AI-governance. De vraag is niet alleen hoe je je eigen modellen beheerst, maar vooral hoe je grip houdt op AI die door anderen wordt gebouwd, getraind en gewijzigd. ISO 42001 stelt daar expliciete eisen aan. In dit artikel leggen we uit wat de norm verwacht en hoe je een werkbare AI-leveranciersbeoordeling inricht.

## Waarom AI-leveranciers een aparte categorie zijn

Leveranciersbeoordeling is voor de meeste organisaties niets nieuws. Wie ISO 27001 heeft of onder NIS2 of DORA valt, beoordeelt leveranciers al op informatiebeveiliging. Toch is AI een wezenlijk andere categorie, om drie redenen.

Ten eerste verandert het product onder je handen. Een leverancier die zijn model bijtraint of vervangt door een nieuwe versie, levert daarmee feitelijk een ander systeem, met mogelijk ander gedrag, andere foutpatronen en andere risico's. Bij klassieke software beheers je dat met changemanagement en releasenotes; bij AI gebeurt het vaak zonder aankondiging.

Ten tweede is de keten langer en ondoorzichtiger. Achter de SaaS-leverancier zit vaak een modelaanbieder, en daarachter trainingsdata waarvan de herkomst niet altijd te achterhalen is. Jouw organisatie blijft intussen verantwoordelijk voor de uitkomsten richting klanten, medewerkers en toezichthouders.

Ten derde raken AI-risico's andere domeinen dan klassieke beveiligingsrisico's: bias in uitkomsten, onjuiste of verzonnen output, ongewenst hergebruik van jouw data voor training, en juridische vragen rond intellectueel eigendom. Een standaard beveiligingsvragenlijst dekt dat niet af.

## Wat ISO 42001 vraagt

ISO 42001 behandelt leveranciers en derde partijen op meerdere plekken. De kern: als AI-systemen of componenten daarvan door derden worden geleverd, moet je organisatie processen hebben om die derden te beoordelen, verantwoordelijkheden in de keten te beleggen en de risico's van geleverde AI te beheersen. Annex A van de norm bevat specifieke beheersmaatregelen voor de relatie met leveranciers en klanten in de AI-waardeketen, waaronder het vastleggen van verantwoordelijkheden tussen partijen en het beoordelen van diensten die AI-componenten bevatten.

Daar komt de EU AI Act bij. Die verordening kent verplichtingen toe aan verschillende rollen in de keten: aanbieders, gebruiksverantwoordelijken, importeurs en distributeurs. Wie een AI-systeem van een leverancier inzet, is doorgaans gebruiksverantwoordelijke en moet onder meer kunnen aantonen dat het systeem volgens de instructies wordt gebruikt en dat er passend toezicht is. Dat kan alleen als je van je leverancier de juiste informatie krijgt. Leveranciersbeoordeling is daarmee niet alleen een normeis, maar ook de plek waar je de informatie ophaalt die je zelf nodig hebt voor compliance.

## Stap 1: weet welke leveranciers AI leveren

Due diligence begint bij de inventarisatie. Neem je bestaande leveranciersregister en contractenoverzicht als vertrekpunt en stel per leverancier de vraag: zit er AI in wat deze partij levert? Let daarbij op stilzwijgende toevoegingen. Leveranciers voegen AI-functies toe via reguliere productupdates, zonder dat inkoop of security daarvan op de hoogte is. Een jaarlijkse uitvraag bij contracteigenaren en een clausule die leveranciers verplicht om nieuwe AI-functionaliteit te melden, voorkomen dat je register veroudert.

## Stap 2: classificeer op risico, niet op contractwaarde

Niet elke AI-leverancier verdient hetzelfde beoordelingsregime. Een spellingscontrole met machine learning is iets anders dan een systeem dat meebeslist over kredietaanvragen of sollicitanten. Classificeer leveranciers op de impact van het AI-systeem: raakt het persoonsgegevens, beïnvloedt het besluiten over mensen, is de output klantzichtbaar, en wat gebeurt er als het systeem fout zit? Die classificatie bepaalt de diepgang van de beoordeling. Let op: de contractwaarde is hier een slechte graadmeter. Een goedkope tool met toegang tot gevoelige data kan een groter risico vormen dan een dure licentie voor een laag-risico toepassing.

## Stap 3: stel de juiste vragen

De kern van de due diligence is een gerichte uitvraag. Vragen die in de praktijk het verschil maken:

Over het model en de data: welke data is gebruikt voor training en hoe is bias beoordeeld? Wordt onze data gebruikt om modellen te trainen, en is dat contractueel uitgesloten? Waar worden onze prompts en outputs opgeslagen en hoe lang?

Over wijzigingen: hoe informeert de leverancier ons over modelwijzigingen of nieuwe versies? Kunnen wij een versie bevriezen of testen voordat een update actief wordt?

Over de keten: welke onderaannemers en modelaanbieders zitten achter de dienst? Gelden onze afspraken ook voor hen?

Over aantoonbaarheid: heeft de leverancier certificeringen zoals ISO 42001 of ISO 27001, of een SOC 2- of ISAE 3402-rapport? Welke logging is beschikbaar zodat wij het gebruik en de uitkomsten kunnen controleren?

Over exit: wat gebeurt er met onze data bij beëindiging, en is er een realistisch alternatief als de dienst wegvalt?

## Stap 4: leg afspraken contractueel vast

Een vragenlijst is een momentopname; het contract regelt de rest van de looptijd. Zorg dat de antwoorden die zwaar wegen in je beoordeling ook als verplichting in het contract of de bijlagen landen. Denk aan een verbod op het trainen met jouw data, een meldplicht bij substantiële modelwijzigingen en incidenten, auditrechten of het recht op periodieke assurance-rapportages, en afspraken over aansprakelijkheid bij schade door onjuiste output. Bij verwerking van persoonsgegevens hoort dit samen te komen met de verwerkersovereenkomst, maar verwar de twee niet: een verwerkersovereenkomst dekt privacy, geen AI-specifieke risico's.

## Stap 5: herbeoordeel doorlopend

AI-leveranciersbeoordeling is geen eenmalige poort maar een cyclus. Plan herbeoordelingen op basis van de risicoclassificatie, bijvoorbeeld jaarlijks voor hoog-risico leveranciers, en herbeoordeel tussentijds bij signalen: een gemelde modelwijziging, een incident, een overname van de leverancier of nieuwe regelgeving. Registreer de uitkomsten in je AIMS, zodat je bij een certificeringsaudit of klantvraag direct kunt laten zien welke leveranciers zijn beoordeeld, wanneer en met welke conclusie.

## Veelgemaakte fouten

Drie patronen zien wij regelmatig misgaan. Organisaties sturen een generieke security-vragenlijst en vinken AI daarmee af, terwijl de AI-specifieke risico's onbevraagd blijven. Ze beoordelen alleen nieuwe leveranciers, terwijl het grootste AI-risico vaak bij bestaande leveranciers zit die functionaliteit hebben toegevoegd. En ze verzamelen antwoorden zonder er consequenties aan te verbinden: een beoordeling zonder acceptatiebesluit, mitigerende maatregelen of contractuele opvolging is administratie, geen risicobeheersing.

Secure Audit ondersteunt organisaties bij het inrichten van AI-governance onder ISO 42001, inclusief leveranciersbeoordeling, AI-inventarisatie en de voorbereiding op certificering. De certificeringsaudit zelf wordt uitgevoerd door een geaccrediteerde certificerende instelling. Neem contact op voor een vrijblijvend gesprek.