En god AI-pilot tester én arbeidsflyt, ikke hele strategien.

Start med arbeidsflyten

Ikke start med modellnavn eller verktøy. Start med hvor arbeidet stopper: innkommende henvendelser, rapporter, avvik, dokumenter, sjekklister, CRM-oppfølging eller intern kunnskap. En god pilot kan forklares på én setning.

Avklar data og tilgang tidlig

Piloten trenger realistiske eksempler, testdata, dokumenter eller systemtilgang. Hvis dataene er sensitive, må anonymisering, tilgangsstyring, logging og leverandørvalg avklares før man bygger for mye.

Bygg kontrollpunkter inn fra start

AI bør ikke få mer ansvar enn risikoen tillater. For dokumenter, rapporter, HMS, økonomi eller kundedata bør piloten ha synlige kilder, menneskelig review og klare regler for når systemet stopper.

Mål go/no-go

En pilot er vellykket når den gir et tydelig svar: bygg videre, endre scope eller stopp. Målingen bør være enkel nok til at både ledelse, brukere og teknisk team forstår hva som faktisk ble bevist.

Problem

Hva tar tid, skaper feil eller gjør at saker stopper?

Brukere

Hvem skal bruke piloten, og hvor ofte skjer arbeidsflyten?

Data

Hvilke dokumenter, systemer, bilder, e-poster eller tabeller trengs?

Risiko

Hva skjer hvis AI tar feil, og hvor må mennesker godkjenne?

Måling

Hvordan måles verdi: tid, kvalitet, feil, responstid eller dokumentasjon?

Kan alle AI-piloter gjøres på 2-6 uker?

Nei. Tidsrammen passer best når scope er smalt, data er tilgjengelig og beslutninger kan tas raskt. Større integrasjoner eller høy risiko krever mer tid.

Hva er vanligste feil i AI-piloter?

For bredt scope, uklare data, manglende måling og for lite fokus på hvordan løsningen faktisk skal brukes i drift.

Må piloten bruke generativ AI?

Nei. Noen piloter bør bruke regler, API-er og automasjon. AI bør brukes der tekst, bilder, dokumenter eller ustrukturert informasjon skaper friksjon.

Hva skjer etter piloten?

Neste steg bør være go/no-go: bygg videre, endre scope, integrer med drift eller stopp før mer tid brukes.