Projeto

Política de Dados

Versão: 2.1 · Data: 11/10/2026 (v1.0: 12/08/2026; v1.1: 14/08/2026; v1.2: 21/08/2026; v2.0: 08/10/2026) · Responsável: Carlos Paes, pessoa física, pesquisador independente — controlador e encarregado · Canal para pedidos sobre dados: [email protected] (mensagens de apoio: [email protected]; outros assuntos: [email protected]) · Abrange: o banco de dados da pesquisa e o site omecanismo.org.

1. Missão e escopo

O banco e o site existem para duas finalidades, nesta ordem: (1) pesquisa sobre o mecanismo do bode expiatório em redes sociais (teoria mimética), combinando casos empíricos e simulação baseada em agentes; (2) interesse público: manter um acervo acessível de episódios documentados de cancelamento em rede, num site que também acolhe quem passou por isso. Nenhuma atividade de dados do projeto se justifica fora dessas duas finalidades.

O banco trata postagens públicas do X/Twitter, em português, reunidas por coleta própria em torno de oito episódios ocorridos entre 2014 e 2025; dados de simulação (NetLogo), que não são dados pessoais; relatos enviados por quem quis contar um caso (formulário Conte seu caso); e mensagens de quem pediu apoio (formulário Estou passando por isto). Cada coleta tem data, parâmetros e arquivo bruto registrados no catálogo do banco. A coleta está encerrada desde 01/10/2026: não há coleta contínua nem campanha nova prevista; um caso novo só entra no acervo por decisão registrada do responsável, nos termos desta política.

Instrumento de coleta. A coleta usou a busca pública da plataforma, por automação de navegador em máquina do responsável, com teto de cerca de mil postagens por dia em quatro dos oito casos, e não devolve compartilhamentos simples (retweets). Esses limites aparecem no site: os dias em que o volume bateu no teto estão marcados nas curvas.

2. Princípios

  1. Não renovar o dano. O banco documenta processos de vitimização; não pode se tornar um novo instrumento de exposição. Na dúvida entre publicar e proteger, protege-se. Pedidos de quem foi alvo têm prioridade máxima.
  2. Minimização no público. O site recebe o mínimo necessário à finalidade — agregados, formas de rede e textos descritivos —, nunca o máximo disponível. Tudo o que identifica, localiza ou reproduz uma postagem ou uma conta permanece no ambiente privado.
  3. Transparência metodológica. Papéis (alvo, alvo secundário, instituição) e a posição das postagens (acusa, contesta, nenhuma das duas) são classificações produzidas pelo método de pesquisa, não fatos nem juízos morais sobre pessoas. Toda classificação carrega proveniência (quem ou qual modelo classificou, versão, confiança) e critérios documentados, e pode ser contestada pelo canal desta política.
  4. Proveniência e reprodutibilidade. Todo dado tem origem registrada (coleta, arquivo bruto com hash, versão de pipeline). Dado sem proveniência não entra no banco. Cada decisão de publicar, alterar ou remover um caso fica registrada, com data e fontes.
  5. Respeito às fontes. Os termos das plataformas restringem a redistribuição de conteúdo; o projeto não redistribui texto de postagens nem identificadores.
  6. A forma, não o mérito. O site descreve a forma da convergência sobre uma pessoa e não julga se a acusação procedia. Nenhum texto do site atribui conduta a alguém identificável.

3. O que é público e o que nunca é

O site publica apenas:

  • textos descritivos de cada caso, em que ninguém é nomeado — nem o alvo. Cada caso é identificado pela transgressão que o desencadeou, pelo ano e pela natureza do alvo (figura pública ou pessoa privada); empresas e instituições aparecem pelo papel que cumpriram, nunca pelo nome;
  • métricas agregadas por caso e por dia: volume, concentração das menções (Gini), centralização, parcela da atenção dirigida ao alvo, fragmentação em ilhas, modularidade, entrada de contas, atenção a instituições, à imprensa e a alvos secundários, tempo entre a cobrança a uma instituição e a resposta dela; parcelas diárias de postagens que acusam, contestam ou nomeiam o ato; totais de mudança de lado por caso. Nenhuma métrica é de uma conta; nenhum total abaixo de cinco é publicado; dias com menos de 30 contas na rede não recebem medidas estruturais nem desenho;
  • grafos sem identificadores: cada nó é só posição no desenho, tamanho em faixas e tipo (alvo, conta, instituição, alvo secundário). Não há nome, perfil, @, pseudônimo nem contagem por conta. Só contas com cinco ou mais ligações no dia são desenhadas uma a uma; as demais entram como amostra, sem atributo. Instituições recebem rótulo genérico (“instituição A”) só quando são até quatro no desenho do dia. Cada ligação leva a cor da posição da postagem que a gerou (acusa, contesta ou nenhuma das duas) — a posição é da postagem, nunca da conta, e nenhum nó é marcado como acusador ou defensor;
  • a proveniência do método: como os dados são coletados e tratados, quais medidas são calculadas, qual modelo classifica a posição das postagens e com que desempenho, e estes critérios de publicação;
  • o modelo de simulação e seus resultados, que não envolvem dados pessoais.

