En maskin som leter etter besparelser i hvert enkelt prosjekt — og som ikke får lov til å godkjenne sine egne funn.
I dag bygger vi først opp hvorfor dette er vanskelig, så går vi gjennom hva systemet faktisk gjorde på et eksempel det er testet på — og til slutt spør vi dere om det er verdt å prøve på ekte tall.
De fleste leter allerede etter besparelser inne i prosjektene sine. Hvorfor er det likevel så få som klarer å hente ut potensialet?
Hvert prosjekt er vedtatt, budsjettert og i gang. Inne i hvert av dem finnes det valg som kunne vært tatt annerledes: en annen løsning, en annen dimensjonering, et tiltak som betaler seg selv.
Vi snakker ikke om å kutte prosjekter. Vi snakker om å finne pengene som allerede ligger inne i dem — og i en stor portefølje er ikke det småpenger. Noen få prosent på tvers av mange prosjekter blir titalls millioner; i store porteføljer hundrevis av millioner, og i de aller største, milliarder.
Å finne en besparelse inne i ett prosjekt er ikke magi — det er fagarbeid. Noen må sette seg inn i kostnadsoverslaget, kjenne alternativene og regne på om det lønner seg.
Problemet er ikke at det er umulig — det gjøres allerede, i de prosjektene noen rekker å se på. Problemet er at det er tidkrevende, ressurskrevende og kompetansekrevende på én gang, og derfor ikke skalerer: de som kan faget godt nok til å gjøre det, har allerede full kalender.
Spørsmålet vi stilte:
kan en maskin gjøre letearbeidet?
Ikke ta beslutningene. Ikke erstatte fagvurderingen. Bare gå gjennom prosjekt etter prosjekt og legge fram kandidatene som er verdt et menneskes tid.
Resten av presentasjonen handler om hvorfor det svaret er vanskeligere enn det høres ut — og hva vi gjorde med det.
Mennesker i begge ender, maskinen i midten. Det er ikke dømmekraften som settes ut — det er letingen. Dere bestemmer hva som er godt fagstoff å bygge på, og dere bestemmer om resultatet holder.
Behold denne figuren i bakhodet. Alt som kommer nå, er utdyping av de tre boksene.
Grønt er der dere kommer inn. Gult er regnekoden som avgjør tallet. Resten er KI-modellene. Menneskene står i begge ender, og de to gule pilene er de eneste veiene noe går tilbake.
Resten av presentasjonen er utdyping av dette kartet — hvorfor hvert steg er der, og hva som faller sammen hvis ett av dem tas bort.
En språkmodell kan skrive et forslag på sekunder. Hvorfor er ikke saken løst der?
Be en språkmodell finne besparelser i et prosjekt, og du får et velformulert notat på under et minutt. Argumentene henger sammen, språket er ryddig, kildene nevnes, og det står et tall nederst.
Dette er den delen KI er god på. Det er også den delen som lurer folk.
Beløpet i eksempelet er lite — det gjelder ett anlegg. For en stor virksomhet er 2,1 millioner ingenting; det er summen over hele porteføljen som teller. Poenget her er ikke størrelsen på tallet, men at ingen har regnet etter.
Tallet i notatet er ikke beregnet — det er formulert. Modellen har skrevet det tallet som passer best i setningen, ikke det tallet som følger av prosjektets egne mengder og priser.
Før noen tør å bruke det, må en fagperson uansett gå det etter i sømmene. Og da har vi flyttet arbeidet, ikke spart det — vi har byttet «lete selv» mot «kontrollere maskinens gjetning».
Et velformulert feil tall er farligere enn ingen tall.
Et rotete anslag blir stilt spørsmål ved. Et pent formulert anslag med kilder og forbehold glir gjennom møtet — og blir sittende i en presentasjon, i et budsjettgrunnlag, i en beslutning.
Dette er kjernen i hvorfor KI stopper ved notatet i dag. Ikke fordi maskinen er dårlig til å foreslå, men fordi ingen kan skille de gode forslagene fra de overbevisende.
Når en erfaren fagperson sier «dette realiseres erfaringsvis ikke fullt ut i drift», er det verdifull kunnskap. Den blir stående i en e-post.
Neste gang samme spørsmål dukker opp, i et annet prosjekt, må den samme personen si det samme på nytt. Kunnskapen finnes i organisasjonen — men den samler seg ikke noe sted en maskin kan bruke den.
Hvis vi ikke kan stole på maskinens tall — hvordan kan vi likevel bruke maskinen?
Maskinen får foreslå.
Den får ikke godkjenne seg selv.
Hele systemet er bygget rundt den ene regelen. Forslaget kommer fra en språkmodell, men avgjørelsen om tallet holder, tas et helt annet sted — av noe som ikke kan overtales.
De neste fire slidene viser hvordan det er satt opp.
Den første kontrollen er også en språkmodell, men med motsatt oppdrag: den skal angripe forslaget. Henger argumentet sammen? Er forutsetningene rimelige? Er noe utelatt som burde vært med?
Dette er språkarbeid, og der er en språkmodell faktisk god. Den fanger dårlig resonnement.
Men den kan ikke fange et tall som bare er feil. To modeller kan være hjertens enige om et regnestykke ingen av dem har gjort.
Den andre kontrollen er ikke en modell i det hele tatt. Det er vanlig regnekode — den typen program som gir samme svar hver gang, som ikke kan overtales av en god formulering, og som ikke har noen mening om saken.
Den tar prosjektets egne mengder og priser, regner ut hva som faktisk er oppnåelig, og sammenligner med det forslaget påstår.
Den er obligatorisk. Den kan ikke skrus av, og det finnes ingen versjon av systemet der et forslag går utenom den.
Taket er ikke en grense for hvor mye virksomheten kan spare, og ikke en budsjettbeslutning. Det er et regnestykke som gjøres per forslag, på nøyaktig de kostnadslinjene forslaget peker på: så mye er det i det hele tatt dekning for akkurat her.
En godkjennelse fra språkmodellen er ikke nok til å slippe et tall gjennom. En avvisning fra regnestykket er nok til å stoppe det. Den stiplede linjen er den som ikke bærer.
Modeller kan finne på ting. Derfor sjekkes det først at kostnadslinjene forslaget viser til faktisk står i prosjektets eget overslag, med riktige mengder og priser. Består det ikke den porten, blir det aldri regnet på.
Og systemet retter aldri opp et tall som ikke stemmer. Det avviser. En maskin som «justerer» tall til noe som passer, ville gjort hele kontrollen verdiløs.
Kontrollen regner. Men hva vet maskinen om prosjektet i utgangspunktet — og hvem bestemmer det?
En kunnskapsbase er en wiki av vanlige tekstdokumenter som lenker til hverandre — og den handler om langt mer enn tall: hva prosjektet består av, hvilke forbedringer som typisk er mulige for denne prosjekttypen, hva som er spart før, hvilket fagstoff som gjelder, og hvordan en besparelse skal måles.
Den krever ikke et eget system — den er nærmere en ryddig fagbok, redigerbar i en helt vanlig teksteditor. Eksempelet vårt har fem dokumenter; en ekte fagbase for et helt fagområde har langt flere.
De fleste KI-verktøy klipper dokumenter i biter og henter de bitene som ligner mest på spørsmålet. Da får du tekstfragmenter uten sammenheng, og modellen fyller hullene selv.
Her gjør systemet i stedet det et menneske ville gjort: begynner i innholdsfortegnelsen, åpner det som er relevant, og følger henvisningene videre. Den ser hvilket dokument som er kilden til hva, og i hvilken rekkefølge ting hører sammen.
Forskjellen merkes i kvaliteten på forslagene — og i at man kan spore hvor et resonnement kom fra. Med hundrevis av dokumenter i basen er det dessuten det eneste som er praktisk mulig: ingen leser alt, verken folk eller maskiner.
Kunnskapsbasen vi har kjørt metoden mot handler om veglys på en fylkesvei, og består av fem dokumenter:
Tallene er hentet fra fagkilder som Håndbok V124 og NMFV — ikke fra demo-manuset. Det står skrevet i kjøringens egen utskrift, nettopp fordi det er en påstand som skal kunne etterprøves.
Kvaliteten på kunnskapsbasen setter taket for kvaliteten på forslagene.
Dette er det viktigste å ta med seg fra hele presentasjonen. Kontrollen hindrer at et galt tall slipper gjennom — men den kan ikke få maskinen til å foreslå et klokt tiltak hvis grunnlaget er tynt, utdatert eller mangler det som betyr noe i faget.
Å bygge en god kunnskapsbase er fagarbeid, og det er dere som kan det. Det er også den delen av dette som ikke kan settes bort — verken til en leverandør eller til en modell.
Ved siden av kunnskapsbasen kan systemet kobles til fagsystemer det kan spørre mens det jobber — ikke bare tall som priser og målt forbruk, men også anleggs- og prosjektregistre og dokumentarkiver med tidligere vurderinger. Koblingen bruker en åpen standard som stadig flere systemer støtter (MCP).
Uten oppsett gjøres ingen slike oppslag i det hele tatt. Det er ikke en innstilling man glemmer å skru av — det er utgangspunktet.
Dette er tekniske forutsetninger, ikke en personvernvurdering. Den som tar systemet i bruk, eier fortsatt sin egen risiko- og personvernvurdering — rammeverket gir bare grunnlaget for å kunne gjøre den.
Fagstoffet som gjelder alle vegprosjekter skrives én gang og gjenbrukes. Det som er spesielt for anlegget — mengder, priser, lokale forhold — bor i prosjektets egen base.
Det betyr at arbeidet med å bygge fagbasene betaler seg ned over mange prosjekter, mens jobben per nytt prosjekt blir liten.
Dette er ikke ett oppsett for hele etaten. Hvert prosjekt, eller hver prosjekttype, trenger sine egne valg — og de valgene er faglige, ikke tekniske:
Dette er den delen av en innføring som koster arbeid — og som avgjør om resultatet blir nyttig. Det er verdt å planlegge for, ikke oppdage underveis.
Slik henger delene sammen — og slik gikk det, steg for steg, på eksempelet metoden er testet på.
Fire lag, og pilen tilbake. Grunnlaget mates av mennesker, modellene jobber i midten, regnekoden avgjør tallet, og fagpersonen avgjør om resultatet er verdt å beholde.
Drøftingen er satt opp som en gruppesamtale mellom agenter. I dag kjører den med to roller — én som foreslår og én som utfordrer — men flere roller kan delta i samme samtale, for eksempel en egen som ser på risiko eller på gjennomførbarhet.
Rollene settes opp på forhånd — systemet velger dem ikke selv. Hvem som deltar, og hvilken modell hver rolle bruker, er innstillinger, ikke noe som må programmeres om. Det gjør at man kan bruke den dyre modellen der den betyr mest: på kritikken.
En rimelig, rask modell holder — den skal produsere kandidater, ikke felle dommen. For eksempel gpt-5-mini eller gpt-4.1-mini.
Her lønner det seg med en tung resonneringsmodell som finner hull i argumentet. For eksempel o3 eller gpt-5.
Da kan hele kjeden kjøre på åpne modeller lokalt, for eksempel gpt-oss-familien — samme oppsett, ingen data ut.
Rammeverket har også en variant der laget settes sammen underveis av systemet selv, men den er merket eksperimentell — og et lag som varierer fra kjøring til kjøring gir verken forutsigbar kostnad eller sammenlignbare resultater. Modellnavnene over er eksempler fra Microsoft Foundrys katalog, ikke et fastsatt oppsett; de kan byttes uten at noe annet endres.
De åtte stegene fra kartet i starten, nå med tallene fra kjøringen på veglys-eksempelet.
Vi har kjørt systemet på ett veglysprosjekt: utskifting av eldre armaturer langs en fylkesvei. Kjøringen tar under tre sekunder og skriver ut hva den gjør underveis — den utskriften er tallene på de neste slidene hentet fra.
Det ene å merke seg: maskinen legger fram et forslag, den andre modellen godkjenner begrunnelsen — og så avviser regnestykket det likevel.
Deretter kjøres det samme prosjektet én gang til, etter at en fagperson har sagt sitt. Da viser det seg om vurderingen faktisk kom fram.
Slik leses figuren. Øverst står maskinens påstand. I midten står taket — så mye finner regnestykket dekning for i akkurat de kostnadslinjene forslaget peker på. Påstanden lå over taket, altså krevde den penger anlegget ikke kan gi, og ble avvist. Nederst står det maskinen fikk godkjent på neste forsøk.
Taket er altså ikke en grense for hvor mye dere kan spare. Det regnes ut på nytt for hvert eneste forslag, og gjelder bare de linjene det forslaget rører.
Det er ikke en svakhet ved eksempelet.
Det er produktet.
Vi viser med vilje en kjøring der maskinen tar feil først. Et system som alltid får rett i første forsøk, har ingen kontroll — det har bare flaks, og du vet ikke hvilken av delene du ser.
Og tallene i eksempelet er små med vilje: ett anlegg, én kostnadslinje. I en portefølje er det summen over mange prosjekter som betyr noe — og det er nettopp derfor det er farlig hvis tallene ikke er kontrollert.
Verdien ligger i at avvisningen skjer før tallet når et menneske, ikke etter.
Avvisningen sendes tilbake til maskinen som en begrunnelse, ikke som et blankt nei. Den får vite hvorfor tallet ikke holdt, og kan foreslå noe mer nøkternt.
Men forsøkene er tellet. Systemet får ikke holde på til noe glir gjennom. Det er forskjellen på en kontroll og en formalitet — og det er også det som gjør at kostnaden ved en kjøring er kjent på forhånd.
Hvor kommer dere inn — og hva skjer med vurderingen dere avgir?
Kunnskapsbasen systemet leser fra, er stengt for maskinens egne svar. Et forslag blir ikke til «kunnskap» fordi maskinen laget det — det må gjennom en fagperson først.
Grunnen er at et system som lærer av seg selv, driver av gårde. Det begynner å bekrefte sine egne antakelser, og etter noen runder er det umulig å se hvor det gikk galt.
Porten inn er derfor stengt som standard, og bare en menneskelig godkjennelse åpner den.
Første kjøring startet med tom erfaringsbase — null tidligere vurderinger. Det er med vilje: uten den kontrollen kunne vi ikke skille «systemet lærte noe» fra «det lå der fra før».
Læringen endret ikke svaret.
Den endret grunnlaget svaret ble formet på.
Andre kjøring landet på samme tiltak til samme beløp. Det kan se ut som ingenting skjedde — men forskjellen er at fagpersonens forbehold nå var med da forslaget ble formet, uten at noen måtte si det på nytt.
Over tid er det dette som er poenget: hver vurdering dere avgir, blir stående og virker på neste prosjekt.
Hva har dere egentlig sett i dag — og hva har dere ikke sett?
Det var ingen levende språkmodell involvert i kjøringen. Den viser at maskineriet virker — ikke at en modell ville foreslått nettopp dette. Grunnen er nøktern: modellkjøringer koster penger, og dette er bygget uten budsjett.
Et menneske har skrevet den. Det finnes en vei for å hente eksterne kilder inn i formatet automatisk, og å ta den i bruk for nye fagområder står for tur.
Ingen pilot har målt dem i drift. 445 500 kroner er hva beregningen gir for et eksempel — ikke en besparelse noen har realisert. Ingen bør sitere beløpet som en oppnådd gevinst.
Grunnregelen systemet er bygget på, er at det ikke får påstå mer enn det gjør. En demo som overselger, bryter med akkurat det den demonstrerer — derfor står disse tre like tydelig som resten.
Koden er åpen og fritt tilgjengelig. Ingen lisenskostnad i selve rammeverket, og ingen binding til én leverandør.
Hva ber vi om — og hva trenger vi fra dere i dag?
Vi ber om å få prøve metoden på ekte tall, én gang.
Å be om finansiering av et program før metoden har møtt ekte prosjektdata, ville vært å be om tillit vi ikke har målt oss fram til.
Det er nøyaktig den feilen systemet selv er bygget for å unngå — så vi kan vanskelig gjøre den her.
Det er fem ting som må på plass før en kjøring kan gjøres på ekte tall. Det er verdt å vite at bare den første er ren teknikk:
Punkt 2 og 5 kan ikke settes bort — de krever fagfolk som kjenner området. Punkt 1, 3 og 4 er oppsett som gjøres én gang og gjenbrukes.
Dere er de eneste i rommet som kan avgjøre det som betyr noe her. Så vi ber dere dømme den, på tre spørsmål:
Et ærlig nei på noen av disse er et nyttigere utfall i dag enn en høflig ja.
En metode for å vurdere kostnadstall har ikke troverdighet fordi den er teknisk velbygget. Den har troverdighet når fagfolk med ansvar sier at den regner riktig.
Det er derfor vi står her, og ikke hos budsjettsiden.