Nog enkele jaren geleden was het antwoord op de vraag "wie heeft deze code geschreven?" relatief eenvoudig. Je kon de programmeur, het team of het softwarehuis aanwijzen dat verantwoordelijk was voor een specifiek onderdeel.
Vandaag ziet de situatie er heel anders uit.
Een deel van de code kan handmatig worden geschreven. Een deel kan door Copilot worden gegenereerd. Een ander fragment wordt gemaakt door een programmeeragent. Weer een ander wordt opgehaald uit een open-sourcebibliotheek. Nog iets anders is een externe afhankelijkheid van een pakket. Daarbovenop komen API's, clouddiensten, kant-en-klare componenten, frameworks en tools die door weer andere bedrijven worden geleverd.
Het systeem werkt. Maar weet je echt waaruit het is opgebouwd?
Code die door AI wordt gegenereerd, ontstaat niet in een vacuüm
De ontwikkeling van AI-tools voor programmeren verandert niet alleen de manier waarop software wordt geschreven. Ze verandert ook de structuur van de verantwoordelijkheid voor code.
Een programmeur kan vandaag een agent een taak beschrijven en vervolgens een kant-en-klare functie, module, tests, configuratie of zelfs voorstellen voor architecturale wijzigingen ontvangen. Dat versnelt het werk enorm.
Het probleem ontstaat wanneer we gegenereerde code behandelen als "code uit het niets".
AI maakt code immers niet los van het hele programmeer-ecosysteem. Modellen worden getraind op enorme datasets, en het gegenereerde fragment kan lijken op bestaande oplossingen, patronen of openbaar beschikbare code. Juist daarom wordt de kwestie van herkomst van code, licenties en verantwoordelijkheid steeds belangrijker.
Dat betekent niet automatisch dat elk door AI gegenereerd codefragment iemands licentie schendt. Het betekent wel dat een organisatie die AI gebruikt in het softwareontwikkelingsproces de herkomst en verificatie van code moet behandelen als onderdeel van het technische proces, en niet als een juridisch curiosum.
Het is niet langer alleen theorie
Op 16 september 2026 heeft het Hof van Beroep van het 9e Circuit een deel van de zaak Doe v. GitHub beslist, waarin programmeurs GitHub, Microsoft en OpenAI onder meer verweten publiek beschikbare code van GitHub te hebben gebruikt bij het creëren en trainen van tools zoals Copilot en Codex.
Een van de claims had betrekking op de DMCA en auteursrechtinformatie. De rechtbank handhaafde de afwijzing van precies die klacht. Tegelijkertijd omvat de zaak ook andere kwesties rond auteursrechten en open-sourcelicenties.
Dat is belangrijk niet omdat één vonnis een eenvoudig antwoord geeft op de vraag "mag je code uit AI gebruiken".
Dat doet het niet.
Belangrijker is dat het geschil een breder probleem laat zien: in de wereld van AI wordt de grens tussen door een mens geschreven code, code gegenereerd door een model en code afkomstig uit een bestaand software-ecosysteem steeds moeilijker te traceren.
En voor bedrijven die software ontwikkelen betekent dit dat ze dit proces beter moeten beheren.
Software supply chain, oftewel: jouw systeem heeft veel meer "auteurs"
In softwarebeveiliging bestaat al jaren het begrip software supply chain - de toeleveringsketen van software.
Dat zijn alle componenten, tools, bibliotheken, afhankelijkheden en processen die betrokken zijn bij het ontstaan van het eindproduct.
NIST wijst in deze context onder meer op de noodzaak om de herkomst van componenten te beheren, open-sourceafhankelijkheden te controleren, kwetsbaarheden te monitoren en SBOM toe te passen, oftewel Software Bill of Materials.
SBOM kun je in grote lijnen vergelijken met een ingrediëntenlijst van een product.
Het zegt niet alleen "we hebben een applicatie". Het laat zien welke componenten erin zitten.
Bijvoorbeeld:
- applicatieframework,
- externe bibliotheken,
- versies van afzonderlijke pakketten,
- open-sourcecomponenten,
- indirecte afhankelijkheden,
- elementen geleverd door externe leveranciers.
Daardoor kun je, wanneer er een kwetsbaarheid in een specifieke bibliotheek opduikt, sneller nagaan welke systemen die gebruiken.
NIST wijst ook op provenance, oftewel de mogelijkheid om de herkomst van software-elementen te traceren.
En juist hier voegt AI een nieuw complicatieniveau toe.
Want naast de bestaande keten komt er een extra manier bij waarop code ontstaat.
Stel je een typisch bedrijfsysteem voor
40% van de code is door het team geschreven.
20% is ontstaan met ondersteuning van AI.
Nog eens enkele fragmenten zijn gegenereerd door een agent.
Een paar bibliotheken komen uit open source.
Een deel van de afhankelijkheden is toegevoegd door het framework.
Het systeem gebruikt API's van een externe leverancier.
Eén component komt uit een pakket dat al twee jaar niet is bijgewerkt.
En de documentatie van de afhankelijkheden?
Die staat ergens in de repository.
Of er is geen documentatie.
Het systeem werkt...
En juist daarom is het probleem onzichtbaar. Totdat er iets gebeurt.
En dan duikt er een kwetsbaarheid op
Stel dat in een van de bibliotheken een ernstige beveiligingslek wordt ontdekt.
De vraag is: weet je of jouw systeem die gebruikt?
Als je een geordend register van afhankelijkheden hebt, kan het antwoord een kwestie van minuten zijn.
Als je dat niet hebt, begint een handmatige zoektocht door repositories, contact met programmeurs, controle van omgevingen, pakketversies en indirecte afhankelijkheden.
En voeg daar nu de door AI gegenereerde code aan toe.
Is bekend welk fragment met welk hulpmiddel is gemaakt?
Is er code review uitgevoerd?
Is de code gedekt door tests?
Zijn de afhankelijkheden gecontroleerd?
Heeft iemand de licentie van de component geverifieerd?
Kan het proces worden gereproduceerd dat tot een specifiek fragment heeft geleid?
Dat zijn niet langer alleen vragen voor de programmeur.
Dit zijn vragen over het beheer van technologisch risico binnen het bedrijf.
Het grootste probleem is niet AI. Het is het ontbreken van een proces
Het zou gemakkelijk zijn om van dit artikel een waarschuwing tegen kunstmatige intelligentie te maken.
Maar dat zou een te eenvoudige conclusie zijn.
AI kan de productiviteit van een ontwikkelingsteam juist sterk verbeteren.
Het probleem ontstaat wanneer een bedrijf het tempo van de codeproductie verhoogt, maar tegelijkertijd de controle over die code niet verhoogt.
Het is een beetje alsof een fabriek plotseling tien keer zoveel onderdelen produceert, maar niet meer doet aan kwaliteitscontrole, materiaalregistratie of controle van leveranciers.
In een softwarehuis bestaan de tegenhangers van zo'n controlesysteem onder andere uit:
- code review
- automatische tests
- scannen van afhankelijkheden
- SBOM
- monitoring van kwetsbaarheden
- controle van open-sourcelicenties
- CI/CD met beveiligingscontroles
- beheer van repositories
- documenteren van de architectuur
- traceren van de herkomst van componenten
- duidelijke regels voor het gebruik van AI in development
NIST wijst ook op de mogelijkheid om mechanismen voor beveiliging van de toeleveringsketen rechtstreeks te integreren in CI/CD-pipelines.
Dat is een belangrijke verandering in denkwijze.
Beveiliging zou geen controle moeten zijn die pas vlak voor de implementatie wordt uitgevoerd.
Het zou deel moeten uitmaken van het softwareontwikkelingsproces.
"Wie heeft deze code geschreven?" houdt op de juiste vraag te zijn
In de wereld van traditioneel development kon je vragen naar de auteur.
In de wereld van AI-assisted development worden veel belangrijkere vragen:
- Waar komt dit onderdeel vandaan?
- Welke licentie heeft het?
- Wie heeft het geverifieerd?
- Welke versie gebruiken we?
- Welke afhankelijkheden heeft het?
- Wordt het nog steeds onderhouden?
- Weten we welke kwetsbaarheden het heeft?
- Kunnen we de wijzigingsgeschiedenis reconstrueren?
- Weten we waar AI heeft meegewerkt aan de totstandkoming ervan?
En vooral:
- Kan het bedrijf bewijzen dat het hier allemaal grip op heeft?
Want de klant koopt natuurlijk niet "AI-code". Die koopt een werkend systeem. En de verantwoordelijkheid voor dat systeem blijft bij de organisatie die het levert en onderhoudt.
Code kan automatisch zijn. Verantwoordelijkheid niet
Dit is waarschijnlijk een van de belangrijkste veranderingen die AI meebrengt voor softwarehuizen.
De programmeur verdwijnt niet. Zijn rol verandert.
Steeds vaker gaat het niet alleen om het schrijven van een bepaald aantal regels code. Het gaat om het ontwerpen van de oplossing, het controleren van gegenereerde onderdelen, risicobeoordeling, testen, integratie, beveiliging en het onderhoud van het hele systeem.
Evenzo kan een bedrijf zich niet beperken tot de vraag of zijn programmeurs AI gebruiken.
Het moet weten hoe ze het gebruiken, in welk proces, met welke controles en hoe dit het hele softwarelevenscyclus beïnvloedt.
Want over een paar jaar kan de vraag misschien niet luiden: "Wie heeft dit systeem geschreven?"
maar: "Kun je reconstrueren waarvan en op welke manier het is gebouwd?"
Als het antwoord "niet helemaal" luidt, is het probleem niet het gebrek aan weer een andere AI-tool.
Het probleem is het gebrek aan controle over de software supply chain.
