Gevinster:
- Bruk evalueringskriterier før du kjøper et AI-verktøy
- Gjenkjenne elementene du skal se etter i databehandlingsavtalen (DPA) og modellkortet
- Lag den godkjente kjøretøylisten og leverandørrisikoscoring
Hva gjør du når en forretningsenhet kommer på døren din og sier "vi vil bruke det nye AI-verktøyet, det vil være veldig nyttig"? Å si "ingen måte" mater skyggen AI; Å si "ok" åpner for ukontrollert risiko. Det riktige svaret er å kjøre en kjøretøyevalueringsprosess. I denne enheten lærer vi hvilke spørsmål du bør stille før du kjøper/sertifiserer et AI-kjøretøy, hva du skal se etter i en databehandlingsavtale (DPA) og modellkort, og hvordan du kan destillere alt dette til en godkjent kjøretøyliste og risikoscore for leverandøren.
Hvorfor er det nødvendig med evaluering?
Hvert AI-verktøy er en databehandler: det behandler organisasjonens data. Å godkjenne feil verktøy betyr å overlate organisasjonens personopplysninger til en tredjepart (og ofte i utlandet) på en ukontrollert måte. Kjernespørsmål å svare på før du godkjenner et verktøy:
- Hvor behandler og lagrer den data (hvilket land)?
- Bruker den dataene våre i modelltrening? Kan den slås av (opt-out)?
- Tilbyr den en databehandleravtale (DPA)?
- Finnes det sikkerhetssertifiseringer (f.eks. ISO 27001)?
- Hvor lenge lagres chat-loggen og kan den slettes?
- Er det en forpliktelse til å varsle oss hvis det er et sikkerhetsbrudd?
Databehandleravtale (DPA)
Databehandlingsavtale (DPA) er en kontrakt signert mellom behandlingsansvarlig (institusjon) og databehandler (AI-leverandør) som spesifiserer hvordan dataene skal behandles. KVKK og GDPR pålegger i stor grad dette. Elementer å se etter i en DPA:
saken
Hva skal det gi?
Omfang og formål med behandlingen
La leverandøren kun operere etter våre instruksjoner
Underbehandlere
Hvem overføres det til? Er det varslet på forhånd?
Overføringssikkerhet
Standard kontraktsklausuler eller tilsvarende
Sikkerhetstiltak
Kryptering, tilgangskontroll, ISO 27001
Varsling om brudd
Varsle oss innen en viss tidsperiode i tilfelle et brudd
Sletting/retur
Forpliktelse til å slette/returnere data på slutten av kontrakten
Rett til revisjon
Evne til å revidere leverandøren eller motta rapporter
Pass på: De fleste "gratis" og "individuelle" AI-planer tilbyr ikke en DPA og kan bruke data til modelltrening. For bedriftsbruk bør bedrifts-/forretningsplaner som tilbyr DPA og garanterer utdanningsopt-out foretrekkes. Gratisplanen er ofte planen der data "betales".
Modellkort og transparens
Et modellkort er et dokument som forklarer hva en AI-modell er designet for, hvilke data den er trent med, dens begrensninger og kjente risikoer. En god leverandør deler dette. Ting å se etter i modellkortet: tiltenkt bruk av modellen, kjente begrensninger og risikoer for skjevhet, bruk som ikke anbefales, og ytelses-/sikkerhetsnotater. Hvis modellkortet mangler eller er veldig vagt, er det i seg selv et varseltegn.
tre minisaker
Tilfelle 1 - Kostnaden for gratisplanen. Et regnskapsteam begynner å behandle kundedata med et gratis AI-verktøy. Verktøyet tilbyr ikke en DPA og oppgir i sine vilkår at det kan bruke dataene til modelltrening. Overholdelsesansvarlig merker dette og forbyr verktøyet, og godkjenner et bedriftsalternativ som tilbyr DPA. Forskjellen: noen hundre TL per måned for lisens etc. Mulige bøter på millioner av pund.
Tilfelle 2 – Underbehandleroverraskelse. Et selskap oppdager i en revisjon måneder senere at AI-verktøyet det godkjente overførte data til underbehandlere i tre forskjellige land. Siden det ikke er noen "underbehandlere skal varsles på forhånd"-klausul i DPA, var selskapet ikke klar over det. Leksjon: En klausul i DPA som synliggjør underbehandlerkjeden er et must.
Tilfelle 3 – Avgjørelse ved scoring. En organisasjon etablerer en leverandørrisikoscoretabell med åtte kriterier for å sammenligne tre AI-verktøy (DPA, dataplassering, opplæringsopt-out, ISO 27001, bruddvarsel, sletting, mønsterkort, pris). Vurderingsresultatet fremhever verktøyet som ikke er det mest populære, men det mest kompatible. Avgjørelsen er basert på en dokumenterbar poengsum snarere enn et subjektivt "Jeg likte det."
Tips: Administrer listen over godkjente kjøretøy som en "hviteliste": tillat bare kjøretøy som er på listen. Svartelisten må oppdateres med hvert nytt verktøy og er alltid ett skritt bak; hvitelisting er sikker som standard.
Utgang og avhengighetsrisiko
Spørsmålet de fleste byråer hopper over når de godkjenner et kjøretøy er: "Hva skjer hvis vi ønsker å forlate dette kjøretøyet?" En god evaluering vurderer utgangen så vel som inngangen. To risikoer skiller seg ut. Den første er dataportabilitet: når du forlater leverandøren, kan du få tilbake dataene og konfigurasjonen i et standardformat, eller er dataene låst i leverandøren? Den andre er leverandørlåsing: forretningsprosesser kan være så knyttet til ett enkelt verktøy at utgangskostnadene blir uutholdelige når leverandøren øker prisene eller forstyrrer tjenesten.
Derfor er det god praksis å også legge til en "exit plan"-linje i bekreftelsesposten: hvordan får vi dataene tilbake, hva er det alternative verktøyet, hvor lang tid tar overgangen. Selv om leverandøren legger ned tjenesten en dag, vil organisasjonen være forberedt.
Forsiktig: Bare fordi et kjøretøy er populært eller billig, betyr det ikke at det er bærekraftig. Små leverandører kan stenge, bli kjøpt opp eller plutselig endre retningslinjene sine. Før du kobler en kritisk prosess til et enkelt verktøy, bør du vurdere exit-scenariet.
Kopierbare maler
MAL 1 — Spørsmålssett for leverandørevaluering: "Forbered evalueringsspørsmål for å stille leverandøren før du godkjenner et nytt AI-verktøy. Inkluder: dataplassering, bruk og fravalg i modellopplæring, DPA-tilstedeværelse, sikkerhetssertifikater, oppbevaringsperiode, bruddvarsel, underbehandlere, slettingsforpliktelse. Inkluder det forventede "sikre" svaret på hvert spørsmål."
MAL 2 — DPA-klausulens sjekkliste: "Sjekk DPA-utkastet under [lim inn tekst] for følgende klausuler: behandlingsomfang, underbehandlere, overføringssikkerhet, sikkerhetstiltak, varslingsperiode for brudd, sletting/retur, revisjonsrett. Merk "tilstede / mangler / usikker" for hver klausul. Minn på at juridisk godkjenning ikke er endelig dømt."
MAL 3 — Resultattavle for leverandørrisiko: "Sett opp en risikotavle med 8 kriterier for å sammenligne 3 AI-verktøy: DPA, dataplassering, opplæringsopt-out, ISO 27001, bruddvarsel, sletting, mønsterkort, kostnad. La hvert kriterium være 0-3 poeng, legg til total og anbefalingskolonne. Gi det en tom mal."
MAL 4 — Godkjent verktøylisteoppføring: "Utkast en ny oppføring i den godkjente AI-verktøylisten: verktøynavn, godkjent tiltenkt bruk, hvilke dataklasser som er tillatt (offentlige/interne/konfidensielle), forbudte datatyper, ansvarlig enhet, godkjenningsdato, gjennomgangsdato. I enkeltlinjeformat."
Svak forespørsel / Sterk forespørsel
SVAK: "Er dette AI-verktøyet trygt?"-> Gjentar markedsføringsløftet om modellverktøy; Den evaluerer ikke konkrete kriterier som DPA, dataplassering, treningsbruk. STERK: "Jeg vil evaluere dette AI-verktøyet for bedriftsbruk. Hvilken informasjon bør jeg be om fra leverandøren basert på følgende 8 kriterier (DPA, dataplassering, opplæringsopt-out, ISO 27001, bruddmelding, lagring, underbehandler, modellkort) og hva bør være den 'akseptable' terskelen i hvert kriterium? Oppgi i sjekkarkformat." -> Modellen produserer et konkret, etterprøvbart evalueringsrammeverk.
Vanlige feil
- Bruk av gratis/individuelle planer med bedriftsdata; Ikke klar over at det ikke er noen DPA og opt-out.
- Godkjenne verktøyet basert på markedsføringsløfte, ikke spørre om dataplassering og pedagogisk bruk.
- Dele data uten å signere en DPA eller sjekke underbehandlerklausulen.
- Godkjenne et kjøretøy uten/uvisst modellkort uten spørsmål.
- Holde en forbudsliste i stedet for en hvit liste og bli igjen med hvert nytt kjøretøy.
- Ikke gjennomgang av kjøretøyet igjen etter godkjenning (betingelsene endres).
- Baserer leverandørvalg på subjektive preferanser, ikke en sertifiserbar poengsum.
Oppsummert
- Hvert AI-verktøy er en databehandler; Systematisk evaluering er viktig før godkjenning.
- Databehandleravtalen (DPA) er det grunnleggende dokumentet som binder dataene; Den bør inkludere omfang, underbehandler, sikkerhet, brudd og slettingsklausuler.
- Gratis/individuelle planer tilbyr ofte ikke DPA og bruker data til trening; Bedriftsplaner bør foretrekkes.
- Modellkortet viser grensene og risikoene ved modellen; Fraværet er et varseltegn.
- Godkjente verktøy bør administreres som en hviteliste, og leverandører bør administreres med en dokumenterbar risikoscore.
Søknadsoppgave
Velg tre ekte AI-verktøy organisasjonen din kanskje vil bruke. Sett opp en leverandørrisikoscoretabell med åtte kriterier (DPA, dataplassering, opplæringsopt-out, sikkerhetssertifisering, bruddvarsling, oppbevaring, modellkort, kostnad) og score hvert kjøretøy fra 0-3 basert på disse kriteriene. Skriv deretter en godkjent kjøretøylisteoppføring for kjøretøyet med høyest score: godkjent tiltenkt bruk, tillatte dataklasser, forbudte datatyper, ansvarlig enhet og vurderingsdato. Til slutt, legg merke til fem elementer du definitivt vil se i et kjøretøys DPA og hvorfor hver av dem er viktig.
sjekkliste
- [ ] Jeg stilte evalueringsspørsmål før jeg godkjente verktøyet.
- [ ] Jeg avklarte dataplassering og brukscase i modelltrening.
- [ ] Jeg sjekket eksistensen av DPA og dens kritiske elementer.
- [ ] Jeg undersøkte modellkortet; Jeg så grensene og risikoene.
- [ ] Jeg evaluerte leverandøren med en dokumenterbar risikoscore.
- [ ] Jeg la verktøyet til hvitelisten med tillatte dataklasser.
- [ ] Jeg har satt en anmeldelsesdato.