Synlige og usynlige AI-implementasjoner

Velkommen til Revisjonskunde AS. Her har økonomiavdelingen implementert et nytt AI-system som avstemmer kundereskontroen mot hovedboken og foreslår forklaringer på differanser. I anskaffelsesprosessen ble AI-spesifikke risikoer vurdert, og i implementasjonsprosjektet ble det gjennomført opplæring og utarbeidet oppdaterte prosessbeskrivelser. Medarbeidere går gjennom resultatet og godkjenner avstemmingen.

Når det gjelder tapsavsetninger, er prosessbeskrivelsene uendret. I år som i fjor sier prosesskartet at controllerne vurderer forfalte kundefordringer, undersøker usikre poster og dokumenterer behovet for tapsavsetning. Controllerne er de samme, regnskapssystemet er det samme, og kontrollene blir gjennomført til avtalt tid. Men arbeidsmåten er likevel ny av året: Controllerne henter ut en reskontro, gir den til sin generelle AI-assistent og ber om en vurdering av hvilke fordringer som bør undersøkes. Listen blir kortere, forklaringene bedre formulert og arbeidet unnagjort før lunsj. Når økonomisjefen spør, er svaret at tapsvurderingen er gjort som vanlig.

Begge endringene kan ha betydning for risikoen for vesentlig feilinformasjon. Men bare den ene er synlig i prosessbeskrivelsen. Spør revisor om selskapet har innført nye systemer, blir den nye AI-drevne avstemmingsfunksjonen et tema. Spør revisor om implementasjon av nye systemer for hvordan tapsvurderinger gjøres, kan svaret bli nei, selv om de praktiske konsekvensene av controllernes bruk av generelt AI-verktøy kan være vel så store som prosess-spesifikke systemimplementasjoner. Lokale regneark og uformelle arbeidsmåter er klassiske utfordringer for revisors prosesskartlegging. Generelle AI-verktøy gjør det enklere å overlate også utvelgelse, forklaringer og deler av skjønnsutøvelsen til et verktøy, uten kontrollerte og sporbare implementasjonsprosjekter: Endringer kan skje hos én digitalt fremoverlent medarbeider, mellom systemuttrekket og den ferdige vurderingen, uten teknisk integrasjon med regnskapssystemet.

Revisjonens grunnprinsipper gir fortsatt et godt utgangspunkt. Oppgaven er å forstå og vurdere de ulike prosessene hos kunden, før revisor vurderer risiko og velger revisjonshandlinger. I denne artikkelen drøfter vi tre konstruerte situasjoner:

• avstemming med et prosess-spesifikt AI-verktøy,

• utarbeidelse av et regnskapsestimat med et generelt AI-verktøy, og

• en arbeidsflyt med flere AI-agenter.

Hva gjør verktøyet og hva gjør mennesket?

Kunstig intelligens, forkortet AI eller KI, kan inngå i både prosess-spesifikke løsninger og i generelle AI-assistent-verktøy. Generelle AI-verktøy som Copilot, Claude, og ChatGPT kan produsere (blant annet) tekst, kode og regneark-analyser ut fra brukerens instruksjoner. Med «AI-agent» mener vi programvare som med støtte fra AI kan utføre flere sammenhengende arbeidstrinn, og bruke andre tilgjengelige systemer og verktøy innenfor gitte rammer.

For revisor er løsningenes rolle i regnskapsprosessen avgjørende. Én og samme assistent kan forklare en Excel-formel for én medarbeider og foreslå tapsavsetningen for en annen. Begge kaller det kanskje å «effektivisere rutinearbeid», men de har gitt verktøyet vidt forskjellige oppgaver.

«Vi bruker AI til avstemming» er omtrent like presist som «vi bruker Excel til avstemming». Revisor trenger å forstå hvilke data som hentes, hvordan sammenligningen gjøres, hvem som undersøker differanser, og om løsningen kan bokføre korreksjoner. Statiske ekspertregler, vanlige beregninger og en AI-løsning kan inngå i det som i prosesskartet er tegnet inn som ett steg. Her vil feil oppstå på ulike måter og kreve ulike kontroller.

Her er tre eksempelvarianter som alle kunne sortert under en «Vi bruker AI til avstemming»-beskrivelse:

