Ver, no trace de um agente, que uma política negou uma solicitação não comprova que a ação foi interrompida. É preciso saber se o executor recebeu essa decisão a tempo e a aplicou à mesma solicitação antes de a operação protegida ocorrer.
A observabilidade contribui para a governança ao permitir a revisão de atividades e decisões. Afirmar que um controle atuou preventivamente exige evidência de um fato adicional: a decisão restringiu a execução. Essa distinção importa ao revisar um controle, investigar um incidente ou relatar o que um agente foi impedido de fazer.
A observabilidade é necessária
As equipes precisam de observações para entender quais operações foram solicitadas, o que a avaliação da política informou e quais resultados foram registrados. Sem esse contexto, uma ação que falhou pode ser confundida com um controle que funcionou, ou uma solicitação permitida com uma operação concluída.
A documentação de traces do OpenTelemetry descreve um span como uma unidade de trabalho ou operação, com horários de início e fim. Eventos de span registram pontos significativos durante essa operação. Essas estruturas podem ajudar a relacionar a avaliação de uma política à solicitação de uma ferramenta, desde que a aplicação registre as informações relevantes.
As observações também podem fornecer contexto à decisão de uma política enquanto o fluxo está em andamento. Elas não precisam chegar depois da ação, e um componente de observabilidade pode participar de uma arquitetura de controle. A questão é o que o caminho de execução faz com as informações que recebe.
Observabilidade não comprova a aplicação da política
Exemplo hipotético: em um teste isolado, um agente solicita que uma ferramenta envie um documento sintético a um destino proibido pela política. A ferramenta registra a solicitação, um serviço de políticas informa uma negativa e o evento aparece em uma visão operacional.
Esse registro mostra que uma negativa foi informada. Por si só, ele não demonstra se a ferramenta reteve a chamada ao destino. A chamada pode ter sido interrompida, já ter sido enviada ou ter sido rejeitada pelo destino por outro motivo. São necessárias mais evidências para distinguir esses resultados.
Até a palavra “negada” precisa ter um significado definido. Uma aplicação pode registrá-la quando o motor de políticas retorna uma decisão, quando o executor interrompe a solicitação ou quando o destino a recusa. São pontos diferentes do processo. A recusa pelo destino pode proteger a operação sem comprovar a eficácia de um controle anterior na cadeia.
O pilar de governança de agentes de IA descreve a cadeia de execução mais ampla. Revisar um controle exige ir além de encontrar seus componentes em um trace: é preciso estabelecer a dependência entre a decisão e a operação que se tentou executar.
Um ponto de decisão precisa afetar o que o executor pode fazer
Um ponto de decisão participa de um controle preventivo quando a execução da operação protegida depende de seu resultado. Receber uma cópia da solicitação e produzir uma decisão é insuficiente se o executor puder prosseguir sem aplicá-la.
Essa dependência pode assumir formas diferentes. O código que intermedeia a chamada de uma ferramenta pode aguardar uma decisão antes de acionar o destino. Um fluxo assíncrono pode manter a solicitação pendente e liberá-la somente nas condições permitidas. Ambos exigem uma conexão efetiva entre a decisão e o componente capaz de executar a ação.
A revisão deve estabelecer o que acontece quando o resultado não chega, chega tarde ou não pode ser utilizado. Se o executor prossegue diante de um erro na avaliação da política, um registro posterior de negativa não demonstra que a ação foi bloqueada. Se a solicitação continua pendente, a evidência deve identificar esse estado. O comportamento previsto e o implementado precisam coincidir na integração avaliada.
Verifique o controle antes da operação protegida
Na solicitação hipotética de envio do documento, a ordem relevante é esta: o executor recebe a operação proposta, mantém a solicitação retida durante a avaliação da política e aplica a negativa antes de qualquer chamada enviar o documento. A coleta de evidências pode continuar depois. O horário de exportação da evidência não estabelece quando o controle atuou.
Uma validação útil usaria dados sintéticos e um destino simulado com instrumentação. Exercite uma solicitação permitida para confirmar que o teste consegue observar uma chamada ao destino. Em seguida, exercite o caso negado e confira tanto a aplicação da decisão pelo executor quanto a ocorrência de uma chamada ao destino. A simples ausência de um evento no destino é uma evidência mais fraca se o mecanismo de observação não foi verificado.
A validação também precisa cobrir novas tentativas, processos em segundo plano e rotas alternativas relevantes no fluxo examinado. A camada que intermedeia a ferramenta pode interromper a primeira tentativa enquanto outro caminho envia a operação. Declare quais caminhos foram exercitados e quais permanecem fora da conclusão; um teste bem-sucedido não comprova cobertura universal.
O limite do controle precisa especificar qual efeito se pretende impedir. Interromper uma etapa posterior não desfaz o envio de dados por uma etapa anterior. Revise a operação que atravessa o limite protegido, em vez de presumir que basta interromper o fluxo em qualquer ponto.
A aprovação precisa continuar vinculada à solicitação revisada
Um evento de aprovação registra uma decisão de permitir algo. Para funcionar como controle, o executor precisa aguardar quando a aprovação for exigida e aplicar uma aprovação válida à solicitação que de fato executará.
No mesmo fluxo hipotético, suponha que a política encaminhe um destino específico à revisão humana, em vez de negá-lo. A aprovação deve se referir ao documento, ao destino e à operação apresentados para revisão, com o escopo e a validade exigidos pela política. Se esses detalhes mudarem, o executor precisa determinar se a aprovação continua aplicável. Uma aprovação anterior em outro ponto da sessão não estabelece esse vínculo.
A evidência deve, portanto, conectar a solicitação pendente, a aprovação e a maneira como o executor aplicou essa aprovação. Identificadores de correlação ajudam a localizar os registros, mas a implementação também precisa verificar se a autorização se aplica. Um identificador em um log não faz essa verificação.
O lado organizacional dessa decisão é tratado em Por que a Governança de IA Precisa Ir dos Modelos para as Ações. Na verificação, a pergunta adicional é se o escopo aprovado governou a operação que veio depois.
Mantenha distintas a evidência da decisão e a evidência da execução
Depois da decisão, um revisor deve conseguir relacionar a operação solicitada, a política aplicável, a decisão retornada, a resposta do executor e o resultado disponível no destino. Preserve a origem e o significado de cada registro para que um relatório não trate observações diferentes como equivalentes.
O Logs Data Model do OpenTelemetry distingue Timestamp, medido na origem do evento, de ObservedTimestamp, medido quando o sistema de coleta o observa. Os valores podem coincidir, e o horário de origem pode estar ausente. Ordenar registros apenas por um horário exibido não comprova que um componente esperou pelo outro.
Diferenças entre relógios, atrasos na coleta e correlação incompleta podem deixar a ordem incerta. Examine a dependência de execução na implementação e as evidências de como ela se comportou. Se faltam registros porque um caminho não foi instrumentado ou a coleta ficou incompleta, mantenha o resultado como desconhecido, em vez de transformar a ausência de evidência em uma afirmação de prevenção.
A conclusão de uma revisão deve identificar a integração e a configuração examinadas, a operação cuja execução foi testada e os limites da observação. Distinga uma decisão informada, uma solicitação cujo envio foi comprovadamente impedido e uma operação cujo resultado continua desconhecido. Isso dá ao próximo revisor uma afirmação que pode ser verificada.
A posição da KonaSense é que afirmações sobre controles preventivos devem atender a esse critério de evidência. Ao avaliar o Kona for Agents, examine a aplicação das decisões, o comportamento de execução e os registros disponíveis na integração específica. A recepção de telemetria e a avaliação de políticas não devem ser apresentadas como prova de que uma ação protegida foi impedida.