EU AI Act (Forordning EU 2024/1689) trådte i kraft 1. august 2024. For ML-ingeniører, platform-teams og DevOps-arkitekter er forordningens krav ikke kun et juridisk spørgsmål — de ændrer direkte, hvordan I bygger, tester, deployer og overvåger AI-systemer i produktion. Denne artikel gennemgår, hvad EU AI Act konkret betyder for jeres MLOps-pipeline, container-strategi og cloud-arkitektur.
1. EU AI Act set fra et MLOps-perspektiv: hvad ændrer sig i jeres pipeline?
EU AI Act regulerer ikke cloud-infrastruktur som sådan. AWS, Azure og GCP er neutrale bærere. Det der reguleres, er AI-systemer — og definitionen er bred: ethvert maskinlæringsbaseret system, der genererer output (forudsigelser, beslutninger, anbefalinger, klassifikationer) til et bestemt formål (Art. 3(1), EU 2024/1689).
Konsekvensen for MLOps-teams er, at compliance ikke starter i juridisk afdeling — den starter i jeres model registry, CI/CD-pipeline og deployment-konfiguration.
Tre centrale skift for ingeniørteams:
Fra "ship it" til "documented and auditable": Høj-risiko AI-systemer (Art. 6, Art. 9-15) kræver dokumenteret risikoledelse, datagovernance og løbende overvågning. Det er tekniske krav, ikke kun papirkrav.
Fra ad-hoc versioning til systematisk model governance: Art. 9 og Art. 11 stiller krav til, at ændringer i AI-systemer er sporbare. En model-opdatering i produktionsmiljø er ikke bare en deployment — det kan udløse krav om ny overensstemmelsesvurdering.
Fra intern logging til eksternaliserbar audit trail: Art. 12 kræver, at høj-risiko AI-systemer automatisk logger hændelser på et niveau, der gør det muligt for tilsynsmyndigheder at rekonstruere systemets adfærd. Det er et infrastruktur-krav, ikke bare et applikationskrav.
2. Risikoklassifikation af cloud-deployede AI-systemer: infrastruktur er neutral, systemet er ikke
Det første spørgsmål for ethvert team, der deployer AI til cloud, er: hvilken risikoklasse tilhører vores system?
EU AI Act opererer med fire klasser:
For cloud-deployede systemer gælder en vigtig præcisering: det er systemets funktion og anvendelseskontekst — ikke dets hosting-miljø — der bestemmer risikoklassen. En rekrutteringsalgoritme deployet i en Kubernetes-cluster på Azure er høj-risiko (Bilag III, punkt 4) uanset, at Azure-platformen selv er regulatorisk neutral.
Praktisk implikation: Klassificeringsøvelsen skal ske inden I arkitekterer jer ind i en containeriseret løsning, ikke efter. Risikoklassen bestemmer, hvilke tekniske krav I skal opfylde, og dermed hvilke arkitekturvalg I må træffe.
3. Versionsstyring og model registry: Art. 9-12 krav til dokumentation af modelversioner
Art. 9 kræver et dokumenteret risikoledelsessystem for hele AI-systemets livscyklus — herunder ved ændringer. Art. 11 og Bilag IV stiller krav til teknisk dokumentation, der skal beskrive systemets "version, dens ydeevne, de data der er anvendt til træning" og "enhver ændring foretaget i systemet."
Det betyder, at jeres model registry ikke blot er et driftsværktøj — det er en compliance-komponent.
Krav der bør være opfyldt i jeres model registry: