Bygg AI-inventeringen före 2 augusti 2026: praktisk vägledning för SMF i EU

Sammanfattning

Merparten av AI-förordningens substantiella skyldigheter börjar tillämpas 2 augusti 2026 — högrisk-skyldigheterna i bilaga III enligt artiklarna 8 till 22, ibruktagarens skyldigheter enligt artikel 26, transparenskraven enligt artikel 50 samt registreringen i EU-databasen enligt artikel 49. Ingen av dessa skyldigheter går att fullgöra utan en komplett och aktuell inventering med utsedda ägare över varje AI-system inom tillämpningsområdet. Förbuden i artikel 5 har varit verkställbara sedan 2 februari 2025 och GPAI-skyldigheterna sedan 2 augusti 2025 (art. 113), så en inventering som byggs idag måste redan från start täcka screening mot förbjudna praktiker, GPAI-flödesposter på ibruktagarsidan och det löpande klassificeringsarbetet. Den goda nyheten för resursbegränsade SMF: ni har med största sannolikhet redan motsvarande register för GDPR artikel 30 (register över behandlingar), NIS2-tillgångsregister och ISO 27001 bilaga A.5.9 — AI-inventeringen byggs lämpligast som en utvidgning av dessa, inte som ett parallellt register. Denna vägledning ger fältlistan, återanvändningskartan, tre konkreta SMF-exempel, vanliga luckor och en 60-dagarsplan så att registret är på plats innan tidsfristen slår till.

Varför AI-inventeringen är avgörande den 2 augusti 2026

AI-förordningen ålägger inte en enda namngiven "inventeringsskyldighet". Den ålägger ett dussin skyldigheter som en efterlevnadsansvarig endast kan fullgöra om hen vet vilka AI-system som finns i organisationen, vad de gör, vem som äger dem och vilken risknivå de befinner sig på. Artikel 9 om riskhantering förutsätter en lista över system att köra analysen mot. Artikel 11 om teknisk dokumentation förutsätter att de berörda systemen har identifierats. Ibruktagarskyldigheterna i artikel 26 — mänsklig tillsyn, övervakning, loggning, information till berörd personal — gäller per system, och de går inte att tillämpa per system utan ett register per system. EU-databasregistreringen i artikel 49 är i sig en inlämning på systemnivå. Utan inventeringen går resten varken att ordna, prioritera eller belägga.

Sanktionerna är medvetet konstruerade för att göra glappet dyrt. Artikel 99 fastställer administrativa böter på 35 miljoner euro eller 7 % av global årsomsättning för förbjudna praktiker (art. 99.3), 15 miljoner euro eller 3 % för bristande efterlevnad av högrisk-skyldigheter (art. 99.4) och 7,5 miljoner euro eller 1 % för felaktiga, ofullständiga eller vilseledande uppgifter till anmälda organ och behöriga myndigheter (art. 99.5). SMF får en partiell lättnad enligt artikel 99.6 — böter får sättas till det lägre av det absoluta beloppet eller procenttalet snarare än det högre — men lättnaden tar inte bort taket, och den gäller över huvud taget inte för den mest skadliga felkategorin: att vid en tillsynsåtgärd upptäcka att man inte vet vilka AI-system man driver. En ofullständig inventering är förutsättningen för den tredje sanktionstypen, eftersom varje svar ni då lämnar till myndigheten med nödvändighet är en uppskattning.

Det finns också en marknadstillträdesdimension. Artikel 79 ger marknadskontrollmyndigheten möjlighet att kräva korrigerande åtgärder för icke konforma högrisksystem, inklusive återkallelse från EU-marknaden. För en B2B-SaaS-leverantör vars företagsavtal innehåller efterlevnadsgarantier — och vars kunder från hösten 2025 och framåt börjar kräva AI-godkännande i upphandlingar — är oförmågan att producera en inventering på systemnivå vid förfrågan en kommersiell risk långt innan den blir en regulatorisk risk. De kunder som frågar först blir de tyska, franska och nederländska företag som redan kör mogna GDPR-leverantörsgranskningar. De accepterar inte "vi kartlägger fortfarande" som svar i slutet av 2026.

Vad "AI-system" betyder enligt artikel 3.1

Artikel 3.1 definierar ett AI-system som ett maskinbaserat system som är utformat för att fungera med varierande grad av autonomi och som kan uppvisa anpassningsförmåga efter ibruktagandet, samt som utifrån uttryckliga eller underförstådda mål härleder, från den indata det tar emot, hur det ska generera utdata såsom prediktioner, innehåll, rekommendationer eller beslut, vilket kan påverka fysiska eller virtuella miljöer. Definitionen är medvetet anpassad till OECD:s reviderade definition från 2023 och avsiktligt bred. Varje organisation som läst den noggrant får samma första reaktion: detta är vidare än vi antog.

