Who Owns the Code Your AI Vendor Writes? The Contract Decides

Here is the short answer in full. Copyright belongs to the author. When a vendor's engineers write your system, the author is the vendor.

You become the owner through an assignment. That is a written, signed clause that hands the vendor's rights to you. The parts a model made on its own may have no copyright at all. That makes the contract, and your hold on the code, matter more, not less.

None of it helps if the system runs on the vendor's cloud, with the vendor's keys. Then you own a copy of something they can switch off.

This is general information, not legal advice. Have your lawyer read the clauses.

Who owns code written by a contractor?

The Copyright Act names two cases where a work is "made for hire." In those cases, the party that paid for it owns it.

The first is work an employee makes as part of their normal job.

The second has three conditions. The work was specially ordered or commissioned from outside. It falls in one of nine listed kinds. And both sides signed a written agreement calling it a work made for hire.

The nine are narrow. A contribution to a collective work, like a magazine. Part of a motion picture or other audiovisual work. A translation. A supplementary work, like a foreword or an index. A compilation. An instructional text. A test, and answer material for a test. And an atlas.

Software is not on the list. Say a contract only calls the vendor's code "a work made for hire." That alone may not make it yours. Code you order from outside doesn't fit any of the nine.

The clause that reliably does it is an assignment. In it, the vendor assigns to you "all right, title and interest" in the work product. That means all of it. Plenty of contracts carry both. The work-for-hire wording comes first. An assignment sits behind it in case the first fails.

The chain matters too. Say the vendor uses freelancers or an outside team. Then the vendor needs signed assignments from them. Without those, it has nothing to assign to you. Ask who wrote the code, and on what paper.

Can anyone own AI-generated code?

Partly. The US Copyright Office put out a report on this in January 2025. Its findings apply straight to code written with AI tools:

• Copyright does not cover work made by AI alone. Nor does it cover work where people had too little control over how it is expressed.
• With the tools most people have today, prompts alone do not give enough control.
• People keep the rights to their own work when it shows in the AI output. They also keep rights in the creative way they choose, arrange or change that output.
• Whether a person added enough is decided case by case.

For a build, the engineering is what makes the code yours to own. That means the design someone chose. It means the code someone wrote or rewrote, and how the pieces were picked and fit.

Say the engineers took model output as it came. That code has a thinner copyright than code they wrote and checked.

Three moves follow. First, have the assignment cover all the vendor's rights in what it hands over. How the code was made should not matter. Then nothing falls into a gap between "written" and "generated." Second, ask whether the vendor's coding tools claim any rights in their output.

Third, lean on control. A repository, or repo, is where code and its full history live. When copyright is thin, a repo on your own account still protects you. A copyright fight can't.

Assignment or license: the clause that decides it

Read the ownership clause for one word. "Client owns the deliverables" sounds final. Then you find the deliverables cover very little.

The vendor's "pre-existing materials" are licensed back to you. Those are its framework and its prompt library. They also include its orchestration layer, the code that runs the AI steps in order. That is how "you own it" turns into "you rent the part that makes it work."

A clean ownership section has four parts:

Ask for the list of what is left out before you sign. An empty list is a good answer. A long one tells you what you would have to rebuild to leave.

Owning the code isn't the same as controlling the system

Say you decide to leave your AI vendor in March. You ask for the code. The reply takes four days.

The repo sits in their account. The cloud project is theirs, and so are the API keys. For fourteen months, the model bill has come through them. Your invoice calls it "AI usage."

No one threatens you. They just quote a "transition fee." It is oddly close to what a rebuild would cost.

Your contract can say you own every line and still leave you right there. Four things decide who can switch the system off:

• The cloud account it runs on.
• The repo that holds the code and its history.
• The API keys and logins. API keys are the passwords one system uses to talk to another.
• The model and hosting bills.

The bills are the quiet one. Say your live system spends $800 a month on models. That sits inside the usual range. Most systems with 1,000+ AI interactions a day spend $200 to $1,200 a month on models.

Now say a made-up vendor bundles that bill into a platform fee. It adds 30%. That is $240 a month, or $2,880 a year. It shows on no line you can check.

Ask to see the provider's own invoice. If the vendor can't show you one, the price you pay is the price they chose.

We build on the client's own accounts from day 0: cloud, repo and hosting. The model bills go straight to the client, so no one marks up the tokens. Tokens are the units model use is billed in. Whoever you hire, ask for that setup by name.

The Keys Test: nine questions to ask before you sign

We call it the Keys Test. Questions 1 to 4 decide who can lock the door. Questions 5 and 6 decide if a new team could take over. Questions 7 to 9 decide what you leave with, and what happens to your data.

A spoken yes is worth nothing in a dispute. Ask for every answer in the contract, with the clause number beside it.

Want a quick read on questions 1 to 3? Ask for your IT lead to be made an owner of the cloud account and the repo. Then see how long the answer takes.

What should an AI handover include?

Six things. The code, the IP, the accounts, the docs, the SOPs and the training. The IP is the legal rights in the work. SOPs are the written steps for running it day to day.

The docs are where most handovers fall short. They should cover the architecture, the workflow maps, the API docs and walkthrough videos. They also need a decision record for each design choice. That is a short note of what was chosen, and why. With all of it, the next engineer can run the system. No call to the last one needed.

Here is the test. Could a team that has never met the vendor run the system from the pack alone?

Ask for the pack's contents page before you sign. A vendor that has a handover pack can show you one. A vendor that doesn't will tell you it is "in progress."

What happens to the IP if you stop halfway?

Ask when ownership moves to you. It might be on final payment. Or it might be phase by phase, as each phase is paid. Both are common.

The answer changes what you hold if a project stops in its second phase. Say the transfer waits for final payment. Then a repo on your own account from day 0 matters even more. The work so far already sits where you can reach it and read its history.

When not to insist on owning it

A managed SaaS is fine when you want a SaaS. SaaS is software you rent and log in to. Your accounting system, your help desk and your CRM are rentals. A rental is a good deal when the product is the same for everyone.

If a thousand other firms run the same product unchanged, rent it. If the system holds the way you make money, you want the keys. For a SaaS, swap the nine questions for three. Can we export our data in a standard format? Is there an API? Is the price fixed for the term?

Owning a system no one can run is a burden. It is a box of keys to a car no one can drive. If you don't have the people, plan to keep a vendor on for support. Or hire.