IA no failover: deixe o modelo escolher e o código executar

Para coordenar um failover com IA sem entregar credenciais nem execução irrestrita ao modelo, fixe uma fronteira: o modelo interpreta o pedido e escolhe uma habilidade tipada; código convencional valida os argumentos, aplica políticas, obtém a aprovação exigida e executa a mudança. A saída do modelo é uma proposta estruturada, nunca uma autorização.

Assim, um pedido como “mover o serviço de pagamentos para a região secundária” não chega diretamente à infraestrutura. Um executor autenticado resolve o ativo, verifica se o destino está pronto, classifica o risco por regras externas e então bloqueia, aguarda aprovação ou inicia um fluxo previamente permitido.

Desenhe a fronteira de confiança

Separe o fluxo em quatro partes: interface de operação, seletor de habilidades, gateway de validação e orquestrador de recuperação. O modelo fica nas duas primeiras; somente o gateway e o orquestrador recebem acesso operacional, limitado à ação, ao serviço e ao ambiente aprovados.

Esse desenho adapta o caso arquitetural do EWOK Agent, no qual a Intuit usa habilidades tipadas e versionadas para orientar a escolha do modelo, enquanto APIs convencionais resolvem ativos, consultam workflows, verificam prontidão, aplicam políticas, criam registros de mudança e executam o failover. Na implementação descrita, o modelo não guarda credenciais AWS nem possui caminho de rede até o EWOK; a autenticação entra no executor pelo contexto da requisição.

O diagrama de confiança deve representar esta sequência:

1. O operador informa serviço, ambiente, destino e objetivo em linguagem natural.
2. O modelo escolhe uma habilidade registrada e preenche seus argumentos.
3. O gateway valida esquema, identidade, ativo e combinações permitidas.
4. O motor de políticas calcula o risco sem delegar a decisão ao modelo.
5. O executor usa uma identidade restrita à requisição e chama apenas APIs autorizadas.
6. O sistema devolve um estado tipado: recusado, aguardando aprovação, em execução, concluído ou falhou.

Converta capacidades em contratos tipados

Não exponha terminal, credencial genérica ou uma função aberta de “executar comando”. Registre capacidades estreitas, como consultar prontidão, listar destinos elegíveis, preparar um plano, solicitar aprovação, iniciar o failover e consultar a execução.

Um contrato de referência para iniciar a operação pode exigir:

• operation: valor enumerado, como iniciar failover;
• asset_id: identificador canônico resolvido no catálogo;
• source_environment e target_environment: par admitido pela política;
• incident_id: obrigatório quando houver exceção ou mudança emergencial;
• requested_by: identidade obtida da sessão autenticada, não do texto produzido pelo modelo;
• idempotency_key: chave usada pelo executor para impedir a repetição da mesma mudança.

Rejeite campos desconhecidos e tipos inválidos antes de qualquer consulta privilegiada. Depois, valide o significado: o ativo existe, o solicitante pode operá-lo, o destino é elegível, a solicitação pertence ao incidente indicado e não há outra execução incompatível. Se faltar um dado obrigatório, retorne uma pendência específica; o modelo não deve completar a lacuna por inferência.

Faça a aprovação acompanhar o risco

A categoria de risco também deve sair de uma tabela ou de um motor de políticas versionado. Tipo de operação, ambiente, criticidade do serviço, prontidão do destino, janela de mudança e exceções são entradas verificáveis. O modelo pode resumir o pedido para o revisor, mas não pode rebaixar a categoria calculada.

Uma matriz inicial, ajustável à política da organização, pode separar:

• Baixo risco: consultas, simulações e coleta de evidências, executadas e registradas automaticamente.
• Risco moderado: preparação de plano ou mudança reversível fora da produção, com um aprovador quando exigido pela política.
• Alto risco: alteração de tráfego em produção, prontidão degradada ou uso de exceção, sempre com aprovação explícita.
• Risco crítico: impacto amplo, conflito com congelamento de mudanças ou controles indisponíveis, sujeito a múltiplos aprovadores ou recusa.

A orientação de intervenção humana do AWS Well-Architected recomenda classificação determinística e níveis de aprovação proporcionais ao risco. Ela também adverte que revisar todas as ações favorece fadiga e aprovações automáticas; o responsável precisa receber a operação proposta, o contexto relevante e as possíveis consequências.

Modele timeout, recusa e auditoria

Ausência de resposta não significa consentimento. Quando o prazo vence, o fluxo deve bloquear a operação ou encaminhá-la ao grupo de escalonamento definido na política. O agente pode informar o estado, mas não deve trocar de ferramenta, alterar parâmetros ou procurar uma rota alternativa para contornar a aprovação.

Registre cada transição sob um identificador único: identidades do solicitante, revisor e executor; habilidade e versão; argumentos validados; versão da política; categoria de risco; decisão e justificativa; horários; escalonamentos; chamadas efetuadas; e resultado. Vincule ao mesmo registro o plano de recuperação, a evidência de prontidão e o registro formal da mudança.

A trilha de auditoria deve ser estruturada e separada do histórico de conversa. Proteja-a contra alteração indevida, aplique a retenção organizacional e impeça que credenciais, segredos ou tokens de aprovação apareçam tanto nela quanto no chat.

Exercite a recusa segura antes da produção

Comece com o executor em modo de simulação: ele resolve os mesmos ativos, avalia as mesmas políticas e produz o plano, mas não modifica tráfego nem infraestrutura. Antes de liberar mudanças reais, faça exercícios de mesa e testes técnicos que cubram o caminho autorizado e as formas esperadas de recusa.

Inclua ativo inexistente, destino sem prontidão, campo adicional, requisição repetida, indisponibilidade do aprovador, timeout, revogação durante a espera, resposta malformada e tentativa de ignorar um congelamento de mudanças. Confirme que nenhuma condição abre outro caminho de execução e que o mesmo identificador conecta pedido, classificação, aprovação e resultado.

O núcleo do NIST AI RMF sustenta essa disciplina ao prever documentação dos limites do sistema e da supervisão humana, controles orientados pela tolerância a risco e testes antes da implantação e durante a operação. Para este padrão, o critério de prontidão não é o modelo acertar uma demonstração: é o executor continuar previsível quando o modelo erra, recusando entradas inválidas, interrompendo operações sem aprovação e preservando uma trilha reconstruível.

Leia também:

• Chave exposta no SageMaker permite executar código — atualizar não basta
• Agent Toolkit da AWS em um comando — limite o que a IA pode executar
• Mantis executa código gerado por IA — isole antes de procurar falhas