# Who owns the AI output: IP and non-compete clauses

[Skip to content](#lm-inhoud)Network/[NL](/en/ip-clausules-concurrentiebeding-ai)EN[Hubhub.llmnet.nlCompare models on task, language, cost and licence.](https://hub.llmnet.nl/en/)[Communitycommunity.llmnet.nlPrompt techniques, patterns and system prompts.](https://community.llmnet.nl/en/)[APIapi.llmnet.nlLLMs in production: rate limits, routing, structured output.](https://api.llmnet.nl/en/)[Consultancyconsultancy.llmnet.nlRolling out AI in an organisation, pilot to production.](https://consultancy.llmnet.nl/en/)[Newsnieuws.llmnet.nlAI developments, explained for the Netherlands.](https://nieuws.llmnet.nl/en/)[Benchmarkbenchmark.llmnet.nlMeasure AI quality yourself, on your own tasks.](https://benchmark.llmnet.nl/en/)[Careersvacatures.llmnet.nlAI roles, salaries and career paths in the Netherlands.](https://vacatures.llmnet.nl/en/)[Learnleren.llmnet.nlAI concepts in plain language, beginner to builder.](https://leren.llmnet.nl/en/)[Guidegids.llmnet.nlRun AI privately on your own Mac, PC, NAS or home server.](https://gids.llmnet.nl/en/)[Directorydirectory.llmnet.nlMapping the AI ecosystem: tools, models, companies.](https://directory.llmnet.nl/en/)[Radarradar.llmnet.nlSignals from X, research and communities for indie developers.](https://radar.llmnet.nl/en/)[Appsapps.llmnet.nlReviews of AI apps and open-source repos, with tips for builders.](https://apps.llmnet.nl/en/)[llmnet.nl — main site](https://llmnet.nl/en/)[](https://x.com/intent/post?url=https%3A%2F%2Fvacatures.llmnet.nl%2Fen%2Fip-clausules-concurrentiebeding-ai&text=Who%20owns%20the%20AI%20output%3A%20IP%20and%20non-compete%20clauses)[](https://www.linkedin.com/sharing/share-offsite/?url=https%3A%2F%2Fvacatures.llmnet.nl%2Fen%2Fip-clausules-concurrentiebeding-ai)[](https://www.reddit.com/submit?url=https%3A%2F%2Fvacatures.llmnet.nl%2Fen%2Fip-clausules-concurrentiebeding-ai&title=Who%20owns%20the%20AI%20output%3A%20IP%20and%20non-compete%20clauses)[](#)[](https://x.com/intent/post?url=https%3A%2F%2Fvacatures.llmnet.nl%2Fen%2Fip-clausules-concurrentiebeding-ai&text=Who%20owns%20the%20AI%20output%3A%20IP%20and%20non-compete%20clauses)[](https://www.linkedin.com/sharing/share-offsite/?url=https%3A%2F%2Fvacatures.llmnet.nl%2Fen%2Fip-clausules-concurrentiebeding-ai)[](https://www.reddit.com/submit?url=https%3A%2F%2Fvacatures.llmnet.nl%2Fen%2Fip-clausules-concurrentiebeding-ai&title=Who%20owns%20the%20AI%20output%3A%20IP%20and%20non-compete%20clauses)[](#)

 
# Who owns the AI output: IP clauses and non-compete clauses

 By Ivo Donker — compiled with AI assistance (Claude & Gemini)

 This article is written for AI engineers, data scientists, machine learning specialists, and software developers who work as employees or on a project basis as freelancers in the Netherlands. Anyone who works daily with large language models, generative AI pipelines, and automated software development notices that traditional employment and service contracts don't quite fit. Classic contracts assume a human author who writes code, designs, or texts starting from a blank page. As soon as generative models are used to generate synthetic data, compute embeddings, fine-tune model weights, or produce tens of thousands of lines of boilerplate code, fundamental legal and contractual gray areas arise.

 In this dossier, we analyze the contractual reality surrounding intellectual property (IP), prompt libraries, reusable toolsets, and non-compete clauses. We examine how Dutch copyright law and case law deal with machine-generated artifacts, which clauses in your employment contract or service agreement are risky, and how you can protect your own toolkit during contract negotiations without sacrificing your professional mobility.

 
## The legal status of AI output under Dutch law

 To understand what an employer or client can contractually claim from you, it must first be established whether AI-generated output is even eligible for intellectual property protection at all. In Dutch copyright law, laid down in the Auteurswet (Copyright Act) and shaped by case law of the Hoge Raad (Dutch Supreme Court) and the European Court of Justice (such as the well-known Infopaq-arrest), a strict requirement applies: a work must be the author's 'own intellectual creation' and bear their 'personal stamp.'

 Pure output that rolls directly out of a neural network after a simple prompt generally has no copyright protection. After all, there are no direct human creative choices in the final expression; the model generates probabilistic sequences of tokens based on statistical patterns in the training data. If an AI engineer instructs a model to write a REST API in Python, no copyright formally rests on those specific generated code blocks, unless the developer makes substantial, creative changes and selections to the end result.

 For an in-depth exploration of the civil-law foundations and the interplay between the European AI Act and property rights, you can consult the dossier on [AI and intellectual property and copyright](https://consultancy.llmnet.nl/en/ai-intellectueel-eigendom-auteursrecht) . This distinction between rights to human-written code and rights to model output is crucial for the way contracts are drafted.

 
## The distinction between input, parameters, weights, and artifacts

 In modern AI development, 'the code' is rarely a single, homogeneous product. A typical AI project consists of at least five different technical components, each of which has a different legal status:

 
 
 
 
 Component | 
 Example | 
 Copyright status | 
 Contractual risk | 
 

 
 
 
 System prompts & templates | 
 Complex prompt chains, constraints, few-shot examples | 
 Potentially protected as a literary work if sufficiently creative | 
 Often claimed as a trade secret or 'employer IP' | 
 

 
 Pipeline code & orchestration | 
 Python code for RAG, chunking, evaluation harnesses | 
 Fully protected by copyright (employer copyright) | 
 Standard ownership of employer/client | 
 

 
 Training & fine-tuning data | 
 Curated domain-specific datasets, JSONL instructions | 
 Database right (substantial investment) or trade secret | 
 Very strictly claimed; confidentiality weighs heavily | 
 

 
 Model weights (fine-tunes) | 
 LoRA adapters, merged model weights | 
 No copyright; protected via contract and confidentiality | 
 Major point of conflict when specialists leave | 
 

 
 Generated output | 
 Generated code, synthesis documents, embeddings | 
 Public domain unless substantially reworked by a human | 
 Employer demands transfer of all derivative results | 
 

 
 
 

 When a contract simply states that "all intellectual property rights to the results of the work belong to the employer," complications arise. If the output is legally not eligible for copyright transfer (because no copyright rests on it), employers try to cover this via confidentiality clauses, contractual appropriation of data files, and license provisions on the underlying weights.

 
## Standard IP clauses in employment contracts dissected

 Article 7 of the Dutch Auteurswet (Copyright Act) governs the so-called employer copyright: when work is performed under an employment relationship and creating certain works is part of the employee's job, the employer is regarded as the maker. In addition, employers apply standard clauses intended to claim every conceivable result for themselves.

 A typical clause in a model contract often reads as follows:

 // Voorbeeld van een brede standaard IP-clausule
"Alle intellectuele en industriële eigendomsrechten, inclusief octrooirechten,
auteursrechten, databankrechten en knowhow, ontstaan tijdens of in verband
met de uitvoering van de arbeidsovereenkomst, dan wel tot stand gebracht met
behulp van bedrijfsmiddelen van de werkgever, komen uitsluitend en onvoorwaardelijk
toe aan de werkgever. Voor zover overdracht bij voorbaat vereist is, draagt de
werknemer deze rechten hierbij over."

 For an AI specialist, this provision contains three specific pitfalls:

 First, the term "in connection with": if you build an open-source evaluation tool for LLMs on your own laptop over the weekend, an employer can argue that this is connected to your daily work as an AI engineer. Second, the claim on "know-how": professional expertise, abstract design patterns, and intuition about which hyperparameter settings work well cannot be transferred, but broad definitions can hinder you in later roles. Third, the handling of personal prompt libraries: scripts and templates you bring along from earlier projects can inadvertently fall under the transfer provision as soon as you enter them into the company's work environment.

 During employment conditions discussions, it's wise to look not only at the base salary but also at the scope of these ownership provisions; read how to approach this strategically in the overview on [negotiating salary for an AI role](https://vacatures.llmnet.nl/en/onderhandelen-over-salaris-ai-functie) to keep contractual flexibility and compensation in balance.

 
## The risk for freelancers and interim AI engineers

 For self-employed AI engineers and interim architects, the situation is even sharper. A freelancer does not fall under the statutory employer copyright of Article 7 of the Auteurswet. Instead, the contractual freedom of the Overeenkomst van Opdracht (service agreement, Book 7 of the Dutch Civil Code) applies. If a service agreement contains no explicit provision on IP transfer, copyright in principle remains with the maker (the freelancer), and the client only obtains an implied license to use it for the intended purpose.

 Clients arm themselves against this with strict transfer provisions requiring that all rights, including source code, prompt constructions, model configurations, and trained adapters, be unconditionally transferred. As a freelancer, you run the risk of 'signing away' generic utility libraries, evaluation scripts, or RAG frameworks that you've developed across multiple jobs to a single client.

 To prevent having to reinvent the wheel with every new assignment, it's necessary to make a clear distinction in your general terms and conditions or in the specific Service Level Agreement between Background IP (your pre-existing tooling, prompt chains, and methodologies) and Foreground IP (the client-specific customization, the domain data, and the specific business logic). Anyone who wants to know more about positioning and contract structures for freelancers will find practical guidance in the guide on [freelancing as an AI specialist and finding assignments](https://vacatures.llmnet.nl/en/freelancen-ai-specialist).

 
## Non-compete clauses in a rapidly evolving AI landscape

 The traditional non-compete clause (Article 7:653 of the Burgerlijk Wetboek, Dutch Civil Code) is intended to protect the employer's business interests: specific trade secrets, unique manufacturing processes, or close client relationships. In practice, however, non-compete clauses are regularly misused to keep scarce technical talent on board.

 In the AI sector, a standard non-compete clause of 12 or 24 months covering all of the Netherlands or the Benelux creates a disproportionately heavy burden. The technological half-life in generative AI is around six to nine months. A model architecture or framework that is the standard today can be outdated within a year. An engineer who isn't allowed to work within their specialism for twelve months falls seriously behind in their expertise and market value.

 Dutch courts test non-compete clauses strictly on the basis of a balancing of interests. An employer cannot simply forbid an employee from working elsewhere as an 'AI engineer' because the market is tight; there must be compelling business requirements, such as knowledge of very specific internal algorithms or direct competitive sensitivity of the product roadmap. Nevertheless, an existing clause creates considerable friction when switching jobs.

 
## The friction in international and remote work

 Many Dutch AI specialists work remotely for foreign scale-ups or American AI labs through arrangements such as an Employer of Record (EoR) or as a direct contractor (B2B contract). This introduces complex conflicts of applicable law.

 American contracts almost always contain extremely far-reaching provisions as standard, such as the Invention Assignment Agreement and strict Non-Compete and Non-Solicitation clauses. Anglo-Saxon contracts often attempt to impose worldwide restrictions and make every idea conceived during the employment relationship the property of the company.

 When you work from the Netherlands, mandatory Dutch labor law partly protects you against unreasonable clauses, provided Dutch law applies to the employment contract. For freelance contracts with foreign parties, however, this protection does not apply automatically. Anyone considering working for a foreign employer would do well to review the guidelines on [remote working in AI and international careers from the Netherlands](https://vacatures.llmnet.nl/en/remote-ai-banen) in order to identify legal complications with foreign jurisdictions in good time.

 
## Practical negotiation strategies for AI contracts

 When you receive a new contract, it's important to proactively propose changes in the area of intellectual property and non-compete restrictions. Below are three concrete adjustments that are customary and defensible in the Dutch market:

 
### 1. Excluding generic professional knowledge and tooling

 Ask for an explicit exclusion of general programming skills, prompt structures, and mathematical techniques. Add an appendix (Schedule) to the contract listing the open-source libraries, personal repositories, and methodologies you already possessed prior to starting employment or the assignment.

 // Voorbeeld van een 'Carve-Out' bepaling voor Background IP
"Buiten de overdracht van intellectuele eigendomsrechten vallen alle generieke
tools, prompt-templates, softwarecomponenten en knowhow die door werknemer/opdrachtnemer
reeds vóór de ingangsdatum zijn ontwikkeld of die algemeen toepasbaar zijn zonder
gebruikmaking van vertrouwelijke bedrijfsinformatie van opdrachtgever (de 'Pre-Existing IP').
Opdrachtgever verkrijgt hierop een niet-exclusieve, royaltyvrije licentie voor intern gebruik."

 
### 2. Narrowing the non-compete clause into a non-solicitation clause

 Propose converting a broad, geographically wide non-compete clause into a specific non-solicitation clause with a limited term (for example, 6 months). A non-solicitation clause prohibits you from working for direct clients or specific partners of your employer, but leaves you free to apply your skills as an AI engineer elsewhere in the same sector.

 
### 3. Permission for open-source contributions and academic publications

 In the AI community, publishing on arXiv and contributing to open-source frameworks (such as Hugging Face, PyTorch, or vLLM) is an important way to maintain your professional reputation. Make sure the contract includes an explicit clause stating that participation in open-source projects on your own time is allowed, provided no confidential company data or proprietary model weights of the employer are leaked.

 
## Case studies from Dutch practice

 To make the theory tangible, we discuss two recognizable real-world situations in which the interpretation of contract clauses had a direct effect on the careers of the specialists involved.

 
### Case A: The AI engineer and his own fine-tuning scripts

 A senior machine learning engineer worked for three years at an e-commerce platform in Amsterdam. During his employment, he developed a modular Python library in his own time for efficiently quantizing and running open source language models locally. For this, he used his own hardware and public datasets.

 When he left for a fintech startup, the former employer invoked the broad IP clause: because the engineer also worked on LLM optimization at his job, the code was allegedly created "in connection with the employment relationship." The case was settled after it could be demonstrated that the commit history on GitHub was exclusively outside working hours and that not a single line of proprietary company code or API access of the employer had been used. This situation underscores the importance of a strict separation between work and private equipment and transparent agreements in advance.

 
### Case B: The freelance data scientist and the domain model

 A freelance data scientist was hired by a Dutch logistics company to build a route optimization model using reinforcement learning. The contract stated that all 'models and weights' became the property of the client. After completing the job, the freelancer wanted to apply a similar optimization architecture at a company in the agricultural sector.

 The logistics client threatened legal action for breach of trade secrets and unauthorized competition. Because the freelancer had not distinguished in the contract between the mathematical architecture (the generic algorithm) and the trained model parameters (based on the logistics data), a lengthy dispute arose. In the end, the freelancer was allowed to reuse the algorithm, but all notebooks and training logs related to the client data had to be deleted. A predefined Background IPclause would have fully prevented this conflict.

 
## Contractual checklist for AI specialists

 Before you sign a new employment contract or interim assignment, it's advisable to go through the following checkpoints step by step:

 
 
- Definition of Results: Is an explicit distinction made between client-specific business logic and generic machine prompts or abstract architectures?
 
- Scope of the transfer: Is the transfer of rights strictly limited to works created within the formal job description and during working hours?
 
- Indemnification for AI output: Does the contract contain a provision indemnifying you as a developer if an external LLM unexpectedly generates infringing code that you integrated in good faith?
 
- Confidentiality vs. portfolio: Is it clearly defined what you may publicly share about the techniques used (for example, in anonymized form on your blog or portfolio)?
 
- Duration and scope of the non-compete clause: Is the non-compete clause limited in time (a maximum of 6 to 12 months), geographically defined, and specifically aimed at direct competitors with an identical product?
 

 Clearly documenting intellectual property and non-compete restrictions is not an expression of distrust, but a necessary condition for a sustainable professional relationship. In a technological field that reinvents itself every month, contractual clarity ensures that you can remain free to innovate, learn, and build.