Tallene AI-en ikke får finne på

Hovedfunn (TL;DR)

• Språkmodeller er gode til å skrive og dårlige til å regne. I m51.ai regner de derfor ikke: hvert tall i en rapport kommer fra én av 184 deterministiske KPI-formler i en egen motor, ikke fra modellen.
• Modellen får se tall, men bare de godkjente. En allowlist avviser hvert tall i et utkast som ikke kan spores til et godkjent faktum — med egne unntaksklasser for årstall, datoer og telefonnumre, så gaten ikke slår ut på det som ikke er en ytelsespåstand.
• Deteksjon er deterministisk, formulering er modellens jobb. 16 playbooks finner problemene med regler; språkmodellen har kun rollen som avgrenset dommer over det reglene allerede fant.
• 124 automatiske regresjonssjekker kjører uten et eneste LLM-kall mot datapakker med kjent fasit, innenfor et hardt budsjett på 175 sekunder, og holder baselinen på null kritiske og null alvorlige avvik.
• Ett lag er et uavhengig orakel: det regner hovedtallene på nytt rett fra rå API-svar og sammenligner med det pipelinen kom fram til. Det er den eneste sjekken som ikke stoler på vår egen utregning.
• Gjennom 22 netter i juli har en automatisert gransking lest våre egne chat-svar og dømt dem mot en rubrikk med seks dimensjoner. 103 turer er dømt. Vi publiserer hva den fant, inkludert det som var galt.

Hvorfor tall er det vanskeligste AI gjør

Et markedsføringsteam kan leve med at en AI-generert setning er litt klosset. Det kan ikke leve med at ROAS-en i rapporten er 4,2 når den egentlig er 3,1. Det første er en redigeringsjobb. Det andre er en beslutning tatt på feil grunnlag, og i verste fall et budsjett flyttet feil vei.

Problemet er at språkmodeller er bygget for å produsere plausibel tekst, ikke korrekte tall. En modell som har sett tusenvis av rapporter vet nøyaktig hvordan en ROAS-setning ser ut, og hvilke tall som pleier å stå i den. Den har ingen intern mekanisme som skiller «tallet jeg faktisk leste i datagrunnlaget» fra «tallet som passer i denne setningen». Begge deler føles like riktige innenfra.

Derfor er «vi bruker en bedre modell» ikke et svar på hallusinerte tall. Bedre modeller hallusinerer sjeldnere, men de hallusinerer fortsatt, og de gjør det mer overbevisende. Svaret må være arkitektonisk: modellen må settes i en posisjon der den ikke kan finne på et tall, fordi den aldri var den som produserte det.

Vi har bygget seks lag rundt det prinsippet. Her er hvert av dem, og hva de faktisk fanger.

Lag 1: Modellen regner ikke

Alle KPI-er i m51.ai beregnes av KPIRegistry, en egen motor i backend som per i dag inneholder 184 registrerte KPI-formler fordelt på ti domenemoduler: Google Ads, SEO, GA4, CRO, GEO, paid social, LinkedIn, Performance Max, porteføljestyring og rapport-KPI-ene.

En formel er vanlig kode. ROAS er konverteringsverdi delt på kostnad, og ingenting annet. Den kjører før språkmodellen i det hele tatt blir spurt om noe. Når agenten senere skal skrive analysen, får den KPI-verdien ferdig utregnet, sammen med perioden den gjelder for, enheten, og hvilken råfeltsti verdien ble hentet fra.

Det betyr at ingen språkmodell utfører en divisjon i produksjonspipelinen vår. Den beskriver et regnestykke noen andre allerede har gjort. Skillet høres akademisk ut, men det er hele forskjellen: en beskrivelse kan være dårlig formulert, men den kan ikke gi feil svar på et regnestykke som er ferdig før den ble spurt.

Hvem gjør hva

Lag 2: Tall uten kilde slipper ikke ut

Lag 1 sikrer at tallene som finnes, er riktige. Det hindrer ikke at en modell skriver et tall som aldri var i datagrunnlaget i det hele tatt. Derfor har utgående innhold sin egen tall-gate.

Nyhetsbrevmodulen har den strengeste implementasjonen, og er et godt eksempel nettopp fordi den skriver kundevendt tekst som sendes på e-post uten at noen nødvendigvis leser korrektur først. Genereringen skjer i to steg — først en plan, så et utkast — og begge stegene passerer samme gate.

Modellen får en eksplisitt liste over godkjente fakta, hentet fra KPI-laget. Hvert faktum har en id. Foreslår modellen en KPI-blokk, må den referere en id som finnes i listen. Er listen tom, får den ikke lov til å lage KPI-blokken overhodet.

Deretter tokeniseres teksten, og hvert tall i utkastet holdes opp mot allowlisten. Det er her det blir interessant, for en naiv tall-gate er ubrukelig i praksis: den slår ut på årstall, datoer, klokkeslett og telefonnumre, og da lærer redaktøren seg på tre dager å ignorere den.

