Innledning
De fleste bedrifter som tester AI for kundesupport støter på det samme problemet. Systemet fungerer fint i flere uker. Så gir det én kunde et selvsikkert, men fullstendig feil svar. Kanskje om en frist for refusjon. Kanskje om en policy som ble endret forrige kvartal. En overordnet legger merke til det, og utrullingen som skulle dekke det meste av køen, stopper stille opp etter å ha dekket bare en brøkdel av den.
Bransjedata bekrefter hvor vanlig dette mønsteret er. «2025 World Quality Report» fra OpenText, Capgemini og Sogeti viste at bekymringer knyttet til pålitelighet og feilvarninger var den største hindringen for innføring av AI for 60 % av de spurte organisasjonene. En separat undersøkelse fra Gong viste at 58 % av bedriftene hadde satt AI-prosjekter på vent, og at nesten halvparten av planlagte AI-investeringer ble holdt tilbake av tillitsproblemer snarere enn budsjettbegrensninger. Verktøyene er kapable. Det er tilliten til dem som henger etter.
Matematikken bak ett feil svar
Supportarbeid er asymmetrisk på en måte som straffer gjennomsnittlig nøyaktighet som målestokk. Et riktig svar sparer noen minutter. Et feil svar kan godkjenne en refusjon som aldri burde ha blitt utbetalt, finne opp en policy som aldri har eksistert, eller inngå en forpliktelse som ingen har godkjent. Når ulempen ved én feil oppveier fordelen ved hundre riktige svar, er det helt feil å optimalisere for gjennomsnittstilfellet.
Det er også en mer skjult kostnad. En supportleder som oppdager at AI-en tar feil én gang, begynner å dobbeltsjekke alt etter det, noe som utligner det meste av tiden det egentlig skulle spare. Tillit måles ikke per samtale. Den bygges opp eller bryter sammen, og når den først bryter sammen, slutter teamene å stole på systemet selv om det har rett mesteparten av tiden.
Hallusinasjoner forsvinner ikke, de håndteres
Selv de sterkeste språkmodellene dikter opp under de rette forholdene, og de reelle tallene er høyere enn de fleste antar. Når det gjelder grunnfestet oppsummering – i hovedsak den samme oppgaven som å svare ut fra egne hjelpedokumenter – plasserer Vectaras rangliste for hallusinasjoner de beste modellene rundt 3 %, og viser at velkjente flaggskipsmodeller ligger mellom 6 % og 15 %. Noen modeller som er tunge på resonnement, klatrer over 20 % på den samme oppgaven, fordi dypere resonnement gir dem større rom for å innføre påstander som kildeteksten aldri har fremsatt. Sett en modell til å svare på åpne spørsmål uten noe å forankre den i, og tallene blir mye dårligere. Forskere ved Stanford fant at ledende modeller hallusinerte på et stort flertall av spesifikke juridiske spørsmål når det ikke ble gitt noe kildedokument.
Ingenting av dette betyr at en bestemt modell er dårlig. Det betyr at ingen enkeltmodell, brukt alene, er pålitelig nok til å brukes overfor betalende kunder uten at noe holder øye med den.
Intelligens og kontroll trekker i motsatte retninger
Det er en strukturell grunn til at en enkelt modell ikke kan løse dette på egen hånd. Etter hvert som et system blir bedre til å håndtere tvetydige eller ukjente saker, blir det også vanskeligere å forutsi fullt ut, fordi den samme resonnementet som lar det håndtere en sak ingen har skrevet manus for, er det samme resonnementet som av og til fører det et sted det ikke burde gå. En mer kapabel modell er ikke automatisk en tryggere modell. Denne avveiningen er grunnen til at pålitelighet må bygges inn som et lag rundt modellen, i stedet for å forventes av modellen i seg selv.
Aissist løser dette med fire lagdelte teknikker i stedet for én. Prompt engineering fastsetter grunnleggende regler som hver oppgave følger, noe som er viktigere i et agentbasert system der en enkelt kundeforespørsel kan utvides til mer enn et dusin deloppgaver som alle må overholde de samme retningslinjene. Et «booster step» kjører usikre beslutninger mer enn én gang og beholder det svaret de fleste agenter er enige om, på bekostning av ekstra databehandling. En «self inspection»-runde innebærer at systemet gjennomgår sin egen utdata, eller overleverer den til en annen modell i en annen rolle, før noe når kunden. Og et «stacked governance layer» ligger over alt dette og sjekker om en utdata eller handling samsvarer med retningslinjene før den sendes ut, og fungerer mindre som et filter og mer som en tilsynsinstans for hele systemet.
Det er denne kombinasjonen som gjør at plattformen holder AI-feilraten under 1 %, et tall som er verdt å merke seg, hovedsakelig fordi så få leverandører i denne bransjen i det hele tatt offentliggjør en slik feilrate.
Å vurdere når man ikke skal svare
Den mest verdifulle egenskapen hos en supportagent er ikke å svare riktig på flere spørsmål. Det er å gjenkjenne hvilke spørsmål den ikke bør prøve å svare på alene. Et system som eskalerer en vanskelig faktureringskonflikt tidlig, med full kontekst vedlagt, forårsaker langt mindre skade enn et system som presser på og gjetter. Dette er også det som skiller en agent som beskriver en løsning fra en som faktisk gjennomfører den – ved å hente frem bestillingen, foreta endringen og bekrefte den tilbake til kunden.
Pålitelighet må opprettholdes, ikke bare bygges opp
Et system som er nøyaktig på lanseringsdagen, vil ikke forbli slik uten at noen overvåker det. Produkter endres, retningslinjer oppdateres, og spørsmålene kundene stiller endrer seg i takt med dette. Kontinuerlig måling fanger opp disse endringene som data i stedet for som en bølge av klager, og en disiplinert syklus med evaluering, testing og utrulling fortsetter å tette hullene den finner, med et menneske som fortsatt godkjenner før noe endres i praksis.
Hva du faktisk bør sjekke før du stoler på en leverandør
Enhver leverandør som hevder at deres AI aldri tar feil, bør behandles med skepsis, fordi det vanligvis betyr at ingen måler nøye nok til å vite noe annet. De som er verdt å ta på alvor, publiserer en feilprosent, forklarer nøyaktig hvordan de oppdager feil før kundene ser dem, og er åpne om når systemet overlater saken til en person i stedet for å gjette. Det er et helt annet salgsargument enn «stol på AI-en», og det er det som faktisk holder mål når det virkelige antallet henvendelser slår inn.
