Governança de IA no código: o caminho estreito até produção

Por que a pergunta "qual IA usar?" é a menos importante?

Porque qualquer modelo, de qualquer fornecedor, escreve código errado com toda a confiança, e trocar de modelo não muda o que acontece com esse código depois. A escolha do assistente, do plano e do modelo costuma ocupar a maior parte das reuniões sobre IA no desenvolvimento, e é a decisão que menos mexe no risco. O risco está no trecho entre o que a IA escreve e o que chega ao servidor: quem olhou, o que foi testado, o que foi barrado e por onde aquilo passou.

Há um dado público que ajuda a desfazer a ideia de que o modelo certo resolve. Em julho de 2025, a Veracode publicou um teste com 80 tarefas de programação desenhadas para expor fraquezas conhecidas, aplicado a mais de 100 modelos de linguagem. Quando a tarefa admitia um jeito seguro e um inseguro, os modelos escolheram o inseguro em 45% dos casos, e os maiores não se saíram significativamente melhor que os menores. O teste foi construído para provocar o erro, então o número não descreve o código que um time escreve no dia a dia. O que ele mostra é outra coisa: tamanho e versão do modelo não são um controle.

Por isso, quando a conversa começa em "qual IA o time deve usar?", nós a puxamos para três perguntas que continuam valendo depois da próxima troca de modelo. O que o assistente pode fazer na máquina de quem programa? Que dados e sistemas ele alcança? Por qual caminho o código que ele ajudou a escrever vira produção? Esta série responde às três, uma camada por vez, e este texto é o mapa.

Repare no que a definição deixa de fora: o modelo. Ele entra como peça trocável. Se a governança dependesse do modelo em uso, cada versão nova seria uma reavaliação de todo o risco do time. Com o caminho no lugar, trocar de modelo é trocar uma peça e observar se os mesmos controles continuam barrando o que devem barrar.

O que muda quando o código passa a ser escrito com IA?

Muda a proporção entre quem escreve e quem revisa. Com IA, o time produz mais código, mais rápido, com o mesmo número de pessoas para revisar, e esse código chega com uma aparência de acabamento que desarma quem lê. Quatro coisas mudam ao mesmo tempo, e só uma delas é a que todo mundo comenta.

A confiança aparente tem nome e tem estudo. Num experimento divulgado em 2022 e publicado no ACM CCS 2023, pesquisadores de Stanford observaram que os participantes com acesso a um assistente de IA escreveram código significativamente menos seguro do que os que não tinham, e ao mesmo tempo eram mais propensos a acreditar que o próprio código estava seguro. O perfil de IA generativa do NIST, de julho de 2024, chama de confabulação a produção de conteúdo errado apresentado com confiança, e trata como risco próprio desses sistemas a relação entre pessoa e IA que leva ao viés de automação e à dependência excessiva. É o retrato de um revisor diante de um pedido de alteração bem formatado no fim do dia.

A autonomia é a mudança menos discutida e a que mais pesa. A OWASP, na edição 2025 da sua lista de riscos de aplicações com modelos de linguagem, chama de agência excessiva (excessive agency) a vulnerabilidade de um sistema executar ações danosas a partir de uma saída inesperada, ambígua ou manipulada do modelo, e aponta três causas: funções demais, permissão demais e autonomia demais. Um assistente de código que roda com as permissões de quem programa tem as três por padrão. Ele lê o que essa pessoa lê, executa o que ela executa e alcança o que ela alcança.

O reflexo comum diante disso é pedir mais cuidado na revisão. Não escala, porque a revisão é justamente o recurso que a IA não multiplicou. O outro reflexo, proibir o uso, também falha: empurra a IA para contas pessoais, sem configuração da empresa e sem registro do que foi feito. O que funciona é tirar da revisão humana tudo o que uma máquina consegue barrar sozinha, para que a pessoa revise o que só uma pessoa consegue julgar.

Quais são as três camadas da governança de IA no código?

Quem usa a IA, o que a IA alcança e por onde o código chega a produção. São três perguntas diferentes, com controles diferentes, e juntas cobrem o percurso inteiro, de quem digita até o servidor. Cada texto desta série mora numa delas.

Uma regra atravessa as três camadas e se repete em todos os textos: controle é mecanismo, não boa vontade. Cada controle precisa responder a três perguntas. O que ele barra? Como se prova que ele barra? O que acontece quando ele falha? Um controle que não responde à segunda é uma esperança, e um que não responde à terceira é uma surpresa marcada para o pior dia.

