Hvor ligger dine AI data, EU cloud og kontrol

Hvor havner dine AI prompts, og hvem kan se dem

Det er et helt naturligt spørgsmål at stille. Du åbner ChatGPT, skriver en besked med kundedata, en kontrakt eller et internt notat, og trykker enter. Men hvad sker der præcist bagefter?

Svaret er mere nuanceret end de fleste forventer. Det handler ikke kun om, om data er krypteret undervejs. Det handler om, hvad der sker i den anden ende. Hvem logger hvad, hvem har adgang til dine inputs, og om der er en linje fra din prompt til en model der forbedrer sig på baggrund af netop den tekst.

AI datasikkerhed er ikke et teknisk nichespørgsmål længere. Det er et ledelsesansvar. Og jo hurtigere danske virksomheder forstår præcis hvad der sker med data, jo hurtigere kan de bruge kunstig intelligens med ro i maven og reel kontrol.

For at forstå det fulde billede er vi nødt til at starte med de tre datatyper, der er i spil, hver gang du bruger en AI-tjeneste.

Prompt, vedhæftning og log, tre forskellige datatyper

Når du bruger en AI-tjeneste, sender du reelt tre slags data af sted, og de behandles ikke nødvendigvis ens.

• Prompten er selve teksten du skriver. Det kan være et spørgsmål, en instruktion eller en samtale. Prompten sendes til modellen og processeres i realtid på udbyderens servere.
• Vedhæftningen er dokumenter, billeder eller filer du uploader. De uploades til udbyderens infrastruktur og kan behandles, gemmes midlertidigt eller analyseres af modellen. Her er det ekstra vigtigt at kende retningslinjerne for opbevaring.
• Loggen er samtalehistorikken, dine tidligere inputs og outputs, metadata om hvornår du brugte tjenesten og fra hvilken IP-adresse. Logs bruges til fejlfinding, sikkerhed og i nogle tilfælde til at forbedre tjenesten.

De tre typer har meget forskellig risikovurdering. En prompt med generisk spørgsmål er ikke det samme som en vedhæftning med lønoplysninger. Og en log der gemmes i 90 dage er ikke det samme som en log der slettes efter sessionen.

Det du skal gøre som virksomhed er at kende forskellen og have en politik for, hvilken type data der må sendes til hvilke AI-tjenester. Det vender vi tilbage til.

Træner modellen på dine data, det korte svar

Dette er det spørgsmål alle stiller. Og svaret er: det afhænger fuldstændig af, hvilken tjeneste du bruger, og hvilken plan du er på.

OpenAI og Microsoft træner som udgangspunkt ikke på data fra virksomhedsplaner som ChatGPT Team, Enterprise eller Azure OpenAI. Det er specifikt fravalgt. Men gratis versioner og forbruger-accounts kan have andre vilkår, hvor data kan bruges til modeltræning.

Det betyder at din kollega, der bruger gratis ChatGPT med sin private Gmail-konto til at skrive tilbud for virksomheden, potentielt sender virksomhedsdata ind i en pulje, der bruges til at træne næste version af modellen.

Det er ikke en skræmmekampagne. Det er en reel forskel i kontraktvilkår, som mange ikke kender til. Og det er præcis den slags detaljer, der afgør om din brug af AI er sikker eller ej.

Tjek altid databehandlingsvilkårene for den specifikke plan og tjeneste du bruger. Ikke marketingsiden. Selve aftalen.

EU cloud og data i Danmark, hvad betyder det reelt

EU cloud og data residency er begreber, der fylder mere og mere i konferencelokaler og indkøbsmøder. Og det er med god grund. GDPR stiller krav til, hvor persondata opbevares og behandles. Men der er en vigtig forskel på, at data fysisk befinder sig i EU, og at din virksomhed har reel kontrol over dem.

Mange cloud-tjenester reklamerer med EU-hosting. Og det er rigtigt, at serverne står i Frankfurt, Dublin eller Amsterdam. Men det er ikke hele historien. For adgang til dataene kan stadig ske fra den amerikanske modervirksomhed, fra supportteams i Asien, eller via underleverandører med servere uden for EU. Og det er præcis det, der gør EU cloud til et mere komplekst begreb end mange tror.

Data hosting i EU er et godt udgangspunkt. Men det er ikke en garanti for kontrol. Det er et startpunkt for de rigtige spørgsmål.

Danske virksomheder der bruger kunstig intelligens i produktion, hvad enten det er til kundesupport, dokumentanalyse eller intern videndeling, skal forholde sig til, hvem der reelt kan tilgå dataene. Ikke bare hvem der juridisk må. Men hvem der teknisk set kan.

Data i EU, men adgang kan ske fra andre lande

Det her er en af de vigtigste pointer i hele datasikkerhedsdebatten om kunstig intelligens. Og den bliver sjældent forklaret ordentligt.