AI-verktøy beregner differanser og foreslår forklaringer. Medarbeideren undersøker forklaringene mot underliggende dokumentasjon og følger opp avvikene.

AI-verktøy gir de samme forslagene, men medarbeideren godkjenner samlet uten å gå inn i ett og ett forslag, fordi forklaringene erfaringsmessig har virket rimelige.

AI-verktøy beregner differanser, foreslår forklaringer, og bokfører korrigeringer av differanser ved behov, uten menneskelig kontroll og godkjenning.

I den første varianten kan medarbeiderens etterprøving være en relevant kontroll. I den andre kan kontrollen ha mistet innhold uten at noen har besluttet å svekke den. Forslagene har som regel stemt, tidspresset er stort, og samlet godkjenning kan være enklest og mest nærliggende i brukergrensesnittet.

I den tredje varianten produserer løsningen også regnskapsinformasjon. Den kan lage feil posteringer, og en eventuell tidligere kontroll før bokføring er tatt bort. Revisor må skille mellom feilmulighetene i transaksjonsbehandlingen og kontrollene som skal håndtere dem. Hvem har gitt løsningen bokføringstilgang? Hvem kan endre terskler og regler? Kan posteringene identifiseres og følges tilbake til grunnlaget?

Her er de etablerte risikobegrepene nyttige. Iboende risiko gjelder muligheten for vesentlig feilinformasjon før tilhørende kontroller tas i betraktning. Kontrollrisiko gjelder faren for at foretakets kontroller ikke forhindrer eller avdekker og korrigerer slik feilinformasjon i tide. Revisjonsrisikoen omfatter også oppdagelsesrisikoen knyttet til revisors handlinger. Vi trenger ingen egen «AI-faktor», men vi trenger en presis beskrivelse av hvilke verktøy som brukes, hva de gjør, og hvor feil kan oppstå.

ISA 315 krever at revisor opparbeider seg forståelse av IT-bruk og vurderer utforming og implementering av identifiserte kontroller. Dersom revisor ikke planlegger å teste kontrollenes effektivitet, skal vurderingen av kontrollrisiko ikke gi en lavere vurdert risiko for vesentlig feilinformasjon enn den iboende risikoen.^{*ISA 315 punkt 25–26 og 34. Punkt 26 omfatter også relevante IT-applikasjoner, risiko som følge av bruk av IT og generelle IT-kontroller. ISA 315}

AI-genererte forklaringer kan ikke erstatte undersøkelser

Anta at avstemming viser en differanse på 180 000 kroner. I vårt eksempel kommer reskontro og hovedbok fra to systemer, og overføringen mellom dem er et eget trinn. Basert på tidspunktene for posteringene og uttrekkene, og læring fra tidligere godtatte forklaringer, foreslår et avstemmings-AI-verktøy at avviket skyldes at en innbetaling er registrert i reskontroen, men først overført til hovedboken etter at hovedbokuttrekket ble tatt. Medarbeideren synes forklaringen virker fornuftig og lukker avviket, uten å ta stilling til hvilke konkrete undersøkelser som er gjort.

Men finnes innbetalingen? Er beløpet riktig? Viser overføringsloggen at den faktisk ble overført senere? Og skal uttrekkene oppdateres før avstemmingen kan ferdigstilles? Forklaringen peker på noe som kan undersøkes, men den underbygger ikke seg selv.

Risikoen ligger i at menneskets arbeid har skiftet innhold. Den som tidligere undersøkte differansen, har begynt å godkjenne en ferdig formulert forklaring. Men en tekst kan være velskrevet lenge før den er velbegrunnet.

Den samme forklaringen kan også havne i revisors arbeidspapirer. Kravet til profesjonell skepsis gjelder selv om kundens dokumentasjon er ryddig og språket selvsikkert.^{*ISA 200, punkt 13(c), (e) og (n), og punkt 15 om profesjonell skepsis. ISA 200} Revisor må undersøke hva forklaringen bygger på, og om bevisene faktisk støtter den.

