Quick Answer
List background and third-party assets in a schedule, define the project deliverables, and choose a license or signed assignment with an explicit transfer trigger. Confirm deployment, maintenance, training reuse, and termination rights across the full contract set.
An AI/ML statement of work should identify the assets the engineer brings, the deliverables the client receives, and the rights that continue after delivery. Separate those decisions before work starts so a repository handoff does not leave ownership, reuse, or third-party permissions ambiguous.
Use three parts: background assets, project deliverables and transfer mechanics, then future-use permissions. Read the SOW together with the main agreement and any incorporated schedules, including their order of precedence.
Part 1: Identify background assets#
Set the ownership split before kickoff, not after the first commit. In this layer, you identify what you already own, list it in Exhibit A, license only the use the client actually needs, and keep a clean evidence trail.
Lock down background IP before the SOW starts#
Under U.S. copyright law, copyright transfers generally require a writing signed by the owner or authorized agent. For commissioned work, work-made-for-hire treatment requires both a qualifying statutory category and a signed agreement; standalone software is not one of the nine listed categories. Use explicit assignment wording when that route is appropriate. Delivering files does not itself transfer copyright. A background-IP schedule is a practical drafting tool, not a statutory form.
List what you bring in before work starts: code libraries, model-related assets, evaluation harnesses, dataset curation scripts, prompt templates, and internal tooling. Then pair Exhibit A with a nonexclusive license limited to the use the client actually needs for the project deliverables.
| Asset type | Background IP (you retain) | Project deliverables (client rights as contracted) |
|---|---|---|
| Code | Prebuilt auth, ETL, evaluation, or inference libraries | Repo components created specifically for this engagement |
| Models | Pre-existing tuning workflows or prior checkpoints | Client-specific configured or trained model deliverable, if explicitly included |
| Datasets | Reusable cleaning scripts or compilation methods | Client-specific labeled dataset or output package named in scope |
| Prompts | Reusable prompt templates and test patterns | Final prompt set delivered as a contracted artifact |
| Tooling | Internal notebooks, deployment helpers, benchmark harnesses | Packaged tool or interface listed as a deliverable |
Draw the reuse boundary in plain language#
Say it directly: the client gets the artifacts and rights named in the SOW, not your methods, templates, or general know-how unless the contract explicitly says otherwise. Copyright protection does not extend to ideas, procedures, processes, systems, or methods of operation. If you also want trade secret protection for reusable methods, you need confidentiality controls and reasonable secrecy measures.
Your version-control history should support that boundary. Keep the pre-project repo state, preserve commit history, and retain both author date and commit date metadata. That record is not complete legal proof on its own, but it is useful as provenance support if ownership is disputed.
Before signing, confirm that:
- Exhibit A names each background asset in plain English.
- The license is nonexclusive and limited to project use.
- Deliverables are listed separately from background IP.
- Repository history and timestamps are preserved.
If the client resists an attachment, use a practical fallback: "Let's add a one-page schedule of pre-existing materials so there is no confusion about what is licensed versus what is being delivered."
You might also find this useful: A Guide to the Statement of Work (SOW) for a SaaS Development Project.
Part 2: Define deliverables and transfer terms#
Once you have fenced off what you already own, define exactly what this engagement creates. Write this section so a third party can see what is required, when it applies, and who is responsible. If a reader has to infer the key terms, the clause is still too loose.
The practical standard here is specificity. The obligations should appear in the agreement, carry legal effect, and be clear enough to audit. Generic wording can sound reassuring, but it usually leaves responsibility blurry.
Test the grant against one concrete deliverable#
For a hypothetical classifier project, the schedule might reserve the engineer’s existing evaluation library, identify a third-party base model under its own license, and assign project-specific API code after cleared payment. The client receives an agreed license to embedded background components so it can run and maintain the delivered service. List the model version, training-data permissions, tuning artifact, and deployment documentation separately. If final payment is delayed, an interim evaluation license can permit acceptance testing without silently authorizing production use; the signed agreement must define that boundary.
Choose wording that reduces ambiguity#
Use wording that names the subject, scope, and trigger instead of relying on labels alone. Keep both IP and security obligations explicit enough that a reviewer can verify them in the signed agreement.
| Wording style | Example pattern | Ambiguity to fix |
|---|---|---|
| Generic promise wording | "We will keep your data safe." | Too vague for audit: no defined duty, timing, or verification method. |
| Specific obligation wording | "Supplier must follow the SOW security and IP terms, notify security breaches within a defined window (for example, 24 or 72 hours), and provide audit evidence on a defined cadence (for example, annually)." | Still incomplete if scope and evidence format are not explicitly listed. |
Define the terms in the same section so a reader does not have to guess what the obligations mean.
Define each obligation class separately#
Instead of one blanket sentence, define each obligation class in plain language.
| Obligation class | What to define in the SOW |
|---|---|
| IP terms | The specific deliverables covered by the IP language and any explicit exclusions. |
| Security requirements | Concrete data protection, confidentiality, and IP protection duties. |
| Breach notification | The reporting window for security incidents (for example, 24 or 72 hours). |
| Verification method | Whether you have a right to audit, require independent reports, or both. |
| Verification cadence | How often verification is required (for example, annually). |
For each definition, point to the exact agreement section or schedule so you can audit it later.
State sequence and checkpoints, not just the end state#
Do not stop at broad outcomes. The clause should answer three questions in order:
- What obligations apply to the engagement.
- When and how incident reporting must happen.
- What evidence will be used to confirm compliance.
If the engagement touches hosted systems or client data, keep the surrounding duties just as specific. Write notice timing as a defined window and set an evidence cadence, instead of leaving both as generic promises.
Handle security verification with a short schedule#
Avoid one-line blanket statements. Use a short schedule a reviewer can scan quickly:
| Schedule item | What to specify |
|---|---|
| Covered scope | Covered suppliers, systems, or services. |
| Incident notice | Breach-notification window. |
| Verification right | Audit right and/or independent report requirement. |
| Evidence timing | Evidence cadence. |
| Agreement link | Signed-agreement reference for each duty. |
If you want a deeper breakdown of wording choices, Work for Hire vs. Assignment of Rights: A Freelancer's Guide to Owning Your IP is a useful companion. Before you finalize assignment language, run your draft through this SOW generator to pressure-test ownership scope and review checkpoints.
Part 3: Agree future use and AI-specific risks#
Once the transfer mechanics are clear, the next risk is post-delivery use. Your SOW should state three things plainly: what the client can do without asking, what requires your written consent, and what is prohibited for models, code, prompts, and evaluation assets.
If the client only needs to run what you delivered, grant a nonexclusive license for operational use rather than labeling it as a transfer. A nonexclusive license is not a copyright ownership transfer, and handing over files or repo access does not transfer copyright by itself. If you want assignment or an exclusive grant, keep it in signed contract language in the SOW/MSA set.
Write future-use rights as separate permissions#
Do not rely on implied intent. Use direct clauses that separate the permission, the limit, and the fallback if ownership changes hands:
- Usage restriction: client use is limited to the operational purpose defined in the SOW.
- Reservation of rights: you keep background technology, methods, know-how, and anything not expressly assigned or licensed.
- License-back: if ownership transfers to the client, you still need a separate nonexclusive right to use limited, redacted samples for portfolio or case-study use.
- Post-delivery responsibility: negotiate acceptance, support, warranties, and liability limits separately; handoff does not automatically end all obligations.
Specify whether the client may retrain, fine-tune, benchmark, or reuse prompts and evaluation assets for successor models. These are proposed contractual limits, not an automatic restriction that follows from handing over a model. If deliverable rights are assigned outright, an intended reuse restriction must be separately agreed and consistent with that assignment.
| Use category | Baseline rule | Who needs permission | Where to document in the SOW |
|---|---|---|---|
| Client operational use | Allowed only for the stated business purpose and operating scope | No extra permission if use stays in scope | IP grant/assignment clause + "Permitted Operational Use" field |
| Model-development reuse | Proposed exclusion unless the signed rights package permits retraining or other reuse | Permission as required by the agreed restriction, not an automatic veto after assignment | Usage Restriction / Prohibited Use clause + reuse schedule |
| Portfolio or marketing reuse | Treat as excluded unless expressly granted after transfer | You need client permission via license-back | License-Back section + confidentiality/redaction terms |
Before signing, check that one clause clearly answers each row in that table. If not, the rights package is still ambiguous.
Split liability into three buckets#
To keep risk allocation clear, split it into three separate buckets:
| Bucket | Scope |
|---|---|
| Code warranty | Project-created code you authored, or properly included, and material conformance to acceptance criteria at delivery. |
| Third-party component risk | Schedule third-party components and avoid promising warranties broader than upstream terms. |
| Post-handoff output use | Client is responsible for deployment choices, prompts, review controls, and outputs after acceptance. |
For third-party components, schedule them and avoid promising warranties broader than upstream terms. For example, Apache-licensed components are provided "AS IS," and extra promises can shift indemnity burden back to you.
Cross-border fallback checklist#
For cross-border deals, keep this checklist short and practical in your drafting notes:
- Specify governing law, dispute forum, and required transfer formalities for the relevant jurisdictions.
- Identify the controller and processor roles where GDPR applies. A processor needs prior specific or general written controller authorization to engage a subprocessor.
- Agree portfolio permission and redaction rules; a license-back does not override confidentiality or third-party restrictions.
- Check termination treatment for completed milestones, uncompleted artifacts, and continuing licenses.
The point of this layer is simple: make future-use boundaries explicit so delivery does not quietly turn into unpriced model-development reuse.
Related: A Guide to Liability Clauses for Freelance AI/ML Engineers.
Before signing: reconcile the rights package#
Check the SOW against the main agreement and incorporated schedules. Record which document controls if the background-IP exclusion, assignment clause, or reuse permission conflicts. A generic entire-agreement clause does not resolve a contradictory rights schedule.
What you retain. List background assets and third-party materials separately. Give the client the embedded-use rights it needs, such as running and maintaining the delivered application, without promising ownership of a base model or dataset you do not own.
What transfers. Name the project-specific code, documentation, and other rights being assigned. State whether the transfer takes effect on creation, acceptance, or cleared payment, and provide an interim evaluation license if needed. Decide what happens to unfinished work and paid milestones on early termination.
What future use is restricted. State whether training reuse, external hosting, portfolio display, and disclosure to subcontractors are allowed. Match restrictions to the actual rights grant, confidentiality obligations, data permissions, and third-party licenses.
What you do before signing.
- Resolve conflicts across the main agreement, SOW, and incorporated schedules.
- Name background, third-party, and project-specific materials separately.
- Choose assignment or license wording, its effective time, and early-termination treatment.
- Confirm client deployment and maintenance rights and each party’s future-use permissions.
Finish by testing one realistic handoff: can the client deploy and maintain the deliverable, can you reuse your excluded tooling, and can each party identify the permissions for the model and data? Correct any conflict before signing.
Use the freelance contract generator to assemble a draft, then reconcile its rights language with the SOW and schedules.
Frequently Asked Questions
How do I protect my existing code when freelancing?
Document what you owned before the project in the contract set, for example as defined exclusions or an attachment. That matters because the SOW usually focuses on tasks, deliverables, and milestones, while IP and confidentiality terms may sit in other documents. Before you sign, check that your exclusions are clearly referenced and consistent across the SOW and general terms.
Who owns the AI model built by a contractor?
Separate ownership of engineer-authored code from rights in base models, weights, training data, and generated outputs. The contract can assign only rights the engineer holds. The U.S. Copyright Office explains that prompts alone generally do not supply sufficient human authorship of generated output; a contract cannot create copyright where none exists. Schedule third-party licenses and define permitted use of each model artifact.
Can a client use my work to train other AI models?
They may be able to if your contract allows it or if the wording is silent enough to be read that way. A clear usage restriction reduces ambiguity around retraining, fine-tuning, and other reuse. Before you sign, check for disclosure before AI use, limits on public tools, and deletion obligations on exit. If those controls are missing, the risk of privacy leaks, unauthorized sharing, and unclear data-use explanations goes up later.
What is an IP assignment clause for an AI engineer?
An assignment transfers specified ownership rights to the client; a license grants defined use rights while ownership stays with the rights holder. Name the deliverables and exclusions, state the transfer trigger, and use signed assignment wording where required. Do not use assignment and license as interchangeable labels.
What should be included in an SOW IP clause for AI development?
Keep these elements aligned: defined deliverables, scope and KPIs, transfer or license language, AI-use and data-handling rules, and clear exclusions. This matters because AI control terms may sit across the SOW, MSA, freelancer contract, data processing addendum, supplier terms, or a linked policy schedule that can be updated. Before you sign, read the full document set together and confirm that the same terms mean the same thing in each place.
What does a reservation of rights clause actually protect?
A reservation-of-rights clause can be interpreted differently based on contract wording and governing law. The key check is whether it conflicts with assignment, license, or AI-use terms elsewhere in the contract set. Before you sign, review those clauses together so rights are not left ambiguous.
What's the difference between "work-for-hire" and an "IP assignment"?
They are different legal routes, and the result depends on governing law and contract structure. Under U.S. copyright law, qualifying work made for hire makes the employer or commissioning party the author and initial owner. An assignment transfers existing ownership rights; a license permits specified uses while ownership stays with the licensor. Standalone commissioned software does not become work made for hire simply because the contract uses that label. Use this quick check before signing:
Try a related tool
Researched and edited by the Gruv editorial team. Gruv builds cross-border billing, payouts, and finance-operations software for global businesses.
Sources
Includes 1 external source outside the trusted-domain allowlist.
Educational content only. Not legal, tax, or financial advice.
Related Posts
Work for Hire vs Assignment of Rights for Freelancers
A freelance agreement is not just about price and scope. It decides who controls the rights in the work. If the ownership language is loose, rights can move earlier than you expect, cutting down your control once the work is delivered or used.
Freelance Liability Clauses That Limit Risk Without Stalling the Deal
Read the liability limit and indemnity together with the scope, warranties and remedies. The useful question is how much you could owe, for which event, and who pays to handle a claim. A cap that looks finite in one section may be bypassed by a carve-out elsewhere.
The Freelance Payment Penalty: A Modeled Audit of Platform Fees, FX Spreads, and Payout Delays
The money rarely disappears through a single, easy-to-spot fee. The real loss is stacked. A marketplace takes its commission, a processor adds a charge for international cards, a bank or payment company converts the currency at a spread, a platform holds the funds before release, and a wire sheds a little to intermediaries on the way in. Each layer looks defensible on its own, but the worker feels the combined result as a smaller deposit and a later payday.