Kapitel IV: Regler för generella AI‑modeller (GPAI) och GPAI‑modeller med systemrisk (artiklarna 50–62)

Översikt: Varför ett eget kapitel för generella AI‑modeller?

EU:s AI‑förordning (AI Act) antogs 2024 och publicerades i EU:s officiella tidning i juli 2024. Kapitel IV (artiklarna 50–62) är nytt i förhållande till tidigare utkast och är särskilt inriktat på generella AI‑modeller (GPAI).

Syftet med kapitlet är att:

• hantera stora, generella modeller (t.ex. stora språkmodeller) som kan användas i många olika AI‑system
• lägga ansvar på leverantören av modellen, inte bara på nedströms utvecklare av AI‑system
• införa extra krav för modeller med systemrisk, dvs. modeller vars påverkan kan bli samhällsomfattande

Koppling till tidigare kapitel:

• Kapitel III fokuserade på högrisk‑AI‑system (artiklarna 8–29) – alltså tillämpningar (t.ex. kreditbedömning, rekrytering).
• Kapitel IV fokuserar på själva modellerna som kan ligga under många olika system.

> Tänk: Kapitel III = hur AI‑system används i specifika sammanhang. Kapitel IV = vad för generella modeller som ligger under många olika användningar.

I resten av modulen bryter vi ner:

1. Vad en GPAI‑modell är (artiklarna 3 och 50–52)
2. Basåtaganden för leverantörer (artiklarna 53–55)
3. Vad som menas med systemrisk (artiklarna 51, 56–57)
4. Extra krav för GPAI‑modeller med systemrisk (artiklarna 58–60)
5. Hur detta påverkar nedströms utvecklare och användare (artiklarna 52, 61)
6. Roll för AI Office och tillsyn (artiklarna 64 ff., men här bara i relation till kapitel IV)

Steg 1: Definition – vad är en generell AI‑modell (GPAI)?

AI‑förordningen använder begreppet general‑purpose AI model (GPAI‑modell). Den formella definitionen finns i artikel 3 och utvecklas i kapitel IV (artiklarna 50–52).

Förenklat:

En GPAI‑modell är en AI‑modell som:

1. Tränas på breda, ofta mycket stora datamängder
2. Kan utföra en mängd olika uppgifter (inte bara en snäv, specialiserad)
3. Kan integreras i många olika AI‑system och användningsfall (t.ex. chatbots, kodassistenter, analysverktyg)

Exempel på GPAI‑modeller:

• Stora språkmodeller (LLM) som kan:
• skriva text
• översätta språk
• sammanfatta dokument
• generera kod
• Multimodala modeller som kan hantera både text och bild
• Generativa bildmodeller som kan användas för:
• marknadsföringsmaterial
• konstnärlig produktion
• syntetiska träningsdata

Viktigt:

• Kapitel IV riktar sig till leverantören av modellen ("provider of a general‑purpose AI model"), inte nödvändigtvis till varje app som använder modellen.
• En och samma modell kan ligga till grund för både lågrisk, högrisk och till och med förbjudna tillämpningar – därför behövs särskilda regler.

> Minnesregel: Om modellen är bred i uppgifter och återanvänds i många system → sannolikt GPAI.

Steg 2: Är detta en GPAI‑modell? – tänk själv

Fundera på följande scenarier. Svara för dig själv: GPAI‑modell eller inte? och motivera kort.

1. Scenarie A

Ett universitet tränar en modell enbart för att känna igen defekter på en viss typ av industrikomponent i en produktionslina. Den används bara i den fabriken.

• Är detta en GPAI‑modell? Varför / varför inte?

1. Scenarie B

Ett företag tränar en stor språkmodell på blandat webbinnehåll, böcker och kod. Den säljs via API till andra företag som använder den för kundtjänst, kodgenerering och dokumentanalys.

• Är detta en GPAI‑modell? Varför / varför inte?

1. Scenarie C

