AI‑kodeassistenter i kildekodetvister

Forside · Gennemgået oktober 2026 · Af John Nielsen

Kort svar: Brug af AI-kodeassistenter kan dokumenteres fra flere kilder: commit-metadata og trailers i Git, commits og pull requests fra agentkonti, platformens auditlog, forbrugsdata pr. bruger og lokale logs og sessionshistorik på udviklerens maskine. Ingen af kilderne er fuldstændige. Trailers kan slås fra eller fjernes, auditloggen indeholder normalt ikke de prompts, der blev sendt fra editoren, og indholdsanalyse af selve koden kan ikke sikkert afgøre, om den er skrevet af en model. Konklusionen skal derfor bygge på flere uafhængige spor.

Spørgsmålene opstår i leverancetvister, hvor aftalen forbød eller krævede oplysning om AI-værktøjer, i tvister om ophav og bidrag, og i interne sager om kildekode sendt til eksterne tjenester. Den juridiske ramme er beskrevet på AI-leverancer: dokumentation af model, data og output og Ophavsret og software: dokumentation af kopiering. Grundlaget for Git som bevis står i Kildekode og Git som bevis.

Spor i Git-historikken

Trailers: Flere værktøjer tilføjer linjer som Co-authored-by i commit-beskeden, når en AI-assistent har bidraget. Nogle editorer har en indstilling, der tilføjer en AI-medforfatter, og nogle agentværktøjer gør det som standard. Indstillingerne kan ændres, og en trailer kan fjernes, når historikken omskrives. Fravær af en trailer viser derfor ikke, at der ikke er brugt AI.

Agentkonti: Kodningsagenter, der arbejder på platformen, committer ofte under en særskilt bot-identitet. Ifølge GitHub committer Copilot coding agent under Copilots identitet med den person, der tildelte opgaven, som medforfatter, og commits indeholder en Agent-Logs-Url-trailer, der peger på agentens sessionslog. En squash-merge kan ændre, hvem der står som forfatter, så de oprindelige commits i pull requesten skal sikres.

Mønstre: Store commits med meget ny kode på kort tid, ensartet kommentarstil og pludselige skift i struktur kan være indikatorer, men de beviser intet alene. Mønstrene bør holdes op mod timeregistrering og opgavehistorik; se Timeregistrering mod commits og tickets.

Platformens logs

Kodeplatformens auditlog registrerer typisk administrative hændelser for AI-tjenesten: tildeling af licenser, ændrede politikker, udelukkelse af indhold fra AI-behandling og agentaktivitet på platformen. Ifølge GitHubs dokumentation indeholder auditloggen for Copilot ikke klientsessionsdata som de prompts, en bruger sender lokalt, og loggen gemmer hændelser i 180 dage, medmindre den streames til et eksternt logsystem. Om platformens auditlogs generelt, se GitHub, GitLab og Azure DevOps: auditlogs.

Forbrugsdata er en separat kilde. Platformene leverer aggregerede tal pr. bruger, sprog og editor, fx antal forslag, accepterede forslag og chatbrug. De viser, at en bruger brugte værktøjet i en periode, ikke hvilken kode der kom ud af det. Agentsessioner på platformen kan have deres egne logs med opgave, trin og ændringer, og de er ofte den mest detaljerede kilde til, hvad en agent faktisk gjorde.

Leverandørens opbevaring

Hvad leverandøren gemmer af prompts og forslag, afhænger af værktøj, adgangsvej og abonnement, og det ændres løbende. Erhvervsplaner har ofte kortere eller ingen opbevaring af prompts fra editoren, mens chat på web eller i kommandolinjen kan opbevares længere. Afklar det i leverandørens aktuelle dokumentation for den relevante periode, og antag ikke, at leverandøren kan levere indholdet. Om eksport fra chattjenester, se ChatGPT, Claude og Gemini: historik og workspace-eksport.

Spor på udviklerens maskine

Editorudvidelser og agentværktøjer i kommandolinjen kan gemme lokale logs, chathistorik og sessionsudskrifter i brugerprofilen eller i projektmappen, og konfigurationsfiler kan vise, hvilke værktøjer og modeller der var sat op. Hvad der gemmes, og hvor længe, varierer mellem værktøjer og versioner. Maskinen skal sikres, før værktøjerne opdateres eller afinstalleres, og kun inden for de rammer, der gælder for adgang til enheden.

