Wat is het risico van AI-leveranciers?
Het risico van een AI-leverancier is de blootstelling die uw organisatie loopt wanneer een derde partij AI-functionaliteit levert, host, traint of integreert in uw producten, processen of beslissingen. Dit risico is breder dan het klassieke IT-leveranciersrisico, omdat een AI-leverancier niet alleen uw data verwerkt, maar ook de output beïnvloedt waarop uw medewerkers en klanten vertrouwen, met gedrag dat in de loop der tijd verandert naarmate modellen opnieuw worden getraind en bijgewerkt.
In de meeste organisaties vallen AI-leveranciers tegenwoordig in vier overlappende categorieën:
- Foundation model aanbieders zoals OpenAI, Anthropic, Google, Mistral en Cohere, die toegankelijk zijn via een API en geïntegreerd worden in interne tools, agents of klantgerichte functies.
- AI-native SaaS-tools zoals notitie-assistenten, codeerhulpsystemen, copiloten voor klantenservice, tools voor verkoopondersteuning en analyseplatformen waar AI het product is.
- Geïntegreerde AI in bedrijfssoftware Denk bijvoorbeeld aan AI-samenvatting in CRM-systemen, AI-scoreberekening in HR-systemen, AI-evaluatie in contractbeheer of AI-triage in servicebeheer, waarbij de AI een nieuwe functie is in een bestaande leveranciersrelatie.
- Gegevenslabels en leveranciers van trainingsgegevens die zich vóór elk model dat je bouwt bevinden, met een aanzienlijke invloed op vooringenomenheid, kwaliteit en wettelijke basis voor training.
Elke categorie brengt verschillende risico's met zich mee, maar ze hebben een gemeenschappelijk probleem: de leverancier bepaalt het gedrag waarvoor u verantwoordelijk bent. Toezichthouders, klanten en verzekeraars verwachten steeds vaker dat u kunt aantonen dat u dat gedrag actief hebt beoordeeld en gecontroleerd – en niet alleen een contract hebt getekend en verder bent gegaan.
Waarom is het risico van AI-leveranciers een onderwerp van discussie geworden op directieniveau?
Drie factoren hebben ervoor gezorgd dat het toezicht op AI-leveranciers is verschoven van een taak die alleen bij de inkoop speelde naar een zaak op bestuursniveau.
Geconcentreerde afhankelijkheid. Een handvol aanbieders van basismodellen vormt nu de basis voor duizenden AI-functionaliteiten in vrijwel elke bedrijfsomgeving. Modelstoringen, beleidswijzigingen, prijswijzigingen en geografische beperkingen hebben direct gevolgen voor uw producten en klanttrajecten. Dat is een concentratierisico waarvoor de raad van bestuur verantwoordelijk is.
Niet-deterministisch gedrag. In tegenstelling tot een traditionele SaaS-leverancier, wiens software vandaag hetzelfde doet als gisteren, kan een AI-leverancier modelgewichten, systeemmeldingen, veiligheidsfilters en trainingsgegevens zonder voorafgaande kennisgeving wijzigen. De output die u tijdens het testen hebt gevalideerd, is mogelijk niet de output die uw klant zes maanden later in productie ziet.
Verantwoordelijkheid van de regelgevende instanties. ISO 42001, de EU AI-wetSectorregulatoren (FCA, PRA, NHS Digital, Ofcom) en gegevensbeschermingsautoriteiten leggen nu expliciete verplichtingen op aan de implementeerder van een AI-systeem, niet alleen aan de ontwikkelaar. Het is niet langer voldoende om naar uw leverancier te wijzen. U moet aantonen dat u een geschikte leverancier hebt gekozen en deze hebt gecontroleerd.
Het praktische gevolg: het risico van AI-leveranciers hoort thuis in het bedrijfsrisicoregister, in het dossier van de auditcommissie en in de AI-beleid, niet verborgen in het inkoopproces.
Wat zegt ISO 42001 over het toezicht op AI-leveranciers?
ISO 42001 In bijlage A.10, een van de negen controlegebieden van bijlage A, worden de relaties met derden op het gebied van AI rechtstreeks behandeld. Dit controlegebied omvat leveranciers, de verdeling van verantwoordelijkheden tussen organisaties en klanten, omdat je in een AI-toeleveringsketen alledrie tegelijk kunt zijn: leverancier voor de ene partij, implementeerder voor een andere en klant van een derde.
Bijlage A.10 vereist dat u:
- Stel een proces op voor het identificeren van AI-leveranciers en de AI-systemen die zij u leveren.
- Leg de verantwoordelijkheden duidelijk en schriftelijk vast tussen u en uw leveranciers, zodat er geen hiaten ontstaan in de aansprakelijkheid voor AI-risico's, -impact en -prestaties.
- Besteed aandacht aan AI-specifieke overwegingen bij de selectie van leveranciers, contractering en het lopende beheer, en niet alleen aan algemene termen met betrekking tot informatiebeveiliging.
- Zorg ervoor dat klanten van uw AI-systemen over de informatie beschikken die ze nodig hebben om deze systemen op een verantwoorde manier te gebruiken.
Bijlage B (die normatief is, niet informatief) biedt implementatierichtlijnen voor elke controle in Bijlage A, inclusief A.10. Naast Bijlage A.10 omvat het toezicht op AI-leveranciers ook A.2 (beleid met betrekking tot AI), A.3 (interne organisatie en verantwoordelijkheden), A.5 (beoordeling van de impact van AI-systemen), A.7 (gegevens voor AI-systemen) en A.8 (informatie voor belanghebbenden). Voor de volledige set, zie onze Bijlage A-controles referentie en de toegewijde Bijlage A.10 Relaties met derden en klanten pagina.
Uw Verklaring van toepasbaarheid U dient te documenteren hoe u elk van deze beheersmaatregelen toepast op uw AI-leveranciersomgeving, inclusief eventuele uitzonderingen en de rechtvaardiging daarvan.
Alles wat u nodig heeft voor ISO 42001
Gestructureerde inhoud, in kaart gebrachte risico's en ingebouwde workflows helpen u AI op verantwoorde wijze en met vertrouwen te beheren.
Hoe beoordeel je een AI-leverancier?
Een grondige screening van een AI-leverancier moet verder gaan dan een simpele beveiligingsvragenlijst. Je beoordeelt niet alleen hoe de leverancier je gegevens beschermt, maar ook hoe ze het AI-systeem waarop je vertrouwt bouwen, beheren, aanpassen en uitfaseren. Het onderstaande raamwerk behandelt de negen gebieden die elke AI-leveranciersbeoordeling zou moeten omvatten, met een voorbeeld van vragen die je kunt stellen en de waarschuwingssignalen die een contract zouden moeten tegenhouden.
| De Omgeving | Vragen te stellen | rode vlag |
|---|---|---|
| Gegevenstraining | Op welke gegevens is het model getraind? Zijn er standaard gegevens van ons gebruikt voor de training? Kunnen we ons schriftelijk afmelden? Wat is de wettelijke basis voor de trainingsgegevens (toestemming, gerechtvaardigd belang, licentie)? | De leverancier kan de bronnen van de trainingsgegevens niet bekendmaken, gebruikt standaard klantgegevens voor training zonder mogelijkheid tot uitsluiting, of maakt gebruik van verzamelde gegevens zonder wettelijke grondslag. |
| Transparantie van modellen | Kunt u een modelkaart of systeemkaart verstrekken? Wat zijn de bekende beperkingen en mogelijke storingen? Hoe wordt het model van versiebeheer voorzien? Worden we op de hoogte gesteld van modelwisselingen of grote hertrainingen? | Geen modeldocumentatie, stilletjes modelwisselingen, geen versiebeheer of weigering om het model überhaupt te beschrijven (een black box zonder enige garantie). |
| Beveiligingshouding | Is de leverancier gecertificeerd volgens ISO 27001 en SOC 2? Hoe worden klantgegevens gescheiden? Welke versleuteling, sleutelbeheer en toegangscontroles zijn er toegepast op inferentieverkeer en logbestanden? | Geen erkende certificering, gedeeld gebruik zonder scheiding, prompts en outputs die oneindig lang in platte tekst worden opgeslagen, en geen SSO en MFA. |
| Privacy en AVG | Waar worden gegevens verwerkt en opgeslagen? Is er een gegevensverwerkingsovereenkomst van kracht? Zijn er adequate overdrachtsmechanismen voor internationale gegevensstromen? Hoe worden de rechten van de betrokkene gewaarborgd met betrekking tot in- en uitvoer van gegevens? | Geen gegevensbeschermingsovereenkomst (DPA), overdracht van gegevens buiten het VK en de EER zonder waarborgen, geen mechanisme ter ondersteuning van verzoeken van betrokkenen om inzage in of verwijdering van gegevens, of onduidelijke bewaartermijnen voor meldingen. |
| Technische Specificaties | Bent u ISO 42001-gecertificeerd? Beschikt u over ISO 27001 en SOC 2 Type II? Wanneer vonden de laatste surveillance-audits plaats? Mogen wij de certificaten en scopebeschrijvingen inzien? | Geen ISO 42001-certificering (of geen geloofwaardig stappenplan daarvoor), verlopen certificaten, omschrijvingen die de dienst die u koopt uitsluiten, of alleen zelfverklaringen. |
| Reactie op incidenten | Hoe definieert u een AI-incident? Wat is uw SLA voor meldingen aan klanten? Hoe gaat u om met modelvervormingen, schadelijke output, incidenten met vooringenomenheid en beveiligingslekken? Kunnen we een geanonimiseerd rapport na een incident inzien? | Geen specifieke definitie van incidenten met betrekking tot AI, meldingstermijnen langer dan 72 uur, geen rapportage na incidenten, of de onmogelijkheid om aan te tonen dat eerdere incidenten volledig zijn afgehandeld. |
| Verandermanagement | Hoe worden wijzigingen in modelgewichten, systeemmeldingen, veiligheidsfilters en richtlijnen beheerd? Worden we hiervan op de hoogte gesteld? Kunnen we een vastgezette versie behouden? Hoe worden wijzigingen getest vóór de uitrol? | Doorlopende updates zonder voorafgaande kennisgeving, zonder optie om een versie vast te zetten, zonder voorafgaande tests op bedrijfsnetwerken en zonder terugdraaimechanisme. |
| Subverwerkers | Wie zijn uw subverwerkers, inclusief hosting, modelhosting, evaluatie en data-etikettering? Hoe worden ze goedgekeurd en gecontroleerd? Worden we op de hoogte gesteld van wijzigingen? | Onvolledige lijst van subverwerkers, ondoorzichtig gebruik van sub-subverwerkers, geen recht van bezwaar tegen nieuwe subverwerkers of gebruik van subverwerkers in ongunstige rechtsgebieden. |
| Exitplan | Hoe krijgen we onze gegevens terug? Hoe lang worden ze bewaard na beëindiging? Worden prompts, outputs en fijnafstellingsgegevens volledig verwijderd? Bestaat er een overdraagbaar formaat voor aangepaste configuratie- of evaluatiegegevens? | Geen vastgestelde exitstrategie, retentie gemeten in jaren in plaats van dagen, geen exportformaat en geen lock-in via eigen evaluatiegegevens. |
Beoordeel elk onderdeel, geef het gewicht op basis van het risico van de AI-toepassing en koppel het resultaat aan het leveranciersrecord in uw leveranciersregister. Het doel is een verdedigbare beslissing, geen perfecte score.
Welke contractvoorwaarden moet u van AI-leveranciers eisen?
Contracten met AI-leveranciers moeten verder gaan dan standaard SaaS-voorwaarden. Beveiligingsschema's en gegevensverwerkingsovereenkomsten behandelen de datalaag, maar AI-gedrag, veranderingen en verantwoordelijkheid vereisen eigen clausules. De onderstaande checklist geeft het minimum weer dat we verwachten in elk belangrijk contract met een AI-leverancier:
- Recht op controle. Een contractueel recht om de leverancier te auditeren of te vertrouwen op onafhankelijke assurance-rapporten (ISO 42001-certificaat, SOC 2 Type II, samenvattingen van penetratietests) met een vastgestelde frequentie, die betrekking hebben op het specifieke AI-systeem dat u koopt.
- Wijzigingsbericht model. Schriftelijke kennisgeving van materiële wijzigingen aan modelgewichten, systeemmeldingen, veiligheidsfilters of beveiligingsmechanismen, met een vastgestelde kennisgevingsperiode (doorgaans 30 tot 90 dagen voor zakelijke toepassingen) en een optie voor het vastzetten van een versie voor gereguleerde workloads.
- Beperkingen op datagebruik. Een expliciet verbod op het gebruik van klantgegevens, -uitvoer, fijnafstemmingsgegevens of metadata voor het trainen van de algemene modellen van de leverancier zonder schriftelijke toestemming, met de verplichting tot gegevensscheiding.
- Toezeggingen met betrekking tot de nauwkeurigheid van de output. Beschrijvingen van het beoogde gebruik, bekende beperkingen en eventuele nauwkeurigheids- of veiligheidsnormen die de leverancier publiceert, met informatie over mogelijke oplossingen indien de leverancier gedocumenteerde functionaliteiten verwijdert.
- Melding van het incident. Een vastgestelde SLA voor meldingen van AI-incidenten (gericht op 24 tot 72 uur, afhankelijk van de ernst) die beveiligingsinbreuken, incidenten met vooringenomenheid, schadelijke output en langdurige serviceonderbrekingen dekt.
- Intellectueel eigendom. Duidelijke toewijzing van intellectueel eigendom in input, output en alle afgeleide werken, met vrijwaring tegen claims van derden op intellectueel eigendom die voortvloeien uit de modeloutput.
- Schadeloosstelling en aansprakelijkheid. Schadeloosstellingen op maat voor datalekken, inbreuken op intellectueel eigendom in modeluitvoer en wettelijke boetes wanneer het gedrag van de leverancier de directe oorzaak is, met aansprakelijkheidslimieten die evenredig zijn aan het risico van de AI-toepassing.
- Afsluiten en gegevens retourneren. Een gedefinieerd exitproces met gegarandeerde exportformaten, verwijderingscertificaten en een maximale bewaartermijn voor resterende gegevens na beëindiging (doorgaans 30 tot 90 dagen).
- Kennisgeving van subverwerker. Een lijst van de huidige onderaannemers in het contract, voorafgaande schriftelijke kennisgeving van wijzigingen en het recht om bezwaar te maken op basis van gedocumenteerde risicogronden.
- Certificeringsonderhoud. Een toezegging om de genoemde certificeringen (ISO 42001, ISO 27001, SOC 2) gedurende de looptijd van het contract te handhaven, met kennisgeving indien een certificering vervalt of de scope wijzigt.
Deze clausules moeten worden ingedeeld naar risiconiveau. Een leverancier van een basismodel in een klantgerichte besluitvormingsketen rechtvaardigt elke clausule; een interne productiviteitstool met een laag risico kan volstaan met een lichtere set clausules, mits de verlengingen worden gecontroleerd.
Hoe monitor je AI-leveranciers na afloop van een contract?
Zorgvuldige controle tijdens de onboarding is noodzakelijk, maar niet voldoende. AI-leveranciers veranderen, en daarmee ook uw gebruik ervan. Continue monitoring moet een combinatie zijn van geplande herbeoordelingen en gebeurtenisgestuurde triggers.
Geplande activiteiten die in uw AI-leveranciersbewakingskalender thuishoren:
- Jaarlijkse due diligence voor leveranciers met een hoog risico, tweejaarlijkse voor leveranciers met een gemiddeld risico, waarbij dezelfde negen gebieden als bij de onboarding worden bestreken, met een aanvullende evaluatie.
- Driemaandelijks overzicht van de wijzigingslogboeken van leveranciersmodellen, subprocessors en beleid ten opzichte van uw vastgestelde basislijn.
- Jaarlijkse beoordeling van de ISO 42001-, ISO 27001- en SOC 2-certificaten en scopeverklaringen van de leverancier.
- Beoordeling van door de leverancier gepubliceerde incident- en transparantierapporten (indien beschikbaar) tijdens elke managementevaluatiecyclus.
- Herzie het gedeelte over leveranciers in uw Verklaring van toepasbaarheid wanneer de omvang van de leverancier wezenlijk verandert
Gebeurtenisgestuurde triggers die een onmiddellijke herbeoordeling zouden moeten afdwingen:
- Een leverancier stelt u op de hoogte van een wijziging in een materieel model, een wijziging van een subverwerker of een beleidswijziging.
- De leverancier ondervindt een publiekelijk bekendgemaakt incident op het gebied van beveiliging, veiligheid of discriminatie.
- De leverancier verliest een certificering waarop hij vertrouwt, wijzigt de reikwijdte ervan of verlengt deze niet.
- Je wijzigt de toepassing van AI (bijvoorbeeld door een interne tool te integreren in een klantgerichte workflow of in een context met een hoog risico volgens de EU-wetgeving inzake kunstmatige intelligentie).
- Een nieuwe regelgeving, sectorrichtlijn of handhavingsmaatregel brengt wezenlijke veranderingen teweeg in uw verplichtingen als implementeerder.
Elke monitoringactiviteit moet bewijsmateriaal opleveren dat gekoppeld is aan het leveranciersdossier, de relevante beheersmaatregelen in Bijlage A en de vermeldingen in het AI-risicoregister waaraan de leverancier bijdraagt. Zo transformeert u leverancierstoezicht van een routinematig inkoopproces naar controleerbaar bestuur.
Ga eenvoudig aan de slag met een persoonlijke productdemo
Een van onze onboarding-specialisten legt u graag uit hoe ons platform werkt, zodat u vol vertrouwen aan de slag kunt.
Hoe verandert de EU-wetgeving inzake kunstmatige intelligentie de verplichtingen van AI-leveranciers?
Het EU AI-wet Dit creëert een gestructureerde reeks verplichtingen die door de hele AI-toeleveringsketen heen lopen. Als u een AI-systeem met een hoog risico implementeert, of een aanbieder bent die een model van een derde partij integreert, worden uw leverancierskeuzes compliance-keuzes.
Belangrijke gevolgen voor het toezicht op AI-leveranciers:
- De verplichtingen van de dienstverlener gelden ook voor uw leveranciers. Aanbieders van algemene AI-modellen (GPAI-modellen) hebben hun eigen verplichtingen met betrekking tot technische documentatie, samenvattingen van trainingsgegevens, auteursrechtbeleid en (voor modellen met systeemrisico's) vijandige testen, incidentrapportage en cyberbeveiliging. U dient van aanbieders van dergelijke modellen te eisen dat zij aantonen hoe zij aan deze verplichtingen voldoen.
- De verplichtingen van de uitzender gelden ook voor u. Als u een AI-systeem met een hoog risico gebruikt, bent u verplicht tot menselijk toezicht, het bewaren van logbestanden, monitoring, incidentrapportage en (in veel gevallen) een beoordeling van de impact op fundamentele rechten. Om hieraan te voldoen, hebt u informatie van de leverancier nodig, waarvoor een contract moet worden afgesloten.
- Informatie stroomt door de hele keten. Leveranciers moeten implementeerders de technische documentatie en gebruiksaanwijzingen verstrekken die nodig zijn om aan hun verplichtingen te voldoen. U dient zorgvuldig te controleren of dit materiaal daadwerkelijk bestaat voor elk AI-component met een hoog risico dat u aanschaft.
- Aanzienlijk risico op wijzigingen. Als u een algemeen model zodanig aanpast, ombouwt of hergebruikt dat er sprake is van een substantiële wijziging, kunt u een zelfstandige leverancier worden – met de bijbehorende verplichting tot conformiteitsbeoordeling. Leverancierscontracten moeten duidelijk vermelden welke aanpassingen wel en niet zijn toegestaan en welke garanties daaraan verbonden zijn.
- Verboden praktijken. Bepaalde toepassingen van AI (zoals sociale scores, het ongerichte verzamelen van gezichtsgegevens, het afleiden van emoties op de werkvloer en in het onderwijs, en andere) zijn verboden. Uw AI-beleid en de beoordeling van leveranciers moeten de toepassingsmogelijkheden toetsen aan deze verboden vóórdat u een contract afsluit, niet erna.
ISO 42001 en de EU AI-wetgeving vullen elkaar aan. De norm biedt het raamwerk voor het managementsysteem; de wetgeving definieert de wettelijke verplichtingen waaraan dit raamwerk moet voldoen. Een goed functionerend leverancierscontroleproces dient beide.
Hoe ISMS.online risicobeheer voor AI-leveranciers uitvoert.
ISMS.online Het platform biedt een gestructureerde plek voor het beheer van AI-leveranciers binnen uw bredere AI-managementsysteem. In plaats van leveranciersgegevens te verspreiden over inkoopformulieren, beveiligingsvragenlijsten, juridische dossiers en compliance-trackers, consolideert het platform de gehele levenscyclus in één verbonden werkruimte.
- Leveranciersregister met AI-specifieke velden. Elke AI-leverancier heeft een profiel met het type leverancier (basismodel, AI SaaS, ingebedde AI, data-etikettering), gebruiksscenario's, risiconiveau, certificeringen, subverwerkers en relevante controlekoppelingen in Bijlage A.
- AI due diligence-vragenlijsten. Voorgefabriceerde sjablonen voor de negen beoordelingsgebieden, inclusief scoreberekening, goedkeuring en opgeslagen bewijsmateriaal gekoppeld aan het leveranciersdossier.
- Het bijhouden van contracten en clausules. Belangrijke AI-clausules (auditrecht, melding van modelwijziging, gegevensgebruik, incident-SLA, exit) worden bijgehouden als velden in het leveranciersrecord, zodat u in één oogopslag een overzicht van uw AI-omgeving kunt krijgen.
- Doorlopende monitoringworkflows. Geplande herbeoordelingen, waarschuwingen voor verlopen certificaten, beoordelingen van wijzigingslogboeken en op triggers gebaseerde herbeoordelingen, allemaal gekoppeld aan het leveranciersrecord en het AI-risicoregister.
- Gekoppelde risico- en impactbeoordelingen van AI. Leveranciersgegevens zijn direct gekoppeld aan gegevens in het AI-risicoregister (clausule 6.1.2) en aan impactbeoordelingen van AI-systemen (clausule 6.1.4), waardoor leveranciersrisico's worden beschouwd als onderdeel van het algehele AI-risicobeeld en niet als een parallel universum.
- Auditbewijs op controleniveau. Elke beoordeling, evaluatie en herbeoordeling levert bewijsmateriaal op dat gekoppeld is aan de specifieke controle in bijlage A die erop van toepassing is, en dat klaar is voor controles in het kader van toezicht.
Het praktische resultaat: wanneer een auditor vraagt hoe u voldoet aan Bijlage A.10 voor uw AI-toeleveringsketen, is het antwoord een enkele gedetailleerde analyse — leverancier, beoordeling, contract, monitoringgeschiedenis, bewijsmateriaal — in plaats van een week aan screenshots en spreadsheets.
Waarom kiezen voor ISMS.online voor AI-leveranciersrisicobeheer?
ISMS.online Het platform is volledig ontworpen voor AI-governance, waardoor leverancierstoezicht een volwaardig onderdeel is in plaats van een losse toevoeging. Dit is wat u krijgt:
- Leveranciersregister specifiek voor AI. Speciaal ontworpen velden voor het type AI-leverancier, gebruiksscenario's, risiconiveau, certificeringen, subverwerkers en modelversies, en niet een generieke leverancierslijst die is overgenomen uit een IT-assettool.
- Voorgebouwde AI-due diligence-sjablonen. De vragenlijsten zijn afgestemd op ISO 42001 Bijlage A.10, de richtlijnen van Bijlage B en de daaruit voortvloeiende verplichtingen van de EU AI-wetgeving, zodat teams kunnen beginnen met een basis die is afgestemd op de standaarden, in plaats van vragen helemaal opnieuw te moeten formuleren.
- Geïntegreerd met het AI-risicoregister. Leveranciersrisico's zijn direct gekoppeld aan AI-risico's (clausule 6.1.2) en impactbeoordelingen van AI-systemen (clausule 6.1.4), waarbij de scoring, behandeling en evaluatiecycli op één plek zijn samengebracht.
- Live Verklaring van toepasbaarheid. Het leveranciersgedeelte van uw SoA blijft actueel naarmate leveranciers, beheersmaatregelen en onderbouwingen veranderen, in plaats van bevroren te blijven in een Word-document.
- Continue monitoring is ingebouwd. Geplande herbeoordelingen, waarschuwingen voor verlopen certificaten en door gebeurtenissen geactiveerde evaluaties zorgen ervoor dat het toezicht op de leverancier gedurende de volledige contractlevenscyclus actief blijft.
- Hergebruik via meerdere standaarden. Leveranciersgegevens worden gedeeld tussen ISO 42001 en de leverancierscontroles van uw bestaande ISO-managementsystemen, zodat u één leveranciersprogramma beheert in plaats van meerdere. Zie voor de overlap ISO 42001 versus ISO 27001.
- Methode voor gegarandeerde resultaten. Een bewezen implementatiemethode, ondersteuning bij de adoptie en live hulp zorgen ervoor dat het toezicht op AI-leveranciers binnen enkele weken, en niet binnen enkele kwartalen, operationeel is.
Of u nu helemaal vanaf nul begint of een bestaand programma voor risicobeheer door derden wilt aanpassen aan de specifieke normen voor kunstmatige intelligentie (AI), ISMS.online biedt u de tools om AI-leveranciersrisicobeheer uit te voeren in overeenstemming met ISO 42001 en de EU AI-wetgeving. Voor een volledig overzicht van de implementatie, zie onze implementatie gidsof hoofd Terug naar het ISO 42001-centrum.
Ben je klaar om het platform in actie te zien? Demo boeken.
Veelgestelde vragen
Wat is AI-leveranciersrisicomanagement?
Risicomanagement voor AI-leveranciers is het proces van het identificeren, beoordelen, contracteren en monitoren van derden die AI-functionaliteit aan uw organisatie leveren. Het omvat leveranciers van basismodellen, native AI SaaS-tools, ingebouwde AI-functies in bedrijfssoftware en leveranciers van datalabeling of trainingsdata. Het breidt het klassieke risicomanagement voor derden uit met AI-specifieke overwegingen zoals trainingsdata, modeltransparantie, niet-deterministisch gedrag en wijzigingsbeheer van modelgewichten en systeemmeldingen.
Vereist ISO 42001 beoordelingen van AI-leveranciers?
Ja. Bijlage A.10 van ISO 42001 behandelt rechtstreeks de relaties met derden en klanten en vereist dat organisaties AI-leveranciers identificeren, verantwoordelijkheden toewijzen en AI-specifieke overwegingen beheren gedurende de gehele leverancierslevenscyclus. Bijlage B (normatief) biedt richtlijnen voor de implementatie. ISMS.online In de Verklaring van Toepasselijkheid moet worden beschreven hoe u deze beheersmaatregelen toepast op uw AI-leveranciersomgeving, met een onderbouwing van eventuele uitzonderingen.
Wat zijn de grootste waarschuwingssignalen bij een beoordeling van een AI-leverancier?
De meest voorkomende struikelblokken zijn: standaard training met klantgegevens zonder mogelijkheid tot uitsluiting, geen modeldocumentatie of versiebeheer, geen erkende certificeringen (ISO 42001, ISO 27001, SOC 2) of verlopen certificeringen, geen specifieke SLA voor incidentrespons of meldingen met betrekking tot AI, stille modelwijzigingen zonder voorafgaande kennisgeving, ondoorzichtige afspraken met onderaannemers en geen gedefinieerd exitproces. Elk van deze punten zou op seniorniveau aanleiding moeten geven tot een risicobeoordeling voordat het contract wordt ondertekend.
Hoe vaak moeten we AI-leveranciers opnieuw beoordelen?
Een jaarlijkse herbeoordeling is een redelijke basis voor AI-leveranciers met een hoog risico, een tweejaarlijkse beoordeling voor leveranciers met een gemiddeld risico en een minder intensieve monitoring voor leveranciers met een laag risico. Naast het schema zouden gebeurtenisgestuurde triggers – materiële model- of subprocessorwijziging, publiekelijk bekendgemaakt incident, verlies van certificering, wijziging van gebruiksscenario, nieuwe regelgeving – een onmiddellijke herbeoordeling moeten afdwingen, ongeacht de planning.
Heeft de EU-wetgeving inzake kunstmatige intelligentie gevolgen voor onze contracten met AI-leveranciers?
Ja. De EU-wetgeving inzake kunstmatige intelligentie (AI) legt verplichtingen op aan aanbieders, implementeerders en importeurs van AI-systemen, en informatie moet door de hele keten stromen om aan die verplichtingen te kunnen voldoen. Contracten met aanbieders van basismodellen en downstream AI-leveranciers moeten de technische documentatie, gebruiksaanwijzingen, transparantie-informatie en incidentmeldingen vereisen die nodig zijn om aan uw verplichtingen als implementeerder of aanbieder te voldoen. Het verfijnen of ingrijpend wijzigen van een algemeen model kan er ook toe leiden dat een implementeerder een aanbieder wordt, wat contractueel moet worden vastgelegd.
Is een ISO 27001-gecertificeerde leverancier voldoende voor AI-toepassingen?
Nee. ISO 27001 behandelt informatiebeveiligingsbeheer en is een sterke basis, maar het gaat niet in op AI-specifieke risico's zoals de herkomst van trainingsdata, modeltransparantie, impact op betrokken personen, vooringenomenheid of het beheer van modelwijzigingen. Voor belangrijke AI-toepassingen moet u ook kijken naar ISO 42001 (of een geloofwaardig stappenplan daarnaartoe), SOC 2 Type II voor de betreffende AI-dienst en expliciete AI-clausules in het contract die verder gaan dan alleen informatiebeveiligingsbepalingen.
Kan ISMS.online het risico van AI-leveranciers beheren naast het algemene leveranciersrisico?
Ja. ISMS.online Het is een platform met meerdere standaarden, waardoor AI-leveranciers in hetzelfde leveranciersregister staan als uw bredere derde partijen, met AI-specifieke velden, due diligence-sjablonen en monitoringworkflows erbovenop. Dat betekent één leveranciersprogramma, één set bewijsstukken en één auditspoor – dat zowel ISO 42001 Bijlage A.10 als de leverancierscontroles van uw bestaande managementsystemen in één overzicht dekt.
