EU AI Act-dokumentation: mall för svenska SMB

De flesta svenska SMB tror att EU AI Act-dokumentation betyder hundratals sidor teknisk text. Det stämmer bara för en liten grupp. För resten handlar det om tre enkla register som tar en eftermiddag att fylla i. Den här guiden visar exakt vad ni måste dokumentera utifrån er roll, och ger er en gratis mall att utgå från.

Vad kräver EU AI Act att svenska SMB dokumenterar?

EU AI Act-dokumentation innebär för de flesta svenska SMB tre saker: ett register över era AI-system, en logg över personalens AI-kunskap, och en notering om var ni informerar användare att de möter AI. Den fullständiga tekniska dokumentationen gäller bara hög-risk-leverantörer.

Lagen är förordning (EU) 2024/1689 och trädde i kraft 1 augusti 2024. Den klassificerar AI-system i fyra risk-kategorier, och dokumentationskraven växer med risken. Eftersom omkring 95 procent av svenska SMB använder AI med minimal eller begränsad risk, blir deras dokumentation lätt: bevisa att ni har koll, inte att ni byggt ett certifierat system.

Misstaget vi ser oftast är att företag antingen ignorerar dokumentation helt, eller drar igång ett enormt projekt som om de vore ett MedTech-bolag. Båda är fel. Rätt nivå av EU AI Act-dokumentation avgörs av två frågor: vilken roll har ni, och vilken risk-klass har systemet?

Vilken dokumentation behöver ni utifrån er roll?

Er roll avgör allt. Är ni tillhandahållare (ni använder ett färdigt AI-verktyg) räcker det med register, kunskapslogg och transparens. Är ni leverantör (ni bygger eller sätter ert namn på ett hög-risk-system) tillkommer fullständig teknisk dokumentation enligt Annex IV.

Skillnaden är stor och missförstås ofta. Att använda ChatGPT, en kundtjänst-chatbot eller AI inbäddad i ert CRM gör er till tillhandahållare, inte leverantör. Då har ni inga krav på teknisk produktdokumentation. Bygger ni däremot ett eget rekryterings- eller kreditbedömnings-system, eller köper ett white label-system som ni säljer under eget namn, blir ni leverantör med betydligt tyngre krav.

Att använda ett AI-verktyg och att bygga ett är två helt olika juridiska roller. Förväxla dem och ni dokumenterar antingen för lite eller fullständigt i onödan.

Ett snabbt test: sätter ni ert eget varumärke på AI-systemet, eller ändrar ni väsentligt hur det fungerar? Då är ni sannolikt leverantör. Köper ni en färdig tjänst och använder den som den är, är ni tillhandahållare, oavsett hur avancerad tekniken bakom är. Tveksamma fall, som att finjustera en egen modell på era data, bör stämmas av med jurist innan ni bestämmer dokumentationsnivå.

Innan ni dokumenterar något behöver ni alltså klassificera era system. Vi har en separat genomgång av hur ni risk-klassificerar era AI-system steg för steg som är det naturliga första steget före den här mallen.

Vad ska ett AI-systemregister innehålla?

Ett AI-systemregister är en enkel tabell som listar varje AI-system ni använder eller tillhandahåller, dess syfte, er roll, dess risk-klass och vilken åtgärd som krävs. Det är grunden i all EU AI Act-dokumentation och bör finnas även om inget system är hög risk.

Registret är inget formellt lagkrav för minimal-risk-system, men det är den dokumentation som binder ihop allt annat och som en revisor eller myndighet först vill se. Lista brett: AI-agenter, chatbots, kundtjänst-automation, intern produktivitets-AI som ChatGPT och Copilot, prediktiv analys, marketing-AI och AI som ligger inbäddad i SaaS-verktyg ni redan betalar för.

För varje system noterar ni:

1. System och leverantör: vad det heter och vem som tillhandahåller det
2. Syfte: vad ni använder det till, konkret
3. Er roll: tillhandahållare eller leverantör
4. Risk-klass: förbjudet, hög, begränsad eller minimal
5. Åtgärd: vad som är gjort eller behöver göras

Just att hålla registret uppdaterat när nya verktyg tas i bruk är viktigare än hur snyggt det ser ut. Ett kalkylark som faktiskt underhålls slår en perfekt PDF som ingen rör.

Hur fyller en typisk SMB i registret?

De flesta SMB landar på tre till fem system i sitt register, oftast en kundtjänst-chatbot, intern produktivitets-AI och något som ligger inbäddat i ett SaaS-verktyg. Ett konkret exempel gör tydligt hur enkel EU AI Act-dokumentation faktiskt blir i praktiken.

