top of page

Explainable AI in Credit: What the LGPD Right to Review Requires in Practice

Writer: Zayon
Zayon
Jul 30
5 min read

Updated: 1 day ago

Logo Zayon em fundo preto com Trustworthy AI Decision Infrastructure, Record Governance Proof e círculos vermelhos concêntricos.

This article discusses regulatory concepts for general information. It is not legal advice. Institutions should consult their legal counsel on how these obligations apply to their specific operations.


When a customer in Brazil is denied credit by an automated system, the conversation often doesn't end there. Under the LGPD, Brazil's General Data Protection Law, individuals have the right to request review of decisions made solely on the basis of automated processing of their personal data when those decisions affect their interests, including decisions that define their credit profile.


For financial institutions using AI in credit, this right raises a practical question that goes beyond compliance checklists: when a customer asks why, what exactly does the institution need to be able to explain?


The answer is more demanding than most institutions assume, and different from what most explainable AI tools provide. Explaining a model is not the same as explaining a decision.


What Article 20 establishes

Article 20 of the LGPD sets out three elements that matter for automated credit decisions.

  • The right to request review. The data subject may request review of decisions made solely on the basis of automated processing of personal data that affect their interests, including decisions intended to define their personal, professional, consumer or credit profile, or aspects of their personality.

  • The duty to inform. When requested, the controller must provide clear and adequate information about the criteria and procedures used for the automated decision, observing commercial and industrial secrets.

  • Oversight when information is withheld. If the controller declines to provide that information on the grounds of commercial or industrial secrecy, the national data protection authority, the ANPD, may carry out an audit to verify discriminatory aspects in the automated processing.

  • One detail of the law's history is often misunderstood. The original text required that the review be carried out by a natural person. That requirement was removed by a 2019 amendment, and a later attempt to restore it was vetoed, with the veto upheld by Congress.


The current text does not explicitly require human review. In practice, many institutions still involve people in reviews, and for good reason, but the legal obligation is to review and to inform, not necessarily to place a human in every case.


Why explaining the model isn't enough

Most explainable AI techniques answer questions about models: which variables most influenced this score? How would the score change if income were higher? These are useful questions for data scientists. They are not the questions a customer, or a regulator, is asking.

When a customer asks why their request was denied, they are asking about the decision. And in most institutions, the decision is not the model's output. It is the result of a chain:

evidence → model signals → credit policy → outcome → action


A model explanation covers one link in that chain. It says nothing about which policy criteria were applied, which thresholds the score was compared to, whether evidence was missing, whether an analyst intervened, or what the customer could change to obtain a different outcome.


An institution that can explain its model but not its decision has answered a question no one asked.


What a decision explanation must contain

To meet the duty to provide clear and adequate information about criteria and procedures, and to make review meaningful, a decision explanation should cover five things:

  1. The outcome. What was decided: approved, denied, approved with conditions, or referred for review.

  2. The criteria applied. Which policy rules determined the outcome, stated in terms the customer can understand.

  3. The evidence considered. Which categories of information the decision relied on, and whether any required information was missing or outdated.

  4. The procedure. How the decision was made: which steps were automated, whether a person was involved, and how the customer can request review.

  5. What would change the outcome. Where possible, which factors, if different, would lead to a different decision.


None of these require disclosing a model's internal structure. All of them require the institution to know, for each decision, exactly which policy and evidence produced it.


Resolving the tension with trade secrets

Article 20 explicitly protects commercial and industrial secrets. Institutions and their vendors often use that protection as a reason to disclose very little. That approach is risky: it invites ANPD scrutiny, and it fails the customer.


A cleaner approach is to separate two layers that are often confused:

  • The credit policy: the criteria, thresholds and rules the institution uses to decide. This is what customers need to understand, and what the institution is accountable for.

  • The model internals: the architecture, weights, training data and feature engineering behind a score. These are legitimately protected, and disclosing them rarely helps a customer understand anything.


When policy and model are separated architecturally, with the model producing a signal and an explicit policy producing the decision, institutions can explain decisions in full without exposing proprietary models. The explanation describes the criteria and how the customer's case met or failed them. The model remains protected.


When policy and model are entangled, with the "policy" being whatever the model does, every explanation becomes a negotiation between transparency and secrecy.


Review is itself a decision

The right to review only has meaning if the review is real. That requires three conditions.

  • The original decision can be reconstructed. The reviewer must see exactly what the system saw: the evidence at that moment, the model version, the policy version and the outcome. If the decision can't be reproduced, the review is a new decision on different information, not a review of the original.

  • The review follows its own defined procedure. Who can review, with what authority, under which criteria and within what time frame should be defined in advance, not improvised for each request.

  • The review is recorded. The outcome of the review, whether it confirms or changes the original decision, and the reasons, should be recorded with the same rigor as the original decision. A review is itself a decision, and it needs its own record.


Recorded reviews also produce a valuable signal. If reviews frequently overturn a certain type of decision, the policy, the evidence or the model behind it probably needs attention.


Beyond the LGPD

The right to review under the LGPD is one of several reasons explainability in credit has moved from best practice to necessity.


Consumer protection rules and banking regulations on fair treatment of customers expect institutions to treat customers transparently and consistently. Supervisors increasingly expect institutions to govern the models behind their decisions. And Brazil's ongoing debate on AI regulation points toward stronger obligations for high-risk uses, a category in which credit decisions are commonly placed.


The common thread is the same: institutions must be able to show not only what their models do, but how their decisions are made, under which rules, and with what accountability.


What institutions should be able to do

  1. Separate the credit policy from the model, so decisions can be explained without exposing model internals.

  2. Record, for every automated decision, the evidence, model version, policy version and outcome.

  3. Generate a clear, customer-facing explanation of criteria and procedure for any decision.

  4. Reproduce any past decision exactly as it was made.

  5. Run reviews under a defined procedure, with defined authority.

  6. Record every review as a decision, with its outcome and reasons.

  7. Monitor review outcomes to identify policies or models that need attention.

  8. Provide records in a format the ANPD or other supervisors can examine if required.


Explain the decision, not just the model

The LGPD's right to review is often treated as a compliance burden. It is better understood as a design requirement: a decision that can't be explained to the person it affects is a decision the institution doesn't fully control.


Institutions that build credit decisions on explicit policy, recorded evidence and reproducible outcomes will find the right to review straightforward to meet. Those that rely on model explanations alone will find every request harder than it should be.


Customers don't ask how the model works. They ask why the decision was made. Institutions need to be able to answer.


Want to see how explainable, reviewable credit decisions work in practice? Talk to our team →


Related Posts

See All
Decision Infrastructure for the Agentic Economy

AI systems are beginning to act: approving transactions, adjusting limits, initiating payments, executing trades, negotiating with other systems on behalf of people and companies. When an AI system ac

 
 
 

Comments


The Zayon Briefing

Topics you're interested in:

A periodic briefing on AI decision infrastructure, governance and what it means for financial institutions. No noise.

STAY INFORMED 

bottom of page