OpenAI's skatteagent I dansk kontekst

OpenAI og Thrive Holdings har offentliggjort en case, hvor en Codex-drevet skatteagent landede 97 % nøjagtighed på 7.000 selvangivelser fordelt på over 30 amerikanske revisionsfirmaer. Tallet er imponerende på sin egen måde.

Den reelle pointe er det loop, der ligger bag tallet. Agenten bliver løbende bedre ved at lære af de rettelser, revisorerne foretager, og omsætter dem til konkrete forbedringer i kodebasen. Vi går igennem, hvad de byggede, hvorfor mønstret rækker langt ud over skat, og hvordan en dansk variant kunne se ud i praksis.

Hvad OpenAI og Thrive faktisk byggede

Casen handler om en AI-agent kaldet Tax AI, der hjælper amerikanske revisorer med at udfylde selvangivelser. Agenten ekstraherer felter fra kildedokumenter, mapper dem til den korrekte placering i skatteberegningen, og afleverer et udkast, revisoren kan godkende eller rette. Under hele forløbet logges den fulde sporing: kildefil, ekstraheret felt, citation, mapping til skattemotoren, revisorrettelse og endeligt indberettet tal.

Tallene i sig selv er ikke små. 7.000 selvangivelser, over 30 revisionsfirmaer, en tredjedel sparet forberedelsestid, 50 % højere gennemløb, og op til 97 % nøjagtighed på det færdige udkast. Ved lancering ramte kun 25 % af selvangivelserne 75 % korrekt feltkomplethed. Seks uger senere var det tal 86 %, og på tværs af de højeste tærskler steg systemet jævnt over hele sæsonen.

Den underliggende model er bygget oven på Codex, OpenAI's agentic AI-kapacitet til kode. Det interessante ligger i, hvad Codex får lov til at gøre i loopet. Modellens størrelse er sekundær. Den læser produktions-traces, identificerer mønstre i revisorernes rettelser, og foreslår konkrete kodeændringer, der lukker fejlmønstrene. Mennesket holder fortsat hånden på rattet, mens det daglige arbejde med at jagte edge cases bliver flyttet over på agenten. Du kan læse OpenAI's egen gennemgang af casen for de tekniske detaljer.

Self-improvement-loopet, trin for trin

Loopet er enkelt at beskrive og svært at bygge ordentligt. Det består grundlæggende af fem skridt, der ligner et almindeligt produkt-engineering-forløb mere end et ML-research-setup.

Først logger systemet alt fra ekstraktion til endeligt tal i en granuleret trace. Når en revisor retter et felt, gemmes både det fejlbehæftede output, kildedokumentet, mapping-logikken og den korrekte værdi. Det er produktets baseline. Uden den granularitet kan du ikke senere placere ansvaret det rigtige sted, når det går galt.

Dernæst aggregeres rettelserne. Når den samme type fejl optræder flere gange på tværs af klienter, ophøjes mønstret til et eval-target. Det betyder, at fejlen får sin egen test-case, der kan køre automatisk hver gang en kandidat-fix er klar. Det er hele forskellen mellem en agent, der "ser smart ud" og en agent, der bevisligt bliver bedre.

Tredje skridt er at give Codex en afgrænset opgave med fuld evidens: trace-data, citation til den relevante regel, kodeeksempler, eval-kommandoer og en konkret bestået-betingelse. Agenten arbejder i en sandbox med adgang til repoet, ikke i et frit promptfelt. Den opfører sig som en ny kollega, der lige er taget ind i teamet og har fået adgang til kodebasen.

Fjerde skridt er menneskelig review. Når Codex foreslår en ændring, gennemgår en ingeniør den, ligesom man ville gøre med en pull request fra en kollega. Tvetydige sager routes tilbage til ingeniøren, før de når Codex i det hele taget. Human-in-the-loop holder kvaliteten oppe og fanger de fejl, agenten ellers ville sende videre.

Femte skridt er deployment og ny baseline. Når en fix er shipped, genererer den nye produktionsdata, der bliver input til næste cyklus. Og her ligger hele pointen. Det her er produkt-engineering med en agent som arbejdshest, langt mere end det er ML-research. Det svære arbejde ligger i trace-designet og eval-arkitekturen, og det ligger hos dig.

Hvorfor mønstret er vigtigere end skatte-casen

Skat er en oplagt første demo for et selvlærende loop, fordi domænet er nemt at teste mod. Felterne er strukturerede, sandheden er entydig (et tal er enten korrekt eller ej), og rettelserne kommer fra fagfolk med dyb domæneviden. Det er ideelt for en bounded eval.

