Vazamento de dados em prompts e uploads: a falha “mais humana” da IA

A cena é familiar e perigosa… um indivíduo abre uma ferramenta pública de IA para “economizar tempo” e cola um contrato, uma planilha, um bilhete, um registro, um pedaço de código… às vezes até uma credencial. É rápido, parece inofensivo e impulsivamente se torna rotina. 

O problema é que o prompt (e o arquivo anexado) deixa de ser apenas um texto: torna-se um canal de vazamento de informações, muitas vezes com boas intenções.

O que mais aparece vazando (e por que isso importa)?

Em relatórios recentes, a Netskope aponta que, quando há envio de dados para apps de IA em violação de política, o que mais aparece é:

👉 código-fonte (representando “quase metade” das violações),

👉 dados regulados (ex.: pessoais/financeiros/saúde),

👉 propriedade intelectual,

👉 e “passwords/keys” (senhas/chaves), muitas vezes junto do próprio código.

Ou seja: a “maior dor” não é um ataque sofisticado. É o cotidiano. É gente boa, competente, tentando resolver um problema rápido  e, sem perceber, empurrando informação sensível para fora do controle da empresa.

Onde isso “estoura” na ISO/IEC 27001:2022

Na prática, esse cenário cai direto no colo de controles como:

• A.8.12 Prevenção de Vazamento de Dados (DLP): a norma 27001 exige que a organização tenha medidas para reduzir o risco de divulgação não autorizada. Sem controles de prevenção/monitoramento (ou sem governança de fluxo), a IA pública pode se tornar um “atalho” para vazamentos.
• E antes de falar sobre bloqueio ou alerta, surge a questão básica: o que é sensível aqui? É por isso que a discussão sobre classificação/rotulagem (que apoia qualquer estratégia prática) muitas vezes se torna o “gargalo invisível”; se a empresa não classifica bem, não pode aplicar consistentemente nenhuma regra. Em auditorias e revisões, o que geralmente falta não é retórica, mas prova operacional.

Em auditorias e revisões, o que normalmente fica faltando não é discurso  é prova operacional.

A evidência que quase sempre falta (e o auditor sente de longe)

Para esse risco específico (prompts e uploads), a evidência “boa” costuma ser bem objetiva:

1. Classificação aplicada também a prompts/arquivos (não só em documentos formais)
2. Regras claras (bloqueio e/ou alerta) para tipos sensíveis: dados regulados, segredos, código crítico
3. Exceções aprovadas (registradas, justificadas e revisadas)  e não “exceções por cansaço”

Sem isso, a política existe… mas a operação deixa “buracos” exatamente onde as pessoas mais usam IA.

E no setor automotivo: por que isso pega em TISAX

Para qualquer pessoa nesse ecossistema automotivo, tudo isso se torna ainda mais sensível porque o TISAX existe precisamente para demonstrar um nível definido de segurança da informação com base nos requisitos do VDA ISA. E o importante é: você trabalha com o TISAX com base no questionário do VDA ISA e nos princípios altamente autoritativos e padronizados delineados por modelos orientados por padrões de melhores práticas internacionais, como o ISO/IEC 27001. 

Implicações realistas: se sua função envolve dados de clientes, fornecedores, projetos, protótipos, incidentes, integrações, código e documentação técnica, um único comando “inocente” pode se tornar um grande ruído na avaliação porque o tópico aborda o controle sobre a confidencialidade e a transmissão de informações.

Onde isso entra na ISO/IEC 27005: risco que muda o jogo

A ISO/IEC 27005 é o “lado do risco” do SGSI: ela dá orientação para gerenciar riscos de segurança da informação para apoiar um ISMS baseado na 27001.

E aqui está o ponto: IA generativa mudou o caminho do dado. O que antes saía por e-mail, pendrive ou compartilhamento, agora também sai por:

👉 prompt,

👉 upload,

👉 colar/arrastar,

👉 extensão do navegador,

👉 conta pessoal logada.

Se isso não está mapeado como cenário de risco (com probabilidade/impacto e tratamento), a empresa passa a “gerenciar o passado”, enquanto o vazamento acontece no presente.

O “antídoto” não é proibir IA é colocar trilho

Proibir, na prática, empurra o uso para a sombra. O caminho mais maduro costuma ser:

• Definir o que pode e o que não pode ir para prompts/uploads (com exemplos do dia a dia: contrato, planilha, log, código, credencial)
• Oferecer caminhos aprovados (ferramentas/contas corporativas, fluxos permitidos)
• Aplicar prevenção de vazamento (DLP) com bom senso: alertar primeiro, bloquear o que for crítico e recorrente
• Treinar com foco em situações reais (não em teoria)
• Gerir exceções do jeito certo: aprovação, registro e revisão

Isso reduz risco sem matar produtividade e, principalmente, gera evidência auditável.

Como a Wiseplan Group ajuda a resolver isso?

Na Wiseplan Group, a gente trata esse problema do jeito que ele realmente é: uma falha prática, do cotidiano, que precisa de governança + processo + controle.

Com uma equipe especializada, ajudamos sua organização a:

• estruturar classificação e regras aplicáveis a prompts/arquivos,
• implementar controles de prevenção/alerta alinhados ao A.8.12 da ISO/IEC 27001:2022,
• preparar evidências e rotinas compatíveis com TISAX/VDA ISA (especialmente em ambientes automotivos),
• e incorporar esse novo canal (IA) no ciclo de gestão de riscos recomendado pela ISO/IEC 27005.

Porque, no fim, o vazamento mais comum hoje não vem de um hacker genial  vem do Ctrl+C / Ctrl+V no lugar errado. E isso dá para evitar, sem travar o negócio.