Intellectual property and AI – Retro-fitting current frameworks for new concepts

Artificial intelligence (AI) may be transforming how we work with information, but it’s also raising a number of questions as to what we ‘own’ – both as to what goes in, and what comes out.

For instance, the Productivity Commission’s interim report into Harnessing Data and Digital Technology identified that restrictions on the use of ‘text and data’, particularly those imposed by copyright law, may impede the advancement of AI, despite the Commission’s assessment that such innovation could deliver strong economic benefits to Australia. Arts and media groups have strongly challenged this position, concerned that these new technologies may exploit artistic content without appropriate attribution or compensation, and without many Australians being any the wiser.

These developments create a number of challenges for businesses developing or procuring AI. There is a tension between taking up the opportunities of these new technologies in a rapid, frictionless manner and the need to manage ownership of key information, both the information organisations put into AI tools (Inputs) or generate from AI tools (Outputs), and the information used to create those tools in the first place (Training Data).

This article outlines the status of Inputs, Outputs and Training Data in Australian intellectual property (IP) law, offering practical steps for businesses to protect their IP when using or developing AI products.

Rights in data – who owns the data we collect or produce?

Under Australian law, data (whether an Input or Output) is not classified as property. This is because information is fundamentally fungible, unlike physical assets such as say a house or a car. Rather, ownership of data is governed at the complex intersection of:

1. The Privacy Act 1988 (Cth) – creating some rights and protections in favour of individuals over data that is also personal information. However, this will only apply to a subset of data, being “personal information” (data that can identify someone), meaning a lot of data or code may not be covered by the Privacy Act at all.

For example, a spreadsheet of customer data including names, email addresses and phone numbers will generally be personal information under the Privacy Act. But, a list of customer phone numbers may not be personal information, provided you can’t reasonably identify someone from that number.

2. IP rights – creating some kind of ownership over certain kinds of information. Copyright is particularly relevant when dealing with data, given it, among other things, protects ‘literary works.’ These cover the unique expression of a range of common data types (e.g. Excel spreadsheets, CSVs, JSON, etc.), as well as code, in a ‘material form’ (i.e. written down), and protects that data/code from being used without the owner’s permission.

For example, raw datapoints are not protected by Copyright. However, the underlying expression of that data, such as in a novel database (e.g. a unique description or creative selections/arrangement) may be protected.

3. Contractual arrangements – granting ‘personal’ rights which can be exercised against a counterparty. These can include requirements for data to be used or protected in a certain way, including confidentiality obligations, but will fundamentally depend on the specific arrangements agreed to by the relevant parties.

For example, purchasing a new human resources information system will involve a set of terms and conditions. These may set out conditions as to the kinds of information that can be processed via that system, such as to provide the system, and to permit the supplier to run some general system analytics.

IP rights in AI tools – who owns a developed model?

This complexity applies both to organisations holding a dataset, and to those developing AI tools.

Assuming the source code of an AI tool has not been substantially copied from another, and the source code was written by an individual developer, then it is likely that the individual developer will own copyright in the source code that enables the AI tool to run.  This extends to the source code giving effect to the mathematical ‘model’ used by that AI tool to process Inputs and generate Outputs.

Whether an organisation owns the copyright for an AI tool depends on the contracts it has with individual developers.  For example, employment or contractor agreements may include terms requiring that any copyright created is automatically assigned to the organisation at the time of creation.  The ‘owner’ may also seek additional protections, such as a patent or a design registration to protect new innovative AI tools or unique user experiences.

However, an AI tool’s model will also rely on a large amount of Training Data. These are specific Inputs that are used to teach the model how to handle new and unexpected situations, with ownership, or rights to use, each training Input being governed by each of the above restrictions.

This is precisely the scenario identified by the Productivity Commission, which proposes expanding ‘fair dealing’ exceptions to copyright, currently only for research and study purposes, to permit the broader training of AI tools from text and data.

Inputs and Outputs – an example

Given the above, ownership of Inputs and Outputs will depend on the specific arrangements in place for a given business, and the AI tool it looks to use. For example:

1. You may be looking to use an AI tool to process your dataset to generate a helpful graph or infographic.
2. The provider of that tool (Provider) will generally have implemented terms of use. In this scenario, let’s assume those terms permit the provider to use your Input to generate the Output, but also to then use both the Input and Output to train the AI tool’s underlying model. This is a fairly common operating model to ensure modern AI tools like large language models have access to the scope of information they need to maintain accuracy and expand their capabilities.
3. You:

a. would be able to use the AI tool so long as you own all relevant rights in the Input dataset, and are able to share it with the Provider without breaching the Privacy Act (note, you may need to consider if you’re comfortable with potentially commercially sensitive information then being sent ‘out in the wild’ for the Provider to use when improving their product); and

b. would not be able to use the AI tool if you have received the Input under a contract with another party (i.e. the copyright holder, or licensee) and that contract does not let you share the Input with the Provider.

4. Where you do end up using the tool to generate an Output, you would only be able to use that Output on the terms set out by the Provider. That could mean:

