Brazil AI Regulation Explained: LGPD and What Follows

Brazil's data protection law already reaches AI systems directly, including a right to request review of automated decisions. That makes explanation capability a present requirement rather than a future one. This guide covers what applies today, drawing on FISTA Solutions' AI enablement work. This article is general guidance, not legal advice.

What applies to AI in Brazil today?

Data protection law reaching automated decisions directly, plus sector supervision.

Source	What it reaches
Data protection law	Personal data, automated decisions, rights
Right to review	Decisions made solely on automated processing
Sector supervision	Financial services, health, and others
Consumer protection	Claims and practices, including AI claims
Proposed AI legislation	Under consideration; track the position
Contractual requirements	Frequently stricter than the baseline

What does the automated decision provision require?

Where decisions are made solely on automated processing and affect a person's interests — including credit, employment, and profiling contexts — the person may request review, and the controller must provide clear information about the criteria and procedures used.

Trade secret considerations apply to how much detail must be given, but the obligation to explain the basis and to offer review does not disappear because the model is proprietary. See what is the right to explanation.

What does that mean for system design?

Two things. First, the system must record enough to explain the basis of a decision after the fact, which means storing inputs and intermediate signals rather than only outputs.

Second, a review path has to exist operationally: someone who can look at a case, understand what happened, and change the outcome. A review process that routes to a team without access to the decision's basis is not a review path, and that becomes obvious the first time it is used.

What about sector supervision?

Financial services and other regulators apply existing powers within their remits, covering model risk, customer outcomes, and operational resilience.

For a regulated firm those expectations are usually the more immediate constraint, and their published guidance is considerably more relevant than general commentary about pending legislation.

What evidence do you need?

An inventory with named owners, records of lawful basis and purpose, the criteria and procedures behind automated decisions, evidence that a review path exists and has been used, and impact assessments where required.

If that evidence exists as a by-product of how systems are built and operated, you are in good shape. If it exists only as documents written for a review, you are not, and the difference is visible to anyone who looks carefully.

How does this change engineering practice?

It makes explanation capability a present design requirement. Systems influencing decisions about people need to store the inputs and signals that produced each outcome, because reconstructing them afterwards is usually impossible.

That has cost and retention implications worth deciding deliberately: storing decision bases for the required period is a design choice with storage and privacy consequences, and it conflicts with minimisation instincts unless it is planned.

How does it interact with other regimes?

Usually more than expected. The same system can attract questions from a data protection authority, a sector supervisor, and a general AI regulator, each starting from a different premise and arriving at overlapping requirements.

One evidence base mapped to several requirements answers all of them. Separate programmes produce separate documents describing the same systems, and inconsistencies between them are themselves a finding.

What does compliance cost?

Mostly the cost of good engineering practice: evaluation, documentation, logging, and oversight design. Built into a project, the incremental cost is modest and much of it is work the system needed anyway.

Retrofitted onto a live system it becomes a project, performed under a deadline you did not choose, on something people already depend on. See AI compliance audit cost.

What are the common mistakes?

Assuming the automated decision provision only applies to fully automated systems in a narrow sense. Logging outputs without inputs. Building a review process with no access to decision bases. And waiting for dedicated AI legislation before doing anything.

Who owns this internally?

The function that owns the systems, with legal and compliance support. Ownership by compliance alone produces documents describing systems nobody changed; ownership by engineering alone produces good practice with no one accountable for the interpretation.

Name a person per system rather than a committee. Committees review; people decide.

What should you ask a supplier?

What documentation they provide about capabilities and limitations, what evaluation evidence they share, how they handle personal data, where processing happens, and what happens to your prompts and outputs.

Suppliers who have prepared answer those quickly. Suppliers who have not take weeks, and that delay is itself information about how the relationship will run.

How do you keep this current?

Assign someone to watch the sources that actually bind you rather than general commentary. Record what was checked and when, so the next review starts from a known point.

Rules in this area change, and a position taken eighteen months ago and never revisited is a risk in itself.

How should organisations prepare for new legislation?

By building explanation capability, inventory, and assessment now. Proposals in this area consistently include risk classification, documentation, oversight, and rights for affected people.

An organisation that already records decision bases, maintains an inventory, and assesses systems by context will experience new legislation as a mapping exercise. One that does not will experience it as a programme.

What should you do first?

Take one system that influences decisions about people and try to explain a specific past decision using only what you logged. That test tells you whether you can meet the requirement that already exists.

How FISTA Solutions helps

FISTA Solutions builds AI systems so the evidence exists when it is needed: decision bases recorded so past outcomes can be explained, review paths that give reviewers access to the evidence behind a decision, evaluation results dated and versioned, oversight designed structurally rather than asserted in policy, and documentation produced during the build rather than reconstructed afterwards. Delivery runs through AI enablement, AI agents, and forward deployed engineers. The record is 150+ projects for 50+ companies across 12+ countries.

To align a system with these requirements, message FISTA on WhatsApp, or read what is the right to explanation.