Who owns the code when you hire a development agency or contractor?

By default, often the contractor. Under UK law, the first owner of copyright in a commissioned work is the person or organization that created it, not the commissioner, unless ownership is assigned in writing. If owning the code matters, the contract has to say so explicitly.

Does paying for software development mean you own the result?

No. Payment buys you what the contract says it buys. Without a written assignment, you may hold only an implied license to use the software, with the contractor retaining copyright. The invoice is not an ownership document.

What should an AI development contract transfer beyond code?

An AI system is more than its repository. Real ownership covers six transfers: code, documented prompts, infrastructure in your cloud, the eval suite with its baselines, credentials under your control, and runbooks. An IP clause that names only "the code" leaves most of the system behind.

Is this legal advice?

No. It is an engineering studio describing the general principles and the contract items worth raising, with the primary government guidance linked. For your specific contracts and jurisdiction, ask a solicitor.

Who owns the code? The default answer surprises most buyers

The short answer

Paying for software does not make it yours by default. Under UK law, the first owner of copyright in commissioned work is its creator, the contractor, unless ownership is assigned in writing. For AI systems the stakes are higher still, because the code is the smallest part: prompts, evals, infrastructure, and credentials decide whether you own a system or merely hold its source. The contract, not the invoice, settles all of it.

Most buyers assume that paying for a build means owning the result. The law assumes the opposite, and the gap between those assumptions is where agencies build their retention business. This is the plain-language version, with the government guidance linked and the AI-specific clauses spelled out.

The default nobody expects

The UK's official guidance is unambiguous: when you commission a copyright work, the first legal owner is the creator, not the commissioner, unless you agree otherwise in writing. Employees are different (their employer owns work made in the course of employment), but agencies, studios, and freelancers are not your employees. Absent a written assignment, the contractor owns the copyright in the software you paid for, and what you hold is, at best, a license to use it. Many jurisdictions rhyme with this default. The practical rule is universal: silence favors the contractor.

The AI twist: code is the smallest part

Classic software disputes fought over one artifact, the source. An AI system distributes its value across artifacts most contracts never mention. The behavior lives in prompts. The proof it works lives in evals. The viability lives in infrastructure and credentials. A vendor can assign you the code with a flourish and retain effective control of the system, because a repository without its prompts, evals, and keys is a museum piece. The six-part handover standard exists precisely because "client owns all IP" does not cover evals nobody wrote down or prompts held back as "methodology."

A repository without its prompts, evals, and keys is a museum piece.

What the contract should say

–Written assignment of IP in the deliverables, signed, not implied by invoices or emails: the gov.uk guidance is explicit that informal agreement does not move ownership.
–The six transfers named individually: code, prompts, infrastructure, evals with baselines, credentials, runbooks. Name them, because generic IP language reliably misses four of the six.
–Vendor background IP carved out honestly. Studios reuse internal libraries and templates; the sane pattern is a broad license to you for anything embedded in your system, with assignment of everything built for you.
–Exit terms for a mid-engagement split: work to date transfers, at a defined price, without negotiation leverage games.
–Your accounts from day one where possible: repos, cloud, API keys. Ownership you already possess needs no clause to enforce.

Ownership beyond the clause

The clause is necessary and insufficient. Ownership you cannot operate is a certificate, which is why the contract items above end in a practical test: the cold-start rehearsal, where your side redeploys the system from your accounts with the vendor watching and not touching. Vendors who build for that test welcome the clause, and vendors who resist it are answering question ten more honestly than they intended. Ownership is our lane and our bias, stated plainly: it is the entire difference between buying an asset and renting a dependency with your logo on it.