Um exercício para amanhã: pegue a última mudança que foi a produção e, para cada camada, responda que controle teria barrado um erro nela e como você sabe que ele teria barrado. Onde a resposta for "alguém teria percebido", a camada ainda não existe.

Camada 1: quem usa a IA

O assistente de código roda na máquina de quem programa, com as permissões dessa pessoa. A primeira camada decide o que ele pode fazer ali, e começa por uma troca: a regra deixa de ser texto que o modelo lê e passa a ser um programa da empresa que roda em pontos fixos do fluxo, antes e depois de cada ação. Sobre esse mecanismo vem um guardrail, que faz três perguntas a cada ação do assistente: quão arriscado é isto, fere alguma regra da casa, foi isto que a pessoa pediu? O modelo que classifica só estima probabilidades. Quem decide é a política da empresa, escrita em código, e uma pergunta sem resposta nunca vira "pode".

Por cima de tudo fica a configuração gerenciada, a camada que a empresa distribui de forma central e que o usuário não sobrescreve na própria máquina. Plugins obrigatórios, limites fixados e segredos que nunca passam pelo repositório entram sozinhos no próximo login de quem chega ao time. Sem ela, a governança vale até a primeira pessoa com pressa.

Camada 2: o que a IA alcança

Ligar a IA aos dados reais da empresa é o que a torna útil, e também o que a torna perigosa. A segunda camada define o que ela lê e garante o que ela nunca escreve. "Só leitura" não é promessa da ferramenta nem frase na instrução. É garantia em três lugares independentes: a permissão do usuário no banco, a recusa do serviço em subir fora desse modo e o escopo do perfil de quem pergunta. Uma falha sozinha não basta para a IA escrever.

Na mesma camada ficam duas decisões que costumam ser esquecidas. O dado pessoal sai mascarado antes de chegar ao modelo, e não depois. E existe uma lista de destinos para onde a IA pode mandar dados; o que não está na lista não recebe nada. A LGPD chama a lógica por trás disso de necessidade: tratar só o mínimo indispensável para a finalidade. Quando a chave que liga a IA aos dados é retirada, as funções de IA caem, e isso é desenho, não falha.

Camada 3: por onde o código chega

A terceira camada é o trilho propriamente dito. Todo código chega a produção por um caminho só, o pull request, e produção nunca compila nada: só roda o que já foi construído, testado e aprovado. Voltar atrás também é um pull request. Um validador recusa, ainda no pedido de alteração, o que a casa não aceita em produção, antes de alguém precisar lembrar.

Esse caminho é guardado por oito checks obrigatórios: lint, tipos, testes, segredos, análise estática, dependências, imagem e validador de deploy. Eles bloqueiam o merge, porque um check que só alerta ensina o time a ignorar o vermelho. Segredo não passa pelo terminal nem fica ao alcance do assistente. A máquina que executa o código de cada pedido de alteração, ainda não revisado, não alcança produção. E produção não tem nenhuma porta de entrada aberta.

O fecho atravessa as três camadas: provar que tudo isso funciona e saber desligar. Uma trilha que mostra quem fez o quê, um botão que desliga a IA para todos e uma rotina curta que impede o desenho de apodrecer.

Por que regra escrita não basta?

Porque regra escrita é texto que o modelo pode ou não seguir. Uma política de uso de IA num documento, num arquivo de instruções do repositório, como o CLAUDE.md do Claude Code, ou nas instruções da organização entra no contexto do modelo como mais um trecho a considerar. Funciona quase sempre. E "quase sempre" é exatamente o problema quando o assunto é segredo, dado pessoal ou produção.

Os motivos são conhecidos. O modelo pondera a instrução contra tudo o mais que está no contexto: o pedido da pessoa, o código aberto, a saída do último comando. Numa conversa longa, a regra fica longe. E o contexto pode trazer texto de fora com instrução escondida, numa página, num comentário de pull request ou na resposta de um conector. A OWASP põe essa injeção de instrução (prompt injection) no topo da lista de 2025 e registra que técnicas como busca em base própria e ajuste fino não a eliminam. O que ela recomenda é tratar privilégio em código, fora do modelo, e exigir aprovação humana para o que é de alto risco.

