En medarbejder kopierer en kundekontrakt ind i ChatGPT for at få et hurtigt resumé. Praktisk og hurtigt, og på under ti sekunder ligger et dokument med navne, priser og fortrolige betingelser på en server i USA. Ingen ond hensigt, ingen alarm der går i gang. Men juridisk er der sket noget, virksomheden ikke længere har styr på: hvem ejer de data nu, hvor ligger de, og hvem kan få adgang til dem.
Den bekymring er ikke længere forbeholdt jurister og it-sikkerhedsfolk. I 2023 satte 23 procent af europæiske virksomheder datasuverænitet blandt deres tre vigtigste hensyn. I dag gør 58 procent det. Det er ikke en trend, der forsvinder igen, og det er en af de skarpeste indvendinger, danske købere har, når de overvejer at bruge AI i noget, der rører ved rigtige kundedata.
Problemet er ikke AI - det er, hvor dine data ender
At bruge en stor sprogmodel er ikke i sig selv et problem. Problemet opstår, når indholdet, du sender, indeholder persondata, forretningshemmeligheder eller kontrakter, og modtageren er en amerikansk udbyder. Her spiller CLOUD Act ind: amerikanske myndigheder kan under visse betingelser kræve adgang til data, som amerikanske selskaber råder over, uanset om serverne fysisk står i Frankfurt, Dublin eller Virginia. Det er ikke et spørgsmål om, hvorvidt udbyderen er sikker eller seriøs. Det handler om, hvilken lovgivning udbyderen er underlagt.
Det praktiske eksempel er nemt at genkende. En dansk virksomhed vælger en amerikansk AI-tjeneste, fordi den er hurtig at komme i gang med. Serverne ligger måske endda i et europæisk datacenter, og alt ser fint ud på overfladen. Men fordi moderselskabet er amerikansk, kan data i princippet blive udleveret til amerikanske myndigheder uden om dansk og europæisk ret. Det er ikke paranoia, men den juridiske virkelighed, som en databehandleraftale ikke kan skrive sig ud af.
Samtidig er rammerne skærpet på europæisk side. EU AI Act er trådt i kraft og stiller krav til, hvordan AI må bruges, og Datatilsynet fører aktivt tilsyn med danske virksomheders brug af AI og persondata. Det betyder ikke, at AI er forbudt. Det betyder, at man skal kunne redegøre for, hvad man sender hvorhen, og hvorfor.
Den gode nyhed er, at du har flere valgmuligheder end "brug ChatGPT" eller "drop AI". Der findes en realistisk trappe af løsninger, hvor hvert trin flytter dine data længere væk fra fremmed jurisdiktion.
Tre trin fra mest til mindst dataeksponering
1. Dataminimering - send kun det nødvendige
Det billigste og mest oversete trin kræver hverken ny software eller ny leverandør. Det handler om at sende mindre. Skal modellen omskrive en tekst, har den sjældent brug for kundens fulde navn, CPR-nummer eller sagsnummer. Fjern eller anonymiser det følsomme, før det forlader huset, og send kun det, opgaven reelt kræver. For en overraskende stor del af de opgaver, virksomheder bruger AI til, er persondata slet ikke nødvendige. De er kommet med, fordi ingen har tænkt over at fjerne dem.
Dataminimering er også kernen i GDPR's princip om at behandle så få data som muligt. Gør du det godt, kan du i mange tilfælde bruge selv en amerikansk model uden at komme i nærheden af persondata.
2. En europæisk model som Mistral
Når opgaven kræver mere kontekst, end du kan nå at pille det følsomme ud af, giver det mening at flytte selve modellen til Europa. Mistral er en fransk udbyder, hvis data behandles i EU, og som ikke er underlagt CLOUD Act. Du får en moderne sprogmodel på niveau med de store amerikanske, men inden for europæisk jurisdiktion og med en databehandleraftale, der er skrevet til GDPR fra bunden.
I praksis er det her det nemmeste, seriøse skridt væk fra USA. Det kræver ingen egen hardware og ingen drift, for du skifter reelt bare, hvilken sky dine kald går til. For de fleste mellemstore virksomheder rammer en europæisk cloud-model den rigtige balance mellem sikkerhed, kvalitet og pris.
3. En selvhostet open source-model
For det mest følsomme - patientdata, avancerede forretningshemmeligheder, data der aldrig må forlade huset - findes det sidste trin: en open source-model, du hoster selv. Moderne open weight-modeller udgives under licenser som Apache 2.0 og kan køre på din egen server eller i dit eget datacenter. Data forlader aldrig din infrastruktur, og der er ingen tredjepart at have en aftale med, fordi der ikke er nogen tredjepart.
Det trin er ikke gratis. Det kræver hardware med tilstrækkelig GPU-kapacitet, og det kræver drift: opdateringer, overvågning og vedligehold. Til gengæld har du fuld kontrol, og for organisationer med reelt følsomme data er det ofte den eneste model, der overhovedet kan forsvares. Pointen er ikke, at alle skal hoste selv. Det er, at muligheden findes, når data kræver det.
Det GDPR-praktiske, uden at jeg spiller advokat
Jeg er udvikler, ikke advokat, og det følgende er ikke juridisk rådgivning. Men der er nogle håndtag, som stort set altid er relevante, uanset hvilket trin du lander på:
Databehandleraftale (DPA): Bruger du en ekstern udbyder, skal der være en aftale, der beskriver, hvordan dine data må behandles. Europæiske udbydere gør det her nemmere end amerikanske.
DPIA ved risikofyldt brug: Behandler du følsomme persondata i stor skala, kan en konsekvensanalyse være påkrævet, før du går i luften.
Logning: Du bør kunne dokumentere, hvad der er sendt hvorhen. Uden log kan du ikke svare på et tilsyn eller en indsigtsanmodning.
Sletning: Data skal kunne slettes igen, og du skal vide, om udbyderen gemmer dine input til træning eller ej.
Datatilsynet har udgivet vejledning om brug af AI og persondata, og den er værd at læse, før man går i gang. Det handler ikke om at blive skræmt fra at bruge AI, men om at kunne dokumentere sine valg, hvis nogen spørger. Og det er markant nemmere at dokumentere, når data i forvejen er holdt inden for EU.
Derfor betyder det noget, at løsningen er din egen kode
Her kommer den tekniske pointe, der binder det hele sammen. Når AI'en er bygget ind i din egen kode i stedet for at være en færdig SaaS-tjeneste, kan du vælge model efter, hvor følsomme data er i den enkelte opgave. Det harmløse - produktbeskrivelser, offentligt materiale, generel tekstbehandling - kan køre på Claude eller GPT, hvor de ofte er både billigst og bedst. Det følsomme kan samtidig dirigeres til Mistral eller en selvhostet model, uden at brugeren mærker forskel.
Et eksempel: en supportfunktion, der både skal formulere generelle svar og håndtere sager med personoplysninger. De generelle svar kan trygt gå til en amerikansk model, mens sagerne med persondata dirigeres til Mistral eller en selvhostet model. Samme løsning, to datastrømme, styret af hvor følsomt det enkelte input er.
Den valgfrihed forsvinder i et lukket abonnement. Køber du en samlet AI-platform, arver du leverandørens valg af model og datastrøm, og typisk er svaret ét amerikansk API for det hele. Bygger du løsningen selv, bliver modelvalget en indstilling, du styrer per opgave, ikke en beslutning, der er truffet for dig. Det er præcis den fleksibilitet, jeg bygger ind i en AI-integration: følsomme data på europæisk eller selvhostet infrastruktur, harmløse opgaver på det, der giver mest for pengene.
Match modellen til dine data
Og lad mig være ærlig, for det modsatte budskab er lige så vigtigt: for helt harmløse opgaver er en amerikansk model helt fin, og ofte den bedste. Der er ingen grund til at hoste sin egen server for at få omskrevet en produkttekst uden en eneste personoplysning i. At behandle alt, som om det var strengt fortroligt, er dyrt og unødvendigt.
Det egentlige greb er ikke at vælge én model og bruge den til alt. Det er at holde op med at tænke på AI som ét sted, dine data ender, og begynde at matche modellen til, hvor følsomme data reelt er. Harmløst kan roligt gå til USA. Fortroligt bliver i EU. Det mest følsomme bliver hjemme. Når det valg er indbygget fra starten, holder du op med at vælge mellem at bruge AI og at overholde GDPR, og får begge dele.
