KI-agenter og copiloterHafsteinn Runarsson · AI Konsulent25 Aug 2026 · 11 min

KI i offentlig sektor: fra pilot til trygg produksjon

En KI-demo kan se overbevisende ut etter få dager. Den sier likevel lite om hvordan løsningen håndterer personopplysninger, svake svar, endringer i datagrunnlaget eller en mandag morgen med mange samtidige brukere.

For kommuner og etater er derfor ikke målet å få en modell til å svare. Målet er å forbedre en avgrenset tjeneste eller arbeidsprosess uten å miste kontroll over kvalitet, ansvar og innsyn. Det krever produktarbeid, teknisk drift og tydelige beslutningsporter.

Denne guiden viser en praktisk vei fra idé til produksjon for KI i offentlig sektor.

Start med oppgaven, ikke modellen

Et godt KI-prosjekt begynner med en konkret flaskehals. Beskriv hvem som gjør jobben i dag, hvor i prosessen tiden går, hvilke feil som er mest alvorlige, og hva som må bli bedre for at investeringen skal være verdt det.

Et svakt mål er «å ta i bruk generativ KI». Et bedre mål beskriver en bestemt arbeidsflyt, for eksempel å hjelpe saksbehandlere med å finne relevant informasjon i godkjente kilder eller å sortere innkommende dokumenter før en medarbeider vurderer dem.

Avklar dette før dere velger teknologi:

• Hvem eier tjenesten og resultatet?
• Hvilken del av prosessen skal endres?
• Hvem påvirkes hvis løsningen tar feil?
• Hvilke handlinger kan bare utføres etter menneskelig godkjenning?
• Hvordan måler dere kvalitet før og etter piloten?
• Hva er kriteriene for å stoppe prosjektet?

Denne avgrensningen gjør det mulig å sammenligne en KI-løsning med dagens arbeidsmåte. Uten et målbart utgangspunkt blir en pilot fort vurdert etter hvor imponerende den virker, ikke etter om den løser oppgaven.

Bruksområder som egner seg for en første pilot

Den første piloten bør ha tydelige grenser, tilgjengelig fagkompetanse og et resultat som kan kontrolleres. Oppgaver med store konsekvenser, uklart ansvar eller handlinger som ikke kan reverseres, bør ikke være startpunktet.

Intern kunnskapsassistent

En intern assistent kan hjelpe ansatte med å finne frem i godkjente rutiner, veiledere og fagnotater. Løsningen bør vise hvilket underlag svaret bygger på, skille mellom funn og forslag, og sende usikre spørsmål videre til en fagperson.

Klargjøring av dokumenter

KI kan prøves som støtte for klassifisering, oppsummering eller uttrekk av informasjon. Resultatet går videre til en medarbeider som kontrollerer det før det brukes i saksbehandling eller kommunikasjon.

Copilot for saksbehandlere

En copilot kan lage utkast, foreslå neste steg eller samle relevant kontekst. Den bør ikke skjule hvem som godkjente sluttresultatet. Fagpersonen må kunne endre, forkaste og begrunne avgjørelsen.

Veiledning med tydelig overgang til menneske

En digital veileder kan svare på avgrensede spørsmål og hjelpe brukeren videre. Den trenger klare grenser for hva den ikke skal svare på, og en synlig vei til menneskelig hjelp når saken faller utenfor dem.

Agent for en begrenset arbeidsflyt

En KI-agent kan hente informasjon og forberede en handling på tvers av systemer. I en første pilot bør selve handlingen ligge bak en godkjenningsport. Agenten foreslår; en navngitt rolle godkjenner.

Bruk et scorekort før dere prioriterer

Vurder hvert forslag med det samme scorekortet. Det gjør prioriteringen mindre avhengig av hvem som presenterer ideen best.

| Område | Spørsmål | Et godt tegn | | --- | --- | --- | | Tjenesteverdi | Hvilket problem løses for ansatte eller innbyggere? | Effekten kan observeres i én konkret prosess | | Datagrunnlag | Finnes relevant, oppdatert og lovlig tilgjengelig informasjon? | Kildene har en eier og en kjent oppdateringsrutine | | Kontrollerbarhet | Kan en fagperson kontrollere resultatet? | Feil kan oppdages før de får konsekvenser | | Integrasjoner | Hvilke systemer må løsningen lese fra eller skrive til? | Piloten kan starte med få, avgrensede tilganger | | Risiko | Hva er det verste som kan skje ved feil bruk eller feil svar? | Risikoen kan reduseres med grenser og godkjenning | | Drift | Hvem følger opp kvalitet, hendelser og endringer? | En tjenesteeier og et driftsteam er navngitt | | Skalering | Kan løsningen forvaltes etter piloten? | Kostnader, kompetanse og eierskap er synlige |

Velg ikke bare ideen med høyest forventet gevinst. Velg den beste kombinasjonen av tjenesteverdi, læring og kontroll.

Arkitekturen må gjøre grensene synlige

