Gestão de riscos de IA: frameworks, ciclo de vida e controlos

O essencial

• A gestão de riscos de IA é um único programa operacional, não uma coleção de referenciais: um ciclo de vida com um dono claro (identificar, avaliar, mitigar, monitorizar) que faz convergir o NIST AI RMF, a ISO/IEC 42001 com a ISO/IEC 23894 e o Article 9 do EU AI Act no mesmo conjunto de controlos.
• O Article 9 obriga os prestadores de sistemas de risco elevado a manter um sistema de gestão de riscos contínuo e iterativo ao longo de todo o ciclo de vida.
• Os riscos de IA agrupam-se em quatro famílias: dados, modelo, operação e segurança, e direitos fundamentais.
• Um programa credível vive dos seus artefactos duráveis: inventário, registo de riscos, mapeamento de controlos, evidências e aprovação do risco residual.
• Nenhum referencial substitui os outros; o valor está em cruzá-los num só quadro de governação da IA que um auditor ou um organismo notificado consiga inspecionar.

O que é a gestão de riscos de IA?

A gestão de riscos de IA é a disciplina que identifica, avalia, trata e monitoriza os riscos específicos que os sistemas de inteligência artificial introduzem numa organização, do primeiro esboço de um caso de uso até à retirada de serviço do modelo. Não é uma auditoria pontual nem um questionário preenchido antes do lançamento, mas um processo que acompanha o sistema enquanto este estiver em produção e a tomar decisões que afetam pessoas. O que a distingue da gestão de risco empresarial clássica e da segurança informática é a natureza dos objetos sob vigilância. Um controlo financeiro trata de montantes e contrapartes; um controlo de cibersegurança trata de vulnerabilidades e acessos. A gestão de riscos de IA acrescenta uma dimensão que nenhum dos dois captura: o comportamento do modelo pode degradar-se sozinho, sem qualquer ataque e sem qualquer alteração de código. Os dados de entrada mudam, a distribuição real afasta-se da distribuição de treino, e o sistema começa a errar de forma silenciosa. Um modelo de scoring aprovado no dia da entrada em serviço pode discriminar seis meses depois, apenas porque a população mudou. Há ainda uma diferença de perímetro. O risco de IA raramente é só técnico. Um mesmo sistema pode ser simultaneamente fonte de risco de dados (treino de proveniência incerta), de risco de modelo (enviesamento), de risco operacional (indisponibilidade) e de risco para os direitos fundamentais (decisão automatizada sem via de recurso). Tratar cada plano em silos separados produz pontos cegos precisamente nas interseções, que é onde os incidentes acontecem. Por isso, a gestão de riscos de IA madura não é uma extensão do registo de riscos corporativo, mas uma peça própria do sistema operativo de governação da IA da organização. Partilha a linguagem da conformidade em gestão de risco tradicional, mas obriga a instrumentar o modelo, a medir o seu desempenho ao longo do tempo e a atribuir a alguém a responsabilidade explícita por aceitar, ou recusar, o risco residual que sobra depois dos controlos.

Porque é que a gestão de riscos de IA é urgente agora

A pressão regulatória deixou de ser hipotética. O Article 9 do EU AI Act exige que os prestadores de sistemas de risco elevado mantenham um sistema de gestão de riscos como processo contínuo, sujeito a revisão sistemática, capaz de identificar os riscos previsíveis para a saúde, a segurança e os direitos fundamentais, de os estimar e avaliar, e de adotar medidas de tratamento direcionadas. O texto vai mais longe: o risco residual deve ser considerado aceitável, e os ensaios servem precisamente para identificar as medidas adequadas. Não basta ter uma política escrita; é preciso demonstrar o funcionamento do processo com evidências, algo que detalhamos no guia do Regulamento Europeu de IA para operadores. A dimensão operacional é a segunda razão. Em poucos anos, os sistemas de IA passaram de provas de conceito isoladas a componentes no caminho crítico de processos reais: aprovação de crédito, triagem de candidaturas, apoio ao cliente, deteção de fraude. Quando um destes sistemas falha, a falha não fica contida na equipa de dados. Propaga-se para o cliente, para o regulador e para a reputação da marca, muitas vezes antes de alguém internamente perceber que algo mudou. Há, por fim, um problema de visibilidade que antecede tudo o resto. Não se pode gerir o risco de um sistema cuja existência se desconhece. A adoção descentralizada de ferramentas de IA generativa por equipas de negócio, sem passar pela área de tecnologia ou pela governação, criou uma camada de Shadow AI que escapa a qualquer inventário. Modelos comprados, APIs subscritas com cartão de crédito, assistentes integrados em folhas de cálculo: cada um é uma superfície de risco não mapeada. O primeiro trabalho de um programa sério não é avaliar riscos, é descobrir sistemas.