De samme egenskaber genfindes i mange B2B-discipliner. Bogføring har strukturerede konteringer og en fagprofessionel, der retter dem. I juridiske kontrakter findes en klausul enten eller mangler. Forsikringsskader har en sagsbehandlers afgørelse som facit, og lønadministration har klare indberetningsregler. Fælles for dem alle er, at der findes et objektivt korrekt svar at måle imod.

Det er disse egenskaber, der gør et self-improvement loop muligt at bygge. Hvis du har dem, kan du lave det. Hvis du ikke har dem, vil agenten i bedste fald give dig en chatbot uden læringsmekanik. Det skal være muligt at sige objektivt, hvad et korrekt output er, og det skal være muligt at observere, hvad praktikeren rettede til.

Den største værdi i OpenAI's case ligger i selve mønstret, mere end i skatten. Det er den slags arkitektur, du som leder af et fagligt selskab bør studere, uanset om dit domæne hedder revision, jura eller bogføring. Den vil blive kopieret i mange vertikaler de kommende år.

Den danske kontekst er anderledes

Det første, du skal bide mærke i, hvis du tænker en dansk udgave, er, at den amerikanske case ikke kan kopieres 1:1. I USA er privatpersoners selvangivelser et reelt manuelt arbejdsstykke. Du skal samle dine W-2'er, dine 1099'er, dine K-1'er, dine rentals og udfylde det hele selv eller via en revisor.

I Danmark er privatborgerens årsopgørelse forudfyldt fra eIndkomst, banker, pensionsselskaber og ejendomsregistre. Skatteyderens job er som regel at godkende det, skattevæsenet allerede har beregnet. Skattestyrelsen kører oven i købet selv AI-løsninger på forskuds- og årsopgørelser. Den danske borger har ikke et stort uudtømt problem her.

Smerten i Danmark ligger et andet sted: hos revisorerne og skatterådgiverne, der laver det komplekse arbejde for virksomheder og hovedaktionærer. Oplysningsskema for selskaber, sambeskatning, virksomhedsordningen, kapitalafkastordningen, udlejning af fast ejendom, beskatning af udenlandske værdipapirer, momsklassificering ved blandet aktivitet, transfer pricing for SMV'er og dobbeltbeskatningsforhold under DBO'er. Det er alt sammen områder, hvor en self-improving agent ville have et reelt mandat.

Køberen er revisionshuset, ikke skatteyderen. BDO, Beierholm, Redmark, Inforevision, de mellemstore regionale huse og over 1.000 mindre revisorer lever af præcis det arbejde. Det er en klassisk B2B-go-to-market.

Datafundamentet i Danmark er stærkere end du tror

Det første offentligt tilgængelige aktiv er Den juridiske vejledning fra Skattestyrelsen. Den dækker hele paletten fra personbeskatning til selskabsskat, moms, told, ejendom og inddrivelse. Den opdateres halvårligt, og den er bindende for Skatteforvaltningens medarbejdere. Det betyder, at den både er autoritativ og struktureret nok til at indeksere i en vector-database som en RAG-baseline.

Oven på det har du SKM-afgørelser fra Landsskatteretten og Skatterådet, bindende svar fra Skatterådet, lovgivning på Retsinformation.dk, og hele tankesættet fra TAX.DK og Karnov, der allerede strukturerer reglerne kommercielt. Det er en betydelig mængde fagligt korpus, og det meste er offentligt tilgængeligt.

På datasiden findes der API-integrationer mod TastSelv Erhverv, primært til moms, men fundamentet er der. Bogføringsdata kan trækkes fra e-conomic, Billy, Dinero, Visma og Uniconta gennem etablerede API'er. CVR-registeret er åbent. Erhvervsstyrelsens regnskaber er offentligt tilgængelige. Du har altså både regelgrundlag og transaktionsdata at koble sammen.

Sammenlignet med USA, hvor skatteloven er fragmenteret mellem føderal og statslig praksis, og hvor regelpraksis ligger spredt på tværs af mange myndigheder, har Danmark én autoritativ kilde. Det er en klar fordel, når du skal bygge en agent, der skal kunne forklare og citere sin egen logik.

Byggeguide: sådan kunne en dansk variant se ud

Det første og vigtigste valg er at afgrænse domænet skarpt. Gå efter noget langt snævrere end "skat" eller "selskabsskat". Eksempelvis "oplysningsskema for holdingselskaber uden datterselskaber". Et snævert domæne giver dig mulighed for at lukke loopet hurtigt, før du udvider scope. OpenAI startede heller ikke med hele skattekoden, de startede med rental-properties og udvidede derfra.

Andet skridt er at finde to til tre partnere blandt mellemstore revisionshuse. Du skal have adgang til faktiske produktionssager, og du skal have ingeniørmæssig villighed til at bygge trace-infrastrukturen ind i deres workflow. Det er hverken hurtigt eller billigt, men det er hele forskellen mellem en demo og et selvlærende system. Behandl partneren som medudvikler på løsningen. Det er den rolle, der får trace-infrastrukturen bygget rigtigt.

