Siter dette som: Apier.no, Derfor svikter REST-API-er for AI-agenter, v1.0

Derfor svikter REST-API-er for AI-agenter

Av Antony Richard Grov, gründer av Apier

Tradisjonelle REST-API-er svikter for AI-agenter fordi de forutsetter at et menneske leser dokumentasjonen, resonnerer seg gjennom grensetilfellene, og retter feil for hånd. En autonom agent gjør ingen av delene, så den hallusinerer parametere, mistolker begrensninger, og kan ikke bevise hva den gjorde. I en kosmetisk app er det en irritasjon. I en regulert handling mot Altinn eller Skatteetaten er et hallusinert organisasjonsnummer eller en feilformatert skatteinnsending et juridisk ansvar.

Estimert lesetid: 7 minutter.

Hvorfor REST-API-er forutsetter en menneskelig leser

Et REST-API er en kontrakt skrevet for to lesere: programmet som gjør kallet, og utvikleren som skrev programmet. Maskinhalvdelen av kontrakten er smal: en URL, et verb, en JSON-kropp, en statuskode. Alt som gjør API-et brukbart bor i den andre halvdelen: dokumentasjonen en utvikler leser, eksemplene de kopierer, Stack Overflow-svaret som forklarer hvorfor den åpenbare forespørselen returnerer en 400, og den akkumulerte dømmekraften i utviklerens hode om hvilke felt som egentlig er påkrevd og hva feilteksten faktisk betyr.

Det fungerte i tretti år fordi det alltid var en utvikler i sløyfen. De leste prosaen, holdt grensetilfellene i hodet, og prøvde på nytt for hånd når noe feilet. En AI-agent fjerner det mennesket fra sløyfen og arver bare maskinhalvdelen av kontrakten. Halvdelen som bar meningen overføres aldri.

Der agenter svikter: oppdagelse, resonnering, gjenoppretting, bevis

En agent som kaller et konvensjonelt REST-API svikter på fire forutsigbare steder. Hvert av dem svarer til noe API-et stille overlot til den fraværende utvikleren.

• Oppdagelse. Agenten må vite hvilket endepunkt og hvilke parametere den skal bruke. Når den kunnskapen bor i prosadokumentasjon i stedet for et maskinlesbart manifest, gjetter agenten, og en gjettet parameter er en hallusinert parameter.
• Resonnering. Begrensningene som betyr noe (hvilket felt som er obligatorisk for denne enhetstypen, hvilken juridisk forutsetning som må holde før en innsending er gyldig) er kodet i dokumentasjon og i utviklerens dømmekraft, ikke i noe agenten kan evaluere. Så agenten mistolker begrensningen og bygger en ugyldig forespørsel som ser gyldig ut.
• Gjenoppretting. En REST-feil er skrevet for et menneske: 400 Bad Request, invalid input. Det finnes ingenting strukturert for agenten å handle på, så den kan ikke rette seg selv. Den prøver det samme ødelagte kallet igjen, eller gir opp.
• Bevis. Et vellykket REST-kall returnerer en 200 og en kropp, og ingenting mer. Det finnes ingen signert kvittering og ingen manipulasjonssikker registrering, så agenten kan ikke senere bevise overfor en tredjepart (en revisor, et skattekontor, virksomheten den handlet for) nøyaktig hva den sendte inn og når.

For en chatbot som oppsummerer været er ingenting av dette fatalt. For en agent som handler på vegne av en virksomhet mot Brønnøysundregistrene eller leverer gjennom Altinn, er hver av de fire et ansvar, og et galt svar er ingen skrivefeil.

API-er for utviklere kontra API-er bygget for agenter

Forskjellen ligger i antakelsene om hvem, eller hva, som er i den andre enden av kallet, ikke i SDK-et.

Hva et API bygget for agenter gjør annerledes

Å lukke de fire gapene er en konkret sjekkliste, ikke en filosofi. Et API bygget for agenter behandler hvert av dem som en førsteklasses del av kontrakten:

• Maskinlesbar oppdagelse. Kapabiliteter, verktøymanifester, og en llms.txt agenten kan liste opp, så den aldri gjetter et endepunkt eller en parameter.
• Deterministisk validering før enhver handling. Inndata sjekkes mot det registeret oppgir før agenten handler, så en feilformatert forespørsel fanges i kanten i stedet for å oppdages for sent.
• Strukturerte, selvrettende feil. Hver feil returnerer en maskinlesbar error_code og konkrete rettetrinn, så agenten kan reparere forespørselen og prøve igjen i stedet for å gå i sløyfe på det samme ødelagte kallet.
• Eksplisitt autorisasjonsavklaring. Selskapets registrerte signaturregler leses ved hvert kall fra det offentlige registeret, aldri antatt fra et token som ble koblet opp én gang.
• En oppføring og et spor. Hvert svar bærer en hash av svaret og et tidsstempel, API-et lagrer en oppføring av kilden det leste, og hvert oppslag lander i en revisjonskjede som bare kan utvides, og som ingen, heller ikke API-leverandøren, kan skrive om.
• Transparensmetadata. Hvert svar bærer regelversjonen og ferskhetsstemplene det ble beregnet mot, så agenten vet hvor oppdatert og hvor autoritativt resultatet er.

Kontrasten er skarpest ved feilgrensen. Et konvensjonelt API gir en agent noe et menneske må tolke. Et API bygget for agenter gir tilbake noe agenten kan handle på direkte:

