Sem time de ML: quem opera depois do lançamento um sistema de LLM para tickets de suporte e documentos nos seus próprios servidores

Um sistema de LLM que classifica tickets de suporte e lê documentos nos seus próprios servidores continua precisando de alguém que o opere depois do lançamento. LLM é a sigla em inglês de modelo de linguagem grande, o tipo de IA por trás do ChatGPT. Uma empresa sem time de machine learning (ML) tem três caminhos. A empresa que construiu o sistema pode continuar operando-o sob um contrato de suporte. Depois de uma transição, o seu time de TI pode assumi-lo no lugar dela ou dividir o trabalho com ela. Em qualquer caminho, alguém precisa verificar a qualidade das respostas com uma periodicidade definida e aprovar cada troca de modelo antes de ela entrar em produção.

O que envolve operar um sistema de LLM depois do lançamento?

Depois do lançamento, operar um sistema de LLM se resume a estas tarefas recorrentes:

• Os servidores, que muitas vezes têm GPUs (os chips em que os modelos de linguagem rodam), e as atualizações do software que roda o modelo
• A versão do modelo em uso e a decisão de quando trocá-la
• A pontuação periódica das respostas em uma amostra fixa dos seus próprios tickets e documentos
• A fila de revisão, ou seja, os itens que o software passa para uma pessoa, e a equipe que trabalha nela
• Mudanças do seu lado, como um novo formulário, uma nova categoria de ticket ou uma nova regra de negócio
• Os logs, que registram o que o sistema fez, e os direitos de acesso aos tickets e documentos
• Falhas de madrugada e a pessoa que é acionada

O vLLM é um programa de código aberto para rodar modelos nos seus próprios servidores. A página de segurança dele no GitHub, consultada em 20 de outubro de 2026, lista um alerta de 6 de outubro de 2026 sobre uma falha corrigida na versão 0.31.0. O título do alerta diz: “Um min_tokens grande demais em uma única requisição trava o motor do vLLM enquanto o /health continua verde”. Nesse título, min_tokens é uma configuração da requisição que define o tamanho mínimo da resposta.

Uma ferramenta de monitoramento consulta um endereço como /health para ver se um servidor está vivo. No caso descrito no alerta do vLLM, o servidor parece saudável mesmo tendo parado de responder às requisições. O monitoramento de um sistema de LLM deve enviar requisições de teste reais e verificar se as respostas voltam.

Em que o nosso próprio sistema difere de uma ferramenta de helpdesk com IA embutida?

Com uma ferramenta de helpdesk vendida como software como serviço (SaaS), uma ferramenta que você aluga pela internet, o fornecedor opera o serviço, e o modelo roda nos servidores do fornecedor ou nos de empresas com que ele trabalha. Os seus tickets vão para o fornecedor e para essas empresas. O artigo sobre software de IA para documentos ou pipeline de LLM sob medida trata da escolha entre uma ferramenta assim e um sistema próprio.

A Zendesk, uma fornecedora de helpdesk, diz na sua página sobre IA generativa, consultada no mesmo dia, que “a Zendesk integra LLMs aos Serviços de duas maneiras”. Uma usa modelos hospedados em plataformas “como AWS Bedrock, Microsoft Azure, Groq ou Fireworks AI”, e a Zendesk diz que, nesse caso, “o provedor do LLM nunca acessa os seus Dados de Serviço”. A outra usa modelos “hospedados diretamente pelo provedor do modelo”, como OpenAI e Google Gemini. Para esses, a Zendesk diz que o texto enviado ao modelo e as respostas dele “não são mantidos em nenhum mecanismo de registro”.

A Intercom, outra fornecedora de helpdesk, publica uma lista de subprocessadores, as empresas que tratam dados em nome dela. A lista, em vigor desde 25 de junho de 2026 e consultada no mesmo dia, cita OpenAI, Anthropic, Google e Microsoft, entre outras, para “processamento de IA”. A página diz que as listas “podem ser atualizadas pela Intercom de tempos em tempos”.

A empresa que construiu o nosso sistema de LLM pode continuar operando-o?

A empresa que construiu o sistema pode oferecer um contrato de suporte, pelo qual ela mantém o sistema funcionando depois do lançamento. Verifique o que o contrato diz sobre estes pontos:

• O que conta como incidente, como o sistema parar ou um campo ser lido errado em muitos documentos, e com que rapidez alguém responde a cada tipo
• Quem pode entrar nos seus servidores, por quais contas, e como esse acesso é registrado
• Quem paga pelos servidores e quem decide quando é preciso mais capacidade
• O que é uma solicitação de mudança, como acrescentar um tipo de documento ou uma categoria de ticket, e como ela é cobrada
• Quais relatórios você recebe todo mês, como notas de qualidade, volumes da fila de revisão e incidentes