Nunca são públicos:

  • texto integral ou trechos de postagens, e capturas de tela que os reproduzam — conteúdos são descritos, não reproduzidos;
  • identificadores nativos de postagens e de contas, e as consultas de coleta (que contêm nomes);
  • a tabela de correspondência entre pseudônimos internos e contas reais;
  • qualquer medida, posição ou papel atribuído a uma conta identificável — inclusive os papéis narrativos usados na pesquisa (quem liderou, quem aderiu) e a posição classificada de cada postagem ligada a quem a escreveu (no grafo, a posição aparece só na ligação, sem identificar a conta);
  • nomes, handles e imagens de pessoas, públicas ou não, ainda que os dados tenham sido públicos na origem;
  • relatos e mensagens recebidos pelo site, e os dados de contato de quem os enviou;
  • credenciais, chaves de API e o conteúdo bruto da coleta.

Pessoa privada. Quando o alvo de um caso não é figura pública, a página do caso fica fora dos buscadores (noindex) e o texto omite os elementos que permitiriam identificá-la: nome, local, imagem, datas exatas de calendário e as consequências concretas que recaíram sobre ela, inclusive decisões de instituições ou da Justiça a seu respeito. Decisões sobre alvos secundários institucionais — por exemplo, a punição de um clube — podem ser descritas pelo papel, sem nome, e datadas só em dias contados a partir do estopim.

Pseudonimizar não é anonimizar. Os episódios são reais e foram públicos; quem os conhece pode reconhecê-los, e nos nós mais centrais a posição na rede, combinada a informação externa, pode sugerir de quem se trata. O site não acrescenta nada ao que já era público e não atribui conduta a ninguém identificável. Dado pseudonimizado no banco continua sendo dado pessoal e permanece sujeito a esta política.

Verificabilidade científica. Como nada que permita localizar as postagens é publicado, a verificação por terceiros não se faz por re-hidratação livre. Pesquisadores identificados podem pedir, pelo canal desta política e com finalidade declarada, acesso à lista de identificadores de um caso, sob compromisso escrito de não redistribuição; a decisão é do responsável e fica registrada (§ 9). Depósitos em repositórios abertos levam só o conjunto agregado e o dicionário de dados.

Revisão antes de publicar. Cada publicação ou alteração de caso é revista e registrada internamente, com data, fontes conferidas e o teste de identificação aplicado. O registro não é publicado, mas é apresentado a quem tiver interesse legítimo em um pedido do § 6.

4. Quem responde pelos dados

O projeto é conduzido por um responsável: Carlos Paes, pessoa física, pesquisador independente, sem vínculo institucional. Ele é o controlador dos dados tratados pelo banco e pelo site e exerce também a função de encarregado (canal: [email protected]). Decide sozinho sobre publicação, remoção, exportação e concessão de acesso, e registra cada decisão (§ 9). Na dúvida, prevalece a alternativa mais protetiva (princípio 1).

A colaboração anterior, em regime paritário, terminou; o fim de uma colaboração implica revogação dos acessos, anotada no registro do § 9. Quando a pessoa jurídica em constituição existir, ela passa a ser a controladora e esta política é revista para registrar isso; até lá, o responsável responde como pessoa física.

