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 — e quase tudo escrito por escritório de advocacia e empresa de compliance. Migalhas, bancas grandes, 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: 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

Aqui está o volume que ninguém contabiliza. O script de análise de log que chama modelo. O agente de triagem de ticket. A automação que resume pull request. Cada um com a própria chave, cada um decidindo sozinho o que envia.

O que fecha: nada, até você saber o que existe. Esse é o passo anterior a qualquer decisão de arquitetura, e escrevi sobre ele em O problema não é quantos modelos de IA sua empresa usa — com o script que faz o levantamento.

Depois de saber o que existe: chave centralizada e revogável em vez de chave por aplicação, e uma camada única por onde toda chamada passa. É o mesmo desenho que o iFood e o Itaú adotaram, de forma independente, quando a escala passou de um certo ponto — nenhum dos dois deixou as aplicações chamarem provedor direto.

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. 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

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".

Para quem isso serve

Se a sua empresa não tem obrigação contratual ou regulatória sobre onde o código roda, contrato com cláusula de retenção zero e configuração versionada resolve a maior parte do risco. Não monte infraestrutura local.

Se você fornece para cliente cujo contrato tem cláusula de confidencialidade, vale ler o que essa cláusula diz sobre processamento por terceiros antes de assumir qualquer coisa. Isso deixa de ser gestão de risco e vira exposição contratual — e é uma leitura que o jurídico faz em uma tarde.

Se o requisito é que o código não saia da infraestrutura, aí é modelo local, e a conversa passa a ser sobre quais tarefas cabem nele e a partir de que volume ele se paga.

Em qualquer um dos três casos, o passo zero é o mesmo: saber quantas aplicações chamam modelo hoje. Sem esse número, você está escrevendo política para um sistema que não mapeou.

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.