AI-løsninger kan samtidig utformes slik at de forbedrer kontrollarbeidet. Den kan knytte forslaget til konkrete poster, vise hvilken dokumentasjon som mangler, og holde avviket åpent til oppfølgingen er dokumentert. Gevinsten ligger da både i teknisk utforming og i medarbeiderens arbeid. Den frigjorte tiden kan brukes på vanskelige differanser fremfor på å flytte tall mellom regneark.

Kontrollmålet setter også en grense for hva avstemmingen viser. To registre kan stemme overens og likevel inneholde den samme uriktige fordringen. Avstemmingen dokumenterer derfor ikke alene fordringenes eksistens eller verdsettelse. Dette må som før håndteres gjennom revisjonshandlinger tilpasset de aktuelle påstandene: Et raskere utarbeidet og penere utformet avstemmingsark utvider ikke kontrollens formål.

Når generelle AI-verktøy er med på vurderingene

I avstemming-eksempelet var bruk av avstemming-AI-systemet innlemmet i prosessbeskrivelsen, og enkelt for revisor å ta tak i. Den uformelle AI-bruken i tapsavsetning-eksempelet kan være vanskeligere å oppdage. Controlleren har ikke bestilt et nytt AI-system spesifikt for tapsavsetninger. Det generelle AI-verktøyet inngår bare «her og der» i dag-til-dag-arbeidet. Om det så brukes til å velge hvilke fordringer som skal undersøkes, kan løsningen ha stor påvirkning på hvilke tap som blir identifisert.

Et nyttig spørsmål er derfor: «Kan du vise meg hvordan du kom fra denne listen til den ferdige vurderingen?» Da følger samtalen arbeidsoppgaven. Medarbeideren trenger ikke først å avgjøre hva revisor mener med et «AI-system», og spørsmålet handler om faglig fremgangsmåte fremfor om mulig regelbrudd.

Revisor kan deretter undersøke hva verktøyet fikk se, hvilken oppgave det fikk, hva det svarte, og hva medarbeideren gjorde videre. Det er forskjell på å omformulere en ferdig tapsvurdering, velge hvilke kunder som skal vurderes, og foreslå størrelsen på avsetningen. Alle tre kan skje i samme samtale med AI-assistenten.

Tapsavsetning på kundefordringer er et regnskapsestimat. ISA 540 krever forståelse av hvordan ledelsen utarbeider estimatet. Hvis revisor tester ledelsens utarbeidelse, omfatter arbeidet blant annet metoder, viktige forutsetninger og data, samt valg av punktestimat og opplysninger om estimeringsusikkerhet.^{*ISA 540 (revidert), punkt 13 og 22–26. ISA 540} AI-bruken gjør spørsmålene konkrete.

Dataene kommer først. Tenk deg at assistenten bare fikk en aldersfordelt saldoliste. Den fikk ingen opplysninger om tvister, sikkerheter, kredittforsikring eller innbetalinger etter balansedagen. Likevel skrev den en overbevisende beskrivelse av kundenes betalingsevne. Teksten kan gi inntrykk av en bredere vurdering enn datagrunnlaget tillater.

Metoden må også frem. «Hvilke kunder bør vi se nærmere på?» er en annen oppgave enn «hvor stor bør avsetningen være?». Hvis assistenten foreslår en sats per aldersgruppe, har ledelsen vurdert om tilnærmingen passer kundemassen og regnskapsregelverket? Eller ble metoden i praksis valgt av verktøyet uten at noen tok stilling til den?

Deretter kommer forutsetningene. Et avsnitt om «normal betalingshistorikk» hjelper lite dersom ingen kan forklare hvilken historikk som er brukt. For en revisor er det et tydelig signal om behov for videre undersøkelser hvis begrunnelsen stopper ved at «verktøyet foreslo det».

Generative modeller kan dessuten gi ulike svar ved gjentatte kjøringer. Anta at samme grunnlag gir forslag om 400 000 kroner i avsetning ved én kjøring og 650 000 kroner ved den neste. Variasjonen beviser ikke at ledelsens endelige estimat er feil. Men den gjør det viktig å forstå hvilket forslag ledelsen valgte, hvorfor det ble valgt, og hvordan det ble etterprøvd. Undersøkes forskjellen, eller velges svaret som passer best med forventningen?

