En pilot kan ha svært gode rammer: En ildsjel følger den tett, testmaterialet er nøye valgt, leverandøren svarer raskt, og teamet har tid til å undersøke det som går galt. I vanlig drift kan dere ikke regne med alt dette. Kundene forventer likevel at tjenesten fungerer.
Overgangen fra pilot til vanlig drift bør være en egen beslutning i ledergruppen. Dere må vite om løsningen fungerer med bemanningen, avtalene og kontrollene bedriften faktisk har.
Test tjenesten uten ildsjelen til stede
Tenk deg en hypotetisk norsk tjenestebedrift der pilotens pådriver kontrollerer hvert kundesvar KI har forberedt. Resultatene ser gode ut. Når andre medarbeidere skal ta over, vet de ikke hvilke kilder de skal bruke. Unntak hoper seg opp, og svarene venter på at ildsjelen kommer tilbake.
Resultatene er altså avhengige av én person. Før løsningen tas i vanlig bruk, ville jeg latt en annen opplært medarbeider prøve den med skriftlige rutiner og avtalt hjelp ved vanskelige saker. Test også hva som skjer ved fravær og driftsavbrudd.
Avklar hva som må være på plass før oppstart
Jeg ville bedt om svar på fem spørsmål:
- Kvalitet: Oppfyller løsningen de definerte oppgavekravene i et representativt utvalg saker, inkludert vanskelige norske språkeksempler og saker den bør avslå eller sende videre?
- Kapasitet: Kan teamet gjennomføre nødvendig kontroll ved normal og høy etterspørsel? Hvem håndterer køen av uavklarte saker?
- Kontroll: Er tilganger, databruk og leverandøravtaler avklart og fulgt opp? Er det tydelig hvem som kan endre løsningen?
- Kontinuitet: Kan tjenesten pauses og reserveløsningen brukes uten at arbeid går tapt, dobles eller sendes feil?
- Ansvar: Finnes det en ansvarlig for driften, noen medarbeiderne kan få hjelp av og et budsjett for å vedlikeholde tjenesten etter prosjektet?
En gjennomsnittlig poengsum for riktige svar sier for lite. En alvorlig feil må vurderes annerledes enn en skrivefeil. Bestem hvilke feil som er uakseptable, ut fra konsekvensene de kan få. Gode testresultater sier noe om sakene dere har testet, ikke om alle situasjoner løsningen kan møte.
Hold oversikt over hva som endres
En fungerende KI-tjeneste består av mer enn modellen. Instruksjoner, dokumentene den bruker, tilganger, søkeinnstillinger og rutiner for kontroll kan alle påvirke resultatet. Registrer oppsettet som ble brukt i godkjenningstestene, slik at senere endringer kan forstås og om mulig reverseres.
NISTs risikoprofil for generativ KI gir frivillig veiledning om å identifisere og håndtere risiko ved generativ KI. Min anbefaling er å beholde et lite utvalg representative testsaker og kjøre dem på nytt når vesentlige deler av løsningen endres. Slik kan dere oppdage om en oppdatering ødelegger noe som fungerte før. Legg til nye saker når dere finner nye typer feil, og beskytt personopplysninger og konfidensielle data i testene.
Løsningen må kunne forbedres. Men dere bør oppdage hvis en leverandøroppdatering eller et endret kildedokument fører til dårligere svar eller andre kundeløfter.
Start driften med avgrenset omfang
Utvid antall brukere, sakstyper og tillatte handlinger hver for seg der det er praktisk. Hvis alle tre endres samtidig, blir det vanskeligere å finne årsaken hvis kvaliteten faller. Velg oppfølgingsintervaller etter konsekvens og brukshyppighet. En kundetjeneste med høy aktivitet kan trenge oppfølging lenge før neste månedsmøte.
Ha en synlig kanal der ansatte kan melde usikkerhet. Blir en feilmelding møtt som motstand mot endring, kan ansatte slutte å si fra. Da mister dere muligheten til å rette opp problemene. Forklar hvem som kan stanse prosessen, og når fullmakten bør brukes.
Før reelle personopplysninger tas inn i løsningen, må relevante personvernplikter vurderes, blant annet om personvernforordningen artikkel 35 krever en vurdering av personvernkonsekvenser. Et internt oppstartsmøte kan ikke sette et lovkrav til side.
Ansvaret fortsetter når prosjektet er ferdig
Skriv ned hva løsningen er godkjent for, hvilke begrensninger som gjenstår, hvem som har ansvaret, og når dere skal følge opp. Hvis et vilkår ikke er oppfylt, gjør valget tydelig: reduser omfanget, utsett oppstart eller stopp. Ikke gjør en pilot til et permanent unntak fordi prosjektbudsjettet er brukt opp.
Bruk planen for hendelseshåndtering til å øve på feil og gevinstguiden til å teste om tjenesten forbedrer arbeidet. Begge deler må følges opp også etter at prosjektet er avsluttet.
Kilder og avgrensning
Kildene ble kontrollert 11. oktober 2026. Oppstartsvurderingen og driftseksemplet er mine anbefalinger og et hypotetisk scenario. NISTs veiledning er ikke en norsk sertifisering eller en erstatning for gjeldende lovkrav.