Versionar prompts, modelos e lógica de workflow como um único lançamento de IA

Um lançamento de IA é a configuração completa que determina o comportamento servido, não apenas o endpoint do modelo ou a frase do prompt. Repor o modelo anterior enquanto permanecem em produção um novo prompt, um contrato de ferramenta, uma permissão ou uma regra de repetição não repõe o serviço anterior. Sem uma identidade única para esse conjunto, a equipa dificilmente consegue provar o que avaliou, saber que configuração tratou um pedido problemático ou encaminhar tráfego para um estado anterior realmente compatível.

O que deve contar como um único lançamento de IA?

Deve contar como um lançamento o conjunto de dependências capaz de mudar o comportamento, a autoridade, o risco, o custo, a latência ou a observabilidade do serviço. A orientação do NIST trata as atividades do ciclo de vida da IA como interdependentes e recomenda inventários de componentes próprios e de terceiros. A Google Cloud descreve igualmente os sistemas de aprendizagem automática em produção como sistemas que incluem configuração, testes, metadados, infraestrutura e monitorização, além do modelo.

• Prompt e instruções de sistema
• Identificador resolvido do modelo e parâmetros de inferência
• Esquemas de ferramentas, permissões e aprovações
• Políticas, filtros e guardrails
• Configuração de recuperação, contexto e encaminhamento
• Código e regras do workflow
• Esquemas de entrada e saída
• Dependências de execução e ligações ao ambiente

Os conjuntos de avaliação, avaliadores, rubricas e limiares não costumam executar no percurso de serviço, mas também precisam de versão e ligação ao lançamento: alterá-los muda a evidência usada para autorizar o candidato. A fronteira exata é específica do sistema. Inclua uma dependência própria ou externa apenas quando possa afetar materialmente o serviço ou a decisão de promoção, e crie um novo candidato sempre que essa configuração efetiva mudar.

Como ligar toda a pilha num manifesto de lançamento?

A pilha deve ser ligada através de um manifesto imutável, criado antes da avaliação, com uma identidade exclusiva e referências resolvidas para cada componente. Registe o identificador do lançamento, hora de criação, responsável, serviço de destino, estado, condições de paragem, responsável pelo rollback e lançamento anterior conhecido. Para cada elemento, guarde uma versão, commit, resumo criptográfico ou referência estável, juntamente com as definições efetivamente aplicadas.

• Identidade e proprietário do candidato
• Versões ou resumos de todos os componentes
• Parâmetros efetivos do modelo
• Ligações, feature flags e regras de encaminhamento aprovadas
• Restrições de compatibilidade e migrações
• Evidência, aprovação e plano de promoção
• Condições de paragem e alvo de rollback

Um alias como «produção» ou «mais recente» é apenas um apontador. O MLflow, por exemplo, documenta versões imutáveis de prompts, aliases mutáveis e configurações de modelo que podem mudar depois do versionamento; também permite registar a associação entre um modelo e uma versão específica do prompt. A OpenAI recomenda fixar snapshots quando disponíveis e executar avaliações da aplicação. O manifesto deve, por isso, conservar o alvo resolvido e a configuração efetiva, não confiar no nome do alias.

No assistente de apoio do exemplo, support-assistant-r18 liga o prompt p-42, o snapshot m-2026-07 e os respetivos parâmetros, o esquema CRM t-9, a política policy-12, o commit wf-a71, o esquema reply-6 e o bloqueio das dependências. O pacote associado aponta ainda para eval-23 e para as versões dos avaliadores. support-assistant-r17 só pode ser o alvo de reposição depois de confirmada a compatibilidade com os campos opcionais de data-limite e escalamento.

Se algo muda o comportamento servido — ou a evidência que o autoriza — precisa de uma identidade resolvida no registo do lançamento.

Que evidência deve decidir se o candidato avança?

O candidato só deve avançar quando a evidência sobre a configuração exata sustentar uma decisão explícita de promover, suspender ou rejeitar. As notas de lançamento devem explicar a intenção comportamental, as dependências alteradas, os cenários e interfaces afetados, as mudanças de permissões ou observabilidade, as limitações conhecidas, o risco residual, os responsáveis pela promoção e o alvo de rollback compatível. Cada decisão precisa de proprietário e de uma ligação aos resultados que a justificam.

Avalie o candidato contra a versão atual, usando contratos, tarefas reais do workflow, casos raros mas dispendiosos, segmentos importantes, regras de segurança e autoridade, comportamento das ferramentas, fiabilidade, latência e custo. A orientação da OpenAI recomenda exemplos específicos do trabalho, participação de especialistas do domínio e auditorias aos avaliadores automáticos; a Google Cloud recomenda comparações com uma referência, segmentos e interfaces. Um resultado agregado nunca deve ocultar uma regressão material num contrato, numa permissão ou num segmento crítico.