Selvom en server fysisk står i EU, kan en cloud-leverandørs ingeniørteam fra USA logge ind og tilgå dine data via support, fejlsøgning eller administration. Det er teknisk muligt og sker i praksis. GDPR regulerer overførsler af persondata til tredjelande, og dette kan udgøre en sådan overførsel, selvom serveren er europæisk.

For AI-tjenester betyder det, at du skal stille spørgsmålet: hvem har adgang til mine prompts og mine logs, og fra hvilke lande kan de tilgå dem?

Det er ikke paranoidt. Det er det spørgsmål din databeskyttelsesrådgiver (DPO) bør stille til enhver AI-leverandør. Og det er det spørgsmål, du bør kræve et skriftligt svar på.

Databehandleraftale og underleverandører, det du skal se

Når du bruger en AI-tjeneste til at behandle persondata, er udbyderen din databehandler. Det kræver en databehandleraftale, en DPA, som den hedder på engelsk. De fleste store udbydere har standardaftaler klar til underskrift.

Men det er ikke nok at underskrive. Du skal også se på underleverandørerne.

En AI-tjeneste bruger sjældent kun egne servere. De bygger ovenpå AWS, Google Cloud eller Azure. De bruger tredjeparts logværktøjer, sikkerhedsmonitoreringssystemer og måske endda andre AI-modeller til interne formål. Alle disse er teknisk set underleverandører, og de kan alle potentielt behandle dine data.

En god databehandleraftale lister underleverandørerne eksplicit og kræver notifikation, hvis de skiftes ud. Tjek om din AI-udbyder gør det. Og tjek om du som minimum ved, hvem der er i kæden.

Hvad du skal tjekke	Hvad du leder efter
Databehandleraftale	Eksisterer den? Er den underskrevet? Dækker den AI-tjenesten specifikt?
Underleverandørliste	Hvem er i kæden? Hvilke lande? Notifikation ved ændringer?
Data residency	Hvilken region gemmes data? Er det EU? Kan det låses til en region?
Adgangskontrol	Hvem hos leverandøren kan se dine data? Under hvilke omstændigheder?
Træningstilvalg	Bruges dine data til modeltræning? Kan det frameldes?

Praktisk datasikkerhed for kunstig intelligens

Teori er fint. Men i hverdagen er det de konkrete rutiner, der afgør om din virksomheds brug af AI er sikker. Og her er der god nyhed: du behøver ikke en stor compliance-afdeling eller et dyrt konsulentfirma for at komme godt i gang.

Det handler om tre ting: at vide hvad du har af data, at beskytte det der ikke behøver at være synligt, og at styre hvem der har adgang til hvad. Det er de samme principper som al anden datasikkerhed, bare tilpasset AI-konteksten.

Kunnstig intelligens er ikke magisk i den forstand, at den har brug for alt for at fungere. Langt de fleste opgaver kan løses med begrænset, anonymiseret eller klassificeret data. Og det er netop der, de praktiske løsninger begynder.

Lad os tage de tre discipliner én ad gangen.

Klassificer data, offentlig, intern og fortrolig

Det første og mest effektive skridt er at indføre en simpel dataklassificering i din virksomhed. Tre niveauer er nok til at starte med:

• Offentlig data: Information der allerede er tilgængelig for alle. Pressemateriale, produktbeskrivelser, generelle FAQ-svar. Denne data kan sendes frit til alle AI-tjenester.
• Intern data: Information der er til intern brug, men ikke særligt følsom. Mødenotater, procesbeskrivelser, interne rapporter uden persondata. Her bør du bruge erhvervsplaner med databehandleraftale.
• Fortrolig data: Personoplysninger, kontrakter, løndata, kundeoplysninger, forretningshemmeligheder. Denne data bør aldrig sendes til en AI-tjeneste uden maskering eller pseudonymisering, og kun via godkendte og sikrede systemer.

Klassificeringen behøver ikke stå i et komplekst dokument. Den kan starte som en enkel aftale i teamet. Og den giver alle et fælles sprog for, hvad der er okay at gøre med hvilken type information.

Maskering og pseudonymisering, når AI ikke behøver alt

En af de mest praktiske teknikker inden for AI datasikkerhed er maskering og pseudonymisering. Og det er enklere end det lyder.

Maskering betyder, at du fjerner eller erstatter følsomme oplysninger, inden du sender data til en AI. I stedet for at skrive "kunden hedder Lars Nielsen og bor i Odense og skylder os 42.000 kr.", skriver du "kunden hedder [NAVN] og bor i [BY] og skylder os [BELØB]". AI-modellen kan stadig løse opgaven, hvad enten det er at opsummere, omformulere eller analysere, uden at have adgang til de faktiske personoplysninger.

