Fem personvernkrav til AI-leverandøren før du signerer

Nøkkelpunkter per 26. august 2026:

• Zero Data Retention betyr at kvalifiserte API-kunder får løfte om at prompts og modellsvar ikke beholdes etter behandling (OpenAI, 2026).
• Totalforbud er på vei ut: andelen organisasjoner med fullt forbud mot generativ AI har falt kraftig på ett år, fra 28 prosent i 2025 til et lite mindretall året etter (secureframe.com).
• Datalekkasjer fra generativ AI er den ledende sikkerhetsbekymringen, oppgitt av 34 prosent av organisasjonene (secureframe.com).
• Staben krymper mens kravene vokser: median personvernstab er nå fem personer, ned fra åtte året før (secureframe.com).
• Preview er ikke leveranse: Private Safety Processing testes med tidlige kunder, og teknisk hvitbok er varslet i september (OpenAI).

---

Hva Zero Data Retention faktisk betyr for API-kunder

Zero Data Retention har på kort tid gått fra teknisk fotnote til salgsargument. Kjernen er enkel nok: kvalifiserte API-kunder får et løfte om at leverandøren ikke beholder spørsmålene eller svarene etter at en forespørsel er behandlet (OpenAI, 2026). Det er en reell forskjell fra hvordan mange skytjenester håndterer inndata som standard. Men et løfte som bare finnes på en produktside, har begrenset verdi den dagen Datatilsynet spør hva du faktisk har sikret deg.

For en norsk SMB som skal ta AI inn i kundeservice, saksbehandling eller dokumentproduksjon, er dette ikke en akademisk øvelse. Personopplysninger havner i prompts, ofte uten at noen har planlagt det. Da er spørsmålet ikke om leverandøren sier at data slettes, men hvor det står, hvem det binder, og hva du kan kreve dokumentert.

Løftet i klartekst

Formuleringen er presis og verdt å lese ordrett. Zero Data Retention gir kvalifiserte API-kunder løftet om at leverandøren ikke beholder deres prompts eller modellsvar etter at forespørselen er behandlet (OpenAI). Det er innholdet i forespørselen som dekkes. Legg merke til to ord som gjør mye arbeid: «kvalifiserte» og «etter at forespørselen er behandlet».

Under behandling må dataene åpenbart eksistere et sted. Løftet handler om hva som skjer etterpå. Det gjør ZDR til et lagringsløfte, ikke et løfte om at data aldri forlater din maskin. Den distinksjonen er den viktigste du tar med deg inn i forhandlingen.

Hva løftet ikke automatisk dekker

Et løfte om at innhold ikke beholdes, sier ingenting i seg selv om metadata, driftslogger, fakturagrunnlag eller misbruksovervåking. Det sier heller ingenting om hva som skjer i ditt eget lag: mellomlagring i din applikasjon, vektordatabaser, chattelogger i grensesnittet eller kopier i et CRM. Mange virksomheter kjøper ZDR fra leverandøren og bygger deretter sin egen fullstendige logg rett ved siden av.

Kravlisten din må derfor dekke hele kjeden, ikke bare modellkallet. Spør konkret: hvilke felter logges for drift, hvor lenge, hvem har tilgang, og hva slettes ved opphør. Får du ikke svar på det skriftlig, har du ikke kjøpt personvern. Du har kjøpt en formulering.

Kvalifisert kunde er ikke det samme som alle kunder

Ordet «kvalifiserte» betyr at ZDR ikke nødvendigvis er standard for enhver konto, ethvert produkt eller enhver modell. Det er en konfigurasjon som må være aktiv for akkurat din bruk. Sjekk derfor tre ting før du antar noe: gjelder det kontoen din, gjelder det modellene du faktisk bruker, og gjelder det alle endepunktene i integrasjonen.

Her ligger også det vanligste blindpunktet i norske SMB-er: konsumentabonnementet ansatte bruker i nettleseren, er en annen avtale enn API-et utviklerne kobler seg på. Vilkårene kan være ulike selv om logoen er den samme. Behandle dem som to separate anskaffelser, med hver sin vurdering.

Databehandleravtalen og hvor Zero Data Retention hører hjemme

Når leverandøren behandler personopplysninger på dine vegne, er du behandlingsansvarlig og de er databehandler. GDPR krever da en skriftlig databehandleravtale som regulerer formål, varighet, sikkerhet, underleverandører, bistand og sletting. Dette er kjent stoff for de fleste ledere. Det nye er at AI-leverandører ofte pakker de mest interessante løftene inn i produktkommunikasjon i stedet for avtaletekst.

