applatenmaken.com/kennisbank/ai-code

Mag uw leverancier uw software met AI laten schrijven?

De vraag is niet meer of uw leverancier AI gebruikt bij het schrijven van uw software, want dat doet vrijwel iedereen. De vraag is wat u daarover afspreekt. Onderzoek dat deze maand rondging liet zien dat ongeveer de helft van de door AI voorgestelde beveiligingsoplossingen zelf kwetsbaarheden bevat. Dat maakt dit een inkoopvraag en niet alleen een technische.

Waarom dit een inkoopvraag is geworden

Een paar jaar geleden was dit een detail van de werkwijze van uw leverancier, net als de vraag welke editor zijn ontwikkelaars gebruiken. Dat is veranderd, om drie redenen die alle drie bij u terechtkomen.

De eerste is kwaliteit. AI-hulpmiddelen zijn goed in het produceren van code die er correct uitziet, en minder goed in het beoordelen of die code past bij wat er al staat. Het onderzoek dat deze maand rondging over beveiligingsoplossingen wees uit dat modellen sterk zijn in het vínden van kwetsbaarheden en zwak in het oplossen ervan: ongeveer de helft van de voorgestelde oplossingen bevatte zelf een kwetsbaarheid. Microsoft stelde om vergelijkbare redenen een grote update uit omdat door AI aangedragen bevindingen handmatig geverifieerd moesten worden.

De tweede is herkomst. Code die een model voortbrengt, is getraind op code van anderen. In de meeste gevallen levert dat geen probleem op, maar het is een vraag die u wilt hebben gesteld voordat uw software ergens de basis van wordt. De derde is onderhoudbaarheid: code die snel is geproduceerd en niet is teruggebracht tot wat nodig is, kost u later meer dan hij bij oplevering heeft bespaard.

Wat er speelt: Vrijwel elke bouwer gebruikt AI-hulpmiddelen; dat is geen uitzondering meer.
Uw risico: Code die werkt maar niet past, met een beveiligingsgat of onnodige complexiteit.
Wat u niet moet doen: Het verbieden. Dat is niet handhaafbaar en levert alleen een leverancier op die er niet meer over praat.
Wat u wel doet: Vastleggen dat hij er verantwoordelijk voor blijft, ongeacht hoe de code tot stand kwam.

Wat u vastlegt in het contract

De kern is eenvoudig: het maakt niet uit hoe de code tot stand is gekomen, uw leverancier staat ervoor in. Dat klinkt vanzelfsprekend maar staat lang niet altijd zo in de overeenkomst, en juist bij AI-hulpmiddelen wordt er soms een voorbehoud gemaakt dat u niet wilt accepteren.

Staat er dat de leverancier instaat voor de geleverde code, ongeacht met welke hulpmiddelen die is gemaakt? Is er een vrijwaring voor aanspraken van derden over rechten op de code? Staat er dat elke wijziging door een mens is beoordeeld voordat hij wordt opgeleverd? Geldt dat ook voor beveiligingsgerelateerde wijzigingen, zonder uitzondering? Is vastgelegd welke componenten van derden in de software zitten en onder welke licentie? Wordt de code eigendom van uw organisatie, met de bijbehorende overdracht? Is er een uitzondering gemaakt voor AI-hulpmiddelen die de aansprakelijkheid beperkt?

De laatste vraag stelt u uitdrukkelijk. Een voorbehoud op dit punt is een reden voor een gesprek, niet iets om over te lezen.

Over het eigendom van de code zelf verandert dit weinig: wat er is afgesproken over overdracht en gebruiksrechten blijft leidend, en dat staat beschreven in broncode: eigendom en overdracht. Wat er wel bij komt, is de vrijwaring: de zekerheid dat als een derde ooit een claim legt op een stuk code, dat niet uw probleem wordt.

Wat u aan de kwaliteitskant afspreekt

Contractueel dichttimmeren helpt achteraf. Wat u vooraf wilt, is dat het gewoon goed gaat. Deze afspraken hebben in de praktijk het meeste effect.

Afspraak	Wat het oplevert	Waar u op let
Menselijke beoordeling van elke wijziging	✓Iemand die het geheel overziet kijkt ernaar voordat het wordt opgeleverd	!Dat het geen formaliteit is; vraag hoe lang zo'n beoordeling gemiddeld duurt
Tests bij elke wijziging	✓U kunt zien dat iets doet wat het moet, ook over een jaar	!Dat de tests iets aantonen en niet alleen bestaan om een percentage te halen
Overzicht van componenten van derden	✓U weet wat er in uw software zit en onder welke licentie	!Dat het wordt bijgehouden en niet alleen bij oplevering is gemaakt
Beveiligingswijzigingen apart behandeld	✓De categorie met het grootste risico krijgt extra aandacht	!Dat een stille scanner niet als bewijs geldt dat iets is opgelost
Documentatie in gewone taal	✓Uw eigen team of een opvolger kan het overnemen	!Dat het gaat over waarom iets zo is gebouwd, niet alleen wat er staat

