Fine-tuning is not a category the law knows. Division 355 asks the same thing of a fine-tune as of any software work: was there a technical outcome nobody could determine in advance, and did you resolve it by hypothesis, experiment and evaluation? For most fine-tuning the honest answer is no, because the recipes are published and they work. For some, the answer is yes.
What AusIndustry says about fine-tuning
AusIndustry's page on AI-related activities gives a fine-tuning example that may be core: investigating a novel fine-tuning strategy "whose effects are not well-understood", where established methods had failed to resolve a scaling problem. The same page lists adjusting parameters such as learning rate as unlikely to be core when "the effect of changing the parameter is well understood". It also says plainly that using AI in development does not make an activity eligible. So the line does not run between fine-tuning and other work. It runs between applying a fine-tuning method and investigating one.
Three questions for any fine-tune
- What is the target? A measurable threshold, for example extraction F1 of 0.92 on a held-out set from a 7B model served under 300 ms on one GPU. "Make the model better at our domain" is a goal, not a hypothesis.
- What does published work say? Model cards, technical reports, papers on parameter-efficient methods, vendor fine-tuning documentation and public community fine-tunes all count as available knowledge. If they show a standard recipe reaching your kind of target under comparable conditions, the outcome was usually knowable. A published recipe does not settle every task, though: where your data, constraint or combination of targets differs in a way that matters, record why the published results do not carry over.
- What would a competent professional predict? If an experienced ML engineer would say the standard recipe will work and it just needs compute, there is nothing to test.
Where the answers leave a real gap, the work of building and running each variant is the experiment itself. Cleaning and formatting data to a model's documented input requirements is listed by AusIndustry as unlikely to be core; it can be a supporting activity when it exists for a genuine experiment.
Eval noise is not uncertainty
Every fine-tune's eval scores move between runs and seeds. That is not the uncertainty the law means. In Coal of Queensland [2021] FCAFC 54 the Full Federal Court separated an activity's outcome from the precise data it produces: not knowing the exact number in advance does not mean the outcome could not be known. Ask whether an ML engineer could have known your approach would clear the threshold, not whether they could have guessed the third decimal place.
Edge cases peculiar to fine-tuning
- Vendor fine-tuning endpoints. When you upload examples to a provider's hosted job, you control the data and a handful of settings, not the method. Any genuine question usually lives in the data mix or the objective, and must be framed that way. The wider position on hosted models is on the third-party AI APIs page.
- Distillation. Training a small model on a larger model's outputs is assessed the same way: published distillation results for your task and size settle many cases.
- Retraining on fresh data. Once the approach works, rerunning it each quarter on new data is business as usual. A core activity ends when its uncertainty is resolved.
- Hyperparameter sweeps. A sweep can be the way you test a stated hypothesis, but a sweep does not create one.
Training a model from scratch raises different questions, covered under training machine learning models. For how AI companies group this work into activities, see R&D for AI companies, and for the GPU bill, cloud compute costs.