At a health plan, a hospital or a clinic, the conversation about AI and the LGPD (Brazil's data protection law) starts one step above that of other sectors. Almost everything an agent touches in service is health data: the procedure requested, the specialty sought, the provider chosen, the receipt sent for reimbursement. And health data is sensitive personal data, with its own rules in Law 13.709/2018.
This guide answers two questions that arrive together: what the LGPD requires of anyone using AI agents with health data, and how the agent protects that data in practice. What applies to any sector is in the general guide to AI governance and the LGPD. Here we cover only what changes when the data is health data.
This is a guide for engineering and for decisions, not a legal opinion. The lawful basis of each flow and the risk assessment are analysis for your legal team and your data protection officer. The sector rules for private health plans and for the professional councils also apply and are not covered here.
What changes when the data is health data
The LGPD lists "data concerning health" among sensitive personal data (art. 5º, II). And art. 11, § 1º extends the same regime to any processing that reveals sensitive data and may cause harm to the data subject. In practice, that reaches inference: an appointment with an oncologist, a hemodialysis claim form or the reimbursement of a psychiatric consultation reveals a health condition without there being a field called diagnosis.
The practical rule for whoever designs the agent: in a health operation, treat almost all of the service context as sensitive, and not only the medical record. Two consequences follow that other sectors do not have, in addition to the lawful basis, which gets its own section just below.
The prohibitions aimed at the sector
Art. 11, § 5º speaks directly to health plan operators: they cannot process health data for "risk selection" when contracting, nor when enrolling and excluding members. A quoting or sales qualification agent, therefore, cannot use health data to select risk and filter who gets in, and the same prohibition reaches the exclusion of members.
§ 4º prohibits controllers from sharing health data among themselves with the aim of obtaining an economic advantage. The exceptions are narrow: the provision of health services, pharmaceutical care and health care, for the benefit of the data subject, to allow the portability they request or the financial and administrative transactions resulting from those services. Every automated sending of health data to another controller (a partner, a group company, a provider) needs to be assessed against that rule before it becomes a flow.
The impact report stops being hypothetical
The national data protection authority may require the controller to prepare a data protection impact report, and the law expressly mentions sensitive data (art. 38). It is worth preparing it together with the agent's design, and not when it is requested: the decisions the report requires are the same ones this guide describes.
Consent or another lawful basis
A tempting shortcut is to treat consent as the answer to everything. It is one of the grounds in art. 11, and one of the most demanding: it must be given "in a specific and prominent manner, for specific purposes" (art. 11, I), and the data subject can revoke it (art. 18, IX). If the agent's flow depends on consent and the member revokes it, the flow needs an alternative path, or it has to stop.
Without consent, processing is only allowed when it is indispensable for one of the purposes in art. 11, II. Those that may come into the analysis of a health flow:
- Compliance with a legal or regulatory obligation by the controller (item a).
- Regular exercise of rights, including in a contract (item d).
- Protection of the life or physical safety of the data subject or of a third party (item e).
- Protection of health, exclusively in a procedure performed by health professionals, health services or a health authority (item f).
- Fraud prevention and the security of the data subject, in the identification and authentication of registration in electronic systems (item g).
Two absences matter: legitimate interest and credit protection (art. 7º, IX and X), which serve as a basis for ordinary personal data, are not in art. 11. Which ground covers each flow, and whether item f reaches your case, is analysis for your legal team. What falls to engineering is not to decide this once for "the AI project": the basis is defined per flow, and the flow is designed to fit it.
Where the agent touches sensitive data
Map by flow, not by system: the same ERP feeds flows with very different risks. The six below follow the member's journey at a health plan, and most of them also apply to hospitals and clinics.
| Flow | Health data that appears | Point of attention |
|---|---|---|
| Member service | Authorization and reimbursement status, coverage checked, network searched. | The channel receives what was not asked for: symptoms, diagnoses, photos of test results. |
| Procedure authorization | The procedure requested, the doctor's order, medical reports. | A decision that affects the data subject: it requires a human review path (art. 20). |
| Scheduling and navigation | Specialty, provider, date, reason for the visit. | The specialty reveals the condition (art. 11, § 1º), and the data goes on to third parties' calendars. |
| Reimbursement | Receipts, Notas Fiscais (Brazilian tax invoices), medical reports. | The document carries more than necessary, and the attachment is stored somewhere. |
| Collections | In principle, none. | Context contamination: the collections agent receiving usage history it does not need. |
| Quoting and sales | Profile, age and covered lives; sometimes, health information volunteered by the prospect. | The prohibition on risk selection (art. 11, § 5º). |
Two patterns run through the table. The agent needs to deal with what arrives, and not only with what it asks for: the member may send, without anyone requesting it, an entire medical report to ask about a waiting period. And the most exposed flows are not always the clinical ones: service and collections receive health data as a side effect, when the context is assembled with the full record because that is simpler. In collections there is one more reason to keep that data out: credit protection is not among the grounds in art. 11.
Minimization and masking before the model
The principle of necessity limits processing to the "minimum necessary" for the purpose (art. 6º, III). With health data, it is the control with the greatest effect, because in many answers the model does not need to know who the person is. To report the status of an authorization, it needs "imaging exam under medical review, documentation complete, within the deadline". It does not need the name, the CPF (Brazil's individual taxpayer ID), the member card number or the attached report. The cut works in four layers, in this order:
- Do not fetch what does not change the answer. The tool that queries the system returns only the flow's fields. The cut happens in the integration, before the data exists in the agent's context.
- Mask identifiers before sending. CPF, member card, phone and email become placeholders, and the re-association happens outside the model, in the system that executes the action.
- Generalize clinical data when the answer does not depend on it. "Imaging exam" instead of the name of the exam and the report; the category instead of the detail.
- Handle what the member sent without being asked. Free text goes through sanitization before the model, and the attachment goes to restricted-access storage, without entering the context, unless the flow depends on it.
Masking is not anonymizing. Under art. 12, data that can be re-associated with the data subject with reasonable effort is still personal data. Masking reduces the exposure and the size of any incident, but the processing remains under the LGPD.
Where the data is processed and stored
An agent leaves health data in more places than the main system. Since the law requires security measures from the design of the service onward (art. 46, § 2º), each of those places needs an owner, a retention period and access control as early as the pilot:
- The model provider. Retention, use for training and processing region, with a written answer in the contract.
- The knowledge base. Indexing manuals, coverage rules and internal protocols is one thing; indexing members' histories or attachments creates one more sensitive store.
- The conversation history and the attachments. The channel and the platform hold everything the member sent, including what was not asked for.
- The execution trail, covered further below.
When the model is processed outside Brazil, there is an international transfer, allowed only in the cases of art. 33, such as a country with an adequate level of protection or specific contractual guarantees; the general guide details this point. In healthcare, the decision weighs more and should be made per flow. Reissuing a payment slip, with the identifier masked, has one risk profile; reading a medical report for an authorization has another, and may call for a provider with no retention guaranteed in the contract, or your own model on your infrastructure. The text on choosing a model helps set up that split.
Where the human approves
Art. 20 gives the data subject the right to request a review of decisions taken solely on the basis of automated processing that affect their interests. In healthcare, the most evident cases are denying authorization, denying coverage, refusing reimbursement, disallowing items on a provider's bill and excluding members. The design rule that resolves most of them fits in one sentence: the agent prepares, the person decides.
In authorization, the agent gathers the documentation, checks eligibility and coverage and tracks the deadline; medical review is what approves or denies. In triage, it guides the member to the point of care and, at any sign of urgency, brings in a health professional immediately. Points that call for human approval, action by action:
- Approval or denial of authorization, coverage and reimbursement.
- Disallowances, and any fraud flag that has consequences for the member or for the provider.
- Guidance that goes beyond pointing to the point of care, and every case with a sign of urgency.
- Communication that reveals health data to anyone other than the data subject.
- Cancellation or exclusion of a member.
Approval is by type of action, not a global switch. The text on human-in-the-loop shows how to design it so the person does not become the bottleneck. And the record of the approval (who, when, on what) goes into the trail.
The trail of every tool call
When the member complains, or internal audit asks why the agent answered what it answered, "the model decided" is not an answer. The LGPD requires a record of processing operations (art. 37), the ability to demonstrate the adoption of effective measures (art. 6º, X) and, when the data subject asks, clear information about the criteria and procedures of an automated decision (art. 20, § 1º). In each execution, the trail needs to keep:
- The input received, already sanitized, and the version of the instructions in use.
- Each tool called, with the parameters sent and the response received.
- The model used, the final answer and whether there was a handoff to a human agent.
- The human approval, when there was one: who, when and on what.
The paradox is that the trail, built to protect, becomes a health database itself. It goes into the inventory, has a retention period and role-based access, and needs to be reachable when the data subject exercises the rights in art. 18, respecting the retention the law authorizes, such as what is needed to comply with a legal or regulatory obligation (art. 16, I). The post on observability covers the technical side.
What to ask the vendor
The general questions are in the governance guide. In healthcare, add these, and ask for the answer in writing:
- Does sanitization happen before the model, including in the free text and the attachments the member sends without being asked?
- Can I decide where each flow is processed (a provider with no retention, a region, my own model on my infrastructure), and not only for the whole account?
- Is human approval configurable by type of action, such as denials, disallowances and clinical guidance, and is it recorded with name and time?
- Does the trail record every tool call with its parameters, and is it reproducible? Who on your team has access to it?
- Do you process the data only according to my instructions, as a processor (art. 39)? Which subcontractors, including model providers, receive data?
- In case of an incident, when and with what information do you notify me? Does it cover what I need to report under art. 48?
Incident response with an agent in the middle
Art. 48 requires the controller to notify the national authority and the data subject of a security incident that may cause relevant risk or harm. The deadline is the one the authority sets, and the law fixes the minimum content of the notice, such as the nature of the data affected, the data subjects involved, the protection measures used, the risks and the steps taken. Check the regulations in force when building the plan.
With an agent, an incident is not only a database leak. Four scenarios deserve their own playbook:
- An answer to the wrong person. The status of an authorization sent to a number that changed owner, or to a family member who uses the same phone.
- Crossed context. One member's data appearing in another member's conversation, through a failure of session or memory isolation.
- Manipulation through text. Someone tries to get the agent to look up another person's data. The control is in the design: the tool only queries the member authenticated in the session, and not any identifier that appears in the conversation.
- Exposure through the trail or the attachments. Improper access to precisely the store that exists for auditing.
The plan needs three capabilities. Contain: suspend the agent or a specific tool without stopping the whole operation. Reconstruct: the trail says which members were affected, with which data and when, which is the content art. 48 asks for. Communicate: the data protection officer leads, with a notice template ready. And masking helps here too: in judging severity, the law says to consider whether there was a technical measure that made the data unintelligible to whoever should not access it (art. 48, § 3º).
How Runflow handles health data
The controls in this guide are part of the Runflow platform for building, operating and measuring agents: sanitization of sensitive data before it reaches the model, end-to-end isolation per client, human approval where the risk demands it and an audit trail of every execution, decision and tool call, reproducible for audit. Runflow does not train models on your data, and you decide where it goes: providers with no retention or your own model on your infrastructure, with the platform managed by us or in your cloud (AWS, Azure or GCP), with your keys.
For health plans, the healthcare agents follow the same bar. The Prior Authorization agent reads the claim form in the TISS standard (the health insurance data standard), checks eligibility and coverage and assembles the case for medical review, without approving or denying on its own. The Health Navigation and Triage agent brings in a health professional when there is a sign of urgency. The decision to disallow or deny is always human, and our engineers connect TISS, ERPs and authorization systems. The free assessment starts with the flow that weighs most on your service today.
