O piloto de IA que nunca chegou à produção: o que faltou em dados e operações

O piloto funcionou. Em um conjunto de documentos escolhidos a dedo, o modelo extraiu os campos, classificou os tickets e convenceu as pessoas que o pediram. Meses depois, ele ainda roda em um sandbox com dados de amostra, e ninguém sabe dizer o que seria preciso para ligá-lo na fila real.

Essa lacuna não se fecha trocando o modelo. Uma demo responde se um modelo consegue ler um documento. A produção pergunta o que acontece com cada documento, incluindo o digitalizado, a thread encaminhada e aquele em que o modelo erra, com dados que talvez nunca tenham tido permissão de chegar ao serviço que o piloto usou.

Uma demo prova que o modelo sabe ler; a produção quer saber de cada documento

Em 2015, Sculley e colegas do Google escreveram que apenas uma pequena fração dos sistemas de machine learning do mundo real é composta pelo código de machine learning, e que a infraestrutura necessária ao redor dele é vasta e complexa. Um pipeline de modelo de linguagem tem a mesma estrutura, e um piloto construído só com a parte pequena não tem nada ao redor para rodar em produção.

Coloque o que o piloto tinha ao lado do que a fila de produção precisa, e o trabalho que falta vira uma lista:

• Avaliação: alguns exemplos de que alguém gostou, versus um conjunto rotulado com uma nota de corte acordada por campo
• Dados: exportações, amostras ou uma API hospedada, versus fontes de produção que podem não ter permissão para sair da sua infraestrutura
• Entrada: PDFs limpos, versus digitalizações, threads de e-mail, anexos e templates que mudam sem aviso
• Saída: texto que uma pessoa leu, versus registros que outro sistema consome e nos quais precisa confiar
• Operações: um usuário por vez, versus volume de pico, indisponibilidade do servidor do modelo e um responsável depois do lançamento

Monte o conjunto de aceitação antes de mexer no modelo

O primeiro artefato que falta é um conjunto rotulado de documentos reais com a resposta que cada um deve produzir. Sem ele, cada mudança de prompt ou de modelo é julgada por quem lê a saída naquele dia, e o piloto não consegue passar por um critério de aprovação que nunca foi posto por escrito.

As Rules of Machine Learning do Google colocam a medição antes do modelo: a Rule #2 é, primeiro, projetar e implementar métricas. Para extração e roteamento de tickets, a métrica não é uma nota única para o documento inteiro:

• Colete os documentos do tráfego real ao longo de um período longo o bastante para incluir fim de mês, feriados e os remetentes que usam formatos incomuns
• Peça que as pessoas que fazem o trabalho hoje os rotulem, duas delas de forma independente em parte do conjunto, e trate as divergências entre elas como lacunas na especificação, e não como ruído
• Pontue cada campo separadamente, porque uma data errada não se compensa na média com um nome correto
• Registre por escrito a nota de corte por campo e por tipo de documento, e indique quais campos podem ser automatizados e quais sempre vão para uma pessoa
• Meça o processo manual atual no mesmo conjunto, para que o modelo seja comparado com a linha de base real, e não com a perfeição
• Mantenha parte do conjunto longe de quem ajusta os prompts, para que a nota final não seja medida nos mesmos exemplos aos quais o prompt foi ajustado

Dados que não podem sair do perímetro mudam a arquitetura, não só o fornecedor

Quando o piloto foi construído sobre um modelo hospedado com amostras, dados sintéticos ou documentos que alguém liberou manualmente, e os dados reais não podem chegar a um provedor externo, o resultado do piloto não se transfere: o modelo que roda dentro pode ser um modelo diferente, ou o mesmo modelo de pesos abertos com outra quantização e outras configurações de serving, e em qualquer caso a qualidade dele precisa ser medida de novo no conjunto de aceitação.

O modelo é o componente óbvio a trazer para dentro. Não é o único, porque um pipeline de modelo de linguagem copia os dados para mais lugares do que a chamada ao modelo:

