Udvikling af AI-modeller til kundeservice

Udvikling af AI-modeller til kundeservice handler om at tilpasse en model til konkrete henvendelser, viden, svarregler og kvalitetskrav. Den sikre tilgang er ikke kun træning, men en styret proces med datavalg, test, menneskelig eskalering, dokumentation og løbende måling.

Hvad betyder udvikling af AI-modeller til kundeservice?

En AI-model til kundeservice er et system, der kan forstå henvendelser, finde relevant information, formulere svar eller foreslå næste handling. Modellen kan være en sprogmodel, en klassifikationsmodel, en sentimentmodel, en søgemodel eller en kombination af flere komponenter. I praksis er det ofte hele løsningen omkring modellen, der afgør kvaliteten.

Udvikling betyder derfor mere end at træne en model på gamle supportsager. Det omfatter valg af opgaver, datakilder, svargrænser, integration med vidensbase, test af fejltyper, logning, eskalering og drift. En model kan være teknisk stærk og stadig være uegnet, hvis den svarer uden korrekt kildegrundlag eller ikke sender vanskelige sager videre til et menneske.

For kundeservice er den praktiske målsætning normalt ikke at erstatte al dialog. Den er at håndtere gentagne, velafgrænsede spørgsmål mere ensartet, hjælpe medarbejdere med forslag og gøre det lettere at finde korrekt information på tværs af kanaler.

Hvilke kundeserviceopgaver egner sig bedst til AI-modeller?

De mest egnede opgaver har tydelige mønstre, gentagne formuleringer og svar, der kan kontrolleres mod en godkendt kilde. Det gælder for eksempel statusspørgsmål, produktinformation, returprocesser, adgangsproblemer, klassificering af henvendelser og forslag til standardiserede svar.

Opgaver med høj usikkerhed, stærke følelser, klager, økonomiske konsekvenser eller behandling af følsomme oplysninger kræver en anden afgrænsning. Her kan AI støtte med opsummering, prioritering eller forslag, men bør ikke stå alene som afgørende instans. Kundeservice involverer ofte tillid, kontekst og undtagelser, som ikke kan reduceres til et svarmønster.

Hvis formålet er en egentlig chatbot, hænger modeludviklingen tæt sammen med dialogdesign, fallback-svar og kanalvalg. AI Mentors gennemgang af, hvordan man bygger en chatbot, er et relevant internt udgangspunkt for den del af løsningen.

Hvordan starter man med datagrundlaget?

Datagrundlaget bør begynde med en opgaveanalyse, ikke med et stort dataudtræk. Først skal du fastlægge, hvilke spørgsmål modellen skal håndtere, hvilke svar den må give, og hvilke oplysninger den må bruge. Derefter kan data udvælges, renses og opdeles efter formål.

Tre datatyper er særligt relevante i kundeservice. Historiske henvendelser viser formuleringer, fejltyper og variationer. Godkendte vidensartikler viser de svar, organisationen faktisk vil stå inde for. Evalueringsdata viser, om modellen klarer nye henvendelser, der ligner virkeligheden, uden at den blot gentager træningseksempler.

Persondata kræver en stram afgrænsning. Kundemails og chatlogs kan indeholde navne, kontaktoplysninger, ordrenumre, helbredsoplysninger, økonomiske forhold eller fritekst, som ikke er nødvendig for at udvikle en model. Dataminimering betyder, at du kun bør bruge de oplysninger, der er nødvendige for det konkrete formål. Pseudonymisering, sletning af unødige felter og separate testdatasæt er derfor en del af udviklingsarbejdet, ikke en eftertanke.

Hvornår er RAG bedre end finjustering?

Retrieval-augmented generation, ofte forkortet RAG, er typisk bedst, når svaret skal bygge på en opdateret vidensbase. I stedet for at gemme al viden i modelvægtene søger systemet først i godkendte dokumenter, produktdata eller supportsider og giver derefter modellen den relevante kontekst til at formulere svaret.

Finjustering er mere relevant, når modellen skal lære et bestemt format, en bestemt klassifikation, en bestemt svartone eller en opgavespecifik måde at følge instruktioner på. Den er normalt ikke den bedste metode til hurtigt skiftende produktvilkår, priser, leveringstider eller politikker, fordi viden i træningsdata kan blive forældet.

For kundeservice er den mest robuste løsning ofte en kombination. RAG leverer aktuel viden, mens instruktioner, eksempler, evalueringsdata og eventuelt finjustering styrer format og adfærd. Det reducerer ikke risikoen til nul, men det gør det lettere at kontrollere, hvor et svar kommer fra, og hvornår modellen mangler grundlag.

Hvordan kan modellen testes før drift?

Test bør måle både korrekthed, brugbarhed og risiko. En model kan score højt på generelle svar og stadig fejle på de situationer, der betyder mest: forkerte returregler, upræcise priser, overset eskalering, for sikker tone ved usikkert svar eller brug af oplysninger, som ikke burde indgå.

Et brugbart evalueringssæt bør indeholde almindelige spørgsmål, kanttilfælde, uklare formuleringer, flersprogede henvendelser, vrede kunder, irrelevante spørgsmål og forsøg på at få modellen til at ignorere regler. For hver test bør der være et forventet svarområde, en grænse for accept og en klar handling, hvis modellen fejler.

