AI governance in Brazil: LGPD, Bill 2338 and the AI Act
A reviewer who approves forty cases an hour and never rejects anything is not a control, it is a stamp. A human in the loop needs time, information and authority.
AI governance is usually treated as a legal matter, something that shows up at the end of a project to rubber-stamp it. When that happens, the conversation becomes a list of objections about a system that is already built. Treated as an engineering requirement, it changes design decisions and costs far less.
This text is a map of the terrain, not legal advice. A decision on a concrete case needs a lawyer.
What already applies today: the LGPD
There is no regulatory vacuum in Brazil. The General Data Protection Law, Law 13,709/2018, already applies to any AI system that processes personal data, and most of them do.
Three of its requirements hit the design of an AI application directly.
Purpose and legal basis. Data collected for customer support does not become model training data out of convenience. Each new use needs its own legal basis, compatible with the purpose that was communicated.
Minimisation. Sending the customer's entire record to the model because it was easier than filtering is the opposite of what the law asks for.
Review of automated decisions. Article 20 provides that the data subject may request review of decisions taken solely on the basis of automated processing that affect their interests. That means logging input, output and criteria, because reviewing requires knowing what happened.
What is under discussion: Bill 2338
Bill 2338/2023, approved by the Senate, proposes a specific framework for artificial intelligence in Brazil, with risk-level classification, proportional obligations and rights for affected people.
At the time of writing it was still moving through the Chamber of Deputies, and the final text may change. Check its status before using any detail as a basis for a decision.
What you can already do without waiting: adopt risk-level classification internally. It is common to every serious proposal and costs almost nothing to put in place early.
Why the European regulation matters here
Regulation (EU) 2024/1689, the AI Act, applies in phases over the years following its entry into force and reaches providers outside Europe when the system's output is used there.
Even with no European customers, it matters for two reasons. First, it is becoming a de facto reference for contracts and investor due diligence. Second, its risk structure, with prohibited practices, high-risk systems and transparency obligations, is already being copied in several jurisdictions.
Frameworks that turn principles into practice
Principles implement nothing. Two documents help you move past the slogan.
The NIST AI Risk Management Framework organises the work into four functions: govern, map, measure and manage. It is voluntary, free and works well as a backbone, because it describes activities rather than only values.
ISO/IEC 42001 defines an AI management system in the same format as other management standards, with policy, roles, risk assessment and continual improvement. It makes sense for organisations that already live with that kind of standard or need certification to sell.
Picking one of the two and actually applying it is worth more than citing both in a slide deck.
The operational minimum
For a mid-sized company, four artefacts cover most of the risk and fit into a week of work.
- An inventory of AI use cases, including the ones the team adopted without asking. You cannot govern what is not on a list.
- Risk classification per use case, with written, simple criteria: impact on people, reversibility of the decision and sensitivity of the data.
- A decision log for cases that affect people, with input, output, prompt and model versions, and who reviewed it.
- A usage policy stating what may go to an external tool and what may not, with concrete examples instead of adjectives.
A human in the loop needs real power
The standard answer to risk is "there is human review". It only counts if the reviewer has the time, the information and the authority to disagree.
A reviewer who approves forty cases an hour and never rejects anything is not a control, it is a stamp. If the process does not record how often the human diverged from the system, there is no way to know which of the two situations you are in.
What this means for your team
Start with the inventory. It is the most tedious task and the most revealing, because there is almost always an AI use over sensitive data that nobody had mapped.
Then classify by risk and concentrate controls where decisions affect people. A chatbot answering questions about opening hours does not need the rigour of a system that takes part in credit decisions or résumé screening.
And write the usage policy before the team invents its own. It already has; the only question is whether you know what it says.
References
The sources behind this article, so you can check them and dig deeper.
- 1Lei 13.709/2018 (Lei Geral de Proteção de Dados Pessoais)Presidência da República, 2018
- 2PL 2338/2023: marco legal da inteligência artificialSenado Federal, 2023
- 3Regulation (EU) 2024/1689 (Artificial Intelligence Act)EUR-Lex, 2024
- 4AI Risk Management Framework (NIST AI 100-1)NIST, 2023
- 5ISO/IEC 42001:2023: AI management systemsInternational Organization for Standardization, 2023
Read next
LLM application security: injection and tool abuse
The question is not where user input comes in, it is what the model can do if it believes the wrong thing. The answer is the size of the possible damage.
Read the articleAI in development: what the data actually shows
One study measured 55.8% faster. Another measured 19% slower. Both are right, and the difference between them is the part that matters.
Read the articleAI code review without lowering the quality bar
People using AI assistants write less secure code and feel more confident it is secure. The gate needs to get stricter, not looser.
Read the article