O que é governança de IA em runtime?
Governança de IA em runtime avalia contexto, política e risco enquanto uma interação de IA ou ação de agente está acontecendo, permitindo à organização observar, permitir, bloquear, ocultar ou remover conteúdo sensível, ou exigir aprovação antes ou durante a execução.
Essa é uma definição operacional. As intervenções disponíveis dependem de um ponto de controle capaz de afetar a interação ou ação. Observar uma atividade pode informar uma decisão sem interrompê-la; solicitar uma intervenção não comprova que o executor a aplicou. A integração precisa definir quais efeitos pode produzir e em quais condições.
A governança do uso de IA estabelece as condições para os usos permitidos. A governança em runtime conecta essas condições a uma interação específica durante o funcionamento do fluxo. Sua pergunta central é se a decisão ainda vale para a operação que o sistema está prestes a realizar.
Uma política escrita precisa de um ponto de aplicação
Uma regra pode estar correta e ainda assim não produzir efeito sobre uma operação. “Reiniciar serviços de staging apenas durante uma janela de manutenção aprovada” expressa uma condição. A implementação precisa identificar o ambiente de destino, verificar se a janela está aberta e impedir a reinicialização quando a condição não for atendida.
A política não precisa mudar para que a resposta mude. Uma janela de manutenção pode terminar, uma aprovação pode expirar ou o alvo de uma solicitação pode mudar enquanto o fluxo está em andamento. Uma decisão baseada no contexto anterior precisa ter limites definidos de quando e onde pode ser usada.
A avaliação em runtime não substitui o planejamento. A organização ainda precisa estabelecer a regra, identificar seu responsável e decidir qual risco aceita. A implementação, então, precisa de um ponto em que essa regra possa afetar a operação relevante.
O contexto em runtime pode mudar antes da aplicação da decisão
O contexto deve identificar a operação proposta, seu alvo, a identidade que atua e os atributos necessários à política. Registre a origem desses atributos e se estão suficientemente atualizados para a decisão. O nome de um ambiente informado na solicitação e um ambiente identificado no cadastro de referência do recurso oferecem evidências diferentes.
A Zero Trust Architecture do NIST, SP 800-207, seção 2.1, em inglês descreve decisões de acesso baseadas em atributos de identidade, aplicação, ativo e outros elementos de contexto, com reavaliação orientada pela política. O documento oferece uma referência para decisões dinâmicas de acesso, não uma especificação de governança de IA em runtime nem uma comprovação da cobertura de um produto.
Exemplo hipotético: um assistente de operações solicita a reinicialização de um serviço de geração de relatórios em staging. A política permite essa reinicialização durante uma janela de manutenção aprovada. A solicitação passa pela verificação de política e aguarda em uma fila de execução. A janela de manutenção termina antes que um worker retire a solicitação da fila.
A permissão anterior é evidência de uma decisão tomada sob as condições anteriores. O contrato de execução precisa estabelecer se o worker ainda pode usá-la. Neste projeto hipotético, o worker verifica a janela novamente antes de disparar a operação e retém a solicitação se ela tiver terminado. Esse comportamento é uma escolha de projeto do exemplo, não uma integração KonaSense testada.
A mesma questão surge se o alvo ou os argumentos da solicitação mudarem depois da avaliação. Uma aprovação para determinada reinicialização não se aplica automaticamente a outro ambiente. Enviar um identificador de decisão junto da solicitação ajuda a localizar o registro, mas a implementação ainda precisa verificar se a decisão cobre a operação.
Defina o contrato no ponto de decisão
O contrato é o acordo entre o componente que avalia a política e aquele capaz de executar a operação. Ele precisa especificar a solicitação avaliada, o contexto usado, as decisões possíveis e o comportamento exigido do executor. Um plano de controle de IA pode coordenar essas responsabilidades sem ser o componente que realiza a ação.
No ponto de decisão, determine o que ainda está sob controle. Uma camada intermediária pode conseguir reter uma chamada de ferramenta, mas não ter autoridade sobre uma solicitação enviada por outro cliente. Uma aplicação pode impedir o envio de texto sem conseguir revogar conteúdo já transmitido. Nomeie a operação protegida com precisão suficiente para distinguir esses limites.
A validade da decisão faz parte desse contrato. Estabeleça quais mudanças exigem reavaliação, por quanto tempo a decisão pode ser usada quando o tempo for relevante e se ela se aplica a uma nova tentativa. O mecanismo que vincula a decisão à operação depende da arquitetura; um rótulo para toda a sessão, isoladamente, não descreve o alvo, os argumentos nem as condições autorizadas.
A avaliação de política também pode não ter informações suficientes para retornar um resultado aplicável. Contexto ausente, decisão não suportada e falha de transporte são estados diferentes. Defina o significado de cada um para a execução, em vez de deixar que o comportamento incidental do adaptador se torne a política da organização.
O guia de arquitetura relaciona essas responsabilidades a componentes e limites de confiança, incluindo a identidade e a autorização que cada passagem deve preservar.
O que cada decisão exige do executor
Os nomes das decisões só são úteis quando seus efeitos estão definidos. A tabela abaixo descreve contratos conceituais, não uma lista de controles disponíveis em toda integração.
| Decisão ou modo | Comportamento necessário para o efeito pretendido | Limite da conclusão |
|---|---|---|
| Observar | Registrar a atividade relevante sem afirmar que a observação a impede | Um registro pode apoiar decisões posteriores; por si só, não comprova intervenção |
| Permitir | Permitir a tentativa especificada, respeitando suas condições e a autorização no destino | A permissão não comprova execução bem-sucedida nem concede privilégios adicionais no destino |
| Bloquear | Reter a operação protegida no caminho controlado | O bloqueio não cobre outro caminho, a menos que ele também seja controlado |
| Ocultar ou remover conteúdo sensível | Substituir ou remover o conteúdo sensível especificado antes do uso que se pretende controlar | Uma substituição sugerida ou instrução adicional não comprova que o conteúdo original foi substituído |
| Exigir aprovação | Manter a operação pendente até que uma decisão válida e aplicável a permita | Um aviso dispensado pelo solicitante não equivale automaticamente à aprovação de um revisor designado |
Para ocultar ou remover conteúdo sensível, o contrato precisa identificar o que será transformado e o que acontece se a transformação não puder ser aplicada. Ocultar texto na tela é diferente de alterar o conteúdo enviado a um modelo ou ferramenta. Confirmar o valor de um editor é uma evidência útil sobre aquele editor; pode ser necessário obter evidências adicionais para estabelecer o conteúdo transmitido.
Para aprovação, especifique quem pode decidir e quais informações essa pessoa revisa. Se a operação mudar enquanto aguarda aprovação, determine se a revisão anterior continua aplicável. Uma solicitação pendente não deve se tornar permitida apenas porque uma resposta não chegou.
A pré-execução governa um efeito específico
A governança de pré-execução avalia uma operação proposta em um ponto no qual sua execução ainda pode ser impedida. “Antes” se refere ao efeito governado. Uma verificação antes de reiniciar o serviço de staging pode governar essa reinicialização mesmo que o assistente já tenha lido informações operacionais ou concluído outras etapas.
Durante um fluxo em andamento, uma decisão posterior pode governar uma etapa futura ou interromper o trabalho que a integração ainda consegue parar. Ela não pode desfazer uma reinicialização concluída nem recolher dados já entregues. Recuperação ou reversão, quando possível, é outra operação, com sua própria autoridade e evidência.
O exemplo da reinicialização, portanto, precisa de uma verificação antes de disparar a operação para governar a solicitação que aguardava na fila. Cancelar uma nova tentativa pode limitar outro efeito, mas não comprova que a primeira reinicialização foi impedida. A governança de agentes de IA situa essas decisões individuais dentro da autoridade mais ampla delegada ao agente.
O guia de governança pré-execução examina como vincular uma decisão a destinos e argumentos concretos, incluindo chamadas que contêm várias operações.
Trate o comportamento em falhas como parte do contrato de política
Uma dependência usada em runtime pode exceder o tempo de resposta ou ficar indisponível. O executor ainda faz algo: continua, permanece pendente, para ou segue outro caminho definido. Revise esse comportamento explicitamente para a operação protegida. Um timeout não é uma decisão de política de que a solicitação é aceitável.
Quando a política exige autorização antes da execução, a ausência dessa autorização não deve ser tratada como aprovação. O Authorization Cheat Sheet da OWASP, em inglês recomenda verificar permissões a cada solicitação e tratar falhas de autorização sem criar um caminho para contorná-la. Esse é um requisito de projeto a avaliar; não descreve o comportamento de todo adaptador de runtime.
Se uma integração complementar estiver configurada para continuar quando a avaliação falha, documente essa perda de controle no caminho afetado. Avalie a autorização que permanece no destino. Não relate a verificação que falhou como aplicação de um controle preventivo apenas porque as solicitações normais são avaliadas com sucesso.
Novas tentativas e caminhos alternativos exigem o mesmo cuidado. Na fila hipotética, um worker não deve tentar novamente uma reinicialização com permissão expirada apenas porque uma tentativa anterior falhou. Uma exceção manual pode oferecer outra via autorizada, mas precisa de responsável, escopo e evidência de qual via foi usada.
As evidências devem mostrar como o contrato foi cumprido
Mantenha clara a distinção entre o resultado da política e a forma como o executor o tratou. Uma resposta emitida por um adaptador mostra o que ele produziu. Uma confirmação de recebimento pode mostrar que outro componente a recebeu. Para estabelecer o que foi aplicado, é preciso obter evidências do comportamento do executor e também do destino quando a conclusão depender de um efeito externo.
Para a reinicialização em fila, uma revisão útil conectaria a solicitação inicial, o estado da janela usado na avaliação, a verificação posterior de validade, o tratamento dado pelo worker e qualquer resultado observado da reinicialização. Se o resultado no destino não puder ser estabelecido, mantenha-o como desconhecido. O exemplo não foi executado como teste; esses registros são evidências propostas, não logs inventados.
A análise sobre observabilidade e governança aprofunda a comprovação de um controle preventivo. Aqui, o requisito adicional é preservar o contexto e as condições em que uma decisão poderia ser aplicada, para que um revisor posterior possa avaliar se o contrato foi cumprido.
Onde a governança em runtime pode atuar
Uma integração no navegador pode participar antes de uma submissão compatível. Um hook de agente de código pode participar em um evento específico de seu ciclo de execução. Uma aplicação ou serviço pode incluir uma verificação antes de chamar uma ferramenta, liberar uma saída ou alterar um recurso. Cada local expõe um contexto diferente e dá à integração uma autoridade diferente sobre a próxima etapa.
Uma verificação de saída pode governar um uso posterior do conteúdo gerado quando esse uso aguarda a verificação. Isso não comprova que prompts ou chamadas de ferramenta anteriores foram governados. Uma observação recebida após uma operação pode informar uma decisão posterior sem se tornar um controle preventivo para a operação já concluída.
Para cada superfície, verifique a integração instalada, o evento relevante, as respostas suportadas e os caminhos alternativos de execução. “Runtime habilitado” não basta para descrever a cobertura. Uma descrição útil identifica o que pode ser avaliado, qual operação pode ser restringida e onde a implementação não permite estabelecer o efeito.
Use o Framework KonaSense de Governança de IA em Runtime para examinar quais responsabilidades e informações faltam para sustentar um resultado específico de governança.
Como a KonaSense aborda a governança de IA em runtime
Os caminhos de integração da KonaSense têm contratos diferentes. Seu comportamento deve ser avaliado para a operação e a instalação específicas.
Na implementação do Kona for Browser revisada, um caminho compatível de submissão pelo DOM pode reter o envio após uma decisão de bloqueio e tentar substituir o texto quando uma transformação é retornada. O efeito depende do caminho e do modo de inspeção. Alguns caminhos de erro ou ausência de resposta retomam o envio, portanto a implementação não comprova uma garantia universal de impedir a operação em caso de falha. Uma atualização no editor, isoladamente, não prova o que o destino recebeu.
No caminho Claude Code PreToolUse revisado para o Kona for Agents, o adaptador pode retornar uma negativa, solicitar aprovação ao usuário ou retornar argumentos de ferramenta alterados. Outros hooks mapeiam as decisões de forma diferente, e erros de avaliação resultam em Allow. Esses mapeamentos não devem ser generalizados como aprovação ou substituição de conteúdo em todo hook ou agente.
Os caminhos de ingestão OTLP revisados avaliam a atividade exportada separadamente da execução da aplicação emissora. Eles retornam respostas OTLP sem decisões de intervenção para essa aplicação. Um resultado de política associado ao evento coletado é evidência de análise, não confirmação de que o emissor aplicou um controle.
Avaliar esses mecanismos exige verificar o contrato em cada ponto suportado: contexto, decisão, aplicação, comportamento em falhas e evidências disponíveis. Nenhum rótulo de decisão, por si só, comprova esses cinco elementos.