GDPR gjelder for AI hver gang et AI-system behandler personopplysninger, enten du trener en modell, finjusterer en eller bare lar teamet ditt lime kunderegistre inn i en assistent. Du trenger et dokumentert formål, et behandlingsgrunnlag for hvert trinn, en vurdering av personvernkonsekvenser der risikoen er høy, og en måte for folk å få en avgjørelse fra et menneske når en automatisert avgjørelse påvirker dem. EU AI Act kommer i tillegg og innfører egne plikter, blant annet om åpenhet. Denne veiledningen forklarer hvordan de to henger sammen for et B2B SaaS-selskap, og hva du bør gjøre først.

Dette er generell informasjon, ikke juridisk rådgivning. Personvernombudet eller juristen din bør bekrefte hvordan det gjelder for selskapet ditt.

Kort fortalt

Innholdsfortegnelse

Hvordan GDPR gjelder for AI

GDPR regulerer personopplysninger, ikke teknologi. En analyse av loven påpeker at AI ikke er nevnt eksplisitt, og at artikkel 22 om automatiserte avgjørelser fungerer som en indirekte kontroll av AI. Alt annet kommer fra de generelle prinsippene: lovlighet, rettferdighet, åpenhet, formålsbegrensning, dataminimering, riktighet, lagringsbegrensning, sikkerhet og ansvarlighet.

For et SaaS-selskap er det praktiske spørsmålet enkelt. Ser AI-en navn, e-postadresser, bruksloggtilknyttet en bruker, supportsaker, fakturaer eller noe annet som identifiserer en person? Hvis ja, gjelder GDPR, selv om AI-en er et verktøy du har kjøpt og ikke har bygget selv.

Formål og behandlingsgrunnlag, trinn for trinn

Veiledningen fra den britiske personvernmyndigheten sier at du for hver enkelt behandling i utvikling og bruk av AI bør identifisere og dokumentere formålet og et egnet behandlingsgrunnlag før du behandler noe. Den sier også at særlige kategorier av personopplysninger krever en egen betingelse. Veiledningen gjelder UK GDPR, som følger EU-reglene tett, og den er en nyttig referanse for tankegangen.

Den samme veiledningen sier at trening og bruk er ulike trinn og kan bygge på ulike behandlingsgrunnlag. Et grunnlag som fungerer for å bygge en modell, dekker ikke automatisk bruk av den på levende kundedata.

I praksis skriver du én linje per AI-bruksområde:

  1. Hva er formålet (for eksempel å oppsummere supportsaker)?
  2. Hvilke personopplysninger leser den?
  3. Hva er behandlingsgrunnlaget (avtale, berettiget interesse, samtykke, rettslig forpliktelse)?
  4. Hvem er behandlingsansvarlig, og hvem er databehandler?
  5. Hvor lagres og behandles dataene?

Hvis du vil ha en enkel gjennomgang av hvordan du velger og dokumenterer et behandlingsgrunnlag og anvender kjerneprinsippene, viser denne artikkelen om de grunnleggende personvernprinsippene i GDPR den samme tankegangen brukt på et bookingsystem, og logikken kan overføres til AI-prosjekter.

Formålsbegrensning, minimering og riktighet

Den nederlandske personvernmyndigheten oppgir formålsbegrensning, dataminimering og riktighet som sentrale GDPR-krav for AI. Hvert av dem påvirker direkte hvordan du bygger.

Den samme nederlandske veiledningen peker på artikkel 32: du trenger egnede tekniske og organisatoriske tiltak, med hensyn til den teknologiske utviklingen, behandlingens sammenheng og risikoene for enkeltpersoner.

Hva EDPB har sagt om AI-modeller

I desember 2024 ga Det europeiske personvernrådet (EDPB) ut uttalelse 28/2024 om AI-modeller. En akademisk oversikt over uttalelsen forklarer at modeller trent på personopplysninger kan beholde eller utlede informasjon om identifiserbare personer, og derfor ikke uten videre kan antas å være anonyme. Den tar også for seg hvordan berettiget interesse kan begrunnes etter at treningen er ferdig. Lærdommen for kjøpere: ikke godta «modellen er anonym» fra en leverandør uten å spørre hvordan det er vurdert.

