9 Contract Red Flags That Cost You Your AI Project's IP

Paying for work does not mean owning it. Under United States intellectual property law, a contractor who creates code, designs or models may legally retain ownership of what a business paid to develop unless a properly drafted agreement says otherwise, and courts interpret the statutory work made for hire categories narrowly. The United States Copyright Office sets out those categories in Circular 30, and commissioned software frequently does not fit them cleanly, which is why an assignment clause matters more than the phrase most contracts lead with.

AI projects make this worse in a specific way: they produce asset types that contracts written before 2023 simply do not name. Fine-tuned model weights, embeddings, evaluation datasets, and prompt libraries are all valuable, all assignable, and all routinely omitted. These are the nine clauses that most often leave a business without ownership of what it funded. This is general information rather than legal advice, and anything material should go to a qualified lawyer in your jurisdiction before signing.

The most common drafting error is treating work made for hire as a complete solution. The doctrine covers employees acting within the scope of employment and nine specific categories of commissioned work, and independently commissioned software often falls outside those categories. When it does, a contract that says only work made for hire and stops there has transferred nothing. The fix is a present assignment clause stating that to the extent the work does not qualify as work made for hire, the contractor assigns all rights, title and interest to the company.

The problem compounds internationally. In the United Kingdom and across the European Union the work for hire principle does not apply at all: creators retain ownership unless the contract explicitly transfers it. A United States template used for a contractor in London may be unenforceable on exactly the point it was included to secure, which makes governing law and the assignment language two clauses to read together rather than separately.

This is the AI-specific red flag most likely to be missed, because the contract predates the asset. A fine-tuned model is not source code and not a document; it is a set of weights derived from a base model, your training data and the contractor's engineering. If the deliverables clause lists code and documentation without naming model weights, checkpoints and adapter files, the most valuable output of a custom AI model training engagement may sit outside the assignment entirely.

Name the artefacts explicitly: base model and version, fine-tuned weights and adapters, training configuration, and the evaluation harness used to validate them. A model handed over without its training configuration and evaluation set is a black box the business cannot retrain or verify, which is a practical loss of control even where legal ownership is technically intact.

Terms such as the work or the deliverables, left undefined, are among the most cited red flags in contract review generally, and they bite hardest in machine learning projects because so much of the value sits in intermediate artefacts. A model in production depends on the feature pipeline, the preprocessing code, the labelled dataset and the monitoring configuration around it. A contract assigning only the final model leaves the business owning something it cannot rebuild, retrain or debug.

An enumerated deliverables schedule solves this, and it is worth writing as part of the machine learning development services scoping conversation rather than at signature. If a specific artefact is not on the list, assume it is not being transferred, and treat the absence of a clause as a finding rather than as no issue.

Ownership of the data a business supplies is usually clear; what is frequently silent is whether the contractor may reuse it, use it to improve their own models, or retain copies after the engagement ends. For a company whose competitive position rests on proprietary data, transaction history, customer records, inspection imagery, that silence is the whole risk. The clause needed is a restriction on use of client data to the engagement only, paired with a deletion or return obligation on termination.

The related question is whether anything derived from that data, embeddings, synthetic datasets, aggregate statistics, is treated as client property or contractor work product. Derived artefacts frequently retain commercially meaningful signal from the source data, so leaving their status unaddressed can undo the protection the data clause was meant to provide.

A licence and an assignment are different transactions, and a contract granting the client a perpetual, worldwide licence to use the deliverables sounds generous while transferring no ownership at all. The contractor remains the owner, retains the right to license the same work to others including competitors, and the client cannot assign the asset onward. That last point surfaces painfully during fundraising or acquisition, when diligence asks who owns the core model and the answer is not the company being bought.

A licence is entirely appropriate for the contractor's pre-existing tools and frameworks, as covered below. It is not appropriate for the bespoke work commissioned and paid for, and the distinction between the two should be explicit in the contract rather than left to interpretation of a single blended clause.

This red flag runs in the opposite direction and is worth understanding because an unreasonable contract is a poor foundation for the working relationship. A clause assigning everything a contractor touches, including tools, libraries and templates they built before the engagement, is unenforceable in practice and signals a client operating from a template nobody reviewed. Experienced specialists will decline it or price it, and the ones who sign without objection are frequently the ones with no reusable toolkit to protect.

The workable structure separates the two clearly: the contractor retains their background IP and grants the client a perpetual, royalty-free licence to use anything of theirs embedded in the deliverable, while all newly created project work is assigned outright. This gives the business everything it needs to operate, modify and sell the asset without demanding ownership of a contractor's general toolkit.

Payment-conditional assignment is commercially normal and protects the contractor from non-payment, which is a legitimate concern. It becomes a red flag when combined with a long or disputed acceptance process and no escrow or milestone structure, because the business can be running the model in production while formally owning none of it, and a payment dispute then becomes an ownership dispute over a live system.

The balanced structure is milestone-based payment with assignment attaching per milestone, so ownership accrues as work is paid for rather than in a single transfer at the end. Acceptance deadlines matter here too: a clause where the client may withhold acceptance indefinitely converts a payment protection into an open-ended hold on ownership.

Most freelance contracts were written before AI coding assistants were on anyone's desk, and their silence is not neutral. When a contract says nothing about whether AI tools were used to produce the deliverable, both parties fill the gap with assumptions, and disputes are born in exactly that gap. The questions worth resolving in writing are whether AI-assisted development is permitted, whether the contractor warrants the output does not infringe third-party rights, and whether client data or code may be sent to third-party model providers during development.

That last point is often the more urgent one commercially, because it is a confidentiality question as much as an ownership question. A generative AI development services engagement will involve model providers by definition, so the contract should name which providers are acceptable and under what data-handling terms rather than leaving it to the contractor's default tooling choices.

Contractors reasonably want to reference their work, and clients reasonably want control over what is disclosed about their systems. A contract silent on this leaves the contractor unsure what they may show and the client with no recourse if a model architecture or a named client relationship appears in a public case study. Both outcomes are avoidable with a clause specifying what may be referenced, whether the client is named, and whether approval is needed first.

This is also worth checking from the other direction during vetting, since a contractor's portfolio necessarily reflects how they handled previous clients' confidentiality. The Gen AI portfolio red flags post covers what to look for in a portfolio review, including work presented in more detail than a prior engagement should have allowed.

Contract review is the last filter, not the first. Most IP problems are visible earlier as a general pattern of vagueness about deliverables, timelines and ownership, and the AI agent hiring red flags post covers the behavioural signals that tend to precede a difficult contract negotiation. A specialist who scopes deliverables precisely in conversation usually produces a contract that needs less correction.

The engagement model shapes the exposure too. An employee's work generally vests with the employer under scope-of-employment rules, while a contractor's does not without an assignment, which is one of several considerations covered in the freelancer vs full-time team comparison. That difference is not an argument against contractors; it is an argument for reading the assignment clause carefully when using them.

The clauses that decide who owns an AI system are rarely the ones under negotiation, because attention concentrates on rate, timeline and scope while the assignment language sits in a template nobody rewrote for machine learning work. The cost of that omission does not appear during the project; it appears during a funding round, an acquisition or a dispute, when the question of who owns the model has an inconvenient answer.

If you are scoping an AI engagement, hire an AI developer who will enumerate the deliverables precisely, weights, training configuration, evaluation harness and pipeline code included, before the contract is drafted. A specialist who volunteers that list without being asked is telling you something useful about how the engagement will run.