• O servidor de inferência e os pesos do modelo, com versões fixadas
• Embeddings e o índice vetorial, que são derivados dos documentos e precisam ser protegidos como os próprios documentos
• Prompts, saídas e traces em logs, já que um prompt registrado em log contém o documento a partir do qual foi montado
• O conjunto de aceitação, a ferramenta de anotação e a fila de revisão
• Monitoramento e rastreamento de erros, que se tornam uma cópia externa dos dados quando rodam como serviço hospedado

O mascaramento ajuda onde os logs precisam sair de uma zona restrita. O Presidio, um framework open source iniciado na Microsoft, detecta e anonimiza dados pessoais em texto, e a documentação dele afirma que, como a detecção é automatizada, não há garantia de que ele encontre todas as informações sensíveis. O mascaramento reduz a exposição; não substitui manter os dados dentro.

A entrada é a metade sem glamour: digitalizações, threads e anexos

Um piloto recebe documentos; a produção recebe o que quer que os remetentes produzam. Antes de qualquer chamada ao modelo, o pipeline precisa transformar isso em texto que consiga rastrear até a origem:

• Digitalizações e fotos passam por OCR, cujos erros em dígitos e em colunas de tabela chegam ao modelo como texto sem nenhum sinal de incerteza
• Threads de e-mail e de tickets trazem respostas citadas, assinaturas e avisos legais, então a mensagem mais recente precisa ser separada do histórico
• É nos anexos que o conteúdo costuma estar, e cada formato precisa do seu próprio caminho de extração
• Cada chunk guarda a sua origem, o arquivo, a página e o offset, para que cada campo extraído possa ser rastreado até o trecho de onde veio
• Duplicatas, como um aviso encaminhado ou um ticket reaberto por e-mail, são detectadas antes de virarem dois registros

Entradas longas pedem cuidado próprio. Em Lost in the Middle, publicado na TACL em 2024, Liu e colegas mostraram que, nos modelos que testaram, o desempenho costuma ser mais alto quando a informação relevante está no início ou no fim do contexto de entrada, e cai de forma significativa quando ela está no meio de um contexto longo. Dividir um documento longo por seção, mantendo a origem em cada chunk, é um padrão mais seguro do que supor que o modelo lê o contexto inteiro de forma uniforme, e o conjunto de aceitação mostra o que vale para os seus documentos.

Saída estruturada precisa de schema, validador e um lugar para a resposta errada

A decodificação restrita (constrained decoding) limita o modelo a um JSON que corresponde a um schema: o vLLM oferece isso como structured outputs, e o llama.cpp por meio de gramáticas. Ela fixa o formato do registro, dentro dos recursos de schema que o backend suporta e desde que a geração não seja cortada pelo limite de tokens, mas não a sua veracidade: um registro bem-formado ainda pode trazer a data errada.

A veracidade é verificada depois do modelo, por código em que o negócio já confia:

• Verificações de tipo e formato: datas, moedas e identificadores com dígito verificador, como o ISIN
• Regras entre campos, como uma data de fim de período que não pode ser anterior à data de início
• Consultas a dados de referência que a empresa já mantém, como um instrumento ou um cliente conhecido
• Consistência com a origem: cada valor extraído, antes da normalização, precisa aparecer no trecho que cita

A confiança do próprio modelo é um filtro fraco. O GPT-4 Technical Report da OpenAI, publicado em 2023, mostra que, em um benchmark de múltipla escolha, o modelo pré-treinado era altamente calibrado e que o pós-treinamento reduziu a calibração. Uma certeza autodeclarada ou uma probabilidade de token é um sinal a ser testado contra o conjunto de aceitação, não um limiar em que confiar por padrão.

Um registro que falha em qualquer verificação vai para uma fila de revisão, não para o sistema a jusante. A fila é um produto por si só: precisa de um responsável, de um planejamento de capacidade em horas de revisores, do trecho de origem exibido ao lado de cada campo e de correções que voltem para o conjunto de aceitação.

Tickets e documentos são entrada não confiável para o modelo

