Wie eigenaar is van AI-gegenereerde code, hangt af van drie dingen: het ontwerpwerk dat een mens erin heeft gestoken, de voorwaarden van uw AI-tool en de contracten met iedereen die code voor u schreef. Het antwoord telt vooral als een investeerder, een koper, een zakelijke klant of een rechter erop moet kunnen vertrouwen.
Deze gids is bedoeld voor founders en COO’s van producten die grotendeels met AI-codingtools zijn gebouwd, en gaat uit van het Nederlandse en Europese recht. U ziet hoe de auteursrechtregels in de Verenigde Staten, de EU en Nederland zich tot elkaar verhouden en welke vijf vragen over IP en licenties u beantwoordt voordat u geld ophaalt of verkoopt. Daarna volgen drie vastleggingen die een eigendomsclaim onderbouwen, en wanneer u een advocaat nodig hebt in plaats van een technische review. De gids hoort bij onze gids over AI-gebouwde producten veilig lanceren. De juridische positie wordt in algemene termen uitgelegd; laat contracten en garanties toetsen door een advocaat.
TL;DR
Behandel eigendom van een AI-gebouwd product als iets wat u aantoont, niet als iets wat u aanneemt. Auteursrecht dekt alleen de delen die een mens heeft gemaakt. De voorwaarden van uw AI-tool bepalen welke rechten u op de output krijgt, en contracten bepalen of de rechten van medewerkers, freelancers en bureaus bij uw bedrijf terechtkwamen. Controleer alle drie vóór een investeringsronde, verkoop of groot klantcontract.
- Auteursrechtregels: het Amerikaanse recht vereist een menselijke maker (Thaler v. Perlmutter, 2025), en de Europese Softwarerichtlijn 2009/24/EG beschermt een programma alleen als het een eigen intellectuele schepping van de maker is. Menselijk ontwerp en menselijke aanpassingen kunnen beschermd zijn; code zonder die inbreng waarschijnlijk niet.
- Vijf vragen over IP en licenties: voorwaarden van AI-tools, bewijs van menselijke inbreng, open-sourcelicenties, schriftelijke overdracht door freelancers en bureaus, en vertrouwelijke invoer in prompts.
- Drie eigendomsvastleggingen: een IP-register, een licentiescan die u exporteert als software bill of materials (SBOM) in SPDX of CycloneDX, en de geschiedenis van menselijke ontwerp- en reviewbesluiten.
- Advocaat of technische review: een advocaat stelt IP-overdrachten en garanties op; een technische review stelt vast wat de codebase bevat en welke licenties gelden.
Wie is eigenaar van AI-gegenereerde code?
Eigendom van AI-gegenereerde code rust op drie lagen. Auteursrecht dekt alleen de delen die een mens heeft gemaakt. De voorwaarden van de AI-tool bepalen welke rechten de leverancier u op de output geeft. Contracten met medewerkers, freelancers en bureaus bepalen of hun rechten naar uw bedrijf zijn gegaan, en een gat in één laag verzwakt de hele eigendomsclaim.
Auteursrecht is het recht om een werk te verveelvoudigen, te wijzigen en in licentie te geven, en software is zo’n werk. Het ontstaat automatisch, maar alleen voor wat een mens heeft gemaakt. De voorwaarden van de AI-tool zijn een overeenkomst tussen uw bedrijf en de leverancier. Volgens de EU IP Helpdesk geldt in standaard toolvoorwaarden de gebruiker als rechthebbende op de output, met het advies de voorwaarden per tool na te lezen. Een overeenkomst kan de rechten doorgeven die de leverancier heeft, maar geen auteursrecht scheppen waar de wet dat niet toekent.
De derde laag gaat over mensen. Code van medewerkers, freelancers, bureaus en de founders zelf is alleen van het bedrijf als een arbeidsrelatie of een getekend contract dat zo regelt. “We hebben het met AI gebouwd, dus het is van ons” is daarom geen volledig antwoord. Een investeerder heeft een antwoord nodig dat noemt welke delen mensen ontwierpen, welke toolvoorwaarden golden en wie de IP-overdrachten tekende.
Is AI-gegenereerde code auteursrechtelijk beschermd? VS, EU en Nederland vergeleken
AI-gegenereerde code is alleen auteursrechtelijk beschermd waar een mens de creatieve keuzes maakte. Code die een machine zonder die inbreng produceerde, is in de Verenigde Staten, de EU en Nederland waarschijnlijk niet beschermd; tabel 1 toont de juridische toets achter elk antwoord.
| Rechtsstelsel | Juridische toets | Belangrijkste bron | Wat het betekent voor uw codebase |
|---|---|---|---|
| Verenigde Staten | Een menselijke maker is vereist. Prompts alleen zijn niet genoeg; menselijke selectie, ordening of aanpassing kan beschermd zijn. | Rapport Part 2 van het US Copyright Office (29 januari 2025); Thaler v. Perlmutter, D.C. Circuit (18 maart 2025) | Alleen de door mensen gemaakte delen zijn te registreren, en AI-gegenereerd materiaal moet worden gemeld. |
| Europese Unie | Een programma is beschermd als het oorspronkelijk is “in die zin dat het een eigen schepping van de maker is” (eigen vertaling). | Softwarerichtlijn 2009/24/EG, artikel 1, lid 3; HvJ EU Infopaq (C-5/08) | Bescherming hangt af van menselijke creatieve keuzes die u kunt documenteren. |
| Nederland | Computerprogramma’s zijn beschermde werken onder de Auteurswet, die de Europese oorspronkelijkheidstoets toepast. | Auteurswet, artikel 10, lid 1, onder 12; Richtlijn 2009/24/EG | Dezelfde toets als in de EU; Nederlandse contractregels bepalen wie de rechten op beschermde code heeft. |
Het Amerikaanse recht is het verst uitgewerkt. In Thaler v. Perlmutter oordeelde het D.C. Circuit op 18 maart 2025 dat de Copyright Act een menselijke maker vereist; het Supreme Court weigerde de zaak op 2 maart 2026 in behandeling te nemen. Het hof voegde toe dat werken die met hulp van AI zijn gemaakt niet zijn uitgesloten. Het rapport van het Copyright Office van januari 2025 trekt de grens: output is beschermd als een mens voldoende van de expressieve elementen bepaalde, via selectie, ordening of aanpassing, maar niet via prompts alleen.
In de EU beschermt de Softwarerichtlijn een programma dat een eigen intellectuele schepping van de maker is, zonder andere criteria. Geen rechter heeft de grens tussen AI-ondersteunde en AI-gegenereerde software nog getrokken: een analyse van advocatenkantoor Dreyfus uit juni 2026 vond geen rechtspraak over software die volledig door AI is geschreven. Zolang die uitspraak er niet is, komt het praktische antwoord overeen met het Amerikaanse: bescherming volgt de menselijke creatieve keuzes die u kunt aantonen.
Code die niet auteursrechtelijk beschermd is, kan wel waarde hebben. Blijft die code geheim, dan kan het een bedrijfsgeheim zijn onder Richtlijn (EU) 2016/943, mits de code handelswaarde heeft omdat ze geheim is en het bedrijf redelijke maatregelen nam om haar geheim te houden.
Vijf vragen over IP en licenties voordat u verkoopt of geld ophaalt
Vijf vragen dekken de IP- en licentiekwesties van een AI-gebouwd product, elk gekoppeld aan één ding dat mis kan gaan: rechten op de output, bewijs van makerschap, licenties van derden, overdracht door bijdragers en invoer in AI-tools. Deze indeling is van deze gids, geen juridische categorie, en elke vraag eindigt met wat u uw developer of advocaat vraagt.
Voorwaarden van AI-tools: wie heeft de rechten op de output
De voorwaarden van uw AI-tool bepalen welke rechten u krijgt op de code die de tool genereert. Controleer voor elke tool die aan het product heeft gewerkt wie de rechten op de output heeft, en of uw prompts en code de modellen van de leverancier mogen trainen. Controleer ook of uw abonnement een IP-vrijwaring bevat, en onder welke voorwaarden.
Iemand heeft deze voorwaarden geaccepteerd, soms op een persoonlijk of gratis account in plaats van een bedrijfsaccount. Voorwaarden verschillen per abonnement en veranderen in de tijd, dus bewaar de versie die gold toen de code werd geschreven. Vraag: “Met welke AI-tools en abonnementen is onze code geschreven, en onder wiens account?”
Menselijke inbreng: bewijs van wie wat ontwierp
Auteursrecht beschermt de delen van AI-ondersteunde code die een mens heeft gemaakt: de architectuur, de keuze en ordening van onderdelen en wezenlijke aanpassingen aan gegenereerde code. Zonder vastlegging van dat werk kan een bedrijf mogelijk niet aantonen dat enig deel van zijn code beschermd is.
Prompts alleen tellen niet mee in de benadering van het US Copyright Office, dus de vastlegging moet ontwerp- en bewerkingswerk laten zien. Commitgeschiedenis, pull-requestreviews en ontwerpnotities kunnen dat leveren als ze vermelden wie elke wijziging deed. Vraag: “Kunnen we laten zien waar een mens de code ontwierp, koos of aanpaste?”
Open-sourcelicenties: verplichtingen die met gegenereerde code meekomen
AI-codingmodellen zijn getraind op grote hoeveelheden openbare code, en gegenereerde code kan overeenkomen met code die onder een open-sourcelicentie is gepubliceerd. Is dat zo, dan kunnen de voorwaarden van die licentie op uw product van toepassing zijn, van het behouden van een copyrightvermelding tot het beschikbaar stellen van uw eigen broncode.
Permissieve licenties zoals de MIT-licentie vereisen dat de copyright- en toestemmingsvermelding in kopieën van de software blijft staan. Copyleftlicenties zoals de GNU GPL verplichten u broncode te leveren als u software verspreidt die op GPL-code is gebaseerd. De GNU AGPL breidt die plicht uit naar gebruikers die de software via een netwerk benaderen.
Amerikaanse rechters toetsen deze vragen nog. In Doe v. GitHub bevestigde het Ninth Circuit op 16 september 2026 de afwijzing van een DMCA-claim, terwijl de contractclaims over open-sourcelicenties nog lopen. Vraag: “Heeft iemand onze code gescand op overeenkomsten met open-sourcelicenties?”
Freelancers en bureaus: rechten schriftelijk overgedragen
Onder de Auteurswet geldt de werkgever als maker van werken die een werknemer maakt als het maken van zulke werken bij zijn taak hoort, tenzij partijen iets anders afspreken (artikel 7). Een freelancer of bureau houdt het auteursrecht, tenzij het schriftelijk en bij akte aan u is overgedragen (artikel 2). Het gebruik van AI-tools verandert niets aan wie moet tekenen.
Hetzelfde geldt voor code die een founder schreef voordat het bedrijf bestond, of zonder arbeidsovereenkomst met het bedrijf. Een factuur of chatafspraak draagt geen auteursrecht over; een getekende overdracht of IP-clausule wel. Dat contract kan ook vastleggen of de bijdrager AI-tools mag gebruiken, op welke accounts, en wie het risico draagt als code overeenkomt met code onder een licentie. Vraag: “Hebben we getekende IP-overdrachten van elke freelancer en elk bureau dat code schreef?”
Vertrouwelijke invoer: code en gegevens in prompts
Tenzij een AI-tool op uw eigen infrastructuur draait, gaat wat u erin plakt naar de systemen van de leverancier. Klantcode, inloggegevens en persoonsgegevens in prompts kunnen geheimhoudingsafspraken en de AVG (GDPR) schenden, en de bescherming als bedrijfsgeheim verzwakken.
Een schriftelijke regel over wat in prompts mag, en welke tools en accounts zijn goedgekeurd, is een van de redelijke maatregelen waarop bescherming als bedrijfsgeheim onder Richtlijn (EU) 2016/943 steunt. Verwerkt de leverancier persoonsgegevens namens u, dan vereist AVG-artikel 28 een verwerkersovereenkomst; AVG voor startups behandelt die plichten. Vraag: “Wat mogen we in AI-tools plakken, en staat dat op papier?”
Kunt u deze vijf vragen nog niet beantwoorden vanuit vastleggingen, dan kan een technische review de feiten vaststellen. Een AI-built product review kijkt naast beveiliging en data naar onderhoudbaarheid en eigenaarschap van de code, en levert bevindingen met onderbouwing en een geprioriteerd actieplan voor uw advocaat.
Wat investeerders en kopers vragen over door AI geschreven code
Investeerders en kopers willen bewijs dat het bedrijf eigenaar is van zijn code of die mag gebruiken, en dat er na de deal geen licentie- of andere claim van derden opduikt. In een investerings- of aandelenkoopovereenkomst kan dat bewijs worden gevraagd via IP-garanties die de founders tekenen, met bekende uitzonderingen in een disclosure.
Due diligence toetst die garanties: wie schreef de code, onder welke contracten, welke open-sourcecomponenten zitten erin en hoe werden AI-tools gebruikt. Een onbeantwoorde vraag kan een disclosure worden, een voorwaarde vóór closing of een punt in de prijsonderhandeling. Onze gids over technical due diligence legt uit hoe investeerders een AI-gebouwd product als geheel beoordelen.
Eigendom van een AI-gebouwd product vastleggen
Drie vastleggingen maken van een eigendomsclaim bewijs: een IP-register, een licentiescan die u exporteert als software bill of materials, en een geschiedenis van menselijke ontwerp- en reviewbesluiten. Samen laten ze zien wie de code schreef, onder welke voorwaarden en met welke componenten van derden.
Houd een IP-register bij voor de codebase
Een IP-register is één document met elke repository, elke bijdrager met zijn contract en IP-clausule, de gebruikte AI-tools en abonnementen, en de diensten van derden waarop het product draait. Het beantwoordt de vraag naar de chain of title: hoe de rechten op elk deel van de code bij uw bedrijf terechtkwamen.
Werk het register bij als er een bijdrager, repository of AI-tool bijkomt, en koppel elke regel aan het getekende contract. Een register dat vanaf het begin is bijgehouden, kunt u zo overhandigen; een register dat tijdens een investeringsronde ontstaat, moet uit e-mails worden samengesteld.
Voer een licentiescan uit en bewaar het rapport
Een licentiescan gebruikt een SCA-tool (software composition analysis) om de open-sourcecomponenten in uw code en hun licenties op te sommen. Exporteer het resultaat als software bill of materials (SBOM) in een standaardformaat zoals SPDX of CycloneDX, en bewaar één rapport per release.
Een dependencyscan toont alleen de packages die uw project declareert. Codefragmenten die in uw eigen bestanden zijn gekopieerd, vragen om een snippetscan, dus vraag uw developer welk type scan is gedraaid. Een code audit-rapport laat zien hoe zulke bevindingen met onderbouwing en prioriteit worden vastgelegd.
Leg menselijke ontwerp- en reviewbesluiten vast
Architectuurbesluiten (architecture decision records), pull-requestreviews en commitgeschiedenis laten zien waar mensen de code ontwierpen, kozen en aanpasten. Die vastleggingen zijn het bewijs voor de menselijke inbreng die auteursrecht beschermt.
Een architecture decision record is een korte notitie van één ontwerpbesluit, de overwogen opties en de reden voor de keuze. Een verplichte, benoemde reviewer voordat gegenereerde code in de hoofdbranch komt, voegt aan elke wijziging een gedateerde vastlegging van menselijke review toe.
Wanneer u een advocaat nodig hebt en wanneer een code review volstaat
Een advocaat stelt IP-overdrachten, AI-gebruiksclausules en investeerdersgaranties op of toetst ze, en adviseert bij geschillen. Een technische review stelt de feiten vast waarop die documenten steunen: wat de codebase bevat, welke licenties gelden en waar vastleggingen van menselijke inbreng ontbreken.
| Taak | Advocaat | Technische review |
|---|---|---|
| IP-overdrachten en AI-gebruiksclausules opstellen of toetsen | Ja | Nee |
| IP-garanties en disclosures voor een deal schrijven | Ja | Levert de feiten |
| Open-sourcecomponenten en hun licenties in kaart brengen | Interpreteert licentieplichten | Ja |
| Gaten in commit- en reviewgeschiedenis vinden | Nee | Ja |
| Adviseren bij een geschil met een bijdrager of leverancier | Ja | Levert bewijs |
De twee werken na elkaar: de review levert bevindingen, en de advocaat vertaalt die naar contractwijzigingen, disclosures of een onderhandelingspositie. Een AI code audit dekt de technische kant; die vervangt geen juridisch advies over uw contracten.
Hoe Sunbytes vaststelt wat uw codebase bevat
IP-garanties zijn maar zo betrouwbaar als de feiten erachter, en een advocaat leest die feiten niet uit een contract. Sunbytes reviewt AI-gebouwde producten om vast te stellen wat de code bevat en waar vastleggingen ontbreken, zodat uw advocaat en investeerders werken met bevindingen in plaats van aannames.
De AI-built product review beslaat vijf gebieden: beveiliging en data, code en architectuur, betrouwbaarheid en kritieke flows, deployment en beheer, en onderhoudbaarheid en eigenaarschap van de code. U krijgt heldere bevindingen met onderbouwing, een geprioriteerd actieplan en een technische overdracht waarmee uw developers verder kunnen. Toegang tot uw code valt onder het ISO 27001-gecertificeerde informatiebeveiligingssysteem van Sunbytes, met klantgovernance vanuit Nederland, 15+ jaar ervaring in softwareontwikkeling en 300+ opgeleverde projecten. Sunbytes geeft geen juridisch advies.
Staat er een investeringsronde, verkoop of groot klantcontract op de planning, bespreek dan met ons de scope van een review van uw codebase. We bepalen de scope per situatie.
