Como separar arquivos e contextos de clientes antes de usar IA

O erro nem sempre começa na resposta da IA. Muitas vezes, ele começa antes, quando arquivos de clientes diferentes entram na mesma pasta, no mesmo projeto ou na mesma conversa. Uma proposta comercial pode herdar o nome errado. Um resumo pode expor uma informação que pertencia a outro contrato. Uma instrução antiga pode continuar influenciando uma tarefa nova sem que ninguém perceba.

Este guia apresenta um método prático para separar contextos, arquivos e permissões por cliente antes de usar inteligência artificial. Ao final, você terá um pacote de contexto delimitado, uma cópia de trabalho com apenas os dados necessários e um registro capaz de mostrar o que entrou, o que saiu e quem aprovou o uso.

Resultado esperado

O resultado não é uma promessa de isolamento absoluto. É um fluxo verificável com quatro barreiras:

• um identificador único para cada trabalho;
• uma área separada para originais, cópias preparadas e saídas;
• uma lista explícita de dados permitidos e proibidos;
• uma revisão final que compara a entrega com a fonte autorizada.

O método é uma proposta editorial do Bastidores da IA. Ele traduz para a rotina princípios de finalidade, adequação, necessidade, segurança, prevenção e prestação de contas presentes na Lei Geral de Proteção de Dados Pessoais. A aplicação jurídica depende do caso, da organização e das obrigações contratuais.

Pré-requisitos

• uma tarefa concreta, com entrega e destinatário definidos;
• acesso autorizado aos arquivos originais;
• um local controlado para guardar documentos de trabalho;
• uma pessoa responsável por aprovar a entrada e a saída;
• as regras do contrato, da empresa e da ferramenta usada;
• uma alternativa sem IA quando os dados não puderem ser enviados com segurança.

Não coloque credenciais, chaves de API, senhas, códigos de recuperação ou segredos de cliente no pacote. Se a tarefa envolver dados pessoais sensíveis, decisões sobre direitos, saúde, crédito, emprego, segurança ou outra área regulada, procure a orientação especializada aplicável antes de continuar.

1. Dê um identificador ao trabalho

Comece pelo trabalho, não pela ferramenta. Crie um identificador que não dependa apenas do nome do cliente. Um formato simples combina cliente, projeto e data de referência, por exemplo cliente-alfa_catalogo_2026-08. O objetivo é impedir que “versão final”, “documentos novos” ou “cliente 2” virem nomes ambíguos.

Registre ao lado do identificador:

• qual entrega será produzida;
• quem receberá a entrega;
• quem autorizou o uso dos arquivos;
• qual ferramenta pode ser usada;
• qual é o prazo de retenção definido pela organização;
• qual evento encerra o trabalho.

Essa ficha evita que um arquivo correto seja usado para uma finalidade diferente da autorizada. Ter acesso técnico a um documento não significa ter permissão para empregá-lo em qualquer tarefa.

2. Separe originais, cópias e saídas

Crie três áreas distintas para cada identificador:

1. originais: materiais recebidos, preservados sem edição;
2. preparados: cópias reduzidas, limpas ou anonimizadas para a tarefa;
3. saídas: respostas da IA, versões revisadas e entrega aprovada.

Não trabalhe diretamente sobre o original. Se precisar remover colunas, ocultar nomes ou converter um arquivo, faça isso na cópia preparada. Mantenha a relação entre a cópia e sua origem por um nome estável, uma data ou um hash, conforme a capacidade da equipe. O guia Como preparar um documento antes de enviar para uma IA detalha a limpeza de propriedades, comentários, revisões e conteúdo oculto.

A separação também deve existir na ferramenta. Quando ela oferecer projetos, espaços de trabalho ou coleções, crie um contêiner dedicado. Se não houver esse recurso, use uma conversa nova e envie somente o pacote aprovado. Não presuma que iniciar outra mensagem dentro da mesma conversa elimina o contexto anterior.

3. Faça um inventário antes do envio

Liste cada arquivo candidato e decida sua situação. Uma tabela curta costuma ser suficiente:

Arquivo	Finalidade	Dados relevantes	Decisão	Motivo
briefing-v3.docx	Definir estrutura da entrega	Escopo e público	Preparar cópia	Contém comentários internos
contrato-assinado.pdf	Não é necessário para redigir	Assinaturas e dados cadastrais	Excluir do pacote	Não atende à finalidade
catalogo-publico.xlsx	Padronizar descrições	Atributos públicos	Usar cópia	Somente colunas autorizadas

