Avvikelsemaskinen: när AI:n får agera, inte bara analysera

Jag ville bygga något som en VD eller ekonomichef känner igen sig i direkt. Inte ännu en chattruta, utan ett vanligt problem: månaden är stängd, siffrorna finns, och någon ska hitta det som inte stämmer innan bokslutet godkänns.

Resultatet blev Avvikelsemaskinen. Du genererar ett påhittat månadsbokslut för en fiktiv webbutik, maskinen gömmer ett par fel i siffrorna, och sedan släpper du loss ett AI-team som granskar framför ögonen på dig med riktiga modellanrop. Efteråt får du facit på vad de hittade och vad det kostar.

Den intressanta delen av bygget var inte tekniken. Det var när jag lät någon som gör det här på riktigt titta på min processdesign.

Vad jag ville uppnå

Demoportföljen hade en lucka. Dataresan visar hur siffror uppstår, hela vägen från ett klick till en rad i en dashboard. Men ingenting visade vad man sedan gör med dem. Och det är där en ekonomichef lever: siffrorna finns redan, frågan är vem som hittar avvikelsen och vem som agerar på den.

Jag ville också visa en sak som är lätt att säga och svår att bevisa: att jag vet var AI hör hemma i ett flöde och var den inte gör det. En demo där AI:n räknar hade varit fel byggd. Kalkyler ska räknas av kod, exakt och kontrollerbart. AI:n ska läsa, bedöma och formulera. Den skillnaden är hela poängen, och den går bara att visa genom att bygga den.

Hur jag tänkte

Grundidén var enkel: gör felen till ett spel. Maskinen planterar två eller tre fel i månaden, säger öppet att den gjort det, och låter besökaren jämföra sig med AI-teamet. Ett facit i slutet gör det ärligt åt båda håll, också när teamet missar något.

För att det skulle kännas som en riktig granskning delade jag upp arbetet på fyra roller med var sitt revir. Fakturajägaren läser leverantörsfakturorna, Marginalvakten budget mot utfall, Trendspanaren sex månaders historik. Redaktören väger deras fynd, ställer alltid en följdfråga tillbaka till en av dem, och skriver sedan utlåtandet till VD:n.

Två beslut satte jag tidigt och har hållit hårt i:

Specialisterna får aldrig facit. De planterade felen skickas inte in i någon prompt. Teamet granskar blint, precis som en människa med ett okänt bokslut, annars är facit-jämförelsen i slutet ingenting värd.

Ingen fritext skickas in. Klienten skickar bara ett slumptal, och servern bygger om exakt samma månad själv. Det gör demon rolig att leka med och samtidigt omöjlig att prompta sig igenom.

Vad jag skapade

Bygget kördes med tre agenter parallellt mot ett låst kontrakt: en typfil som beskrev datamodellen, eventprotokollet och exakt vilka funktioner alla skulle koda mot. En agent byggde API-orkestreringen, en byggde gränssnittet, och datagrunden fick jag skriva själv efter att den agenten avbröts två gånger av tekniska gränser. Det visade sig vara rätt fördelning ändå, eftersom generatorn är den enda filen där ett fel gör hela facit-mekaniken meningslös.

Siffrorna kalibrerade jag mot verklig e-handel och stresstestade över 400 genererade månader: bruttomarginal kring 55 procent, annonsering 13 procent av omsättningen, en tunn resultatmarginal på några få procent. Just för att marginalen är tunn svider felen, och det är det som gör igenkänningen.

Felen är heller inga tryckfel. Det är dubbelbetalda fakturor, en prenumeration som tyst klivit upp en nivå, en faktura registrerad i fel valuta, och kostnader som kryper uppåt snabbare än försäljningen. Sådant som faktiskt passerar en attest.

Sedan lade jag till den delen som gör att det ser ut som en maskin och inte en färdig tabell: siffrorna snurrar fram som på en enarmad bandit innan de låser sig, radvis, och först när rådatan satt sig räknas avvikelsekolumnerna fram i ett svep. Först data ur maskinen, sedan kalkylen. Den ordningen är inte pynt, den är hela pedagogiken.

Där jag hade fel

När granskningsdelen var klar ville jag ta demon ett steg längre. Att hitta ett fel är halva jobbet, någon ska ju agera på det. Min plan var rimlig på ytan: AI:n klassificerar avvikelsen, slår upp vem som äger kostnadsstället och skriver ett mejl till rätt person.

Innan jag byggde lät jag en verksam business controller granska designen. Det var det bästa jag gjorde i hela projektet, för hon rev upp den på fyra punkter.

Periodisering saknades helt. Ungefär sju av tio avvikelser i en månad handlar inte om fel, utan om timing. Fakturan kom inte in, eller två kom samma månad. Jag hade byggt en felkatalog och glömt den vanligaste förklaringen.

