RIPD para projetos de IA: quando fazer e o que incluir

RIPD para projetos de IA: quando fazer e o que incluir

Saiba quando um projeto de IA pede relatório de impacto (RIPD) na LGPD e quais seções incluir em um documento enxuto, útil e fácil de manter.

••

Quer aplicar isso na sua empresa?

Agendar conversa com o Juan →

RIPD para projetos de IA: quando fazer e o que incluir

Um projeto de IA pede RIPD quando o tratamento de dados pessoais pode gerar risco relevante para os titulares: dados sensíveis, dados de crianças e adolescentes, decisões automatizadas com efeito sobre a pessoa, perfilamento ou uso de legítimo interesse como base legal. A LGPD define o relatório e permite que a ANPD o solicite, mas não traz uma lista fechada de casos, então a decisão é de risco e precisa ficar registrada. Para começar, um RIPD enxuto de poucas páginas, com fluxo de dados, base legal, riscos e controles, costuma ser suficiente.

Principais pontos

  • O RIPD descreve o tratamento de dados, os riscos aos titulares e as medidas para reduzi-los. Não é uma peça jurídica abstrata, é um documento de decisão.
  • Sinais que pedem o relatório: dados sensíveis, dados de crianças, decisão automatizada, legítimo interesse, perfilamento e envio de dados a provedores externos de modelo.
  • Mesmo quando o relatório completo não é necessário, vale registrar por escrito por que a empresa concluiu isso.
  • Um RIPD enxuto cabe em poucas páginas e deve ser feito antes do piloto, não depois do lançamento.
  • O documento precisa ser revisado quando o fluxo, o fornecedor, o modelo ou os dados mudarem.

O que é o RIPD e o que a LGPD diz sobre ele?

O Relatório de Impacto à Proteção de Dados Pessoais (RIPD) é a documentação do controlador sobre processos de tratamento que podem gerar riscos às liberdades civis e aos direitos fundamentais, junto com as medidas, salvaguardas e mecanismos de mitigação. Essa definição está no artigo 5 da LGPD.

O artigo 38 prevê que a ANPD pode determinar que o controlador elabore o relatório, inclusive para dados sensíveis. Também há a previsão de que a autoridade possa pedir o relatório quando o tratamento se baseia em legítimo interesse. Ou seja, a lei não diz que todo projeto precisa de um RIPD desde o primeiro dia, mas diz que a empresa deve estar preparada para apresentá-lo.

Na prática, isso muda a pergunta. Em vez de perguntar se a lei obriga, pergunte se, caso a ANPD ou um titular questione o projeto, a empresa conseguiria mostrar que avaliou os riscos antes de operar. Se a resposta for não, o RIPD é a forma mais barata de corrigir isso. Acompanhe as orientações publicadas pela ANPD e confirme os detalhes do seu caso com o encarregado ou com a assessoria jurídica. Este texto não substitui parecer jurídico.

Quando um projeto de IA pede RIPD?

IA muda o risco por três motivos: ela costuma receber texto livre (onde as pessoas colocam o que quiserem), pode combinar dados de várias fontes e, muitas vezes, depende de um provedor externo para processar. Use a lista abaixo como guia de decisão. Quanto mais itens se aplicam, mais forte é o motivo para fazer o relatório antes do piloto.

  • Dados sensíveis no fluxo: saúde, biometria, origem racial, religião, opinião política, vida sexual. Em atendimento por WhatsApp, isso aparece sem aviso, quando o cliente descreve um sintoma ou envia um exame.
  • Dados de crianças e adolescentes: comum em escolas, cursos e atividades de lazer.
  • Decisão automatizada com efeito relevante: concessão de crédito, negociação de dívida, priorização de atendimento, aprovação de matrícula, triagem de candidatos. A LGPD prevê o direito de pedir revisão de decisões tomadas apenas com base em tratamento automatizado.
  • Base legal de legítimo interesse: a ANPD pode pedir o relatório, então é melhor já tê-lo.
  • Perfilamento ou monitoramento: pontuação de leads com dados comportamentais, análise de conversas para inferir perfil, acompanhamento de funcionários.
  • Envio de dados pessoais a provedor de modelo ou a ferramenta de terceiros, o que pode envolver transferência internacional e exige olhar contrato, retenção e uso dos dados.
  • Volume e escala: muitos titulares, histórico longo de conversas ou combinação de bases que antes ficavam separadas.

