While Australia has no dedicated AI legislation, existing technology-neutral frameworks, including the Privacy Act 1988 (Cth), the Copyright Act 1968 (Cth), Australian Consumer Law, and anti-discrimination statutes, readily apply to regulate the deployment and use of AI systems and their outputs.
Regulatory considerations aside, AI engagements carry the same project delivery risks familiar to any complex technology procurement: performance management, milestone slippage and personnel dependency.
For businesses commissioning bespoke AI tools, whether custom-trained models, automated workflows or AI-powered integration solutions, the development contract is a key instrument that may be utilise to manage risk. It can shape what the developer builds, how it builds it, and what data it uses along the way.
Below, we provide some practical tips that Australian organisations might use in their AI procurement contracts to manage developer risk across the AI development lifecycle.
The strategies presented here are more relevant to more complex, data-intensive bespoke builds and may not be suitable for shorter-cycle engagements.
Each should be assessed on a case-by-case basis, driven by your business needs, the nature of the engagement and your organisation’s risk appetite.
Tip 1 | Cast compliance obligations broadly
Rather than tying the developer’s compliance obligations to specific pieces of legislation included in a contract, a preferred approach is to include a catch-all definition to cover relevant laws, regulations, regulatory guidance, mandatory standards, and industry codes of practice applicable to artificial intelligence or automated decision-making.
This may encompass privacy legislation, consumer law, copyright, and any law applicable to artificial intelligence or automated decision-making, and the project more generally, in the relevant jurisdiction. As an obligation of the engagement, this approach requires the developer to stay across the AI regulatory landscape, which will no doubt evolve over time.
Tip 2 | Embed responsible AI obligations in the contract
Australia’s voluntary AI Ethics Principles, published by the Department of Industry, Science and Resources, provide a useful normative benchmark as to what responsible AI development looks like, and one option is to embed them in a contract as binding obligations on the developer, otherwise, they remain purely voluntary.
Once incorporated as contractual requirements, a breach may trigger termination rights, damages claims or indemnities.
In practice, this might mean requiring the developer to build with appropriate human oversight mechanisms, deliver transparency and explainability in the system’s decision-making processes, and conduct reliability and safety testing before deployment. Organisations may also wish to consider reserving the right to contest or seek human review of automated outputs, particularly where those outputs may have a material impact on end users, or where, during early deployment, confidence in the model’s behaviour is still being established.
Tip 3 | Address risks in using training data
Copyright risk is a key area of potential developer exposure in the Australian AI context, particularly where the engagement involves training or fine-tuning a model on new datasets. Unlike the United States, Australia has no broad fair use exception and its narrower fair dealing defences are unlikely to cover wholesale ingestion of copyrighted material for commercial AI training, meaning copyright risk for AI systems deployed in Australia will likely be greater.
The overseas litigation landscape demonstrates why this matters. In the United States, The New York Times v Microsoft and OpenAI and Getty Images v Stability AI both allege large-scale training on copyrighted content without permission. In November 2025, the UK High Court handed down = the first major ruling on AI and copyright in Getty Images, confirming that AI copyright liability is a live and evolving risk. With the US cases still progressing, if a developer trains a model on unlicensed data, the organisation deploying the system may find itself holding the risk.
Several contractual mechanisms address this risk directly: a prohibition on the developer using training data obtained in breach of third-party intellectual property rights; warranties that all training data has been lawfully collected, sourced and licensed in compliance with the Copyright Act 1968 (Cth); audit and record-keeping obligations giving the organisation ongoing visibility into the developer’s data practices, including by maintaining a register of training data sources; and IP indemnities specifically covering the provenance of training data.
However, a degree of commercial pragmatism is necessary. Where a developer has drawn on large-scale datasets or pre-trained foundation models with opaque provenance, the question becomes one of risk allocation: can the developer credibly stand behind an indemnity, or does the organisation need to accept a residual level of risk and manage it through operational practices such as output filtering, usage restrictions or internal review processes?
Where the developer is training on the organisation’s own datasets, the organisation should consider whether the developer’s use of that data is appropriately scoped and restricted and including limitations on the developer using the organisation’s data to train models deployed for other clients, and obligations to delete or return the data once the engagement concludes.
Tip 4 | Safeguard personal information through privacy obligations
AI systems are frequently trained on, or operate upon, data that includes personal information. Under the Privacy Act 1988 (Cth), it is typically the organisation that bears the regulatory exposure if things go wrong, regardless of whether it was the developer that caused the breach. The contract can therefore play an important role in extending the organisation’s privacy compliance obligations into the development process.
The contract may usefully address several areas: restrictions on the developer incorporating personal information in training data without demonstrated compliance with the Privacy Act and Australian Privacy Principles; prohibitions on offshore transfers or third-party processing without the organisation’s express written approval; and obligations on the developer to notify data breaches within vigorous timeframes (for example, within 24 to 48 hours of becoming aware of a suspected breach, to give the organisation time to meet its own notification obligations under the Notifiable Data Breaches scheme).
Data sovereignty is a further consideration. The developer may use cloud infrastructure hosted offshore or subcontract processing outside Australia. The Australian Privacy Principles impose accountability on the disclosing entity, meaning the organisation may be exposed if an overseas recipient mishandles data. Requiring the developer to obtain written approval before disclosing personal information outside Australia, and before engaging third parties to process it, are prudent steps. In some cases, organisations may require that all personal information be stored and processed exclusively within Australia or comparable jurisdictions.
Tip 5 | Require robust information security commitments
Contractual security obligations worth seeking include: requiring the developer to maintain an information security management system aligned with a recognised standard such as ISO/IEC 27001; periodic penetration testing by an independent third party with remediation obligations for critical findings; audit rights; and cyber risk insurance covering network security liability and data breach response costs. Where personal information is involved, the contract should also specify concrete technical requirements such as data minimisation, role-based access controls, pseudonymisation where practicable, and secure deletion at end of engagement.
Tip 6 | Plan for regulatory change
A regulatory change mechanism might oblige the developer to track evolving laws, notify the organisation of material changes, assess the impact on the system, and propose compliance updates with agreed timeframes and cost-sharing arrangements helping avoid a situation where the organisation is left with a non-compliant system because the developer failed to keep pace with the law. This mechanism might also address who bears the cost of compliance updates (particularly where regulatory change requires material re-engineering), what notice periods apply, and what happens if the parties cannot agree on the scope or cost of required changes.
Tip 7 | Lock in performance management governance
Even where AI-specific provisions take centre stage, standard technology procurement governance should not be overlooked – particularly for substantial bespoke builds.
Key mechanisms include:
- key personnel clauses requiring consent before substitution
- milestone-based progress reporting and formal acceptance testing with rejection rights
- payments structured around milestone achievement rather than time elapsed
- a joint steering committee (where the scale of the engagement warrants it)
- structured defect remediation obligations with severity levels and response times
Key takeaways
Australia’s existing regulatory frameworks impose obligations on organisations developing and deploying AI, and the AI development contract remains one of the most practical tools for managing the risks that an AI procurement engagement may introduce. When entering into a new AI development agreement or revisiting an existing one, it is worth considering whether these risks are adequately addressed before the developer moves on and any exposure becomes the organisation’s alone.
Our commercial law team regularly advises on AI procurement contracts and AI development agreements across a wide range of industries. If you would like to discuss how these considerations apply to your specific AI development engagement, please get in touch.
This article is intended as general information only and does not constitute legal advice. You should seek specific legal advice before acting on any of the matters discussed.