Tre konsekvenser följer för inventeringens omfattning. För det första är "maskininlärning" inte en förutsättning. Ett regelbaserat expertsystem som härleder utdata från indata mot en kunskapsbas faller inom definitionen, även om de flesta tekniker inte skulle kalla det AI. Skäl 12 undantar vissa klassiska statistiska och optimerande tekniker där det inte finns något inferenselement, men undantaget är snävt och omtvistat i kanten. Vid tvivel: ta med systemet i inventeringen och dokumentera skälet till att det inte kräver en risknivåklassificering.

För det andra innebär "varierande grad av autonomi" att gränsen mellan AI och konventionell programvara inte går vid "människa i loopen". Ett system med obligatoriskt mänskligt godkännande av varje utdata är fortfarande ett AI-system om det härleder dessa utdata. Artikel 14 om mänsklig tillsyn är då en designegenskap hos AI-systemet, inte en utgång ur AI-förordningen. CV-screeningverktyg som tar fram en rangordnad slutlista som rekryteraren får välja från är AI-system även när rekryteraren formellt fattar anställningsbeslutet.

För det tredje drar "utdata som kan påverka fysiska eller virtuella miljöer" in en lång lista över operativ programvara som organisationer sällan etiketterar som AI: dynamiska prismotorer, modeller för bedrägeripoängsättning, prediktorer för kundavhopp, klassificerare för innehållsmoderation, rekommendationssystem, automatiserad e-postdirigering, efterfrågeprognoser och prediktiva underhållsmodeller. De flesta visar sig vara minimala risker enligt klassificeringsanalysen, men de hör hemma i inventeringen ändå. Poängen med registret är att visa att en klassificering har utförts, inte bara att räkna upp de system som visade sig vara högrisk.

Att koppla inventeringen till AI-förordningens risknivåer

Varje post i inventeringen bär en risknivåetikett, och etiketten styr resten av akten. De fem kategorierna — oacceptabel, hög risk, begränsad risk, minimal risk samt GPAI-överlägget — sitter ovanpå samma register, och en enskild produkt kan generera flera inventeringsposter när den innehåller flera distinkta AI-användningsfall. Behandla posterna som enheter av efterlevnadsarbete, inte som en leverantörskatalog.

System med oacceptabel risk enligt artikel 5 — åtta förbjudna familjer som täcker manipulativa tekniker, utnyttjande av sårbarheter, social poängsättning, profileringsbaserad förebyggande polisverksamhet, oriktad insamling av ansiktsbilder, känsloigenkänning på arbetsplats och i utbildning, biometrisk kategorisering efter känsliga attribut samt biometrisk identifiering i realtid på offentlig plats för brottsbekämpning — bör aldrig förekomma som aktiva inventeringsposter. Om ett befintligt system eller en planerad upphandling matchar något förbud finns inventeringsposten endast för att dokumentera beslutet om utfasning. Förbuden har varit verkställbara sedan 2 februari 2025, så detta är inte längre en framtida skyldighet.

Högriskposter — bilaga III-kategorierna plus säkerhetskomponenter i bilaga I-produkter enligt artikel 6.1 — bär den tyngsta fältuppsättningen. De tretton skyldigheterna i artiklarna 9 till 49 genererar dokumentationskrav som en tunn inventeringspost inte kan stötta. För högriskposter är det bäst att betrakta inventeringen som ett index som pekar mot en separat teknisk akt enligt artikel 11 och bilaga IV, där inventeringsposten i sig endast bär den metadata en granskare behöver för att navigera till akten. De substantiella skyldigheterna gäller från 2 augusti 2026 för bilaga III-högrisksystem och från 2 augusti 2027 för produktsäkerhetsspåret enligt bilaga I i art. 6.1.

Ett andra filter verkar inom bilaga III. Artikel 6.3 ger ett undantag för bilaga III-system som inte utgör en betydande risk för skada eftersom de utför en snäv procedurmässig uppgift, förbättrar resultatet av en tidigare avslutad mänsklig aktivitet, upptäcker beslutsmönster eller avvikelser utan att ersätta mänsklig bedömning, eller utför en förberedande uppgift inför en bilaga III-bedömning. Profilering av fysiska personer diskvalificerar undantaget i samtliga fall. Varje bilaga III-post i inventeringen behöver en skriftlig art. 6.3-analys: antingen ett positivt utfall (med den specifika led som åberopas) och resonemanget, eller ett negativt utfall som bekräftar att systemet stannar i högriskkategorin.

Poster med begränsad risk — chattbottar, deepfake-verktyg, AI-genererad text eller media, känsloigenkänningssystem där de inte är förbjudna — bär transparensskyldigheterna enligt artikel 50. Inventeringen ska registrera avslöjandemekanismen per system: var chattbannerns text är placerad, vilken vattenmärkningsteknik som används för syntetiska utdata, redaktionsgranskningsloggen för AI-genererad text om frågor av allmänt intresse, och ibruktagarens notis som används för deepfakes. Skyldigheterna för begränsad risk gäller också från 2 augusti 2026, och till skillnad från högriskbanan finns ingen undantagsväg som lyfter plikten: varje chattbot behöver ett avslöjande och inventeringen behöver belägga det.

