For få år siden var svaret på spørgsmålet "hvem skrev denne kode?" forholdsvis enkelt. Man kunne pege på en programmør, et team eller et softwarehus, som var ansvarligt for et bestemt modul.
I dag ser situationen helt anderledes ud.
En del af koden kan være skrevet manuelt. En del kan være genereret af Copilot. Et andet stykke skaber en programmeringsagent. Noget hentes fra et open source-bibliotek. Endnu et stykke er en afhængighed fra en ekstern pakke. Dertil kommer API'er, cloud-tjenester, færdige komponenter, frameworks og værktøjer leveret af forskellige virksomheder.
Systemet virker. Men ved du virkelig, hvad det er bygget af?
Kode genereret af AI opstår ikke i et vakuum
Udviklingen af AI-værktøjer til programmering ændrer ikke kun måden, vi skriver software på. Den ændrer også ansvarsstrukturen omkring koden.
I dag kan en programmør beskrive en opgave for en agent og få en færdig funktion, modul, tests, konfiguration eller endda forslag til arkitekturændringer. Det er en enorm produktivitetsforøgelse.
Problemet opstår, når vi behandler den genererede kode som "kode, der forsvinder".
AI skaber ikke kode løsrevet fra hele udviklingsøkosystemet. Modeller trænes på enorme datamængder, og et genereret uddrag kan ligne eksisterende løsninger, mønstre eller offentligt tilgængelig kode. Derfor bliver spørgsmålet om kodens oprindelse, licenser og ansvar stadig vigtigere.
Det betyder ikke automatisk, at hvert stykke kode genereret af AI krænker nogens licens. Men det betyder, at en organisation, som bruger AI i softwareudviklingen, bør behandle oprindelsen og verifikation af kode som en del af ingeniørprocessen, ikke kun som en juridisk kuriositet.
Det er ikke kun teori længere
16. september 2026 afgjorde Appelretten i 9. kreds en del af sagen Doe v. GitHub, hvor programmører anklagede GitHub, Microsoft og OpenAI-relaterede enheder for blandt andet at bruge offentligt tilgængelig kode fra GitHub til at skabe og træne værktøjer som Copilot og Codex.
Et af kravene handlede om DMCA og oplysninger om ophavsret. Retten fastholdt afvisningen af dette konkrete krav. Sagen omfatter dog også andre spørgsmål vedrørende ophavsret og open source-licenser.
Det er vigtigt ikke fordi én dom giver et enkelt svar på spørgsmålet "kan man bruge kode fra AI".
Det gør den ikke.
Vigtigere er, at tvisten illustrerer et større problem: i AI-verdenen bliver grænsen mellem kode skrevet af mennesker, kode genereret af modeller og kode fra eksisterende softwareøkosystemer stadig sværere at spore.
Og for de virksomheder, der udvikler software, betyder det, at de må blive bedre til at styre processen.
Software supply chain — dit system har mange flere "forfattere"
I software-sikkerhed har man længe brugt begrebet software supply chain — softwarens forsyningskæde.
Det dækker alle komponenter, værktøjer, biblioteker, afhængigheder og processer, der deltager i skabelsen af det endelige produkt.
NIST peger her blandt andet på behovet for at styre komponenternes oprindelse, kontrollere open source-afhængigheder, overvåge sårbarheder og anvende SBOM, altså Software Bill of Materials.
SBOM kan forenklet sammenlignes med en ingrediensliste for et produkt.
Den siger ikke bare "vi har en applikation". Den viser, hvilke komponenter der er indeni.
For eksempel:
- applikationens framework,
- eksterne biblioteker,
- versioner af enkelte pakker,
- open source-komponenter,
- indirekte afhængigheder,
- elementer leveret af eksterne leverandører.
På den måde, når der opdages en sårbarhed i et konkret bibliotek, kan man hurtigere finde ud af, hvilke systemer der bruger det.
NIST fremhæver også provenance, altså muligheden for at spore oprindelsen af softwareelementer.
Her tilføjer AI et nyt niveau af kompleksitet.
For til den eksisterende kæde kommer en ny måde, hvorpå kode kan opstå.
Forestil dig et typisk forretningssystem
40% af koden er skrevet af teamet.
20% er skabt med hjælp fra AI.
Andre dele er genereret af en agent.
Nogle biblioteker kommer fra open source.
En del afhængigheder blev tilføjet af et framework.
Systemet benytter API'er fra en ekstern leverandør.
En komponent stammer fra en pakke, som ingen har opdateret i to år.
Og dokumentationen af afhængighederne?
Den ligger et sted i repository'et.
Eller den findes ikke.
Systemet virker…
Og derfor er problemet usynligt. Indtil noget sker.
Og så opdages en sårbarhed
Lad os antage, at der opdages en alvorlig sikkerhedssvaghed i et af bibliotekerne.
Spørgsmålet er: Ved du, om dit system bruger den?
Hvis du har et ordentligt register over afhængigheder, kan svaret være et spørgsmål om minutter.
Hvis du ikke har — begynder manuel gennemgang af repositories, kontakt til udviklere, kontrol af miljøer, pakkeversioner og indirekte afhængigheder.
Og nu tilføjer vi kode genereret af AI.
Ved man, hvilket uddrag der blev skabt med hvilket værktøj?
Er der foretaget code review?
Er koden dækket af tests?
Er afhængighederne blevet kontrolleret?
Har nogen verificeret komponentens licens?
Kan man rekonstruere processen, som førte til et konkret uddrag?
Det er ikke længere spørgsmål kun til udvikleren.
Det er spørgsmål om virksomhedens teknologirisikostyring.
Det største problem er ikke AI. Det er mangel på processer
Det ville være nemt at gøre denne artikel til en advarsel mod kunstig intelligens.
Det ville dog være en for simpel konklusion.
AI kan markant forbedre et udviklingsteams produktivitet.
Problemet opstår, når en virksomhed øger tempoet for kodeproduktion, men ikke samtidig øger kontrollen med denne kode.
Det svarer lidt til, at en fabrik pludselig fremstiller ti gange så mange komponenter uden at øge kvalitetskontrollen, materialeregnskabet eller leverandørkontrollen.
I et softwarehus svarer sådanne kontrolsystemer blandt andet til:
- code review
- automatiske tests
- afscanning af afhængigheder
- SBOM
- overvågning af sårbarheder
- kontrol af open source-licenser
- CI/CD med sikkerhedskontroller
- styring af repositories
- dokumentation af arkitektur
- sporing af komponenternes oprindelse
- klare retningslinjer for brug af AI i development
NIST peger også på mulighed for at integrere supply chain-sikkerhedsmekanismer direkte i CI/CD-pipelines.
Det er en vigtig ændring i tankegangen.
Sikkerhed bør ikke være en kontrol, der kun udføres lige inden deployment.
Den bør være en del af selve udviklingsprocessen.
"Hvem skrev denne kode?" er ikke længere det rigtige spørgsmål
I traditionel udvikling kunne man spørge om forfatteren.
I AI-assisteret udvikling bliver følgende spørgsmål langt vigtigere:
- Hvor kommer denne komponent fra?
- Hvilken licens har den?
- Hvem har verificeret den?
- Hvilken version bruger vi?
- Hvilke afhængigheder har den?
- Ved vi, om den stadig vedligeholdes?
- Kender vi dens sårbarheder?
- Kan vi genskabe ændringshistorikken?
- Ved vi, hvor AI deltog i dens skabelse?
Og frem for alt:
- Kan virksomheden bevise, at den har styr på det hele?
For en kunde køber ikke "kode fra AI". Kunden køber et fungerende system. Og ansvaret for det system hviler fortsat på den organisation, som leverer og vedligeholder det.
Koden kan være automatisk. Ansvarligheden er det ikke
Det er sandsynligvis en af de vigtigste ændringer, som AI bringer ind i softwarehusene.
Programmøren forsvinder ikke. Rollen ændrer sig.
Oftere handler det ikke kun om at skrive et vist antal linjer kode. Det handler om at designe løsningen, kontrollere genererede elementer, vurdere risiko, teste, integrere, sikre og vedligeholde hele systemet.
Ligeledes kan en virksomhed ikke nøjes med at spørge, om dens programmører bruger AI.
Den bør vide hvordan de bruger det, i hvilken proces, med hvilke kontroller, og hvordan det påvirker softwarelivscyklussen.
For om få år kan spørgsmålet ikke være: "Hvem skrev dette system?"
men: "Kan du genskabe, af hvad og på hvilken måde det blev bygget?"
Hvis svaret er "ikke helt", er problemet ikke et nyt AI-værktøj.
Problemet er manglen på kontrol over software supply chain.
