Who owns your AI code when the engagement ends?

Founders discover the answer to this question at the worst possible moment: during a due-diligence review, when an investor's lawyer asks for the signed IP assignments and nobody can find them. Paying an external team to build your AI feature does not automatically mean you own what they built. This is a plain-English guide to what you actually walk away with when a contractor, agency, or subscription team leaves, and the short checklist that protects it.

The short version:

• Under US copyright law, code an independent contractor writes belongs to the contractor by default, not to whoever paid for it.
• A signed present assignment of IP, not just work-for-hire language, is what actually transfers ownership.
• Owning the repository is not the same as owning the system. Prompts, eval suites, datasets, and the knowledge in someone's head all leave with the team unless you plan for it.

Paying for code is not owning it

This surprises most first-time founders. Under 17 U.S.C. 201, work created by an independent contractor is owned by the contractor unless there is a written agreement that says otherwise. Employees are different, but a contractor or agency is not your employee. Writing a check does not move the copyright.

The common fix people reach for, a "work made for hire" clause, is weaker than it looks for software. The work-for-hire doctrine only applies to nine narrow statutory categories, and commissioned software is not clearly one of them, so a court may not treat your app as work for hire even when the contract says so. In one survey of technology services agreements, more than 85 percent included work-for-hire language but fewer than 40 percent included a properly drafted assignment as a backup. That gap is exactly what diligence lawyers look for.

The language that actually works is a present assignment: the developer "hereby assigns" all right, title, and interest to the company, in writing and signed. An agreement to assign in the future is not enough, because copyright assignments must be in writing and a promise to sign later can be renegotiated for more money. If you take one thing from this post, make it this sentence in your contracts.

The five things you actually need to own

Owning the git repository is the floor, not the ceiling. A working AI system is more than its source code, and each of these leaves with the team by default.

1. A clean IP assignment chain

Every person who touched the code, including subcontractors and freelancers the agency brought in, needs to have assigned their work to the entity you are contracting with, and that entity needs to assign it to you. Ask your vendor to warrant that its contributors have signed agreements sufficient to pass ownership through. Any professional team expects that request.

2. The prompts, evals, and datasets

In an AI system the prompts, the evaluation suite, and any curated or labeled datasets are often worth more than the application code around them. They are also the parts most likely to live in a personal notebook or a scratch file. Name them explicitly in the deliverables so they transfer with everything else.

3. Infrastructure as code and credentials

If the deployment only exists as manual steps in one engineer's terminal history, you do not really own a running system. Insist on infrastructure defined in code, plus a documented, transferable list of every account, key, and third-party service the system depends on.

4. Documentation and runbooks

The difference between a system you own and one you are hostage to is whether a new engineer can operate it without the original author. Runbooks for retraining, on-call, and known failure modes are deliverables, not favors.

5. Model artifacts and their provenance

Fine-tuned model weights, the training data that produced them, and a record of which base models and versions were used all matter for reproducibility and for your own legal footing. If you cannot rebuild the model without the vendor, you do not fully own it.

Vendor and model lock-in is the softer trap

Even with clean IP, you can be stuck if the system is wired to one provider's proprietary surfaces. Teams that avoid lock-in treat portability as a design requirement from day one: they keep logic in exportable formats, own their data, and prefer standard protocols such as REST, webhooks, and MCP over vendor-specific connectors.

Two contract clauses do most of the work. First, a data portability clause: you can bulk-export all data, including conversations, analytics, knowledge-base content, and evaluation results, on demand. Second, a termination clause requiring the vendor to hand over all indexed content, prompts, and any training data in a standard format within 30 days of the engagement ending. This is one of the trust signals we flag in how to vet an AI development partner before you sign anything.

The offboarding checklist that saves you

The worst handoffs are the ones nobody planned. Institutional knowledge evaporates before anyone schedules a transfer, and the receiving team is handed a black box. Give yourself a 30 to 60 day runway and work through a short list.

Schedule knowledge-transfer sessions with the engineers who did the work, and record them. Confirm the full IP assignment chain is signed and filed, not merely promised. Take ownership of every repository, cloud account, and third-party service, then revoke the departing team's access on a known date. Reduce the bus factor by having your own people operate the system, with the outgoing team on standby, before the engagement formally closes. This is the deliberate version of the overlap we recommend when you hire your first in-house AI engineer, and it is the opposite of the rushed final-week scramble that produces most handoff disasters.

None of this is about distrust. A team that plans a clean exit from the start is usually the same team that ships well in the middle, which is one reason continuity is worth weighing alongside cost when you compare a subscription against a hire or a fractional pod. The cost of getting this wrong is real: unclear ownership is a recurring theme in the hidden cost of wrong hires, and it can stall or sink a financing round.

Frequently asked questions

Does a work-for-hire clause mean I own the code?

Not reliably for software. Work for hire applies to a narrow set of categories, and commissioned software is not clearly one of them. You need a present assignment of IP in a signed agreement as the backstop, because that is what courts enforce.

What should I ask a vendor about their subcontractors?

Ask them to warrant, in writing, that every contributor, including subcontractors and freelancers, has signed agreements sufficient for the vendor to assign the deliverables to you. Without that chain, a single unassigned contributor can cloud your ownership.

How do I avoid vendor lock-in on an AI system?

Require data portability and a 30-day export of all content, prompts, and training data at termination. Prefer standard protocols over proprietary connectors, keep your logic and data in exportable formats, and confirm you can rebuild the system without the vendor.

When should I plan the offboarding?

At the start, not the end. Write the IP assignment, data portability, and export clauses into the original contract, and give any real transition a 30 to 60 day runway with recorded knowledge-transfer sessions so the knowledge does not leave with the people.