A saída é transformar a regra em mecanismo. Nos assistentes de código, isso tem nome: hook, um ponto fixo do fluxo, antes de usar uma ferramenta, depois de usá-la ou ao abrir a sessão, em que um programa da empresa roda e decide, independentemente do que o modelo achou. A diferença cabe em três verbos. A instrução orienta. A skill ensina. O hook roda.

O erro mais caro não é ter só texto. É ter um texto que afirma proteção mecânica onde o mecanismo não roda. Uma skill viaja para superfícies onde o hook não existe, como o chat no navegador, e continua dizendo que a proteção está ativa. O time passa a se achar protegido sem estar, e isso é pior do que não ter regra nenhuma. Por isso todo mecanismo precisa avisar, ao abrir a sessão, se está pronto ou se não está operante.

Nem tudo precisa virar mecanismo. Poucas proibições absolutas bloqueiam: segredo escrito em código, escrita direta em banco de produção, dado apagado em definitivo. O resto orienta ou pede aprovação, para que o time não aprenda a contornar um bloqueio que dispara toda hora. O próximo texto desta série detalha essa fronteira.

Para amanhã, abra o arquivo de instruções do assistente do seu time e marque cada frase que é uma proibição. Para cada uma, pergunte o que acontece se o modelo não a seguir. Onde a resposta for "vaza um segredo" ou "altera produção", a regra precisa virar mecanismo.

O que é o "caminho estreito" até produção?

É um caminho só para produção, igual para pessoa e máquina, que bloqueia em vez de alertar e prova, a cada uso, que está funcionando. As quatro propriedades dependem uma da outra. Tire qualquer uma e o caminho alarga.

Um só. Se existe um jeito de mudar produção sem passar pelo repositório, ele vai ser usado no dia em que a IA sugerir um atalho, e ela vai sugerir. Acesso direto ao servidor para "só ajustar um arquivo", build feito na própria máquina de produção, variável trocada à mão num painel: cada um desses é um segundo caminho, sem revisão e sem registro. O desenho fecha todos, inclusive o da emergência. Em incidente, voltar atrás é um pull request que troca a versão, e por isso o caminho precisa ser rápido o bastante para ninguém ter motivo de sair dele.

Igual para pessoa e máquina. O assistente não ganha um caminho especial, e o desenvolvedor mais experiente também não. A mesma CI, os mesmos checks, a mesma aprovação. A razão é prática: num pull request de hoje, as linhas da pessoa e as da IA estão misturadas, e ninguém consegue separá-las com segurança. A autoria deixou de ser informação útil para decidir o que entra. O que decide é o que o código faz.

Bloqueia, não alerta. Um controle que só avisa vira paisagem em poucos dias. O time aprende que vermelho não impede nada e passa a ignorar também o vermelho que importava. Os oito checks obrigatórios bloqueiam o merge e, por isso, precisam ser justos: bloquear só o que tem correção, avisar do resto e ter um dono para cada aviso.

Verificável. Cada controle do caminho tem uma prova que se repete, e não um "foi configurado". A máquina que roda os testes tenta alcançar a rede interna e precisa falhar. O validador recebe um serviço com porta exposta e precisa recusar. A varredura de segredos recebe um segredo de teste e precisa barrar. Se a prova parar de falhar quando deveria, o controle caiu, e alguém fica sabendo.

Nada disso é invenção desta série. O framework de desenvolvimento seguro do NIST, o SSDF, organiza o tema como práticas de processo: preparar a organização, proteger o software, produzir software bem protegido e responder a vulnerabilidades. Em julho de 2024, ele ganhou um complemento para IA generativa. O caminho estreito é a forma operacional dessa ideia para um time que escreve código com IA: quem carrega a segurança é o processo, não a promessa da ferramenta.

O erro comum é estreitar o caminho só para a IA. Bloquear o assistente e deixar a pessoa com acesso direto ao servidor não estreita nada. A IA sugere o comando, a pessoa cola no terminal, e o atalho continua aberto, agora com uma etapa a mais e nenhum registro.

O que fica com as pessoas?

Três coisas que nenhum mecanismo faz: revisar o que entra, decidir o risco que se aceita e apertar o botão de desligar. O trilho existe para que as pessoas parem de fazer o que a máquina faz melhor, como procurar segredo esquecido ou dependência vulnerável, e se concentrem no que só elas fazem. No AI RMF do NIST, de janeiro de 2023, governar é a função transversal, a que define papéis, responsabilidades e cultura, e dá sentido a mapear, medir e gerenciar.

