Et rammeverk som leter etter kostnadsbesparelser inne i hvert prosjekt — der ingen besparelse er godkjent før et deterministisk regnestykke har fått avvise den, og der din fagvurdering blir varig kunnskap i systemet. Dette underlaget er skrevet for deg som kan faget, ikke maskineriet, og som skal kunne svare for dette overfor dem som sitter på budsjettet.
Det finnes mange verktøy som kan foreslå kostnadskutt. Problemet i en offentlig etat er ikke å få forslag — det er å vite hvilke av dem som tåler å bli lagt fram. Dette systemet er bygget rundt en kontroll som kan avvise systemets eget beste forslag, og som gjør det uten å spørre modellen om lov.
I demoen skjer nettopp det: forslaget påstår 2,1 millioner i besparelse, kontrollen regner etter og avviser det, og det som til slutt godkjennes er 445 500 kroner. Det er ikke en svakhet ved demoen — det er produktet.
Kjernen er én setning: maskinen får foreslå, men den får ikke godkjenne seg selv — og kontrollen som avgjør er vanlig regnekode, ikke en språkmodell. Resten av dokumentet er belegg for den setningen, og forbeholdene i del 6 avgrenser hva den ikke betyr.
Et forslag om penger er verdiløst hvis ingen kan si om tallet holder. En språkmodell kan skrive et velformulert notat om at man sparer to millioner på å bytte armaturer. Notatet vil se riktig ut, argumentene vil henge sammen, og kildene vil bli nevnt. Det som mangler er den ene tingen en etat trenger før tallet kan brukes: noen som har regnet etter, uavhengig av den som foreslo.
Det er derfor KI stopper ved notatet i dag. Forslaget må uansett gjennom en manuell fagvurdering før noen tør å bruke det, og da har man flyttet arbeid, ikke spart det. Verre: et flytende formulert feilaktig tall er farligere enn ingen tall, fordi det er vanskeligere å avvise i et møte.
Og det andre problemet: fagvurderingen forsvinner. Når en erfaren fagperson sier «dette realiseres erfaringsvis ikke fullt ut i drift», blir det stående i en e-post eller i et referat. Neste gang samme spørsmål dukker opp, i et annet prosjekt, må vedkommende si det på nytt. Kunnskapen finnes i organisasjonen, men den akkumulerer ikke noe sted et system kan bruke den.
Systemet setter to helt ulike kontroller på hvert forslag, og det er avgjørende at de er ulike:
Når de er uenige, vinner den som regner. Det er hele arkitekturen i én setning. En godkjennelse fra språkmodellen er ikke nok til å slippe et tall gjennom; en avvisning fra regnestykket er nok til å stoppe det.
Kontrollen gjør dessuten én ting til, før den i det hele tatt begynner å regne: den sjekker at kostnadslinjene forslaget viser til, finnes i prosjektet, og at mengdene og enhetsprisene stemmer med det prosjektet faktisk har oppgitt. Et oppdiktet tall kommer altså aldri fram til beregningen. Og systemet retter ikke opp — det avviser. Å la maskinen «korrigere» et tall til noe som passer, ville vært den ene tingen som gjorde hele kontrollen verdiløs.
Demoen kjører på under tre sekunder og viser ett prosjekt: utskifting av veglysarmaturer på en fylkesvei. Den går gjennom åtte steg, men for å gjenfortelle den holder det med fire bevegelser.
Systemet navigerer seg gjennom en kunnskapsbase om prosjektet — fagkilder, tidligere tiltak, metodebeskrivelser. Det er verdt å merke seg at det navigerer: det følger lenker mellom dokumentene slik et menneske ville gjort, i stedet for å klippe ut tekstbiter som ligner på søkeordene.
Legg merke til linja som sier «tidligere dommer hentet for kandidaten: 0». Første kjøring skjer mot en tom erfaringsbase, med vilje. Det er kontrollen som gjør at vi senere kan bevise at læringen faktisk skjedde, og ikke bare lå der fra før.
Forslaget kommer med parametere og kostnadslinjer: bytte 2 500 eldre armaturer, påstått besparelse 2 100 000 kroner. En andre agent går løs på begrunnelsen og konkluderer med at resonnementet holder.
På dette punktet ville de fleste KI-verktøy vært ferdige. Her er det halvveis.
Den deterministiske kontrollen regner, og avviser:
Avvisningen sendes tilbake til forslagsstilleren som en begrunnelse, ikke som et blankt nei — men forsøkene er tellet og begrenset. Systemet får ikke lov til å prøve i det uendelige til noe glir gjennom. Det er forskjellen på en kontroll og en formalitet.
Setningen som bærer det hele: den ene kontrollen godkjente resonnementet, den andre avviste tallet — og det er den som regner som blokkerer.
En fagekspert vurderer utfallet og godkjenner det — men med en korreksjon: i drift realiseres erfaringsvis rundt 79 % av en slik beregnet besparelse. Den vurderingen løftes inn i kunnskapsbasen.
Så kjøres det samme prosjektet én gang til. Nå står det 3 tidligere dommer i stedet for 0, og fagpersonens korreksjon er med i grunnlaget når neste forslag formes. Utfallet blir det samme tiltaket til samme beløp — og det er riktig og verdt å si høyt: læringen endret ikke svaret her, den endret grunnlaget svaret ble formet på.
Mennesker er inne i begge ender av kjeden, og bevisst ikke i midten. Dere lager kunnskapsgrunnlaget systemet leser, og dere dømmer utfallet når maskinen er ferdig. Grovarbeidet i mellom — å gå gjennom prosjekt etter prosjekt og lete etter kandidater — er det maskinen gjør. Det er ikke dømmekraften som settes ut; det er letingen.
Vurderingen kan avgis når det passer deg. Systemet venter ikke med åpen skjerm. Du kan legge svaret ditt i en innboks dager etter kjøringen, i ditt eget fagspråk, og neste kjøring plukker det opp. Demoen viser begge tidsskalaene: en vurdering avgitt underveis, og et driftsnotat som kom etterpå.
Bare det et menneske har godkjent, blir varig kunnskap. Porten inn til kunnskapsbasen er stengt for alt annet: rå maskinoutput kommer aldri inn. Det er den mekanismen som hindrer at systemet over tid lærer av seg selv og driver av gårde.
Fagpersonenes egen gjennomgang av hva dette betyr for dem, ligger i det andre underlaget til denne demoen — «Fagfolk dømmer. Maskinen gjør grovarbeidet.»
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 — så disse tre står like tydelig som resten.
Agentenes svar i demoen er skriptet — det er ingen levende språkmodell i rommet.Det som demonstreres er at dataflyten virker, at den deterministiske ryggraden faktisk blokkerer, og at læringssløyfa lukkes. Det som ikke demonstreres, er at en levende modell ville produsert nettopp dette forslaget. Grunnen er nøktern: modellkjøringer koster penger, og dette er utviklet uten budsjett. Selve rammeverket er bygget for å kjøre mot ekte modeller, og gjør det — det er demoen som er skrudd av, ikke koden.
Kunnskapsbasen i demoen er laget for hånd.Et menneske har skrevet den. Det finnes en vei for å hente eksterne kilder inn i formatet — og den skanner nå innholdet for manipulert kildetekst før det skrives — men eksempelet her gikk ikke gjennom den, og den generiske «fabrikken» som skal produsere slike baser for vilkårlige fagområder, er bevisst ikke bygget ennå.
Tallene er modellerte, ikke målte.⚠️ Ingen pilot har validert dem i drift. 445 500 kroner er hva beregningen gir for et syntetisk eksempel med oppgitte forutsetninger — det er ikke en besparelse noen har realisert. Ingen bør sitere et kronebeløp fra denne demoen som en oppnådd gevinst. Det demoen viser, er at metoden avviser det den ikke kan forsvare; hva den er verdt i kroner, er nettopp det en pilot skal svare på.
| Område | Status | Hva det betyr |
|---|---|---|
| Hele kjeden fra kontekst til lagret dom | Bygget | Alle åtte steg er koblet sammen og kjører ende til ende. Det er dette demoen viser. |
| Den deterministiske kontrollen | Bygget | Obligatorisk og blokkerende — kan ikke slås av eller gjøres til en valgfri tilleggsmodul. |
| Læring fra fagvurderinger | Bygget | Begge tidsskalaer: vurdering avgitt underveis, og vurdering avgitt dager etterpå. |
| Kodekvalitet | 810 tester | 810 automatiske tester går grønt, 4 er hoppet over. Målt i dag på den versjonen som demonstreres. |
| Kjøring mot ekte språkmodell | Ikke prøvd i skala | Rammeverket støtter det (Azure og lokal profil), men er ikke kjørt i omfang — det koster penger vi ikke har brukt. |
| Fabrikk for kunnskapsbaser | Bevisst utsatt | Kunnskapsbaser lages for hånd i dag. Å automatisere det er et eget prosjekt. |
| Pilot på ekte prosjektdata | Ikke gjort | Dette er hovedhullet, og det er dette del 8 handler om. |
Koden er åpen og fritt tilgjengelig (MIT-lisens), bygget på Microsofts Agent Framework. Det er ingen leverandørbinding og ingen lisenskostnad i selve rammeverket.
Vi ber ikke om en budsjettpost. Vi ber om en beslutning om å prøve metoden på ekte tall, én gang, i avgrenset form.
Det er den ærlige bestillingen på dette stadiet. Å 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 ennå — og det er den samme feilen systemet selv er bygget for å unngå.
Finner metoden besparelser i ekte prosjekter som fagfolk faktisk godkjenner — og hvor mange av maskinens forslag blir avvist av kontrollen underveis? Begge tallene er interessante. Et system som aldri avviser noe, er ikke et system som har kontrollert noe.
Dere er de eneste i rommet som kan avgjøre det som betyr noe her, og det er verdt å si rett ut: vi ber dere gjøre mot denne metoden nøyaktig det systemet ber dere gjøre mot hvert enkelt forslag. Døm den. Tre spørsmål, og et ærlig nei på noen av dem er et nyttigere utfall enn en høflig ja:
Sier dere ja til det tredje, er det den anbefalingen som skal videre til budsjettsiden — fra dere, ikke fra teknologimiljøet. 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.
| Spørsmål | Svar |
|---|---|
| Er dette en ekte KI-modell? | Ikke i demoen — agentsvarene er skriptet, og det står i åpningsbildet. Det som er ekte er dataflyten, den deterministiske kontrollen og at læringen faktisk går gjennom fil. |
| Hva hvis modellen finner på et tall? | Kontrollen avstemmer hver kostnadslinje mot prosjektets erklærte kostnadsgrunnlag før beregningen i det hele tatt starter. En ukjent kostnadskode, eller en mengde som ikke stemmer, blir avvist. Systemet retter ikke opp — det avviser. |
| Erstatter dette fagfolk? | Nei. Mennesker lager grunnlaget og dømmer utfallet. Maskinen gjør letearbeidet i mellom. |
| Hvorfor viste første kjøring null tidligere erfaringer? | Med vilje — første kjøring går mot tom erfaringsbase. Uten den kontrollen kunne man ikke skille «systemet lærte noe» fra «det lå der fra før». |
| Kan vi styre hva som analyseres? | Ja. En kjøring kan bestilles med en oppdragsfil der du skriver hva den er til for og hvilke tilnærminger du vil ha vurdert. Men bestillingen styrer hva som vurderes, aldri hva som godkjennes — kontrollen gjelder uendret. Det er ikke vist i denne demoen. |
| Hva koster det å bruke? | Rammeverket er åpen kildekode uten lisenskostnad. Driftskostnaden er modellbruk, og den har innebygde tak. ⚠️ Konkret beløp avhenger av omfang og er ikke estimert. |
| Går dataene våre ut av huset? | Det bestemmer den som setter det opp. Rammeverket kan kjøre helt lokalt, og det gjør ingen nettverkskall som ikke er konfigurert eksplisitt. Personvernvurdering og risikovurdering tilhører den som tar systemet i bruk — det er bevisst ikke bygget inn påstander om compliance. |
| Kan den kjøre en hel portefølje? | Biblioteket har porteføljekjøring med globalt kostnadstak. Denne demoen kjører ett prosjekt, og porteføljestien er ikke prøvekjørt denne uka — ikke lov bort en live demonstrasjon av den. |
Hver tallpåstand over er målt, ikke gjengitt fra hukommelsen. Dette er kildene, slik at den som blir utfordret kan svare presist.
| Påstand | Kilde | Status |
|---|---|---|
| 2 100 000 påstått · 1 769 915 grense · 445 500 godkjent | Det innsjekkede demo-transkriptet, linje 19, 24 og 27 | Målt |
| Realiseringsgrad 79 % (fagpersonens korreksjon) | Samme transkript, linje 32 og 45 | Målt |
| 3 tidligere dommer i andre kjøring, 1 fra basen + 2 lært | Samme transkript, linje 50–51 — regnet ut av kjøringen selv | Målt |
| 810 tester grønne, 4 hoppet over | uv run pytest kjørt 13.08.2026 på v1.0.0 | Målt |
| Demoen kjører på under 3 sekunder | Målt ved generalprøve 12.08.2026 | Målt |
| Versjon v1.0.0 satt og publisert | git describe og oppslag mot server, begge 13.08.2026 | Målt |
| Kostnaden ved en pilot | Ingen — omfanget er ikke valgt ennå | Ikke estimert |
| Gevinst i kroner ved bruk i etaten | Ingen — ingen pilot har kjørt | Ikke målt |
De to nederste radene er de viktigste i tabellen. At de står der tomme, er ikke en mangel ved dokumentet — det er grunnen til at bestillingen i del 8 er en pilot og ikke et program.