Hvorfor finner en språkmodell på et organisasjonsnummer?

Fordi det å generere ett er formet som gjenkalling, ikke som oppslag. Et norsk organisasjonsnummer er ni sifre med et MOD-11-kontrollsiffer, og en modell som har sett millioner av dem, kan produsere strenger som ser riktige ut og noen ganger til og med består kontrollen. Ingenting i den prosessen konsulterer et register, så nummeret er plausibelt snarere enn sant. Løsningen er strukturell: valider formatet ved grensen, og slå deretter nummeret opp mot Brønnøysund-baserte data før noe ledd behandler det som et faktum.

Hva gjør et verktøysvar til å stole på?

Tre egenskaper sammen: skjema, kilde og ferskhet. Inndataene valideres før noe kjøres, så et misdannet organisasjonsnummer avvises i stedet for å omtolkes. Utdataene er strukturert JSON som agenten leser felt for felt, ikke prosa den omskriver. Og svaret bærer proveniens: hvilken kilde det kom fra, hvor ferske dataene er, og hvilken regelbokversjon som evaluerte det. Et svar med de vedleggene kan kontrolleres; en flytende setning kan ikke.

Hva bør en agent gjøre når dataene mangler?

Rapportere ukjent og stoppe. De åpne registerdataene dekker faktisk ikke alt: tekster om signaturrett og prokura ligger for eksempel i Foretaksregisteret og finnes ikke i det åpne rollevokabularet, så det ærlige svaret på åpent nivå er ukjent, ikke en tom liste. En agent som sender det utfallet videre, gir brukeren et sant bilde. En agent som fyller stillheten med en gjetning, gjør en datagrense om til en fabrikasjon.

Kan en agent verifisere et selskap uten API-nøkkel?

Den kan øve inn hele formen uten en. Oppdagelse på MCP-endepunktet er nøkkelløs, seks offentlige verktøy kjører uten nøkkel, og den nøkkelløse sandkassen speiler verifiseringskallet på simulerte data, så en agent kan lære forespørsels- og svarformene fra ende til ende. Levende svar om et virkelig, navngitt selskap er den nøkkelbelagte flaten: selskapsdata-verktøy svarer 401 uten nøkkel, med vilje, fordi dataene er personnære.

Fjerner forankring behovet for menneskelig gjennomgang?

Nei, og det er heller ikke meningen. Forankring fikser faktalaget: agenten slutter å påstå utdaterte eller oppdiktede registerdata og begynner å sitere kildefestede, daterte svar. Beslutninger bygget på de faktaene er et eget lag, og for alt bindende, en innsending, en kontrakt, en erklæring overfor en myndighet, skal et menneske fortsatt gå gjennom før noe forplikter. Det forankring endrer, er kvaliteten på det mennesket gjennomgår: etterprøvbare fakta i stedet for selvsikker prosa.

Hvordan får AI-agenter norske selskapsfakta uten å hallusinere?

Av Antony Richard Grov, gründer av Apier

Ved aldri å be modellen huske dem. En agent får pålitelige norske selskapsfakta ved å kalle et deterministisk verktøy som spør det autoritative registeret i det øyeblikket spørsmålet stilles, i stedet for å trekke fra det modellen tok opp under trening. En språkmodells gjenkalling av organisasjonsnumre, styrenavn og frister er generering, ikke oppslag: den produserer plausible verdier enten de er sanne eller ikke. Det forankrede alternativet validerer inndataene mot et skjema, løser spørsmålet mot Brønnøysund-baserte data ved svartid, og returnerer et strukturert resultat som bærer sin egen proveniens: kilden, dataferskheten og regelbokversjonen det ble evaluert under. Apier eksponerer den flaten over MCP på https://www.apier.no/api/mcp, med nøkkelløs oppdagelse, så en modell kan gå fra å gjette til å sitere før noen holder en nøkkel.

Begge veiene gir et svar, og begge svarene leser like godt. Bare det ene kan kontrolleres, og det er derfor forankring er en koblingsbeslutning og ikke en modellegenskap.

Hvorfor hallusinerer språkmodeller selskapsfakta?

