A segurança da IA agêntica deixou de ser um tema de laboratório no dia em que os agentes passaram a planear, a guardar memória, a chamar ferramentas e a agir com autoridade delegada. Quase todos os guias sobre o assunto são escritos por fornecedores de segurança e param na ameaça. A lista de referência, o OWASP Top 10 for Agentic Applications, tem 57 páginas e não nomeia um único regulamento. Este guia lê os mesmos dez riscos como os leria um auditor ou uma autoridade de fiscalização do mercado: que dever cada um toca, que registo prova que foi tratado e que prazos já estão a contar.
O essencial
- Um agente não distingue de forma fiável instruções de conteúdo: controla-se o que pode fazer, não o que lhe dizem.
- O Top 10 da OWASP para aplicações agênticas (9 de dezembro de 2025) lista dez riscos, ASI01 a ASI10, e 86 mitigações numeradas, pela nossa contagem.
- As suas 57 páginas nunca referem o Regulamento da IA nem a ISO/IEC 42001: a leitura jurídica é sua.
- Para a Comissão, os agentes são sistemas de IA, não uma categoria à parte; o projeto de orientações sobre risco elevado (19 de maio de 2026) avalia o sistema agêntico como um todo.
- Comunicação do Regulamento de Ciber-Resiliência desde 11 de setembro de 2026, transparência do artigo 50.º desde 2 de agosto de 2026, risco elevado do anexo III a 2 de dezembro de 2027.
O que é a segurança da IA agêntica?
A segurança da IA agêntica é a disciplina que consiste em manter os sistemas que planeiam, memorizam, chamam ferramentas e agem com autoridade delegada dentro do âmbito que o seu responsável pretendia, e em conseguir prová-lo. A OWASP usa quatro capacidades como tela para desenhar as ameaças: planeamento e raciocínio, memória, uso de ferramentas e ação. É aqui que a segurança da IA agêntica se separa da segurança da IA em geral e da segurança das aplicações assentes em modelos de linguagem. Nestas, o modelo é um componente que devolve texto. Num agente, o modelo é um ator: decide o passo seguinte, escolhe a ferramenta e executa. Com os agentes de IA autónomos, e é essa a diferença entre IA agêntica e IA generativa, o risco passa do que o sistema diz para o que o sistema faz.
Porque é que os agentes quebram os pressupostos da segurança aplicacional
Os agentes desfazem três pressupostos da segurança aplicacional.
- Código e dados deixam de ser separáveis. Segundo a OWASP, os agentes e o modelo subjacente não conseguem distinguir de forma fiável as instruções do conteúdo relacionado.
- A identidade que age não é a identidade que pediu. O agente trabalha com credenciais herdadas ao longo de cadeias de delegação.
- Uma única falha persiste e propaga-se. O que entra na memória volta nas sessões seguintes e passa a outros agentes.
Da carta dos responsáveis do projeto OWASP saem dois princípios. O primeiro é o Least Agency (agência mínima): evitar autonomia desnecessária, porque colocar comportamento agêntico onde não faz falta alarga a superfície de ataque sem acrescentar valor. O segundo é a observabilidade, que a OWASP considera inegociável: ver o que os agentes fazem, porquê, e que ferramentas invocam. Para uma triagem rápida, basta o teste da “tríade letal” de Simon Willison: dados privados, conteúdo não confiável e comunicação com o exterior, reunidos no mesmo agente.
A lista de referência da segurança da IA agêntica: OWASP Top 10 for Agentic Applications
O documento foi publicado a 9 de dezembro de 2025 pelo OWASP GenAI Security Project (Agentic Security Initiative): 57 páginas, licença CC BY-SA 4.0, mais de 100 contribuidores. Cada entrada traz descrição, exemplos comuns, cenários de ataque e orientações de prevenção e mitigação. Pela nossa contagem, são 86 mitigações numeradas (entre 7 e 10 por entrada) e 61 cenários de ataque. <table header-row=”true”> <tr> <td>ID</td> <td>Entrada</td> <td>O que corre mal</td> <td>Primeiro controlo da OWASP</td> </tr> <tr> <td>ASI01</td> <td>Agent Goal Hijack (sequestro do objetivo)</td> <td>Um atacante redireciona os objetivos do agente com prompts, resultados de ferramentas, documentos ou mensagens forjadas</td> <td>Tratar toda a entrada em linguagem natural como não confiável; aprovação humana para alterar o objetivo</td> </tr> <tr> <td>ASI02</td> <td>Tool Misuse and Exploitation (uso indevido de ferramentas)</td> <td>O agente usa uma ferramenta legítima de forma insegura: exfiltração, ação destrutiva, chamadas encadeadas</td> <td>Agência e privilégio mínimos por ferramenta: âmbitos, limites de frequência, destinos de saída permitidos</td> </tr> <tr> <td>ASI03</td> <td>Identity and Privilege Abuse (abuso de identidade e privilégios)</td> <td>Cadeias de delegação e credenciais herdadas ou em cache levam o agente além do que o requerente poderia</td> <td>Permissões limitadas à tarefa e ao tempo; autorização ação a ação</td> </tr> <tr> <td>ASI04</td> <td>Agentic Supply Chain Vulnerabilities (vulnerabilidades da cadeia de abastecimento)</td> <td>Ferramenta, plug-in, servidor MCP, modelo, prompt ou agente de terceiros malicioso ou adulterado</td> <td>Proveniência, SBOM e AIBOM, manifestos assinados, lista de permitidos e versões fixadas</td> </tr> <tr> <td>ASI05</td> <td>Unexpected Code Execution (RCE) (execução inesperada de código)</td> <td>Código gerado ou uma entrada de ferramenta transforma-se em execução de comandos numa máquina</td> <td>Execução em ambiente isolado, nenhum caminho direto para produção, aprovação para execuções privilegiadas</td> </tr> <tr> <td>ASI06</td> <td>Memory and Context Poisoning (envenenamento da memória)</td> <td>O contexto armazenado (resumos, embeddings, repositórios RAG) recebe conteúdo falso que persiste entre sessões</td> <td>Validar as escritas em memória, segmentá-la, proveniência, cópias instantâneas e reposição</td> </tr> <tr> <td>ASI07</td> <td>Insecure Inter-Agent Communication (comunicação insegura entre agentes)</td> <td>As mensagens entre agentes são falsificadas, repetidas ou alteradas</td> <td>Autenticação mútua, mensagens assinadas, versão do protocolo fixada, registos de agentes atestados</td> </tr> <tr> <td>ASI08</td> <td>Cascading Failures (falhas em cascata)</td> <td>Uma falha propaga-se por agentes e ferramentas a todo o sistema</td> <td>Isolamento e fronteiras de confiança, disjuntores, aplicação independente das políticas, registos invioláveis</td> </tr> <tr> <td>ASI09</td> <td>Human-Agent Trust Exploitation (exploração da confiança humana)</td> <td>As pessoas confiam em excesso num agente fluente e aprovam ações prejudiciais</td> <td>Confirmações explícitas, pré-visualização separada do efeito, resumos do risco em linguagem simples</td> </tr> <tr> <td>ASI10</td> <td>Rogue Agents (agentes fora de controlo)</td> <td>Um agente comprometido ou desalinhado sai do seu âmbito enquanto cada ação parece legítima</td> <td>Registos de auditoria assinados, monitorização comportamental, interruptor de emergência e revogação de credenciais, quarentena e reintegração</td> </tr> </table> Duas observações da nossa leitura. O registo ou a monitorização surge como mitigação numerada em nove das dez entradas, e a aprovação humana em sete: lida na transversal, a lista é uma especificação de registos e de regras de aprovação. E os identificadores estão mapeados para o LLM Top 10 (apêndice A), para o Top 10 de identidades não humanas (apêndice C) e para CycloneDX e AIBOM (apêndice B, útil na due diligence a fornecedores de IA), mas para nenhuma lei.
O que mostra o registo de incidentes
O Top 10 traz um rastreador de exploits e incidentes (apêndice D): cerca de duas dezenas de incidentes públicos, de fevereiro a outubro de 2025, classificados sobretudo como Tool Misuse, Agent Goal Hijack e Unexpected Code Execution:
- Fevereiro de 2025: injeção de prompt no ChatGPT Operator através de conteúdo web.
- Abril de 2025: ataque de agente intermediário com um cartão de agente falso num diretório A2A aberto.
- Julho de 2025: agentes do Copilot Studio públicos por omissão e sem autenticação.
- Setembro de 2025: ForcedLeak no Salesforce Agentforce, por injeção indireta de prompt, e o primeiro servidor MCP malicioso encontrado em circulação, no npm, a fazer-se passar pelo postmark-mcp.
Segundo a Help Net Security, que a 11 de junho de 2026 resumiu o relatório State of Agentic AI Security and Governance da OWASP (versão 2.01, 1 de junho de 2026), a edição de 2025 catalogava ameaças plausíveis; a de 2026 cataloga CVE, avisos de fornecedores e relatos de violações. São acompanhados 53 projetos agênticos, 28 deles agentes de programação. Os que somam mais avisos: n8n (57), Claude Code (22), AutoGPT (15), Dify (13) e Roo-Code (11). Em março de 2026, um pacote LiteLLM com porta traseira no PyPI registou cerca de 47 000 descarregamentos numa janela de três horas; é um gateway usado por várias frameworks de agentes. Para a segurança da IA agêntica ficam duas lições. A porta de entrada é quase sempre banal: um pacote, uma página web, um pedido de suporte, uma configuração por omissão. E o dano é decidido por aquilo que o agente estava autorizado a fazer. Por isso, o red teaming de IA deve medir o alcance das permissões, e o MITRE ATLAS ajuda a descrever o que foi testado.
O que as orientações de segurança da IA agêntica deixam de fora: a lei
O PDF do Top 10 não menciona o Regulamento da IA, a ISO/IEC 42001 nem qualquer outro regulamento: verificámo-lo por pesquisa em texto integral. Não é um defeito num documento de segurança. É uma lacuna para quem responde perante uma autoridade. O GenAI Security Industry Framework Crosswalk da OWASP, divulgado a 1 de setembro de 2026, mapeia agora os riscos de IA generativa para 25 referenciais, incluindo o Regulamento da IA. É um índice útil e um mapeamento comunitário, não uma leitura jurídica. E a Comissão? Os agentes não são uma categoria separada: as definições de sistema de IA (artigo 3.º, ponto 1) e de modelo de IA de finalidade geral (artigo 3.º, ponto 63) abrangem-nos. O projeto de orientações sobre a classificação de risco elevado foi publicado a 19 de maio de 2026 para consulta. Segundo comentários de escritórios de advogados, um sistema composto por vários componentes que interagem, sistemas agênticos incluídos, é avaliado como um todo, e a derrogação do artigo 6.º, n.º 3, não pode ser invocada módulo a módulo. A versão final está pendente. A tabela seguinte é a nossa leitura, não um mapeamento da OWASP nem da Comissão. <table header-row=”true”> <tr> <td>Entrada</td> <td>Ponto de apoio no Regulamento da IA</td> <td>Evidência que um auditor pede</td> </tr> <tr> <td>ASI01</td> <td>Art. 15.º, n.º 5 (tentativas de alterar utilização, resultados ou desempenho); art. 9.º</td> <td>Inventário dos canais de entrada não confiáveis; prompt de sistema versionado; relatório do teste de substituição do objetivo</td> </tr> <tr> <td>ASI02</td> <td>Art. 14.º; art. 26.º, n.º 1 (utilização conforme as instruções)</td> <td>Registo de ferramentas com âmbitos e limites de frequência e de saída; regra de aprovação para ações destrutivas; registo imutável das chamadas</td> </tr> <tr> <td>ASI03</td> <td>Art. 15.º, n.º 5; RGPD, art. 32.º</td> <td>Uma identidade por agente; credenciais de curta duração e âmbito limitado; revisão das cadeias de delegação</td> </tr> <tr> <td>ASI04</td> <td>Art. 25.º (responsabilidades na cadeia de valor); Regulamento de Ciber-Resiliência, anexo I</td> <td>AIBOM ou SBOM; ferramentas e servidores MCP assinados e com versão fixada; avaliações de fornecedores</td> </tr> <tr> <td>ASI05</td> <td>Art. 15.º, n.os 4 e 5; Regulamento de Ciber-Resiliência, anexo I</td> <td>Configuração do ambiente isolado; lista de execução automática versionada; registos das análises</td> </tr> <tr> <td>ASI06</td> <td>Art. 10.º (governação de dados); art. 15.º, n.º 5 (envenenamento de dados)</td> <td>Regra de validação das escritas em memória; registos de proveniência; teste de reposição; regra de conservação</td> </tr> <tr> <td>ASI07</td> <td>Art. 15.º, n.º 5; art. 12.º</td> <td>Configuração da autenticação mútua; mensagens assinadas; registo de agentes; política de versões do protocolo</td> </tr> <tr> <td>ASI08</td> <td>Art. 15.º, n.º 4 (resiliência a erros e falhas); art. 72.º (acompanhamento pós-comercialização)</td> <td>Limites do raio de impacto; resultados dos testes de disjuntores; registos dos testes de repetição</td> </tr> <tr> <td>ASI09</td> <td>Art. 14.º, n.º 4, alínea b) (enviesamento da automatização); art. 50.º, n.º 1</td> <td>Desenho das confirmações para ações de risco; canal de reporte para utilizadores; registos da formação em supervisão</td> </tr> <tr> <td>ASI10</td> <td>Art. 14.º, n.º 4, alínea e) (paragem); art. 72.º; art. 73.º</td> <td>Simulacro do interruptor de emergência e da revogação; linha de base comportamental; procedimento de quarentena e reintegração</td> </tr> </table> Na ISO/IEC 42001, as áreas de controlo do anexo A cobrem o terreno: ciclo de vida do sistema de IA (operação e monitorização, registos de eventos), relações com terceiros e com clientes, utilização de sistemas de IA e responsabilidades. Um auditor de certificação pergunta como foram identificados os riscos dos agentes e o que foi decidido para cada um.
Que lei torna exigível a evidência de segurança da IA agêntica
Nenhuma lei europeia tem um capítulo sobre segurança da IA agêntica. Várias permitem a uma autoridade pedir os registos acima.
- Regulamento da IA, artigos 9.º, 12.º, 14.º e 15.º. Sistemas de risco elevado: gestão de riscos, registo automático de eventos, supervisão humana, incluindo a capacidade de interromper o sistema com um botão de paragem ou procedimento semelhante (artigo 14.º, n.º 4, alínea e)), e resiliência contra tentativas de terceiros não autorizados de alterar a utilização, os resultados ou o desempenho (artigo 15.º, n.º 5). Anexo III a partir de 2 de dezembro de 2027, anexo I a partir de 2 de agosto de 2028, após o Omnibus Digital, Regulamento (UE) 2026/1744.
- Regulamento da IA, artigo 26.º. Os responsáveis pela implantação utilizam o sistema de acordo com as instruções, confiam a supervisão a pessoas competentes, monitorizam o funcionamento e conservam os registos gerados automaticamente durante pelo menos seis meses.
- Regulamento da IA, artigo 50.º. Desde 2 de agosto de 2026, um agente que interaja diretamente com pessoas tem de deixar claro que estas lidam com um sistema de IA.
- Regulamento da IA, artigo 55.º. Modelos de finalidade geral com risco sistémico: testagem adversarial e proteção de cibersegurança, desde 2 de agosto de 2025.
- Regulamento de Ciber-Resiliência, Regulamento (UE) 2024/2847. Produtos com elementos digitais, o que abrange a maior parte do software comercial que traz um agente. Desde 11 de setembro de 2026, os fabricantes comunicam vulnerabilidades ativamente exploradas e incidentes graves: alerta precoce em 24 horas, notificação em 72 horas. Requisitos essenciais completos a partir de 11 de dezembro de 2027.
- RGPD, artigo 32.º. Segurança do tratamento sempre que o agente toque em dados pessoais.
- NIS 2 e DORA. Entidades essenciais e importantes, entidades financeiras: gestão do risco das TIC e notificação de incidentes já devidas; o DORA aplica-se desde 17 de janeiro de 2025.
Somam-se os prazos do artigo 73.º do Regulamento da IA para incidentes graves em sistemas de risco elevado: 15 dias, 2 dias em caso de infração generalizada ou de perturbação de uma infraestrutura crítica, 10 dias em caso de morte. Um incidente com um agente pode pôr três relógios a contar ao mesmo tempo (Regulamento de Ciber-Resiliência, RGPD, Regulamento da IA). Tenha o procedimento de comunicação de incidentes de IA escrito de antemão. Em Portugal, a ANACOM foi designada em setembro de 2025 autoridade de fiscalização do mercado e ponto de contacto único para o Regulamento da IA, e o CNCS (Centro Nacional de Cibersegurança) é a autoridade nacional de cibersegurança.
Da segurança da IA agêntica à evidência: um método em sete passos
Sete decisões escritas, cada uma com um responsável.
- Inventarie cada agente. Responsável, finalidade, modelo, ferramentas e respetivos âmbitos, repositórios de memória, identidades e credenciais, outros agentes com que comunica, sistemas que pode alterar. O lugar natural é o inventário de sistemas de IA, num registo de IA estruturado.
- Aplique o Least Agency. Para cada agente, registe porque a autonomia é necessária e o que pode fazer sem aprovação, e retire as ferramentas de que não precisa. Uma recusa registada é evidência.
- Dê a cada agente a sua própria identidade. Sem contas de serviço partilhadas; credenciais de curta duração, limitadas à tarefa; permissões vinculadas ao sujeito, ao recurso, à finalidade e à duração.
- Escreva a regra de aprovação. Que ações (apagar, pagar, publicar, conceder acessos, alterar um objetivo) exigem uma pessoa, quem, e como é apresentado o pedido para que a aprovação não seja um reflexo. A supervisão humana só conta se quem aprova perceber o que aprova.
- Registe o que uma autoridade vai pedir. Objetivo, plano, cada chamada a ferramentas com parâmetros, cada aprovação, cada mensagem entre agentes: registos invioláveis, com carimbo temporal, conservados pelo menos seis meses quando o Regulamento da IA se aplica.
- Teste antes de lançar e depois de cada alteração. Uma nova ferramenta, versão do modelo, prompt ou fonte de memória reabre ASI01, ASI02 e ASI06. Inclua no red teaming um simulacro do interruptor de emergência e da revogação de credenciais.
- Ponha a cadeia de abastecimento e os prazos no papel. AIBOM ou SBOM, ferramentas e servidores MCP assinados e com versão fixada, cláusulas com fornecedores (ver a due diligence a fornecedores) e o nome de quem notifica em 24 ou 72 horas.
Cada passo deixa um registo. Juntos, formam uma declaração de aplicabilidade para a segurança da IA agêntica: dez entradas e, para cada uma, uma decisão, um controlo, um responsável e o resultado de um teste.
Papéis: quem responde pela segurança da IA agêntica na cadeia de valor
Um agente raramente é obra de uma só parte: prestador do modelo, framework, editores de ferramentas e servidores MCP, integrador, organização que o implanta. Segundo o artigo 25.º do Regulamento da IA, quem coloca o seu nome num sistema de risco elevado, o modifica substancialmente ou altera a sua finalidade prevista passa a ser prestador. Montar um agente a partir de um modelo de finalidade geral e de ferramentas pode fazer do integrador o prestador de um sistema de IA. O artigo AI Agents Under EU Law (arXiv, 2026) propõe uma arquitetura de conformidade em doze passos. Conclui que a tarefa fundadora do prestador é um inventário exaustivo das ações externas do agente, dos fluxos de dados, dos sistemas ligados e das pessoas afetadas, e que os sistemas agênticos de risco elevado com deriva comportamental não rastreável não conseguem, por agora, cumprir os requisitos essenciais. O relatório Ahead of the Curve, da The Future Society (junho de 2025), chama a isto o “problema das muitas mãos” e reparte os deveres entre prestadores de modelos, prestadores de sistemas e responsáveis pela implantação. Para a segurança da IA agêntica, isto dá três frentes:
- Cláusulas contratuais: notificação de alterações, aviso de vulnerabilidades, acesso aos registos.
- Uma matriz RACI interna entre a segurança, a função de governação da IA e o responsável de negócio, para que a responsabilidade pela IA não fique entre equipas.
- A monitorização da deriva como controlo de conformidade: num agente, a deriva do modelo é um comportamento que se afasta do que foi avaliado.
Normas em movimento: o que acompanhar até chegarem as normas harmonizadas
O NIST lançou a 17 de fevereiro de 2026 a AI Agent Standards Initiative, através do Center for AI Standards and Innovation (CAISI), com três pilares: normas lideradas pela indústria, protocolos de código aberto e investigação sobre segurança e identidade dos agentes. O pedido de informação sobre a proteção de sistemas de agentes fechou a 9 de março de 2026; o documento de conceito do NCCoE sobre identidade e autorização esteve aberto até 2 de abril de 2026. Segundo notas da Cloud Security Alliance, estão em preparação perfis de controlos da SP 800-53 para implantações com um e com vários agentes, sem data de publicação. A OWASP publicou o Securing Agentic Applications Guide 1.0 e recebeu em setembro de 2026 a doação do Agent Control Standard, orientado para a aplicação de políticas em tempo de execução. O CLTC de Berkeley publicou em fevereiro de 2026 a versão 1.0 do Agentic AI Risk-Management Standards Profile, que estende o NIST AI RMF com uma governação que cresce com o grau de agência, em vez de tratar a autonomia como binária. Na União Europeia, as normas harmonizadas do Regulamento da IA continuavam em preparação no CEN-CENELEC em 2026. Enquanto nenhuma for citada no Jornal Oficial, a estrutura mais defensável para a segurança da IA agêntica é uma taxonomia pública reconhecida acompanhada dos seus próprios registos. Ver também o perfil NIST AI 600-1 e a ISO/IEC 42001.
Perguntas frequentes
O que é a segurança da IA agêntica, em termos simples? É o conjunto de práticas que mantém um agente de IA dentro do que o seu responsável quis que ele fizesse, e que permite prová-lo. Um agente planeia, guarda memória, usa ferramentas e executa ações com permissões delegadas. A disciplina responde a quatro perguntas: que ferramentas tem, com que identidade age, que ações exigem uma pessoa e que registos ficam. Em que difere a segurança da IA agêntica da segurança da IA ou dos LLM? Numa aplicação com modelo de linguagem, o modelo produz texto, e o risco está no que entra e sai. Num agente, o modelo decide e atua: chama ferramentas, escreve em memória, fala com outros agentes. Surgem riscos novos, como o abuso de identidade em cadeias de delegação, o envenenamento persistente da memória ou as falhas em cascata. A segurança da IA agêntica controla o que o agente pode fazer. O OWASP Top 10 para aplicações agênticas é obrigatório? Não. É um documento comunitário, sob licença aberta, sem força legal. O que pode ser exigido é a evidência, quando uma lei se aplica: registos de eventos e supervisão humana para sistemas de risco elevado, comunicação de vulnerabilidades no Regulamento de Ciber-Resiliência, segurança do tratamento no RGPD. O Top 10 dá uma estrutura pública e reconhecida para organizar a evidência de segurança da IA agêntica. O Regulamento da IA abrange os agentes de IA? Sim, enquanto sistemas de IA. A Comissão não criou uma categoria própria: as definições existentes cobrem-nos. O risco elevado depende da utilização, não da tecnologia. O artigo 50.º obriga, desde 2 de agosto de 2026, a informar as pessoas de que interagem com um sistema de IA. O projeto de orientações de 19 de maio de 2026, segundo os comentários publicados, avalia um sistema agêntico como um todo; a versão final está pendente. O que significa Least Agency na segurança da IA agêntica? Significa que a autonomia tem de ser justificada, caso a caso. Na prática, são três gestos: retirar as ferramentas que o agente não usa, limitar o âmbito das que ficam (destinos, frequência, só leitura) e definir as ações que exigem sempre uma pessoa. Cada decisão fica registada, incluindo as recusas. Para a OWASP, autonomia desnecessária alarga a superfície de ataque sem acrescentar valor. Qual é a primeira coisa a fazer pela segurança da IA agêntica? O inventário. Liste todos os agentes em uso, incluindo os que as equipas montaram por iniciativa própria, e registe para cada um o responsável, as ferramentas, as credenciais e os sistemas que pode alterar. Depois, retire as ferramentas de que o agente não precisa e dê-lhe uma identidade própria, em vez de uma conta de serviço partilhada. O resto constrói-se sobre essa lista.
Conclusão
A comunidade de segurança fez a sua parte: dez riscos, 86 mitigações e um registo de incidentes que cresce todas as semanas. Não diz que lei se aplica, quando, nem o que uma autoridade pede para ver. Essa parte da segurança da IA agêntica é sua: o inventário, a decisão de Least Agency, a identidade, a regra de aprovação, os registos, os testes e os prazos. A comunicação do Regulamento de Ciber-Resiliência já está em vigor, e dezembro de 2027 traz os deveres de risco elevado e os requisitos completos de produto. O AI Sigil regista cada agente no registo de IA como um registo de primeira classe, com as suas ferramentas, riscos, controlos, responsáveis e evidências, para que a resposta a um auditor seja um relatório e não uma reconstituição.