Regelen du kan bruke som filter er kort: hvis løftet ikke kan brytes, kan det heller ikke håndheves. En påstand på en nettside kan endres uten varsel. En avtalebestemmelse kan ikke. Tabellen under viser hvor de vanligste AI-løftene bør lande.

Løfte fra leverandøren	Hvor det må stå	Bevis du ber om
Zero Data Retention	Databehandleravtale eller bindende tjenestevedlegg	Skriftlig bekreftelse på at akkurat din konto og dine endepunkter er kvalifisert
Ingen trening på dine data	Avtaletekst, ikke FAQ eller blogginnlegg	Bestemmelse som også binder underleverandører
Behandlingssted og infrastruktur	Vedlegg om behandlingssted	Navngitt region og beskrivelse av driftsmodell
Kryptering og nøkkelkontroll	Sikkerhetsvedlegg	Beskrivelse av hvem som genererer, oppbevarer og kan trekke tilbake nøkler
Underleverandører	Underleverandørliste med varslingsplikt	Oppdatert liste, varselfrist og innsigelsesrett
Sletting ved opphør	Exit-bestemmelser	Slettebekreftelse innen avtalt frist, i lesbart format

Produktsiden er markedsføring, avtalen er forpliktelse

Alura mener personvernløfter skal kunne etterprøves i kontrakt og dokumentasjon, ikke bare i leverandørens markedsføring. Det er ikke mistillit til den enkelte leverandøren. Det er en erkjennelse av at ansvaret følger deg som behandlingsansvarlig uansett hva leverandøren har skrevet i en lansering.

Praktisk betyr det at du ber om avtaleutkastet tidlig, ikke etter at teknisk pilot er ferdig. Leverandører som har orden på dette, sender dokumentene uten motstand. De som svarer med lenker til hjelpesenteret, forteller deg noe nyttig om hvor modent kundeforholdet kommer til å bli.

Det avtalen må navngi konkret

En databehandleravtale som bare gjentar lovteksten, er verdiløs i en AI-anskaffelse. Den må navngi hvilke kategorier personopplysninger som kan forekomme i prompts, hvilke formål behandlingen har, hvor lenge noe eventuelt lagres, og hvilke tekniske tiltak som gjelder. Er svaret «kunden bestemmer selv hva som sendes inn», har du fått en ansvarsfraskrivelse forkledd som fleksibilitet.

Be også om at avtalen skiller mellom innhold og driftsdata. Zero Data Retention håndterer innhold. Driftsdata må reguleres for seg, med egen oppbevaringstid. Uten det skillet blir diskusjonen uklar akkurat der den burde vært skarpest.

Endringer, varsling og retten til å si nei

AI-leverandører endrer arkitektur oftere enn tradisjonelle programvareleverandører. Nye underleverandører, nye regioner og nye funksjoner kommer fortløpende. Avtalen må derfor gi deg varsel i rimelig tid før endringer som påvirker behandlingen, og en reell mulighet til å motsette deg dem.

Innsigelsesrett uten konsekvens er tomt. Koble den til en hevingsrett med rimelig oppsigelsesfrist og plikt til å bistå ved migrering. Det er den eneste mekanismen som gir en liten kunde faktisk forhandlingskraft etter signering.

---

Les også: Lavkode og no-code AI-verktøy: AI uten programmering for norske SMB-er. Norske SMB-er står for over halvparten av alle ansatte i privat sektor, men mange bruker fortsatt manuelle ...

---

Fem personvernkrav du stiller før signering

Kravene under er formulert slik at de kan limes rett inn i et anskaffelsesdokument eller en tilbudsforespørsel. Poenget er ikke å være vanskelig. Poenget er at hvert krav skal kunne etterprøves med et dokument, ikke bare bekreftes muntlig i et møte.

