When does a healthcare AI agent need Anvisa registration?

A healthcare AI agent does not need registration because it uses artificial intelligence. It needs it when the intended purpose declared by the manufacturer turns it into a medical device. This guide shows where Anvisa draws that line: what RDC 657/2022 and RDC 751/2022 say, what the agency has already officially answered about virtual assistants, and what is coming in the 2026-2027 Regulatory Agenda.

The question that decides everything: the declared intended purpose

RDC 657/2022 defines software as a medical device (SaMD) as software that meets the definition of a medical device, "intended for one or more medical indications, and that performs these purposes without being part of medical device hardware" (art. 2, VII). The definition includes mobile apps and subscription-licensed, centrally hosted software.

The same resolution excludes five cases from the framework (art. 1, paragraph 2): wellness software; software on Anvisa's list of unregulated products; software used exclusively for administrative and financial management in healthcare services; software that processes demographic and epidemiological data with no clinical, diagnostic or therapeutic purpose; and software embedded in a medical device already under sanitary surveillance.

The point that matters most for AI agents comes from Anvisa's official Q&A document on RDC 657/2022: "it is not a matter of whether the software uses AI or ML, but rather the intended use of the device that must be observed" (answer 111). Using artificial intelligence does not make a product a medical device; declaring a medical purpose does. The regulatory question is not "does the agent use AI?", but "what does the manufacturer declare it does?".

What Anvisa has already answered about virtual assistants

The Q&A document records real inquiries very close to what we now call an AI agent. In one of them (answer 26), a platform with an app and a virtual assistant, including a chatbot, telehealth and voice interaction with predictive models, was reviewed by Anvisa. The conclusion: limited to scheduling, appointment booking, electronic medical records, logging the patient's condition and communication, the solution does not fall under the rules and is not a medical device subject to regularization.

In answer 9, the same reasoning for telemedicine: software that performs only medical record, scheduling, data transmission and communication functions, by video, audio or text, is not a medical device. Diagnosis and treatment suggestions made by the physician, without the software's help, do not change that framing.

Answer 24 draws the finest line: software that prescribes medication is SaMD; but "if the software only serves to communicate to the patient the prescription made by a physician, in this case the function is communication" and no framing applies. The physician decides the course of action; software that merely carries that decision stays outside the medical device regime.

When the agent becomes a medical device

If the declared intended purpose includes informing clinical decisions, the product is SaMD and its risk classification comes from Rule 11 of Annex I of RDC 751/2022. Software intended to provide information used for diagnostic or therapeutic decision-making is class II; it rises to class III if those decisions could cause serious deterioration of health or surgical intervention, and to class IV if they could cause death or irreversible deterioration. Software monitoring physiological processes is class II, or III when it involves vital parameters with immediate risk. Any other SaMD is class I.

The class defines the regime (arts. 6 and 7 of RDC 751/2022). Classes I and II follow notification: the form goes to Anvisa, but the technical dossier stays with the company (art. 10 of RDC 657/2022). Classes III and IV require registration, with a technical report covering software and hardware architecture, interoperability, cybersecurity controls, verification and validation, risk management and clinical evaluation (art. 12), plus a declaration of conformity with IEC 62304 (software life cycle), IEC 62366-1 (usability) and ISO 14971 (risk management), or equivalent versions (art. 13).

On timelines and entry costs, the Q&A document records: petitions follow the 90-day deadlines of Law 6,360/1976, and RDC 743/2022 set 30 days for notifications. The petitioning company needs an Operating Authorization (AFE) covering the right activity and, under the registration regime, the manufacturer needs Good Manufacturing Practices certification. And a warning often forgotten: distributing SaMD without regularization, even for free, is a sanitary violation.

The AI-specific layer

When AI is used to achieve the product's medical purpose, Anvisa requires a specific report (answers 50 and 111): the rationale justifying the applied technique, the size and description of the datasets used for learning, training and verification, the origin and quantity of the data and the statistical justification for the dataset sizes. Missing information can lead to rejection.

On continuous learning, the recorded position is direct (answer 115): there is no regularized SaMD with open-code AI in continuous learning. Such a product would be treated as innovative technology and would need to demonstrate safety and efficacy, with protection mechanisms against deviations from the validated code. In practice, the code is frozen before submission, and relevant algorithm changes go through an amendment petition (art. 16 of RDC 657/2022).

The regulatory horizon is already visible. The preliminary topic list of the 2026-2027 Regulatory Agenda includes the revision of RDC 657/2022, justified by the need that "items related to artificial intelligence and machine learning must be incorporated into the RDC", along with harmonization with international practices. Until then, the current rule stands: the declared intended purpose governs.

Where Lisa stands

Lisa was designed to operate on the communication side, in the same framing Anvisa has already recognized as outside the medical device regime. Nothing reaches the patient without human approval; the agent does not choose courses of action or treatments; the clinical content is, literally, what the team approved; clinical questions go to the human queue, with the conversation's context. It is the same design described in the technical article on the limits of Lisa's guard rails.

The Lisa ANVISA Ready initiative organizes this regulatory and clinical-safety readiness: if a future purpose requires framing as SaMD, the architecture of frozen versions, explicit approval and traceability already speaks to what RDC 657/2022 asks for in verification, validation and change management.

Checklist before launching a healthcare AI agent

1. Write the declared intended purpose of the product, in full, in the scope. It is the document Anvisa reads first.
2. Ask whether the agent informs or suggests diagnostic or therapeutic decisions, or only communicates what the physician decided. Only the first case becomes SaMD.
3. If it is SaMD, estimate the class by the impact of a wrong decision: death or irreversible harm points to IV; serious deterioration, to III; all other cases, to II.
4. Check whether the AI learns in production. If it does, prepare for the innovative-technology regime; if not, freeze and version the code before any submission.
5. Confirm the company prerequisites: an Operating Authorization (AFE) covering the right activity and, for registration, Good Manufacturing Practices certification.
6. If in doubt, use Anvisa's formal software framing channel before launch, not after.