Fra AI-pilot til drift: Det skal være på plads før udrulning
En god demonstration er ikke det samme som en løsning i daglig drift. Få en praktisk tjekliste til kvalitet, ansvar, fejlhåndtering og overdragelse.
Partner & CTO hos Adtention
Hvad ændrer sig, når piloten bliver hverdag?
I en AI-pilot er eksperterne tæt på, eksemplerne er afgrænsede, og fejl kan ofte rettes manuelt. I drift kommer opgaverne løbende. Brugerne har forskellig erfaring, kilder ændrer sig, og en forbindelse kan være nede, netop når arbejdet haster.
Overgangen kræver derfor sin egen beslutning. En prototype viser, at en idé kan afprøves. En pilot undersøger den under afgrænsede forhold. En driftsløsning skal kunne anvendes, overvåges og vedligeholdes med et aftalt ansvar. Ingen af trinnene dokumenterer automatisk det næste.
Skriv acceptkriterier, før I kalder testen en succes
“Brugerne var glade” er nyttig feedback, men utilstrækkeligt som eneste kriterium. Beskriv, hvilke opgaver løsningen må håndtere, og hvilke resultater der kræver kontrol eller afvisning.
For en assistent, der klargør tilbudsudkast, kan kriterierne eksempelvis være, at kunden identificeres korrekt, priser hentes fra en godkendt kilde, og manglende oplysninger markeres. Afsendelse kan fortsat kræve en sælger. Det er et konstrueret eksempel på kriterier, ikke et dokumenteret kunderesultat.
Brug et testsæt med normale opgaver, undtagelser, manglende data og input, som løsningen skal afvise. Gem forventninger og faktiske resultater. Når en instruktion, integration eller model ændres, kan de samme eksempler vise, om noget er blevet dårligere.
Planlæg de fejl, som kan opstå
| Situation | En aftale, der skal være på plads |
|---|---|
| Kilden eller API’et svarer ikke | Vis en forståelig status, og send opgaven til en aftalt kø eller manuel arbejdsgang. |
| Det samme input kommer igen | Genkend opgaven, så en genkørsel ikke opretter endnu en ordre eller kladde. |
| AI mangler et nødvendigt felt | Bed om oplysningen eller stop. Udfyld ikke hullet med et sandsynligt gæt. |
| En medarbejder finder en fejl | Gør det let at melde den med et opgave-ID og relevant kontekst. |
| En ændring forringer kvaliteten | Kunne vende tilbage til en kendt version eller sætte løsningen på pause. |
Gem kun de oplysninger i logs, som er nødvendige til fejlsøgning og opfølgning. Aftal adgang og opbevaring ud fra indholdet. Det er sjældent nødvendigt, at alle brugere kan se fulde kundehenvendelser fra alle andre.
Fordel ansvar på konkrete opgaver
En driftsoverdragelse bør som minimum navngive den forretningsansvarlige, den teknisk ansvarlige og den person, der vedligeholder faglige kilder. Det kan være få personer med flere roller, men rollerne skal være tydelige.
- Forretningen ejer mål, prioritering og kriterier for anvendelse.
- Fagpersonen vurderer resultater og holder kilder og regler aktuelle.
- Teknikken håndterer integrationer, adgang, versioner og fejl.
- Brugerne følger arbejdsformen og melder de undtagelser, der ikke er dækket.
Aftal svartider og support særskilt med den ansvarlige leverandør. Et udviklingsprojekt indeholder ikke automatisk løbende overvågning, døgnsupport eller alle fremtidige ændringer.
Rul ud i et omfang, I kan følge
Begynd med en afgrænset brugergruppe eller opgavetype. Lad eventuelt løsningen køre parallelt uden at skrive til de centrale systemer, mens I sammenligner med den eksisterende behandling. Derefter kan godkendte resultater få lov at gå videre.
Følg både brug, kvalitet og samlet arbejdstid. En hurtigere AI-generering hjælper kun lidt, hvis kontrollen bliver tungere. Se også, om medarbejderne omgår løsningen, og hvorfor. Det kan være et tegn på manglende oplæring, dårlig placering i arbejdet eller en reel begrænsning.
I Kirppu-casen indgår menneskelig vurdering ved usikkerhed. Den type håndtering af undtagelser er vigtig at beskrive som en del af løsningen. Casens oplyste billedvolumen er ikke i sig selv dokumentation for en bestemt fejlprocent eller økonomisk gevinst.
Bed om en overdragelse, andre kan arbejde videre fra
En brugbar overdragelse beskriver datakilder, forbindelser, rettigheder, instruktioner, tests, kendte begrænsninger og proceduren ved fejl. Den forklarer også, hvad virksomheden selv ejer, og hvilke dele der afhænger af licenser eller tredjepartsleverandører.
Prøv at lade en anden relevant person løse en almindelig supportopgave ud fra dokumentationen. Kan vedkommende finde den rigtige kilde, se fejlstatus og kontakte den ansvarlige? Hvis alt stadig kræver udviklerens hukommelse, er overdragelsen ikke færdig.
Læs guiden til AI-integration, hvis systemforbindelserne er den største usikkerhed, og guiden til medarbejderoplæring, hvis anvendelsen halter. Everydai hjælper med AI-implementering, så test, arbejdsform og overdragelse hænger sammen.
