Leverandørevaluering og tredjepartsrisiko

Gevinster:

• Evne til å evaluere en AI-leverandør på sertifisering, lagring, dataopphold og underprosessorakser
• Evne til å verifisere forsikringer med dokumenter og kontraktsklausuler og ikke stole på verbale ord
• Evne til å knytte DPA og vilkår om bortvalg/sletting til sikkerhetsgjennomgang før kjøp

De fleste organisasjoner trener ikke sine egne modeller; bruker en leverandørs API. Dette eliminerer ikke risikoen – det overfører den bare til noen andre, og det er ditt ansvar å vurdere risikoen du overfører. Hver tredjepart dataene dine går til er en utvidelse av sikkerhetsgrensen din. I denne enheten lærer du hvordan du vurderer en AI-leverandør; Vi vil lære hvordan du gjennomfører en sikkerhetsgjennomgang før kjøp gjennom samsvarssertifikater, databehandlingsavtale (DPA), datalagring, datadomisil og underbehandlere.

Hvorfor tredjepartsrisiko?

I tilfelle en revisjon eller et brudd, vil ikke forsvaret av "vi behandlet ikke dataene, leverandøren gjorde det" redde deg. Du er behandlingsansvarlig; Leverandøren er databehandler. KVKK og GDPR gjør dette skillet, men det meste av ansvaret ligger hos deg. Derfor er valg av leverandør ikke en kjøpsbeslutning, men en sikkerhetsbeslutning.

Advarsel: «En stor og kjent leverandør» er ingen garanti for sikkerhet. Trygghet kommer fra signerte kontraktsbestemmelser og verifiserbare sertifiseringer; ikke på grunn av merkevarens rykte.

Evaluation Axes

Examine an AI vendor on seven axes:

• Samsvarssertifiseringer: SOC 2 Type II (uavhengig revisjon av en organisasjons sikkerhetskontroller), ISO/IEC 27001 (styringsstandard for informasjonssikkerhet) og i økende grad ISO/IEC 42001 (standard for styringssystem for kunstig intelligens).
• Datalagring: Hvor lenge beholdes forespørselen/svaret? Tilbys ZDR (null dataoppbevaring)?
• Bruk i trening: Brukes dataene dine til å trene modellen? (Vanligvis "nei" på bedriftsnivå.)
• Databosted: I hvilket land/region blir dataene behandlet og lagret?
• Underbehandlere: Hvilke andre selskaper bruker leverandøren (sky, overvåking)? De er også en del av grensen din.
• Sikkerhetsfunksjoner: Kryptering (under transport/hvile), tilgangskontroll, revisjonslogg, hendelsesvarslingstid.
• Kontrakt og utgang: Er det en DPA? Er dataene dine garantert slettet hvis tjenesten avsluttes? Hva er risikoen for innlåsing?

Trinn for trinn: Leverandørgjennomgang

1. Send inn en sikkerhetsundersøkelse. Gjør om aksene ovenfor til en liste med spørsmål.
2. Be om bevis. Bekreft påstander med dokumentasjon (SOC 2-rapport, ISO-sertifikat, DPA-utkast).
3. Kartlegg dataflyten. Hvilke data går hvor og for hvilken prosess?
4. Forhandle DPA. Ikke start produksjonen uten å signere en databehandleravtale (lovteksten som spesifiserer hvordan leverandøren skal behandle dataene).
5. Gjennomgå underbehandlere. Vurder hele kjeden.
6. Sett opp en tidsplan for reevaluering. Leverandørrisiko bør revurderes minst én gang i året.

Fire kopierbare maler

Kjerne for leverandørsikkerhetsundersøkelse:

Ting å spørre leverandøren om: 1. Hvilke samsvarssertifiseringer har du? (SOC 2 Type II, ISO 27001/42001) Kan du dele rapporten?2. Hvor mye forespørsel-/svardata lagres? Finnes det et ZDR-alternativ?3. Brukes dataene våre i modelltrening? Står det skrevet i kontrakten?4. I hvilken region behandles/lagres dataene? Kan vi velge en region?5. Hvem er underbehandlerne dine? Hvordan gir du beskjed når det endres?6. Hvilken varslingsperiode har du i tilfelle brudd?7. Hvordan og når slettes våre data når kontrakten utløper?

Regel for kontroll av bevisbekreftelse:

For hver påstand, "finnes det bevis?" sjekk:- Sertifiseringskrav -> har jeg sett gjeldende rapport/sertifikatnummer?- ZDR/lagringskrav -> står det skrevet i kontraktsklausulen?- Ikke-bruk under opplæring -> Er det en åpen klausul i DPA? Merk hvert krav uten bevis som "IKKE VERIFISERT"; Ikke godta verbale ord.

