Legitimate Interest Under LGPD for AI: How to Justify It

Legitimate Interest Under LGPD for AI: How to Justify It

Legitimate interest (LGPD art. 7, item IX) can support an AI use when the company can demonstrate three things: a legitimate and concrete purpose, use of only the data that is strictly necessary, and a balancing test showing that the data subject's rights and expectations do not override the company's interest. Citing the legal basis in a document is not enough. You need to record the reasoning before the AI goes live, in a form an outsider can understand and challenge.

This is a practical guide for people who have to decide and document. It does not replace legal advice, and the final call on the legal basis should go through whoever is accountable for data protection in your company.

Key takeaways

• Legitimate interest requires a concrete purpose, demonstrated necessity and balancing against the data subject's rights. All three tests must be written down.
• It does not apply to sensitive personal data, and it calls for extra care with data about children and teenagers.
• Using AI does not change the legal basis by itself, but it changes the risk: the model may infer, retain or expose more than the manual process did.
• The minimum documentation is a legitimate interest assessment record, with safeguards, an objection channel and periodic review.
• If the use involves decisions that significantly affect the data subject, also look at the right to review under art. 20 and consider another legal basis, such as consent.

What is legitimate interest, and why does it come up so often in AI projects?

The LGPD lists ten legal bases for processing personal data. Legitimate interest is the most flexible, because it depends neither on the data subject's authorization nor on a specific legal obligation. In exchange for that flexibility, the law demands accountability: art. 10 says it can only support processing for legitimate purposes, assessed from concrete situations, and that only the strictly necessary data should be processed.

In AI projects it tends to be the natural candidate for a practical reason. When a company wants to classify existing customer messages, summarize a support history or prioritize tickets, asking for new consent often makes little sense. The contract may cover part of the processing, but not necessarily the use of a language model to analyze the content.

That does not make it a comfortable basis. Three limits need to be clear from the start:

• Sensitive personal data (health, biometrics, racial origin, religious belief and the others in art. 5, item II) cannot be processed on the basis of legitimate interest.
• Data about children and teenagers requires attention to the best interest of the data subject and often calls for another basis.
• The data subject has the right to be informed and, in some situations, to object to the processing.

For official guidance, follow the publications of Brazil's data protection authority (ANPD) on the legal bases for processing.

Test 1: Is the purpose legitimate and concrete?

The first test asks what, exactly, the AI will process the data for. Vague purposes such as improving the experience or gaining efficiency do not pass. The purpose must describe a real process and a verifiable benefit.

A good purpose description answers four questions:

• Which business process is being supported (ticket triage, reply drafting, lead classification)?
• Who benefits: the company, the data subject, both?
• Is the purpose lawful and compatible with what the data subject reasonably expects when dealing with the company?
• Does the purpose exist today, in a concrete situation, or is it a hypothesis for the future?

The last point is the most neglected. Keeping conversations because they might be useful for training something later is not a concrete purpose. Summarizing the history of a customer who opened a ticket today is.

Purposes also need to be kept separate. Using customer messages to reply to those customers is one purpose. Using the same messages to build behavior profiles or tune a model is another, and it needs its own test.

Test 2: Is the processing necessary and proportionate?

The second test asks whether the company can achieve the purpose by processing less data, or in a different way. Art. 10 speaks of strictly necessary data, and the necessity principle (art. 6, item III) requires limiting processing to the minimum needed for the purpose.

In AI practice, necessity is examined on four fronts:

• Which fields go into the prompt or the model's context. Do full name, tax ID and address really help with the task, or are the text of the question and the order number enough?
• How long the data stays in logs, histories and search indexes.
• Who can access the model's outputs and what the model can look up or do.
• Whether a less invasive alternative exists, such as deterministic rules, pseudonymized data or a model running on your own infrastructure (see running Ollama local models in a company for that route).

If the AI provider is located outside the country, necessity also touches data transfer. That is a separate topic, covered in international data transfer under LGPD when using AI providers.

A useful rule: if the team cannot explain why each category of data is in the flow, it is probably not necessary.

Test 3: Does the balance favor the company or the data subject?

The third test weighs the company's interest against the data subject's rights and freedoms. This is where most justifications turn out weak, because the text only describes the company's benefit and ignores the other side.

The balancing test looks at:

• Reasonable expectation: does a person who wrote to support expect the message to be read by a system that helps serve them? Do they expect it to be used for another purpose, such as behavior analysis?
• Impact: what happens to the data subject if the AI gets it wrong? A misclassified reply is different from a denied customer or an unwarranted charge.
• Nature of the data: contact details and order history weigh less than financial, location or intimate relationship data.
• Position of the data subject: employees, students and patients have less freedom to refuse than retail customers.
• Safeguards: what the company does to reduce the impact (minimization, human review, action limits, an objection channel).

