Forordning (EU) 2024/2847 stiller krav til produktet og til processen bag det, uanset hvem eller hvad der har skrevet linjerne. Kode, som en udvikler har fået foreslået af en AI-assistent, skal derfor opfylde bilag I på samme måde som kode, en kollega har skrevet i hånden.
At forordningen ikke skelner efter kodens ophav, er vores tolkning. Teksten nævner ikke værktøjer til kodegenerering. Den taler om fabrikantens pligter for produktet, og de pligter gælder fra 11. december 2027. Indtil da er spørgsmålet, hvordan I vil kunne vise kontrol, når en myndighed eller en kunde spørger.
Hvad forordningen faktisk siger
Artikel 13, stk. 1, pålægger fabrikanten at sikre, at produktet er designet, udviklet og fremstillet i overensstemmelse med de væsentlige krav i bilag I, del I. Stk. 2 kræver en vurdering af cybersikkerhedsrisiciene, og resultatet skal bruges i planlægning, design, udvikling, produktion, levering og vedligeholdelse. Efter stk. 3 skal vurderingen være skrevet ned og holdes ajour, så længe supportperioden løber.
Ingen af de tre stykker interesserer sig for, om en linje er skrevet af et menneske. De interesserer sig for, om produktet har de egenskaber, bilag I kræver, og om fabrikanten kan vise, hvordan det er sikret. Den samme læsning gælder sårbarhedshåndteringen i bilag I, del II.
Det betyder også det omvendte. Forordningen forbyder ikke AI-assistenter i udviklingen. Brugen er et valg, som risikovurderingen skal tage stilling til.
Værktøjet hører hjemme i risikovurderingen
Risikovurderingen efter artikel 13, stk. 2, handler om produktet. Når en del af koden kommer fra et værktøj, der foreslår kode ud fra mønstre, er det relevant for, hvilke fejl der kan opstå, og hvordan de fanges. Det er praksis at skrive det ind. Forordningen nævner det ikke.
Spørgsmål, vurderingen kan svare på:
- Hvor i produktet bruges foreslået kode, og hvor er det aftalt, at den ikke bruges?
- Hvilke kodeændringer kræver altid en anden udviklers gennemgang?
- Hvordan fanges kendte svage mønstre, fx manglende inputkontrol eller hårdkodede hemmeligheder?
- Sendes kildekode eller kundedata ud af huset til værktøjet, og er det afvejet?
Det sidste punkt er en sag for husets egen informationssikkerhed og fortrolighed. Det hører med, fordi kildekode, der lækker, kan blive en risiko for produktet.
Hvordan vurderingen bygges op for et softwareprodukt, står i risikovurderingen for et softwareprodukt.
Afhængigheder, værktøjet foreslår
Et konkret problem er de biblioteker, en AI-assistent foreslår at hente ind. Et forslag kan pege på en pakke, der er forældet, ikke længere vedligeholdes eller har et navn, der minder om en kendt pakke. Efter bilag I, del II, nr. 1, skal komponenterne kendes og beskrives, blandt andet i en softwarekomponentliste. Artikel 13, stk. 5, kræver omhu, når komponenter fra tredjeparter integreres.
Kravene skelner ikke mellem en afhængighed, en udvikler fandt selv, og en, et værktøj foreslog. En pakke, der kommer ind via et forslag, skal igennem samme kontrol som andre. Hvad den kontrol består af, står i valg af tredjepartskomponenter.
En gennemgang vil typisk sammenholde komponentlisten med byggefilerne. Står der pakker i byggefilerne, som ingen har vurderet, er det et fund, uanset hvordan de kom ind.
Menneskelig gennemgang og frigivelse
Den vigtigste kontrol er den, der ligger før frigivelse. Bilag I, del II, nr. 3, kræver effektive og regelmæssige afprøvninger og gennemgange af produktets sikkerhed. Hvordan de tilrettelægges, er fabrikantens valg.
For foreslået kode er det praksis at se på tre ting:
- Gennemgang af ændringen. En anden udvikler har læst den, og det kan ses i versionsstyringen.
- Automatiske kontroller. Statisk analyse, test og kontrol af afhængigheder kører på al kode, før den flettes ind.
- Frigivelsen. En navngiven person godkender releasen ud fra resultatet af de to første.
Ingen af de tre punkter er særlige for AI. Det er de samme kontroller, en sikker udviklingsproces har i forvejen. Forskellen er, at mængden af foreslået kode kan vokse hurtigere end evnen til at gennemgå den. Et tegn på det er, at gennemgangene bliver kortere, mens ændringerne bliver større.
Det spor, en gennemgang beder om
Bilag VII beder om en beskrivelse af design, udvikling og sårbarhedshåndtering i den tekniske dokumentation. Hvis AI-assistenter indgår i processen, er det naturligt, at beskrivelsen siger hvordan. En gennemgang af processen vil typisk bede om at se:
- husets regler for brug af AI-assistenter i udviklingen
- risikovurderingens afsnit om værktøjet
- eksempler på ændringer med foreslået kode og den gennemgang, de fik
- komponentlistens historik for nye afhængigheder
- logfiler eller rapporter fra de automatiske kontroller
Et tænkt eksempel. Et softwarehus lader udviklerne bruge en AI-assistent i alle moduler. En gennemgang finder, at to nye biblioteker kom ind i sidste release uden at stå i komponentlisten, og at ændringerne blev godkendt af samme person, der skrev dem. Fundet handler om processen, ikke om værktøjet. Rettelsen er at lade alle ændringer gå gennem en anden udvikler og at lade byggekæden stoppe, når en ny pakke ikke er registreret.
AI-funktioner inde i selve produktet er et andet emne med en anden forordning. Det er beskrevet i AI-funktioner i softwaren.
Hvad det kræver, og hvad det koster at lade være
Det kræver, at brugen af AI-assistenter står i risikovurderingen, at foreslåede afhængigheder går gennem samme kontrol som andre, og at hver ændring har en gennemgang, der kan ses bagefter.
Uden det spor kan I ikke vise, hvordan koden blev kontrolleret. Over for en myndighed er det jeres dokumentation, der bærer. Et værktøj kan ikke tage ansvaret for fejl i et produkt, I har bragt i omsætning.
Det skal I lade være med
- At undtage foreslået kode fra gennemgang, fordi den ser rigtig ud · bilag I måler produktet, ikke kilden.
- At lade nye pakker komme ind uden registrering · komponentlisten skal dække dem.
- At skrive “AI-genereret” som forklaring på en fejl · ansvaret er fabrikantens.
Det skal auditten kunne vise
- ☐ Et afsnit i risikovurderingen om brugen af AI-assistenter.
- ☐ Husets regler for, hvor og hvordan foreslået kode må bruges.
- ☐ En komponentliste, der dækker alle afhængigheder i byggefilerne.
- ☐ En gennemgang af hver ændring udført af en anden end forfatteren.
Kilder
- Forordning (EU) 2024/2847, dansk udgave, artikel 13, stk. 1-3 og 5, artikel 71, bilag I, del I og del II, nr. 1 og 3, og bilag VII, læst 13. november 2026.
Senest gennemgået: november 2026.
Næste skridt
Find den seneste release og tjek, om alle nye pakker står i komponentlisten, og hvem der godkendte ændringerne.
Læs også: Hvornår i udviklingsforløbet skal gennemgangen ligge? · Softwarekomponentlisten (SBOM) efter CRA
→ Kontakt · Tlf. 70 13 63 23 · Cyber Resilience Act hos Nielco IT
