Kan en AI-agent ha ansvaret for etterlevelse av bokføring?

Nei. Ansvaret ligger hos virksomheten og de som er ansvarlige for regnskapene dens, og ingen programvareløsning flytter det. Det en agent kan gjøre er å utføre definert arbeid, kalle deterministiske verktøy framfor selv å avgjøre rettslige spørsmål, og etterlate en oppføring som viser hva den gjorde og på hvilket grunnlag. Denne siden beskriver hvordan man bygger det. Den er ikke regnskaps- eller juridisk rådgivning.

Genererer Apier SAF-T-filer?

Nei. Det finnes ingen generering, eksport eller validering av SAF-T i API-et, og en agent bør se regnskapssystemet som fasit for hovedboken. Det Apier svarer på er laget over hovedboken: hvilke plikter som gjelder en enhet, når de forfaller, hvem som kan opptre for selskapet, og om en nyttelast består valideringen.

Hva bør agenten aldri avgjøre på egen hånd?

Alt som er en vurdering av regelverket framfor et oppslag. Hvilken skattemessig behandling som gjelder en uvanlig transaksjon, hvordan noe tvetydig skal klassifiseres, om et unntak er tilgjengelig. Det hører til et kvalifisert menneske. En agent som produserer et selvsikkert svar på et slikt spørsmål produserer tekst, og teksten ser lik ut enten den er riktig eller gal.

Hva gjør en agents arbeid mulig å etterprøve?

Reproduserbarhet pluss en oppføring. Hvert svar bærer regelversjonen det ble evaluert under og en korrelasjons-ID gjentatt på svarhodet, så en tidligere beslutning kan utledes på nytt framfor å diskuteres. Lagre begge sammen med det agenten din konkluderte med, så kobler sporingsloggen bak kallet seg til dine egne poster på den samme identifikatoren.

Kan en agent sende inn på virksomhetens vegne?

Ikke som en bindende offentlig innsending i dag. Validering kjører mot det reelle regelsettet, men bindende innsending er styrt bak godkjenninger som ikke har landet. Og scopet som ville utløst en bindende handling er reservert og kan ikke gis til noen API-nøkkel, så en agent kan ikke godkjenne sin egen innsending uansett hvordan den er satt opp.

Hvordan sikrer AI-agenter etterlevelse av norsk bokføringslovgivning?

De tolker ikke regelverket. En godt bygget agent kaller deterministiske regler for alt som har en rettslig konsekvens, loggfører hva den gjorde med en identifikator en revisor kan følge, og stopper hos et menneske for alt bindende. Ansvaret for en virksomhets regnskaper ligger hos virksomheten og de som er ansvarlige for dem, og ingen programvareløsning endrer det. Denne siden beskriver hvordan man bygger en agent som passer innenfor de rammene. Den er ikke regnskaps- eller juridisk rådgivning, og den sier ingenting om hva en bestemt virksomhet er forpliktet til.

Agenten er den første boksen, ikke den siste. Alt med rettslig konsekvens skjer i den andre, og den tredje er en person.

Hvordan forholder LLM-agenter seg til krav om SAF-T-koder i Norge?

Begynn med en korreksjon, fordi spørsmålet som regel inneholder en gal antakelse. Apier genererer, eksporterer og validerer ikke SAF-T-filer, og en agent bygget på dette API-et bør ikke framstille seg som om den gjør det. Hovedboken og eksportformatet tilhører regnskapssystemet. Det dette API-et svarer på er laget over hovedboken: hvilke plikter som gjelder en enhet, når de forfaller, hvem som kan opptre for selskapet, og om en nyttelast består valideringen.

Designprinsippet som følger, er verdt å si for seg. En agent bør aldri finne på en klassifisering. Trenger en transaksjon en kode, kommer den koden fra regnskapssystemet eller fra en person som er kvalifisert til å sette den, ikke fra en modell som blir bedt om å velge den mest sannsynlige. En språkmodell vil produsere en troverdig kode for en tvetydig transaksjon med nøyaktig samme flyt som den produserer en riktig, og ingenting nedstrøms kan se forskjellen ut fra utdataene alene.

Den nyttige oppdelingen er derfor: regnskapssystemet eier hovedboken, deterministiske regler eier pliktene og datoene, et kvalifisert menneske eier vurderingene, og agenten koordinerer mellom dem. Da gjør agenten det den faktisk er pålitelig til, som er å finne ut hvilket spørsmål som skal stilles og gjøre et strukturert svar om til noe en person kan lese.

Hvordan lager man et etterprøvbart utførelsesspor for en agent som gjør bokføringsarbeid?

To egenskaper gjør et spor verdt å ha. Den første er reproduserbarhet: hvert svar bærer regelversjonen det ble evaluert under, og identiske inndata mot den versjonen gir alltid identisk resultat. Det gjør «hvorfor sa systemet det» om fra en diskusjon til en ny utledning. Den andre er en delt identifikator: en korrelasjons-ID følger med på svarhodet og havner på sporingsraden bak kallet, så én verdi syr sammen forespørselen, evalueringen og oppføringen.