PapelQuem (hoje)Responsabilidade
Responsável (controlador e encarregado)Carlos PaesDecisão de publicação e de remoção; resposta a titulares; guarda de chaves e backups; manutenção desta política
Moderador de contribuiçõesO responsável (futuro: convidados)Avaliar relatos e casos contribuídos segundo esta política antes de qualquer uso em publicação
Quem contribuiPessoas que enviam relatos pelo siteEnviar relato próprio e verdadeiro, sem identificar terceiros; aceitar os termos de contribuição e o consentimento datado
Revisor independenteAgente ou pessoa sem envolvimento na redaçãoRevisar textos e dados antes de uma publicação, com relatório registrado

Um relato contribuído nunca vira página do site por si: entra na base de pesquisa e só aparece em publicações de forma agregada ou desidentificada (§ 7).

5. Ciclo de vida, retenção e descarte

Coleta. Sempre com propósito e parâmetros registrados; o arquivo bruto é imutável e catalogado (hash, escrita única). A coleta está encerrada (§ 1).

Camadas e retenção. O banco tem três camadas: o bruto (arquivos como vieram da coleta), a camada tratada (postagens, contas pseudonimizadas, classificações) e a camada publicada (agregados e grafos sem identificadores). A camada publicada é a única que sai do ambiente privado. Prazo de retenção do texto das postagens no ambiente privado: o texto integral e o bruto ficam enquanto a pesquisa estiver ativa, com revisão anual registrada que decide, caso a caso, o que continua necessário; o que deixar de ser necessário é eliminado, ficando só agregados e o registro de proveniência. Dados de perfil que vieram junto com a coleta (biografia, contagens de seguidores) não são usados nas medidas e são os primeiros candidatos à eliminação.

Exclusão lógica e efetiva. Durante a pesquisa a exclusão é lógica (marcação): ativa, apagada na fonte, removida a pedido. Postagens marcadas saem do cálculo das métricas e dos grafos na atualização seguinte do pipeline. Para a marca removida a pedido, o texto e o conteúdo bruto da postagem passam a ser eliminados — rotina em implantação, a concluir antes da abertura do site ao público; fica apenas o registro do pedido, sem o conteúdo, para comprovar o atendimento.

Conteúdo apagado na origem. Como nada publicado depende da plataforma para existir, o que foi apagado na origem não desaparece sozinho do que o projeto divulga. A cada atualização de um caso, uma amostra das postagens é verificada na origem e as apagadas recebem a marca correspondente. Com a coleta encerrada e os casos estáveis, a verificação acontece na revisão anual.

Relatos e mensagens de apoio. O site não guarda formulários em banco de dados: cada envio vira um e-mail para uma caixa do projeto. Um relato de Conte seu caso é dado de pesquisa, registrado com a versão do consentimento marcada, e é guardado por até 6 meses a contar do recebimento; depois disso o texto é apagado e ficam só resultados anonimizados de análises agregadas. Uma mensagem de Estou passando por isto é conversa, não dado: fica na caixa enquanto a conversa durar e é apagada quando a pessoa pedir, quando a conversa terminar ou, no máximo, 6 meses depois da última mensagem. Em qualquer dos dois, a pessoa pode pedir a exclusão a qualquer momento.

Limite de envios. Para conter abuso, o site limita o número de envios e de perguntas ao chatbot por conexão por hora. Para essa contagem guarda, por no máximo uma hora, um código derivado do endereço de rede — não o endereço —, que não entra no e-mail nem em registro permanente.

6. Pedidos de remoção, correção e contestação

Qualquer pessoa citada ou alcançada por um caso — ainda que não nomeada — pode pedir correção, anonimização adicional ou remoção de dados a seu respeito, no site ou no banco, escrevendo para [email protected]. O mesmo canal recebe contestações a uma classificação ou a uma descrição (princípio 3) e os pedidos de titulares previstos na LGPD: confirmação de tratamento, acesso, correção, anonimização, eliminação, informação sobre compartilhamento, e revogação do consentimento dado num relato.

Compromissos. Resposta em até 7 dias, com a decisão e o que foi alterado; a pessoa que pediu é informada em qualquer caso. Pedidos de quem foi alvo de um episódio têm prioridade e leitura mais favorável. Não se exige que a pessoa prove ser quem diz ser além do razoável para o pedido: para retirar algo do site basta o pedido; para receber dados do banco a seu respeito, é preciso demonstrar a titularidade da conta.

