
LGPD Automated Decision-Making: The Right to Review (Art. 20)
Art. 20 of Brazil's LGPD gives people the right to review automated decisions. Learn what it says and how to build a review process for AI projects.
Want to apply this in your company?
Book a call with Juan →LGPD Automated Decision-Making: The Right to Review (Art. 20)
Article 20 of Brazil's LGPD (the general data protection law) gives data subjects the right to request a review of decisions made solely through automated processing of personal data, when those decisions affect their interests. That includes decisions meant to define a personal, professional, consumer or credit profile. In practice, if you use AI to approve, deny, classify or prioritize people, you need a channel to receive review requests, a way to explain the criteria used, and a process to reassess the case. This article explains the rule and proposes a review structure for AI projects. It is not legal advice.
Key takeaways
- Article 20 applies to decisions based solely on automated processing that affect the data subject's interests, not to every use of AI.
- The data subject can ask for clear information about the criteria and procedures behind the decision, with trade secrets and industrial secrets respected.
- The current text does not expressly require a person to carry out the review, but designing the flow with human review is the safer choice.
- A review request only works if the company kept a record of what was decided, using which data, and by which version of the system.
- The simplest path is to map where AI makes a relevant decision, limit that power, and test the review flow in a pilot before scaling.
What Article 20 of the LGPD says
The main provision of Article 20 recognizes the data subject's right to request a review of decisions made solely through automated processing of personal data that affect their interests. The text lists examples: decisions meant to define a personal, professional, consumer or credit profile, or aspects of a person's personality. The list is illustrative. The central test is the effect on the data subject, not the label put on the decision.
The first paragraph deals with transparency. The controller must provide, whenever requested, clear and adequate information about the criteria and procedures used in the automated decision, with trade secrets and industrial secrets respected. The second paragraph provides that if the company fails to provide that information by invoking a trade or industrial secret, the ANPD (Brazil's data protection authority) may carry out an audit to check for discriminatory aspects in the automated processing.
This right connects to the principles in Article 6 of the LGPD, especially transparency, data quality, prevention and non-discrimination. The full text is published on the Brazilian government's Planalto website, and the ANPD publishes guidance and regulatory acts worth following, because interpretation keeps evolving.
When is a decision solely automated?
The word "solely" causes the most doubt. A decision is solely automated when the system reaches the result and that result takes effect without a person genuinely evaluating the case. If an agent just clicks "confirm" on the AI's suggestion, with no criteria and no power to disagree, you risk treating it as a human decision when in practice it is not.
To tell the cases apart, it helps to classify each AI use into three levels:
- Support: the AI summarizes, organizes or suggests, and a person decides with real autonomy and enough information.
- Decision with oversight: the AI decides, but there are exception rules, sampling and a clear way to reverse the outcome.
- Fully automatic decision: the AI decides and the result applies directly, with no prior intervention.
Article 20 weighs most on the third level and, depending on the design, on the second. The effect matters too. Classifying a message as a "question about opening hours" is unlikely to affect the data subject's interests. Denying an installment plan, refusing an enrollment, blocking a registration or setting service priority in a sensitive situation is a different matter.
To decide what should stay out of full automation, also read what not to delegate to AI in business.
Does a person have to carry out the review?
The answer needs care. Earlier versions of the law's text said the review had to be done by a natural person. That requirement is not in the wording currently in force, and an attempt to restore it during the legislative process was vetoed. So the law does not expressly say a human must review.
That does not mean any automated review will do. The right is to a review of a decision that affects the data subject, and a review that simply runs the same model on the same data hardly serves that purpose. There is also a practical risk: if the data subject goes to the ANPD or to court, a company that can show an independent reassessment with documented criteria is in a much better position.
For that reason, the project recommendation is simple: make review by a person with authority to change the outcome the default, and use automated review only as a triage step. Anyone planning a different approach should consult legal counsel and follow the debate described in Brazil AI Regulation: What Companies Should Watch and Do Now, since AI-specific regulation may still change the picture.
What the company must be able to explain
Paragraph 1 requires clear and adequate information about criteria and procedures. This does not oblige you to hand over code, model weights or full prompts, since trade and industrial secrets are expressly respected. But the company must be able to answer, in plain language, questions such as:
- Which personal data was considered in the decision?
- Where did that data come from (registration, history, conversation, third parties)?
- Which rules or criteria weighed on the result?
- Which part was done by a system and which part by a person?
- How can the data subject contest it, and what happens next?
If the honest answer is "we do not know why the system decided this", you have a design problem, not a communication problem. Systems built on language models can produce convincing justifications that do not match what actually influenced the result. That is why the explanation should come from system records (data used, rules applied, version) and not from asking the model to justify itself afterward.
The NIST AI Risk Management Framework and the OECD AI Principles treat transparency, explainability and human oversight as risk management practices. They are not Brazilian law, but they help structure what to document.
How to structure the review request: step by step
A working review flow is a small operational process, not just a clause in the privacy policy. One possible sequence:
- Inventory the decisions: list where AI or an automatic rule approves, denies, classifies or prioritizes people, and flag those that affect significant interests.
- Define the channel: an email, a form or an option in WhatsApp itself with clear wording, such as "I want a person to reassess this decision". The channel should be easy to find and should not require a new account.
- Notify at the moment of the decision: say that the result came from automated processing and how to request a review.
- Record the decision: keep input data, rules applied, output, model or flow version, date and who was notified.
- Assign the reviewer: a person with access to the full case, authority to reverse the outcome, and instructions not to simply confirm the system.
- Set an internal deadline and a reply: define a response time consistent with the right and answer clearly, with the result and the criteria.
- Fix the cause: if the review reveals wrong data or a poor criterion, adjust the flow and record the change.
- Track indicators: volume of requests, how many were reversed and why. Frequent reversals point to a design problem.
For higher-impact decisions, this process usually connects to the Data Protection Impact Assessment for AI Projects (LGPD RIPD), which is the natural place to record risks, mitigation and the general logic of the processing.
Illustrative scenario
Consider, as an illustrative scenario, a store that offers installment payments and uses a WhatsApp agent to pre-screen orders. The agent checks registration data and purchase history and automatically replies whether the installment plan was approved.
Without a review design, the customer gets a "we could not approve this" message and nothing more. With the recommended design, the message says the analysis was automated, summarizes the types of criteria considered and offers the option "ask for a person to reassess". When the customer chooses it, the case goes to a queue with the complete record: data used, rule applied, reply sent. The reviewer can correct outdated data, accept a new proof of payment, or keep the denial with an explanation. If many reversals come from outdated data, the fix belongs in the quality of the database, not in customer service.
The same reasoning applies to other sectors where AI touches decisions about people, such as school admissions or prioritization in support and collections.
How our method applies to this topic
Our working method has four steps. Map: survey the current process, identify where decisions about people are made and which data goes into them. Limit: restrict the agent's data and actions so that higher-impact decisions always go through human approval and logging. Pilot: test a real flow with logs and an agreed success metric, including the review flow, to confirm it works before scaling. Transfer: hand over the operation with documentation, named owners and a decision to expand, adjust or stop.
In the pilot, measure the quality of the review too, not just the time saved. The article on how to measure an AI automation pilot details metrics and decision gates that help with this.
Another design note: when the company uses an AI vendor or platform, the split between controller and processor affects who answers to the data subject. Define it in the contract and in the process, not just in the sales pitch. See Data Controller vs Processor in an AI Vendor Contract (LGPD) for how to approach it.
Frequently asked questions
Does Article 20 ban automated decisions? No. The LGPD does not prohibit decisions made through automated processing, but it guarantees the data subject the right to request a review and to receive clear information about criteria and procedures. The company still needs a legal basis for the processing and must respect the principles in Article 6.
Is a chatbot that only answers questions an automated decision? Generally not. Answering questions about opening hours or order status does not normally define a profile or affect the data subject's interests in the way Article 20 describes. The risk appears when the agent starts approving, denying, classifying or prioritizing people with a relevant effect, and in that case it is wise to treat the flow as an automated decision.
Can I refuse to explain the criteria because of trade secrets? Trade and industrial secrets are respected by the law, but they do not work as a blanket refusal. The company must still provide clear and adequate information about criteria and procedures at an understandable level, and the ANPD may carry out an audit to check for discriminatory aspects if the information is not given.
Do I need a lawyer to build this flow? The operational design can be built by people who know the process and the technology, but the interpretation of what counts as a solely automated decision, the legal basis and the wording shown to data subjects should be validated by legal counsel or a data protection officer. Ideally both teams work together from the mapping stage.