As grandes categorias de risco de IA

Um registo de riscos de IA útil organiza-se por famílias, porque cada uma exige métricas, testes e controlos diferentes. Quatro categorias cobrem a maioria dos casos.

Riscos de dados

Os dados são a matéria-prima e, portanto, a primeira fonte de risco. A qualidade insuficiente (rótulos errados, valores em falta, amostras não representativas) propaga-se diretamente para o comportamento do modelo. A proveniência incerta levanta questões de licenciamento e conformidade quando não se consegue reconstituir de onde veio cada conjunto de treino. A privacidade impõe-se sempre que dados pessoais entram no ciclo, o que torna a avaliação de impacto sobre a proteção de dados um passo obrigatório e não opcional. E existe o envenenamento de dados, em que um atacante contamina o conjunto de treino para induzir um comportamento específico mais tarde. Estes riscos partilham uma propriedade incómoda: manifestam-se a jusante, no modelo, muito depois de a decisão sobre os dados ter sido tomada.

Riscos de modelo

Aqui vivem os riscos mais discutidos. O enviesamento algorítmico, quando o modelo trata sistematicamente pior um grupo, é o mais escrutinado pelos reguladores e o tema que aprofundamos no artigo sobre enviesamento algorítmico. A deriva (drift) é a degradação silenciosa do desempenho à medida que a realidade se afasta dos dados de treino. A alucinação, sobretudo em modelos generativos, produz saídas plausíveis mas falsas, e é um dos principais riscos da IA generativa. A robustez mede a resistência do modelo a entradas fora do esperado. Medir estes riscos exige instrumentação séria, apoiada em benchmarks de LLM e em métricas acompanhadas ao longo do tempo, não uma única vez.

Riscos operacionais e de segurança

Depois de o modelo estar em produção, entra em cena uma superfície de ataque própria. Os ataques adversariais (entradas construídas para enganar o modelo), a injeção de instruções em sistemas baseados em prompts, o roubo de modelo e a exfiltração de dados de treino estão hoje catalogados de forma estruturada no MITRE ATLAS, a referência para táticas adversariais contra sistemas de aprendizagem automática. Somam-se o uso indevido (o sistema aplicado a fins não previstos) e os riscos de disponibilidade, porque um modelo no caminho crítico que fica indisponível é uma interrupção de negócio como qualquer outra.

Riscos éticos, legais e para os direitos fundamentais

A última família é a que os controlos técnicos não resolvem sozinhos. A discriminação com efeito jurídico ou material sobre uma pessoa, a falta de transparência sobre quando e como uma decisão foi automatizada, e a ausência de supervisão humana efetiva colocam a organização em conflito direto com o direito. A explicabilidade da IA deixa de ser uma preocupação académica e passa a ser a condição para que uma pessoa afetada possa contestar uma decisão. São precisamente estes os riscos que o Article 9 obriga a identificar em primeiro lugar.

O ciclo de vida da gestão de riscos de IA

Um programa funciona quando o risco percorre um circuito fechado e repetível, com um dono em cada etapa. As quatro fases seguintes descrevem esse circuito: não são um projeto com início e fim, mas uma engrenagem que gira enquanto o sistema estiver vivo.

Identificar e mapear

Tudo começa no inventário. Sem uma lista fiável dos sistemas de IA em uso, com o respetivo caso de uso, finalidade prevista, dados que processam e pessoas afetadas, não há gestão de risco possível, apenas reação a incidentes. Esta fase corresponde à função Map do NIST AI RMF: caracterizar o contexto antes de julgar o risco. É aqui que se decide se um sistema é de risco elevado à luz do EU AI Act, se processa dados pessoais, se toma decisões com efeito jurídico. Um sistema mal mapeado será mal avaliado, por mais rigorosa que seja a análise seguinte. A pergunta prática desta etapa é simples: o que faz este sistema, para quem, e o que pode correr mal.

Avaliar e medir

Com o contexto estabelecido, avalia-se cada risco quanto à probabilidade e ao impacto, e mede-se o que é mensurável. É a função Measure do NIST AI RMF. Medir significa testar: ensaios de enviesamento em subgrupos, avaliação de robustez, verificação de desempenho contra limiares definidos à partida. O Article 9 é explícito ao ligar os ensaios à identificação das medidas de tratamento: testa-se para descobrir o que precisa de correção, não para produzir um relatório tranquilizador. Uma avaliação honesta distingue o risco inerente (antes de qualquer controlo) do risco residual (o que sobra depois), porque é sobre este último que alguém terá de decidir.

