A maioria das empresas que coletam dados da web não tem regras escritas para fazer isso. Um desenvolvedor cria um scraper para um projeto de precificação, outra equipe o copia para pesquisa de leads, um contratado adiciona um terceiro, e ninguém consegue dizer quais sites são coletados, quais dados pessoais são armazenados, ou quem responderia a uma reclamação de um proprietário de site. O trabalho geralmente está correto. O problema é que ninguém consegue demonstrar que está correto.
Uma política interna curta resolve isso. Ela dá aos engenheiros padrões claros, dá às equipes jurídica e de segurança algo para revisar uma vez em vez de toda vez, e dá à empresa uma resposta quando um cliente, um auditor ou um site pergunta como ela coleta dados. Este guia explica o que essa política precisa cobrir e traz um modelo que você pode adaptar.
Principais conclusões
- Uma política de coleta deve ser curta o suficiente para que os engenheiros a leiam: escopo, uma etapa de aprovação, regras para fontes, regras para dados pessoais e o que acontece quando alguém se opõe.
- Torne o caminho seguro o padrão. Páginas públicas, sem login, identificação honesta, ritmo moderado e respeito ao robots.txt não precisam de aprovação especial; qualquer outra coisa precisa.
- Trate objeções como objeções. A autoridade de proteção de dados da França, por exemplo, espera que os coletores excluam sites que se opõem por meio do robots.txt ou de CAPTCHAs.
- Dados pessoais mudam tudo: defina o que você pode coletar, minimize-os no momento da coleta, defina um prazo de retenção e torne a exclusão possível.
- Nomeie um responsável e um processo de remoção. A primeira reclamação é o pior momento para decidir quem vai respondê-la.
- Este modelo é um ponto de partida, não um aconselhamento jurídico; peça que a área jurídica o revise em relação às suas jurisdições e contratos.
Por que uma política escrita importa
Há três razões práticas.
Consistência. Sem regras escritas, cada projeto toma suas próprias decisões sobre robots.txt, ritmo, dados pessoais e retenção. Alguns serão cuidadosos, outros não, e a empresa carrega o risco do menos cuidadoso.
Velocidade. Uma política com padrões claros permite que a maioria dos projetos comece sem uma reunião. Jurídico e segurança revisam a política uma vez, depois apenas as exceções.
Evidência. Os reguladores de proteção de dados esperam que os controladores consigam demonstrar quais salvaguardas aplicam. A autoridade francesa de proteção de dados, a CNIL, por exemplo, publicou orientações sobre a coleta de dados pessoais por web scraping que listam medidas como definir critérios de coleta com antecedência, excluir sites que claramente se opõem, inclusive por meio do robots.txt ou de CAPTCHAs, filtrar dados desnecessários e excluir dados sensíveis assim que forem identificados. Uma política escrita é como você demonstra que essas medidas existem.
O que a política precisa cobrir
| Seção | A pergunta que ela responde |
|---|---|
| Finalidade e escopo | A quais atividades e equipes isso se aplica? |
| Papéis | Quem é responsável pela política, quem aprova projetos, quem responde a reclamações? |
| Regras padrão | O que qualquer projeto pode fazer sem pedir autorização? |
| Aprovação | O que precisa de aprovação, de quem e com quais informações? |
| Fontes | Quais sites e páginas estão dentro do escopo, e como tratamos seus sinais? |
| Dados pessoais | O que podemos coletar sobre pessoas, e como minimizamos e protegemos esses dados? |
| Conduta técnica | Como os coletores se identificam, controlam o ritmo das requisições e lidam com credenciais? |
| Fornecedores | O que exigimos de provedores de proxy e de dados? |
| Armazenamento e retenção | Onde os dados coletados ficam, quem pode acessá-los, por quanto tempo os mantemos? |
| Objeções e remoções | O que acontece quando um proprietário de site, uma pessoa ou um regulador se opõe? |
| Registros e revisão | O que registramos, e quando revisamos a política? |
O modelo
Adapte o texto à sua empresa, exclua o que não se aplica e mantenha-o curto. O texto entre colchetes é para você preencher.
1. Finalidade e escopo
Esta política rege a coleta automatizada de dados de sites e serviços on-line pela [Empresa], seus funcionários e contratados, incluindo scrapers, crawlers, automação de navegador e dados comprados de terceiros que coletam em nosso nome. Ela não cobre dados que nossos próprios usuários nos fornecem, ou APIs oficiais usadas sob seus próprios termos, exceto quando a seção 6 se aplicar.
2. Papéis
- Responsável pela política: [cargo, por exemplo Head of Data] mantém esta política e o registro de projetos de coleta.
- Aprovadores: [contato jurídico] e [contato de segurança] aprovam projetos que precisam de aprovação conforme a seção 4.
- Responsável pelo projeto: cada projeto de coleta nomeia uma pessoa responsável por seguir esta política.
- Contato de remoção: [cargo e caixa de e-mail compartilhada] recebe e responde objeções conforme a seção 10.
3. Regras padrão para todo projeto
Qualquer projeto pode prosseguir sem aprovação adicional se:
- coletar apenas páginas publicamente disponíveis que qualquer visitante possa ver sem fazer login;
- respeitar o robots.txt e outros mecanismos de opt-out legíveis por máquina que se apliquem ao coletor;
- identificar o coletor de forma honesta e não disfarçar o tráfego automatizado como uma pessoa específica;
- controlar o ritmo das requisições de modo que não cause carga perceptível no alvo;
- não coletar dados pessoais além do que a seção 6 permite;
- estar registrado no registro de projetos antes de começar.
4. Projetos que precisam de aprovação
Um projeto precisa de aprovação por escrito dos aprovadores antes de começar se ele:
- coletar dados pessoais além de detalhes de contato comercial publicados para fins comerciais;
- coletar qualquer dado de categoria especial, como saúde, religião ou opinião política;
- coletar de páginas atrás de login, paywall ou qualquer outro controle de acesso;
- continuar depois que um site tiver mostrado que se opõe, inclusive por meio do robots.txt, um CAPTCHA, bloqueio, uma cláusula contratual ou um pedido direto;
- coletar para treinamento, ajuste fino ou avaliação de modelos de aprendizado de máquina;
- vender, licenciar ou compartilhar os dados coletados fora da [Empresa].
O pedido indica a finalidade, as fontes, os campos de dados, quaisquer dados pessoais e sua base legal, o volume esperado, o período de retenção e o responsável pelo projeto.
5. Fontes e seus sinais
- Prefira uma API oficial, um feed de dados ou uma licença quando houver uma disponível e que cubra a necessidade.
- Leia e registre os termos relevantes de cada fonte antes de a coleta começar.
- Trate o robots.txt, limites de taxa, CAPTCHAs, bloqueios e reservas publicadas como sinais da vontade do site, não como obstáculos a serem contornados.
- Não contorne controles de acesso, medidas técnicas de proteção ou autenticação.
- Pare de coletar de uma fonte prontamente quando ela se opuser, e registre a interrupção no registro.
6. Dados pessoais
- Colete apenas os dados pessoais que a finalidade declarada exige, e filtre outros dados pessoais no momento da coleta sempre que possível.
- Nunca colete dados de categoria especial a menos que aprovado conforme a seção 4; se forem coletados por acidente, exclua-os assim que forem identificados.
- Pseudonimize identificadores quando a análise não precisar da identidade em si.
- Não combine dados coletados com outras fontes para identificar indivíduos, a menos que aprovado.
- Torne possível encontrar e excluir os dados de uma pessoa mediante solicitação.
7. Conduta técnica
- Armazene credenciais de proxies, APIs e contas-alvo no gerenciador de segredos aprovado, nunca no código.
- Use apenas provedores de proxy e de dados que atendam à seção 8.
- Registre, para cada execução de coleta, o horário, a fonte, a localização de coleta e a configuração utilizada.
- Monitore volumes de requisições e taxas de erro, e pause a coleta automaticamente quando uma fonte começar a recusar requisições.
8. Fornecedores
Fornecedores de proxy e de dados devem conseguir demonstrar como sua rede ou seus dados são obtidos e com que consentimento, operar um processo de know-your-customer, aplicar uma política de uso aceitável, e assinar termos consistentes com esta política. O responsável pela política mantém uma lista de fornecedores aprovados.
9. Armazenamento e retenção
- Armazene os dados coletados apenas em [sistemas aprovados], com acesso limitado às pessoas que precisam deles.
- Mantenha as páginas brutas coletadas por no máximo [período] e os dados extraídos por no máximo [período], a menos que uma aprovação defina um período diferente.
- Exclua os dados ao final do período de retenção, e registre a exclusão.
10. Objeções e remoções
- Qualquer objeção de um proprietário de site, de um indivíduo ou de uma autoridade vai para o contato de remoção dentro de [um dia útil].
- A coleta afetada é pausada enquanto a objeção é analisada, a menos que o jurídico oriente de outra forma.
- O contato de remoção responde dentro de [período] e registra a objeção, a decisão e quaisquer dados excluídos.
- Objeções repetidas sobre o mesmo projeto acionam uma revisão da aprovação desse projeto.
11. Registros e revisão
O responsável pela política mantém o registro de projetos, as aprovações, a lista de fornecedores e o log de remoções, e revisa esta política pelo menos [anualmente] e sempre que a lei ou as atividades da empresa mudarem materialmente.
Fazendo isso funcionar na prática
Uma política que fica parada em um drive compartilhado não muda nada. Alguns hábitos a tornam real:
- Coloque o registro onde os projetos começam. Um formulário curto na ferramenta que os engenheiros já usam, com as regras padrão como caixas de seleção, identifica os projetos antes que eles existam em vez de depois.
- Incorpore os padrões ao código. Uma biblioteca de coleta compartilhada que respeita o robots.txt, define um User-Agent honesto, controla o ritmo das requisições e registra o contexto da coleta torna a política o caminho fácil, não uma etapa extra. Respeitando o robots.txt e os opt-outs de IA aborda quais sinais ler.
- Registre onde os dados foram observados. Registrar horário, localização e configuração por execução é o que torna os dados coletados defensáveis mais tarde, como argumentado em o caso para um padrão de ponto de observação.
- Verifique seus fornecedores. Pergunte aos provedores de proxy como eles obtêm seus IPs, e veja como os provedores obtêm IPs residenciais de forma ética e a economia de malware por trás de proxies baratos para entender por que isso importa.
- Mantenha segredos fora do código. Executando scrapers em CI/CD mostra como lidar com credenciais de proxy com segurança.
- Leia os sinais antes de construir. Uma verificação rápida do que protege uma fonte, como em nossa consulta de stack anti-bot, mostra cedo se um projeto se enquadra nas regras padrão ou precisa de aprovação.
Para o panorama jurídico mais amplo, veja web scraping é legal e proxies residenciais e GDPR; para a prática do dia a dia, boas práticas de web scraping.
Conclusão
Uma política de coleta de dados não precisa ser longa. Ela precisa de um escopo claro, padrões seguros que permitam que a maior parte do trabalho prossiga, uma etapa de aprovação para os casos arriscados, regras firmes para dados pessoais, e uma pessoa nomeada que responda quando alguém se opuser.
Escreva-a uma vez, incorpore seus padrões às ferramentas que os engenheiros usam, e mantenha o registro atualizado. Então, na próxima vez que alguém perguntar como sua empresa coleta dados da web, a resposta será um documento em vez de uma correria. Adapte o modelo à sua situação, e peça que a área jurídica o revise antes de adotá-lo.