Fra AI-idé til drift: Sådan tester I, om løsningen faktisk virker

En leder ser en demonstration, hvor AI læser en mail, finder kundens ordre og skriver et præcist svar på få sekunder. Alle omkring bordet kan se gevinsten.

I driften er mailen måske på svensk. Kunden omtaler to ordrer i samme tråd. Returreglen blev ændret i sidste uge. Et indsat dokument indeholder en skjult instruktion. Og den kollega, der normalt opdager undtagelsen, har fået at vide, at systemet allerede er testet.

Afstanden mellem de to situationer er det arbejde, et seriøst pilotprojekt skal udføre.

Start med problemet, som det ser ud i dag

AI-projekter begynder ofte med en løsning: “Vi vil have en chatbot” eller “Vi skal have en agent.” Det gør det svært at vurdere, om projektet overhovedet hjælper.

Skriv i stedet problemet i almindeligt sprog:

Kundeservice bruger i gennemsnit 14 minutter på at finde relevante oplysninger og skrive et første svar på leveringshenvendelser. I 18 procent af sagerne sendes sagen videre, fordi information mangler eller sagen er en undtagelse.

Nu kan I undersøge, om flaskehalsen er søgning, datakvalitet, uklare regler, manglende oplæring eller selve formuleringen. AI er muligvis én del af løsningen. Måske er en bedre søgefunktion eller en enklere politik mere effektiv.

Mål en baseline før forsøget:

• tid pr. sag og samlet gennemløbstid
• faglig korrekthed og antal rettelser
• videresendelser, genhenvendelser og klager
• medarbejderens belastning og oplevede kontrol
• variation mellem almindelige sager og undtagelser

Hvis I først måler efter indførelsen, mangler sammenligningen. Og hvis I kun måler tid, kan en hurtigere proces skjule flere fejl.

Gør succes og fiasko målbar

“Bedre svar” er ikke et testkriterium. Beskriv de egenskaber, der skal være til stede.

For et AI-udkast til kundeservice kan kriterierne være:

• Den korrekte ordre og aktuelle politik anvendes.
• Alle nødvendige spørgsmål bliver stillet.
• Der loves ikke noget, medarbejderen ikke har mandat til.
• Svaret er forståeligt og passer til virksomhedens tone.
• Sager om betaling, trusler eller følsomme oplysninger sendes til den rigtige person.
• Systemet stopper, når datagrundlaget er uklart.

Sæt en tærskel for hvert kriterium og beslut, hvilke fejl der er uacceptable uanset gennemsnittet. Et system kan have 95 procent korrekte svar og stadig være ubrugeligt, hvis de sidste fem procent omfatter farlige betalingsinstruktioner.

OpenAI og Anthropic anbefaler begge at definere succeskriterier og evalueringer tidligt i agent- og modelarbejde. Pointen er ikke leverandørspecifik: Det, I ikke kan beskrive som et acceptabelt resultat, kan I heller ikke teste meningsfuldt.

Byg et lille, hårdt testsæt

Et brugbart pilotprojekt behøver ikke tusind sager fra dag ét. Det behøver et repræsentativt og bevidst krævende sæt.

Tag eksempelvis 40 historiske eller kunstigt konstruerede sager:

• 20 almindelige sager
• 8 sager med manglende eller modstridende oplysninger
• 5 sjældne, men vigtige undtagelser
• 3 sager med følsomme eller fortrolige data
• 2 sager med en misvisende instruktion i en mail eller fil
• 2 sager, hvor systemet skal sige “jeg kan ikke afgøre det”

Fjern eller beskyt persondata efter jeres regler. Lad fagpersoner beskrive det forventede resultat, før AI’en køres. Ellers risikerer I at flytte målstregen, når et overbevisende svar dukker op.

Gem både input, forventning, faktisk output og bedømmelse. Når et svar fejler, klassificér årsagen: forkert kilde, forældet data, manglende kontekst, dårlig prompt, utilstrækkelig rettighed, integrationsfejl eller modeladfærd.

Den klassifikation fortæller, hvad der skal ændres. Flere promptord reparerer ikke en forældet database.

Test hele kæden

En model kan være god, mens løsningen er dårlig. Det sker, når den får forkert data, kalder det forkerte værktøj eller afleverer svaret på en måde, der ikke kan kontrolleres.

Kortlæg kæden:

1. Hvilken hændelse starter processen?
2. Hvilke data hentes, fra hvilken version og med hvilke rettigheder?
3. Hvad må modellen foreslå, og hvad må den udføre?
4. Hvor skal et menneske godkende?
5. Hvad logges uden at skabe unødig datarisiko?
6. Hvad sker der ved timeout, manglende data eller modstridende instruktioner?
7. Hvordan vender sagen tilbage til den normale arbejdsgang?

Test også de kedelige tekniske fejl: et system er nede, et felt ændrer navn, et dokument er scannet dårligt, eller to kunder har næsten samme navn. Drift går oftere i stykker på grænseflader end i den perfekte demoprompt.

Brug skyggedrift før automatisk handling

I skyggedrift kører AI-løsningen på virkelige eller realistiske sager, men dens forslag styrer ikke udfaldet. Den normale proces fortsætter, og resultaterne sammenlignes bagefter.

Det giver svar på spørgsmål, et lukket testsæt ikke kan:

• Hvor ofte dukker nye sagstyper op?
• Hvor meget tid bruger medarbejderen på at kontrollere?
• Bliver fejl opdaget eller bare godkendt?
• Skaber systemet nye afbrydelser og koordinationsarbejde?
• Er datakilderne faktisk opdaterede i hverdagen?

Næste trin kan være begrænset medpilot: AI foreslår, og en fagperson godkender hver sag. Først senere kan bestemte lavrisikohandlinger eventuelt automatiseres.