Tredje skridt er at indeksere Den juridiske vejledning i en vektor-database. Vi bruger selv pgvector med nomic-embed-text via Ollama, men valget af stack er sekundært. Det vigtige er, at agenten har autoritativ regelreference at citere, og at citationen følger med outputtet. En agent uden citation er en agent, du ikke kan stå inde for over for en kunde.

Fjerde skridt er at designe trace-formatet. Det er den mest undervurderede del af opgaven. Et trace skal indeholde kildedokumentet (fx revisorens scan eller PDF-bilag), den ekstraherede værdi, hvilken regelcitation der blev brugt, hvilket felt i oplysningsskemaet den endte i, hvad revisoren rettede den til, og den endeligt indberettede værdi. Uden den granularitet kan du ikke lokalisere, hvor i kæden fejlen opstod, og så bliver self-improvement-loopet til gætværk.

Femte skridt er at bygge eval-suiten ud fra praktiker-rettelser. Når den samme type rettelse optræder fem gange på tværs af klienter, bliver det et eval-target med konkret pass-betingelse. Det er her engineering-disciplinen ligger. Du skal være villig til at oversætte revisorens "det her er forkert" til en testbar betingelse. Det er typisk svært, og det er typisk her ambitiøse projekter strander.

Sjette skridt er at sætte ingeniøragenten ind i loopet. Codex, Claude Code eller en lignende agent med adgang til repo, evals og trace-data. Agenten får snævre opgaver med menneskelig review på hver ændring. Den arbejder inde i produktet sammen med dine ingeniører, præcis som OpenAI beskriver det, som en arbejdshest under deres opsyn.

GDPR er ikke en sidebemærkning. Skattedata er særligt følsomt, og databehandleraftaler med revisionshusene skal være på plads, før første sag køres gennem systemet. Lokal inferens eller EU-hosted modeller er ikke valgfrit her. I vores egen stack ville en lokal model køre ekstraktion og førstegangs-mapping, mens grovere ingeniøropgaver kan ligge på frontier-modeller med EU-residency. Det er en arkitekturbeslutning, der skal tages tidligt, fordi den påvirker hele stack.

Hvorfor MCP gør det realistisk for danske SMV'er

For tre år siden ville et projekt som dette have krævet en større ingeniørorganisation. I dag er det reelt overkommeligt for et mindre konsulenthus med den rigtige arkitektur. Model Context Protocol (MCP) har fundamentalt ændret omkostningsstrukturen for at integrere AI mod eksisterende systemer.

I praksis betyder det, at du kan bygge én MCP-server per kilde (Den juridiske vejledning, e-conomic, TastSelv Erhverv, dit eget trace-store) og lade agenten orkestrere kald på tværs. Du slipper for at bygge én stor monolitisk integration, og du kan iterere på hver kilde isoleret. Det er ikke et tilfælde, at vi selv har bygget en MCP-flåde for Consile på områder som GSC, Google Ads, HubSpot og vores egen interne videnbank. Mønstret virker.

Det betyder også, at en dansk skatteagent ikke behøver at være en mastodont fra dag ét. Du kan starte med et enkelt domæne, én MCP-integration mod et revisionshus' bogføringssystem, ét eval-target, og udvide derfra. Det er hele forskellen mellem et projekt, der kan finansieres af én pilot, og et projekt, der kræver venturefinansiering.

Mønstret rækker længere end skat

Hvis du leder en virksomhed med fagspecialister, der jagter edge cases manuelt, har du grundlæggende det samme problem, som amerikanske revisorer havde. Bogføring, debitorstyring, kontraktreview, skadebehandling, lønindberetning, momsklassificering, GDPR-audits, ISO-compliance. Det er alle domæner med strukturerede regler, eksperter med fejlrettelsespræference, og gentagne mønstre, der kan løftes ind i evals.

Spørgsmålet er ikke længere "skal vi have AI", men "kan vi designe en trace, vi kan lære af". Hvis svaret er ja, har du fundamentet til et self-improving loop. Hvis svaret er nej, skal du arbejde på dataopsamlingen først, før du arbejder på modellen. Det er den rækkefølge, der adskiller projekter, der lykkes, fra projekter, der bliver til dyre demos.

Det er pointen at tage med fra OpenAI's tax-case. Modeller udvikler sig hurtigt, men trace-design og eval-arkitektur er produktarbejde, der står i mange år. Det er det fundament, der lader en agent blive bedre i morgen end den var i dag, og det giver renters rente i en B2B-forretning.