O que a remoção atinge. O site, na publicação seguinte — em regra no mesmo prazo de 7 dias. No banco, a postagem ou a conta recebe a marca removida a pedido: sai das medidas e dos grafos na atualização seguinte, e o texto e o conteúdo bruto são eliminados, nos termos e no prazo de implantação do § 5. Quando o pedido envolve um caso inteiro de pessoa privada, a página pode ser retirada por completo.

Registro. Cada pedido — data, objeto, decisão, data do atendimento — fica no registro interno de publicação, sem o conteúdo removido. Esse registro é o que permite dizer que o prazo foi cumprido.

Se o pedido for negado. A resposta diz por quê e o que a pessoa pode fazer em seguida, inclusive recorrer à Autoridade Nacional de Proteção de Dados.

Quem trata. Uma pessoa física, sem vínculo institucional e, por ora, sem personalidade jurídica própria (§ 4). O projeto não é “órgão de pesquisa” no sentido do art. 5º, XVIII, da LGPD, que alcança entidades da administração pública e pessoas jurídicas sem fins lucrativos com missão institucional de pesquisa; por isso as hipóteses dos arts. 7º, IV, e 11, II, “c” não estão disponíveis ao projeto.

Postagens públicas (dados pessoais comuns). Os dados foram tornados manifestamente públicos pelos titulares nas plataformas; o tratamento observa finalidade, boa-fé e interesse público (art. 7º, §§ 3º e 4º) e se apoia no legítimo interesse (art. 7º, IX), com o teste de proporcionalidade documentado em relatório interno: finalidade legítima e de interesse público (§ 1), necessidade dos dados para a finalidade e minimização no ambiente público (§§ 2 e 3), salvaguardas efetivas (pseudonimização, remoção a pedido, controle de acesso). O relatório de legítimo interesse e o registro das operações de tratamento (art. 37) são documentos internos, mantidos pelo responsável e apresentados à autoridade quando pedidos.

Posição das postagens (classificação). Um classificador de linguagem treinado nesta pesquisa atribui a cada postagem uma de três posições: acusa, contesta a acusação, nenhuma das duas. A posição descreve o ato de fala de uma postagem dentro de um episódio — não uma opinião política, uma convicção ou um traço da pessoa — e é publicada só agregada (parcelas por dia, totais por caso) ou por interação no grafo, nunca ligada a uma conta identificável (§ 3). No banco, a posição fica associada à postagem pseudonimizada, com proveniência (modelo, versão, confiança) e acesso restrito ao responsável; nenhum rótulo de posição por conta é guardado ou publicado — o lado de uma conta num dia é calculado internamente, só para os totais de mudança de lado, e sai do banco somado (§ 3) —, e os papéis narrativos usados na análise descrevem só comportamento observável na rede.

Opinião política e outros dados sensíveis. Postagens de episódios de cancelamento podem revelar opinião política, religião ou outro dado sensível (art. 5º, II). O projeto não extrai, não classifica e não publica nenhum desses atributos; o texto que os contém fica no ambiente privado, sob as regras dos §§ 5 e 9, e é o primeiro candidato à eliminação na revisão de retenção. Na dúvida sobre publicar qualquer coisa que revele um atributo sensível de alguém, não se publica.

Crianças e adolescentes. A coleta não distingue a idade de quem escreveu; postagens de adolescentes podem existir no acervo. Nenhuma postagem é publicada individualmente, nenhuma conta é identificável no site, e um pedido de remoção feito por adolescente ou por responsável tem prioridade. Os formulários do site exigem declaração de maioridade; o chatbot não coleta dados.

Relatos e mensagens. Base legal: consentimento (art. 7º, I), colhido em cada formulário com texto datado, específico e revogável. Quem envia um relato declara ter 18 anos ou mais, que o relato é próprio e verdadeiro e não identifica terceiros; autoriza o uso desidentificado em pesquisa e concede licença gratuita e não exclusiva para citar e traduzir trechos desidentificados em análises e publicações. A mensagem de apoio não é tratada como dado de pesquisa.

Chatbot. As perguntas feitas em Perguntar — com as mensagens anteriores da mesma conversa, até oito, para que a resposta tenha contexto — são enviadas à API da Anthropic (Estados Unidos) para gerar a resposta e não são guardadas pelo projeto; o site avisa isso antes do uso. O corpus do assistente é feito só de textos próprios do projeto, sem nomes das pessoas envolvidas nos casos.

