If you are building or buying an AI tool that reads a scan, flags a patient at risk, triages a symptom, or suggests a treatment, you may be dealing with a regulated medical device, not just software. In Australia, the question is decided by function, not by branding, and it is decided under the Therapeutic Goods Act 1989 (Cth).
For a risk or compliance operator, the practical exposure is simple to state and easy to miss: supplying a regulated device that is not properly included, classified, and assessed is a compliance failure, and AI features are exactly the kind of function that can pull ordinary-looking software into scope.
What the Therapeutic Goods Act requires
The governing instruments are the Therapeutic Goods Act 1989 (Cth) and the Therapeutic Goods (Medical Devices) Regulations 2002. The regulator is the Therapeutic Goods Administration, the TGA. Software-based medical devices, including AI and machine-learning-based devices often called Software as a Medical Device, or SaMD, are regulated as medical devices under this framework.
The threshold question: is it a medical device?
Everything turns on whether your product meets the definition of a medical device. That definition is function-led: it looks at what the software is intended to do, such as diagnosis, prevention, monitoring, prediction, or treatment of a disease or condition. A tool that only stores records or supports administration is unlikely to be caught. A tool that interprets clinical data and returns a clinical output is much more likely to be in scope. This is a threshold you assess deliberately, not one you assume your way past.
Inclusion in the ARTG
Before supply in Australia, a regulated medical device generally must be included in the Australian Register of Therapeutic Goods, the ARTG. Inclusion is the gate to lawful supply. A product that should be included but is not is not merely undocumented, it is potentially being supplied outside the framework.
Risk classification, Essential Principles, and conformity assessment
Devices are classified by risk, and the classification drives how much scrutiny applies. Higher-risk functions attract more rigorous requirements. Across classes, a device must meet the Essential Principles, which are the baseline safety and performance requirements, and must satisfy conformity assessment, the evidence-based process by which a manufacturer demonstrates the device does what it claims and is safe to supply. For an AI device, that evidence includes how the model performs, on what data, and within what intended clinical use.
Where clinical decision support sits
Not all software that informs a clinician is regulated the same way. Some clinical decision support software is excluded or carved out, depending on its function and on the degree of clinician oversight. Broadly, where a qualified health professional can independently review the basis for the software's recommendation and is not relying on it as the sole determinant, the regulatory treatment can differ from a device that produces an output the clinician cannot meaningfully interrogate. The TGA has published guidance on these boundaries. The point for an operator is that "decision support" is not an automatic exemption, and the carve-out is conditional, so you must map your specific tool to the specific conditions rather than reach for the label.
Where AI comes in
AI changes the risk picture in ways the framework was not originally built around, which is precisely why it deserves attention.
Ordinary software becomes a device through its output
A model that scores images, classifies lesions, predicts deterioration, or recommends a dose is producing a clinical output. That output is the function that can make the software a medical device. Teams sometimes treat an AI feature as a product enhancement and overlook that it may have changed the regulatory character of the whole product.
Continuously learning and adaptive algorithms
A conventional device is assessed as it stands. An adaptive or continuously learning algorithm can change after approval, which raises a change-management question: a device that changes materially may need re-assessment. If your model retrains, updates weights, or shifts behaviour in the field, you need to know which changes are within the scope of what was assessed and which cross a line that triggers a fresh look. This is a live governance issue, not a theoretical one.
Data, performance drift, and intended use
AI performance depends on the data it was validated against. A tool that performs well on one population or one imaging setup may degrade elsewhere. Using a device outside its stated intended use, or letting real-world performance drift away from the validated baseline, is where clinical risk and compliance risk meet.
Post-market obligations continue
Manufacturer duties do not end at inclusion. They include post-market monitoring and adverse event reporting. For AI, this means watching real-world performance, capturing failures, and reporting adverse events, because the model's behaviour in the field is part of what keeps the device compliant.
What to do
Classify the function first. Determine whether your AI tool meets the definition of a medical device based on what it is intended to do clinically, and document that reasoning.
Check ARTG status. Confirm whether the device is, or should be, included in the Australian Register of Therapeutic Goods, and confirm its risk classification.
Test the carve-out honestly. If you are relying on a clinical decision support exclusion, map your tool against the actual conditions, especially the degree of genuine clinician oversight, rather than assuming the label applies.
Nail down change management. For any adaptive or learning model, define which updates are within scope and which may require re-assessment, and build a control that catches material changes before they ship.
Maintain post-market surveillance. Stand up monitoring for real-world performance and a working adverse event reporting path, and keep the evidence trail current.
Watch intended use. Keep deployment inside the validated population and setting, and treat drift as a signal to act.
If you are not sure whether your AI tool crosses into medical device territory, that uncertainty is itself the finding to resolve first. The free AIRA Health Check is a fast way to surface where an AI feature may pull you into the therapeutic goods framework and what to verify before you supply.