Quais dados não devem ir para a IA sem checagem
O que eu faria se um funcionário enviasse um contrato para a IA e dissesse: “É só texto.” Eu primeiro mapearia o caminho dos dados: de onde veio o documento, quem verá o histórico de execução, o que vai para a nuvem e quando tudo é apagado.
O erro que eu eliminaria primeiro: “A gente só não manda o passaporte inteiro” não é um controle se o texto ainda tem e-mail, número de contrato, endereço e uma combinação rara de atributos que identifica a pessoa com facilidade.
O que preparar e que resultado esperar
- Resultado: Você tem um conjunto mínimo de dados, permissões separadas e um caminho claro para entrada ou ações perigosas.
- Crie um registro de cenários de IA com campos para dados, provedor, finalidade, retenção, acesso, owner e risco.
- Mantenha os dados de origem e os direitos de acesso separados do resultado para poder verificar o que a proteção de dados no processo de IA fez.
- Teste prompt injection, instrução maliciosa em anexo, record_id alheio e resposta vazia da ferramenta.
Torne impossível uma ação perigosa sem approval
- Monte um mapa de dados
Para cada etapa de IA, liste campos, fonte, finalidade, retenção, região e o papel que pode vê-los. Não escreva “todos os dados do cliente”.
Проверьте: Cada campo tem um motivo e o excedente pode ser removido.
Если не сработало: Comece com dados de teste ou desidentificados.
- Limite as credentials
Em Credentials/Permissions, conceda read em vez de write, uma pasta em vez de todo o drive, um projeto em vez de todo o CRM. Use uma chave separada para cada workflow.
Проверьте: Revogar uma chave não abre acesso ao restante do sistema.
Если не сработало: Verifique permissões em uma conta sandbox.
- Filtre a entrada antes da IA
Antes do modelo, remova senhas, tokens, números completos de cartão e dados pessoais desnecessários. Coloque Human approval antes de send, refund, delete e update permissions.
Проверьте: O log não tem segredos nem campos sensíveis de que a tarefa não precisa.
Если не сработало: Substitua o valor por uma máscara ou um id interno.
- Monte casos de ataque e de falha
Teste instruções em anexo, spoofing de record_id, tentativa de ler pasta alheia, excesso de limite e resposta vazia. Cada checagem deve terminar em stop, retry ou handoff.
Проверьте: Um cenário perigoso nunca chega a uma ação real.
Если не сработало: Revogue direitos de escrita até corrigir a causa raiz.
Um registro de dados antes da primeira solicitação
Crie uma tabela para data_type, source, purpose, legal_basis, allowed_destination, retention_days, access_role e deletion_owner. Marque à parte passaportes, dados bancários, contratos, correspondência e preços internos.
Minimização não é só mascarar um nome. Antes da IA, remova campos de que a tarefa não precisa, substitua o resto por CLIENT_001 e mantenha a tabela de mapeamento separada. A resposta não deve permitir reconstruir valores originais pelo prompt.
- Não dê a um workflow acesso a uma pasta inteira por um único documento.
- Verifique o contrato do fornecedor, a região de armazenamento, o treinamento com seus dados e a exclusão.
Como verificar se o mascaramento funciona
Crie um documento de teste com marcadores deliberados PASSPORT_TEST_001, CARD_TEST_002 e EMAIL_TEST_003. Inspecione o payload antes do envio, o payload do provedor e os logs. Se um marcador passar além da etapa local, o mascaramento está no lugar errado ou só se aplica ao texto visível.
Um registro de dados antes da primeira integração
Crie `data_type`, `source`, `purpose`, `legal_basis`, `allowed_destination`, `retention_days`, `access_role` e `deletion_owner`. Marque à parte passaporte, contrato, dados bancários, correspondência e preços internos. A IA recebe só os campos necessários para a tarefa específica.
Guarde chaves de API em `Credentials`, não em `Set`, `Code` nem em URL. No n8n self-hosted, defina uma chave de criptografia separada e limite o salvamento de execution data ao necessário para revisão de incidentes.
N8N_ENCRYPTION_KEY=<long_secret_key>
EXECUTIONS_DATA_SAVE_ON_SUCCESS=none
EXECUTIONS_DATA_PRUNE=true
EXECUTIONS_DATA_MAX_AGE=168Checagens de mascaramento com marcadores de teste
Crie um documento de teste com `PASSPORT_TEST_001`, `CARD_TEST_002` e `EMAIL_TEST_003`. Verifique o payload antes do modelo, o payload do provedor e os logs de erro. Se um marcador passar além da etapa local, o mascaramento é aplicado tarde demais.
O mesmo valor de origem deve receber o mesmo token dentro de uma execução, e a tabela de mapeamento deve viver separada, criptografada e com TTL. Não envie dados brutos para Slack ou e-mail pelo ramo de erro.
O que deixar para o modelo e o que remover antes
| Critério | Pergunta | Bom sinal |
|---|---|---|
| Entrada | O que exatamente entra na proteção de dados no processo de IA? | Crie um registro de cenários de IA com campos para dados, provedor, finalidade, retenção, acesso, owner e risco. |
| Ação | O que o sistema pode fazer sozinho? | Somente ações pré-listadas, sem acesso a toda a conta |
| Verificação | Como saber que o resultado é aceitável? | Teste prompt injection, instrução maliciosa em anexo, record_id alheio e resposta vazia da ferramenta. |
| Falha | Para onde vão os casos pouco claros? | Pare o workflow, revogue o acesso à ferramenta, mantenha um log técnico sem segredos e revise as últimas ações. |
O que deve mudar depois da configuração
Você tem um conjunto mínimo de dados, permissões separadas e um caminho claro para entrada ou ações perigosas.
Onde a segurança quebra: no acesso, não no modelo
Tratar o system prompt como proteção contra entrada prejudicial.
Registrar dados pessoais e segredos por completo.
Usar uma única chave de admin em todas as integrações.
Não ter um owner que revogue o acesso durante um incidente.
Quando você precisa de uma revisão de segurança separada
Você precisa de um especialista quando dados médicos, financeiros ou pessoais são processados, há vários provedores ou um regulador impõe exigências.
O que checar antes de conectar dados reais
Dá para enviar e-mails de clientes para a IA?
Somente depois de checar contrato, política de retenção, região e a necessidade de cada campo. Para testes, prefira texto desidentificado.
Basta não mostrar um segredo na resposta?
Não. Um segredo não deve entrar na entrada, no contexto, nos logs nem em ferramentas que não precisam dele.
E se a resposta do agente parecer suspeita?
Pare o workflow, revogue o acesso, mantenha um log técnico sem PII e revise as últimas ações.
Qual o primeiro controle a colocar?
Least privilege e confirmação obrigatória antes de qualquer ação difícil de desfazer.