Krav	Slik formuleres det	Dokumentasjon du ber om
1. Zero Data Retention	Leverandøren skal ikke beholde prompts eller modellsvar etter at forespørselen er behandlet	Bekreftelse på ZDR-kvalifisering for konto, modeller og endepunkter
2. Ingen trening på kundedata	Kundeinnhold skal ikke brukes til trening eller finjustering av generelle modeller	Avtalebestemmelse som også binder underleverandører
3. Kontroll over infrastruktur og nøkler	Kundeinnhold skal ligge på infrastruktur kunden kontrollerer, eller krypteres med nøkler kunden kontrollerer	Arkitekturbeskrivelse og nøkkelhåndteringsrutine
4. Tilgang, logging og varsling	Leverandørpersonell skal ikke ha tilgang til kundeinnhold, og avvik varsles innen avtalt frist	Tilgangsmodell, loggoversikt og varslingsprosedyre
5. Sletting og exit	Alle data slettes ved opphør, og kunden får eksportert sitt materiale i åpent format	Skriftlig slettebekreftelse og eksportbeskrivelse

Krav 1: Zero Data Retention som anskaffelseskrav

Alura mener Zero Data Retention bør stå som et eksplisitt anskaffelseskrav, ikke som en forhandlingsbonus man håper å få med. Forskjellen er ikke retorisk. Et krav i konkurransegrunnlaget tvinger leverandøren til å svare før prisen er satt. En bonus man ber om til slutt, blir raskt til «det kan vi se på i neste fase».

Formuler kravet med leverandørens egne ord, siden de allerede er offentlige: ingen oppbevaring av prompts eller modellsvar etter behandling (OpenAI, 2026). Da må en leverandør som ikke tilbyr dette, si det høyt i stedet for å svare rundt spørsmålet.

Krav 2: Ingen trening på dine data, i avtaletekst

Dette er et annet krav enn ZDR, og forveksles ofte med det. Et løfte om at data ikke beholdes, og et løfte om at data ikke brukes til å trene modeller, er to separate forpliktelser. En leverandør kan i prinsippet oppfylle det ene uten det andre, avhengig av hvordan behandlingen er satt opp.

Krev derfor begge deler skriftlig, og krev at bestemmelsen følger med nedover i kjeden. Hvis leverandøren bruker underleverandører til deler av behandlingen, må forbudet mot treningsbruk gjelde dem også. Ellers har du plugget hovedhullet og latt sidedøren stå åpen.

Krav 3: Dokumentert kontroll over infrastruktur og nøkler

For ZDR-distribusjoner er utgangspunktet at kundeinnhold forblir på infrastruktur som kunden kontrollerer (OpenAI). Det er en sterk posisjon, og den bør stå i avtalen med en beskrivelse av hva «kontrollerer» betyr i praksis.

Der leverandøren tilbyr egen lagring i stedet, er alternativet at innholdet krypteres med nøkler kunden kontrollerer (OpenAI, 2026). Da flytter spørsmålet seg fra hvor dataene ligger til hvem som kan låse dem opp. Be om å få rutinen for nøkkelgenerering, oppbevaring og tilbaketrekking beskrevet, ikke bare bekreftet.

Krav 4: Tilgang, logging og varsling ved avvik

Det avgjørende spørsmålet er ikke om leverandøren har gode intensjoner, men om et menneske hos leverandøren teknisk kan lese innholdet ditt. I designet bak Private Safety Processing er svaret at leverandørpersonell ikke får tilgang til kundeinnholdet, heller ikke når noe flagges som risiko (OpenAI). Det er akkurat den typen påstand du skal be om å få bekreftet i avtale og dokumentasjon.

Legg til krav om varslingsfrist ved sikkerhetsbrudd og om bistand ved innsynsbegjæringer. En liten organisasjon har ikke kapasitet til å håndtere et avvik alene. Bistandsplikten er det du faktisk kommer til å bruke hvis det smeller.

Krav 5: Sletting, eksport og exit uten gissel

Exit-bestemmelsen er kravet flest hopper over og flest angrer på. Den skal si hva som slettes, når, hvordan det bekreftes, og hva du får med deg ut. Uten et krav om eksport i åpent format risikerer du at prompts, konfigurasjon og evalueringsdata blir liggende igjen hos leverandøren.

Sett en konkret frist for slettebekreftelse etter opphør, og krev at bekreftelsen dekker sikkerhetskopier. Det er en billig bestemmelse å få inn før signering og en dyr en å få inn etterpå. Se også vår gjennomgang av AI-leverandørvalg for øvrige kontraktspunkter.

Praktisk sjekkliste: spørsmålene du sender mandag morgen

Kravene over er hva du vil oppnå. Spørsmålene under er hvordan du finner ut om leverandøren kan levere. De er formulert slik at et unnvikende svar er lett å kjenne igjen, også for en leder uten juridisk bakgrunn.

