Como versionar prompts, modelos e lógica de fluxo em uma única versão de IA

Uma versão de IA é a configuração completa capaz de alterar o comportamento servido, não apenas o nome do modelo ou o texto do prompt. Se a equipe reverte o endpoint, mas mantém uma permissão nova, um schema de ferramenta diferente ou uma regra de retry alterada, ela não restaurou o sistema que havia sido testado. A unidade operacional precisa ter uma identidade única que reúna componentes resolvidos, configurações efetivas e vínculos do ambiente. Sem isso, investigar um atendimento problemático vira arqueologia entre históricos separados: ninguém demonstra com segurança o que foi avaliado, o que recebeu tráfego e qual combinação anterior ainda pode ser restaurada.

O que deve contar como uma única versão de IA?

Deve contar como uma versão o conjunto de dependências que pode mudar comportamento, autoridade, risco, custo, latência ou observabilidade no atendimento real. O NIST trata atividades e atores do ciclo de vida como interdependentes, enquanto o Google Cloud descreve sistemas de ML em produção como muito mais amplos que o código do modelo. O limite exato varia por serviço, mas deve ser definido pela influência operacional de cada elemento, seja ele próprio, contratado ou fornecido por terceiros.

• Prompt e instruções de sistema, incluindo sua versão resolvida.
• Snapshot do modelo, parâmetros de inferência e formato de resposta.
• Schemas de ferramentas, permissões, políticas, guardrails e aprovações.
• Configuração de recuperação, contexto, roteamento e fontes de dados.
• Código do fluxo, schemas de entrada e saída e dependências de execução.
• Bindings de ambiente que alteram o tratamento de uma requisição.

Dados de avaliação, avaliadores, rubricas e limites também precisam de versão, mas ocupam outra camada: normalmente não atendem a requisição; influenciam a autorização para promovê-la. Essa distinção mantém o manifesto de execução preciso sem esconder os ativos de garantia. Qualquer mudança em um componente do caminho servido cria uma nova candidata. Uma alteração no gate pode conservar o mesmo pacote de execução, porém deve gerar nova evidência decisória para que os resultados continuem comparáveis.

Como reunir a pilha de comportamento em um manifesto?

Congele um manifesto imutável com ID da versão, horário de criação, proprietário, serviço de destino, status, condições de parada, responsável pelo rollback e última versão conhecida como boa. Para cada componente, registre a versão resolvida, commit, digest, hash de conteúdo ou referência estável, além das configurações efetivas. Aliases como “produção” e “mais recente” são ponteiros móveis: o registro deve guardar aquilo para o qual apontavam quando a candidata foi formada.

• Identidade e estado: release ID, proprietário, ambiente-alvo, criação e aprovação.
• Componentes: referências resolvidas de prompt, modelo, ferramentas, políticas, código, schemas e runtime.
• Ambiente: chave do feature flag, regra de roteamento, conexões aprovadas e referência de recuperação ou dados, sem copiar segredos.
• Compatibilidade: contratos, migrações, dependências e versão anterior candidata à restauração.
• Evidência: build, avaliações, pareceres, plano de exposição, limites conhecidos e runbook de efeitos externos.

Considere o assistente interno de suporte support-assistant-r18. O pacote liga prompt p-42, snapshot m-2026-07 e parâmetros, schema de CRM t-9, policy-12, commit wf-a71, schema reply-6 e lock de dependências; separadamente, referencia eval-23 e versões dos avaliadores. support-assistant-r17 só entra como alvo de rollback depois de uma verificação dos campos opcionais de vencimento e escalonamento. Alocações e horários ficam em eventos de implantação vinculados, sem reescrever a candidata.

Se algo pode mudar o comportamento servido ou a evidência que o autoriza, precisa de identidade resolvida no registro da versão.

Quais evidências devem decidir se a candidata avança?

A candidata só deve avançar quando a versão completa tiver sido confrontada com gates aplicáveis e a decisão estiver registrada como promover, manter em espera ou rejeitar. As notas de versão devem explicar a intenção comportamental, dependências modificadas, cenários e interfaces afetados, alterações de permissão ou observabilidade, evidências, limitações, risco residual, responsáveis e alvo compatível de rollback. O objeto testado precisa ser exatamente aquele que poderá receber tráfego.

Compare a candidata com a versão atual usando exemplos do trabalho real, casos raros de alto custo e segmentos importantes. Não aprove por uma média agregada quando houver regressão material de contrato, autoridade, segurança ou segmento. Conjuntos, avaliadores, rubricas e limites devem ter versões próprias, pois uma troca no gate muda a leitura dos resultados. Quando o risco justificar, quem criou a mudança não deve ser a única pessoa autorizada a promovê-la.

Como a mesma candidata deve chegar à produção?

