Compliance-AI: så verifierar vi varje beslut

Vem som helst kan kalla sin AI förklarbar, ansvarsfull eller regelefterlevande. Det räcker att skriva orden på en hemsida och rita en ramverksbild med fyra rutor och pilar. Orden har blivit så billiga att de inte säger något längre. Frågan jag ställer till andra leverantörer, och som vi själva försökte svara på under en vecka i maj 2026, är enkel: hur bevisar ni det?

En revisor, en tillsynsmyndighet eller en it-chef på en bank som ska godkänna ett pilotprojekt tror inte på en säljbroschyr. De frågar vad det finns att granska. Det här inlägget går igenom vad vi byggde på Kapaciti den veckan, och vad som har kommit till sedan dess, för att gå från ord till något som går att kontrollera.

Extern verifierbarhet är poängen

Compliance-AI som inte går att kontrollera utifrån är teater. Det spelar ingen roll hur väl de interna rutinerna är dokumenterade om en utomstående inte kan pröva dem utan att lita på leverantörens egna system. Förtroende måste gå att mäta, upprepa och signera. Annars håller det inte i en granskning på riktigt.

I praktiken behövde vi sju delar. En kryptografisk kedja som binder ihop varje steg agenten tar. En publik verifierare som vem som helst kan ladda ner och köra. Tester som medvetet försöker få agenten att göra fel. Regelscenarier som mäter hur agenten resonerar om AI-förordningen och GDPR. En extern tidsstämpel, så att inte ens vi kan ändra loggen utan att det syns. En trendfil, så att resultaten går att följa mellan körningarna. Och en publicerad metod som visar hur vi tänkte, inte bara vad vi mätte. Texten går igenom dem i tur och ordning.

Den första delen, en kryptografisk kedja

Problemet är lätt att formulera och svårt att lösa. När en AI-agent har gjort något som får följder, hur vet du veckor senare att ingen har ändrat loggen? En rad i en databas kan ändras av alla med skrivrätt. En CSV-fil i en molnlagring kan skrivas över. Ett nattligt pdf-utdrag kan bytas ut. Det räcker inte att säga att allt loggas, för en logg som går att ändra är bara en textfil.

Vår lösning bygger på två gamla och beprövade byggstenar. Den ena är SHA-256, samma hashfunktion som Bitcoin vilar på sedan 2009, specificerad i FIPS 180-4. Den andra är Ed25519, en algoritm för digitala signaturer från RFC 8032 som är snabbare än RSA att signera med. Båda är äldre än de flesta AI-företag och granskade av tusentals personer.

Tänk dig en kvittobok där varje ändring syns. Varje gång agenten gör något som spelar roll, ett svar till en användare, ett anrop till ett verktyg eller ett beslut att inte svara på en fråga, skriver vi ett nytt block. Blocket innehåller indata och utdata, eller ett fingeravtryck av dem, tillsammans med modellnamn och tidsstämpel. Sedan räknar vi fram en SHA-256-hash över hela blocket. Den blir blockets identitet, 64 tecken lång. Nästa block innehåller den hashen. Ändrar någon ett enda tecken i ett gammalt block ändras dess hash, och då bryts länken till nästa block och till alla som följer. Historien går inte att ändra utan att varje senare block skrivs om. Eftersom varje block också är signerat med vår privata Ed25519-nyckel går det inte ens att skriva om dem utan nyckeln.

Det här är ingen blockkedja i kryptovalutornas mening. Det finns ingen konsensus, ingen token och ingen delad huvudbok. Det är en hashkedja med en signerare per organisation. Den publika nyckeln publicerar vi öppet, så att vem som helst kan kontrollera att signaturerna kommer från oss. Fingeravtrycket för nyckeln som signerar våra utvärderingspaket, ett SHA-256-värde av den publika nyckeln skriven i hex, är sha256:0e6daf50937454fcfaa1e9f74713b430bb04c60fb56bc30857ef632fad614505. Nycklarna listas på kapaciti.se/trust/audit-keys och i /.well-known/audit-keys-index.json, så att en granskare kan jämföra värdet i ett paket med en källa utanför paketet.

Den andra delen, en publik verifierare

Att vi själva säger att kedjan stämmer är värdelöst, eftersom det är vi som har skrivit den. Det intressanta är om någon annan kan kontrollera den utan att lita på våra system. Därför har vi byggt en fristående verifierare och publicerat den på github.com/Fluxz-Holding/kapaciti-audit-demo.

Verktyget är medvetet litet: drygt 400 rader Node.js utan externa beroenden och utan byggsteg. En granskare behöver Node 22 eller senare och en paketfil. Det räcker att klona repot och köra node verify.mjs med paketfilen som argument. Du behöver inte ringa oss.