Fase acadêmica e site público. Enquanto o tratamento era exclusivamente acadêmico incidia o art. 4º, II, “b”, que mesmo assim remete aos arts. 7º e 11. Com o site no ar, o tratamento passa a ser atividade contínua de divulgação de interesse público; esta política foi revista antes da publicação por esse motivo.

Porte. Agente de tratamento de pequeno porte (Resolução CD/ANPD nº 2/2022), o que dispensa a indicação formal de encarregado — mantido, em qualquer hipótese, o canal do cabeçalho — e dobra os prazos do § 10.

Ética em pesquisa. Por usar informações de acesso público, a pesquisa se enquadra nas hipóteses do art. 1º, parágrafo único, II–III, da Resolução CNS 510/2016. Sem vínculo institucional não há comitê de ética ao qual submeter o protocolo; a ausência de análise ética externa é suprida, na medida do possível, pelas salvaguardas desta política e é declarada em qualquer publicação.

Ressalva. Esta política foi submetida a parecer de advogado especializado em direito digital (outubro de 2026) e incorpora suas recomendações. Termos de uso, política de privacidade em sentido estrito e termos de contribuição são documentos separados, em elaboração; até lá, valem as regras desta política e os textos dos próprios formulários.

8. Operadores e transferência internacional

São operadores os terceiros que tratam dados por conta do projeto. Nenhum dado identificável é enviado a um serviço que não esteja nesta lista, e cada um recebe só o que a sua função exige. Vários ficam fora do Brasil; a transferência se dá nos termos do capítulo V da LGPD, com base nas cláusulas e garantias dos próprios provedores.

ServiçoPaísFunçãoO que recebe
Cloudflare (Pages, Functions, KV, Email Routing)EUAHospedagem do site, formulários, limite de envios, roteamento de e-mailPáginas públicas; o conteúdo dos formulários em trânsito; código derivado do endereço de rede por até 1 hora; e-mails dos endereços @omecanismo.org em trânsito
ResendEUAEnvio dos e-mails gerados pelos formuláriosCópia de cada e-mail enviado (texto, assunto e endereços), guardada por 30 dias e depois apagada; cópias de segurança até 7 dias a mais
Google (Gmail)EUACaixa de e-mail do projeto (relatos, apoio, remoção, contato)Os e-mails recebidos e as respostas, pelos prazos do § 5
Anthropic (API)EUAGera as respostas do chatbotCada pergunta, com até oito mensagens anteriores da mesma conversa, e o corpus do site; nada é guardado pelo projeto
DatabricksEUABanco de dados da pesquisa (bruto, tratado, publicado)Postagens coletadas, contas pseudonimizadas, classificações, métricas
GitHubEUARepositórios de código (privados)Código do site e do pipeline e os dados já publicados; nunca o bruto, nunca identificadores
Hugging FaceEUAGuarda do modelo classificador de posiçãoOs pesos do modelo; não recebe postagens do acervo

Sem cookies, sem medição. O site não usa cookies, não tem medição de audiência nem recursos de terceiros carregados na página (fontes, vídeos externos, botões de redes sociais).

Contratos. Os serviços acima são contratados sob os termos padrão de cada provedor, que incluem suas cláusulas de tratamento de dados. Um incidente num provedor é incidente do projeto (§ 10): o prazo legal do controlador não se suspende porque a falha foi de um fornecedor.

9. Controle de acesso e proteção do ambiente

Princípio. Cada pessoa e cada programa recebe o menor privilégio suficiente para a sua função. Como o acervo documenta pessoas já expostas uma vez, um acesso indevido aqui não é um problema de propriedade intelectual: é a repetição do dano que o projeto estuda. Com a decisão de não publicar identificadores, o banco privado é o único lugar onde a ligação entre pessoa e caso existe.

Perfis de acesso. O banco opera com contas nominais, nunca com credencial compartilhada.

PerfilQuem / o quêPode
ResponsávelCarlos PaesTudo, inclusive publicar, remover e conceder acessos — cada uma dessas ações é registrada
Colaborador convidadoNinguém, hojeLer apenas a camada publicada ou um recorte pseudonimizado, por prazo definido; nunca a tabela de correspondência
SiteA aplicação públicaNada no banco: o site é estático, construído a partir de arquivos exportados da camada publicada
PipelineRotinas automatizadasEscrever nas camadas bruta e tratada; sem apagar estruturas

