Broncode-escrow en documentatie-overdracht bij AI-geschreven maatwerksoftware: een checklist

Toen je die maatwerksoftware liet bouwen, ging het gesprek over wat ze moest kunnen. Welke schermen, welke koppelingen, welke rapportages, tegen welke prijs. Terecht. Maar er is een tweede vraag die pas opspeelt als de samenwerking stopt: kun je dan zelf verder? Als je bouwer failliet gaat, zijn tarief verdubbelt, ermee stopt of simpelweg niet meer reageert, wil je niet ontdekken dat de software op papier van jou is, maar dat niemand anders hem kan draaien, begrijpen of aanpassen.

Bij software waar een AI-model een groot deel van de code schreef, is die vraag scherper dan ooit. Niemand aan de bouwkant heeft elke regel met de hand geschreven of gelezen, op puur door een model gegenereerde code rust mogelijk helemaal geen auteursrecht, en de kennis om het geheel te onderhouden zit niet in een mensenhoofd maar verspreid over prompts, specificaties en tooling. De vragen over aansprakelijkheid, eigenaarschap en onderhoud zijn het waarom; deze gids is het afvinkbare stappenplan. Ze is voor de ondernemer, de IT-verantwoordelijke of het team dat maatwerk laat maken, van een klein MKB-bedrijf tot een afdeling van een grotere organisatie, en die niet wil vastzitten aan een enkele bouwer.

Wat je nodig hebt

Voordat je iets vastlegt, verzamel je dit:

• Je contract of offerte, of de bereidheid om opnieuw te onderhandelen. Je onderhandelingsmacht is op zijn grootst vlak voor de handtekening en verdampt daarna.
• Een lijst van wat "de software" precies is. Niet alleen de broncode, maar ook de documentatie, je data, de build- en deploy-instructies, de configuratie en secrets, en de externe licenties of API’s waar de code op leunt.
• Helderheid over wie wat nu beheert: in wiens Git-repository staat de code, en wie beheert de hosting?
• Een budgetkader. Escrow via een gespecialiseerde partij kost jaarlijks geld; zelf de repository beheren kost vooral eigen beheerkennis.
• Waar nodig een jurist voor de akte, want eigendomsoverdracht luistert nauw.

Van afhankelijkheid naar eigenaarschap in zes stappen

Broncode-escrow en documentatie-overdracht zetten zwart op wit dat je jouw AI-geschreven maatwerksoftware ook zonder de oorspronkelijke bouwer kunt draaien en doorontwikkelen. Je legt eigendom vast, deponeert de code bij een onafhankelijke partij als je hem niet zelf beheert, laat die deponering verifiëren en dwingt een complete kennisoverdracht af. Dit regel je zo:

1. Leg broncode-eigendom expliciet vast, met een akte

Auteursrecht ontstaat automatisch bij de maker. Werkt de bouwer als freelancer of bureau, dan blijft dat recht bij hem, ook nadat je de rekening hebt betaald; je krijgt standaard alleen een gebruiksrecht. En het aanleveren van de broncode is geen eigendomsoverdracht: overdracht van auteursrecht op software vereist een schriftelijke akte, een mondelinge of impliciete afspraak volstaat niet. Benoem in die akte expliciet de broncode, de documentatie en de data. Omdat op puur door AI gegenereerde code mogelijk geen auteursrecht rust, leun je niet op dat recht alleen: leg contractueel het eigendom vast en vraag om vrijwaring voor eventuele licentie-inbreuk in de gegenereerde code.

2. Regel escrow voor de code die je niet zelf beheert

Houdt je bouwer de repository en de hosting in beheer, dan is escrow je vangnet. Een escrow-regeling kent drie partijen: je leverancier, een onafhankelijke escrow-agent (een gespecialiseerde partij of een IT-notaris) en jij als afnemer. De leverancier deponeert de broncode, de build-instructies en de documentatie bij die derde. In de overeenkomst leg je de vrijgave-gronden vast: de situaties waarin het materiaal aan jou wordt vrijgegeven, klassiek bij faillissement of wanneer de leverancier het onderhoud staakt. Bij vrijgave krijg je de broncode plus een gebruiksrecht om ermee door te gaan.

3. Kies het juiste type: klassiek versus SaaS-escrow

Draait je maatwerk als geïnstalleerde software bij jou, dan volstaat klassieke broncode-escrow vaak. Draait het als SaaS of in de cloud, dan niet: klassieke escrow houdt geen rekening met je data en de draaiende omgeving, en met alleen de broncode sta je nog nergens als de servers tot de failliete boedel behoren. Voor die situatie bestaat SaaS-escrow: een dubbel depot met zowel de broncode en de infrastructuurbeschrijving als je klantdata, met geautomatiseerde incrementele snapshots en opslag binnen de EU. Zo blijven code en data actueel en, belangrijker, buiten de failliete boedel, zodat ze bij een deconfiture direct beschikbaar zijn.