Fordi parametrisk minne er et øyeblikksbilde, og å svare fra det er generering og ikke henting. Når en modell oppgir en styresammensetning eller et organisasjonsnummer fra treningsdata, fortsetter den et statistisk mønster; den slår ikke opp i noe register. Svaret er formet som et faktum og leveres med samme flyt enten verdien ble husket riktig, husket fra en utdatert side, eller satt sammen av biter fra flere selskaper. Ingenting i mekanismen skiller de tilfellene fra hverandre.

Selv en verdi som var riktig ved trening, forfaller. Styrer byttes ut, selskaper går til avvikling, og frister flyttes når en lovfestet dato lander på en helg eller helligdag. Registeret beveger seg daglig; øyeblikksbildet gjør det ikke. Feilen er altså ikke at modellen er slurvete: gjenkalling av registerdata har en holdbarhetsdato, og modellen har ingen måte å vite hvor gammel kopien dens er.

Skraping ved svartid minsker gapet uten å lukke det. En hentet side kan være mellomlagret, oversatt eller rett og slett gammel, og agenten mottar ustrukturert tekst den må tolke før den kan handle. Tolkningen er det samme generative steget på et nytt sted: modellen avgjør hva siden sannsynligvis betyr, og en tolkningsfeil leser nøyaktig som et faktum.

Hva må til for at et svar er forankret?

Først et deterministisk verktøy som spør det autoritative registeret når spørsmålet stilles, ikke før. Determinisme er en publisert egenskap ved dette API-et: samme inndata evaluert under samme regelbokversjon gir samme utdata, så to agenter som stiller samme spørsmål får samme svar, og et svar kan reproduseres senere under en gjennomgang.

Deretter skjemaer på begge sider av kallet. Inndata valideres ved grensen: et organisasjonsnummer er ni sifre med et MOD-11-kontrollsiffer, og en streng som stryker på kontrollen, avvises som en skrivefeil i stedet for å omtolkes til noe modellen antakelig mente. Utdata er typet JSON, så agenten leser felter i stedet for å omskrive prosa, og et manglende felt er synlig fraværende i stedet for stille glattet over.

Til slutt proveniens på hvert svar. Svarene bærer en _meta-blokk som navngir datakilden, dataferskheten og regelbokversjonen evalueringen kjørte under, og MCP-verktøyresultater legger til en begrunnelse som lister reglene som ble anvendt og kildedataene bak utfallet. Det er det som lar en agent sitere resonnementet sitt til en bruker, og det som lar brukeren kontrollere det.

Oppslag eller gjetning: hvorfor er ukjent et godt svar?

Et forankret svar sier ukjent når registeret er taust, og det utfallet bærer vekt. De åpne registerdataene dekker ikke alt: hvem som holder signaturrett eller prokura, for eksempel, er Foretaksregisteret-informasjon som det åpne rollevokabularet rett og slett ikke inneholder, så det ærlige svaret på åpent nivå er ukjent, aldri en tom liste kledd opp som et funn. En agent bygget på en slik registerbasert arbeidsflyt kan forgrene seg på det utfallet: eskalere, spørre, eller stoppe.

Modellens flytende gjetning er feilen i denne kontrasten, ikke reserveløsningen. Flyt er ukorrelert med sannhet: et galt organisasjonsnummer leser nøyaktig som et riktig, og et oppdiktet styremedlem er grammatisk umulig å skille fra et virkelig. Et system som kan si ukjent, gjør manglende data om til en synlig tilstand kalleren håndterer; et system som ikke kan det, fyller stillheten med sin beste fortsettelse, som er nettopp den atferden ordet hallusinasjon navngir.

Hvordan kobler MCP modellen til registeret?

Gjennom en driftet verktøyserver modellen oppdager i stedet for å huske. Endepunktet er https://www.apier.no/api/mcp, oppdagelsen er nøkkelløs, og verktøyene dukker opp i modellens verktøyliste med inndataskjemaene sine festet til, så modellen kjenner den nøyaktige formen på et gyldig spørsmål før den stiller det. Klientoppsett, konfigurasjonsmatrisen per klient og den fulle verktøyreferansen eies av veiledningen om MCP-serveren.

Nøkkelgrensen følger dataene, ikke transporten. Seks offentlige verktøy kjører uten legitimasjon, blant dem pliktmalene, fristkalenderen og feilforklareren; hvert verktøy som svarer om et navngitt selskap, krever en API-nøkkel. Modellen selv holder aldri en offentlig legitimasjon i noen av modusene: agentens nøkkel gir avgrensede lesetilganger mot Apier, og alt på myndighetssiden blir bak API-et, et skille veiledningen om trygg tilgang dekker i sin helhet.

