por AgentPolicy (LX AI)
Pacotes de política de agente de IA e NIST AI RMF
Um pacote de política é um conjunto reutilizável de regras sobre o que um agente pode fazer: quais ferramentas ele pode chamar, quais classes de dados ele pode tocar e quando ele deve escalar para um humano. Mapear essas regras para as quatro funções do Quadro de Gestão de Risco de IA do NIST, Governar, Mapear, Medir e Gerenciar, mantém o pacote aterrado em uma estrutura que os auditores já reconhecem. O pacote é um rascunho que você aprova, não um certificado de conformidade.
Governar: propriedade e responsabilidade
Definir proprietários de regras
Eu começo cada pacote nomeando uma pessoa ou equipe responsável por cada regra. Esse proprietário assina a texto da regra, revisa trimestralmente e aprova qualquer alteração. Sem um proprietário claro, uma regra que bloqueia uma ferramenta perigosa hoje pode ser esquecida quando uma nova integração aparece, deixando o agente com acesso não intencionado.
Processo de controle de alterações
Eu trato o pacote como um arquivo controlado por versão. Cada edição cria um novo commit, inclui uma breve justificativa e passa por uma lista de verificação de revisão que aborda: (1) impacto em ferramentas permitidas, (2) efeito em tags de classe de dados, (3) caminhos de escalonamento e (4) compatibilidade com evidências de auditoria existentes. A lista de verificação vive no mesmo repositório que o pacote, para que os revisores possam ver a diferença e a discussão em um só lugar.
Link para a função Govern do NIST
O NIST AI RMF descreve Govern como a base que define papéis, responsabilidades e políticas. Meu pacote espelha isso tornando a propriedade explícita e incorporando um fluxo de trabalho de controle de alterações leve que os auditores podem inspecionar. Quando um auditor pergunta “quem é responsável por esta regra?”, eu posso apontar para o campo de proprietário e o histórico de commits.
Mapa: contexto e fluxos de dados
Inventário de ferramentas e classes de dados
Eu listo cada ferramenta externa que o agente pode chamar, em seguida, etiqueto cada ferramenta com as classes de dados que ela pode ler ou escrever. Por exemplo, uma ferramenta de resumo recebe a etiqueta "tickets de cliente" porque pode ingerir o texto do ticket, enquanto uma ferramenta de cálculo matemático recebe a etiqueta "nenhum" porque só retorna números. Esta visão em duas camadas evita o erro comum de permitir que uma ferramenta seja utilizada sem entender quais dados ela toca.
Avaliação de risco por ferramenta
Para cada par ferramenta-dados, eu atribuo uma pontuação de risco simples: baixo, médio ou alto. A pontuação vem de três perguntas: (1) A ferramenta lida com informações de identificação pessoal? (2) A ferramenta pode invocar outros serviços? (3) A ferramenta foi mencionada em bases de dados de vulnerabilidades públicas? Eu registro a pontuação no pacote para que os revisores vejam por que uma ferramenta é restrita ou permitida.
Link para a função de mapeamento da NIST
O mapeamento no AI RMF é sobre entender o contexto e o impacto potencial. Meu inventário e folha de pontuação fornecem um artefato concreto que mostra quais sistemas o agente alcança, quais dados fluem por meio dele e qual seria o custo de uma falha. Isso satisfaz o requisito de mapeamento para "identificar e categorizar riscos" antes de qualquer controle ser aplicado.
Medida: telemetria e evidências
Registo de acertos de regras
Configuro o agente para emitir uma entrada de registo estruturada cada vez que uma regra é avaliada. A entrada contém: carimbo de data e hora, ID do agente, ID da regra, nome da ferramenta, classe de dados, decisão (permitir/negar/escalar) e a pontuação de risco da etapa Map. Estes registos fluem para um armazenamento central onde posso executar consultas simples como “mostrar todas as negações para a ferramenta de resumo na última semana.”
Rastreio de escalada
Sempre que o pacote dispara uma escalada, registo o motivo e o humano que respondeu. Ao longo do tempo, calculo duas métricas: (1) taxa de escalada por ferramenta, e (2) tempo médio de resolução humana. Estes números se tornam as evidências que mostro durante uma revisão para provar que os limites não são apenas escritos, mas realmente aplicados.
Link para a função de Medida do NIST
A função de Medida exige indicadores quantitativos que mostrem se os controles estão funcionando. As minhas métricas baseadas em registos dão aos auditores uma forma repetível de ver a eficácia da regra, a frequência de escalada e a latência de resposta. Se as métricas mostram um aumento súbito de negações para uma ferramenta, sei que o pacote precisa de uma atualização da etapa Map.
Gerir: resposta e iteração
Atualizações impulsionadas por incidentes
Quando um registo de log revela uma violação de política — digamos, o agente chamou uma ferramenta proibida — abro um bilhete que faz referência à linha de log exata. O bilhete impulsiona um fluxo de trabalho curto: (1) verificar a violação, (2) decidir se apertar a definição da ferramenta, adicionar uma lista de permissões de saída ou exigir confirmação, (3) editar o pacote, (4) aumentar a versão e (5) fechar o bilhete com um link para o novo commit.
Versionamento como código
Armazeno o pacote em um repositório Git. Cada lançamento recebe uma versão semântica (por exemplo, 1.2.0). A mensagem de commit inclui a regra alterada, o motivo e o número do bilhete associado. Isso facilita mostrar a um auditor a diferença exata entre a versão revisada no mês passado e a versão em produção hoje.
Link para a função Gerir do NIST
Gerir no AI RMF é sobre responder a problemas detectados e melhorar os controles. Meu fluxo de bilhetes impulsionado por incidentes e pacote controlado por versão dá um mecanismo concreto para detectar, responder e verificar a melhoria — exatamente o que a Gerir espera.
Construir um pacote de políticas passo a passo
Comece com uma lista de permissões de ferramentas
Eu começo coletando cada API, CLI ou webhook que o agente possa precisar. Eu escrevo cada entrada em uma lista YAML simples, anotando o fornecedor, versão e propósito da ferramenta. Nesta etapa, não me preocupo com classes de dados; eu apenas quero um inventário completo.
Adicione tags de classes de dados
Em seguida, eu percorro a lista de permissões e pergunto: quais dados essa ferramenta lê ou grava? Eu adiciono uma tag como "registros financeiros", "informações de saúde" ou "web pública". Se uma ferramenta toca múltiplas classes, eu adiciono múltiplas tags. Esta etapa transforma uma lista simples em um mapa que pode ser pontuado para risco.
Defina limiares de escalonamento
Para cada par de ferramenta-dados, eu decido quando o agente deve passar para um humano. Eu uso a pontuação de risco da etapa de mapeamento: pontuações baixas obtêm permissão automática, pontuações médias obtêm permissão com registro de auditoria e pontuações altas forçam uma escalada. Eu codifico esses limiares como uma tabela de decisão no pacote.
Valide com cenários de teste
Antes de chamar o pacote de "pronto", eu executo um conjunto de interações scriptadas que tentam acionar cada regra. Eu verifico se os logs capturam a decisão esperada, se as escaladas disparam quando devem e se nenhuma regra falha silenciosamente. Se um teste mostra uma discordância, eu retorno à etapa de mapeamento ou gerenciamento para corrigir o pacote.
O que isto não é
Quero ser claro sobre os limites de um pacote de políticas. Não é uma garantia de que o agente nunca violará uma regra. Não é um escudo de 100 % contra vetores de ataque novos que eram desconhecidos quando o pacote foi escrito. Não substitui uma revisão legal formal, uma avaliação de um organismo notificado ou a sua própria aceitação de riscos. O pacote é uma ferramenta de apoio à decisão que torna as regras visíveis, testáveis e alteráveis, mas a responsabilidade final ainda reside com os humanos que possuem o sistema.
Lista de verificação do operador para pacotes de política de agente de IA através de uma lente de NIST AI RMF
Mantenho uma lista de verificação escrita ao lado de cada lançamento que toca neste tópico. A lista é propositadamente monótona: nomear o proprietário, nomear o artifact de evidência e nomear o rollback. Se um passo não puder produzir um ficheiro, um bilhete ou uma linha de registo, não é um passo — é um desejo.
Antes de alterar a produção
- Congele a branch ou a revisão de configuração que irá medir contra. - Registe o modo de falha atual com uma entrada concreta e uma saída concreta. - Confirme qual identidade o trabalho é executado como, e se essa identidade pode alcançar dados que não deve. - Abra as referências principais que irá citar: https://genai.owasp.org/llmrisk/llm01-prompt-injection, https://owasp.org/www-project-top-10-ci-cd-security-risks/CICD-SEC-06-Insufficient-Credential-Hygiene.
Enquanto executa a verificação
- Prefira um caminho reprodutível em vez de dez capturas de ecrã anedóticas. - Escreva o resultado seguro esperado antes de acionar a ferramenta ou consulta. - Capture o comando exato, prompt, esquema ou regex em teste — não uma paráfrase. - Se o sistema puder agir (enviar, escrever, apagar, transferir), exija uma fronteira de confirmação no mesmo passe.
Depois de terminar
- Arquive o risco residual com um proprietário e uma data, mesmo quando a varredura estiver limpa. - Não converta um cheque verde em linguagem de vendas que afirme a completude. - Re-execute a mesma lista de verificação quando o modelo, o esquema da ferramenta ou as regras de validação mudarem.
Sinal | O que registrar | Parar o envio? Escrita ou envio inesperado | Nome da ferramenta, args, identidade | Sim até que seja controlado Falta de confirmação em ação destrutiva | Caminho de chamada e bypass | Sim Texto não confiável tratado como instrução | Superfície de origem e ação resultante | Sim para alcance do agente Varredura limpa, julgamento aberto | Itens adiados + proprietário | Apenas se o caminho central for seguro
AgentPolicy ajuda com a primeira passagem mensurável. As escolhas de arquitetura, a assinatura legal e as afirmações voltadas para o cliente ainda precisam de um proprietário humano. Trate cada linha da lista de verificação como suporte à decisão, não como um certificado.
Como explico limites aos compradores
Quando um prospecto pergunta se o produto "cobrir tudo", respondo com a fronteira: verificações automatizadas capturam padrões conhecidos; cadeias novas e julgamento de política ainda precisam de revisão. Essa honestidade mantém a carga de suporte baixa e mantém o blog alinhado com o que o produto realmente faz.
Se precisar de uma segunda opinião, combine este texto com as referências abaixo e com a sua própria reprodução de teste. Não pule a etapa de reprodução apenas porque um modelo escreveu um resumo confiante.
Referências
- https://genai.owasp.org/llmrisk/llm01-prompt-injection - https://owasp.org/www-project-top-10-ci-cd-security-risks/CICD-SEC-06-Insufficient-Credential-Hygiene - https://cheatsheetseries.owasp.org/cheatsheets/LLM_Prompt_Injection_Prevention_Cheat_Sheet.html - https://cheatsheetseries.owasp.org/cheatsheets/SQL_Injection_Prevention_Cheat_Sheet.html
Artigos relacionados
- Ferramentas permitidas vs agentes de fim aberto - Explore a matriz completa de tópicos de micro-SaaS de IA →
Does a generated policy pack satisfy the EU AI Act?
Não. O pacote é de suporte à decisão. Onde se aplica o Regulamento (UE) 2024/1689 do Regulamento AI da UE, ainda precisa de avaliação de conformidade, documentação técnica e design de supervisão humana. O pacote o ajuda a preparar esses artefactos, não a substituí-los.
Como as funções do NIST AI RMF mapeiam um ficheiro de política?
Govern atribui propriedade, Map regista o contexto do sistema e dos dados, Measure regista quais regras foram ativadas, e Manage atualiza o pacote após um incidente. As quatro funções dão ao pacote uma estrutura que os revisores já reconhecem.
O que torna um pacote aplicável em vez de decorativo?
Telemetria. Se não puder mostrar quais regras foram ativadas e onde um agente foi negado, a política é um desejo. Associe o pacote com registo para que os seus limites sejam observáveis durante a revisão.
Quem deve ser o proprietário de um pacote de política de agente?
Um proprietário nomeado, idealmente com contribuições de engenharia e risco. O proprietário aprova alterações e é responsável quando um abuso de ferramenta escapa. Um pacote sem proprietário tende a se deteriorar à medida que novas integrações chegam.
Apoio à decisão apenas. Não é aconselhamento jurídico ou certificado de conformidade.