En produksjonsklar løsning er mer enn en språkmodell. Tegn arkitekturen som en arbeidsflyt der data, beslutninger og ansvar kan følges.

En nyttig inndeling er:

1. Brukerflate og arbeidsflyt. Hvor starter oppgaven, og hvordan ser brukeren status, kilder og neste steg?
2. Godkjente datakilder. Hvilke dokumenter og registre kan løsningen bruke, hvem eier dem, og hvordan oppdateres de?
3. Modell eller agent. Hvilke oppgaver utfører den, og hvilke spørsmål eller handlinger ligger utenfor mandatet?
4. Verktøy og integrasjoner. Hvilke systemer kan løsningen lese fra, og hvilke handlinger kan den foreslå eller utføre?
5. Kontroller. Hvor ligger tilgangsstyring, validering, godkjenning og stoppmekanismer?
6. Logging og observasjon. Hvilke hendelser må kunne undersøkes uten at logger samler mer informasjon enn formålet krever?

Tilgangene bør følge oppgaven. En assistent som bare skal finne informasjon, trenger ikke skrivetilgang. En agent som klargjør en handling, trenger ikke nødvendigvis lov til å fullføre den. Smale tilganger gjør både testing og hendelseshåndtering enklere.

Personvern, sikkerhet og transparens inn i designet

Disse vurderingene bør skje før en leverandør eller modell får tilgang til reelle data. Samle fagansvarlig, personvern, informasjonssikkerhet, arkitektur og tjenesteeier rundt den samme arbeidsflyten. Da vurderer teamet den faktiske bruken, ikke bare et generelt verktøy.

Dokumenter blant annet:

• hvilket formål løsningen har
• hvilke datakategorier som brukes
• hvor data sendes og lagres
• hvem som kan se spørsmål, svar og logger
• hvordan brukere får vite at KI inngår
• hvordan en avgjørelse eller anbefaling kan ettergås
• hva som skjer ved mistanke om feil eller uønsket tilgang
• når løsningen skal stoppe og be om menneskelig vurdering

Transparens må være forståelig i selve tjenesten. Brukeren bør kunne se hva løsningen gjør, hva den ikke gjør, og hvordan man får hjelp. Interne team trenger i tillegg sporbarhet nok til å undersøke et avvik.

Menneskelig kontroll må være en funksjon

Menneskelig kontroll fungerer dårlig som en setning i et styringsdokument hvis ingen vet hvem kontrolløren er eller hva personen skal vurdere. Bygg kontrollen inn i grensesnittet og arbeidsflyten.

Definer:

• hvilken rolle som godkjenner
• hvilket grunnlag godkjenneren får se
• hvilke usikkerhetssignaler som utløser kontroll
• hvilke handlinger som aldri kan automatiseres
• hvor avviste forslag og begrunnelser registreres
• hvem som kan stanse løsningen

En god godkjenningsport reduserer ikke mennesket til en knappetrykker. Den gir nok kontekst til å vurdere forslaget og gjør det enkelt å rette eller avvise.

Evaluer systemet, ikke bare enkeltsvar

En håndfull vellykkede samtaler er ikke en kvalitetstest. Lag et testsett som speiler oppgavene, språkbruken, grensetilfellene og de alvorlige feilene tjenesten kan møte. Fageksperter bør være med på å definere forventet resultat og hva som teller som en uakseptabel feil.

Test minst disse dimensjonene:

• Faglig kvalitet: Er svaret eller forslaget korrekt nok for den avgrensede oppgaven?
• Kildebruk: Holder løsningen seg til godkjent underlag, og gjør den grunnlaget synlig?
• Fullstendighet: Mangler kritisk informasjon selv om formuleringen høres trygg ut?
• Avgrensning: Avviser eller eskalerer løsningen oppgaver den ikke skal håndtere?
• Tilgang: Kan den hente eller påvirke noe brukeren ikke skal ha tilgang til?
• Overlevering: Kommer saken til riktig person med nok kontekst?
• Robusthet: Holder kontrollene når spørsmål er uklare, motstridende eller formulert på uventede måter?

Fastsett tersklene før piloten evalueres. Ellers er det lett å flytte mållinjen når en demo nesten består. Kravene bør være strengest for feil med størst konsekvens.

Innkjøp som støtter drift og handlingsrom

En anskaffelse bør dekke hele levetiden til løsningen, ikke bare tilgang til en modell. Be leverandøren beskrive dataflyt, underleverandører, tilgangsstyring, logging, endringer i modeller og hvordan tjenesten kan avvikles.

Avklar også:

• hvordan kvalitet skal dokumenteres ved oppstart og etter endringer
• hvilke data og logger virksomheten kan eksportere
• hvordan sikkerhetshendelser og driftsavvik håndteres
• hvem som kan endre instruksjoner, kilder og integrasjoner
• hvordan modell- eller leverandørbytte kan gjennomføres
• hvilke vilkår som gjelder for leveranse, tilgang, eierskap og overlevering
• hvilken kompetanse som skal bli igjen hos virksomheten