Deixar a empresa no comando é o que menos exige da sua equipe. O know-how fica então com a empresa, e você depende dela para a maioria das mudanças. O que deve ser seu quando a empresa sair é assunto do artigo sobre as perguntas que um COO deve fazer antes de assinar.

O nosso time de TI não tem experiência com ML. Ele pode assumir o sistema?

Um time de TI que já opera os servidores da sua empresa normalmente consegue incluir no seu trabalho os servidores, os direitos de acesso, os backups e o monitoramento do sistema de LLM. As tarefas específicas de modelos de linguagem, como interpretar as notas de qualidade e testar uma nova versão do modelo, exigem treinamento antes.

Para a transição, o time de TI precisa de runbooks, guias passo a passo para as tarefas diárias e para cada falha conhecida, como a fila de revisão lotar. O time também precisa da amostra de teste dos seus tickets e documentos com as respostas corretas e do script que pontua o sistema com base nela. O código e os arquivos do modelo devem ficar em um armazenamento que a sua empresa controla.

Um ambiente de teste, uma cópia do sistema em que as mudanças são testadas antes de chegarem aos tickets reais, deve existir antes do lançamento. O treinamento pode acontecer ali: o seu time faz as tarefas de rotina na cópia, e os engenheiros da empresa conferem o trabalho.

As mudanças de prompt e de regras precisam de um responsável. Um prompt é o texto que diz ao modelo o que fazer. Quando um formulário muda ou surge uma nova categoria de ticket, alguém precisa atualizar o prompt ou as regras e pontuar a amostra de teste de novo. Decida se essa pessoa fica na TI, na empresa contratada ou no time dono do processo, como o suporte.

Como funcionaria uma divisão entre o nosso time de TI e a empresa?

Em uma divisão, o seu time de TI fica com os servidores e os acessos, e a empresa é chamada para mudanças de modelo e problemas de qualidade.

Uma divisão pode deixar uma lacuna. Quando a qualidade cai, a TI pode culpar o modelo enquanto a empresa culpa os servidores, então o contrato deve dizer por escrito quem decide o quê.

Por exemplo, a sua empresa aprova cada nova versão do modelo depois que a empresa contratada a pontuou na amostra de teste. Corrigir um problema de qualidade cabe à empresa contratada, enquanto o acesso aos servidores continua sendo decisão do seu time de TI. Defina também a pessoa que olha primeiro quando um alerta dispara de madrugada e como ela aciona o outro lado.

Por que a qualidade das respostas às vezes cai depois do lançamento?

A acurácia pode sofrer deriva (drift), ou seja, mudar devagar sem nenhuma mensagem de erro. Novos assuntos de tickets depois do lançamento de um produto, um formulário alterado ou uma nova versão do modelo podem, cada um, causar deriva. Os servidores continuam rodando como antes, então o monitoramento dos servidores não mostra a queda.

A deriva aparece quando a mesma amostra dos seus tickets e documentos com as respostas corretas é pontuada de novo. Isso deve acontecer com uma periodicidade definida, por exemplo todo mês, e depois de cada mudança no modelo, no prompt ou nas regras. Compare cada nota com a registrada no lançamento.

Os artigos sobre um piloto de IA travado e sobre as perguntas para um COO explicam como montar a amostra de teste. Seja qual for o caminho escolhido, o contrato deve nomear a pessoa que refaz a pontuação e dizer quem vê os resultados.

Quem decide quando o modelo muda?

Com um modelo de pesos abertos nos seus próprios servidores, a sua empresa decide quando trocar. Um modelo de pesos abertos é aquele cujo criador publica os arquivos do modelo para qualquer pessoa baixar e rodar sob a licença dele. A licença continua valendo, e uma versão mais nova pode vir com outra.

Os modelos Gemma, do Google, são um exemplo. A página do Gemma 3 no Hugging Face, o site de modelos, consultada no mesmo dia, remete aos Gemma Terms of Use, os termos de uso do Gemma, que incorporam uma Prohibited Use Policy, uma política de uso proibido. O blog de código aberto do Google disse em 2 de abril de 2026 que “os modelos Gemma 4 são os primeiros do Gemmaverse a serem lançados sob a licença Apache 2.0, aprovada pela OSI.” Passar do Gemma 3 para o Gemma 4 muda, portanto, a licença que os seus advogados leem: dos termos próprios do Google para a Apache 2.0, uma licença de código aberto.

