Sikkerhedsaspekter ved AI i kundeservice handler om at beskytte kundedata, styre automatiske svar og afgrænse, hvad en chatbot eller agent må gøre. Den sikre løsning kombinerer dataminimering, adgangskontrol, test, tydelig information til kunden og menneskelig overtagelse, når sagen kræver vurdering.
Sikker AI i kundeservice kræver klare grænser for data, adgang og automatiske handlinger. Den centrale pointe er at kombinere dataminimering, instruktionssikring, hallucinationskontrol, menneskelig overtagelse, leverandørstyring og relevante EU-krav, så automatisering ikke gør kundedialogen mindre sikker.
Hvad dækker sikkerhedsaspekter ved AI i kundeservice?
AI i kundeservice kan svare på spørgsmål, foreslå svar til medarbejdere, sortere henvendelser, oversætte beskeder, finde relevante vidensbaseartikler og udføre afgrænsede handlinger i et kundesystem. Sikkerhedsarbejdet handler derfor ikke kun om selve sprogmodellen. Det handler om hele kæden fra kundens besked til dataopslag, svar, logning og eventuelle handlinger i bagvedliggende systemer.
En enkel chatbot til kundeservice har typisk lavere risiko, hvis den kun svarer ud fra offentlige hjælpetekster. Risikoen stiger, når løsningen får adgang til ordredata, kontooplysninger, klagehistorik, interne noter eller mulighed for at ændre en sag. Jo mere systemet kan se og gøre, desto tydeligere skal grænserne være.
Den praktiske sikkerhedsopgave er at beslutte, hvilke data AI må bruge, hvilke handlinger der kræver menneskelig godkendelse, hvordan svar kontrolleres, og hvordan fejl opdages. En god løsning er ofte mindre autonom end teknologien tillader, fordi kundeservice kræver både korrekt information, fortrolighed og situationsfornemmelse.
Hvilke data er mest udsatte i en kundedialog?
Kundedialoger kan indeholde navne, adresser, telefonnumre, mailadresser, kundenumre, ordrenumre, betalingsoplysninger, reklamationer, helbredsoplysninger, ansættelsesforhold, adgangsproblemer og personlige forklaringer. Mange af disse oplysninger virker rutinemæssige i en supportsag, men de kan blive følsomme, hvis de kombineres eller sendes videre til en ekstern AI-tjeneste uden klare rammer.
Dataminimering er en central kontrol. AI-systemet bør kun modtage de oplysninger, der er nødvendige for den konkrete opgave. Hvis en kunde spørger om leveringstid, behøver modellen typisk ikke hele kundens sagshistorik. Hvis en medarbejder bruger AI til at formulere et svar, bør interne noter, adgangskoder og unødvendige identifikatorer fjernes eller maskeres.
Der er også risiko for, at et svar kommer til at afsløre oplysninger fra en anden sag, fra interne instruktioner eller fra fejlagtigt hentet kontekst. Arbejdet med forebyggelse af datalækager i AI-applikationer bør derfor dække både input, opslag, modeloutput, logfiler og medarbejdernes brug af værktøjet.
Hvordan opstår instruktionsangreb mod kundeservice-AI?
Et instruktionsangreb opstår, når en bruger forsøger at få AI-systemet til at tilsidesætte sine regler. I kundeservice kan det være en kunde, der skriver, at systemet skal ignorere interne retningslinjer, afsløre skjulte instruktioner, give rabat uden grundlag eller hente oplysninger, kunden ikke har ret til. Angrebet kan også ligge indirekte i en vedhæftet fil, en mailtråd eller en tekst, som systemet bliver bedt om at opsummere.
Risikoen bliver større, når AI-løsningen er forbundet med værktøjer. Hvis modellen kan slå kunder op, sende mails, ændre ordrer eller oprette refusioner, kan en manipuleret besked forsøge at få systemet til at bruge disse funktioner forkert. Derfor bør eksternt indhold behandles som upålideligt, også når det ser almindeligt ud.
Tekniske filtre kan reducere risikoen, men de bør ikke stå alene. Sikker arkitektur bruger flere lag: faste tilladelser i kode, skarpe rettigheder til datakilder, kontrol af outputformat, begrænsning af værktøjsadgang og menneskelig godkendelse for handlinger med økonomisk, juridisk eller privatlivsmæssig betydning.
Hvordan bør adgang til systemer og handlinger afgrænses?
AI i kundeservice bør følge princippet om mindst mulig adgang. Modellen skal ikke have bredere systemrettigheder end den opgave, den udfører. En løsning, der besvarer spørgsmål om returpolitik, behøver ikke adgang til at ændre kundens adresse. En løsning, der foreslår svar til en medarbejder, behøver ofte slet ikke at kunne udføre handlinger direkte.
Adgangskontrol bør ligge uden for modellen. Det betyder, at applikationen kontrollerer, om en bestemt handling er tilladt, før den udføres. Modellen kan foreslå, at en ordre skal annulleres, men et almindeligt programflow bør kontrollere brugerrolle, kundens identitet, sagstype, beløbsgrænse og krav om godkendelse.
| Funktion | Mulig risiko | Relevant kontrol |
|---|---|---|
| Svarforslag | Forkert eller for vidtgående svar sendes til kunden | Medarbejder godkender svaret før afsendelse |
| Dataopslag | AI henter flere personoplysninger end nødvendigt | Datakilder begrænses efter sagstype og rolle |
| Refusion | Uautoriseret økonomisk handling | Beløbsgrænse, identitetskontrol og manuel godkendelse |
Hvorfor er menneskelig overtagelse en sikkerhedskontrol?
Menneskelig overtagelse er ikke kun en servicefunktion. Det er en sikkerhedskontrol, fordi nogle sager kræver ansvarlig vurdering, kontekst og mulighed for at afvige fra et standardflow. AI kan være nyttig til at sortere, opsummere og foreslå næste trin, men den bør ikke alene afgøre vanskelige klager, identitetssager, økonomiske undtagelser eller henvendelser med særligt følsomme oplysninger.
En løsning bør have klare eskaleringsregler. Overtagelse bør udløses, når kundens identitet er usikker, når kunden anfægter en afgørelse, når sagen indeholder vrede eller sårbare oplysninger, når modellen mangler kildegrundlag, eller når en handling kan skade kunden økonomisk eller praktisk. Medarbejderen skal kunne se, hvad AI har gjort, hvilke oplysninger der er brugt, og hvorfor sagen blev eskaleret.
Gode AI-sikkerhedsprotokoller og standarder beskriver ikke kun tekniske roller, men også ansvar i driften. Det bør være klart, hvem der ejer vidensbasen, hvem der godkender ændringer, hvem der håndterer afvigelser, og hvordan et problem med AI-svar rapporteres.
Hvordan reduceres risikoen for forkerte eller opdigtede svar?
AI-modeller kan formulere et overbevisende svar uden at have sikkert grundlag for det. I kundeservice kan det føre til forkerte oplysninger om reklamationsret, leveringstid, pris, kontoindstillinger eller vilkår. En AI-hallucination bliver særlig problematisk, når kunden opfatter svaret som en bindende afklaring fra virksomheden.
Risikoen kan reduceres ved at lade AI svare ud fra godkendt viden, tydelige produktdata og aktuelle politikker. Når der ikke findes et sikkert svar, bør systemet sige, at sagen skal undersøges, i stedet for at gætte. Det er også en fordel at adskille generering fra beslutning: AI kan formulere et svar, men regelmotorer, databaser eller medarbejdere bør afgøre forhold som beløb, rettigheder og status.
Kvalitetskontrol bør omfatte både faktiske fejl og tonefejl. Et svar kan være faktuelt korrekt, men for kategorisk, for uklart eller for ufølsomt i en konflikt. Derfor bør testdata indeholde realistiske sager med tvetydige spørgsmål, fejlstavninger, vrede kunder, blandede sprog og ufuldstændige oplysninger.
Hvordan bør logning og overvågning indrettes?
Logning gør det muligt at undersøge fejl, forbedre vidensbasen og dokumentere, hvad der skete i en kundesag. Samtidig kan logfiler blive en ny risikokilde, fordi de ofte indeholder kundebeskeder, interne noter, modeloutput og tekniske hændelser. Sikker logning kræver derfor en balance mellem sporbarhed og dataminimering.
Organisationen bør beslutte, hvilke data der gemmes, hvor længe de gemmes, hvem der kan læse dem, og hvordan følsomme oplysninger maskeres. Det bør være muligt at finde mønstre uden at give unødvendig adgang til konkrete kundedata. Eksempler er gentagne afviste svar, mange eskaleringer på samme emne, usædvanlige opslag i kundedatabasen eller stigende fejlrate efter en ændring i vidensbasen.
Overvågning bør også dække misbrug. Hvis en bruger gentagne gange forsøger at få systemet til at afsløre interne regler, hente andre kunders data eller udføre handlinger uden godkendelse, bør det registreres som et sikkerhedssignal. Reaktionen kan være blokering, manuel gennemgang eller ændring af adgangsregler.
Hvad betyder leverandørvalg og databehandleraftaler?
Leverandøren påvirker sikkerheden, fordi AI-tjenesten ofte behandler kundedata uden for organisationens egne systemer. Før en løsning bruges med rigtige kundesager, bør dataveje, underleverandører, lagring, sletning, træningsbrug, supportadgang, kryptering og geografisk behandling være afklaret. Det samme gælder muligheden for at eksportere logs og dokumentere hændelser.
En praktisk leverandørkontrol bør skelne mellem tre spørgsmål: Hvilke data sendes ud af organisationen, hvad må leverandøren bruge dem til, og hvordan kan organisationen verificere, at aftalen følges? Hvis leverandøren ændrer model, datacenter, vilkår eller sikkerhedsfunktioner, bør ændringen vurderes, før den påvirker kundedialogen.
- Kontrollér om kundedata bruges til modeltræning eller kun til den konkrete behandling.
- Afklar slettefrister, backup, logadgang og underleverandører.
- Kræv klare procedurer for brud, fejl, serviceafbrydelser og ændringer i løsningen.
- Test eksport og lukning, så kundedata ikke bliver låst fast i et værktøj.
Hvilke europæiske regler påvirker sikkerhedsarbejdet?
I Europa skal AI i kundeservice vurderes sammen med regler for databeskyttelse, informationssikkerhed og transparens. GDPR stiller krav om passende tekniske og organisatoriske sikkerhedsforanstaltninger, når personoplysninger behandles. For en AI-løsning betyder det blandt andet, at risiko, datatyper, adgang, logning og test skal passe til den konkrete behandling.
EU AI Act kan også få betydning. Et AI-system, der er beregnet til direkte interaktion med personer, skal som udgangspunkt indrettes, så personen informeres om, at vedkommende interagerer med AI, medmindre det er åbenlyst i sammenhængen. For kundeservice betyder det, at en skjult automatiseret dialog kan være problematisk, især hvis kunden med rimelighed tror, at dialogen er med et menneske.
Ikke alle kundeservicebots er højrisikosystemer. Klassifikationen afhænger af formål, sektor, data, konsekvenser og den rolle, systemet spiller i beslutningen. En generel hjælpefunktion har typisk en anden risikoprofil end et system, der påvirker adgang til ydelser, økonomiske forhold eller rettigheder. Den vurdering bør dokumenteres, før løsningen sættes i drift.
Hvordan testes en AI-løsning før drift?
Test bør begynde med en trusselsmodel: Hvad kan gå galt, hvem kan udnytte det, hvilke data kan rammes, og hvilke handlinger kan AI-systemet påvirke? Derefter bør løsningen testes med realistiske kundesager, manipulerende beskeder, ufuldstændige oplysninger, ukorrekte antagelser og situationer, hvor det rigtige svar er at eskalere til et menneske.
Testen bør ikke kun måle, om svaret lyder godt. Den bør kontrollere, om systemet holder sig til godkendte kilder, afviser uautoriserede handlinger, beskytter interne regler, undgår at udlevere personoplysninger og registrerer hændelser korrekt. Integrationer skal testes særskilt, fordi fejl ofte opstår i koblingen mellem model, database og arbejdsflow.
- Fastlæg tilladte og forbudte opgaver for AI-systemet.
- Test almindelige kundespørgsmål mod godkendt viden.
- Test manipulerende og indirekte instruktioner i beskeder og bilag.
- Test adgangsgrænser for kundedata, ordrer og økonomiske handlinger.
- Test eskalering, logning, fejlbeskeder og nødstop.
Hvordan kan sikkerhed indbygges i den daglige arbejdsgang?
Sikker AI i kundeservice er en driftsopgave. Vidensbasen ændrer sig, produkter ændrer sig, kunder finder nye måder at stille spørgsmål på, og medarbejdere opdager svagheder i hverdagen. Derfor bør der være faste rutiner for at opdatere kilder, gennemgå fejl, justere eskaleringsregler og fjerne data, der ikke længere skal bruges.
Medarbejdere bør kunne markere et AI-svar som forkert, usikkert, for kategorisk eller datamæssigt problematisk. Den feedback bør ikke kun bruges til sprogforbedring. Den bør bruges til at rette kildemateriale, adgangsregler og processer. Hvis mange sager om samme emne eskaleres, kan problemet ligge i produktinformationen, ikke i modellen.
| Kontrol | Formål | Typisk ejer |
|---|---|---|
| Vidensbasegennemgang | Sikrer at AI svarer ud fra aktuelle oplysninger | Kundeservice eller produktansvarlig |
| Adgangsrevision | Fjerner unødvendige data- og værktøjsrettigheder | IT-sikkerhed eller systemejer |
| Hændelsesreview | Finder mønstre i fejl, misbrug og eskaleringer | Drift, compliance eller supportledelse |
Hvilke fejl bør organisationer undgå?
Den mest almindelige fejl er at se AI-løsningen som et isoleret skriveværktøj, selv om den reelt er forbundet med kundedata og processer. Når systemet får adgang til sagshistorik, identitet, ordrestatus eller interne retningslinjer, bliver det en del af organisationens sikkerhedsarkitektur.
- At sende fulde kundesager til AI, selv om en kort og maskeret version er nok.
- At lade AI udføre handlinger uden rollebaseret adgang og menneskelig godkendelse.
- At teste med for pæne eksempler og glemme vrede, uklare eller manipulerende henvendelser.
- At gemme logs uden klar frist, adgangsstyring og maskering.
- At skjule for kunden, at dialogen er automatiseret, når det ikke er åbenlyst.
- At antage, at en ny modelversion automatisk har samme sikkerhedsprofil som den gamle.
En mere robust tilgang begynder med små, afgrænsede brugssager. AI kan først hjælpe med at finde vidensbaseartikler eller foreslå svar, mens medarbejderen stadig kontrollerer afsendelse. Direkte handlinger i kundesystemer kan derefter tilføjes gradvist, hvis adgang, test, logning og eskalering fungerer stabilt.
Hvilke kilder ligger til grund?
Kildesektionen bygger på OWASPs 2025 Top 10 Risk & Mitigations for LLMs and Gen AI Apps, NISTs AI Risk Management Framework, GDPR-teksten om behandlingssikkerhed og EU AI Act-reglen om transparens ved direkte AI-interaktion.