Under the TGA's updated guidance, applying from 5 February 2026, AI medical software is regulated according to its intended purpose. If your software is intended to diagnose, screen, monitor, predict or treat a condition, it is very likely a medical device under the Therapeutic Goods Act 1989, whether or not it uses AI. Administrative and reporting AI generally sits outside device regulation.
Key takeaways
- The trigger is intended purpose, judged from how the product is designed, described, marketed and used. The presence of AI does not change the test.
- Software that uses generative AI to give a diagnostic or treatment recommendation is treated as a regulated medical device.
- Software that assists a clinician who makes the decision may be exempt from ARTG inclusion, but it is still regulated as a medical device.
- Synthetic data may supplement clinical evidence. It cannot replace real-world clinical data.
- Start with administrative automation (transcription, recalls, billing, reporting), where device risk is low, and treat any clinical-facing build as a regulated product from day one.
When does a healthcare AI feature become a medical device?
Many Australian health organisations are now building software with AI inside it: a patient-facing app that triages symptoms, a dashboard that flags chronic-disease patients trending toward a crisis, a tool that reads a scan and highlights a region for a clinician to review. For a long time the line between "clinical software" and "regulated medical device" felt distant and aimed mostly at hardware manufacturers.
That distance has closed. In February 2026 the Therapeutic Goods Administration (TGA) published updated guidance on when software as a medical device, including software that is or uses AI, is regulated in Australia. Regulation is triggered by the manufacturer's intended purpose. A large language model or machine learning model under the bonnet changes nothing about whether the rules apply.
For a health-technology team inside a clinic group, allied health network, medical software vendor or hospital innovation unit, now is the time to find out which side of the line your product sits on. Supplying an unregistered medical device carries serious consequences under the Act, and retrofitting compliance after launch costs far more than designing for it. This guide is written for the product lead or clinical governance lead who needs to brief a board.
What changed in 2026
- The TGA's updated guidance on AI and medical device software applies from 5 February 2026.
- The trigger is intended purpose, not the presence of AI. Regulation is technology-agnostic.
- Software that provides a diagnostic or treatment recommendation using generative AI is called out as a regulated medical device.
- Software that only assists a clinician to make a decision can be exempt from ARTG inclusion, but is still regulated as a medical device.
- Synthetic data may supplement clinical evidence, but cannot replace real-world clinical data.
Why is intended purpose the test for AI medical software?
Under the Therapeutic Goods Act 1989, a product is a medical device where its intended purpose includes diagnosis, prevention, monitoring, prediction, prognosis, treatment or alleviation of disease, injury or disability. A software developer becomes a manufacturer for regulatory purposes when the product meets that definition and they meet the Act's definition of manufacturer.
Two products with identical code can therefore land in different regulatory positions because of how they are described, marketed and used. A tool that "summarises a patient's history for the treating clinician to consider" sits differently from one that "identifies patients who require urgent escalation". Marketing copy, onboarding screens and sales decks are evidence of intended purpose. You cannot claim in a pitch that your model diagnoses a condition and then tell the regulator it is administrative software.
New features can also change intended purpose. A helpful admin tool that quietly grows clinical features may cross into device territory, and those features should not ship until the right approvals are in place.
The practical discipline is worth adopting now. Write one clear sentence stating what your software is intended to do and who acts on its output. Test every piece of external language against that sentence. If your marketing promises more clinical value than the statement admits, you have a gap a regulator, plaintiff lawyer or hospital procurement team will eventually find.
What is the software intended to do?
- Diagnose, screen or predict a conditionLikely a regulated medical device
- Recommend a treatment or dosageLikely a regulated medical device
- Assist a clinician who makes the decisionMay be regulated, possible ARTG exemption
- Administrative, booking or records onlyGenerally not a medical device
Are AI healthcare reporting tools regulated by the TGA?
Generally not, when they are administrative. AI that books appointments, drafts recall letters, transcribes a consultation for the clinician to check, reconciles billing or produces operational and compliance reports is usually outside the medical device framework. That is the safest ground for a health organisation that wants AI's productivity benefit without device regulation, and we cover it in our guide to AI for healthcare practices. Regulatory weight arrives when the software makes or materially shapes a clinical judgement, such as a report that ranks patients for clinical escalation.
Where is the line for clinical decision support software?
Clinical decision support is the most contested territory. Software that uses generative AI to provide a diagnostic or treatment recommendation is treated as a regulated medical device. Software that assists a clinician to make a clinical decision can be exempt from inclusion on the Australian Register of Therapeutic Goods (ARTG), while still being regulated as a medical device.
The difference turns on who really makes the decision and whether the clinician can independently review the basis for the output. If the tool gives a clinician something they can interrogate, check against underlying information and overrule, it sits closer to the assist category. If it effectively makes the call, or presents output a busy clinician will realistically rubber-stamp, it sits closer to regulated and registered.
This matters for anyone building with a large language model. A fluent, confident treatment recommendation discourages independent review because it reads like an answer. The safer pattern is to surface the evidence, show the source and frame the output as material for the clinician to weigh. That is good clinical safety practice, and it can be the difference between an ARTG-exempt assist tool and a registered device with a full conformity assessment.
| Assist (possible ARTG exemption) | Decision maker (regulated device) | Impact | |
|---|---|---|---|
| Who decides | Clinician | Software output drives it | Key test |
| Reviewability | Basis is visible and checkable | Opaque recommendation | Design matters |
| Output framing | Evidence to weigh | Confident verdict | UX choice |
| Generative recommendation | Flagged for human judgement | Diagnostic or treatment call | Higher risk |
| Override | Easy and expected | Rarely exercised | Safety signal |
Two cautions. First, exemption from ARTG inclusion is not exemption from regulation: a qualifying assist tool is still a medical device with obligations. Second, the boundary is fact-specific. If your product sits near the line, engage a regulatory affairs professional or seek the TGA's view instead of relying on any blog, including this one.
How are AI medical devices classified, and which standards apply?
Once software is a medical device, it is classified by potential for harm, from Class I (lowest) through Class IIa and IIb to Class III (highest). Australia's software classification rules draw on the risk categorisation approach of the International Medical Device Regulators Forum (IMDRF). The class sets how much independent oversight and evidence is required before supply.
Higher classes need conformity assessment, which in practice means a quality management system and alignment with recognised standards. The standards that recur for software medical devices are:
- ISO 13485: quality management systems for medical devices.
- IEC 62304: the medical device software lifecycle.
- ISO 14971: risk management for medical devices.
These cannot be added at the end. IEC 62304 governs how you plan, build, verify and maintain software across its lifecycle, so it shapes development from the first sprint. You cannot reverse-engineer a compliant lifecycle history onto a codebase. If your product could realistically be Class IIa or higher, the cheapest moment to adopt the discipline is now, while the codebase is small.
- Define purposeOne clear intended-purpose statement
- ClassifyIMDRF-based risk categorisation
- Build to standardIEC 62304, ISO 14971, ISO 13485
- EvidenceClinical and validation data
- ARTG pathwayConformity assessment and inclusion
Where does AI help a health organisation, and where does it add regulatory risk?
The same AI capability that triggers device regulation when it faces the patient can be a low-risk gain when it faces the back office. Drawing that line deliberately captures the benefit without carrying regulatory weight you do not need.
On the low-risk side: consultation transcription a clinician reviews and signs, automated recall and reminder letters, coding and billing reconciliation, routing of routine enquiries, and operational reporting. None of these decide anything clinical. Our note on AI agent governance, data access and human override sets out the guardrails that keep them on the right side of the line.
On the higher-risk side, generative AI introduces failure modes clinicians and regulators rightly worry about: confabulating a plausible but wrong clinical detail, drifting as inputs change, or being unable to explain its output. That is why the TGA's evidence position matters. Synthetic data may supplement clinical evidence, but it cannot replace real-world clinical data, so validating a diagnostic model purely on generated cases is not an option.
- Admin automation (transcription, recall, billing)Low regulatory risk
- Assist tools with visible, reviewable outputMedium, possible ARTG exemption
- Generative diagnostic or treatment recommendationsHigh, registered device
- Best first move for most practicesStart with admin
How do you ensure compliance in healthcare-focused AI agent development?
Device regulation does not sit alone. Health software handles some of the most sensitive personal information there is, bringing the Privacy Act 1988 and the Australian Privacy Principles into scope, and health data is a prime target for attackers. The TGA has also expanded its guidance on cyber security expectations for medical devices.
For any healthcare AI agent, document answers to these questions before launch:
- Intended purpose: what is the agent for, who acts on its output, and does any external language claim more?
- Data flow: does any patient information leave Australian jurisdiction through a model API or cloud service? Keeping the model on your own infrastructure in Australia removes that question.
- Human override: who can override the agent, and is that override real in day-to-day use?
- Logging: if an output is questioned later, can you reconstruct what the software saw and produced?
- Change control: how will you detect performance drift, and is the model allowed to update after release or registration?
The last point is sharper for AI than for traditional software. An AI system can behave differently as inputs shift, as a vendor updates an underlying model, or as the patient population changes. A compliant build needs drift monitoring, a clear position on post-registration updates and records showing what the deployed version did. Software that silently changes behaviour under a registration granted for its earlier form is a live compliance risk.
Our 50-point AI security checklist is a useful starting frame, and the same governance questions face clinicians directly under the AHPRA guidance on AI use in practice. Treat the TGA pathway, privacy and cyber security as one integrated discipline: teams that do move faster than teams that discover each requirement in turn.
How long does a compliant AI medical software build take?
Once a team realises its product may be a regulated device, panic and deferral are both mistakes. The realistic path is staged, and each stage is cheaper the earlier it starts.
- Weeks 1-2Purpose and triageWrite the intended-purpose statement, test it against your marketing, decide which side of the device line you are on
- Weeks 3-6Classify and gap-assessApply IMDRF risk factors, engage regulatory advice for borderline cases, map the standards gap
- Months 2-4Build to lifecycleAdopt IEC 62304, ISO 14971 and QMS discipline, design reviewable outputs and human override
- Months 4-9Evidence and pathwayGather real clinical validation data, prepare conformity assessment and ARTG inclusion where required
These timings are indicative. A low-risk assist tool with a clean intended purpose may move quickly. A Class IIb generative diagnostic tool is a multi-quarter regulatory programme. In both cases the expensive mistakes happen in weeks one and two, when a team fails to write down its intended purpose honestly or markets a clinical capability it has not built the compliance to support.
For health organisations that want the productivity gain without a regulatory programme, start with administrative automation. That is where most near-term value sits, device risk is low, and it builds the data discipline you will need if you later take on a clinical-facing build. Read that way, the TGA's 2026 guidance is a map of exactly where the line is.
How Solve8 can help
Our consultants and engineers help healthcare and allied health groups separate low-risk administrative AI from clinical-facing builds, then design and build the administrative side on your infrastructure in Australia, with a person approving before anything reaches a patient or a system of record. For clinical-facing products we work alongside your regulatory adviser on intended purpose, reviewable outputs and logging. See our custom AI development services or talk to us.
This article is general information about how the rules apply, not legal or regulatory advice. Whether a specific product is a regulated medical device depends on its intended purpose and facts. Seek advice from a qualified regulatory affairs professional or the Therapeutic Goods Administration before making supply decisions.
