What changes in a software contract when the code is AI-generated?

Six clauses carry assumptions that no longer hold: intellectual property ownership, acceptance criteria, warranty duration, data handling, third-party disclosure, and handover. Each was written on the assumption that a human authored every line, and the contract now depends on that assumption in ways the writers did not intend.

Who owns AI-generated code?

A supplier can assign whatever rights they hold, but copyright generally attaches to human authorship, and the US Copyright Office's January 2025 Part 2 report holds that copyright does not extend to purely AI-generated material or to material where human control over the expressive elements is insufficient, while a larger work incorporating AI-generated content can still be protected. The practical response is to write the clause around delivery of assets you need rather than relying solely on an assignment of rights.

Does this mean we cannot own our software?

You own the assets: the source code, the build configuration, the infrastructure definitions, the check suite, and the specifications. Those are deliverables a contract can require regardless of copyright status. What may be weaker is the ability to stop a third party who independently produced similar code, which matters for a product you intend to license and rarely matters for internal software.

What should acceptance criteria say in an AI-build contract?

They should reference a specific, machine-checkable set of guarantees rather than "conforms to the specification". Attach the list of things the system must always be true about as a schedule, and define acceptance as that suite passing, since a subjective acceptance standard is what disputes are about when nobody can show a document or test that settles them.

How long should the warranty period be?

Long enough to include real production load and at least one month-end cycle, since the defects that matter in generated code appear in unusual cases and under conditions that do not happen during a short warranty period. A 30-day warranty that starts at handover typically expires before the system first handles heavy real use.

What data clauses matter specifically for AI development?

Two: which model providers or third-party services receive your code or your data during development, and whether anything you supply can be retained or used for training. Both should be stated explicitly rather than left to a general confidentiality clause, because a general clause does not anticipate a supplier pasting your schema into a tool.

What is a disclosure clause and why does it matter?

A term requiring the supplier to identify the third-party services, models, and tools that handle your code or data. It matters because your own compliance obligations often apply to subprocessors too, and you cannot assess suppliers and tools you have not been told about.

What should the handover clause require?

Named artefacts with a schedule: source and history, build and deploy configuration, infrastructure definitions, the check suite, environment setup documentation, and a written list of anything currently known to only one person. A clause promising reasonable cooperation is unenforceable in practice because cooperation is unmeasurable.

Should the contract state how much code is AI-generated?

A percentage is not a useful contractual term, since it does not predict quality in either direction and is difficult to measure honestly. A disclosure clause naming which tools and services are used is more useful, because it lets you assess the suppliers and tools involved and your own compliance risk.

Is this an adversarial approach to a supplier relationship?

No, and every clause here is easier to agree before work starts than after an incident. A supplier who resists a machine-checkable acceptance standard or a named handover list is telling you something useful, and a good supplier usually welcomes both because they remove the ambiguity that produces disputes.

Procurement for AI-built software: Reveneau

We keep seeing the same contract. It is a decent contract. It was drafted carefully, probably around 2019, for a time when a person typed every line of the deliverable, and six of its clauses now depend on that assumption in ways nobody intended.

None of this is about distrusting a supplier. It is about the fact that the document describes a production process that has changed, and the gaps only become visible at the moments a contract exists to handle: a dispute over whether something was delivered, an incident after handover, or the day you want to take the code somewhere else.

Six clauses. The first one surprises almost everybody.

1. Intellectual property: the assignment may give you less than you think

The standard clause says the supplier assigns you all intellectual property rights in the deliverable. That has always read as complete coverage.

The complication is that copyright generally attaches to human authorship. In the United States, the Copyright Office's Part 2 report on copyright and artificial intelligence, published on 29 January 2025, concluded that copyright does not extend to purely machine-generated material, or to material where there is insufficient human control over the expressive elements to constitute authorship, while works incorporating genuine human contribution can be protected in respect of that contribution. Other jurisdictions differ, and the position is still developing.

So a supplier can assign you, in complete good faith, every right they hold, and the set of rights they hold may be smaller than the phrase "all intellectual property" suggests.

For most buyers this is a theoretical problem. If you are building an internal operations system, nobody is going to reproduce it, and the practical value is in the running software rather than in the ability to sue over the source. It becomes a real problem in exactly two situations: when you intend to license or resell the software, and when the software's value in an acquisition depends on ownership you can prove and protect.

The useful response is not to argue about copyright law in a commercial negotiation. It is to write the clause so that it does two things at once: assign whatever rights exist, and separately require delivery of a named list of assets. Source code with its history, build configuration, infrastructure definitions, the check suite, the specifications, and the credentials or accounts needed to run it. Those are contractual obligations that hold regardless of what copyright does or does not cover, and they are what you actually need in order to keep operating and changing the system.

Raise it with your own counsel rather than treating this piece as legal advice. It is a warning to check, not a legal opinion.

2. Acceptance criteria: "conforms to the specification" is the source of most disputes

Traditional acceptance language points at a specification document and says the deliverable must conform to it. That works when both parties can read the document and largely agree on what it means.

It works less well when the specification was also the input to a code generator, because a specification precise enough to be implemented literally and a specification loose enough to argue about are two very different documents, and most contracts attach the second kind.

