Eu entrego funcionalidades de IA. Depois eu provo que funcionam.

Ninguém quer conversar com a própria fila de feedback. O valor é determinístico: classificar, resumir, rotear, alertar. Uma interface de chat adicionaria latência e removeria a possibilidade de auditoria.

Cenário no Make, quatro passos de ponta a ponta (veja a fig. 1). Cada passo pode ser reexecutado isoladamente.

Nenhuma necessária. Cada mensagem é classificada de forma independente. Evitado deliberadamente: a ausência de estado mantém o pipeline depurável.

A IA nunca responde diretamente a um cliente. Ela roteia para um humano com um resumo; o email de alerta é o handoff. Ela não resolve nada sozinha.

Schema de saída estruturada na etapa de LLM, rótulo de fallback em caso de falha de parsing, e a mensagem bruta sempre registrada junto com a classificação.

Um golden set de mensagens rotuladas, rodado toda noite pelo Promptfoo, para capturar desvio de classificação quando a versão do modelo muda.

Um wrapper de chat sobre o corpus era a construção óbvia. A necessidade real era um dashboard operacional: fontes, jobs de ingestão, execuções de avaliação e feedback, tudo inspecionável. O Q&A é apenas uma funcionalidade dentro dele.

API em FastAPI + worker de ingestão durável alimentando a fig. 1; um gateway de provedor troca embeddings determinísticos locais pelo Gemini conforme o ambiente. Dashboard em React por cima.

Consultas, respostas e citações persistidas. Excluir uma fonte propaga em cascata: chunks, embeddings, jobs, payloads, citações. Nenhuma memória órfã.

Um endpoint de feedback no nível da resposta alimenta um loop de revisão; as execuções de avaliação são disparadas e persistidas via API, para que um humano aprove antes que mudanças de provedor ou de limiar sejam lançadas.

Respostas somente extrativas (citar ou se abster), trilha de auditoria completa sobre eventos de fonte/consulta/avaliação/feedback, provedores locais determinísticos para desenvolvimento reproduzível, fallback do Gemini para local quando faltam chaves.

Promover os limiares de avaliação a gates de deploy, para que uma regressão de recuperação bloqueie o release antes que ele chegue à retro.

Um "assistente de QA de IA" que opina sobre qualidade é exatamente o modo de falha. O veredito precisa ser calculado por código a partir dos exit codes dos comandos. Aqui, um LLM nunca corrige a própria prova.

Uma única CLI conduzindo a fig. 1: cada runner é um plugin (detect → plan → run → collectEvidence); um runner travado não consegue travar uma execução. Dois gates: pré-commit com menos de 15ms, e um gate de merge sobre o repositório inteiro.

Um registro de evidência em vez de memória: o comando exato, o exit code e a métrica interpretada de cada execução são gravados em um registro de prova, reverificável offline.

O loop autônomo de correção é limitado. Ele corrige apenas o que o arcabouço consegue verificar, faz commit quando há melhora, reverte quando há regressão, e para honestamente em caso de impasse para revisão humana.

Contrato anti-alucinação: nenhuma pontuação sem um artefato de respaldo. Pisos de cobertura crescentes, disciplina de honest-skip, evidência redigida e assinada com ed25519.

Dez runners dedicados de segurança de IA: viés, consistência, alucinação, jailbreak, prompt-injection, recusa, toxicidade, vazamento de PII, custo, latência. Esse é o arcabouço que eu trago para as funcionalidades de LLM dos meus clientes.