Dados e LGPD em projetos de IA: as perguntas que precisam de resposta

Antes de um projeto de IA ser aprovado, quatro perguntas chegam a quem responde pela arquitetura: onde nossos dados são processados, se o fornecedor treina com eles, quem pode acessá-los e como são eliminados. As perguntas costumam aparecer como objeções, e merecem respostas diretas, inclusive quando a resposta honesta é "depende do seu contrato, e é exatamente ali que você precisa olhar".

Este texto responde as quatro perguntas uma a uma, com um fluxo de documentos como exemplo contínuo: uma empresa que processa documentos operacionais com apoio de IA. Teste: sua próxima reunião de projeto consegue responder as quatro perguntas por escrito?

Onde os dados são processados?

Resposta direta: em todos os ambientes que o fluxo toca, e cada um precisa estar mapeado. Um único fluxo pode passar pelo banco da empresa, um serviço de nuvem, um modelo de linguagem contratado e o navegador de quem usa a solução. Cada ambiente tem regras próprias de acesso e configuração. No exemplo deste texto, um documento operacional percorre o banco da empresa, um serviço de nuvem e um modelo de linguagem contratado.

A pergunta prática é onde o dado sensível fica exposto. Em alguns desenhos, só a parte necessária vai para o modelo e o resto permanece no ambiente da empresa. Em outros, o registro inteiro se move. A diferença está menos no modelo e mais em como o fluxo foi construído.

flowchart TD
  source["Sistema de origem"]
  company["Ambiente da empresa"]
  log["Registro de eventos para operação e auditoria"]
  ai["Serviço de IA"]
  result["Saída"]
  review{"Revisão humana nas exceções"}
  retention["Retenção definida -> eliminação"]
  source -->|"controle de acesso"| company
  company --> log
  company -->|"contrato define o uso"| ai
  ai --> result
  result --> review
  review --> retention

Para cada ambiente, responda o que chega, o que sai, quem opera e sob quais condições. A arquitetura pode incluir ambientes separados, tráfego criptografado e gestão protegida de credenciais, conforme os requisitos do projeto. Nada disso é automático. Precisa estar no escopo e ser verificável.

Se a pergunta "onde este dado é processado?" não tem resposta clara, o projeto não está pronto para começar.

O dado é usado para treinar modelos de terceiros?

Resposta direta: depende dos serviços e contratos adotados, e é por isso que a resposta se resolve no contrato e na configuração, não na conversa. Alguns fornecedores permitem desligar o uso para treinamento. Outros tratam o dado de forma diferente conforme o plano contratado. No exemplo, o contrato do serviço precisa definir se os documentos podem ser usados para treinamento.

Antes da entrada em produção, o projeto define quais fornecedores podem processar o dado, quais configurações de privacidade serão aplicadas e quais usos são permitidos, formalizados por escrito. Se um fornecedor não permite a configuração necessária, isso é uma restrição do projeto, não um detalhe: pode exigir trocar o serviço, mudar a arquitetura ou estreitar os dados que se movem. Melhor descobrir no diagnóstico do que na primeira auditoria.

Quem pode acessar o dado, e o que fica registrado?

Resposta direta: o acesso segue papéis, permissões e integrações autorizadas, para pessoas e para serviços, e o registro precisa guardar o que a operação e a auditoria precisam ver.

Um log útil mostra quando o dado foi acessado, por qual fluxo e com qual resultado. Um log inútil registra tudo e ninguém lê. Existe um trade-off aqui, e vale nomeá-lo: o log detalhado ajuda a investigar, mas guarda informação que também precisa de proteção; o log mínimo reduz a exposição, mas dificulta entender o que aconteceu. O caminho usual é registrar o que operação e auditoria precisam, restringir o acesso aos papéis que precisam e revisar essa lista conforme o processo muda.

Em fluxos com decisões automatizadas, inclua os pontos de revisão humana no mesmo mapa: onde uma pessoa valida informação, para o fluxo ou corrige uma decisão. Sem esse ponto, uma exceção pode passar sem ninguém ver.

Por quanto tempo o dado é guardado, e como é eliminado?

Resposta direta: cada pedaço de dado recebe um destino no fim do fluxo, definido antes da construção. Os projetos costumam desenhar bem a entrada e deixar a saída indefinida, o que significa dado parado em algum lugar por tempo indeterminado porque ninguém combinou quando ele sai.

A pergunta a responder é se o dado precisa continuar existindo depois que o fluxo termina, por operação, auditoria ou obrigação legal. Se sim, por quanto tempo e com qual proteção. Se não, qual é o caminho de eliminação e como ele pode ser verificado.

No exemplo contínuo, a empresa que processa documentos operacionais com apoio de IA: o documento entra, é lido em ambiente separado, os campos extraídos alimentam o sistema de origem e o registro da conferência fica para auditoria. O documento original, os campos extraídos e o log da operação têm destinos diferentes; tratar os três como um só é o erro comum.

A anonimização entra aqui também. Em alguns casos dá para trabalhar com dados que não identificam diretamente pessoas, o que reduz a exposição. Em outros, a identificação é necessária para o processo funcionar. A escolha depende da finalidade e precisa de validação jurídica, não de regra genérica.

O que não dá para responder de forma genérica

Não vamos nomear aqui um encarregado, um DPO, ou prazos fixos de retenção. Finalidade, base legal, retenção, anonimização, eliminação e responsabilidades são avaliados conforme o tratamento realizado, e a resposta muda caso a caso. O trabalho da engenharia é deixar o tratamento visível o suficiente para que essas decisões sejam tomadas com informação, não por suposição.

Em resumo: as quatro respostas

• Onde é processado? Em todos os ambientes que o fluxo toca, cada um mapeado e verificável.
• O fornecedor treina com o dado? Resolvido no contrato e na configuração, verificado antes da entrada em produção.
• Quem acessa? Papéis e permissões, com um registro que sirva à operação e à auditoria.
• Como é eliminado? Cada pedaço recebe um destino, retenção e eliminação, definidos antes da construção.

Essas perguntas não bloqueiam um projeto de IA. Elas o organizam. No diagnóstico, esse mapeamento costuma ser planejado para 2 a 3 semanas, junto com a priorização das oportunidades. Quando há piloto, sua construção costuma ser estimada em 4 a 6 semanas após a definição do escopo, dependendo dos dados, acessos e integrações envolvidos.

Para revisar essas perguntas no seu contexto, Solicitar diagnóstico.