O essencial
- A segurança da IA consiste em proteger os dados, os modelos, os pipelines e as interfaces de um sistema de IA ao longo de todo o ciclo de vida. É uma disciplina distinta do uso da IA ao serviço das operações de segurança.
- Com o Regulamento europeu da IA, a segurança da IA deixou de ser facultativa: o artigo 15.º exige aos sistemas de risco elevado um nível adequado de exatidão, robustez e cibersegurança, incluindo a resistência a ataques adversariais e ao envenenamento de dados.
- As ameaças são próprias da aprendizagem automática: exemplos adversariais, envenenamento de dados e modelos, roubo de modelo, injeção de instruções e tratamento inseguro das saídas, reunidos no OWASP Top 10 para aplicações LLM e no MITRE ATLAS.
- Não se protege o que não foi inventariado: o registo dos sistemas de IA e a deteção da IA na sombra são o primeiro controlo, não um pormenor posterior.
- As organizações que acertam tratam a segurança da IA como um conjunto de controlos governado, ligado ao Regulamento europeu, à ISO/IEC 42001 e ao NIST AI RMF, sustentado por provas que um auditor aceitará em vez de um painel.
O que é a segurança da IA?
A segurança da IA é a prática de proteger um sistema de IA e tudo aquilo de que depende: os dados de treino e de inferência, o próprio modelo, os pipelines que o constroem e o servem, e as interfaces que o expõem aos utilizadores e a outros sistemas. Abrange todo o ciclo de vida, da recolha de dados ao treino, à colocação em produção, à monitorização e à desativação.
Uma distinção confunde muitas vezes as primeiras conversas, vale a pena enunciá-la com clareza. Usar a IA para a segurança significa aplicar a aprendizagem automática a tarefas defensivas, por exemplo a deteção de anomalias ou a triagem de alertas. A segurança da IA, objeto deste guia, significa proteger o próprio sistema de IA contra ataques e falhas. A distinção importa, porque ambas exigem responsáveis, controlos e provas diferentes.
Porque pesa esta distinção na conformidade? Porque os reguladores tratam agora a segurança do sistema de IA como uma obrigação expressa. O Regulamento europeu reúne exatidão, robustez e cibersegurança num só artigo para os sistemas de risco elevado (artigo 15.º do Regulamento da IA). A partir do momento em que a segurança passa a ser um requisito legal e não uma preferência de engenharia, exige governance: controlos definidos, responsabilidade atribuída e registos que demonstrem que os controlos funcionam.
Porque a segurança da IA é hoje um requisito de conformidade
Durante uma década, proteger um modelo foi uma boa ideia confinada à engenharia. Isso mudou. Três instrumentos fazem hoje da segurança da IA uma obrigação documentada.
Primeiro, o Regulamento europeu da IA. O artigo 15.º obriga os prestadores de sistemas de risco elevado a concebê-los para alcançar um nível adequado de exatidão, robustez e cibersegurança, e a manter essas propriedades ao longo da vida do sistema. O texto nomeia o adversario sem rodeios: os sistemas devem resistir às tentativas de terceiros não autorizados de alterar a sua utilização, as suas saídas ou o seu desempenho, incluindo ataques adversariais e envenenamento de dados.
Segundo, a ISO/IEC 42001. A norma de 2023 é o primeiro sistema de gestão da IA certificável, e os seus controlos do anexo A integram a segurança da IA, a governance dos dados e a mitigação de ataques adversariais num sistema que um organismo externo pode auditar (ISO/IEC 42001). A segurança encontra assim um lugar dentro de um ciclo governado em vez de uma lista de pendências.
Terceiro, o quadro de gestão de risco da IA do NIST. O NIST organiza o trabalho em quatro funções, Governar, Mapear, Medir e Gerir, e é na função Gerir que residem os controlos de segurança (NIST AI RMF). Lido em conjunto com a correspondência entre quadros do nosso guia dos referenciais, transforma a segurança numa rotina repetível e documentada.
O fosso entre obrigação e capacidade continua largo. Numa avaliação da Microsoft a 28 organizações, 25 não dispunham das ferramentas adequadas para proteger os seus sistemas de IA. É a conformidade que fecha esse fosso, porque impõe inventário, seleção de controlos e prova, em vez de deixar a segurança a quem se lembra de a pedir.
O panorama de ameaças à IA
Proteger um sistema de IA começa por saber contra o que nos defendemos. Os ataques à IA não decalcam a segurança de aplicações clássica, porque o modelo, os dados e a instrução são todos superfícies de ataque. Convém agrupar as ameaças por alvo. A base de conhecimento MITRE ATLAS reúne estas técnicas numa matriz inspirada no ATT&CK, e o nosso guia do MITRE ATLAS percorre a correspondência entre técnica e controlo.
Ataques ao modelo
Os exemplos adversariais são entradas concebidas para levar o modelo a classificar mal ainda que pareçam normais ao olho humano. Os ataques por evasão usam-nos na inferência para contornar um classificador. A extração de modelo, ou roubo de modelo, interroga um modelo em produção vezes suficientes para reconstruir uma cópia funcional, subtraindo propriedade intelectual e criando um modelo na sombra que o atacante pode sondar sem ligação.
Ataques aos dados
O envenenamento corrompe o conjunto de treino para que o modelo aprenda o errado, de uma degradação subtil da exatidão a portas traseiras ocultas que se ativam com uma entrada escolhida. Os ataques por inferência de pertença fazem o inverso: verificam se um registo concreto estava nos dados de treino, o que pode expor informação pessoal ou confidencial.
Ataques à camada de aplicação
Nos sistemas construídos sobre grandes modelos de linguagem, a camada de aplicação é hoje o alvo mais mole. O OWASP Top 10 para aplicações LLM encabeça a lista com a injeção de instruções, com a qual um atacante esconde instruções num prompt, num documento ou na saída de uma ferramenta para contornar as proteções do modelo, exfiltrar dados ou desencadear ações através das ferramentas ligadas. O tratamento inseguro das saídas, quando a resposta do modelo é propagada sem validação, transforma um defeito de linguagem num comprometimento do sistema.
Cadeia de fornecimento e riscos agenticos
Modelos, conjuntos de dados e bibliotecas provêm de terceiros, pelo que um modelo de pesos abertos envenenado ou uma dependência comprometida constituem um risco de cadeia de fornecimento. Os sistemas agenticos, capazes de invocar ferramentas e de agir sobre as próprias saídas, alargam o raio de impacto: uma única injeção bem-sucedida pode propagar-se em ações reais. O nosso guia dos agentes de IA autónomos trata os controlos de governance de que estes sistemas precisam.
Não se protege o que não se vê: inventário da IA e IA na sombra
Cada controlo que se segue pressupõe que sabe quais os sistemas de IA que opera. A maioria das organizações não sabe. As equipas adotam copilotos, integram modelos de terceiros e ligam agentes mais depressa do que qualquer função central consegue acompanhar, gerando IA na sombra: IA em uso que a governance nunca viu.
A IA na sombra é um problema de segurança antes de ser um problema de conformidade. Um modelo não registado não tem responsável, nem avaliação de ameaças, nem monitorização, nem via de gestão de incidentes. O primeiro controlo de um programa de segurança da IA não é, portanto, uma firewall, mas um inventário. Um registo vivo dos sistemas de IA, dos seus dados, dos seus modelos e do seu nível de risco é o que torna possível cada controlo posterior. O nosso guia da IA na sombra explica como o uso oculto da IA se torna uma lacuna de governance e porque a deteção é o controlo zero.
Ligar a segurança da IA aos quadros: Regulamento da IA, ISO 42001, NIST AI RMF
O gesto que nenhuma página concorrente faz consiste em ligar cada ameaça ao controlo que lhe responde e à cláusula que o exige. É isto que transforma a segurança da IA, de uma lista de compras de ferramentas, numa posição de conformidade defensável.
| Obrigação | O que exige | Controlo que a satisfaz |
|---|---|---|
| Artigo 15.º (robustez) | Resistência a erros, falhas e manipulação adversaria | Testes adversariais e red teaming, testes fora da distribuição |
| Artigo 15.º (cibersegurança) | Resistência à alteração não autorizada do uso, saídas ou desempenho | Controlo de acessos, integridade do modelo e dos dados, serviço seguro |
| ISO/IEC 42001 anexo A | Controlos de segurança da IA geridos num sistema certificado | Conjunto de controlos documentado, responsável designado, ciclo de revisão |
| NIST AI RMF (Gerir) | Tratamento priorizado dos riscos de IA identificados | Registo de riscos, correspondência de controlos, monitorização |
Construa a correspondência uma vez e cada auditoria passa a ser uma consulta em vez de uma corrida. A explicação da ISO 42001 e o guia do NIST AI RMF aprofundam cada lado, e o guia operacional do Regulamento da IA situa o artigo 15.º entre as obrigações mais amplas dos sistemas de risco elevado.
Das ameaças a controlos auditáveis
Uma ameaça que não se consegue provar é uma ameaça que não se consegue defender numa auditoria. Cada classe de ameaça deve, por isso, resolver-se num controlo nomeado, com um responsável e um registo.
- Ataques adversariais e por evasão: testes adversariais e red teaming planeados, com resultados registados e repetidos a cada evolução do modelo.
- Envenenamento de dados: rastreabilidade e proveniência dos dados, controlos de integridade no pipeline de treino.
- Roubo de modelo: limitação de frequência, monitorização de consultas e controlo de acessos nos pontos de inferência.
- Injeção de instruções e saídas inseguras: validação de entradas e saídas, listas de autorização de ferramentas, isolamento entre o modelo e as ações a jusante.
- Deriva e obsolescência: monitorização contínua do desempenho e do comportamento, com limiares que geram um alerta.
O sentido de formular os controlos assim não é a lista, é a prova. Um painel mostra um estado no instante presente; um auditor precisa de um registo ao longo do tempo. Cada controlo deve produzir um artefacto datado: um relatório de teste, um registo de monitorização, uma revisão de acessos. O nosso guia da auditabilidade expõe o que torna um sistema de IA auditável e como prová-lo, e a monitorização contínua da conformidade é o modo como estes artefactos se acumulam sem corridas manuais antes de cada revisão.
Quem responde pela segurança da IA? Funções e governance
A segurança da IA falha quando cada um pressupõe que outro trata dela. A cibersegurança clássica cabe ao CISO, mas a segurança da IA atravessa a ciência de dados, o MLOps e a conformidade, pelo que a responsabilidade tem de ser explícita.
Uma repartição viável atribui a prestação de contas a um responsável ou a um comité de governance da IA, com o CISO responsável pelos controlos de segurança, a ciência de dados responsável pelos testes ao modelo e a conformidade responsável pelas provas e pela correspondência aos quadros. Uma breve matriz de responsabilidades, acordada uma vez, evita a falha comum de um modelo ser lançado sem um responsável pela sua segurança. Esta camada de governance é o tema do nosso guia do sistema operativo da governance da IA, que mostra como estas funções se ligam ao ambiente de controlo mais amplo.
Como operacionalizar um programa de segurança da IA
Traduzir estas ideias num programa em funcionamento é uma sequência, não um projeto com data de fim.
- Inventariar cada sistema de IA, IA na sombra incluída, e atribuir a cada um um nível de risco.
- Conduzir uma avaliação de ameaças e riscos por sistema, usando o OWASP LLM Top 10 e o MITRE ATLAS como listas de verificação.
- Selecionar controlos a partir da sua correspondência aos quadros e atribuir a cada um um responsável.
- Testar os controlos: testes adversariais, red teaming e validação, dimensionados ao nível de risco.
- Recolher as provas como artefactos datados para cada controlo.
- Monitorizar em contínuo a deriva, os abusos e as novas vulnerabilidades.
- Integrar a gestão de incidentes, incluindo a comunicação regulamentar quando exigida. O Regulamento europeu fixa obrigações de comunicação de incidentes graves, tratadas no nosso guia da comunicação ao abrigo do artigo 73.º.
Execute a sequência como um ciclo. Cada novo modelo reentra no passo um, e cada alteração substancial relança testes e prova.
Perguntas frequentes
O que é a segurança da IA, em poucas palavras?
A segurança da IA é proteger um sistema de IA, os seus dados, o seu modelo, os seus pipelines e as suas interfaces contra ataques e falhas ao longo do ciclo de vida. Distingue-se do uso da IA para tarefas de segurança como a deteção de ameaças. Num contexto de conformidade abrange também obrigações expressas, como o requisito do artigo 15.º do Regulamento europeu de que os sistemas de risco elevado mantenham exatidão, robustez e cibersegurança.
Qual é a diferença entre segurança da IA e cibersegurança?
A cibersegurança clássica protege redes, aplicações e pontos terminais. A segurança da IA acrescenta superfícies de ataque que os controlos clássicos não cobrem: os dados de treino, o comportamento aprendido do modelo e a instrução. Uma firewall não trava nem o envenenamento de dados nem a injeção de instruções. A segurança da IA estende, pois, a cibersegurança com controlos conscientes do modelo, como testes adversariais, rastreabilidade de dados e validação de saídas, e liga-os aos quadros próprios da IA.
Quais são as principais ameaças à IA?
As classes recorrentes são os exemplos adversariais e os ataques por evasão aos modelos, o envenenamento de dados e modelos, o roubo ou extração de modelo, a inferência de pertença, a injeção de instruções e o tratamento inseguro de saídas na camada de aplicação, e os riscos de cadeia de fornecimento por modelos e bibliotecas de terceiros. O OWASP Top 10 para aplicações LLM e o MITRE ATLAS são os dois catálogos de referência que a maioria das equipas usa para verificar que não falta nenhuma categoria.
O Regulamento europeu da IA exige a segurança da IA?
Sim. O artigo 15.º obriga os prestadores de sistemas de risco elevado a alcançar e manter um nível adequado de exatidão, robustez e cibersegurança, estável durante toda a vida do sistema. Nomeia expressamente a resistência a ataques adversariais e ao envenenamento de dados. A segurança é, portanto, uma obrigação documentada para os sistemas de risco elevado, não uma prática de engenharia facultativa.
Como se relacionam a ISO 42001 e o NIST AI RMF com a segurança da IA?
A ISO/IEC 42001 é um sistema de gestão da IA certificável cujos controlos do anexo A incluem a segurança da IA, dando-lhe uma casa governada e auditável. O NIST AI RMF organiza o trabalho em Governar, Mapear, Medir e Gerir, com os tratamentos de segurança situados na função Gerir. Juntos, permitem ligar cada controlo de segurança a uma cláusula reconhecida, o que faz da auditoria uma consulta em vez de uma corrida.
Por onde começar um programa de segurança da IA?
Pelo inventário. Não se pode proteger, testar nem atestar um sistema de IA que não foi registado, e a maioria das organizações opera IA na sombra que a governance nunca viu. Construa um registo vivo dos sistemas de IA com os seus dados, modelos e níveis de risco, conduza depois as avaliações de ameaças, selecione controlos ligados aos quadros, teste-os e recolha provas datadas. O inventário é o controlo zero; tudo o resto depende dele.
Conclusão
A segurança da IA passou de refinamento de engenharia a obrigação de conformidade expressa, e as páginas que se posicionam para o termo não acompanharam: descrevem ameaças e vendem ferramentas, sem ligar a segurança aos quadros que agora a exigem. As organizações que agem bem tratam a segurança da IA como um conjunto de controlos governado, ligado ao Regulamento europeu, à ISO 42001 e ao NIST AI RMF, partindo de um inventário honesto para chegar a provas que um auditor aceitará. A AI Sigil foi construída para executar exatamente este ciclo, da deteção da IA à correspondência de controlos até às provas prontas para auditoria. Veja como o sistema operativo da governance da IA torna a segurança da IA uma capacidade defensável e contínua.