Quick answer: An AI project may warrant assessment as potential R&D at the point where the outcome stops being knowable in advance — but technical uncertainty is only one of several conditions the law requires. If you're applying an existing model, API or documented method to reach a known result, that particular activity will generally be routine implementation. You reach a point worth assessing when a competent professional could not know or determine the outcome in advance on the basis of current knowledge, information or experience, and you resolve it through systematic experiment, based on established science, for the purpose of generating new knowledge. Even then, eligibility is generally self-assessed against all the applicable conditions. Recognising that moment early — and framing the hypothesis and experiment up front — is what protects a possible claim.
Most AI projects don't start as research. They start as a build. You have a chatbot to ship, an automation to wire up, an ML feature a customer asked for — and you reach for the tools that exist: an API, a pre-trained model, a documented technique. That's implementation, and there's nothing wrong with it. The hard question isn't whether you're using AI. It's whether, somewhere in the middle of that build, the work quietly stopped being implementation and became something a reviewer would recognise as experimental.
This article is about spotting that moment — the decision point, not the tax test. If what you actually want is the full eligibility framework (what counts as core R&D, how training, fine-tuning and APIs are treated), start with Is AI / ML development eligible? and don't re-derive it here. What follows is the earlier problem: how to recognise, mid-project, that you may have reached a line worth assessing — and what to do the moment you suspect it.
The Decision Point: Known Outcome vs. Genuinely Uncertain Outcome
A key distinction between routine implementation and potential R&D is whether the outcome of the specific activity could be known or determined in advance. It is not determined by difficulty, cost or technical sophistication. However, as discussed below, uncertainty on its own does not settle the eligibility question.
Implementation applies existing knowledge to reach a result you can reasonably predict. You might not know exactly how long it'll take, and it might be genuinely hard — but a competent professional in your field, looking at the problem, would expect it to work. Integrating a support chatbot on top of an existing LLM, training a standard classifier on your data, wiring an automation between two systems: the path is documented, the outcome is expected.
You reach a point where the activity may warrant assessment as potential R&D when the outcome becomes genuinely uncertain — when a competent professional, with access to relevant knowledge and resources, could not know or determine the outcome in advance on the basis of existing knowledge, information or experience, and experimentation is required to determine whether the proposed approach will work under the identified technical constraints.
Signals You May Have Reached the Decision Point
You rarely notice the moment in real time. But the signs are recognisable if you know what to look for. Ask yourself:
Am I applying a known method, or could I not determine the outcome in advance? If your team keeps saying "we don't actually know if this will work," that's a signal — not a problem to hide.
Has the documented approach failed for a reason I can point to? "The standard method degrades past a threshold we can't design around" is very different from "it was fiddly."
Are we running experiments, not just iterations? Varying an approach, measuring against defined criteria and evaluating results is experimentation. Trying things until the demo works is development.
Could a competent professional in my field have determined the result in advance? If yes, the activity is unlikely to qualify as a core R&D activity. If honestly no, it may have reached a point that warrants assessment against the remaining conditions.
Am I generating new technical knowledge, or getting my product working? The first points toward R&D; the second, on its own, doesn't.
If several of these indicators are present, the activity may have reached a point that warrants more detailed assessment. One caution: separate genuine technical uncertainty from ordinary business or commercial uncertainty — not knowing whether customers will buy it, or whether you'll hit a deadline, isn't the kind of uncertainty the law means. That distinction is worth getting right, and we work through it in a companion piece on business versus technical uncertainty. The next step isn't to assume you have a claim — it's to treat the work as potentially assessable and start behaving accordingly.
A Concrete Before/After
Implementation (outcome knowable): A logistics company builds a chatbot to answer delivery questions. It integrates an existing LLM via API, adds retrieval over its own FAQ, and ships. Hard work, real value — but a competent team would expect it to work. On the facts described, these activities would generally be unlikely to qualify as core R&D activities.
Reached the decision point (outcome uncertain): Mid-build, the same team finds that standard retrieval-augmented generation fails on their data — updates arrive as inconsistent, intermittent feeds, and off-the-shelf chunking produces answers that contradict live status. A review of reasonably accessible technical knowledge does not identify an established approach capable of resolving the problem under these reliability constraints. They form a hypothesis about a proposed retrieval and reconciliation approach whose performance under those specific constraints could not be determined from existing knowledge, and start running controlled experiments to see whether it holds. That specific portion — not the whole chatbot project — may warrant assessment against the requirements for a core R&D activity. (We work through a fuller RAG-and-automation example in a companion article.)
Notice what changed: not the ambition, but the knowability of the outcome. And notice the claim isn't "the project is eligible" — it's "this part may need a proper R&D pathway assessment against every condition."
What to Start Recording the Moment You Suspect It
A significant evidence risk is attempting to reconstruct the experiment at tax time, months after the original technical framing and observations may have been lost. From the moment you suspect you've reached the decision point, keep contemporaneous records that capture:
The technical unknown — what you could not determine in advance, and why existing methods didn't resolve it;
The hypothesis you set out to test;
The experiments — what you varied, measured and observed, including approaches that failed;
A clear line between the experimental work and the routine build around it.
You don't need certainty about eligibility to start maintaining records. You only need a reasonable basis to believe that the activity may involve an outcome that could not be determined in advance. Contemporaneous records can help preserve the technical evidence required for a later assessment. Further guidance is provided in our companion article on building evidence from day one.
Where an RSP Fits
The decision point is easiest to catch while the work is live — which is exactly when most teams are heads-down shipping and least likely to stop and frame it. The distinct thing we bring here is early technical scoping: sitting with your engineers while the work is happening to name the hypothesis, define the experiment and distinguish experimental activities from the surrounding routine development work. As a Registered Research Service Provider (RSP000047), that up-front research framing is the capability we supply — turning a vague "this got hard" into a documented experimental question you can actually assess. (RSP registration confirms that the provider has met the applicable registration requirements for its registered research fields. It does not constitute government endorsement of a particular project or guarantee that any activity will qualify for the R&DTI.) When you're ready to test your own read, our 2-minute preliminary screening tool can provide an initial structured indication of whether the activities may warrant further assessment.
If your AI project has started to surprise you, assess the point where your AI project became technically uncertain — framing the hypothesis and experiment while the work is live is far cheaper than reconstructing it later.
Frequently Asked Questions
Q: How do I know if my AI project is R&D or just implementation?
A: Ask whether the outcome could be known in advance. If a competent professional in your field would expect your approach to work — you're applying an existing model, API or documented method — that's generally implementation. When you could not know or determine the outcome in advance and it can only be resolved through systematic experiment, you may have reached a point worth assessing. Technical uncertainty is only one condition, and eligibility is self-assessed, so confirm against your own facts.
Q: My chatbot was really hard to build — does difficulty make it R&D?
A: Not on its own. Difficulty, cost and time aren't the test. The test starts with whether the technical outcome could be determined in advance, and then asks for systematic experiment, established science and the purpose of generating new knowledge. A hard-but-predictable build is still implementation.
Q: When should I start keeping records?
A: From the moment you suspect you've reached the decision point — not at tax time. Records made while the work is underway should capture the technical unknown, the hypothesis, what was varied, what was observed and how the results were evaluated. Contemporaneous records generally provide stronger evidence than a narrative reconstructed after the work has been completed.
Q: Does using an existing AI model rule out R&D?
A: Not automatically. Using an existing model, API or library to achieve an outcome that can reasonably be determined in advance will generally be routine implementation for that particular activity. Potential core R&D may arise where existing knowledge does not enable the outcome of a specific activity to be determined in advance and a proposed solution must be tested through systematic experimentation. Evidence that established approaches have proved insufficient may support the assessment, but prior failure is not a mandatory condition.
Sources & Further Reading
Check if you are eligible for the R&DTI (business.gov.au) — core and supporting activities, hypothesis and systematic progression
Artificial intelligence related activities and the R&D Tax Incentive (business.gov.au) — how the eligibility test applies to AI work
Income Tax Assessment Act 1997 s 355-25 — core R&D activities (Federal Register of Legislation)
Research and development tax incentive (ato.gov.au)
Related: R&D Tax Incentive for software and AI · 2-minute self-assessment · Research framing · Registered Research Service Provider
Note: The Australian Government announced reforms to the R&D Tax Incentive in the 2026–27 Budget, intended to apply to income years starting on or after 1 July 2028. Until those changes take effect, the program continues to operate under the current legislation. Readers should check the latest official guidance before relying on the future measures.
This article provides general information only and does not constitute tax, legal or financial advice. Eligibility for the R&D Tax Incentive depends on the specific entity, activities, expenditure and circumstances involved. Businesses should assess their circumstances against the legislation and current official guidance and obtain independent professional advice where appropriate.