Det er også relevant å spørre hva som faktisk var likt mellom kjøringene. En ny fil, en endret instruks eller en annen modellversjon kan forklare forskjellen. Dokumentasjonen bør gjøre det mulig å skille slike endringer fra variasjon i selve modellens svar. Det avgjørende er ikke at teksten kan gjenskapes ord for ord, men at regnskapsvurderingen har et forståelig og etterprøvbart grunnlag.

Samme problemstilling kan oppstå ved prosjektinntekter. En AI-assistent kan anslå gjenstående kostnader eller oppsummere prosjektledernes rapporter før inntektene beregnes. Usikkerheten rundt fullføringsgrad og sluttprognose består. AI-bruken kan i tillegg endre både estimatprosessen og kontrollene. Hvis controlleren tidligere leste rapportene, men nå bare leser sammendraget, må revisor undersøke hva som kan ha falt ut, og hvordan det fanges opp.

Skillet mellom administrativ støtte og regnskapsmessig vurdering følger derfor bruken av resultatet. Språklig bearbeiding av en allerede underbygd vurdering kan ha begrenset betydning. Et sammendrag som avgjør hvilke problemer ledelsen får se, kan ha stor betydning. Oppgavens navn i prosesskartet forteller ikke nok, revisor må dykke inn i den og forstå konkret hvordan AI er brukt.

Dokumentasjonen må følge arbeidsoppgaven

Det nærliggende er å be om innsyn i samtaler med AI-assistenter som del av revisjonsarbeidet. En logg kan vise at controlleren ba om «en forklaring på differansen», uten å be verktøyet undersøke om forklaringen var riktig. Den kan også vise om AI-assistenten tok stilling til spørsmål som datagrunnlaget ikke ga dekning for.

En eksport er likevel ikke automatisk fullstendig. Vedlegg, tidligere meldinger eller informasjon fra tilkoblede systemer kan mangle. ISA 500 krever vurdering av informasjonens relevans og pålitelighet. Når revisor bruker informasjon produsert av foretaket, skal revisor etter behov innhente bevis for nøyaktighet og fullstendighet og vurdere om informasjonen er tilstrekkelig presis og detaljert for formålet.^{*ISA 500, punkt 7 og 9. ISA 500} En chatlogg må vurderes på samme måte som annet mulig revisjonsbevis.

Det er dessuten forskjell på dokumentasjon av en konkret regnskapsoppgave og innsyn i en ansatts samlede samtalehistorikk. Historikken kan inneholde personlige og irrelevante opplysninger. Tilgang til personopplysninger må ha et rettslig grunnlag og avgrenses til det som er nødvendig; rutinemessig innhenting av hele AI-samtalehistorikken er et dårlig utgangspunkt for å dokumentere én tapsvurdering.

For en regnskapsrelevant AI-oppgave foreslår vi at følgende følger vurderingen:

• Datagrunnlaget, med dato, avgrensning og relevante tilleggsopplysninger.

• Instruksen og oppsettet som er nødvendig for å forstå oppgaven.

• Resultatet som faktisk ble brukt.

• Medarbeiderens etterprøving og oppfølging av mangler eller avvik.

• Den endelige beslutningen og begrunnelsen for den.

Omfanget må tilpasses oppgaven. Ren språkvask som ikke endrer faglig innhold eller beslutningsgrunnlag, trenger normalt ikke samme dokumentasjon som et vesentlig estimat. Forslaget er ment å gjøre regnskapsarbeidet etterprøvbart, ikke å arkivere hver eneste samtale. Det gjør også virksomheten mindre avhengig av én person: Hvis controlleren slutter, bør etterfølgeren kunne forstå hvordan fjorårets avsetning ble laget.

Hyllevare fritar ikke kunden fra disse vurderingene. Når en leverandør er en serviceorganisasjon etter ISA 402, kan en type 2-rapport gi relevant bevis om kontroller hos leverandøren. Revisor må vurdere rapportens dekning, perioden og de kontrollene hos kunden som rapporten forutsetter, og teste kundekontrollene når det er nødvendig.^{*ISA 402, punkt 17 om bruk av type 2-rapport. ISA 402} Rapporten dekker ikke automatisk hvordan controlleren velger data eller følger opp et AI-generert forslag.