Forespørsel om dataflytkartlegging:

Trekk ut dataflyten for følgende integrasjon: {{ scenario }}Spesifiser ved hvert trinn: hvilke data (inneholder den PII), hvor den går (hvilket selskap/region), til hvilket formål, hvor mye som lagres. Merk hvert trinn og underbehandlere som krysser bedriftsgrensen.

Scorekort for leverandørrisiko:

Poeng hver akse med en poengsum på 0-2 (0=ingen, 1=delvis, 2=full): sertifikat, ZDR/retensjon, ikke bruk i opplæring, dataopphold, underbehandlertransparens, bruddvarsel, avslutning/sletting. Hvis totalt < 10 eller en hvilken som helst akse er 0: "RISIKO HØY, satt i produksjon".

Svak forespørsel / sterk forespørsel

dårlig tilnærming

Sterk tilnærming

Forutsatt "stort selskap, trygt"

Bekreft sertifikat og DPA med dokument

stole på verbale forsikringer

Knytter enhver forsikring til kontraktsklausulen

Bare gjennomgå leverandøren

Also consider the sub-processor chain

velg en gang og glem

Årlig revurderingskalender

Tre minivesker

Sak 1 – Prosjekt startet uten DPA ble stoppet. A retail company quickly brought an assistant into production; Det juridiske teamet oppdaget senere at det ikke var noen signert DPA med leverandøren. Prosjektet ble suspendert mens kundedata ble behandlet, DPA ble forhandlet frem og gjenåpnet etter at datadomisilet ble fikset i EU-regionen.

Tilfelle 2 - Underprosessorkjeden gir en overraskelse. Et helseselskap hadde godkjent hovedleverandøren; Dataflytkartlegging avslørte imidlertid at leverandøren brukte et selskap i et tredjeland for overvåking. Dette brøt med dataoppholdskravet. Selskapet la til opphold i regionen til kontrakten.

Tilfelle 3 — Scorecard eliminerte det billige budet. Tre forslag ble vurdert. Den billigste leverandøren fikk 0 (ingen SOC 2) på sertifiseringsaksen. Målkortregelen "hvis noen akse er 0, sett den i produksjon" ble eliminert; En 22 % dyrere, men fullt vurdert leverandør ble valgt, og beslutningen ble dokumentert for revisjon.

Tips: Forveksle aldri to forskjellige garantier: "våre data er ikke lagret (ZDR)" og "våre data brukes ikke i trening" er separate klausuler. En leverandør kan tilby det ene, men ikke det andre; Be om begge tydelig i kontrakten.

Vanlige feil

• Vurderer leverandørens størrelse/merke som sikkerhetsgaranti.
• Stole på jungeltelegrafen uten å bekrefte påstander med dokumentasjon.
• Går i produksjon uten å signere en DPA.
• Ignorerer underbehandlerkjeden (databoligen er gjennomboret der).
• Tenker at ZDR og "ikke brukt i utdanning"-garantien er det samme.
• Godkjenne leverandøren én gang og ikke revurdere årlig.

Oppsummert

• Du er behandlingsansvarlig; Leverandørvalg er en sikkerhetsbeslutning, ikke en kjøpsbeslutning.
• Evaluer på syv akser: sertifisering, oppbevaring/ZDR, pedagogisk bruk, dataopphold, underbehandlere, sikkerhetsfunksjoner, kontrakt/exit.
• Bekreft hver forsikring med dokument og kontraktsbestemmelse; Merkevare og jungeltelegrafen er ikke nok.
• Vurder også underprosessorkjeden; databolig er ofte gjennomboret der.
• Ikke start produksjonen før en DPA er signert og revurder leverandøren årlig.

Søknadsoppgave

Fyll ut sikkerhetsundersøkelsen ovenfor for en AI-leverandør du bruker (eller vurderer) og spør "er det bevis?" for hvert svar. Tick ​​the column. Kartlegg deretter dataflyten og merk hvert trinn som krysser bedriftsgrensen. Score til slutt de syv aksene og lag et risikomålekort og spør "er det egnet for produksjon?" Skriv begrunnelsen for avgjørelsen din.

sjekkliste

• [ ] Jeg har dokumentert leverandørens samsvarssertifiseringer (SOC 2 / ISO 27001).
• [ ] Datalagring, ZDR og "non-use in education" klausuler er skrevet i kontrakten.
• [ ] Den oppfyller kravet mitt om dataopphold (KVKK/GDPR).
• [ ] Jeg kartla og evaluerte underprosessorkjeden.
• [ ] Jeg gikk ikke i produksjon uten en signert DPA.
• [ ] Jeg setter opp en årlig re-evalueringskalender for leverandøren.