# AI en intellectueel eigendom: rechten op output

Deel:[𝕏](https://twitter.com/intent/tweet?url=https%3A//consultancy.llmnet.nl/ai-intellectueel-eigendom-auteursrecht&text=AI%20en%20intellectueel%20eigendom%3A%20rechten%20op%20output)[LinkedIn](https://www.linkedin.com/sharing/share-offsite/?url=https%3A//consultancy.llmnet.nl/ai-intellectueel-eigendom-auteursrecht)[Reddit](https://www.reddit.com/submit?url=https%3A//consultancy.llmnet.nl/ai-intellectueel-eigendom-auteursrecht&title=AI%20en%20intellectueel%20eigendom%3A%20rechten%20op%20output)[Facebook](https://www.facebook.com/sharer/sharer.php?u=https%3A//consultancy.llmnet.nl/ai-intellectueel-eigendom-auteursrecht)[Kopieer link](#)

# AI en intellectueel eigendom: rechten op output

Door Ivo Donker — samengesteld met AI-ondersteuning (Claude & Gemini) · Laatst bijgewerkt: 6 augustus 2026

Bij het zakelijk inzetten van generatieve kunstmatige intelligentie ontstaat binnen organisaties snel de vraag wie de rechten bezit op gegenereerde teksten, broncode, afbeeldingen en data-analyses. Waar traditionele softwareontwikkeling en contentcreatie leunen op overzichtelijke auteursrechtelijke kaders, introduceert de toepassing van grote taalmodellen (LLM's) een samenspel van IE-recht, licentievoorwaarden en contractuele afspraken. Veel organisaties veronderstellen onterecht dat het ontvangen van een AI-antwoord automatisch betekent dat zij een exclusief intellectueel eigendomsrecht verkrijgen.

Om juridische en operationele risico's beheersbaar te houden, moeten organisaties afstappen van simplistische aannames over eigendom. Het vraagstuk laat zich het beste ontleden door onderscheid te maken tussen wettelijke beschermingsomvang, contractuele overdracht en operationele beheersing. Dit artikel analyseert hoe rechten rondom generatieve AI-output in elkaar grijpen en welke maatregelen een organisatie moet nemen in de eigen ontwikkel- en beheerprocessen.

## De drie juridische lagen van een AI-systeem

Wanneer een organisatie gebruikmaakt van een LLM of een generatieve AI-toepassing, lopen drie afzonderlijke lagen van intellectueel eigendom door elkaar. Om te bepalen welke rechten waar rusten, moeten deze lagen strikt gescheiden worden beoordeeld.

### 1. Rechten op de trainingsdata

De eerste laag betreft de dataset waarmee een model is getraind. Deze data bestaat uit auteursrechtelijk beschermde boeken, artikelen, code-repositories en webpagina's. De juridische vraag in deze laag richt zich op de rechtmatigheid van het scrapen, opslaan en verwerken van dit materiaal door de modelbouwer. Voor de zakelijke eindgebruiker is dit primair een indirect risico: wanneer de trainingsdata onrechtmatig is verzameld, kan dat via inbreukclaims invloed hebben op de continuïteit van de dienst of de rechtmatigheid van het model zelf.

### 2. Rechten op het model en de gewichten

De tweede laag gevormd door de softwarearchitectuur, de getrainde parameters (gewichten) en de specifieke modelbestanden. Bij propriëtaire modellen rust het intellectueel eigendom hiervan volledig bij de leverancier. Bij open modellen worden de gewichten beschikbaar gesteld onder een specifieke licentie. De gebruiker krijgt uitsluitend een gebruiksrecht op de functionaliteit van de software of de gewichten, maar wordt geen eigenaar van de onderliggende AI-technologie.

### 3. De status van de gegenereerde output

De derde laag is het resultaat dat uit het model rolt na het invoeren van een prompt: de output. Dit is de laag waar organisaties dagelijks mee werken. De vraag welke rechten rusten op deze specifieke uitvoer staat los van wie eigenaar is van het model of wie de rechten op de trainingsdata bezit. Een licentie op een model betekent niet automatisch dat de gegenereerde output IE-rechtelijk beschermd is of dat de gebruiker de enige is die aanspraak kan maken op dat resultaat.

## Eigendom versus contract: wat regelen leveranciersvoorwaarden?

In de praktijk is de vraag "van wie is de AI-output?" zelden een zuivere eigendomsvraag in IE-rechtelijke zin, maar een contractuele afspraak tussen de afnemer en de AI-leverancier. Auteursrecht ontstaat namelijk van rechtswege onder specifieke voorwaarden en kan niet door een leverancier worden "gecreëerd" als de wet daar geen basis voor biedt. Een leverancier kan contractueel wel afstand doen van zijn eigen claims op de uitvoer en eventuele rechten overdragen aan de klant.

De meeste zakelijke SaaS-voorwaarden voor AI-diensten bevatten een bepaling waarin de aanbieder verklaart alle rechten, titels en belangen in de gegeneerde uitvoer over te dragen aan de gebruiker, voor zover die rechten juridisch bestaan. De kern van de zaak zit in die laatste toevoeging. Wanneer een leverancier stelt dat "alle rechten aan de klant behoren", overhandigt hij slechts de rechten die hij zelf kan doen gelden. Als er op de uitvoer volgens de wet geen auteursrecht rust, draagt de leverancier juridisch gezien niets over behalve een contractuele toezegging dat de leverancier de klant niet zal klagen voor het gebruik ervan.

Let op: Een contractuele overdracht van de leverancier aan de klant biedt geen bescherming tegen derden als de output inbreuk maakt op bestaande auteursrechten. Voor de precieze inrichting van commerciële afspraken verwijzen we naar onze gids over [AI-contracten en SLA-onderhandelingen](https://consultancy.llmnet.nl/ai-contracten-en-sla).

Bovendien verschillen voorwaarden sterk per dienstniveau. Bij gratis of consumentengerichte interfaces behouden aanbieders vaak het recht om de ingevoerde prompts en gegenereerde output te gebruiken voor het hernieuw trainen van hun modellen. Bij zakelijke enterprise-abonnementen wordt deze verwerking doorgaans uitgesloten. Het kiezen van de juiste contractvorm is daarom een eerste vereiste bij [het kiezen van een AI-leverancier](https://consultancy.llmnet.nl/ai-leverancier-kiezen).

## Mogen gebruiken versus een exclusief recht hebben

Organisaties halen twee begrippen veelvuldig door elkaar: het recht om een werk te gebruiken en het bezit van een exclusief recht om anderen van dat werk uit te sluiten. Dit onderscheid heeft directe operationele consequenties.

Wanneer een organisatie via een generatieve AI-tool een marketingtekst, een logo-ontwerp of een softwaremodule genereert, staat het de organisatie op basis van de gebruikerovereenkomst vrij om dit resultaat te gebruiken, te publiceren of te verkopen. Dit gebruiksrecht is echter niet hetzelfde als een exclusief auteursrecht. Zonder exclusief recht kan een organisatie een concurrent niet juridisch dwingen op te houden met het gebruiken van een vrijwel identieke tekst of afbeelding.

Dit risico manifests zich doordat AI-modellen deterministisch en statistisch van aard zijn. Twee verschillende gebruikers die bij dezelfde aanbieder een vergelijkbare of identieke prompt invoeren, kunnen outputs ontvangen die inhoudelijk of vormelijk nauwelijks van elkaar verschillen. Omdat de AI-aanbieder aan beide gebruikers hetzelfde gebruiksrecht verleent, ontstaat een situatie waarin meerdere partijen dezelfde content rechtmatig gebruiken zonder dat een van hen aanspraak kan maken op een alleenrecht.

## De rol van menselijke creatieve inbreng

Het internationale en Europese auteursrecht leunt op een centraal staatssysteem: een werk komt pas voor auteursrechtelijke bescherming in aanmerking als het het resultaat is van de eigen intellectuele schepping van een menselijke auteur. Er moet sprake zijn van vrije en creatieve keuzes die tijdens het wordingsproces van het werk zijn gemaakt.

Voor AI-gegenereerde output betekent dit dat puur machinaal gegenereerd materiaal niet door het auteursrecht wordt beschermd. Het louter invoeren van een korte tekstinstructie (prompt) geldt in de regel niet als voldoende creatieve sturing. Een prompt zoals "Schrijf een persbericht over een nieuw softwareproduct" bevat onvoldoende vormgevende elementen; de daadwerkelijke uitdrukking van de tekst wordt immers door het algoritme bepaald.

Er kan pas een auteursrechtelijk beschermd werk ontstaan wanneer de menselijke rol dominant en sturend is. Dit kan op drie manieren vorm krijgen:

- Voorbewerking en sturing: Het vooraf selecteren, structureren en gedetailleerd afkaderen van bronmateriaal waarmee de AI als hulpmiddel werkt.

- Iteratieve selectie en montage: Het uitsturen van tientallen opeenvolgende opdrachten waarbij de menselijke maker steeds specifieke onderdelen kiest, combineert, herschikt en aanpast.

- Nabewerking: Het substantieel menselijk herschrijven, aanvullen of visueel bewerken van de gegenereerde AI-output tot een nieuw, origineel geheel.

De juridische scheidslijn tussen een 'onbeschermde AI-generatie' en een 'met AI ondersteund auteursrechtelijk werk' is niet scherp gedefinieerd. Organisaties moeten er vooralsnog van uitgaan dat ruwe AI-output rechtenvrij is in de publieke ruimte en dat pas door aantoonbare menselijke bewerking beschermbaarheid opgebouwd kan worden. Meer over het maatschappelijke en juridische debat rondom dit onderwerp lees je in het artikel over [AI en auteursrecht op nieuws.llmnet.nl](https://nieuws.llmnet.nl/ai-en-auteursrecht).

## Het risico op inbreuk op rechten van derden

Naast de vraag of een organisatie zelf rechten kan claimen op AI-output, speelt het risico dat de gegenereerde uitvoer onbedoeld inbreuk maakt op de rechten van derden. Omdat taal- en beeldmodellen getraind zijn op miljarden bestaande werken, bestaat het gevaar dat een model patronen, passages of stijlelementen letterlijk of vrijwel letterlijk overneemt.

Dit risico is niet bij alle soorten output even groot. Bij omvangrijke teksten is de kans op een identieke alinea relatief klein, tenzij het trainingsmateriaal een specifieke bron extreem vaak bevatte. Het risico piekt echter bij korte, herkenbare en sterk beschermde vormen:

- Slogans en merkzinnen: Korte, pakkende zinnen die door het model als waarschijnlijke opeenvolging van woorden worden gegenereerd, maar die beschermd zijn als merk of handelsnaam.

- Code-fragmenten: Specifieke algoritmes of functies die letterlijk zijn overgenomen uit open-source projecten met dwingende licentievoorwaarden.

- Beeldstijlen en karakters: Gegenereerde afbeeldingen die kenmerkende visuele eigenschappen vertonen van beschermde merkfiguren of specifieke kunstenaars.

Auteursrechtelijke inbreuk is een objectief gegeven: het feit dat een organisatie niet wist dat de AI-tool een bestaand werk heeft gereproduceerd, ontheft de organisatie niet van aansprakelijkheid wanneer de uitvoer openbaar wordt gemaakt of commercieel wordt geëxploiteerd.

## Vrijwaringen van AI-aanbieders: wat dekken ze wel en niet?

Om zakelijke klanten gerust te stellen, bieden diverse grote AI-leveranciers zogenaamde IP-indemnification of vrijwaringsregelingen aan. Zulke regelingen beloven dat de leverancier juridische kosten en eventuele schadevergoedingen op zich neemt als een klant door een derde wordt aangeklaagd vanwege auteursrechtinbreuk door het gebruik van de AI-output.

Hoewel deze vrijwaringen commercieel aantrekkelijk klinken, moeten organisaties de kleine lettertjes grondig analyseren. Aan deze garanties hangen doorgaans strikte voorwaarden:

Aspect | 
Standaard belofte | 
Contractuele werkelijkheid & Beperkingen | 

Ingebouwde filters | 
Vrijwaring tegen inbreukclaims. | 
Geldt alleen als alle ingebouwde veiligheids- en auteursrechtfilters ingeschakeld bleven. | 

Prompt-restricties | 
Dekking voor generieke uitvoer. | 
Vervalt zodra de gebruiker doelbewust heeft gezocht naar het reproduceren van bestaande werken. | 

Systeemintegratie | 
Schadeloosstelling bij claims. | 
Geldt uitsluitend voor de directe model-output, niet voor het eindproduct waarin de output is verwerkt. | 

Commerciële limieten | 
Volledige juridische dekking. | 
Vaak gecapped tot het totale bedrag dat de klant in de afgelopen 12 maanden aan de dienst heeft betaald. | 

Vrijwaringen bieden een belangrijk veiligheidsnet, maar ze dekken niet de reputatieschade, de kosten van operationele vertraging of het moeten terugtrekken van een reeds gelanceerd product uit de markt. Een organisatie blijft zelf verantwoordelijk voor de risico-afweging.

## Open modellen en licentiestructuren

Bij het gebruik van open modellen (waarvan de modelgewichten lokaal of op eigen cloud-infrastructuur worden gedraaid) geldt een andere dynamiek dan bij propriëtaire SaaS-diensten. Hier bepaalt de softwarelicentie van het model welke rechten en plichten de organisatie heeft.

Het is van cruciaal belang om het onderscheid te begrijpen tussen de licentie op de modelgewichten en de status van de output die met het model wordt gegenereerd:

### Licenties op gewichten

De licentie op de gewichten (zoals een Apache 2.0, MIT, of een aangepaste commerciële licentie zoals de Llama-licentiestructuur) regelt wat een organisatie wel en niet mag doen met de modelbestanden zelf. Denk aan het aanpassen van de architectuur, het herdistribueren van het model, of het inzetten van het model voor commerciële doeleinden boven een bepaald aantal actieve gebruikers.

### Rechten op gegenereerde uitvoer

De meeste open-sourcelicenties leggen geen eigendomsclaims op de gegenereerde data. De maker van het model claimt doorgaans geen rechten op wat gebruikers uit het model halen. Wel kunnen er gebruiksbeperkingen (Acceptable Use Policies) in de licentie verweven zijn. Deze verbieden bijvoorbeeld het gebruik van de output voor specifieke medische, militaire of misleidende doeleinden.

Voor een diepere analyse van de documentatie bij open modellen verwijzen we naar onze gids over [modelkaarten en licenties lezen](https://hub.llmnet.nl/modelkaarten-en-licenties-lezen) op hub.llmnet.nl, evenals het artikel over het [licentiedebat rond open modellen](https://nieuws.llmnet.nl/licentiedebat-open-modellen) op nieuws.llmnet.nl.

## Specifieke risico's bij softwareontwikkeling en broncode

Inzet van generatieve AI bij softwareontwikkeling (via code-assistenten en geïntegreerde LLM's) brengt specifieke juridische risico's met zich mee. Broncode is van nature sterk gestructureerd en onderworpen aan duidelijke licentiemodellen, waardoor inbreuk sneller kan worden vastgesteld.

Het grootste risico bij AI-gegenereerde code is licentiebesmetting. Als een model is getraind op repositories met een zogenaamde 'copyleft'-licentie (zoals GPL of AGPL), en het model genereert een codefragment dat substantieel overeenkomt met die getrainde broncode, kan de vraag ontstaan of de propriëtaire software waarin deze code wordt geïntegreerd eveneens onder die open-sourcelicentie moet vallen.

Om licentiebesmetting en IE-risico's in softwareprojecten te voorkomen, moeten organisaties broncode-beheer niet achteraf controleren, maar inrichten in de ontwikkelstraat:

- Automatische scanning in de CI/CD-pipeline: Zet hulpmiddelen in die gegenereerde code vergelijken met openbare repositories op exacte overeenkomsten en licentiekenmerken voordat de code naar de main branch wordt gemerged.

- Inschakelen van attributie-filters: Configureer AI-code-assistenten zo dat zij suggesties die exact overeenkomen met bekende open-source bronnen blokkeren of voorzien van bronvermelding.

- Scheiding van kern-intellectueel eigendom: Hanteer striktere regels voor de kernalgoritmes van de organisatie en sta het gebruik van generatieve code-assistenten primair toe bij standaard boilerplate-code of het schrijven van geautomatiseerde testen.

## Praktische maatregelen voor de organisatie

Om te zorgen dat het gebruik van AI-tools geen juridische tijdbom wordt onder de IP-portefeuille van een organisatie, zijn concrete operationele maatregelen noodzakelijk. Het gaat erom dat een organisatie altijd kan aantonen hoe content of code tot stand is gekomen.

### 1. Bepaal waar generatieve output mag landen

Niet alle bedrijfsmiddelen vereisen een exclusief auteursrecht. Het is verstandig om binnen de organisatie een helder onderscheid te maken tussen categorieën documenten en media:

- Lage IP-waarde (Ruim gebruik toegestaan): Interne samenvattingen, e-mailconcepten, inspiratiesessies en eerste opzetten voor interne presentaties.

- Middelmatige IP-waarde (Menselijke controle vereist): Externe blogartikelen, documentatie, ondersteunende marketingteksten en routinematige softwarefunctionaliteiten.

- Hoge IP-waarde (Geen of uiterst beperkte AI-generatie): Merknamen, slogans, patentaanvragen, de kern van propriëtaire broncode en visuele merkidentiteiten.

Het vastleggen van deze categorieën vormt een essentieel onderdeel bij het [opstellen van intern AI-beleid](https://consultancy.llmnet.nl/ai-beleid-opstellen).

### 2. Breng een audit trail en provenance-registratie aan

Wanneer een organisatie een auteursrecht wil claimen op een werk dat mede met behulp van AI tot stand is gekomen, moet de menselijke inbreng bewijsbaar zijn. Dit vereist het vastleggen van de 'provenance' (herkomst):

- Sla gebruikte prompts en gegenereerde tussenresultaten op in de projectarchieven.

- Bewaar versies waarin de menselijke bewerkingen, correcties en toevoegingen zichtbaar zijn.

- Gebruik versiebeheersystemen (zoals Git) waarin de geleidelijke opbouw van tekst of code door menselijke ontwikkelaars transparant is vastgelegd.

### 3. Voer periodieke IP-reviews uit op AI-processen

Evalueer op regelmatige basis welke AI-tools binnen de teams worden gebruikt en controleer of de leveranciersvoorwaarden van die tools tussentijds zijn gewijzigd. Leveranciers passen hun algemene voorwaarden en dataverwerkingsbeleid regelmatig aan, wat direct invloed kan hebben op het eigendom en de vertrouwelijkheid van de ingevoerde gegevens.

## Vragen die je aan een jurist stelt

Het inrichten van een verantwoord AI-gebruik is een multidisciplinaire taak. Een AI-consultant of IT-architect helpt bij de technische borging en procesinrichting, maar specifieke risico's vereisen de expertise van een IE-jurist of bedrijfsjurist. Leg de volgende concrete vragen voor aan de juridisch adviseur van de organisatie:

- Bieden onze huidige klantcontracten voldoende dekking als wij opleverproducten (code, advies, designs) opleveren die deels met AI zijn gegeneerd?

- Voldoet onze manier van documenteren en bewerken aan de huidige jurisprudentie om auteursrecht te kunnen claimen op onze eindproducten?

- Zijn de vrijwaringsvoorwaarden van onze enterprise-AI-leveranciers juridisch afdwingbaar onder het toepasselijk recht van onze overeenkomst?

- Hoe verhouden onze AI-activiteiten zich tot de geheimhoudingsplichten (NDA's) die wij met onze zakelijke opdrachtgevers zijn overengekomen?

- Welke specifieke risico's lopen wij bij het verwerken van vertrouwelijke klantdata in de door ons gehoste open-source modellen?

Door deze juridische vragen vooraf te beantwoorden en te verankeren in de operationele workflow, bouwt een organisatie aan een AI-strategie die niet alleen efficiënt is, maar ook juridisch houdbaar op de lange termijn.

## Lees ook

- [AI-contracten en SLA-onderhandelingen voor organisaties](https://consultancy.llmnet.nl/ai-contracten-en-sla)

- [AI-beleid opstellen: van richtlijnen tot handhaving](https://consultancy.llmnet.nl/ai-beleid-opstellen)

- [Een B2B AI-leverancier kiezen: criteria en risico-analyse](https://consultancy.llmnet.nl/ai-leverancier-kiezen)

- [Nieuws & achtergrond: het maatschappelijke debat over AI en auteursrecht](https://nieuws.llmnet.nl/ai-en-auteursrecht)

- [Handleiding: modelkaarten en licenties van LLM's lezen](https://hub.llmnet.nl/modelkaarten-en-licenties-lezen)

- [Achtergrond: het evoluerende licentiedebat rond open AI-modellen](https://nieuws.llmnet.nl/licentiedebat-open-modellen)

llmnet.nl - B2B AI-consultancy en integratie