Poster med minimal risk utgör huvuddelen av registret. Det finns inga obligatoriska skyldigheter enligt AI-förordningen för dessa system, men inventeringen behöver ändå dokumentera det negativa utfallet — det dokumenterade resonemanget om att systemet inte faller inom bilaga III, inte interagerar direkt med fysiska personer och inte genererar syntetisk media. Skyldigheten om AI-kompetens i artikel 4 gäller oavsett risknivå, så inventeringen bör fånga vilken personalkategori som driver varje minimalt risksystem och bekräfta att de omfattas av AI-kompetensprogrammet.

GPAI är ett överlägg, inte en risknivå. Nästan varje SMF-inventeringspost som bygger på en grundmodell — GPT-4o, Claude, Gemini, Mistral Large, Llama, Command — är en ibruktagarpost enligt artikel 53.1 b som ärver flödesinformation från uppströmsleverantören. Inventeringen behöver ett särskilt fält för uppströmsmodellens identitet och version, leverantören, referensen till den publicerade träningsdatasammanställningen samt datumet då den senaste uppsättningen av leverantörens bruksanvisningar granskades. Det finns två separata regler att hålla isär. Artikel 25 överför leverantörsskyldigheterna för högrisk till en nedströmsaktör i tre fall — när aktören släpper ut ett högrisk-AI-system på marknaden under eget namn eller varumärke, väsentligt modifierar ett högrisksystem som redan finns på marknaden, eller modifierar det avsedda ändamålet med ett system som inte är högrisk (inklusive en GPAI) så att det blir högrisk enligt artikel 6. Skäl 109 behandlar ett annat fall: en organisation som finjusterar eller på annat sätt modifierar en GPAI utan att den blir ett högrisksystem. Där är skyldigheterna på nedströmsaktören begränsade till själva modifieringen — typiskt att komplettera uppströmsleverantörens tekniska dokumentation med information om förändringarna, inklusive eventuella nya träningsdatakällor. De flesta SMF passerar ingen av dessa trösklar, men inventeringen är det enda ställe där gränsdragningen dokumenteras för varje system.

Obligatoriska fält i inventeringen

En försvarbar AI-inventering har omkring femton fält per post. Motstå frestelsen att lägga till fler — varje extra fält är en underhållsbörda, och det hållbara registret är det som personalen faktiskt uppdaterar när systemen ändras. Listan nedan är minimumuppsättningen som stöder de skyldigheter som börjar tillämpas 2 augusti 2026.

• Systemnamn och unik identifierare — en stabil etikett som används konsekvent över den tekniska akten, EU-databasregistreringen, leverantörsavtalen och den interna ändringshanteringen.
• Ägare — en enda namngiven person inom organisationen som är ansvarig för att hålla posten uppdaterad och utlösa omklassificering när systemet ändras väsentligt. Ett team eller en avdelning är ingen ägare.
• Leverantör eller intern utveckling — om systemet byggs internt, upphandlas som SaaS eller är inbäddat i en större produkt. Detta avgör om ni är leverantör, ibruktagare eller bägge enligt artiklarna 25 och 26.
• Risknivå enligt AI-förordningen — oacceptabel, hög risk (artikel 6.1 eller 6.2 / bilaga III med specifik bilaga III-punkt), begränsad risk (med specifik artikel 50-punkt), minimal risk, plus en GPAI-flagga där det är aktuellt.
• Klassificeringsmotivering — en kort prosamotivering, inklusive eventuell tillämpning av art. 6.3-undantaget. Vaga motiveringar håller inte vid en granskning; standarden är "dokumenterad eftersom motiverad".
• Uppströmsmodell — för GPAI-ibruktagarposter: modellens identitet, version, leverantör samt datumet då uppströmsleverantörens bruksanvisning enligt artikel 53.1 b senast granskades.
• Avsett ändamål — det specifika användningsfallet såsom det beskrivs för ibruktagare, formulerat som i bruksanvisningen enligt artikel 13. Glidning mellan avsett ändamål och faktisk användning är ett av de vanligaste granskningsfynden.
• GDPR-rättslig grund — för varje system som behandlar personuppgifter: GDPR-artikel 6-grunden (och artikel 9-villkoret där känsliga kategorier är inblandade). Korsreferera mot motsvarande artikel 30-post.
• Träningsdatas ursprung — proveniensöversikt som täcker källa, licensvillkor, efterlevnad av upphovsrättsundantag och eventuell dataminimering eller avidentifiering. För GPAI-ibruktagarposter kan fältet hänvisa till uppströmsleverantörens publicerade träningsdatasammanställning.
• Typ av utdata — prediktion, rekommendation, klassificering, innehållsgenerering eller beslut. Utdatatypen styr transparensskyldigheterna i artikel 50 och GDPR-analysen enligt artikel 22.
• Beslutspåverkan — om utdata påverkar väsentliga beslut om identifierbara fysiska personer, och i så fall den berörda populationen (anställda, kandidater, kunder, patienter, mottagare). Detta är fältet som signalerar när en separat DPIA enligt artikel 35 GDPR eller en konsekvensbedömning för grundläggande rättigheter enligt artikel 27 i AI-förordningen krävs.
• Mänsklig tillsynsdesign — de åtgärder enligt artikel 14 som faktiskt har implementerats: granskning före driftsättning, validering av utdata, möjlighet till åsidosättande, interventionströsklar och eskaleringsvägar. Generiska poster som "en människa granskar utdata" klarar inte granskningsstandarden.
• Status för bedömning av överensstämmelse — för högriskposter: vald väg (intern kontroll enligt bilaga VI, tredjepartsbedömning enligt bilaga VII för biometri, integrerad bedömning för bilaga I-produkter), datum för senaste bedömningen och referens till EU-försäkran om överensstämmelse enligt artikel 47.
• EU-databasregistrering — för högriskposter som omfattas av artikel 49: registreringsidentifierare och datum för senaste uppdatering.
• Datum för senaste granskning och nästa granskningsutlösare — kalenderdatum för den senaste klassificeringsgranskningen och de förändringshändelser som tvingar fram en omgranskning (modellbyte, ändring av träningsdata, utvidgning av avsett ändamål, integration i ett nytt arbetsflöde).