O inventário força uma pergunta importante: este arquivo é necessário ou apenas está disponível? O princípio da necessidade da LGPD orienta limitar o tratamento ao mínimo necessário para a finalidade. Isso não produz uma regra automática para todos os casos, mas impede a prática comum de enviar uma pasta inteira por conveniência.

4. Prepare a cópia mínima

Abra uma cópia do material e remova o que não participa da tarefa. Dependendo do formato, verifique:

• nomes, e-mails, telefones, documentos e endereços;
• comentários, alterações controladas, notas do apresentador e células ocultas;
• abas, páginas, anexos e objetos incorporados sem relação com a entrega;
• metadados de autor, caminho, organização e histórico;
• fórmulas ou links que apontam para outra base;
• instruções antigas que conflitam com a finalidade atual.

Quando um identificador pessoal for necessário para manter a coerência, considere substituí-lo por um rótulo consistente, como Participante A ou Unidade 03. Guarde a tabela de correspondência fora do pacote enviado à IA e apenas se ela for realmente necessária ao processo.

Anonimização e pseudonimização não são sinônimos, e trocar um nome não garante que a pessoa deixou de ser identificável. Cargo, cidade, caso raro e datas podem reidentificar alguém em conjunto. Se a equipe não consegue avaliar esse risco, reduza o escopo ou não envie o material.

5. Defina permissões antes de conectar contas

Algumas ferramentas podem acessar pastas, e-mail, calendário, armazenamento em nuvem ou sistemas internos. Revise a permissão no ponto de origem. Prefira acesso somente leitura e limitado à pasta do trabalho. Evite conectar uma raiz inteira quando a tarefa depende de poucos arquivos.

Registre quem concedeu o acesso, para qual conta, com qual escopo e até quando. O guia de revisão de permissões para agentes de IA ajuda a distinguir leitura, escrita, exclusão e delegação. Uma integração com poder de alterar ou apagar arquivos exige um gate adicional e aprovação humana explícita.

O guia de segurança da informação da ANPD para agentes de tratamento de pequeno porte reúne medidas administrativas e técnicas, incluindo controle de acesso, gerenciamento de vulnerabilidades, segurança das comunicações e treinamento. Ele é uma orientação, não uma certificação automática do seu fluxo.

6. Monte um pacote de contexto explícito

Em vez de despejar documentos e esperar que a ferramenta deduza a tarefa, crie uma instrução de contexto com estes campos:

• objetivo: o que deve ser produzido;
• público: quem vai ler ou usar;
• fontes permitidas: nomes exatos dos arquivos preparados;
• fontes proibidas: outros clientes, conversas anteriores e conhecimento não confirmado;
• ações permitidas: resumir, classificar, comparar ou redigir;
• ações proibidas: enviar, publicar, excluir, inventar ou completar lacunas;
• formato da saída: estrutura, campos obrigatórios e marcação de incerteza;
• regra de parada: quando pedir esclarecimento em vez de inferir.

Uma regra útil é pedir que toda informação ausente seja marcada como não localizada na fonte autorizada. Isso não impede alucinações sozinho, mas cria um critério observável para a revisão.

7. Faça um teste com dados fictícios

Antes de enviar material real, teste o fluxo com um arquivo pequeno e fictício. Verifique se a ferramenta respeita o formato, se tenta buscar informação fora do pacote e se solicita permissões adicionais. Use nomes claramente inventados e não copie exemplos reais apenas mudando poucas letras.

O teste deve incluir pelo menos uma lacuna proposital. Se a instrução pede uma data que não existe no arquivo, a saída correta é declarar a ausência ou pedir esclarecimento. Se o sistema inventar uma data, ajuste a instrução ou interrompa o uso antes de trabalhar com dados do cliente.

O Playbook de medição do NIST AI RMF recomenda adaptar a avaliação ao contexto, documentar limitações e acompanhar respostas a riscos identificados. O Playbook é voluntário e não oferece um conjunto universal de testes.

8. Revise a saída contra o pacote aprovado

Não revise apenas se o texto ficou bom. Abra o inventário, as cópias preparadas e a saída lado a lado. Confirme:

• cada nome, data, número e compromisso na fonte autorizada;
• se apareceu informação de outro cliente ou projeto;
• se o modelo acrescentou fatos externos sem fonte;
• se dados removidos reapareceram por contexto anterior;
• se a saída contém instruções ocultas, comentários ou metadados;
• se o destinatário final pode acessar tudo o que será entregue.