Mitigar e gerir

A terceira fase transforma a avaliação em ação. Aplicam-se controlos, técnicos e organizacionais: filtros, limiares, supervisão humana em pontos de decisão, restrições de utilização, planos de recuo. Cada controlo deve estar associado ao risco que reduz, para que a ligação entre risco e mitigação seja rastreável. No fim, sobra sempre um risco residual, e a etapa só está completa quando uma pessoa com autoridade o aceita formalmente, por escrito. Essa aprovação do risco residual é o artefacto que o Article 9 exige em substância ao pedir que o risco residual seja julgado aceitável. Sem uma assinatura responsável, o registo de riscos é apenas uma lista de intenções.

Monitorizar e rever

O ciclo fecha na produção, e nunca para. Vigia-se a deriva do modelo, acompanha-se o desempenho real face aos limiares, e mantém-se um processo de resposta a incidentes pronto a atuar. A monitorização de conformidade dos sistemas de IA transforma esta vigilância num fluxo contínuo em vez de uma revisão anual. Quando ocorre um incidente grave, entra em cena a obrigação de reporte de incidentes de IA prevista no Artigo 73 do EU AI Act. A monitorização alimenta de volta a identificação: cada incidente e cada deriva reabrem o ciclo, tal como o exigem a revisão sistemática do Article 9 e a natureza iterativa do NIST AI RMF.

Referenciais e normas

O erro mais comum é tratar cada referencial como um projeto separado, com equipa, calendário e lista de controlos próprios. Os três principais dizem, no essencial, a mesma coisa por vocabulários diferentes. O trabalho de valor está em mapeá-los para o mesmo conjunto de controlos, donos e evidências, algo que exploramos no artigo sobre o cruzamento entre NIST, ISO 42001 e EU AI Act.

NIST AI RMF

O NIST AI RMF 1.0, publicado em 2023, organiza-se em quatro funções centrais: Govern, Map, Measure e Manage, iteradas ao longo do ciclo de vida da IA. Govern é transversal e sustenta as outras três; na prática, as equipas começam em Map, avançam para Measure e chegam a Manage, com Govern a atravessar tudo. É um referencial voluntário, não certificável, e a sua força é a linguagem comum que oferece. Os documentos de origem estão em NIST AI 100-1 e no centro de recursos da NIST, e traduzimo-los para a prática no guia do NIST AI RMF.

ISO/IEC 42001 e ISO/IEC 23894

A ISO/IEC 42001 define um sistema de gestão de IA (AIMS) certificável: descreve o «o quê» e o «onde», ou seja, a estrutura de gestão, as responsabilidades e os processos que uma organização deve manter. A ISO/IEC 23894 complementa-a com o «como» do processo de risco: identificação, análise, avaliação e tratamento ao longo do ciclo de vida. Na prática, a ISO/IEC 42001 importa a ISO/IEC 23894 como o seu método de risco, pelo que as duas se leem em conjunto. A ficha oficial está disponível junto da ISO, e detalhamos a norma no artigo ISO 42001 explicada.

EU AI Act, Artigo 9

Ao contrário dos outros dois, o Article 9 é direito diretamente aplicável. Impõe aos prestadores de sistemas de risco elevado um sistema de gestão de riscos contínuo e iterativo, documentado e mantido, com revisão sistemática. Exige identificar os riscos para a saúde, a segurança e os direitos fundamentais, estimá-los e avaliá-los, adotar medidas de tratamento direcionadas e garantir que o risco residual é aceitável. Permite ainda combinar este processo com os processos de risco exigidos por outras normas de direito da União, o que evita duplicação e torna viável o programa único que defendemos.

O quadro seguinte mostra como as três referências descrevem os mesmos passos de programa:

Passo do programa	NIST AI RMF	ISO/IEC 42001 + 23894	EU AI Act Artigo 9
Governação e responsabilidade	Govern	Cláusulas de liderança e planeamento	Sistema de risco documentado e mantido
Identificar e contextualizar	Map	Identificação de risco da 23894	Identificar riscos para saúde, segurança, direitos
Avaliar e medir	Measure	Análise e avaliação da 23894	Estimar e avaliar riscos, ensaios
Tratar e aceitar	Manage	Tratamento da 23894; controlos do Anexo A	Adotar medidas; risco residual aceitável
Monitorizar e rever	Govern e Manage	Cláusulas de avaliação e melhoria	Processo contínuo, revisão sistemática

