Opbygning af jeres AI-inventar inden 2. august 2026: praktisk vejledning til SMV'er i EU

Kort fortalt

De fleste materielle forpligtelser i AI-forordningen får virkning fra 2. august 2026 — højrisiko-pligterne i Bilag III iht. artikel 8-22, idriftsætterpligterne i artikel 26, gennemsigtighedsforpligtelserne i artikel 50 og registrering i EU-databasen iht. artikel 49. Ingen af disse pligter kan opfyldes uden et fuldstændigt, opdateret og ejer-tildelt inventar over hvert eneste AI-system, der falder ind under jeres ansvar. Forbuddene i artikel 5 har været håndhævelige siden 2. februar 2025, og GPAI-forpligtelserne siden 2. august 2025 (art. 113), så et inventar, der bygges i dag, skal allerede dække screening for forbudte praksisser, registrering af GPAI-flow-down for idriftsættere og det almindelige risikoniveau-arbejde. Den gode nyhed for ressourceknappe SMV'er: I fører næsten med sikkerhed allerede tilsvarende registre — fortegnelsen iht. GDPR artikel 30, aktivregisteret iht. NIS2 og inventaret iht. ISO 27001 bilag A.5.9. AI-inventaret bygges bedst som en udvidelse af disse, ikke som et selvstændigt fjerde register. Denne vejledning giver jer skemaet, genbrugslandkortet, tre konkrete SMV-eksempler, de huller der typisk fanger organisationer, og en 60-dages plan, så I står klar inden fristen.

Hvorfor et AI-inventar er nødvendigt inden 2. august 2026

AI-forordningen pålægger ikke én navngivet "inventar"-pligt. Den pålægger derimod et dusin pligter, som en compliance-ansvarlig kun kan opfylde, hvis vedkommende ved, hvilke AI-systemer der findes i organisationen, hvad de bruges til, hvem der ejer dem, og hvilket risikoniveau hvert enkelt har. Artikel 9-risikostyring forudsætter en liste af systemer, som analysen kan køres mod. Artikel 11-tekniske dokumentation forudsætter, at de relevante systemer er identificeret. Idriftsætterpligterne i artikel 26 — menneskeligt tilsyn, overvågning, logning, oplysning af berørte arbejdstagere — gælder pr. system, og de kan ikke opfyldes pr. system uden et register pr. system. Registrering i EU-databasen iht. artikel 49 er i sig selv en system-niveau-indberetning. Uden inventaret kan resten hverken planlægges, prioriteres eller dokumenteres.

Bøderne er konstrueret, så hullet bliver dyrt. Artikel 99 fastsætter administrative bøder på 35 mio. EUR eller 7 % af global årlig omsætning for overtrædelse af forbuddene (art. 99, stk. 3), 15 mio. EUR eller 3 % for manglende overholdelse af højrisiko-forpligtelser (art. 99, stk. 4), og 7,5 mio. EUR eller 1 % for forkerte, ufuldstændige eller vildledende oplysninger til notificerede organer og kompetente myndigheder (art. 99, stk. 5). SMV'er har en delvis lempelse efter artikel 99, stk. 6 — bøden kan fastsættes til det laveste af det absolutte beløb og procentsatsen frem for det højeste — men lempelsen fjerner ikke loftet, og den hjælper slet ikke i den mest skadelige fejltype: at man under et tilsyn opdager, at man ikke ved, hvilken AI man kører. Et ufuldstændigt inventar er den umiddelbare forudsætning for den tredje bødetype, fordi ethvert svar, I afgiver til myndigheden, så nødvendigvis bliver et skøn.

Der er også en markedsadgangs-dimension. Artikel 79 giver markedsovervågningsmyndigheden hjemmel til at kræve afhjælpende foranstaltninger over for ikke-overensstemmende højrisiko-systemer, herunder tilbagetrækning fra EU-markedet. For en B2B-SaaS-leverandør, hvis enterprise-kontrakter indeholder garantier om regelefterlevelse — og hvis kunder fra anden halvdel af 2025 vil begynde at kræve AI-forordningens godkendelse i deres indkøbsproces — er det at stå uden et system-niveau-inventar på forespørgsel en kommerciel risiko længe før det bliver en regulatorisk. De kunder, der spørger først, bliver de tyske, franske og hollandske virksomheder, der allerede driver modne GDPR-due diligence-processer over for leverandører. De accepterer ikke "vi er stadig i gang med at kortlægge" som svar i slutningen af 2026.

Hvad et "AI-system" omfatter efter art. 3, stk. 1

Artikel 3, stk. 1 definerer et AI-system som et maskinbaseret system, der er designet til at fungere med varierende grader af autonomi, og som efter idriftsættelse kan udvise tilpasningsevne, og som — med eksplicitte eller implicitte mål — på baggrund af det input, det modtager, udleder, hvordan det skal generere output såsom forudsigelser, indhold, anbefalinger eller beslutninger, der kan påvirke fysiske eller virtuelle miljøer. Definitionen er bevidst tilpasset OECD's reviderede definition fra 2023 og er bevidst bred. Enhver organisation, der har læst den grundigt, har samme første reaktion: dette er bredere, end vi havde antaget.