A mesma candidata resolvida deve percorrer uma escada de exposição medida, começando por replay sem atuação ou shadow quando isso for viável. Ferramentas de escrita e outros efeitos consequenciais precisam ser desabilitados ou isolados; reproduzir cegamente ações de produção não é teste seguro. Depois, a equipe pode avançar para uso interno, uma coorte persistente de produção, expansão controlada e tráfego completo, sempre comparando sinais previamente acordados com a versão atual.

1. Executar replay representativo com ações externas bloqueadas e comparar os rastros completos.
2. Liberar para um grupo interno mantendo aprovações nos atos consequenciais.
3. Direcionar uma coorte persistente e limitada à candidata.
4. Expandir somente após cumprir a janela de observação e a necessidade de amostra definidas pelo serviço.
5. Mover para todo o tráfego e continuar o monitoramento identificado por versão.

Cada etapa gera um evento vinculado ao manifesto, com regra da coorte, alocação, horário, observações e decisão. Aumentar uma exposição já aprovada não cria, sozinho, outra candidata. Alterar prompt, parâmetro, ferramenta, permissão, política, recuperação, workflow, schema, dependência ou binding que afete cada requisição cria. Percentuais, amostras e janelas devem refletir risco, volume, demora para detectar problemas e capacidade de resposta. Shadow e canário reduzem incerteza, mas não cobrem todas as condições nem garantem encontrar falhas raras.

Quando interromper a versão e o que o rollback deve restaurar?

A versão deve parar diante de uma violação confirmada de segurança ou política, uso de ferramenta sem autorização, quebra de contrato ou falha grave de confiabilidade; outras regressões seguem limites específicos definidos antes da exposição. Um achado ambíguo pode justificar pausa e investigação, em vez de rollback automático, mas ainda precisa de disposição e responsável explícitos. O alvo da restauração é o pacote completo conhecido como bom e compatível, nunca um componente revertido de forma isolada.

Antes de depender de support-assistant-r17, verifique schemas, estado persistido, migrações, contratos de ferramentas, roteamento e disponibilidade do provedor. O Google Cloud recomenda ensaiar a restauração da versão anterior; esse exercício mostra se o caminho de retorno continua utilizável e se a equipe sabe validar o serviço depois da troca. O ensaio deve ocorrer antes do incidente, mantendo identificados o dono do rollback, o procedimento e os sinais que confirmam a recuperação.

• Restaurar o tráfego futuro para o pacote compatível.
• Localizar requisições e IDs de ações afetadas pelos rastros da versão.
• Conter o caminho de ação ainda ativo.
• Conciliar, corrigir, notificar ou compensar segundo um runbook autorizado.
• Registrar gatilho, horários, verificações, decisões e responsáveis.

Rollback de configuração não apaga mensagens, desfaz gravações, cancela aprovações nem remove tarefas já criadas no CRM. Ele controla o que atenderá as próximas requisições. Efeitos concluídos exigem uma frente distinta de remediação, com autoridade adequada ao sistema afetado. No exemplo, a equipe desabilita a criação de tarefas, obtém os IDs pelos rastros e aplica o runbook do CRM; simplesmente voltar para r17 não elimina tarefas produzidas por r18.

Qual registro permite reconstruir uma versão de IA depois?

O registro durável deve permitir reconstruir a configuração efetiva, a evidência observada e a decisão tomada. Preserve o manifesto imutável, identificadores e parâmetros resolvidos, bindings do ambiente, resultados de compatibilidade, versões e resultados das avaliações, aprovações, eventos de implantação, alocações, achados, rastros, rollback e disposição final. Ligue o release ID a cada rastro para atribuir gerações, chamadas de ferramentas, transferências, guardrails, tempos e resultados à candidata que realmente atendeu.

Registre também identificadores de requisição do provedor e da aplicação quando estiverem disponíveis. Isso facilita cruzar um sintoma observado com evidências dos dois lados do serviço. Não é necessário conservar todo prompt, entrada de ferramenta, resposta do modelo ou conteúdo do cliente: identificadores, resultados governados e amostras autorizadas podem sustentar a investigação sem transformar completude do tracing em retenção indiscriminada. Conteúdo sensível, acesso e prazos seguem as políticas organizacionais aplicáveis.

O resultado é reprodutibilidade de configuração e de decisão, não repetição idêntica de cada saída. Identificadores fixados e parâmetros arquivados reduzem ambiguidades, mas modelos estocásticos e serviços hospedados ainda podem variar. Adote o menor pacote que identifique candidata, evidência, promoção e retorno compatível. Mudanças em dados sensíveis, permissões consequenciais, fluxos regulados, retenção ou remediação externa devem envolver os profissionais qualificados de segurança, privacidade, jurídico, registros, risco ou domínio da organização.