Brazil's AI Rules for US SaaS 2026: LGPD Article 20, the ANPD, and PL 2338

Four Ways an Offshore Vendor Lands in Scope

Each of these is independent. Any one of them is sufficient, and none of them requires you to have chosen Brazil as a market on purpose.

You process data of people located in Brazil

The LGPD reaches processing carried out anywhere when the data belongs to individuals in Brazilian territory, regardless of where your servers or your company sit. There is no employee threshold, no revenue threshold and no local-establishment requirement to cross first. A self-serve signup from São Paulo puts the processing inside scope on the day it happens.

You offer goods or services to the Brazilian market

Offering is judged by conduct rather than by intent — pricing in reais, Portuguese-language marketing, a local payment method, a .com.br property or a partner reselling locally are each the kind of fact that establishes targeting. An English-only product that happens to have Brazilian users is a weaker case; a product with a Portuguese onboarding flow is not arguable.

The data was collected in Brazil

Data collected in Brazilian territory stays in scope even after it moves. This matters most for acquisition and for vendor migrations: importing a customer list, absorbing a product, or taking over a partner's user base carries the origin of that data with it, and the diligence question 'where was this collected' is the one nobody asks until an inquiry arrives.

Your model was trained on data with a Brazilian origin

Training is processing. If Brazilian personal data went into a training set, the lawful basis, transparency and rights obligations attach to that processing as well as to inference. Purpose limitation is the pressure point: data collected to deliver a service and later reused to train a general model is a new purpose that needs its own basis and its own disclosure.

Article 20, Decomposed Into Things You Have to Build

This is the provision that reaches AI products directly, and it long predates any AI statute. For each element: what the law asks for, and the engineering artefact that satisfies it.

The right itself

What the law asks: A data subject may request review of decisions taken solely on the basis of automated processing that affect their interests — including decisions intended to define a personal, professional, consumer or credit profile, or aspects of their personality.
What you have to build: A channel that accepts a review request, an identity check proportionate to the decision, a queue with an owner, and a response inside the statutory window. Most products have none of these because the decision was never modelled as a decision — it was a status field that changed.

The scope trap in 'solely'

What the law asks: Solely automated is a narrower category than automated, but the escape hatch is smaller than teams assume. A human who approves a queue of model outputs at a rate that precludes individual consideration is not meaningful involvement, and the record of how long each review took is discoverable.
What you have to build: If you rely on human involvement to stay outside the article, instrument it: who reviewed, what they saw, how long they had, and whether they ever overturned the model. A zero-overturn rate across thousands of reviews is evidence against you, not for you.

Information about the criteria

What the law asks: The controller must provide clear and adequate information about the criteria and procedures used in the automated decision, subject to commercial and industrial secrecy.
What you have to build: A per-decision explanation artefact that names the inputs and the logic at a level a person can act on. Trade-secrecy is a real limit and a badly overused one — withholding everything and citing secrecy invites the regulator to audit the very thing you were protecting.

The audit power when secrecy is invoked

What the law asks: Where the controller refuses to disclose on secrecy grounds, the supervisory authority may carry out an audit to verify discriminatory aspects of the automated processing.
What you have to build: Assume the audit and prepare for it: a retained record of model versions, training data provenance, evaluation results by protected characteristic, and the decisions each version produced. This is the single most under-built artefact in AI products selling into Brazil.

What the AI Bill Adds on Top

The dedicated statute does not replace the LGPD; it layers a risk-based regime over it. Treat the four items below as the shape to plan against, and confirm the final text before you rely on any specific threshold or deadline.