Tre konsekvenser følger for inventarets rækkevidde. For det første: "machine learning" er ikke en forudsætning. Et regelbaseret ekspertsystem, der udleder output fra input på grundlag af en videnbase, falder ind under definitionen, selv om de fleste ingeniører ikke ville kalde det AI. Betragtning 12 undtager visse klassiske statistiske og optimeringsmæssige teknikker, hvor der ikke er noget inferentielt element, men undtagelsen er snæver og omstridt i kanten. Når I er i tvivl, skal systemet med i inventaret, og I dokumenterer årsagen til, at det ikke kræver en risikoniveau-klassifikation.

For det andet: "varierende grader af autonomi" betyder, at grænsen mellem AI og almindelig software ikke følger linjen "menneske i sløjfen". Et system med obligatorisk menneskelig godkendelse af hvert output er stadig et AI-system, hvis det udleder disse output. Artikel 14-menneskeligt tilsyn er da en designegenskab i et AI-system, ikke en udvej fra forordningen. Værktøjer til CV-screening, der præsenterer en rangordnet shortlist for en rekrutterer, er AI-systemer, selv om rekrutteren formelt træffer ansættelsesbeslutningen.

For det tredje: "output, der kan påvirke fysiske eller virtuelle miljøer" trækker en lang række driftsmæssige softwarekomponenter ind, som organisationer sjældent kategoriserer som AI: dynamiske prismotorer, bedrageri-scoringsmodeller, churn-prædiktorer, klassifikatorer til indholdsmoderation, anbefalingssystemer, automatiseret e-mailrouting, efterspørgselsprognoser, prædiktivt vedligehold. De fleste af disse vil ende i kategorien minimal risiko ved en grundig analyse, men de hører alligevel hjemme i inventaret. Pointen med registeret er at dokumentere, at klassifikationen er udført — ikke kun at liste de systemer, der endte med at være højrisiko.

Sådan kobles inventaret til AI-forordningens risikoniveauer

Hver post i inventaret bærer en risikoniveau-mærkat, og mærkaten styrer alt det øvrige arbejde med posten. De fem kategorier — uacceptabel risiko, høj risiko, begrænset risiko, minimal risiko og det parallelle GPAI-overlay — sidder ovenpå det samme register, og ét enkelt produkt kan give anledning til flere inventarposter, når det indeholder flere distinkte AI-anvendelsestilfælde. Behandl posterne som compliance-arbejdsenheder, ikke som et leverandørkatalog.

Systemer med uacceptabel risiko iht. artikel 5 — otte forbudte familier, der dækker manipulative teknikker, udnyttelse af sårbarheder, social scoring, profileringsbaseret prædiktiv politiarbejde, ikke-målrettet skraping af ansigtsbilleder, følelsesgenkendelse på arbejdspladser og uddannelsesinstitutioner, biometrisk kategorisering efter særlige attributter samt realtids-fjernbiometrisk identifikation i offentlige rum til retshåndhævelse — bør aldrig fremgå som en aktiv inventarpost. Hvis et eksisterende system eller et planlagt indkøb falder ind under et af forbuddene, eksisterer inventarposten kun for at dokumentere beslutningen om at indstille brugen. Forbuddene har været håndhævelige siden 2. februar 2025, så det er ikke længere en fremtidig forpligtelse.

Højrisiko-poster — Bilag III-kategorierne plus sikkerhedskomponenter i Bilag I-produkter iht. artikel 6, stk. 1 — bærer det tungeste feltsæt. Pligtsættet på 13 punkter fra artikel 9 til artikel 49 skaber dokumentationskrav, som en tynd inventarpost ikke kan bære. For højrisiko-poster behandles inventaret bedst som et indeks, der peger på et selvstændigt teknisk dossier iht. artikel 11 og Bilag IV, hvor selve inventarposten kun rummer den metadata, en revisor skal bruge for at finde dossieret. De materielle forpligtelser gælder fra 2. august 2026 for Bilag III-højrisiko-systemer og fra 2. august 2027 for produktsikkerhedssporet i Bilag I iht. art. 6, stk. 1.

Et andet filter virker inden for Bilag III. Artikel 6, stk. 3 giver en undtagelse for Bilag III-systemer, der ikke udgør en betydelig risiko for skade, fordi de udfører en snæver proceduremæssig opgave, forbedrer resultatet af en tidligere afsluttet menneskelig aktivitet, opdager beslutningsmønstre eller afvigelser uden at erstatte menneskelig vurdering eller udfører en forberedende opgave til en Bilag III-vurdering. Profilering af fysiske personer udelukker undtagelsen i alle tilfælde. Hver Bilag III-inventarpost skal have en skriftlig art. 6, stk. 3-analyse: enten en positiv konstatering (med angivelse af den specifikke punktbestemmelse, der lægges til grund) og begrundelsen, eller en negativ konstatering, der bekræfter, at systemet bliver i højrisiko-kategorien.

Begrænset risiko-poster — chatbots, deepfake-værktøjer, AI-genereret tekst eller medier, følelsesgenkendelse hvor det ikke er forbudt — bærer gennemsigtighedsforpligtelserne i artikel 50. Inventaret skal pr. system dokumentere, hvordan oplysningen sker: placering af chatbanner, vandmærkning af syntetisk output, redaktionel kontrolloggen for AI-genereret tekst om emner af offentlig interesse, idriftsætter-siden af deepfake-oplysningen. Begrænset risiko-forpligtelser gælder også fra 2. august 2026, og — modsat højrisiko-sporet — er der ingen undtagelsesvej, der løfter pligten: hver chatbot skal have en oplysning, og inventaret skal kunne dokumentere det.