Spørsmål til leverandøren	Godt svar	Varselsignal
Er vår konto kvalifisert for Zero Data Retention, og for hvilke modeller?	Skriftlig bekreftelse med navngitte modeller og endepunkter	«ZDR er tilgjengelig for enterprise-kunder» uten videre presisering
Hvor står dette i avtalen?	Henvisning til punkt i databehandleravtale eller vedlegg	Henvisning til hjelpesenter, blogg eller salgspresentasjon
Hvilke driftsdata lagres, og hvor lenge?	Konkret liste med oppbevaringstid per kategori	«Kun det som er nødvendig for tjenesten»
Hvem hos dere kan teknisk lese vårt innhold?	Beskrevet tilgangsmodell med begrunnede unntak	«Ingen har tilgang» uten forklaring på hvordan det håndheves
Hvilke underleverandører brukes, og hvordan varsles endringer?	Oppdatert liste, varselfrist og innsigelsesrett	Liste som ikke er datert, eller varsling «ved behov»
Hva skjer med dataene våre 30 dager etter oppsigelse?	Definert sletteprosess med skriftlig bekreftelse	Svar som forutsetter at dere selv rydder opp

Hvordan du leser svarene

Vurder svarene på to akser: presisjon og plassering. Presisjon handler om hvorvidt svaret inneholder navngitte systemer, tidsfrister og roller. Plassering handler om hvor forpliktelsen bor. Et presist svar i en e-post er bedre enn ingenting, men det er ikke det samme som en avtalebestemmelse.

Vær særlig oppmerksom på svar som flytter ansvaret tilbake til deg uten å si det direkte. «Kunden er selv ansvarlig for hva som sendes inn» er formelt riktig og praktisk ubrukelig som eneste svar. Du trenger å vite hva som skjer med det som faktisk sendes inn, siden noe alltid vil bli sendt inn.

Hvem i egen organisasjon må være med

En AI-anskaffelse som bare eies av IT, ender som regel med et teknisk godt oppsett og en tynn avtale. En som bare eies av innkjøp, ender med det motsatte. Sett sammen et lite team med en teknisk eier, en avtaleeier og en fageier fra avdelingen som skal bruke verktøyet.

Fageieren er ofte den viktigste og den som glemmes. Det er den personen som vet hvilke personopplysninger som faktisk kommer til å havne i en prompt når saksbehandleren har det travelt. Metoden er den samme som i andre AI-anskaffelser: kartlegg reell bruk før du vurderer vilkår.

Private Safety Processing og hva preview betyr i en anskaffelse

Et av spørsmålene som melder seg raskt når leverandøren ikke lagrer noe, er hvordan misbruk da skal oppdages. Svaret markedet nå prøver ut, er systemer som ser mønstre uten å se innhold. Private Safety Processing er designet for å identifisere mønstre på tvers av relaterte interaksjoner uten å gi leverandørens personell tilgang til det underliggende innholdet (OpenAI, 2026).

Det er en teknisk interessant konstruksjon, og den er relevant for kjøpere fordi den påvirker hvordan du beskriver behandlingen i din egen dokumentasjon. Men den er også fersk, og det får konsekvenser for hva du kan bygge en signert avtale på.

Signal i stedet for innhold

Mekanismen er verdt å forstå på leder-nivå. Systemet bruker kundeinnhold uansett hvor det er lagret, og med leverandørlevert lagring er innholdet kryptert med nøkler kunden kontrollerer (OpenAI). Når en risiko identifiseres, mottar leverandøren et smalt definert signal som indikerer typen aktivitet.

Personell får altså ikke tilgang til innholdet selv når noe flagges (OpenAI, 2026). Hvis dette holder i praksis, er det en av få konstruksjoner som løser motsetningen mellom sikkerhetsovervåking og datamininering på en måte som lar seg forklare til et styre.

Preview er ikke leveranse

Alura mener funksjoner som fortsatt er i preview ikke bør legges til grunn i en signert avtale før teknisk dokumentasjon foreligger. Private Safety Processing testes for tiden med tidlige kunder, og leverandøren planlegger å begynne utrulling og publisere en teknisk hvitbok i september (OpenAI).

Det gir deg en enkel og profesjonell forhandlingsposisjon: kravene dine gjelder det som er i drift i dag, og funksjoner under utrulling behandles som opsjon med egen vurdering når dokumentasjonen kommer. Kunngjøringen er datert 19. august 2026 (OpenAI, 2026), så tidslinjen er kort nok til at det er verdt å vente på hvitboken før du binder deg.

