Checklist de lançamento para aplicações com LLM

Por que isso importa

O modelo passou, mas o lançamento ainda não estava pronto#

Uma versão candidata pode passar nas avaliações do modelo e ainda ser insegura para publicação: o artefato não é identificável, um segredo entrou na compilação, a jornada crítica nunca foi exercitada, faltam alertas ou ninguém ensaiou a reversão. Nenhuma dessas falhas aparece em uma nota de qualidade da resposta.

O checklist de lançamento existe para fechar essa lacuna operacional mais ampla. Diferentemente do gate de qualidade, que decide se o comportamento atende a uma política de avaliação, este artigo acompanha a candidata inteira: contrato, segurança, observabilidade, responsabilidade, recuperação e promoção de tráfego.

Artefato sem identificação, segredo exposto, jornada não testada, alerta ausente e reversão não ensaiada apontam para o mesmo começo: definir o que significa “pronto”.

01 · Contrato de execução

Defina sucesso antes de executar o modelo#

Escreva a tarefa, ferramentas permitidas, esquema de saída, comportamento de recusa, orçamento de latência e falhas críticas antes de escolher uma métrica. Um requisito vago como “ser útil” não produz um controle (gate) auditável.

Separe invariantes de preferências. Validade do esquema, autorização e uso proibido de ferramentas são bloqueadores determinísticos. Tom, relevância e completude podem exigir rubricas ou revisão humana. Colocar tudo em uma nota esconde falhas graves.

Um contrato definido mostra o que testar; o conjunto de avaliação verifica se a versão candidata realmente o atende.

02 · Evidência de avaliação

Teste casos conhecidos, limites e recuperação#

Construa um conjunto versionado com jornadas comuns, limites difíceis, entradas adversariais e falhas já observadas. Registre as versões do conjunto de dados, prompt, modelo, ferramenta e rubrica em cada execução.

Não promova apenas pela taxa de aprovação. Inspecione falhas por capacidade e fatia de risco, compare com a última versão aprovada e trate cobertura ausente como incerteza, não como sucesso.

Casos comuns e de limite cobrem o comportamento, mas falhas graves de segurança precisam de uma condição própria de parada.

03 · Bloqueadores críticos

Dê à segurança e à autorização um controle próprio#

O OWASP Top 10 para aplicações com LLM descreve riscos que uma nota média de qualidade não neutraliza. Injeção de prompt (prompt injection), agência excessiva, exposição de informação sensível e tratamento inseguro de saída exigem testes e responsáveis explícitos.

Um invariante crítico deve falhar de forma segura: o lançamento para mesmo se todos os indicadores graduais melhorarem. Documente o processo de exceção para que urgência não redefina a política silenciosamente.

Depois que os bloqueadores críticos passam, a equipe ainda precisa de sinais de produção que não criem um novo risco de privacidade.

04 · Operação

Observe decisões sem criar um vazamento de dados#

Rastreie operações de modelo e ferramentas, latência, erros, uso de tokens e vereditos de avaliação com identificadores de baixa cardinalidade. Capture conteúdo de mensagens apenas quando necessário, com mascaramento ou remoção de dados sensíveis, controle de acesso e retenção.

Conecte o controle a uma pessoa responsável pelo lançamento e a um sinal de reversão. Alerta sem responsável é apenas um registro; reversão sem caminho testado é apenas intenção.

Esses sinais só ajudam quando levam a um resultado explícito de lançamento, sob responsabilidade de uma pessoa nomeada.

05 · Decisão de lançamento

Termine em PROMOTE, HOLD ou ROLLBACK#

Use os três resultados como ações operacionais. Eles dizem o que acontece com o tráfego, não se o modelo é “bom” em termos abstratos.

1. P

   PROMOTE

   A evidência obrigatória está completa, invariantes críticos passam e o risco residual foi aceito pela pessoa responsável.

2. H

   HOLD

   A evidência está ausente, conflitante, fora do domínio validado ou aguarda decisão humana.

3. R

   ROLLBACK

   Evidência de produção cruza um limite predefinido de confiabilidade, segurança ou negócio.

{
  "schema_version": "release-decision@1",
  "candidate": "release-2026-07-20.1",
  "artifact": "image@sha256:<digest>",
  "evidence": ["tests", "evals", "security", "operations"],
  "owner": "release-owner",
  "decided_at": "2026-07-20T14:30:00Z",
  "verdict": "HOLD",
  "reason": "candidate journey not verified",
  "rollback_target": "release-2026-07-19.3"
}

O checklist reúne contrato, evidências, bloqueadores, operação e responsável em uma única revisão antes do tráfego.

Checklist pré-tráfego

Doze perguntas antes do tráfego de produção#

Responda a cada pergunta para o artefato e a revisão exatos em análise. Resposta em branco é evidência ausente, não aprovação implícita.

• ✓O contrato de comportamento está versionado?
• ✓Esquema, autorização e invariantes de política passam?
• ✓O conjunto cobre jornadas comuns, limites, ataques e recuperação?
• ✓Falhas anteriores de produção foram reproduzidas?
• ✓Rubrica e modelo do avaliador estão fixados por versão?
• ✓Os segmentos de alto risco foram analisados separadamente do resultado médio?
• ✓Cada risco crítico possui bloqueador rígido?
• ✓Prompts e respostas estão mascarados ou sem captura por padrão?
• ✓A execução pode ser reproduzida pelas versões registradas?
• ✓Existe uma pessoa responsável pelo lançamento?
• ✓A reversão está definida e ensaiada?
• ✓A decisão final e sua evidência foram registradas?

O resultado é um registro de lançamento cujo status verde pode ser explicado e revertido.

Conclusão

Um fluxo verde não é o mesmo que um lançamento pronto#

Prontidão para lançamento não é a soma de caixas marcadas. É um argumento revisável de que o comportamento esperado está definido, riscos críticos são bloqueados, jornadas representativas foram exercitadas, a operação consegue observar o resultado e uma pessoa responsável aceita a incerteza restante.

Antes de enviar tráfego, faça uma última pergunta: outra pessoa da operação consegue identificar o artefato exato, reproduzir a evidência decisiva, explicar por que a candidata foi promovida e voltar a uma revisão conhecida? Se alguma parte estiver ausente, registre HOLD em vez de deixar um campo vazio virar aprovação silenciosa.