Own your AI software: what to own when a partner builds it

If a partner builds your agentic software, you should come out of the build owning three things: the custom code, the domain logic and workflows it encodes, and the data it works on. Anything shared that the partner brings, such as a backbone or reusable modules, should come with agreed, lasting usage rights. And the cloud, AI and external services should run in accounts that are yours. That is what it takes to own your AI software in practice, and it has to be written into the build before the first line of code, not negotiated at handover.

Most ownership problems are gaps, not disputes: nobody decided who holds the repository, what happens when a subscription ends, or whether the product can move with the company if it is sold. ScopeRight, an independent assessment and scoping practice, has described what such gaps cost in its piece on the hidden costs of choosing the wrong AI partner. Here we take the builder's side of the same question: what does the ownership arrangement look like when it is done properly?

What does it mean to own AI software?

AI software ownership means your company holds the rights to the custom code and product-specific development, controls the data and the accounts the software runs in, and can keep operating, changing and transferring it without asking the party that built it.

Paying for software is not the same as owning it. The UK Intellectual Property Office's guidance on ownership of copyright works states that when you commission a work, the first legal owner of the copyright is the party that created it and not the commissioner, unless otherwise agreed in writing. Rules differ between countries, and this article is not legal advice. The practical point travels well: the agreement decides, so the agreement has to say it.

Ownership is also not a single switch. An agentic product is assembled from parts with different owners, and that is normal. The useful question is whether you own the right things and hold clear rights to the rest.

The three layers of AI software ownership

Layer 1: your product, which you own

This is everything that makes the software yours: your screens, your domain logic, your business workflows, your extensions. In agentic software it also covers things that do not look like code: the instructions given to agents, the rules for when a person must approve a step, and the test cases you use to check that an agentic workflow still behaves as intended. We would name those explicitly in the agreement.

At Nova, you own your custom code and product-specific development. Your data belongs in this layer too: each customer runs in its own environment with its own data, there is no shared database across customers, and connecting a system does not mean its source data has to move.

Layer 2: the backbone, which you license

Every business application needs the same foundations: access and permissions, workflow orchestration with human oversight, audit trails, administration and APIs. Rebuilding them for each product adds little that is specific to you, so a provider brings them as a shared layer. In our case that is Nova Backbone and the optional modules on top of it.

This layer is not yours. Nova retains ownership of the shared Backbone and reusable modules, and maintains and licenses them. The line between the layers can run through a single word: generic workflow orchestration (steps, approvals, audit) is shared, while your specific order intake with a two-step approval belongs to your product.

Layer 3: your environment, which you hold in your own accounts

The repository, the hosting, the database, the AI model provider and other external services should sit in accounts in your company's name. A core licence does not automatically include cloud, AI or external licence costs; they are separate and paid in your own accounts. That takes some set-up effort, and it removes a common form of AI vendor lock-in: the product that cannot leave because it lives in somebody else's account.

For cloud services, EU law now points the same way. The Data Act, applicable from 12 September 2025, sets a framework for customers to switch between providers of data-processing services. For the custom build itself, the agreement is what counts.

A licensed backbone is still a dependency

We should be plain about the trade-off. Building on a licensed backbone means part of your product rests on something you do not own. That is a dependency, and calling it anything else would be misleading. What matters is whether the dependency is bounded. Our approach to ownership and continuity sets out how we handle it:

• Delivery. The delivery should include the agreed code, documentation and deployment access, with lasting rights to the delivered Nova components.
• Updates. Updates and service follow the subscription you choose. Without an update subscription, you continue on the version delivered to you, with the agreed usage rights. That is not free access to the current Backbone, and external usage costs continue.
• Maintenance. An update subscription does not replace application maintenance. Someone still has to look after your own product.
• Limits. Your own custom products may be developed broadly. Reselling the Nova core as competing infrastructure requires different rights, and white-label and reseller rights are explicit additions.

The software handover checklist: seven things to agree before the build starts

1. Code and documentation. Which repositories and documents are delivered, and when. Ideally the repository sits in your organisation from the first day, so there is no handover moment to miss.
2. Deployment access. Can your team, or a developer you appoint, deploy the product from your own accounts without the original builder?
3. Usage rights to delivered components. Which shared components are included, and are the rights to the delivered version lasting?
4. Life without an update subscription. What continues, what stops, and which external costs keep running.
5. Transfer if the company is sold. The product and agreed usage rights should be transferable to the buyer, who can then choose whether to continue the update and support relationship.
6. Who operates it. Hosting, monitoring, fixes and user support each need a name next to them: your team, a certified partner or the provider.
7. Continuity if the partner leaves. App handover, documentation and credentials should be part of the delivery, and a next partner should never get access without your consent. The same applies when an implementation partner builds on the provider's platform.

How do you write ownership into the build?

Put the checklist in the implementation plan, next to scope, integrations, security and milestones, and not only in the contract. A clause that says code will be delivered is weaker than a plan in which delivery is a milestone, with a named repository and a person on your side who has deployed from it.

When is owning the software the wrong answer?

Standard software is often the right answer, and ownership has a cost: someone has to operate, maintain and evolve what you own. If a workflow runs the same way in your company as in every other, a subscription is usually less work. Ownership earns its place where the software is mission-critical and specific to how you work, and where you would otherwise depend on someone else's roadmap for it.

This is why our approach for SMEs starts with an assessment that compares value, total cost, operations, integrations and continuity before anything is built. Sometimes the conclusion is to keep and improve what you already have.

Ownership is what lets the relationship change

Ownership does not make a product good. It makes it yours to improve, to move and to hand to someone else: your own developers, a certified partner or us. The way you work with a partner can change over time. Who owns the custom code should not.

If you are scoping a build and want to test these terms against a real workflow, discuss your build with us.

Own the software. Own the data. Rent the expertise.