En bildmodell tränas på stora bilddatamängder och kan generera bilder i många stilar. Den används i spelutveckling, reklam och utbildningsmaterial.

• Är detta en GPAI‑modell? Varför / varför inte?

> Tips: Använd tre kontrollfrågor: (1) Bred uppgiftsförmåga? (2) Många möjliga användningar? (3) Kan integreras i många olika AI‑system?

Steg 3: Basåtaganden för leverantörer av GPAI‑modeller (artiklarna 53–55)

Kapitel IV anger horisontella skyldigheter för alla leverantörer av GPAI‑modeller, oavsett om modellen har systemrisk eller inte.

Centrala skyldigheter (förenklad översikt, med koppling till artiklarna):

1. Teknisk dokumentation (art. 53)

Leverantören ska ta fram och upprätthålla dokumentation som gör att:

• myndigheter kan bedöma modellens överensstämmelse med AI‑förordningen
• nedströms utvecklare kan förstå modellens egenskaper och begränsningar

Typiskt innehåll:

• beskrivning av modellarkitektur
• träningsmetoder och data‑källor på aggregerad nivå
• kända begränsningar och risker

1. Information till nedströms användare/utvecklare (art. 53–54)

Leverantören ska tillhandahålla tillräcklig information för att:

• underlätta efterlevnad av AI‑förordningen för dem som bygger vidare på modellen
• möjliggöra korrekt riskbedömning för högrisk‑tillämpningar

Detta kan inkludera:

• användarhandbok / model card
• information om prestanda, bias, robusthet
• rekommenderade användningsområden och förbjudna/olämpliga användningar

1. Upphovsrättsrelaterade skyldigheter (art. 55)

Leverantören ska:

• respektera EU:s upphovsrättsregler, särskilt vid insamling och användning av träningsdata
• dokumentera och offentliggöra en sammanfattning av de upphovsrättsskyddade verk som använts i träningen, i den mån detta är möjligt (t.ex. typ av källor, inte nödvändigtvis fullständiga listor på varje verk)

1. Registrering och transparens (art. 52, 60)

Vissa GPAI‑modeller ska registreras i en EU‑databas. För modeller med systemrisk är kraven strängare (mer om detta senare), men även vanliga GPAI‑modeller omfattas av grundläggande transparens.

> Praktiskt: Som leverantör måste du tänka "dela tillräckligt mycket" för att nedströms aktörer ska kunna göra rätt enligt kapitel III, utan att nödvändigtvis öppna hela källkoden eller alla träningsdata.

Steg 4: Exempel – dokumentation och upphovsrätt för en språkmodell

Föreställ dig att du är leverantör av en GPAI‑språkmodell som liknar dagens stora LLM:er.

1. Dokumentation (art. 53)

Du tar fram en "Model Card" som innehåller:

• Syfte och kapacitet
• Kan generera text, sammanfatta, översätta, skriva kod
• Träningsdata (översikt)
• Webbkorpusar (allmänspråk)
• Digitaliserade böcker
• Open source‑kod
• Kända begränsningar
• Risk för hallucinationer
• Sämre prestanda på mindre språk
• Risk för reproduktion av bias från träningsdata
• Prestandamått
• Resultat på standard‑benchmarks

2. Information till kunder (art. 53–54)

Du publicerar en användarguide:

• Rekommenderade användningsområden: prototyper, assistans, idé‑generering
• Varningar:
• Får inte användas som enda grund för rättsliga beslut om individer
• Kräver mänsklig granskning vid medicinsk rådgivning
• Tekniska råd:
• Hur man loggar användning
• Hur man bygger säkerhetsfilter runt modellen

3. Upphovsrätt (art. 55)

Du:

• Dokumenterar vilka datakategorier som innehåller upphovsrättsskyddat material (t.ex. böcker, tidningsartiklar)
• Publicerar en sammanfattning över datakällor, t.ex.:
• "Modellen har tränats på böcker licensierade från förlag X och Y, nyhetsarkiv från Z, samt publika webbkorpusar insamlade enligt gällande upphovsrättsregler."

