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

Derfor svikter REST-API-er for AI-agenter

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 — et hallusinert organisasjonsnummer, en feilformatert skatteinnsending — er det 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. Maskin-halvdelen 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 maskin-halvdelen av kontrakten — den smale halvdelen. 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 kartlegger 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.

Utvikler-API-er kontra agent-native API-er

Forskjellen er ikke et bedre SDK. Det er et annet sett av antakelser om hvem — eller hva — som er i den andre enden av kallet.

Hva et agent-native API gjør annerledes

Å lukke de fire gapene er en konkret sjekkliste, ikke en filosofi. Et agent-native API 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 skriving. En forespørsel sjekkes for struktur og juridisk grunnlag før den kan nå det offentlige, så en feilformatert nyttelast fanges i kanten, ikke oppdages etter innsending.
• 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. Hvem som har lov til å handle for hvem avklares ved hvert kall fra ekte delegeringsdata, aldri antatt fra et token som ble koblet opp én gang.
• En kvittering og et spor. Hver handling produserer en signert, manipulasjonssikker kvittering, og lander i en tilføy-bar revisjonskjede 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 agent-native API gir tilbake noe agenten kan handle på direkte:

{
  "success": false,
  "error_code": "MISSING_DELEGATION",
  "explanation": {
    "summary": "Systembrukeren er ikke delegert til å levere MVA for denne enheten.",
    "fix_steps": [
      "Be enheten delegere MVA-tilgangspakken i Altinn.",
      "Prøv igjen når delegeringen er aktiv."
    ]
  }
}

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 systembrukeren mangler delegering av MVA-tilgangspakken — en maskinlesbar feil den kan rette, ikke en prosatekst den må tolke.

AVERT: femstegssløyfen en agent kjører

AVERT er navnet på den agent-native sløyfen: 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. Bekreft at agenten juridisk har lov til å handle for enheten — Maskinporten-legitimasjon (virksomhetssertifikat) pluss Altinn-delegering og kontroll av handleevne — før noe annet skjer.
2. Validate. Hver forespørsel passerer gjennom en deterministisk sandkasse som sjekker struktur og juridisk grunnlag og returnerer maskinlesbare feil agenten kan rette seg etter, så ingen feilformatert nyttelast når det offentlige.
3. Execute. Det autoriserte kallet til Altinn, Maskinporten, eller Skatteetaten som enheten. Lesehandlinger er live i dag; skrivebanen rulles ut per design-partner.
4. Receipt. En signert, manipulasjonssikker registrering av nøyaktig hva som ble sendt inn, ved siden av det rå offentlige svaret, så handlingen kan verifiseres uavhengig senere.
5. Trail. En tilføy-bar, sammensatt revisjonskjede over enhetens regulerte handlinger, som ingen — heller ikke Apier — kan skrive om.

Slik står det i dag, sagt rett ut: Validate og Trail er live, og lese-oppslag kjører i produksjon. Skrivebanen — Execute som en bindende innsending, slik som faktisk å levere en MVA-melding — er i design-partner-forhåndsvisning, ikke en live autonom innsendingsevne. En agent kan ikke levere en ekte MVA-melding på egen hånd gjennom Apier i dag; den kan autorisere, validere mot de ekte reglene, og bygge et komplett, beviselig spor 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 det Maskinporten-baserte MCP-laget som sitter mellom AI-agenter og norsk offentlig infrastruktur — Altinn, Brønnøysundregistrene, Skatteetaten — og implementerer den agent-native kontrakten ende til ende: maskinlesbar oppdagelse, deterministisk validering, strukturerte selvrettende feil, avklaring av handleevne per kall, signerte kvitteringer, og et tilføy-bart spor. Det selger ikke virksomhetsdata; data-oppslag er en handelsvare. Bevis og spor er det ikke — og det er laget AVERT definerer.

Hvis du bygger en agent som må handle på norsk compliance-infrastruktur, start med dokumentasjonen og en nøkkel:

• Registrer deg for en API-nøkkel — gratisnivå, ingen offentlige legitimasjoner 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 kartlegger til 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 levere en norsk MVA-melding gjennom Apier i dag?

Ikke autonomt. Lese-oppslag og deterministisk validering er live i dag, og hver handling lander i et tilføy-bare spor. Skrivesteget (Execute) er i design-partner-forhåndsvisning — bindende innsendinger rulles ut per design-partner, ikke som en live autonom innsendingsevne.

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 — DigDir sin utviklerdokumentasjon for Maskinporten og Altinn 3 systembrukere.
• brreg.no — Brønnøysundregistrene, kilden til virksomhets- og rolledata.
• skatteetaten.no — Skatteetaten, skattemyndigheten bak MVA og relaterte innsendinger.

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