Ta en svensk e-handlare med tio anställda och tre AI-system. System ett är en kundtjänst-chatbot från en extern leverantör. Roll: tillhandahållare. Risk: begränsad, eftersom den interagerar direkt med kunder. Åtgärd: lägg in en transparens-disclaimer enligt Artikel 50 vid första svaret.

System två är ChatGPT, som teamet använder för produkttexter och mejlutkast. Roll: tillhandahållare. Risk: minimal. Åtgärd: ta upp verktyget i AI-kunskapsloggen och i den interna policyn om godkända verktyg. Inga tyngre krav tillkommer.

System tre är ett verktyg som bedömer delbetalnings-risk i kassan. Roll: tillhandahållare. Risk: potentiellt hög, eftersom kreditbedömning av privatpersoner ligger i Annex III. Åtgärd: kontrollera leverantörens dokumentation, utse en namngiven mänsklig tillsyn och säkerställ att loggarna sparas i minst sex månader.

Hela övningen tar en eftermiddag, och resultatet besvarar de tre frågor en myndighet, kund eller investerare ställer: vilka AI-system har ni, vilken risk har de, och vad har ni gjort åt det. Lägg märke till att bara ett av tre system, kreditverktyget, drar några tyngre krav. Det är typiskt. Merparten av raderna i ett SMB-register hamnar i minimal eller begränsad risk, och just därför blir dokumentationen hanterbar när ni väl klassificerat rätt.

Måste ni dokumentera personalens AI-kunskap?

Ja. Artikel 4 om AI-kunskap gäller alla som använder eller tillhandahåller AI och är i kraft sedan 2 februari 2025. Ni ska säkerställa att personalen har tillräcklig AI-kunskap, och utan dokumenterad utbildning kan ni inte bevisa att kravet är uppfyllt.

Det här är den del som flest missar, just för att den redan gäller och inte väntar på någon framtida deadline. Kravet är medvetet flexibelt: nivån ska stå i proportion till hur ni använder AI och vilka som berörs. För ett litet bolag som använder ChatGPT internt räcker en kort internutbildning plus en enkel policy om vilka verktyg som är godkända.

Det som behövs är en logg: vem som utbildats, när, och vad utbildningen omfattade. En rad per personalgrupp räcker. Poängen är inte byråkrati utan bevisbarhet. Om frågan ställs ska ni kunna peka på ett datum och ett innehåll, inte säga "vi pratade om det på ett möte".

När krävs transparens-dokumentation?

Artikel 50 kräver att ni informerar användare när de interagerar med AI eller tar del av AI-genererat innehåll. Det gäller chatbots och AI-agenter, deepfakes, och AI-genererad text som publiceras i samhällsinformerande syfte. Dokumentera var och hur ni informerar.

För de flesta SMB betyder det här en enda sak i praktiken: chatbotten eller AI-agenten på webben ska tala om att den är AI vid första kontakt. En mening räcker, till exempel "Du chattar med en AI-assistent. Skriv 'mänsklig agent' om du vill nå en person." Transparens-registret noterar bara vilket system det gäller, vilken typ av disclosure som krävs, och var texten visas.

Genererar ni bilder, ljud eller video som är deepfakes, eller AI-text om nyheter och samhällsfrågor, tillkommer märkningskrav. Det är ovanligt för vanliga SMB men värt att känna till om ni jobbar med marknadsföringsinnehåll. Den här typen av transparens är samma princip som vi byggde in när vi tog fram Eteyas guide till EU AI Act för svenska företag.

Vad gäller för tillhandahållare av hög-risk-system?

Är ni tillhandahållare av ett hög-risk-system (Annex III, till exempel rekryterings- eller kreditbedömnings-AI) tillkommer skyldigheter enligt Artikel 26: namngiven mänsklig tillsyn, övervakning av driften, och att spara systemets automatiska loggar i minst sex månader.

Det här är en mindre grupp SMB, men kraven är konkreta och bevisbara. Ni ska kunna peka ut en namngiven person med rätt kompetens och befogenhet att ingripa, beskriva hur ni övervakar systemet, och visa att loggarna sparas. Enligt en genomgång från IAPP är det just dessa bevis, namngiven tillsyn och sparade loggar, som flest tillhandahållare saknar inför att kraven börjar gälla.

En liten undergrupp måste dessutom göra en konsekvensbedömning för grundläggande rättigheter, FRIA, enligt Artikel 27. Den gäller offentliga organ, privata aktörer som levererar offentliga tjänster, och tillhandahållare av AI för kreditbedömning eller liv- och sjukförsäkring. Gäller inget av detta er, kan ni hoppa över FRIA helt.

Hur länge ska dokumentationen sparas?

