By · Last updated 2026-06-05

Voltar ao BlogGDPR & Conformidade

Por que 'Excluir a Coluna de Email' Não é Suficiente...

CSV de pesquisa contém PII não apenas em colunas estruturadas, mas em respostas de texto livre.

June 5, 20267 min de leitura
research dataCSV anonymizationGDPR Article 89survey datadata sharing

A Lacuna Que a Exclusão de Colunas Não Cobre

Atualizado para 2026

Conjuntos de dados de pesquisa circulam entre universidades como arquivos CSV. Quando as equipes preparam um CSV para compartilhamento, o trabalho é baseado em colunas. Encontrar os dados pessoais. Excluir ou substituir.

Esse método funciona para campos fixos. Uma coluna chamada "email" contém endereços de e-mail — excluir. Uma coluna chamada "phone" contém números de telefone — excluir. Uma coluna chamada "participant_name" contém nomes — substituir por um código.

Mas as respostas em texto livre são um ponto cego. Excluir colunas rotuladas não as afeta.

Uma pesquisa com 5.000 linhas pode ter cinco colunas PII estruturadas e quinze colunas de resposta em texto livre. As estruturadas contêm nomes, e-mails, telefones, IDs e anos de nascimento. As de texto livre contêm comentários, notas e sugestões.

As colunas estruturadas são limpas. As de texto livre ficam brutas. Mas os respondentes escrevem coisas como estes três exemplos.

Primeiro: "Meu médico no Boston Medical Center, Dra. Maria Santos, disse que o tratamento era novo." Segundo: "Estou lidando com isso desde meu acidente de 2019." Terceiro: "Você pode entrar em contato com minha cuidadora em margaret.wells@gmail.com para mais detalhes."

Cada entrada nomeia uma pessoa real. Algumas incluem informações de saúde ou dados de contato. Nada disso aparece em um cabeçalho de coluna. Nada disso é capturado pela exclusão de colunas.

Por Que Isso Não Atende ao Padrão do RGPD

O considerando 26 do RGPD define registros anônimos como aqueles que não podem ser vinculados a nenhuma pessoa. O padrão é rigoroso. Os registros são verdadeiramente anônimos apenas quando a re-identificação não é razoavelmente possível.

Um CSV com colunas estruturadas limpas mas pessoas nomeadas em texto livre não passa nesse teste. Esses nomes são identificáveis. O conjunto de dados ainda é pessoal. As regras de salvaguarda do artigo 89 do RGPD ainda se aplicam. Três riscos surgem daí.

Isenção de pesquisa científica (art. 89): O artigo 89 permite que pesquisadores processem dados pessoais para a ciência com menos obrigações. Mas apenas onde existam "salvaguardas adequadas". Compartilhar um arquivo com PII em texto livre ainda presente enquanto invoca o artigo 89 é uma falha legal.

Aprovação ética: A maioria dos comitês de ética e IRBs exige anonimização genuína para conjuntos de dados compartilhados. Trabalho parcial — colunas estruturadas limpas, texto livre bruto — geralmente não passa no teste. O comitê pode rejeitar a submissão.

Acordos de compartilhamento de dados: Os DSAs entre instituições definem o nível de anonimização exigido. Trabalho parcial que não atende ao considerando 26 do RGPD pode violar o DSA. Confira nossa visão geral de conformidade legal para ver como isso se encaixa em um programa mais amplo.

Por Que o Texto Livre É Tão Difícil de Limpar

As respostas em texto livre de pesquisas estão entre os alvos PII mais difíceis. Veja por quê.

Nomes em contexto: "Dra. Maria Santos no Boston Medical Center" requer reconhecimento de entidades nomeadas (NER) para sinalizar uma pessoa e uma organização. Listas de palavras-chave não conseguem encontrar isso.

Nomes em histórias: "O carro do João bateu no meu" coloca um nome real dentro de uma narrativa. É uma pessoa mencionada de passagem. Somente o NER detecta isso.

Formatos não padrão: Dados de contato podem aparecer como "entre em contato comigo em margaret ponto wells arroba gmail". Ferramentas de apenas regex não capturam essas variações.

Entidades específicas de pesquisa: Pesquisas clínicas frequentemente contêm IDs de hospitais, códigos de sites e nomes de lugares. Estes podem identificar um respondente mesmo quando parecem genéricos.

Correspondência de padrões sozinha não é suficiente. Ferramentas NLP são necessárias para uma anonimização real de pesquisas. Veja Segurança e Conformidade para opções técnicas.

Um Exemplo Real de Três Universidades

Uma equipe de pesquisa de três universidades europeias realizou uma pesquisa sobre experiência do paciente. O conjunto de dados tinha 5.000 respondentes, 3 colunas PII estruturadas e 8 colunas de resposta em texto livre. O objetivo era compartilhamento entre instituições sob um DSA e o artigo 89 do RGPD.