Minimal risiko-poster udgør størstedelen af registeret. Der er ingen obligatoriske forpligtelser efter AI-forordningen for disse systemer, men inventaret skal stadig dokumentere den negative konstatering — det skriftlige ræsonnement om, at systemet ikke falder ind under Bilag III, ikke interagerer direkte med fysiske personer og ikke genererer syntetiske medier. AI-læsefærdighedspligten i artikel 4 gælder uanset risikoniveau, så inventaret bør registrere, hvilken medarbejdergruppe der betjener hvert minimal risiko-system, og bekræfte, at de er omfattet af AI-læsefærdighedsprogrammet.

GPAI er et overlay, ikke et risikoniveau. Næsten enhver SMV-inventarpost, der bygger på en grundmodel — GPT-4o, Claude, Gemini, Mistral Large, Llama, Command — er en idriftsætterpost iht. artikel 53, stk. 1, litra b med arvet flow-down-information fra opstrøms-udbyderen. Inventaret skal have et dedikeret felt til den opstrøms model-identitet og -version, udbyderen, henvisning til den offentliggjorte træningsdata-resumé samt datoen for, hvornår det seneste sæt brugeranvisninger fra udbyderen blev gennemgået. Der er to adskilte regler at holde fra hinanden. Artikel 25 overdrager højrisiko-udbyderpligterne til en nedstrøms aktør i tre tilfælde — når aktøren markedsfører et højrisiko AI-system under eget navn eller varemærke, når aktøren foretager en væsentlig modifikation af et højrisiko-system, der allerede er på markedet, eller når aktøren ændrer det tilsigtede formål med et ikke-højrisiko-system (herunder en GPAI), så det bliver højrisiko iht. artikel 6. Betragtning 109 tager fat på et andet tilfælde: en organisation, der finjusterer eller på anden måde modificerer en GPAI uden at gøre den til et højrisiko-system. Dér er pligterne på den nedstrøms aktør begrænset til selve modifikationen — typisk et supplement til opstrøms-udbyderens tekniske dokumentation med oplysninger om ændringerne, herunder eventuelle nye træningsdatakilder. De fleste SMV'er krydser ingen af tærsklerne, men inventaret er det eneste sted, hvor grænsen er dokumenteret pr. system.

Obligatoriske felter i inventaret

Et forsvarligt AI-inventar har omtrent femten felter pr. post. Modstå fristelsen til at lægge flere på — hvert ekstra felt er en vedligeholdelsesbyrde, og det bæredygtige register er det, som medarbejderne faktisk opdaterer, når systemerne ændrer sig. Listen nedenfor er det minimumssæt, der bærer de forpligtelser, som gælder fra 2. august 2026.

• Systemnavn og unikt identifikator — en stabil mærkat, der bruges konsistent på tværs af det tekniske dossier, EU-database-registreringen, leverandørkontrakter og interne ændringssager.
• Ansvarlig — én navngivet person i organisationen, der er ansvarlig for at holde posten ajour og for at udløse en omklassifikation, når systemet ændres væsentligt. Et team eller en afdeling er ikke en ansvarlig.
• Intern eller ekstern udbyder — om systemet er bygget internt, indkøbt som SaaS eller indlejret i et større produkt. Det afgør, om I er udbyder, idriftsætter eller begge dele iht. artikel 25 og 26.
• Risikoniveau efter AI-forordningen — uacceptabel, høj risiko (artikel 6, stk. 1, eller artikel 6, stk. 2 / Bilag III med specifik Bilag III-punktbestemmelse), begrænset risiko (med specifikt artikel 50-stykke), minimal risiko, plus GPAI-overlay-flag, hvor det er relevant.
• Klassifikationsbegrundelse — kort skriftlig begrundelse, herunder enhver henvisning til art. 6, stk. 3-undtagelsen. Vage begrundelser overlever ikke en revision; "dokumenteret fordi begrundet" er målestokken.
• Underliggende model — for GPAI-idriftsætterposter: model-identitet, version, udbyder samt datoen for, hvornår opstrøms-udbyderens brugeranvisninger iht. artikel 53, stk. 1, litra b sidst blev gennemgået.
• Tilsigtet formål — den specifikke anvendelse som beskrevet over for idriftsættere, formuleret som i brugeranvisningerne iht. artikel 13. Afvigelse mellem tilsigtet formål og faktisk anvendelse er en af de hyppigste revisionskonstateringer.
• GDPR-retsgrundlag — for ethvert system, der behandler personoplysninger: GDPR-retsgrundlaget iht. artikel 6 (og artikel 9-betingelse, hvor særlige kategorier af oplysninger indgår). Krydshenvis til den tilsvarende post i fortegnelsen iht. GDPR artikel 30.
• Træningsdatas oprindelse — provenans-resumé med kilde, licensbetingelser, overholdelse af copyright-fravalg og enhver dataminimering eller pseudonymisering. For GPAI-idriftsætterposter kan feltet pege på opstrøms-udbyderens offentliggjorte træningsdata-resumé.
• Outputtype — forudsigelse, anbefaling, klassifikation, indholdsgenerering, beslutning. Outputtypen styrer artikel 50-gennemsigtighedsforpligtelserne og GDPR artikel 22-analysen.
• Indvirkning på beslutninger — om output påvirker afgørelser om identificerbare fysiske personer med konsekvenser, og i bekræftende fald hvilken berørt population (medarbejdere, ansøgere, kunder, patienter, modtagere af ydelser). Det er feltet, der signalerer, hvornår en særskilt DPIA iht. GDPR artikel 35 eller en grundrettighedseffektvurdering iht. AI-forordningens artikel 27 er nødvendig.
• Design af menneskeligt tilsyn — de artikel 14-foranstaltninger, der faktisk er implementeret: gennemgang før idriftsættelse, validering af output, mulighed for at tilsidesætte, interventionsgrænser, eskalationsveje. Generiske formuleringer á la "et menneske gennemgår output" består ikke revisionsstandarden.
• Status for overensstemmelsesvurdering — for højrisiko-poster: den valgte rute (intern kontrol iht. Bilag VI, tredjepartsvurdering iht. Bilag VII for biometri, integreret vurdering for Bilag I-produkter), datoen for seneste vurdering og referencen til EU-overensstemmelseserklæringen iht. artikel 47.
• EU-database-registrering — for højrisiko-poster, der falder under artikel 49: registrerings-ID og dato for seneste opdatering.
• Seneste gennemgang og næste udløser — kalenderdatoen for den seneste klassifikationsgennemgang og de ændringshændelser, der vil tvinge en fornyet gennemgang (modeludskiftning, ændring af træningsdata, udvidelse af tilsigtet formål, integration i en ny forretningsproces).

