För bara några år sedan var svaret på frågan "vem skrev den här koden?" relativt enkelt. Man kunde peka ut en programmerare, ett team eller ett mjukvaruhus som ansvarade för en specifik modul.
I dag ser situationen helt annorlunda ut.
En del av koden kan skrivas manuellt. En del kan genereras av Copilot. Ett annat avsnitt kan skapas av en programmeringsagent. Något annat hämtas från ett open source-bibliotek. Ytterligare något blir ett externt beroende i ett paket. Därtill kommer API:er, molntjänster, färdiga komponenter, ramverk och verktyg som levereras av ytterligare företag.
Systemet fungerar. Men vet du egentligen vad det är byggt av?
AI-genererad kod uppstår inte i ett vakuum
Utvecklingen av AI-verktyg för programmering förändrar inte bara hur mjukvara skrivs. Den förändrar också ansvarsfördelningen kring koden.
En programmerare kan i dag beskriva en uppgift för en agent och sedan få en färdig funktion, modul, tester, konfiguration eller till och med förslag på arkitektoniska ändringar. Det innebär en enorm acceleration av arbetet.
Problemet uppstår när vi behandlar den genererade koden som "kod från ingenstans".
AI skapar nämligen inte kod frikopplad från hela det programmeringsmässiga ekosystemet. Modeller tränas på enorma datamängder, och det genererade avsnittet kan likna befintliga lösningar, mönster eller offentligt tillgänglig kod. Just därför blir frågan om kodens ursprung, licenser och ansvar allt viktigare.
Det betyder inte automatiskt att varje kodsnutt som genereras av AI bryter mot någon annans licens. Det betyder däremot att en organisation som använder AI i mjukvaruutvecklingen bör behandla kodens ursprung och verifiering som en del av den tekniska processen, inte som en juridisk kuriosa.
Det är inte längre bara teori
Den 16 september 2026 avgjorde 9:e kretsens appellationsdomstol en del av målet Doe v. GitHub, där utvecklare anklagade GitHub, Microsoft och OpenAI-relaterade parter bland annat för att ha använt offentligt tillgänglig kod från GitHub vid skapandet och träningen av verktyg som Copilot och Codex.
Ett av anspråken gällde DMCA och information om upphovsrätt. Domstolen fastställde avvisningen av just den anklagelsen. Samtidigt omfattar målet också andra frågor relaterade till upphovsrätt och open source-licenser.
Detta är viktigt inte för att en enskild dom ger ett enkelt svar på frågan "får man använda kod från AI".
Det gör den inte.
Det viktigaste är att tvisten visar ett större problem: i AI-världen blir gränsen mellan kod skriven av en människa, kod genererad av en modell och kod som kommer från det befintliga mjukvaruekosystemet allt svårare att spåra.
Och för företag som utvecklar mjukvara innebär det ett behov av bättre styrning av den här processen.
Software supply chain, alltså har ditt system betydligt fler "författare"
Inom mjukvarusäkerhet har begreppet software supply chain länge använts - mjukvarans leveranskedja.
Det omfattar alla komponenter, verktyg, bibliotek, beroenden och processer som deltar i att skapa den slutliga produkten.
NIST lyfter i detta sammanhang bland annat behovet av att hantera komponenters ursprung, kontrollera open source-beroenden, övervaka sårbarheter och använda SBOM, alltså Software Bill of Materials.
SBOM kan i mycket grova drag jämföras med en lista över produktens ingredienser.
Den säger inte bara "vi har en applikation". Den visar vilka komponenter som finns inuti.
Till exempel:
- applikationsramverk,
- externa bibliotek,
- versioner av enskilda paket,
- open source-komponenter,
- indirekta beroenden,
- element som levereras av externa leverantörer.
Tack vare detta kan man snabbare se vilka system som använder ett visst bibliotek när en sårbarhet upptäcks i det.
NIST pekar också på provenance, alltså möjligheten att spåra mjukvaruelementens ursprung.
Och just här lägger AI till en ny nivå av komplexitet.
För nu tillkommer ännu ett sätt att skapa kod i den befintliga kedjan.
Föreställ dig ett typiskt affärssystem
40% av koden skrevs av teamet.
20% uppstod med stöd av AI.
Ytterligare delar genererades av en agent.
Några bibliotek kommer från open source.
En del beroenden lades till av ramverket.
Systemet använder API:er från en extern leverantör.
En komponent kommer från ett paket som ingen har uppdaterat på två år.
Och dokumentationen av beroendena?
Den finns någonstans i repot.
Eller så finns den inte.
Systemet fungerar...
Och just därför är problemet osynligt. Tills något händer.
Och sedan dyker en sårbarhet upp
Anta att en allvarlig säkerhetslucka upptäcks i ett av biblioteken.
Frågan är: Vet du om ditt system använder det?
Om du har ett strukturerat register över beroenden kan svaret vara en fråga om minuter.
Om du inte har det börjar ett manuellt sökande i repositories, kontakt med utvecklare, kontroll av miljöer, paketversioner och indirekta beroenden.
Och lägg nu till AI-genererad kod ovanpå det.
Vet man vilken del som skapades med vilket verktyg?
Gjorde man code review?
Täcktes koden av tester?
Kontrollerades beroendena?
Verifierade någon komponentens licens?
Går det att återskapa processen som ledde till att just den här koden skapades?
Det här är inte längre frågor enbart för programmeraren.
Det är frågor som rör företagets hantering av teknologisk risk.
Det största problemet är inte AI. Det är bristen på process
Det vore lätt att göra den här artikeln till en varning för artificiell intelligens.
Men det vore en alltför enkel slutsats.
AI kan kraftigt förbättra produktiviteten i ett utvecklingsteam.
Problemet uppstår när företaget ökar takten i kodproduktionen, men inte samtidigt ökar kontrollen över den koden.
Det är lite som om en fabrik plötsligt producerade tio gånger fler delar, men inte ökade kvalitetskontrollen, materialregistreringen eller kontrollen av leverantörerna.
I ett mjukvaruhus är motsvarigheterna till ett sådant kontrollsystem bland annat:
- code review
- automatiska tester
- skanning av beroenden
- SBOM
- övervakning av sårbarheter
- kontroll av open source-licenser
- CI/CD med säkerhetskontroller
- hantering av repositories
- dokumentation av arkitekturen
- spårning av komponenters ursprung
- tydliga regler för användning av AI i utveckling
NIST pekar också på möjligheten att integrera mekanismer för säkerhet i leveranskedjan direkt med CI/CD-pipelines.
Detta är en viktig förändring i sättet att tänka.
Säkerhet bör inte vara en kontroll som görs först före driftsättning.
Den bör vara en del av programvaruutvecklingsprocessen.
"Vem skrev den här koden?" slutar vara rätt fråga
I den traditionella utvecklingsvärlden kunde man fråga efter författaren.
I världen av AI-assisterad utveckling blir följande frågor mycket viktigare:
- Varifrån kommer denna komponent?
- Vilken licens har den?
- Vem har verifierat den?
- Vilken version använder vi?
- Vilka beroenden har den?
- Är den fortfarande underhållen?
- Känner vi till dess sårbarheter?
- Kan vi återskapa ändringshistoriken?
- Vet vi var AI deltog i dess tillkomst?
Och framför allt:
- Kan företaget bevisa att det har kontroll över allt detta?
För kunden köper ju inte "kod från AI". Kunden köper ett fungerande system. Och ansvaret för det systemet bär fortfarande organisationen som levererar och underhåller det.
Koden kan vara automatisk. Ansvar kan det inte
Detta är troligen en av de viktigaste förändringarna som AI för med sig till mjukvaruhus.
Programmeraren försvinner inte. Deras roll förändras.
Allt oftare handlar det inte enbart om att skriva ett visst antal kodrader. Det handlar om att designa lösningen, granska de genererade komponenterna, bedöma risker, testa, integrera, säkerställa säkerhet och underhålla hela systemet.
På samma sätt kan företaget inte begränsa sig till att fråga om dess utvecklare använder AI.
Det bör veta hur de använder det, i vilken process, med vilka kontroller och hur det påverkar hela programvarans livscykel.
För om några år kanske frågan inte längre lyder: "Vem skrev det här systemet?"
utan: "Kan du återskapa vad det byggdes av och hur det byggdes?"
Om svaret är "inte riktigt", är problemet inte bristen på ännu ett AI-verktyg.
Problemet är bristen på kontroll över mjukvarans leveranskedja.
