En demo af en AI-funktion viser det bedste tilfælde med udvalgte eksempler, én bruger og en udvikler ved tastaturet. Før funktionen kan gå i drift hos kunderne, mangler der typisk fem ting: en måling af kvaliteten, en plan for fejl, overvågning af svarene, en aftale med support og en styring af forbruget. Afstanden fra demo til drift overrasker de fleste ledelser, for det, der var hurtigt at vise frem, er kun den første del af arbejdet.
Det hænger sammen med teknikken. En sprogmodel, som er den AI-teknik, de fleste tekstfunktioner bygger på, kan give imponerende resultater efter få dages arbejde. Det svære er alle de tilfælde, som ingen tænkte på i demoen, og at holde kvaliteten, når modellen, data og brugerne ændrer sig.
Kvalitet, I kan vise frem
Spørg udviklerne: hvor ofte er svaret godt nok, og hvordan ved I det? Hvis svaret er “det ser fint ud”, er der ingen måling endnu.
Før drift skal der findes en samling af virkelige eksempler, også de svære, med en vurdering af, hvad der er et godt svar. Samlingen køres ved hver ændring. Fremgangsmåden står i artiklen om test af AI-funktioner. Ledelsen bør selv se resultatet, og beslutte hvilken kvalitet der er god nok til netop denne opgave. Det er en forretningsbeslutning, som udviklerne ikke bør sidde alene med.
Spørg desuden, hvad der sker, når teksten er lang, sproget er dansk med fagudtryk, spørgsmålet er uklart, eller der ikke findes noget svar i data.
Fejl, der kan ske, og hvad brugeren så ser
Tre slags fejl skal have et design:
- Tjenesten svarer ikke. Modellen er nede, kaldet tager for lang tid, eller I rammer udbyderens loft. Brugeren skal have en klar besked, og resten af produktet skal fortsætte.
- Svaret er forkert. Det er emnet i AI-funktionen svarer forkert. Designet skal gøre det let at kontrollere, rette og melde fejl.
- Svaret er upassende. Funktionen kan bringes til at sige noget, I ikke vil stå på mål for. Der skal være en grænse for, hvad den må svare på, og en test af den.
Svartid hører med. En sprogmodel kan være flere sekunder om et svar, og det føles langt i et produkt, der ellers reagerer med det samme. Vis, at der arbejdes, og lad svaret komme frem løbende, hvor det giver mening.
Overvågning af noget, der ikke går ned
Almindelig overvågning fortæller, om tjenesten kører. En AI-funktion kan køre fint og alligevel give dårligere svar end i sidste måned. Overvågningen skal derfor også se på:
- andelen af svar, brugerne markerer som dårlige, og hvor brugerne opgiver,
- om svarene ændrer sig efter en opdatering af model, data eller instruktioner,
- svartid og fejl fra udbyderen,
- forbrug pr. kunde og pr. funktion.
Nogen skal læse et udsnit af rigtige samtaler med faste mellemrum, når det er aftalt med kunderne, og når logningen er bygget til det. Hvad der må gemmes, er emnet i kundedata i AI-funktionen. Generel overvågning og vagt står i overvågning, vagt og driftshændelser.
Support skal kende funktionen
Når en kunde skriver “jeres AI sagde noget forkert”, skal supporten kunne se, hvad der blev spurgt, og hvad der blev svaret. Den skal vide, hvad funktionen kan og ikke kan, og hvem der tager sagen videre. Skriv en kort side til support, før funktionen frigives, og aftal, hvem der retter hvad. Er det data, instruktioner eller modellen? Uden den aftale ender sagerne hos den udvikler, der byggede prototypen.
Styring af forbruget
En købt model afregnes som regel efter forbrug. I en demo betyder det intet. I drift kan én kunde med et automatisk script bruge mere end alle andre tilsammen. Før frigivelse skal der være:
- et loft pr. bruger og pr. kunde,
- en besked, når loftet nås, som kunden forstår,
- en alarm, der går til en person, når forbruget stiger usædvanligt,
- mellemlagring af svar, hvor det er sikkert, og valg af mindre model til lette opgaver.
Vær opmærksom på, at funktioner, som kalder modellen i en løkke, kan bruge meget på kort tid. Det gælder især AI-agenter.
Tjekliste: klar til kunder
Gennemgå listen på et møde med den, der ejer produktet, den, der ejer teknikken, og support. Kan et punkt ikke besvares, er det det næste arbejde.
- ☐ Vi har en testsamling, og den køres før hver udgivelse.
- ☐ Vi har besluttet, hvilken kvalitet der er god nok.
- ☐ Funktionen kan slås fra uden ny udgivelse, pr. kunde og samlet.
- ☐ Brugeren kan melde et dårligt svar med ét klik.
- ☐ Vi ved, hvad der gemmes, hvor længe, og hvem der kan se det.
- ☐ Vi har et loft for forbrug og en alarm.
- ☐ Support har en side om funktionen og en vej videre.
- ☐ Brugeren kan se, at det er AI, se gennemsigtighedskravene.
- ☐ Vi har besluttet, hvem der ejer funktionen efter lanceringen.
Frigiv gradvist. Start med få kunder, se på tallene, og udvid derefter.
Det skal I lade være med
- At give salg en dato ud fra demoen · demoen siger meget lidt om, hvornår funktionen er klar.
- At frigive til alle på én gang · en gradvis frigivelse viser fejl, mens de endnu er små.
- At lade prototypens kode gå direkte i drift · den blev skrevet for at vise noget, og den er sjældent bygget til fejl og forbrug.
- At efterlade funktionen uden ejer · når kvaliteten falder, skal nogen have det som sin opgave.
Det skal I kræve af den eksterne
- ☐ En liste over, hvad der mangler, i et sprog ledelsen kan prioritere efter.
- ☐ Et realistisk bud på rækkefølgen, så salg kan få besked i tide.
- ☐ Klare kriterier for, hvornår funktionen må gå videre til flere kunder.
- ☐ En aftale om ejerskab mellem produkt, udvikling og support.
Senest gennemgået: november 2026.
Næste skridt
Læs også: Fra AI-bygget prototype til produkt · Når salg lover det, udviklingen ikke kan holde
→ Kontakt · Tlf. 70 13 63 23 · Ekstern CTO hos Nielco IT
