On-prem vs sky-AI for sensitive dokumenter: risiko, kostnad, etterlevelse

On-premise versus sky-spørsmålet for AI på sensitive dokumenter blir som regel diskutert på feil nivå. Den ene leiren behandler det som en estetisk preferanse for suverenitet. Den andre behandler det som et bekvemmelighetsspørsmål i anskaffelser, best løst gjennom det skyforholdet man allerede har. Ingen av perspektivene fanger det beslutningen egentlig handler om.

Det ærlige svaret er et konkret regnestykke. Det har tre inndata: en Transfer Impact Assessment etter Schrems II^[1], en analyse av hendelseseksponering etter NIS2^[3], og en kostnadsanalyse som tar med reviderbarheten til den databehandleren som faktisk håndterer dataene. Denne artikkelen går gjennom hver av dem, og foreslår deretter et beslutningstre som holder på tvers av jus, helse, finans og offentlig sektor.

Schrems II-regnestykket

Schrems II-dommen fra 2020 ugyldiggjorde ikke skybaserte overføringer fra EU. Den ugyldiggjorde EU-USA Privacy Shield, bekreftet Standard Contractual Clauses (SCC-er) og påla hver overføring en ny plikt: eksportøren må gjennomføre en Transfer Impact Assessment som fastslår at loven i mottakerlandet gir et i hovedsak likeverdig beskyttelsesnivå etter EU-rett, eller spesifisere de supplerende tiltakene som tetter gapet.^[1]

EDPBs Recommendations 01/2020 beskriver hvordan supplerende tiltak ser ut i praksis.^[2] Anbefalingene skiller mellom tre tilfeller:

1. Use Case 1: krypterte data der nøklene holdes i EU. Akseptabelt, fordi den utenlandske behandleren ikke meningsfullt kan dekryptere.
2. Use Case 2: pseudonymiserte data der re-identifikasjonsnøkkelen blir værende i EU. Akseptabelt under tilsvarende betingelser.
3. Use Case 3: klartekstilgang for behandleren. Anbefalingene er tydelige: ingen avtalefestede eller organisatoriske tiltak kan kompensere for klartekstilgang hos en behandler som er underlagt uforholdsmessig overvåkingsmyndighet. Overføringen består ikke vurderingen.

Boten på 1,2 milliarder euro mot Meta i 2023 for EU-USA-overføringer^[4] viser at vurderingen håndheves, ikke at den er teoretisk. Det er den største GDPR-boten på rekord. Den ble håndhevet ikke fordi Meta er spesielt, men fordi overføringsarkitekturen ikke besto Use Case 3 og tilsynet sa det.

Hvor dette lander for AI på sensitive dokumenter

Skybasert AI for sensitive dokumenter innebærer som regel klartekstilgang. Modellen må lese dokumentet for å behandle det. Drives modellen av en amerikansk leverandør, må Transfer Impact Assessment ta hensyn til det amerikanske regelverket (FISA 702, Executive Order 12333, CLOUD Act). EDPBs Use Case 3-analyse gjelder. De supplerende tiltakene de fleste sky-AI-leverandører tilbyr (regionale datasentre, avtalefestede begrensninger, påstander om «ingen myndighetstilgang»), overstyrer ikke, slik EDPB leser det, den underliggende lovbaserte eksponeringen.

Tre veier ut av problemet:

• EU-basert leverandør som eier hele stacken (modell, drift, nøkkelhåndtering). Transfer Impact Assessment kan bestås; det som gjenstår av analyse, handler om lokal håndheving, ikke om grensekryssende overvåking.
• On-premise eller suveren sky-utrulling der modellen kjøres i ditt miljø og dataene aldri krysser en jurisdiksjonsgrense.
• Sterke supplerende tiltak, først og fremst kryptering på klientsiden med nøkler i EU, slik at utrullingen havner i Use Case 1 av EDPB-anbefalingene.

