What software ownership actually means when the code is written with AI

You paid for the software. Do you own it? That question used to have a boring legal answer. Then developers started writing code with AI assistants, and business owners started asking whether any of it still belongs to them. The short answer is yes. The longer answer is that ownership was never really about copyright anyway, and the things that actually protect you are the same things they always were.

AI-assisted code can be owned by the business that paid for it, in every way that matters commercially. What decides real ownership is possession of the repository, an assignment clause in the contract, infrastructure accounts in your name, a clean dependency list, and documentation good enough for a stranger to pick up. Copyright law has a genuine wrinkle around purely machine-generated text, but it almost never changes the outcome for a line-of-business system. The bigger risks are lock-out and unmaintainable code, and both are contract problems, not AI problems.

• Ownership is five separate things. Source code, your data and its structure, infrastructure accounts, the deployment pipeline, and documentation.
• Get repository access on day one, in an account you pay for. If you only get code at the end, you do not have control, you have a promise.
• Ask for a written list of every third party package and its license. Copyleft licenses like AGPL can create obligations you did not sign up for.
• Hosting in the vendor's cloud account is the most common form of hidden lock-in, and it has nothing to do with who owns the code.
• If a second developer can't run your system locally and ship a small change in a day, your ownership is theoretical.

Most contracts talk about "the software" as if it were a single object. It isn't. A working system is five assets, and a vendor can hand you one while quietly keeping the other four.

The source code is the obvious one. The database schema matters just as much, because it defines how your data is organised and whether anyone else can read it. Then there are the infrastructure accounts, meaning the cloud hosting, the domain registrar, the email sending service, and any paid API keys. Fourth is the deployment pipeline, which is the automation that takes new code and puts it in front of your staff. Fifth is documentation, including setup instructions and a plain-English description of what the system does.

You need all five. A business that has the code but not the AWS account can't deploy. A business that has the code and the account but no documentation has a very expensive puzzle. Ask for all five by name in the agreement.

Commercially, yes. Practically, yes. Legally, there's one real nuance and it is smaller than the internet makes it sound.

Copyright protects human authorship. The US Copyright Office has been consistent that material generated entirely by a machine, with no meaningful human input, isn't protected on its own. Human-written code is protected. So is a human's selection, arrangement, and editing of machine-suggested material. Real development with AI looks like a developer prompting, reviewing, rejecting, restructuring, and testing. That is human authorship by any reasonable reading.

Here is why it rarely matters for your business. Copyright protects you against someone copying your code. Nobody is going to steal your dispatch scheduler and sell it. The risk you actually face is being locked out of your own system by the people who built it, or being unable to hire anyone else to work on it. Neither of those is a copyright question. Both are contract and access questions.

One thing worth asking about is whether the AI tools in use carry IP indemnity. Several major coding assistants offer contractual protection for their business customers against third party copyright claims arising from suggested code. It's a reasonable question to put to any firm. If they can't tell you what tools they use and under what terms, that tells you something about their process.

Work made for hire language is the starting point, but it isn't enough by itself. In US law, work for hire only applies to certain categories and relationships. A good agreement pairs it with a present assignment of all rights as a backup, so that whatever the firm holds, you hold.

The clause that matters more than either is repository access from day one. Your code should live in a source control account that your company owns and pays for. Your developers get invited to it. Not the other way around. This single arrangement removes most of the control a bad vendor could ever hold over you.

Code escrow, where a third party holds a copy in case the vendor fails, was invented to solve a problem you no longer need to have. If you already have the repository, escrow adds cost and a false sense of safety. Skip it and take the real thing.

A few other clauses earn their place. Ask for a warranty that the delivered code doesn't knowingly include third party material with incompatible license terms. Expect the firm to keep a non-exclusive license to generic building blocks they reuse across clients, like a login component or a PDF generator. That is normal and reasonable. What isn't reasonable is a firm retaining rights to the parts specific to your business.

Every modern application is mostly other people's code. A typical web system pulls in hundreds of open source packages for things like date handling, charts, and PDF generation. Those packages come with licenses, and the licenses come with obligations.

Most are harmless. MIT, Apache 2.0, and BSD let you do essentially anything as long as you keep the copyright notice. The ones to watch are copyleft licenses, particularly GPL and AGPL. In plain English, copyleft means that if you distribute software built on that component, you may have to publish your own source code under the same terms. AGPL extends that trigger to software you run as a web service, which is exactly what most business systems are.

You don't need to read licenses yourself. Ask the firm to produce a software bill of materials, which is a plain list of every package, its version, and its license. Automated scanners generate this in minutes. Any firm that hesitates either hasn't looked or doesn't want you to.