Um ticket de suporte é um texto escrito por alguém de fora da empresa, e um documento pode trazer instruções que o remetente colocou ali de propósito. O OWASP Top 10 for LLM Applications 2025 coloca a injeção de prompt (prompt injection) em primeiro lugar, incluindo a injeção indireta, em que as instruções chegam dentro de conteúdo externo que o modelo processa, como um site ou um arquivo.

Três itens da mesma lista se traduzem em regras de design para um pipeline de documentos:

• Injeção de prompt (Prompt injection): marque cada documento e ticket como conteúdo não confiável, mantido separado das instruções em um template que o remetente não pode editar
• Tratamento inadequado da saída (Improper output handling): valide a saída do modelo antes que qualquer sistema aja com base nela, como você validaria a entrada de um usuário
• Agência excessiva (Excessive agency): dê ao pipeline o menor privilégio de que a tarefa precisa, para que um modelo que lê tickets não consiga encerrar contas nem enviar pagamentos

O OWASP também observa que não está claro se existe prevenção infalível contra injeção de prompt. Quem sustenta o peso são as verificações de saída e o limite de privilégios, não a redação do prompt.

Fixe o modelo, o prompt e o parser como uma única versão

O comportamento de um pipeline é o resultado de vários artefatos que mudam de forma independente. Trate-os como uma única release e grave o identificador dela em cada registro que ela produzir:

• Os pesos do modelo por checksum, com a quantização e a versão do servidor de inferência
• O template do prompt, o schema de saída e os parâmetros de decodificação
• O motor de OCR, as regras de chunking e os validadores
• A versão do conjunto de aceitação com a qual a release foi avaliada

Fixar versões não torna as saídas idênticas. A Thinking Machines Lab mostrou em setembro de 2025 que um servidor de inferência pode devolver completions diferentes para o mesmo prompt com temperatura zero, porque o resultado de uma requisição depende de quantas outras requisições compartilham o batch dela; o mesmo post mostra que kernels invariantes ao batch eliminam isso com um custo em velocidade. A menos que o servidor rode esses kernels, reprodutibilidade significa rodar de novo o conjunto de aceitação a cada release e comparar as notas, não esperar texto idêntico.

Operações: capacidade, filas e a hora em que o servidor do modelo cai

A capacidade é planejada em tokens, não em documentos. Meça a distribuição do tamanho de entrada e de saída no tráfego real, porque um único anexo longo pode custar tanto quanto muitos tickets curtos, e o tempo de geração cresce com o tamanho da saída.

Sistemas de serving agrupam requisições em batches para manter o acelerador ocupado. No artigo do vLLM, apresentado no SOSP 2023, Kwon e colegas relataram que paginar o cache de chave-valor da atenção melhorou o throughput de 2 a 4 vezes com o mesmo nível de latência, em comparação com os sistemas que avaliaram. Batches maiores aumentam o throughput e também aumentam a latência de cada requisição, o que uma fila de back-office consegue absorver e uma etapa interativa não, então os dois tipos de trabalho ficam separados:

• Trabalho interativo, como a triagem de tickets pela qual um agente de suporte está esperando, com capacidade própria e uma meta de latência
• Trabalho em batch, como a extração noturna, em uma fila que absorve picos e pode ser pausada
• Backpressure entre a ingestão e o servidor do modelo: uma fila limitada e um limite de concorrência, para que um pico de documentos espere ou seja recusado com um sinal de retentativa em vez de sobrecarregar o servidor
• Processamento idempotente com chave no documento, para que uma retentativa depois de uma queda não crie um segundo registro
• Um fallback para o processo manual quando o servidor do modelo está indisponível, para que o trabalho espere por uma pessoa em vez de desaparecer

O fallback é o que torna reversível ligar o pipeline. O processo manual que existe hoje continua sendo o piso, e o pipeline tira trabalho dele campo a campo, em vez de substituí-lo em uma única data.

Monitore as respostas, não só os servidores