Hvem kontrollerer infrastrukturen og krypteringsnøklene

Under alle personvernløfter ligger et enkelt maktspørsmål: hvem kan teknisk hente ut dataene? Svaret avgjøres av hvor innholdet ligger og hvem som holder nøklene. Alt annet er detaljer rundt det.

Modell	Hvem kontrollerer lagringen	Dette må avklares i avtalen
ZDR-distribusjon	Kunden. Innholdet forblir på infrastruktur kunden kontrollerer	Hva som defineres som innhold, og hva som regnes som driftsdata utenfor løftet
Leverandørlagring med kundens nøkler	Leverandøren lagrer, kunden holder nøklene	Nøkkelgenerering, rotasjon, tilbaketrekking og hva som skjer ved nøkkeltap
Standard leverandørlagring	Leverandøren, uten kundekontrollerte nøkler	Oppbevaringstid, tilgangsmodell og om oppsettet i det hele tatt er akseptabelt for deres data

Kundekontrollert infrastruktur

At kundeinnhold forblir på infrastruktur kunden kontrollerer, er det sterkeste utgangspunktet i tabellen (OpenAI, 2026). Men «kontrollerer» må defineres. Betyr det din egen sky-konto, din egen region, eller en logisk adskilt del av leverandørens miljø?

Be om et arkitekturdiagram og få det vedlagt avtalen. Et diagram er lettere å etterprøve enn en setning, og det gir revisor noe konkret å se på senere. Dette er også dokumentet du trekker frem hvis en kunde av deg stiller de samme spørsmålene videre.

Når nøkkelkontroll er den reelle garantien

I modellen der leverandøren lagrer og du holder nøklene, er nøkkelrutinen selve personvernet. Krypteringen er bare like sterk som prosessen rundt nøklene. Avklar derfor hvem som kan be om utlevering, hvordan tilbaketrekking fungerer, og hva som teknisk skjer med dataene i det øyeblikket en nøkkel trekkes tilbake.

Dette er også stedet å være ærlig om egen kapasitet. Nøkkelkontroll er et ansvar, ikke bare en rettighet. En organisasjon uten rutiner for nøkkelhåndtering får ikke bedre personvern av å holde nøkler den ikke klarer å administrere.

Markedet i 2026: fra totalforbud til kontrollert bruk

For et par år siden var reaksjonen i mange virksomheter å stenge døren. Det bildet har snudd raskt. Andelen organisasjoner med totalforbud mot generativ AI har falt kraftig, fra 28 prosent i 2025 til et lite mindretall i 2026 (secureframe.com). Forbudet er ikke lenger normen, det er unntaket.

Alura mener totalforbud sjelden er riktig svar for norske SMB-er, og at kontrollkrav i avtalen er en mer holdbar styringsmekanisme. Et forbud flytter bruken ut av synsfeltet uten å fjerne behovet som skapte den. Kontrollkrav flytter bruken inn i noe du kan revidere.

Personvernprogrammene vokser med AI

Samtidig som forbudene faller, utvides arbeidet rundt. Ni av ti organisasjoner rapporterer at personvernprogrammene har utvidet omfang på grunn av AI (secureframe.com). Det er ikke overraskende, men det har en praktisk konsekvens: personvern er blitt en linjeoppgave i AI-prosjekter, ikke et sluttsjekkpunkt.

For en SMB betyr det at vurderingen bør skje samtidig med verktøyvalget. Å velge løsning først og deretter oppdage at behandlingsgrunnlaget ikke holder, er den dyreste rekkefølgen. Se også oversikten over AI-verktøy for bedrifter når dere setter opp kandidatlisten.

Fra forbud til styringsmekanismer som holder

Et forbud er lett å vedta og vanskelig å håndheve. Kontrollkrav er vanskeligere å vedta og lettere å håndheve, fordi de er knyttet til dokumenter og leverandørforhold i stedet for til de ansattes selvdisiplin. Kombinasjonen som fungerer for de fleste SMB-er er tre lag: godkjente verktøy, klare regler for hva som ikke skal limes inn, og avtaler som tåler at reglene av og til brytes.

Det tredje laget er det som skiller en gjennomtenkt policy fra et ønske. Antakelsen bør være at noen kommer til å sende inn personopplysninger ved et uhell. Spørsmålet avtalen skal svare på, er hva som da skjer med dataene.

