AI Medical Software and the TGA in 2026

The Feature You Shipped Might Now Be a Medical Device

A growing number of Australian midsize health businesses are building software with AI inside it. A patient-facing app that triages symptoms. A dashboard that flags which chronic-disease patients are trending toward a crisis. A tool that reads a scan and highlights a region for a clinician to review. For a long time the regulatory question sat quietly in the background, because the line between "clinical software" and "regulated medical device" felt distant and mostly aimed at manufacturers of physical hardware.

That distance has closed. In February 2026 the Therapeutic Goods Administration published updated guidance on when and how software as a medical device, including software that is or uses artificial intelligence, is regulated in Australia. The guidance applies from 5 February 2026. Its central message is deceptively simple and has real consequences: regulation is triggered by the manufacturer's intended purpose, not by whether the product happens to use AI. If your software is intended to diagnose, screen, monitor, predict, treat or manage a disease or condition, it is very likely a medical device under the Therapeutic Goods Act 1989, and the fact that a large language model or a machine learning model sits under the bonnet changes nothing about whether the rules apply.

For a health-technology team inside a clinic group, an allied-health network, a medical software vendor or a hospital innovation unit, this is the moment to find out which side of the line your product sits on. Getting it wrong is not a paperwork inconvenience. Supplying an unregistered medical device in Australia carries serious consequences under the Act, and retrofitting compliance after launch is far more expensive than designing for it. This guide maps the intended-purpose test to real product decisions, explains where AI genuinely helps a regulated build and where it adds risk, and sets out an honest planning timeline. It is written for the product lead, clinical governance lead or founder who needs to brief a board, not for a regulatory affairs specialist who already lives in the ARTG.

What actually changed

• 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. Technology-agnostic regulation.
• Software that provides a diagnostic or treatment recommendation using generative AI is explicitly called out as a regulated medical device.
• Software that only assists a human 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 the TGA position is that it cannot replace real-world clinical data.

Intended Purpose Is the Whole Game

The single most important idea in the TGA framework is that the classification of your software flows from what you say it is for. Under the Therapeutic Goods Act 1989, a product is a medical device where its intended purpose includes uses such as diagnosis, prevention, monitoring, prediction, prognosis, treatment or alleviation of disease, injury or disability. Developers of software become a manufacturer for regulatory purposes when their product falls within the definition of a medical device and they meet the definition of manufacturer under the Act.

This means two products with identical code can land in different regulatory positions purely because of how they are described, marketed and intended to be used. A tool that "summarises a patient's history for the treating clinician to consider" sits differently from a tool that "identifies patients who require urgent escalation". The words in your marketing copy, your onboarding screens and your sales deck are evidence of intended purpose. You cannot claim in a pitch that your model diagnoses a condition and then argue to the regulator that it is merely administrative software.

The practical discipline this creates is worth adopting even before you know your final classification. Write down, in one clear sentence, what your software is intended to do and who acts on its output. Then test every piece of external language against that sentence. If your marketing quietly promises more clinical value than your intended-purpose statement admits, you have a compliance gap that a regulator, a plaintiff lawyer or a hospital procurement team will eventually find.

The bottom row matters as much as the top. Genuinely administrative AI, the kind that books appointments, drafts recall letters, transcribes a consultation for the clinician to check, or reconciles billing, is generally outside the medical device framework. That is the safest ground for a health business that wants the productivity benefit of AI without stepping into device regulation. Plenty of high-value automation lives here, and we cover it in our guide to AI for healthcare practices. The regulatory weight only arrives when the software starts making or materially shaping a clinical judgement.

Clinical Decision Support: The Line Everyone Argues About

The most contested territory is clinical decision support software, and the TGA guidance draws a careful distinction that every AI health builder should understand. Software that uses generative AI to provide a diagnostic or treatment recommendation is explicitly treated as a regulated medical device. By contrast, software that assists a human clinician to make a clinical decision can be exempt from the requirement to be included on the Australian Register of Therapeutic Goods, while still being regulated as a medical device.

The difference turns on who is really making the decision and whether the clinician can independently review the basis for the software's output. If your tool hands a clinician a recommendation that they can interrogate, check against the underlying information and overrule using their own judgement, it sits closer to the assist category. If your tool effectively makes the call, or presents its output in a way that a busy clinician will realistically rubber-stamp without meaningful review, it sits closer to the regulated-and-registered category.

This has a direct design consequence for anyone building with a large language model. A generative model that produces a fluent, confident treatment recommendation is precisely the kind of output that discourages independent review, because it reads like an answer rather than a prompt to think. The safer design pattern for decision-support tools is to surface the evidence, show the source, and frame the output as material for the clinician to weigh, not as a verdict. That design choice is not only good clinical safety practice. It can be the difference between an ARTG-exempt assist tool and a registered device with a full conformity assessment behind it.

Two cautions are worth stating plainly. First, the exemption from ARTG inclusion is not an exemption from regulation. An assist tool that qualifies is still a medical device and still carries obligations. Second, the boundary is genuinely fact-specific. If your product sits near the line, this is the point where you engage a regulatory affairs professional or seek the TGA's own view rather than relying on a blog, including this one. The purpose here is to help you recognise which conversations you need to have, not to substitute for them.

Risk Classification and the Standards That Come With It

Once software is a medical device, it is classified by the potential for harm. The TGA plans to use the risk-categorisation factors identified by the International Medical Device Regulators Forum to classify software as a medical device in Australia. Devices run from Class I, the lowest risk, through Class IIa and Class IIb to Class III, the highest, with the classification determining how much independent oversight and evidence is required before supply.