Hvor EU AI Act kommer i tillegg til GDPR

De to lovene har ulike røtter. Ifølge en studie fra Europaparlamentet bygger AI Act på en produktsikkerhetsmodell, mens GDPR beskytter personopplysninger gjennom rettigheter og prinsipper. Den samme studien peker på at pliktene kan overlappe: en konsekvensvurdering for grunnleggende rettigheter (FRIA) og en vurdering av personvernkonsekvenser (DPIA) kan duplisere hverandre, og plikter om åpenhet og logging kan være overflødige.

Rollene er også ulike. GDPR bruker behandlingsansvarlige og databehandlere. AI Act bruker provider, importør, distributør og deployer. Et SaaS-selskap kan samtidig være provider av egne AI-funksjoner og deployer av en annens modell, og behandlingsansvarlig eller databehandler for personopplysningene som er involvert. Kartlegg hver rolle per bruksområde.

GDPR EU AI Act
Utgangspunkt Personopplysninger og folks rettigheter AI-systemet og risikonivået
Sentrale roller Behandlingsansvarlig, databehandler Tilbyder, deployer, importør, distributør
Typiske dokumenter Behandlingsprotokoll, DPIA Teknisk dokumentasjon, logger, FRIA for enkelte høyrisikobruksområder
Menneskelig involvering Rett til ikke å være gjenstand for avgjørelser som utelukkende er automatiserte og har rettsvirkning Menneskelig tilsyn for høyrisikosystemer

Enkelte nasjonale myndigheter har påpekt at et system kan oppfylle den ene loven og likevel bryte den andre, og derfor trengs en vurdering fra sak til sak. Den belgiske myndigheten legger til at AI Act bygger videre på GDPR-ansvarligheten med formell hendelsesrapportering og styring med human-in-the-loop.

NIS2 er en tredje brikke, og den handler om cybersikkerhet og risikostyring for enheter som omfattes av regelverket, ikke om AI spesifikt. Hvis selskapet ditt faller inn under virkeområdet, hører sikkerhetstiltakene du setter rundt AI-systemer hjemme i den samme risikoprosessen. Om dere omfattes, er et spørsmål for juridisk rådgiver.

Åpenhetsplikter når AI møter mennesker

Åpenhet finnes i begge lovene, og folk forveksler dem ofte.

Tidspunktet er viktig. Kommisjonens AI Act Service Desk oppgir at pliktene i artikkel 50 ble håndhevbare 2. august 2026, og at tilbydere av systemer som er brakt på markedet før denne datoen har frem til 2. desember 2026 på seg til å oppfylle visse krav til merking og gjenkjenning.

For et SaaS-selskap er de vanligste tilfellene en chatbot i produktet eller i støttewidgeten, og generert tekst eller genererte bilder som du publiserer. Merk chatboten som AI, og sjekk hvordan verktøyene dine merker generert innhold. For en grundigere gjennomgang av artikkel 4 og 50, se vår guide til EU AI Act artikkel 4 og 50 for SaaS.

Støttemedarbeider som tester en produktchatbot

DPIA, menneskelig tilsyn og automatiserte avgjørelser

Tre sikkerhetstiltak kommer opp oftest.

DPIA. Den belgiske myndigheten forklarer at en DPIA er påkrevd i visse tilfeller, blant annet ved høyrisikobehandling og bruk av ny teknologi. Den nederlandske myndigheten sier på samme måte at en slik vurdering trengs når algoritmiske systemer behandler personopplysninger og risikoen for personvernet er høy. Er du usikker, gjennomfør en. Det er billigere enn å forklare senere hvorfor du lot være.

Menneskelig tilsyn. AI Act krever menneskelig tilsyn for høyrisikosystemer gjennom utvikling, deployering og bruk, og den samme belgiske kilden sier dette sammen med kravet om FRIA.

Automatiserte avgjørelser. Etter GDPR har folk rett til ikke å være gjenstand for avgjørelser som utelukkende er basert på automatisert behandling og som har rettsvirkning for dem. Hvis en AI-agent kan avgjøre hvem som får en kontrakt, en kredittgrense eller tilgang til en tjeneste, bør du bygge et menneskelig godkjenningstrinn inn i prosessen.