Lido em coluna, cada referencial parece um mundo à parte. Lido em linha, torna-se evidente que um único controlo bem desenhado satisfaz as três exigências ao mesmo tempo, e que a escolha entre eles é, na maior parte dos casos, uma falsa escolha. É esta leitura horizontal que sustenta um referencial de governação de IA coerente.

Construir um programa de gestão de riscos de IA: papéis, artefactos, controlos

Um referencial não gere risco nenhum. Quem gere risco são pessoas com responsabilidades atribuídas, a produzir artefactos concretos que outra pessoa pode inspecionar. Um programa operacional assenta em três pilares. Os papéis vêm primeiro. Cada sistema de IA precisa de um dono de negócio, responsável pela finalidade e pela aceitação do risco residual, e de um dono técnico, responsável pela medição e pelos controlos. Acima deles, uma função de governação (um comité, um responsável pela IA, ou a articulação com a proteção de dados) mantém a visão de conjunto e a coerência com o quadro regulatório. Sem nomes associados a cada linha do registo de riscos, o programa é uma intenção, não um processo. Os artefactos são a prova de que o programa existe. Cinco são incontornáveis, e são exatamente os que um auditor ou um organismo notificado vai pedir: o inventário de sistemas de IA, o registo de riscos por sistema, o mapeamento de controlos (que liga cada controlo ao risco que reduz e ao requisito regulatório que satisfaz), as evidências que demonstram que o controlo está de facto a operar, e a aprovação do risco residual assinada por quem tem autoridade para a dar. Estes artefactos têm de ser duráveis e datados, porque o valor de uma evidência está na sua rastreabilidade ao longo do tempo. É aqui que a auditabilidade da IA deixa de ser um princípio abstrato e passa a ser uma propriedade concreta do sistema documental. Os controlos, por fim, são o elo entre a intenção e a redução real do risco. Um controlo sem evidência associada não é um controlo, é uma afirmação. Um controlo que não está ligado a nenhum risco identificado é esforço desperdiçado. E um controlo que existe no documento mas não é verificado em produção é uma falsa sensação de segurança. A disciplina que separa um programa credível de uma pasta de PDF é simples de enunciar e difícil de manter: cada risco tem um dono, cada controlo tem uma evidência, e cada risco residual tem uma assinatura.

Erros comuns na gestão de riscos de IA

O primeiro erro é confundir avaliar uma vez com gerir de forma contínua. Uma avaliação feita antes do lançamento e nunca mais revista ignora precisamente o que torna a IA diferente: a deriva. O sistema seguro no dia zero pode ser perigoso ao fim de um trimestre, sem que uma única linha de código tenha mudado. O segundo erro é tratar cada referencial como um projeto separado. Equipas que correm um projeto NIST AI RMF, outro ISO/IEC 42001 e um terceiro de conformidade com o EU AI Act triplicam o trabalho e acabam com três verdades ligeiramente diferentes sobre o mesmo sistema. O terceiro erro é gerir riscos de sistemas que não estão inventariados, deixando de fora toda a camada de Shadow AI. Não há avaliação que compense a ausência de descoberta. O quarto erro é confundir documentação com controlo. Uma política escrita não reduz risco; um controlo verificado em produção sim. A distância entre os dois é onde vivem os incidentes. O quinto erro é esquecer o âmbito. Muitas organizações reduzem a IA aos modelos internos e ignoram os de fornecedores e a IA de finalidade geral integrada em produtos de terceiros, que representa hoje boa parte da superfície de risco real. E estas exigências não vivem só na Europa: legislação como a lei de IA do Colorado segue uma lógica próxima de dever de cuidado.

Como a AI Sigil operacionaliza a gestão de riscos de IA

A AI Sigil foi desenhada para o programa único descrito neste artigo, e não para gerir referenciais em paralelo. O inventário de sistemas, o registo de riscos, o mapeamento de controlos, as evidências e a aprovação do risco residual vivem no mesmo lugar, com o NIST AI RMF, a ISO/IEC 42001 e o Article 9 do EU AI Act mapeados para o mesmo conjunto de controlos. É a diferença entre uma plataforma coerente e um conjunto de ferramentas soltas, que analisamos na comparação entre plataforma de conformidade e uma pilha improvisada de ferramentas. O objetivo é simples: quando o auditor ou o organismo notificado bater à porta, os artefactos já existem, estão datados e estão ligados entre si.

Perguntas frequentes

