Data Protection Impact Assessment for AI Projects (LGPD RIPD)

Data Protection Impact Assessment for AI Projects (LGPD RIPD)

An AI project calls for a data protection impact assessment (in Brazil, the RIPD under the LGPD) when processing personal data could create meaningful risk for the people the data belongs to: sensitive data, data about children and teenagers, automated decisions that affect a person, profiling, or legitimate interest as the legal basis. The LGPD defines the report and allows the national data protection authority (ANPD) to request it, but it does not give a closed list of cases. The decision is therefore a risk judgment, and it needs to be written down. To start, a lean assessment of a few pages, covering data flow, legal basis, risks and controls, is usually enough.

Key takeaways

• The assessment describes the data processing, the risks to data subjects and the measures that reduce them. It is not an abstract legal exercise. It is a decision document.
• Signals that call for the report: sensitive data, children's data, automated decisions, legitimate interest, profiling, and sending data to external model providers.
• Even when a full report is not needed, record in writing why the company reached that conclusion.
• A lean assessment fits in a few pages and should be done before the pilot, not after launch.
• Review the document whenever the flow, the vendor, the model or the data changes.

What is a RIPD and what does the LGPD say about it?

The Relatório de Impacto à Proteção de Dados Pessoais (RIPD) is the Brazilian counterpart of a data protection impact assessment. It is the controller's documentation of processing activities that may create risks to civil liberties and fundamental rights, together with the measures, safeguards and mitigation mechanisms in place. That definition appears in article 5 of the LGPD.

Article 38 provides that the ANPD may order the controller to prepare the report, including for sensitive data. The authority may also request it when processing relies on legitimate interest. In other words, the law does not say every project needs an assessment on day one, but it does say the company must be ready to present one.

In practice, that changes the question. Instead of asking whether the law requires it, ask this: if the ANPD or a data subject challenged the project, could the company show that it assessed the risks before going live? If the answer is no, the assessment is the cheapest way to fix that. Follow the guidance published by the ANPD and confirm the details of your case with your data protection officer (the encarregado) or legal counsel. This text does not replace legal advice.

When does an AI project need a data protection impact assessment?

AI changes the risk for three reasons: it often receives free text (where people write whatever they want), it can combine data from several sources, and it frequently relies on an external provider to process the data. Use the list below as a decision guide. The more items apply, the stronger the case for completing the assessment before the pilot.

• Sensitive data in the flow: health, biometrics, racial origin, religion, political opinion, sex life. In WhatsApp support, this shows up unannounced, when a customer describes a symptom or sends a test result.
• Data about children and teenagers: common in schools, courses and leisure activities.
• Automated decisions with relevant effect: granting credit, negotiating a debt, prioritizing support, approving an enrollment, screening candidates. The LGPD gives people the right to request review of decisions made solely through automated processing.
• Legitimate interest as the legal basis: the ANPD can ask for the report, so it is better to already have it.
• Profiling or monitoring: scoring leads with behavioral data, analyzing conversations to infer a profile, tracking employees.
• Sending personal data to a model provider or third-party tool, which may involve international transfer and requires a look at the contract, retention and use of the data.
• Volume and scale: many data subjects, long conversation histories, or combining databases that used to be separate.

Our working rule, not a legal requirement: if the project involves sensitive data, children's data or automated decisions that affect a person, treat the assessment as a prerequisite for the pilot. If it has only one or two milder signals, a short assessment and a review by the data protection officer are enough. For the broader picture of the law applied to AI, see LGPD and artificial intelligence: what companies should do.

When is a full assessment probably not necessary?

Not every use of AI touches personal data in a meaningful way. Examples of low risk: an internal assistant that summarizes technical documents with no personal data, a classifier for parts or defects on a production line, a tool that helps draft generic text. In those cases, a full report would be bureaucracy with no payoff.

Still, the decision to skip it should also be recorded. One page with these items is enough:

• A description of the use case in two or three sentences.
• Which data goes in, and confirmation that there is no personal data or that it is minimal.
• Who decided the assessment was not needed, and when.
• A review condition: what, if it changes, reopens the analysis (for example, starting to accept customer attachments or connecting the CRM).

That last line matters a great deal. AI projects tend to grow through integration, and a harmless internal assistant can become a flow with customer data within a few weeks.

Which sections belong in a lean assessment?

A good assessment for AI is short enough to be read and updated. The structure below covers the essentials and can be copied into your company's internal document.

• Identification: project name, controller, processors and vendors involved, data protection officer, process owner and date of preparation.
• Purpose and scope: which business problem the system solves, what it does and what it explicitly does not do.
• Data processed: categories of data, whether there is sensitive or children's data, where the data comes from, who the data subjects are and how long the data is kept.
• Legal basis and transparency: which legal basis supports each purpose, what the data subject is told and when, and how they exercise their rights.
• Data flow: where the data travels (channel, orchestrator, model, database, logs, backups), marking which parts sit with third parties and in which country.
• Role of AI and human oversight: what the model decides, what it only suggests, when it hands over to a person and how the data subject requests review.
• Identified risks: for each risk, one sentence on what could go wrong for the data subject, the estimated likelihood in qualitative terms and the severity.
• Mitigation measures: data minimization, masking, permissions, retention, contracts, testing, action limits, decision logging.
• Residual risk and decision: what remains after the measures, who accepted the risk and under what conditions the project proceeds, changes or stops.
• Review: frequency and update triggers, such as a model change, a new channel, a new integration or an incident.