> Poängen: Du behöver inte avslöja varje enskild bok, men du måste visa att du tagit hänsyn till upphovsrätt och ge en meningsfull sammanfattning.

Steg 5: GPAI‑modeller med systemrisk – vad menas? (artiklarna 51, 56–57)

Vissa GPAI‑modeller är så stora och kraftfulla att deras användning kan påverka hela samhällssystem. Dessa kallas GPAI‑modeller med systemrisk.

Enligt kapitel IV (särskilt artiklarna 51, 56–57) beaktas bland annat:

1. Skalnivå

• Mycket stor beräkningskapacitet vid träning (t.ex. extremt hög FLOPs‑nivå)
• Mycket stor användarbas eller integration i kritisk infrastruktur

1. Potentiell påverkan

• Kan möjliggöra allvarliga skador på grundläggande rättigheter (t.ex. massövervakning, desinformation i stor skala)
• Kan användas för att utveckla avancerade cyberattacker eller biologiska/kemiska hot

1. Oförutsägbarhet och emergenta egenskaper

• Modellen uppvisar beteenden som inte enkelt kan förutses av utvecklaren
• Svår att kontrollera i nedströms applikationer

Hur avgörs om det är systemrisk?

• AI Office på EU‑nivå har en central roll (mer i nästa steg).
• Det finns trösklar och kriterier (t.ex. baserat på beräkningsresurser vid träning) som används som indikatorer.
• Leverantörer kan behöva göra en egen bedömning och rapportera till AI Office.

> Tänk: Systemrisk ≈ modell med sådan skala och kapacitet att felanvändning eller oavsiktliga effekter kan få samhällsomfattande konsekvenser.

Steg 6: Extra krav för GPAI‑modeller med systemrisk (artiklarna 58–60)

När en GPAI‑modell bedöms ha systemrisk skärps kraven på leverantören. Utöver de basåtaganden du redan sett tillkommer bl.a. (se särskilt artiklarna 58–60):

1. Avancerad modellutvärdering och riskhantering (art. 58)

Leverantören ska:

• genomföra omfattande tester före utsläppande på marknaden
• analysera systemrisker (t.ex. möjligheter till massdesinformation, avancerade cyberattacker)
• dokumentera riskreducerande åtgärder (säkerhetsfilter, begränsningar, API‑kontroller)

1. Säkerhetsåtgärder och kontinuerlig övervakning (art. 58–59)

• Upprätthålla kontinuerlig övervakning av modellens beteende i verklig användning
• Uppdatera modellen eller skyddsmekanismer när nya risker upptäcks
• Ha interna processer för incidenthantering och samarbete med myndigheter

1. Rapportering och transparens till AI Office (art. 59)

• Regelbunden rapportering om:
• kända allvarliga incidenter
• större uppdateringar av modellen
• Tillgång till viss dokumentation för AI Office och andra relevanta myndigheter

1. Registrering i EU‑databas (art. 60)

• GPAI‑modeller med systemrisk ska registreras i en offentlig EU‑databas, med centrala uppgifter om modellen och dess leverantör.

> Kontrast: En "vanlig" GPAI‑modell behöver dokumentation och upphovsrättshantering. En GPAI‑modell med systemrisk behöver dessutom djupgående riskanalys, löpande övervakning och nära dialog med AI Office.

Steg 7: AI Office och bedömningen av systemrisk

EU har inrättat ett AI Office (under EU‑kommissionen) som har en nyckelroll för GPAI‑modeller.

I relation till kapitel IV gör AI Office bland annat:

1. Fastställer kriterier för systemrisk

• Utvecklar riktlinjer och tekniska kriterier (t.ex. beräkningströsklar) för när en modell ska anses ha systemrisk.

1. Bedömer och klassificerar modeller

• Kan, baserat på information från leverantörer och andra källor, besluta att en viss modell omfattas av reglerna för GPAI‑modeller med systemrisk.

