TL, DR
Todas as diretorias agora questionam sobre os riscos da IA, e a maioria das equipes de segurança responde com adjetivos em vez de números. As estruturas de governança dizem o que governar. Elas não dizem o que contabilizar. Todas essas métricas de risco de IA vêm do mesmo lugar: o código que sua organização já utiliza.
- Uma estratégia de IA agentiva possui três camadas, e apenas uma delas é o modelo. O que o agente escreve, a que o agente está conectado e o que o agente recebe. A maioria dos programas mede o primeiro e ignora os outros dois.
- O raio da explosão não está incluído no modelo. Está no arquivo de habilidades, na configuração do MCP, no escopo da ferramenta e nas credenciais sob as quais o agente é executado. Uma avaliação de modelo limpa e um agente com privilégios excessivos coexistem sem problemas.
- Nove métricas de risco de IA, cada uma delas um número em vez de um adjetivo. Ativos de IA não aprovados, caminhos de injeção rápidos que chegam a um coletor de ferramentas, segredos em
.mcp/servers.json, dependências adicionadas pelo agente sinalizadas antes da existência de uma assinatura. - Se você não conseguir atingir esse número neste trimestre, o problema não está na métrica. O inventário está pronto. Comece com três contagens, não com um programa.
O que significa, na prática, o risco da IA quando você é quem está lançando o software?
Pergunte a dez pessoas o que significa risco de IA e você receberá dez respostas diferentes. Viés do modelo. Alucinação. Vazamento de dados. Exposição a regulamentações. Substituição de empregos. Todas reais, todas merecem atenção, e nenhuma delas pode ser respondida por uma equipe de segurança em uma tarde de terça-feira.
Existe uma versão mais específica da questão que uma equipe de segurança pode de fato dominar: Que tipo de IA está presente no software que desenvolvemos, o que ela pode alcançar e o que acontece quando alguém a manipula. Essa versão tem uma resposta, e a resposta está nos seus repositórios e pipelineem vez de em um documento de política.
Este post trata da versão de risco da IA. Não porque as questões de governança não importem, mas porque elas não podem ser respondidas enquanto esta não for. Uma estrutura pede que você faça um inventário dos seus sistemas de IA. Ela não informa que esse inventário está armazenado em um... .mcp/servers.json arquivo que ninguém abriu desde que foi committed.
Por que a maioria dos programas de avaliação de risco em IA mede a coisa errada?
Existem três padrões de falha, e a maioria das organizações apresenta pelo menos dois deles.
- Medir a adoção em vez da exposição. “72% dos nossos desenvolvedores usam ferramentas de IA” é uma métrica de produtividade com um selo de segurança. Ela não diz nada sobre o que essas ferramentas podem alcançar.
- Medir o modelo em vez do sistema. A avaliação crítica de um endpoint responde à questão de se um modelo pode ser induzido a dizer algo que não deveria. Ela não responde às consequências, pois o impacto reside no escopo da ferramenta, nas credenciais sob as quais o agente é executado e nos arquivos de configuração que definem ambos. Uma avaliação de modelo limpa e um agente com privilégios excessivos coexistem sem problemas.
- Medir o que é fácil de contar. Número de políticas de IA publicadas. Número de funcionários que concluíram o treinamento em IA. Esses números aumentam de forma consistente e não apresentam correlação com nada.
O Estrutura de gerenciamento de risco NIST AI O texto deixa explícito que a mensuração é uma de suas quatro funções principais, juntamente com governar, mapear e gerenciar. A estrutura é deliberadamente orientada a resultados, em vez de prescritiva, o que é adequado para uma standard e inútil numa terça-feira. Você ainda precisa decidir o que contar.
Quais métricas de risco de IA realmente lhe dizem algo?
Nove métricas. Cada uma é um número, cada uma muda quando sua exposição muda e cada uma pode ser gerada por código em vez de por uma pesquisa.
| métrico | Por que é importante | De onde vem o número? |
|---|---|---|
| 01Total de ativos de IA descobertos e a variação desde o mês passado | Não é possível fazer um relatório sobre o risco da IA se você nunca o contabilizou. A tendência importa mais do que o número absoluto. | Descoberta contínua de modelos, estruturas, conjuntos de dados, endpoints de inferência, agentes, servidores MCP, habilidades e ferramentas de codificação de IA |
| 02Ativos de IA não aprovados como percentagem do total | Essa é a sua taxa de IA paralela. É a métrica de risco de IA mais citada por um conselho administrativo. | Acompanhamento do status de aprovação por ativo em relação à sua apólice. |
| 03Ativos de IA sem proprietário definido | Um ativo que ninguém possui é um ativo que ninguém vai consertar. Geralmente, o número mais problemático do conjunto. | A propriedade foi rastreada em relação ao ativo. |
| 04Caminhos de injeção imediatos que alcançam um coletor de ferramentas | A entrada de dados não confiáveis em um prompt do sistema só importa se houver algo perigoso do outro lado. | Detecção de risco por IA mapeada para o OWASP Top 10 para candidaturas a mestrado em Direito (LLM) |
| 05Servidores MCP em uso e quantos deles contêm resultados. | A configuração do MCP é onde o agente recebe suas ordens. É também onde as credenciais se acumulam. | A configuração do servidor MCP foi analisada como um artefato de segurança. |
| 06Segredos encontrados em arquivos de configuração de IA | Uma pesquisa realizada em 2026 encontrou mais de 24,000 segredos armazenados em arquivos de configuração do MCP no GitHub público, sendo que mais de 2,000 ainda eram válidos. | Detecção de segredos em todo o código, configurações, contêineres e pipelines |
| 07Dependências adicionadas pelo agente foram sinalizadas antes da existência de uma assinatura pública. | Os agentes extraem pacotes rapidamente, e o nome que seu modelo inventou é uma superfície de ataque explorável. | Alerta antecipado de malware, detecção de evidências seguida de validação por IA |
| 08Proporção de descobertas de IA que são alcançáveis e estão em código ativamente desenvolvido. | Separa o acúmulo de tarefas que você nunca conseguirá concluir do trabalho que realmente impacta sua visibilidade. | O funil de priorização de IA |
| 09Percentagem de textos escritos por agentes pull requests fundido com aprovação humana | A métrica de governança que um regulador solicitará, e aquela que ninguém monitora. | Pull request análise e portões de aprovação |
Se você for escolher apenas uma, escolha a métrica 02. A proporção de ativos de IA não aprovados em relação ao total é o número que sobrevive à análise da equipe de segurança e, posteriormente, à auditoria. committee, e se move quando você realmente faz alguma coisa.
O que uma estratégia de IA orientada a agentes deve abranger?
Três camadas. O erro que quase todo mundo comete é começar pela primeira e parar por aí.
- Primeira camada: o que o agente escreve. O código gerado por IA apresenta as mesmas classes de vulnerabilidade que o código humano, e pesquisas que remontam a 2022 têm consistentemente constatado que uma parcela substancial de programas gerados por IA contém falhas de segurança. Essa camada é a mais conhecida, e é exatamente por isso que concentra toda a atenção.
- Camada dois: aquilo a que o agente está conectado. Arquivos de habilidades, arquivos de regras, configurações do servidor MCP, escopos de ferramentas, as credenciais sob as quais o agente é executado. Essa é a camada que determina o alcance de um ataque bem-sucedido e é invisível para qualquer coisa que teste o modelo por meio de seu endpoint. ATLAS DE MITRA cataloga esse terreno diretamente: o estudo de caso AML.CS0041, "Rules File Backdoor", descreve caracteres de largura zero em um arquivo de regras transformando a documentação em instruções que um agente obedece silenciosamente. Um revisor que lê o pull request não vê nada.
- Camada três: o que o agente capta. Dependências, modelos, conjuntos de dados, ferramentas externas. Uma pesquisa apresentada na USENIX Security em 2025 gerou 2.23 milhões de amostras de código em 16 modelos e descobriu que 19.7% dos pacotes recomendados não existiam, produzindo mais de 205,000 nomes inventados únicos. Os atacantes não precisam mais comprometer um mantenedor. Eles registram o nome que seu agente inventou e esperam.
Uma estratégia de IA agética que abrange apenas a primeira camada produz um relatório limpo e um perfil de risco de IA inalterado. OWASP Top 10 para candidaturas a mestrado em Direito (LLM) reflete isso em sua própria estrutura: o excesso de agência está no topo da lista.cisProvavelmente porque é um problema de fiação, não um problema do modelo.
Como implementar isso sem comprometer o desempenho dos agentes?
O instinto é bloquear tudo. Isso falha porque o objetivo principal do agente é a capacidade de processamento, e um controle que reduz a capacidade pela metade é removido em menos de um quarto dela.
Três princípios de implementação que se confirmam:
- Meça continuamente, controle seletivamente. Todas as nove métricas de risco de IA podem ser coletadas em cada varredura sem bloquear nada. Reserve os bloqueios rígidos para o pequeno conjunto em que a falha é irrecuperável: uma dependência maliciosa, um segredo ativo, um modelo não aprovado que manipula dados regulamentados.
- Coloque a segurança onde o agente já está. Um agente conectado via MCP chama a plataforma de segurança enquanto gera e verifica o código recém-escrito, e itera sobre as correções até que o código atenda aos seus limites. Não há intervenção humana nessa etapa, e nada precisa ser instalado no ambiente de execução do agente. Esse é o único ponto de intervenção que escala com a capacidade de processamento do agente, em vez de ser reduzido a ela.
- Mantenha o ser humano no centro das atenções. pull request. Para tudo que chega ao código de produção, uma pessoa precisa aprovar. Isso não é cautela, é a posição de design que a Lei de IA da UE já impõe, e é muito mais barato implementar agora do que adaptar posteriormente sob pressão de auditoria. É também a métrica 09, e é por isso que vale a pena monitorá-la desde o início.
A área que geralmente fica sem atribuição na maioria das organizações é a segunda. Os arquivos de configuração ficam numa posição intermediária entre a segurança de aplicações, que os trata como infraestrutura, e a engenharia de plataforma, que os trata como documentação. É nessa lacuna que os ataques mais interessantes se infiltram.
Como começar a mensurar o risco da IA neste trimestre?
Não desenvolva o programa completo. Apresente três números. Conte seus ativos de IA. Conte quantos deles ninguém aprovou. Conte quantos segredos estão escondidos nos arquivos de configuração da IA. Esses três números cabem em um slide; são todos defensáveis e serão piores do que quem os solicitou imagina.
Em seguida, escolha o pior e corrija-o antes da próxima reunião do conselho. Isso é um programa de IA para gestão de riscos em funcionamento. Todo o resto é mera especulação.
As organizações que terão dificuldades com os riscos da IA em 2027 não serão as que agiram rapidamente. Serão as que passaram o ano de 2026 elaborando políticas de IA sem sequer quantificá-las. Uma política que ninguém consegue mensurar é apenas um documento. As métricas de risco da IA são o que a transformam em um controle.
Veja seus próprios números. Conecte um repositório e a Xygeni retorna seu inventário de IA, os ativos não aprovados, os riscos mapeados para as estruturas usadas por seus auditores e uma lista de materiais de IA (AI-BOM) que você pode exportar. Comece de graça or Agenda uma Demonstração.
Perguntas frequentes
Qual a diferença entre risco e segurança da IA?
A segurança da IA diz respeito principalmente ao funcionamento do modelo: se ele se comporta conforme o esperado, se seus resultados são prejudiciais e se ele pode ser manipulado para realizar algo que deveria rejeitar. O risco da IA, em um contexto de segurança, refere-se ao alcance que um sistema de IA comprometido ou com mau funcionamento pode atingir em seu ambiente. Os dois conceitos se sobrepõem, mas são de responsabilidade de equipes diferentes e medidos com instrumentos distintos. Uma equipe de segurança pode agir sobre o segundo aspecto hoje mesmo.
Quantas métricas de risco de IA devemos reportar ao conselho?
De três a cinco. Um conselho não pode tomar decisões com base em nove números, e uma apresentação com nove tende a ocultar o que realmente importa. Informe o número total de ativos de IA, a porcentagem de não aprovados e uma métrica de exposição, como descobertas de IA alcançáveis em desenvolvimento ativo. Guarde o restante para a revisão operacional.
Precisamos de uma lista de materiais baseada em IA se ainda não existe regulamentação que a exija?
Atualmente, não existe nenhuma regulamentação que obrigue a criação de uma lista de materiais de IA (AI-BOM), e é exatamente por isso que gerá-la é barato agora, mas caro depois. Existem dois formatos legíveis por máquina disponíveis hoje, e um auditor aceitará qualquer um deles. O valor não está na conformidade, mas sim no fato de que gerar o arquivo força a criação do inventário, e o inventário é essencial para todas as métricas de risco de IA.
Nossos desenvolvedores usam ferramentas de IA que nunca aprovamos. Por onde começamos?
Faça as contas antes de impor restrições. Anunciar uma política contra ferramentas que você não consegue visualizar leva ao uso clandestino e destrói a visibilidade necessária. Primeiro, realize uma investigação, publique os dados internamente sem atribuição e use-os para chegar a uma lista de ferramentas aprovadas que reflita o que as pessoas realmente precisam. A aplicação de medidas é muito mais eficaz quando feita após a coleta de evidências do que quando feita antes.
