Ja, det kan de, hvis adgangen er bygget forkert. Den største risiko i en AI-funktion ligger sjældent i selve modellen. Den ligger i det lag, der henter data frem og lægger dem ved spørgsmålet, for hvis det lag ikke kender brugerens rettigheder, kan én kundes oplysninger dukke op i et svar til en anden. Beskyttelsen består af fire ting: et overblik over datastrømmene, adskillelse af kunderne, styr på logning og en afklaring af, hvad udbyderen gør med data.
Artiklen er til ledelsen i en SaaS-virksomhed, hvor flere kunder deler samme installation. Den tekniske baggrund er forklaret i artiklen om delte og separate installationer.
Tegn datastrømmen
Bed udviklerne tegne, hvor data bevæger sig, når en bruger stiller et spørgsmål. Tegningen behøver ikke være pæn. Den skal svare på:
- Hvad brugeren skriver, og hvor det sendes hen.
- Hvilke data funktionen henter fra jeres systemer.
- Hvad der sendes til modellen, og hvor modellen kører.
- Hvad der gemmes undervejs, hvor og hvor længe.
- Hvem der kan læse det bagefter, hos jer og hos udbyderen.
Mange virksomheder opdager her en kopi, de ikke havde tænkt over. Kundernes dokumenter er ofte blevet omdannet til såkaldte embeddings, en talform der gør det muligt at søge på betydning, og de ligger i en særskilt database. Selv om det ligner tal, er det stadig kundens indhold. Det skal have samme beskyttelse, slettes samme dag som originalen og med i oversigten.
Hvor det går galt
Fire fejl går igen.
- Søgning uden kundefilter. Funktionen søger i alle dokumenter og filtrerer bagefter, eller slet ikke. Et spørgsmål fra kunde A kan så finde et dokument fra kunde B.
- Modellen får lov at bestemme adgangen. Instruktionen siger “vis kun data for denne kunde”. Det er en venlig opfordring, ingen kontrol. En sprogmodel kan narres, se prompt injection.
- Mellemlagring på tværs. Et svar gemmes for at spare tid og genbruges til en anden bruger, der stiller et lignende spørgsmål.
- Rettigheder inden for kunden. Adskillelsen mellem kunderne holder, men en medarbejder kan nu spørge sig frem til lønsedler eller HR-sager, som produktet ellers skjuler for vedkommende.
Det sidste overses ofte. Funktionen skal have præcis de samme rettigheder som den bruger, der spørger, og aldrig bredere.
Adskillelse skal ligge uden for modellen
Princippet er enkelt: adgang afgøres af almindelig kode, før data når modellen. Det, modellen aldrig får at se, kan den ikke røbe. I praksis betyder det:
- Hvert kald til søgningen bærer kundens og brugerens identitet fra login, og den kommer aldrig fra teksten.
- Filteret ligger i databasen eller i et fast lag, så en udvikler ikke kan glemme det i en ny funktion.
- Store kunder eller følsomme data kan få hver sin søgedatabase.
- Mellemlagring holdes adskilt pr. kunde eller slås fra.
- Der er en automatisk test, hvor en bruger hos kunde A forsøger at få data fra kunde B frem. Den kører ved hver udgivelse.
Den test bør også ligge i testsamlingen. Spørg udviklerne, hvornår den sidst kørte, og hvad den viste.
Logning af samtaler
Logning er nødvendig for at rette fejl og forbedre funktionen, men samtalerne kan rumme alt, hvad brugerne skriver, også personoplysninger og forretningshemmeligheder. Beslut derfor:
- Hvad der gemmes, og i hvilken form.
- Hvor længe det gemmes, og hvordan det slettes, også når en kunde stopper.
- Hvem der må læse med, og om det bliver registreret.
- Hvad kunderne er blevet fortalt, og hvad de kan vælge fra.
Log til fejlsøgning havner let i generelle logværktøjer, hvor mange har adgang. Tjek det særskilt. Sletning og testdata er uddybet i persondata i produktet.
Træning hos udbyderen
Det første, kunderne spørger om, er, om deres data bruges til at træne modellen. Svaret afhænger af, hvilket produkt og hvilke vilkår I har hos udbyderen, og vilkårene kan ændre sig. Læs dem, og få svar på:
- Bruges data til træning, og er det slået fra som standard eller noget, I selv skal fravælge?
- Gemmes spørgsmål og svar hos udbyderen, hvor længe og til hvilket formål?
- Hvor behandles data, og af hvilke underleverandører?
- Hvad sker der med dem, når aftalen ophører?
- Hvordan får I besked om ændringer?
Brug jeres egne kundedata til at forbedre modeller eller funktioner, så skal det også være aftalt. Hvad kunden har sagt ja til i jeres vilkår, er ofte smallere, end udviklerne antager.
Er der personoplysninger i spil, hører vurderingen hjemme hos den, der har ansvaret for databeskyttelse. Rollen er forklaret under DPO, og konkrete spørgsmål er noget for en advokat eller databeskyttelsesrådgiver. Medarbejdernes egen brug af AI-værktøjer er et andet emne, som hører under sikkerhedsregler for generativ AI.
Svaret til kunden
Skriv en kort side, salg kan sende, når kunderne spørger: hvad funktionen bruger, hvor data ligger, hvad der gemmes, at data ikke deles mellem kunder, og hvordan det er testet. Den hører til besvarelsen af kundens spørgeskema. Giv kunderne mulighed for at slå funktionen fra. Nogle store kunder vil kræve det, og det koster lidt, når det er bygget med fra begyndelsen.
Det skal I lade være med
- At overlade adgangskontrol til instruktioner til modellen · adgang skal afgøres i kode.
- At glemme kopierne · søgedatabaser, logfiler og mellemlagre er også kundedata.
- At svare kunderne ud fra hukommelsen · gå til de aktuelle vilkår hos udbyderen.
- At lægge rigtige kundedata i prøver og demoer · de har en tendens til at blive liggende.
Det skal I kræve af den eksterne
- ☐ En tegning af datastrømmen, som ledelsen kan forstå.
- ☐ Krav om, at adskillelsen af kunder sker uden for modellen, og at den testes automatisk.
- ☐ En oversigt over, hvad der gemmes, hvor længe og af hvem.
- ☐ Spørgsmål til udbyderen om træning, opbevaring og ændringer, med svarene skrevet ned.
- ☐ En side til salg, der svarer ærligt på kundens spørgsmål.
Senest gennemgået: november 2026.
Næste skridt
Læs også: AI-agenter i produktet · Demoen virker
→ Kontakt · Tlf. 70 13 63 23 · Ekstern CTO hos Nielco IT
