Hvis du spør ChatGPT om en norsk skatteparagraf den ikke kjenner, gir den deg en. Ofte med paragrafnummer. Ofte med en presis ordlyd. Det eneste problemet er at paragrafen ikke finnes.
For en gründer som skal levere sin første MVA-melding er det forskjellen på rett og feil tall i Skatteetatens system.
Det er den vanligste — og farligste — egenskapen til de fleste AI-verktøy: de er designet til aldri å si "jeg vet ikke". Hvis modellen ikke har et svar, finner den et som høres riktig ut.
Grundo er bygget motsatt vei.
Bakvendt arkitektur
I stedet for å gjette pent når den ikke vet, er hele Grundo designet for å spore nøyaktig hva den ikke kan svare på — og lære av det over tid.
Det skjer i fire lag.
Lag 1 — Kilde på hver eneste påstand
Grundos kunnskap om norsk regelverk er ikke trent inn i en modell. Den ligger i en strukturert database der hver påstand har en lenke til der den kommer fra — Altinn, Skatteetaten, Brønnøysundregistrene, Lovdata, NAV.
Når Grundo svarer på et spørsmål om MVA-grensen, henter den ikke svaret fra noe den "husker". Den henter det fra en konkret rad i databasen som ble lagt inn med en lenke til Skatteetatens egen veiledning.
Det betyr at jeg kan etterprøve hvert eneste svar Grundo gir. Og hvis Skatteetaten endrer en sats, kan jeg finne hver eneste sted satsen er brukt og oppdatere den.
Ingen påstand uten paragraf.
Lag 2 — Ordbok som vokser med samtalen
Grundo har en intern ordbok — et glossary — som forklarer norske fagbegreper når de dukker opp i en samtale. ENK, MVA, Foretaksregisteret, næringskode, forskuddsskatt. Termer som er åpenbare for en regnskapsfører, men ikke for noen som starter sin første bedrift.
Ordboken bygger seg ut etter hvert som Grundo brukes. Når Grundo støter på begreper den er trygg på betydningen av, legger den dem inn automatisk. Termer den er usikker på går i en kø av forslag — og legges ikke inn før de har dukket opp ofte nok i ekte samtaler.
Det betyr at sjeldne ord ikke får forsøple ordboken, men at de vanlige feller seg på plass av seg selv.
Lag 3 — Hullene logges som konsepter, ikke som strenger
Det viktigste laget. Når en bruker spør Grundo noe den ikke kan svare presist på, logges det. Men ikke som rå tekst.
Grundo omformulerer først spørsmålet til et kanonisk konsept — den underliggende tingen brukeren faktisk lurer på, løsrevet fra den spesifikke formuleringen. Det betyr at to brukere som spør samme ting på to forskjellige måter blir samme rad i loggen.
Et ekte eksempel fra databasen, fra i går kveld:
{
rawQuestion: "Når lønner det seg å starte AS, skattemessig?",
canonicalQuestion: "Hva er det skattemessige brekkpunktet
mellom ENK og AS med tanke på overskudd
og skattesatser?",
category: "skatt",
contextNote: "Bruker vil vite når AS blir mer skattefordelaktig
enn ENK basert på inntektsnivå",
count: 1,
status: "new"
}
To ting er verdt å peke på her.
canonicalQuestion er Grundos egen omskriving av hva brukeren egentlig lurte på. Det er denne som brukes til å gjenkjenne duplikater. Hvis fem ulike brukere spør "ENK eller AS når jeg tjener 800k?", "skattemessig brekkpunkt for AS?" og "burde jeg endre selskapsform med høy inntekt?" — så er det samme hull. Telleren teller det fem ganger, og viser meg at det er noe mange lurer på.
status: "new" er første trinn i en workflow. Når jeg har skrevet en KnowledgeEntry som dekker hullet, går status videre til løst, og hullet forsvinner fra dashboardet mitt.
Hullene er ikke skjult i logger eller begravet i analytics. De er en synlig kø.
Lag 4 — Manuell review og fakta-injeksjon
Jeg ser hullene i et admin-dashboard hver dag. Når et konsept har dukket opp ofte nok, legger jeg inn en ny KnowledgeEntry — med kildehenvisning til en autoritativ norsk kilde — som dekker det.
Neste bruker som stiller samme spørsmål får svaret med én gang.
Grundo lærer ikke ved å trene en modell på nytt. Den lærer ved at jeg fyller hullene én etter én, manuelt, med en kilde. Det er tregere enn modelltrening, men det betyr at hvert nytt svar er etterprøvbart, oppdaterbart, og knyttet til en konkret paragraf.
Det neste laget — folk som vet bedre enn meg
Her må jeg være ærlig om noe.
Jeg er en utvikler. Jeg kan lese Lovdata, jeg kan tolke Skatteetatens veiledninger, og jeg kan strukturere informasjon i en database. Men jeg er ikke regnskapsfører.
Det er mor.
Og far. Og begge søstrene mine.
Jeg er vokst opp ved et middagsbord der folk diskuterte saldoavskrivninger og skattepliktig fordel av elbil. Da jeg hadde lekser i matte, satt det fire personer rundt bordet som kunne hjelpe meg på fem forskjellige måter. Det jeg lærte tidlig var at det finnes overraskende mange måter å regne feil på et tall — og at konsekvensene av å ta feil i en MVA-melding ikke er teoretiske.
Jeg bygger Grundo for et publikum jeg kjenner — folk som starter sin første bedrift og ikke har en autorisert regnskapsfører i nær familie. Men jeg bygger den med en ydmykhet jeg fikk fra dem som har det.
Planen for neste fase er at en autorisert regnskapsfører skal faktasjekke alle de mest kritiske svarene Grundo gir. Ikke som en gimmick. Som en faktisk gjennomgang av kunnskapsbasen, med signatur, og en dato for når den sist ble verifisert.
Det er ikke for å gjøre Grundo perfekt. Det er for å gjøre Grundos selvtillit fortjent.
Hvorfor det er bygget sånn
Det handler ikke om å være den smarteste AI-en på markedet.
Det handler om å være den ærligste.
En forretningspartner som sier "det vet jeg ikke, men jeg skriver det ned og kommer tilbake" er mer verdt enn en som lyver med selvtillit. Det er den enkle setningen som er kjernen i hele arkitekturen jeg har beskrevet over.
Grundo skal ikke late som den er en regnskapsfører. Den skal være en assistent som vet hvor regelverket finnes, som vet hva den selv ikke vet, og som blir bedre hver eneste dag — fordi noen aktivt fyller hullene.
Det er den eneste typen AI jeg ville stolt på med min egen bedrift.