Layer	What it means for a vendor
Risk classification	The AI bill follows the now-familiar structure of prohibited uses, a high-risk category with heavy obligations, and lighter transparency duties for everything else. High-risk categories track consequential decisions — credit, employment, education access, essential services, biometric identification, health. If your product decides one of those for a Brazilian user, plan for the heavy tier.
Rights that attach to affected persons	Beyond the LGPD's review right, the bill contemplates a right to information before an AI-mediated interaction, a right to explanation of a decision, a right to contest, and a right to human review of consequential outcomes. In practice these collapse into one product requirement: a decision must be explainable and reversible by a person, on request, after the fact.
Governance and documentation	Impact assessments for high-risk systems, an accountable governance structure, incident reporting to the authority, and retained technical documentation. This is the ISO-42001-shaped work, and a company that has built a management system for another regime will be reusing it rather than starting over.
The supervisory architecture	The ANPD is positioned to coordinate, with sector regulators keeping their existing authority over their own industries. The practical consequence for a vendor is two-headed: the data-protection authority and the financial, health or consumer regulator can each reach the same product, and they will not coordinate their timelines for your convenience.

The Regimes That Will Be Pleaded Alongside It

Brazilian claimants do not plead one statute. A single automated-decision dispute typically arrives wearing several of these at once, and only the first is a data-protection matter.

Consumer Defence Code (CDC)

Brazil's consumer statute predates all of this and is aggressively enforced. It reaches misleading advertising, unfair contract terms and defective services — which is the doctrine an over-claimed AI feature lands in. It also supports collective actions brought by public prosecutors and consumer bodies, which is a materially different threat model from individual complaints.

Marco Civil da Internet

The internet framework governs connection and access-log retention, due process for content removal, and net-neutrality principles. Products that host or moderate user content inherit obligations here that have nothing to do with the AI layer but that a Brazilian claimant will plead alongside it.

Central Bank and sector rules

Credit, payments and open-finance products sit under regulation that has its own model-governance expectations and its own reporting. A fintech vendor cannot treat the LGPD as the ceiling; the sector regulator's requirements bind the same feature independently.

Labour law

Brazilian employment law is protective and its courts are accessible. Automated performance, scheduling or termination decisions applied to workers in Brazil generate exposure in a forum that is quick, cheap for the claimant, and not sympathetic to the argument that a vendor's model made the call.

The review-request drill

Pick any automated outcome your product produces — a rejected application, a suppressed listing, a risk score, a plan downgrade. Now answer, without engineering help: which inputs drove it, which model version produced it, who inside your company can overturn it, how a user in Brazil would ask you to, and how long that takes.

That is Article 20 in operational form. If any answer is "we would have to go look", the answer to a real request is the same, except with a statutory clock attached and an authority entitled to audit for discriminatory effect when you decline to explain.

Frequently Asked Questions

Does the LGPD apply to a US SaaS company with no Brazilian entity?

Yes, on any of three independent triggers: processing personal data of individuals located in Brazil, processing for the purpose of offering goods or services to the Brazilian market, or processing data that was collected in Brazilian territory. None of them requires a local subsidiary, a local server, a revenue threshold or an employee count — the statute is written to reach exactly the offshore-vendor case. The practical obligation that surprises US teams most is the representative requirement: a controller not established in Brazil that processes under these triggers is expected to appoint a representative in the country, and to publish contact details for a data protection officer that a Brazilian data subject or the authority can actually reach. A support inbox in English routed to a US timezone is not a compliant channel, and the absence of one is the easiest possible finding for a regulator to make because it is visible from outside your company.

What is LGPD Article 20 and why does it matter more than the AI bill right now?

Article 20 gives a data subject the right to request review of decisions taken solely on the basis of automated processing that affect their interests, expressly including decisions that define a consumer, credit, professional or personality profile. It is in force, it has been in force for years, and it applies to your product today, whereas the dedicated AI statute is still moving through its process. Two things about it are frequently misread. First, the review right is not limited to the credit and employment cases everyone thinks of — 'affecting their interests' is broad, and account restrictions, content demotions, pricing decisions and risk scores all sit inside it comfortably. Second, the controller must provide clear information about the criteria and procedures used, and where the controller declines on trade-secrecy grounds, the authority is empowered to audit the processing for discriminatory effects. Refusing to explain therefore does not close the question; it escalates it to someone with more powers than the data subject had.

Can we rely on legitimate interest to train models on Brazilian user data?