Det som ikke løser problemet: SCC-er alene, angivelse av datalokasjon alene, kontraktsfestede garantier alene.

NIS2-regnestykket for hendelseseksponering

NIS2, EUs utvidede cybersikkerhetsdirektiv, fikk nasjonal virkning på tvers av EU sent i 2024. Virkeområdet dekker en lang liste essensielle og viktige virksomheter, blant annet helse, offentlig forvaltning, bankvesen og leverandører av digital infrastruktur.^[3]

For vårt formål er det to artikler som gjør jobben.

Artikkel 21: risikohåndtering

Artikkel 21 krever at essensielle og viktige virksomheter har på plass hensiktsmessige tekniske, operasjonelle og organisatoriske tiltak for å håndtere cybersikkerhetsrisiko. Listen er detaljert: risikoanalyse, hendelseshåndtering, kontinuitet, sikkerhet i leverandørkjeden, sårbarhetshåndtering, tilgangskontroll, kryptering, flerfaktorautentisering, opplæring, og det avgjørende punktet: vurdering av cybersikkerhetspraksisen hos leverandører og direkte tjenestetilbydere.

Sky-AI-leverandører er direkte tjenestetilbydere. Plikten etter artikkel 21 ligger hos deg, ikke hos dem. Deres sikkerhetsposisjon, hvordan krav videreføres i underleverandørkontrakter, evnen til å støtte din hendelseshåndtering og oppførselen deres i tidligere hendelser, blir alt sammen del av din etterlevelse.

Artikkel 23: hendelsesrapportering

Artikkel 23 setter en stram tidsfrist for hendelsesrapportering. Vesentlige hendelser krever et tidlig varsel innen 24 timer, en innledende vurdering innen 72 timer, og en endelig rapport innen én måned. Klokka starter når du blir kjent med hendelsen.

Den operasjonelle konsekvensen: en sky-AI-leverandør som bruker 48 timer på å bekrefte at det har skjedd en hendelse i sitt miljø, setter deg i brudd med 24-timersfristen, selv om du selv responderer feilfritt. Leverandørens responshastighet er ditt problem, ikke deres.

On-premise-oppsett fjerner ikke denne eksponeringen; den flyttes til ditt eget hendelsesresponsteam. Regnestykket er om teamets klokke er kortere enn leverandørens. For de fleste regulerte virksomheter som har investert i sikkerhetsdrift, er svaret ja.

Norske særtrekk: Sikkerhetsloven

For virksomheter som driver i Norge, gjelder et ekstra lag. Sikkerhetsloven^[5] stiller spesifikke krav til skjermingsverdig informasjon og til virksomheter som håndterer sensitiv informasjon om statssikkerheten, blant annet aktsomhetsvurdering av leverandørkjeden og krav til behandlingssted. Sky-AI-behandling av materiale loven dekker, er i praksis begrenset; det tryggere mønsteret er lokal utrulling med dokumenterte kontroller.

For virksomheter som kan ende opp med å håndtere materiale Sikkerhetsloven berører (forsvarsleverandører, deler av energi og telekom, deler av offentlig sektor), må arkitekturen ofte være fremtidssikret selv om dagens arbeid ikke er sikkerhetsgradert. Å bygge for on-premise fra starten er billigere enn å bygge om i ettertid etter en kontraktsvinning.

Den faktiske kostnadsmodellen

Den vanlige antakelsen er at on-premise AI er dyrere enn sky-AI. Det er delvis sant i liten skala og delvis usant i stor skala, og diskusjonen utelater som regel fire kostnadslinjer som endrer regnestykket.

Egress og inferenspris per enhet

I stor skala blir sky-AI-inferens raskt dyrt når det faktureres per token. En selvhostet modell med åpne vekter på en passende dimensjonert GPU har en annen kostnadskurve: høy fast kostnad, nesten null marginalkostnad per forespørsel. Krysningspunktet avhenger av volum og modellstørrelse; for virksomheter som behandler titusenvis av dokumenter i måneden, er on-premise ofte billigere per enhet, selv før etterlevelseshensyn.