En AI Act-sjekkliste for SaaS-team

Kommisjonens oversikt over AI Act sier at høyrisikosystemer må dekke risikovurdering og risikoreduksjon, datasettkvalitet, logging, teknisk dokumentasjon, informasjon til deployere, menneskelig tilsyn, robusthet, cybersikkerhet og nøyaktighet. De fleste SaaS-produkter er ikke høyrisiko, men listen er en god standard for all AI som berører folks data.

Fristene for høyrisikosystemer ligger senere enn mange tror. Ifølge FAQ-en til Service Desk må systemer på sensitive områder som arbeidsliv (vedlegg III) oppfylle kravene innen 2. desember 2027, og systemer innebygd i regulerte produkter (vedlegg I) innen 2. august 2028. Sjekk den offisielle siden for gjeldende status, siden tidslinjer kan endres.

En praktisk sjekkliste:

  1. Kartlegg all bruk av AI. Ta med verktøy som enkeltpersoner har tatt i bruk på egen hånd.
  2. Klassifiser hver enkelt bruk. Er det en chatbot, en intern assistent, en skåringsmodell eller noe som tar avgjørelser om mennesker? Spør juridisk rådgiver om noen av bruksområdene er høyrisiko.
  3. Kartlegg rollene. Tilbyder, deployer, behandlingsansvarlig, databehandler.
  4. Dokumenter formål og behandlingsgrunnlag for hvert trinn.
  5. Gjennomfør en DPIA der risikoen er høy.
  6. Sett tilganger. AI-en skal bare lese og endre det brukeren selv kunne lese og endre.
  7. Legg inn godkjenningstrinn for handlinger med reelle konsekvenser.
  8. Før logger over hva AI-en har lest, skrevet og utløst.
  9. Merk AI-interaksjoner og generert innhold.
  10. Lær opp folk. Artikkel 4 krever AI-kompetanse.
  11. Sjekk leverandørene. Hvor behandles dataene, og brukes de til å trene modellene deres?
  12. Utpek en eier. Én navngitt person bør være ansvarlig.

Vårt rammeverk for AI-styring for B2B SaaS-selskaper gjør dette om til en fungerende struktur.

Hvor AI ikke hører hjemme

God etterlevelse handler også om å bestemme hva AI ikke skal gjøre. Vi ville holdt AI unna disse områdene:

Bygg datafundamentet først

De fleste GDPR-problemer med AI starter i dataene, ikke i modellen. Hvis du ikke kan si hvor en kundes data ligger, hvilket system som er riktig og hvem som kan lese dem, kan du ikke oppfylle innsyns- eller slettekrav, og du kan ikke kontrollere hva en AI leser.

Derfor jobber vi i en fast rekkefølge:

  1. Datafundament. CRM- og økonomidataene dine blir kilden til sannhet, og systemene rundt blir avstemt til én felles versjon.
  2. AI-lag. Assistenten teamet ditt allerede bruker, kobles til disse dataene via MCP, innenfor tilgangsrettigheter.
  3. Avdelingsagenter. Spesialbygde agenter for Finance, Sales og Customer Success, slik at folk kan spørre, rapportere og slå opp på tvers av systemer, og oppdatere poster eller utløse prosesser med godkjenning der det er nødvendig og med et revisjonsspor.

Bygging, pilot og testing kjøres på selvdrevet europeisk infrastruktur i Tyskland, og GDPR, NIS2 og EU AI Act behandles som designkrav fra starten. Ingen design kan garantere etterlevelse, og den vurderingen ligger hos deg og din juridiske rådgiver. Men et system med tilgangsrettigheter, godkjenninger og logger gjør spørsmålene tilsynsmyndighetene stiller, langt enklere å besvare. Du kan se hvordan dette fungerer i praksis på siden vår om AI-agenter for Finance, Sales og Customer Success, og Admin Portal viser hvordan tilgang og godkjenninger styres på ett sted.

Vårt perspektiv