---

Les også: Generativ AI: Revolusjonerer innholdsproduksjon for norske bedrifter. Schibsted sparer 13 000+ timer med AI-transkripsjon, VG ser 19 % klikkrate på AI-sammendrag, og Forrester ...

---

Hva personvernarbeidet koster når staben er fem

Ressursbildet er stramt. Median personvernstab er nå fem personer, ned fra åtte året før (secureframe.com). I norske SMB-er er tallet ofte langt lavere: en person med personvern som en av flere hatter. Det er den virkeligheten kravlisten din må passe inn i.

Konsekvensen er at du må velge hva som gjøres grundig og hva som gjøres raskt. Tabellen under er en prioriteringsmodell for et lite team som skal gjennom en AI-anskaffelse uten å stoppe opp.

Oppgave	Hva det krever	Kan det vente?
Kartlegge hvilke personopplysninger som havner i prompts	En workshop med fageier og teknisk eier	Nei. Alt annet bygger på dette
Sikre ZDR og treningsforbud i avtalen	Krav i forespørsel, gjennomgang av avtaleutkast	Nei. Kan ikke rettes etter signering
Risikovurdering av behandlingen	Strukturert dokument, ikke et notat i en e-post	Nei, men kan gjøres parallelt med pilot
Rutine for nøkkelhåndtering	Definerte roller og prosess	Bare hvis dere velger kundekontrollerte nøkler
Opplæring av brukerne	Kort, konkret og gjentatt	Kan starte enkelt og utvides
Revisjon av leverandørens dokumentasjon	Årlig gjennomgang	Ja, men sett datoen nå

Budsjettene øker, men ikke overalt

43 prosent av organisasjonene økte personvernutgiftene det siste året (secureframe.com). Med et arbeidsomfang som vokser i takt med AI-bruken, betyr det at de øvrige skal levere mer for det samme. Det er en gjenkjennelig situasjon for de fleste norske mellomledere.

Samtidig er avkastningen godt dokumentert: 99 prosent av organisasjonene rapporterer minst en konkret fordel fra personverninitiativer (secureframe.com). Det er et brukbart argument å ha med inn i budsjettdiskusjonen, men bare hvis du kan peke på hvilken fordel du sikter mot: raskere salgsprosesser, færre avvik, eller kortere svartid på kundenes sikkerhetsskjemaer.

Slik prioriterer en liten organisasjon

Belastningen er reell. Nær to av tre personvernprofesjonelle, 65 prosent, sier rollen er mer stressende nå enn for fem år siden (secureframe.com). Når kapasiteten er knapp, er den beste investeringen å flytte arbeid fra løpende oppfølging til engangsarbeid i kontrakten.

Et krav du får inn i avtalen en gang, jobber for deg hver dag etterpå. En rutine som krever manuell oppfølging hver uke, konkurrerer med alt annet på skrivebordet og taper som regel. Prioriter derfor kontraktsarbeid, tilgangsstyring og standardvalg fremfor kontrollpunkter som forutsetter at noen har tid.

Regulatorisk bilde: 179 av 240 jurisdiksjoner har rammeverk

Personvernregulering er ikke lenger et europeisk særtilfelle. 179 av 240 jurisdiksjoner har nå databeskyttelsesrammeverk (secureframe.com). For en norsk virksomhet med kunder eller ansatte i flere land betyr det at GDPR er utgangspunktet, ikke hele bildet.

Det praktiske utslaget i en AI-anskaffelse er at spørsmålet «hvor behandles dataene» får flere lag. Du må vite hvor behandlingen skjer, hvor eventuell lagring skjer, og hvilke regler som gjelder for underleverandører i andre land.

Geografi hører hjemme i avtalen, ikke i en antakelse

Krev at behandlingssted er navngitt i et vedlegg og at endringer utløser varslingsplikt. En leverandør som svarer «vi bruker europeiske datasentre» uten å ville skrive det ned, gir deg ikke noe du kan vise til senere.

Husk at overføring til land utenfor EØS krever et gyldig overføringsgrunnlag. Det er ditt ansvar som behandlingsansvarlig å kunne dokumentere hvilket grunnlag som brukes, uansett hvor stor leverandøren er. Standardavtaler alene er ikke et svar, de er et utgangspunkt for en vurdering.

Dokumentasjonsplikten treffer kjøperen