Udvid efter dokumentation, ikke efter kalender. “Piloten har kørt i fire uger” siger ikke, om den har mødt nok variation.

Mål det skjulte arbejde

En automatisering kan se effektiv ud i systemets statistik og samtidig flytte arbejde til andre mennesker.

Medarbejderen bruger måske mindre tid på at skrive, men mere tid på at:

• kontrollere kilder og tal
• omskrive generiske formuleringer
• genskabe konteksten, som systemet fjernede
• håndtere mærkelige undtagelser
• forklare fejl til kunder og kolleger
• vedligeholde prompts, instruktioner og adgang

Mål derfor samlet arbejdsforbrug og kvalitet på tværs af processen. Tal med de mennesker, der modtager outputtet. En hurtigere første afdeling kan skabe langsommere sagsbehandling hos den næste.

Se også på variation. Hvis erfarne medarbejdere får stor gevinst, mens nye medarbejdere godkender flere fejl, kræver løsningen en anden træning og arbejdsdeling.

Sikkerhed og prompt injection hører til piloten

Når en AI-agent læser eksternt indhold og har adgang til værktøjer, kan materialet indeholde instruktioner, der forsøger at få agenten til at ignorere sine regler. Det kaldes prompt injection.

En supportagent kan eksempelvis læse en vedhæftet fil med en skjult besked om at sende data til en anden adresse. Hvis agenten både kan læse og handle, er det ikke kun et forkert svar, men en sikkerhedshændelse.

Test derfor:

• om eksternt indhold behandles som data og ikke som autoritative instruktioner
• om agenten har mindst mulige rettigheder
• om følsomme handlinger kræver menneskelig godkendelse
• om destination, beløb og modtager er synlige ved godkendelsen
• om logs gør en hændelse forståelig uden at kopiere unødige hemmeligheder

OpenAI’s beskrivelse af forsvar mod prompt injection fremhæver netop begrænset adgang, robuste arbejdsgange og brugerbekræftelse ved vigtige handlinger. Ingen enkelt prompt er et fuldt forsvar.

Aftal go, no-go og rollback på forhånd

Når teamet har investeret tid og begejstring, bliver det sværere at stoppe. Skriv derfor beslutningsreglerne før pilotens afslutning.

Et go kan kræve, at:

• alle kritiske tests består
• kvaliteten mindst matcher baseline
• tidsgevinsten er reel efter kontrolarbejde
• databeskyttelse, sikkerhed og ansvar er godkendt
• medarbejderne er trænet og kan bruge alternativet
• overvågning og en navngiven ejer er på plads

Et no-go eller en pause kan udløses af:

• en kritisk fejltype, selv om gennemsnittet er godt
• manglende mulighed for at forklare eller rette udfald
• en leverandør- eller dataændring, der ikke er testet
• uacceptabel påvirkning af kunder eller medarbejdere
• omkostninger eller kontrolarbejde, der fjerner gevinsten

Rollback betyder, at I kan vende sikkert tilbage til en kendt arbejdsgang. Bevar instruktioner, adgang og bemanding til alternativet. Øv om nødvendigt skiftet, ligesom man øver andre beredskaber.

Drift er et løbende eksperiment med ansvar

Efter lancering kan modellen, systemprompten, datakilden, integrationen eller brugeradfærden ændre sig. En regel kan få ny ordlyd. Kundernes sprog kan skifte. En leverandør kan opdatere en standardindstilling.

Udpeg derfor en ejer, der følger:

• kvalitet på et fast testsæt og stikprøver fra drift
• kritiske fejl, klager og menneskelige tilsidesættelser
• ændringer i model, data, prompt og værktøjer
• om gevinsten stadig findes
• om nye grupper eller anvendelser påvirkes
• dato for næste samlet vurdering

NIST’s AI Risk Management Framework beskriver risikostyring som en løbende cyklus af at styre, kortlægge, måle og håndtere. Det passer godt til generativ AI, fordi adfærden ikke kan reduceres til én godkendelsestest.

Brug versionsnumre på den samlede løsning, ikke kun modellen. En ny prompt eller datakilde kan ændre mere end et nyt modelnavn.

Den gode pilot gør jer klogere – også når svaret er nej

Et pilotprojekt er ikke mislykket, hvis det viser, at AI ikke skal overtage opgaven. Det kan afdække en uklar proces, dårlig datakvalitet eller et behov for bedre søgning og oplæring.

Det mislykkede pilotprojekt er det, der kun producerer en flot demonstration og ingen viden om grænserne.

Når problem, baseline, testsæt, skyggedrift, stopkriterier og ejer er på plads, kan organisationen træffe en mindre dramatisk beslutning: Ikke “tror vi på AI?”, men “har denne løsning dokumenteret, at den gør denne opgave bedre under de vilkår, vi faktisk arbejder under?”

Det spørgsmål er lidt kedeligere end demoen. Det er også langt mere værdifuldt.

Kilder og videre læsning

• OpenAI: A practical guide to building AI agents – leverandørguide om blandt andet valg af opgave, guardrails og menneskelig indgriben.
• OpenAI: Designing AI agents to resist prompt injection – officiel beskrivelse af truslen og forsvar i agentarbejdsgange.
• Anthropic: Define success criteria and build evaluations – leverandørguide til målbare kriterier og testsæt.
• Anthropic: Building effective agents – praktiske mønstre og afvejninger for agenter og workflows.
• NIST: AI Risk Management Framework – officiel ramme for løbende styring, kortlægning, måling og håndtering af AI-risici.
• Digitaliseringsstyrelsen: Guide til virksomheder – dansk myndighedsguide til ansvarlig brug af generativ AI.