Mange AI-piloter starter med et verktøy og leter etter et problem. En lisens kjøpes, noen ansatte får tilgang, og etter en måned spør ledelsen om bedriften har «fått effekt».
Det er vanskelig å svare fordi ingen målte utgangspunktet, ingen definerte oppgaven, og alle brukte verktøyet forskjellig.
En bedre pilot begynner med én avgrenset arbeidsflyt og ett tydelig mål.
Velg riktig pilot
Den første piloten bør være:
- Hyppig nok til at den kan testes flere ganger.
- Avgrenset med tydelig start og slutt.
- Reversibel dersom noe går galt.
- Målbar før og etter.
- Nyttig, men ikke sikkerhetskritisk.
- Mulig å kontrollere manuelt.
Gode kandidater kan være førsteutkast til møtereferat, klassifisering av innkommende henvendelser, sammenstilling av ukesrapport eller kontroll av om et dokument mangler obligatoriske felt.
Dårlige førstepiloter er autonome betalinger, endelige personalsaker og løsninger som publiserer eller sender informasjon uten kontroll.
Uke 1: Kartlegg og mål
Beskriv dagens prosess i fem til ti steg. Noter hvem som gjør hva, hvilke systemer som brukes, hvor det oppstår venting og hvilke unntak som finnes.
Mål deretter dagens:
- Volum.
- Aktiv arbeidstid.
- Total gjennomløpstid.
- Feilrate.
- Antall saker som må gjøres på nytt.
- Opplevd frustrasjon eller avbrudd.
Velg to eller tre mål. En pilot blir uklar dersom alt skal forbedres samtidig.
Eksempel:
Målet er å redusere tiden for første klassifisering av kundehenvendelser fra seks til tre minutter, uten at alvorlige feil øker og uten at AI sender svar direkte til kunden.
Uke 2: Bygg en begrenset versjon
Gi løsningen minst mulig tilgang. Bruk testdata eller anonymiserte data der det er mulig. Dersom den trenger tilgang til en mappe, start med en egen testmappe i stedet for hele dokumentarkivet.
Definer:
- Hvilke kilder AI kan lese.
- Hvilke handlinger den kan foreslå.
- Hvilke handlinger den ikke får utføre.
- Hvem som godkjenner resultatet.
- Hvor feil og testresultater registreres.
- Hvordan løsningen stoppes.
Digdir anbefaler trinnvis innføring og sentral konfigurasjon som begrenser risiko. Støttefunksjoner som tilgangsstyring, logging og varsling om sensitive data bør vurderes når de er relevante.[5]
Uke 3: Test det som går galt
En pilot bør ikke bare testes på perfekte eksempler. Bruk også saker med:
- Manglende informasjon.
- Uklare formuleringer.
- Feil filformat.
- Motstridende dokumenter.
- Uventet språk.
- Duplikater.
- Data som ikke skal behandles.
- En oppgave systemet bør avvise.
Kontroller om AI-en sier fra når den er usikker, eller om den fyller hullene med sannsynlige, men feilaktige antagelser.
Registrer resultatene i kategorier:
- Godkjent uten endring.
- Godkjent etter mindre retting.
- Krever betydelig retting.
- Feil som kunne gitt konsekvens.
- Saken burde vært sendt direkte til et menneske.
Digdirs egne forsøk viser hvorfor dette er viktig: Manuell kontroll var nødvendig, og AI-verktøy kunne både utelate sentral informasjon og hallusinere innhold.[20] [19]
Uke 4: Sammenlign og avgjør
Sammenlign piloten med utgangspunktet. Ikke vurder bare om løsningen virket i en demonstrasjon.
Spør:
- Ble oppgaven raskere når kontrolltiden regnes med?
- Ble kvaliteten bedre eller dårligere?
- Hvilke saker måtte fortsatt behandles manuelt?
- Oppstod nye feil eller sikkerhetsproblemer?
- Var løsningen enkel nok til at ansatte faktisk brukte den?
- Hva koster drift, support og videreutvikling?
- Er gevinsten stor nok til å forsvare avhengigheten av leverandøren?
Ta én av fire beslutninger:
- Stopp: Gevinsten er for liten eller risikoen for høy.
- Endre: Problemet er riktig, men løsningen eller arbeidsflyten må justeres.
- Forleng: Datagrunnlaget er for lite til å ta en beslutning.
- Skaler: Målene er nådd, risikoen er håndterbar og noen får ansvar for drift.
NISTs AI Risk Management Framework bruker funksjonene Govern, Map, Measure og Manage. For en liten pilot kan dette oversettes til ansvar, forståelse av bruken, måling og løpende risikohåndtering.[21] [22]
Pilotkortet
Fyll ut dette før oppstart:
| Felt | Beskrivelse |
|---|---|
| Problem | Hva er tungvint eller feil i dag? |
| Prosess | Hvor begynner og slutter testen? |
| Eier | Hvem kan ta beslutninger? |
| Data | Hva får løsningen tilgang til? |
| Handling | Hva kan AI foreslå eller utføre? |
| Kontroll | Hvem godkjenner resultatet? |
| Baseline | Hvordan fungerer prosessen i dag? |
| Mål | Hva må bli bedre? |
| Stoppkriterium | Når avsluttes testen? |
| Driftsansvar | Hvem eier løsningen etter piloten? |
Neste steg i serien: AI-policy for småbedrifter: Reglene dere bør ha før ansatte deler kundedata med en chatbot og AI Act for norske småbedrifter: Hva gjelder nå – og hva bør dere forberede?.
Kilder
[5] Anskaffelse av generativ KI
[19] KI-verktøy for identifisering av digitaliseringstiltak
[20] Kunnskapsgrunnlag om digitaliseringstiltak
[21] Artificial Intelligence Risk Management Framework (AI RMF 1
