Hva er risikoen for AI-leverandører?
Risikoen for AI-leverandører er eksponeringen organisasjonen din bærer når en tredjepart leverer, er vert for, trener opp eller bygger inn AI-funksjonalitet i produktene, prosessene eller beslutningene dine. Den er bredere enn klassisk IT-leverandørrisiko fordi en AI-leverandør ikke bare behandler dataene dine – de kan forme resultatene dine ansatte og kunder er avhengige av, med atferd som endres over tid etter hvert som modeller omskoleres og oppdateres.
I de fleste organisasjoner i dag faller AI-leverandører inn i fire overlappende kategorier:
- Leverandører av fundamentsmodeller som OpenAI, Anthropic, Google, Mistral og Cohere, tilgjengelig via API og innebygd i interne verktøy, agenter eller kundevendte funksjoner.
- AI-baserte SaaS-verktøy som notattakere, kodeassistenter, kundesupport-copiloter, salgsfremmende verktøy og analyseplattformer der AI er produktet.
- Innebygd AI i bedriftsprogramvare som for eksempel AI-oppsummering i CRM, AI-scoring i HR-systemer, AI-gjennomgang i kontraktshåndtering eller AI-triage i tjenestehåndtering, der AI-en er en ny funksjon i et eksisterende leverandørforhold.
- Leverandører av datamerking og opplæringsdata som ligger oppstrøms i forhold til enhver modell du bygger, med betydelig innflytelse på skjevhet, kvalitet og lovlig grunnlag for opplæring.
Hver kategori medfører ulike risikoer, men de deler et felles problem: leverandøren kontrollerer atferden du er ansvarlig for. Regulatorer, kunder og forsikringsselskaper forventer i økende grad at du beviser at du aktivt har vurdert og overvåket denne atferden – ikke bare signert en kontrakt og gått videre.
Hvorfor har risiko for AI-leverandører blitt et problem i styrerommet?
Tre krefter har flyttet tilsyn med AI-leverandører fra å være en anskaffelsesoppgave til et anliggende på styrenivå.
Konsentrert avhengighet. En håndfull leverandører av grunnleggende modeller ligger nå under tusenvis av AI-funksjoner på tvers av nesten alle bedriftsstabel. Modellavbrudd, endringer i policyer, prisendringer og geografiske begrensninger forplanter seg umiddelbart til produktene og kundereisene dine. Det er en konsentrasjonsrisiko styret må ta ansvar for.
Ikke-deterministisk atferd. I motsetning til en tradisjonell SaaS-leverandør hvis programvare gjør det samme i dag som i går, kan en AI-leverandør endre modellvekter, systemmeldinger, sikkerhetsfiltre og treningsdata uten varsel. Resultatet du validerte i testing er kanskje ikke resultatet kunden din ser i produksjon seks måneder senere.
Regulatorisk ansvarlighet. ISO 42001, den EUs AI-lov, sektorregulatorer (FCA, PRA, NHS Digital, Ofcom) og databeskyttelsesmyndigheter legger nå eksplisitte forpliktelser på distributøren av et AI-system, ikke bare byggeren. Å peke på leverandøren din er ikke lenger et forsvar. Du må vise at du valgte en passende leverandør og holdt øye med dem.
Den praktiske konsekvensen: Risiko knyttet til KI-leverandører hører hjemme i registeret over foretaksrisiko, i revisjonskomiteens pakke og i AI-politikk, ikke begravd i anskaffelser.
Hva sier ISO 42001 om leverandørtilsyn med AI?
ISO 42001 tar for seg tredjeparts AI-relasjoner direkte i vedlegg A.10, et av ni kontrollområder i vedlegg A. Kontrollområdet dekker leverandører, ansvarsfordeling mellom organisasjoner og kunder, fordi du i en AI-forsyningskjede kan være alle tre samtidig – leverandør til én part, distributør av en annen og kunde av en tredjepart.
Vedlegg A.10 krever at du:
- Etabler en prosess for å identifisere leverandører av kunstig intelligens og kunstig intelligens-systemene de tilbyr deg
- Fordel ansvaret tydelig og skriftlig mellom deg og leverandørene dine, slik at det ikke er noen hull i ansvarliggjøringen av risiko, påvirkning og ytelse knyttet til AI
- Ta hensyn til spesifikke hensyn knyttet til AI i leverandørvalg, kontraktsføring og løpende administrasjon, ikke bare generiske vilkår for informasjonssikkerhet
- Sørg for at kundene av AI-systemene dine har informasjonen de trenger for å bruke dem ansvarlig
Vedlegg B (som er normativt, ikke informativt) gir implementeringsveiledning for hver kontroll i vedlegg A, inkludert A.10. Ved siden av vedlegg A.10 berører tilsyn med KI-leverandører også A.2 (retningslinjer knyttet til KI), A.3 (intern organisering og ansvar), A.5 (vurdering av virkningen av KI-systemer), A.7 (data for KI-systemer) og A.8 (informasjon for interesserte parter). For hele settet, se vår Vedlegg A kontrollerer referanse og den dedikerte Vedlegg A.10 Tredjeparts- og kundeforhold side.
Din Anvendelseserklæring bør dokumentere hvordan du anvender hver av disse kontrollene på din AI-leverandørgruppe, inkludert eventuelle unntak og begrunnelsen for dem.
Alt du trenger for ISO 42001
Strukturert innhold, kartlagte risikoer og innebygde arbeidsflyter som hjelper deg med å styre AI ansvarlig og med selvtillit.
Hvordan vurderer du en AI-leverandør?
Due diligence hos KI-leverandører må gå utover et sikkerhetsspørreskjema. Du vurderer ikke bare hvordan leverandøren beskytter dataene dine, men også hvordan de bygger, driver, endrer og avvikler KI-systemet du er avhengig av. Rammeverket nedenfor dekker de ni områdene som enhver vurdering av KI-leverandører bør berøre, med et utvalg av spørsmål å stille og de røde flaggene som bør stoppe en kontrakt.
| Område | Spørsmål å spørre | rødt flagg |
|---|---|---|
| Dataopplæring | Hvilke data ble modellen trent på? Ble noen av dataene våre brukt til opplæring som standard? Kan vi reservere oss skriftlig? Hva er det juridiske grunnlaget for opplæringsdata (samtykke, legitim interesse, lisensiering)? | Leverandøren kan ikke oppgi kildene til opplæringsdataene, bruker kundedata til opplæring som standard uten å måtte reservere seg, eller er avhengig av skrapede data uten lovlig grunnlag for forsvar. |
| Modelltransparens | Kan dere fremlegge et modellkort eller systemkort? Hva er de kjente begrensningene og feilmodusene? Hvordan er modellen versjonert? Vil vi bli varslet om modellbytter eller større omskolering? | Ingen modelldokumentasjon, stille modellbytter, ingen versjonering eller nektelse av å beskrive modellen i det hele tatt (svart boks uten garanti) |
| Sikkerhetsstilling | Er leverandøren sertifisert i henhold til ISO 27001 og SOC 2? Hvordan er kundedata segregert? Hva er krypteringen, nøkkelhåndteringen og tilgangskontrollene rundt inferenstrafikk og logger? | Ingen anerkjent sertifisering, delt leieforhold uten segregering, ledetekster og utdata logget i klartekst på ubestemt tid, eller ingen SSO og MFA |
| Personvern og GDPR | Hvor behandles og lagres data? Finnes det en databehandleravtale? Finnes det tilstrekkelige overføringsmekanismer for internasjonale strømmer? Hvordan håndteres rettighetene til den registrerte for input og output? | Ingen databehandleravtale, overføringer utenfor Storbritannia og EØS uten sikkerhetstiltak, ingen mekanisme for å støtte forespørsler om tilgang eller sletting av data fra registrerte, eller uklar oppbevaring av forespørsler |
| Spesifikasjoner | Er dere sertifisert i henhold til ISO 42001? Har dere ISO 27001 og SOC 2 Type II? Når var de siste overvåkingsrevisjonene? Kan vi se sertifikatene og omfangserklæringene? | Ingen ISO 42001 (eller ingen troverdig plan for den), utløpte sertifikater, omfangserklæringer som ekskluderer tjenesten du kjøper, eller kun egenattestering |
| Hendelsesrespons | Hvordan definerer dere en AI-hendelse? Hva er tjenestenivåavtalen deres for varsling til kunder? Hvordan håndterer dere modellhallusinasjoner, skadelige utdata, skjevhetshendelser og sikkerhetsbrudd? Kan vi se en redigert rapport etter hendelsen? | Ingen AI-spesifikk hendelsesdefinisjon, varslingsvinduer som er lengre enn 72 timer, ingen rapportering etter hendelser eller manglende evne til å vise tidligere hendelser som er håndtert fra ende til ende |
| Endringsledelse | Hvordan håndterer dere endringer i modellvekter, systemmeldinger, sikkerhetsfiltre og rekkverk? Får vi beskjed? Kan vi beholde en låst versjon? Hvordan testes endringer før utrulling? | Rullende oppdateringer uten varsel, ingen versjonslåsingsmulighet, ingen testing før utgivelse på bedriftstrafikk eller ingen tilbakerullingsmekanisme |
| Underbehandlere | Hvem er underdatabehandlerne deres, inkludert hosting, modellhosting, evaluering og datamerking? Hvordan blir de godkjent og revidert? Får vi varsel om endringer? | Ufullstendig liste over underdatabehandlere, ugjennomsiktig bruk av underdatabehandlere, ingen rett til å protestere mot nye underdatabehandlere eller bruk av underdatabehandlere i ugunstige jurisdiksjoner |
| Avslutningsplan | Hvordan får vi tilbake dataene våre? Hvor lenge oppbevares de etter at de er avsluttet? Blir ledetekster, utdata og finjusteringsdata fullstendig slettet? Finnes det et portabilitetsformat for tilpasset konfigurasjon eller evalueringsdata? | Ingen definert exit, oppbevaring målt i år i stedet for dager, intet eksportformat eller låsing via proprietære evalueringsdata |
Poeng hvert område, vektlegg i henhold til risikoen i brukstilfellet for AI, og koble resultatet til leverandørposten i leverandørregisteret ditt. Målet er en forsvarlig avgjørelse, ikke en perfekt poengsum.
Hvilke kontraktsvilkår bør du kreve fra AI-leverandører?
Leverandørkontrakter for AI må gå utover standard SaaS-vilkår. Sikkerhetsplaner og databehandleravtaler håndterer datalaget, men AI-atferd, endringer og ansvarlighet trenger sine egne klausuler. Sjekklisten nedenfor er minimumskravet vi forventer i enhver vesentlig AI-leverandørkontrakt:
- Rett til revisjon. En kontraktsmessig rett til å revidere leverandøren, eller stole på uavhengige revisjonsrapporter (ISO 42001-sertifikat, SOC 2 Type II, sammendrag av penetrasjonstest) på en definert kadens, som dekker det spesifikke AI-systemet du kjøper.
- Varsel om modellendring. Skriftlig varsel om vesentlige endringer i modellvekter, systemmeldinger, sikkerhetsfiltre eller rekkverk, med en definert varslingsperiode (vanligvis 30 til 90 dager for bedriftsbruk) og et alternativ for versjonslåsing for regulerte arbeidsbelastninger.
- Begrensninger for databruk. Eksplisit forbud mot bruk av kundeinndata, -utdata, finjusteringsdata eller -metadata for å trene leverandørens generelle modeller uten skriftlig samtykke, med forpliktelser til datasegregering.
- Forpliktelser til nøyaktighet i utdata. Representasjoner om tiltenkt bruk, kjente begrensninger og eventuelle nøyaktighets- eller sikkerhetsstandarder som leverandøren publiserer, med rettsmidler hvis leverandøren fjerner dokumenterte funksjoner.
- Hendelsesvarsel. En definert tjenestenivåavtale for varsling av AI-hendelser (rettet mot 24 til 72 timer avhengig av alvorlighetsgrad) som dekker sikkerhetsbrudd, skjevhetshendelser, skadelige utdatahendelser og langvarig tjenesteforringelse.
- Åndsverk. Tydelig allokering av IP i input, output og eventuelle avledede verk, med erstatningsplikt mot tredjeparts IP-krav som oppstår fra modellutput.
- Erstatning og ansvar. Skreddersydde erstatninger for brudd på databeskyttelse, brudd på immaterielle rettigheter i modellutdata og regulatoriske bøter der leverandørens oppførsel er den umiddelbare årsaken, med ansvarsgrenser proporsjonale med risikoen ved brukstilfellet av AI.
- Utgang og data retur. Definert utgangsprosess med garanterte eksportformater, slettingssertifikater og en maksimal oppbevaringsperiode for gjenværende data etter opphør (vanligvis 30 til 90 dager).
- Varsel til underdatabehandler. En liste over nåværende underdatabehandlere i kontrakten, skriftlig forhåndsvarsel om endringer og rett til å protestere på dokumenterte risikogrunner.
- Vedlikehold av sertifisering. En forpliktelse til å opprettholde oppgitte sertifiseringer (ISO 42001, ISO 27001, SOC 2) i kontraktsperioden, med varsel dersom en sertifisering utløper eller omfanget endres.
Disse klausulene bør være risikonivåinndelte. En leverandør av grunnleggende modeller i en kundeorientert beslutningstakingspipeline garanterer hver klausul; et internt produktivitetsverktøy med lav risiko kan kjøre på et lettere sett med overvåkede fornyelser.
Hvordan overvåker du AI-leverandører etter kontraktsinngåelse?
Due diligence ved onboarding er nødvendig, men ikke tilstrekkelig. AI-leverandører endrer seg, og det samme gjør bruken av dem. Kontinuerlig overvåking må kombinere planlagte revurderinger med hendelsesdrevne triggere.
Planlagte aktiviteter som bør stå i kalenderen for tilsyn med AI-leverandører:
- Årlig re-due diligence for leverandører med høy risiko, to ganger årlig for leverandører med middels risiko, dekker de samme ni områdene som onboarding med en delta-gjennomgang
- Kvartalsvis gjennomgang av leverandørmodell, underbehandler og policyendringslogger mot din faste grunnlinje
- Årlig gjennomgang av leverandørens ISO 42001-, ISO 27001- og SOC 2-sertifikater og omfangserklæringer
- Gjennomgang av leverandørpubliserte hendelses- og åpenhetsrapporter (der det er tilgjengelig) i hver ledelsesgjennomgangssyklus
- Ny gjennomgang av leverandørdelen av din Anvendelseserklæring når leverandørens omfang endres vesentlig
Hendelsesdrevne utløsere som bør fremtvinge en umiddelbar revurdering:
- En leverandør varsler deg om en vesentlig modellendring, en endring av underdatabehandler eller en endring av policy
- Leverandøren opplever en offentliggjort sikkerhets-, trygghets- eller skjevhetshendelse
- Leverandøren mister, endrer omfanget av eller unnlater å fornye en pålitelig sertifisering
- Du endrer brukstilfellet for AI (for eksempel ved å flytte et internt verktøy til en kunderettet arbeidsflyt eller en høyrisikokontekst i henhold til EUs AI-lovgivning)
- En ny forskrift, sektorveiledning eller håndhevingstiltak endrer dine forpliktelser som distributør vesentlig
Hver overvåkingsaktivitet bør produsere bevis knyttet til leverandørregisteret, relevante kontroller i vedlegg A og AI-risikoregisteroppføringene som leverandøren bidrar til. Slik gjør du leverandørtilsyn fra et anskaffelsesritual til reviderbar styring.
Kom enkelt i gang med en personlig produktdemo
En av våre onboarding-spesialister vil veilede deg gjennom plattformen vår for å hjelpe deg med å komme i gang med selvtillit.
Hvordan endrer EUs KI-lov forpliktelsene til KI-leverandører?
Ocuco EUs AI-lov skaper et strukturert sett med forpliktelser som flyter nedover AI-forsyningskjeden. Hvis du distribuerer et AI-system med høy risiko, eller en leverandør som bygger inn en tredjepartsmodell, blir leverandørvalgene dine samsvarsvalg.
Viktige implikasjoner nedstrøms for tilsyn med AI-leverandører:
- Leverandørforpliktelser gjelder for leverandørene dine. Leverandører av generelle AI-modeller (GPAI) har sine egne forpliktelser knyttet til teknisk dokumentasjon, sammendrag av treningsdata, retningslinjer for opphavsrett og (for systemiske risikomodeller) kontradiktorisk testing, hendelsesrapportering og nettsikkerhet. Du bør be leverandører av grunnleggende modeller om å dokumentere hvordan de oppfyller disse forpliktelsene.
- Distributørens forpliktelser gjelder deg. Hvis du bruker et AI-system med høy risiko, har du forpliktelser til menneskelig tilsyn, loggoppbevaring, overvåking, hendelsesrapportering og (i mange tilfeller) en konsekvensvurdering av grunnleggende rettigheter. Å oppfylle disse forpliktelsene krever informasjon fra leverandøren, som må inngås i kontrakt.
- Informasjonsflyt nedover kjeden. Leverandører må gi distributørene den tekniske dokumentasjonen og bruksanvisningen som er nødvendig for å oppfylle deres forpliktelser. Din due diligence-prosess bør bekrefte at dette materialet faktisk finnes for enhver AI-komponent med høy risiko du anskaffer.
- Betydelig risiko for modifikasjoner. Hvis du finjusterer, omformulerer eller gir nytt formål til en generell modell til det punktet hvor den blir vesentlig modifisert, kan du bli en egen leverandør – med den tilhørende samsvarsvurderingsbyrden. Leverandørkontrakter må tydeliggjøre hvilke modifikasjoner som er og ikke er tillatt, og hvilke garantier som følger med dem.
- Forbudte praksiser. Enkelte bruksområder med AI (sosial scoring, umålrettet ansiktsskraping, følelsesmessig inferanse på arbeidsplassen og i utdanningen, og annet) er forbudt. Din AI-policy og leverandørvurdering må screene brukstilfeller mot disse forbudene før kontraktsinngåelse, ikke etterpå.
ISO 42001 og EUs KI-lovgivning er komplementære. Standarden gir deg styringssystemet for stillasarbeid; loven definerer de juridiske forpliktelsene som stillasarbeid har. En velfungerende leverandørtilsynsprosess tjener begge.
Hvordan ISMS.online kjører risikostyring for AI-leverandører
ISMS.online gir AI-leverandørtilsyn et strukturert hjem i ditt bredere AI-styringssystem. I stedet for å spre leverandørdata på tvers av innkjøpsark, sikkerhetsspørreskjemaer, juridiske mapper og samsvarssporere, konsoliderer plattformen livssyklusen i ett tilkoblet arbeidsområde:
- Leverandørregister med AI-spesifikke felt. Hver KI-leverandør har en oversikt med leverandørtype (grunnmodell, KI SaaS, innebygd KI, datamerking), brukstilfeller, risikonivå, sertifiseringer, underbehandlere og relevante kontrolllenker i tillegg A.
- AI due diligence spørreskjemaer. Forhåndsbygde maler som dekker de ni vurderingsområdene, med poengsum, godkjenning og lagret dokumentasjon knyttet til leverandørens post.
- Kontrakt- og klausuloppfølging. Viktige AI-klausuler (revisjonsrett, varsel om modellendring, databruk, tjenestenivåavtale for hendelser, avslutning) spores som felt i leverandørposten, slik at du kan rapportere om AI-eiendommen din med et raskt blikk.
- Løpende overvåkingsarbeidsflyter. Planlagte revurderinger, varsler om utløp av sertifikater, gjennomgang av endringslogger og triggerbaserte revurderinger, alt knyttet til leverandørposten og AI-risikoregisteret.
- Tilknyttede risiko- og konsekvensvurderinger av AI. Leverandøroppføringer kobles direkte til AI-risikoregisteroppføringer (punkt 6.1.2) og konsekvensvurderinger av AI-systemer (punkt 6.1.4), slik at leverandørrisiko behandles som en del av det overordnede AI-risikobildet, ikke et parallelt univers.
- Revisjonsbevis på kontrollnivå. Hver vurdering, gjennomgang og revurdering produserer bevis knyttet til den spesifikke kontrollen i vedlegg A den støtter, klare for overvåkingsrevisjoner.
Det praktiske resultatet: Når en revisor spør hvordan dere oppfyller vedlegg A.10 for KI-forsyningskjeden deres, er svaret én enkelt detalj – leverandør, vurdering, kontrakt, overvåkingshistorikk, bevis – ikke en uke med skjermbilder og regneark.
Hvorfor velge ISMS.online for risiko knyttet til AI-leverandører?
ISMS.online er bygget for AI-styring fra ende til ende, så leverandørtilsyn er en førsteklasses del av plattformen snarere enn et tillegg. Her er hva du får:
- AI-spesifikt leverandørregister. Spesiallagde felt for AI-leverandørtype, brukstilfeller, risikonivå, sertifiseringer, underbehandlere og modellversjoner, ikke en generisk leverandørliste som er omformet fra et IT-ressursverktøy.
- Forhåndsbygde maler for due diligence for AI. Spørreskjemaer i samsvar med ISO 42001 Annex A.10, Annex B-veiledning og nedstrøms forpliktelser i henhold til EUs AI-lov, slik at teamene starter fra et standardtilpasset utgangspunkt i stedet for å skrive spørsmål fra bunnen av.
- Integrert med AI-risikoregisteret. Leverandørrisiko er direkte knyttet til AI-risikoer (punkt 6.1.2) og konsekvensvurderinger av AI-systemer (punkt 6.1.4), med poengsum, behandling og gjennomgangssykluser på ett sted.
- Bo Anvendelseserklæring. Leverandørdelen av SoA-en din holder seg oppdatert etter hvert som leverandører, kontroller og begrunnelser endres, ikke fryst i et Word-dokument.
- Kontinuerlig overvåking innebygd. Planlagte revurderinger, varsler om utløp av sertifikater og hendelsesutløste gjennomganger holder leverandørtilsynet aktivt gjennom hele kontraktens livssyklus.
- Gjenbruk av flere standarder. Leverandørregistreringer delt på tvers av ISO 42001 og leverandørkontrollene i dine eksisterende ISO-styringssystemer, slik at du kjører ett leverandørprogram, ikke flere. For overlappingen, se ISO 42001 vs ISO 27001.
- Metode for garanterte resultater. Dokumentert implementeringsmetode, adopsjonsstøtte og live hjelp, slik at tilsyn med AI-leverandører er oppe og går i løpet av uker, ikke kvartaler.
Enten du starter fra null eller oppgraderer et eksisterende tredjeparts risikoprogram til AI-spesifikke standarder, ISMS.online gir deg verktøyene til å kjøre risikostyring for KI-leverandører i tråd med ISO 42001 og EUs KI-lov. For fullstendig implementeringskontekst, se vår implementeringsveiledning, eller hodet tilbake til ISO 42001-huben.
Klar til å se plattformen i aksjon? Kontakt.
Spørsmål og svar
Hva er risikostyring for AI-leverandører?
Risikostyring for KI-leverandører er prosessen med å identifisere, vurdere, inngå kontrakter med og overvåke tredjeparter som leverer KI-kapasitet til organisasjonen din. Den dekker leverandører av grunnleggende modeller, KI-native SaaS-verktøy, innebygde KI-funksjoner i bedriftsprogramvare og leverandører av datamerking eller opplæringsdata. Den utvider klassisk tredjepartsrisiko med KI-spesifikke hensyn som opplæringsdata, modelltransparens, ikke-deterministisk atferd og endringshåndtering av modellvekter og systemspørsmål.
Krever ISO 42001 vurderinger av AI-leverandører?
Ja. Vedlegg A.10 i ISO 42001 omhandler tredjeparts- og kundeforhold direkte, og krever at organisasjoner identifiserer AI-leverandører, fordeler ansvar og håndterer AI-spesifikke hensyn gjennom hele leverandørens livssyklus. Vedlegg B (normativt) gir implementeringsveiledning. Din ISMS.online Anvendelseserklæringen bør dokumentere hvordan du anvender disse kontrollene på din AI-leverandørgruppe, med eventuelle unntak begrunnet.
Hva er de største røde flaggene i en vurdering av AI-leverandører?
De vanligste problemene er: opplæring i kundedata som standard uten mulighet for bortvelging, ingen modelldokumentasjon eller versjonskontroll, ingen anerkjente eller utløpte sertifiseringer (ISO 42001, ISO 27001, SOC 2) eller utløpte, ingen AI-spesifikk hendelsesrespons eller varslings-SLA, stille modellendringer uten varsel, ugjennomsiktige underbehandlerordninger og ingen definert utgangsprosess. Enhver av disse bør utløse en risikobeslutning på seniornivå før kontraktsinngåelse.
Hvor ofte bør vi revurdere AI-leverandører?
Årlig revurdering er en rimelig grunnlinje for leverandører av AI med høy risiko, med toårig gjennomgang for leverandører med middels risiko og lettere overvåking for leverandører med lav risiko. I tillegg til tidsplanen bør hendelsesdrevne utløsere – vesentlig endring av modell eller underprosessor, offentliggjort hendelse, tap av sertifisering, endring av brukstilfelle, ny forskrift – tvinge frem en umiddelbar revurdering uavhengig av kalenderen.
Påvirker EUs KI-lovgivning våre KI-leverandørkontrakter?
Ja. EUs KI-lov pålegger leverandører, distributører og importører av KI-systemer forpliktelser, og informasjon må flyte nedover i kjeden for at disse forpliktelsene skal oppfylles. Kontrakter med leverandører av grunnleggende modeller og nedstrøms KI-leverandører bør kreve den tekniske dokumentasjonen, bruksanvisningen, informasjonen om åpenhet og hendelsesvarslingen som er nødvendig for at du skal kunne oppfylle dine forpliktelser som distributør eller leverandør. Finjustering eller vesentlig endring av en generell modell kan også gjøre en distributør om til en leverandør, noe som må håndteres kontraktsmessig.
Er en ISO 27001-sertifisert leverandør nok for brukstilfeller av kunstig intelligens?
Nei. ISO 27001 dekker informasjonssikkerhetsstyring og er et sterkt grunnlag, men den tar ikke for seg spesifikke risikoer knyttet til AI, som opplæringsdatas opprinnelse, modelltransparens, innvirkning på berørte individer, skjevhet eller styring av modellendringer. For vesentlige brukstilfeller av AI bør du også se etter ISO 42001 (eller en troverdig plan for den), SOC 2 Type II som dekker den aktuelle AI-tjenesten, og eksplisitte AI-klausuler i kontrakten som går utover informasjonssikkerhetsvilkår.
Kan ISMS.online håndtere AI-leverandørrisiko sammen med generell leverandørrisiko?
Ja. ISMS.online er en plattform med flere standarder, slik at AI-leverandører sitter i samme leverandørregister som dine bredere tredjeparter, med AI-spesifikke felt, due diligence-maler og overvåkingsarbeidsflyter lagt oppå. Det betyr ett leverandørprogram, ett sett med bevis og ett revisjonsspor – som dekker ISO 42001 Annex A.10 og leverandørkontrollene i dine eksisterende styringssystemer i én enkelt visning.