Regra prática nossa, e não exigência legal: se o projeto tem dados sensíveis, dados de crianças ou decisão automatizada com efeito sobre a pessoa, trate o RIPD como pré-requisito do piloto. Se tem apenas um ou dois sinais mais leves, um RIPD curto e uma revisão pelo encarregado já resolvem. Para o contexto geral da lei aplicada a IA, veja LGPD e inteligência artificial: o que a empresa deve fazer.

E quando um RIPD completo provavelmente não é necessário?

Nem todo uso de IA toca dados pessoais de forma relevante. Exemplos de risco baixo: um assistente interno que resume documentos técnicos sem dados de pessoas, um classificador de peças ou defeitos em linha de produção, um apoio à redação de textos genéricos. Nesses casos, um relatório completo seria burocracia sem ganho.

A dispensa, porém, também deve ser registrada. Uma página com estes itens é suficiente:

  • Descrição do caso de uso em duas ou três frases.
  • Quais dados entram e a confirmação de que não há dados pessoais ou de que são mínimos.
  • Quem decidiu que o RIPD não era necessário e quando.
  • Condição de revisão: o que, ao mudar, reabre a análise (por exemplo, passar a aceitar anexos de clientes ou conectar o CRM).

Essa última linha importa muito. Projetos de IA costumam crescer por integração, e um assistente interno inofensivo pode virar um fluxo com dados de clientes em poucas semanas.

Quais seções incluir em um RIPD enxuto?

Um bom RIPD para IA é curto o bastante para ser lido e atualizado. A estrutura abaixo cobre o essencial e pode ser copiada para o documento interno da empresa.

  • Identificação: nome do projeto, controlador, operadores e fornecedores envolvidos, encarregado, responsável pelo processo e data de elaboração.
  • Finalidade e escopo: qual problema de negócio o sistema resolve, o que ele faz e o que ele explicitamente não faz.
  • Dados tratados: categorias de dados, se há dados sensíveis ou de crianças, origem dos dados, quem são os titulares e por quanto tempo os dados ficam guardados.
  • Base legal e transparência: qual hipótese legal sustenta cada finalidade, o que o titular é informado e em que momento, e como ele exerce seus direitos.
  • Fluxo de dados: por onde o dado passa (canal, orquestrador, modelo, banco, logs, backups), com indicação de quais partes estão com terceiros e em que país.
  • Papel da IA e supervisão humana: o que o modelo decide, o que apenas sugere, quando passa para uma pessoa e como o titular pede revisão.
  • Riscos identificados: para cada risco, uma frase sobre o que pode dar errado com o titular, a probabilidade estimada de forma qualitativa e a gravidade.
  • Medidas de mitigação: minimização de dados, mascaramento, permissões, retenção, contratos, testes, limites de ação, registro de decisões.
  • Risco residual e decisão: o que sobra depois das medidas, quem aceitou o risco e em que condições o projeto segue, muda ou para.
  • Revisão: periodicidade e gatilhos de atualização, como troca de modelo, novo canal, nova integração ou incidente.

Os riscos específicos de IA merecem atenção própria na seção de riscos: vazamento de dados por resposta indevida, injeção de instruções por mensagens maliciosas, alucinação com efeito sobre o titular e acesso excessivo de ferramentas conectadas. A lista OWASP Top 10 para aplicações com LLM ajuda a não esquecer categorias de falha, e o framework de gestão de risco de IA do NIST oferece uma forma estruturada de pensar mapeamento, medição e gestão de riscos.

Cenário ilustrativo: agente de WhatsApp em uma clínica

Cenário ilustrativo, sem relação com cliente real. Uma clínica quer um agente no WhatsApp para confirmar consultas, remarcar horários e responder dúvidas sobre preparo de exames. O pacientes escrevem texto livre e, às vezes, enviam fotos de pedidos médicos.

Aplicando o guia de decisão: há dados sensíveis (saúde), há texto livre e há envio de dados a um provedor de modelo. Três sinais fortes, então o RIPD vem antes do piloto. No documento, a equipe faria escolhas como estas:

  • Finalidade restrita a agendamento e orientações administrativas, sem qualquer interpretação clínica.
  • O agente recebe apenas nome, telefone e horário. Diagnóstico e prontuário ficam fora do alcance das ferramentas.
  • Quando o paciente descreve sintomas, o agente não analisa: registra o mínimo e transfere para a recepção.
  • Anexos são descartados ou encaminhados a uma pessoa, sem processamento pelo modelo.
  • Logs guardam a decisão do agente e o motivo, com prazo de retenção definido e acesso restrito.