Gaten har derfor egne trygge klasser. Årstall mellom 1900 og 2099 vurderes i kontekst — står det «i 2026» eller «siden 2024», er det en tidsangivelse, ikke en ytelsespåstand. Telefonnumre gjenkjennes på både format og omkringliggende ord. Datoer og klokkeslett slipper gjennom. URL-er maskeres i stedet for at hele feltet forkastes, slik at et tall inne i en sporingslenke ikke feller en ellers korrekt setning.

Og det viktigste unntaket: tall kunden selv har skrevet i briefen. Skriver du «vi feiret 20 år i mai» i briefteksten, skal ikke systemet nekte å gjenta det. En egen allowlist trekkes derfor ut av briefen og gjelder både plan- og utkaststeget, token-eksakt.

Overskriftsflater — emnelinje, preheader og overskrifter — er strengere enn brødteksten. De arver kun bare tall fra briefen, ikke tall med modifikator. «20 %» kan stå i brødteksten hvis kunden skrev det; det får ikke stå i emnelinjen på samme grunnlag. En emnelinje er den mest siterte setningen i en e-post, og fortjener den strammeste gaten.

Lag 3: Reglene finner problemet, modellen forklarer det

Den vanligste måten å bygge en AI-analysemotor på er å gi modellen alle dataene og be den finne det interessante. Det gir imponerende demoer og upålitelig produksjon, fordi «finn det interessante» er nøyaktig den oppgaven der en modell har mest frihet til å konstruere et mønster som ikke er der.

Vi gjør det motsatte. m51.ai har 16 playbooks i produksjon — budsjett-pacing, søkeordsløsing, Performance Max-helse, innholdsforfall i SEO, striking distance, konverteringssporing, landingssideytelse og kreativ-helse i Meta, blant andre. Hver av dem er en deterministisk regel skrevet i et predikat-språk. Regelen kjører mot KPI-verdiene og treffer, eller treffer ikke.

Først når en regel har truffet, kobles språkmodellen inn — og da i en avgrenset dommerrolle. Den vurderer om funnet er verdt å foreslå for akkurat denne kunden, og skriver begrunnelsen. Den kan avvise et funn. Den kan ikke legge til et.

Konsekvensen er at motoren er propose-only og revisjonsbar hele veien. Et forslag kan alltid spores tilbake til regelen som utløste det, hvilken versjon av regelen som kjørte, og verdiene den traff på.

Lag 4: Et orakel som ikke stoler på oss

Alle lagene over deler en svakhet: det er vår egen kode som kontrollerer vår egen kode. Har KPIRegistry en feil i en formel, vil hvert nedstrøms lag reprodusere feilen helt lojalt.

Derfor finnes recompute-orakelet. Sjekken tar rå API-svarene fra en faktisk kjøring — ikke datapakken pipelinen bygget, men det plattformene faktisk returnerte — og regner ut hovedtallene på nytt med en uavhengig implementasjon. Så sammenligner den med det pipelinen kom fram til.

Orakelet dekker fem headline-KPI-er for ukes- og månedsrapporten, og 26 KPI-er fordelt på de fem audit-workflowene for Google Ads, SEO, paid social, CRO og GEO. Avviker de to utregningene mer enn toleransen, flagges det.

Det er den eneste sjekken i suiten som ikke bruker et eneste tall pipelinen selv har produsert, og derfor den eneste som kan fange en feil i fasiten.

Lag 5: 124 sjekker på under tre minutter

Over dette ligger en deterministisk regresjonssuite. Den kjører 124 sjekker uten et eneste LLM-kall, mot pinnede datapakker med kjent fasit, innenfor et hardt tidsbudsjett på 175 sekunder — lavt nok til at den kan stå som gate i CI på hver eneste endring.

83 av sjekkene er substratuavhengige kontrakts- og invariantsjekker. 34 krever pinnede fixturer med fasitverdier. 7 krever et ferskt snapshot fra ekte API-er.

Sjekkene håndhever ting som ikke skal kunne være sanne. En prosentvis endring kan ikke eksistere uten en forrige verdi å endre seg fra. En periode kan ikke slutte før den starter. En beskrivelse kan ikke være ordrett identisk med begrunnelsen sin. Et pengebeløp kan ikke sammenlignes på tvers av valuta uten at en kurs er brukt. Slike sjekker er kjedelige å skrive, og fanger nøyaktig den typen feil som ellers når kunden.

Baselinen står på null kritiske og null alvorlige avvik. Det er den strengeste tilstanden fila kan ha, og den er gate: bryter en endring den, blir den ikke merget.

Lag 6: Vi gransker våre egne svar hver natt

De fem første lagene handler om rapporter og generert innhold, altså flater der vi selv kontrollerer formatet. Det sjette handler om chat, der brukeren spør fritt og Nova svarer fritt. Der finnes ingen skjema å validere mot.

