What to look for · Chapter 07
Who owns your AI automation? IP and lock-in
Ownership is where buyers get burned. A great build is worthless if you can't keep it. This chapter shows what to own and how to avoid lock-in.
“Risk comes from not knowing what you're doing.”
What you should own in an AI automation project
You should own four things outright. Together they let you keep, move or replace the build.
- The code and workflow logic.
- Your data and its exports.
- The accounts it runs on.
- Documentation and credentials.
Own these and you can maintain or replace the build. Miss them and you're tied to the agency.
What is vendor lock-in?
Lock-in isn't always deliberate. It often creeps in through small choices. The result is the same — you lose leverage.
How agencies create lock-in
Watch for these patterns. Any one of them makes leaving harder.
- Running the automation on their accounts.
- Building on a closed, proprietary platform.
- Holding the credentials and API keys.
- Skipping documentation and handover.
- Tying support to their code only.
Ownership by build type
Who owns the build depends on how it's made. Here's the usual picture.
| Build type | Who usually owns it | Lock-in risk |
|---|---|---|
| No-code on your accounts | You | Low |
| Custom code, handed over | You | Low |
| No-code on their accounts | Shared or unclear | Medium |
| Agency's own platform | The agency | High |
Questions to ask about ownership
- Who owns the code and workflows?
- Whose accounts does it run on?
- Can we export our data anytime?
- Do we get documentation and credentials?
- What happens if we leave?
What to put in the contract
Put ownership in writing before work starts. Four clauses protect you.
- IP assignment of the code to you.
- Your data stays yours, with export rights.
- A handover of accounts, keys and docs.
- Clear exit terms and notice periods.
Contracts get their own chapter later in this guide.
Common ownership mistakes
Key takeaways
- Own the code, workflows, data and accounts.
- It should run on your accounts, not theirs.
- Get IP assignment and a handover in writing.
- Beware closed platforms you can't leave.
Comparing agencies?
Browse the directory and ask each about ownership up front.
Browse the directoryFrequently asked questions
Who owns the code an AI automation agency builds?+
It depends on your contract — so agree it up front. By default, ownership can sit with the agency. Insist on IP assignment so the code is yours. You should also own the workflows, data and documentation. Get it in writing before work starts.
What is vendor lock-in in AI automation?+
Vendor lock-in is when a build ties you to one agency or platform. Leaving means rebuilding, losing data, or paying to escape. It often creeps in through small choices. The fix is owning the code, data and accounts from the start.
How do I avoid vendor lock-in with an agency?+
Own the code, workflows, data and accounts it runs on. Make sure the automation runs on your accounts, not theirs. Get documentation, credentials and a proper handover. Add IP assignment and clear exit terms to the contract. Then you can maintain or move it anytime.
Should AI automation run on my accounts or the agency's?+
On your accounts, wherever possible. That keeps you in control of data, billing and access. If it runs only on the agency's system, leaving is hard and costly. Ask where it runs and who holds the keys before you start.
Do I own my data with an AI automation agency?+
You should — but confirm it in the contract. Your data stays yours, with the right to export it anytime. Agencies process it to build and run the automation. Make sure a processor agreement and retention terms are clear. Never leave data ownership vague.
What should an AI automation contract say about ownership?+
It should assign the code and IP to you. It should confirm your data stays yours, with export rights. It should include a handover of accounts, keys and docs. And it should set clear exit terms and notice. Cover this before any work begins.