Den praktiske gjennomgangen bør derfor følge en bestemt vurdering eller avstemming fra grunnlag til beslutning. En demonstrasjon av hvordan medarbeideren ville gjort oppgaven i dag, kan gi prosessforståelse. Skal revisor undersøke hva som faktisk skjedde ved en tidligere avslutning, trengs dokumentasjon og andre bevis som belyser den utførelsen.

Hvem kontrollerer controller-agentene?

Tenk nå at controlleren har organisert avstemmingen rundt flere AI-agenter. Én henter regnskapsdata, en annen sammenholder postene, og en tredje foreslår avviksforklaringer. Controlleren undersøker unntak og godkjenner leveransen. Hvilke kontroller finnes i denne arbeidsflyten, og hva må revisor undersøke før de kan tillegges vekt?

Begynn med et avgrenset kontrollmål: Differanser mellom kundereskontro og hovedbok skal identifiseres og følges opp før avslutningen. Da kan arbeidsflyten deles i trinn som faktisk lar seg undersøke. Kanskje er den viktigste kontrollen en enkel sjekk av at uttrekkene gjelder samme periode og dekker alle relevante poster. «Agenten kvalitetssikrer regnskapet» gir mindre å arbeide med.

Vi foreslår å undersøke mandat, utførelse og oppfølging. Mandatet viser hvilke oppgaver og tilganger agenten har. Utførelsen viser hvilke data og verktøy som inngikk i en bestemt kjøring. Oppfølgingen viser hvem som undersøkte avvikene, og hvorfor de ble lukket. En AI-instruks beskriver ønsket atferd, men den dokumenterer ikke at atferden ble fulgt.

Sporbarheten må også ha et grunnlag utenfor agentens egen forklaring. Et sammendrag skrevet etter kjøringen er agentens fortelling om hva den gjorde. Registreringer av hvilke filer som ble lest, hvilke verktøy som ble brukt og hvilke posteringer som ble opprettet, kan belyse de faktiske handlingene. Også slike registreringer må vurderes for relevans, pålitelighet og fullstendighet før revisor bygger på dem.^{*ISA 500, punkt 7 og 9. ISA 500}

To agenter gir heller ikke automatisk to uavhengige vurderinger. Begge kan ha brukt det samme ufullstendige uttrekket eller bygget på samme feilaktige forutsetning. At de er enige, sier da lite om det som mangler. Revisor bør følge en mulig feil gjennom flere ledd og undersøke hvor den faktisk vil bli oppdaget.

Tester med vanskelige tilfeller kan belyse utformingen. Hva skjer hvis uttrekket mangler én konto, hvis en fil leses inn to ganger, eller hvis avviket ikke har noen tilgjengelig forklaring? Slike tilfeller kan prøves i et avskjermet testmiljø. En løsning som holder avviket åpent og sender det videre, kan være mer nyttig enn en som alltid finner noe å skrive.

Resultatene må knyttes til løsningen som faktisk var i bruk. En ny AI-instruks kan endre hvilke avvik som slås sammen, og en justert terskel kan endre hva som bokføres automatisk. Leverandøren kan også endre modellen. For vesentlige oppgaver foreslår vi identifiserbare versjoner av instrukser og oppsett, sammen med vurdering av relevante endringer. Ellers blir det vanskelig å vite hva en vellykket test i desember sier om arbeidet i mars.

ISA 330 krever tester av kontroller når revisor vil bygge på kontrollenes effektivitet, eller når substanshandlinger alene ikke gir tilstrekkelig og hensiktsmessig revisjonsbevis på påstandsnivå. Forespørsler alene er ikke nok for testing av kontrollens effektivitet, og beviset må dekke tidspunktet eller perioden revisor vil bygge på. Selv med effektive kontroller kreves substanshandlinger for hver vesentlig transaksjonsklasse, kontosaldo og tilleggsopplysning.^{*ISA 330, punkt 8–11 og 18, samt punkt 4(a) om substanshandlinger. ISA 330} Disse kan omfatte både detaljtester og analytiske substanshandlinger.

Når agenten kan bokføre, må revisor dessuten vurdere hvordan posteringene inngår i testingen som håndterer risikoen for ledelsens overstyring av kontroller. At en postering er automatisk, forteller ikke alene hvem som har påvirket grunnlaget eller instruksen.^{*ISA 240, punkt 32(a), om testing av posteringer og andre justeringer. Henvisningen gjelder den norske versjonen publisert i mars 2024. ISA 240} Tilgangsstyring og endringskontroll er del av forståelsen av arbeidsflyten.

