Lista de fornecedores que tratam dados: por onde passa um comentário do seu blog

Uma leitora pergunta por e-mail para onde vai o comentário que ela deixou no blog. Você abre a política de privacidade e lê "compartilhamos dados com parceiros de confiança". Aí começa a contar: o servidor fica num provedor de nuvem, a CDN fica na frente, o antispam analisa o texto, um serviço de e-mail avisa o autor do post, o monitor de erros captura o corpo da requisição quando algo quebra e o backup vai para outro storage. São seis empresas, e a política não nomeia nenhuma. A resposta curta: mantenha uma lista dos fornecedores que tratam dados por você, organizada por função, publique o essencial na política e faça com que nenhuma ferramenta nova chegue a produção sem entrar nessa lista.

A lista não é burocracia. Se você não consegue escrevê-la, não sabe para onde o dado dos seus usuários viaja, e então também não sabe o que fazer quando um desses fornecedores tiver um incidente.

Por que "parceiros" esconde o fluxo

Na LGPD, quem decide sobre o tratamento é o controlador; quem trata em nome dele é o operador. O fornecedor de e-mail, a hospedagem e o antispam costumam estar nesse papel. Quando o seu operador contrata outro para parte do serviço, as orientações da ANPD sobre agentes de tratamento usam o termo suboperador. A lei dá ao titular o direito de saber com quem você compartilha dados e para quê, e essa informação precisa ser clara.

"Parceiros de confiança" falha nos dois pontos. Não diz quem é nem para quê. E esconde uma realidade de time pequeno: ferramentas entram por cartão de crédito, num sprint, porque alguém precisava resolver um problema. Ninguém atualiza a política, o contrato padrão é aceito com um clique e, dois anos depois, ninguém lembra que o plugin de chat recebe o e-mail de cada visitante.

Como levantar quem recebe o dado

Pegue um fluxo concreto e siga o dado. No caso do blog, o comentário:

1. Navegador até o servidor. Passa pela CDN ou pelo proxy reverso de outra empresa? Ela vê IP, cabeçalhos e o corpo do formulário.
2. Aplicação. Onde o servidor roda? Quem é o provedor da máquina ou do serviço gerenciado?
3. Chamadas de saída. Procure no código cada chamada HTTP para fora: antispam, verificação de e-mail, análise de texto.
4. Notificações. Qual serviço envia o aviso de "novo comentário"? O texto do comentário vai no e-mail?
5. Observabilidade. Monitor de erros, logs centralizados, APM. Eles podem capturar corpo de requisição, cookies e usuário logado. Veja log sem senha nem documento.
6. Cópias. Backup, réplica, ambiente de homologação com dados reais.
7. No navegador. Scripts de terceiros carregados na página do comentário veem o que a pessoa digita.

Para cada passo, anote: empresa, função, quais dados recebe, país onde processa, link do contrato ou termo de tratamento de dados. Transferência internacional tem regras próprias na LGPD, então o país importa.

Uma busca rápida ajuda a não depender só da memória. No repositório, procure domínios externos e variáveis de ambiente com chave de API. Cada *_API_KEY é um fornecedor que precisa estar na lista.

Como manter a lista viva no repositório

Lista em documento solto envelhece no primeiro mês. O que funciona é guardar o inventário junto do código e fazer o build reclamar quando aparece dependência nova que ninguém classificou. Um arquivo privacidade/fornecedores.json:

{
  "fornecedores": [
    {
      "funcao": "Envio de e-mail de notificação",
      "empresa": "Provedor de E-mail Exemplo",
      "dados": ["e-mail do autor", "texto do comentário"],
      "pais": "Estados Unidos",
      "contrato": "https://exemplo.com/termos-de-tratamento",
      "pacotes": ["nodemailer"]
    },
    {
      "funcao": "Monitoramento de erros",
      "empresa": "Monitor Exemplo",
      "dados": ["IP", "URL", "mensagem de erro"],
      "pais": "Alemanha",
      "contrato": "https://exemplo.com/dpa",
      "pacotes": ["@sentry/node"]
    }
  ],
  "pacotesSemDadoPessoal": ["express", "mysql2", "helmet", "zod"]
}

