Política de IA no Trabalho: Guia das 8 Seções Essenciais

O problema não é a IA, é a ausência de regras para ela

Toda semana chega um pedido parecido: “queremos ativar o Copilot para o time todo”. A pergunta que raramente vem junto é outra: “e qual é a nossa política de uso de IA?”. Na maioria das vezes, a resposta é silêncio, ou pior, um documento genérico baixado da internet e nunca adaptado à realidade da empresa.

Isso é um problema concreto, não teórico. Sem uma política formal, cada colaborador decide sozinho o que é aceitável colar num prompt. Alguns vão perguntar ao ChatGPT como corrigir um e-mail. Outros vão colar uma planilha de folha de pagamento inteira para “resumir os dados”. A ferramenta não distingue as duas situações, quem distingue é a política que a empresa não escreveu.

Esse uso não autorizado de ferramentas de IA fora do controle da TI tem nome: shadow AI. E ele se comporta exatamente como shadow IT sempre se comportou, com um agravante. Um arquivo compartilhado por engano num link do SharePoint pode ser revogado. Um dado colado num modelo público de IA generativa não. Uma vez que a informação sai do perímetro da empresa e entra no processamento de um serviço externo, não existe botão de desfazer. O dado pode ter sido usado para treinamento, pode ter ficado em log, pode ter sido processado num país sem os mesmos requisitos de proteção de dados que a empresa segue.

Uma política de IA no trabalho existe para fechar essa lacuna antes que ela vire incidente. Não é burocracia, é o documento que dá ao time confiança para usar IA sem transformar cada prompt numa aposta de compliance.

As oito seções que toda política de IA precisa ter

Uma política de IA robusta não é uma lista de proibições. É um framework que explica o raciocínio, define limites claros e cria processo para o que ainda não foi previsto. Oito seções cobrem isso de forma completa.

1. O porquê

Abra a política explicando a razão de a empresa adotar IA e por que isso importa para quem vai usá-la no dia a dia. Essa seção reduz resistência, porque explica o raciocínio de negócio, não só a regra. Serve também como sumário executivo do restante do documento, com um resumo de uma frase para cada seção seguinte.

2. Ferramentas aprovadas

Aqui a política lista taxativamente quais ferramentas de IA podem ser usadas, como o time solicita acesso e, principalmente, o que acontece com quem usa uma ferramenta fora dessa lista. É a seção que ataca o shadow AI diretamente.

Vale detalhar um processo de aprovação de novas ferramentas, com um canal claro para o colaborador pedir avaliação de uma IA que descobriu e quer usar, em vez de simplesmente instalar uma extensão de navegador não gerenciada. Isso transforma curiosidade em pedido formal, não em risco silencioso.

3. Diretrizes de uso

Comece com um ou dois casos de uso bem definidos, com o fluxo de trabalho descrito do início ao fim. Por exemplo, autorizar o time financeiro a usar Copilot para projeções orçamentárias com base em planilhas já classificadas como internas, ou liberar o time de marketing para gerar rascunhos de conteúdo com um agente do Copilot Studio treinado nas diretrizes de marca da empresa.

Essa seção deve ser tratada como documento vivo. Conforme novos casos de uso são testados e aprovados, entram na lista, com um processo definido para comunicar as equipes afetadas e agendar o treinamento correspondente.

4. Ética

O uso de IA generativa traz debates éticos que a política precisa endereçar antes que virem problema público. Os pontos que costumam faltar em políticas genéricas são:

• Transparência: quando e como a empresa informa a clientes que um conteúdo foi gerado ou auxiliado por IA.
• Responsabilidade humana: exigência de revisão humana (human-in-the-loop) antes de qualquer saída de IA virar decisão, comunicação externa ou entrega ao cliente.
• IA como ferramenta, não substituto: deixar explícito que a IA apoia o trabalho, não substitui julgamento profissional nem elimina posições por si só.
• Equidade: protocolos para reduzir viés em triagem de currículos, avaliação de desempenho ou qualquer uso que envolva pessoas.
• Privacidade e minimização de dados: proibição explícita de expor CPF, endereço, dados bancários, informações de saúde ou qualquer dado pessoal identificável a ferramentas de IA sem controle de acesso adequado.
• Direito de recusa: garantir que colaboradores possam optar por não usar IA em determinadas tarefas sem represália.

A escolha da ferramenta em si também é uma decisão ética. Um fornecedor que não deixa claro onde processa os dados, ou que usa prompts de clientes para treinar modelos públicos por padrão, é um risco que a política precisa antecipar, não descobrir depois.

5. Governança de dados

