Brazil does not have an AI act in force. It has a comprehensive AI bill, PL 2338/2023, that the Federal Senate approved on 10 December 2024 and sent to the Chamber of Deputies, where it has been under review by a special committee since. It also has laws that already apply to AI systems today, above all the general data protection law (LGPD), enforced by the national data protection authority (ANPD). Engineers building for Brazilian users therefore face two questions at once: what must my system do now, and what will it have to do if the bill passes in roughly its Senate form?
This article answers both from an engineering point of view and ends with a control set that serves either outcome. It deliberately does not repeat the data protection detail in LGPD for LLM applications; read that next. This is not legal advice. The status described here is as of early October 2026, and a bill in committee can change completely before a vote, so check the Chamber's record before relying on any provision.
Where the bill stands
The timeline so far: the bill was introduced in the Senate in 2023, reworked by a temporary Senate committee during 2024, and passed by the full Senate in December 2024. In the Chamber of Deputies a special committee took it up in 2025, with Deputy Aguinaldo Ribeiro as rapporteur. In December 2025 the executive sent a companion bill to fix a constitutional problem in the governance chapter (a legislative initiative defect: Congress cannot create duties for executive bodies on its own), designating the ANPD as the residual AI regulator for activities not covered by a sectoral regulator. As of the Chamber's record in early September 2026, the bill was still awaiting the committee opinion.
Two practical consequences follow. First, nothing in PL 2338/2023 creates an obligation today. Second, the text you plan against is the Senate text, and the Chamber may change tiers, deadlines and sanctions. Brazil is holding general elections this month, and the legislative calendar around elections is unpredictable; do not plan on a specific enactment date. Plan on controls that are useful regardless.
What binds AI systems today
The binding layer today is made of general laws that happen to reach AI systems.
- LGPD. Any processing of personal data of people in Brazil needs a legal basis, honours data subject rights and may need a data protection impact report (RIPD) when the ANPD asks for one. Article 20 gives the data subject the right to request review of decisions taken solely on the basis of automated processing that affect their interests, including profiling, and to receive clear information about the criteria and procedures used, subject to trade secrets. For AI products this is the most important existing rule: it already requires an explanation path and a review path for automated decisions.
- ANPD enforcement. The authority has acted on AI directly. In July 2024 it ordered Meta to suspend the use of Brazilian users' personal data to train its AI models, citing the legal basis and information given to users, and lifted the measure after Meta committed to changes. Expect the ANPD, which the AI bill would put at the centre of AI oversight, to keep using LGPD tools on training data, children and transparency.
- Consumer Defense Code. Consumer-facing AI is a product or service under the CDC: information duties apply, abusive practices are prohibited, and suppliers answer for defects. A chatbot that gives a customer wrong contract terms is a consumer problem before it is an AI problem.
- Sector rules. Electoral authorities have regulated AI-generated campaign content, including labelling duties and a ban on deceptive deepfakes, and financial and health regulators apply their existing model-risk, outsourcing and product rules to AI. See AI finance regulation for the financial pattern.
What the Senate text would add
The Senate text follows the risk-based design familiar from the EU, with Brazilian choices layered on top.
- Excessive risk, prohibited. Systems that exploit vulnerabilities or use subliminal techniques to cause harm, and government social scoring, are among the banned uses.
- High risk, regulated. The list covers uses such as education and admissions, recruitment and employment decisions, access to essential public and private services, law enforcement, migration and border control, the administration of justice and critical infrastructure. Credit scoring was left out of the high-risk list in the Senate text, a contested choice the Chamber may revisit.
- Assessments. Systems would be classified through a preliminary risk assessment (who must perform it, and when, depends on the final text), and high-risk systems would need an algorithmic impact assessment, plus governance measures such as documentation, testing, logging and human oversight.
- Rights of affected persons. Prior information that one is dealing with AI, explanation of decisions, the right to contest, human review or human participation in significant decisions, and protection against unlawful discrimination.
- Generative and general-purpose AI. The Senate added obligations for these models, and a copyright section requiring transparency about protected works used in training and letting rights holders object to their use; the remuneration details remain disputed.
- Governance and sanctions. A national system (SIA) coordinated by the ANPD with sectoral regulators, and fines of up to R$50 million or 2 percent of revenue in Brazil per infringement, among other sanctions.
Compared with the EU AI Act, covered in the EU AI Act article, the Brazilian text puts more weight on individual rights of affected people and on the data protection authority, and its maximum fines are much lower than the EU's turnover-based ceilings. If you already comply with the EU regime, most of the technical work transfers; the differences are in the rights workflow, the regulator and the language of the notices.
One control set for both regimes
The mapping is the core idea of this article. LGPD Article 20 already demands an explanation and a review path for automated decisions; the bill would broaden who can ask and what must be documented. The LGPD impact report already forces you to describe processing and risks; the bill would add an algorithmic impact assessment with a specific scope. An AI system inventory with a risk classification is useful for both. Build the plumbing now and the bill, if it passes, changes the evidence your plumbing must output rather than the architecture.
An inventory and triage you can run
Start with a machine-readable inventory. Every AI system gets a record that answers the questions both regimes ask: what does it decide, about whom, using what data, and with what human involvement. The classifier below encodes the Senate text's tiers as a first-pass triage, not a legal determination; it exists so that lawyers review a short list instead of every system.
from dataclasses import dataclass, field
HIGH_RISK_USES = { # Senate text of PL 2338/2023; update when the Chamber changes it
"recruitment", "employment_decision", "education_admission", "essential_service_access",
"law_enforcement", "migration_border", "justice_administration", "critical_infrastructure",
}
PROHIBITED_USES = {"subliminal_manipulation", "exploit_vulnerability", "government_social_scoring"}
@dataclass
class AISystem:
name: str
use: str # one controlled vocabulary value
affects_people_in_brazil: bool
automated_decision: bool # decides without a human in the loop
personal_data: bool
model_provider: str
trained_on_third_party_works: bool = False
owners: list = field(default_factory=list)
def triage(s: AISystem) -> dict:
out = {"system": s.name, "today": [], "if_bill_passes": []}
if not s.affects_people_in_brazil:
return out
if s.personal_data:
out["today"].append("LGPD: legal basis, rights, RIPD on request")
if s.personal_data and s.automated_decision:
out["today"].append("LGPD Art. 20: criteria disclosure and review on request")
if s.use in PROHIBITED_USES:
out["if_bill_passes"].append("PROHIBITED: escalate to legal now")
elif s.use in HIGH_RISK_USES:
out["if_bill_passes"] += ["algorithmic impact assessment", "human oversight design",
"logging and documentation", "contest and human review path"]
else:
out["if_bill_passes"].append("preliminary assessment on file")
if s.trained_on_third_party_works:
out["if_bill_passes"].append("training-works disclosure and opt-out handling")
return outKeep the vocabulary of uses controlled and versioned. When the Chamber publishes its opinion, you change two sets and rerun triage across the inventory, and the diff is your gap list. The broader method of turning regulation into dated obligations and evidence is in regulation as an engineering problem.
Worked example: an LLM that screens job applicants
Take a concrete case: a company screens job applications in Brazil with an LLM that reads CVs in Portuguese, scores fit against the job description and auto-rejects the lowest third.
Today. The CVs are personal data, so the company needs a legal basis and must answer access and correction requests. The auto-rejection is a decision based solely on automated processing that affects the candidate's interests, so Article 20 applies: a rejected candidate can request review and clear information about the criteria. That requires three things the team must build: a decision record per candidate (model version, prompt template version, inputs used, score, threshold), a plain-Portuguese summary of the criteria, and a queue where a recruiter reviews contested decisions with the record in front of them. If the CVs or scores go to a model provider abroad, the international transfer rules apply as well.
If the bill passes in the Senate form. Recruitment is on the high-risk list. The company would add an algorithmic impact assessment covering bias testing across groups, the human oversight design and logging, and would have to tell candidates up front that AI is used. The decision record, criteria summary and review queue built for Article 20 become the evidence for the explanation, contest and human review rights. The cheapest engineering change, removing the auto-reject so a human confirms every rejection, reduces exposure under both regimes; whether it is worth the recruiter time is a business decision the inventory makes visible.
Controls that pay off either way
These controls pay off under current law and under the bill.
- Decision log. For every automated decision about a person: system and model version, prompt and policy versions, input references, output, confidence and the human who confirmed it, if any. Retain per your LGPD retention policy.
- Explanation generator. A template, reviewed by legal, that turns the log into Portuguese text describing criteria and main factors without exposing trade secrets.
- Review path. A queue with an SLA where a qualified human can overturn the decision, and whose outcomes feed back into evaluation.
- Bias testing. Disparity metrics per protected group on held-out data before release and on production samples monthly.
- Training data provenance. For anything you train or fine-tune: sources, licences, personal data flags and a register of rights-holder objections you honour.
- AI disclosure. A notice in Portuguese at the point of interaction, and labelling for generated media.
- Incident log. Serious failures recorded with impact and fix; the data breach notification duty to the ANPD already exists for security incidents involving personal data.
Failure modes
- Treating the bill as law. Teams copy obligations from a summary, ship them as policy, and then the Chamber changes the text. Label every bill-derived control as anticipated and keep its source.
- Treating the bill's absence as freedom. Article 20, the CDC and ANPD enforcement apply now. The Meta suspension shows the authority will act on AI training under existing law.
- English-only artefacts. Notices, explanations and review correspondence for Brazilian users need to be in clear Portuguese; a translated-on-request policy fails the transparency test in practice.
- Review in name only. A reviewer who sees only the model's score and approves everything is not human review. Give reviewers the inputs and the authority to overturn, and measure their override rate.
- No version pinning. If the decision log does not record model and prompt versions, you cannot explain a decision made last quarter after the provider updated the model.
- Forgetting the provider chain. A third-party model API is an international transfer of personal data and a dependency your impact assessment must describe.
Trade-offs
| Choice | Benefit | Cost |
|---|---|---|
| Build to the Senate text now | No scramble if it passes | Rework if the Chamber changes it |
| Build only to current law | Lowest immediate cost | Larger gap later; Article 20 already demands most plumbing |
| Human confirms every decision | Lower exposure under both regimes | Throughput and staff cost |
| One global control set (EU plus Brazil) | Single pipeline | Notices, regulator and rights workflow still local |
The usual best answer is to build the shared plumbing now, because current law already needs it, and to keep bill-specific documents as drafts that you finalise only after enactment.
What to do next
- List every AI system that affects people in Brazil and fill in the inventory record above.
- Run the triage and send the high-risk and prohibited candidates to counsel.
- For each automated decision, confirm you have a decision log, a Portuguese explanation and a working Article 20 review path; build whichever is missing first.
- Check legal bases and international transfer arrangements for every model provider.
- Start a training-data provenance register for anything you train or fine-tune.
- Assign someone to watch the Chamber's record for PL 2338/2023 and the companion governance bill, and rerun triage when the text changes.