On this page

Disclaimer

The information provided in this guidance is general in nature and is intended to assist you to self-assess the eligibility of your R&D activities. If the Department of Industry, Science and Resources undertakes a formal review, your activities will be assessed against the legislative criteria set out in sections 355-25 and 355-30 of the Income Tax Assessment Act 1997.

What are AI-related activities?

AI represents an emerging and evolving area within the broader software sector. As AI is part of software development, the Software development sector guide for the R&DTI page also applies to AI‑related activities and should be reviewed before reading this guidance.

AI‑related R&D activities may involve developing AI models or using AI within software systems. This includes:

  • scoping and designing AI‑enabled solutions
  • developing and training AI models
  • testing and evaluating model performance
  • integrating AI into software applications and platforms
  • deploying models into operational use
  • monitoring, updating, or maintaining AI systems over time.  

While often associated with the software sector, AI is increasingly used across many sectors such as healthcare, agriculture, resources, and advanced manufacturing.

Common risk areas for AI-related R&DTI applications

When self-assessing your eligibility for the R&DTI, there are some common risk areas to be aware of if you are undertaking AI-related activities.

Using an AI model or technique that is new to you does not, by itself, mean the activity is eligible for the program. For an AI-related activity to be eligible as a core R&D activity, it must aim to resolve a technical hurdle where a proposed solution (the hypothesis) is tested through planned experiments.

For example, while the following activities may be complex, they are unlikely to meet the requirements of core R&D activities because they can generally be addressed by experts in the field using existing knowledge and solutions:

  • implementing logging, alerts, dashboards, or routine performance checks using established methods and tools to confirm expected model behaviour
  • cleaning, formatting, and aligning data to meet a model’s documented input requirements using standard data preparation techniques, where the transformations required are known in advance
  • running regression, acceptance, or functionality tests using established testing methods to confirm a system works as intended, where expected outcomes are already known
  • adjusting or fine-tuning parameters (e.g. learning rate) using established methods when it is known that the issue can be solved by parameter changes and the effect of changing the parameter is well understood
  • integrating known model outputs (such as scores, labels and recommendations) into applications or dashboards, using pre‑defined logic, rules and interfaces, where the behaviour of the model and the integration approach are established.

How AI-related activities may be eligible R&D activities

AI‑related activities are eligible R&D activities when they meet the requirements for core R&D activities or supporting R&D activities. These requirements do not depend on the technology used. As such, using AI in software development does not make an activity eligible.

AI-related activities may meet the requirements of a core R&D activity where a technical hurdle exists and an expert in the field considers that only experimentation will determine if a proposed solution, or the way to develop a solution, can resolve the technical hurdle.

The following examples illustrate AI‑related activities that may be able to meet the requirements for core R&D activities as they may involve a technical hurdle that can only be resolved through experimentation:

  • Investigating whether a novel AI model fine‑tuning strategy, whose effects are not well-understood and which has not previously been applied in a comparable AI‑deployment environment, could resolve scalability issues in AI systems where established methods have failed.
  • Experimentally testing an AI architecture to solve domain-specific performance limitations, when it is not currently known if it can work effectively in the target domain or cope with the available data regime.

Activities that do not meet the requirements of core R&D activities may qualify as supporting R&D activities.

Examples

The following hypothetical examples are designed to help you better understand the eligibility requirements of the R&DTI and identify which of your activities may qualify for the program. These examples provide general guidance only and do not replace the legislative definitions.

Example 1: research existing technologies to build an AI chatbot

This example explains why desktop research into currently available technologies to inform the technology stack design of an AI chatbot does not meet the requirements for a core R&D activity. It shows how the outcome and the design of the technology stack can be determined using existing knowledge, rather than through experimentation.

Scenario

A company plans to implement an AI chatbot using retrieval augmented generation (RAG) to provide information that is specific to a workplace and always up to date. The company has already decided what the chatbot will do and has determined it can use existing AI and chatbot platforms to deliver this outcome more quickly, with proven technology and less risk.

Its first step is to review existing technology and know-how to decide on the technology stack design. After the technology stack has been decided, the company will then implement the chosen technologies and software.

The activity

The company conducts desktop research for available and proven platforms, AI models, frameworks, methods and RAG pipelines.

The search includes both open-source and vendor products as well as product reviews, articles, tutorials and videos about how these products are implemented in practice. The company maintains records covering:

  • product recommendations and relevant comments about benefits and limitations
  • notes, videos and tutorials about implementation.

Once the company has gathered enough information, the results are evaluated to decide the technology stack, which is recorded for the initial software bill of materials for the chatbot.

The company concludes that it knows how the chatbot can be implemented to meet its design specifications by using existing and proven technologies. It is confident it has the expertise to resolve any bugs or integration issues that it may encounter.

Outcome could be known or determined in advance

