Se você trabalha em um banco, uma fintech, uma empresa de saúde ou um órgão público, provavelmente já conhece a regra: não se cola código proprietário no ChatGPT, no Claude nem no Copilot, nem para perguntar "isso é seguro?". A regra existe por bons motivos. Mas ela também significa que os times com mais a perder com uma vulnerabilidade são justamente os que ficam de fora da revisão de código com IA. Uma IA self-hosted para segurança de código é o jeito de fechar essa lacuna sem quebrar a regra.
Neste guia vemos por que a restrição existe, quais são os riscos reais, as opções para rodar uma IA privada, o que avaliar em um fornecedor e por que um log auditável e à prova de adulteração de cada chamada à IA é a peça que transforma um "confie em nós" em prova.
Por que times regulados não podem colar código em ferramentas de IA públicas
Código fonte não é só texto. Ele carrega o desenho do seu modelo de autorização, nomes de serviços internos, esquemas de banco de dados, às vezes fixtures de teste com dados que parecem de clientes reais e, com frequência demais, credenciais. Para uma empresa regulada, também é propriedade intelectual e, muitas vezes, informação coberta por confidencialidade contratual ou legal.
Quando um dev cola um arquivo em um assistente de IA genérico, acontecem várias coisas fora do controle da empresa:
- O código atravessa o perímetro rumo a um terceiro que o time de segurança pode nunca ter avaliado.
- Ele pode ser retido. Dependendo do produto e do plano, os prompts podem ser guardados para monitoramento de abuso, debugging ou recursos de histórico.
- Ele pode ser usado para treinamento. As versões para consumidores de alguns assistentes usam as conversas para melhorar os modelos a menos que o usuário desative. Planos empresariais e de API geralmente não fazem isso por padrão, mas é uma cláusula de contrato que você precisa verificar, não algo para presumir.
- Não fica nenhum registro do seu lado. Depois você não consegue provar o que foi enviado, por quem, nem para qual modelo.
Por isso muitas organizações reguladas bloqueiam essas ferramentas no proxy, ou só as liberam com um contrato empresarial aprovado. E por isso a "IA na sombra", devs usando contas pessoais mesmo assim, é uma preocupação real.
Os riscos concretos: retenção, treinamento e compliance
Retenção de dados
Mesmo quando um provedor promete não treinar com seus dados, ele pode guardar os inputs por um período para segurança e monitoramento de abuso. Acordos de retenção zero existem para alguns clientes empresariais de API, mas são negociados, não vêm por padrão. Para código com segredos ou dados de clientes, "guardado por um tempo no servidor de outra empresa" já é um incidente esperando classificação.
Treinamento e memorização
A preocupação não é que amanhã um modelo recite seu repositório para um estranho. É que, quando os dados entram em um pipeline de treinamento, você perde a capacidade de garantir onde eles vão parar e não consegue apagá-los com certeza. Para segredos comerciais, essa perda de controle é o problema.
Frameworks de compliance
- LGPD e GDPR: se o código, os logs ou os fixtures contêm dados pessoais, enviá-los a um provedor de IA faz dele um operador de dados. Você precisa de um acordo de tratamento de dados, uma base legal e, se os dados saem do país ou da UE, um mecanismo de transferência internacional válido.
- HIPAA: para empresas que atendem o mercado americano de saúde, o código em si normalmente não é informação de saúde protegida, mas dados de teste, logs e dumps de banco dentro de um repo podem ser. Compartilhar PHI com um fornecedor exige um business associate agreement.
- SOC 2: os auditores vão perguntar como você gerencia fornecedores que tocam dados sensíveis e como controla e registra acessos. Uma ferramenta de IA não avaliada e sem logs vira um achado.
- Sigilo bancário e regulação financeira: em muitas jurisdições os bancos têm deveres legais de sigilo sobre as informações dos clientes e regras rígidas de terceirização para qualquer terceiro que as processe. Times de segurança costumam tratar o código do core bancário como dentro desse escopo.
- Governo e defesa: regras de residência e classificação de dados muitas vezes proíbem de vez o processamento em serviços estrangeiros ou multi-tenant.
Opções para rodar uma IA privada para revisar código
"IA self-hosted" cobre várias arquiteturas, cada uma com seus trade-offs:
| Opção | Onde o modelo roda | Prós | Contras |
|---|---|---|---|
| LLM local on-prem | Seu próprio data center ou suas GPUs | Controle máximo, funciona air-gapped | Hardware caro, você opera e atualiza o modelo |
| LLM na sua VPC | Um deploy dedicado na sua conta de nuvem | O código fica no seu perímetro de nuvem, encaixa nos seus controles | Você ainda gerencia GPUs, escala e qualidade do modelo |
| Modelo próprio do fornecedor com inferência efêmera | O modelo do fornecedor em infraestrutura dedicada e de vida curta | Sem carga operacional, sem provedor de IA terceiro no caminho | Você depende dos controles do fornecedor, então precisa de provas |
| API de terceiros com retenção zero | Um provedor de modelos frontier sob acordo de não retenção | Modelos gerais muito fortes | O código ainda sai para outra empresa; depende do contrato |
| Assistente de chat público | Serviço compartilhado para consumidores | Prático | Geralmente inaceitável para código regulado |
A inferência efêmera merece um olhar mais atento. A ideia é simples: um ambiente isolado é criado para um scan, o modelo analisa o código ali, os resultados são devolvidos e o ambiente é destruído. Nada persiste entre clientes e não existe um repositório de prompts de longa duração para vazar depois.
O que avaliar antes de uma IA tocar no seu código
- Onde exatamente o modelo roda? No seu hardware, na sua conta de nuvem, na infraestrutura dedicada do fornecedor ou em uma API compartilhada de terceiros? Peça a resposta por escrito, incluindo a região.
- Qual modelo, e de quem? É um modelo próprio do fornecedor ou um wrapper sobre OpenAI, Anthropic ou Google? Um wrapper pode servir para muitas empresas, mas você precisa saber.
- O que é retido e por quanto tempo? Código fonte, prompts, respostas do modelo, achados, logs. Cada um pode ter uma política diferente.
- Algo é usado para treinamento? O padrão e o mecanismo de opt-out precisam ser explícitos.
- Existe um registro de auditoria de cada chamada à IA? Dá para ver qual modelo processou quais arquivos, quando e para quê? O log pode ser alterado sem deixar rastro?
- Quão bom o modelo é em segurança? Privacidade não vale nada se os achados forem ruído. Peça resultados em um repositório que você conhece bem e observe os falsos positivos e se cada achado aponta um arquivo e uma linha concretos.
- O que acontece quando um modelo externo é usado? Alguns recursos, como gerar uma correção, podem usar um modelo frontier. Isso deve ser opt-in, explícito e registrado.
Como um modelo de segurança self-hosted analisa código sem que ele saia da infraestrutura controlada
Um modelo de segurança self-hosted faz mais ou menos o que um revisor faz, mas dentro de um perímetro sobre o qual você consegue raciocinar:
- Busca o repositório com acesso somente leitura e restrito, para um ambiente isolado.
- Monta contexto: rotas, handlers, modelos de dados, manifestos de dependências, workflows de CI, infraestrutura como código.
- Raciocina sobre caminhos de ataque: segue o input não confiável entre arquivos, verifica se cada operação sensível tem checagem de autorização, procura injeções, desserialização insegura, segredos e más configurações. É o mesmo raciocínio que torna útil o code review com IA, e complementa a análise estática de código clássica; em SAST e DAST mostramos como as camadas se encaixam.
- Valida e prioriza os achados por explorabilidade, não por coincidência de padrões.
- Registra cada chamada ao modelo em um log de auditoria e depois destrói o ambiente.
A propriedade-chave é que nenhuma etapa da análise exige enviar o código a um provedor de IA genérico de terceiros. É isso que torna um scanner de vulnerabilidades com IA utilizável em ambientes onde os assistentes públicos são proibidos.
O log de auditoria é a prova
"Não enviamos seu código para lugar nenhum" é uma afirmação. Um log de auditoria auditável e à prova de adulteração é evidência. A técnica padrão é uma cadeia de hashes: cada entrada do log inclui um hash criptográfico da anterior, então o log forma uma cadeia que não pode ser editada no meio sem quebrar todos os elos seguintes.
{
"seq": 1042,
"timestamp": "2026-09-23T14:02:11Z",
"scan_id": "scn_8f3a",
"purpose": "vulnerability_analysis",
"model": "self-hosted-security-model",
"provider": "self-hosted",
"input_sha256": "9c1e...a7",
"output_sha256": "44b0...1d",
"prev_hash": "e3d9...52",
"entry_hash": "sha256(prev_hash + canonical_json(entry))"
}Com um log assim você responde às perguntas que um auditor ou o time de segurança de um cliente vai fazer:
- Qual modelo processou nosso código? Cada chamada indica o modelo e o provedor.
- Alguma IA de terceiros viu o código? Filtre por provedor. Se um modelo externo foi usado, existe uma entrada para isso, com o consentimento que o autorizou.
- O log foi alterado? Recalcule a cadeia. Uma única entrada editada ou apagada quebra todos os hashes seguintes.
- O que exatamente foi enviado? Os hashes de inputs e outputs permitem verificar o conteúdo sem que o log armazene o código.
Verificar é barato. Qualquer pessoa pode recalcular a cadeia:
prev = GENESIS
for entry in log:
expected = sha256(prev + canonical_json(entry.without_hash))
assert entry.prev_hash == prev
assert entry.entry_hash == expected
prev = entry.entry_hashPara garantias mais fortes, ancore periodicamente o último hash em um lugar que o fornecedor não possa reescrever, por exemplo exportando-o para o seu próprio storage ou SIEM.
Como a Nurbak aborda isso
Como exemplo concreto: a Nurbak se conecta ao GitHub e escaneia um repositório com seu próprio modelo de IA self-hosted rodando em infraestrutura efêmera, então a análise não envia seu código para a OpenAI nem para a Anthropic. Cada chamada à IA fica registrada em uma trilha de auditoria auditável e encadeada por hashes. O scan reporta vulnerabilidades exploráveis com arquivo e linha, cruza as dependências com CVEs conhecidos, aponta más configurações de GitHub Actions, Docker, Terraform e Kubernetes e segredos no histórico do git, e gera um score de segurança de 0 a 100 com explicações em linguagem simples.
Existe um único ponto em que um modelo externo participa, e ele é opt-in: a Nurbak pode abrir um pull request com a correção e um teste de regressão de segurança, e essa correção é gerada com o Claude somente depois que o usuário dá consentimento explícito. Esse consentimento e a chamada ficam na mesma trilha de auditoria, então fica registrado exatamente quando o código saiu do perímetro self-hosted e por quê. O scan grátis mostra completos os 3 achados mais importantes; os planos pagos começam em USD 79 por mês. Veja como funciona na página do scanner de vulnerabilidades com IA.
Uma política prática para IA no seu pipeline de código
- Classifique os repositórios. Nem todos são igualmente sensíveis. Um SDK público e o core bancário merecem regras diferentes.
- Por padrão, análise self-hosted para repos sensíveis; modelos externos só por recurso e com consentimento explícito.
- Exija uma trilha de auditoria de cada chamada à IA, de qualquer fornecedor, e exporte-a para os seus próprios sistemas.
- Procure segredos primeiro. Uma chave no histórico do git é um problema independentemente de qual modelo a leia.
- Mantenha pessoas no circuito. Achados e correções da IA passam pela revisão normal de pull requests, como qualquer outra mudança.
- Revise a política conforme modelos e contratos mudam. O que vale hoje sobre a retenção de um provedor pode não valer no ano que vem.
Isso se encaixa naturalmente em um programa de DevSecOps: os mesmos gates nos pull requests, agora com um revisor de IA que você tem permissão para usar. Os achados se mapeiam bem para categorias como as do OWASP Top 10 2025, e para o que a IA não consegue julgar continua existindo o pentest.
Resumo
Times regulados estão certos em não colar código em assistentes de IA públicos. A resposta não é desistir da revisão de segurança com IA, e sim levar o modelo até o código: on-prem, na sua VPC ou no modelo próprio de um fornecedor rodando em infraestrutura efêmera, sem IA de terceiros no caminho por padrão. Depois, exija provas, não promessas: um log à prova de adulteração de cada chamada à IA, inclusive das poucas, consentidas, que usam um modelo externo. Se um fornecedor não consegue mostrar esse log, assuma que seu código vai para algum lugar que você não enxerga.