Um modelo aprovado ainda pode ser usado para solicitar uma ação não autorizada. Quando um agente transforma a saída do modelo em uma operação em outro sistema, a governança precisa alcançar a autoridade usada para executar essa operação.
Isso muda a distribuição de responsabilidades. O programa de IA pode determinar que um modelo é adequado para uma tarefa. O responsável pela área de negócio pode aprovar a finalidade do fluxo de trabalho. O responsável pelo sistema de destino ainda precisa definir o que esse fluxo pode ler ou alterar. Essas decisões têm escopos diferentes, mesmo quando uma equipe toma várias delas.
Levar a governança dos modelos às ações significa explicitar esses limites. A avaliação do modelo continua necessária. Sua aprovação deve incluir condições que os responsáveis pela execução consigam interpretar e aplicar.
O que a aprovação de modelos e fornecedores continua resolvendo
A avaliação de um modelo pode estabelecer se seu comportamento e suas limitações são aceitáveis para o uso pretendido. A análise do fornecedor pode examinar o tratamento de dados, as dependências do serviço e as condições contratuais. Juntas, essas análises ajudam a decidir se a organização deve usar aquele modelo ou serviço, e sob quais condições.
Essas decisões continuam relevantes depois da implantação. Se um fluxo deixa de resumir material público e passa a interpretar registros internos, sua avaliação anterior talvez já não responda às questões necessárias. A governança precisa ter um caminho para levar essa mudança aos revisores responsáveis.
O limite é que a adequação ao uso não concede autoridade para operar. Uma avaliação pode sustentar o uso de um modelo para preparar uma recomendação sem estabelecer permissão para executá-la. O programa de governança de IA precisa conectar essas duas decisões, preservando seu alcance, em vez de reuni-las sob um único rótulo de “aprovado”.
Como um agente muda a decisão de aprovação
Um agente pode selecionar uma sequência de operações enquanto executa uma tarefa. Por isso, o escopo da delegação importa: aprovar o objetivo não deve deixar indefinida a autoridade disponível ao agente.
Exemplo hipotético: uma equipe pede a um agente que prepare uma conciliação financeira com dados sintéticos em um ambiente de teste isolado. Um revisor confere o resultado e aprova sua qualidade. O agente então propõe gravar esse resultado no sistema que mantém os registros oficiais da organização.
O cálculo não ficou menos preciso. O que mudou foi o uso proposto. Uma conciliação correta de dados de teste continua sendo um resultado de teste; aprovar sua qualidade não autoriza uma entrada nos registros oficiais. A gravação proposta exige uma decisão própria sobre o destino, a identidade que a executará e os limites de sua autoridade. Até que essas condições estejam definidas, ela deve permanecer fora do fluxo permitido.
Quem patrocina o experimento pode ter autoridade para aprovar o teste sem poder autorizar gravações naquele sistema. O responsável pelo destino pode autorizar uma operação de escopo restrito sem poder aprovar o modelo para outro uso. Uma aprovação não deve ampliar silenciosamente o alcance da outra.
É nesse ponto que o registro da aprovação precisa ser preciso. “Agente de conciliação aprovado” deixa o limite em aberto. “Pode preparar resultados com dados sintéticos no ambiente de teste; não pode gravar no sistema de registro” dá ao responsável pelo experimento e à equipe de engenharia uma decisão que ambos conseguem aplicar.
Por que a ação é um ponto útil de controle
Uma ação concreta revela a autoridade que o fluxo está prestes a exercer. A organização pode avaliar a operação solicitada conforme as regras do responsável pelo destino, usando contexto verificável em vez de aceitar a explicação do agente como permissão.
A orientação da OWASP sobre Excessive Agency recomenda aplicar a autorização nos sistemas de destino, sem depender de um LLM para decidir se a ação é permitida. Para o programa corporativo, a consequência é direta: a aprovação pela equipe de IA não deve se sobrepor à autorização no destino.
Isso não exige que uma pessoa aprove cada operação rotineira. O responsável pelo destino pode aprovar uma classe definida de ações por meio de uma política, com permissões delimitadas e condições para exceções. O controle em runtime verifica, durante a execução, se a solicitação concreta se enquadra nessa delegação. Uma solicitação fora desse escopo precisa de outra decisão, mesmo que a tarefa que a originou tenha sido aprovada.
O pilar de governança de agentes de IA explica a cadeia técnica de execução e seus controles em mais detalhe. A questão de gestão é quem tem autoridade para definir cada limite e quem pode alterá-lo.
Conectar observação, decisão, aplicação da política e evidência
A observação permite que a operação proposta seja avaliada. Ela deve fornecer à equipe responsável contexto verificado suficiente para determinar qual política se aplica. Lacunas, como uma identidade desconhecida no destino, devem ficar visíveis na decisão, em vez de serem preenchidas com afirmações do agente.
A decisão transforma a política do responsável em um escopo permitido, uma negativa ou uma solicitação a alguém com autoridade para aprovar. O mecanismo de aprovação precisa reconhecer essa autoridade. Quem iniciou a tarefa não recebe automaticamente o direito de aprovar todas as operações que ela gerar.
A aplicação da política faz a decisão produzir efeito sobre a execução. A equipe que opera a integração deve estabelecer onde uma solicitação proibida é interrompida e quais permissões do destino continuam valendo. Registrar uma decisão em um sistema de aprovações deixa essa responsabilidade em aberto se ninguém responde por aplicá-la no caminho de execução.
A evidência permite revisar essas responsabilidades. Defina quem consegue recuperar a política, a decisão, a aprovação e o resultado da execução, quando disponível, além de explicar as lacunas. Um registro de permissão e um registro de gravação concluída respondem a perguntas diferentes. Preservar essa distinção evita que um relatório de governança apresente como verificado mais do que as evidências permitem.
O que os CISOs devem mudar no processo de aprovação
Comece por definir quem tem autoridade para decidir. O NIST AI RMF Playbook, GOVERN 2.1 e 2.3 orienta a clareza de papéis e da comunicação sobre riscos de IA, com responsabilidade executiva pelas decisões de risco no desenvolvimento e na implantação. Nossa recomendação é levar essa clareza à passagem entre a aprovação de um caso de uso de IA e o responsável por cada sistema afetado.
Uma solicitação de aprovação deve dizer qual autoridade concede e o que permanece fora dela. O programa central pode registrar o uso aceito e as condições relativas ao modelo. O responsável pelo destino pode especificar as operações e permissões autorizadas ali. A equipe que opera o fluxo pode documentar onde essas restrições se aplicam e quem mantém as evidências. Organizações pequenas podem atribuir várias responsabilidades à mesma pessoa e ainda assim registrar as decisões separadamente.
A revisão de mudanças também precisa acompanhar alterações de autoridade. Se o fluxo de teste recebe uma credencial capaz de gravar em registros oficiais, a autorização no destino precisa ser revista, mesmo que modelo, fornecedor e prompt permaneçam iguais. Da mesma forma, trocar o modelo pode exigir uma nova avaliação de adequação sem que as permissões do fluxo mudem. Um único processo de gestão de mudanças pode encaminhar cada questão ao responsável adequado.
O tratamento de exceções exige o mesmo rigor. Defina quem pode aprovar a ampliação do escopo, por quanto tempo essa aprovação vale e como os limites originais serão restabelecidos. Quem aceita o risco também precisa saber o que acontece quando um serviço de políticas ou mecanismo de aprovação fica indisponível. Esse comportamento deve ser verificado na integração real; um chamado de aprovação ou o nome de uma categoria de produto não o comprova.
A perspectiva da KonaSense
A posição da KonaSense é que a governança deve acompanhar a autoridade delegada até a execução. Uma discussão útil sobre controles de agentes começa pela ação que a organização pretende permitir, pela pessoa responsável por essa permissão e pelo ponto em que ela pode ser aplicada.
Essa é a base para avaliar o Kona for Agents: identificar a integração específica do agente, examinar como a decisão é tomada e aplicada, e verificar sua cobertura e seu comportamento em caso de falha. O cenário financeiro acima ilustra um limite de autorização; não é uma afirmação de que a KonaSense se integra a sistemas financeiros. A avaliação do produto deve esclarecer quais limites a integração implementa para as equipes responsáveis por operá-la.