Genbrug af det, I allerede har

Det billigste AI-inventar er det, der udvides fra eksisterende registre frem for at bygges fra bunden. Tre allerede eksisterende artefakter dækker det meste af felterne ovenfor og det meste af den styringsdisciplin, der skal til for at holde dem ajour.

Fortegnelsen over behandlingsaktiviteter iht. GDPR artikel 30 dækker personoplysnings-rygraden i ethvert AI-system, der behandler oplysninger om identificerbare fysiske personer. Fortegnelsen indeholder allerede retsgrundlaget, kategorierne af oplysninger, kategorierne af registrerede, modtagerne, internationale overførsler og opbevaringsperioden — alt sammen oplysninger, AI-inventaret enten skal kopiere eller henvise til. Den pragmatiske løsning er at tilføje en "AI-system-reference"-kolonne til den eksisterende fortegnelse, og — på AI-inventarsiden — at henvise til den tilsvarende post i fortegnelsen frem for at duplikere personoplysningsfelterne. DPIA'er iht. GDPR artikel 35 og grundrettighedseffektvurderinger iht. AI-forordningens artikel 27 — som gælder idriftsættere der er offentlige organer eller private enheder, der leverer offentlige tjenester, og separat for enhver idriftsætter (offentlig som privat) af et Bilag III §5(b)-kreditværdighedssystem eller et §5(c)-livs- eller sundhedsforsikrings-risikovurderings- eller -prissætningssystem — bør begge linkes til fra inventarposten frem for at blive kopieret ind i den.

NIS2-aktivregistre, hvor de findes, dækker den driftsmæssige og informationssikkerhedsmæssige rygrad. Medlemsstaternes nationale gennemførelseslove for NIS2 — gennemførelsesfristen var 17. oktober 2024, og Europa-Kommissionen indledte i november 2024 traktatbrudsprocedurer mod 23 medlemsstater, der havde forpasset fristen; gennemførelsen er fortsat i bølger gennem 2025 og 2026 — pålægger væsentlige og vigtige enheder at føre et register over IKT-aktiver og -afhængigheder. For SMV'er, der falder ind under NIS2, indeholder registeret typisk allerede de cloud-platforme, SaaS-afhængigheder og kritiske softwaresystemer, som AI-arbejdsbelastninger kører på. At tagge AI-systemer i NIS2-registeret og krydshenvise til AI-inventaret bringer de to regler på linje og undgår den situation, hvor en organisations NIS2-inventar viser en tredjeparts-SaaS uden at signalere, at SaaS'en indlejrer en AI-anvendelse, der falder ind under AI-forordningen.

ISO/IEC 27001:2022 bilag A.5.9 (tidligere A.8.1.1 i 2013-versionen) kræver et inventar over informationer og tilknyttede aktiver, herunder software, tjenester og selve informationen. For ISO-certificerede SMV'er er aktivinventaret efter A.5.9 den naturlige bærer af AI-registeret. Den revisionssti, ISO 27001 kræver — ansvarlig, klassifikation, ændringsspor — kortlægger sig allerede over på AI-forordningens inventarfelter ovenfor. At behandle AI-inventaret som en delmængde af ISO 27001-aktivinventaret frem for som et nyt artefakt sparer dobbelt vedligeholdelse, giver AI-registeret gavn af den eksisterende ISMS-gennemgangskadence og undgår den alt for almindelige tilstand, hvor ISMS-aktivregisteret og AI-inventaret driver fra hinanden i indbyrdes uoverensstemmende versioner.