• Test om svaret er faktuelt korrekt i forhold til den godkendte kilde.
• Test om modellen siger fra, når der mangler information.
• Test om den eskalerer ved klager, følsomme oplysninger eller usikre sager.
• Test om den holder sig til den ønskede rolle og ikke opfinder procestrin.
• Test om samme spørgsmål får ensartede svar på tværs af formuleringer.

NISTs arbejde med AI-risikostyring peger på, at risiko kan se anderledes ud i kontrollerede tests end i faktisk drift. Derfor bør test ikke stoppe ved lancering. De første uger i produktion bør behandles som en måleperiode med tæt overvågning, lave automationsgrænser og hurtig mulighed for rollback.

Hvilke kvalitetsmål bør man styre efter?

Kvalitet i kundeservice kan ikke måles med én score. En model kan give korte svar, men misforstå sagen. Den kan give venlige svar, men være upræcis. Den kan løse mange henvendelser, men skabe flere opfølgende kontakter, hvis kunderne ikke får et brugbart svar første gang.

Derfor bør kvalitetsmål kombineres. Første gruppe handler om modelens tekniske præstation: korrekt klassifikation, svarpræcision, kildebrug, afvisning ved manglende grundlag og robusthed mod manipulerende instruktioner. Anden gruppe handler om serviceeffekt: løsningsgrad, genåbnede sager, gennemsnitlig håndteringstid, medarbejderkorrektioner og kundetilfredshed.

AI-baseret analyse kan også bruges til at måle mønstre i henvendelser og tilfredshed, men måling bør ikke forveksles med sandhed. Hvis en sentimentmodel vurderer en kunde som negativ, er det et signal til prioritering eller nærmere læsning, ikke en endelig diagnose. Det samme gælder ved sentimentanalyse for bedre kundeservice, hvor kontekst og sprogbrug har stor betydning.

Hvordan bør menneskelig eskalering bygges ind?

Menneskelig eskalering bør defineres som en del af modelens adfærd. Det er ikke nok at have en medarbejder et sted i organisationen, hvis modellen ikke kan genkende de situationer, hvor et menneske skal overtage. Eskalering skal være konkret, testbar og synlig i logningen.

En god eskaleringsregel beskriver både udløser og handling. Hvis kunden skriver om klage, opsigelse, sikkerhed, betaling, sygdom, juridiske konsekvenser eller gentagne fejl, skal modellen kunne skifte fra svar til overdragelse. Hvis den ikke kan finde et sikkert svar i vidensbasen, bør den sige det klart og sende sagen videre i stedet for at formulere et sandsynligt svar.

For medarbejdervendte løsninger kan modellen stadig være nyttig i vanskelige sager. Den kan opsummere samtalen, foreslå relevante vidensartikler, udpege manglende oplysninger og skrive et udkast. Men ansvaret for den endelige vurdering bør være placeret hos en person, når sagen har praktiske, økonomiske eller personlige konsekvenser for kunden.

Hvordan håndteres sikkerhed og misbrug?

Kundeservicekanaler er åbne for uforudsigelige input. En model kan møde forsøg på at få interne regler frem, omgå adgangskontrol, udlevere oplysninger om andre kunder eller skrive svar, der strider mod virksomhedens processer. Sikkerhed handler derfor både om tekniske kontroller og om klare svargrænser.

Et centralt kontrolpunkt er adskillelsen mellem brugerens tekst, systemets instruktioner og de data, modellen må bruge. Kundens besked bør ikke kunne ændre systemets rolle, sikkerhedsregler eller adgang til interne oplysninger. Derudover bør integrationer begrænses, så modellen kun kan udføre de handlinger, den faktisk har brug for.

Logning er også nødvendig, men logning må ikke blive et ubegrænset lager af persondata. Organisationen bør definere, hvilke hændelser der logges, hvor længe de gemmes, hvem der kan se dem, og hvordan de bruges til forbedring. NISTs generative AI-profil fremhæver test, evaluering og dokumentation af risici som en del af udviklings- og driftsarbejdet.

Hvordan passer AI-modeller ind i eksisterende kundeserviceværktøjer?

En AI-model bliver først praktisk nyttig, når den passer ind i de systemer, medarbejdere og kunder allerede bruger. Det kan være ticketsystem, chat, telefontransskription, CRM, vidensbase, ordresystem eller selvbetjeningsportal. Integrationerne bør designes efter mindste nødvendige adgang.

Hvis modellen kun skal foreslå et svar, behøver den sjældent skriveadgang til kundens sag. Hvis den skal oprette en returlabel, kræver det derimod en kontrolleret handling med tydelig godkendelse, fejlhåndtering og logning. Jo tættere modellen kommer på egentlige handlinger, jo vigtigere bliver adgangsstyring, revisionsspor og rollback.

Internt hænger dette sammen med automatisering af kundehenvendelser med AI. Automatisering bør begynde med opgaver, hvor regler, datakilder og ansvar er tydelige. Først derefter giver det mening at udvide til mere komplekse samtaler eller handlinger.

