Colocar um LLM em produção sem dar autonomia a ele

A demonstração funciona. Alguém cola um documento bagunçado, o modelo extrai os campos corretamente e a sala concorda que isso tem de ir para produção.

A distância entre aquele momento e um sistema que você consegue operar por um ano não é qualidade de modelo. É o desenho ao redor dele: o que acontece quando erra, como você descobre e quem responde pelo resultado.

Comece nomeando o custo de uma resposta errada

Antes de qualquer coisa, escreva quanto custa uma única saída errada. Não a média. O pior caso realista.

Esse número determina a arquitetura inteira. Um modelo que resume anotações internas e um modelo que codifica uma guia médica são a mesma tecnologia em sistemas completamente diferentes.

Custo de uma resposta errada	Papel do modelo	Revisão
Aborrecimento leve, fácil de desfazer	Age direto	Amostragem depois do fato
Retrabalho interno, sem impacto externo	Age e sinaliza baixa confiança	Revisa a cauda sinalizada
Alguém de fora vê, ainda recuperável	Propõe, uma pessoa confirma	Toda saída, antes de sair
Move dinheiro ou cria registro regulado	Propõe, uma pessoa edita e assina	Toda saída, com trilha de auditoria
Irreversível ou juridicamente vinculante	Só apoia	O modelo nunca produz o artefato

Repare que nenhuma linha diz "quando o modelo for preciso o bastante, tire a pessoa". Acurácia move você para baixo na coluna de revisão; não move para cima na coluna de autonomia. Um modelo 99% preciso num processo irreversível ainda produz uma catástrofe a cada cem execuções.

O limiar é uma decisão de negócio

A maioria dos sistemas com LLM em produção precisa de um sinal de confiança para que os casos incertos sejam encaminhados a uma pessoa. Onde esse limiar fica não é escolha de engenharia, e tratar como se fosse é como esses projetos dão errado.

O limiar é uma troca entre dois custos:

• Abaixo do limiar, o trabalho vai para um humano. Isso tem custo conhecido por item e uma fila.
• Acima do limiar, o trabalho passa sem conferência. Isso tem custo desconhecido por erro e uma taxa.

Definir o limiar significa alguém com autoridade orçamentária decidir quantos erros por mil são aceitáveis, dado o que cada erro custa. O papel da engenharia é medir as duas curvas e apresentá-las. Não é escolher o número.

Confiança não é o que o modelo diz sobre si

Perguntar a um modelo o quanto ele está confiante produz um número que parece probabilidade e não é. Modelos são sistematicamente confiantes demais, e esse número correlaciona mais com a fluência da resposta do que com o acerto dela.

Sinais mais confiáveis, em ordem aproximada de utilidade:

1. Concordância entre execuções independentes. Mesma entrada, amostragem diferente ou enunciado diferente. Discordância é sinal forte de caso incerto.
2. Verificabilidade contra a fonte. Se o modelo extraiu um valor, esse valor aparece na entrada? Campo extraído que não existe no documento é alucinação, por mais confiante que algo alegue estar.
3. Validação estrutural. A saída faz parse, o total fecha, o código existe na tabela, a data é plausível. Barato, determinístico, e pega uma parcela surpreendente das falhas.
4. Distância da distribuição de treino. Entradas diferentes de tudo o que o sistema já viu merecem uma pessoa, independentemente do que o modelo produziu.

Os três primeiros custam chamadas extras ou código extra. Esse custo é o preço de saber a hora de parar.

O que a revisão humana precisa efetivamente pegar

"Uma pessoa confere" só é um controle se a pessoa tiver como pegar o erro. Três detalhes de desenho decidem se a revisão é real:

Mostre a evidência, não só a resposta. Um revisor que vê o valor extraído com link para a linha de origem confere em segundos. Um revisor que vê só o valor pode apenas adivinhar.

Faça a ação correta ser tão rápida quanto a preguiçosa. Se aprovar é um clique e corrigir é um formulário, você vai receber aprovações. O caminho de edição precisa ser pelo menos tão rápido quanto o de aceite.

Meça a discordância dos revisores. Se os revisores aprovam 100% do que veem, revisão não está acontecendo. Esse número é o melhor sinal de que o controle é real, e vale alertar sobre ele.

Registro, porque vão perguntar

Em algum momento alguém vai perguntar por que o sistema produziu determinada saída em determinado dia. Se você não souber responder, o sistema não deveria estar num processo regulado.

No mínimo, por decisão: a entrada, o modelo e a versão, a versão do prompt, a saída crua, o sinal de confiança, a decisão de roteamento e, quando uma pessoa tocou, quem foi e o que mudou. Retenção suficiente para cobrir a sua janela de auditoria.

É aqui também que o tratamento de dados fica específico: o que vai para o provedor do modelo, se pode ser usado em treino e por quanto tempo fica guardado. A nossa posição sobre isso está escrita na política de IA, e os controles de acesso em volta nas práticas de segurança.

Decisões que um modelo não deveria assumir

Independentemente da acurácia, algumas decisões não deveriam ficar atrás de um modelo, porque a falha não é corrigível depois:

• Qualquer coisa que encerra uma relação: negativa de atendimento, encerramento de conta, desligamento.
• Qualquer coisa que cria registro legal ou regulado sem um signatário nomeado.
• Qualquer coisa em que a pessoa afetada tem direito a uma explicação que você não consegue produzir.

Nesses casos o modelo pode preparar, resumir ou rascunhar. Uma pessoa decide e assina. Isso não é conservadorismo, é o único desenho em que a responsabilidade tem onde pousar.

Se o processo em volta é na verdade automação de tela e não decisão, o balanço é outro: veja RPA ou integração por API. E se o modelo precisa de dados de um sistema que ninguém pode mudar, isso é primeiro um problema de camada anticorrupção.