AI schreef je maatwerksoftware: 5 contractvragen die je vroeger niet stelde

Toen je voor het laatst maatwerksoftware liet bouwen, ging het gesprek waarschijnlijk over wat het moest kunnen. Welke schermen, welke koppelingen, welke rapportages, tegen welke prijs en welke opleverdatum. Dat is een logisch gesprek, en jarenlang was het ook het juiste gesprek. Alleen klopt de aanname eronder niet meer. Die aanname was dat een mens elke regel code bedacht, begreep en kon uitleggen. Vandaag schrijft een taalmodel een fors deel van die regels mee, en niemand aan de bouwkant leest ze nog allemaal na.

Mijn stelling is simpel en een beetje ongemakkelijk: nu AI meeschrijft aan je maatwerksoftware, verschuift het echte risico van functionaliteit naar aansprakelijkheid, eigenaarschap en onderhoud, en de meeste inkoopcontracten in het MKB stellen die vragen nog niet. Ze specificeren tot achter de komma wat de software moet doen, en zwijgen over wat er gebeurt als er iets misgaat, als je wilt overstappen, of als code onderhouden moet worden die geen mens ooit met de hand heeft geschreven. Het contract wijst nog naar het oude risico.

Waarom de grond onder je contract is verschoven

AI-code is geen randverschijnsel meer. Uit de ontwikkelaarsenquête van 2025 waarin 84 procent van de programmeurs AI-tools gebruikt of dat van plan is blijkt hoe gewoon het is geworden, terwijl in datzelfde onderzoek nog geen derde de juistheid van de output zegt te vertrouwen en bijna de helft die output juist wantrouwt. Dat is de kern van het ongemak: de code gaat massaal de deur uit, maar de mensen die hem produceren geloven zelf niet dat hij klopt.

En dat wantrouwen is niet irrationeel. In een analyse van 470 pull requests vond codebeoordelaar CodeRabbit dat door AI geschreven code ongeveer 1,7 keer zoveel problemen bevat als code van alleen mensen, met driekwart meer logische fouten en tot acht keer zoveel prestatieproblemen. Het gaat dus niet om af en toe een tikfout. Het defect-profiel is anders: de code oogt keurig, compileert, doet in de demo wat het moet doen, en verbergt zijn zwakke plekken beter dan een mens dat zou doen.

Tegelijk is het aansprakelijkheidsrecht net de andere kant op bewogen. De vernieuwde Europese productaansprakelijkheidsrichtlijn behandelt software en AI-systemen uitdrukkelijk als producten, en in Nederland gaat die aanscherping op 9 december 2026 het Burgerlijk Wetboek in, waardoor meer partijen in de keten aansprakelijk kunnen zijn voor schade door een gebrekkig product. De wetgever kiest bewust geen zachte landing voor AI. Wie de baten van de automatisering pakt, draagt straks aantoonbaar ook het risico.

De vijf vragen die het contract nu moet beantwoorden

AI-geschreven maatwerksoftware is software waarvan een deel niet door een mens is bedacht maar door een taalmodel is gegenereerd, en dat verplaatst de contractuele aandacht van de functionaliteit naar vijf vragen over risico en eigenaarschap. Dit zijn de vijf die ik zou stellen voordat ik teken:

• Aansprakelijkheid: wie draait op voor schade door AI-gegenereerde code?
• Eigenaarschap: van wie zijn de broncode en de output, juridisch en praktisch?
• Onderhoud: wie kan code onderhouden die geen mens heeft geschreven?
• Test- en auditgaranties: met welk bewijs toont de bouwer aan dat het klopt?
• Exit: kun je door als de leverancier wegvalt?

Het zijn geen juridische spitsvondigheden. Het zijn de plekken waar de rekening straks valt, en het contract is het enige moment waarop je er nog invloed op hebt.

1. Wie is aansprakelijk als AI-gegenereerde code schade veroorzaakt?

Het standaardantwoord van veel leveranciers is een vrijwaring: de output wordt geleverd "zoals hij is", zonder garantie. Dat was al mager toen mensen alles schreven. Het wordt onhoudbaar nu de bouwer een deel van het werk uitbesteedt aan een model met een aantoonbaar hoger foutpercentage, en het volle bouwvoordeel opstrijkt terwijl hij het volle risico bij jou parkeert. Een leverancier die zo redeneert, verkoopt je het risico met korting.

En de gedachte dat de aansprakelijkheid dan wel bij de modelbouwer ligt, is een luchtkasteel. Net zoals jij de rekening betaalt zodra een AI-agent in jouw naam een fout maakt, staat ook hier de partij die de software op klanten loslaat vooraan. Het contract moet dus niet regelen of AI gebruikt is, maar wie welk deel van dat risico draagt, en met welke verzekering dat is afgedekt.

2. Van wie zijn de broncode en de output?

Bij door mensen geschreven code was het auteursrecht helder geregeld. Bij AI-output is eigendom niet vanzelfsprekend. Eigendom van AI-output ontstaat namelijk alleen bij aantoonbare menselijke creativiteit, niet door een tool te gebruiken, ervoor te betalen of te prompten. Vertaal dat naar een codebase: op de regels die een model puur genereerde, rust mogelijk helemaal geen auteursrecht, en soms zit er materiaal in met een licentie die je niet kent.