Sometimes, and the analysis has to be done and documented before the training rather than reconstructed after a complaint. The LGPD provides legitimate interest as a basis, but constrains it: it supports processing for legitimate purposes considered from concrete situations, it requires a balancing against the data subject's rights and reasonable expectations, and it cannot be used for sensitive personal data, which has its own narrower list of bases. Three failure modes recur. Reusing service data to train a general-purpose model is a purpose change that the original collection notice did not cover, and reasonable expectation is judged from what you told the user, not from what your terms permitted in principle. Sensitive categories — health, biometric, racial or ethnic origin, religious or political data, union membership — cannot ride on legitimate interest at all, and 'we did not intend to collect it' is not a defence when free-text fields and uploaded documents routinely contain it. And the balancing test must be recorded: the authority's first request in any inquiry is the assessment document, and producing one dated after the complaint is worse than producing nothing.

How do we move Brazilian personal data to the United States lawfully?

Through one of the transfer mechanisms the LGPD recognises, with the standard contractual clauses published by the ANPD being the practical route for most vendors. The clauses are not the GDPR's — the ANPD issued its own, with its own timetable for bringing existing contracts into line, and a US company that has simply pasted its European annexes into a Brazilian agreement has not done the work. Two operational points get missed. The clauses have to reach the sub-processor layer, so every downstream vendor in the chain — model API, logging platform, analytics, support tooling — needs to be papered consistently, and the inventory of who receives Brazilian data is usually incomplete the first time anyone builds it. And a transfer impact analysis is expected in substance even where it is not named as such: the point is to show you considered the destination's legal environment and the safeguards applied, not to produce a specific document title. Start from the data map. Almost every failure here is a vendor nobody knew was in the path.

What are the penalties, and how are they actually applied?

The headline sanction is a fine of up to two percent of revenue in Brazil for the prior year, capped at fifty million reais per violation, alongside daily fines, public disclosure of the infraction, blocking or deletion of the data concerned, and partial or total suspension of the processing activity. For a foreign vendor with modest Brazilian revenue, the monetary cap is often less alarming than the operational sanctions: an order to suspend processing is a product outage for that market, and publication of the infraction is a durable procurement obstacle. The more common commercial reality, though, is that the ANPD is not the party you meet first. Brazilian enforcement is pluralistic — public prosecutors, consumer protection bodies and the courts all have independent routes, and collective actions are a normal instrument rather than an exotic one. A single automated-decision complaint can therefore arrive as a regulatory inquiry, a consumer body demand and a civil claim in parallel, and the response to each will be judged against the same missing documentation.

We are the processor, not the controller. Does that reduce the exposure?

It reallocates it rather than removing it, and the LGPD's allocation is less forgiving than teams expect. Brazilian law uses controller and operator, and the operator carries direct statutory duties around security, incident notification, retention of processing records and acting on the controller's instructions. More importantly, the LGPD contemplates joint and several liability in circumstances where the operator fails to comply with its obligations or acts outside the controller's lawful instructions — and a vendor whose model makes a scoring or ranking decision the customer merely consumes will have real difficulty maintaining that it exercised no influence over purposes or means. The determination is made on the facts of who decided what, not on the label in the agreement. If your product ships a model you trained on your own data, that you version and change on your own schedule, and whose outputs the customer cannot inspect, you are closer to a controller of that processing than your contract says.

What should we build first if Brazil is a small share of revenue?

Build in this order, because it front-loads the items that are both cheap and visible from outside. First, the contactable channel: a published data protection officer contact, a Portuguese-language privacy notice, and a representative arrangement if the triggers apply — this is the finding a regulator can make without opening a file, so remove it. Second, the automated-decision inventory: list every place your product changes a person's outcome without a human deciding, because you cannot honour a review right you have not enumerated, and this exercise typically surfaces three to five decisions nobody had classified. Third, the review workflow for those decisions: a request intake, an identity check, a human with authority to overturn, a response within a defined window, and a log. Fourth, the documentation set — lawful-basis records, the legitimate-interest balancing where relied upon, the transfer clauses down to sub-processors, and retained evaluation results. Everything after that is refinement. Notice that only the third item is meaningful engineering work; the rest is inventory and paperwork that gets done badly precisely because it is not engineering work.

Everyone Is Waiting for Brazil's AI Law. Brazil Already Regulates Your Model.