Who owns the AI system after we leave?

in Australia, if you do not have it in writing, the contractor owns the copyright in the code they wrote for you. Not you. That is the opposite of the American default, which is what most articles on this topic are describing, and it is why "we paid for it, so we own it" is not a legal position here.

So the question is not whether your agency is trustworthy. It is what your agreement says, and whether anyone has read it since it was signed.

Here is ours. Actual clauses, actual numbers, including the parts that are negotiable.

Why the Australian answer is different

Worth getting this out of the way, because it is the single most commonly repeated mistake in this area.

In Australia, intellectual property created by a contractor belongs to the contractor unless the contract says otherwise. Source code, executable code, data structures and documentation are automatically protected by copyright from the moment they are created, with no registration required, and that copyright sits with whoever wrote them.

The American doctrine people are half-remembering is work for hire, which operates differently. If your understanding of "we commissioned it, so it is ours" came from a US blog, a US template, or a US-trained assistant, it is wrong here.

Practical consequence: the assignment has to be written down. Every time. There is no default that saves you.

Who owns the prompts and the code?

Split it into two piles, because conflating them is where every argument starts.

The thing built for you

Your workflows, your configuration, your integrations, the logic that exists because your business works the way it does. In our agreements, that assigns to the client on full payment.

We set the transfer point at payment rather than at creation so that ownership and payment stay aligned. That is a position we have had to explain in writing more than once during contract review, and it is a fair one in both directions.

The tools it was built with

Our frameworks, templates, components, patterns and know-how. The things we bring to every project. Those stay ours, and you get a licence to keep using them as part of what we delivered, permanently, including if another provider takes it over.

The plainest version of this we have ever written was and it is the test we would apply to any agency:

Anything built for ICRAR is yours. The tools and methods we use to build it stay ours, and you keep the right to use them in your site forever.

Why the second half exists: every developer alive starts from a boilerplate. If we assigned ours to you, and you later saw the same header structure on another company's website, it would look like we sold you something we reused. We did not. Everyone reuses it. That is what a boilerplate is.

The part specific to AI, which most contracts miss

Here is where a website-era IP clause quietly fails you.

In an AI build, the real asset is not the code. It is the prompts, the tool definitions, the evaluation sets and the configuration. That is where the accumulated knowledge of how your business makes a decision actually lives. Six months in, the prompt is worth more than the plumbing.

Our own agreement is explicit that AI systems, tooling, prompts, configurations, models, software and infrastructure used or developed to deliver the services remain our property, and that nothing transfers except by a separate written assignment, agreed and quoted.

We are telling you that plainly because it is a negotiable, and you should know it is one before you sign rather than after. If those artefacts matter to you, ask for them in the assignment and expect it to be priced. What you should not accept is a contract that is silent on them, because silence resolves in the contractor's favour in this country.

Whose API keys is it running on?

This is the question almost nobody asks and the one that decides whether you actually control the thing.

Our arrangement runs in two phases, and it is worth copying whoever you are buying from.

During the build, model and API usage runs through our own Claude account and is billed to you on the same terms as the rest of the fees. That keeps the work moving without waiting for procurement to open a new vendor account, which can otherwise add weeks before a line of code is written.

On deployment, it crosses to your account. Your own Claude account, with a single dedicated API key allocated so that only your traffic goes through that key. Not a shared pool, not our key with your workload sitting on it.

After that, usage runs prepaid: a balance, typically topped up to $500, which automatically replenishes back to $500 when it falls to around $50, with the balance and the usage visible on your own dashboard.

Two reasons that matters more than it sounds:

1. If the relationship ends, the system keeps running, because the credential it runs on is yours. Nobody has to do an emergency migration during a period when the two parties are not getting along.
2. You can see what it costs, monthly, without asking us. An AI system whose running cost you cannot see is not really yours yet.

If your provider will not put the production workload on your own key, ask why. There are legitimate answers, particularly during a build. There are also answers that mean you cannot leave.

What happens if we stop paying you?

Our fixed-project agreement answers this in one clause, and the useful part is the specificity.

On expiry or termination, within 30 days and using reasonable endeavours, we must delete or destroy all client materials in our possession, cease all use of and revoke our own access to your systems, credentials and API keys, and on written request confirm in writing that we have done it.