AI-specific risks deserve their own attention in the risk section: data leakage through an improper response, instruction injection through malicious messages, hallucination that affects the data subject, and excessive access by connected tools. The OWASP Top 10 for LLM applications helps you avoid forgetting categories of failure, and the NIST AI Risk Management Framework offers a structured way to think about mapping, measuring and managing risk.

Illustrative scenario: a WhatsApp agent at a clinic

Illustrative scenario, not based on a real client. A clinic wants a WhatsApp agent to confirm appointments, reschedule slots and answer questions about exam preparation. Patients write free text and sometimes send photos of medical requests.

Applying the decision guide: there is sensitive data (health), there is free text, and data is sent to a model provider. Three strong signals, so the assessment comes before the pilot. In the document, the team would make choices like these:

• Purpose limited to scheduling and administrative guidance, with no clinical interpretation at all.
• The agent receives only name, phone number and appointment time. Diagnoses and medical records stay out of reach of its tools.
• When a patient describes symptoms, the agent does not analyze them. It records the minimum and hands the conversation to reception.
• Attachments are discarded or forwarded to a person, without being processed by the model.
• Logs keep the agent's decision and the reason for it, with a defined retention period and restricted access.

The result is an assessment that describes a smaller, safer flow, not a stalled project. That is the real value of the document: it forces the decision to limit scope before the system starts collecting more than it needs. For details on legal basis and record keeping in this channel, see LGPD compliance for AI on WhatsApp: legal basis, consent and records, and for passing conversations to people, see the WhatsApp AI agent human handoff playbook.

Step by step: preparing the assessment without stalling the project

The assessment works best as part of the pilot design, not as a separate legal stage. A sequence that tends to work:

• Step 1: describe the use case on one page, with the current process and who is affected.
• Step 2: draw the real data flow, including channel, model, database, logs, backups and connected tools.
• Step 3: mark each data item as necessary or dispensable. Remove what is dispensable before thinking about mitigation.
• Step 4: apply the decision guide and record which signals apply.
• Step 5: bring together the data protection officer, the business owner and the technical owner to list risks from the data subject's point of view, not the company's.
• Step 6: define measures and action limits: what the agent can read, write and decide, and when it calls a person.
• Step 7: record the residual risk and the decision to proceed, adjust or stop, with a name and a date.
• Step 8: define the review triggers and put the review on the project calendar.

This sequence maps directly to the way we work: map the process and the current baseline, limit data and actions, pilot a real flow with logs and an agreed success metric, then hand over the operation to decide whether to expand, adjust or stop. The assessment is, in large part, the written record of the map and limit phases, and the pilot logs feed its first review. To structure the pilot itself, see the AI pilot charter template.

How do you keep the assessment alive after launch?

The most common mistake is treating the report as a one-time deliverable. With AI, the system changes for reasons that do not show up in the company's own code: the provider updates the model, a new tool is connected, the team expands the scope of support. Each of those changes can alter the data flow.

Three habits keep the document useful:

• Tie the assessment to change control: every new integration, channel or vendor swap goes through one simple question, did this change the flow described in the report?
• Use the pilot logs as evidence: conversations handed to humans, review requests and incidents show whether the risks you anticipated were the right ones.
• Record incidents and near misses in the document itself, with the fix that was applied.

As for measuring the pilot, quality metrics and risk metrics can run side by side. The article on how to measure an AI automation pilot shows how to define decision gates that include this kind of signal.

Frequently asked questions

Is the assessment mandatory for every AI project? The LGPD has no rule requiring the report for every use of AI. The ANPD can order it to be prepared, and in higher-risk situations having the document ready is the prudent choice. Confirm how your case is classified with your data protection officer or legal counsel.

Who should prepare the assessment? Responsibility lies with the controller, usually with the data protection officer coordinating and with input from business, technology and legal. Vendors and processors contribute information about the flow, retention and security measures, but they do not replace the evaluation made by the company that decides how the data is used.

Does using an external model provider change the assessment? Yes, because the vendor enters the data flow. The document should state which data is sent, in which country it is processed, how long it is retained, whether it can be used for training and which contract governs this. If the same result can be achieved by sending less data, that is the first mitigation measure.

Is a lean assessment enough? For most pilots, yes, as long as it covers purpose, data, legal basis, flow, risks, measures, residual risk and review. Length matters less than the honesty of the analysis and keeping it current. If the scope grows, the document grows with it, not before.

Sources

• ANPD: Autoridade Nacional de Proteção de Dados
• NIST AI Risk Management Framework
• OWASP Top 10 for LLM Applications