Os dashboards dos servidores dizem se o pipeline respondeu. Não dizem se as respostas estavam certas, e um modelo que se degrada diante de um template novo mantém a mesma latência. O monitoramento de um pipeline de extração ou de tickets cobre as duas coisas:

• A taxa de envio para a fila de revisão e as correções dos revisores por campo, por tipo de documento e por release
• Uma amostra regular de registros automatizados conferida novamente por pessoas com base nos critérios de aceitação
• Drift de entrada: novos remetentes, novos templates, a mistura de idiomas e o tamanho dos documentos
• Falhas de validação por regra, que podem revelar um formato novo antes que as métricas de acurácia se mexam
• Tokens, horas de acelerador e idade dos itens na fila por tipo de documento, ao lado da latência de cada etapa

O Generative AI Profile do NIST, o NIST AI 600-1, publicado em julho de 2024, organiza esse trabalho sob as quatro funções do seu AI Risk Management Framework: govern, map, measure e manage (governar, mapear, medir e gerenciar). Os nomes importam menos do que a consequência: medir depois do lançamento é uma atividade formalmente atribuída e com pessoas alocadas, não algo que o time do piloto faz quando sobra tempo.

Faça o rollout por campo e por tipo de documento: shadow, assistido e depois automatizado

Ligar o pipeline para tudo em uma única data acopla todos os riscos em um único evento. Um rollout em etapas os mantém separados:

• Shadow: o pipeline processa o tráfego real, não grava em lugar nenhum, e os registros dele são comparados com o que as pessoas produziram
• Assistido: o pipeline pré-preenche, uma pessoa confirma cada registro e as correções são contadas por campo
• Automatizado por campo e por tipo de documento, só onde a nota de corte se mantém no tráfego real, com todo o resto ainda revisado
• Um retorno ao modo assistido por tipo de documento, que o responsável pela operação aciona sem aprovação à parte quando uma taxa monitorada ultrapassa o seu limite

Um piloto que lê bem os documentos e mesmo assim nunca chega à produção não falhou na leitura. Ele nunca recebeu um conjunto de aceitação no qual ser aprovado, um caminho de dados que tivesse permissão de usar, um lugar para as suas respostas erradas nem um responsável para o dia seguinte ao lançamento.

A empresa que entrega isso pede os seus documentos antes de perguntar que modelo você prefere

A pergunta por trás deste artigo, quem consegue colocar um pipeline de LLM dentro da sua própria infraestrutura e de fato levá-lo à produção, tem um teste que não precisa de uma lista de fornecedores. Uma empresa que faz esse trabalho pergunta sobre aceitação e operações antes de recomendar um modelo:

• Pede para revisar uma amostra de documentos e tickets reais, incluindo os ruins, dentro do seu ambiente ou sob o seu acordo de dados, e pergunta como o processo manual lida com eles hoje
• Propõe construir primeiro o conjunto de aceitação com o seu pessoal, com notas de corte por campo, antes de qualquer ajuste
• Lista cada lugar para onde os dados serão copiados, dos pesos e índices a logs, traces, dados de avaliação, a ferramenta de revisão e o monitoramento, e mostra que cada um fica dentro
• Coloca os validadores, a fila de revisão e o fallback para o processamento manual no mesmo documento de design que o modelo
• Traz uma release que fixa modelo, prompt, schema e parser juntos, e um rollout por campo que vai de shadow a automatizado
• Nomeia quem opera o pipeline depois do lançamento, quem revisa a amostra e quem é acionado quando o servidor do modelo para

Cada item é algo sobre o que você pode perguntar na primeira conversa, e uma resposta vaga significa que o trabalho que faltou no piloto ainda não teve o escopo definido.

Então a primeira pergunta não é qual modelo rodar dentro do seu perímetro. É quais campos, em quais documentos, você aceitaria automatizados, medidos contra o quê, e quem assume os registros que falham na validação.

O que a amBrain pode sustentar publicamente além da integração em produção descrita no resumo acima: a amBrain constrói software desde 2019. Trabalhamos em três formatos: entrega completa, time dedicado ou engenheiros embarcados no seu time.