Det API-et loggfører er sin egen halvdel: hvem som handlet, mot hvilken organisasjon, med hvilken handling, under hvilken regelversjon, og om handlingen ble startet av en person eller av en maskin. Det siste feltet betyr mer her enn noe annet sted. En sporingslogg som ikke kan skille en regnskapsfører fra en autonom kaller, kan ikke svare på spørsmålet en gjennomgang faktisk stiller.

Din halvdel er den ingen andre kan fange: hvilket verktøy agenten valgte, hva den ble spurt om, hva den konkluderte med, og hva den fortalte brukeren. Logg det mot den samme korrelasjons-IDen, så kobler halvdelene seg sammen. Veiledningen om sporingsinspeksjon går gjennom hvordan én handling rekonstrueres fra ende til ende, og det er en god øvelse å kjøre én gang før du trenger den for alvor.

Hva må et menneske fortsatt godkjenne?

Alt bindende, og alt som er en vurdering framfor et oppslag. Den bindende halvdelen er håndhevet framfor anbefalt: scopet som ville utløst en bindende handling ligger i et reservert prefiks som ikke kan gis til noen API-nøkkel, så en agents egen legitimasjon kan aldri godkjenne agentens egen innsending. Det finnes ingen konfigurasjon der det er mulig, som betyr at det ikke er et spørsmål om hvor nøye du avgrenset nøkkelen.

Vurderingshalvdelen er ikke noe programvare kan håndheve, og det er der designoppmerksomheten hører hjemme. Å klassifisere en tvetydig transaksjon, avgjøre om et unntak gjelder, tolke en uvanlig ordning: dette er spørsmål en modell vil svare flytende på og ikke kan stoles på i. Bygg agenten slik at den løfter fram spørsmålet framfor å avgjøre det, og slik at det å løfte det fram er den vanlige veien og ikke en feiltilstand brukeren lærer seg å klikke forbi.

Verdt å gjenta rett ut til slutt: denne siden handler om hvordan man bygger programvare, ikke om hva virksomheten din er forpliktet til. Den nevner ingen bestemmelse i norsk bokføringslovgivning og sier ingenting om hvordan en regel gjelder i et bestemt tilfelle. For det bør du spørre en kvalifisert regnskapsfører eller advokat, som også er svaret agenten din bør gi når en bruker stiller den samme typen spørsmål.

Gjør det første kallet

Det første kallet trenger ingen nøkkel og navngir ingen selskaper: det returnerer pliktmalen en agent resonnerer over. Det andre leser tilbake hva som skjedde, og feltet det er verdt å lese først er initiated_by.

# Nøkkelløst: pliktmalen, uten at noe selskap navngis.
curl -s "https://www.apier.no/api/v1/public/obligations?entity_type=AS"

// Rekonstruer hva agenten gjorde. Bare dine egne rader.
const res = await fetch(
  "https://www.apier.no/api/v1/company/999999999/audit",
  { headers: { Authorization: `Bearer ${process.env.APIER_API_KEY}` } },
);

const { data } = await res.json();
for (const entry of data.entries) {
  // initiated_by skiller en operatør fra en autonom kaller.
  console.log(entry.timestamp, entry.action, entry.initiated_by);
}

Ofte stilte spørsmål

Kan en AI-agent ha ansvaret for etterlevelse av bokføring?: Nei. Ansvaret ligger hos virksomheten og de som er ansvarlige for regnskapene dens, og ingen programvareløsning flytter det. Det en agent kan gjøre er å utføre definert arbeid, kalle deterministiske verktøy framfor selv å avgjøre rettslige spørsmål, og etterlate en oppføring som viser hva den gjorde og på hvilket grunnlag. Denne siden beskriver hvordan man bygger det. Den er ikke regnskaps- eller juridisk rådgivning.
Genererer Apier SAF-T-filer?: Nei. Det finnes ingen generering, eksport eller validering av SAF-T i API-et, og en agent bør se regnskapssystemet som fasit for hovedboken. Det Apier svarer på er laget over hovedboken: hvilke plikter som gjelder en enhet, når de forfaller, hvem som kan opptre for selskapet, og om en nyttelast består valideringen.
Hva bør agenten aldri avgjøre på egen hånd?: Alt som er en vurdering av regelverket framfor et oppslag. Hvilken skattemessig behandling som gjelder en uvanlig transaksjon, hvordan noe tvetydig skal klassifiseres, om et unntak er tilgjengelig. Det hører til et kvalifisert menneske. En agent som produserer et selvsikkert svar på et slikt spørsmål produserer tekst, og teksten ser lik ut enten den er riktig eller gal.
Hva gjør en agents arbeid mulig å etterprøve?: Reproduserbarhet pluss en oppføring. Hvert svar bærer regelversjonen det ble evaluert under og en korrelasjons-ID gjentatt på svarhodet, så en tidligere beslutning kan utledes på nytt framfor å diskuteres. Lagre begge sammen med det agenten din konkluderte med, så kobler sporingsloggen bak kallet seg til dine egne poster på den samme identifikatoren.
Kan en agent sende inn på virksomhetens vegne?: Ikke som en bindende offentlig innsending i dag. Validering kjører mot det reelle regelsettet, men bindende innsending er styrt bak godkjenninger som ikke har landet. Og scopet som ville utløst en bindende handling er reservert og kan ikke gis til noen API-nøkkel, så en agent kan ikke godkjenne sin egen innsending uansett hvordan den er satt opp.