Het beeld van een ontwikkelaar die een regel code ondertekent, lijkt misschien ouderwets in een tijd waarin AI-agenten patches, tests en documentatie in seconden genereren. Maar die handtekening heeft nog altijd meer gewicht dan ooit. Niet omdat software terug moet naar een langzaam en handmatig ambacht, maar omdat kritieke systemen iets nodig hebben dat geen enkel model op zichzelf kan bieden: verifieerbare menselijke verantwoordelijkheid.
De vooruitgang van programmeerassistenten heeft het tempo van ontwikkeling veranderd. Tools zoals Copilot, Claude Code, Cursor of Codex helpen bij het schrijven van functies, het opsporen van fouten, het voorstellen van refactoringen en het automatiseren van taken die vroeger uren kostten. In sommige teams wordt niet meer gedebatteerd over het gebruik van AI, maar over hoe deze te integreren zonder controle te verliezen over kwaliteit, veiligheid en eigenaarschap van de code.
Het probleem ontstaat wanneer snelheid wordt verward met betrouwbaarheid. Een AI-gegenereerde patch kan compileren, de stijl van het project volgen en eenvoudige tests doorstaan, maar falen in een randgeval, een onveilige afhankelijkheid introduceren of een kwetsbaar patroon reproduceert dat is geleerd uit publieke code. De schijn van correctheid volstaat niet. In software, en vooral bij kritieke infrastructuur, komt de kostenpost van een fout vaak pas in het productiesysteem aan het licht.
Linux zet een grens: AI helpt, maar ondertekent niet
De Linux-kernel heeft een regel geformaliseerd die de huidige situatie goed samenvat. AI-assistenten kunnen helpen bij ontwikkeling, maar mogen het label Signed-off-by niet toevoegen. Die ondertekening is gekoppeld aan het Developer Certificate of Origin, het mechanisme waarmee een bijdrager certificeert dat hij recht heeft om die code in te dienen en de verantwoordelijkheid voor de bijdrage op zich neemt.
De richtlijnen van de kernel zijn duidelijk: alleen een persoon kan de door AI gegenereerde code reviewen, de compatibiliteit met de licentie controleren, zijn eigen handtekening zetten en voor het resultaat instaan. Wanneer een AI-tool betrokken is geweest, moet dat worden aangegeven met een Assisted-by-label, waarin de agent, de modelversie en indien relevant andere gebruikte analysetools worden vermeld.
Deze aanpak betekent niet dat AI wordt afgewezen. Het is een manier om deze binnen een vertrouwd proces te integreren dat al bestond. De boodschap voor andere projecten is eenvoudig: AI kan schrijven, suggesties doen of versnellen, maar kan niet aansprakelijk worden gesteld voor juridische of technische gevolgen. Als een patch iets breekt, een kwetsbaarheid ontsnapt, of een licentie wordt geschonden, ligt de verantwoordelijkheid niet bij het model, de API of een externe leverancier, maar bij de menselijke bijdrager.
Deze scheiding wordt steeds belangrijker. In ontwikkelomgevingen met autonome agenten zal de verleiding groeien om volledige beslissingen uit handen te geven. Maar hoe autonomer een tool wordt, hoe noodzakelijker het wordt om vast te leggen wat is gedaan, met welke permissies, op welk repository, onder welke instructies en door wie het eindresultaat is gevalideerd.
Snel gegenereerde code geeft ook snel schuld
De beveiliging van AI-toepassingen in ontwikkeling kan niet beperkt blijven tot het passeren van een linter of het uitvoeren van basistests. Een rapport van Veracode over door AI gegenereerde code concludeerde dat 45% van de bestudeerde monsters bekende beveiligingsfouten bevatte. Dit betekent niet dat alle door AI gegenereerde code onveilig is, of dat menselijke code perfect is. Maar het wijst erop dat productiviteit zonder review snel technische en beveiligingsschulden kan opstapelen.
Hierbij hoort een standaard: behandel door AI gegenereerde code als niet-vertrouwbaar totdat het tegendeel is bewezen. Dit betekent menselijke review, geautomatiseerde tests, statische analyses, afhankelijkheidcontroles, geheimenbeheer, veiligheidscontroles en architectuuroverwegingen bij wijzigingen in gevoelige onderdelen.
Het is ook belangrijk om afhankelijkheden te monitoren. Modellen kunnen bibliotheken voorstellen die niet bestaan, verouderd of slecht onderhouden zijn. In een traditioneel ontwikkelproces kent de ontwikkelaar het ecosysteem, maar in een agent-gestuurd proces kan een tool pakketten toevoegen zonder te begrijpen wat de beveiligingsregels van de organisatie vereisen. Dit risico wordt niet weggenomen door vertrouwen, maar door controlemechanismen.
Het klassieke beginsel van minimale privileges moet worden uitgebreid met een nieuw uitgangspunt: minimale bevoegdheid. Een agent zou slechts dat moeten kunnen doen wat noodzakelijk is voor een specifieke taak. Het is niet hetzelfde om een agent te laten voorstellen of te laten wijzigen, en permisos te geven voor het aanpassen van branches, openen van pull requests, wijzigen van pipelines, installeren van dependencies of uitrollen in productie.
Supply chain toont dat impliciet vertrouwen niet standhoudt
Recente incidenten buiten AI-ondersteund ontwikkelen bevestigen dezelfde les. In april 2026 werd de site van CPUID, bekend van tools zoals CPU-Z en HWMonitor, twintig uur lang aangevallen. Volgens Kaspersky vervingen aanvallers legitieme downloadlinks door trojan-achtige installers met een ondertekende executable en een kwaadaardige DLL genaamd CRYPTBASE.dll, geladen via DLL sideloading.
Het detail is belangrijk. Het is niet altijd nodig om het ondertekende binaire te veranderen om de gebruiker te compromitteren. Soms volstaat het om de distributieketen aan te passen, een library op de juiste plek te plaatsen en gebruik te maken van verouderde load-regels. De ondertekening bleef vertrouwen wekken, maar de geleverde software was al geïnfecteerd.
Apple repareerde in april 2026 ook de kwetsbaarheid CVE-2026-28950 in Notification Services, waardoor meldingen die voor verwijdering waren bestemd onverwacht konden blijven hangen. Media legden de link met forensisch onderzoek naar Signal-meldingen. Hoewel encryptie eind-tot-eind solide is, hangt de privacy ook af van het besturingssysteem, meldingssystemen, lokale kopieën, logs en tools voor data-extractie.
Deze voorbeelden laten zien dat veiligheid niet op één manier te waarborgen is. Een model kan correct ogende code genereren, een executable getekend zijn, en een app berichten versleutelen. Maar als de supply chain, het OS, bibliotheekladen of logbeheer falen, wordt het vertrouwen geschaad op een andere plek.
Continue verificatie, geen ceremoniële audit
AI-governance mag niet slechts een beleidsmap zijn die jaarlijks wordt herzien. Als agenten code genereren, documentatie aanpassen, bugs indienen, pull requests reviewen of deployment voorstellen, moet controle deel uitmaken van het dagelijkse werkproces.
Dat betekent dat je bij elke verandering moet registreren of AI-assistentie is gebruikt, de prompts en relevante acties moet vastleggen, menselijke review moet afdwingen bij kritieke wijzigingen, automatische controles moet toepassen vóór merge, en permissies moet beperken per repository, omgeving en taak. Daarnaast moet je metrics bijhouden zoals valse positieven, herhaalde fouten en de gebieden waar de tool vaker de fout ingaat.
Het doel is niet de adoptie van AI te stoppen, maar deze duurzaam te maken. Innovatie zonder traceerbaarheid kan niet worden gecontroleerd. Automatisering zonder limieten is niet te sturen. En code die niemand ondertekent, ook al werkt hij vandaag, wordt een probleem als hij morgen faalt.
De rol van ontwikkelaar verandert niet door AI, hij verwatert alleen niet. De ontwikkelaar wordt minder functioneel als mechanisch typist en meer verantwoordelijk voor oordeel, context, architectuur, veiligheid en validatie. AI kan veel schrijven, maar iemand moet weten wat niet geschreven mag worden, wat niet gedeployed mag worden en waar een meer grondige review noodzakelijk is.
In 2026 is de vraag niet meer of organisaties AI gebruiken voor softwareontwikkeling, maar wie ondertekent wat AI produceert, welke controles er zijn en wat er gebeurt wanneer het resultaat faalt. De mens blijft aan het roer, niet uit nostalgie, maar omdat hij nog altijd de enige is die verantwoording kan afleggen.
Veelgestelde vragen
Kan AI code ondertekenen in de Linux-kernel?
Nee. Volgens de kernelrichtlijnen kunnen AI-agenten geen Signed-off-by-tags toevoegen. Alleen een persoon kan het Developer Certificate of Origin certificeren en de verantwoordelijkheid nemen.
Wat betekent de tag Assisted-by?
Deze geeft aan dat een AI-hulpmiddel heeft geholpen bij de bijdrage. Het biedt transparantie zonder de juridische of technische verantwoordelijkheid bij de AI te leggen.
Is alle door AI gegenereerde code onveilig?
Nee. Maar ze moet worden gecontroleerd zoals elke niet-vertrouwde code. Beveiligingsstudies tonen aan dat er vaak fouten in AI-gegenereerde monsters zitten, waardoor menselijke review en tests nog steeds essentieel zijn.
Welke controles moet een bedrijf toepassen bij het gebruik van AI-agenten voor programmeren?
Permissies beperken, acties registreren, menselijke review afdwingen bij gevoelige wijzigingen, beveiligingsanalyses toepassen, afhankelijkheden controleren en continue verificatie integreren in het ontwikkelproces.