Como deve o mesmo candidato chegar à produção?

O mesmo candidato resolvido deve atravessar uma sequência medida: replay sem atuação ou shadow quando for viável, utilização interna, coorte canário persistente, expansão e tráfego total. Num replay de pedidos reais, desative ou isole em sandbox as escritas e outros efeitos consequentes; não repita cegamente ações de produção. Em cada fase, compare com o lançamento atual os sinais acordados de tarefa, segurança, ferramentas, fiabilidade, latência e custo.

1. Reproduzir casos representativos sem permitir ações externas
2. Expor à equipa interna com as aprovações mantidas
3. Encaminhar uma coorte persistente e identificável
4. Expandir após cumprir a janela e a amostra definidas para o serviço
5. Passar a tráfego total mantendo monitorização identificada por lançamento

A atribuição da coorte, a fração de tráfego, o início da observação e a decisão ficam em eventos de implementação ligados ao manifesto, sem o alterar. Um aumento de exposição previamente aprovado pode continuar a pertencer ao mesmo candidato. Porém, uma mudança no prompt, modelo, parâmetro, ferramenta, permissão, política, contexto, workflow, esquema, dependência ou ligação ambiental exige nova identidade. Percentagens, amostras e períodos devem refletir risco, volume, latência de deteção e capacidade operacional; nem shadow nem canário cobrem todas as condições raras.

Quando deve o lançamento parar e o que tem de ser reposto?

O lançamento deve parar perante uma violação de segurança ou política, uma ação de ferramenta sem autoridade, uma falha contratual ou uma falha grave de fiabilidade; outras regressões seguem limites definidos para o serviço. Declare estes gatilhos antes da exposição, bem como quem decide e quem executa a reposição. Um sinal ambíguo pode justificar suspensão e investigação em vez de rollback automático, mas nunca deve ficar sem disposição, proprietário ou prazo operacional.

• Confirmar esquemas, contratos e migrações
• Verificar estado, encaminhamento e ligações ao ambiente
• Ensaiar a reposição antes de ser necessária
• Validar o serviço imediatamente após restaurar tráfego

O rollback deve restaurar o conjunto completo conhecido e compatível, não apenas o modelo ou prompt anterior. A Google Cloud recomenda testar a reposição rápida e segura da versão anterior, mas a compatibilidade pode ter mudado com esquemas, estado, fornecedores ou ferramentas. A reposição só controla pedidos futuros: não elimina mensagens, escritas de dados, aprovações ou tarefas já concluídas. Use traces identificados pelo lançamento para localizar pedidos e ações afetados e aplique um runbook autorizado de contenção, reconciliação, correção, notificação ou compensação.

Que registo permite reconstruir um lançamento mais tarde?

Um registo reconstruível conserva o manifesto imutável, os componentes e parâmetros resolvidos, as ligações ao ambiente, os resultados de compatibilidade, as versões e resultados das avaliações, as aprovações, os eventos de implementação, a exposição, os achados, o rollback e a disposição final. A Google Cloud recomenda registar versões, tempos, executores, parâmetros, artefactos, resultados e a referência anterior. Estes elementos permitem reconstituir a configuração efetiva e explicar a decisão tomada.

• Identidade do lançamento em cada trace
• Gerações, chamadas de ferramentas, transferências e guardrails relevantes
• Tempos, resultados e identificadores de ações externas
• Identificador do pedido da aplicação e do fornecedor, quando disponível
• Versão da avaliação, resultado, aprovação e exceções
• Alvo, momento e validação de qualquer rollback

O tracing pode captar a hierarquia do workflow, gerações, chamadas, transferências, guardrails e metadados, ao mesmo tempo que exclui entradas e saídas sensíveis. A OpenAI recomenda também guardar identificadores de pedidos para diagnóstico entre fronteiras técnicas. Isso não obriga a conservar todos os prompts, conteúdos de clientes ou respostas: retenção e acesso seguem a política da organização. O resultado é reprodutibilidade da configuração e da decisão, não a promessa de repetir byte a byte uma resposta estocástica ou alojada.

Comece pelo pacote mais pequeno que ainda identifica o candidato, a evidência usada para o autorizar, as decisões de promoção e um alvo compatível de reposição. Quando a mudança afetar dados sensíveis, permissões consequentes, workflows regulados, retenção ou reparação de ações externas, envolva os profissionais qualificados de segurança, privacidade, jurídico, arquivo, risco ou domínio. Este método organiza a decisão operacional; não determina os requisitos especializados aplicáveis à organização.