When the result favors the company only because of safeguards, those safeguards stop being optional. They become part of the justification and must actually exist in the system. If the use touches automated decisions with significant effect, also read LGPD automated decision-making and the right to review under art. 20.

Illustrative scenario: triaging WhatsApp support messages

Illustrative scenario: an online store wants to use AI to classify the messages arriving on its support WhatsApp (exchange, delay, product question) and suggest a draft reply that an agent reviews.

• Purpose: speed up the triage of support requests made by the customer themselves. It is concrete, tied to an existing process and compatible with what the customer expects when writing to support.
• Necessity: the model receives the message text and the order status. It does not receive the tax ID, the full address or the entire purchase history. The logs keep the classification and the draft for a defined period, not the full content forever.
• Balancing: the impact of an error is low, because the agent reviews before sending. The customer is told in the privacy policy and at first contact that support uses automated tools, and can ask for fully human service.
• Warning point: if someone sends sensitive data, such as a medical report, the flow needs a rule not to reuse that content and to escalate to a human.

If the same store wanted to use the conversations to build purchase-propensity profiles and trigger offers, that would be a different purpose, with a different balancing test and different rules. For that case, see also WhatsApp outbound messages: templates, opt-in and best practices.

How to document the decision, step by step

The LGPD does not impose a single form, but art. 10, paragraph 3, provides that the ANPD may request a data protection impact report when processing is based on legitimate interest, and art. 37 requires keeping a record of processing operations. A legitimate interest assessment record (often called an LIA) is the simplest way to be prepared.

A documentation outline that works:

• Describe the use case in plain language: process, data, tools, providers and where the data is processed.
• Record the concrete purpose and who is internally responsible for the decision.
• List the data categories and justify each one. Mark what was deliberately left out.
• Describe the alternatives considered and why they were discarded.
• Write out the balancing test: expectations, possible impacts, vulnerable groups, risks of model error.
• List the safeguards: minimization, masking, retention, access control, human review, agent action limits, decision logs.
• Define transparency: where and how the data subject is informed and how they object or request review.
• Mark the date of the assessment and the review triggers: a change of provider, purpose or data type, or an incident.
• Have it approved by the data protection officer (DPO) or whoever performs that role, and keep the version.

For AI-specific risks, the NIST AI Risk Management Framework helps structure risk mapping, and the OWASP Top 10 for LLM applications covers technical failures, such as data leakage through prompts, that belong in the balancing test.

The method we apply in AI projects maps directly onto this record. Mapping the current process and data supplies the content for purpose and necessity. Limiting the agent's data and actions produces the safeguards. Piloting a real flow, with logs and an agreed success metric, shows whether the balancing holds up in practice. Handing over the operation with updated documentation lets you decide whether to expand, adjust or stop the use.

When is legitimate interest not the right basis?

Some signs indicate it is worth changing the basis or redesigning the use:

• The processing involves sensitive data, such as health or biometrics. Here legitimate interest is not available.
• The data subject would not reasonably expect that use, for example recording and analyzing internal conversations without notice. For meetings, see recording meetings with AI: consent and privacy law (LGPD).
• The AI makes or influences decisions with significant effect on a person, such as credit, hiring or access to a service, without effective human review.
• The use is monitoring people, such as tracking employee productivity. In that case the power imbalance weighs heavily in the balancing test (see how to measure AI productivity without surveillance on your team).
• The company cannot explain the purpose or the safeguards in a few clear sentences.

In these cases, the options are to narrow the scope until the test passes, choose another basis (performance of a contract, legal obligation or consent, depending on the case) or not do the use at all.

Frequently asked questions

Can I use legitimate interest to send customer data to an AI tool? It may be possible, if the purpose is concrete, the data is limited to what is necessary and the balancing is favorable, with the safeguards implemented. You also need to check the contract with the provider, where the data is processed and whether the data is used to train the provider's model. Each of these points feeds into the assessment.

Do I need to tell the customer when I use legitimate interest with AI? Yes. Transparency is a requirement of art. 10 itself and of the LGPD principles. The notice should be in the privacy policy and, where it makes sense, at the point of contact, such as the first message of a support conversation. The data subject should also have a clear path to object or request review.

Does legitimate interest exempt me from an impact report? Not necessarily. The ANPD may request a data protection impact report when processing is based on legitimate interest, and higher-risk AI uses may justify preparing one on your own initiative. Keeping the written assessment current reduces the effort if a request arrives.

How often should I review the assessment? Review it whenever the purpose, the data type, the provider or the AI's level of autonomy changes, and after any relevant incident. Also set an internal periodic review, because models and tools change, and a balancing test done during the pilot may not hold in the expanded operation.

Sources

• ANPD: Autoridade Nacional de Proteção de Dados
• NIST AI Risk Management Framework
• OWASP Top 10 for LLM Applications