a. to the extent it’s possible to ‘own’ the Output, as a combination of the above rights, the Provider may grant you that ownership – meaning you can potentially enforce protections in the Output. This is the approach generally taken in OpenAI’s terms of service for ChatGPT; or

b. the Provider retains ‘ownership’ of the Output and grants you a licence / contractual right to use it in a particular way – such as permitting you to only use the Output where you leave a note attributing it to the Provider.

We note these rights are somewhat unclear however given copyright protection in Australia requires a work to be original, involving some exertion of independent intellectual effort by a human. To that end, there is an open question as to whether Outputs are deemed to have been created by a human with the assistance of an AI tool, or by the AI tool itself. The prevailing view however is that the human them self (or their employer or principal, depending on the context) will be the ‘owner’ of that work.

Furthermore, even if you do ‘own’ that Output, there is a risk the Output could reproduce or echo substantial parts of other copyrighted works (e.g. existing artwork). This may amount to an infringement of the copyright in that other work.

How can you manage your data?

Considering the complex state of data ownership in Australia businesses need to understand both how their data will be used by AI tools they procure, and how to protect data they use to create those AI tools in the first place.

For developers, it’s important to:

1. Have a plan in place to manage how you collect Training Data, including measures to address:

a. where this data can be sourced from;

b. the kind of rights you’ll require (including licences to relevant IP); and

c. checks and balances to avoid misuse of any personal information (including to avoid illegal surveillance or unauthorised scraping activities).

2. Manage IP ownership within your organisation, including ensuring IP is held by the appropriate entity so that you can ‘license out’ your AI tool to customers under the entity. This will generally involve IP being owned by your company, not your employees or contractors. But, you may need to assess how this is best done in view of taxation and other corporate structuring obligations.
3. Manage your customer and supplier contracts closely, to ensure the following:

a. transparency as to how you’ll use your customer Inputs, including as to whether you use them to train your tool, and as to who ‘owns’ Outputs;

b. you receive sufficient rights to use customers’ Inputs, such as by requiring customers to warrant they have obtained all relevant rights/consents to share an Input with you; and

c. third party suppliers align with those practices – such as by protecting information and, providing storage/processing services, in the way and at the locations you would expect.

4. Ensure compliance with other relevant laws, including the Privacy Act. This means ensuring your tool does not misuse personal information contained in an Input, and taking steps to protect any such personal information, or de-identify it so as to mitigate privacy risks.

When procuring AI tools, it’s important to:

1. Undertake due diligence before introducing any such tools. This should include:

a. a targeted questionnaire to assess the Provider’s information and cyber security controls, data protection and retention measures, and the management/storage of Inputs and Outputs, including any disclosures to other organisations;

b. an assessment of how the Provider’s terms of service will manage ownership of Inputs and Outputs, including to ensure you have sufficient rights to use the Output in the way you intend; and

c. if necessary, obtaining assurances that the Provider will not use your Inputs as Training Data, or otherwise without your consent.

2. Assess the rights you have in your existing information to understand if you are able to use it as an Input. This includes assessing whether:

a. your proposed use of the Input, and disclosure to the Provider, will comply with the Privacy Act and/or other applicable privacy laws; and

b. you have sufficient other rights, whether in respect of copyright and/or applicable contracts/licences, to provide the Input to the Provider as contemplated by their terms and conditions.

3. Be transparent with your own customers about how you may use their information. This should include:

a. ensuring your privacy policy and privacy collection statements are clear and transparent as to how you will use AI to process personal information. This is particularly important if you will use an AI tool to make automated decisions about someone – noting additional requirements to describe this will come into force from December 2026; and

b. updating your customer contracts to ensure you have sufficient rights to process information via that AI tool. This may mean ‘marrying up’ requirements under the Provider’s terms of service against your own agreements to ensure you have obtained all relevant rights.

4. If your Inputs include personal information, ensuring you only provide this information where authorised under the Privacy Act (i.e. for the primary purpose for which it was collected, or a permitted secondary purpose).
5. Implement internal policies to ensure your staff comply with these requirements, such as by restricting the kinds of information that can form an Input, or whitelisting certain Providers, alongside an ‘AI Use Policy’ (or similar).

In either case, it is also critical to ensure alignment with community expectations regarding the use of AI, such as the expectations set out in Australia’s voluntary AI safety standard and AI ethics principles.  While these are not strict legal requirements, they reflect the need to use emerging technologies, and manage Inputs and Outputs responsibly, noting the potential for significant harm where these tools are developed or deployed carelessly.

We understand that staying on top of new and emerging technologies is an ongoing challenge. To support you on your journey with AI, our team has prepared this useful take away reference document that summarises the key risks and considerations when developing or procuring new AI tools.

Our team will keep sharing AI tips and updates in 2026. In the meantime, please do not hesitate to contact us if your team is working through these requirements or looking for guidance on how to manage AI responsibly.

If you found this insight article useful and you would like to subscribe to Gadens’ updates, click here.

Authored by:

Dudley Kneller, Partner
Raisa Blanco, Special Counsel
Chris Girardi, Associate
Jayarupi Pahala Vithana, Lawyer
Timothy Mikhail, Seasonal Clerk