Løsningen er en nattlig, automatisert gransking. Hver natt hentes døgnets faktiske chat-turer fra produksjon, filtrert mot et valgt domene, og dømmes mot en versjonert rubrikk med seks dimensjoner: forankring i data, relevans, hjelpethet, tone, domenefaglig korrekthet og verktøybruk. Hvert funn skal være reproduserbart — det holder ikke å notere at et svar «virket svakt».

Per 30. juli 2026 har rutinen kjørt 22 netter i løpet av 24 døgn, og 103 turer er dømt og lagret med begrunnelse. Gjennomsnittlig forankring ligger på 7,85 av 10 på de 84 turene der dimensjonen var målbar. 20 av de 103 turene fikk minst ett defektflagg.

Det tallet må leses riktig. Utvalget er ikke tilfeldig trafikk — det er målrettet mot det domenet vi til enhver tid mistenker mest, og dommen er bevisst adversariell: granskeren er instruert til å lete etter feil, ikke til å vurdere om svaret var greit nok. 20 av 103 er derfor ikke en feilrate for plattformen. Det er utbyttet av å lete der det er mest sannsynlig å finne noe.

Hva den faktisk fant

To eksempler fra siste uke, begge fikset.

28. juli fabrikkerte et Google Ads-svar et datapunkt i en graf. Prosaen var eksakt riktig. Grafen viste 82 GA4-sesjoner for en dag der tallet var 10 — og 82 var antall Google Ads-klikk samme dag. Modellen hadde kopiert nabo-seriens verdi. Verre enn feilen i seg selv: punktet opphevet visuelt nettopp den konklusjonen svaret bygget på, som handlet om gapet mellom klikk og sesjoner. Rotårsaken var at chart-blokker ikke ble validert noe sted — verken i backend, frontend eller QA-laget. Eneste forsvar var én setning i system-prompten. Nå er det en deterministisk sjekk.

30. juli parret et svar riktig pacing-prosent med feil nevner: «136 % pacing (7 029 kr av ~5 518 kr)». 7 029 av 5 518 er 127 %, ikke 136 %. Prosenten var korrekt hentet, men tallparet leseren fikk servert, var ikke reproduserbart. Det skjedde i to av fire turer som siterte pacing, mens to søsterturer på identisk datagrunnlag fikk det riktig — altså drift, ikke en systematisk feil formel.

Rotårsaken var verdt mer enn fiksen. Verktøyet returnerte to ulike budsjettnevnere per kampanje — forventet forbruk hittil i måneden og estimert månedsbudsjett — uten å oppgi hvilken av dem prosenten var regnet fra. Modellen valgte selv, og valgte ikke alltid likt. Fiksen var ikke å be modellen skjerpe seg, men å gjøre payloaden entydig: en eksplisitt lesekontrakt i selve svaret, på begge annonseplattformene.

Det er mønsteret vi ser igjen og igjen. Når en modell «hallusinerer», er årsaken oftere en tvetydig kontrakt enn en uoppmerksom modell. Det er gode nyheter, for tvetydige kontrakter kan fikses permanent — det kan ikke uoppmerksomhet.

Én ærlig begrensning

Vi kjører også en online dommer som sampler turer fortløpende i produksjon. Natten til 30. juli samplet den 3 av 24 turer, altså 12,5 prosent, og traff ingen av de tre turene der den grundigere nattlige gjennomgangen fant faktafeil. Samme observasjon natten før. Det er ikke dommerens kvalitet som er begrensningen, det er samplingsraten. Vi skriver det her fordi det er den typen tall som ellers aldri kommer ut av et selskap.

Hva dette ikke løser

Arkitekturen over hindrer at et tall oppstår fra ingenting. Den hindrer ikke at et helt korrekt tall brukes til å underbygge en dårlig anbefaling. Den hindrer heller ikke at en agent henter riktig verdi fra feil metrikk — som da SEO-agenten presenterte Keyword Planners konkurranseindeks som SEO-vanskelighetsgrad. Det funnet kom fra samme nattrutine, men handlet om domeneforståelse, ikke om aritmetikk.

Den erstatter heller ikke faglig gjennomlesning. Alt agentene produserer av forslag går gjennom en godkjenningsflyt der et menneske bestemmer hva som tas videre. Det er et bevisst designvalg, ikke en midlertidig sikkerhetsventil vi planlegger å fjerne.

Hva det betyr for teamet ditt

• Tallene i rapporten er de samme tallene som står i Google Ads og GA4, fordi de er regnet ut av kode med kjent formel — ikke gjengitt av en modell.
• Hvert forslag kan spores tilbake til regelen som utløste det, og til verdiene regelen traff på.
• Innhold som sendes ut til mottakere kan ikke inneholde en ytelsespåstand uten et godkjent faktum bak seg.
• Vi finner våre egne feil før du gjør det, og vi skriver ned hva vi fant.