Højrisiko-AI-systemer skal opretholde en komplet teknisk fil inden markedsføring på EU-markedet. Art. 11 og Bilag IV definerer præcist, hvad der skal inkluderes — fra systemarkitektur til styring af træningsdata og planer for eftersalgsovervågning.
Hvad er den tekniske fil?
Den tekniske dokumentation — populært kaldet den "tekniske fil" — er den overordnede dokumentationspakke, der demonstrerer, at et højrisiko-AI-system opfylder alle EU AI-forordningens krav. Påbudt ved Art. 11 og struktureret ved Bilag IV, skal den udarbejdes inden systemet markedsføres på EU-markedet og holdes opdateret gennem hele systemets livscyklus.
Den tekniske fil indsendes ikke centralt. Udbyderen holder den og fremviser den på anmodning til markedsovervågningsmyndigheder og bemyndigede organer. Dette er en pull-model: myndigheder kommer til dig; du skal være klar til at aflevere en komplet, sammenhængende pakke, ikke en improviseret stak filer sammensat under pres.
Art. 11 pålægger udbydere tre pligter:
- Udarbejd den inden markedsplacering eller ibrugtagning.
- Hold den opdateret — enhver væsentlig ændring af systemet kræver opdatering af filen og genoprøvning af overensstemmelse.
- Gør den tilgængelig for kompetente myndigheder og bemyndigede organer på anmodning inden for en fastlagt tidsramme (typisk 10 arbejdsdage under nationale markedsovervågningsregler).
Standarden for "opdateret" er funktionel: den tekniske fil skal afspejle systemet som faktisk implementeret, ikke systemet som oprindeligt designet. Hvis en modelopdatering ændrer præstationskarakteristika, nøjagtighedstærskler eller træningsdata, skal filen revideres i overensstemmelse hermed.
Hvem har brug for teknisk dokumentation?
Teknisk dokumentation under Art. 11 og Bilag IV er obligatorisk for udbydere af:
- Højrisiko-AI-systemer oplistet i Bilag III — selvstændige systemer inden for områder som biometrisk kategorisering, rekruttering, kreditvurdering, forvaltning af kritisk infrastruktur, uddannelse, retshåndhævelse, migration og grænsekontrol og retsplejeadministration (underlagt Art. 6(3)'s filter for væsentlig risiko)
- AI-systemer der fungerer som sikkerhedskomponenter i Bilag I-regulerede produkter — AI integreret i medicinsk udstyr, maskiner, køretøjer, luftfartsudstyr og lignende produkter reguleret af eksisterende EU-produktsikkerhedslovgivning
Teknisk dokumentation er ikke krævet for:
- Minimal-risiko-AI-systemer (chatbots, spamfiltre, anbefalingsmotorer uden for højrisikokategorier)
- AI-systemer kun underlagt gennemsigtighedsforpligtelser under Art. 50 (f.eks. deepfake-oplysninger, følelsesregistreringsoplysninger, hvor de ikke er højrisiko)
- AI-modeller til generelle formål (GPAI) model-udbydere — de har separate dokumentationsforpligtelser under Art. 53, herunder teknisk dokumentation for selve modellen, men ikke Bilag IV-formatet designet til implementerede højrisikosystemer
Hvis du er en deployer (ikke en udbyder), er du ikke forpligtet til at udarbejde den tekniske fil. Dog skal deployere opretholde logs af systembrug (Art. 26(5)), og udbydere er berettiget til at trække på disse logs, når de opdaterer teknisk dokumentation eller håndterer hændelsesrapporter.
De 14 elementer i Bilag IV
Bilag IV specificerer det minimale indhold af den tekniske fil. Der er intet stift format — udbydere kan organisere dokumentationen, som de finder passende — men alle 14 elementer skal være til stede og substantielle. Afkrydsningsfelter uden understøttende dokumentation opfylder ikke Bilag IV.
| # | Bilag IV-element | Hvad det skal indeholde |
|---|---|---|
| 1 | Generel beskrivelse | Systemnavn, versionsidentifikator, tilsigtet formål, tilsigtede brugere, geografiske markeder, udbydernavn og -adresse, eventuel autoriseret repræsentant |
| 2 | Systemkomponenter | Hardwarekrav, softwarekomponenter, tredjeparts modeller eller biblioteker brugt, oversigt over træningsmætodik, algoritmisk tilgang (f.eks. overvåget læring, forstærkningslæring, transformer-arkitektur) |
| 3 | Designspecifikationer | Systemarkitektur, dataflowdiagrammer, centrale designbeslutninger og deres begrundelse, afvejninger foretaget (f.eks. nøjagtighed vs. forklarbarhed), outputformat og hvordan output indgår i downstream-beslutninger |
| 4 | Trænings-, validerings- og testdata | Datasæt brugt i hver fase, datakilder, dataforvaltningsprocedurer, statistiske egenskaber ved datasæt (størrelse, fordeling, dækning), databehandlings- og forbehandlingsprotokoller, foranstaltninger til at opdage og adressere datasæt-skævheder |
| 5 | Risikostyringsdokumentation | Det komplette Art. 9 risikostyringssystem: identificerede risici for sundhed, sikkerhed og grundlæggende rettigheder; risikoestimering og -evaluering; risikoafbødende foranstaltninger vedtaget; accepterede restrisici; grundlag for at acceptere restrisici |
| 6 | Livscyklusændringer | Beskrivelse af alle væsentlige modifikationer foretaget efter initial implementering, deres natur og omfang, hvordan overensstemmelse blev genoprøvet efter hver ændring, versionshistorik med datoer |
| 7 | Menneskelige tilsynsforanstaltninger | Hvordan Art. 14-kravene implementeres: override- og stop-mekanismer, grænseflader der sætter menneskelige operatører i stand til at overvåge output, uddannelses- eller kvalifikationskrav til operatører, dokumenterede procedurer for menneskelig indgriben |
| 8 | Validerings- og testprocedurer | Præstationsmetrikker brugt (nøjagtighed, præcision, recall, F1, AUC, retfærdighedsmetrikker), testdatasætbeskrivelser, testbetingelser og -miljø, metodik for skævheds-test og -resultater, robusthed og stresstest, out-of-distribution-præstation |
| 9 | Cybersikkerhedsforanstaltninger | Tekniske foranstaltninger mod modelstyveri, dataforgiftning, adversarielle angreb, prompt injection (for LLM-baserede systemer), adgangskontroller, kryptering under overførsel og i hvile, procedurer for sårbarhedsstyring |
| 10 | Overvågning af skævhed og nøjagtighed | Løbende overvågningsprocedurer efter implementering, nøjagtighedstærskler under hvilke systemet udløser en gennemgang, præstationsbenchmarks opdelt på demografiske grupper, hvor det er relevant, procedurer for at handle på detekteret drift eller skævhed |
| 11 | Brugsanvisninger | Det Art. 13 deployer-rettede dokument: tilsigtet formål og anvendelsestilfælde, præstationskarakteristika og begrænsninger, kendte begrænsninger, vedligeholdelses- og opdateringskrav, logforpligtelser for deployere, kontaktpunkt for rapportering af hændelser |
| 12 | Plan for eftersalgsovervågning | Design af Art. 72 overvågningssystem: data indsamlet fra deployere, hyppighed af overvågningscyklusser, tærskler der udløser gennemgang eller opdatering, procedure for rapportering af alvorlige hændelser (Art. 73), procedure for at tilbageføre overvågningsdata til risikostyring |
| 13 | Beskrivelse af grænseflader | API'er og integrationspunkter, inputdataformater og -begrænsninger, outputformater og deres semantik, integration med andre systemer eller komponenter, versionskompatibilitet |
| 14 | Harmoniserede standarder og fælles specifikationer | Liste over harmoniserede standarder anvendt (f.eks. ISO/IEC 42001:2023, EN-standarder under AI-forordningens standardiseringsprogram), fælles specifikationer vedtaget under Art. 41, i hvilken grad hver standard er anvendt, eventuelle afvigelser og deres begrundelse |
Praktisk note om element 4 (træningsdata): Bilag IV kræver ikke, at du offentliggør datasæt eller leverer dem til myndigheder som standard. Det kræver, at dokumentationen eksisterer og kan fremvises. For proprietære datasæt vil en beskrivelse af dataforvaltningsprocedurer, statistiske resuméer og resultater af skævheds-test typisk opfylde kravet uden at afsløre kommercielt følsomme data.
Praktisk note om element 14 (standarder): Fra midten af 2026 er AI-forordningens standardiseringsprogram stadig under udarbejdelse. ISO/IEC 42001 (AI-styringssystemer) er tilgængeligt og bredt refereret. Udbydere bør overvåge det europæiske standardiseringsarbejde under CEN/CENELEC JTC 21 og opdatere dette afsnit, efterhånden som harmoniserede standarder offentliggøres i EU-Tidende.
EU-overensstemmelseserklæring (Art. 47)
EU-overensstemmelseserklæringen (EU DoC) er et separat obligatorisk dokument — det er ikke del af den tekniske fil, men det refererer til den. EU DoC er udbyderens formelle erklæring om, at AI-systemet overholder alle gældende EU AI-forordningskrav.
En gyldig EU DoC skal indeholde:
- Udbyderens navn og adresse (og autoriseret repræsentant, hvis relevant)
- AI-systemets navn, version, serie- eller batchnummer, hvis relevant
- En erklæring om, at systemet overholder EU AI-forordningen
- Den anvendte overensstemmelsesvurderingsprocedure: Bilag VI (intern kontrol / selvvurdering) for de fleste Bilag III-systemer eller Bilag VII (tredjeparts vurdering af et bemyndiget organ) for biometrisk kategorisering-AI og AI brugt i kritisk infrastruktur, der kræver tredjeparts involvering
- En liste over de harmoniserede standarder eller fælles specifikationer, der er anvendt
- Udbyderens autoriserede repræsentants underskrift med dato og sted
EU DoC skal opbevares i 10 år efter markedsplacering og fremvises på anmodning. Den ledsager CE-mærkningen (se nedenfor).
For AI-systemer integreret i Bilag I-produkter kan EU DoC fusioneres med overensstemmelseserklæringen, der kræves under den relevante sektorlovgivning, forudsat den indeholder alle elementer krævet af begge retsinstrumenter.
CE-mærkning (Art. 48)
Højrisiko-AI-systemer, der markedsføres på EU-markedet, skal bære CE-mærkning, som signalerer overensstemmelse med EU AI-forordningen og enhver anden gældende EU-harmoniseret lovgivning, der dækker det samme produkt.
Undtagelser: AI-systemer i Bilag III-kategorier implementeret af offentlige myndigheder til egen intern brug er fritaget for CE-mærkningskravene. De forbliver underlagt alle andre forpligtelser — teknisk dokumentation, risikostyring, menneskelig tilsyn, registrering — men behøver ikke anbringe CE-mærkning.
CE-mærkning skal anbringes inden systemet markedsføres på EU-markedet. Den skal være synlig, læselig og uudslettelig. Hvor systemets fysiske natur ikke tillader direkte anbringelse af mærket, kan det fremgå af emballagen eller i brugsanvisningerne.
Når et højrisiko-AI-system er en komponent i et Bilag I-produkt, der allerede kræver CE-mærkning under sektorspecifik lovgivning (f.eks. medicinsk udstyr, maskiner), dækker CE-mærkningen overensstemmelse med både sektorlovgivningen og AI-forordningen. Udbydere bør tydeligt dokumentere, hvilke overensstemmelsesvurderingsprocedurer der understøtter CE-mærkningen.
Praktisk tjekliste: Minimalt levedygtig teknisk fil
Inden ethvert højrisiko-AI-system markedsføres på EU-markedet, verificér, at disse 10 punkter er komplette og dokumenterede:
- [ ] Systembeskrivelse og versionskontrol — navn, version, tilsigtet formål dokumenteret; en ændringslog eksisterer
- [ ] Arkitekturdiagram — dataflow- og komponentdiagram der viser al hardware, software og tredjeparts elementer
- [ ] Træningsdatainventar og governance-optegnelse — datasæt katalogiseret med kilde, størrelse, splits og datakvalitetsprocedurer dokumenteret
- [ ] Risikovurdering (i henhold til Art. 9) — identificerede risici, afbødende foranstaltninger og accepterede restrisici dokumenteret og godkendt
- [ ] Resultater af skævheds-test — testmetodik dokumenteret; resultater opdelt på relevante demografiske grupper, hvor det er relevant
- [ ] Nøjagtighedsmetrikker på et repræsentativt testsæt — præstationsmetrikker dokumenteret med testbetingelser; tærskler defineret
- [ ] Dokument for menneskelig tilsynsprocedure — override-mekanismer beskrevet; operatørkrav (uddannelse, kvalifikation) dokumenteret
- [ ] Cybersikkerhedsvurdering — kendte angrebsvektorer vurderet; tekniske modforanstaltninger dokumenteret
- [ ] Brugsanvisninger (deployer-rettede) — Art. 13 dokument komplet, inkl. begrænsninger, logforpligtelser og hændelsesrapporteringskontakt
- [ ] Plan for eftersalgsovervågning — dataindsamlingsomfang, overvågningshyppighed, gennemgangstærskler og hændelsesrapporteringsprocedure dokumenteret
Denne tjekliste dækker minimum. En velforberedt teknisk fil vil gå videre — særligt med hensyn til metodik for skævheds-test, modelkort for komponentmodeller og dokumentation for, at risikostyringsprocessen er iterativ snarere end en engangsøvelse.
Hvordan dette forbindes til EU AI-forordnings akademiet
EU AI-forordnings akademiets Pro-niveau inkluderer brugsklare skabeloner til teknisk dokumentation, der dækker alle 14 Bilag IV-elementer, inkl.:
- En struktureret XLSX-arbejdsbog med én fane pr. Bilag IV-element, forhåndsudfyldt med prompts og eksempelposter
- Et DOCX teknisk fil-skelet klar til redigering
- Et risikovurderingsregneark der følger Art. 9's iterative proces
- En skabelon til dataforvaltningsoptegnelse der dækker trænings-, validerings- og testdatasæt
- En skabelon til plan for eftersalgsovervågning tilpasset Art. 72
Disse skabeloner er designet til at tilpasses dit specifikke system — de er udgangspunkter med substantielt indhold, ikke blanke formularer.
Relaterede sider:
- Bilag III — Højrisiko-AI-kategorier og forpligtelser
- Overensstemmelsesvurderingsprocedurer (Bilag VI og VII)
- EU AI-forordnings akademi — skabeloner og træning
- Værktøjer — Overensstemmelsesvurderingsvelger
Official AI Act Compliance Deadline Calendar
Updated · Sources: Regulation (EU) 2024/1689 and the 2026 Digital Omnibus on AI.
| Obligation | Applies to | Original date | New date | Status | Countdown | Legal basis |
|---|---|---|---|---|---|---|
| Prohibited Practices (Art. 5) | All providers and deployers | active | — | AI Act Art. 5 | ||
| GPAI Rules (Chapter 5) | GPAI model providers | active | — | AI Act Art. 51-56 | ||
| High-risk AI — Annex III (standalone) | Providers of standalone Annex III systems | deferred | — | AI Omnibus 2026 Art. 6(2) | ||
| High-risk AI — Annex I (embedded) | AI embedded in Annex I regulated products | deferred | — | AI Omnibus 2026 Art. 6(1) | ||
| AI-Generated Content Marking | Providers of generative GPAI systems | active | — | AI Act Art. 50(2) | ||
| Regulatory Sandboxes | National competent authorities | active | — | AI Act Art. 57 |
⬇ Download JSON · CC BY 4.0
AI Act meets DORA and NIS2
Is your organisation subject to both the AI Act and DORA? The two regulations intersect on the operational resilience of financial AI systems. Our sister site regulation-dora.eu covers DORA in depth.
Explore regulation-dora.eu ↗Frequently Asked Questions
Udbyderen af højrisiko-AI-systemet er alene ansvarlig for at udarbejde og opretholde den tekniske dokumentation. Deployere er ikke forpligtet til at udarbejde den, men skal opbevare adgangslogfiler og kan have brug for at levere dem til udbydere til rapporteringsformål.
Teknisk dokumentation skal opbevares i 10 år, efter at AI-systemet er markedsført på EU-markedet eller taget i brug (Art. 18). For AI-systemer integreret i produkter underlagt Bilag I-lovgivning gælder produktlovgivningens opbevaringsperiode, hvis den er længere.
Nej — teknisk dokumentation indsendes ikke centralt. Den skal opbevares af udbyderen og gøres tilgængelig for markedsovervågningsmyndigheder og bemyndigede organer på anmodning. Registrering i EU's AI-database (Art. 71) er obligatorisk, men den fulde tekniske fil forbliver hos udbyderen.
Et formelt dokument underskrevet af udbyderen, der angiver, at AI-systemet overholder EU AI-forordningens krav. Det skal inkludere systemnavn, version, udbyderidentitet, en liste over gældende opfyldte krav, den anvendte overensstemmelsesvurderingsprocedure og en reference til relevante harmoniserede standarder. Det ledsager CE-mærkningen.
Stay ahead of AI Act changes
Get compliance alerts when deadlines or obligations change.
No spam. One-click unsubscribe.