Ud over de tre er to tilstødende registre værd at røre ved: indkøbsregistret over leverandører (der typisk fanger enhver ekstern SaaS, organisationen bruger, og ofte er den hurtigste vej til en fuldstændig skygge-AI-kortlægning) og databeskyttelsesregistret over samtykker eller kontraktlige grundlag (der allerede understøtter GDPR-siden af ethvert kunderettet AI-system). Når AI-inventaret bygges som en samling af krydshenvisninger på tværs af disse eksisterende registre frem for som et nyt regneark, falder vedligeholdelsesomkostningen med omkring halvdelen, og den sammenhæng på tværs af regelsæt, som revisorer kigger efter, opstår naturligt.

Tre SMV-eksempler

Konkrete eksempler skærper disciplinen. Tre kortfattede tilfælde nedenfor viser, hvordan inventarskemaet lander i praksis for henholdsvis en HR-tech-leverandør, en FinTech og en MedTech-SMV — typer, der hver især er karakteristiske for de unge europæiske virksomheder, der i dag er mest eksponerede over for fristen 2. august 2026.

HR-tech: en SaaS-leverandør med 50 medarbejdere i München

Produktet er et ATS-system med to AI-drevne funktioner: et CV-resumeringsmodul bygget oven på GPT-4o samt en intern kandidat-rangordningsmodel, der er trænet på kundens historiske ansættelsesdata. Inventaret indeholder to adskilte poster, ikke én. Post A — CV-resumering — er for sig selv et begrænset risiko-system (artikel 50, stk. 1-gennemsigtighed i chatbot-stil, fordi rekrutteren ser et resumé tydeligt mærket som AI-genereret) med et GPAI-idriftsætter-overlay, der peger på OpenAI som opstrøms-udbyder. Post B — kandidat-rangordning — er entydigt højrisiko iht. Bilag III, punkt 4(a) (beskæftigelse, rekruttering, kandidat-udvælgelse) med leverandøren som udbyder, fordi systemet markedsføres på EU-markedet under leverandørens eget navn. Post B bærer det fulde 13-punkts-pligtsæt fra artikel 9 til artikel 49; post A bærer kun artikel 50, stk. 1-oplysningen plus GPAI-flow-down-registreringen. Den fælles ansvarlige på tværs af begge poster er produktchefen, med en udpeget AI-forordnings-ansvarlig i juridisk afdeling som sekundær ansvarlig. Inventaret krydshenviser til ISO 27001-aktivregisteret (virksomheden er certificeret) for begge poster og til GDPR-fortegnelsen for personoplysningsfelterne. Begge poster markerer 2. august 2026 som udløseren for færdiggørelse af det tekniske dossier iht. artikel 11 og Bilag IV.

FinTech: en forbrugerkredit-startup med 30 medarbejdere i Vilnius

Produktet er en forbrugerkredit-applikation med to AI-komponenter: en kreditscoringsmodel, der er trænet på interne data plus open banking-signaler, samt en bedrageri-detektionsmodel, der er lagt oven på transaktionstelemetri. Kreditscoringsmodellen lander i Bilag III, punkt 5(b) — vurdering af fysiske personers kreditværdighed — og er højrisiko som udgangspunkt; virksomheden er udbyder, markedsfører systemet på sin egen platform og kører intern overensstemmelsesvurdering iht. Bilag VI. Bedrageri-detektionsmodellen anvender den tekstuelle undtagelse, der er skrevet direkte ind i Bilag III, § 5(b), og som fra starten udelukker "AI-systemer, der bruges til at opdage finansielt bedrageri" fra kreditværdighedskategorien — det er en anden undtagelse end art. 6, stk. 3-undtagelsen for proceduremæssige opgaver, der filtrerer Bilag III-systemer generelt, og inventarposten skal gøre klart, hvilken udvej den anvender. Fordi undtagelsen er snæver (den dækker bedrageri-detektion, ikke al transaktions-risikoscoring), holder virksomhedens juridiske team klogeligt en defensiv position ved at opretholde et delvist højrisiko-kontrolsæt på bedrageri-modellen og udløse en ny klassifikation, hver gang modellens formål udvides ud over bedrageri-detektion. Grænsetilfældet er en kundeservice-chatbot bygget på Mistral Large; den bliver til et begrænset risiko-Post C med et GPAI-idriftsætter-overlay. Krydshenvisningen til GDPR-fortegnelsen er kritisk her, fordi GDPR artikel 22 (automatiserede individuelle afgørelser) gælder for kreditscoring-posten, og inventaret skal kunne dokumentere den registreredes ret til at få menneskelig indgriben, til at give udtryk for sit synspunkt og til at anfægte afgørelsen. AI-forordningens artikel 27 bider også her — enhver idriftsætter af et Bilag III, § 5(b)-system skal gennemføre en grundrettighedseffektvurdering, uanset om idriftsætteren er offentlig eller privat. DPO'en er den udpegede ansvarlige for begge højrisiko-poster; chefen for Customer Operations ejer chatbotten.

MedTech: en remote-monitoring-startup med 20 medarbejdere i Dublin