Registre a decisão como aprovada, corrigida, escalada ou descartada. Para trabalhos recorrentes, salve o checklist e a instrução como versões controladas. Não transforme uma aprovação antiga em permissão permanente para novos dados.

9. Encerre o trabalho de forma verificável

Ao concluir, revogue acessos temporários, mova a versão aprovada para o destino correto e aplique a política de retenção da organização às cópias e saídas. Não apague originais ou registros que devam ser preservados por contrato, lei ou procedimento interno. Também não mantenha cópias “por precaução” sem prazo e finalidade.

O registro final pode conter identificador, arquivos utilizados, versão da instrução, ferramenta, data, revisor, decisão e local da entrega. Evite copiar para esse log o conteúdo sensível que o próprio processo tentou limitar.

Exemplo ilustrativo: dois catálogos de clientes diferentes

Uma pessoa precisa padronizar descrições de produtos para os clientes Alfa e Beta. Os dois enviaram planilhas parecidas, mas usam regras diferentes. Alfa permite título com material e cor. Beta proíbe inferir qualquer atributo ausente.

O fluxo cria dois identificadores e duas áreas separadas. Para Alfa, a cópia preparada contém somente código, material, cor e descrição atual. Para Beta, contém código e descrição, acompanhados da regra explícita de marcar atributos ausentes. Nenhuma planilha de contrato ou preço interno entra nos pacotes.

Primeiro, cada instrução é testada com produtos fictícios. Depois, as saídas reais são conferidas contra a planilha do respectivo cliente. Se uma descrição de Alfa aparecer no trabalho de Beta, a execução é descartada e o contexto é reiniciado. O erro não é corrigido apenas no texto final, porque indica falha na separação do processo.

Este é um exemplo ilustrativo, não uma captura de tela nem prova de resultado. A estrutura precisa ser adaptada às ferramentas, contratos e riscos de cada equipe.

Checklist antes de enviar arquivos à IA

• O trabalho tem identificador, finalidade, destinatário e responsável?
• Originais, cópias preparadas e saídas estão separados?
• Cada arquivo foi inventariado e justificado?
• A cópia contém somente os dados necessários?
• Comentários, propriedades, abas ocultas e anexos foram revisados?
• As permissões estão limitadas ao escopo e ao tempo necessários?
• A instrução declara fontes e ações permitidas e proibidas?
• Um teste fictício comprovou o tratamento de lacunas?
• A saída será comparada com a fonte autorizada por uma pessoa responsável?
• Há uma regra de retenção e encerramento do acesso?

Erros comuns

• Separar só pelo nome do arquivo: nomes parecidos ainda podem ser enviados ao projeto errado.
• Confiar em uma conversa nova: a configuração da ferramenta e as fontes conectadas também precisam ser verificadas.
• Enviar a pasta inteira: disponibilidade não demonstra necessidade.
• Trocar nomes e chamar de anonimização: outros atributos podem identificar pessoas.
• Usar acesso amplo por conveniência: conectores devem receber o menor escopo compatível com a tarefa.
• Revisar apenas a redação: mistura de contexto pode produzir texto fluido e ainda assim incorreto ou indevido.
• Manter tudo para sempre: cópias e saídas precisam de finalidade e prazo definidos.

Limites deste método

Pastas separadas, projetos e checklists reduzem erros operacionais, mas não provam isolamento técnico nem conformidade legal. O provedor pode ter políticas próprias de retenção, treinamento, administração e registro. A organização precisa verificar contrato, configuração, região, controles corporativos e obrigações setoriais.

O perfil do NIST para riscos de IA generativa orienta considerar contexto de uso, ciclo de vida e riscos específicos. Ele não substitui análise jurídica, segurança da informação ou avaliação do fornecedor.

A pergunta de encerramento é concreta: se esta saída trouxer uma informação de outro cliente, você consegue provar de onde ela veio, impedir o envio e corrigir a causa? Se a resposta for não, o processo ainda precisa de separação antes de ganhar escala.

Fontes oficiais consultadas em 21 de agosto de 2026

• Lei nº 13.709/2018, Lei Geral de Proteção de Dados Pessoais, para princípios de finalidade, adequação, necessidade, segurança, prevenção e responsabilização.
• ANPD, Guia orientativo sobre segurança da informação para agentes de tratamento de pequeno porte, para controles administrativos e técnicos de segurança.
• NIST AI RMF Playbook, Measure, para avaliação adaptada ao contexto, documentação de limitações e acompanhamento de riscos.
• NIST AI 600-1, perfil de riscos para IA generativa, para contexto de uso, ciclo de vida e riscos específicos de sistemas generativos.