IA offline para plataformas de mensageria: por que os modelos locais importam

Quase todo recurso de IA em software de mensageria hoje funciona como um serviço alugado. Ele roda nos servidores de outra empresa, é cobrado de acordo com os preços de outra empresa e só funciona enquanto a conexão entre as suas instalações e as dela se mantiver ativa. Para a maioria dos compradores, é uma troca aceitável. Para um banco que opera uma plataforma de mensageria dentro de uma DMZ, para um órgão de governo em um ambiente isolado da rede (air-gapped) ou para um revendedor em um mercado cuja moeda variou 30% neste ano, é inviável. Este guia trata do que realmente acontece quando você retira a nuvem da equação: o que um modelo local (on-premise) consegue fazer de fato, o que ele não consegue, e o padrão de projeto que permite ter as duas opções sem apostar o produto em nenhuma delas.

Por que a IA em nuvem é inviável em implantações em DMZ e reguladas

Existem três barreiras distintas, e os compradores costumam encontrá-las nesta ordem.

A barreira da rede. Uma plataforma de mensageria que faz a terminação de OTPs para um banco não fica exposta na internet aberta. Ela fica em uma DMZ, ou em uma camada ainda mais interna, com uma política de firewall escrita por alguém cuja função é dizer não. Uma saída HTTPS para um fornecedor de IA não é uma simples opção a marcar: é uma solicitação de mudança, uma revisão, um registro na matriz de riscos e, no caso de um ambiente isolado da rede, é simplesmente impossível, porque não existe nenhuma rota de saída da sala. Qualquer recurso que dependa de comunicação com servidores externos é um recurso que não existe para esse cliente. Isso não é hipotético nem raro: é o formato normal das contas mais valiosas deste setor.

A barreira dos dados. Mesmo onde existe uma rota, o problema é o conteúdo. Uma solicitação de reescrita leva o corpo da mensagem, e o corpo da mensagem é o nome de um cliente, uma referência de conta, uma senha de uso único, um aviso de débito, uma consulta médica. Enviar isso a um terceiro significa responder a perguntas sobre acordos de tratamento de dados, suboperadores, retenção, jurisdição e transferência internacional, para cada mensagem, indefinidamente. Algumas dessas perguntas têm boas respostas. Em um mercado regulado, “o texto nunca sai do prédio” é uma conversa muito mais curta do que qualquer uma delas.

A barreira comercial. O preço da IA em nuvem é uma decisão tomada na diretoria de outra empresa. As tarifas mudam, os planos gratuitos são encerrados, os modelos são descontinuados em um cronograma que você não define, e uma chave pode ser revogada ou ter o volume limitado em qualquer dia, sem aviso. Se o principal recurso do seu produto depende disso, você construiu um negócio sobre uma dependência que não controla. Os operadores de mercados emergentes sentem isso com mais força, porque um preço em USD e uma receita em moeda local não variam juntos.

Nenhuma dessas barreiras significa que a IA está descartada. Significa que a IA precisa ser capaz de funcionar dentro das suas instalações.

O que os modelos locais realmente podem, e não podem, fazer

Aqui a honestidade importa mais do que o entusiasmo, porque é na distância entre o discurso de marketing e a capacidade real da máquina que os projetos fracassam.

O que eles fazem bem. Um modelo pequeno ajustado para instruções, algo na faixa de 3 a 8 bilhões de parâmetros, quantizado e servido localmente via llama.cpp ou Ollama em CPU comum, é realmente bom em trabalho de texto bem delimitado. Reescrever uma mensagem para torná-la mais cordial, mais curta ou mais formal. Corrigir tom e gramática. Redigir uma tradução para uma pessoa aprovar. Responder a uma dúvida de suporte com base em um documento recuperado. Classificar a intenção para um chatbot e produzir uma resposta curta, em estilo de roteiro. São exatamente as tarefas de que uma plataforma de mensageria precisa, e todas têm o mesmo formato: entrada curta, saída curta, tarefa restrita e uma pessoa por perto.

O que eles fazem mal. Raciocínio longo, com várias etapas. Manter a coerência de um contexto grande e complicado. Redação criativa com nuances que precisa sair perfeita na primeira tentativa. Qualquer tarefa em que a diferença entre uma resposta boa e uma excelente valha dinheiro de verdade. Um modelo de ponta em nuvem é significativamente melhor em tudo isso, e fingir o contrário não ajuda ninguém.