Pseudonymisering er et skridt videre, hvor du erstatter identifikatorer med koder, som kun din virksomhed kan oversætte. Og det er en anerkendt metode under GDPR til at reducere risikoen ved databehandling.

Du kan gøre dette manuelt som en rutine i teamet, eller du kan bygge et workflow der automatisk anonymiserer data, inden det sendes til AI-modellen. Det er præcis den slags løsninger jeg bygger til virksomheder, der vil bruge AI effektivt og sikkert på samme tid.

Adgangsstyring, hvem må spørge AI om hvad

Adgangsstyring til AI-tjenester er et overset område. De fleste virksomheder har styr på, hvem der må tilgå regnskabssystemet eller CRM-systemet. Men hvem der må bruge hvilken AI-tjeneste til hvad? Der er det sjældnere, der er en klar politik.

Og det er et problem. For en medarbejder med adgang til en AI-tjeneste, der kan uploade dokumenter, har potentielt adgang til at sende hvilken som helst intern fil af sted. Ubevidst. Og med gode intentioner.

Adgangsstyring på AI-området handler om: hvem må bruge hvilke tjenester, hvilke datatyper må de bruge, og er der centrale konti med klare vilkår eller bruger alle deres egne private accounts?

Løsningen er ikke at forbyde alt. Det er at etablere godkendte tjenester, centrale virksomhedsaccounts med de rette aftaler, og klare retningslinjer for hvad der må sendes hvortil. Det er ikke kompliceret. Det kræver bare at nogen tager beslutningen.

Alternativ hvis din cloud leverandør bliver et problem

Det er et scenarie de færreste tænker over, når de vælger en AI-tjeneste. Hvad sker der, hvis leverandøren skifter vilkår, hæver priserne markant, lukker en funktion du er afhængig af, eller simpelthen holder op med at eksistere?

Det er ikke langsøgt. Det sker i tech-branchen hele tiden. Og jo mere din virksomhed er bygget op om en enkelt AI-leverandørs infrastruktur, jo større er risikoen for at blive sat i en umulig situation.

Cloud exit, altså evnen til at flytte sig fra en leverandør til en anden, er en del af en moden AI-strategi. Og det starter med at sikre, at du aldrig er fanget. Du skal eje dine data, din dokumentation og dine workflows. Ikke leverandøren.

Dette er også relevant i en NIS2 og AI-kontekst. NIS2-direktivet, der nu er i kraft i Danmark, stiller krav til it-sikkerhed og leverandørrisikostyring hos virksomheder inden for kritiske sektorer. At have en cloud exit-plan er et konkret skridt i den retning.

Backup, eksport og dokumentation, så du ikke sidder fast

Den praktiske sikring mod leverandørlåsning starter med tre ting: backup, eksport og dokumentation.

Backup betyder, at du aldrig kun har data et sted. Hvis du bruger en AI-tjeneste til at gemme samtalehistorik, vidensbase eller procesdata, bør du have en kopi i et system du selv kontrollerer. Det kan være et simpelt databasesystem som Supabase eller PostgreSQL, som du selv hoster.

Eksport handler om at sikre, at du kan trække dine data ud i et standardformat til enhver tid. Ikke alle leverandører gør det nemt. Tjek om din AI-tjeneste understøtter eksport af historik, konfigurationer og trænede tilpasninger, inden du bygger noget oven på dem.

Dokumentation er den del de fleste glemmer. Skriv ned, hvad du bruger, til hvad. Hvilke prompts er centrale? Hvilke workflows er forretningskritiske? Dokumentation er det, der gør det muligt at genopbygge hurtigt, hvis du skal skifte.

Skift af model eller hosting, hvad koster det i drift

Et af de store spørgsmål i enterprise-AI-diskussionen er: hvad koster det at skifte?

Hvis du har bygget din AI-løsning direkte oven på én leverandørs API, er svaret: det kan godt koste en del. Ikke kun i kroner, men i tid og omstilling.

Den mest fremtidssikrede tilgang er at bygge med modelveksling i tankerne fra starten. Det betyder at designe dine systemer, så du relativt nemt kan skifte den underliggende sprogmodel ud, hvad enten det er fra GPT-4 til Claude, fra Claude til Gemini, eller fra en cloudbaseret model til en lokal LLM.

Self hosted AI og lokal LLM er begreber der vinder mere og mere indpas, netop fordi de giver fuld kontrol. En model der kører på din egen server, med dine egne data, uden ekstern adgang, er i sagens natur den mest sikre løsning fra et datasikkerhedsperspektiv. Det kræver mere opsætning, men for virksomheder med høje krav til compliance AI og NIS2 kan det være det rigtige valg.

