Who Owns the Prompts You Wrote for a Client?

The engagement ends and the client asks for the prompts. Whether you hand them over depends less on copyright than on what your contract says, and on a distinction almost nobody draws at signing: the prompt text, the technique behind it, the evaluation set that proves it works, and the configuration it runs in are four separate assets. Most agreements treat them as one thing, or say nothing at all, which is how a routine handover turns into an argument.

This is a contracting problem more than a legal one, and it is solvable in a paragraph if you do it before the work starts. What follows is general practice, not legal advice, and the details vary by jurisdiction and by what you signed.

The four assets, and who usually ends up with each

The prompt text itself

The literal words, including the system prompt, the examples and the output format instructions. If you were paid to produce it as a deliverable, this is the piece the client reasonably expects to own, and fighting for it makes you look like you are holding the work hostage.

Worth knowing: whether a given prompt attracts copyright at all is unsettled and fact-specific. A three line instruction is closer to a functional recipe than a creative work; an elaborate system prompt with structured examples sits somewhere else entirely. Because that question is genuinely uncertain, do not build your position on it. Build it on the contract, which you control.

The technique

The general approach: how you structure a classification prompt, the two-pass review pattern you use everywhere, the way you format few-shot examples. This is your craft, and it walks out of the room in your head whether or not anybody signs anything.

Almost no client intends to buy your methods, but a broad work-for-hire clause assigning 'all materials and know-how developed' can read as if they did. That is the clause to narrow, and it is a reasonable thing to ask for, because no client wants a supplier who cannot reuse their own experience.

The evaluation set

The test cases, the labelled examples, the scoring rubric, the record of which prompt versions failed and how. This is the most valuable and least discussed asset in the entire engagement.

The reason is simple. Prompts are cheap to rewrite and go stale with every model release. The eval set is what tells anyone whether a new prompt is better or worse, and it holds the client's own domain knowledge, which is why it usually belongs to them. Say so explicitly, and say who holds a copy, because 'it was on my laptop' is not a handover.

The configuration and scaffolding

Model choice, temperature and sampling settings, retry logic, retrieval setup, any fine-tune or adapter. Where a fine-tuned model exists, name it in the contract on its own line, including who holds the account it lives in and what happens to it at termination. A tuned model attached to your vendor account is a dependency nobody agreed to.

A clause you can propose

Plain language beats clever drafting here. Something in this shape covers the four assets without a negotiation:

Deliverables. On final payment, the Client owns the prompt text,
evaluation datasets, configuration and documentation delivered under
this agreement, together with any fine-tuned model artefacts created
using Client data.

Background IP. The Supplier retains ownership of the general methods,
techniques, prompt patterns, tooling and reusable components used to
produce the Deliverables, and may use them for other clients, provided
they contain no Client Confidential Information or Client data.

Client data. Client data and any material derived from it remain the
Client's, and are not used to train or improve any model except as
expressly agreed in writing.

The middle paragraph is the one to insist on. Without it, a standard assignment clause can leave you unable to reuse a pattern you invented years earlier. The third protects the client and, incidentally, protects you from an awkward question later. Where you are also delivering code, the ownership question there has its own shape, covered in who owns AI generated code.

If you deliver anything creative built on generated material and expect to register it, the disclosure rules matter separately. The US Copyright Office maintains its guidance and reports at copyright.gov/ai, and its 2023 registration guidance for works containing AI-generated material sets out the human authorship requirement and the duty to disclose AI-generated portions when registering.

If the contract is already signed and silent

Do not open with a legal position. Open with what the client actually needs, which is almost never ownership for its own sake. It is usually one of three things: to keep operating without you, to modify the system as their business changes, or to be sure you are not handing their prompts to a competitor.

All three are satisfiable without a fight. Hand over the prompt text and the eval set, document how it works, and offer a written commitment that anything containing their data or business specifics is theirs alone. Keep the general patterns. In practice this is what both sides wanted, and stating it clearly ends the conversation faster than any clause.

Where it does escalate, it is almost always because the client suspects they are being locked in. That suspicion is best defused early, in the proposal, which is why writing an AI project proposal is the right place to say what they will own.

Keep your reusable work separable from day one

The practical protection is not contractual, it is organisational. Keep your general patterns in a library that exists independently of any engagement, with its own history showing it predates the client. Build client work by adapting from it rather than by inventing in the client's repository, and you can demonstrate provenance instead of asserting it.

That is the same discipline as maintaining a reusable prompt library, with an ownership benefit attached. It also makes the handover itself trivial, because the client-specific part is already a distinct set of files rather than something you have to extract under time pressure.

Frequently asked questions

Can I reuse a prompt I wrote for one client with another?

The pattern, generally yes if your contract retains background IP. The specific prompt, generally no, because it usually contains the client's terminology, examples and business rules, which are confidential regardless of who owns the copyright. Strip it back to the structure and rebuild for the new context, which produces better output anyway.

Are prompts protected by copyright?

It is unsettled and depends on the prompt and the jurisdiction. Short functional instructions are weak candidates; long structured system prompts with original examples are stronger ones. Treat the answer as unreliable and rely on your contract and on confidentiality terms instead, which do not depend on how a court would classify the text.

Should I charge more if the client wants full ownership?

Only if they want the methods as well, which is genuinely a different purchase and priced differently. Ownership of the deliverables themselves should be included in the normal fee. Charging extra for the thing they thought they were buying reads as a bait and switch, and it is the fastest way to lose a client who would otherwise have renewed. Related pricing structures are covered across the AI monetization pillar.

Does the client need to know I used AI to write the prompts?

Using a model to help draft prompts is ordinary tooling, much like using an IDE. What matters is disclosure where it affects them: what data leaves their environment, which vendors see it, and what you have agreed about training. That broader question is worked through in should I tell clients I use AI.