Resposta curta: dados públicos e internos podem entrar num LLM quase sempre, dados confidenciais apenas num ambiente coberto por cláusulas contratuais de não treino e não retenção, e dados restritos nunca entram num prompt, exceto sob forma mascarada. A regra de funcionamento é a exposição mínima necessária: envie ao modelo apenas o que ele precisa para responder. Os números de 2026 explicam a urgência: cerca de 35% dos dados empresariais que os colaboradores colocam em ferramentas de IA estão classificados como sensíveis, contra 27% um ano antes e 11% dois anos antes.
O verdadeiro problema não é a tecnologia, é o uso que já está a acontecer
Na maioria das organizações o debate sobre «se adotar IA» decorre na administração enquanto os colaboradores já estão a colar. Os inquéritos de 2026 indicam que cerca de 80% dos colaboradores usam ferramentas de IA que o departamento de TI não aprovou, e que cerca de 63% deles já colaram material sensível – código-fonte, fichas de clientes, dados financeiros ou documentos de estratégia – numa conta pessoal de chatbot.
O detalhe preocupante é a titularidade da conta. Quando a colagem parte de uma conta pessoal, fica fora de qualquer controlo organizacional: sem registo, sem controlo sobre a retenção e sem forma de apagar depois. Segundo os mesmos dados, cerca de 82% das colagens em ferramentas de IA têm origem em contas pessoais.
A fatura: as organizações com utilização não autorizada de IA muito disseminada absorvem em média cerca de 670 000 dólares em custos adicionais de violação, e 97% das organizações que reportaram uma violação relacionada com IA não tinham controlos de acesso à IA dignos desse nome. Ao mesmo tempo, apenas cerca de 37% das organizações têm alguma política para detetar ou gerir esse tipo de utilização.
A conclusão prática: uma proibição geral não funciona, apenas empurra a utilização para a clandestinidade. O que funciona é uma política de classificação clara, associada a uma alternativa aprovada que seja verdadeiramente cómoda.
Os quatro níveis de classificação e o que é permitido em cada um
A maioria das políticas de classificação empresarial usa quatro níveis: público, interno, confidencial e restrito. A tabela abaixo traduz esses níveis numa decisão prática perante um modelo de linguagem:
| Nível | Exemplos | O que é permitido com um LLM |
|---|---|---|
| Público | Conteúdos de marketing, especificações de produto publicadas, relatórios divulgados | Permitido em qualquer ferramenta, incluindo as públicas |
| Interno | Procedimentos, apresentações internas, documentação de processos | Permitido apenas numa ferramenta empresarial aprovada |
| Confidencial | Dados de clientes, tabelas de preços, código-fonte, previsões | Só onde se apliquem cláusulas de não treino e não retenção |
| Restrito | Dados de saúde, salários, identificadores pessoais, segredos de negócio | Nunca entra num prompt. Apenas sob forma mascarada ou resumida |
A distinção mais importante é entre confidencial e restrito, e é aí que a maioria das organizações se confunde. Dados confidenciais que vazam causam dano comercial, pelo que um bom contrato é suficiente. Dados restritos causam dano regulatório e pessoal, e aí um contrato não chega, porque a exposição não pode ser desfeita depois.
As duas técnicas que resolvem a maior parte dos casos
A anonimização remove ou oculta de forma irreversível os identificadores pessoais. Use-a quando não for preciso ligar a resposta a uma pessoa concreta, por exemplo ao analisar tendências em tickets de apoio.
A pseudonimização substitui identificadores por tokens reversíveis. O nome de um cliente passa a CLIENTE_4471 e, quando a resposta regressa, o sistema faz a correspondência inversa. É a técnica que permite trabalhar com dados reais de clientes sem enviar nomes para fora.
A regra que cobre ambos os casos: a exposição mínima necessária. Envie ao modelo apenas o que é preciso para responder e retire por completo os itens classificados dos prompts externos. Na maioria dos casos verifica-se que o modelo precisa da estrutura e do contexto, não dos nomes.
O que tem de constar no contrato com o fornecedor de IA
A diferença entre «os dados confidenciais são permitidos» e «não são» decide-se quase sempre no contrato, não na tecnologia. Se um colaborador cola um input confidencial num LLM público, esses dados podem ser registados, retidos ou usados para melhorar o serviço, salvo obrigação contratual em contrário do fornecedor. Três cláusulas a verificar:
| Cláusula | O que estabelece | Porque importa |
|---|---|---|
| Sem treino | Os seus inputs não são usados para treinar modelos | Sem ela, os seus dados podem reaparecer na resposta de outro utilizador |
| Sem retenção ou retenção limitada | Os prompts são apagados ao fim de um período definido | Reduz a janela de exposição caso o fornecedor sofra um incidente |
| Local de tratamento e subcontratantes | Onde os dados são tratados e quem mais lhes toca | Determina que regulamentos se aplicam e o que pode ser transferido |
Como implementar isto sem um programa de seis meses
Passo 1: um inventário vivo. Mapeie os tipos de dados sensíveis por classe – identificadores pessoais, dados de saúde, propriedade intelectual e dados financeiros – e atribua a cada um um responsável, um sistema de origem e uma política de retenção. Não é um exercício teórico: é a lista em que assentará cada decisão futura.
Passo 2: uma alternativa aprovada e cómoda. Antes de proibir o que quer que seja, disponibilize uma ferramenta empresarial que funcione mesmo. Se a alternativa aprovada for lenta ou desajeitada, os colaboradores regressam à conta pessoal e a política fica no papel.
Passo 3: aplicação na camada dos dados. Oculte automaticamente os identificadores pessoais à entrada do prompt e aplique a mesma verificação à saída. Uma aplicação que depende apenas da formação dos colaboradores não sobrevive ao primeiro trimestre.
Passo 4: uma regra que toda a gente memoriza. «Se não o enviaria por e-mail a outro cliente, não o cole num chat.» Não é juridicamente preciso, mas é compreendido e aplicado, e é isso que conta.
A ligação à sua base de conhecimento: a partir do momento em que passa da colagem manual para um sistema que responde a partir dos seus próprios documentos, a classificação torna-se um filtro técnico em vez de uma regra de comportamento. Abordámos isso no guia sobre como construir uma base de conhecimento RAG empresarial, em particular na secção sobre aplicar permissões no momento da recuperação.
E se está a pesar um investimento em infraestrutura contra poupanças em ferramentas, passe os números pela economia unitária: o custo de um único incidente cobre normalmente anos de ambiente aprovado. O acompanhamento completo deste percurso enquadra-se na nossa prática de implementação de IA.
Perguntas frequentes
Podem introduzir-se dados de clientes no ChatGPT?
Não numa conta pessoal nem numa versão pública. Os dados de clientes são confidenciais, pelo que só podem ser introduzidos num ambiente empresarial com cláusulas contratuais de não treino e não retenção. Sem esse contrato, introduza apenas uma versão mascarada em que nomes e identificadores foram substituídos por tokens.
Qual é a diferença entre dados confidenciais e dados restritos?
Uma fuga de dados confidenciais causa dano comercial, pelo que um contrato sólido com o fornecedor é suficiente. Uma fuga de dados restritos – saúde, salários, identificadores pessoais – causa dano regulatório e pessoal que não pode ser desfeito. Por isso os dados restritos nunca entram num prompt.
Uma proibição geral de ferramentas de IA é solução?
Não. Os inquéritos de 2026 mostram que cerca de 80% dos colaboradores já usam ferramentas não aprovadas e que cerca de 82% das colagens vêm de contas pessoais. Uma proibição sem uma alternativa aprovada e cómoda apenas desloca a utilização para uma zona sem registo e sem controlo.
Qual é a diferença entre anonimização e pseudonimização?
A anonimização remove identificadores de forma irreversível e serve para análise de tendências. A pseudonimização substitui-os por tokens reversíveis, para que a resposta possa ser ligada de volta à pessoa em causa. Use a segunda quando precisa de agir sobre um cliente concreto.
Que cláusulas têm de constar num contrato com um fornecedor de IA?
Três: nenhuma utilização dos seus inputs para treinar modelos, eliminação ou retenção limitada dos prompts dentro de um período definido, e uma definição clara do local de tratamento e dos subcontratantes que tocam nos dados.
Continuar a ler
Critérios de aceitação de uma funcionalidade de IA – o que definir antes de construir, depois de fixadas as regras sobre dados.