Merk hva denne koblingen bevisst ikke inneholder: en skrivevei. Verktøyene leser, løser opp og validerer; ingenting her sender noe inn til et offentlig system. For et kunnskapsproblem er det riktig form, fordi hvert kall er et spørsmål, og hvert svar kommer med bevisene festet til.

Gjør det første kallet

Konfigurasjonsblokken kobler Claude Desktop til den driftede serveren gjennom den publiserte stdio-proxyen. Curl-kallet under trenger ingen nøkkel: det kjører ett av de seks nøkkelløse verktøyene og returnerer fristkalenderen for 2026 med proveniensen festet til, som er hele denne sidens argument i ett svar.

{
  "mcpServers": {
    "apier": {
      "command": "npx",
      "args": ["-y", "@apier-no/mcp"],
      "env": { "APIER_API_KEY": "apr_live_<your_key_here>" }
    }
  }
}

# Nøkkelløst tools/call: den norske fristkalenderen for 2026,
# evaluert fra regelboken ved svartid, uten legitimasjon.
curl -s https://www.apier.no/api/mcp \
  -H "content-type: application/json" \
  -d '{"jsonrpc":"2.0","id":1,"method":"tools/call","params":{"name":"get_public_deadlines","arguments":{"year":2026}}}'

Ofte stilte spørsmål

Hvorfor finner en språkmodell på et organisasjonsnummer?: Fordi det å generere ett er formet som gjenkalling, ikke som oppslag. Et norsk organisasjonsnummer er ni sifre med et MOD-11-kontrollsiffer, og en modell som har sett millioner av dem, kan produsere strenger som ser riktige ut og noen ganger til og med består kontrollen. Ingenting i den prosessen konsulterer et register, så nummeret er plausibelt snarere enn sant. Løsningen er strukturell: valider formatet ved grensen, og slå deretter nummeret opp mot Brønnøysund-baserte data før noe ledd behandler det som et faktum.
Hva gjør et verktøysvar til å stole på?: Tre egenskaper sammen: skjema, kilde og ferskhet. Inndataene valideres før noe kjøres, så et misdannet organisasjonsnummer avvises i stedet for å omtolkes. Utdataene er strukturert JSON som agenten leser felt for felt, ikke prosa den omskriver. Og svaret bærer proveniens: hvilken kilde det kom fra, hvor ferske dataene er, og hvilken regelbokversjon som evaluerte det. Et svar med de vedleggene kan kontrolleres; en flytende setning kan ikke.
Hva bør en agent gjøre når dataene mangler?: Rapportere ukjent og stoppe. De åpne registerdataene dekker faktisk ikke alt: tekster om signaturrett og prokura ligger for eksempel i Foretaksregisteret og finnes ikke i det åpne rollevokabularet, så det ærlige svaret på åpent nivå er ukjent, ikke en tom liste. En agent som sender det utfallet videre, gir brukeren et sant bilde. En agent som fyller stillheten med en gjetning, gjør en datagrense om til en fabrikasjon.
Kan en agent verifisere et selskap uten API-nøkkel?: Den kan øve inn hele formen uten en. Oppdagelse på MCP-endepunktet er nøkkelløs, seks offentlige verktøy kjører uten nøkkel, og den nøkkelløse sandkassen speiler verifiseringskallet på simulerte data, så en agent kan lære forespørsels- og svarformene fra ende til ende. Levende svar om et virkelig, navngitt selskap er den nøkkelbelagte flaten: selskapsdata-verktøy svarer 401 uten nøkkel, med vilje, fordi dataene er personnære.
Fjerner forankring behovet for menneskelig gjennomgang?: Nei, og det er heller ikke meningen. Forankring fikser faktalaget: agenten slutter å påstå utdaterte eller oppdiktede registerdata og begynner å sitere kildefestede, daterte svar. Beslutninger bygget på de faktaene er et eget lag, og for alt bindende, en innsending, en kontrakt, en erklæring overfor en myndighet, skal et menneske fortsatt gå gjennom før noe forplikter. Det forankring endrer, er kvaliteten på det mennesket gjennomgår: etterprøvbare fakta i stedet for selvsikker prosa.