Når aftalen forbød AI-værktøjer

Mange udviklingsaftaler regulerer nu brugen af AI-værktøjer: forbud, krav om godkendelse, krav om oplysning eller krav om, at kundens kode ikke må sendes til eksterne tjenester. Det tekniske spørgsmål bliver da ikke kun, om der er brugt et værktøj, men hvornår, af hvem, på hvilket repositorium og med hvilke indstillinger.

En brugbar opdeling er:

Adgang: havde udviklerne licenser eller installerede udvidelser i perioden? Licenstildelinger i auditloggen og konfiguration på maskinerne kan vise det.
Brug: viser forbrugsdata, agentsessioner eller trailers, at værktøjet blev brugt, og i hvilke repositorier?
Data ud af huset: var kundens repositorium udelukket fra AI-behandling, og var den indstilling aktiv hele perioden? Ændringer i udelukkelser står i auditloggen.
Indhold: hvilke commits er knyttet til brugen, og hvilken del af leverancen udgør de?

Svarene skal holdes adskilt, fordi de kan pege i forskellige retninger. En udvikler kan have haft licens uden at bruge den, eller have brugt værktøjet på et andet projekt.

Sikring

Spejl repositoriet med alle grene, tags og referencer, også pull request-referencer, og hash resultatet. En almindelig kloning kan mangle referencer.
Sikr pull requests med commits, kommentarer og reviews, før de squashes eller lukkes.
Eksportér auditloggen for AI-tjenesten og organisationen, og hent forbrugsdata for perioden.
Sikr agentsessioner og deres logs, hvis platformen har dem.
Dokumentér politikkerne, som de var: hvem der havde licens, og hvilke indstillinger og udelukkelser der gjaldt.
Sikr udviklermaskiner med lokale logs og konfigurationer, hvor det er relevant og lovligt.

Indholdsanalyse af koden

Om en bestemt kodeblok er skrevet af en model, kan ikke afgøres sikkert ved at analysere teksten. Detektionsværktøjer har kendte fejlrater, og menneskeskrevet kode kan ligne modelkode og omvendt. Se AI-genereret indhold: tekniske metoder til vurdering. En mere håndfast analyse er sammenligning med offentlig kode for at finde uddrag, der kan rejse licensspørgsmål, uanset hvordan de er kommet ind.

Leverandørernes vilkår og dokumentation om opbevaring ændres løbende. Gem derfor en dateret kopi af de relevante sider for den periode, sagen handler om, så rapporten kan henvise til de vilkår, der faktisk gjaldt, og ikke kun til den nuværende version.

Typiske fejlkilder

Trailer er ikke indhold: en AI-medforfatter i en commit viser, at værktøjet var involveret, ikke hvor meget af koden der stammer fra det.
Omskrevet historik: rebase og squash fjerner eller ændrer metadata. Sammenlign med platformens kopi og med kopier hos andre udviklere.
Fælles konti og maskiner: licenser kan være delt, og byggeservere committer under tekniske brugere.
Tidszoner: commit-tid er udviklerens lokale tid med zoneangivelse, platformens logs er ofte i UTC.

Hvad sporene kan og ikke kan bevise

Sporene kan samlet vise, at en bruger havde adgang til og brugte en AI-kodeassistent i en periode, at bestemte commits er lavet af en agent, og at bestemte politikker var gældende. De kan sjældent vise præcis, hvilke linjer der kom fra en model, og de kan ikke vise, at AI ikke er brugt. Rapporten bør skelne mellem dokumenteret brug, indikatorer og det, der ikke kan afgøres.

Kilder og versioner

Senest gennemgået: oktober 2026.

Næste skridt

Læs også: Fejllister og fejlklassifikation i en projekttvist · Kunden påstår fejl i jeres software: sikring af produktion

→ Uvildig IT-sagkyndig med forensic-baggrund · For sagkyndige · Tlf. 70 13 63 23 · Digital bevissikring hos Nielco IT

Skrevet af John Nielsen, IT‑sagkyndig og indehaver af Nielco IT. Selvstændig siden 2009 og mere end 30 års erfaring med IT‑sikkerhed. Har været IT‑sagkyndig i danske retskredse og ved Den Fælles Europæiske Patentdomstol (UPC). Om John Nielsen · LinkedIn · Redaktionel politik