Produktet er en applikation til fjernmonitorering af patienter med ét AI-anvendelsestilfælde: en algoritme, der markerer klinisk væsentlige ændringer i vitale parametre på grundlag af kontinuerlig wearable-telemetri. Systemet er reguleret som medicinsk udstyr efter Forordning (EU) 2017/745 (MDR) og bærer CE-mærkning under det regelsæt. AI-inventarposten er højrisiko iht. artikel 6, stk. 1 — AI'en er en sikkerhedskomponent i et produkt, der er omfattet af Bilag I EU-harmoniseringslovgivning (medicinsk udstyr), som kræver tredjepartsoverensstemmelsesvurdering. De materielle højrisiko-forpligtelser i AI-forordningen gælder for denne post fra 2. august 2027, ikke fra 2. august 2026, på grund af den udskudte tidsplan for artikel 6, stk. 1 i artikel 113. Overensstemmelsesvurderingen er integreret i den eksisterende MDR-procedure; det notificerede organ, der virker iht. MDR, dækker også det AI-specifikke vurderingsarbejde, og de AI-specifikke leverancer (artikel 11-tekniske dokumentation, artikel 9-risikostyring, artikel 13-gennemsigtighed over for sundhedsprofessionelle) lægges oven på det eksisterende tekniske dossier. Inventarposten henviser til MDR-dossieret frem for at duplikere det, QMS-ansvaret ligger hos den samme person, der allerede leder MDR-artikel 10-kvalitetsstyringssansvaret, og inventaret krydshenviser til GDPR-fortegnelsen for behandlingen af personhenførbare helbredsoplysninger iht. GDPR artikel 9, stk. 2, litra h. Den udskudte frist er fælden her: en MedTech, der ved en fejl behandler 2. august 2026 som sin udløser, kommer til at køre parallelle overensstemmelsesvurderinger tolv måneder for tidligt.

Huller, der rammer SMV'er

Tre kategorier af huller dukker gentagne gange op i SMV-inventararbejdet, og hvert af dem underminerer i stilhed inventaret, medmindre det jagtes bevidst.

Skygge-AI er det største. Marketingsafdelinger tager Jasper, ChatGPT Team eller Copy.ai i brug til indholdsproduktion. Salgsteams tilkobler Gong, Apollo eller Lavender til samtaleoptagelser og e-mail-outreach. Udviklingsteams bruger GitHub Copilot, Cursor eller Codeium uden formel indkøbsbeslutning. HR kører undersøgelser gennem ChatGPT og fører fritekstsvar gennem sentiment-klassifikatorer. Hvert af disse er et AI-anvendelsestilfælde, der falder ind under artikel 3, stk. 1 — næsten med sikkerhed begrænset eller minimal risiko isoleret set, men usynligt for det centrale inventar, medmindre nogen spørger. Modforholdsreglen er proceduremæssig: en erklæringsformular på én side, der sendes ud til hver afdelingschef med spørgsmål om enhver AI-tjeneste, deres team har anvendt de seneste seks måneder, gentaget hvert kvartal, hvor svarene krydstjekkes mod indkøbskortafregningerne og SaaS-udgiftsbogen. Den første runde af erklæringer fra en typisk SaaS-virksomhed med 50 medarbejdere afdækker mellem tolv og tyve AI-tjenester, som den centrale compliance-funktion ikke kendte til.

Indlejret AI i SaaS er det andet hul. Det er stadig oftere sådan, at det B2B-SaaS-produkt, organisationen har brugt i årevis, i 2024 og 2025 lydløst har tilføjet AI-funktioner — Salesforce Einstein, HubSpot AI, Notion AI, Slack AI, Zoom AI Companion, Microsoft 365 Copilot, Google Workspace Gemini-funktioner, Atlassian Intelligence. Værtsorganisationen er idriftsætter af hvert af disse AI-undersystemer, selv om indkøbet oprindeligt var rettet mod det underliggende produktivitetsværktøj. Inventaret skal opfange hver AI-underfunktion som en distinkt post og ikke kollapse dem til moder-SaaS'ens linje. Hver leverandør er på sin side en GPAI-idriftsætter oven på en opstrøms model-udbyder, så flow-down-kæden løber tre lag dybt: grundmodel (OpenAI/Anthropic/Google) → SaaS-leverandør (HubSpot/Microsoft/Slack) → værtsorganisation. Inventarposten skal navngive alle tre lag, hvis idriftsætterpligterne skal kunne håndhæves.

Modeludskiftninger er det tredje og mest glatte hul. En SaaS-leverandør udskifter sin underliggende GPAI-model — fx fra GPT-4 til GPT-4o eller fra Claude 3.5 til Claude 4 — uden at ændre produktets overflade, og inventarposten på idriftsættersiden bliver i stilhed urigtig. Modforholdsreglen er at indføre et "model-version låst"-felt i inventaret og kræve, at en udskiftning af opstrøms-modellen udløser en ny klassifikation. Hos modne leverandører annonceres ændringen typisk via en udgivelsesnotekanal, som indkøbsteamet bør abonnere på; for mindre modne leverandører bør inventarposten eksplicit notere, at opstrøms-modellens identitet er volatil, og gennemgangskadencen for posten skal strammes (kvartalsvist frem for årligt).

Hyppige problemer med ejertilhørsforhold

Den hyppigste grund til, at et AI-inventar driver mod ubrugelighed, er, at ejerskabet er tildelt et team eller en afdeling i stedet for en navngivet person. "Produktteamet ejer post 7" er et ikke-svar, når systemet ændres væsentligt, og ingen opdaterer posten, fordi ingen personligt skyldte opdateringen. Den disciplin, der holder ethvert andet regulatorisk register sammen — den navngivne DPO bag GDPR-fortegnelsen, den navngivne CISO bag ISO 27001-aktivregisteret, det navngivne NIS2-kontaktpunkt i medlemsstatsanmeldelsen — er den samme disciplin, AI-inventaret kræver.