Bygger ni hög-risk-system som leverantör ska den tekniska dokumentationen sparas i tio år efter att systemet satts på marknaden (Artikel 18). Som tillhandahållare av hög-risk-system sparar ni systemets loggar i minst sex månader (Artikel 26.6). För minimal-risk-system finns inget formellt krav, men ett levande register är god praxis.

Den tekniska dokumentationen för hög-risk-leverantörer följer Annex IV och täcker systembeskrivning, datastyrning, prestanda, riskhantering och loggning enligt Artikel 12. Små företag och startups får lämna den i förenklad form, och EU-kommissionen ska ta fram en förenklad mall för ändamålet. Tills den publiceras räcker det att täcka rubrikerna i Annex IV proportionerligt mot er storlek.

Sätt ett återkommande datum för översyn, minst en gång per år och vid varje lagändring. EU AI Act-dokumentation är inte en engångsuppgift utan ett levande underlag som ska spegla vilka system ni faktiskt kör.

Vilka är de vanligaste misstagen i EU AI Act-dokumentation?

De tre vanligaste misstagen är att överdokumentera som vanlig tillhandahållare, att glömma AI-kunskapsloggen trots att Artikel 4 redan gäller, och att behandla dokumentationen som en engångsuppgift istället för ett levande register som följer verksamheten.

Det första och dyraste misstaget är att dokumentera som om ni vore leverantör. Ett bolag som bara använder färdiga AI-verktyg drar ibland igång ett fullständigt Annex IV-projekt det inte alls behöver, med veckor av onödigt arbete. Klassificera rollen först, dokumentera därefter.

Det andra misstaget är att hoppa över AI-kunskapsloggen. Eftersom Artikel 4 inte väntar på någon framtida deadline glöms den lätt bort i jakten på hög-risk-kraven. Det är samtidigt den enklaste delen att åtgärda, och ofta den första en motpart frågar efter eftersom den redan är skarp.

Det tredje misstaget är att se dokumentationen som klar. Ett register som speglar förra årets verktyg är värdelöst. Nya AI-funktioner dyker upp i SaaS-verktyg ni redan betalar för, ofta utan att någon aktivt valt dem. Utan ett återkommande översynsdatum slutar registret stämma inom några månader, och då faller hela poängen.

Behöver ni en AI-policy utöver registret?

Ja, för de flesta SMB är en kort intern AI-policy ett naturligt komplement till dokumentationen. Registret beskriver vad ni har, medan policyn styr hur personalen får använda AI. Tillsammans täcker de både EU AI Act-dokumentation och praktisk styrning.

EU AI Act kräver ingen formell policy i sig, men Artikel 4 om AI-kunskap blir svår att uppfylla utan en. En policy på en sida räcker långt: vilka verktyg som är godkända, vilka data som aldrig får matas in i publika AI-tjänster, och vem man frågar vid tveksamheter. Det är samma princip som en informationssäkerhetspolicy, fast för AI.

Policyn löser också det vanligaste praktiska problemet, skugg-AI. När personalen använder verktyg som ingen godkänt hamnar de utanför registret och utanför kontrollen. En tydlig policy med en enkel väg att föreslå nya verktyg håller registret aktuellt och minskar risken att ett okänt system bryter mot transparens- eller dataskyddskrav. Policyn och registret bör därför ses över vid samma tillfälle.

När börjar kraven gälla?

Förbjudna praktiker, GPAI-regler och AI-kunskap (Artikel 4) gäller redan idag. Hög-risk-kraven var satta till 2 augusti 2026, men enligt den provisoriska Digital Omnibus-överenskommelsen skjuts fristående Annex III-system till 2 december 2027. Den är ännu inte formellt antagen.

Det praktiska rådet är därför enkelt: planera för 2 augusti 2026 tills senareläggningen är publicerad i EU:s officiella tidning. Rådet och parlamentet enades om förslaget under våren 2026, men ett förslag är inte gällande lag förrän det formellt antagits. Att börja dokumentera ett halvår innan deadline är minimum för att hinna utan stress.

Att skjuta upp hög-risk-kraven ändrar dessutom ingenting för de delar som redan gäller. AI-kunskap, transparens och förbudet mot vissa praktiker påverkas inte av Omnibus. För majoriteten av SMB, som ändå mest berörs av just de delarna, är väntan alltså inte ett skäl att vänta med dokumentationen.

Vanliga frågor

Att komma igång med EU AI Act-dokumentation är enklare än de flesta tror, så länge ni börjar i rätt ände: klassificera systemen, fyll i registret, logga kunskapen. Mallen ovan ger er strukturen. Behöver ni hjälp att klassificera era system rätt eller bygga AI som är dokumenterad från start, finns vi här.