Brazil LGPD AI Controls Mapping: LGPD Articles to Enforcement Points
The LGPD (Law 13.709/2018) governs AI in Brazil today, and each of its articles attaches to a concrete moment in the AI request flow. This maps the LGPD obligations that bite when a prompt carrying personal data leaves your network, from the Article 6 accountability principle to Article 20 automated decisions and the Articles 33 to 36 transfer rules, onto the technical control and enforcement point that satisfies each. The mapping stays concrete: article, where it applies, the control, and the evidence produced.
The LGPD was drafted around data processing in general, and it governs AI without amendment, because each obligation attaches to the handling of personal data whatever performs the handling. When a developer sends a customer record into a model, the Lei Geral de Proteção de Dados (Law 13.709/2018) treats that as processing and, if the endpoint sits abroad, an international transfer. The Autoridade Nacional de Proteção de Dados (ANPD) enforces the result, and its 2025 technical note on automated decisions marks Article 20 as an area of active scrutiny while PL 2338/2023 moves through the Chamber of Deputies.
Brazilian AI governance often ends at a policy aligned to LGPD principles. What tends to be missing is the mapping from an article to the control that enforces it where personal data actually leaves the network. I want to set that out article by article.
The control point: one HTTPS request
Every mapping below resolves to the same moment: an HTTPS POST carrying a context window to a model endpoint. That request is where identity is known, where data classification can be evaluated, where the destination country is chosen, and where a decision is recorded or blocked. A control living in a policy document describes the article without enforcing it.
Article 6: principles, especially accountability
Article 6 sets the principles: purpose, adequacy, necessity, transparency, security, and accountability (prestação de contas). Accountability requires the controller to demonstrate compliance. The control is a per-request record that captures identity, prompt classification, destination, and decision for every AI call. Enforcement produces this as a byproduct, which is what turns "we uphold the principles" into evidence a controller can show.
Article 7 and Article 11: legal basis
Article 7 lists the legal bases for personal data and Article 11 the stricter bases for sensitive data (health, biometrics, and more). A prompt carrying sensitive personal data into a model needs a basis that supports that processing. The control is prompt-level classification tied to per-role policy: a caller whose role lacks a basis for sensitive data in prompts gets blocked before transmission. The evidence is the per-request classification and policy decision.
Article 20: automated decisions
Article 20 gives data subjects the right to review of solely-automated decisions affecting their interests, with clear information on criteria and procedures. The enforcement-relevant control is a per-decision record binding input to output and the applied logic, plus a route flag for decisions that must support human review. This parallels GDPR Article 22 handling, and the evidence is the decision lineage the ANPD reads when a subject exercises the right.
Articles 33 to 36: international transfer
A prompt to a model hosted outside Brazil is an international transfer under Articles 33 to 36, governed by ANPD Resolution CD/ANPD 19/2024. The control is destination-aware routing: prompts carrying regulated classifications route only to endpoints in permitted countries or under an approved mechanism, or get blocked. AI data residency controls implement this, and the evidence is a per-request destination-and-classification log.
Article 46: security
Article 46 requires technical and administrative security measures. For AI traffic the control is access governance on the model channel: per-role, per-route policy replacing shared static keys, failing closed on ambiguity. The evidence is a continuous access record rather than a point-in-time attestation, which matches how the ANPD tests the boundary as it operated.
The mapping at a glance
The Article 48 breach connection
The mapping has a row that only activates after an incident. Article 48 requires notifying the ANPD and affected data subjects of a security incident that may cause risk or damage. When an AI channel is implicated, you cannot assess or notify on an exposure you cannot reconstruct. The independent per-request record turns that assessment into a timeline, and it is the same artifact the LGPD audit-evidence view is built around. My frank opinion: Article 48's clock starts running whether or not you have the log, which is why building it before the incident is the only sane choice.
DeepInspect
Each row above resolves to an enforcement point, and DeepInspect is that point. It sits inline between your users or agents and the LLM APIs they call, evaluates identity, classification, and destination on every request, enforces per-role and per-route policy, and writes a signed record of the decision before the response returns. The LGPD mapping stops being a set of principles and becomes a running control with evidence attached.
For a controller preparing for closer ANPD scrutiny of Article 20 and the transfer rules, that means each obligation has a per-decision record standing behind it. Book a technical deep dive at deepinspect.ai.
Frequently asked questions
- Which LGPD articles matter most for AI?
Article 6 (principles, especially accountability), Articles 7 and 11 (legal basis, including sensitive data), Article 20 (automated decisions), Articles 33 to 36 (international transfer), and Article 46 (security) do the heaviest lifting for AI traffic. Each maps to a control at the request boundary, because the ANPD tests what happened to personal data rather than what a policy intended.
- How does Article 20 shape controls specifically?
Article 20 makes a per-decision record operationally necessary. Providing clear information on the criteria and procedures of an automated decision, and supporting the right to review, requires decision lineage tying inputs to the output and the applied logic. That lineage is produced at the point the decision request is made, not reconstructed later from application logs the controller can edit.
- Do these controls require modifying the model?
These controls operate at the HTTP request boundary between the application and the model, so they are model-agnostic and require no retraining. The application continues to supply identity context, which is its role in any identity-aware design, while classification, routing, enforcement, and recording happen in the request path.