When does an AI project become more than implementation?

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

There's one line that separates implementation from potential R&D, and it isn't difficulty, cost or cleverness. It's whether the outcome could be known in advance — though, as you'll see, uncertainty on its own doesn't settle the 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 could not know or determine the outcome in advance on the basis of current knowledge, information or experience, and no established method covers your specific combination of constraints. But that uncertainty is only the entry condition. The law asks for more: that you resolve the question through a systematic progression of work, based on principles of established science, moving from hypothesis to experiment, observation and evaluation — and that the activity is conducted for the purpose of generating new knowledge, and isn't one of the excluded activities (Income Tax Assessment Act 1997, s 355-25). So an unpredictable result, by itself, doesn't mean you already have R&D. It means you've reached the point where a proper assessment against all of those conditions is warranted. Eligibility is always self-assessed against your own facts.

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, it's implementation. If honestly no, you may be at the decision point.

• 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 ring true, you're at the decision point. 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. Nothing here needs an R&D pathway.

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. No documented method covers feeds with these reliability characteristics. 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 portion — not the whole chatbot — is where the project may have become something worth assessing. (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

The most common and costly mistake is reconstructing the experiment at tax time, months after the framing is gone. 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 recording. You just need enough suspicion to stop discarding the evidence — a discipline we treat at length in a companion article on building evidence from day one, and one our evidence and audit-readiness work is designed to support.

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 separate the experimental core from the routine build before the framing evaporates. 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 is a listing, not a government endorsement or a guarantee of eligibility.) When you're ready to test your own read, the 2-minute self-assessment is a fast, structured starting point.

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 happens (the unknown, the hypothesis, what you varied and observed) are far more credible than a narrative reconstructed later, and they cost almost nothing to keep as you go.

Q: Does using an existing AI model rule out R&D?
A: Not automatically, but using a model, API or library to reach a known outcome is implementation. R&D generally lives in the specific part where existing approaches demonstrably fail and you have to experiment to find one that works — see our software-and-AI page for how that line is assessed against all the conditions.

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