A revisão. Quem aprova um pull request responde pelo que entrou, tenha escrito ou não. Com os checks no lugar, a revisão muda de natureza. A pessoa não procura vírgula nem chave esquecida, porque isso já foi barrado. Ela pergunta se aquilo deveria existir, se faz o que diz e se mexe em algo que não devia, que é a pergunta que nenhum check responde. Por isso o desenho prevê mais de um dono de código para cada área: com um só, todo pedido desse dono trava, e a pressão para liberar sem revisão volta.

O risco aceito. Todo desenho real tem desvios: orçamento que não comporta uma máquina a mais, sistema antigo que não cabe no trilho, ferramenta que ainda não bloqueia. O desenho reduz o risco, não o elimina, e dizer isso em voz alta é parte do método. O desvio é decidido pela diretoria, escrito com nome, data e motivo, e revisto. O mesmo vale para os limites do guardrail: quem pode mudá-los é a diretoria, por um pedido de alteração, e não quem se incomodou com um bloqueio numa tarde.

O botão de desligar. Uma governança que não se desliga é refém da própria ferramenta. É preciso um comando único que desligue uma função de IA para todos de uma vez, com quem pode acioná-lo definido antes do incidente. E é preciso uma trilha que mostre o que foi tentado e o que foi executado, guardada fora da máquina onde aconteceu, com retenção de um ano, e honesta sobre o que ela não consegue mostrar.

Tudo isso só continua de pé com uma rotina curta: 5 minutos por dia, 30 minutos por semana, 2 horas por mês e meio dia por trimestre, cada uma com o que cabe nela. Entrega, numa implantação de governança, é a prova de cada controle, e não "subiu".

Por onde começar numa empresa pequena?

Pela fundação, antes da automação. Primeiro o caminho único, depois os segredos, depois o assistente governado, e só então o que exige mais maquinário. A ordem importa mais do que a velocidade: um guardrail sofisticado na máquina de quem programa não protege nada se o servidor de produção aceita mudança feita à mão.

Imagine um time de cinco pessoas que adotou um assistente de código há alguns meses. Ninguém ali tem tempo para um projeto de governança, e ninguém precisa. A sequência abaixo cabe em ciclos curtos, e cada passo vale sozinho, mesmo que o seguinte demore.

1. Um caminho só. Todo código num repositório da empresa, branch principal protegido e merge só por pull request com aprovação de alguém além do autor. Confira que a proteção está ligada de fato, e não só combinada.
2. Segredos fora do código e do terminal. Um cofre de segredos, um segredo por uso, nada escrito em arquivo versionado e nada colado em linha de comando, com troca semestral registrada sem o valor.
3. Poucos checks que bloqueiam. Comece por segredos, testes e dependências com correção disponível, bloqueando o merge, e amplie até os oito quando o time confiar no vermelho.
4. Produção sem atalho. Deploy só pelo que o repositório diz, produção sem build e sem porta de entrada, e a máquina de testes separada da de produção.
5. O assistente governado. Configuração gerenciada pela empresa e as poucas proibições absolutas transformadas em mecanismo, com o aviso de "não operante" visível para quem usa.
6. Dados só de leitura. Quando a IA precisar de dados reais, leitura garantida no banco, dado pessoal mascarado antes do modelo e destinos permitidos em lista.
7. Prova e desligamento. Trilha fora da máquina, botão de desligar testado e a rotina na agenda de alguém com nome.

O erro comum de quem começa é inverter a ordem: instalar a ferramenta mais visível, um scanner ou um guardrail, sobre um caminho que ainda tem atalhos. A ferramenta acende alertas, ninguém tem tempo de tratá-los, e o time conclui que governança é ruído. Começar pela fundação faz o contrário. Cada passo fecha uma porta, e porta fechada não gera alerta.

Os textos seguintes desta série seguem esse percurso. Começam pela primeira camada: por que a política de uso de IA precisa virar mecanismo, como um guardrail decide entre risco, regra e pedido, e o que o time não consegue desligar. Passam pela segunda, com a IA que lê e não escreve dados de produção. Descem a terceira: o pull request como único caminho, o gate que bloqueia em vez de alertar, o segredo que não passa pelo terminal e a máquina que roda código de PR sem tocar produção. E terminam no que atravessa as três: provar que funciona e saber desligar.