Trygg arbeidsmetode for AI-agenter i regnskap

En regnskapsagent bør ikke vurderes etter hvor mange API-kall den kan sende, men etter hvor enkelt arbeidet er å kontrollere. En god agent kan forklare hvilke data den brukte, hva den foreslo, hva som faktisk ble endret og hvordan resultatet ble verifisert.

Den tryggeste grunnmodellen er:

Bekreft kontekst → les → analyser → foreslå → godkjenn → skriv → les på nytt → rapporter

Denne rekkefølgen passer både for en enkel avstemming og et større månedsoppdrag. Den hindrer agenten i å gjette seg frem til tenant, periode eller eksisterende tilstand.

Bekreft tenant og periode først

Feil selskap er den farligste stille feilen i et flerfirmaoppsett. Med bruker-API-nøkkel skal agenten hente tilgjengelige tenants fra GET /api/me, sammenligne tenant-id, selskapsnavn og organisasjonsnummer med oppdraget og deretter bruke X-Tenant-Id konsekvent.

Arbeidskonteksten bør minst angi:

Stabile opplysninger kan ligge i en lokal kontekstfil. Agenten bør likevel kontrollere kritiske verdier mot ReAI når arbeidet starter. En gammel fil skal ikke overstyre aktuelle systemdata.

Bruk minst mulig tilgang

Bruk normalt en bruker-API-nøkkel. Den arver brukerens selskaper, roller og rettigheter, gjør flerfirmaarbeid mulig gjennom X-Tenant-Id og knytter API-endringer til brukeren som eier nøkkelen. Kontroller derfor at brukeren selv ikke har bredere tilgang enn oppdraget krever.

Velg en tenant-API-nøkkel når du bevisst trenger en fast integrasjon for ett selskap med begrensede scopes. Gi da først bare scopes som trengs for lesing, og utvid tilgangen for en konkret arbeidsflyt når du vet hvilke endepunkter den bruker.

Unngå en delt, generell bruker med bred skriveadgang til hovedbok, bank, faktura, lønn og innstillinger. Opprett en personlig bruker-API-nøkkel for hver agent eller arbeidsflyt. Separate nøkler gjør det enklere å:

• Stanse én arbeidsflyt uten å påvirke andre.
• Se hvilken agent eller integrasjon som brukte nøkkelen.
• Begrense konsekvensen hvis en nøkkel kommer på avveie.
• Regenerere eller slette nøkkelen etter oppdraget.

API-nøkkelen skal aldri vises i rapporter, kommandologger eller feilmeldinger som deles videre. Masker også Authorization-headeren når agenten oppsummerer arbeidet.

Les eksisterende data før du skriver

Agenten må undersøke om objektet allerede finnes før den oppretter noe. Dette gjelder særlig kunder, leverandører, fakturaer, bilag, betalinger og vedlegg. Et nytt objekt kan være teknisk gyldig og likevel skape et regnskapsmessig duplikat.

Før et skrivekall bør agenten kunne svare på:

1. Hvilket eksisterende objekt gjelder oppgaven?
2. Hvilke felt er feil eller mangler?
3. Kan objektet oppdateres, eller krever tilstanden reversering eller nytt objekt?
4. Er perioden åpen, og er MVA eller annen rapportering allerede levert?
5. Hvilken dokumentasjon underbygger endringen?

Når et eksisterende bilag kan rettes korrekt og sporbarheten bevares, er det ofte bedre enn å lage enda et korrigeringsbilag. Agenten skal ikke velge en ny postering bare fordi det er enklere å programmere.

Skill mellom forslag og utførelse

Et godt forslag er konkret nok til at et menneske kan godkjenne det uten å rekonstruere analysen. Be agenten vise:

• Endepunkt og HTTP-metode.
• ID-ene til objektene som berøres.
• Dagens verdier og foreslåtte verdier.
• Regnskapsmessig effekt på konto, MVA, reskontro og periode.
• Dokumentasjonen som støtter forslaget.
• Hvordan endringen skal verifiseres.
• Hvordan den kan korrigeres hvis resultatet blir feil.