Vi ser det samme mønsteret i voksende SaaS-selskaper. Folk bruker allerede AI, i CRM, i kundestøtte og i økonomi, og ingen eier det. Ingen har bestemt hvilke data den kan lese, ingen fører oversikt over hva den har gjort, og personvernerklæringen ble skrevet før noe av dette fantes.

Vårt syn er at etterlevelse for en stor del er et driftsproblem. En personvernerklæring hindrer ikke en assistent i å lese en post den ikke burde lese. Tilgangsrettigheter, godkjenninger og logger gjør det. Derfor starter vi med datafundamentet, kobler deretter til AI-laget og bygger så avdelingsagenter, og derfor tar vi i bruk AI én prosess om gangen, med den dyreste først.

Det hjelper også å ha én person som både avgjør hvor AI lønner seg og bygger det, slik at strategien og det fungerende systemet ikke glir fra hverandre. Det er tanken bak en fraksjonell Chief AI Officer med 25 års erfaring fra å drive operasjoner. Vi designer etter GDPR, NIS2 og EU AI Act fra første dag, og du eier kildekode, dokumentasjon og infrastruktur ved overleveringen.

Vi gir ikke juridisk rådgivning, og ingenting vi bygger garanterer etterlevelse. Vi gjør systemene enklere å styre, og vi jobber sammen med din juridiske rådgiver.

Claus Nielsen

Hvor du starter

Hvis AI allerede er i bruk og ingen eier det, er første steg et ærlig bilde av hva dere har. Vår AI Readiness Assessment starter fra €4,500 og ser på dataene, prosessene og den regulatoriske eksponeringen deres, slik at dere vet hvor AI lønner seg og hvor ikke. For løpende eierskap har retaineren for fraksjonell Chief AI Officer tre nivåer: Advisor fra €3,000 per måned, Operating fra €6,500 per måned og Embedded fra €11,000 per måned.

Bygg prises enten til 30% av første års besparelse, når den er målt og bevist, eller til en fast pris avtalt før arbeidet starter. Du kan også bestille en gratis oppdagelsessamtale på 30 minutter via hovednettstedet vårt.

FAQ

Gjelder GDPR hvis vi bare bruker et AI-verktøy fra en tredjepart?

Ja, hvis personopplysninger legges inn i det. Du er vanligvis behandlingsansvarlig og leverandøren av verktøyet er databehandler, så du trenger en avtale, et formål og et behandlingsgrunnlag, og du bør vite hvor dataene behandles. Sjekk om leverandøren bruker innspillene dine til å trene modellene sine.

Erstatter EU AI Act GDPR?

Nei. De gjelder side om side. GDPR beskytter personopplysninger, mens AI Act regulerer AI-systemer etter risikonivå. Ett enkelt AI-bruksområde kan utløse plikter etter begge, og enkelte dokumenter, som konsekvensvurderinger, kan overlappe.

Trenger vi en DPIA for hvert AI-prosjekt?

Ikke nødvendigvis. En DPIA er påkrevd i noen tilfeller, blant annet ved høyrisikobehandling og ny teknologi, ifølge den belgiske myndigheten. Hvis et AI-system behandler personopplysninger på en måte som kan påvirke personer alvorlig, bør du gjennomføre en. Spør personvernombudet ditt når det er uklart.

Hva må vi fortelle brukerne om AI?

Etter GDPR skal du forklare hvilke personopplysninger du behandler og hvorfor. Etter AI Act artikkel 50, som kan håndheves fra 2 August 2026, må personer få beskjed når de samhandler direkte med et AI-system, og AI-generert innhold må merkes i maskinlesbart format. Din juridiske rådgiver kan bekrefte hvilke deler som gjelder for produktene dine.

Kan en AI-agent ta beslutninger om kunder på egenhånd?

For rutinemessige oppgaver med lav innvirkning, ja, innenfor tilgangsrettigheter og med logger. For beslutninger med rettslig eller tilsvarende betydelig virkning for en person gir GDPR folk rett til ikke å bli gjenstand for utelukkende automatiserte avgjørelser. Bygg inn menneskelig vurdering for slike.

Kilder