Att återanvända det ni redan har

Den billigaste AI-inventeringen är den som utvidgas från befintliga register snarare än byggs från grunden. Tre redan existerande artefakter täcker de flesta av datafälten ovan och den styrning som krävs för att hålla dem aktuella.

Register över behandlingar enligt GDPR artikel 30 (ROPA på engelska) täcker personuppgiftsryggraden i varje AI-system som behandlar uppgifter om identifierbara fysiska personer. Registret fångar redan rättslig grund, kategorier av uppgifter, kategorier av registrerade, mottagare, internationella överföringar och bevarandetiderna — vart och ett av dessa fält behöver AI-inventeringen antingen replikera eller hänvisa till. Det pragmatiska greppet är att lägga till en kolumn "AI-systemreferens" i den befintliga ROPA, och på AI-inventeringssidan hänvisa till motsvarande ROPA-post i stället för att duplicera personuppgiftsfälten. DPIA enligt artikel 35 GDPR och eventuella konsekvensbedömningar för grundläggande rättigheter enligt artikel 27 i AI-förordningen — tillämpliga på ibruktagare som är offentliga organ eller privata enheter som tillhandahåller offentliga tjänster, samt separat på varje ibruktagare (offentlig eller privat) av ett system enligt bilaga III §5(b) (kreditvärdighet) eller §5(c) (riskbedömning eller prissättning av liv- eller sjukförsäkring) — bör båda länkas ut från inventeringsposten snarare än kopieras in.

NIS2-tillgångsregister, där sådana finns, täcker drift- och informationssäkerhetsryggraden. Medlemsstaternas NIS2-genomförandelagar — genomförandetidsfristen var 17 oktober 2024 och Europeiska kommissionen inledde överträdelseförfaranden i november 2024 mot 23 medlemsstater som missat den; genomförandet har sedan rullat ut i vågor under 2025 och 2026 — kräver att väsentliga och viktiga enheter upprätthåller ett register över IKT-tillgångar och beroenden. För SMF som omfattas av NIS2 innehåller registret typiskt redan molnplattformarna, SaaS-beroenden och kritiska programvarusystem som AI-arbetslasterna körs på. Att tagga AI-system i NIS2-registret och korshänvisa till AI-inventeringen anpassar de två regelverken och förhindrar situationen där en organisations NIS2-inventering visar en tredjeparts-SaaS utan att markera att SaaS-tjänsten innehåller ett AI-användningsfall som omfattas av AI-förordningen.

ISO/IEC 27001:2022 bilaga A.5.9 (tidigare A.8.1.1 i 2013 års version) kräver en inventering av information och associerade tillgångar, inklusive programvara, tjänster och informationen själv. För ISO-certifierade SMF är den tillgångsinventering som A.5.9 kräver den naturliga bäraren av AI-registret. Den granskningsspår som ISO 27001 kräver — ägare, klassificering, ändringshistorik — kartläggs redan mot AI-förordningens inventeringsfält ovan. Att behandla AI-inventeringen som en delmängd av ISO 27001-tillgångsinventeringen snarare än som en ny artefakt sparar dubbelt underhåll, ger AI-registret nyttan av den befintliga ISMS-granskningskadensen och förhindrar det alltför vanliga tillstånd där ISMS-tillgångsregistret och AI-inventeringen glider ifrån varandra.

Utöver dessa tre är två angränsande register värda att beröra: upphandlingsleverantörsregistret (som vanligen fångar varje extern SaaS organisationen använder, och ofta är den snabbaste vägen till en komplett skugg-AI-svep) samt registret över samtycke eller avtalsgrund för dataskyddet (som redan ligger till grund för GDPR-sidan av varje kundvänt AI-system). När AI-inventeringen byggs som en federation av referenser över dessa befintliga register snarare än som ett nytt kalkylark sjunker underhållskostnaden med ungefär hälften, och den korsregimkonsistens som granskare letar efter framträder naturligt.