Dette gir et bedre beslutningsgrunnlag for både kjøp, videreutvikling og en eventuell avslutning.

Fem porter fra pilot til produksjon

1. Problem og utgangspunkt

Beskriv dagens prosess, målet, risikoen og målemetoden. Navngi tjenesteeier og fagansvarlig. Ikke bygg før teamet kan forklare hvilken beslutning piloten skal gi grunnlag for.

2. Sandkasse med testdata

Bygg den minste arbeidsflyten som kan testes. Bruk kontrollerte data, begrens integrasjonene og opprett testsettet tidlig. Her skal teamet oppdage om ideen i det hele tatt er gjennomførbar.

3. Kontrollert pilot

La en liten, navngitt brukergruppe prøve løsningen i en reell, men avgrenset arbeidssituasjon. Samle både kvalitetsresultater og friksjon i arbeidsflyten. Registrer når brukerne retter, avviser eller går rundt løsningen.

4. Begrenset produksjon

Åpne for et definert bruksområde med klare tilgangsgrenser. Drift, overvåking, støtte og hendelseshåndtering må være på plass. Endringer i modell, instruksjoner, datakilder eller integrasjoner går gjennom en avtalt kontroll.

5. Skalering

Utvid først når løsningen består de avtalte tersklene over tid. Nye brukergrupper, datakilder og handlinger er nye risikoflater og bør vurderes som egne endringer, ikke som en automatisk fortsettelse av piloten.

Hver port bør ende med en dokumentert beslutning: fortsett, endre eller stopp.

Drift begynner før lansering

KI-kvalitet må følges opp som en del av tjenesten. Et produksjonsteam trenger en oversikt og en enkel driftsrutine for det som faktisk betyr noe i arbeidsflyten.

Følg med på:

• resultater mot testsett og kvalitetsgrenser
• avvisninger, eskaleringer og menneskelige rettelser
• feil i datakilder og integrasjoner
• svartid, kapasitet og kostnad
• endringer i bruksmønster
• sikkerhets- og personvernhendelser
• modell-, instruksjons- og dataversjoner

Lag en kort hendelsesplan: hvem varsles, hvordan stoppes løsningen, hvordan begrenses skade, og hva må testes før den åpnes igjen? Øv på planen før dere trenger den.

Roller som må være navngitt

Et tverrfaglig team trenger ikke være stort, men ansvar kan ikke være anonymt. Navngi minst:

• en tjenesteeier som eier målet og beslutningene
• en produkteier som prioriterer arbeidsflyten
• en fagansvarlig som definerer kvalitet
• ansvarlige for personvern og informasjonssikkerhet
• en teknisk eier for integrasjoner, tilgang og drift
• brukere som tester løsningen i faktisk arbeid

Leverandøren kan bygge og støtte løsningen. Virksomheten må fortsatt eie formålet, risikovurderingen og beslutningen om hvor den skal brukes.

Vanlige spørsmål om KI i offentlig sektor

Hvordan kan KI brukes i offentlig sektor?

Start med støtte til avgrensede arbeidsoppgaver: søk i godkjent kunnskap, klargjøring av dokumenter, utkast, sortering eller veiledning. Knytt hvert bruksområde til en navngitt prosess, en ansvarlig rolle og en måte å kontrollere resultatet på.

Hvilket KI-prosjekt bør en kommune eller etat starte med?

Velg en oppgave med tydelig tjenesteverdi, håndterbar risiko, tilgjengelige fagpersoner og et resultat som kan testes. Unngå å starte med den mest synlige eller mest autonome ideen bare fordi den gir den beste demoen.

Hvordan håndterer man personvern, sikkerhet og transparens?

Kartlegg formål, dataflyt, tilganger, leverandører, lagring, logging og menneskelig kontroll før løsningen får reelle data. Vis brukeren når KI inngår, og bygg en praktisk vei til innsyn, retting og menneskelig hjelp.

Hvordan evaluerer man en KI-agent?

Test hele arbeidsflyten med et faglig godkjent testsett. Mål kvalitet, kildebruk, avgrensning, tilganger, overlevering og alvorlige feil. En agent må også testes på handlingene den kan foreslå eller utføre, ikke bare på teksten den produserer.

Hvordan går man fra pilot til produksjon?

Bruk faste porter for problem, sandkasse, kontrollert pilot, begrenset produksjon og skalering. Hver port trenger dokumenterte terskler, ansvar og en beslutning om å fortsette, endre eller stoppe.

Fra god demo til forvaltbar tjeneste

KI i offentlig sektor blir nyttig når den inngår i en tjeneste som kan styres, testes og driftes. Det betyr smalt mandat, gode datagrenser, menneskelig kontroll og et team som følger kvaliteten etter lansering.

Daia bygger KI-agenter og copiloter, full-stack produkter og automasjon for produksjonsleveranser. Om dere vil avgrense en pilot eller gjøre en eksisterende løsning klar for drift, kan dere starte en samtale. Omfang, pris, tidsplan, tilgang, eierskap og overlevering avtales for hvert oppdrag.