---
title: "Política de uso de IA para desenvolvedores"
description: "Política de uso de IA escrita é texto que o modelo pode ou não seguir. Por que as regras absolutas precisam virar hook, e como saber se ele está ligado."
url: https://franklinfreitas.com/blog/regra-escrita-nao-e-regra-politica-de-ia
---

[Blog](https://franklinfreitas.com/blog/) [Governança de IA](https://franklinfreitas.com/blog/governanca-de-ia/) Regra escrita não é regra: por que a política de IA virou mecanismo

Governança de IA · 1 de setembro de 2026 · 13 min de leitura

# Regra escrita não é regra: por que a política de IA virou mecanismo

Uma política de uso de IA escrita num documento, num CLAUDE.md ou nas instruções da organização é texto que o modelo pode ou não seguir. Funciona quase sempre, e quase sempre não basta para segredo e dado pessoal. A regra só existe quando vira mecanismo: um programa que roda em pontos fixos do fluxo e decide sem depender do modelo.

## Em resumo

- Instrução entra no contexto do modelo como mais um trecho. Ele pondera, quase sempre segue, e quando não segue ninguém fica sabendo.
- Instrução orienta, skill ensina, hook roda. Só o hook decide sem depender do modelo.
- A skill viaja para onde o hook não existe. Uma regra que parece mecânica e não roda é pior do que nenhuma.
- Poucas proibições absolutas bloqueiam. O resto pede aprovação ou orienta, para o time não aprender a contornar.
- Todo mecanismo diz, ao abrir a sessão, se está pronto ou não operante. Ausência silenciosa é falha.

## O que acontece com uma regra que só existe como texto?

Ela entra no contexto do modelo como mais um trecho a considerar, e o modelo decide, a cada passo, quanto peso ela tem. Quase sempre ele segue. Às vezes não segue, e ninguém fica sabendo quando. No [texto que abre esta série](https://franklinfreitas.com/blog/governanca-de-ia-caminho-estreito-ate-producao), chamamos isso de problema do "quase sempre": aceitável para estilo de código, inaceitável para segredo, dado pessoal e produção.

Vale entender o caminho que a regra faz, porque ele explica por que reescrevê-la não resolve. Um arquivo de instruções do repositório, como o CLAUDE.md do Claude Code, é carregado no início de cada sessão e passa a fazer parte das instruções de sistema do modelo, como a própria Anthropic descreve. As instruções da organização seguem o mesmo caminho. A partir daí, a regra disputa atenção com tudo o que entra depois: o pedido de quem está usando, o código aberto, a saída de cada comando, o conteúdo de cada página consultada. Numa sessão longa, ela fica cada vez mais longe do que o modelo está fazendo agora.

Três situações comuns fazem uma regra escrita falhar sem que ninguém tenha errado de propósito.

- O pedido contrário. Alguém escreve "só para testar, deixa a chave no arquivo". O modelo pondera a regra contra um pedido explícito e recente, e o pedido costuma ganhar.
- A distância. Numa sessão de horas, com dezenas de arquivos lidos e comandos executados, a instrução do começo é um trecho entre muitos. Ela não some, mas pesa menos.
- O texto de fora. Uma página, um comentário de pull request, o README de uma dependência ou a resposta de um conector trazem uma instrução escondida. É a injeção de instrução, que a OWASP pôs no topo da sua lista de riscos de aplicações com modelos de linguagem, edição 2025.

A OWASP é direta sobre o terceiro caso: técnicas como busca em base própria e ajuste fino não eliminam a injeção de instrução. A recomendação é tratar privilégio em código, fora do modelo, e exigir aprovação humana para ações de alto risco. O perfil de IA generativa do NIST, de julho de 2024, vai na mesma direção ao registrar que esses sistemas ampliam a superfície de ataque justamente por serem vulneráveis a esse tipo de manipulação. Nenhum dos dois sugere escrever a instrução com mais força.

Suponha uma regra que o modelo segue em 99 de cada 100 ocasiões, uma taxa que ninguém mediu e que parece generosa. Num time em que cada pessoa dispara centenas de ações do assistente por semana, essa regra falha algumas vezes por semana. E a falha não deixa rastro: nenhum aviso, nenhum registro, nada que diga qual das centenas de ações foi a que escapou. Para estilo de código, isso é irrelevante. Para um segredo escrito num arquivo que vai ao repositório, uma vez basta.

O reflexo comum é reforçar o texto: maiúsculas, "IMPORTANTE", "NUNCA", a mesma regra repetida em três lugares. Isso pode aumentar a adesão, mas não muda a natureza da regra. Ela continua sendo um pedido ao modelo e continua falhando em silêncio. Para amanhã, liste as regras que o seu time deu ao assistente e responda duas perguntas para cada uma. Se o modelo ignorar isto, o que acontece? E quem fica sabendo?

## Qual a diferença entre instrução, skill e hook?

Instrução orienta, skill ensina, hook roda. As três vivem no mesmo ecossistema do assistente de código, e por isso costumam ser confundidas, mas só uma delas decide sem depender do modelo.

O que éQuem decide se a regra valeOnde ela valeComo falhaInstruçãoTexto carregado no contexto no início da sessão: o arquivo de instruções do repositório, as instruções da organizaçãoO modelo, a cada passoOnde o texto for carregadoEm silêncioSkillUm pacote de instruções e procedimentos que o assistente carrega quando o assunto apareceO modelo, que decide carregar e seguirEm qualquer superfície que carregue o texto, inclusive onde os scripts dela não existemEm silêncio, às vezes afirmando o contrárioHookUm programa da empresa que o assistente executa em pontos fixos do fluxoO programaSó onde o mecanismo está instalado e ligadoDe forma visível, se for desenhado para isso

Em uma frase

Hook: Um ponto do fluxo do assistente de IA (antes de usar uma ferramenta, depois de usá-la, ao abrir a sessão) em que um programa da empresa roda e pode permitir, pedir aprovação ou bloquear, independentemente do que o modelo decidiu.

Os pontos fixos são poucos e previsíveis. Antes de o assistente usar uma ferramenta, o hook vê a intenção: o comando que vai rodar, o arquivo que vai ser escrito, o conteúdo proposto. Depois, vê o resultado: o arquivo como ficou no disco, a saída do comando. Ao abrir a sessão, confere se tudo de que precisa está presente. Em alguns assistentes há também um ponto no momento em que a pessoa envia o pedido. No Claude Code, por exemplo, os dois primeiros se chamam PreToolUse e PostToolUse, e o da abertura, SessionStart. A Anthropic descreve os hooks como ações disparadas automaticamente em pontos específicos do fluxo de trabalho.

O que muda tudo é quem decide. Antes de uma ação, o hook pode deixar seguir, pedir aprovação da pessoa ou bloquear, e essa decisão vem do programa, não do raciocínio do modelo. O modelo não consegue argumentar com um hook. Pode reescrever a ação, e é isso que se quer: quando o bloqueio devolve a regra e a correção, o assistente refaz o trabalho do jeito certo, em vez de tentar variantes até uma passar. Um hook pode até consultar outro modelo para avaliar uma ação que depende de interpretação, mas esse modelo só estima; quem aplica a política é o código. Separar quem estima de quem decide é o assunto do próximo texto da série.

A skill merece atenção à parte, porque é a peça mais fácil de confundir com mecanismo. Ela é texto, e texto viaja. Uma skill escrita para o assistente no terminal aparece também no chat do navegador, numa máquina nova, em outro projeto. Os hooks, os scripts empacotados com ela e as variáveis de configuração da empresa não viajam junto. A regra prática que usamos cabe em quatro palavras: skill viaja, hook não.

Isso não diminui a skill. Ela é o melhor lugar para explicar por que uma regra existe e como fazer certo, e um assistente que entende o porquê erra menos e dispara menos bloqueios. O texto faz o modelo acertar na primeira vez; o mecanismo segura quando ele não acerta. Os dois juntos funcionam. O que não funciona é um no lugar do outro.

## Por que uma regra que parece mecânica e não roda é pior do que nenhuma?

Porque muda o comportamento de quem confia nela. Sem regra nenhuma, o time sabe que está por conta própria e toma cuidado. Com uma regra que afirma proteção automática, o time relaxa, e o modelo também, porque ele lê o texto que diz que há proteção e segue adiante como se houvesse. O risco não cresce por causa da regra; cresce pela confiança que ela cria.

Imagine uma skill que descreve os cuidados de uma operação sensível e afirma que parte deles é "mecânica", aplicada por um programa e não pelo modelo. Na máquina onde o pacote completo está instalado, a frase é verdadeira. Aberta numa superfície onde só o texto chegou, a skill continua afirmando a mesma coisa, e agora é falsa. O modelo, lendo que há proteção, não toma o cuidado que tomaria sem ela. Se nada de ruim acontecer, é porque faltava algum outro acesso, e não porque a proteção funcionou. Isso é falhar seguro por sorte.

O NIST tem nome para a metade humana desse problema. No perfil de IA generativa, a configuração entre pessoa e IA aparece como risco próprio desses sistemas, por levar ao viés de automação e à dependência excessiva: a pessoa passa a confiar no sistema além do que ele entrega. Uma regra que afirma proteção inexistente produz exatamente isso, nos dois lados da conversa.

Há dois jeitos de o mecanismo não rodar, e confundi-los manda o diagnóstico para o lugar errado.

1. O mecanismo não está ali. A superfície não carrega hooks, o pacote não foi instalado, o script não existe naquela máquina. Não adianta conferir rede ou credencial, porque o problema é a superfície.
2. O mecanismo está ali e não decide. O programa existe, mas falta a chave que ele usa, falta o interpretador que o roda, ou o serviço que ele consulta não responde. Muitos mecanismos, nesse caso, deixam a ação seguir sem avaliação, e se isso acontece em silêncio o efeito é o mesmo de não ter mecanismo.

A correção é escrever toda afirmação de proteção como condicional à superfície. A skill que depende de um hook, de um script ou de uma configuração abre com um teste: o arquivo existe, a variável está definida, o programa responde. Se o teste falhar, ela diz isso a quem está usando e instrui o assistente a não improvisar um caminho alternativo. Um substituto improvisado entrega a operação sem as proteções que a skill prometia. Sem o filtro, não há máscara; sem o hook, não há bloqueio.

## O que vale transformar em mecanismo e o que pode continuar texto?

Poucas proibições absolutas bloqueiam. O resto pede aprovação ou só orienta. A tentação, quando se descobre o hook, é transformar a política inteira em bloqueio, e esse é o jeito mais rápido de ensinar o time a contornar o mecanismo.

O critério que usamos tem três perguntas. O erro é irreversível ou expõe algo que não volta? A regra vale sem depender do contexto? Existe uma correção clara para quem for bloqueado? Quando as três respostas são sim, a regra bloqueia. Quando o erro tem conserto ou a regra depende de contexto, ela pede aprovação. Quando é convenção, continua texto.

NívelQuando usarExemplos genéricosO que o mecanismo fazBloquearProibição absoluta: o erro não tem volta ou expõe algo que não se recolheSegredo escrito em código ou configuração versionada; escrita direta no banco de produção; dado de negócio apagado em definitivoImpede a ação e devolve a regra e a correção, para o assistente refazerPedir aprovaçãoRegra que depende de contexto, ou erro que tem consertoEnvio direto ao branch principal; mudança num servidor de produção; dado pessoal sem máscara numa saídaMostra o motivo, deixa a pessoa decidir e registra a decisãoOrientarConvenção, estilo, preferência do timePadrão de nomes, organização de pastas, formato das mensagens de commitNada além do texto, que continua útil

Por que tão poucas no primeiro nível? Porque cada bloqueio que dispara sem motivo custa confiança. O time barrado várias vezes numa tarde por algo que não era problema aprende que o mecanismo erra e passa a procurar o jeito de desligá-lo. A falha de um bloqueio rigoroso demais não aparece como incidente; aparece como gente trabalhando fora do assistente, ou pedindo para tirá-lo. O nível intermediário existe para isso. Ele interrompe, explica e deixa a pessoa decidir, sem tirar dela o controle.

Quem escolhe o nível de cada regra não é quem está incomodado com ela numa terça-feira. É a diretoria, e a escolha fica escrita no próprio código do mecanismo, versionada, mudando só por pedido de alteração revisado. A política deixa de ser um documento que alguém interpreta e passa a ser um arquivo com histórico: qual regra, em que nível, desde quando e por decisão de quem.

O que continua texto não é regra de segunda classe. É contexto: por que a empresa não escreve no banco de produção, qual é o caminho certo para guardar um segredo, como o time prefere organizar o código. Bem escrito, esse texto faz o assistente acertar na primeira tentativa e reduz as vezes em que o mecanismo precisa agir. Para amanhã, pegue a política de uso de IA do seu time e separe as frases em três pilhas: bloquear, pedir aprovação e orientar. Se a primeira pilha tiver mais do que um punhado de itens, ela provavelmente está misturando proibição com preferência.

## Como saber se o mecanismo está ligado?

Ele precisa dizer, toda vez que a sessão abre, se está pronto ou se não está operante. Um mecanismo que pode estar desligado sem ninguém perceber vale o mesmo que uma regra escrita, com a desvantagem de parecer outra coisa.

A ausência costuma ser silenciosa por desenho. Um hook que não encontra a chave, o interpretador ou o serviço que consulta tem duas opções: bloquear tudo ou deixar passar. Bloquear tudo, para o time inteiro, numa queda de um serviço de terceiro produz a reação previsível, que é alguém desligar o mecanismo, e isso é pior do que a queda. Deixar passar é razoável desde que seja dito em voz alta, para quem está usando, no momento em que acontece. A escolha entre as duas posturas, falhar aberto ou fechado, é da diretoria e vale para todos de uma vez. O que não se aceita é a terceira opção, a de falhar aberto em silêncio.

Na prática, a abertura da sessão roda uma conferência curta, e o resultado aparece para a pessoa antes do primeiro pedido.

- O programa do mecanismo existe nesta superfície.
- O interpretador de que ele precisa está instalado, na versão certa.
- A chave ou configuração de que ele depende está presente, sem que o valor apareça na tela.
- A postura de falha está declarada: o que acontece se o serviço consultado não responder.
- O veredito sai numa linha só: pronto, ou não operante e por quê.

Ligado não é o mesmo que funcionando. A prova de que o mecanismo barra é um conjunto de casos de teste que deveriam ser bloqueados, como um segredo falso num arquivo ou uma escrita proibida num comando, rodados contra o mecanismo na CI do próprio pacote. Se um caso que deveria ser barrado passar, o pacote não é publicado. É a pergunta de três partes da série inteira aplicada ao primeiro controle: o que ele barra, como se prova que barra e o que acontece quando falha.

E cada decisão do mecanismo deixa registro: o bloqueio, o pedido de aprovação, a ação que seguiu sem avaliação, o erro. É essa trilha que permite responder, depois, se o mecanismo estava agindo na semana em que algo deu errado. Sem ela, a única evidência é a memória de quem estava na sessão.

Resta uma pergunta que o hook sozinho não responde: o que impede uma pessoa de desligá-lo na própria máquina? A resposta é a configuração gerenciada pela empresa, assunto de outro texto desta série. Antes dela vem o que o mecanismo faz a cada ação, que é o tema do próximo: como um guardrail decide entre o risco, a regra da casa e o que a pessoa pediu.

## Perguntas frequentes

Um CLAUDE.md bem escrito não basta?

Para orientar, basta, e vale caprichar nele. Para proibição absoluta, não. O CLAUDE.md é carregado no contexto do modelo como parte das instruções de sistema, e o modelo pondera essas instruções contra o pedido da pessoa, o código e o conteúdo que lê. Quase sempre segue. Segredo, dado pessoal e produção pedem uma regra que não dependa disso: um hook, que roda em pontos fixos do fluxo e decide independentemente do modelo.

O que é um hook, em termos simples?

É um programa da empresa que o assistente de IA executa sozinho em momentos fixos: antes de usar uma ferramenta, depois de usá-la e ao abrir a sessão. Antes de uma ação, ele pode deixar seguir, pedir aprovação ou bloquear. Depois, pode olhar o resultado e mandar corrigir. A decisão é do programa, não do modelo, que não consegue argumentar com ele.

O modelo consegue contornar um hook?

Não pela conversa: a decisão é do programa. Mas um hook só vê as ações para as quais foi registrado. Se ele olha comandos e escrita de arquivos e o assistente consegue ler um arquivo sensível por outra ferramenta, essa leitura não passa por ele. Por isso o desenho de um hook começa pela lista do que ele cobre e do que não cobre, e o que ele não cobre vai para outra camada.

Quantas regras devem bloquear?

Poucas: as proibições absolutas, em que o erro não tem volta, a regra vale em qualquer contexto e existe uma correção clara. Segredo escrito em código e escrita direta no banco de produção são exemplos típicos. O resto pede aprovação ou só orienta. Bloqueio demais ensina o time a contornar o mecanismo, e a falha aparece como gente trabalhando fora dele.

Então a skill não serve para nada?

Serve, e muito. A skill ensina o porquê de cada regra e o jeito certo de fazer, e um assistente que entende o motivo erra menos e esbarra menos no bloqueio. O problema é tratá-la como proteção. Ela é texto, viaja para superfícies onde o hook não existe e continua dizendo o que diz. Toda afirmação de proteção numa skill precisa ser condicional: só vale onde o mecanismo roda.

Como sei se o mecanismo está funcionando na máquina de alguém?

Pela linha que ele mostra ao abrir a sessão: pronto, ou não operante e por quê. Se ela não aparece, considere que não está. Funcionar também se prova: casos de teste que deveriam ser barrados rodam na CI do próprio pacote, e um caso que passa impede a publicação. E cada bloqueio, pedido de aprovação ou ação sem avaliação fica registrado numa trilha.

## Fontes

1. [Using CLAUDE.md files: Customizing Claude Code for your codebase](https://www.claude.com/blog/using-claude-md-files) · Claude (Anthropic) · 25 de novembro de 2025
2. [Enabling Claude Code to work more autonomously](https://www.anthropic.com/news/enabling-claude-code-to-work-more-autonomously) · Anthropic · 29 de setembro de 2025
3. [OWASP Top 10 for LLM Applications 2025](https://genai.owasp.org/resource/owasp-top-10-for-llm-applications-2025/) · OWASP GenAI Security Project · 17 de novembro de 2024
4. [Artificial Intelligence Risk Management Framework: Generative Artificial Intelligence Profile (NIST AI 600-1)](https://www.nist.gov/publications/artificial-intelligence-risk-management-framework-generative-artificial-intelligence) · NIST · 26 de julho de 2024

### Uma conversa já separa o urgente do que pode esperar.

Entender como a sua operação está hoje é por onde começamos, não onde paramos.

[Conversar no WhatsApp](https://wa.me/5532998024931?text=Ol%C3%A1%2C%20vim%20pelo%20site%20e%20gostaria%20de%20conversar) [Como trabalhamos](https://franklinfreitas.com/como-trabalhamos#entender)

Série · parte 2 de 10

[IA no código: o caminho estreito até produção](https://franklinfreitas.com/blog/governanca-de-ia/#serie)

[Anterior Governança de IA no código: o caminho estreito até produção](https://franklinfreitas.com/blog/governanca-de-ia-caminho-estreito-ate-producao)[Próximo Como um guardrail de IA decide: risco, regra e o que você pediu](https://franklinfreitas.com/blog/como-um-guardrail-de-ia-decide)

## Leia também

- [Governança de IA no código: o caminho estreito até produção](https://franklinfreitas.com/blog/governanca-de-ia-caminho-estreito-ate-producao)

Por [Victor Freitas](https://franklinfreitas.com/sobre/victor-freitas) · Consultor em governança de tecnologia e IA · Franklin Freitas Consultoria

Conduz diagnósticos e implantações de governança de tecnologia e IA em pequenas e médias empresas, com experiência acumulada em provedores de internet. Mais de 20 anos no mercado de TI, com passagens por desenvolvimento, DevOps, infraestrutura, arquitetura de solução e AIOps. Casado, pai de duas filhas.

Franklin Freitas Consultoria é a marca de F. F. SOFTWARE HOUSE LTDA · CNPJ 67.982.774/0001-36 · Espera Feliz/MG

[victor@franklinfreitas.com](mailto:victor@franklinfreitas.com?subject=Contato%20pelo%20site) · [WhatsApp +55 (32) 99802-4931](https://wa.me/5532998024931?text=Ol%C3%A1%2C%20vim%20pelo%20site%20e%20gostaria%20de%20conversar)

[Como trabalhamos](https://franklinfreitas.com/como-trabalhamos) · [Produtos](https://franklinfreitas.com/produtos) · [Blog](https://franklinfreitas.com/blog/) · [Quem conduz](https://franklinfreitas.com/sobre/victor-freitas) · [Aviso de privacidade](https://franklinfreitas.com/privacidade) · Sem cookies e sem formulário.

© 2026 F. F. SOFTWARE HOUSE LTDA