Tre SMF-exempel på inventering

Konkreta exempel skärper disciplinen. Tre korta fall nedan visar hur inventeringsschemat landar i praktiken hos en HR-tech-leverantör, en FinTech och en MedTech-SMF, var och en typisk för det tidiga europeiska bolag som är mest utsatt för tidsfristen 2 augusti 2026.

HR-tech: 50 anställda, SaaS-leverantör i München

Produkten erbjuder ett ansökningshanteringssystem med två AI-drivna funktioner: en CV-sammanfattningsfunktion byggd ovanpå GPT-4o och en intern kandidatrangordningsfunktion tränad på kundens historiska anställningsdata. Inventeringen innehåller två distinkta poster, inte en. Post A — CV-sammanfattning — är ett system med begränsad risk i sig (artikel 50.1, chattbotsstil-transparens, eftersom rekryteraren ser en sammanfattning som tydligt märkts som AI-genererad), med ett GPAI-ibruktagaröverlägg som pekar på OpenAI som uppströmsleverantör. Post B — kandidatrangordning — är otvetydigt högrisk enligt bilaga III punkt 4 a (anställning, rekrytering, kandidaturval), med leverantören som leverantör eftersom systemet släpps ut på EU-marknaden under leverantörens eget namn. Post B bär den fulla uppsättningen av tretton skyldigheter i artiklarna 9 till 49; post A bär endast avslöjandet enligt artikel 50.1 plus GPAI-flödesposten. Den gemensamma ägaren för båda posterna är produktchefen, med en utsedd AI-förordningsansvarig på juridikavdelningen som sekundär ägare. Inventeringen korsrefererar ISO 27001-tillgångsregistret (företaget är certifierat) för båda posterna och GDPR-ROPA för personuppgiftsfälten. Båda posterna markerar 2 augusti 2026 som utlösare för slutförande av den tekniska akten enligt artikel 11 och bilaga IV.

FinTech: 30 anställda, konsumentkreditbolag i Vilnius

Produkten erbjuder en konsumentkreditansökan med två AI-komponenter: en kreditbedömningsmodell tränad på interna data samt open banking-signaler, och en bedrägeridetekteringsmodell ovanpå transaktionstelemetri. Kreditbedömningsmodellen landar i bilaga III punkt 5 b — kreditvärdighetsbedömning av fysiska personer — och är högrisk som standard; bolaget är leverantör, släpper ut systemet på sin egen plattform och kör intern kontroll-överensstämmelsebedömning enligt bilaga VI. Bedrägeridetekteringsmodellen utnyttjar det textuella undantaget som skrivits direkt in i bilaga III §5(b), vilket utesluter "AI-system som används för att upptäcka finansiella bedrägerier" från kreditvärdighetskategorin redan från början — det är ett annat undantag än det procedurmässiga undantaget i artikel 6.3 som filtrerar bilaga III-system generellt, och inventeringsposten behöver göra klart vilken utgång som används. Eftersom undantaget är snävt (det täcker bedrägeridetektering, inte all transaktionsriskpoängsättning) intar bolagets juridikteam klokt en defensiv hållning genom att upprätthålla en partiell högriskkontrolluppsättning på bedrägerimodellen, och utlöser en omklassificering varje gång modellens ändamål utvidgas bortom bedrägeridetektering. Gränsfallet är en kundsupportchattbot byggd på Mistral Large; den blir en post C med begränsad risk och GPAI-ibruktagaröverlägg. Korsreferensen till GDPR-ROPA är kritisk här eftersom artikel 22 GDPR (automatiserat individuellt beslutsfattande) gäller för kreditbedömningsposten, och inventeringen behöver belägga den registrerades rätt att få mänskligt ingripande, uttrycka sin åsikt och bestrida beslutet. Artikel 27 i AI-förordningen biter också här — varje ibruktagare av ett bilaga III §5(b)-system måste utföra en konsekvensbedömning för grundläggande rättigheter, oavsett om ibruktagaren är offentlig eller privat. Dataskyddsombudet är utsedd ägare för båda högriskposterna; chefen för kundverksamheten äger chattboten.

MedTech: 20 anställda, distansövervakningsbolag i Dublin