1. Övervakar efterlevnad

• Kan begära dokumentation, utvärderingsrapporter och annan information från leverantörer.
• Samarbetar med nationella tillsynsmyndigheter.

1. Samordnar standarder och bästa praxis

• Främjar utveckling av harmoniserade standarder för testning, dokumentation och riskhantering av GPAI‑modeller.

> Praktiskt: För en leverantör av en mycket stor modell blir AI Office en central motpart. För en nedströms utvecklare är AI Office mer "i bakgrunden", men påverkar genom vilka krav som ställs på modellleverantören.

Steg 8: Förhållandet mellan GPAI‑modeller och nedströms AI‑system (artiklarna 52, 61)

Kapitel IV reglerar modellerna, medan kapitel III reglerar många av systemen som byggs ovanpå modellerna.

Nyckelpoänger:

1. Delat ansvar

• Leverantören av GPAI‑modellen ansvarar för:
• modellens grundläggande egenskaper
• dokumentation, riskinformation, upphovsrätt
• Nedströms utvecklare (providers of AI systems) ansvarar för:
• hur modellen används i ett specifikt system
• att uppfylla kraven för t.ex. högrisk‑AI (kapitel III, artiklarna 8–29)

1. Hur GPAI‑kraven hjälper nedströms aktörer

• Genom dokumentation och model cards får nedströms utvecklare:
• bättre underlag för riskhantering (art. 9)
• underlag för teknisk dokumentation av sitt AI‑system (art. 11)
• information för mänsklig översyn och transparens (art. 13–14)

1. Kedjeeffekt vid systemrisk

• Om en underliggande modell klassas som GPAI‑modell med systemrisk, kan nedströms system:
• behöva ta hänsyn till extra begränsningar eller säkerhetsåtgärder som leverantören anger
• få tillgång till mer detaljerad dokumentation och riskinformation

1. Art. 61 – samarbete i värdekedjan

• Uppmuntrar informationsutbyte mellan modellleverantörer, systemutvecklare och deployers.
• Syftet är att minska informationsasymmetrier: nedströms aktörer ska inte behöva gissa hur modellen fungerar.

> Bild i huvudet: En kedja från modell → AI‑system → slutanvändare. Kapitel IV stärker den första länken så att resten av kedjan kan uppfylla sina skyldigheter.

Steg 9: Snabbtest – förståelse av GPAI‑skyldigheter

Testa din förståelse av kärnidéerna i kapitel IV.

Steg 10: Repetition av nyckelbegrepp

Använd korten för att repetera de viktigaste begreppen från kapitel IV.

Steg 11: Applicera på din egen (eller en tänkt) modell

Avsluta med att koppla kapitlet till en konkret modell du känner till eller vill utveckla.

1. Identifiera modellen

Välj en verklig eller hypotetisk modell, t.ex.:

• en språkmodell för kundtjänst
• en bildgenereringsmodell för marknadsföring
• en multimodal modell för utbildning

1. Är det en GPAI‑modell?

Svara för dig själv:

• Har modellen breda uppgiftsförmågor?
• Kan den användas i många olika system och domäner?
• Om ja: vilka artiklar i kapitel IV blir relevanta (minst art. 53–55)?

1. Systemrisk eller inte?

Fundera:

• Vilken skala (träning, användare) skulle krävas för att du skulle bli orolig för systemrisk?
• Vilka typer av skador skulle kunna uppstå i värsta fall?

1. Checklista för skyldigheter

Gör en kort lista (punkter) över vad du som leverantör skulle behöva:

• Dokumentera (teknisk dokumentation, model card)
• Informera kunder om (begränsningar, risker)
• Göra kring upphovsrätt
• Göra extra om modellen riskerar att klassas som med systemrisk

> Tips: För en verklig projektidé kan du markera vilka artiklar (t.ex. 53, 55, 58) som du behöver läsa mer i originaltexten.