This is where I see the most expensive misunderstandings. A business proudly owns its code, then discovers the application runs in the agency's cloud account, on the agency's domain registrar, with the agency's Stripe and Twilio keys wired in. The code is yours. The running system is not.

Fix it at the start. The cloud account should be opened by your company, with your company card on file. The domain should be registered to you. Third party services that charge money should be your accounts with the developers added as users. This costs nothing extra and removes the problem entirely.

Managed hosting from your development firm is fine, and often sensible if you have no IT staff. The test is whether you can leave. If the answer involves a migration project, it isn't managed hosting, it's a hostage situation with an invoice attached.

AI has made it easy to produce a large volume of working code quickly. That's genuinely useful. It also creates a failure mode worth naming. Code generated fast and merged without review tends to drift. You end up with three different ways of talking to the database and two competing patterns for handling errors. It runs. It is also miserable to change.

Maintainability is what turns a legal right into a practical one. The things that create it are unglamorous. Automated tests that catch breakage. A README that explains how to run the system on a new machine. Consistent patterns. Comments where the business logic is strange, which it usually is, because your business is strange in the specific way that makes it yours.

Owning your system doesn't make it free. You still pay for hosting, and someone still has to apply security updates to those hundreds of packages. Budget for care, not just construction. Software that nobody touches for two years becomes software nobody can safely touch.

Ownership also doesn't stop a competitor building something similar. It protects your specific code, not your idea. And if your plan is to license the system to other companies as a product, get a software lawyer involved early. That is a different risk profile, and the copyright wrinkle around machine-generated material starts to matter more when the code itself is the asset being sold.

Custom is also the wrong answer for plenty of things. Don't build your own accounting ledger. Don't rebuild email, payroll, or payment processing. Those are solved, regulated, and cheap. Build the part that's specific to how you operate, which is usually the workflow layer nobody sells off the shelf.

Where the arithmetic tips is subscription pricing that scales with headcount. Sixty users at ninety-five dollars a month is $5,700 a month, or $68,400 a year. Over five years that's $342,000 in rent, with no asset at the end and a renewal letter every January. Compare that total against a one-time build plus modest hosting and periodic maintenance. If the gap is large and the tool is a poor fit anyway, the build wins on money and on fit. If you have twelve users on a $40 seat, it doesn't. Do the multiplication before you do anything else.

Put these in an email and send them to every firm you're considering. The answers will sort the field quickly.

1. Will the repository be in our company's account from week one, with your team invited as collaborators?
2. Does the agreement assign all rights to us, and what generic components do you retain a license to reuse?
3. Which cloud, domain, and third party service accounts will be in our name and billed to our card?
4. Can you provide a dependency list with licenses at handover, and are there any copyleft components in it?
5. What AI coding tools does your team use, and do those tools carry IP indemnity for business use?
6. What documentation and automated tests ship with the final delivery?
7. If we hired a different developer next year, what would their first day look like?

A firm that answers all seven without flinching is a firm that expects you to be able to leave. That's the posture you want. Ownership isn't a clause you win in negotiation. It's a set of defaults that either exist from the first week or get retrofitted expensively later.

If you're weighing a renewal against a build and want an outside read on the numbers, you can book a free strategy session with us in Clearwater. We'll tell you if the math doesn't work.

Is AI-written code legally protectable?

Human-written and human-edited code is protected by copyright. Material generated entirely by a machine with no meaningful human involvement generally isn't. Real development involves constant human review and restructuring, so working systems are protectable in practice. For internal business software, this distinction almost never affects anything you care about.

Should I ask my developer to stop using AI tools?

No. You'd be paying more for the same result. What you should ask is how the code gets reviewed and tested before it ships. The quality risk comes from unreviewed output, not from the tool itself.

What if my current system is hosted in my agency's account?

It's fixable, and it's a normal project. You create your own cloud account, migrate the application and database, move the domain, and reissue API keys under your billing. Do it while the relationship is good rather than during a dispute.

Do I need code escrow?

Not if you already hold the repository. Escrow exists to solve the problem of not having the code. Holding it yourself from day one is cheaper and more reliable.

How do I know the documentation is good enough?

Don't read it yourself. Give it to a developer who has never seen the project and ask them to get it running. An hour of their time answers the question better than any review you could do.

If you're still deciding whether to build at all, start with our piece on buy versus build and when a custom system beats another SaaS renewal.

Related articles

• Buy versus build, and when a custom system beats another SaaS renewal
• How to migrate off a platform without losing twelve years of attachments
• What a good software handover package actually contains
• Per-seat pricing and the hidden cost of growing your team