Det er en fristende feilslutning at en stor internasjonal leverandør «tar seg av» etterlevelsen. Leverandøren tar seg av sin egen. Din dokumentasjonsplikt, protokoll over behandlingsaktiviteter og risikovurdering er fortsatt din.

Den gode nyheten er at arbeidet gjenbrukes. Har du gjort en ordentlig vurdering for det første AI-verktøyet, er det andre langt raskere. Bygg malene mens du er i den første anskaffelsen, ikke etterpå.

Markedsobservasjon: datalekkasjer fra generativ AI topper risikolisten

Når organisasjoner blir spurt om hva de frykter mest, er svaret entydig nok til å styre etter. Datalekkasjer fra generativ AI er den ledende sikkerhetsbekymringen, oppgitt av 34 prosent (secureframe.com). Det er ikke modellkvalitet, kostnad eller opphavsrett som troner øverst. Det er lekkasje.

Det er nyttig informasjon når du skal prioritere tiltak, fordi det peker mot hvor kontrollene bør sitte: i grensesnittet mellom mennesker og verktøy, og i vilkårene som styrer hva som skjer med det som sendes inn.

Hvor lekkasjer faktisk oppstår

De fleste hendelser handler ikke om at en modell «husker» noe den ikke skulle. De handler om at et dokument ble limt inn i feil verktøy, at en integrasjon fikk bredere tilgang enn nødvendig, eller at en logg i egen applikasjon lagret hele samtalen. Ingen av disse løses av leverandørens produktside.

Derfor bør kontrollene dine dekke tre punkter: hvilke verktøy som er godkjent, hva integrasjonen har tilgang til, og hva du selv lagrer. Det siste punktet er det som oftest overses i virksomheter som ellers har god orden.

Tiltak som faktisk reduserer risikoen

Prioriter tilgangsstyring foran deteksjon. Å begrense hva en AI-integrasjon kan lese, gir mer effekt per krone enn å overvåke hva som skjer etterpå. Gi hver integrasjon minste nødvendige tilgang, og revider tilgangene når bruken endrer seg.

Legg deretter til enkel, konkret opplæring med eksempler fra egen virksomhet. «Ikke lim inn personopplysninger» er for abstrakt. «Ikke lim inn hele sykefraværsdokumentet, bruk sammendraget uten navn» virker. Dette gjelder like mye når AI brukes til innholdsproduksjon som til saksbehandling.

Vanlige feil norske SMB-er gjør i AI-anskaffelser

Feilene under går igjen på tvers av bransjer og størrelser. De har det til felles at de er billige å unngå før signering og kostbare å rette etterpå.

Å forveksle konsumentabonnement med API-avtale

Den vanligste feilen er å lese vilkårene for API-et og tro at de gjelder nettleserverktøyet de ansatte allerede bruker, eller omvendt. Det er to produkter med to sett vilkår, og ofte to ulike beslutninger.

Kartlegg begge før du konkluderer. En rask oversikt over hvem som bruker hva, avdekker som regel minst ett verktøy ingen visste var i bruk. Det er ikke et disiplinproblem, det er et signal om et udekket behov.

Å godta «vi trener ikke på dine data» uten definisjon

Setningen høres avklarende ut, men reiser flere spørsmål enn den svarer på. Gjelder den alle modeller? Gjelder den også finjustering? Gjelder den underleverandører? Og hvor står den, i avtalen eller i en FAQ som kan endres på en ettermiddag?

Be om definisjonen skriftlig og be om plasseringen. Er svaret upresist på begge punkter, er du tilbake til det Alura mener er kjernen: løftet må kunne etterprøves i kontrakt og dokumentasjon, ikke bare i markedsføringen.

Å behandle ZDR som en bonus og exit som en formalitet

Mange tar opp Zero Data Retention i siste forhandlingsrunde, som noe fint å få med hvis det er tid. Da er prisen satt og motivasjonen for å strekke seg liten. Kravet hører hjemme i forespørselen, ikke i sluttspurten.

Exit-bestemmelsen lider av samme skjebne. Den skrives sist, av folk som er slitne, og blir stående som en generisk formulering. Skriv den tidlig, mens dere fortsatt er nysgjerrige på hva som faktisk skjer med dataene når samarbeidet tar slutt. Om dere først skal bygge selv, gjelder de samme kravene også for lavkode- og no-code-verktøy.

Ofte stilte spørsmål om Zero Data Retention og personvern