Tre mønstre virker i praksis. Det første er en enkelt AI-forordnings-ansvarlig, typisk hjemhørende i juridisk eller compliance-funktionen, der ejer det centrale register og er den navngivne ansvarlige for de højeste-risiko-poster (de højrisiko-poster i Bilag III, hvor det tekniske dossier iht. artikel 11 kræver tværgående input). Det andet er en fødereret model, hvor AI-forordnings-ansvarlige ejer selve registeret og metoden, mens de enkelte produktansvarlige eller funktionsansvarlige er navngivet på hver post — egnet til SaaS-organisationer, hvor nye AI-funktioner udgives hvert kvartal, og centralt ejerskab af hver post ville skabe en flaskehals. Det tredje er en medejer-model, hvor hver højrisiko-post har en udpeget forretningsansvarlig (produktchefen eller chefen for den relevante funktion) og en udpeget kontrolansvarlig (DPO'en eller AI-forordnings-ansvarlige) — den forretningsansvarlige er ansvarlig for at holde posten ajour, mens systemet udvikler sig, og den kontrolansvarlige er ansvarlig for, at pligtsættet bliver opfyldt. Hver model er forsvarlig; det, der ikke er forsvarligt, er at lade poster stå med team-niveau-ejerskab eller manglende ejerskab.

Et andet ejertilhørsforholdsproblem er den fraværende medejer på tværgående poster. HR-tech-eksemplet ovenfor er det kanoniske tilfælde: produktansvarlig for kandidat-rangordningsfunktionen er naturligt placeret til at holde det tekniske dossier ajour, men pligten til at oplyse berørte arbejdstagere iht. artikel 26, stk. 7 sidder hos kundens egen idriftsætter-side-HR-funktion, ikke hos leverandøren. Hvis leverandørens inventarpost ikke navngiver en modpartsansvarlig inde i hver kundeorganisation, kan de kaskaderede artikel 26-idriftsætterpligter ikke dokumenteres, og leverandørens egne artikel 13-brugeranvisninger kan ikke målrettes ordentligt. Kunde-onboardingsdokumentationen og MSA-skabelonen skal begge indeholde en klausul, der pålægger kunden at navngive en AI-forordnings-idriftsætter-ansvarlig før aktivering.

Artikel 26, stk. 5 fortjener en sidste omtale, fordi det er en af de få idriftsætterpligter, der fanger selv disciplinerede inventarer på det forkerte ben. Idriftsættere af højrisiko-AI-systemer skal overvåge driften af systemet på grundlag af brugeranvisningerne og — hvor relevant — informere udbydere iht. artikel 72. Når idriftsættere har grund til at antage, at brug i overensstemmelse med brugeranvisningerne kan medføre, at systemet udgør en risiko som omhandlet i artikel 79, stk. 1, skal de uden unødig forsinkelse informere udbyderen eller distributøren og den relevante markedsovervågningsmyndighed — og suspendere brugen af systemet. I praksis betyder det, at hver højrisiko-inventarpost skal have en navngivet overvågningsansvarlig på idriftsættersiden, en dokumenteret eskalationsvej, der ender hos den relevante nationale kompetente myndighed, og en skriftlig suspensionsprotokol, der kan aktiveres uden yderligere intern godkendelse. At udpege disse for sent — efter systemet allerede er i drift — er en af de hyppigste compliance-konstateringer i de tidlige håndhævelsessager.

60-dages plan for opbygning af inventaret

Tres dage er nok til at lancere en forsvarlig første version af inventaret, hvis arbejdet er rent tidsplanlagt, ledelsen forpligter sig til kadencen fra start, og eksisterende registre genbruges frem for at duplikeres. Planen nedenfor antager en typisk SMV med 30-100 medarbejdere uden tidligere AI-styringsfunktion og én tværgående AI-forordnings-ansvarlig udpeget til arbejdet.

Dag 1 til 10 — kortlægning af scope og genbrug. AI-forordnings-ansvarlige indsamler den eksisterende GDPR-fortegnelse, ISO 27001-aktivinventaret (hvor relevant), NIS2-registeret (hvor i scope), indkøbslisten over leverandører og SaaS-udgiftsbogen. Hver post på tværs af registrene gennemgås for AI-relevans, og dem, der berører AI, markeres til inventaret. Den ansvarlige skitserer inventarskemaet — det femten-felt-sæt, der er beskrevet ovenfor, med eventuelle organisationsspecifikke tilføjelser — og sender det til godkendelse hos DPO'en, CISO'en (hvor en sådan findes) og en sponsor i ledelsen. Værktøjet besluttes i samme vindue: regneark, GRC-platform eller udvidelse af fortegnelses-værktøjet. For SMV'er uden GRC-platform er et struktureret regneark under versionsstyring med obligatoriske gennemgangsfelter tilstrækkeligt for første version.

Dag 11 til 30 — opdagelse og udfyldning. Skygge-AI-kortlægningen kører i dette vindue: en erklæringsformular på én side til hver afdelingschef, en SaaS-udgiftsafstemning og strukturerede interviews med hver funktionschef (produkt, udvikling, marketing, salg, kundesupport, HR, økonomi, drift). Hver erklæring bliver til en udkast-inventarpost. AI-forordnings-ansvarlige udfylder metadatafelterne fra eksisterende fortegnelse og aktivregistre, hvor data allerede findes, og åbner kun et nyt dataindsamlingsspor for de felter, der reelt er AI-specifikke (tilsigtet formål, outputtype, opstrøms-model, træningsdatas oprindelse, design af menneskeligt tilsyn). Ved udgangen af dag 30 skal hvert AI-anvendelsestilfælde, organisationen kender til, have en udkast-inventarpost — selv om risikoniveau-klassifikationen er foreløbig og begrundelsen stadig er skitseagtig.

Dag 31 til 50 — klassifikation og hulanalyse. AI-forordnings-ansvarlige fører hver udkast-post gennem beslutningstræet for risikoniveauer (otte spørgsmål, der dækker artikel 5, Bilag III, artikel 6, stk. 1, artikel 6, stk. 3, udbyder/idriftsætter-status, GPAI-overlay, artikel 50, stk. 1-interaktion, artikel 50, stk. 2/4 syntetisk indhold og artikel 51 systemisk risiko). Hver post tildeles et risikoniveau med en skriftlig begrundelse. For højrisiko- og begrænset risiko-poster kører den ansvarlige en hulanalyse mod det tilsvarende pligtsæt: for højrisiko, det 13-punkts-grundlag fra artikel 9 til artikel 49; for begrænset risiko, de fire artikel 50-oplysningspligter. Hvert hul bliver til en afhjælpningsopgave med en navngivet ansvarlig og en måldato tidsplanlagt mod 2. august 2026 (eller 2. august 2027 for Bilag I artikel 6, stk. 1-poster). Anvendelsesområdet for DPIA og artikel 27-grundrettighedseffektvurdering besluttes i samme vindue: enhver højrisiko-post, der behandler personoplysninger, udløser en DPIA-gennemgang, og enhver højrisiko-post, der idriftsættes af et offentligt organ, af en privat enhed der leverer offentlige tjenester, eller afenhver idriftsætter af et Bilag III §5(b)-kreditværdighedssystem eller §5(c)-livs- eller sundhedsforsikrings-prissætningssystem udløser en artikel 27-effektvurdering.

Dag 51 til 60 — godkendelse og driftskadence. Inventaret og hulanalysens backlog forelægges ledelsen til godkendelse. AI-forordningspunktet tilføjes som et stående kvartalsvist bestyrelsespunkt. Den ansvarlige for hver højrisiko-post udpeges formelt skriftligt, og overvågningsansvarlige iht. artikel 26, stk. 5 på idriftsættersiden bekræftes sammen med deres suspensionsbeføjelse. Kunde-rettede kontrakter og onboardingsdokumentation gennemgås for klausuler om artikel 13-brugeranvisninger og artikel 26-idriftsætter-flow-down. AI-læsefærdighedsprogrammet iht. artikel 4 afgrænses, og inventaret bruges til at identificere de medarbejdergrupper, der betjener eller bruger hvert system. En første intern revision af inventaret planlægges til udgangen af 1. kvartal 2027 — seks måneder efter forpligtelserne får virkning, længe nok til, at den faktiske drift har afsløret den første runde af problemer, kort nok til, at huller stadig kan afhjælpes inden første eksterne revisionscyklus. Anden-version-gennemgangen af selve inventaret planlægges til udgangen af 2. kvartal 2027.

Konklusion og næste skridt

Fristen 2. august 2026 er fast og asymmetrisk: omkostningen ved at være forsinket på inventaret er langt højere end omkostningen ved at være tidlig på den, fordi næsten alle øvrige pligter i AI-forordningen hviler på den. Arbejdet er også usædvanligt godt på linje med det, europæiske SMV'er allerede gør godt — fortegnelsen iht. GDPR artikel 30, NIS2-aktivregistre, ISO 27001-aktivinventarer — så den marginale indsats er meningsfuldt mindre, end overskriftsreguleringen antyder. Fælden er at behandle AI-inventaret som et selvstændigt artefakt frem for som en udvidelse af de registre, der allerede findes. Byg det som en samling af krydshenvisninger, navngiv én enkelt person som ansvarlig for hver post, og behandl skygge-AI, indlejret SaaS-AI og modeludskiftninger som de tre kategorier af huller, der i stilhed underminerer registeret, hvis de ikke jagtes eksplicit.

Praktisk ser de næste tres dage sådan ud for en SMV, der starter fra nul: udpeg en AI-forordnings-ansvarlig i uge ét, lås skemaet og genbrugsplanen i uge to, kør skygge-AI-kortlægningen i uge tre og fire, udfyld det første komplette udkast af registeret i uge fire og fem, klassificér og hulanalysér hver post i uge seks og syv, og forelæg et godkendt register og en afhjælpningsplan for ledelsen i uge ni. Ved uge ti er inventaret ikke længere et projekt — det er et stående driftsaktiv med en kvartalsvis gennemgangskadence og en udpeget ansvarlig for hver post. Det er den positur, fristen 2. august 2026 belønner, og det er den positur, der gør resten af AI-forordningens compliance-backlog håndterlig.