
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

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

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:
Artigos relacionados


Política de IA na empresa: uma página pode impedir o dado de sair

SAFE ou mútuo conversível: a dívida muda quem assume o risco

Wellhub libera mais R$ 100 milhões — recebíveis viram garantia de expansão

Falha no Cisco SD-WAN já dá acesso de administrador — não há atalho

CropX compra a SCIO e tenta ligar a recomendação agrícola ao resultado da safra
Assine nossa newsletter
Receba as últimas notícias sobre Web3, IA e cripto diretamente no seu e-mail.