Muligheten er likevel interessant. En godt avgrenset agentløsning kan dokumentere handlinger og synliggjøre uavklarte avvik bedre enn en manuell prosess. Der historikk og dokumentasjon mangler, må revisor søke andre bevis og vurdere konsekvensene for revisjonsopplegget. Flere detaljtester løser ikke nødvendigvis problemet hvis selve grunnlaget for å etterprøve arbeidet er borte.

Begynn med den siste vurderingen

Dette angår også mindre foretak, hvor én eller to personer gjør det meste av regnskapsarbeidet og prosesskartet kanskje aldri har eksistert. AI-bruken kan begrense seg til en generell assistent. Spørsmålet om hva den fikk se og hvordan svaret ble brukt, er like relevant.

Revisor kan ta utgangspunkt i den vanlige samtalen med daglig leder eller regnskapsfører og følge en konkret vurdering. Bruker kunden ekstern regnskapsfører, kan også regnskapsførerens arbeidsmåte være relevant. Omfanget av undersøkelsene må tilpasses oppdraget. En revisjonsstrategi med hovedvekt på substanshandlinger gjør det fortsatt nødvendig å forstå grunnlaget som handlingene retter seg mot.

Når revisor oppdager at en kontroll har mistet innhold, bør forholdet beskrives konkret. «AI-risiko» forteller ledelsen mindre enn at avvik nå lukkes uten dokumentasjon, eller at en AI-assistent i praksis velger hvilke kunder som skal vurderes uten at utelatte poster blir kontrollert. Manglene vurderes etter ISA 265. Vesentlige mangler skal kommuniseres skriftlig til dem som har overordnet ansvar for styring og kontroll. Standarden regulerer også kommunikasjon til ledelsen.^{*ISA 265, punkt 6(b) og 8–11. Standarden bruker betegnelsen «vesentlig mangel i intern kontroll». ISA 265}

Dialogen kan gi kunden et bedre grunnlag for å styre AI-bruken. Ledelsen kan avklare hvilke oppgaver verktøyene skal utføre, hvem som følger opp resultatene, og hvilken dokumentasjon som skal bevares. Revisor kan kommunisere observasjoner og konsekvenser, mens ledelsen må ta ansvar for utformingen og gjennomføringen av kundens kontroller.

Både prosess-spesifikke og generelle AI-verktøy kan gi kunden en raskere månedsavslutning og revisor et bedre dokumentert grunnlag. Forutsetningen er at noen kan vise hva AI-verktøyene gjorde, hva mennesket undersøkte, og hvordan avvik ble håndtert. En ryddig kontrollrapport er fortsatt bare utgangspunktet for spørsmålet om hva som faktisk ble kontrollert.

Ved neste prosessgjennomgang kan revisor begynne med den siste avstemmingen, det siste estimatet eller den siste avviksforklaringen og be den som gjorde jobben, konkret vise fremgangsmåten. Bruk av generelle AI-verktøy er sjelden tegnet inn i prosesskartet.

Sju spørsmål til neste prosessgjennomgang^{*Spørsmålene er forfatternes forslag til praktisk bruk, ikke en uttømmende eller autoritativ sjekkliste.}

1. Kan du vise hvordan du kom fra grunnlaget til den ferdige vurderingen?

2. Hvilke trinn gjør AI-verktøyet, og hvilke gjør du?

3. Hvilke data fikk AI-verktøyet, og hvilke fikk det ikke?

4. Hvordan undersøker du forslagene, og hva skjer om grunnlaget mangler?

5. Kan løsningen bokføre eller endre data, og hvem har gitt den tilgang?

6. Hvem kan endre instrukser, terskler og oppsett, og hvordan dokumenteres endringene?

7. Hva finnes igjen som viser hva som faktisk ble gjort av hvem, og hvordan resultatet ble fulgt opp?

Be gjerne om å få følge en vanlig kjøring, et reelt avvik, og å få se en situasjon der en har avdekket at AI-verktøyet kommer til kort.