Spørsmålene under er de som oftest kommer opp i ledergrupper som står midt i en AI-anskaffelse.

Gjelder Zero Data Retention automatisk for alle kunder?

Nei. Løftet er formulert for kvalifiserte API-kunder, ikke for enhver konto eller ethvert produkt (OpenAI, 2026). Be om skriftlig bekreftelse på at akkurat din konto, dine modeller og dine endepunkter er dekket, og få bekreftelsen knyttet til avtalen.

Er Zero Data Retention nok til å oppfylle GDPR?

Nei. ZDR er et sterkt teknisk tiltak, men det erstatter ikke behandlingsgrunnlag, databehandleravtale, informasjonsplikt eller risikovurdering. Du er fortsatt behandlingsansvarlig. ZDR reduserer risikoen ved leverandørleddet og forenkler vurderingen, men vurderingen må gjøres.

Hva er forskjellen på ZDR og at leverandøren ikke trener på dataene mine?

ZDR handler om oppbevaring: prompts og modellsvar beholdes ikke etter at forespørselen er behandlet (OpenAI). Treningsforbud handler om bruk: at innholdet ditt ikke inngår i trening eller finjustering av generelle modeller. Krev begge, hver for seg, i avtaleteksten.

Kan vi legge en funksjon som er i preview til grunn i avtalen?

Det bør du unngå. Private Safety Processing testes med tidlige kunder, og teknisk hvitbok er varslet i september (OpenAI, 2026). Alura mener preview-funksjoner ikke hører hjemme som forutsetning i en signert avtale før dokumentasjonen foreligger. Behandle dem som opsjon med egen vurdering.

Bør vi bare forby generativ AI internt?

Sjelden. Andelen med totalforbud har falt kraftig på ett år (secureframe.com), og Alura mener totalforbud sjelden er riktig svar for norske SMB-er. Et forbud fjerner oversikten uten å fjerne behovet. Godkjente verktøy med kontrollkrav i avtalen gir bedre styring og lar seg faktisk følge opp.

Oppsummering og neste steg i anskaffelsen

Personvern i AI-anskaffelser koker ned til et spørsmål om plassering. De samme løftene som ser sterke ut på en produktside, blir etterprøvbare først når de står i databehandleravtalen med navngitte systemer, frister og roller. Det er hele forskjellen mellom en beslutning du kan forsvare og en du håper ingen spør om.

Rekkefølgen som fungerer

Start med kartleggingen av hvilke personopplysninger som realistisk havner i prompts. Sett deretter de fem kravene inn i forespørselen før prisen forhandles. Be om avtaleutkast og arkitekturbeskrivelse tidlig, og la den tekniske piloten gå parallelt med den juridiske gjennomgangen i stedet for etter den.

Hold funksjoner under utrulling utenfor forpliktelsene inntil dokumentasjonen foreligger, og sett en dato for når du vurderer dem på nytt. For funksjoner varslet med hvitbok i september er den datoen enkel å sette.

Tre ting å gjøre denne uken

Send sjekklistens spørsmål til leverandøren du er nærmest å velge, og se hvor lang tid det tar før du får skriftlige svar med henvisning til avtalepunkter. Svartiden i seg selv er nyttig informasjon.

Gå deretter gjennom hva dere selv lagrer i egen applikasjon, siden det er der mange lekkasjer starter uansett hvor godt leverandøravtalen er skrudd sammen. Til slutt: sett ZDR og treningsforbud inn som faste punkter i innkjøpsmalen, slik at neste anskaffelse starter et hakk lenger fremme enn denne gjorde.

I Alura kombinerer vi teknisk AI-kompetanse med praktisk forståelse for GDPR, EU AI Act og Datatilsynets forventninger. Vi hjelper norske virksomheter å bygge AI som tåler en revisjon, uten å bremse innovasjonen.

Bestill en compliance-vurdering: vi kartlegger dine AI-systemer mot gjeldende og kommende krav, og leverer en handlingsplan som faktisk er gjennomførbar. Uforpliktende.

Kilder

• OpenAI (2026). OpenAI reaffirms Zero Data Retention for API customers, previews Private Safety Processing
• secureframe.com. 110+ Data Privacy Statistics: The Facts You Need To Know In 2026
• secureframe.com. 110+ Data Privacy Statistics: The Facts You Need To Know In 2026
• OpenAI. OpenAI offers Zero Data Retention for frontier models