{
  "success": false,
  "error_code": "ORG_NUMBER_INVALID_CHECKSUM",
  "explanation": {
    "summary": "Organisasjonsnummeret feilet MOD-11-kontrollsifferet.",
    "fix_steps": [
      "Kontroller de ni sifrene mot Brønnøysund.",
      "Prøv igjen med det rettede nummeret."
    ]
  }
}

Ingenting i den kroppen krever at et menneske leser den. Agenten forgrener på error_code, viser fix_steps til den som kan handle på dem, og prøver igjen når forutsetningen holder. Her forteller koden agenten at organisasjonsnummeret feilet kontrollsifferet: en maskinlesbar feil den kan rette, ikke en prosatekst den må tolke.

AVERT: femstegssløyfen en agent kjører

AVERT er navnet på sløyfen bygget for agenter: de fem stegene en AI-agent følger for å utføre en regulert handling mot norske offentlige systemer og komme ut med bevis den kan stå inne for. Hele rammeverket bor på apier.no/avert; kort fortalt:

1. Authorize. Les enhetens registrerte signaturregel (signaturrett og prokura fra Brønnøysund) før noe annet skjer, og la agenten din anvende den på handlingen det gjelder.
2. Validate. Agenten sjekker den planlagte handlingen mot det registeret oppgir, og hver feil Apier returnerer er maskinlesbar, så agenten kan rette seg etter den. Apier sender ingenting videre til det offentlige.
3. Execute. Det bindende steget skjer i virksomhetens egne systemer, under virksomhetens egen myndighet. Apier tilbyr ingen skrivebane og leverer ingen innsendinger.
4. Receipt. En manipulasjonssikker registrering av hva som ble lest, fra hvilket register og når (en hash av svaret og en oppføring av kilden i hvert svar, et signert sertifikat ved behov), så grunnlaget for handlingen kan verifiseres uavhengig senere.
5. Trail. En sammensatt revisjonskjede over enhetens regulerte handlinger, som bare kan utvides, og som ingen, heller ikke Apier, kan skrive om.

Slik står det i dag: leseoppslag kjører i produksjon, og hvert oppslag lander i sporet som bare kan utvides. Bindende innsendinger, slik som faktisk å levere en MVA-melding, tilbys ikke av Apier: virksomheten leverer i egne systemer. En agent kan ikke bruke Apier til å levere en MVA-melding; den kan lese selskapets registrerte signaturregler, lese fristene, sjekke inndataene sine mot registeret og ta vare på et beviselig spor av hva den leste frem til det bindende steget. Spesifikasjonen er offentlig og åpen for gjennomgang på github.com/PowerLaunch/avert-spec.

Hvor Apier passer inn

Apier er API-et og MCP-laget som gir AI-agenter kildebelagte, daterte svar om norske virksomheter fra de offentlige registrene (Brønnøysundregistrene) og de publiserte reglene, og implementerer kontrakten for agenter for lesing: maskinlesbar oppdagelse, deterministisk validering, strukturerte selvrettende feil, signerte kvitteringer, og et spor som bare kan utvides. Det selger ikke virksomhetsdata; dataoppslag er en handelsvare. Bevis og spor er det ikke, og det er nettopp det laget AVERT definerer.

Hvis du bygger en agent som trenger verifiserte fakta om norske virksomheter, start med dokumentasjonen og en nøkkel:

• Registrer deg for en API-nøkkel: gratisnivå, og ingen legitimasjon fra det offentlige kreves for å starte i sandkassen.
• Les dokumentasjonen: endepunkter, MCP-serveren, og kontrakten for strukturerte feil i sin helhet.
• AVERT-rammeverket: femstegssløyfen og hvordan hvert steg er tilordnet et offentlig system.

Vanlige spørsmål

Hvorfor kan ikke en AI-agent bare bruke et vanlig REST-API?

En agent kan kalle et REST-endepunkt, men den kan ikke pålitelig lese prosadokumentasjon, resonnere seg gjennom juridiske grensetilfeller, rette seg etter prosafeilmeldinger, eller bevise hva den gjorde. I en regulert handling betyr det gapet hallusinerte parametere og et resultat agenten ikke kan stå inne for.

Hva er AVERT?

AVERT er en femstegssløyfe (Authorize, Validate, Execute, Receipt, Trail) som en AI-agent følger for å utføre en regulert handling mot norske offentlige systemer og komme ut med kryptografisk bevis.

Kan en AI-agent bruke Apier til å levere en norsk MVA-melding?

Nei. Apier leser selskapsfakta, signaturrett og frister, og hvert oppslag lander i et spor som bare kan utvides. Apier leverer ikke MVA-meldinger eller andre skjemaer; i AVERT-løkken skjer steget Execute i virksomhetens egne systemer, under virksomhetens egen myndighet.

Videre lesning

• apier.no/avert: AVERT-rammeverket (Authorize, Validate, Execute, Receipt, Trail) i sin helhet.
• github.com/PowerLaunch/avert-spec: den offentlige AVERT-spesifikasjonen, åpen for gjennomgang.
• altinn.no: Altinn, portalen agenter handler gjennom for regulerte innsendinger.
• docs.digdir.no: Digdirs utviklerdokumentasjon for Maskinporten og Altinn 3 systembrukere.
• brreg.no: Brønnøysundregistrene, kilden til virksomhetsdata og rolledata.
• skatteetaten.no: Skatteetaten, skattemyndigheten bak MVA og relaterte innsendinger.

Publisert 2026-06-27. Sist oppdatert 2026-11-03.