# Who owns the prompts and evals you build for a client?

> If the contract never names prompts, evals and connectors, the ownership dispute is not avoided, only postponed until handover day.

Original: https://fdetimes.net/en/guides/who-owns-prompts-evals-client-work/

Picture yourself in week six at a logistics client. The repo already holds an eval suite of 400 cases built from real support tickets, 30 prompts, a connector into the ticketing system, and all of it runs on the eval harness library your company uses on every project.

At the review, the client's team lead asks a perfectly ordinary question: when the contract ends, do they get to keep all of it? You realise you don't know the answer. Worse, the contract may not know either.

In this situation the question has arrived six weeks late. You are not a lawyer and do not need to become one. Your job is to understand enough to spot the gap at kickoff, while fixing it is still cheap, and then put the right questions to legal.

## Everything goes into one of two bags

The basic framework is simple. As UpCounsel explains it, background IP is what existed before the project began, and foreground IP is what is developed during the project. Your company's eval harness library is background. The 400 cases built for the client are foreground.

The default rule for the background bag is fairly comfortable. Sprintlaw, a UK law firm writing for AI automation agencies, advises that the contract should state that pre-existing materials remain the agency's unless expressly assigned.

But keeping ownership is only half the story. If the connector you hand over needs your library to run, UpCounsel notes, the contract must make clear whether the client is granted a licence to use that library.

The foreground bag needs a list. Sprintlaw advises defining precisely which deliverables are assigned, naming them specifically, such as scripts, workflows and prompts, rather than a line like "all products of the services". The reason is practical: prompts and evals are new artifacts, and a clause drafted from an old template may not have anticipated them.

In the United States there is an extra trap. Under the definition in 17 U.S. Code § 101, a commissioned work is a "work made for hire" only if it falls into one of the categories the statute lists and both parties have agreed so in a signed written instrument.

So "the client paid, so the client owns it" is not a safe default. You need an explicitly written assignment clause.

**Key point:** Whatever the contract does not name will be argued over on handover day.

## One engagement, four artifacts

Back to the logistics client. Sit down with the repo, put each item in its bag, and you get a table like this:

| Artifact | Bag | Question for legal |
|---|---|---|
| Your company's eval harness library | Background | Is the client licensed to keep using it after the project, and within what scope? |
| 400 eval cases built from real tickets | Foreground, contains confidential information | Who owns it, and may your side retain any version? |
| 30 custom prompts and workflows | Foreground | Does the assignment list name them? |
| Connector into the ticketing system | Hybrid: shared core, custom configuration | Where is the line between the core and the custom part? |

The second row is the hardest. The eval suite is the most valuable thing you produce, because it encodes what "correct" means for this client.

But it is built from their data, and Sprintlaw stresses that the contract should clearly limit reuse of the client's confidential information.

If you want to carry the suite's structure into your next project, agree on it from the start; don't decide it yourself in the final week.

The last row shows why you should separate the code early. If the connector core sits in its own package and the client's configuration in its own module, the IP boundary matches the boundary in the repo. If everything is mixed in one file, no clause will save you at handover.

## The third layer: the model provider's terms

The two parties to the contract are not the whole picture. Sprintlaw warns that third-party AI platform terms may restrict transfer, resale, copying, use for training or later commercialisation. You cannot give the client a right you do not have yourself.

Take Anthropic's commercial terms as an example. Under them, the customer retains all rights to Input and owns Output, and Anthropic may not train models on Customer Content from the services. With an eval suite built from real tickets, this is a detail you can use to reassure the client's security team.

But read the word "Customer" carefully. The terms grant rights to Output to the Customer, so the first step is to check who the Customer is on the account the project uses. If it is not your client, add one more question for legal: by what route in the contract do the rights to Output reach the client?

Watch the feedback clause too: Anthropic states that it may use customer feedback without any obligation to the customer. Sending real eval cases along with a bug report deserves some thought before you press send.

## What to do in week one

Start with an inventory of expected artifacts, written before there is any code: which libraries you bring in, prompts, evals, connectors, runbook documentation. Label each line background, foreground or hybrid. Then mark which lines touch the client's confidential data.

Next, check who the Customer is on the project's API account and read the sections on Input, Output, training and feedback in the provider's terms. Finally, send the table to legal with three questions: does the assignment list name prompts, evals and connectors; does the client have a licence for the existing tools; and what may your side reuse after the project.

The skill also pays off when job hunting. When an FDE posting mentions "scoping" or "SOW", a CV line such as "built the artifact inventory and classified IP with legal at kickoff" shows that you have run an engagement, not merely written code inside one.

## Common mistakes

The most common mistake is treating prompts as trivial configuration that nobody lists. The second is letting internal libraries mingle with client code, so that on handover day delivering the connector means delivering the company's shared tooling too.

The third is copying the whole eval suite into the next project because "it's only tests anyway", when every case in it is the client's confidential data.

The last is subtler: believing IP is a matter for sales and legal. They draft the clauses, but only the people writing the code know what the repo really contains. The question the logistics team lead asked in week six is one you should have asked yourself on day one, and the answer should already be sitting in a four-row table.

**Try this week:**

- Open the repo of your current engagement, list every artifact and label each line background, foreground or hybrid.
- Search your current SOW or contract for the words 'prompt', 'eval' and 'connector'; for any that are missing, send a question to legal.
- Read the Input/Output and feedback sections of your model provider's commercial terms, then check who the 'Customer' is on the project's API account.

## Sources

- [IP Assignment Clauses for UK AI Automation Agencies](https://sprintlaw.co.uk/articles/ip-assignment-clauses-for-uk-ai-automation-agencies/)

- [Understanding Background IP: Key Legal Insights](https://www.upcounsel.com/background-intellectual-property)

- [Pre Existing IP Meaning: Key Insights for Agreements](https://www.upcounsel.com/pre-existing-intellectual-property-rights)

- [17 U.S. Code § 101 - Definitions](https://www.law.cornell.edu/uscode/text/17/101)

- [Commercial Terms of Service](https://www.anthropic.com/legal/commercial-terms)