A concessão, alteração e revogação de acessos é registrada e revista a cada revisão semestral; o fim de uma colaboração implica revogação imediata. A separação entre a tabela de correspondência e o restante do banco, com permissões próprias, é condição para qualquer colaborador receber acesso.

Autenticação. Contas que dão acesso a dados (nuvem do banco, repositórios, hospedagem, caixas de e-mail do projeto, provedor do modelo) exigem autenticação em dois fatores e senhas únicas guardadas em gerenciador. O site não tem login: ninguém se cadastra para usar o site, enviar um relato ou falar com o assistente.

Segredos. Chaves de API e senhas nunca são versionadas em repositório, público ou privado; as chaves do site ficam como segredos na hospedagem. Exposição de credencial — ainda que suspeita, ainda que antiga no histórico de versões — é incidente (§ 10) e a correção é a rotação da credencial, não só a sua remoção.

Proteção dos dados armazenados. O banco fica em serviço de nuvem que guarda os dados cifrados e só aceita conexão cifrada. Em implantação, a concluir antes da abertura do site ao público: cifragem de disco no computador do responsável, que guarda cópias dos arquivos coletados, e uma cópia de segurança do banco fora do provedor principal, cifrada, cuja restauração passa a ser testada a cada revisão semestral; a data do último teste é um dos indicadores do § 11.

Cópias e ambientes derivados. Extrações para ferramentas de exploração, serviços gratuitos, testes ou demonstrações usam dados pseudonimizados ou agregados, ou rodam localmente. Corpus identificável não é carregado em serviço de terceiro fora do § 8. Toda extração para fora do ambiente de trabalho é registrada.

Registro de ações. Publicar, alterar ou retirar um caso; aprovar o uso de um relato; marcar uma remoção; atender um pedido do § 6; alterar a atribuição de papéis; exportar um conjunto de dados ou uma lista de identificadores; conceder ou revogar acesso — tudo é gravado com data, objeto e motivo. Esse registro sustenta as promessas dos §§ 3, 6 e 10: sem ele, prazo cumprido é afirmação sem prova.

10. Resposta a incidente de segurança

O que conta como incidente. Qualquer acesso não autorizado, perda, alteração, destruição ou divulgação acidental ou ilícita de dados sob responsabilidade do projeto. Incluem-se: exposição de credencial; publicação, por erro, de algo da lista do § 3 (“nunca são públicos”) — inclusive um identificador de postagem, um nome ou a tabela de correspondência; envio de corpus identificável a terceiro fora do § 8; perda de dispositivo com dados do projeto; acesso indevido à caixa de e-mail que guarda relatos e mensagens de apoio.

Procedimento.

  1. Conter, no mesmo dia. Retirar do ar o que estiver exposto, revogar e rotacionar credenciais, suspender o acesso comprometido.
  2. Registrar o conhecimento. Anotar no registro de ações (§ 9) a data e a hora em que se soube que dados pessoais foram afetados — é desse marco que corre o prazo legal.
  3. Avaliar o risco aos titulares, por dois critérios que se somam: o incidente pode afetar significativamente direitos e interesses dos titulares? E envolve dados sensíveis, dados de crianças e adolescentes, credenciais ou dados em larga escala? Registrar a avaliação, inclusive quando concluir pela ausência de risco relevante.
  4. Comunicar, havendo risco relevante, à Autoridade Nacional de Proteção de Dados e aos titulares afetados em até 3 dias úteis a contar do marco do item 2, pelo canal próprio da Autoridade, com o conteúdo mínimo exigido: natureza dos dados afetados, número aproximado e categorias de titulares, medidas técnicas adotadas, riscos identificados e providências tomadas ou propostas. O que não estiver disponível no prazo inicial segue em até 20 dias úteis. Pelo enquadramento de pequeno porte (§ 7), os prazos correm em dobro. Premissa de trabalho: como o acervo reúne texto de muitas contas e pode revelar atributos sensíveis, presume-se que um vazamento do ambiente privado atende aos dois critérios. Na dúvida, comunica-se.
  5. Comunicar aos titulares em linguagem clara: o que aconteceu, quais dados a seu respeito foram afetados e o que o projeto está fazendo — sem exigir que a pessoa entenda a arquitetura do banco para entender o próprio risco. Quem foi alvo de um episódio documentado, se afetado, é comunicado com prioridade.
  6. Corrigir e registrar. Identificar a causa, aplicar a correção, anotar no registro e relatar o incidente na revisão semestral (§ 11).