Write acceptance against an artefact instead. Attach the list of guarantees the system must always hold as a schedule to the contract, and define acceptance as that suite passing in an environment both parties can see. It changes acceptance from a judgment into an observation, which is the entire point of having an acceptance clause.

This has a second benefit that suppliers usually like: it protects them too. A supplier who has met an explicit, agreed set of checks is protected against new scope that is added late and presented as a defect. The mechanics of writing those checkable sentences are in how to write an acceptance test a machine can run.

3. Warranty: 30 days from handover usually expires before anything real happens

A short warranty period made more sense when the defect profile was different. Hand-written code tends to fail in ways that appear during normal use, early.

Generated code fails differently. Veracode's Spring 2026 research across more than 150 models found generated code compiling and running correctly more than 95 percent of the time while being secure in roughly 55 percent of generations. The failures happen mostly in unusual cases: unusual permission combinations, concurrent access, data patterns that only exist after months of data has been collected, and third-party services behaving incorrectly.

None of those conditions reliably occurs in the first 30 days after handover. A warranty that expires before the system has seen a genuine traffic peak, a month-end close, or the first customer who does something unexpected covers only the kind of defect that was never going to appear anyway.

Ask for a period that includes real production load and at least one full business cycle. It is a reasonable request and a serious supplier will not find it strange.

4. Data handling: name the model providers

A general confidentiality clause was written to stop a supplier telling your competitor what you are building. It was not written to address a developer pasting your database schema, your customer data structure, or a production log excerpt into a third-party service in order to debug something.

Two terms are worth stating explicitly. First, which model providers and third-party services may receive your code or your data during development, and under what conditions. Second, whether anything supplied by you may be retained or used to train a model.

If you operate in a regulated space this stops being optional. Your own obligations apply to subprocessors too, and a supplier's tool choices become part of what your compliance must cover whether or not anybody wrote them down. The engineering side of turning regulation into requirements is covered in translating regulation into engineering requirements, and the general approach in choosing a partner for regulated work.

5. Disclosure: you cannot assess suppliers nobody told you about

This clause usually does not exist at all, and it is the cheapest one to add.

Require the supplier to identify the third-party services, tools, and model providers that handle your code or data, and to notify you when that list changes in a meaningful way. Not a percentage of generated code, which is neither measurable nor informative, but the names of the systems your code and data pass through.

The reason is practical rather than philosophical. When a provider has an incident, or changes its retention terms, or turns out to be doing something your own policy forbids, you need to know whether your supplier uses it. A supplier who cannot produce that list has not thought about it, which is itself a finding.

6. Handover: name the artefacts, do not ask for cooperation

Most handover clauses promise reasonable cooperation during a transition period. That is unenforceable in practice, because cooperation is unmeasurable and the moment you need it is the moment the relationship is at its worst.

Replace it with a list and a schedule:

Source code with full commit history, in a repository you control.
Build and deployment configuration that works.
Infrastructure definitions, so the environment can be recreated rather than described.
The check suite, and evidence of it passing.
The specifications: what the system must always be true about.
Environment setup documentation good enough that a new engineer can be running locally within a day.
A written list of anything currently known to only one person.

That last item is the honest one. Every project has such a list and a supplier who claims otherwise has not looked. Asking for it in writing, before the relationship has problems, is how you find out whether it is short.

Handover matters more with generated code because the specific risk is a large codebase that looks consistent and correct but comes with no explanation, which is genuinely hard for a new team to take over safely. We wrote that up in handing over AI-written software.

What not to put in the contract

Two things we would leave out.

A limit on AI-generated code. It sounds sensible and it is not enforceable, not measurable, and not correlated with quality in either direction. A hand-written codebase with no verification carries the same risk as a generated one with no verification. Write the contract around the verification, not the authorship.

A prohibition on AI tooling. Some buyers ask for this. In practice it either gets ignored, or it leaves you with only suppliers willing to say yes to anything, which is not the group you want to be choosing from.

The tone of the conversation

None of this is adversarial and it should not be presented as such. Every clause here is easier to agree before the work starts than after the first incident, and a good supplier tends to welcome the acceptance and handover terms because they remove the ambiguity that produces disputes.

The response to these requests is itself information. A supplier who resists a machine-checkable acceptance standard is telling you they do not have one. A supplier who cannot name what only one person knows is telling you they have not asked. Neither is disqualifying on its own, and both are worth knowing before signature rather than after.

Thanks to the procurement and legal teams who let us read marked-up drafts and explain which clauses had no effect. Several of the changes above came from their questions rather than ours.

A contract cannot make software work. It can make sure you still have everything you need on the day it stops.

Related guide: How to evaluate an AI development partner.

Sources

US Copyright Office, Copyright and Artificial Intelligence, Part 2: Copyrightability (published 29 January 2025): copyright does not extend to purely AI-generated material, or to material where there is insufficient human control over the expressive elements to constitute authorship, and prompts alone are unlikely to supply sufficient human contribution. Using AI as an assistive tool, or incorporating AI-generated content into a larger work, does not remove protection from the work as a whole.
Veracode, Spring 2026 GenAI Code Security update: across more than 150 models, generated code compiled and ran correctly in over 95 percent of cases while being secure in roughly 55 percent.

Procurement for AI-built software