Quais são os quatro tipos de risco de IA? Os riscos de IA agrupam-se em quatro famílias. Os riscos de dados abrangem a qualidade, a proveniência, a privacidade e o envenenamento dos conjuntos de treino. Os riscos de modelo incluem o enviesamento, a deriva, a alucinação e a falta de robustez. Os riscos operacionais e de segurança cobrem os ataques adversariais, o uso indevido e a indisponibilidade. Os riscos éticos, legais e para os direitos fundamentais envolvem a discriminação, a falta de transparência e a ausência de supervisão humana. Cada família exige métricas e controlos próprios, e um mesmo sistema pertence normalmente a várias em simultâneo.

Como é usada a IA na gestão de risco? Há dois sentidos que convém não confundir. Num deles, a IA é o objeto do risco: é o sistema que temos de identificar, avaliar, mitigar e monitorizar, e é esse o tema deste artigo. No outro, a IA é uma ferramenta ao serviço da gestão de risco em geral, por exemplo na deteção de fraude, na análise de anomalias ou na revisão de documentos. Quando a IA é a ferramenta que apoia decisões de risco, ela própria passa a ser um sistema que precisa da sua própria gestão de riscos de IA. A ferramenta não escapa ao programa.

Existe uma «regra dos 30%» na gestão de riscos de IA? Não. Não existe nenhuma «regra dos 30%» reconhecida em qualquer norma de gestão de riscos de IA, nem no NIST AI RMF, nem na ISO/IEC 42001, nem no Article 9 do EU AI Act. Nenhum destes textos fixa um limiar numérico universal do género «aceitar até 30% de risco». O que os referenciais exigem é que o risco residual seja avaliado e considerado aceitável em função do contexto e da finalidade prevista do sistema, e que essa aceitação seja documentada e assinada por quem tem autoridade. Qualquer número mágico apresentado como regra do setor deve ser tratado com ceticismo.

Qual é a diferença entre risco de IA e risco de cibersegurança? A cibersegurança protege a confidencialidade, a integridade e a disponibilidade dos sistemas contra ameaças, sobretudo intencionais. A gestão de riscos de IA inclui essa preocupação (os ataques adversariais são um risco real) mas vai além dela em dois pontos. Primeiro, o comportamento de um modelo pode degradar-se sem qualquer ataque, apenas porque a realidade mudou, algo que a cibersegurança não modela. Segundo, o âmbito abrange o enviesamento, a transparência e os direitos fundamentais, que não são questões de segurança. As duas disciplinas cruzam-se, mas nenhuma contém a outra.

Que referencial devo usar para a gestão de riscos de IA? A pergunta certa não é qual escolher, mas como cruzá-los. Se opera na União Europeia com sistemas de risco elevado, o Article 9 do EU AI Act é obrigatório e não negociável. O NIST AI RMF oferece a melhor linguagem comum para estruturar o processo internamente. A ISO/IEC 42001 dá-lhe um sistema de gestão certificável, útil para demonstrar maturidade a clientes e reguladores. O ideal é mapeá-los para o mesmo conjunto de controlos, para que um único esforço satisfaça as três exigências em vez de correr três projetos paralelos.

Quem é responsável pela gestão de riscos de IA numa organização? A responsabilidade é partilhada, mas nunca difusa. Cada sistema precisa de um dono de negócio, que responde pela finalidade e aceita formalmente o risco residual, e de um dono técnico, que responde pela medição e pelos controlos. Acima deles, uma função de governação (um comité de IA, um responsável dedicado, ou a articulação com a proteção de dados, o que em Portugal aproxima naturalmente a CNPD) mantém a coerência do conjunto. O princípio decisivo é que cada linha do registo de riscos tenha um nome associado. Risco sem dono é risco por gerir.

Conclusão

A gestão de riscos de IA não se resolve escolhendo o referencial certo, mas construindo um único programa que os faça convergir. Identificar, avaliar, mitigar e monitorizar deixam de ser fases de um projeto e passam a ser uma engrenagem contínua, alimentada pelo NIST AI RMF, pela ISO/IEC 42001 com a ISO/IEC 23894 e pelo Article 9 do EU AI Act, todos mapeados para o mesmo conjunto de controlos, donos e evidências. O que sobra no fim não é um relatório, mas um conjunto de artefactos duráveis (inventário, registo de riscos, mapeamento de controlos, evidências, aprovação do risco residual) que garantem a auditabilidade perante um auditor ou um organismo notificado. Nas indústrias reguladas, é essa capacidade de demonstrar, e não apenas de afirmar, que separa quem cumpre de quem apenas diz cumprir.