Kostnader til revisjon og TIA

Hvert leverandørforhold på sky-AI-siden som berører personopplysninger, trenger en Transfer Impact Assessment med jevnlig gjennomgang. Hver TIA koster juristtid, teknisk gjennomgangstid og dokumentasjonsarbeid. Gang opp antallet leverandører. On-premise fjerner TIA-eksponeringen for det arbeidet helt.

Kostnader til hendelsesrespons

Sannsynligheten for at en sky-AI-leverandør blir involvert i en sikkerhetshendelse i løpet av et år, er ikke ubetydelig. Hver slik hendelse utløser intern etterforskning, varslinger, kundekommunikasjon og ofte tilsynsdialog, uansett om dine egne data ble berørt eller ikke. On-premise fjerner denne eksponeringen for det arbeidet.

Innelåsing

Sky-AI-API-er endrer seg. Prisene endres. Modellversjoner går ut. Et arbeid som er avhengig av én bestemt leverandørs bestemte modell, er eksponert for alt dette. Modeller med åpne vekter kjørt på egen infrastruktur bytter noe toppkvalitet mot stabilitet i pris og oppførsel over tid.

Et beslutningstre som holder

På tvers av regulert arbeid avgjør fire spørsmål de fleste utrullingsbeslutninger.

1. Forlater dataene din jurisdiksjon i klartekst på noe punkt?

Hvis ja, gjelder Schrems II-analysen. Hvis du ikke kan fullføre den troverdig, er svaret on-premise eller suveren sky.

2. Er du en essensiell eller viktig virksomhet etter NIS2?

Hvis ja, omfatter risikohåndteringen for leverandører og fristene for hendelsesrapportering enhver sky-AI-leverandør i pipelinen. Leverandører som ikke kan vise til 24-timers hendelsesrespons, er ikke levedyktige. For arbeid med høy innsats reduserer on-premise eksponeringen mot leverandører.

3. Er arbeidet Sikkerhetsloven-relevant eller sektorgradert?

Hvis ja, eller kanskje: on-premise. Kostnaden ved å bygge om i ettertid er høy.

4. Er volumet høyt nok til at tokenfakturering dominerer TCO-en?

Hvis ja, er on-premise ofte billigere uansett etterlevelsesargumenter.

Hvis alle fire svar er nei (lavt volum, ingen grensekryssende problemer, ikke i NIS2-omfang, ikke i sensitiv sektor), er sky-AI det riktige valget. Det meste av regulert arbeid ligger ikke i den kvadranten.

Et mønster som faktisk virker

Utrullingsmønsteret som holder best gjennom vurderingen med disse fire spørsmålene, er:

• Kryptering på klientsiden av dokumenter før de forlater brukerens nettleser eller arbeidsstasjon.
• Lokal AI-behandling inne i kundens nettverk, eller i en suveren sky-region med drift kun i EU og nøkkelhåndtering i EU.
• Ingen lagring av klartekst i noe eksternt system etter at behandlingen er ferdig.
• Detaljerte tilgangslogger som tåler en gjennomgang fra tilsynet under ethvert relevant rammeverk.

Dette er ingen tilfeldighet. Det er arkitekturen som samtidig består Schrems II Use Case 1, oppfyller leverandørkravene i NIS2 artikkel 21, ligger innenfor begrensningene i Sikkerhetsloven der de gjelder, og gir kjøperen et dokumentasjonsspor. At den ofte også er billigere i skala, er en bonus, ikke poenget.

Poenget er at spørsmålet om on-premise eller sky for AI på sensitive dokumenter ikke er en preferanse. Det er et regnestykke. Gjort ærlig ender det ofte med ett svar for regulert arbeid med høy innsats og et annet for arbeid med lav innsats. Feilen er å behandle begge typer arbeid likt.