The carve-outs are stated too, because a clause with no carve-outs is a clause nobody can honour: routine system backups that will be overwritten in the ordinary course of the backup cycle, and records we are required to retain by law, by our insurers, or to resolve a dispute.

Read that as a template for what to demand. A vendor exit clause should:

• name a number of days,
• name the credentials specifically, not just "your data",
• offer written confirmation on request, and
• state its carve-outs honestly.

"We will return your data on request" is not a commitment. It is a sentiment.

One more thing worth asking for, which came out of a negotiation with a client -  third-party models accessed under zero-retention terms using dedicated, scoped keys for you specifically. That single sentence answers "where did our data go" at the contract layer rather than the architecture layer, and it is much harder to argue with later. In the same negotiation we tightened breach notification to 48 hours, with 24 hours for eligible breaches.

What do you hand over, and when?

Ask for the handover contents at the start, not at the end. Anyone who has actually done this can list them on the spot.

What a complete AI handover contains:

1. The repository, with history, in your organisation rather than ours.
2. The prompts and tool definitions as versioned files, not screenshots and not pasted into a document.
3. The evaluation set, so the next team can tell whether their change made things worse.
4. The credential inventory: which key runs what, whose account it sits in, who can rotate it.
5. The architecture diagram with the regions labelled.
6. The runbook for when it breaks, including what to alert on.
7. The list of every automated decision the system makes about a person, which you will need for your privacy policy anyway from 10 December 2026.

If a provider can hand over items 1, 2, 5 and 6 but not 3, 4 and 7, that is not a bad provider. That is a normal one. It is also a fair indication of how much of the build was deliberate versus assembled and hoped for.

Item 3 is the one to push hardest on. Without an evaluation set, the next team cannot safely change anything, which means in practice they will rewrite it, which means you pay for it twice.

The bit that only applies if you are regulated

If you are an APRA-regulated entity, this stops being a philosophical question about ownership and becomes a filing.

CPS 230 commenced on 1 July 2025 and brings material service provider obligations with it, including a register that goes to APRA. So "who owns the AI system, and what happens if that provider disappears" is something you may have to answer on paper, about us, to your regulator. We would much rather you asked us that in month one than in month fourteen.

The related standard, CPS 234, covers information security and is the other one that decides whether a build clears risk review.

Ask your provider for theirs in those terms. The specificity of the answer tells you most of what you need to know about how many of these conversations they have had.

The questions to actually ask

Take these into your next vendor conversation. None are unfair, and all are cheaper to ask now than to discover later.

Frequently asked

We already signed an agreement that is silent on prompts. What now?
Raise it at renewal or as a variation. It is a much easier conversation while the relationship is good, and most providers will deal with it reasonably because the alternative is a fight later.

Is a perpetual licence as good as owning it?
For most operational purposes, close. The differences bite in two places: whether you can modify it freely, and whether you can hand it to a competitor of your provider. Read what the licence permits, not just that one exists.

Should we insist on owning the agency's frameworks?
No, and be suspicious of anyone who agrees. A provider who assigns their reusable components to every client either does not reuse anything, which makes them expensive, or is promising the same thing to several people.

What if the code was written mostly by AI?
It does not change the contractual question, which is about what your agreement assigns. It is worth asking your provider how they handle it, and worth noting that in Australia the copyright position for material generated without a human author is unsettled. Get the assignment written anyway.

Who should own this internally?
Whoever signs the agreement needs to understand it, but the person who should be asking these questions is whoever will be left holding the system. That is usually not the same person.

Where to go from here

If the question you actually have is about internal roles rather than vendors, we wrote that up separately in who should own your CRM. Our full security, hosting, subprocessor and data return position is published in the Trust Centre, and the cost side of running a system on your own key is in Breeze credits or your own API key.

If you would rather see what we have actually built and handed over, the work is at nbh.co/work.

Worth a thought before your next renewal. If your current provider walked away on Friday, what would you need on Monday, and do you have it?

General information about our own contracting position, not legal advice. Get your own.

Sources

• IP Australia, who owns intellectual property
• APRA CPS 230, Operational Risk Management
• APRA CPS 234, Information Security
• Voluntary AI Safety Standard, National AI Centre
• ISO/IEC 42001, AI management systems