Um sistema nos seus próprios servidores ainda pode chamar um modelo por uma API hospedada, uma conexão pela internet com os servidores de outra empresa. Esse modelo é aposentado no cronograma dessa empresa. A página de descontinuação de modelos da Anthropic (model deprecations), consultada no mesmo dia, diz: “Requisições a modelos que passaram da data de aposentadoria vão falhar.” A Anthropic diz que dá aos clientes com implantações ativas “aviso prévio de pelo menos 60 dias antes da aposentadoria de modelos lançados publicamente”. A página acrescenta que as datas dela valem para as plataformas da própria Anthropic e que o Amazon Bedrock e o Google Cloud “definem os próprios cronogramas de aposentadoria”.

Cada troca significa pontuar a nova versão na sua amostra antes de ela entrar em produção, com a versão antiga pronta caso as notas caiam. A página da Anthropic sugere “testar a fundo os seus aplicativos com os novos modelos bem antes da data de aposentadoria.”

Um ticket de suporte pode enganar o sistema?

Injeção de prompt (prompt injection) é um ataque em que o texto enviado ao sistema traz instruções dirigidas ao modelo. Os tickets de suporte vêm de fora da sua empresa, então um sistema que os lê continua exposto enquanto roda. O OWASP Top 10 for LLM Applications 2025, uma lista de riscos publicada pelo projeto de segurança OWASP e consultada no mesmo dia, coloca a injeção de prompt em primeiro lugar. Um exemplo diz: “Um invasor injeta um prompt em um chatbot de atendimento ao cliente, instruindo-o a ignorar as diretrizes anteriores, consultar repositórios de dados privados e enviar e-mails, o que leva a acesso não autorizado e escalonamento de privilégios.”

As regras de design contra injeção de prompt, como não dar ao sistema mais acesso do que a tarefa dele exige, estão no artigo sobre o piloto travado. O OWASP também lista uma medida para repetir enquanto o sistema roda: “Realizar regularmente testes de penetração e simulações de violação, tratando o modelo como um usuário não confiável”. Teste de penetração significa testadores tentando invadir de propósito, com a sua permissão.

Os testes de penetração entram no cronograma das tarefas de operação, e o contrato deve dizer qual lado os contrata e corrige o que eles encontrarem. Os logs podem guardar o texto completo dos tickets, então decida quem pode lê-los e por quanto tempo eles são mantidos.

Quanto vai custar operar o sistema por mês, e o que devemos perguntar antes de assinar?

Nos seus próprios servidores, os custos mensais começam pelos servidores e pelas GPUs deles, comprados ou alugados, e pelo tempo da equipe na fila de revisão. Um contrato de suporte se soma a eles se a empresa mantiver algum papel, e o mesmo vale para os novos testes depois de cada mudança. O artigo não traz números, porque cada um depende dos seus volumes e da sua configuração.

A composição dos custos depende do caminho escolhido. Com a empresa operando o sistema, boa parte do custo está no contrato de suporte. Depois de uma transição, uma parte maior é tempo dos seus próprios funcionários, incluindo o treinamento.

Faça as mesmas perguntas a todas as empresas que se oferecem para construir e operar o sistema:

• Quais tarefas de operação vocês vão assumir depois do lançamento, e quais ficam com o nosso time de TI?
• Com que frequência vocês vão pontuar o sistema na nossa amostra de teste?
• Quem paga pelos novos testes quando uma versão de modelo que usamos for aposentada?
• O que o nosso time de TI recebe na transição, e como vocês vão verificar se ele consegue operar o sistema sozinho?

Os termos de licença variam de um modelo para outro, e as regras de proteção de dados variam por país. Este artigo não é aconselhamento jurídico, então confira com um advogado os termos que se aplicam a você.

Onde a amBrain se encaixa?

O único projeto com modelo de linguagem que a amBrain descreve publicamente é este: “Levamos à produção uma integração de LLM dentro do perímetro de FinTech de um cliente: extração e normalização de avisos não estruturados de corretoras e de venues — eventos corporativos, alterações de instrumentos e de margem — em registros estruturados que o sistema de trading consome.”

Este artigo não é um estudo de caso e não descreve nenhum trabalho para clientes. A frase citada não diz quem opera esse sistema hoje, onde o modelo dele roda nem quais etapas deste artigo ele incluía. Os tickets de suporte, os documentos e os caminhos de operação deste artigo são exemplos gerais e não foram tirados desse projeto nem de nenhum outro trabalho da amBrain.

Os fornecedores, os criadores de modelos e os projetos de software citados aqui são exemplos tirados de páginas publicadas, e o artigo não afirma nenhuma relação entre a amBrain e qualquer um deles. O artigo não traz preços, prazos nem condições da amBrain.

A amBrain constrói software desde 2019. Ela trabalha em três formatos: entrega completa, time dedicado ou engenheiros embarcados no seu time. A frase dela sobre propriedade é: “O cliente mantém a propriedade integral do produto e do código, exceto dos nossos componentes reutilizáveis.” Se a amBrain estiver na sua lista curta, faça a ela as mesmas perguntas que a qualquer outra empresa.