Dan denk je eigenaar te zijn van je maatwerk, terwijl je in een juridisch niemandsland staat. Het contract moet daarom twee dingen borgen: dat de code, de data en de documentatie aantoonbaar van jou zijn en niet uitsluitend bij de bouwer berusten, en dat de leverancier je vrijwaart als er ondanks alles licentie-inbreuk in de gegenereerde code blijkt te zitten.

3. Wie onderhoudt code die niemand heeft geschreven?

Maatwerk kende altijd al een verborgen afhankelijkheid: je zat vast aan de bouwer die als enige snapte hoe het in elkaar stak. Goede documentatie loste dat op. AI vergroot precies dit probleem, want het produceert code die werkt zonder dat iemand kan uitleggen waarom hij werkt. Dat is niet toevallig het gebied waar het defect-profiel het slechtst is: dezelfde analyse vond ruim drie keer zoveel leesbaarheidsproblemen in AI-code.

Onderhoudbaarheid is daarmee van een vanzelfsprekendheid tot een contractvraag verworden. "Het werkt" is niet hetzelfde als "het is over twee jaar door een ander te onderhouden". Ik zou in het contract vastleggen dat opgeleverde code leesbaar en gedocumenteerd is, met een menselijke maker die de architectuur kan verantwoorden, niet een stapel gegenereerde bestanden waar bij het eerste echte probleem niemand meer in durft te snijden.

4. Welke test- en auditgaranties krijg je?

Als je de code niet op zicht kunt vertrouwen, en bijna de helft van de makers doet dat zelf niet, dan moet je hem op bewijs kunnen vertrouwen. Dat is een wezenlijk andere vraag dan "is het getest?", waarop het antwoord altijd ja is. De vraag is: laat het testbewijs zien. Welke testdekking, welke security-scan, welke controle op de herkomst en licenties van meegetrokken dependencies.

Dit is waar ik het scherpst zou zijn, omdat het de goedkoopste plek is om een gebrek te vangen. Een fout die je vooraf met een audit vindt, kost een herstelronde. Dezelfde fout die je na 9 december 2026 in productie ontdekt, kan onder de aangescherpte productaansprakelijkheid een schadeclaim worden. Verdediging is hier geen inkoopdetail, het is een ontwerpkeuze die je in het contract afdwingt.

5. Wat gebeurt er bij overdracht of exit?

AI verlaagt de kosten om software te bouwen, maar het verlaagt de kosten om ervan af te stappen niet. Sterker, het verhoogt ze, want onbegrijpelijke code maakt je afhankelijker van de partij die hem produceerde. Wat is vendor lock-in dan anders dan precies dit: vastzitten omdat vertrekken te duur of te ingewikkeld is. Wie wil weten hoe vast hij zelf zit en hoe hij eruit komt, moet dat niet ontdekken op de dag dat de samenwerking eindigt.

Een exit-afspraak is meer dan een export-knop. Het is het recht op de volledige broncode, de data in een bruikbaar formaat, de documentatie, en de vrijheid om met een andere partij door te bouwen. Diezelfde logica geldt als je leverancier zelf verandert: regel je exitrechten nu het nog kan, niet als een vreemde de touwtjes overneemt, want op dat moment is je onderhandelingsmacht nul.

Maar een goede bouwer regel je dit toch niet met wantrouwen?

De sterkste tegenwerping is dat je een goede leverancier niet met een advocaat aan tafel benadert. Vertrouwen is de basis van elke samenwerking, en een dik contract voelt als de bijl aan de wortel daarvan. Ik ben het daar deels mee eens, en toch klopt de conclusie niet.

Het gaat namelijk niet om wantrouwen, maar om timing. Je onderhandelingsmacht is maximaal vóór de handtekening en vrijwel nul erna. Een goede leverancier heeft geen enkel probleem met deze vijf vragen, want hij regelt ze toch al zo. Alleen een leverancier die het risico stilletjes naar jou wil schuiven, gaat steigeren. De vragen zijn dus geen teken van wantrouwen, ze zijn een filter dat het onderscheid meteen zichtbaar maakt.

En de tweede tegenwerping, dat AI-code toch gewoon code is, keert zich tegen zichzelf. Precies omdat je aan de buitenkant het verschil niet ziet, kun je niet meer leunen op de aanname dat er een mens achter elke regel zat die je kunt aanspreken. Wat je niet kunt zien, moet je contractueel afdwingen. Of je nu bouwt of koopt, en of het een kernproces betreft dat maatwerk rechtvaardigt of niet: de vraag is niet langer alleen wat de software doet, maar van wie ze is en wie opdraait als ze faalt.

De handtekening is je enige hefboom

De verleiding is groot om te denken dat AI het inkopen van software eenvoudiger heeft gemaakt. Sneller, goedkoper, minder gedoe. Op het niveau van bouwen klopt dat. Op het niveau van risico is het omgekeerde waar: er is een laag bijgekomen die je niet kunt inspecteren, en de wet legt de rekening daarvoor nadrukkelijk bij de partij die het product levert en gebruikt.

Dat maakt het contract belangrijker dan het ooit was. Niet als juridisch ritueel, maar als het ene moment waarop de macht nog aan jouw kant van de tafel ligt. Stel jezelf bij elk stuk software dat je laat bouwen dezelfde vijf vragen, en wees het meest op je hoede bij de leverancier die ze het liefst overslaat. Want de functionaliteit staat in de demo. Het risico staat in de kleine lettertjes die er nog niet in staan.