Resumo

  • draft-smith-opsawg-ai-network-governance-01 afirma que comunicar restrições ao serviço de IA não substitui a fiscalização programática e independente do agente.
  • Proposta compatível, operação aceita e rollback solicitado são fatos distintos da autoridade aplicada e do estado final observado.

Há uma diferença operacional entre dizer “esta ação é proibida” e provar “este executor bloqueou esta ação por esta versão da regra”.

A primeira frase cabe no prompt. A segunda exige identidade de política, estado histórico, decisão reproduzível e vínculo com a operação no equipamento.

Essa diferença é o melhor ponto de draft-smith-opsawg-ai-network-governance-01, publicado em 27 de setembro de 2026. Trata-se de um Internet-Draft individual ativo, sem endosso da IETF, sem posição formal no processo e sem RFC stream. O cabeçalho o apresenta como Informational. É uma proposta de arquitetura, não um padrão ou relatório de produção.

O escopo exige acesso direto ao plano de gestão de router ou switch, consulta a um serviço externo de IA, capacidade de alterar configuração ou estado sem aprovação humana por ação e uso de interfaces como NETCONF, RESTCONF ou gNMI. Sistemas apenas consultivos ficam de fora.

O serviço externo recebe contexto e propõe. O agente local coleta telemetria, detecta, avalia e executa. A IA não deve obter acesso direto ao dispositivo. Isso reduz uma via de ataque, mas transforma o agente local no ponto privilegiado onde política, credenciais e estado se encontram.

O Action Registry é um catálogo fixo, implementado por desenvolvedores, com parâmetros, risco e reversibilidade. A Operator Allow List seleciona o subconjunto autorizado na instalação. A IA não cria novos tipos; uma sugestão fora do catálogo é descartada. Parâmetros fora da faixa são rejeitados, mesmo com confiança alta.

O rascunho também manda incluir no contexto do modelo ações permitidas e bloqueadas, alvos protegidos, limites e teto de risco. A projeção reduz propostas inúteis e ajuda a explicar escalonamentos. Mas o texto faz a ressalva decisiva: comunicar restrições não substitui enforcement. Toda proposta deve ser validada de forma independente antes da execução, em camadas que vão do parser ao ponto de interação.

Logo, um prompt correto não é controle de acesso. E um evento “guardrail aprovado” sem entradas identificadas não é auditoria suficiente.

O recibo mínimo por ação deve juntar o snapshot aprovado por humanos; versões do registro, listas e regras de alvo; faixas e risco; estado dos contadores, degradação e revogação; proposta e parse; veredito; validação no ponto de execução; operação autenticada; pre-state; resposta; telemetria nova; e resultado de rollback, bloqueio ou escalonamento.

O hash do prompt é apenas a identidade de uma projeção enviada a terceiro. Ela pode omitir detalhes sensíveis, simplificar padrões ou refletir saldo anterior. Para saber por que o dispositivo mudou, é preciso identificar a política que o executor consultou naquele instante.

Os limites sugeridos tornam a dependência histórica evidente. O texto propõe default de cinco ações de remediação por hora e máximo de vinte, três ações por alvo em 24 horas e máximo de cinco, além de cotas para ações irreversíveis, consultas e tentativas. Esses números não são constantes universais. As fontes congeladas não apresentam validação empírica para toda topologia.

“Quinta ação da hora” depende de eventos completos, relógio, janela e continuidade depois de restart. Cooldown, retry, revogação e nível de degradação também dependem de história.

A seção 17.3 recomenda checks sem estado quando possível, derivados da trilha persistente em vez de memória. A escolha impede que restart zere contadores, mas não elimina o estado. Ela torna a integridade, ordem, retenção, relógio, ativação e convergência do log parte do sistema de segurança.

Os exemplos de fail-safe são úteis: se o dado de rate limit não puder ser consultado, suponha a cota esgotada; se o matcher falhar, trate o alvo como protegido; se o registro estiver indisponível, bloqueie. Estado desconhecido não pode virar permissão.

Depois da autorização existe a realidade do dispositivo. O draft exige captura anterior, telemetria fresca e rollback se não houver melhora. Cache ou supressão de duplicidade não demonstram recuperação.

Mesmo assim, um snapshot não recompõe pacote perdido, sessão encerrada, fila consumida ou timer de vizinho remoto. Rollback é outra operação para frente num sistema em movimento. Precisa de sua própria resposta, releitura e observação do serviço.

A regra de alvo único também não garante impacto único. Uma interface ou instância pertence a domínios compartilhados. Mudança local pode se propagar por convergência e deslocamento de tráfego.

Na injeção de prompt, logs e descrições do equipamento podem influenciar o modelo. Sanitizar ajuda; a defesa arquitetural é manter a IA consultiva e validar toda saída. O teste deve atravessar parser, catálogo, alvo, parâmetros, histórico, execução e failover, não apenas registrar uma recusa do modelo.

O draft chama a trilha de auditoria de principal mecanismo de accountability e recomenda integridade e retenção externa. É nela que o recibo de política deve morar. Logar configuração no startup é valioso, mas não explica uma ação depois de vários reloads.

Os autores dizem que os conceitos derivam de experiência operacional em infraestrutura de produção. É uma afirmação dos autores, não estudo independente com escala, incidentes e resultados. Limites e controles precisam ser hipóteses testadas localmente.

O princípio de especificação inicial mínima de Heng Lu favorece invariantes verificáveis: a IA não amplia ações; desconhecido fecha; o agente não altera suas regras; toda mutação aponta para a autoridade que a admitiu. A separação das camadas de realidade impede confundir “permitido” com estado físico. A primazia do código em execução exige releitura e efeito do serviço.

Fontes