Bokslutet stängs på deadline oavsett. Det här var den riktiga smällen. Man kan inte vänta på leverantörens kreditfaktura till den femte. En controller bokar upp något nu, en periodisering eller en reservation, så att månaden blir rätt, och tar den administrativa matchen efteråt. Min design hade bara det administrativa spåret. Den var skriven av någon som aldrig suttit i en stängning.

Ingen ärendehantering. Ett bolag med åtta anställda bygger inte eskaleringstrappor för en avvikelse på 15 000 kronor. Fokus ligger på att förstå avvikelsen och få prognosen rätt.

Och terminologin var fel. Attestordning, rättelseverifikat, upplupen kostnad, väsentlighetsprincipen. Ord som en ekonom hör direkt om man använder dem slarvigt.

Jag byggde om efter det. Nu har varje ärende två spår: vad som bokas nu för att månaden ska bli rätt på deadline, och vilken uppföljning som sker efter stängningen. Den delningen är kortets hela poäng, och den kom inte från mig.

En sak till som jag höll fast vid: routingen ligger i kod, inte hos modellen. Vem som äger kostnadsstället och var beloppsgränsen går kommer ur en attestordning som går att granska. AI:n klassificerar och formulerar, men den bestämmer aldrig vem ärendet går till. Och ingenting skickas. Utkasten skrivs, människan godkänner.

Frågan alla ställer: får siffrorna lämna huset?

Den kommer inom en halv minut från alla som jobbar med ekonomi, och den är berättigad. I demon går anropen till Anthropics API. Det är oproblematiskt här, eftersom både bolaget och siffrorna är påhittade. På riktiga underlag är det en avtalsfråga innan det är en teknisk: leverantörsfakturor och kvitton innehåller personuppgifter, och hanterar man dessutom någon annans klientmaterial krävs personuppgiftsbiträdesavtal och besked till klienten om att AI används i handläggningen.

Så här skulle jag dela upp det:

Lokalt: allt som är identifierbart. Att läsa fakturor och kvitton är hög volym och låg svårighet, precis den sortens uppgift som inte behöver en frontier-modell. Det är också där personuppgifterna finns. Kör den delen på egen hårdvara så blir avtalsfrågan trivial i stället för besvärlig.

I molnet: principfrågorna, avidentifierade. "Hur ska en förutbetald licenskostnad periodiseras enligt K2" innehåller inga personuppgifter. Det är också där en stor modell är värd sitt pris.

I kod: allt som räknas. Aritmetiken, väsentlighetsgränsen, attestordningen. Den delen ska inte flytta någonstans alls, och den är redan så i demon.

Jag har inte byggt den lokala halvan. Jag har byggt molnhalvan och strukturen runt den, och det är strukturen som är det svåra. Ett byte av var modellen körs ändrar inte att koden räknar, att modellen föreslår och att människan attesterar. Det är hela poängen med att lägga reglerna i kod i stället för i prompten: de överlever ett modellbyte.

Resultat och lärdomar

Demon hittar sina planterade fel. I skarpa körningar tar granskningen runt en halv minut på sju modellanrop och landar på ungefär fyrtio öre. Teamet friar dessutom saker på eget bevåg, som två snarlika fakturor från samma fraktbolag som visar sig vara utrikes och inrikes, alltså inte en dubblett.

Det jag tar med mig är mest om arbetssättet:

Låt någon som gör jobbet granska processen innan du bygger den. Jag hade byggt en snygg demo av fel process, och den hade sett övertygande ut för alla utom för dem jag försöker imponera på. En halvtimmes granskning sparade ett halvt bygge och gjorde slutresultatet mycket vassare.

Att välja bort AI är också ett designbeslut. Kalkylen, väsentlighetsgränsen, attestordningen och facit ligger i kod. Det gör inte demon mindre AI-driven, det gör den granskbar. En ekonomichef som ser att AI:n inte räknar slappnar av på ett sätt som ingen brasklapp åstadkommer.

Parallella agenter behöver ett låst kontrakt. Tre agenter som bygger samtidigt fungerar bara om gränssnittet mellan dem är skrivet och orörligt innan de börjar. Det jag lade en timme på i förväg sparade ett dygns hopfogande.

Hur jag går vidare

Demon finns på svenska och engelska, med samma siffror på båda språken. Nästa steg är inte fler funktioner utan fler ögon: jag vill se var folk faktiskt tappar tråden, och om åtgärdsledet läses eller bara skummas.

Den intressanta fortsättningen är dessutom inte i demon. Det är att köra samma process på riktiga siffror, mot ett riktigt ekonomisystem, där rättelseverifikatet faktiskt bokas och utkastet faktiskt går iväg efter att någon tryckt godkänn.

Verktyg i den här processen

Claude – både byggpartner och de fyra rollerna i demon. Haiku 4.5 för specialisterna, Sonnet 4.6 för redaktören och åtgärdsledet.
Gemini – extern granskare av koncept och namn, och rollen som business controller i processgranskningen.
Next.js – sajten och API-routerna som orkestrerar modellanropen.