Produkten är en applikation för distansövervakning av patienter med ett enda AI-användningsfall: en algoritm som flaggar kliniskt signifikanta förändringar i vitalparametrar baserat på kontinuerlig telemetri från en bärbar enhet. Systemet är reglerat som medicinteknisk produkt enligt förordning (EU) 2017/745 (MDR) och CE-märkt enligt det regelverket. AI-inventeringsposten är högrisk enligt artikel 6.1 — AI:n är en säkerhetskomponent i en produkt som omfattas av bilaga I EU-harmoniseringslagstiftning (medicintekniska produkter) som kräver tredjepartsbedömning av överensstämmelse. De substantiella högrisk-skyldigheterna enligt AI-förordningen gäller för denna post från 2 augusti 2027, inte 2 augusti 2026, på grund av den uppskjutna tidsplanen för artikel 6.1 i artikel 113. Bedömningen av överensstämmelse integreras med den befintliga MDR-proceduren; det anmälda organet som verkar enligt MDR täcker även det AI-specifika överensstämmelsearbetet, med de AI-förordningsspecifika leveranserna (teknisk dokumentation enligt artikel 11, riskhantering enligt artikel 9, transparens för vårdpersonal enligt artikel 13) lagda ovanpå den befintliga tekniska akten. Inventeringsposten hänvisar till MDR-akten snarare än duplicerar den, kvalitetsledningsägaren är samma person som redan leder MDR artikel 10-ansvaret för kvalitetsledningen, och inventeringen korsrefererar GDPR-ROPA för behandlingen av personliga hälsodata enligt artikel 9.2 h GDPR. Den uppskjutna tidsfristen är fällan här: en MedTech som av misstag tar 2 augusti 2026 som sin utlösare hamnar i parallellt överensstämmelsearbete tolv månader för tidigt.

Luckor som drabbar SMF

Tre kategorier av luckor dyker upp upprepade gånger i SMF-inventeringsarbete, och var och en undergräver tyst registret om den inte jagas medvetet.

Skugg-AI är den största. Marknadsteam använder Jasper, ChatGPT Team eller Copy.ai för innehållsutkast. Säljteam kopplar in Gong, Apollo eller Lavender till samtalsinspelningar och e-postutskick. Utvecklingsteam använder GitHub Copilot, Cursor eller Codeium utan formellt upphandlingsbeslut. HR kör enkäter genom ChatGPT och matar fritextsvar genom sentimentklassificerare. Var och en av dessa är ett AI-användningsfall inom artikel 3.1, nästan säkert under begränsad eller minimal risk i sig, men osynligt för den centrala inventeringen om ingen frågar. Lösningen är procedurell: en ensidig deklarationsblankett som cirkuleras till varje avdelningschef och ber dem lista varje AI-verktyg som teamet använt under de senaste sex månaderna, upprepad varje kvartal, med kreditkortsutdraget och SaaS-utgiftsboken som korskontroller. Den första rundan av deklarationer från ett typiskt 50-personers SaaS-bolag avslöjar mellan tolv och tjugo AI-verktyg som den centrala efterlevnadsfunktionen inte kände till.

Inbäddad AI inom SaaS är den andra luckan. I allt högre grad har den standardiserade B2B-SaaS-produkten som organisationen använt i åratal tyst lagt till AI-funktioner under 2024 och 2025 — Salesforce Einstein, HubSpot AI, Notion AI, Slack AI, Zoom AI Companion, Microsoft 365 Copilot, Google Workspace Gemini-funktioner, Atlassian Intelligence. Värdorganisationen är ibruktagare av vart och ett av dessa AI-delsystem, även om upphandlingen ursprungligen avsåg det underliggande produktivitetsverktyget. Inventeringen måste fånga varje AI-delfunktion som en distinkt post, inte slå ihop dem under den överordnade SaaS-raden. Varje leverantör är i sin tur GPAI-ibruktagare ovanpå en uppströmsmodellleverantör, så flödeskedjan löper i tre lager: grundmodell (OpenAI/Anthropic/Google) → SaaS-leverantör (HubSpot/Microsoft/Slack) → värdorganisation. Inventeringsposten behöver namnge alla tre lagren om ibruktagarskyldigheterna ska vara verkställbara.

Modellbyten är den tredje och mest hala luckan. En SaaS-leverantör byter sin underliggande GPAI-modell — säg från GPT-4 till GPT-4o, eller från Claude 3.5 till Claude 4 — utan att produktytan ändras, och AI-inventeringsposten på ibruktagarsidan blir tyst felaktig. Lösningen är att lägga till ett fält "modellversion låst" i inventeringen och kräva en omklassificeringsutlösare när uppströmsmodellen ändras. För mogna leverantörer aviseras ändringen vanligen via en releasenotiskanal som upphandlingsteamet bör prenumerera på; för mindre mogna leverantörer bör inventeringsposten uttryckligen notera att uppströmsmodellens identitet är volatil, och granskningskadensen för den posten bör skärpas (kvartalsvis snarare än årligen).

Vanliga problem med ägaransvar

Den vanligaste anledningen till att en AI-inventering glider in i värdelöshet är att ägarskapet tilldelas ett team eller en avdelning snarare än en namngiven individ. "Produktteamet äger post 7" är ett icke-svar när systemet ändras väsentligt och ingen uppdaterar posten, eftersom ingen personligen är skyldig att göra uppdateringen. Den disciplin som håller alla andra regulatoriska register samman — det namngivna dataskyddsombudet bakom GDPR-ROPA, den namngivna CISO bakom ISO 27001-tillgångsregistret, den namngivna NIS2-kontaktpersonen i medlemsstatens anmälan — är samma disciplin AI-inventeringen behöver.