Esta seção conecta a política de IA ao framework de governança de dados que a empresa já deveria ter, ou precisa construir junto. Ela define o que pode e o que não pode alimentar a ferramenta, como os dados restritos são armazenados e isolados, e qual o modelo de acesso, tanto por colaborador quanto pela própria ferramenta.

Em ambientes Microsoft 365, essa é a seção que mais depende de arquitetura real, não só de texto. O Copilot não é um modelo genérico solto na internet, ele opera dentro do tenant boundary da organização e respeita as permissões já existentes no Microsoft Graph. Isso é uma vantagem de segurança, mas também um risco escondido: se a permissão de um site do SharePoint está mal configurada, com links “qualquer pessoa com o link” ou herança de permissão nunca revisada, o Copilot vai encontrar e resumir esse conteúdo exatamente como qualquer colaborador com acesso encontraria.

Por isso, antes de ativar Copilot em escala, a governança de dados precisa incluir uma auditoria de permissionamento no SharePoint e no OneDrive, o uso de rótulos de confidencialidade do Microsoft Purview Information Protection e políticas de Prevenção de Perda de Dados (DLP) que bloqueiem o compartilhamento de conteúdo sensível com ferramentas de IA não aprovadas. A política precisa citar essas ferramentas pelo nome e descrever quem é responsável por mantê-las configuradas.

6. Compliance

Em setores regulados, o uso incorreto de IA pode gerar multas relevantes, além de dano reputacional. A política precisa detalhar as barreiras que mantêm a empresa em conformidade. Um exemplo direto: dados de saúde protegidos sob regulações como a LGPD, ou informações equivalentes a PHI sob HIPAA em operações internacionais, não podem ser processados por nenhuma ferramenta de IA sem um acordo contratual específico de tratamento de dados com o fornecedor.

Esta seção também deve reiterar as medidas disciplinares para quem viola a política, incluindo desligamento em casos graves, e recomenda-se envolver o time jurídico, o responsável por compliance e RH na redação, não deixar essa parte só com a TI.

7. Boas práticas

Independente do nível de familiaridade do time com IA, uma lista de boas práticas de uso, incluindo orientação de prompting, melhora a adoção e reduz erro. Isso inclui orientar o colaborador a sempre indicar contexto e fonte no prompt, verificar a saída antes de usar, e nunca tratar uma resposta de IA generativa como fato verificado sem checagem, especialmente em números, citações e referências legais, onde alucinações são mais comuns e mais custosas.

8. Treinamento

A última seção define a cadência de treinamento obrigatório sobre as ferramentas aprovadas e sobre a própria política. Também é o espaço para indicar trilhas de aprofundamento para quem quer ir além do mínimo exigido. Treinamento sem repetição perde efeito rápido, o ideal é revisão pelo menos semestral, e sempre que uma nova ferramenta ou caso de uso for aprovado.

Por que o Microsoft 365 exige uma seção própria na política

Empresas que já operam em Microsoft 365 têm uma vantagem real na hora de escrever a política de IA: parte da governança já existe na plataforma, só precisa ser referenciada e ativada corretamente. Vale a política citar explicitamente:

• Políticas de DLP do Microsoft Purview aplicadas a Teams, Exchange e SharePoint, bloqueando o compartilhamento de dados classificados como confidenciais com endpoints de IA externos.
• Rótulos de sensibilidade aplicados a documentos e sites, que o Copilot respeita ao decidir o que incluir numa resposta.
• Insider Risk Management para monitorar padrões anômalos de uso de IA, como um volume incomum de prompts contendo dados financeiros.
• Governança específica para agentes criados no Copilot Studio, incluindo quem pode publicar um agente e qual conector de dados ele pode acessar.

Ignorar essa camada técnica na política é o erro mais comum que vemos: escrever regras de comportamento sem amarrar controles técnicos que as tornem verificáveis. Uma política que diz “não compartilhe dados sensíveis com IA” sem uma política de DLP correspondente é uma intenção, não um controle.

Trate a política como código, não como PDF assinado uma vez

A política de IA precisa evoluir junto com os casos de uso. Toda vez que uma nova ferramenta é aprovada, um novo departamento adota IA ou um novo requisito regulatório aparece, o documento precisa ser revisado, versionado e recomunicado. Empresas que tratam essa política como estática costumam descobrir, meses depois, que metade do time já está usando uma ferramenta que nunca foi formalmente aprovada, simplesmente porque o processo de solicitação era lento ou inexistente.

A Trinapse ajuda organizações a estruturar essa política junto com a arquitetura técnica que a sustenta, desde a auditoria de permissionamento no SharePoint até a configuração de DLP e a governança de agentes no Copilot Studio, para que a regra escrita e o controle técnico andem juntos.