4. Eis verificatie, niet alleen deponering

Een depot dat nooit is gecontroleerd, is schijnzekerheid: je weet pas of de code compleet en bruikbaar is op het moment dat je hem het hardst nodig hebt. Goede escrow-partijen bieden daarom oplopende verificatieniveaus, van een integriteitscontrole (is het materiaal virusvrij, leesbaar en van het verwachte type) via een materiaal-audit (steekproeven tegen de definities in de overeenkomst) tot volledige verificatie waarbij de daadwerkelijke deployment wordt gesimuleerd en bewezen wordt dat de broncode tot de werkende software compileert. Bij AI-geschreven code weegt dat zwaarder dan ooit, want geen mens heeft de opbouw regel voor regel gecontroleerd. Vraag minimaal om een build- of volledige verificatie, niet alleen om een deponeringsbevestiging.

5. Dwing documentatie- en kennisoverdracht af

Dit is de AI-specifieke laag, en meteen de belangrijkste. Omdat een model de code produceerde en niemand alles naleest, zit de begrijpelijkheid niet vanzelf in het product. Maak de overdracht daarom een concreet op te leveren onderdeel met acceptatiecriteria, geen belofte. Eis minimaal:

• Een architectuuroverzicht en een leesbare README die uitlegt hoe het geheel in elkaar zit.
• Beslisdocumentatie: waarom de belangrijkste keuzes zo gemaakt zijn.
• Een actuele afhankelijkhedenlijst (een SBOM) en een geautomatiseerde testset.
• Een deploy-runbook waarmee een ander de software van nul kan opzetten.
• De AI-context: de specificaties, prompts en projectinstructies plus welke modellen en tools zijn gebruikt, zodat een volgende bouwer, mens of jouw eigen AI-opstelling, verder kan waar deze stopte.

6. Test de overdracht een keer echt

Laat voor de eindafrekening iemand die er niet aan meebouwde, je eigen team of een derde, de repository ophalen en de software puur op basis van de documentatie opzetten en draaien. Lukt dat niet zonder de bouwer te bellen, dan is de overdracht niet af. Deze ene brandoefening is het verschil tussen papieren eigendom en werkend eigendom.

Valkuilen

• De deponering die je nooit verifieert. "Er staat een kopie in escrow" is geen garantie dat die kopie compileert. Laat het bouwen tot werkende software aantonen.
• Broncode-afgifte verwarren met eigenaarschap. Code in handen krijgen is niet hetzelfde als het auteursrecht bezitten, en data in de cloud is niet hetzelfde als data die je mag meenemen. Alleen een akte regelt het eerste.
• Documentatie die "later" komt. Bij handgeschreven code zit kennis nog in iemands hoofd; bij AI-code niet. Zonder overdracht als opleverpunt koop je een black box.
• Escrow afsluiten en vergeten. Een deponering van twee jaar oud is een momentopname van verouderde code. Eis periodieke of geautomatiseerde deponering die met de software meeloopt.
• Alleen op maandprijs kiezen. De goedkoopste bouwer van nu is de duurste als je er over drie jaar niet uit komt. Lock-in is geen ja of nee maar een schaal die je per systeem in kaart brengt en langs drie concrete routes doorbreekt; reken de overstapkosten mee in de keuze. Dat dit geen theorie is, blijkt zodra een investeerder je softwareleverancier overneemt en je exitrechten ineens goud waard worden.

Kant-en-klaar versus maatwerk

Er is geen enkel beste mechanisme; er is het mechanisme dat past bij hoe kritisch en hoe cloud-afhankelijk je software is. Grofweg vier routes, van goedkoop en simpel naar duur en waterdicht:

Voor het grootste deel van het MKB is de goedkoopste route ook de sterkste: word gewoon zelf eigenaar van de repository, leg dat vast in een akte en dwing een echte documentatie-overdracht af. Escrow is de tussenweg wanneer je bouwer de code echt moet houden, bijvoorbeeld omdat het een gedeeld product is. En de zware cloud-continuïteit reserveer je voor software die je omzet direct raakt. Match het mechanisme aan het risico, en betaal niet voor een depot als eigenaarschap volstaat.

Eigenaarschap regel je vooraf

Eigendom is geen alinea die je achteraf toevoegt. Het is een ontwerpkeuze die je maakt voordat de eerste regel code, of de eerste prompt, geschreven is. De software die je vandaag laat bouwen, is pas echt van jou als je hem ook zonder de bouwer kunt draaien, begrijpen en doorontwikkelen. Regel dat als vraag aan de voorkant, niet als noodgreep aan de achterkant, want op het moment dat je het vangnet nodig hebt, is het te laat om het nog te spannen.