- Comece pela classificação de dados (público, interno, confidencial, sensível) e traduza isso em regras de prompt
- Liste casos de uso permitidos e proibidos por área (jurídico, RH, financeiro, marketing, suporte)
- Padronize revisão humana: o usuário é responsável por checar fatos, fontes e números antes de publicar/decidir
- Aprovação de ferramentas: o padrão é “não aprovado” até passar por segurança, privacidade e contrato
- Registre riscos e exceções: trilha mínima de auditoria para incidentes e aprendizado organizacional
1) Defina objetivo e escopo (o que a política cobre)
Declare, em linguagem simples, para quem vale (CLT, PJ, estagiários, terceiros), onde se aplica (notebook corporativo, celular pessoal, conta gratuita) e quais tipos de IA entram (chatbots, geração de imagem, copilotos de código, transcrição, automação). Evite “vale para tudo”: isso vira letra morta.
2) Classifique dados e transforme em regras de prompt
Crie uma tabela de classificação de dados (ex.: Público, Interno, Confidencial, Sensível/LGPD). Para cada nível, escreva: (a) pode ou não pode entrar em ferramentas externas, (b) precisa anonimizar, (c) precisa contrato/DPA e conta corporativa. Se você não tiver um inventário perfeito, comece pelo básico: dados pessoais, dados financeiros, segredos comerciais e credenciais nunca entram “in natura”.
3) Estabeleça usos permitidos x proibidos (por risco)
Separe o que é baixa criticidade (rascunho, brainstorming, reescrita) do que é alta criticidade (decisão de crédito, diagnóstico, demissão, aconselhamento jurídico final). O erro comum é proibir tudo; o acerto é permitir com controle. Se algo impacta pessoa (direitos, dinheiro, saúde, emprego), exija revisão e registro.
4) Crie padrão de revisão humana e verificação de fatos
A regra prática: IA pode sugerir; humano decide. Defina como checar: pedir evidências, conferir números em fonte primária, validar citações (sem assumir que existem), e manter rascunhos com marcação do que foi gerado. Onde a consequência é alta (jurídico/finanças/RH), trate saída da IA como hipótese, não como referência.
5) Aprovação de ferramentas e modelos (lista branca)
Mantenha uma lista de ferramentas aprovadas e uma de proibidas/pendentes. Para aprovar, peça um “mínimo viável” de informações: onde dados são processados, política de retenção, controles de acesso, SSO/MFA quando houver, logs, e possibilidade de desativar treinamento com dados do cliente (quando aplicável). Quando você não tiver certeza, registre a incerteza e restrinja o uso a dados públicos.
6) Regras para prompts, anexos e integrações (o que não pode vazar)
Escreva exemplos concretos do que não entra: CPF, dados de saúde, folha de pagamento, contratos completos, chaves de API, base de clientes, prints de sistemas internos. Inclua um checklist de anonimização antes de colar texto. Integrações (plugins, conectores, automações) merecem regra própria, porque ampliam o risco de exfiltração sem o usuário perceber.
7) Diretrizes de autoria, propriedade intelectual e plágio
Defina: (a) quando o conteúdo precisa citar fontes, (b) como lidar com textos “parecidos demais” (revisão e reescrita), (c) como tratar assets de imagem/áudio (uso comercial, direitos, consentimento). Sem inventar promessas: a política deve dizer o que a empresa espera, não garantir que o modelo sempre será original.
8) Treinamento rápido, canal de dúvidas e incidentes
Treinamento que funciona cabe em 30–45 minutos e inclui exemplos do dia a dia da empresa. Defina um canal para: dúvidas de uso, pedido de aprovação de ferramenta, e reporte de incidente (ex.: envio acidental de dado). Incidente não pode virar caça às bruxas; precisa virar melhoria de processo.
9) Auditoria mínima: logs, amostragem e revisão trimestral
Você não precisa monitorar tudo para começar, mas precisa de rastreabilidade em áreas sensíveis. Recomende: registrar ferramenta usada, finalidade, tipo de dado (nível), e quem revisou. Revise a política periodicamente, porque modelos, planos e integrações mudam rápido.
Modelo enxuto de política (estrutura pronta para copiar)
Se você quer algo que realmente seja lido, mire em 1–3 páginas. Uma estrutura que costuma funcionar:
1) Finalidade e escopo; 2) Definições (IA generativa, dado pessoal, dado sensível); 3) Princípios (minimização de dados, segurança, transparência); 4) Regras por classificação de dados; 5) Usos permitidos/proibidos; 6) Revisão e responsabilização; 7) Ferramentas aprovadas e processo de exceção; 8) Incidentes e sanções; 9) Atualizações.
Tabela prática: o que pode entrar no prompt (por nível de dado)
Abaixo vai um mapa conservador. Ajuste ao seu apetite de risco e aos contratos que você tem (por exemplo, conta corporativa com controles e cláusulas específicas pode mudar o “permitido com condição”).
| Tipo de dado | Exemplos | Pode usar em IA externa? | Condição mínima |
|---|---|---|---|
| Público | Texto do site, releases, manuais já publicados | Sim | Sem anexar informações internas por engano; revisar saída |
| Interno (não sensível) | Processos genéricos, templates, e-mails sem dados pessoais | Depende | Preferir ferramenta aprovada; evitar anexos; revisar |
| Confidencial | Estratégia, precificação, pipeline de vendas, contratos (sem dados pessoais) | Em geral, não | Somente em ferramenta aprovada com controles; minimização/trechos; registro |
| Pessoal (LGPD) | Nome + e-mail, histórico de cliente, currículo | Evite | Anonimizar/pseudonimizar; finalidade clara; ferramenta aprovada; necessidade real |
| Sensível (LGPD) / Alta criticidade | Saúde, biometria, religião, dados de menores, folha/benefícios | Não | Exceção raríssima com validação jurídica/segurança e controles robustos |
| Credenciais e segredos técnicos | Senhas, tokens, chaves de API, configs internas | Não | Nunca; usar cofres de segredo e práticas de DevSecOps |
Onde as empresas mais erram (e como corrigir sem paralisar o time)
Erro 1: política “anti-IA” que o time ignora. Correção: permita usos de baixo risco, com regra de dados clara.
Erro 2: confiar em resposta bonita como se fosse fato. Correção: rotina de verificação (fontes, números, citações) e checklists por área.
Erro 3: liberar plugin/conector sem avaliação. Correção: lista branca e processo simples de aprovação.
Erro 4: esquecer terceiros. Correção: a política precisa cobrir fornecedores e freelancers, inclusive em dispositivos pessoais quando acessam dados corporativos.
Perguntas frequentes
A política deve proibir ChatGPT/Claude/Gemini no trabalho?
O que escrever na política sobre LGPD, sem virar texto jurídico inútil?
Como lidar com alucinação (respostas erradas) dentro da política?
Preciso registrar todo prompt e toda resposta dos funcionários?
Leia também
Como anonimizar dados antes de usar ChatGPT, Claude ou Gemini (2026): checklist sem vazar informação
Guia prático para anonimizar e minimizar dados antes de colar textos em ChatGPT, Claude ou Gemini. Checklist, exemplos do que remover, tabela de riscos e perguntas frequentes para evitar vazamentos e exposição de clientes, contratos e dados pessoais.
Ler →
Como evitar alucinação em IA (2026): checklist prático para checar fatos, fontes e números
Guia direto ao ponto para reduzir alucinação em ChatGPT, Claude e Gemini: prompts, checagem de fontes, validação de números e um fluxo simples de auditoria antes de publicar.
Ler →
Como escolher sua assinatura de IA em 2026 (Plus, Pro, Advanced, Team ou grátis): guia prático sem arrependimento
Guia direto para decidir entre plano grátis e assinatura de IA em 2026. Compare por tarefa, privacidade, limites, trabalho em equipe e custo-benefício, com checklist e perguntas-chave para não pagar à toa.
Ler →
Como usar IA para responder RFP (proposta comercial) em 2026 — sem vazar dados e sem prometer o que não entrega
Guia prático para usar ChatGPT/Claude/Gemini em respostas de RFP e propostas comerciais: workflow, prompts, tabela de checagem, riscos (LGPD) e revisão final.
Ler →