Av alla delar av AI-förordningen är det inget område som genererat mer förvirring hos svenska bolag än GPAI. General-Purpose AI Models. Reglerna trädde i kraft 2 augusti 2025, men praxis bygger fortfarande upp sig, Code of Practice utvecklas i takt med att leverantörerna signerar, och tröskeln för "systemic risk" är ett tekniskt mått som de flesta jurister aldrig hört talas om innan AI Act.
Jag jobbar med våra kunder i den tekniska änden av compliance, där man faktiskt bygger på GPAI-modeller. Och där är frågorna konkreta. Är OpenAI och Anthropic ansvariga, eller är vi det? Vad krävs för att vi själva blir GPAI-leverantörer? Räknas vår finetune som "väsentlig modifiering"? Får vi köra Mistral on-premise utan att bekymra oss om Code of Practice?
Den här artikeln går igenom vad GPAI faktiskt är, vilka leverantörer som påverkas, vad Code of Practice innebär i maj 2026, vilka skyldigheter som gäller, och när er användning gör er själva till GPAI-leverantör. För övergripande tidslinje och kontext hänvisar jag till vår sammanställning av AI-förordningen.
Vad är GPAI? Definition och tröskel
En General-Purpose AI Model definieras i artikel 3 som en AI-modell som uppvisar betydande generalitet, kan utföra ett brett spektrum av distinkta uppgifter, och kan integreras i en mängd nedströmssystem eller applikationer. Det är en bred definition som täcker både text, bild, ljud och multimodala modeller.
Förordningen särskiljer två nivåer:
Vanlig GPAI. Modeller som uppfyller definitionen men inte når systemic risk-tröskeln. Här ligger de flesta öppna modeller och en stor del av de kommersiella.
Systemic risk GPAI. Modeller som tränats med mer än 10²⁵ FLOPs (floating point operations) över hela träningsprocessen. För att sätta detta i perspektiv: GPT-4 uppskattades till cirka 2 × 10²⁵ FLOPs vid lansering. Tröskeln är medvetet satt så att den fångar dagens frontier-modeller och växer i takt med beräkningskraften. Listan med utpekade systemic risk-modeller publiceras och uppdateras av kommissionen.
För svenska bolag är skillnaden viktig. Vanlig GPAI har begränsade leverantörsskyldigheter (dokumentation, upphovsrätt, träningsdatasammanfattning). Systemic risk GPAI har dessutom krav på modellutvärdering, riskhantering, incidentrapportering och cybersäkerhet.
Vilka är GPAI-leverantörerna i praktiken?
I maj 2026 omfattar GPAI-reglerna en relativt avgränsad grupp leverantörer:
- OpenAI (GPT-serien, inklusive GPT-5 och systemic risk-klassade modeller).
- Anthropic (Claude-familjen, där Opus 4.6 och senare ligger i systemic risk-spannet).
- Google DeepMind (Gemini-familjen).
- Meta (Llama-modellerna, öppna men ändå GPAI).
- Mistral AI (Mistral Large, Mixtral).
- xAI (Grok-familjen).
- Aleph Alpha (europeisk leverantör inriktad mot offentlig sektor).
- Flera kinesiska leverantörer som Alibaba (Qwen) och DeepSeek när modellerna görs tillgängliga inom EU.
Det är intressant att Meta valt en mer återhållsam linje när det gäller Code of Practice (mer om det nedan), medan OpenAI, Anthropic och Google signerat. Det reflekterar både olika affärsmodeller och olika syn på regulatorisk strategi.
Code of Practice: status i maj 2026
Code of Practice är ett frivilligt instrument enligt artikel 56 som ska konkretisera hur GPAI-leverantörer i praktiken uppfyller sina skyldigheter. Det är inte lag, men signering ger ett antagande om regelefterlevnad. Den som inte signerar måste själv visa motsvarande compliance, ofta med betydligt högre transparenskrav.
Code of Practice utvecklades under 2024 och 2025 av ett konsortium koordinerat av AI Office med deltagande från akademi, näringsliv och civilsamhälle. Det första versionen släpptes i juli 2025 och har tre huvuddelar:
- Transparens. Hur leverantören dokumenterar sin modell för nedströmsanvändare.
- Upphovsrätt. Hur leverantören respekterar EU:s upphovsrättsregler och hanterar opt-out-signaler från innehållsägare.
- Säkerhet och systemic risk. Endast för systemic risk-leverantörer. Modellutvärdering, riskbedömning, incidentrapportering.
Status maj 2026:
- Signerat: OpenAI, Anthropic, Google, Mistral, Aleph Alpha, Microsoft, IBM, samt en handfull mindre EU-leverantörer.
- Inte signerat: Meta (har offentligt uttryckt skepsis mot säkerhetsdelen), xAI, vissa kinesiska leverantörer.
För svenska bolag som använder GPAI är detta praktiskt relevant. Om er leverantör signerat Code of Practice kan ni i hög grad lita på att deras dokumentation och säkerhetsåtgärder uppfyller AI Act-kraven. Om de inte signerat måste ni göra mer due diligence själva, något som lyfter compliance-bördan på er som deployer.
Skyldigheter för GPAI-leverantörer
Alla GPAI-leverantörer som släpper modeller på EU-marknaden har följande skyldigheter enligt artikel 53:
Teknisk dokumentation
Leverantören ska upprätthålla aktuell teknisk dokumentation av modellen som omfattar designval, träningsprocess, utvärderingsresultat och kända begränsningar. Dokumentationen ska hållas tillgänglig för AI Office och nedströmsleverantörer på begäran.
Information till nedströmsanvändare
Dokumentation som hjälper nedströmsanvändare att förstå modellens kapacitet och begränsningar. Detta är vad ni som svenska bolag använder för att bygga er egen riskbedömning när ni integrerar GPAI.
Upphovsrättspolicy
Leverantören ska implementera en policy som respekterar EU:s upphovsrättsregler (direktiv 2019/790) och särskilt artikel 4 om text and data mining. I praktiken betyder det att leverantören måste respektera "opt-out"-signaler från innehållsägare, exempelvis robots.txt-direktiv som signalerar att innehåll inte får användas för träning.
Sammanfattning av träningsdata
En offentligt tillgänglig sammanfattning av vilken typ av innehåll som använts för träning, baserad på en mall som AI Office tillhandahåller. Detta är en av de mest debatterade delarna, eftersom leverantörerna måste avslöja mer om sina träningsdata än vad många velat tidigare.
Vid systemic risk: dessutom
Systemic risk-leverantörer har enligt artikel 55 ytterligare skyldigheter:
- Modellutvärdering inklusive adversariell testning.
- Riskbedömning och dokumenterade mitigeringsåtgärder.
- Incidentrapportering till AI Office.
- Adekvat cybersäkerhetsskydd för modellvikter och träningsinfrastruktur.
När blir ni själva GPAI-leverantör?
Det här är frågan som genererat mest oro hos svenska scaleups, och med rätta. Tre situationer kan göra er till GPAI-leverantör, även om ni "bara" bygger ovanpå en befintlig modell:
1. Ni tränar en egen modell från grunden
Detta är det tydligaste fallet. Om ni tränar en GPT-liknande modell på er egen data och släpper den, är ni GPAI-leverantörer. För de flesta svenska bolag är detta inte aktuellt på grund av kostnaden, men ett antal akademiska och nationella initiativ rör sig i den riktningen.
2. Ni gör väsentlig finetuning som ändrar modellens karaktär
Detta är gråzonen. Lätt finetuning (några tusen exempel, mindre modifiering av specifika beteenden) gör er inte till GPAI-leverantör. Substantiell finetuning som ändrar modellens kapacitet, säkerhetsprofil eller breda användbarhet kan göra det. Praxis utvecklas, men en arbetsregel vi använder: om er finetune skulle räknas som en "ny modell" i marknadsföringssyfte, är ni leverantör.
3. Ni släpper en finetuned modell under eget namn
Detta är artikel 25-fällan tillämpad på GPAI. Om ni paketerar en modifierad GPAI-modell som er egen produkt och släpper den under eget varumärke, blir ni leverantör med fullt ansvar för dokumentation, upphovsrätt och (om tröskeln nås) systemic risk. Detta är samma logik som vi gick igenom i artikeln om rollerna i AI-förordningen, tillämpad på GPAI-nivån.
Praktiskt exempel från vår verksamhet: En kund tog Llama 3.1 70B, finetunade den på svensk juridisk data, och paketerade den som en del av sin SaaS-produkt. Eftersom modifieringen var domänspecifik utan att ändra modellens grundkapacitet, och produkten såldes som en applikation snarare än en modell, hamnade de inte i GPAI-leverantörsrollen. Men: om de istället hade marknadsfört modellen separat och låtit kunder ladda ner den för andra ändamål, hade gränsen passerats.
Vad GPAI-reglerna betyder för svenska deployers
Som deployer av GPAI har ni begränsade direkta skyldigheter under artikel 53. Men reglerna påverkar er ändå på tre sätt:
1. Dokumentationskedjan. Ni ska kunna visa att den modell ni använder är en compliant GPAI. Om leverantören är publicerad i AI Office-databasen och har signerat Code of Practice, har ni grunden klar.
2. Användning av outputs. Era användningsfall ovanpå GPAI kan i sig vara högrisk under Annex III, vilket gör att hela deployerskyldigheterna gäller oavsett vad GPAI-leverantören gör. Här går vi igenom Annex III-bedömningen i detalj i en separat artikel.
3. Transparens till slutanvändare. Ni måste informera er användare när AI används för beslut som påverkar dem. Detta gäller oavsett om er underliggande modell är GPAI eller specialbyggd.
Tre rekommendationer för svenska organisationer
1. Inventera vilka GPAI-modeller ni använder och deras Code of Practice-status. Det är en kort lista, men det är värt att veta. OpenAI, Anthropic, Google har signerat. Meta har inte. Det påverkar vilken due diligence ni behöver göra på er egen sida.
2. Dokumentera er finetuning-praxis aktivt. Skriv ner vad ni finetunar, varför, omfattning, och vilket utfall ni mäter. Detta är försäkringen mot att oavsiktligt glida över i GPAI-leverantörsrollen. Tillsynsmyndigheten kommer fråga, och en muntlig "vi gjorde lite RLHF" räcker inte.
3. Följ Code of Practice-utvecklingen kvartalsvis. Det är ett levande dokument som uppdateras, och vilka leverantörer som signerar förändras. Sätt en kalenderpåminnelse var tredje månad för att kolla AI Office-databasen. Det tar femton minuter och håller er compliance-stack aktuell.
Walmas perspektiv
På Walma använder vi GPAI-modeller dagligen i Noda och i den verktygsbyggande vi gör för kunder. Vår praxis är att tydligt separera modellnivån från applikationsnivån i både teknisk arkitektur och avtal. Underliggande GPAI är en valbar komponent (vi kör OpenAI, Anthropic, Mistral, Llama beroende på kundens preferens och säkerhetskrav), medan applikationslagret är vårt och tydligt definierat. Det gör att kunden kan välja sin GPAI-strategi utan att tappa kontrollen över vad som byggs ovanpå.
Om Code of Practice ändras eller en GPAI-leverantör förlorar sin compliance-status kan vi byta underliggande modell utan att riva upp applikationen. Det är så vi tänker att GPAI-användning bör arkitekteras för svenska bolag framöver: löst kopplat, dokumenterat, och anpassningsbart.
FAQ
Är Claude och GPT GPAI-modeller?
Ja. Båda är klassade som GPAI, och de senaste generationerna (Claude Opus 4.6, GPT-5) är dessutom i systemic risk-spannet på över 10²⁵ FLOPs.
Vad händer om vår GPAI-leverantör tappar Code of Practice-statusen?
Då måste ni göra mer egen due diligence eftersom presumtionen om regelefterlevnad försvinner. I praktiken innebär det att ni behöver dokumentera leverantörens compliance på egen hand, vilket är tidskrävande men görbart.
Kan vi köra Llama on-premise utan att bekymra oss om GPAI-reglerna?
Som deployer ja, eftersom skyldigheterna ligger på Meta som GPAI-leverantör. Men om er användning faller inom Annex III gäller högrisk-deployerskyldigheterna oavsett, och om ni finetunar modellen substantiellt kan ni glida över i leverantörsrollen.
Hur dokumenteras träningsdata enligt artikel 53?
AI Office tillhandahåller en mall för sammanfattning som leverantören fyller i. Den ska beskriva typ av innehåll (text, bild, kod, ljud), källor på övergripande nivå, eventuella opt-out-respekterade signaler, och perioden för insamlingen. Detaljnivån är medvetet hållen så att leverantörerna inte tvingas avslöja affärshemligheter, men tillräckligt för att tredje part ska kunna bedöma riskprofilen.
Vad är sanktionen för en GPAI-leverantör som inte följer reglerna?
GPAI-skyldigheter ligger på nivå 2 i sanktionsstrukturen: upp till 15 miljoner euro eller 3 procent av global omsättning. För systemic risk-leverantörer kan AI Office dessutom kräva modifieringar eller, i extremfall, marknadsåterkallelse. Detaljerna går vi igenom i vår artikel om sanktioner.
Hur kan Walma hjälpa oss navigera GPAI-reglerna?
Vi gör GPAI-mappning som en del av AI Act-projekt: vilka modeller används, vilka leverantörer ligger bakom, vilken Code of Practice-status har de, och var ligger gränsen mot er egen leverantörsroll. Resultatet är en levande inventarielista som ni kan visa upp för tillsynsmyndigheten och uppdatera när underliggande modeller eller praxis ändras.
