Is an LGPD impact assessment mandatory for every AI deployment?

Article 38 frames the report as something the national authority may determine the controller must prepare. The obligation does not attach automatically to a category of processing. In practice, controllers running high-risk processing prepare one in advance, because the authority's determination arrives on its own timetable and the underlying analysis takes weeks. Treating it as conditional rather than as optional is the defensible reading.

What counts as the types of data collected for prompt traffic?

The categories of personal data that actually entered the requests, including sensitive categories where present. Establishing that requires either classifying content before it is sent or retaining and analysing payloads afterwards. Token counts, model identifiers and request timestamps do not answer the question, and an assessment resting on those fields is describing the platform's telemetry rather than the processing operation.

How does Article 20 change what the assessment must show?

Article 20 creates a data subject right to request review of solely automated decisions, with clear and adequate information on the criteria and procedures used. Where an LLM participates in such a decision, the assessment should describe how an individual output can be tied back to its input, its model configuration and its authorising identity. A controller that cannot make that link cannot satisfy a review request, and the assessment is the right place to say so honestly.

Where does DeepInspect fit in an LGPD risk assessment?

DeepInspect evaluates HTTP traffic between authenticated users or agents and LLM endpoints routed through it, applying content classification and identity-bound policy before forwarding, and recording each decision independently. That supplies the types of data, the safeguard description, and the mitigation evidence Article 38 asks for. Data collection upstream of the request, internal system security, and the model's own behaviour sit outside that boundary.

Brazil LGPD AI Risk Assessment: What Article 38 Actually Obliges

LGPD Article 38 says the national authority may determine that a controller must prepare a data protection impact assessment, and it then fixes a floor for the contents. The report must contain at least a description of the types of data collected, the methodology used for collection and for ensuring the security of the information, and the controller's analysis of the adopted measures, safeguards and mechanisms of risk mitigation.

Written out that way, the obligation is modest. Applied to an LLM deployment, the first two items are the ones that collapse.

TL;DR

LGPD Article 38 lets the ANPD require a data protection impact assessment, known in Brazil as the relatório de impacto à proteção de dados pessoais.
The minimum contents are the types of data collected, the methodology for collection and for securing the information, and the controller's analysis of measures, safeguards and mitigation mechanisms.
Article 20 gives data subjects a right to request review of decisions made solely on automated processing, with clear information on the criteria and procedures used.
For prompt traffic, the types of data collected are usually undocumented, because nothing classifies the content before it is sent.
A risk assessment that describes the platform rather than the request is describing the wrong object.

What Article 38 requires, in the official wording

The IAPP English translation of the LGPD renders Article 38 as follows: the national authority may determine that the controller must prepare a data protection impact assessment, which shall include personal data, sensitive data, and refer to its data processing operations, pursuant to regulations, subject to commercial and industrial secrecy. The report must contain at least a description of the types of data collected, the methodology used for collection and for ensuring the security of the information, and the analysis of the controller regarding the adopted measures, safeguards and mechanisms of risk mitigation. The controlling version is the official Portuguese text of Lei 13.709/2018, where Article 38 sits in the chapter on good practice and governance.

Two features of that text shape the work. The authority's determination is the trigger, so the timing belongs to the ANPD and not to the controller's own assessment cycle. The commercial and industrial secrecy carve-out protects proprietary detail without removing the obligation to describe the operation.

For an AI deployment, the operation being described is the disclosure of content to a model, and that is the part most assessments skip in favour of describing the vendor.

The types of data collected is the field that fails

A conventional processing operation has a form, a schema, or a file layout. Naming the types of data collected is a reading exercise.

Prompt traffic has none of that. A support agent pastes a customer message. An engineer pastes a stack trace containing an account identifier. An agent assembles context from a CRM, a ticketing system and a document store, and sends the result in one request. The union of what those requests contain is the answer to Article 38's first item, and the union is unknown in almost every deployment I have reviewed unless someone classified the content before it was sent.

Sensitive data raises the stakes. The LGPD's definition covers racial or ethnic origin, religious conviction, political opinion, health and sexual life data, and biometric or genetic data. A health insurer's support queue routinely contains the health category. Article 38 names sensitive data explicitly, so a report that cannot establish whether sensitive data entered the operation is incomplete on its face.

The methodology for securing the information

The second item asks how the information is collected and how it is secured. Here the vendor's attestation does real work, and it also stops short.

Transport encryption, provider retention terms and access controls are describable from documentation. What sits outside vendor documentation is what the controller did at the moment of the request: which identity authorised it, what classification the content carried, which policy version applied, and whether a prohibited combination would have been refused.

That last clause is the difference between a safeguard and an aspiration. A policy document stating that health data may not be sent to a general-purpose model is a safeguard only if something enforced it. Our LGPD AI controls mapping piece places this alongside the other obligations, and the audit evidence piece covers what the record has to carry.

Article 20 and the automated decision overlap

Article 20 gives the data subject the right to request review of decisions made solely on the basis of automated processing that affect their interests, including decisions defining personal, professional, consumer or credit profiles, or aspects of their personality. When requested, the controller must provide clear and adequate information on the criteria and procedures used, subject to commercial and industrial secrecy.

An LLM sitting inside a decision path pulls that obligation forward. Answering a review request means reconstructing which model produced which output, on which input, under which configuration, at which moment. A controller that cannot tie an output back to its input and its authorising identity cannot supply clear and adequate information about the procedure.

The risk assessment is where that reconstruction capability gets described, or where its absence becomes visible. I would treat an Article 38 report that asserts explainability without naming the record that supports it as a finding and not as evidence.

Building the assessment around the request

Three shifts make an Article 38 report about an LLM deployment defensible.

Describe the request rather than the platform. Name the processing operation as "content of category X, sent by identity Y, to model destination Z, under policy version P", and the three required items follow directly.

Classify before sending, not after. Classification applied downstream tells you what was in a log. Classification applied at the decision point tells you what was permitted, which is what a safeguard analysis needs.

Record the refusals. An assessment that lists only successful transactions describes throughput. Retaining the denied cases, with timestamps, demonstrates that the mitigation mechanism the report describes actually operated.

Our LGPD AI compliance checklist covers the wider programme, and the AI governance audit framework supplies the structure for keeping these artefacts together across regimes.

DeepInspect

DeepInspect provides an independent policy decision at the HTTP AI request boundary. For traffic routed through it, DeepInspect evaluates the application-supplied identity and role against organisational policy for content classification and model authorisation before the request reaches the model.

Each decision produces a signed, tamper-evident record held outside the calling application's write path, covering permitted and refused requests alike. An Article 38 report built on those records describes the processing operation as it ran, with dates, and not as the control documentation intended it to run.

Book a technical deep dive at deepinspect.ai.