What Your Company Should Own After an AI Implementation
Data, code, accounts, domains, hosting, database access, credentials, documentation, deployment, subscriptions, analytics and support — what an organization should hold after an implementation, and what it will not.
Ownership is easy to assume and expensive to discover late. After an implementation, three categories exist: assets the client should hold, intellectual property that stays with the implementation partner, and technology governed by third-party providers. This article is not legal advice; the terms that apply are the ones in your agreement.
Three categories, not one
"Do we own it?" is a reasonable question with an unhelpfully short answer. A delivered application is almost always a combination of things with different owners.
Client-owned assets are the ones your organization should be able to hold, administer and move. Implementation-partner intellectual property is the reusable work a partner brings to every engagement. Third-party technology is licensed from providers on their terms, by whoever holds the account.
Problems come from treating the three as one. A partner who hands over everything including their own reusable tooling is unusual; a partner who hands over nothing leaves you unable to operate what you paid for.
What your organization should hold
These are the items that determine whether you can operate, change or move the application without depending on goodwill.
- Your data, in a format you can export without the partner present
- Application code written specifically for your engagement, on the terms your agreement sets out
- Accounts with hosting, database and third-party providers, in your organization's name
- Domains and DNS control
- Administrative database access
- API credentials for services you pay for
- Documentation covering how to run, deploy and change the application
- The deployment path, so a change can be released without one individual
- Analytics and any measurement configuration
- Source control, or a complete copy of the repository
What usually stays with the implementation partner
Most partners bring reusable material: internal libraries, templates, verification tooling, delivery processes, operational software. That work was not created for your engagement and is generally not transferred with it.
This can be entirely reasonable — it is often why the engagement was faster than building from nothing. What matters is that it is named, and that your application does not silently depend on something you cannot access or licence.
The question to ask is precise: if this relationship ended, what would stop working, and what would we need a licence for?
What third parties govern
Hosting, databases, email delivery, payments, AI providers and authentication all arrive with their own terms, pricing and data handling. Nobody in the engagement owns those; someone holds the account.
Hold the accounts yourself where you can. Where a partner holds an account on your behalf, know which, why, and what transferring it involves.
Subscriptions and the cost you inherit
An application carries a running cost after launch: hosting, database, email, AI usage, any licensed component. That cost belongs to whoever holds the accounts, and it should be visible before launch rather than discovered on a card statement.
Ask for the list, with which are essential and which are optional.
Support is a separate arrangement
Ownership and support are often confused. Owning the code does not mean your team can maintain it, and a support arrangement does not mean the partner owns the application.
Both should be written down separately: what you own, and who is responsible for it after launch.
Settle it before the contract
Every item above is easier to agree before work starts. Afterwards, each becomes a negotiation at the least convenient moment.
This is the reasoning behind how MessyOrg scopes work — clear scope, clear ownership, clear handoff — and why each engagement defines what belongs to the client, what remains MessyOrg intellectual property, what is governed by third-party providers, and what is included in the final handoff. Final ownership and licensing terms are defined in the applicable agreement.
A note on legal advice
This article describes categories and questions. It is not legal advice, and it does not describe the terms of any particular agreement. Contractual ownership depends on the agreement you sign, and significant arrangements are worth reviewing with your own counsel.
Key takeaways
- Separate client-owned assets, partner intellectual property and third-party technology explicitly.
- Hold your own accounts, domains, credentials and administrative database access.
- Ask what would stop working if the relationship ended — that answer is the real dependency list.
- Agree ownership, running cost and support before work begins, not at handoff.