Core R&D activities occur when a technical hurdle exists that can only be resolved by conducting hypothesis-driven experiments. In this example, the activity does not involve a technical hurdle that readily available knowledge, information or experience, could not resolve at the time the activity was conducted. Instead, the company relied on existing information about platforms, AI models, frameworks, methods and RAG pipelines to determine the appropriate technology stack to develop its chatbot.

As there is no technical hurdle, the company does not need to apply a systematic progression of work that starts with testing an idea through experiments.

Example 2: research new chunking methods for an AI chatbot

This example explains how researching technologies could be a supporting R&D activity when it is directly related to a planned core R&D activity that has not yet started. The activity shows how the information collected from the research activity helps in refining the hypothesis and designing the experiment for the planned core R&D activity.

Scenario

A company has created a technology stack design for its AI chatbot which uses retrieval augmented generation (RAG) and is aware of common problems of inconsistent answer quality, poor handling of long or complex documents, and irrelevant context being retrieved for certain queries. AI researchers and the software development community believe new dynamic chunking methods could resolve these issues. The company is aware these new methods are still theoretical and not able to be used in a production release unless they could be shown to work on real-world data.

The company is planning an activity to determine how these new chunking methods could be used in its chatbot’s RAG chunking pipeline. Before it can do that, it needs to understand the new chunking methods so that it can refine a hypothesis to test these methods on real-world data.

The activity

The company conducts a desktop review of selected industry and technical publications as well as engaging with the AI development community through online knowledge bases, developer and learning platforms, technical blogs and forums. The desktop review finds reports of experiments benchmarking the chunking methods using artificial data. These reports explain the limitations that currently prevent validation for use with real-world data. Other publications describe how these new chunking methods could be validated for use with real-world data, including whether they can handle noisy data, cross-document reasoning and open-ended questions.

The company searches for the most up-to-date information about the new methods, including by posting questions to online knowledge bases, platforms, blogs and forums. These sources identify the mechanisms within the AI chatbot where these new methods could improve performance. They also provide practical information on how to test whether the theoretical approaches work in practice.

The company uses its desktop research to develop a better understanding of how these methods should work with real-world data to improve the chatbot’s performance.

Based on this research the company selects one promising new chunking method and identifies the variables linking this method to a specific effect. After outlining its success metrics, the company has refined its hypothesis and is ready to test it in an experiment.

Directly related to a core R&D activity

The company’s desktop research can be a supporting R&D activity because it is directly related to a core R&D activity. In this example, the desktop review was conducted specifically to provide the information needed to refine the hypothesis, experiment and evaluation for its planned core R&D activity. The previous and current investigations, along with decisions about the variables, metrics, hypothesis, and experimental methods showed the company’s intent and progress toward carrying out that core R&D activity.

Example 3: experiment on unproven document chunking methods

This example explains the process a company could follow to identify an activity whose outcome cannot be known or determined in advance and can only be determined by applying a systematic progression of work. It highlights the importance of first identifying a technical hurdle that existing knowledge, information or experience cannot resolve.

Scenario

A company has created a technology stack design for its AI chatbot which uses retrieval augmented generation. It aims to address known issues with retrieval performance and answer quality.

At the time the activity was conducted, the company’s background research confirmed that there were no existing solutions to address this technical hurdle. The company received advice from relevant experts that theoretical dynamic chunking methods could address these issues. However, these methods had not been tested with real-world data and experts could not predict how they would respond to noisy data, cross document reasoning and open-ended questions found outside artificial testing situations.

The activity

In an internal chat, the company discusses the advice from experts that it is not possible to predict the outcome of applying the new chunking methods to real-world data. It decides that it will need to develop and test its proposed solution (hypothesis) to improve chunk relevance, retrieval performance and answer behaviour.

The company conducts a series of runs to compare new and baseline chunking methods on the same real‑world data and queries. Each run is observed by measuring chunking and answer semantic similarity, retrieval context precision and recall, and answer faithfulness, with the results grouped by each chunking method.

The experimental results are evaluated by averaging the data for all runs for each chunking method and comparing them against the data for the baseline chunking method. The chunking and answer semantic similarity, retrieval context precision and recall, and answer faithfulness for the dynamic methods are then determined based on their statistical significance.

The company finds the uncertainty introduced by using real-world data has led to several assumptions within its hypothesis being proven wrong. Its hypothesis needs to be adjusted, and new runs conducted to test it.

Outcome cannot be known or determined in advance

This activity can be a core R&D activity because the company has identified a technical hurdle in improving retrieval performance and answer quality for its chatbot that is not known nor can be determined in advance using existing knowledge, information or experience. At the time the activity was conducted, the company’s background research found no available solutions which experts were confident would resolve the hurdle. A possible recommended solution was, at the time, only theoretical and no expert in the field could confidently predict how it would work with real-world data. At this point, the company decided it could not simply apply the solution but needed to test a hypothesis to determine whether and how the performance of a new chunking method would address the technical hurdle.