A restrição que as pessoas esquecem: velocidade. Um modelo local em CPU produz cerca de 10 a 25 tokens por segundo. Uma reescrita de 200 tokens, portanto, leva algo entre 8 e 20 segundos. Para um usuário que clica em “reescrever” e aguarda, isso é aceitável. Para um chatbot ao vivo atendendo clientes em volume, fica no limite, e é nesse ponto que você adiciona uma GPU modesta, mantém as respostas curtas ou direciona esse recurso específico para um motor em nuvem. Nenhuma otimização transforma uma CPU em um data center.

A consequência prática. Projete seus prompts com base no modelo nativo, não no de nuvem. O nativo é o motor mais fraco que você vai executar, e isso faz dele o patamar mínimo: se um prompt gera uma resposta utilizável nele, vai gerar uma resposta utilizável em qualquer motor. Se você ajustar os prompts para um modelo de ponta e depois houver fallback para o nativo, esse fallback será o momento em que o seu recurso apresenta resultados ruins diante do cliente, e isso vai acontecer na pior hora possível. Construa com base no patamar mínimo e toda melhoria será um ganho adicional.

O padrão de seleção de motor: nativo por padrão, sua chave como opção

O erro é tratar isso como uma escolha binária. Local ou nuvem, escolha um e conviva com ele. A melhor resposta é transformar o motor em uma configuração e a interface em um contrato.

No projeto de IA offline do Smppcube, o administrador escolhe o motor uma única vez nas configurações globais. Os modelos locais nativos são o padrão e estão sempre disponíveis. Um provedor de nuvem com a chave do próprio administrador é opcional, para as implantações que querem mais capacidade e têm uma rota para a internet. Todos os recursos que dependem dele (reescrita, tradução, chatbot, jornadas, textos de campanha, RAG) chamam uma única interface interna e não sabem, nem precisam saber, o que está por trás dela. Altere a configuração e todos os recursos acompanham a mudança de uma vez, sem nenhuma reconfiguração.

Três detalhes fazem isso funcionar na prática, e não apenas em uma apresentação.

Um único formato, construído sobre o padrão. A interface segue o contrato de chat-completions compatível com a OpenAI, que atende o servidor nativo e a grande maioria dos provedores com um único caminho de código. A Anthropic recebe um único adaptador adicional. Essa é toda a superfície de integração, e é por isso que adicionar um provedor é uma alteração de configuração, e não um projeto.

Embeddings são uma configuração separada. Recuperação e chat são tarefas diferentes, com estruturas de custo diferentes, e o modelo de embeddings é escolhido independentemente do modelo de chat. Você pode executar a recuperação no nativo, sobre os seus próprios documentos, enquanto direciona o chat para um motor em nuvem, ou o inverso, e trocar um nunca afeta o outro.

O fallback é o patamar mínimo de segurança. As chaves são criptografadas em repouso, mascaradas nos logs e limitadas por um teto rígido de gastos por motor. Quando o teto é atingido, quando o provedor sofre uma interrupção, quando a conexão cai, a plataforma volta automaticamente para o nativo e o recurso continua funcionando. Ninguém precisa ser acionado fora de hora, e nenhuma tela para de funcionar. É essa peça que torna segura a escolha da nuvem: você não está confiando a sua disponibilidade ao fornecedor, está usando a capacidade dele com uma garantia mínima por trás.

E um limite que vale a pena deixar bem claro: aqui a IA é assistiva, não autônoma. As campanhas continuam dependendo de aprovação humana. As respostas do RAG têm uma proteção do tipo “não está na documentação” em vez de inventar algo plausível. Um modelo offline que inventa informações com convicção é pior do que nenhum modelo, e essa proteção importa ainda mais quando o modelo é pequeno.

A única tarefa que é sempre nativa: spam

Existe exatamente um recurso de IA que nunca tem escolha de motor, e o motivo é instrutivo.

