Due diligence op AI-leveranciers: Een praktische gids
Bij het integreren van kunstmatige intelligentie (AI) en Large Language Models (LLM's) binnen bedrijfsprocessen is de afhankelijkheid van externe leveranciers aanzienlijk. Waar traditionele softwareleveranciers relatief voorspelbare risicoprofielen hebben, introduceren AI-leveranciers nieuwe variabelen op het gebied van data-eigendom, model-veroudering, intellectueel eigendom en computationele stabiliteit. Het uitvoeren van een gestructureerd due-diligenceonderzoek is daarom essentieel voordat een definitieve samenwerking of contractering plaatsvindt.
Definitie: AI-leveranciers-due-diligence is het diepgaande, systematische onderzoek naar de financiële, juridische, technische en operationele aspecten van een AI-aanbieder. Het doel is het identificeren van risico's vóórdat contractuele verplichtingen worden aangegaan.
Leverancierskeuze versus Due Diligence
Het is belangrijk om een duidelijk onderscheid te maken tussen het selectieproces en het due-diligenceproces. Bij het selecteren van een partner ligt de nadruk op functionele eisen, operationele behoeften en de strategische fit met de organisatie. Voor dit initiële traject kan gebruik worden gemaakt van de stappen beschreven in de gids voor een AI-leverancier kiezen.
Due diligence begint pas wanneer de voorkeursleverancier (of een shortlist van kandidaten) in kaart is gebracht, maar nog vóórdat er definitieve contracten worden ondertekend. Waar de selectiefase antwoord geeft op de vraag: *"Kan deze leverancier onze problemen oplossen?"*, geeft due diligence antwoord op de vraag: *"Vormt deze leverancier een structureel risico voor onze bedrijfsvoering, reputatie of compliance?"*. Dit onderzoek raakt nauw aan de interne risicobeoordeling die organisaties zelf moeten uitvoeren, zoals uiteengezet in het dossier over de AI-risicoanalyse en DPIA.
De vier pijlers van AI-due-diligence
Een compleet due-diligenceonderzoek is opgebouwd uit vier specifieke onderzoeksgebieden. Elk gebied vereist specifieke expertise vanuit de eigen organisatie of externe adviseurs.
1. Financieel onderzoek
Veel aanbieders van innovatieve AI-oplossingen zijn jonge ondernemingen of start-ups met een hoge 'burn rate' (de snelheid waarmee durfkapitaal wordt verbruikt). Het financiële onderzoek moet inzicht geven in de continuïteit van de leverancier op de middellange termijn. Belangrijke controlepunten zijn:
- Cashpositie en runway: Beschikt de leverancier over voldoende liquide middelen om de komende 18 tot 24 maanden operationeel te blijven zonder dat er nieuwe investeringsrondes nodig zijn?
- Omzetconcentratie: Is de leverancier voor een onevenredig groot deel van de inkomsten afhankelijk van één of twee grote klanten? Het wegvallen van zo’n klant kan de stabiliteit van de leverancier direct in gevaar brengen.
- Prijsontwikkeling en infrastructuurkosten: AI-modellen vereisen aanzienlijke rekenkracht (GPU-capaciteit). Onderzoek of de marges van de leverancier houdbaar zijn bij schaalvergroting, of dat prijsstijgingen op korte termijn te verwachten zijn.
2. Juridisch en Compliance
De juridische due diligence richt zich met name op intellectueel eigendom, privacywetgeving en de herkomst van data. Dit is een van de meest complexe gebieden vanwege de veranderende wetgeving rondom AI-systemen.
- Licentiestructuren van modellen: Maakt de leverancier gebruik van open-source modellen, propriëtaire modellen of een hybride vorm? Het is cruciaal om de exacte voorwaarden te begrijpen van de onderliggende systemen. Voor een diepgaande analyse hiervan wordt verwezen naar het artikel over modelkaarten en licenties lezen.
- Trainingsdata en auteursrecht: Vraag schriftelijke garanties over de herkomst van de data waarmee de modellen zijn getraind. Is er sprake van mogelijke inbreuk op het auteursrecht? Biedt de leverancier volledige vrijwaring tegen claims van derden wegens inbreuk op intellectueel eigendom?
- AVG-rollen (GDPR): Stel vast wie de verwerkingsverantwoordelijke is en wie de verwerker. Hoe wordt omgegaan met data die door gebruikers als prompts worden ingevoerd? Worden deze prompts gebruikt voor de verdere training van de modellen van de leverancier? Dit laatste dient in zakelijke contexten te allen tijde uitgesloten te worden.
3. Technisch onderzoek
Bij het technische onderzoek wordt gekeken naar de robuustheid van de software-architectuur, de integratiemogelijkheden en de beveiliging. Dit gaat verder dan een standaardsoftware-audit.
- Architectuur en afhankelijkheden: Is het systeem modulair opgebouwd? Wat gebeurt er als een onderliggende API-koppeling naar een grote LLM-provider uitvalt?
- Informatiebeveiliging: Hoe zijn data in rust (at rest) en data in beweging (in transit) versleuteld? Welke mechanismen zijn aanwezig om prompt-injection en andere AI-specifieke kwetsbaarheden te voorkomen? Zie voor een overzicht van deze risico's het artikel over AI-security voor bedrijven.
- Incidenten- en uptimegeschiedenis: Vraag naar historische gegevens over systeemuitval en beveiligingsincidenten.
4. Operationeel onderzoek
De operationele pijler beoordeelt de capaciteit van de leverancier om de geleverde diensten structureel en volgens afspraak te ondersteunen.
- Support en escalatiepaden: Welke ondersteuningsniveaus (SLAs) worden gegarandeerd? Is er 24/7 support beschikbaar voor bedrijfskritische processen?
- Vendor lock-in en exit-strategie: Hoe eenvoudig is het om over te stappen naar een andere leverancier? Kan de eigen data inclusief metadata, prompts en fijngeslepen modelgewichten (fine-tuning weights) eenvoudig worden geëxporteerd?
Technische verificatie in de praktijk
Het controleren van de technische claims van een AI-leverancier vereist een actieve en kritische houding. Vertrouw niet uitsluitend op marketingmateriaal of algemene presentaties. Een gestructureerd technisch onderzoek maakt gebruik van de volgende stappen:
Evaluatie van security-certificeringen
Certificeringen zoals ISO 27001 en SOC 2 Type II zijn belangrijke indicatoren voor een volwassen informatiebeveiligingsbeleid, maar ze zijn niet zaligmakend voor AI-specifieke risico's. ISO 27001 richt zich op het managementsysteem voor informatiebeveiliging in brede zin. Een SOC 2 Type II-rapport biedt meer detail omdat het de effectiviteit van controles over een langere periode (meestal minimaal zes maanden) toetst. Vraag specifiek naar het volledige SOC 2-rapport inclusief de beschreven beheersmaatregelen (controls), en niet enkel naar de samenvatting of de verklaring van de accountant. Let hierbij op of de reikwijdte (scope) van de audit daadwerkelijk betrekking heeft op de AI-dienst die wordt afgenomen, en niet enkel op de hostingomgeving van de leverancier.
Penetratietesten en kwetsbaarhedenanalyses
Vraag om recente penetratietestrapporten (pen-tests) die zijn uitgevoerd door een onafhankelijke, gecertificeerde derde partij. De test mag niet ouder zijn dan twaalf maanden. Let bij AI-toepassingen specifiek op of de pen-test ook betrekking had op API-endpoints en specifieke AI-aanvalvectoren, zoals het omzeilen van filters (jailbreaking) en ongeautoriseerde toegang tot de onderliggende database (vector database). Indien de leverancier weigert om details te delen, kan dit een indicatie zijn van een ontoereikend beveiligingsniveau.
Datalocatie en subverwerkers
Stel vast waar de fysieke servers staan waar de data worden verwerkt en opgeslagen. Binnen de Europese Unie (EU) gelden strenge regels voor datadoorgifte. Indien de leverancier gebruikmaakt van Amerikaanse cloudinfrastructuur, controleer dan welke aanvullende waarborgen zijn getroffen om te voldoen aan de AVG (zoals Standard Contractual Clauses). Daarnaast moet de lijst van subverwerkers (derde partijen die door de leverancier worden ingeschakeld om de dienst te leveren, zoals API-aanbieders of hostingpartijen) nauwkeurig worden gecontroleerd. Elke subverwerker vormt een potentieel risico in de keten.
Contractuele waarborgen en exit-scenario's
De resultaten van de due diligence vormen de basis voor de uiteindelijke contractonderhandelingen. Een goed doorlopen onderzoek stelt de organisatie in staat om gerichte clausules op te nemen in de overeenkomst. Voor gedetailleerde juridische formuleringen verwijzen we naar het artikel over AI-contracten en SLAs.
Dataportabiliteit en eigendom
In het contract moet expliciet worden vastgelegd dat alle ingevoerde gegevens (prompts), historische interactiedata en klantspecifieke aanpassingen (zoals embeddings of fine-tuning datasets) exclusief eigendom blijven van de afnemer. De leverancier moet bij beëindiging van de overeenkomst verplicht zijn deze data in een gangbaar, gestructureerd formaat (zoals JSON of CSV) aan te leveren.
Model-versiebeheer en deprecation policy
AI-leveranciers updaten hun modellen regelmatig. Dit kan ertoe leiden dat de werking van het systeem verandert of dat bepaalde functionaliteiten wegvallen. Zorg voor contractuele afspraken waarin de leverancier verplicht is om:
- Nieuwe modelversies eerst in een testomgeving (sandbox) aan te bieden alvorens deze in productie te nemen.
- Oudere modelversies minimaal twaalf maanden na de introductie van een nieuwe versie te blijven ondersteunen (de zogenaamde deprecation-termijn).
- Wijzigingen in het modelgedrag of de nauwkeurigheid vooraf aan te kondigen met bijbehorende impactrapportages.
Continuïteitsclausules bij overname of faillissement
De consolidatie in de AI-markt is hoog. De kans dat een leverancier wordt overgenomen door een grotere speler of in financiële problemen raakt, is reëel. Neem daarom bepalingen op die de continuïteit van de dienstverlening waarborgen. Denk hierbij aan een broncode-escrow (inclusief modelgewichten en trainingsopstellingen) of het recht om bij een overname het contract per direct kosteloos te beëindigen met behoud van alle data.
Voor concrete afspraken rondom beschikbaarheid en prestaties is het raadzaam om de standaarden voor service levels te bestuderen. Meer details hierover zijn te vinden op de pagina over SLA en uptime bij LLM-providers.
Inrichting van het due-diligence-traject
Een succesvol due-diligenceonderzoek volgt een gestructureerde tijdlijn en vereist een duidelijke rolverdeling binnen de organisatie. Het proces verloopt doorgaans via de volgende fasen:
| Fase | Activiteiten | Verantwoordelijke |
|---|---|---|
| 1. Voorbereiding | Opstellen NDA, bepalen scope, inrichten beveiligde dataroom. | Juridisch adviseur / Projectmanager |
| 2. Uitvraag | Verzenden vragenlijst, opvragen SOC 2, ISO-certificaten en pen-tests. | Security Officer (CISO) |
| 3. Evaluatie | Analyseren van de aangeleverde documenten, interviews met technische staf van leverancier. | Technisch expert / Lead Developer |
| 4. Rapportage | Vastleggen van risico's, rode vlaggen en advies voor contractering. | Projectmanager / Risico-analist |
Rode vlaggen (Red Flags)
Tijdens het due-diligenceonderzoek kunnen bepaalde signalen direct aanleiding geven tot bezorgdheid of het stopzetten van het traject. Wees alert op de volgende 'red flags':
- Weigeren van transparantie over trainingsdata: Als de leverancier weigert om in algemene termen toe te lichten hoe het model is getraind en of er gelicentieerde data zijn gebruikt, is het risico op auteursrechtelijke claims onacceptabel hoog.
- Ontbreken van versiebeheer: Leveranciers die updates direct en ongevraagd doorvoeren naar de productieomgeving zonder testfase voor de klant.
- Onduidelijke opslaglocaties van data: Het niet kunnen specificeren op welke serverlocaties en door welke subverwerkers de data worden verwerkt.
- Gebrek aan aansprakelijkheid: Contractvoorstellen waarin de leverancier elke aansprakelijkheid voor de output van het model uitsluit en geen enkele vrijwaring biedt voor IP-inbreuk.
- Focus op data-opslag en AVG: Controleer minimaal of de data binnen de EU worden opgeslagen en of de leverancier akkoord gaat met een standaard verwerkersovereenkomst waarin staat dat de data niet worden gebruikt voor modeltraining.
- Vraag om standaardverklaringen: Vraag de leverancier om een schriftelijke verklaring waarin zij garanderen dat zij beschikken over de benodigde rechten voor de trainingsdata en dat zij de software regelmatig laten testen op kwetsbaarheden.
- Gebruik bestaande frameworks: Maak gebruik van gratis beschikbare checklists en standaarden van instanties zoals het Nationaal Cyber Security Centrum (NCSC) om de basisbeveiliging te toetsen.
- Beperk de scope: Voer de due diligence met name uit op de onderdelen die direct invloed hebben op de continuïteit van de eigen bedrijfsvoering. Als de AI-tool enkel ondersteunend is (zoals bij het redigeren van interne teksten), kan het onderzoek lichter zijn dan wanneer het systeem direct klantcontact afhandelt.
Proportionele due diligence voor het MKB
Het uitvoeren van een volledig due-diligenceonderzoek zoals hierboven beschreven kan kostbaar en tijdrovend zijn. Voor het Midden- en Kleinbedrijf (MKB) met beperktere budgetten is het van belang om het onderzoek proportioneel in te richten. Niet elk traject vereist een extern team van juristen en auditors.
Voor een lichtere variant kunnen de volgende stappen worden genomen om de grootste risico's te mitigeren:
