IA em GRC: citar não é verificar

Um agente de IA lê uma política de segurança, encontra um parágrafo relevante e assinala um requisito como cumprido. A sua explicação parece plausível e inclui uma ligação para a fonte. Mas que alteração ao requisito ou às evidências mudaria esse veredicto?

A investigação recente sobre governação, risco e conformidade (GRC) torna essa pergunta inevitável. Um modelo pode dar a resposta certa pela razão errada, citar uma fonte genuína associada ao sistema errado ou confundir uma política escrita com um controlo eficaz. Na Secani, encaramos isto como um desafio de desenho de produto: a ligação entre requisito, observação e decisão tem de estar aberta a inspeção.

Teste se o veredicto depende da regra

O preprint Verdict Without the Rule mantém um caso fixo enquanto elimina, substitui ou nega a regra aplicável. Em cinco modelos executados localmente e 20 domínios, a eliminação da regra alterou o veredicto em apenas 5,3 % dos casos, em média. Um veredicto inalterado não está automaticamente errado: regras diferentes podem conduzir ao mesmo resultado. Mas uma resposta correta, por si só, não consegue estabelecer que o sistema utilizou a regra fornecida.

Isso exige pares de casos revistos, e não apenas benchmarks de resposta única. Se um requisito de revisão de acessos passar de trimestral para mensal enquanto os registos disponíveis se mantêm iguais, a avaliação pode ter de mudar. Reformular o mesmo requisito sem alterar o seu significado deve deixar a avaliação estável. Ambas as reações importam.

Separe a cobertura das políticas da prova operacional

O PACE separa a recuperação de passagens relevantes de políticas da avaliação sobre se estas cobrem um requisito de segurança total, parcialmente ou de todo. Os resultados apresentados dizem respeito à cobertura da documentação, e não a saber se as medidas descritas funcionam na prática. Uma política pode exigir autenticação multifator para os acessos privilegiados sem provar que contas estão tecnicamente protegidas ou que exceções existem.

O ReCon documenta uma falha ainda mais simples: em alguns exemplos, os modelos tratam o texto do requisito incluído no prompt como se fosse uma evidência da empresa. Os requisitos e os registos da empresa precisam, por isso, de identidades distintas no modelo de dados. Uma citação deve apontar para a passagem que efetivamente sustenta a afirmação.

Esta distinção torna as constatações acionáveis. “A política existe, mas faltam evidências técnicas para três contas privilegiadas” diz a um consultor o que investigar. “Parcialmente conforme” não diz.

Verifique a relação, e não apenas a fonte

O pipeline descrito em From Legacy Documentation to OSCAL extrai ativos de descrições de sistemas e utiliza informação estruturada sobre ameaças para produzir artefactos de conformidade. A sua análise de erros mostra por que razão uma fonte real pode, ainda assim, sustentar a conclusão errada: se um ativo for extraído incorretamente, consultas posteriores podem devolver vulnerabilidades genuínas de outro produto.

A revisão humana é mais valiosa nessas ligações de elevado impacto: uma versão de produto, uma fronteira de sistema, um local ou uma atribuição de controlo de que dependem muitas constatações posteriores. Uma sugestão extraída deve continuar a ser distinguível de um elemento de inventário confirmado. Quando uma ligação fundamental é corrigida, as avaliações dela derivadas têm de ser rastreáveis.

Dê às evidências um âmbito e uma janela temporal

O artigo Compliance-as-Code for AI-Driven Identity Systems propõe “contratos de evidências” que especificam os tipos de evidências exigidos, os mapeamentos, os campos, as versões e os períodos de observação. O seu protótipo utiliza fluxos de identidade sintéticos, pelo que o estudo é um exemplo de arquitetura e não uma validação ampla em contexto empresarial.

Um relatório de teste de março não prova automaticamente que um controlo continua a funcionar após uma alteração ao sistema em setembro. Uma exportação de configuração de uma filial não estabelece o estado de outra. As evidências precisam de um sujeito, de uma origem, de um período e de uma afirmação que sustentam. Se uma integração deixar de fornecer dados atuais, o estado presente é não comprovado; isso é diferente de uma falha de controlo demonstrada.

Torne repetíveis as verificações acordadas

O artigo Ontological Knowledge Blocks descreve uma representação intermédia estruturada de obrigações definidas por especialistas, compilada em regras de validação executáveis. A interpretação normativa continua a ser uma responsabilidade humana. Um preprint separado sobre avaliação de riscos mapeia artefactos técnicos observáveis para resultados ordinais através de regras versionadas e verifica formalmente algumas propriedades de consistência. Nenhum dos estudos estabelece um motor de conformidade universal nem probabilidades de incidentes calibradas empiricamente.

O princípio útil é distinguir a interpretação da execução repetível. Um agente pode sugerir critérios a partir de uma política. Depois de os especialistas os aprovarem, verificações como um campo em falta, um período de observação expirado ou um limiar ultrapassado não devem precisar de uma nova interpretação pelo modelo em cada execução. Um veredicto deve registar a versão do requisito, as versões das evidências e a lógica aplicada.

Reabra as decisões quando as suas premissas mudarem

A conformidade contínua não é uma exigência para reabrir todos os controlos após cada edição de um documento. Exige saber que conclusões dependem da informação que mudou. Um título corrigido pode não ter qualquer efeito. Uma nova exceção para acessos privilegiados pode afetar vários referenciais.

A decisão histórica deve permanecer intacta: pode ter sido justificada na altura. Mas não deve continuar indefinidamente como afirmação atual depois de as suas premissas terem mudado. Relações explícitas e versionadas permitem aos consultores concentrar-se nas avaliações que precisam realmente de ser revistas.

Estes artigos não provam que a GRC possa ser totalmente autónoma. Vários são preprints ou avaliações de protótipos restritos. Apontam, no entanto, para um padrão útil para a Secani: os agentes devem preparar informação, propor mapeamentos, explicar lacunas e ajudar os consultores a chegar mais depressa a decisões defensáveis.

Um estado verde é um resultado. A ligação rastreável entre requisito, realidade e decisão é o produto.