A verificação de spam roda no caminho crítico das mensagens. Todas as mensagens passam por ela, o que significa que a verificação precisa ter custo praticamente nulo e nunca pode esperar por um salto de rede. No Smppcube, ela usa fastText e regras, roda em cerca de um décimo de milissegundo e nunca usa um LLM. Com 3.000.000 de mensagens por mês, uma chamada de 200 ms para a nuvem a cada mensagem não é um problema de custo, é um problema físico: sua vazão despenca e sua fila se acumula atrás da latência de um terceiro.

A política importa tanto quanto o mecanismo: sinalizar, não bloquear. O filtro marca o que parece spam e deixa a decisão de envio com você. Um falso positivo que interrompe silenciosamente o tráfego de OTP de um cliente é um erro muito mais caro do que uma mensagem sinalizada que uma pessoa confere rapidamente. Essa é a regra geral da IA em um caminho crítico, e é por isso que o classificador offline, rápido e simples é a ferramenta certa, e não o mais impressionante.

Os custos, com honestidade

Deixe de lado as afirmações vagas de que “IA é cara” e faça as contas, porque a resposta é de fato diferente em cada volume.

O uso assistivo leve é barato na nuvem. Cinquenta usuários de clientes, cada um fazendo quarenta reescritas por dia, geram cerca de 60.000 chamadas por mês. Com aproximadamente mil tokens por chamada, são 60 milhões de tokens, o que em um modelo intermediário fica em torno de US$ 30 a US$ 60 por mês. Quem afirma que só a conta de tokens justifica adotar o nativo nesse volume está tentando vender alguma coisa. Nessa escala, você adota o nativo por causa da DMZ e dos dados, não da fatura.

Os chatbots mudam o cenário. Agora coloque um chatbot com RAG para atender o tráfego de entrada. Vinte mil conversas por mês, com seis turnos cada, são 120.000 chamadas, e cada uma leva contexto recuperado, digamos 4.500 tokens somando entrada e saída. São cerca de 540 milhões de tokens por mês, aproximadamente US$ 200 a US$ 400 conforme o modelo, ou US$ 2.400 a US$ 4.800 por ano. A parte desconfortável é a tendência: essa conta cresce sempre que o negócio cresce, então o sucesso aumenta os seus custos justamente no trimestre em que você queria a margem.

O nativo não tem cobrança por uso. O custo de uma chamada nativa é zero. O custo do nativo é o servidor: um servidor existente com capacidade sobrando, ou cerca de US$ 40 a US$ 80 por mês de capacidade adicional, um valor fixo, quer você faça mil chamadas ou um milhão. Ao lado de uma licença de plataforma com pagamento único que já roda no seu próprio hardware, seguindo a mesma lógica de alugar ou ser dono do guia do gateway self-hosted, o item de IA deixa de ser um custo variável e passa a fazer parte da máquina que você já comprou.

O resumo honesto: no uso leve, escolha o nativo pela soberania e a nuvem pela qualidade, e a diferença em dinheiro é irrelevante em qualquer dos casos. Em volumes de chatbot, o nativo é significativamente mais barato e, mais importante, previsível. É a previsibilidade que permite oferecer a um cliente um preço válido por um ano.

Como escolher com honestidade

Se a sua implantação tem uma rota direta para a internet, nenhuma restrição de residência de dados, e você quer o melhor resultado possível em algumas tarefas de alto valor, use um motor em nuvem com a sua própria chave. É uma boa decisão, e o padrão descrito acima a suporta totalmente. Use o nativo para spam e recuperação, a nuvem para a redação, e mantenha o fallback ativo.

Priorize o nativo quando qualquer uma destas condições for verdadeira: sua plataforma roda em uma DMZ ou em um ambiente isolado da rede, seus clientes perguntam sobre suboperadores antes de perguntar sobre preço, sua receita está em uma moeda que não acompanha o USD, ou o seu volume de IA tem o perfil de um chatbot e está crescendo. E priorize o nativo, em qualquer caso, se você entrega um produto a clientes cujos ambientes você não controla, porque um recurso que precisa de uma rota para a internet é um recurso que, sem que ninguém perceba, não existe para uma parte do seu mercado.

O que vale a pena garantir no projeto não é a escolha entre local e nuvem. É que a escolha pertença a quem é dono dos servidores, que seja uma configuração e não uma reconstrução, e que o patamar mínimo por baixo dela sempre se mantenha. Desconecte o cabo e a IA continua funcionando. Todo o resto é uma questão de preferência.