O resultado é um RIPD que descreve um fluxo menor e mais seguro, e não um projeto travado. Esse é o valor real do documento: ele força a decisão de limitar antes que o sistema comece a coletar mais do que precisa. Para detalhes de base legal e registro nesse canal, veja LGPD no WhatsApp com IA: consentimento, base legal e registro, e para a passagem para pessoas, transbordo humano em agentes de IA no WhatsApp.

Passo a passo para elaborar o RIPD sem travar o projeto

O RIPD funciona melhor como parte do desenho do piloto, não como etapa jurídica separada. Uma sequência que costuma funcionar:

  • Passo 1: descreva o caso de uso em uma página, com o processo atual e quem é afetado.
  • Passo 2: desenhe o fluxo de dados real, incluindo canal, modelo, banco, logs, backups e ferramentas conectadas.
  • Passo 3: marque cada dado como necessário ou dispensável. Remova o que for dispensável antes de pensar em mitigação.
  • Passo 4: aplique o guia de decisão e registre quais sinais se aplicam.
  • Passo 5: reúna encarregado, responsável de negócio e responsável técnico para listar riscos pela ótica do titular, não da empresa.
  • Passo 6: defina medidas e limites de ação: o que o agente pode ler, escrever e decidir, e quando aciona uma pessoa.
  • Passo 7: registre o risco residual e a decisão de seguir, ajustar ou parar, com nome e data.
  • Passo 8: defina os gatilhos de revisão e coloque a revisão no calendário do projeto.

Esse roteiro conversa diretamente com o método de trabalho que seguimos: mapear o processo e a linha de base atual, limitar dados e ações, pilotar um fluxo real com logs e uma métrica de sucesso combinada, e transferir a operação para decidir se expande, ajusta ou encerra. O RIPD é, em boa parte, o registro escrito das fases de mapear e limitar, e os logs do piloto alimentam sua primeira revisão. Para estruturar o piloto em si, veja o modelo de plano piloto de IA.

Como manter o RIPD vivo depois do lançamento?

O erro mais comum é tratar o relatório como entregável de uma vez só. Em IA, o sistema muda por razões que não aparecem no código da empresa: o provedor atualiza o modelo, uma nova ferramenta é conectada, o time amplia o escopo do atendimento. Cada uma dessas mudanças pode alterar o fluxo de dados.

Três hábitos mantêm o documento útil:

  • Ligar o RIPD a um controle de mudanças: toda nova integração, canal ou troca de fornecedor passa por uma pergunta simples, esse fluxo alterou o relatório?
  • Usar os logs do piloto como evidência: conversas que foram encaminhadas a humanos, pedidos de revisão e incidentes mostram se os riscos previstos eram os certos.
  • Registrar incidentes e quase-incidentes no próprio documento, com a correção aplicada.

Quanto à medição do piloto, as métricas de qualidade e de risco podem andar juntas. O texto sobre como medir um piloto de automação com IA mostra como definir gates de decisão que incluem esse tipo de sinal.

Perguntas frequentes

O RIPD é obrigatório para todo projeto de IA? Não há, na LGPD, uma regra que obrigue o relatório para qualquer uso de IA. A ANPD pode determinar a elaboração, e há situações de risco mais alto em que ter o documento pronto é a decisão prudente. Confirme o enquadramento do seu caso com o encarregado ou com a assessoria jurídica.

Quem deve elaborar o RIPD? A responsabilidade é do controlador, normalmente com o encarregado coordenando e participação de negócio, tecnologia e jurídico. Fornecedores e operadores contribuem com informações sobre o fluxo, a retenção e as medidas de segurança, mas não substituem a avaliação feita pela empresa que decide sobre o uso dos dados.

O uso de um provedor externo de modelo muda o RIPD? Sim, porque o fornecedor entra no fluxo de dados. O documento deve indicar quais dados são enviados, em que país são processados, por quanto tempo ficam retidos, se podem ser usados para treino e qual contrato regula isso. Se o mesmo resultado puder ser obtido enviando menos dados, essa é a primeira medida de mitigação.

Um RIPD enxuto é suficiente? Para a maioria dos pilotos, sim, desde que cubra finalidade, dados, base legal, fluxo, riscos, medidas, risco residual e revisão. O tamanho importa menos que a honestidade da análise e a atualização contínua. Se o escopo crescer, o documento cresce junto, e não antes.

Fontes

LGPDRIPDIAPrivacidadeGovernança de dados