Who Owns the Output?

A technology company came to us to paper a partnership. The product was built on AI, the deal was signed in principle, and the draft in front of everyone was thorough about payment, term, and territory. It said nothing about who owned what the system produced, nothing about whether either side could use the other's data to improve a model, and nothing about who answered for it if the output turned out to resemble someone else's protected work. The commercial terms were finished. The terms that would actually decide the value of the deal had not been started.

That gap is the norm right now, not the exception, and it is worth understanding why. For most of contract history, the questions a document leaves unanswered are quietly answered by default rules: copyright vests in the author, work made for hire and assignment move it, gaps in a sale are filled by the commercial code, and a license grants what the words fairly imply. Those defaults were built for a world of human authorship and negotiated rights. Artificial intelligence removes the assumptions underneath them. When the defaults stop giving clean answers, silence in the contract stops being neutral. It becomes a position, usually the wrong one, and usually the other side's.

Here are the questions the old defaults no longer answer, and what a contract now has to say out loud.

Who owns the output, and is "own" even the right word

Ask who owns the output of an AI system and you assume the question has an answer of the familiar kind. Often it does not.

Current as of July 2026. Under current U.S. Copyright Office guidance, material generated purely by an AI system, without sufficient human authorship, is not protected by copyright at all, while the human-authored contributions around it can be. That baseline is more settled than it looks: the Supreme Court declined further review of the leading case on the question in March 2026, leaving the human-authorship requirement in place. What remains genuinely contested, and is still being tested in litigation, is the boundary: how much human selection, arrangement, or modification of AI-assisted material is enough to make it protectable. The practical point for a founder holds regardless of where that boundary settles: a clause that says "Customer owns all output" may be granting ownership of something no one can own, which is to say it may be granting very little. Worse, AI output is not exclusive. The same prompt and the same model can produce the same or a closely similar result for someone else tomorrow, so "ownership" of an output does not carry the exclusivity that ownership of a bespoke work would.

The workable contract stops asking who owns the output as if it were a painting, and instead allocates rights and risk between the parties: which side may use the output and for what, who bears the risk that it is not protectable, and who bears the risk that it overlaps with someone else's. Those are answerable questions. "Who owns it" often is not.

Who may train on the inputs

The second question runs the other direction: not the output, but the data going in. May the provider use your inputs, your prompts, your documents, your customers' data, to train or improve its models?

There is no comfortable default here. The provider's rights to your data are whatever the contract grants, and if the contract is silent, you have not avoided the question, you have handed it to whoever drafts the paper. For a company on the vendor side, an unstated training right invites a customer to write a restrictive one for you in security review. For a company on the customer side, silence can mean your confidential material trains a system your competitor also uses. Either way the term has to be explicit and narrow: whether training is permitted at all, and if so, only on aggregated and de-identified data, said in plain words rather than left to inference.

Whose risk is the model's provenance

The third question is the one founders least expect and enterprise customers raise first. A model was trained on data, and that data came from somewhere. If some of it was protected, the output can carry infringement risk that no one in the room created on purpose.

This is live and unsettled law, and the contract cannot resolve what the courts have not. What it can do is allocate the risk deliberately. Enterprise customers increasingly push that risk onto the vendor through the IP indemnity, and an uncapped IP or infringement indemnity can quietly become the largest exposure in the agreement. So provenance risk is not only an IP question; it is a limitation-of-liability question, and the two clauses have to be read together, because the indemnity is where the risk lands and the cap is what decides how far it reaches.

The chain of rights, and why you can't grant what you don't hold

The last question ties the others together, and it is where founders building on someone else's model get caught. If your product sits on top of a third-party model reached through an API, your rights to the outputs, your ability to promise anything about them to your own customers, and your indemnity protection all flow down from that upstream provider's terms. You cannot grant your customers more than your model provider grants you.

That single sentence resolves a surprising number of disputes before they happen. A founder promises a customer broad ownership and a clean indemnity, then discovers the upstream terms give neither, and the promise is now a liability with nothing behind it. The discipline is to read the whole chain, upstream and downstream, and to make sure what you promise your customers is actually supported by what you were promised. Rights, like water, do not rise above their source.

What the contract has to decide

None of this requires predicting how the law resolves. It requires deciding, expressly, the things the defaults used to decide silently. In practice that is a short list:

• Output rights. Not "who owns it," but which party may use the output and for what, with an honest acknowledgment of the limits on protectability and exclusivity.
• Training rights on inputs. Whether the provider may use your data to train or improve, and if so, on what terms. Say it; do not leave it.
• Provenance and indemnity. Who bears the risk that output or training data infringes a third party's rights, and how that indemnity interacts with the liability cap.
• Confidentiality and data handling. Whether inputs are confidential, how they are stored, and whether they can surface in anyone else's output.
• The upstream chain. That nothing you promise your customers exceeds what your own model provider has granted you.

The through-line is simple. The default rules that used to fill these gaps were written before the technology existed, and they no longer answer cleanly. Until they do, the contract that says nothing is the contract most exposed, and the founder who decides these questions on purpose is negotiating from a position the silent one has already given away.

The firm drafts and negotiates the contracts that AI, SaaS, and technology companies live on, output and data rights, IP ownership and licensing, indemnity and the liability cap, and the upstream-to-downstream chain that decides what a founder can actually promise. If your agreements are silent on the questions above, that silence is a decision. It is worth making it the one you intended.

Read the agreement your biggest customer just redlined, or the one you are about to send →

This material is for general information only and is not legal advice; reading it does not create an attorney-client relationship. It describes an area of law that is unsettled and evolving as of the date shown, stated at the level of principle; confirm the current law before acting. Have your specific agreements reviewed by counsel.