Classification is where the engineering reality of a compliant build becomes concrete. Higher-risk classes require conformity assessment procedures appropriate to the class, and in practice that means a quality management system and demonstrated alignment with recognised standards. For software medical devices, the standards that repeatedly appear are ISO 13485 for quality management systems, IEC 62304 for the medical device software lifecycle, and ISO 14971 for risk management. These are not badges you add at the end. IEC 62304 in particular governs how you plan, build, verify and maintain the software across its lifecycle, which means it shapes your development process from the first sprint.

The uncomfortable truth for a fast-moving product team is that these standards were written for a discipline of documented, controlled, auditable software engineering, and a typical startup development culture is the opposite of that. You cannot reverse-engineer a compliant lifecycle history onto a codebase after the fact. If there is a realistic chance your product is a Class IIa or higher device, the cheapest possible moment to adopt the relevant lifecycle and risk-management discipline is now, while the codebase is small and the team is small.

Where AI Helps, and Where It Adds Regulatory Risk

There is a genuine irony in this space. The same AI capability that can trigger device regulation when it faces the patient can be a low-risk productivity gain when it faces the back office. Drawing that line deliberately is how a health business captures the upside without carrying regulatory weight it does not need.

On the low-risk side, AI that never makes a clinical judgement can transform the administrative load that consumes health practices. Consultation transcription that a clinician reviews and signs. Automated recall and reminder letters. Coding and billing reconciliation. Triage of inbound phone calls and routing of routine enquiries. This is real money. Administrative burden is one of the largest hidden costs in Australian healthcare delivery, and none of these use cases require a device registration because none of them decide anything clinical. For a practical view of what safe, governed automation looks like in a clinic, our note on AI agent governance, data access and human override sets out the guardrails that keep these tools on the right side of the line.

On the higher-risk side, generative AI introduces failure modes that regulators and clinicians rightly worry about. A model that confabulates a plausible but wrong clinical detail, that drifts as its inputs change, or that cannot explain the basis for its output, is a poor fit for a decision that affects a patient. This is why the TGA's position on evidence matters so much. Synthetic data may be used to supplement clinical evidence, but the guidance is clear that it cannot replace real-world clinical data. A team that hopes to validate a diagnostic model purely on generated or simulated cases will find that pathway closed.

The strategic conclusion for most midsize health businesses is not "avoid AI". It is to be deliberate about which of your AI use cases touch clinical judgement and which do not, to harvest the administrative gains first because they are low-risk and fast, and to treat any clinical-facing build as a regulated product from day one rather than discovering the obligation after launch. The teams that get into trouble are the ones that let a helpful admin tool quietly grow clinical features without ever revisiting its intended purpose.

Governance, Privacy and Cyber Security Come as a Package

Medical device regulation does not sit alone. Health software handles some of the most sensitive personal information there is, which brings the Privacy Act 1988 and the Australian Privacy Principles into scope, and it operates in a threat environment where health data is a prime target. The TGA has itself expanded its guidance on cyber security expectations for medical devices, reflecting that a device that can be compromised is a device that can harm.

For an AI build specifically, three governance questions deserve a documented answer before launch. Where does the data flow, and does any patient information leave Australian jurisdiction through a model API or cloud service. Who can override the system, and is that override real rather than theoretical. What is logged, so that if an output is later questioned you can reconstruct what the software saw and produced. These are the same questions any well-governed AI deployment should answer, and they are non-negotiable when the subject is a patient. Our 50-point AI security checklist is a useful starting frame, and the governance questions are the same ones facing clinicians directly under the AHPRA guidance on AI use in practice.

There is also a change-management dimension that AI makes sharper than traditional software. A conventional medical device does more or less the same thing on the day it ships and a year later. An AI system can behave differently as its inputs shift, as an underlying model is updated by a vendor, or as the population it sees changes. That means monitoring is not optional. A compliant AI health build needs a plan for detecting performance drift, a clear position on whether and how the model is allowed to update after registration, and a record-keeping regime that lets you show the regulator what the deployed version actually did. Software that silently changes behaviour under a registration granted for its earlier form is a live compliance risk, not a feature.

The point to hold onto is that the TGA device pathway, privacy compliance and cyber security are not three separate projects. They are three views of the same obligation to build health software that is safe, controlled and accountable. A team that treats them as one integrated discipline moves faster than a team that discovers each requirement in sequence.

An Honest Timeline

The temptation, once a team realises its product may be a regulated device, is either to panic or to defer. Both are mistakes. The realistic path is a staged one, and the earlier you start, the cheaper each stage is.

The numbers here are indicative, not promises. A genuinely low-risk assist tool with a clean intended purpose may move quickly. A Class IIb generative diagnostic tool is a serious, multi-quarter regulatory programme that no blog post can compress. What is consistent across both is that the expensive mistakes happen in weeks one and two, when a team either fails to write down its intended purpose honestly or markets a clinical capability it has not built the compliance to support.

For health businesses that want the productivity upside without the regulatory programme, the message is genuinely good. Start with the administrative automation. It is where most of the near-term value sits, it carries little device risk, and it builds the internal capability and data discipline you will need if you later decide to take on a clinical-facing build. Approached that way, the TGA's 2026 guidance is less a barrier than a map. It tells you exactly where the line is, so you can decide, deliberately, which side of it you want your next feature to sit on.

Related Reading

• AI for healthcare practices: patient automation done safely
• AHPRA guidance on AI: what practitioners must do
• AI agent governance, data access, privacy and human override
• The 50-point AI security checklist for Australian businesses
• AI automation for dental practices and patient scheduling

This article is general information about the regulatory landscape, 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.