IA local: quando o modelo pequeno ganha da API

A discussão sobre IA nas empresas quase sempre assume um formato só, e ele não é IA local: mandar texto para uma API, receber texto de volta e pagar por token. Isso funciona bem para uma parte do trabalho e é desproporcional para outra.

Boa parte do que se pede a um modelo dentro de uma operação não é escrever. É decidir. Este chamado é de qual fila? Este alerta merece atenção? Este documento é contrato ou nota fiscal? Este texto é reclamação ou dúvida?

Decisão e geração são problemas diferentes, e tratar os dois com a mesma ferramenta é o que faz a conta de IA crescer sem que a qualidade acompanhe.

A pergunta que separa os dois mundos

Antes de escolher modelo, classifique a tarefa. A pergunta é: a resposta certa está numa lista fechada?

As duas primeiras linhas costumam representar a maior parte do volume numa operação e a menor parte do valor por resposta. É exatamente o perfil em que pagar por token e esperar pela rede é o pior arranjo possível.

Os três ganhos da IA local, na ordem em que aparecem

Custo por decisão

Numa tarefa de decisão, o que você precisa de volta é um rótulo e um grau de confiança. Enviar isso para um modelo de geração significa pagar pelo processamento de um modelo grande para produzir uma palavra.

Em volume baixo, ninguém percebe. Em triagem contínua, com milhares de eventos por dia, a diferença aparece na fatura mensal e cresce junto com a adoção.

Latência

Chamada de rede tem custo em tempo que não depende do modelo: resolução de nome, conexão, fila do fornecedor. Para uma resposta que o usuário vai ler, isso não importa. Para uma decisão que entra no meio de um fluxo automático, importa muito, e a diferença entre centenas de milissegundos e poucos milissegundos muda o que é possível fazer.

O dado que não pode sair

Esse é o argumento que destrava conversa comercial travada. Existe um conjunto de clientes, especialmente em saúde, jurídico, setor público e indústria, cuja objeção não é preço nem qualidade: é a cláusula que proíbe enviar dado para fora do ambiente.

Para esse cliente, modelo local não é otimização, é a condição de existir o projeto. E vale a sinceridade sobre o alcance: rodar local resolve a saída do dado, e não substitui controle de acesso, registro e retenção, que continuam sendo o assunto de sempre em política de uso de IA na empresa.

Onde isso encosta em cibersegurança

O caso de uso mais concreto hoje é triagem. Um centro de operações recebe muito mais evento do que consegue analisar, e a maior parte da fila é repetição.

Um modelo pequeno que responde "isto se parece com falso positivo, confiança 0,82" resolve um problema de volume sem inventar nada, porque ele escolhe entre opções dadas em vez de redigir uma conclusão. O desenho que funciona tem duas regras:

• Abaixo de um limiar de confiança, vai para humano. O valor exato se calibra com o histórico, e a regra existe justamente para que o modelo não decida onde ele não sabe.
• A decisão fica registrada com a pontuação. Sem isso não há como medir se o modelo está ajudando ou empurrando erro para frente.

É o mesmo raciocínio dos estágios descritos em agentes de IA no SOC: autonomia cresce por classe de tarefa, com o veredicto comparado antes de virar ação.

A parte que os posts de IA local não contam

Existe um entusiasmo com modelo local que costuma omitir o trabalho.

1. Desempenho antes do ajuste costuma ser ruim. Modelo pequeno genérico acerta pouco na sua tarefa específica. O salto vem do ajuste fino com exemplos do seu contexto, e isso exige dado rotulado, que quase sempre não existe pronto.
2. Você precisa de um conjunto de avaliação. Sem uma lista de casos com a resposta certa conhecida, não há como saber se a troca melhorou. Esse é o item que mais atrasa projetos.
3. Atualização passa a ser sua. Modelo hospedado melhora sozinho. Modelo local fica onde você deixou, e a decisão de atualizar vem com o risco de mudar comportamento em produção.
4. Hardware tem limite. Muita demonstração impressionante depende de acelerador específico de uma plataforma, e nem sempre existe leitura direta para servidor comum. Confira em que máquina o número foi medido.
5. Mistura de arquiteturas custa manutenção. Ter parte local e parte em API é o arranjo mais comum e também o que mais gera confusão sobre onde cada dado passou.

Nenhum desses pontos derruba a ideia. Eles mudam o critério de decisão: IA local compensa quando o volume é alto, a tarefa é estável e o dado é sensível. Fora dessa interseção, a API continua sendo o caminho mais barato quando se conta o tempo de quem implanta.

Como testar sem comprometer nada

Um piloto honesto leva pouco tempo e responde a pergunta:

1. Separe 200 casos reais já decididos. Chamados já classificados, alertas já triados, documentos já separados. O gabarito é o trabalho que a equipe já fez.
2. Rode o modelo local nesses casos. Sem ajuste nenhum, só para ter o piso. Para subir um modelo na sua máquina em minutos, o caminho mais curto hoje é o Ollama.
3. Ajuste com metade e avalie na outra metade. É o mínimo para não medir memorização, cuidado que vale para qualquer avaliação de modelo, como já discutido em como ler um benchmark de IA.
4. Compare os três números que decidem: acerto, custo por mil decisões e tempo de resposta.
5. Defina o limiar de confiança olhando os erros. Onde o modelo erra com confiança alta é onde o desenho precisa de revisão, e não onde ele erra com confiança baixa.

Se a comparação for contra uma API que você já usa, o resultado costuma ser claro em uma tarde. O que quase nunca é claro sem esse teste é quanto trabalho de ajuste a sua tarefa vai exigir.

O ponto que fica

A pergunta certa não é se IA local é melhor que IA na nuvem. É que tipo de tarefa você está tentando resolver.

Para escrever, analisar e raciocinar, o modelo grande hospedado continua sendo a resposta na maioria dos casos. Para decidir milhares de vezes por dia, com dado que não pode sair e com prazo em milissegundos, mandar tudo para uma API é pagar caro por uma capacidade que aquela tarefa não usa.