Custom AI: who actually owns the automation you paid for?

You have AI built for your business. An assistant that sorts your inbox, something that answers customer questions at night, a system that prepares quotes. It works, you are happy, you pay the invoice. Then a year later comes the question almost nobody asks upfront: who owns this? Having AI built is not the same as buying a tool. With a tool you know where you stand, you cancel and it stops. With custom work it is murky, because there are four separate things that belong to somebody, and they are rarely all yours. Here is what those four are, what Dutch law says about them, and the five things to put in writing before you sign.

You are buying four things, not one

When someone builds an automation for you, you do not get a product. You get a small stack of separate parts, and each part has its own owner, which can be a different owner per part. That is why the question so often gets the wrong answer: people picture one thing, while there are four.

• The build itself, the instructions, the order of steps, the rules. This is the real custom work and the only part designed specifically for you.
• The place where it runs, the account or server where it works day and night.
• The keys to your systems, what lets it reach your mailbox, your bookkeeping or your planning.
• The thinking, the AI model comes from a large supplier and is never yours, and not your builder's either.

That last part is the least exciting: you rent it, everybody rents it, and in most cases you can swap it for a different one. It is the first three where things go wrong. And with the first three, the answer is almost never sorted out by itself.

The law: the maker owns it, not the payer

This is the part that surprises most business owners. Article 1 of the Dutch Copyright Act says copyright belongs to the maker. Whoever thinks it up and types it holds the right. Article 7 makes one exception: if your own employees make it, you as the employer are the maker. But an outside agency is not your staff. Hire someone in and they are the maker, and they stay the owner, even though you paid the whole bill.

It can be transferred, but not casually. Article 2 of the same act requires the transfer to be in writing, by a separate deed. And there is a line that is easy to miss: the transfer only covers what is explicitly stated. So a sentence like we transfer all rights is weaker than it sounds. Whatever is not spelled out does not travel with it.

To be clear: this is not a story about bad companies. Most builders have no plan to lock you in. It simply is not written down anywhere, because nobody asked. Which is exactly why it is so easy to fix, upfront, in two sentences, while everyone is still cheerful.

Whose name is on the accounts?

In practice this matters more than the paperwork. You can own everything on paper and still not be able to get in. That happens when the whole thing runs on your builder's account: you get a monthly invoice with a line on it, and you have never logged in to the place where it actually happens. While the relationship is good, you notice nothing. The day you want to switch, you notice immediately.

Five questions that sort this out in ten minutes:

• Whose name is on the server or account where the automation runs?
• Who pays the AI model supplier: you directly, or your builder who passes it on?
• Who can revoke the keys to your own systems, you, or only your builder?
• Where is what the system has learned kept: the examples, the corrections, the standard answers?
• If your builder ceases to exist tomorrow, does it simply keep running until you have something else?

That last one is the real test. The answer you want is yes, because it runs under your name and someone else can take over the maintenance. If you get hesitation, you know enough, not because anyone is up to no good, but because something still needs arranging.

The most valuable part is the least visible

In the first months an automation mostly improves through corrections. This answer is not quite right. We do not talk to customers like that. This exception needs adding. All those small adjustments together are why it works well after six months and did not in week one. They are also the one part you cannot buy again: a new party can rebuild the technical side, but not those six months of watching over it.

Yet this appears in almost no contract. Make sure it comes with you when you leave, in an ordinary file you can open, not a presentation, not a screenshot, but the text itself. Exporting it costs your builder ten minutes and saves you weeks when you switch.

Source code in escrow: right idea, wrong size

The standard fix from the software world is escrow: your builder deposits the source code with an independent party, and if they collapse or the argument gets ugly, you get the key. Fine instrument. But look at the price. Softcrow, one of the Dutch providers, publishes it openly: 1,250 euro one-off set-up and 1,440 euro per year per package, excluding VAT. Want a check that the deposited package actually works, and that inspection costs 2,895 euro.

For the system your whole company runs on, that is money well spent. For an automation of a few thousand euro it is out of proportion. There is a far cheaper route: make sure it stands in your name from day one. Your own server in a Dutch data centre starts at 5 euro a month at TransIP, excluding VAT. Then you do not need to insure access, because you have it.

Owning it is not the same as being able to use it

Here we have to be honest, even though it is less pleasant to sell. You can own everything and still be stuck. If it was built with home-made tooling nobody else knows, if there is not a line of documentation, or if the only person who understands it just moved to the Philippines, then you have paper ownership and nothing else. Being locked in is rarely only a legal problem; it is usually a practical one.

Three things make the difference, and you can ask about all three upfront. One: is it built with common tooling another party will recognise? Two: is there an explanation an outsider can read, rather than a list of technical terms? Three: is there a record of what changed and when? That last one looks like bureaucracy, but it is the first thing a new party asks for.

And count on maintenance, because an automation never stands entirely still. The systems it talks to change, an update arrives, a supplier adjusts something. Roughly once a month there is something to bring up to date. Whoever takes it over has to be able to do that, a more realistic question than whether they may have the code.

Five things to put in writing before you sign

• Who becomes the owner of what is built. In writing, with the word copyright in it, settled at the order, not at delivery.
• Whose name the server and the accounts are in. The answer you want: yours.
• What comes with you if you stop: the instructions, the explanation, what the system has learned and the data inside it, in a file you can open yourself.
• The notice period and what a handover costs. An amount or a number of hours, agreed upfront, not to be discussed later.
• Who does the maintenance, how often, and what happens if your builder stops doing it.

This fits on one page and costs you one conversation. If a party will not put it on paper, you have just gathered the most important information of the whole project, before anything has been built.

When you do not need to worry about any of this

Not every automation deserves this paperwork. If it is a small thing of a few hundred euro that someone else could rebuild in a day, the exit arrangement costs more than the risk. Overdoing it is also a mistake. Our rule of thumb: if it touches your primary process, orders, invoices, customer contact, or rebuilding it would take more than a week, arrange it properly. Below that, just make sure the accounts are in your name. That catches nine out of ten problems.

And if the answer is that your current set-up is fine as it is: also good. We say so just as plainly when something is better done by hand or better left where it is. There is plenty to automate that does pay off.

What you can do this week

• Pull up the last quote or agreement from your automation supplier and search for the word copyright. If it is not there, it is not arranged.
• Log in once to the place where your automation runs. If you cannot, you know what to sort out first.
• Ask for an export of what the system has learned. If you get it within a week, you are in good shape.
• About to have something new built? Put the five points above in your request, before a single euro is spent.

We ourselves work on a monthly cancellable basis with no long-term contracts, that is not a coincidence, it is the same thinking as above. A client who can leave is a client who stays because it works.