AI-leveranciersdue-diligence: praktische gids voor SaaS-teams

Due diligence werkt wanneer een voorgesteld gebruik wordt omgezet in een verdedigbaar operationeel besluit. Het team moet functie, betrokken data en mensen, model- en infrastructuurleveranciers, tests, juridische rollen, contractafspraken en wijzigingsmonitoring begrijpen. De uitkomst is geen ingevulde vragenlijst, maar goedkeuring, voorwaardelijke goedkeuring, beperkte pilot, escalatie of afwijzing met redenen en eigenaren.

De EU AI Act bevat geen universele checklist met de naam “AI vendor due diligence”. De diepgang hangt af van systeem, doel, classificatie, rol in de waardeketen, gegevensverwerking en sectorregels. Een notulenassistent en een systeem dat sollicitanten rangschikt vereisen verschillende beoordelingen. Start bij de use case en vraag bewijs dat past bij de gevolgen.

Waarom gewone leveranciersreview niet volstaat

Toegang, encryptie, beschikbaarheid, subverwerkers, incidenten en verwijdering blijven belangrijk. Een AI-dienst kan echter modellen, retrievalbronnen, filters of het gebruik van prompts en outputs veranderen zonder klassieke release. Kwaliteit kan per taal, groep of invoer variëren. “Beslisondersteuning” kan onder tijdsdruk feitelijk beslissend worden.

Beoordeel leverancier én systeem: onderneming, hosting, modellen, beveiliging, contract en continuïteit; daarnaast doel, gebruikers, betrokkenen, data, gedrag, menselijk toezicht, integraties en vervolgacties. Anders ontstaat hetzelfde probleem als bij handmatige vendor-risk-reviews tijdens opschaling.

Wanneer verdiepen

Een zwaardere review is passend als persoonlijke, vertrouwelijke, gereguleerde of klantdata binnenkomt; output belangrijke beslissingen beïnvloedt; de dienst autonoom handelt of productie wijzigt; eigen kennis wordt gekoppeld; fouten moeilijk te herkennen of herstellen zijn; de keten onduidelijk blijft; of uitval materiële schade veroorzaakt.

Leid classificatie niet af uit marketing. Onder de AI Act bepalen doel en rol de verplichtingen. Artikel 25 kan providerverantwoordelijkheid verschuiven bij rebranding, substantiële wijziging of een nieuw hoogrisicodoel. Providers van hoogrisicosystemen en derden die componenten leveren moeten noodzakelijke informatie via schriftelijke afspraken uitwisselen. Op 30 augustus 2026 is een groot deel van de AI Act van toepassing; de gewijzigde hoogrisicodata zijn 2 december 2027 voor bijlage III en 2 augustus 2028 voor gereguleerde producten. Gebruik die tijd voor voorbereiding.

Welk bewijs u vraagt

1. Systeem en keten: grens, modellen en providers, regio's, integraties, bronnen, subverwerkers, toegestane en verboden gebruiken, beperkingen, versies en meldingen.
2. Data en privacy: doel, locatie, toegang, bewaartermijn, verwijdering, training en doorgifte voor prompts, uploads, outputs, feedback, metadata en logs. Is de leverancier AVG-verwerker, dan verlangt artikel 28 voldoende waarborgen en een passend contract. De EDPB beschrijft een specifieke, doorlopende beoordeling van onder meer deskundigheid, betrouwbaarheid, middelen, beleid, audits en certificeringen.
3. Security en weerbaarheid: rapporten en scope, kwetsbaarheden, incidenten, encryptie, identiteiten, tenantscheiding, herstel en afhankelijkheden. Voor generatieve AI: promptinjectie, datalekken, onveilige tools en vergiftigde bronnen.
4. Prestaties en impact: geteste groepen en talen, baseline, drempels, omstandigheden, beperkingen en fouten. Test ook uw configuratie met moeilijke input, escalatie, menselijke override en herstel.
5. Governance: leveranciersverantwoordelijken voor security, privacy, AI governance, incidenten en meldingen; interne business- en risico-eigenaren; klachten, schadelijke output en bewijs na beëindiging.

Het vrijwillige NIST AI RMF noemt beleid, gedocumenteerde controles, noodprocessen en monitoring voor AI van derden. Het GenAI-profiel noemt inkooponderzoek, SLA's, assurance-rapporten en ketentransparantie. Dit zijn ontwerpreferenties, geen bewijs van juridische compliance.

Contract en besluitvorming

Laat het contract uit het bewijs volgen: doel, gebruikers en data; training; modellen, subverwerkers, locaties en meldingen; security, incidenten en medewerking; documentatie; beperkingen en toezicht; wijzigingen; continuïteit, portabiliteit, verwijdering en exit; evenredige aansprakelijkheid. Een contract repareert geen ongeschikt systeem, maar beschermt informatie en remedies.

1. Beschrijf doel, gebruikers, betrokkenen, input, output, integraties, automatisering, menselijke controle en vervolgactie.
2. Ken een voorlopige klasse en AI Act-/AVG-rollen toe; noteer transfers, sectorregels en onzekerheid.
3. Vraag proportioneel bewijs en hergebruik actuele documenten die echt antwoord geven.
4. Test het geconfigureerde product met rechtmatige representatieve data; bewaar versies en resultaten.
5. Behandel hiaten met herstel, compensatie, beperktere scope, tijdelijke pilot, risicoacceptatie of afwijzing.
6. Herbeoordeel bij wijzigingen in doel, model, provider, data, integratie, autonomie, incident of regelgeving.

Het beslisrecord bevat product en versie, toegestaan en verboden gebruik, keten, risicoklasse, rollen, motivering, bewijs, tests, hiaten, contract, besluit, voorwaarden, termijnen en monitoring. De veranderende AI-governanceverwachtingen vragen actueel bewijs.

FAQ

Wat is het praktische doel?

Verdedigbaar bepalen of en hoe een specifieke AI-dienst mag worden gebruikt, hiaten vroeg vinden, controles toewijzen en bewijs bewaren voor klanten, audits, incidenten en herbeoordeling.

Wat legt u eerst vast?

Het exacte gebruik: gebruikers, betrokkenen, data, input, output, integraties, menselijke controle en vervolgactie. Zonder die grens zijn leveranciersantwoorden en juridische rollen niet betrouwbaar te beoordelen.

Wat is de grootste fout?

Due diligence behandelen als eenmalige documentenuitwisseling. Een sterke review verbindt scope, bewijs, tests, contract, voorwaarden, monitoring en duidelijke herbeoordelingstriggers.