Responsabilidade. O responsável conduz a resposta. Um plano de incidente interno, com os contatos e os passos operacionais, acompanha esta política e não é publicado.

11. Indicadores de acompanhamento (revisão semestral)

Acervo e pedidos: casos publicados, alterados e retirados no período; pedidos do § 6 recebidos, atendidos e negados, e a parcela respondida em 7 dias; relatos e mensagens de apoio recebidos e a parcela respondida em 7 dias; relatos apagados ao fim dos 6 meses; pedidos de acesso a identificadores por pesquisadores, atendidos e recusados.

Qualidade: parcela das postagens com classificação de posição válida; parcela das menções resolvidas para conta; resultado do último controle de qualidade de carga, por caso; postagens marcadas como apagadas na fonte.

Segurança: incidentes registrados, por gravidade (zero só significa alguma coisa se houver quem procure); acessos ativos por perfil, revistos na própria revisão; data do último backup restaurado com sucesso — backup sem teste de restauração não conta; data da última rotação de credenciais.

12. Vigência e revisão

Esta versão vigora a partir da sua publicação no site, nesta página, com a data indicada no cabeçalho. O resumo em Sobre → Privacidade é um extrato dela; em caso de divergência, vale esta política.

Revisão a cada 6 meses, ou antes, quando mudarem a legislação, os termos das plataformas, o escopo do projeto ou o responsável (§ 4). A revisão semestral inclui a leitura dos indicadores do § 11, a revisão da lista de acessos ativos (§ 9) e o relato dos incidentes do período (§ 10). Toda alteração entra no histórico abaixo, com data e motivo; versões anteriores ficam disponíveis a quem pedir pelo canal do cabeçalho.

Histórico de versões

  • v1.0 — 12/08/2026. Redação inicial (missão, princípios, público × não público, papéis, ciclo de vida, remoção, base legal, indicadores, vigência).
  • v1.1 — 14/08/2026. Novo § sobre controle de acesso e proteção do ambiente e novo § sobre resposta a incidente; grafos reescritos; papéis de controlador e operador; indicadores reorganizados.
  • v1.2 — 21/08/2026. Ambiente público sem identificadores; projeto sem vínculo institucional (não é órgão de pesquisa; dados comuns em legítimo interesse; dados sensíveis em aberto até o parecer); curadoria paritária entre dois responsáveis. Versão submetida ao parecer jurídico.
  • v2.1 — 11/10/2026. Revisão independente de coerência: regra da pessoa privada precisada (decisões sobre alvos secundários institucionais podem ser descritas pelo papel, em dias contados do estopim) (§ 3); posição da postagem no grafo distinguida da posição ligada à conta (§ 3); medidas suprimidas em dias de rede pequena são as estruturais (§ 3); eliminação efetiva a pedido, cifragem de disco e cópia de segurança descritas como em implantação até a abertura ao público (§§ 5, 6 e 9); consentimento datado também no formulário de apoio (§ 7); mensagens anteriores da conversa enviadas ao chatbot (§§ 7 e 8); canal apoio@ no cabeçalho; prazos em dobro pelo pequeno porte (§ 10).
  • v2.0 — 08/10/2026. Após o parecer jurídico e as decisões de outubro: um só responsável, controlador e encarregado, com canal próprio (§ 4); ninguém nomeado no site, nem o alvo, com os critérios de publicação escritos (rede mínima, limiar de grau, instituições pelo papel, pessoa privada fora dos buscadores) e sem a hipótese de nomear figuras públicas (§ 3); posição das postagens classificada por modelo, com proveniência, publicada só agregada e por interação, nunca por conta (§§ 3 e 7); coleta encerrada (§ 1); prazo único de 7 dias para pedidos, em vez de 72 h/15 dias, e remoção efetiva do texto removido a pedido (§§ 5 e 6); relatos e mensagens com retenção de 6 meses, consentimento datado e licença de citação desidentificada (§§ 5 e 7); operadores nomeados, com país e função, chatbot e limite de envios descritos (§ 8); crianças e adolescentes (§ 7); perfis de acesso reduzidos ao arranjo real, site sem acesso ao banco (§ 9); indicadores alinhados aos prazos prometidos (§ 11).