E um script que roda no CI e falha se o package.json tiver dependência que não está em nenhuma das duas listas:

const fs = require('fs');

const pkg = JSON.parse(fs.readFileSync('package.json', 'utf8'));
const inv = JSON.parse(fs.readFileSync('privacidade/fornecedores.json', 'utf8'));

const classificados = new Set(inv.pacotesSemDadoPessoal);
for (const f of inv.fornecedores) {
  for (const p of f.pacotes || []) classificados.add(p);
  for (const campo of ['funcao', 'empresa', 'dados', 'pais', 'contrato']) {
    if (!f[campo] || (Array.isArray(f[campo]) && f[campo].length === 0)) {
      console.error('Fornecedor "' + (f.empresa || '?') + '" sem o campo ' + campo);
      process.exitCode = 1;
    }
  }
}

const deps = Object.keys(pkg.dependencies || {});
const faltando = deps.filter((d) => !classificados.has(d));
if (faltando.length) {
  console.error('Dependências sem classificação de privacidade: ' + faltando.join(', '));
  console.error('Adicione em privacidade/fornecedores.json antes de subir.');
  process.exitCode = 1;
}

Rode com node scripts/checar-fornecedores.js no pipeline. O script não descobre sozinho se um pacote envia dados; ele força uma pessoa a decidir e deixar a decisão registrada no pull request. Serviços contratados sem pacote, como a CDN, entram no JSON do mesmo jeito, com pacotes vazio.

O que vai para a política pública

A política não precisa copiar o JSON, mas precisa ser específica. Uma forma que funciona é listar por função e nomear a empresa:

Para hospedar o site usamos a empresa X (servidores no Brasil). Para enviar e-mails de notificação usamos a empresa Y (Estados Unidos), que recebe seu e-mail e o texto do comentário. Para detectar erros usamos a empresa Z, que recebe endereço IP e a página acessada.

Quando trocar de fornecedor, atualize a lista e a data de revisão da política no mesmo pull request. Se a mudança for relevante para quem já é usuário, avise.

Antes de ligar uma ferramenta nova

A pergunta não é "posso usar?", é "o que ela recebe e precisa receber?". Muitas ferramentas permitem reduzir a coleta: mascarar campos no monitor de erros, desligar gravação de sessão, não enviar o corpo do e-mail para análise. Configure isso antes de ir para produção, não depois da reclamação. Se o fornecedor processa dado pessoal, procure o termo de tratamento de dados dele e guarde o link no inventário. A mesma lógica vale para o formulário: veja como montar um formulário de contato que chega sem espalhar a mensagem por serviços desnecessários.

Erros comuns

• Escrever "parceiros" na política. A pessoa não sabe para onde o dado vai e você não cumpre o dever de informar com clareza.
• Esquecer a observabilidade. O monitor de erros captura corpo de requisição com e-mail e às vezes senha. Vira o fornecedor com mais dado e menos atenção.
• Trocar de fornecedor sem atualizar a lista. A política nomeia uma empresa que você nem usa mais e omite a atual.
• Ignorar o país. Transferência internacional exige base própria. Sem saber o país, você não sabe se precisa dela.
• Contrato só aceito no clique. Ninguém sabe o que o fornecedor pode fazer com o dado nem quanto tempo guarda.
• Lista sem dono. Documento que ninguém revisa envelhece em semanas.

Checklist

• Cada fornecedor que recebe dado pessoal tem função, empresa, dados, país e contrato registrados.
• O inventário está no repositório e o CI falha com dependência não classificada.
• Variáveis de API key do ambiente batem com a lista de fornecedores.
• A política pública nomeia as empresas por função, sem "parceiros".
• Monitor de erros e logs mascaram e-mail, senha e documento.
• Toda troca de fornecedor atualiza lista e política no mesmo pull request.
• A lista tem um responsável e uma data de revisão.

Pegue o formulário de comentário do seu blog e responda por escrito, agora: por quantas empresas passa o texto que a leitora digitou, e todas elas estão nomeadas na sua política?