Programmet räknar om varje blocks hash från grunden, kontrollerar varje signatur, går igenom kedjan från första blocket till det sista och skriver ut ett besked. Har något manipulerats, är en signatur fel eller har kedjan en lucka avslutar verifieraren med felkod 1 och säger varför. Stämmer allt skriver den OK och visar fingeravtrycket, som du själv kan jämföra med den publicerade källan.

Det är skillnaden mellan att be om förtroende och att förtjäna det. I det första fallet säger leverantören att loggen är säker och lovar. I det andra lämnar leverantören över paketet, verifieraren och fingeravtrycket och ber dig kontrollera. Vi har gjort det öppet för att det är det enda sätt vi ser att ta bort frågan om man kan lita på oss i en reglerad bransch.

Den tredje delen, tester som försöker få agenten att göra fel

Kedjan visar vad agenten gjorde. Den visar inte att det var rätt. För det behövs tester som medvetet försöker få agenten att göra fel. Sviterna kördes i maj 2026 mot vår helpdeskagent och mot en agent för frågor om AI-förordningen och GDPR, inte mot ALEX.

Robusthet betyder här några konkreta saker. Att agenten håller sig till sitt uppdrag. Att den inte hittar på siffror, kundnamn eller artikelnummer som saknas i underlaget. Att den inte lämnar ut sina egna instruktioner när någon ber om dem. Att den inte byter roll mitt i ett samtal för att hjälpa till med något olämpligt. Vi mäter det med 50 tester i fem kategorier: att hålla sig till uppdraget, att inte fabricera fakta, att inte hallucinera, att hålla rollen och att inte lämna ut instruktionerna. Testerna är våra egna och skrivna för svenska.

I körningen 18 maj 2026 bedömdes 18 av testerna. 16 klarades och 2 föll, alltså 88,9 procent av de bedömda. De övriga 32 fick inget svar från modellen och bedömdes därför inte, så urvalet var litet. I körningen 19 maj bedömdes 45. 37 klarades och 8 föll, alltså 82,2 procent, och för 5 tester kunde domarmodellen inte ge något omdöme. I körningen 20 maj bedömdes alla 50, och 44 klarades. Den 19 maj körde vi också en svårare svit med 15 avancerade attacker. Där klarades 10, alltså 66,7 procent, vår svagaste publicerade körning. Siffrorna finns i den publicerade trenddatan.

Vi vill inte putsa på resultaten. När alla skriver att de klarar alla säkerhetstester hjälper det inte att bli ännu en röst i den kören. Det som hjälper är att publicera de råa siffrorna, paketet och fördelningen per kategori, så att den som vill kan dra egna slutsatser. Paketet för körningen 18 maj (robustness-suite-2026-05-18.bundle.json) ligger i verifierarens repo, i mappen bundles. Öppna paketet så ser du fråga och svar i varje test, för de 32 obesvarade testerna det felmeddelande som kom i stället, och verifieraren visar att inget är ändrat.

Den fjärde delen, regelscenarier

Robusthetstesterna mäter inte kunskap om regler. För det finns en egen svit med scenarier där agenten får realistiska frågor om AI-förordningen och GDPR. Den bedöms på hur rätt den klassar risknivån, hur exakt den hänvisar till artiklar och hur ärligt den hanterar gränsfall.

Ett av scenarierna gäller ett bemanningsföretag som låter AI rangordna cv:n. Är det hög risk enligt bilaga III punkt 4 a i AI-förordningen, och vilka skyldigheter följer av det? Agenten ska klassa rätt, hänvisa till rätt artiklar och inte hitta på artikelnummer. Bedömningen görs av en domarmodell som följer en skriven bedömningsmall.

I körningen 19 maj 2026 bedömdes 6 av 18 scenarier, med en snittpoäng på 88,3 procent. Fyra scenarier fick 100, bland dem rangordningen av ansökningar. Lägst, 45, fick ett scenario om övervakning av anställda, där svaret inte tog upp arbetsrätten alls, varken medbestämmandelagen eller arbetstidslagen. Sådana luckor vill vi hitta tidigt, eftersom de visar var nästa justering av instruktionerna ska börja. I körningen dagen efter bedömdes alla 18 scenarierna, och snittpoängen blev 94,4 procent. Siffrorna går att kontrollera i paketen och i trenddatan.

I ett av scenarierna flaggade domarmodellen att agenten angav antalet områden i bilaga III, åtta, utan att antalet fanns i facit. Antalet stämmer med lagtexten, och flaggan står kvar i paketet. Vi redovisar bedömningarna som de är, även där domaren tar fel. Paketet ligger på /eval-bundles/regulatory-suite-2026-05-19.bundle.json.

Den femte delen, en extern tidsstämpel