Tre mönster fungerar i praktiken. Det första är en enskild AI-förordningsansvarig, typiskt placerad i juridik- eller efterlevnadsfunktionen, som äger det centrala registret och är namngiven ägare för de högsta riskposterna (de högrisk-bilaga III-system där den tekniska akten enligt artikel 11 kräver tvärfunktionell input). Det andra är en federerad modell där den AI-förordningsansvarige äger registret självt och metodiken, medan enskilda produktägare eller funktionsägare är namngivna på varje post — lämpligt för SaaS-organisationer där nya AI-funktioner släpps varje kvartal och centralt ägarskap över varje post skulle skapa en flaskhals. Det tredje är en samägningsmodell där varje högriskpost har en utsedd verksamhetsägare (produktchefen eller chefen för den relevanta funktionen) och en utsedd kontrollägare (dataskyddsombudet eller den AI-förordningsansvarige) — verksamhetsägaren ansvarar för att hålla posten aktuell när systemet utvecklas, kontrollägaren ansvarar för att skyldighetsuppsättningen uppfylls. Alla tre modeller är försvarbara; det som inte är försvarbart är att lämna poster med teamnivå- eller obesatt ägarskap.

Ett andra problem med ägartilldelning är den frånvarande motpartägaren på tvärfunktionella poster. HR-tech-exemplet ovan är det kanoniska fallet: produktägaren för kandidatrangordningsfunktionen är naturligt placerad att hålla den tekniska akten aktuell, men skyldigheten att informera berörda anställda enligt artikel 26.7 vilar hos kundens egen HR-funktion på ibruktagarsidan, inte hos leverantören. Om leverantörens inventeringspost inte namnger en motpartägare inom varje kundorganisation kan de kaskaderande ibruktagarskyldigheterna i artikel 26 inte beläggas, och leverantörens egen bruksanvisning enligt artikel 13 kan inte adresseras korrekt. Kunddokumentationen vid onboarding och mallen för huvudtjänsteavtalet behöver båda en klausul som kräver att kunden namnger en AI-förordnings-ibruktagarägare före aktivering.

Artikel 26.5 förtjänar en sista nämning eftersom den är en av de få ibruktagarskyldigheterna som överraskar även disciplinerade inventeringar. Ibruktagare av högrisk-AI-system ska övervaka systemets drift utifrån bruksanvisningen och, där det är relevant, informera leverantörer i enlighet med artikel 72. Där ibruktagare har skäl att anta att användning enligt bruksanvisningen kan leda till att systemet uppvisar en risk i den mening som avses i artikel 79.1 ska de utan onödigt dröjsmål informera leverantören eller distributören och den behöriga marknadskontrollmyndigheten — och avbryta användningen av systemet. Praktiskt innebär det att varje högriskpost i inventeringen behöver en namngiven övervakningsägare på ibruktagarsidan, en dokumenterad eskaleringsväg som slutar hos den relevanta nationella behöriga myndigheten samt ett skriftligt avbrottsprotokoll som kan aktiveras utan ytterligare interna godkännanden. Att utse dessa sent, efter att systemet redan är i drift, är ett av de vanligaste fynden vid tidiga tillsynsgranskningar.

60-dagars uppbyggnadsplan

Sextio dagar räcker för att leverera en försvarbar första version av inventeringen om arbetet sekvenseras rent, ledningen åtar sig kadensen vid starten och befintliga register återanvänds snarare än dupliceras. Planen nedan förutsätter en typisk SMF med 30 till 100 anställda utan tidigare AI-styrningsfunktion och en tvärfunktionell AI-förordningsansvarig utsedd för arbetet.

Dag 1 till 10 — omfattning och återanvändningskartläggning. Den AI-förordningsansvarige samlar in den befintliga GDPR-ROPA, ISO 27001-tillgångsinventeringen (där tillämplig), NIS2-registret (där omfattat), upphandlingsleverantörslistan och SaaS-utgiftsboken. Varje post över dessa register granskas för AI-relevans, och de som rör AI flaggas för inventeringen. Den ansvarige utarbetar inventeringsschemat — den femtonfälts-uppsättning som beskrivits ovan, med eventuella organisationsspecifika tillägg — och cirkulerar det för godkännande av dataskyddsombudet, CISO (där sådan finns) och en sponsor på ledningsorganet. Verktygsval avgörs i samma fönster: kalkylark, GRC-plattform eller utvidgning av ROPA-verktyget. För SMF utan GRC-plattform räcker ett strukturerat kalkylark under versionshantering med obligatoriska granskningsfält för den första versionen.

