Resumo
- Política de uso de IA é documento. Documento não intercepta requisição.
- Código-fonte sai da empresa por três caminhos distintos, e cada um se fecha de um jeito diferente. Só um deles é resolvido por treinamento de equipe.
- O caminho mais fácil de fechar é o assistente de terminal, e a maioria das empresas não fechou porque nunca olhou a configuração padrão da ferramenta.
- Modelo local resolve o problema de vazamento de forma definitiva e custa qualidade. Quando isso compensa depende de volume, e o cálculo é simples.
O que existe hoje sobre o assunto
Se você buscar sobre risco de mandar código-fonte para IA, vai encontrar bastante material. Quase tudo escrito por advogado: escritórios de direito digital, portais jurídicos, consultorias de proteção de dados.
O material é bom no que se propõe. Explica a LGPD, fala de transferência internacional de dados, cita a Resolução CD/ANPD 19/24, alerta sobre shadow AI. E termina, invariavelmente, na mesma recomendação: crie uma política de uso de IA e treine a equipe.
Isso é necessário e é insuficiente, pela razão mais simples possível: uma política é um documento, e documento não intercepta requisição HTTP. Se ninguém aplicou a regra em algum lugar do caminho entre o editor do desenvolvedor e a API do provedor, a política descreve o comportamento desejado sem alterar o comportamento real.
O caso mais citado do tema mostra exatamente isso. Em 2023, engenheiros da Samsung colaram código proprietário e transcrições internas no ChatGPT, em incidentes separados. Os dados entraram no corpus e não puderam ser recuperados. Nenhuma política escrita depois desfaz isso.
Este artigo é sobre a camada que falta.
Os três caminhos
Código-fonte sai da empresa por três rotas, e tratá-las como uma coisa só é o erro que faz a política não funcionar.
1. O assistente de código no terminal ou na IDE
O desenvolvedor instala a ferramenta, ela lê o repositório e manda contexto para um provedor. É a rota de maior volume e a mais fácil de fechar — porque é configuração, não comportamento.
E é onde mora a armadilha mais comum: a configuração padrão raramente é a que a sua empresa escolheria. Já documentei um caso concreto em Claude Code é o melhor, mas: o OpenCode, na instalação padrão, aponta o modelo principal e o auxiliar para um tier gratuito de terceiro. Quem instalou sem olhar passou a mandar contexto de repositório para um provedor que nunca escolheu, sem violar nenhuma política — porque nenhuma política falava sobre isso.
O que fecha: configuração versionada no repositório, com provedor e modelo definidos explicitamente, e verificação em CI que falha o build quando alguém aponta para fora da lista. A regra passa a viver onde o código vive.
2. Agente, script e automação interna
Essa é a rota que ninguém contabiliza, porque ela não parece produto: o script que analisa log, o agente que tria ticket, a automação que resume pull request. Cada um nasceu para resolver um problema pontual, cada um carrega a própria chave, e cada um decide sozinho o que manda para fora.
Por que ela é difícil de fechar: não dá para escrever política sobre o que você não sabe que existe. Diferente da rota anterior, aqui nem a lista existe.
Então o trabalho tem duas etapas, nessa ordem.
Primeiro, levantar. Um script de inventário varre o repositório e devolve os pontos de chamada, os provedores e as chaves em minutos. Sem esse número, qualquer decisão seguinte é chute.
Depois, centralizar. Chave virtual por aplicação em vez de chave real espalhada, e uma camada única por onde toda chamada passa — o desenho está em Um gateway de IA em 40 linhas de YAML.
3. A pessoa colando no chat
Esse é o único dos três que é problema de treinamento e de política. O desenvolvedor abre o navegador, cola um trecho e pede ajuda.
O que fecha: parcialmente, política e conscientização. E, de forma mais eficaz, dar uma alternativa autorizada que seja boa. Quando existe uma ferramenta aprovada que funciona bem, o incentivo de contornar cai muito. Bloqueio sem alternativa produz criatividade, não conformidade.
O que efetivamente impede o código de sair
Em ordem crescente de custo e de garantia.
Anonimização na fronteira. Uma camada que remove identificador antes da chamada sair. Medi o Microsoft Presidio em PII brasileiro e ele não detecta CPF de fábrica — o resultado e o conserto estão em PII e modelos de linguagem. Funciona bem para dado pessoal — CPF, CNPJ, e-mail, telefone — e é obrigatória se houver dado de cliente no fluxo. Não resolve segredo industrial, porque não existe como anonimizar a lógica de um algoritmo proprietário sem destruir a pergunta.
Contrato com o provedor. Retenção zero, cláusula de não-treinamento, região de processamento definida. Reduz risco de forma real e depende de confiança contratual — o dado sai, você só combinou o que acontece com ele. Vale ler qual tier você assinou: a regra do plano gratuito costuma ser diferente da do pago.
Modelo local. O dado não sai. É a única opção que transforma a garantia de contratual em técnica. Custa qualidade, custa hardware e custa operação.
Quando modelo local compensa
Aprofundei este assunto em A pergunta não é se um modelo pequeno é bom o suficiente.
Números que circulam publicamente, para calibrar a conta — não são medições minhas:
- Regra prática de VRAM: cerca de 0,5 GB por bilhão de parâmetros em quantização de 4 bits.
- Servidor com GPU dedicada no Brasil parte de algo em torno de R$ 3.200 por mês.
- O ponto de equilíbrio contra API costuma ser citado a partir de aproximadamente 10 milhões de tokens por mês.
A conta é direta: pegue seu consumo mensal de tokens, multiplique pelo preço do provedor, compare com o custo fixo da máquina. Abaixo do ponto de equilíbrio, modelo local é decisão de conformidade, não de economia — e tudo bem, desde que seja assumido como tal na hora de aprovar.
E a ressalva honesta: modelo local de 7 a 14 bilhões de parâmetros não entrega a qualidade de um modelo de fronteira em tarefa aberta. Ele empata em tarefa estreita e bem definida — classificação, extração de campo, reescrita com formato fixo. A pergunta certa não é "modelo local é bom o suficiente", é "qual das minhas tarefas cabe nele".
O que fazer com cada rota
O post inteiro é sobre três rotas, então o fecho é o que fazer com cada uma.
Rota 1, o assistente na IDE. Versione a configuração no repositório e ponha uma verificação em CI que falha o build quando alguém aponta para provedor fora da lista. É a mais fácil das três e a de maior volume.
Rota 2, agente e automação. Rode o inventário esta semana. Você não tem como fechar o que não sabe que existe, e o levantamento leva minutos.
Rota 3, a pessoa colando no chat. Política e conscientização resolvem parte. O resto se resolve dando uma ferramenta aprovada que funcione bem — quando existe, o incentivo de contornar cai.
E a decisão que atravessa as três: até onde o contrato com o provedor te cobre. Cláusula de retenção zero e configuração versionada resolvem a maior parte do risco na maioria das empresas. Quando o requisito é que o dado não saia da rede, aí a conversa vira outra, e ela está em onde o modelo local entra.
Como ajudamos times a adotar IA
Trabalhamos com times de engenharia que buscam incorporar IA ao dia a dia de desenvolvimento — não como experimento, mas como parte real do fluxo de trabalho.
Isso passa por escolher as ferramentas certas para o contexto do time, configurá-las de forma que façam sentido para a política de dados da empresa e garantir que os desenvolvedores saibam usá-las de um jeito que realmente aumente a produtividade, em vez de gerar mais fricção.
Se você tem um time de desenvolvimento e está tentando colocar IA para trabalhar de forma séria, fale com a gente.