En kedja som vi själva signerar visar att ingen har ändrat den efter signeringen. Den visar inte när signeringen skedde. Den som håller nyckeln skulle i teorin kunna bygga om en hel kedja i efterhand och signera den på nytt.

Testpaketen från maj saknar det skyddet. Därför har vi sedan dess byggt in en tidsstämpel från en extern part i loggen som ALEX skriver. Tidsstämpeln binder posten till en tidpunkt som vi inte styr över, så att er revisor kan kontrollera både att posten är oförändrad och när den skrevs. Det är därför vi kan säga att inte ens vi kan ändra loggen utan att det syns.

Det ersätter inte en revision. Det gör revisionen enklare, eftersom underlaget redan går att kontrollera utan att fråga oss.

Den sjätte delen, en trend över tid

Ett resultat från en enda dag säger lite. En trend säger mer. Trendfilen har en rad per körning med förändringen mot körningen innan. Domarmodellen byttes mellan körningarna: robusthetssviten bedömdes av Claude Haiku 4.5 den 18 maj och av Claude Sonnet 4.6 den 20 maj, regelsviten av Claude Haiku 4.5 den 19 maj och av Claude Opus 4.7 den 20 maj. Förändringen mellan 18 och 20 maj mäter alltså också bytet av domare. Paketen för robusthetssviten 18 maj och regelsviten 19 och 20 maj är publicerade. Trendfilen omfattar tre körningar av robusthetssviten och två av regelsviten, 18 till 20 maj 2026. Sedan dess har vi kört en separat svit mot helpdeskagenten, 29 augusti 2026, där alla 35 kontroller klarades.

Senaste körningen av båda sviterna är från 20 maj 2026. Trendfilen är publik, så den som vill kan se både siffrorna och när de togs fram.

Den sjunde delen, en publicerad metod

Inget av det ovan räcker om ingen förstår hur vi har resonerat. Siffror, paket och en verifierare behöver en text som beskriver tankegången, så att en utomstående kan bilda sig en uppfattning om metoden i sig.

Därför ligger metoddokumenten i mappen docs på github.com/Fluxz-Holding/kapaciti-audit-demo. SPEC beskriver hur kedjan normaliseras och signeras och hur ett paket är uppbyggt. THREAT-MODEL beskriver vilka angripare vi har byggt för och vilka kvarstående risker vi har accepterat. BUNDLE-SCHEMA beskriver dataformatet block för block. VERIFY-YOURSELF går steg för steg igenom hur en utomstående kör verifieraren. FAQ samlar de vanligaste frågorna.

Dokumenten anger sina källor, bland annat RFC 8032 för Ed25519, FIPS 180-4 för SHA-256 och RFC 8785 för hur JSON normaliseras. Vi visar alltså också hur vi tänkte och vilka källor vi lutade oss mot.

Vad det betyder för dig som köpare

Kanske ansvarar du för it på en bank, för regelefterlevnad i ett vårdbolag eller för upphandling i en kommun. Då kan du ladda ner ett paket från kapaciti.se/trust/verify-yourself och verifieraren från github.com/Fluxz-Holding/kapaciti-audit-demo, och köra verifieraren på din egen dator utan att fråga oss. Du ser samma utdata som vi. Fingeravtrycket kan du jämföra med det som står på kapaciti.se/trust/audit-keys.

Du behöver inte tro oss. Du kan kontrollera oss. Allt står i koden, i dokumenten och i de signerade paketen.

Ska du köpa in en AI-agent är nästa fråga vad loggen behöver visa. Vad lagen kräver av den som inför en agent har vi skrivit om under AI-förordningen och AI-agenter, och vill du gå igenom era egna system punkt för punkt finns vår checklista för AI-förordningen med 22 kontrollpunkter.

Den som upphandlar i en kommun eller region hittar krav på loggar och insyn i vår mall för att upphandla AI i offentlig sektor. Hur samma ja och samma logg ser ut i ett kommunalt diarium beskriver vi på sidan om hur registratorn får ett förslag, och vad en AI-medarbetare är och gör står på en egen sida.

Det här har vi gjort

Inga superlativ och inga påståenden om att vara bäst, störst eller först. Vi har byggt sju delar som tillsammans låter en utomstående kontrollera vårt arbete utan att lita på oss. Kedjan är signerad. Verifieraren är publik. De två testsviterna är körda och resultaten publicerade. Loggen som ALEX skriver i dag har en extern tidsstämpel. Trenden går att följa. Metoden är dokumenterad.

Nästa gång någon ber dig tro att deras AI är förklarbar har du en checklista. Be att få se den signerade loggen och att få verifiera den själv. Be att få se de råa resultaten från testerna, den senaste körningen av regelscenarierna och vem som har tidsstämplat loggen. Be att få se den publicerade metoden och trenden över tid.

Saknas det är det marknadsföring som har lånat ett ord från juristerna.