Godkjenningen bør gjelde dette konkrete forslaget. «Ordne regnskapet» er ikke en godkjenning til å sende et ukjent antall skrivekall.

Handlinger som alltid bør godkjennes

Krev uttrykkelig menneskelig godkjenning før agenten:

• Oppretter eller endrer betalinger.
• Sender faktura, purring eller annen kommunikasjon til en ekstern mottaker.
• Leverer MVA-melding, skattemelding eller andre myndighetsoppgaver.
• Lukker eller gjenåpner en avstemmingsperiode.
• Sletter, arkiverer eller reverserer regnskapsobjekter.
• Endrer åpningsbalanse eller posteringer i tidligere perioder.
• Gjør større masseendringer.

Godkjenning er særlig viktig fordi enkelte DELETE-operasjoner i ReAI kan arkivere eller reversere i stedet for å utføre en ren fysisk sletting. Agenten må lese OpenAPI-beskrivelsen og responsen, ikke anta effekten ut fra HTTP-metoden alene.

Bevar dokumentasjon og kontrollspor

For hvert oppdrag bør agenten lagre en kort arbeidsrapport med:

Oppdrag: Avstem bankkonto 1920 for januar
Tenant: 123 / Eksempel AS
Kilder: ReAI API og kontoutskrift januar.pdf
Lest: bankkonto, avstemmingsoversikt, posteringer
Foreslått: 3 matcher, 1 manglende bilag
Godkjent av: navn og tidspunkt
Utført: API-kall og berørte ID-er
Verifisert: nytt lesekall og kontrollsum
Avvik: bilag 456 må undersøkes manuelt

Rapporten skal inneholde objekt-ID-er og forklaringer, men ikke token, fødselsnummer, unødvendige bankdetaljer eller hele dokumentinnholdet. Oppbevar kildefilene separat fra agentens oppsummering.

Verifiser med et nytt lesekall

Et vellykket HTTP-svar er ikke det samme som et korrekt regnskap. Etter en endring skal agenten hente objektet på nytt og kontrollere:

• At de forventede feltene faktisk ble endret.
• At beløp, valuta, dato og tenant er riktige.
• At debet og kredit balanserer når det gjelder et bilag.
• At vedlegg fortsatt er koblet til riktig objekt.
• At reskontro, bankavstemming eller rapporter fikk forventet effekt.
• At API-et ikke svarte med en annen livssyklus enn agenten forventet.

Ved massearbeid bør agenten også sammenligne antall objekter og kontrollsummer før og etter. Små, avgrensede batcher er enklere å kontrollere og korrigere.

Stopp ved manglende API eller uklarhet

Agenten skal bruke ReAI sitt offentlige API. Hvis nødvendig funksjonalitet mangler, skal den beskrive det manglende endepunktet eller feltet og stoppe den delen av oppgaven. Den skal ikke omgå API-et med direkte databasetilgang, skjult nettleserautomatisering eller tilfeldige interne endepunkter.

Det samme gjelder faglig usikkerhet. Manglende dokumentasjon, uklar MVA-behandling eller tvil om tidligere rapportering er et kontrollpunkt, ikke et signal om å velge det mest sannsynlige svaret.

En praktisk kvalitetsport

Før agenten får lov til å skrive, bør alle svar være ja:

• Er riktig tenant og periode bekreftet?
• Har brukeren bare nødvendige rettigheter, eller er tenant-nøkkelen avgrenset til nødvendige scopes?
• Er eksisterende data lest og duplikater kontrollert?
• Finnes relevant dokumentasjon?
• Er forslag og regnskapsmessig effekt synlig?
• Er risikofylte handlinger godkjent av et menneske?
• Finnes en plan for verifisering og eventuell korrigering?

Begynn med oppsettet for AI-agent og ReAI API hvis nøkkel, arbeidsmappe og OpenAPI ikke er klart. Se deretter den konkrete arbeidsflyten for bankavstemming eller bilag og dokumentasjon .