1 em 29 prompts na América Latina expõe dados — o risco nasce no uso comum

|Autor: Equipe editorial da QUASA|6 min de leitura
1 em 29 prompts na América Latina expõe dados — o risco nasce no uso comum

Uma reportagem de 9 de outubro de 2026 da CNN Brasil divulgou um dado da Check Point Research: em julho, 1 em cada 29 prompts analisados na América Latina, cerca de 3,5%, apresentava alto risco de exposição de dados sensíveis. Foi a maior proporção entre as regiões comparadas. O risco começa em tarefas comuns, quando alguém inclui informações corporativas em um pedido a uma ferramenta de IA generativa.

Na análise da Check Point, a taxa global de julho foi de 1 em cada 36 prompts e 88% das organizações que usavam regularmente essas ferramentas registraram ao menos um prompt de alto risco; a empresa resume a distinção: “These figures describe routine use rather than attacks”. A classificação indica exposição potencial no conteúdo enviado, não uma contagem de acessos indevidos ou ataques confirmados. Para decidir o que pode entrar em um prompt, o ponto de partida é o tipo de dado exigido pela tarefa.

O que a proporção regional mede

Comparação da Check Point Research mostra proporção maior de prompts de alto risco na América Latina do que na América do Norte.

No relatório integral da Check Point Research, que cobre julho e agosto de 2026, a comparação de prompts apresentada para julho registra 1 em cada 29 na América Latina, 1 em cada 32 na América do Norte, 1 em cada 40 na Europa e 1 em cada 41 na Ásia-Pacífico. A unidade da medição é o prompt observado nas redes corporativas monitoradas pela empresa. Não é a parcela de trabalhadores que vazaram dados nem a de empresas que sofreram uma invasão.

Um pedido pode ser classificado como arriscado pelo conteúdo que leva à ferramenta, mesmo que ninguém tenha demonstrado acesso posterior a esse conteúdo. A diferença importa: uma investigação de incidente precisa apurar o destino dos dados e quem pôde consultá-los; a medição de prompts identifica uma exposição potencial no momento do envio. O levantamento, portanto, permite avaliar a frequência desse comportamento no universo monitorado, mas não calcular quantos vazamentos efetivamente ocorreram.

Também há uma consequência para a leitura do recorte regional. A posição da América Latina descreve a proporção encontrada naquele conjunto de tráfego corporativo, durante o período medido. Ela não significa que toda empresa da região tenha a mesma taxa. Para uma equipe, a pergunta útil passa a ser mais específica: qual informação, dentro de uma tarefa legítima, está sendo entregue à IA sem ser necessária para obter a resposta?

Que dados podem entrar no pedido

A classificação abaixo é uma proposta de regra de entrada para uso corporativo, não uma política publicada pela Check Point. Antes de enviar um pedido, convém separar o objetivo da tarefa dos dados usados para executá-la. Uma ferramenta aprovada pode ajudar a revisar um texto público, mas sua aprovação não torna automaticamente apropriado colar nela uma base de clientes ou uma negociação em andamento.

  • Público: conteúdo já divulgado oficialmente, como uma descrição de produto publicada. Pode fornecer contexto a uma ferramenta autorizada, desde que o pedido não acrescente detalhes internos.
  • Interno: procedimentos de equipe, mensagens operacionais e indicadores ainda não divulgados. Seu uso depende das permissões da organização e da ferramenta; inclua apenas o trecho necessário e retire identificadores dispensáveis.
  • Confidencial: propostas comerciais, preços negociados, código privado, bases de clientes e resultados ainda não publicados. Não envie o material bruto a uma ferramenta de uso geral. Quando a tarefa permitir, substitua-o por categorias, valores fictícios ou uma descrição agregada.
  • Restrito: senhas, chaves de API, credenciais e dados pessoais detalhados. Esses elementos não devem aparecer no prompt; uma tarefa que dependa deles precisa seguir o fluxo autorizado para seu tratamento.

A decisão depende tanto do conteúdo quanto do ambiente. Um campo genérico como “valor da compra” serve para pedir uma fórmula; os registros reais que preenchem esse campo exigem outra autorização. Da mesma forma, resumir uma cláusula sem identificar as partes é diferente de enviar o contrato completo, com nomes e condições negociadas. A regra curta é usar informação real somente quando ela for necessária para a tarefa e permitida naquele serviço.

Pedidos cotidianos que carregam dados demais

Exemplo de prompt corporativo substitui dados identificáveis de clientes por categorias genéricas antes do envio à IA.

Os exemplos seguintes são hipotéticos. Em cada caso, o objetivo profissional pode ser mantido enquanto se reduz o conteúdo fornecido à IA. A alternativa proposta ajuda a formular ou estruturar o trabalho; o processamento dos registros reais continua no ambiente autorizado pela organização.

  • Base de clientes: evite “Resuma esta lista com nomes, contatos e histórico de compras”. Prefira pedir uma estrutura de resumo usando categorias e dados fictícios. Se o objetivo for conhecer o comportamento da base real, produza antes os totais permitidos no sistema que guarda esses registros.
  • Negociação: evite colar um contrato completo para melhorar a redação de uma cláusula. Prefira apresentar uma versão genérica da cláusula, sem nomes, preços negociados, datas específicas ou outros elementos que revelem a operação.
  • Erro técnico: evite enviar código acompanhado de chave de API, endereço interno e dados de produção. Prefira reproduzir o erro com um exemplo mínimo, credenciais removidas e valores inventados que preservem a lógica necessária à explicação.

Retirar apenas o nome não basta quando o restante do pedido permite reconhecer a pessoa ou a negociação. Cargo, cidade, valor exato e uma circunstância rara podem se combinar de modo identificável. O mesmo cuidado vale para anexos e para mensagens anteriores da conversa: apagar um dado da frase mais recente não o remove do contexto que já foi enviado.

Quando a anonimização deixa de resolver

Uma substituição funciona quando a resposta depende da estrutura do problema, e não da identidade dos registros. Para pedir uma fórmula, por exemplo, nomes genéricos de campos e linhas inventadas podem preservar o raciocínio. Para melhorar um aviso, bastam o público, a finalidade e um trecho sem informação protegida. Esse tipo de redução mantém a tarefa compreensível sem transferir a base original.

Já uma análise que depende dos valores exatos, do histórico individual ou de detalhes contratuais perde utilidade se tudo isso for trocado por exemplos. Nessa situação, a saída é executar a análise no ambiente que a empresa autorizou para aqueles dados, ou usar uma ferramenta cuja permissão cubra expressamente esse tratamento. O ganho de conveniência de colar o conteúdo em outra conversa não altera a classificação da informação.

Para o funcionário, essa fronteira aparece antes do botão de envio: se o pedido só funciona com registros identificáveis, segredos técnicos ou termos confidenciais, ele exige um fluxo autorizado para esses dados. É nessa decisão rotineira de entrada que a exposição apontada pelo levantamento pode ser evitada.

Leia também:

Compartilhar:

Assine nossa newsletter

Receba as últimas notícias sobre Web3, IA e cripto diretamente no seu e-mail.

0