Hvad skal dokumenteres under udviklingen?

Dokumentation gør modellen lettere at styre, fejlfinde og forbedre. Den bør beskrive formål, målgruppe, datakilder, fravalgte datatyper, modeltype, integrationspunkter, testresultater, kendte begrænsninger, eskaleringsregler og ansvar for drift. Dokumentationen skal være praktisk nok til, at både tekniske og kundeservicefaglige personer kan bruge den.

Dokumentationen bør også indeholde beslutninger, der ofte forsvinder i projektforløb: hvorfor visse henvendelser ikke automatiseres, hvilke svar modellen ikke må give, hvordan datakilder opdateres, og hvilke fejl der udløser stop eller manuel gennemgang. Det er særligt nyttigt, når modellen senere skal opdateres, eller når en ny leverandør, platform eller kanal bliver relevant.

I EU-kontekst kan AI Act og GDPR gøre dokumentation endnu vigtigere, afhængigt af løsningens rolle, risikoniveau og databehandling. En almindelig kundeservicebot er ikke automatisk et højrisikosystem, men transparens, dataminimering, adgangsstyring og ansvarlig brug er stadig relevante kontrolpunkter.

Hvornår bør modellen opdateres eller trænes igen?

Modellen eller dens omkringliggende opsætning bør opdateres, når produkter, politikker, kundemønstre eller kvalitetstal ændrer sig. I en RAG-løsning kan den vigtigste opdatering være selve vidensbasen. I en klassifikationsmodel kan det være nye labels. I en finjusteret model kan det være nye eksempler, hvis de gamle ikke længere dækker virkelige henvendelser.

Genoptræning bør ikke være automatisk uden kontrol. Nye data kan indeholde fejl, midlertidige undtagelser, personoplysninger eller medarbejderformuleringer, som ikke bør blive modeladfærd. Derfor bør opdateringer gennem samme evalueringsflow som den første version: datascreening, test, sammenligning med baseline, risikovurdering og beslutning om drift.

Et tegn på behov for opdatering er, at medarbejdere ofte retter de samme svar. Et andet tegn er, at kunder stiller nye spørgsmål efter produktændringer, kampagner eller ændrede vilkår. Her bør fejlmønstre omsættes til bedre vidensartikler, bedre routing eller nye evalueringssager, før man konkluderer, at selve modellen skal ændres.

Hvordan kan man indføre AI i kundeservice trin for trin?

En trinvis indførelse giver mere kontrol end en bred lancering. Start med et afgrænset område, hvor svarene er dokumenterede, risikoen er lav, og medarbejderne kan vurdere output. Det kan være interne svarforslag, emneklassifikation eller en bot, der kun svarer på et snævert sæt spørgsmål.

1. Vælg en konkret opgave med målbare kvalitetskrav.
2. Rens og afgræns data, så modellen kun bruger nødvendige oplysninger.
3. Byg en prototype med tydelige svargrænser og eskalering.
4. Test mod realistiske henvendelser, fejltyper og kanttilfælde.
5. Lad medarbejdere bruge løsningen som assistent før fuld automatisering.
6. Mål fejl, korrektioner, løsningsgrad og kundeoplevelse løbende.

Når modellen viser stabil kvalitet, kan anvendelsen udvides. Det kan være til flere kanaler, flere emner eller tættere integration med serviceværktøjer. En separat vurdering af AI-drevne chatbots i kundeoplevelser kan hjælpe med at skelne mellem teknisk funktion og faktisk serviceværdi.

Hvilke fejl bør undgås i udviklingsarbejdet?

Den mest almindelige fejl er at behandle modeludvikling som et rent teknisk projekt. Kundeservicekvalitet afhænger af procesviden, tone, undtagelser, ansvar og kundeoplevelse. Hvis medarbejdere først involveres efter lancering, opdages mange fejl for sent.

En anden fejl er at bruge historiske samtaler som sandhed. Gamle svar kan være forældede, ufuldstændige eller skrevet under tidspres. De kan vise, hvordan kunder spørger, men de bør ikke alene bestemme, hvad modellen skal svare. Godkendte videnskilder og aktuelle procedurer bør have højere vægt end tilfældige tidligere formuleringer.

En tredje fejl er at måle succes på antallet af automatiserede svar alene. Hvis automatisering sænker kvaliteten, øger genkontakt eller skjuler utilfredse kunder, er den ikke en forbedring. Udvikling af AI-modeller til kundeservice bør derfor koble teknisk performance med servicekvalitet, sikkerhed og menneskelig kontrol.

Hvilke kilder ligger til grund?

Artiklen bygger på NIST AI Risk Management Framework 1.0 og NISTs generative AI-profil for risikostyring, test og driftskontrol. Den tekniske afgrænsning mellem retrieval og modeltræning bygger blandt andet på forskningsartiklen om retrieval-augmented generation samt OpenAI-dokumentationen om modeloptimering og finjustering.

Databeskyttelse og europæisk kontekst er afgrænset med udgangspunkt i GDPR på EUR-Lex og den officielle tekst til EU’s Artificial Intelligence Act.