Jeg arbejder med begge tilgange: cloudbaserede AI-løsninger med ordentlige aftaler og kontroller, og self hosted alternativer via Docker og Hetzner VPS, til virksomheder der vil have al data på egne servere. Begge kan fungere. Det handler om kravene.

Gennemsigtighed der skaber tillid i teamet

AI datasikkerhed handler ikke kun om teknik og aftaler. Det handler også om mennesker. Og her er dansk arbejdskultur faktisk et aktiv, fordi vi er vant til at snakke åbent om beslutninger og at inddrage medarbejdere i forandringer.

Problemet opstår, når AI implementeres ovenfra uden forklaring. Når medarbejderne ikke ved, hvad der logges, hvem der kan se hvad, eller om AI bruges til at overvåge dem. Så opstår der mistillid. Og mistillid er en af de største barrierer for succesfuld AI-implementering i danske virksomheder.

Gennemsigtighed er ikke bare et nice-to-have. Det er en forudsætning for at AI faktisk virker i praksis. Medarbejdere der forstår og stoler på de systemer de bruger, bruger dem bedre. Og de bidrager til at identifcere problemer, inden de bliver store.

Det starter med klare, skriftlige rammer. Ikke lange juridiske dokumenter. Enkle, menneskelige regler der forklarer, hvad AI bruges til i virksomheden, hvad der registreres, og hvad det bruges til.

Skriv reglerne ned, så alle bruger AI ens

En AI-politik behøver ikke være et 40-siders dokument. Den kan starte som en enkelt side med svar på de vigtigste spørgsmål:

Hvilke AI-tjenester er godkendte til brug i virksomheden? Hvad må sendes til dem, og hvad må ikke? Hvem ejer adgangen, og hvem kontakter man ved tvivl?

Når alle bruger de samme tjenester med de samme retningslinjer, reducerer du ikke bare risikoen. Du skaber også ensartethed i outputs og lettere mulighed for at forbedre processerne over tid.

En AI-politik er også et signal til medarbejderne om, at ledelsen har tænkt det igennem. At det ikke bare er "brug det bare og se hvad der sker". Det er den slags konkret forberedelse, der adskiller virksomheder der får noget ud af kunstig intelligens, fra dem der kæmper med det i årevis.

Når medarbejdere føler sig overvåget, sker det her

Dette er den del, som mange ledere overser, når de implementerer AI og logning i virksomheden.

Hvis medarbejderne oplever, at AI-systemet primært er der for at registrere hvad de laver, hvornår de er aktive, og hvor lang tid de bruger på opgaver, så sker der to ting. De begynder at arbejde uden om systemet. Og de holder op med at dele ideer og eksperimentere.

Begge dele er ødelæggende for den forretningsmæssige værdiskabelse, som AI ellers kan bidrage med.

Logning og audit trail er legitime og vigtige sikkerhedsværktøjer. De dokumenterer, hvad der er sket, og giver mulighed for at efterforske og reagere ved sikkerhedshændelser. Men de bør altid implementeres med en klar kommunikation om, hvad der logges, og hvem der har adgang til logsene.

Formålet med logning er sikkerhed og dokumentation. Ikke præstationsmåling. Og den forskel er vigtig at kommunikere klart og ærligt til medarbejderne. Gør du det, undgår du den utilsigtede bivirkning, der kan forvandle et stærkt AI-initiatv til et tillidsknusende kontrolsystem.

Opsummering: kontrol over AI data er din virksomheds valg

Den vigtigste pointe fra denne artikel er egentlig meget enkel: usikkerhed om AI data er ikke et teknisk problem. Det er et informationsproblem. Og det kan løses med de rette spørgsmål, de rette aftaler og de rette rutiner.

Vi har gennemgået, hvad der faktisk sker med dine prompts, vedhæftninger og logs. Vi har set på, hvad EU cloud og data i Danmark reelt betyder, og at servernes geografiske placering ikke alene er nok. Vi har set på de praktiske redskaber: dataklassificering, maskering, pseudonymisering og adgangsstyring.

Vi har talt om cloud exit og hvorfor du aldrig bør bygge noget, du ikke selv kan tage med, hvis du skifter leverandør. Og vi har talt om, at gennemsigtighed internt ikke bare er pænt, det er en forudsætning for at AI fungerer i en dansk virksomhedskultur.

AI datasikkerhed, compliance AI og sikker brug af kunstig intelligens i virksomheder handler i bund og grund om kontrol. Ikke om at begrænse brugen af teknologi, men om at bruge den bevidst. Med øjnene åbne. Og med klare regler alle forstår.

Det er den tilgang, jeg arbejder ud fra, når jeg hjælper danske virksomheder med at implementere AI på en måde, der rent faktisk giver mening. Ikke fordi det er et salgsargument, men fordi det er den eneste fremgangsmåde, der holder på den lange bane.