Apenas com exclusão de colunas:

  • Colunas PII estruturadas: removidas
  • Respostas em texto livre: deixadas brutas
  • Afirmação: "Colunas PII excluídas"
  • PII restante: 47 pessoas nomeadas, 23 endereços de e-mail em comentários, 18 referências de lugar que poderiam identificar respondentes

Com detecção NLP:

  • Colunas PII estruturadas: pseudonimizadas com tokens consistentes
  • Respostas em texto livre: 47 nomes substituídos, 23 e-mails mascarados, 18 referências de lugar generalizadas ("Boston Medical Center" → "[Instituição de Saúde]")
  • Resultado: um arquivo que atende ao considerando 26 do RGPD
  • Comitê de ética aprovou o método
  • DPO confirmou conformidade com o DSA

A lacuna é real. O primeiro resultado parece limpo. O segundo resultado está limpo.

Um Protocolo de Cinco Passos Antes do Compartilhamento

Use estes passos antes de compartilhar qualquer arquivo de pesquisa ou entrevista.

Passo 1: Rotular cada coluna Marcar cada coluna como PII estruturada, não-PII estruturada ou resposta em texto livre. Anotar.

Passo 2: Lidar com PII estruturada Excluir entradas desnecessárias para análise. Pseudonimizar entradas necessárias para vinculação de registros. Registrar os códigos usados.

Passo 3: Escanear colunas de texto livre Aplicar detecção NLP em todas as colunas de texto livre. Revisar cada entidade detectada. Confirmar quais são PII reais.

Passo 4: Aplicar substituições Substituir PII confirmada no texto livre. Usar etiquetas claras como [PESSOA], [EMAIL] ou [LOCAL].

Passo 5: Verificar e documentar Amostrar 50–100 linhas da saída. Verificar entradas de texto livre manualmente. Escrever uma nota curta: ferramentas usadas, tipos de entidades encontradas, colunas processadas. Compartilhar com o conjunto de dados para revisão ética.

Isso transforma "excluímos a coluna de nomes" em um processo claro e documentado. Atende ao artigo 89 do RGPD e aos padrões de anonimização exigidos pela maioria dos comitês de ética. Visite nosso hub de documentação para guias relacionados.

Fontes

Pronto para proteger seus dados?

Comece a anonimizar PII com mais de 285 tipos de entidades em 48 idiomas.

About this page

We update this page when our platform or the law changes.

Read our founder note for how we work.

Each change shows up in the timestamp at the top.

Related reading

We follow these rules

  • GDPR (EU 2016/679).
  • ISO/IEC 27001:2022.
  • NIS2 (EU 2022/2555).
  • HIPAA safe harbor under 45 CFR § 164.514(b)(2).

Our promise

We do not sell your data.

We do not train models on your text.

We store your files in Germany.

You can delete your account at any time.

You own your work.

Where we run

Our servers live in Falkenstein, Germany.

We use Hetzner. They hold ISO 27001 certification.

All data stays in the EU.

Backups run every day.

Need help?

Email support@anonym.legal.

We reply within one business day.

How we test

We run a full check suite on every release.

Each surface gets its own sweep script and report.

Human reviewers spot-check the output each week.

We track recall and precision on a labelled set.

Bad runs block the deploy.

What we never do

  • We never sell your information to third parties.
  • We never train models on what you upload.
  • We never keep your work after you delete it.
  • We never share keys with any outside firm.
  • We never run ads inside the product.

Plans in plain words

We sell credits, not seats.

One credit covers one short job.

Long jobs use a few credits each.

You can top up at any time.

Unused credits roll over each month.

Read the plans page for current rates.

Who built this

A small team of engineers and lawyers built this.

We ship from Europe and work in the open.

Our founder note spells out why we started.

Where to start

How the parts fit

A browser add-on cleans text inside Chrome.

A Word plug-in handles drafts in Office.

A small desktop tool works on whole folders.

An agent protocol link feeds large models safely.

All four share one core engine and one rule set.

Words from our team

We started this work after a lunch about cookies.

One friend kept getting odd ads on her phone.

We asked why a court file leaked through a draft.

We sketched the first build on a napkin that week.

By month three we had a tiny demo for a friend.

She used it on her first case the next day.

Common questions we hear

Can the tool read scanned PDFs? Yes, with OCR.

Does it work on long files? Yes, in small chunks.

Can I roll my own rule set? Yes, save it as a preset.

Does it run offline? The desktop build runs offline.

Do you keep my files? No, the cloud build wipes after each run.

Will it learn from my work? No, we never train on inputs.

A short tour of the workflow

Upload a file or paste a snippet of prose.

Pick the entities you want gone from the draft.

Choose a method: replace, mask, hash, encrypt, or redact.

Press run and watch the side panel show each hit.

Skim the result and tweak any rule that misfired.

Save the cleaned file or send it to a teammate.