Vendors hand over a folder of files and call it a handoff. What they’ve actually transferred is access, and access disappears the day the relationship does. The distinction between access and ownership is not subtle; it’s the difference between a project you control and one you’re renting from whoever built it.
A handoff meeting and a folder of code are table stakes. Full ownership means you can fire the vendor tomorrow, hand the project to a different team, and keep operating without interruption. Most handoffs don’t deliver that. Here’s what does.
Why “Handoff” and “Ownership” Are Not the Same Thing
Vendors hand over deliverables. That doesn’t mean you own them outright. The distinction matters, especially when AI workflows sit at the core of a business process.
Access vs. Ownership, What the Distinction Costs You
Access transfer means you can log into accounts, see the code, and run the tool. Ownership transfer means you hold the IP, can modify the system without permission, and have no ongoing dependency on the original vendor.
The difference becomes expensive when you want to change something. If the vendor used a proprietary orchestration layer, their own LangChain wrappers, a custom middleware, a hosted API that’s theirs not yours, you may have access but no ability to operate independently. You’re a tenant, not an owner.
The Builder.ai Collapse: A Warning That Went Unheeded
Builder.ai was once valued at $1.3 billion and backed by Microsoft. When it collapsed in 2024, hundreds of businesses discovered that the software powering their operations lived on Builder.ai infrastructure, and they had no portable version of it. The companies that got their code back found it undocumented, untested, and non-functional without Builder.ai’s internal platform.
Access? Yes. Ownership? No. 81% of enterprise leaders say they’re concerned about AI vendor dependency, yet only 6% say they could switch providers without material disruption. SMBs are in a worse position than enterprises. They have less use to renegotiate, less technical staff to diagnose the dependency, and less capital to rebuild.
The Full Ownership Transfer Checklist
A proper handoff package covers five categories. If any one is missing, ownership is incomplete.
Source Code and Build Artifacts
You need the full source code in a repository you control, not a read-only fork on the vendor’s GitHub org. That includes all dependencies pinned to specific versions, build scripts, CI/CD configuration, and deployment manifests.
The test is simple: can a new developer clone the repo and run the project with no calls to the vendor? If not, the code handoff is incomplete.
Credentials, API Keys, and Infrastructure Access
Every API key, service account, database credential, and infrastructure login should be transferred to accounts you own, not shared access to the vendor’s account. This includes third-party service accounts (OpenAI, Anthropic, AWS, GCP), domain registrar access, and DNS control.
Rotate every credential after transfer. Shared access to a vendor-controlled account is not ownership; it’s borrowed access that can be revoked.
AI-Specific Assets: Model Configs, Prompts, Fine-Tuning Data
This is where most handoffs fall short. The “AI” in your AI project often lives in prompt templates, system instructions, model configuration files, and fine-tuning datasets. If those aren’t included in the handoff, the vendor retains the core intellectual property even if you have all the surrounding code.
Demand: all prompt files, system prompts, and any fine-tuned model weights as exportable files. If the vendor used a fine-tuned model they hosted privately, you need the weights, or a contract clause that gives you the right to them.
Intellectual Property Documentation
Get written confirmation, in the contract if possible, in a handoff letter if not, that all work produced is assigned to you, not licensed to you. There is a material legal difference. A license can be revoked. An assignment transfers ownership permanently.
This applies to AI-generated code too. The IP status of AI-generated work is still contested in most jurisdictions, but a vendor who refuses to sign an assignment clause is telling you something about their intentions.
Operational Documentation and Runbooks
Code alone isn’t sufficient. You need: architecture diagrams, a description of how each component connects, runbooks for common failure scenarios, and documentation of any external dependencies. Without this, the project may technically be yours but practically unusable by anyone who wasn’t there when it was built.
60% of project transitions are derailed without standardized documentation and clear ownership transfer, according to Monday.com’s 2026 Project Handoff Report. The fix is documentation produced throughout the project, not assembled in the last week before handoff.
What to Demand in the Contract Before Work Starts
The handoff checklist only works if the contract gives you the right to enforce it. Negotiate these terms before any work begins.
Work-for-Hire vs. IP Assignment Clauses
Work-for-hire language means the IP is yours from the moment it’s created. IP assignment language means ownership transfers to you at a specified point (usually payment in full). Both are acceptable. A licensing arrangement, where the vendor grants you rights to use something they still own, is not acceptable for a custom AI build.
If the contract says “license” where you expect “assignment,” push back. This is not a minor drafting technicality.
Data Portability and Model Portability Requirements
If your AI tool is trained on your business data, customer records, transaction history, documents, that data must remain yours and must be exportable in a standard format. The contract should say so explicitly.
For fine-tuned models, require that the weights be stored in a location you control, or that there is a defined export procedure. Proprietary hosting with no export path is vendor lock-in by design.
Exit Clause and Service Continuity Language
Include a clause that specifies exactly what happens at termination: what gets handed over, in what format, within what timeframe, at what cost. An exit clause that requires you to give 90 days’ notice and pay for a “transition package” is use for the vendor, not protection for you.
The clause should also address what happens if the vendor ceases operations. A full ownership transfer package held in escrow, triggered by insolvency, is a reasonable ask for any project above £10,000.
Red Flags That Signal You Won’t Get Full Ownership
Spot these before you sign. They’re harder to address mid-project.
Proprietary Platforms With No Export Path
If the vendor builds your AI workflow on their own proprietary platform, and there is no documented way to export the workflow logic to a vendor-neutral format, you will never fully own the project. The underlying IP lives on their infrastructure.
Ask directly: “If we end the engagement, can we run this on our own infrastructure without any dependency on your platform?” If the answer is evasive, you have your answer.
Vague “License” Language Instead of Assignment
Watch for phrases like “perpetual, irrevocable license”, this sounds like ownership but isn’t. A license is permission to use something owned by someone else. Push for “assigns all right, title, and interest” language instead.
Vendor Retains Training Data or Fine-Tuned Weights
If a vendor’s contract says they retain rights to fine-tuned models or training datasets derived from your business data, walk away. That data is your asset. A model trained on it is, in effect, an extraction of your business knowledge that the vendor can use elsewhere.
How to Verify You Actually Own What Was Handed Over
Getting a handoff package is not the same as verifying it works. Test before the vendor relationship officially ends.
The Vendor Independence Test
Run the project with the vendor out of the picture. No calls to their support line, no access to their Slack, no help from their team. Can your staff or a new contractor operate, maintain, and modify the system using only what was handed over?
If the answer is no, if something breaks and nobody can fix it without calling the original vendor, the handoff is incomplete. This test should be run before final payment.
Running the Project Without the Original Team
Bring in one developer who was not involved in the build. Give them only the handoff package. Ask them to: deploy the project locally, run the tests, make a small change, and document what they found confusing or missing.
This is the most reliable signal of handoff quality. A well-documented project is deployable by a stranger. A poorly-documented one is held hostage by the people who built it.
If you’re evaluating a current or prospective engagement, this test will surface ownership gaps before they become expensive.
Frequently Asked Questions
Who legally owns AI-generated code, the agency or the client?
It depends on the contract, not on who pressed “generate.” In most jurisdictions, AI-generated code has unclear copyright status; which means the contract is what actually governs ownership. Without an explicit IP assignment clause, both parties may have a claim, or neither may. Always require a written assignment of all project IP, including AI-generated components, before work starts.
What’s the difference between a license and an IP assignment?
A license gives you permission to use something the vendor still owns. An assignment transfers ownership to you, the vendor retains nothing. Licenses can be revoked, can include use restrictions, and expire. An IP assignment is permanent. For a custom AI project, always require assignment, not a license.
Can I demand full ownership even if the vendor used their own AI tools to build it?
Yes. The tools a vendor uses to produce a deliverable are their business, the deliverable is yours. A carpenter owns their tools, not the furniture they build for you. Any vendor who claims they retain IP in a custom deliverable because they used proprietary tools to build it is misrepresenting standard work-for-hire arrangements.
What documents should be included in an AI project handoff package?
The minimum: full source code repository with version history, all credentials transferred to client-owned accounts, AI-specific assets (prompts, model configs, fine-tuning data), a signed IP assignment letter, architecture diagrams, and a runbook covering deployment and common failure scenarios. Anything missing from this list is a gap the vendor should be asked to fill before final payment is released.
What happens to my AI project if the agency goes out of business?
Without proper handoff documentation in your possession, you may lose access entirely. The Builder.ai collapse in 2024 left hundreds of businesses with unusable software because their projects lived on the vendor’s infrastructure. The protection is simple: full ownership transfer, including all code, credentials, and documentation, completed and verified before the engagement ends, not after. An escrow arrangement for key assets is reasonable for larger projects.
Every project Designodin delivers includes full ownership transfer by default, no license-back arrangements, no proprietary dependencies, no architectural lock-in. If you want to talk through what this looks like for your operation, start a conversation. You can also see how we scope and build this at designodin.com/ai.