O Framework KonaSense de Governança de IA em Runtime é um modelo de oito funções para examinar como uma organização conecta conhecimento sobre o uso de IA, decisões de política com responsáveis definidos, controles efetivos e evidências que podem ser revisadas. Ele ajuda a equipe a identificar qual responsabilidade ou relação falta para sustentar um resultado específico de governança.
As funções são Descobrir, Identificar, Observar, Avaliar, Decidir, Aplicar, Aprovar e Evidências. Este é um modelo proposto pela KonaSense para analisar programas de governança. Não é uma norma externa, um esquema de certificação ou uma comprovação de que um produto implementa as oito funções. Sua utilidade precisa ser avaliada diante dos fluxos reais da organização e das evidências disponíveis.
Comece por um resultado de governança e um limite de escopo
Escolha um resultado concreto antes de avaliar as funções. “Governar nossos agentes” é amplo demais para determinar qual informação ou controle está faltando. Em um fluxo hipotético de manutenção, “Não enviar uma ordem de manutenção a um prestador externo até que o responsável autorizado pela unidade aprove seu escopo” identifica uma operação protegida e um requisito de autoridade.
Defina as aplicações, pessoas, agentes, ambientes e caminhos incluídos na revisão. Nomeie a operação sob governança e o destino relevante. Registre as exclusões para que uma conclusão sobre um caminho gerenciado não se transforme silenciosamente em uma conclusão sobre todas as formas de realizar o trabalho.
O AI RMF Playbook do NIST, em MAP 1.1, em inglês, orienta a compreender a finalidade pretendida, o contexto de uso, os pressupostos e as limitações. Esses princípios ajudam a definir o escopo da revisão; não definem este modelo de oito funções.
A governança do uso de IA estabelece as condições para os usos permitidos. Este framework examina quais funções tornam essas condições aplicáveis e verificáveis dentro do escopo escolhido.
Leia as funções como responsabilidades conectadas
A ordem dos nomes não é uma sequência universal de execução. Um inventário pode existir antes do início de um fluxo, a identificação pode ser refinada durante seu funcionamento e observações podem informar avaliações posteriores. Várias funções podem operar em um mesmo componente ou estar distribuídas entre equipes.
A aprovação é condicional. Quando a política a exige, a operação protegida deve permanecer pendente até que uma decisão autorizada se aplique. As informações de aprovação alimentam a decisão e a verificação de sua aplicabilidade antes da liberação; a posição de Aprovar depois de Aplicar na lista não coloca a autorização humana depois do efeito. As evidências acompanham as funções, inclusive decisões que não produzem ação.
Separe o responsável pela função do mecanismo que executa parte dela. Um serviço pode avaliar uma política sem ser responsável pela regra de negócio. Uma equipe de operações pode manter uma integração sem ter autoridade para aprovar uma exceção. O NIST, em GOVERN 2.1, em inglês, orienta a documentar papéis e canais de comunicação; as atribuições abaixo são responsabilidades que cada organização precisa definir.
Oito funções, responsabilidades conectadas
Os números identificam funções, não a ordem de execução. As conexões mostram relações a examinar dentro do escopo da revisão.
- 8. Evidências
Conecte registros relevantes entre as funções, preservando suas fontes, significado e limites.
- 1. Descobrir
- Identifique os sistemas de IA e caminhos de uso conhecidos, com suas fontes e limites de cobertura.
- 2. Identificar
- Associe a atividade às identidades e ao contexto empresarial relevantes; torne explícitas as associações não esclarecidas.
- 3. Observar
- Estabeleça quais atividades e condições podem ser observadas, por quais fontes e com quais lacunas.
O contexto de Descobrir, Identificar e Observar informa as funções Avaliar e Decidir. As lacunas de contexto permanecem explícitas.
- 4. Avaliar
- Avalie os critérios aplicáveis diante da operação e dos fatos disponíveis, preservando as incertezas relevantes.
- 7. Aprovar
Quando a política exigir aprovação, mantenha a operação protegida pendente até que uma decisão autorizada se aplique.
As informações de aprovação alimentam Decidir e a verificação de aplicabilidade antes da liberação. Aprovação pendente, indisponível ou expirada não é permissão.
- 5. Decidir
- Selecione uma resposta autorizada para o contexto avaliado. Permitir autoriza uma tentativa; não comprova sucesso.
Uma decisão só pode limitar a operação protegida em um ponto capaz de aplicar a resposta.
- 6. Aplicar
- Aplique a resposta suportada no ponto de controle identificado; indique os caminhos afetados e o que permanece sem verificação.
As oito funções
1. Descobrir
Quais aplicações de IA, agentes, ferramentas de código e caminhos de uso estão no escopo? A descoberta estabelece o que o programa encontrou e onde procurou. Cadastros de aplicações, configurações de implantação, relatos de usuários e observações podem contribuir com partes diferentes desse panorama. Preserve suas fontes e seus limites de cobertura, em vez de reuni-los em uma afirmação de completude sem sustentação.
O responsável pelo inventário precisa da participação das equipes que operam essas superfícies. Um resultado passível de revisão identifica os sistemas conhecidos, seus responsáveis, os caminhos examinados e as áreas ainda não esclarecidas. O NIST, em GOVERN 1.6, em inglês, trata da manutenção de inventários de sistemas de IA e da atribuição dessa responsabilidade. Um inventário preenchido ainda não comprova que todo uso de cada aplicação listada está aprovado.
2. Identificar
De quem é essa atividade e qual contexto empresarial se aplica? A identificação associa a atividade aos usuários, dispositivos, agentes, aplicações e sessões relevantes. Também distingue quem solicita, a pessoa ou o recurso afetado e a identidade usada para executar uma operação. Uma conta de serviço compartilhada pode ser conhecida enquanto o usuário que iniciou a atividade permanece sem identificação.
Os responsáveis por identidade e pelas aplicações devem estabelecer as fontes e os mapeamentos que sustentam essas associações. O resultado deve permitir ao revisor partir de uma referência de atividade e chegar às identidades relevantes, ou ver exatamente qual associação não pôde ser estabelecida. Um nome fornecido por um agente não é automaticamente uma identidade verificada, e uma identidade verificada não constitui, por si só, autorização para a tarefa.
3. Observar
Quais atividades e condições o programa consegue de fato observar? A observação fornece os sinais necessários para entender usos, sessões, solicitações de ferramentas, movimentação de dados, riscos e ações. Selecione os sinais de acordo com a pergunta. Um registro de solicitação de ferramenta proposta e um registro de alteração concluída no destino respondem a perguntas diferentes.
As equipes responsáveis por instrumentação e coleta precisam especificar a fonte, o caminho de coleta, as restrições de acesso e as lacunas conhecidas. Seu resultado para revisão é uma descrição delimitada das observações disponíveis, incluindo informações ausentes ou atrasadas. Coletar mais conteúdo não é automaticamente mais útil; a captura desnecessária de prompts ou respostas pode criar cópias adicionais de informações sensíveis. A função Evidências determina como as observações relevantes sustentam uma conclusão passível de revisão.
4. Avaliar
O que a política e os critérios de risco aplicáveis dizem sobre esse contexto? A avaliação precisa da versão relevante da regra, da operação ou do uso em análise e dos fatos que afetam a resposta. Mantenha distinguíveis uma finalidade declarada, um atributo observado e uma condição não esclarecida. Caso contrário, uma suposição pode entrar na avaliação como se fosse evidência.
O responsável pela política define os critérios; o responsável pelo mecanismo de avaliação deve aplicá-los conforme o previsto. Uma avaliação passível de revisão identifica os critérios examinados, os fatos utilizados e as incertezas relevantes ou informações de contexto ausentes. Isso permite distinguir uma regra inadequada da aplicação incorreta de uma regra adequada. A avaliação pode ser automatizada, humana ou combinada; o modelo não exige automatizar todo julgamento organizacional.
5. Decidir
Qual resposta está autorizada para o uso ou a operação avaliados? Uma decisão pode permitir, negar, exigir aprovação, solicitar transformação, ocultação ou remoção de conteúdo sensível quando essas respostas forem suportadas, emitir um alerta ou registrar. Seu significado precisa ser explícito. Um alerta pode solicitar atenção sem reter uma operação. Permitir pode autorizar uma tentativa sem comprovar seu sucesso.
Defina quem tem autoridade para escolher a resposta, inclusive quem pode aceitar uma exceção e dentro de qual escopo. O resultado é uma decisão identificável, vinculada ao contexto avaliado e às suas condições. A falha em obter uma decisão deve continuar distinguível de uma decisão que permite a operação. O pilar de governança em runtime aprofunda os contratos de validade e falha que essa responsabilidade precisa especificar.
6. Aplicar
Qual ponto consegue aplicar a decisão à operação protegida? A aplicação depende de um mecanismo com a autoridade necessária e de uma forma de associar a decisão ao que será controlado. Enviar o resultado de uma política a outro componente ainda não é evidência de que ele foi respeitado.
O responsável pelo ponto de controle deve estabelecer as respostas suportadas, os caminhos afetados e o comportamento quando não for possível aplicar a decisão. O resultado para revisão descreve o que foi aplicado e o que permanece sem verificação, no limite relevante. Quando a autorização precisa preceder a execução, a Transaction Authorization Cheat Sheet da OWASP, seção 2.8, em inglês descreve um controle final de autorização vinculado à execução. Esse princípio não comprova controle preventivo sobre caminhos externos àquele ponto.
7. Aprovar
Quem pode tomar a decisão humana exigida por essa operação? A aprovação precisa de uma proposta identificável, dos fatos relevantes para revisão e de uma pessoa autorizada para aquele escopo. Alguém capaz de explicar a finalidade de negócio pode não ter autoridade para aprovar acesso a um recurso de outra equipe. A falta de evidência técnica também não é resolvida simplesmente pedindo que essa pessoa clique de novo.
O responsável pelo negócio ou pelo recurso relevante define a delegação e a autoridade para exceções. Um resultado passível de revisão preserva quem decidiu, o que foi aprovado ou rejeitado e as condições aplicáveis. Aprovação pendente, indisponível ou expirada deve continuar distinguível de permissão. O NIST, em GOVERN 3.2, em inglês, orienta a diferenciar os papéis humanos na supervisão; não exige que uma pessoa aprove toda ação de IA.
8. Evidências
O que um revisor pode comprovar sobre a decisão, sua aplicação e o resultado? As evidências conectam registros das funções relevantes, preservando sua origem, significado e limitações. Uma solicitação negada pode ter evidência de decisão sem tentativa de ação. Uma solicitação enviada pode ter resultado desconhecido no destino.
Os responsáveis pelas evidências e os investigadores precisam acordar a pergunta de revisão, os registros necessários, o acesso permitido e a retenção. O resultado deve distinguir conclusões sustentadas de perguntas não esclarecidas e identificar o que resolveria cada lacuna relevante. O guia de trilha de auditoria de agentes de IA explica essas relações em detalhe. Um registro protegido pode continuar incompleto, e um sistema de coleta não pode comprovar um evento que suas fontes nunca observaram.
Diagnostique uma lacuna sem confundi-la com outra
Revisão de um projeto hipotético: a equipe responsável pelas instalações propõe um assistente que prepara ordens de manutenção a partir de relatos de funcionários. A preparação interna é permitida. Antes de enviar uma ordem a um prestador externo, o responsável autorizado pela unidade deve aprovar o trabalho e o destinatário. Essas condições compõem um exercício hipotético de projeto; não descrevem uma integração existente, um incidente ou um resultado de teste.
Suponha que o desenho contenha um registro no inventário de aplicações, uma conta compartilhada para envio, um avaliador de política, um pedido de confirmação humana e uma fila de entrega. Esses componentes ainda não comprovam o resultado exigido. A revisão precisa examinar as relações entre eles.
| Condição no desenho proposto | Responsabilidade ou relação a examinar | O que resolveria a lacuna |
|---|---|---|
| O assistente está no inventário, mas o desenho não associa as solicitações de envio ao funcionário que as iniciou e à unidade relevante | Identificar deve fornecer o contexto necessário a Avaliar e Aprovar | Uma fonte e um mapeamento estabelecidos para as identidades e a unidade relevantes, com tratamento explícito das associações não esclarecidas |
| O pedido de confirmação é enviado ao solicitante, mas nenhuma regra estabelece sua autoridade sobre a unidade | Aprovar não tem uma delegação estabelecida; Decidir não pode tratar a confirmação como a permissão exigida | Autoridade de aprovação definida e um mecanismo que preserve uma decisão aplicável à ordem revisada |
| A interface da fila informa aceitação, mas o desenho não tem uma observação que comprove a entrega ao prestador | A função Evidências ainda não pode sustentar uma conclusão de entrega | Uma fonte capaz de comprovar o resultado necessário no destino, ou uma conclusão explícita de que a entrega permanece desconhecida |
A primeira lacuna não se resolve acrescentando outra linha ao inventário de aplicações. A segunda não se resolve retendo uma conversa mais longa. A terceira não significa automaticamente que o envio falhou ou que um controle de aprovação foi contornado. Cada lacuna exige um responsável capaz de resolver a atribuição específica e evidências adequadas àquela pergunta.
A análise da descoberta ao enforcement examina uma lacuna hipotética de coordenação em que uma condição de política não tem uma fonte estabelecida nem um responsável definido.
O guia de arquitetura ajuda a localizar os componentes e limites de confiança quando uma relação exige trabalho de engenharia. O framework mantém esse trabalho conectado ao resultado de governança que ele deve sustentar.
Transforme o diagnóstico em uma decisão de revisão delimitada
Distinga a ausência de uma capacidade ou atribuição de um resultado ainda não verificado. Se nenhum componente consegue reter o envio ao prestador, o ponto de aplicação exigido está ausente do desenho proposto. Se um controle está especificado, mas seu comportamento ainda não foi examinado, a prevenção não está verificada. Essas constatações não devem receber a mesma descrição ou correção.
Use “não aplicável” apenas com uma justificativa de escopo. Um fluxo pode não exigir aprovação humana para determinada operação de baixo risco sob a política estabelecida. Alguém continua responsável por essa escolha de política, seus limites e sua revisão quando as condições mudarem. O rótulo não deve esconder uma questão de autoridade não resolvida nem fazer desaparecer a responsabilidade pela governança.
Para cada lacuna relevante, registre o resultado afetado, a relação ausente, a pessoa capaz de resolvê-la e a observação ou decisão necessária para encerrá-la. Defina uma condição operacional provisória quando necessário. Na revisão hipotética, isso poderia significar permitir a preparação interna e manter o envio a prestadores fora do piloto até que seu caminho de aprovação estivesse estabelecido. Essa é uma restrição proposta, não um controle testado aqui.
Priorize pela consequência e pela incerteza. Um caminho capaz de realizar uma operação externa não autorizada pode exigir atenção antes de uma lacuna de relatório com consequências menores. A incerteza sobre esse caminho pode, por si só, limitar o que se pode aprovar de forma responsável. Não transforme o número de funções concluídas em uma pontuação de maturidade inventada nem use uma pontuação agregada para esconder um controle ausente que o resultado exige.
O Modelo de Maturidade de Governança de Agentes de IA oferece seis níveis para revisar o que um programa com escopo definido pode demonstrar, com requisitos de evidência e limites explícitos.
Reveja a avaliação quando o fluxo, a autoridade, as fontes de informação ou os mecanismos de controle mudarem. O NIST, em MANAGE 4.1, em inglês, trata de mecanismos de monitoramento e revisão após a implantação. A pergunta prática aqui é quais conclusões anteriores continuam sustentadas e quais relações precisam ser verificadas novamente.
Aplique o modelo a uma implementação real
Use as mesmas perguntas ao revisar o Kona for Agents, o Kona for Browser ou os processos ao redor deles na organização. Nomeie a integração real e a operação protegida antes de atribuir uma função a um componente. A escolha de um produto não comprova quais responsabilidades estão atendidas em uma instalação específica.
O resultado útil é uma decisão de revisão sobre a qual a equipe consegue agir: qual uso está coberto, qual decisão pode afetar qual operação, quem responde por uma condição não esclarecida e quais evidências ainda são necessárias. As oito funções oferecem uma estrutura para chegar a esse resultado; não substituem as evidências exigidas para sustentá-lo.