You paid for the build, the agent is running in production, and one day your provider tells you that you need to move to their monthly subscription to keep using it. Or worse: you want to change supplier and discover that the code, the instructions and the account access do not follow you. The ownership question almost never comes up when you sign. It comes up at the first disagreement.
This is a legal question, not a matter of trust. An AI agent combines several objects that do not fall under the same regime: code, instructions written in natural language, a document base, business data, hosting accounts and, almost always, a model that belongs to someone else. As long as the contract says nothing, each of those objects stays with whoever produced it.
Key Takeaways
- An AI agent is not a single deliverable: code, prompts, knowledge base, data and accounts follow different regimes, and the contract must treat them separately.
- Under French law, copyright in software starts with the person who wrote it. Transfer to the client is not automatic: it requires a written assignment that defines exactly what is assigned.
- The statutory exception for employees does not apply when you work with an agency or a freelancer: in that case, only the rights explicitly listed in the contract move to your side.
- Owning the agent means holding the code repository, the instructions, the account access and the documentation. A mere right of use does not make you independent.
- A clause granting you in advance everything the provider will produce in the future is weak: the code prohibits the blanket assignment of future works.
An AI agent is not a single deliverable
The first mistake is to talk about "the agent" as one object. An agent in production is an assembly. For ownership purposes, what matters is who holds each part.
The code and the orchestration
This is the easiest part to identify: the program that receives a request, calls a model, triggers your tools and returns an answer. That code is protected by copyright as software, with a specific regime in the intellectual property code. It lives in a repository with a version history, and that repository is what must change hands.
The prompts and instructions
The instructions given to the model are often the most specific asset in the project: business rules, tone, answer format, error cases, guardrails. They do not look like code, but they are written, structured and sometimes several hundred lines long. Older contracts do not mention them at all, and that is where the most unpleasant conversations happen: the provider considers them part of their know-how, you consider them a description of your company.
The knowledge base and the data
An agent connected to your procedures, your offers or your contracts relies on a document corpus. The documents belong to you, but the way they are chunked, indexed and stored may stay with the provider. The question to ask is simple: if I get the raw files back, do I get a usable agent back?
The model, which almost always belongs to a third party
Except in very specific projects, you do not train a model. You call an API, whether from OpenAI, Mistral, Google or an open source model installed on a server. In that case you buy no share of the model: you buy a right of use governed by the vendor's terms, and that right can change in price or scope without your development contract protecting you. So you need to separate clearly what you own (the code, the instructions, the integration), what you have access to (a model endpoint), and what nobody assigns to you (the model weights).
The accounts, the keys and the infrastructure
The last piece, often forgotten: the agent runs on a cloud account, with API keys, a domain name, a database. If those accounts were opened in the provider's name, you do not own your agent, even with a perfect assignment clause. You are renting your own tool.
| Item | Default holder | What you need to obtain |
|---|---|---|
| Code and orchestration | The developer who wrote it | Written assignment of economic rights, repository transferred |
| Prompts and instructions | The provider, if not listed | Explicit inclusion in the assigned deliverables |
| Document base | You for the files, the provider for indexing | Export of the corpus and its configuration |
| Model in use | The model vendor or the open source community | Nothing to assign: manage the dependency and the cost |
| Cloud accounts, keys, domain | Whoever opened them | Opened in the client's name, or written transfer |
What French law says when the contract is silent
French copyright does not work like patent law. There is no registration that makes you the owner: the right arises from the act of creation, in the hands of the author, meaning in principle the natural person who wrote the code.
The employee exception
The intellectual property code provides for automatic transfer of rights to the employer. According to article L113-9 of the French intellectual property code, "the economic rights in software and its documentation created by one or more employees in the performance of their duties or following their employer's instructions are vested in the employer, who alone is entitled to exercise them".
This rule is often invoked by executives who conclude that paying is enough. It does not apply to your situation if the developer is employed by their agency and not by your company. It protects the developer's employer, not that employer's client.
The general rule: a written, defined assignment
With an independent provider, an agency or a services company, you need an assignment contract. And that contract is framed by law. According to article L131-3 of the French intellectual property code, "the transfer of the author's rights is subject to the condition that each of the rights assigned is the subject of a distinct mention in the assignment deed and that the scope of exploitation of the rights assigned is delimited as to its extent and its purpose, as to place and as to duration".
Three practical consequences. First, a vague clause such as "the client owns the deliverables" does not say which rights are assigned: reproduction, adaptation, making available, commercialisation. Second, an assignment with no duration or territory is poorly defined, which opens the door to dispute. Third, the code prohibits the blanket assignment of future works: a clause giving you in advance everything the provider will ever produce for you, including undescribed changes, is not a blank cheque.
On top of that, moral rights remain attached to the author and cannot be assigned. In practice this does not stop you from operating the agent, but it explains why some contracts include a waiver of certain moral rights, and why a serious provider negotiates it instead of ignoring it.
Four contractual set-ups, from most open to most closed
All four are defensible. What is not defensible is signing one while believing you signed another.
| Set-up | What you get | What you cannot do | When it fits |
|---|---|---|---|
| Full assignment | Code, instructions and documentation belong to you | Nothing, subject to third party components | Strategic project, agent central to your business |
| Perpetual licence | Unlimited right of use, no ownership transfer | Resell, modify, hand maintenance to another party | Stable internal tool, controlled budget |
| Subscription licence | Use as long as you pay | Continue after termination | Packaged agent, low specificity |
| Open source with services | You hold the delivered code, under a free licence | Appropriate a third party's existing code | Projects where reversibility comes first |
A full assignment is not always desirable. If your agent is an adaptation of a product the provider maintains for twenty clients, demanding ownership of the core means asking them to sell their business. The right question is not "who owns everything" but "what do I need in order not to be stuck".
Ownership in practice: what must change hands
A signed rights assignment is not enough to make you independent. What decides your real freedom is the list of accesses. This is the list an AI agent project should produce before going live.
- The code repository, with its full history, on an account you control.
- The instructions and their versioning, in the same repository or in an exportable file.
- The test and production environments, opened in your name and billed in your name.
- The model API keys, attached to your own vendor account, so cost and rate limits stay with you.
- The domain name and the business email addresses used for notifications.
- The operations documentation: architecture, dependencies, restart procedure, restore procedure.
- The register of subcontractors and third party services, with their exact role.
A simple test tells you where you stand: ask a third party to take over the agent without contacting the provider. If they cannot, ownership is theoretical. This is what an consulting audit covers before signature, and even more so after two years in operation.
The traps that lose ownership without saying so
The reusable components clause
Many contracts assign the specific deliverables, then reserve for the provider "the generic components, libraries and frameworks" it has developed. The clause is legitimate. The problem is its definition: if your agent's orchestration is described as a generic component, you have assigned the facade and kept the walls.
Fine-tuning and training data
When a model is tuned on your data, a new question appears: who owns the tuned weights? The development contract almost never says, and the model vendor's terms often provide that the tuned model stays with them. Without a written answer, assume you hold the data but not the result, and that the data may feed a shared service.
White-label hosting
An agent presented under your brand may run on the provider's infrastructure, with your users and your data. You then own the brand and the interface, not the service. If the relationship ends, the tool ends.
Undisclosed subcontracting
The provider who signs is not always the one who builds. A subcontracting chain complicates rights traceability: a subcontractor may hold rights it never assigned to its principal, and therefore that the principal cannot assign to you. The assignment clause must flow down at every level, as detailed in our article on the essential clauses of an AI services contract.
The promise of a free handover
"If you leave, we will help you for free." An oral promise, or a clause with no duration or scope, is not an exit plan. Handover is prepared at signature, with a defined restitution format and deadline.
Six questions to ask before signing
- Which items exactly are assigned, and which stay under licence?
- Will the code repository be created on an account I control from the first commit?
- Are the prompts and instructions listed among the assigned deliverables?
- Who opens the cloud accounts and model API keys, and in whose name are they billed?
- What happens if the model we use changes price or disappears?
- In what form do I get the agent back if we stop, and within what delay?
Those six answers fit on one page. The quote that precedes signature should already contain them, and the questions to ask an AI agency help you test consistency between the sales pitch and the contract.
FAQ
If I pay for the development, doesn't the code automatically belong to me?
No. Under French law, copyright in software starts with the person who wrote it, unless the employee transfer rule applies to their employer. With an agency or a freelancer, only a written assignment, with a distinct mention of the rights assigned and a defined scope of exploitation, transfers economic rights.
Can my provider reuse my agent for a competitor?
It depends on what the contract reserves. If the provider keeps ownership of generic components or its technical core, it can reuse them, sometimes with elements close to your configuration. Two safeguards: a sector exclusivity clause and a ban on reusing your data and your instructions.
Who owns the model when the agent calls an API such as OpenAI or Mistral?
Nobody on your side. You hold a right of use governed by the vendor's terms, which may change its prices, its models or its conditions. What you own is the integration code, the instructions and the ability to switch model providers without rewriting the agent.
What happens if the provider shuts down or is acquired?
Without a repository in your name, cloud accounts in your name and operations documentation, you lose the tool. That is why reversibility must be drafted as a continuity clause, with a restitution format (repository, exports, access) and a deadline that applies if the provider ceases trading.
Should I register the code or the trademark?
Registering code with a deposit body (such as APP or e-Soleau in France) proves the date and the content of a creation. It transfers no rights: it records them. Trademark registration protects the name, not the software. The two are complementary, and neither replaces the assignment clause.
Conclusion
Ownership of an AI agent is not decided by a single clause but by three layers: the assignment contract, the list of deliverables, and the real access to accounts and repository. A project can be perfectly executed and leave you with nothing if one of those layers is missing.
Before your next signature, get in writing what comes back to you, what stays under licence, and in what form you recover the whole set. If you want to review a contract under negotiation, or frame a project with these questions from day one, write to us from the contact page.
