Most AI products in Australia are built on a model someone else trained, reached through an API. That is a sensible engineering choice, and it is also why most of that work is not R&D. AusIndustry's guidance on AI-related activities says "using AI in software development does not make an activity eligible", and its software sector guide treats integrating third-party APIs from vendor documentation as routine.
Why calling the API is not, by itself, the experiment
Sending a hosted model requests, parsing its structured output and showing the result in your product is integration. AusIndustry lists integrating known model outputs (scores, labels, recommendations) into applications through predefined logic as unlikely to be core, where the model's behaviour and the integration approach are established. The ATO's software alert TA 2017/5 describes the same pattern from the other side: claims that rest on using existing technologies as they were intended to be used.
Rand's reading applies that guidance to calling a hosted model and adjusting prompts against documented behaviour: usually not core, though either can be supporting work for a genuine experiment.
Not being able to see or change the weights, training data or architecture is not itself the reason. The law asks whether the outcome could be known in advance, not what you are able to modify, and a black-box model can be the subject of an experiment, with your inputs, constraints or verification as the things you vary. The practical difficulty is that providers document their models and publish evaluations, so the question has to be one that this material, and an experienced engineer's judgement, leaves open.
Where a real question can sit
A genuine question can involve a hosted model in four ways:
- A method of your own that uses the model as a component, such as a verification layer, a decoding constraint or a retrieval method, where its effect on a measurable error rate is not established. Retrieval work has its own page on RAG systems.
- An outcome in another field. If a hosted model delivers a health coaching intervention, whether it changes a clinical endpoint is a scientific question even though the software is ordinary. That is assessed against the clinical literature, not engineering practice.
- A changed model. If you adapt the model itself, the question moves to LLM fine-tuning.
- The model's behaviour in conditions nobody has studied, where the answer is not in the provider's documentation or published evaluations, tested by planned runs against a proposed answer.
In each case the new knowledge must be something a competent professional could not have determined in advance. Confirming that a provider's model does what its documentation says does not meet that bar, and nor does variable output on its own: answers that change between runs are not, by themselves, an unknown outcome.
Where such an experiment exists, the API work around it changes character. Wiring the model into a test harness, building the seeded test set and logging every response so runs can be compared can all be supporting work, because they exist to run the experiment. The same wiring in the shipped product is ordinary development, and if it also serves customers it must pass the dominant purpose test before any of it counts.
Traps specific to building on APIs
- Model version churn. When a provider updates or retires a model and your outputs shift, re-tuning prompts and tests is usually maintenance.
- Reliability plumbing. Retries, caching, rate-limit handling and fallbacks between providers are usually standard patterns.
- Function calling and structured output used as documented are configuration.
- Benchmarking providers. Running the same prompts through three vendors and keeping the best is usually selection between known options.
- API spend. Only the share used for registered experiments counts; see cloud compute costs for how that share is worked out.
For how AI companies usually find their genuine core activities, see R&D for AI companies.