03 July 2026
AI development contracts in Australia need to do more than describe the software being built. They need to deal with data, privacy, copyright, ownership, testing, security and who is responsible if the tool gets it wrong.
AI projects are moving quickly. Businesses are commissioning custom chatbots, automated workflows, internal knowledge tools, customer service assistants, document review systems and AI-powered integrations.
That can be smart. It can also be risky.
The problem is that many AI projects are still contracted like ordinary software builds. That is a mistake. AI tools often rely on large datasets, third-party platforms, model outputs, automated decisions and ongoing changes after launch. A standard development agreement may not cover those issues properly.
The contract is where the risk should be sorted out before the build starts.
Australia does not need an “AI Act” for AI risk to be real
Australia does not currently have one single AI law that covers every business use of AI. But that does not mean AI sits outside the law.
Existing laws can still apply, including laws dealing with:
-
privacy and personal information
-
copyright and training data
-
confidential information
-
consumer law and misleading conduct
-
discrimination and automated decision-making
-
cyber security and data protection
-
ownership of intellectual property
The blunt point is this: if your business deploys the AI system, your business may be the one customers, regulators or commercial partners look to first if something goes wrong.
That is why the contract with the AI developer matters.
1. Be clear about what the AI tool is meant to do
A vague AI brief creates vague accountability.
Before signing, the contract should clearly describe:
-
what the AI system is being built to do
-
what it is not being built to do
-
what data it will use
-
what systems it will connect with
-
who the end users are
-
whether it will make recommendations, decisions or just support human review
-
what level of accuracy, reliability or performance is expected
This is especially important where the AI tool may affect customers, staff, pricing, eligibility, compliance, health, safety, finance or legal rights.
Do not just contract for “an AI solution”. Contract for a defined tool, for a defined purpose, with defined limits.
2. Make legal compliance part of the developer’s job
A developer may understand the technology. That does not mean they automatically carry the legal risk.
Your contract should require the developer to comply with all applicable laws, standards, regulatory guidance and industry requirements relevant to the AI project. Avoid wording that only lists today’s laws. AI regulation is still developing, so the contract should be broad enough to deal with legal change.
This can include obligations around:
-
responsible AI practices
-
privacy and data handling
-
copyright compliance
-
cyber security
-
transparency and explainability
-
human oversight
-
record-keeping
-
bias, safety and reliability testing
The goal is simple: the developer should not be able to say, “That was not our problem.”
3. Control the data going into the system
AI risk often starts with the data.
If the developer is training, fine-tuning or configuring an AI system, you need to know what data is being used and whether it can legally be used.
The contract should deal with:
-
whether third-party data is being used
-
whether that data is licensed or lawfully sourced
-
whether copyright material is included
-
whether personal information is included
-
whether confidential business information is included
-
whether your data can be used to improve tools for other clients
-
whether data must be deleted or returned at the end of the project
This is not a technical detail. It is a legal and commercial risk.
If the developer cannot explain where the training data came from, that should raise a red flag.
4. Protect your business data
Many AI projects involve sensitive business information. That may include customer lists, product data, internal documents, pricing, financial information, employee records, source code, trade secrets or commercially valuable know-how.
The contract should make it clear that your data remains yours.
It should also restrict how the developer can use, store, copy, transfer or disclose that data. In particular, you should consider whether the developer is allowed to:
-
upload your data into third-party AI tools
-
store data outside Australia
-
use subcontractors
-
use your data to train other models
-
retain copies after the project ends
-
combine your data with other client data
If the answer is no, the contract needs to say so clearly.
5. Deal with privacy before personal information is used
If the AI tool uses personal information, privacy cannot be treated as an afterthought.
The contract should address:
-
what personal information will be collected or used
-
whether consent is required
-
where the data will be stored
-
whether the data will be transferred overseas
-
who can access the data
-
how long the data will be kept
-
what happens if there is a suspected data breach
-
how quickly the developer must notify your business
A 24 to 48 hour breach notification window may be appropriate for higher-risk projects. Waiting a week to find out about a privacy incident can leave the business exposed.
6. Decide who owns the IP
AI development can create messy ownership questions.
The contract should deal with ownership of:
-
the underlying model or platform
-
custom code
-
prompts, workflows and configurations
-
training materials
-
fine-tuned model layers
-
documentation
-
outputs generated by the system
-
improvements made during the project
Do not assume that paying for development means you own everything.
Sometimes the developer will retain ownership of background technology. That may be reasonable. But your business still needs the rights required to use, modify, commercialise and maintain the system.
At a minimum, the contract should clearly state what your business owns, what it is licensed to use, and what happens if the developer relationship ends.
7. Build in testing, acceptance and human oversight
AI systems can produce confident wrong answers. They can also behave differently when exposed to new data, new users or new prompts.
That means testing should not be informal.
Your contract should include:
-
performance benchmarks
-
acceptance testing
-
error reporting
-
bias and safety testing where relevant
-
security testing
-
clear rejection rights if the system does not meet agreed standards
-
a defect correction process
-
human review requirements for higher-risk outputs
For many business uses, the AI tool should support decision-making, not quietly replace accountability.
If the output matters, a human should know when and how to check it.
8. Make the developer stand behind the work
Warranties and indemnities matter.
Depending on the project, the developer may need to promise that:
-
it has the right to use the technology it provides
-
the system does not infringe third-party IP rights
-
training data has been lawfully sourced
-
it will comply with privacy and security obligations
-
it will not misuse your confidential information
-
it will fix defects within agreed timeframes
For higher-risk projects, your business may also want indemnities for IP infringement, privacy breaches, confidentiality breaches, data misuse or security failures caused by the developer.
The practical question is whether the developer can actually stand behind those promises. A warranty from a small developer with no insurance and limited assets may not be worth much if the risk is serious.
9. Plan for legal and technical change
AI systems do not stand still. Laws, models, platforms and business uses can all change after launch.
The contract should explain what happens when changes are needed.
This may include:
-
who monitors legal and regulatory change
-
who pays for compliance updates
-
how updates are scoped and approved
-
what happens if a third-party AI platform changes its terms
-
what support the developer must provide after launch
-
whether the business can move the system to another provider
A good AI contract should not just get the project live. It should keep the business protected after the developer has moved on.
10. Do not forget basic project control
AI-specific clauses are important, but the basics still matter.
For larger AI builds, consider including:
-
milestones
-
staged payments
-
progress reporting
-
key personnel obligations
-
approval rights before subcontracting
-
steering committee meetings
-
clear delivery dates
-
support and maintenance terms
-
termination rights if the project goes off track
AI does not remove ordinary project risk. It adds another layer to it.
Bottom line
If your business is building or commissioning an AI tool, the contract should not be treated as paperwork to get out of the way.
It is where you decide who carries the risk for the data, the outputs, the IP, the privacy issues, the security controls and the system’s performance.
The worst time to negotiate those points is after the tool has launched and something has gone wrong.
IP Solved helps businesses review, negotiate and structure AI development contracts, technology agreements, IP ownership clauses, data protection obligations and commercial risk allocation before problems become expensive. Speak with IP Solved before you sign, build or deploy.
This article provides general information only and is not legal advice. Specific advice should be obtained for your business and product.
