Lov å feile? Produktutvikling i en sektor som ikke har råd til det

Friksjonen

Build, Measure, Learn. Tre ord som har definert hvordan tech-selskaper bygger produkter de siste femten årene. Ship tidlig. Lær av feil. Iterer. Det som ikke funker, fikser du i neste runde.

Det er en elegant metodikk. Den har ett problem: den forutsetter at det er lov å feile.

I offentlig sektor er det ikke alltid det.

Når feil har konsekvenser

En feil i en forbrukerapp betyr en dårlig brukeropplevelse. Kanskje en sur anmeldelse. Kunden bytter til en konkurrent.

En feil i offentlig saksbehandling kan bety at en innbygger ikke får rettighetene sine ivaretatt. At et vedtak mangler begrunnelse. At noen mister en klagerett de hadde krav på. At journalføringsplikten ikke overholdes, og at dokumenter forsvinner fra offentlighetens innsyn.

Det er ikke det samme som en bug i en handlekurv.

Og likevel: vi mener at iterativ produktutvikling er den eneste måten å bygge noe som faktisk fungerer for fagpersonene som skal bruke det. Alternativet — lange spesifikasjonsfaser, vanntette kravdokumenter, tre år fra idé til lansering — gir ikke bedre resultater. Det gir bare dyrere feil.

Så hvordan navigerer man dette? Ærlig talt: vi vet ikke helt. Men vi har begynt å tenke systematisk om det.

Tre soner med ulikt rom for feil

Det vi har oppdaget, er at «rom for feil» ikke er ett spørsmål. Det er minst tre:

Brukeropplevelse og arbeidsflyt

Her er det rom for å feile. Mye, faktisk.

Hvilken rekkefølge bør feltene komme i? Hva skal være synlig med én gang, og hva kan ligge bak et klikk? Hvordan presenterer vi et sammendrag av en sak? Hvor lang bør en AI-generert tekst være?

Alt dette er designvalg som kan testes, endres og forbedres uten at noens rettigheter blir berørt. Hvis vi lager et grensesnitt som er forvirrende, er konsekvensen at saksbehandleren bruker lenger tid. Det er dumt, men det er ikke farlig. Vi kan fikse det neste uke.

Det er her Build, Measure, Learn fungerer best. Korte sykluser, hyppig testing med ekte fagpersoner, rask iterasjon. Vi observerer hvordan saksbehandlere bruker verktøyet, og vi justerer.

Etterrettelig bruk — vedtak, begrunnelse og innsyn

Her krymper rommet for feil dramatisk.

Forvaltningsloven krever at vedtak begrunnes (§ 24-25). Offentlighetsloven krever journalføring (§ 10) og innsyn (§ 3). Parten skal underrettes (§ 27) og informeres om klagerett (§ 28). Sektorlover stiller ytterligere krav — opplæringsloven krever at barnets beste vurderes, barnehageloven regulerer opptak og prioritering.

Når AI genererer et vedtaksforslag, og saksbehandleren godkjenner det — er begrunnelsen tilstrekkelig? Er alle fakta i saken vurdert mot de riktige vilkårene? Er klageinformasjonen korrekt? Er vedtaket journalført i henhold til arkivkravene?

Her kan vi ikke «shippe og se hva som skjer». En mangelfull begrunnelse er ikke en UX-feil. Det er en rettssikkerhetsfeil.

Det betyr ikke at vi unngår å bygge denne funksjonaliteten. Men det betyr at vi tester annerledes. Vi evaluerer mot regelverket, ikke bare mot brukeropplevelsen. Vi lar fagpersoner — saksbehandlere som kjenner lovverket — vurdere kvaliteten på AI-genererte forslag. Og vi bygger menneske-i-loopen som en arkitektonisk forutsetning, ikke som en avkrysningsboks.

Feiling er fortsatt en del av syklusen. Men konsekvensene av feil begrenses ved at en kvalifisert fagperson alltid vurderer og godkjenner.

Etterrettelig implementering — systemkrav, kundekrav og leverandørkrav

Og så er det det tredje laget: kravene som avgjør om kunden i det hele tatt kan ta løsningen i bruk.

GDPR krever databehandleravtaler, DPIA og tredjelandsvurderinger. Informasjonssikkerhet krever risikovurderinger og tekniske tiltak. KI-forordningen krever risikokategorisering, transparensdokumentasjon og menneskelig tilsyn. Arkivloven krever autentisitet og integritet.

Her er det ikke «rom for å feile» i det hele tatt. Enten har du en gyldig databehandleravtale, eller så har du det ikke. Enten er DPIA-en gjennomført, eller så er den ikke det.

Men det betyr ikke at dette arbeidet er statisk. Regelverket endrer seg. KI-forordningens tidsfrister ble justert i mars 2026. Datadelingsloven er under utarbeidelse. Og for hvert nytt regulatorisk krav må vi oppdatere dokumentasjon, vurdere konsekvenser og sikre at arkitekturen støtter det.

Det er en form for iterasjon — men med null toleranse for hull.

Hva vi egentlig gjør

Vi innrømmer gjerne at vi ikke har en perfekt formel for dette. Det vi har, er en tilnærming:

Vi skiller bevisst mellom hva som er trygt å iterere på og hva som må være riktig fra start. Brukerflater og arbeidsflyt: iterer raskt. Vedtakskvalitet og etterlevelse: test grundig, evaluer mot regelverk, involver fagpersoner. Systemkrav og dokumentasjon: ingen snarveier.

Vi bruker piloter med ekte fagpersoner — ikke fordi det høres bra ut i en presentasjon, men fordi det er den eneste måten å oppdage hvor grensene går mellom «dette kan vi prøve oss frem på» og «dette må være riktig».

Og vi dokumenterer det vi lærer. Ikke bare produktbeslutninger, men også hvor vi brant oss. Hvilke antakelser som viste seg å være feil. Hvilke etterlevelseskrav vi undervurderte.

Spørsmålet vi ikke er ferdige med

Kan du bruke startup-metodikk i en sektor som forvalter rettigheter, plikter og myndighetsutøvelse?

Vi tror svaret er ja — men bare hvis du er ærlig om hvor grensene går. Build, Measure, Learn fungerer for det som kan itereres. For det som ikke kan itereres, trenger du en annen tilnærming: forstå problemet før du bygger løsningen, involver de som kjenner konsekvensene, og bygg etterlevelse inn i arkitekturen — ikke som et lag på toppen.

Det er en vanskeligere historie å fortelle enn «vi shipper raskt og itererer». Men det er en mer ærlig en.