Dag 11 till 30 — upptäckt och populering. Skugg-AI-svepet körs i detta fönster: en ensidig deklarationsblankett till varje avdelningschef, en SaaS-utgiftsavstämning och strukturerade intervjuer med varje funktionsledare (produkt, utveckling, marknad, sälj, kundsupport, HR, ekonomi, drift). Varje deklaration blir en utkasts-inventeringspost. Den AI-förordningsansvarige populerar metadatafälten från de befintliga ROPA- och tillgångsregistren där datan redan finns och öppnar endast en ny datainsamlingstråd för fält som verkligen är AI-specifika (avsett ändamål, utdatatyp, uppströmsmodell, träningsdatas ursprung, mänsklig tillsynsdesign). I slutet av dag 30 ska varje AI-användningsfall som organisationen känner till ha en utkasts-inventeringspost, även om risknivåklassificeringen är preliminär och motiveringen fortfarande är skelettartad.

Dag 31 till 50 — klassificering och gapanalys. Den AI-förordningsansvarige går igenom varje utkastspost via risknivåbeslutsträdet (åtta frågor som täcker artikel 5, bilaga III, artikel 6.1, artikel 6.3, leverantör/ibruktagar-status, GPAI-överlägg, artikel 50.1-interaktion, artikel 50.2/50.4 syntetiskt innehåll och artikel 51 systemisk risk). Varje post tilldelas en risknivå med en skriftlig motivering. För högrisk- och begränsade-risk-poster kör den ansvarige en gapanalys mot motsvarande skyldighetsuppsättning: för högrisk, baslinjen med tretton skyldigheter i artiklarna 9 till 49; för begränsad risk, de fyra avslöjandeskyldigheterna i artikel 50. Varje gap blir en åtgärdsuppgift med en namngiven ägare och måldatum, sekvenserad mot 2 augusti 2026 (eller 2 augusti 2027 för bilaga I artikel 6.1-poster). Omfattningen för DPIA och konsekvensbedömning för grundläggande rättigheter enligt artikel 27 avgörs i samma fönster: varje högriskpost som behandlar personuppgifter utlöser en DPIA-granskning, och varje högriskpost som drivs av ett offentligt organ, av en privat enhet som tillhandahåller offentliga tjänster, eller av varje ibruktagare av ett system enligt bilaga III §5(b) (kreditvärdighet) eller §5(c) (prissättning av liv- eller sjukförsäkring) utlöser en FRIA enligt artikel 27.

Dag 51 till 60 — godkännande och driftskadens. Inventeringen och åtgärdsbackloggen presenteras för ledningsorganet för godkännande. AI-förordningspunkten läggs till som en stående kvartalspunkt på styrelseagendan. Ägaren för varje högriskpost utses formellt skriftligen, och övervakningsägarna för artikel 26.5 på ibruktagarsidan bekräftas tillsammans med deras avbrottsbefogenhet. Kundvända avtal och onboarding-dokumentation granskas för bruksanvisningen enligt artikel 13 och ibruktagarflödesklausulerna enligt artikel 26. AI-kompetensprogrammet enligt artikel 4 omfattningsbestäms, med inventeringen som verktyg för att identifiera de personalkategorier som driver eller använder varje system. En första intern granskning av inventeringen schemaläggs till slutet av Q1 2027 — sex månader efter att skyldigheterna börjat tillämpas, tillräckligt långt för att skarp drift ska ha synliggjort den första rundan av problem, tillräckligt kort för att gap fortfarande ska kunna åtgärdas före den första externa granskningscykeln. Den andra versionsgranskningen av inventeringen själv schemaläggs till slutet av Q2 2027.

Slutsats och nästa steg

Tidsfristen 2 augusti 2026 är fast och asymmetrisk: kostnaden för att vara sen med inventeringen är vida högre än kostnaden för att vara tidig, eftersom nästan varje annan skyldighet i AI-förordningen vilar på den. Arbetet är också ovanligt väl anpassat till det europeiska SMF redan gör väl — register över behandlingar enligt GDPR artikel 30, NIS2-tillgångsregister, ISO 27001-tillgångsinventeringar — så den marginella ansträngningen är meningsfullt lägre än rubrikförordningen antyder. Fällan är att behandla AI-inventeringen som en parallell artefakt snarare än som en utvidgning av de register som redan finns. Bygg den som en federation, namnge en enskild individ som ägare för varje post, och behandla skugg-AI, inbäddad SaaS-AI och modellbyten som de tre lucktyper som tyst kommer att underminera registret om de inte jagas explicit.

Praktiskt ser de kommande sextio dagarna ut så här för en SMF som börjar från noll: utse en AI-förordningsansvarig under vecka ett, lås schemat och återanvändningsplanen under vecka två, kör skugg-AI-svepet under vecka tre och fyra, populera det första kompletta utkastet av registret under vecka fyra och fem, klassificera och gapanalysera varje post under vecka sex och sju, och presentera ett godkänt register med åtgärdsfärdkarta för ledningsorganet under vecka nio. Vid vecka tio är inventeringen inte längre ett projekt — den är en stående operativ tillgång med kvartalsvis granskningskadens och en utsedd ägare för varje post. Det är hållningen som tidsfristen 2 augusti 2026 belönar, och det är hållningen som gör resten av AI-förordningens efterlevnadsbacklog hanterbar.