O Modelo de Maturidade de Governança de Agentes de IA da KonaSense é um modelo de seis níveis para descrever o que uma organização pode demonstrar sobre a governança de um conjunto definido de fluxos de agentes e escolher o próximo avanço verificável. Ele avalia as evidências que sustentam uma afirmação de governança, não a quantidade de ferramentas compradas ou políticas escritas.
Os níveis são Não gerenciado, Descoberta, Observabilidade, Política, Aplicação em runtime e Governança adaptativa. Eles compõem uma estrutura de avaliação proposta pela KonaSense, não uma norma do setor, uma certificação ou um sistema de pontuação validado empiricamente. Um nível se aplica apenas ao escopo e às condições sustentados pela revisão.
Defina o que está sendo avaliado
Nomeie os fluxos de agentes, caminhos de execução, ambientes e operações incluídos na avaliação. Identifique os usuários relevantes, as identidades de execução, as configurações, as versões de política e o período de revisão. Um cliente interativo e uma tarefa agendada podem usar o mesmo software de agente com autoridades e controles diferentes.
Descreva o resultado de governança exigido. Para um agente que altera uma lista interna de responsáveis por escalonamento, esse resultado pode exigir que as mudanças fiquem restritas aos registros de uma equipe aprovada e respeitem a aprovação de um responsável designado. Esse é um requisito ilustrativo, não o relato de uma integração KonaSense. A avaliação precisa estabelecer o que pode mudar, qual autoridade se aplica e quais caminhos podem produzir o efeito.
A governança de agentes de IA define a delegação e as responsabilidades mais amplas. O Framework KonaSense de Governança de IA em Runtime mapeia as funções necessárias para sustentar um resultado de governança. Este modelo de maturidade acrescenta outra pergunta: o que o programa consegue demonstrar agora, dentro de seu escopo, e quais evidências justificariam a próxima afirmação?
Não reúna superfícies diferentes em uma pontuação média da empresa. Um controle em runtime demonstrado em um caminho pode coexistir com um executor agendado ainda não examinado. Preserve separadamente o achado mais restrito e a incerteza mais ampla. Se não for possível estabelecer o escopo, registre a avaliação como incompleta em vez de atribuir um nível que apenas aparente precisão.
Os seis níveis
Os níveis 1 a 5 se apoiam nas condições relevantes dos níveis anteriores dentro do escopo avaliado. Um documento de política, isoladamente, não estabelece o Nível 3 se a equipe não consegue identificar a atividade governada ou obter as observações necessárias para avaliá-la. Registre uma capacidade de nível posterior como um achado específico quando as condições que a sustentam ainda estiverem incompletas.
Nível 0: Não gerenciado
A atividade de agentes não conta com práticas consistentes de inventário, política ou evidências dentro do escopo revisado. A governança depende de conhecimento individual e decisões pontuais que a organização não consegue reconstruir ou manter de forma confiável.
Use essa descrição quando uma revisão delimitada estabelecer que essas práticas não operam de forma consistente. As evidências relevantes podem incluir o fluxo e a configuração reais, os registros disponíveis e a confirmação de responsabilidades com as pessoas envolvidas. Não conseguir obter registros ou conversar com um responsável é insuficiente por si só. Um ambiente não examinado ainda está sem avaliação; isso não basta para classificá-lo como não gerenciado.
Preserve as regras ou os controles individuais que a revisão encontrar. O primeiro avanço é estabelecer um inventário com responsável definido e um escopo para o uso relevante de agentes, identificando omissões conhecidas. Não é substituir a incerteza por um rótulo de Nível 0.
Nível 1: Descoberta
A organização consegue identificar os usos e as superfícies de agentes relevantes dentro do limite da avaliação. O inventário relaciona agentes e caminhos de execução conhecidos aos seus responsáveis e ambientes relevantes, em vez de listar apenas nomes de produtos.
Sustente essa afirmação com as fontes do inventário, o método usado para conciliá-las, o período ou a configuração descritos e as áreas que essas fontes não cobrem. Um catálogo de aplicações, uma observação de endpoint ou o relato de um operador podem estabelecer fatos diferentes; registre qual fonte sustenta cada entrada.
O próximo resultado a demonstrar é uma visão coerente da atividade relevante nesses caminhos. Um agente descoberto não está necessariamente monitorado, e uma entrada no inventário não comprova que suas ferramentas, sessões ou ações sejam observáveis. Mantenha esse limite associado ao achado de Nível 1.
Nível 2: Observabilidade
O programa consegue examinar sessões, ferramentas, ações e sinais de risco relevantes para os fluxos no escopo, preservando a origem e o significado das observações. A visibilidade precisa ser suficiente para a pergunta de revisão; não é uma promessa de capturar todos os eventos ou o raciocínio interno de um agente.
Mostre que os registros disponíveis podem ser relacionados à atividade em análise. Identifique o que a fonte observou, o que a coleta preservou e onde faltam informações. Uma solicitação proposta, uma tentativa de execução e um resultado no destino continuam sendo estágios diferentes. Um grande volume de logs não comprova que essas relações estejam disponíveis.
O guia de trilha de auditoria de agentes de IA descreve as relações entre evidências em detalhe. O próximo avanço é tornar os comportamentos aceitáveis e inaceitáveis explícitos o suficiente para avaliá-los diante desse contexto. Observar uma operação arriscada não mostra, por si só, que existe uma regra de governança ou que a operação pode ser restringida.
Nível 3: Política
As regras definem comportamentos aceitáveis e inaceitáveis para a atividade no escopo. Elas identificam condições relevantes, autoridade de decisão e tratamento de exceções. Os revisores conseguem determinar qual regra se aplica a um uso concreto ou a uma ação proposta, em vez de inferir permissão a partir da finalidade geral do agente.
As evidências incluem a versão de política aplicável, seu responsável, os fatos exigidos por suas condições e como os avaliadores interpretam suas respostas. Use casos concretos para estabelecer se uma regra distingue o comportamento pretendido daquele que ultrapassa a delegação. A avaliação pode envolver pessoas, software ou ambos; um documento chamado “política de IA” não comprova que suas condições sejam utilizáveis.
Esse nível não comprova aplicação em runtime. O próximo resultado é evidência de que uma decisão específica pode afetar a operação protegida em um ponto de controle disponível. Uma política que diz “exigir aprovação” e um componente que exibe um pedido de confirmação não comprovam, por si sós, que uma aprovação autorizada governa a execução.
Nível 4: Aplicação em runtime
A política pode afetar ações de agentes durante a execução em pontos de controle identificados. A afirmação precisa nomear a operação protegida, os caminhos que passam pelo controle e as condições em que a resposta pretendida pode ser aplicada.
As evidências devem conectar a proposta avaliada e a decisão ao comportamento do executor, com observações no destino quando o efeito alegado as exigir. Examine casos permitidos e restritos, além do comportamento relevante em falhas. Um registro de decisão, isoladamente, não comprova que o executor reteve uma operação. Um controle que permite a continuidade quando uma autorização exigida está indisponível não pode receber crédito por fazer cumprir essa autorização no caminho afetado.
O NIST, em MEASURE 2.3, em inglês, orienta a documentar medições sob condições semelhantes às de implantação e a considerar as diferenças entre os ambientes de medição e implantação. Isso sustenta a necessidade de especificar as condições de uma afirmação sobre controle; não valida este nível de maturidade. O pilar de governança em runtime explica os contratos de decisão e aplicação a examinar.
O próximo avanço é manter essa capacidade durante a operação e as mudanças, incluindo o tratamento de aprovações, as alterações de contexto e as lacunas de evidência. Uma demonstração bem-sucedida não comprova que o processo continua efetivo durante todo um período de revisão ou em outra configuração.
Nível 5: Governança adaptativa
A avaliação automatizada de política, os processos de aprovação aplicáveis, o contexto de risco e as evidências operam como um processo mantido ao longo do tempo, abrangendo os usos de IA e agentes no escopo. Mudanças e feedback levam a revisões com responsáveis definidos e ajustes verificados, com visibilidade contínua de onde o processo de governança se degradou ou permanece incompleto.
Adaptativa não significa que a política se reescreve ou se aprova sozinha. As pessoas continuam responsáveis por mudanças de política e exceções. A automação pode apoiar avaliação, encaminhamento, atualizações de contexto e coleta de evidências, enquanto decisões humanas continuam necessárias onde a política as exige. Operação contínua significa um processo mantido em operação, com cobertura e procedimentos de resposta definidos, não uma garantia de controle ininterrupto sobre todos os eventos.
Sustente essa afirmação com evidências ao longo de um período de revisão adequado: registros operacionais, exceções tratadas, lacunas detectadas, mudanças autorizadas e verificação da configuração resultante. O período e as observações precisam corresponder ao fluxo e à conclusão. O modelo não prescreve uma quantidade universal de dias nem trata uma regra de monitoramento configurada como prova de que seu processo de resposta funciona.
O NIST, em GOVERN 1.5, em inglês, trata de monitoramento planejado e revisão periódica com responsabilidades atribuídas. MANAGE 4.2, em inglês, trata de melhoria contínua, incluindo mudanças nos procedimentos organizacionais. Esses princípios sustentam a manutenção da governança; não tornam a política que se altera sozinha um requisito de maturidade.
Construa um achado com evidências, não com um rótulo de funcionalidade
Para cada nível proposto, mantenha um registro de revisão que identifique:
- Escopo e afirmação: os fluxos, caminhos, operações, configuração e período descritos pelo achado.
- Evidências de suporte: sua origem, o que foi examinado e qual requisito elas comprovam.
- Limites e evidências contrárias: exclusões, lacunas, falhas ou condições que impedem uma conclusão mais ampla.
- Decisão e responsável: a afirmação aceita pelo revisor, quem responde por ela e eventuais restrições operacionais.
- Próximo resultado: a capacidade ou relação de evidências específica a estabelecer antes de reconsiderar o nível.
O NIST, em MEASURE 2.1, em inglês, enfatiza a documentação dos conjuntos de teste, métodos, métricas e ferramentas usados na avaliação. Preserve contexto suficiente para que outro revisor entenda a avaliação de um controle. O rótulo de maturidade não deve substituir o registro que o sustenta.
Distinga um mecanismo exigido que está ausente de outro cujo comportamento não foi verificado. Se os registros estiverem inacessíveis, informe isso e identifique o que permitiria a revisão. Se um requisito for considerado não aplicável, registre a justificativa de escopo e a pessoa autorizada a fazer essa determinação. Nenhum desses estados deve se transformar silenciosamente em um requisito atendido ou em uma afirmação de que todo o ambiente é não gerenciado.
Quando as evidências forem heterogêneas, apresente um perfil de capacidades sustentadas e requisitos não resolvidos, em vez de forçar um número único. Uma política documentada pode continuar sendo um achado válido mesmo quando a aplicação em runtime não foi verificada. Da mesma forma, uma verificação bem-sucedida de um controle delimitado não comprova a completude do inventário, a usabilidade da política ou a manutenção de um processo de revisão em outros contextos.
Use a avaliação para escolher o próximo resultado
Plano hipotético de avaliação: uma equipe de operações quer avaliar um agente que mantém uma lista interna de responsáveis por escalonamento. Os funcionários podem acioná-lo por um cliente interativo; uma tarefa agendada usa outra identidade de execução e outra configuração. O patrocinador quer uma única afirmação de Nível 4 para os dois caminhos. Nenhuma lista é alterada e nenhum teste é executado neste exemplo.
As regras abaixo são condições de avaliação para essa revisão proposta, não evidências coletadas ou níveis atribuídos:
| Se a revisão conseguir estabelecer esta condição | Conclusão defensável | Próximo resultado a estabelecer |
|---|---|---|
| Apenas o uso relevante, a configuração e o limite do inventário do caminho interativo estão estabelecidos | O Nível 1 pode ser sustentado para esse escopo; os requisitos posteriores permanecem em aberto | Observações da atividade relevante que possam ser relacionadas aos registros usados na revisão de Nível 2 |
| As evidências de política definem as mudanças permitidas na lista, mas o comportamento em runtime não foi verificado | A política sustenta parte do Nível 3; não estabelece o Nível 4 nem os demais requisitos de suporte | Evidência de que a decisão aplicável afeta a operação nomeada sobre a lista no caminho controlado |
| A identidade agendada, a configuração e os registros afetados não foram examinados | Esse caminho está sem avaliação; o achado do caminho interativo não se transfere para ele | Escopo, identidade, autoridade e responsável definidos para avaliar o caminho agendado |
Isso produz itens de trabalho diferentes, em vez de um nível médio. O caminho interativo precisa de evidências para seu próximo requisito ainda não sustentado. O caminho agendado precisa primeiro de um limite de avaliação. Comprar o mesmo controle para ambos não resolveria a falta de conhecimento sobre a identidade agendada nem comprovaria que qualquer uma das instalações o aplica corretamente.
Escolha a ordem pelas consequências da operação e pela incerteza que impede uma decisão responsável. Se a tarefa agendada puder alterar registros que precisam permanecer dentro da autoridade de uma equipe, esclarecer esse escopo pode ser mais urgente do que melhorar um relatório do caminho interativo. Esse é um julgamento condicional de prioridade, não um achado de risco observado ou uma pontuação numérica.
Mantenha o nível subordinado à decisão operacional
Um nível mais alto não autoriza uma nova tarefa, recurso ou identidade de execução. Um nível mais baixo não determina, por si só, se um uso delimitado é aceitável. Os responsáveis precisam estabelecer os controles exigidos para aquele uso e decidir quais riscos ou restrições restantes podem aceitar. Um controle preventivo exigido não pode ser substituído por um rótulo favorável de maturidade.
Use o guia de implantação de agentes de código quando o próximo avanço precisar de um piloto com critérios explícitos de aceite. Mantenha a avaliação focada no resultado que esse piloto deve demonstrar, em vez de reproduzir seu checklist de implementação como uma tabela de pontuação.
Reabra o achado relevante quando as evidências expirarem, uma configuração mudar, um novo caminho for introduzido ou uma lacuna operacional comprometer a conclusão anterior. Preserve os achados que continuarem sustentados dentro de seu escopo original. O resultado útil é uma descrição atual do que está demonstrado, do que é incerto e de quem responde pelo próximo avanço verificável.