Escolher um framework de segurança de IA antes de uma auditoria ao abrigo do AI Act ou da ISO/IEC 42001 tornou-se um exercício de triagem: há mais de quinze referenciais no mercado e cada fornecedor apresenta o seu. Comparamo-los em quatro famílias que respondem a quatro perguntas diferentes e terminamos com uma regra de seleção por papel do operador e a lista das provas que um auditor aceita.
O essencial
- «Que framework?» é a pergunta errada: a lei diz o que provar, os catálogos o que testar, os controlos o que evidenciar, os modelos de responsabilidade quem detém o quê.
- Qualquer framework de segurança de IA deve ser mapeado contra as seis classes de ataque do artigo 15.º do AI Act.
- Outubro de 2026 mudou a resposta: ISO/IEC 27090 publicada, EN 18286 citada no Jornal Oficial, inquérito da prEN 18282 concluído.
- Na indústria, só a CSA AICM e o DASF mapeiam controlo a controlo o AI Act e a ISO/IEC 42001.
- Um produto com elementos digitais pode cumprir a cibersegurança do artigo 15.º pela via do Regulamento de Ciber-Resiliência (CRA).
O que é um framework de segurança de IA (e o que não é)
Chamamos framework de segurança de IA a um conjunto nomeado e versionado de ameaças, controlos ou responsabilidades para proteger um sistema de IA (dados, modelo, pipeline, aplicação, agentes), contra o qual um terceiro pode verificar o trabalho feito. Há quatro famílias, cada uma com a sua pergunta:
- <b>O que provar:</b> a lei (artigos 15.º e 55.º do AI Act, Regulamento de Ciber-Resiliência ou CRA).
- <b>O que testar:</b> os catálogos de ameaças (MITRE ATLAS, OWASP, NIST AI 100-2).
- <b>O que evidenciar:</b> os conjuntos de controlos (CSA AICM, DASF, ISO/IEC 42001, ISO/IEC 27090, overlays do NIST, ETSI EN 304 223, ENISA).
- <b>Quem detém o quê:</b> a orientação de arquitetura e responsabilidade (SAIF, CoSAI, AWS, Microsoft).
A nossa leitura: um referencial por família, mapeado uma única vez. Comparar o SAIF com o artigo 15.º é comparar uma planta com um caderno de encargos.
Um framework de segurança de IA não é um produto de AI security posture management (AI-SPM), que é uma categoria de ferramenta. Também não é um framework de safety: em português, «segurança» cobre as duas palavras inglesas, e embora a Cisco tenha defendido, a 16 de dezembro de 2025, que security e safety são inseparáveis, o AI Act trata-as em artigos distintos. Nem é o quadro de governação de IA, do qual é uma peça, nem toda a disciplina da segurança da IA.
O mapa de 2026: os frameworks numa tabela
Dezoito referenciais que surgem quando se procura um framework de segurança de IA, nas versões de outubro de 2026.
| Framework | Entidade | Família | Última versão (data) | Dimensão | Correspondência com lei ou norma |
|---|---|---|---|---|---|
| AI Act, artigo 15.º | União Europeia | Lei | Regulamento (UE) 2024/1689; anexo III a 2 de dezembro de 2027, anexo I a 2 de agosto de 2028 | um artigo, seis classes de ataque nomeadas | é a lei |
| Regulamento de Ciber-Resiliência (CRA) | União Europeia | Lei | Regulamento (UE) 2024/2847; notificação desde 11 de setembro de 2026, aplicação plena a 11 de dezembro de 2027 | requisitos essenciais do anexo I | artigo 12.º, n.º 1: dá por cumprida a cibersegurança do artigo 15.º |
| prEN 18282 | CEN-CENELEC JTC 21 | Norma harmonizada (projeto) | inquérito público de 15 de maio a 14 de julho de 2026 | não público | redigida para o artigo 15.º |
| ISO/IEC 27090:2026 | ISO/IEC JTC 1/SC 27 | Orientação | publicada em outubro de 2026, 56 páginas | orientação, não certificável | prova em auditorias ISO/IEC 27001 e 42001 |
| ISO/IEC 42001:2023, anexo A | ISO/IEC JTC 1/SC 42 | Sistema de gestão certificável | dezembro de 2023 | controlos do anexo A (A.6.2, A.7, A.8.4, A.10.3) | certificado |
| NIST AI RMF 1.0 e NIST AI 600-1 | NIST | Framework de risco | janeiro de 2023, julho de 2024 | quatro funções, característica «secure and resilient» | voluntário; mapeado pela AICM e pelo DASF |
| NIST Cyber AI Profile (NIST IR 8596) | NIST e MITRE | Perfil comunitário do CSF 2.0 | projeto preliminar inicial, 16 de dezembro de 2025; sem projeto público | três áreas de foco (Secure, Defend, Thwart) | CSF 2.0 e AI RMF |
| NIST SP 800-53 Control Overlays for Securing AI Systems | NIST | Overlay de controlos | documento de conceito, 14 de agosto de 2025; sem overlay em projeto | cinco overlays | SP 800-53 Rev. 5 |
| NIST AI 100-2 E2025 | NIST | Taxonomia de ameaças | 24 de março de 2025, 127 páginas | duas taxonomias (IA preditiva e IA generativa) | nenhuma |
| Guidelines for Secure AI System Development | NCSC, CISA e 23 cossignatários | Orientação de ciclo de vida | 27 de novembro de 2023 | quatro fases | nenhuma |
| ETSI EN 304 223 | ETSI (do código de prática britânico) | Requisitos de base | TS em abril de 2025, EN em dezembro de 2025 | 13 princípios, 72 disposições, cinco fases | nenhuma |
| ENISA FAICP | ENISA | Framework de boas práticas | 7 de junho de 2023 | três camadas | cooperação do considerando 78 do AI Act |
| MITRE ATLAS | MITRE | Base de conhecimento de ameaças | versão 2026.10 (28 de outubro de 2026) | 16 táticas, 129 técnicas, 92 subtécnicas, 44 mitigações | ATT&CK |
| OWASP Top 10 for LLM 2026, Agentic Top 10, AI Exchange | OWASP GenAI Security Project | Listas de ameaças e guia de controlos | agosto de 2026, dezembro de 2025, flagship desde março de 2025 | 10 + 10 entradas, mais de 50 controlos | NIST, ATLAS, CWE; o AI Exchange contribuiu para a ISO/IEC 27090 e a prEN 18282 |
| CSA AI Controls Matrix | Cloud Security Alliance | Conjunto de controlos | v1.1, 22 de junho de 2026 | 247 controlos, 18 domínios, AI-CAIQ com 320 perguntas | ISO/IEC 42001, ISO 27001, NIST AI RMF, AI 600-1, BSI AIC4, AI Act |
| Databricks DASF | Databricks | Conjunto de controlos | v3.0, 20 de março de 2026 | 13 componentes, 97 riscos, 73 controlos | ATLAS, OWASP, SP 800-53, CSF, ENISA, ISO/IEC 42001, 27001, AI Act |
| Google SAIF | Google (dados doados à CoSAI) | Arquitetura e mapa de riscos | SAIF 2.0, 6 de outubro de 2025 | 15 riscos, 24 controlos, três princípios para agentes | nenhuma |
| CoSAI, AWS, Microsoft | OASIS, AWS, Microsoft | Responsabilidade partilhada e âmbito | CoSAI Shared Responsibility Framework v1.0, maio de 2026; AWS AI Security Framework, maio de 2026; modelo da Microsoft para agentes, agosto de 2026 | camadas, âmbitos, princípios | nenhuma (referências OWASP e ATLAS) |
A tabela diz o que cada referencial é, não qual adotar: quem decide são as famílias. Na última coluna, só a AICM e o DASF, entre os referenciais da indústria, chegam ao AI Act. O Integrated AI Security and Safety Framework da Cisco (16 de dezembro de 2025, 19 objetivos de atacante, mais de 150 técnicas) ficou de fora: é uma taxonomia e pertence aos catálogos de ameaças.
Catálogos de ameaças: o que o artigo 15.º, n.º 5, manda testar
O n.º 5 do artigo 15.º do AI Act exige que um sistema de IA de risco elevado resista a terceiros não autorizados que tentem alterar a sua utilização, resultados ou desempenho, e nomeia os ataques a prevenir, detetar, responder, resolver e controlar: envenenamento de dados, envenenamento de modelos, exemplos adversariais ou evasão do modelo, ataques à confidencialidade e falhas do modelo. Com a alteração não autorizada, são seis classes, e um framework de segurança de IA tem de ser testável contra todas.
O MITRE ATLAS 2026.10 (28 de outubro de 2026) conta 16 táticas, 129 técnicas, 92 subtécnicas, 44 mitigações e 77 estudos de caso; as técnicas para agentes chegaram com a v5.0.0 (30 de setembro de 2025) e as versões são mensais desde meados de 2026.
O OWASP Top 10 para LLM 2026 (3 de agosto de 2026) vai de LLM01 Prompt Injection a LLM10 Improper Output Handling; o Agentic Top 10 (9 de dezembro de 2025), de ASI01 Agent Goal Hijack a ASI10 Rogue Agents, cobre os sistemas que agem.
A NIST AI 100-2 E2025 (24 de março de 2025) separa a IA preditiva (evasão, envenenamento, privacidade) da generativa (cadeia de abastecimento, injeção de prompts direta e indireta, agentes), com revisões anuais previstas (taxonomia NIST AI 100-2, IA adversarial).
| Classe de ataque do artigo 15.º, n.º 5 | MITRE ATLAS | OWASP | NIST AI 100-2 |
|---|---|---|---|
| Envenenamento de dados | técnicas de envenenamento | LLM05 | envenenamento |
| Envenenamento do modelo | técnicas de cadeia de abastecimento e de envenenamento | LLM04 e LLM05 | envenenamento e cadeia de abastecimento |
| Exemplos adversariais ou evasão do modelo | técnicas de evasão | LLM01 para a evasão ao nível do prompt | evasão |
| Ataques à confidencialidade | técnicas de exfiltração e de inferência | LLM02 | privacidade |
| Falhas do modelo | não é uma classe de ataque | LLM07, LLM10 | não é uma classe de ataque |
| Alteração não autorizada da utilização ou dos resultados | envenenamento da configuração e do contexto de agentes (AML.T0080, AML.T0081) | ASI03, ASI06 | secção sobre agentes |
Conjuntos de controlos: onde o framework de segurança de IA se torna prova
É nesta família que um framework de segurança de IA deixa de descrever e passa a produzir prova.
CSA AICM e Databricks DASF
A CSA AI Controls Matrix v1.1 (22 de junho de 2026) tem 247 objetivos de controlo em 18 domínios e cinco pilares, análise de lacunas face à ISO/IEC 42001, ISO 27001, NIST AI RMF, AI 600-1, BSI AIC4 e AI Act, o questionário AI-CAIQ (320 perguntas) e o STAR for AI (nível 1 em autoavaliação, nível 2 em certificação sobre ISO 42001 ou 27001). Serve melhor quem já usa a CCM ou a ISO 27001.
O DASF 3.0 (20 de março de 2026) cobre os agentes: 13 componentes, 97 riscos, 73 controlos, um compêndio com separadores de aplicabilidade e correspondências com ATLAS, OWASP, SP 800-53, CSF, ENISA, ISO/IEC 42001, 27001 e AI Act. Rende mais num lakehouse.
ISO/IEC 42001 e ISO/IEC 27090
No anexo A da ISO/IEC 42001, a segurança está em A.6.2.2 (requisitos), A.6.2.4 (verificação e validação), A.6.2.5 (implantação), A.6.2.6 (operação e monitorização), A.6.2.7 (documentação técnica), A.6.2.8 (registos de eventos), A.7.2 a A.7.6 (dados), A.8.4 (comunicação de incidentes) e A.10.3 (fornecedores). A ISO/IEC 27090:2026 (outubro de 2026, 56 páginas, SC 27) é orientação não certificável que diz a um auditor ISO 27001 ou 42001 o que significa proteger um sistema de IA; a ISO/IEC 27091 (privacidade) está em FDIS desde julho de 2026 (ver a pilha de normas do AI Act).
NIST, ETSI e ENISA
As overlays SP 800-53 do NIST não passaram de um documento de conceito (14 de agosto de 2025) e de um esboço anotado (janeiro de 2026); o Cyber AI Profile, de um projeto preliminar inicial (16 de dezembro de 2025, comentários fechados a 30 de janeiro de 2026). São promissores, mas ainda não citáveis, e o NIST AI RMF não tem controlos. A ETSI EN 304 223 (13 princípios, 72 disposições, cinco fases, derivada do código britânico de 31 de janeiro de 2025) é a única base com disposições numeradas. As diretrizes do NCSC e da CISA (quatro fases) e o guia agêntico da CISA (1 de maio de 2026) são prática de implantação; o FAICP da ENISA, em três camadas, lembra que a cibersegurança geral vem primeiro.
A regra que aplicamos: um conjunto de controlos, com análise de lacunas face à lei, mantido como documento vivo do framework de segurança de IA.
Arquitetura e responsabilidade partilhada: SAIF, CoSAI, AWS, Microsoft
Esta família diz quem detém cada controlo e em que camada ele fica.
O SAIF 2.0 (Google, 6 de outubro de 2025) tem quatro áreas de componentes, 15 riscos, 24 controlos, três princípios para agentes (controladores humanos bem definidos, poderes limitados, ações e planeamento observáveis) e uma autoavaliação que gera um relatório. Os seus dados foram doados à CoSAI em setembro de 2025 e tornaram-se o CoSAI Risk Map.
A CoSAI (OASIS, julho de 2024) publicou princípios para sistemas agênticos seguros desde a conceção (16 de julho de 2025: governados e responsabilizados por humanos; delimitados e resilientes; transparentes e verificáveis), um AI Incident Response Framework (outubro de 2025, playbooks mapeados no ATLAS), o AI Shared Responsibility Framework v1.0 (maio de 2026: cinco camadas, um responsável por componente), o MCP Security v2.0 (setembro de 2026) e o Zero Trust for AI Systems (16 de setembro de 2026).
A AWS tem a Generative AI Security Scoping Matrix (cinco âmbitos, outubro de 2023), a Agentic AI Security Scoping Matrix (quatro âmbitos, novembro de 2025) e o AWS AI Security Framework (maio de 2026: três camadas, três fases, controlos cumulativos). A Microsoft publica um modelo de responsabilidade partilhada para IA e, desde agosto de 2026, um modelo para agentes mapeado no OWASP e no ATLAS.
O nosso veredicto: nenhum destes documentos tem correspondência com o artigo 15.º. Num framework de segurança de IA, servem para repartir controlos entre a sua equipa, o fornecedor de cloud e o do modelo, nunca para reivindicar conformidade.
A lei por detrás do framework de segurança de IA: artigo 15.º, artigo 42.º, n.º 3, e o CRA
O que o artigo 15.º exige
O n.º 1 exige exatidão, solidez e cibersegurança adequadas e consistentes ao longo do ciclo de vida; o n.º 4, resiliência a erros e falhas, redundância técnica e controlo dos ciclos de realimentação; o n.º 5, resistência aos ataques acima. O artigo 13.º, n.º 3, alínea b), subalínea ii), manda indicar nas instruções de utilização o nível contra o qual o sistema foi testado. Para os modelos de finalidade geral com risco sistémico, o artigo 55.º, n.º 1, alíneas a) e d), exige desde 2 de agosto de 2025 testes adversariais documentados e cibersegurança do modelo e da infraestrutura física.
A via do Regulamento de Ciber-Resiliência
O artigo 42.º, n.º 2, presume conforme com a cibersegurança do artigo 15.º o sistema certificado num esquema do Regulamento Cibersegurança (Regulamento (UE) 2019/881), a partir de 2 de agosto de 2026. O Omnibus Digital sobre IA (Regulamento (UE) 2026/1744, em vigor desde 27 de julho de 2026) acrescentou um n.º 3: com o artigo 12.º, n.º 1, do CRA, um sistema de risco elevado que seja produto com elementos digitais considera-se conforme com essa cibersegurança se respeitar os requisitos essenciais do CRA e a declaração de conformidade CRA o demonstrar. Os organismos notificados do AI Act podem verificar também os requisitos do CRA (artigo 12.º, n.º 2). O considerando 77 limita a via à cibersegurança, sem solidez nem exatidão. As obrigações de risco elevado aplicam-se a partir de 2 de dezembro de 2027 (anexo III) e de 2 de agosto de 2028 (anexo I); o CRA aplica-se plenamente a 11 de dezembro de 2027.
Normas, ENISA e incidentes
A EN 18286 (gestão da qualidade), citada em outubro de 2026 pela Decisão de Execução (UE) 2026/2274, é a primeira norma harmonizada do AI Act. A prEN 18282 (especificações de cibersegurança para sistemas de IA, JTC 21 WG 5) esteve em inquérito público de 15 de maio a 14 de julho de 2026; o prazo do pedido de normalização é 28 de fevereiro de 2027. Até ser citada, não dá presunção.
A ENISA juntou ao FAICP a visão sobre a cibersegurança na era da IA de fronteira (7 de julho de 2026, dia do Plano de Ação da UE para a Cibersegurança e a IA: NIS2, CRA e AI Act lidos em conjunto para os modelos de risco sistémico) e o ENISA Threat Landscape 2026 (22 de setembro de 2026), que põe os ataques potenciados por IA entre as ameaças principais.
Por fim, o artigo 73.º: uma violação de segurança só se comunica se for um incidente grave (artigo 3.º, ponto 49), e o responsável pela implantação monitoriza e suspende ao abrigo do artigo 26.º, n.º 5 (ver a comunicação de incidentes). Um framework de segurança de IA que ignore esta fronteira produz alertas, não prova.
Como escolher: uma regra de seleção por papel do operador
A escolha depende do papel que o AI Act atribui à organização, não do setor.
| O seu papel | Âncora legal | Catálogo de ameaças | Conjunto de controlos | Prova que um auditor aceita |
|---|---|---|---|---|
| Prestador de um sistema de IA de risco elevado | artigos 9.º, 11.º, 13.º, 15.º e 43.º | ATLAS, OWASP, NIST AI 100-2 | anexo A da ISO/IEC 42001 ou CSA AICM; prEN 18282 quando harmonizada | secção de cibersegurança do anexo IV, relatórios de testes e de red teaming, métricas nas instruções de utilização, declaração UE de conformidade |
| Prestador de um produto com elementos digitais | artigo 12.º do CRA, artigo 42.º, n.º 3, do AI Act | os mesmos | requisitos essenciais do anexo I do CRA | declaração de conformidade CRA que indique o nível do artigo 15.º |
| Responsável pela implantação | artigos 26.º e 73.º | OWASP Agentic Top 10 para agentes | AI-CAIQ ao fornecedor, matriz de responsabilidade partilhada (CoSAI, AWS ou Microsoft), monitorização | questionário do fornecedor, registo das instruções de utilização, registo de monitorização, decisão de suspensão |
| Prestador de GPAI com risco sistémico | artigo 55.º, n.º 1, alíneas a) e d) | ATLAS, avaliações de fronteira | CoSAI, a visão da ENISA, o código de práticas | testes adversariais documentados, medidas de cibersegurança para o modelo e a infraestrutura |
| Empresa que constrói sobre uma plataforma cloud | artigo 15.º ou 26.º, consoante o papel | OWASP Top 10 para LLM | o framework da plataforma (SAIF, DASF, AWS, Microsoft) como camada de implementação, AICM para a alegação de conformidade | correspondência de controlos com análise de lacunas |
Três regras completam a tabela. Um conjunto de controlos, um catálogo de ameaças e um modelo de responsabilidade, não três de cada. Cada um mapeado uma única vez contra as seis classes do artigo 15.º: esse mapeamento é a espinha dorsal do seu framework de segurança de IA. E o mapeamento sob controlo de alterações: uma nova versão, um novo modelo ou um novo agente reabre-o, e com o ATLAS mensal a revisão vai para o calendário.
Em Portugal, a ANACOM foi anunciada a 19 de setembro de 2025 como autoridade de fiscalização do mercado. O Centro Nacional de Cibersegurança e o Quadro Nacional de Referência para a Cibersegurança continuam a ser a base de cibersegurança geral, e a CNPD trata dos dados pessoais usados no treino e na inferência. Num sistema de IA de risco elevado, a avaliação da conformidade pede as duas camadas.
Do framework de segurança de IA à prova de auditoria
Um auditor não aceita um framework, aceita artefactos datados. Pedimos sete antes de dar um framework de segurança de IA por operacional.
- <b>A correspondência de controlos com análise de lacunas face ao artigo 15.º.</b> A AICM e o DASF trazem uma. Adapte-a em vez de a reescrever.
- <b>O modelo de ameaças de cada sistema</b> contra as seis classes do artigo 15.º. Inclui as técnicas ATLAS e os riscos OWASP que de facto se aplicam.
- <b>Os relatórios de testes adversariais e de </b><b>red teaming</b>, datados. Repetem-se após cada alteração substancial.
- <b>A secção de cibersegurança do anexo IV e as métricas das instruções de utilização.</b> Os números têm de coincidir com os testes.
- <b>O questionário AI-CAIQ e a repartição de responsabilidades.</b> Sem eles, os controlos herdados do fornecedor ficam por demonstrar.
- <b>Os playbooks de incidente e o registo das decisões do artigo 73.º.</b> Cada violação avaliada leva a razão da decisão.
- <b>O relatório de risco SAIF ou DASF como documento de trabalho.</b> Orienta a equipa, nunca serve de alegação de conformidade.
Estes registos vivem melhor numa plataforma de governação: primeiro o inventário dos sistemas de IA, depois um conjunto de controlos por sistema, depois a prova datada. A monitorização da conformidade assinala o que caducou, a auditabilidade guarda o rasto e a AI-BOM documenta a cadeia de abastecimento.
Perguntas frequentes
<b>O que é um framework de segurança de IA?</b>
Um conjunto nomeado e versionado de ameaças, controlos ou responsabilidades contra o qual um terceiro pode verificar a proteção de um sistema de IA. Há quatro famílias: a lei (AI Act, CRA), os catálogos de ameaças (ATLAS, OWASP, NIST AI 100-2), os conjuntos de controlos (AICM, DASF, ISO/IEC 42001, ISO/IEC 27090, ETSI EN 304 223) e os modelos de responsabilidade (SAIF, CoSAI, AWS, Microsoft). Escolha um por família.
<b>Que framework de segurança de IA exige o AI Act?</b>
Nenhum pelo nome. O AI Act exige resultados: exatidão, solidez e cibersegurança adequadas e resistência às classes de ataque do artigo 15.º, n.º 5. A presunção virá das normas harmonizadas, e a prEN 18282 ainda não está citada. Até lá, há duas vias: um certificado do Regulamento Cibersegurança (artigo 42.º, n.º 2) ou, para produtos com elementos digitais, a declaração CRA (artigo 42.º, n.º 3). Qualquer framework de segurança de IA tem de ser mapeado contra o artigo 15.º.
<b>A ISO/IEC 27090 é uma norma certificável?</b>
Não. A ISO/IEC 27090:2026 (outubro de 2026, ISO/IEC JTC 1/SC 27, 56 páginas) é orientação sobre ameaças e comprometimentos de sistemas de IA, sem certificado próprio. Vale nas auditorias que já existem: dá a um auditor ISO/IEC 27001 ou 42001 uma referência do que significa proteger um sistema de IA e sustenta os controlos do anexo A. O certificado continua a ser o da ISO/IEC 42001 ou o da 27001.
<b>NIST AI RMF ou NIST Cyber AI Profile: qual é o framework de segurança?</b>
Por agora, nenhum dos dois dá controlos. O AI RMF 1.0 (janeiro de 2023) e o NIST AI 600-1 (julho de 2024) são frameworks de risco com quatro funções e a característica «secure and resilient». O Cyber AI Profile (NIST IR 8596), perfil comunitário do NIST CSF 2.0, só existe como projeto preliminar inicial de 16 de dezembro de 2025. Para controlos citáveis, recomendamos a AICM ou o DASF, que já mapeiam o AI RMF.
<b>Preciso de um framework se o meu fornecedor executa o modelo?</b>
Sim, mas de outro tipo. O responsável pela implantação segue as instruções de utilização, monitoriza o sistema e suspende-o perante um risco (artigo 26.º); o artigo 73.º cobre os incidentes graves. O seu framework de segurança de IA é o lado do cliente: AI-CAIQ ao fornecedor, matriz de responsabilidade partilhada (CoSAI, AWS ou Microsoft), OWASP Agentic Top 10 para agentes e registo de monitorização. Os controlos do fornecedor documentam-se, não se presumem.
<b>Qual é a diferença entre um framework de segurança de IA e o AI security posture management?</b>
O framework define o que deve ser verdade: ameaças a testar, controlos a aplicar, responsáveis. O AI security posture management (AI-SPM) é uma categoria de ferramenta que descobre modelos, agentes e dados em uso, deteta configurações erradas e recolhe sinais. A ferramenta alimenta a prova, não a define: um painel sem correspondência com o artigo 15.º mostra atividade, não conformidade. Primeiro o framework, depois a ferramenta.
Conclusão
A lei decide o que provar, o catálogo de ameaças o que testar, o conjunto de controlos o que mostrar. Um framework de segurança de IA útil em 2026 não é o mais recente nem o do seu fornecedor de cloud: é um referencial por família, mapeado uma vez contra as seis classes do artigo 15.º e mantido sob controlo de alterações. Outubro de 2026 trouxe a ISO/IEC 27090, a primeira norma harmonizada e o fim do inquérito da prEN 18282; até dezembro de 2027 há tempo, mas não há folga. Comece pelo inventário, escolha o conjunto de controlos e ligue cada prova ao controlo que demonstra. A plataforma de governação de IA da AI Sigil foi desenhada para manter tudo num único registo.