Problemet: fagsystemet svarer på feil spørsmål
Autoriserte regnskapsforetak er underlagt kvalitetskontroll fra Regnskap Norge. Kontrollen er dokumentbasert: byrået fyller ut et kontrollskjema og sender inn dokumentasjonen kontrolløren ber om.
Skjemaet dekker ti kontrollområder på to nivåer. Byrånivået spør om foretakets egne rutiner: risikovurdering, beredskapsplan, hvitvaskingsrutine, kvalitetsstyringssystem, etterutdanning. Oppdragsnivået spør om hver enkelt klient: oppdragsavtale, fullmakter, virksomhetsforståelse, kvalitetssikring av saldobalanse, årsregnskap og skattemelding med kvittering.
Før kontrollen må noen svare på hvert punkt. For hvert oppdrag. I et byrå med hundre klienter er det ukevis med arbeid, og det er den typen arbeid der du finner det du leter etter og går glipp av det du ikke tenkte på.
Den nærliggende løsningen er å spørre fagsystemet. PowerOffice Quality, der regnskapsforetak fører kvalitetsdokumentasjonen sin, vet hvilke oppgaver som er avkrysset som utført, av hvem og når.
Det er her gapet ligger. En avkrysset oppgave sier at noen mente de var ferdige. Kontrolløren spør om noe annet: finnes dokumentet, og holder innholdet mot kravet?
Første versjon av systemet vårt kontrollerte avkrysningsstatus i PowerOffice. Kunden ga tilbakemelding om at det ikke duger, og de hadde rett. Det ble det ufravikelige kravet resten av systemet er bygget rundt: en avkrysset oppgave i Quality kan ikke oppfylle et kontrollpunkt. Ikke delvis, ikke som støtte, ikke i kombinasjon med noe annet.
Versjon to leser dokumentene i stedet.
Hva systemet gjør
Det tar imot dokumentasjonen for ett kontrollsubjekt, enten en klient eller byrået selv, og svarer på ett spørsmål per kontrollpunkt: finnes dokumentasjonen kravet ber om, gjelder den på kontrolldatoen, og holder innholdet mål mot lovkravet?
Svaret er ett av fem: oppfylt, avvik, mangel, krever manuell vurdering, eller ikke aktuelt.
Ut kommer en avviksrapport med hjemmel, sitat og sidetall for hvert funn, en porteføljeoversikt på tvers av alle oppdrag, og de strukturerte funnene som fil. Rapporten du leser er en projeksjon av de strukturerte funnene, aldri omvendt. Det er derfor du kan spørre hvorfor et punkt er flagget og få bevisreferansen tilbake, i stedet for en gjetning basert på rapportteksten.
Hvordan det fungerer
Inntaket ser et sett filer for ett subjekt. En ZIP, en mappe, enkeltfiler eller et direkte oppslag mot Quality går inn samme vei og behandles likt.
Første versjon tok imot ZIP-er kunden lastet ned selv. Det var med vilje: vi ville ikke bygge en integrasjon før vi visste at kontrollen holdt. Nå henter systemet dokumentene rett fra kvalitetsmodulen. Det er ren lesetilgang, og systemet skriver aldri noe tilbake.
Det første settet vi fikk var en flat dump. Ingen mapper, ingen metadata, og omtrent halvparten av filnavnene var tilfeldige tegnrekker: en fil med et slikt navn viste seg å være en mva-kvittering fra Skatteetaten. Alle filene bar dessuten samme dato, nemlig dagen noen lastet dem ned fra fagsystemet.
Det avgjorde to designvalg. Dokumenter kjennes igjen på innhold, ikke filnavn. Og datoer leses ut av teksten i dokumentet, ikke av filsystemet.
Derfra går det i faste steg. Tekst og datoer trekkes ut. Dokumentene klassifiseres mot en lukket typeliste, først med signaturregler og deretter med språkmodell for resten. Kontrollpunktene bindes til de dokumentene som er relevante. Så kjører de deterministiske reglene: finnes, riktig periode, alder, frist, konsistens, omfang.
De reglene er porten. Språkmodellen kjører først etter at de har passert, og bare på punkter som krever en innholdsvurdering.
Alt evalueres mot en oppgitt kontrolldato, aldri mot dagens dato. Det gjør kjøringene reproduserbare, og lar byrået simulere kontrollbesøket før det skjer.
Hva systemet ikke har lov til å gjøre
Det er lett å skrive i en instruks at språkmodellen skal være forsiktig. Det er noe annet å gjøre det umulig for den å la være. Dette er ikke retningslinjer i et dokument. Det er bygget inn i koden og låst av over 800 automatiske tester.
Det kan aldri oppgradere et funn. Språkmodellen kan bekrefte eller nedgradere, aldri gjøre en mangel om til oppfylt. Systemet kan felle, aldri frikjenne. Asymmetrien er med vilje: en maskin som kan frikjenne, er en maskin som kan ta feil på den dyre måten.
Det kan ikke påstå noe uten bevis. Hvert funn peker på en navngitt regel, eller på et sitat med sidetall fra et konkret dokument. En vurdering uten gyldig sitat nedgraderes automatisk til krever manuell vurdering.
Det påstår ikke fravær før alt er lest. Er det dokumenter systemet ikke har klart å lese, nekter det å hevde at noe mangler, og kontrollen avslutter med feilkode. En kontroll over et halvlest sett skal ikke se ut som en ren attest.
Hva vi har kjørt det på
Systemet er bygget sammen med et autorisert regnskapsforetak som har dokumentbasert kontroll i høst. Dette er ikke en uforpliktende pilot. Behovet var reelt, og rapportene skal stå seg foran en ekte kontrollør om få uker.
Oppdragsnivået ble først kjørt mot dokumentasjonen for én oppdragsgiver: 59 dokumenter i tre ZIP-filer. Deretter er kontrollen kjørt mot hele oppdragsporteføljen, rundt 4 400 dokumenter hentet rett fra fagsystemet.
Det er der integrasjonen slutter å være en teknisk detalj. 59 filer kan et menneske laste ned manuelt. 4 400 dokumenter er ikke en arbeidsflyt, det er en unnskyldning for å la være.
Tre funn fra de kjøringene sier mest om hva som skiller dokumentkontroll fra avkrysningskontroll:
Et dokument som tilhørte en helt annen oppdragsgiver lå arkivert i feil klientmappe. Konsistenssjekken på organisasjonsnummer fant det ikke, fordi dokumentet ikke inneholdt ett eneste nisifret tall. Sjekken ble utvidet til å se etter firmanavn som ikke hører hjemme, og da dukket det opp.
Bankavstemminger gjaldt feil regnskapsår. Filen het riktig. Innholdet gjorde det ikke.
Og i en del av oppdragene mangler Quality selv signeringsdato på oppdragsavtalen. Det er ikke et avvik, og rapporten sier at det ikke er et avvik: en dato i et fagsystem oppfyller ikke kravet, og et tomt felt beviser ikke at avtalen mangler. Men det er stedene fagsystemet ikke vet noe, og der ville en kontrollør sett først.
Byrånivået kjører også, men rapporterer foreløpig mangel på alt, fordi byråets egen rutinedokumentasjon ennå ikke er levert inn. Den rapporten fungerer i praksis som innhentingsliste.
Hvordan vi vet at sperrene holder
Vi kjørte en strukturert stresstest mot vår egen motor. Ikke en gjennomgang av om koden så pen ut, men et forsøk på å bryte garantiene over. Den fant elleve svakheter.
Noen var at systemet krasjet i stedet for å gi beskjed, for eksempel når en fil var låst av en synkronisering. Noen kunne gjøre rapporten usann uten at noe så galt ut: dokumenter i undermapper ble oversett, slik at motoren kunne melde mangel om noe som lå der hele tiden. Og én var en ekte svakhet i sitatkontrollen, der en normalisering av tegn gjorde at et sitat kunne gjenfinnes i et dokument som sa noe annet.
Alle elleve er rettet, hver med en test som holder feilen lukket.
Deretter gikk rettelsene gjennom to uavhengige kritiske gjennomganger. De fant seks nye problemer, og fire av dem var innført av rettelsene selv.
Det siste er det viktigste vi har lært. Retting introduserer feil. Et system som ikke reviderer sine egne rettelser, har ikke kontroll, det har optimisme.
En presisering vi insisterer på, også internt: antall grønne tester er ikke et mål på faglig treffsikkerhet. Det er et mål på at feil vi har funnet, ikke kommer tilbake. De to er ikke det samme, og alle som blander dem selger deg noe.
Status, og hva som ikke er bygget
Vi sier dette rett ut, fordi et system som overselger seg selv er nøyaktig den feilen produktet finnes for å hindre.
56 kontrollpunkter er bygget, fordelt på ni av skjemaets ti områder. Det ene som ikke er dekket, lar seg ikke kontrollere: det spør hvilken foretaksform byrået har og hvor stor omsetningen var, altså opplysninger byrået oppgir, ikke krav som kan brytes. To enkeltpunkter gjenstår også, og begge står oppført med grunn.
Rapporten sier dette selv. Øverst står et forbehold som navngir områdene den ikke dekker og hvorfor. Forbeholdet krymper av seg selv når områder bygges ut.
Vi publiserer også svakhetene vi kjenner til, i dokumentasjonen kunden får. Skannede dokumenter uten tekstlag leses ikke. Årstall som står langt inne i et regneark blir oversett. Begge deler fører til krever manuell vurdering, aldri til en godkjenning.
En ren rapport betyr aldri at dere er klare. Den betyr at det ikke ble funnet avvik i det som faktisk ble kontrollert. Et verktøy som lar deg tro du er ferdig, er verre enn ingen verktøy.
Motoren vet ikke at den driver med regnskap
Systemet består av to deler som holdes strengt adskilt.
Motoren tar imot filer, trekker ut tekst og datoer, kjenner igjen dokumenttyper, kjører regler, krever bevis og skriver rapport. Reglene den kan kjøre heter finnes, periode, frist, konsistens og omfang. Ingen av dem er bransjespesifikke.
Kontrollpunktene er den andre delen. De ligger som tekstfiler, én per kontrollområde, med lovhenvisning og kontrollørinstruks gjengitt ordrett fra skjemaet. De er data, ikke kode. Det er de som vet at dette handler om oppdragsavtaler og skattemeldinger.
Vi bygde det slik fordi kravet var at nye kontrollår skulle kunne legges til uten kodeendring. Regelverk endrer seg oftere enn programvare bør. Nytt kontrollår er en ny mappe.
Det samme gjelder en ny bransje.
Hvor ellers dette hører hjemme
Anlegg er det nærmeste eksempelet. En entreprenør sitter på samsvarserklæringer, sertifikater med utløpsdato, HMS-planer, avviksbehandling og sluttdokumentasjon. Spørsmålene er identiske: finnes dokumentet, gjelder det dette prosjektet, er sertifikatet fortsatt gyldig på den datoen som gjelder, og hører papiret til den underentreprenøren det sier det hører til.
Samme mønster finnes i transport, næringsmiddelproduksjon, helse og bemanning. Fellesnevneren er ikke bransjen. Det er at noen med myndighet kommer og ber om dokumentasjon mot en liste, og at listen er lang nok til at manuell gjennomgang blir en flaskehals.
Vi har ikke levert dette i anlegg ennå. Det vi har, er en motor der bransjekunnskapen ligger i tekstfiler noen kan lese og rette, framfor å være støpt inn i koden. Forskjellen mellom regnskap og anlegg er den mappen, ikke maskineriet under.
Det betyr også at en ny bransje er ærlig arbeid, ikke en bryter vi skrur på. Kontrollpunktene må skrives av noen som kjenner kravene, og de må testes mot ekte dokumenter. Det er den delen som tar tid, og den delen som er verdt å gjøre riktig.
Hva betyr dette for dere?
Poenget er ikke at AI leser dokumenter. Det gjør mange verktøy.
Poenget er at forskjellen mellom en påstand og et funn er et sitat du kan slå opp, og at den forskjellen må være bygget inn i systemet framfor å være noe leverandøren lover.
Jobber dere i en bransje der noen kommer og ber om dokumentasjon mot en liste, er det verdt en samtale. Kontrollpunktene deres er andre. Spørsmålene under er de samme.
AI starter ikke med teknologi. Den starter med struktur.
Book 30 minutter, så viser vi deg en ekte rapport →
Les også: Hvem har ansvaret for AI i bedriften? Derfor bør dere ha en AI-komité · MCP: broen til systemene deres