Uma organização pode saber qual agente está em atividade, ter uma política por escrito e dispor de um ponto capaz de reter uma ação, mas ainda não ter base para decidir. O trabalho que falta pode ser definir quem responde por uma condição de negócio e o que confere autoridade à informação sobre ela.
As oito camadas discutidas aqui são uma perspectiva analítica das oito funções do Framework KonaSense de Governança de IA em Runtime. Elas descrevem responsabilidades conectadas, não oito serviços, uma sequência de execução prescrita ou controles obrigatórios em todo caminho. Sua utilidade é ajudar a equipe a encaminhar uma lacuna de governança às pessoas capazes de resolvê-la.
Um inventário não resolve uma condição de política
Exercício hipotético de revisão de desenho: uma organização exige o aceite do solicitante antes que um agente possa encerrar um chamado interno de atendimento. A aplicação consta no inventário, e o desenho proposto inclui um ponto no qual o encerramento pode ser retido. Porém, ninguém estabeleceu qual fonte tem autoridade para registrar o aceite nem quem responde por mantê-la. Nenhum chamado é encerrado e nenhum teste é realizado neste exemplo.
O inventário ajuda a localizar a aplicação e seu operador. Ele não pode decidir o que significa “aceito” no processo de atendimento. Um comentário no chamado pode conter uma expressão de satisfação, a interpretação de um operador ou um texto copiado de outra fonte. Encontrar a palavra não comprova que a pessoa exigida pela política aceitou a solução relevante.
O AI RMF Playbook do NIST, em GOVERN 1.6, trata da manutenção de inventários de sistemas de IA e da atribuição de responsabilidade por eles. É um trabalho útil, com finalidade definida. O programa de governança ainda precisa conectar a aplicação conhecida à autoridade e às informações exigidas por sua política.
Acrescentar um campo chamado “aprovação necessária” ao inventário pode documentar a condição. Isso não estabelece a fonte que permitirá satisfazê-la. A equipe passou de uma questão de descoberta para uma responsabilidade não resolvida no processo de negócio.
Estabeleça o significado antes de implementar a condição
O responsável pelo processo de atendimento precisa definir qual ação constitui aceite e quem pode fornecê-lo. Seria uma resposta autenticada do solicitante, uma decisão de alguém com delegação para isso ou outro procedimento expressamente permitido? São escolhas de desenho para a organização hipotética, não requisitos para toda central de atendimento.
A fonte também precisa ter uma relação definida com o chamado e a solução em análise. O aceite de uma solução anterior não deve se tornar, silenciosamente, o aceite de outra materialmente diferente. O processo deve estabelecer o significado do registro, quem pode criá-lo ou alterá-lo e em quais condições ele se aplica.
O responsável pela política e o responsável pelo processo resolvem essas perguntas. A partir daí, o responsável pela integração pode determinar como a informação relevante chega ao avaliador e o que o controle consegue fazer com a decisão. Uma pessoa pode exercer vários papéis; o requisito é uma atribuição clara de autoridade e responsabilidade, não um organograma maior.
O NIST, em GOVERN 2.1, recomenda documentar papéis, responsabilidades e canais de comunicação na gestão de riscos de IA. Aplicado ao exemplo, esse princípio significa que quem configura o ponto de controle não deveria precisar inventar a definição de aceite válido da organização.
O guia de arquitetura de governança de agentes explica como o contexto de uma decisão atravessa limites técnicos. Antes de implementar essa conexão, o programa precisa estabelecer em qual fonte o componente receptor pode se apoiar e o que essa fonte tem autoridade para afirmar.
Mais observações podem ajudar sem fornecer a autoridade que falta
Observações adicionais podem revelar que um registro de aceite já existe ou explicar por que um registro existente não está chegando ao avaliador. Instrumentação e investigação podem, portanto, fazer parte da solução. A distinção está entre encontrar evidência de uma condição já estabelecida e decidir o que deve contar como essa condição.
Se o processo não tem uma fonte ou delegação acordada, coletar uma conversa mais longa não estabelece esse acordo em nome do responsável. Extrair uma frase com mais precisão também não decide se seu autor tinha autoridade para aceitar o trabalho. A observação pode informar a revisão enquanto a questão de autoridade permanece em aberto.
Por isso, a próxima tarefa precisa ser nomeada com precisão. “Melhorar a visibilidade do agente” descreve uma área ampla de trabalho. “Estabelecer a fonte do aceite e a autoridade para registrá-lo neste processo de atendimento” identifica a relação não resolvida. Depois dessa definição, uma tarefa de implementação pode especificar como obter e verificar a informação relevante.
Preserve as observações válidas já disponíveis. Uma condição não resolvida não apaga o inventário, não torna todos os registros inutilizáveis nem prova que o agente agiu indevidamente. Ela limita a conclusão que o programa pode alcançar sobre a conformidade do encerramento proposto com a política.
Evite transformar uma condição não resolvida em permissão
Na política hipotética, o encerramento exige um aceite aplicável. Se esse aceite não puder ser comprovado, um registro ausente não deve ser tratado como permissão. Também não prova que o solicitante rejeitou a solução. São conclusões diferentes, que exigem evidências diferentes.
Um responsável com autoridade para isso pode definir um procedimento separado de exceção ou reconsiderar a própria condição. Essa é uma decisão explícita de política, com escopo e responsabilidade próprios. Ela não deve surgir por acidente em uma integração que substitui a informação por um campo conveniente ou trata um valor indisponível como aprovação.
Um pedido de confirmação ao operador do agente não é automaticamente o aceite do solicitante. A organização precisa estabelecer se esse operador pode agir em nome do solicitante e se a decisão abrange a solução relevante para o chamado. Acrescentar uma pessoa ao fluxo não elimina a necessidade de definir sua autoridade.
Enquanto a relação não estiver estabelecida, a equipe pode manter o encerramento fora do caminho automatizado, sob uma restrição operacional definida. Essa restrição é uma resposta proposta à lacuna hipotética, não um controle testado aqui. O pilar de governança em runtime explica o trabalho separado de especificar e verificar como uma decisão afeta a operação protegida.
Use as camadas para encaminhar o próximo trabalho
O framework torna a lacuna visível entre as responsabilidades. A descoberta localiza o agente e seu caminho de uso. A questão do aceite envolve o contexto de negócio e a autoridade necessária para avaliar e decidir. O responsável pelo controle precisa de uma resposta utilizável, e o revisor precisa de evidências do que essa resposta estabeleceu.
Ao concluir uma passagem de responsabilidade, revise o resultado à luz do requisito original. Um novo campo pode estar preenchido sem que alguém tenha autoridade para produzir seu conteúdo. Um procedimento documentado pode existir sem que o caminho controlado disponha de uma forma suportada de usar seu resultado. Se alguma dessas relações continuar sem solução, mantenha a lacuna e seu responsável visíveis, em vez de declarar a política operacional apenas porque cada equipe concluiu sua própria tarefa.
O framework canônico contém as oito funções e seu diagrama. Use-o para identificar qual responsabilidade precisa ser resolvida a seguir e leve essa decisão ao trabalho de processo ou engenharia correspondente. O progresso está em conseguir sustentar a decisão de governança dentro de seu escopo, com uma fonte pela qual alguém responda e um controle aplicável, e não apenas em ampliar o inventário ou reter um log mais longo.