By · Last updated 2026-06-05

Voltar ao BlogSegurança de IA

O Problema do PII em Capturas de Tela...

Slack, Teams, Jira e e-mail recebem regularmente capturas de tela contendo PII de clientes.

June 5, 20266 min de leitura
screenshot PIIinternal toolsGDPR compliancedata leakageJira Slack security

O Ponto Cego DLP que Você Ainda Não Auditou

As ferramentas DLP monitoram o tráfego de rede, anexos de e-mail e transferências de arquivos. Elas detectam planilhas com colunas SSN. Elas sinalizam e-mails com listas de clientes. Elas bloqueiam uploads com prontuários médicos.

Elas não detectam capturas de tela.

Uma captura de tela é um arquivo de imagem. Os dados pessoais que ela contém são representados como pixels. Eles não são armazenados como texto. Motores DLP que buscam padrões de dados pessoais não encontram nada.

Todos os dias, funcionários colam capturas de tela no Slack, Jira, Teams e cadeias de e-mail. Nenhum alerta DLP é disparado.

Como Capturas de Tela Espalham Dados Pessoais no Trabalho

O trabalho remoto e híbrido tornou o compartilhamento de capturas comum. As ferramentas internas se enchem delas todos os dias.

Os membros da equipe compartilham capturas para dar contexto rápido:

  • Agentes de suporte compartilham visualizações de contas de clientes com líderes de equipe.
  • Desenvolvedores compartilham logs de erros que incluem dados inseridos por usuários.
  • Gestores de contas enviam registros CRM para dar contexto às equipes financeiras.
  • Administradores de TI capturam visualizações do sistema para documentar configurações para prestadores.
  • Equipes de produto compartilham visualizações de dashboards em atualizações para partes interessadas.

Cada anexo pode conter informações pessoais. Uma captura de conta de cliente contém nome, e-mail, status e endereço de cobrança. Um arquivo de log de erros pode incluir nomes, endereços ou números de telefone inseridos por usuários. Uma captura de registro CRM contém o perfil completo da conta. Um arquivo de dashboard pode mostrar identificadores de usuário em rótulos de gráficos.

O Problema de Controle de Acesso

Compartilhar capturas de tela também cria um problema de controle de acesso.

A maioria das organizações aplica controles de acesso baseados em funções nos sistemas de produção. Um agente de suporte vê apenas os registros de sua fila. Um prestador vê apenas os arquivos de projeto atribuídos a ele.

Quando um agente captura um registro de cliente e cola em um canal do Slack com prestadores, o controle de acesso é contornado. O prestador obtém dados pessoais que não poderia acessar pelos caminhos normais. O DPA que rege o trabalho dos prestadores pode não cobrir essa transferência. Os direitos RGPD do cliente podem não se aplicar a esse prestador.

Esse contorno é um problema nos termos do Artigo 5(1)(f) do RGPD. Ele abrange integridade e confidencialidade. Também pode criar problemas de alinhamento com o Artigo 28 se os prestadores receberem dados pessoais sem os DPA adequados. Consulte nosso guia de conformidade RGPD para uma lista de verificação das obrigações do Artigo 28.

Detecção de Dados Pessoais em Imagens como Proteção Técnica

A proteção técnica para exposição de dados pessoais baseada em capturas é OCR mais detecção NLP. Os passos são simples.

  1. O funcionário captura uma tela de uma interface de cliente.
  2. Antes de compartilhar: faz upload da captura em uma ferramenta de detecção.
  3. A ferramenta extrai o texto visível via OCR.
  4. O NLP identifica entidades de dados pessoais no texto.
  5. O funcionário vê um relatório: «Esta captura contém: [nome do cliente], [endereço de e-mail], [ID da conta].»
  6. O funcionário então redige os dados pessoais, restringe o escopo de compartilhamento ou prossegue com uma razão escrita.

Isso não bloqueia todo o compartilhamento. Mostra as informações pessoais antes de elas se moverem. As pessoas podem então fazer escolhas informadas. Veja como isso se encaixa na sua pilha de proteção na página de segurança.

Caso de Uso: Política de Capturas no Jira para um Helpdesk SaaS

O helpdesk de uma empresa SaaS usava o Jira para registrar problemas de contas. Os arquivos anexados a esses tickets continham dados pessoais de usuários. Especificamente:

  • Endereços de e-mail de usuários de interfaces de gestão de contas.
  • Detalhes de planos de assinatura.
  • Valores e datas de cobrança.
  • Dados de pagamento parciais em alguns casos.

Uma auditoria RGPD encontrou 847 tickets do Jira criados em 18 meses. Todos continham anexos com dados pessoais. O Jira estava acessível a todos os 200 engenheiros. Alguns eram prestadores sem DPA para registros de cobrança de clientes.

Etapas de remediação:

  1. Auditoria retroativa: detecção de dados pessoais em todos os anexos existentes. 312 tickets sinalizados para revisão do DPO.
  2. Limpeza de tickets: 89 tickets tiveram arquivos ocultados antes de serem reaneados.
  3. Mudança de processo: novo fluxo de trabalho exigindo verificação de dados pessoais antes de anexar no Jira.
  4. Treinamento: sessão de 15 minutos para toda a equipe do helpdesk.

Resultados após 90 dias:

  • Incidentes de dados pessoais no Jira: queda de 90 por cento.
  • Incidentes restantes: casos em que a equipe prosseguiu com uma razão diagnóstica escrita.
  • Escopo do DPA: atualizado para reduzir a exposição desnecessária de dados pessoais a prestadores.

Os 312 tickets históricos constituíram uma constatação de conformidade. A queda de 90 por cento serviu como prova de remediação na resposta à auditoria.

Integrando a Revisão de Capturas nos Fluxos de Trabalho da Equipe

Para organizações que desejam controles de dados pessoais sem desacelerar as operações, existem várias opções.

Opção leve: Uma ferramenta de navegador que os funcionários usam antes de colar no Slack ou Jira. Arraste a captura, obtenha um relatório de dados pessoais em cinco segundos, depois prossiga ou redija.

Hook no Jira ou ServiceNow: Detecção que é executada antes de os arquivos chegarem aos tickets. Funciona como uma varredura antivírus antes de um upload de arquivo.

Bot do Slack: Um bot que recebe uploads de capturas em canais selecionados. Ele executa a detecção de dados pessoais. Ele publica uma resposta em thread com as entidades detectadas. Isso torna as informações pessoais visíveis sem bloquear o fluxo de trabalho.

Norma de equipe mais amostragem: Uma verificação automatizada semanal. Amostre 10 por cento das capturas nas ferramentas de colaboração. Execute a detecção. Reporte os resultados ao líder da equipe. Isso cria responsabilidade sem bloquear nenhum fluxo de trabalho.

Para registros RGPD: o controle de dados pessoais em capturas conta como uma «medida organizacional» nos termos do Artigo 32. Documente a proteção — política mais ferramenta técnica. Adicione prova de uso. Isso satisfaz a regra de responsabilidade do Artigo 5(2). Consulte nossa página de conformidade e a entrada do glossário para o Artigo 32.

Quer ver como a anonym.legal lida com isso para sua equipe? Visite nossa página de planos ou leia a declaração do fundador sobre de-identificação.

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.