Deze punten horen in het programma van eisen en niet in een gesprek achteraf. Hoe u ze opschrijft zonder een technisch document te maken, staat in een programma van eisen schrijven.

Waarom een verbod niet werkt

Sommige organisaties reageren met een verbod: geen AI-hulpmiddelen bij het bouwen van onze software. Dat is begrijpelijk en het werkt niet, om twee redenen.

De eerste is dat het niet te controleren is. AI-ondersteuning zit inmiddels in de ontwikkelomgeving zelf, in het codeplatform en in de gereedschappen die ontwikkelaars al gebruiken. Een verbod betekent in de praktijk dat er niet meer over gesproken wordt, wat u slechter af maakt dan wanneer het gewoon op tafel ligt.

De tweede is dat u er iets goeds mee weggooit. Diezelfde hulpmiddelen zijn uitstekend in het vinden van beveiligingsproblemen in bestaande code, in het schrijven van tests en in het documenteren van wat er is gebouwd. Dat zijn precies de dingen die in projecten blijven liggen. Een leverancier die deze middelen verstandig inzet, levert doorgaans beter werk dan een die het uit principe niet doet.

De vraag is dus niet of het gebeurt maar of er iemand naar kijkt. Dat is dezelfde vraag die u altijd al had, en dezelfde vraag die terugkomt bij het beoordelen van de oplevering: zie software opleveren en accepteren.

Veelgestelde vragen

Gebruikt mijn softwareleverancier AI om mijn software te schrijven?

Vrijwel zeker, in enige vorm. AI-ondersteuning zit inmiddels in de ontwikkelomgevingen en codeplatforms die ontwikkelaars dagelijks gebruiken. De nuttige vraag is niet of het gebeurt, maar hoe het wordt gebruikt en wie de uitkomst beoordeelt voordat die bij u wordt opgeleverd.

Is code die door AI is geschreven minder veilig?

Niet per definitie, maar er is een specifiek aandachtspunt. Modellen zijn goed in het vinden van kwetsbaarheden en aanmerkelijk zwakker in het oplossen ervan: uit onderzoek dat deze maand rondging bleek ongeveer de helft van de voorgestelde beveiligingsoplossingen zelf een kwetsbaarheid te bevatten. Laat daarom expliciet vastleggen dat beveiligingswijzigingen altijd door een mens worden beoordeeld.

Moet ik AI-gebruik verbieden in het contract?

Dat raden we af. Het is niet te controleren omdat de hulpmiddelen in de standaardomgeving van ontwikkelaars zitten, en het betekent in de praktijk vooral dat er niet meer over wordt gesproken. Bovendien gooit u er iets goeds mee weg: dezelfde hulpmiddelen zijn sterk in het vinden van fouten en het schrijven van tests.

Wie is eigenaar van code die door AI is geschreven?

Wat u daarover in het contract afspreekt blijft leidend: de leverancier draagt de rechten aan u over of verleent u een gebruiksrecht, ongeacht hoe de code tot stand kwam. Wat u daarnaast wilt is een vrijwaring, zodat een eventuele claim van een derde over rechten op een stuk code niet bij u belandt.

Wat is een overzicht van componenten van derden?

Een bijgehouden lijst van alle externe bibliotheken en onderdelen die in uw software zitten, met versie en licentie. Dat overzicht heeft u nodig als er ergens een kwetsbaarheid bekend wordt, en om te weten of de licentievoorwaarden verenigbaar zijn met hoe u de software gebruikt. Vraag om een actuele lijst en niet om een momentopname bij oplevering.

Hoe merk ik of de menselijke beoordeling echt gebeurt?

Vraag hoe lang zo'n beoordeling gemiddeld duurt en wat er in de afgelopen maand is teruggestuurd. Een leverancier die concrete voorbeelden kan noemen van wijzigingen die niet door de beoordeling kwamen, doet het waarschijnlijk echt. Een leverancier bij wie alles er altijd doorheen komt, heeft een formaliteit ingericht.

Wordt mijn software hierdoor moeilijker te onderhouden?

Dat kan, en het is het risico dat het minst wordt besproken. Code die snel is geproduceerd en niet is teruggebracht tot wat nodig is, is groter en ingewikkelder dan nodig, en dat betaalt u later terug in onderhoud. Vraag daarom naar documentatie in gewone taal over waarom iets zo is gebouwd, niet alleen over wat er staat.

Verandert dit iets aan de oplevering?

Aan de procedure niet, aan waar u op let wel. Kijk naast werkende functionaliteit ook naar of er tests zijn die iets aantonen, of het overzicht van componenten actueel is, en of de documentatie leesbaar is voor iemand die er niet bij was. Dat zijn de drie dingen die het verschil maken tussen software die u kunt overnemen en software die u vastzet bij één partij.