LLMs locais seguros para workflows sensíveis de desenvolvimento

Local é um local de execução, não uma propriedade de segurança

O Ollama documenta que prompts executados localmente não são enviados ao serviço, que recursos de cloud podem ser desativados e que o servidor usa 127.0.0.1 por padrão. São controles úteis, mas o workflow inclui editor, plugins, shell, repositório, vector store, downloader, package manager, telemetria, ferramentas, backups e sistema operacional.

Comece com um diagrama de dados e classificação explícita: código, segredos, dados de clientes, evidência de incidentes, documentos, prompts, embeddings, outputs, traces e patches. Para cada fluxo, identifique processo, identidade, armazenamento, retenção, destino de rede e ações possíveis.

Coloque um gateway de política antes de cada modelo

Aplicações não devem chamar Ollama, llama.cpp ou vLLM diretamente. Um gateway local autentica o cliente, classifica a requisição, aplica política de projeto, remove segredos óbvios, escolhe um modelo aprovado, limita contexto e output, registra metadados mínimos e bloqueia ferramentas e destinos proibidos.

A mesma interface pode encaminhar trabalho de baixa sensibilidade para um provedor cloud aprovado. A decisão precisa ser explícita e baseada em sensibilidade, projeto, residência, modelo permitido, tipo de tarefa, tamanho do contexto e autorização. Não dependa da memória do desenvolvedor sobre qual janela de chat é segura.

Pesos de modelo são inputs executáveis da supply chain

Inferência local ainda baixa artefatos de terceiros e executa parsers, tokenizers, templates, bibliotecas nativas, drivers e às vezes código customizado. O Hugging Face documenta o risco de execução arbitrária do pickle. Prefira safetensors ou formatos restritos como GGUF, rejeite remote code não revisado, escaneie artefatos e isole conversões.

Espelhe modelos aprovados em um registry interno. Fixe revisão, hashes, digest do container, runtime, tokenizer, template, quantização, licença e model card. Registre proveniência e vulnerabilidades. SLSA, Sigstore e NIST SSDF oferecem padrões reutilizáveis para essa cadeia.

RAG precisa aplicar as permissões antes do retrieval

Um vector database privado ainda pode vazar dados entre projetos. A ingestão deve excluir .env, chaves, credenciais, dumps, binários, dependências, dados pessoais e diretórios fora do repositório permitido. Aplique ACL antes de embedding e novamente antes de retornar chunks. Um filtro de metadados depois da busca não deve ser a única barreira entre tenants.

Separe índices quando o isolamento exigir, criptografe storage, versione o corpus, propague deleções e exponha path, commit, linhas e decisão de acesso de cada chunk. O modelo deve receber o mínimo necessário para a tarefa, não o repositório inteiro.

Execução de ferramentas é uma fronteira mais forte que inferência

Um modelo local com shell arbitrário, home directory, SSH, cloud CLI ou APIs internas pode ter alcance maior que um chat cloud. O OWASP destaca prompt injection e excessive agency. Trate output do modelo como input não confiável e coloque cada ferramenta atrás de um adapter tipado e governado.

Use worktrees ou containers descartáveis, identidade non-root, mounts read-only, limites de recurso, allowlist de comandos, rede negada, restrição de paths, timeout e aprovação antes de escrita, commit, instalação, alteração em banco ou comunicação externa. Mostre o diff e o comando exatos.

Segredos não podem depender de uma instrução no prompt

“Não revele segredos” não é controle. Mantenha credenciais fora dos paths indexados e do ambiente visível ao modelo. Use identidades curtas e escopadas, secret brokers, scanners antes do commit e da ingestão e análise de output. Rotacione qualquer segredo que entre em prompt, trace, embedding ou artefato.

Criptografia de disco protege o equipamento desligado, não um editor comprometido. Uso enterprise também exige gestão de endpoint, patching, screen lock, antimalware, separação de usuários, backup controlado e revogação remota.

Meça qualidade antes de declarar o modelo local suficiente

Privacidade falha indiretamente quando um modelo fraco gera código inseguro ou força a equipe a procurar um serviço não aprovado. Avalie nos repositórios e tarefas reais: correção do patch, testes, segredos, autorização, dependências, APIs inventadas, tool use, latência, memória e energia.

Quantização, contexto, hardware, template e retrieval alteram comportamento. Versione tudo e use o mesmo pipeline de avaliação de qualquer componente de produção. Encaminhe ao tier local apenas tarefas que atendam ao piso de qualidade.

O que eu construiria

Eu construiria um gateway de IA para workstations gerenciadas e clusters privados. Ele classificaria contexto, aplicaria política por repositório, selecionaria modelo fixado, faria retrieval com ACL, abriria worktree isolado, exporia ferramentas estreitas, escanearia o diff e exigiria aprovação para ações relevantes.

Um control plane central distribuiria manifestos de modelos, policies, extensões aprovadas, evals, revogações e schema de auditoria sem coletar código. A equipe veria quais dados ficaram locais, quais tarefas sanitizadas saíram, quais artefatos rodaram e quais ações foram aprovadas.

O princípio de design

Inferência local reduz a fronteira de dados e remove dependência do provedor. A segurança vem do controle do workflow inteiro: identidade, artefatos, rede, retrieval, ferramentas, storage, logs, qualidade e autoridade humana. “Roda na minha máquina” é condição inicial, não conclusão de segurança.