Notícias

Como transformar os princípios de risco da IA em prática: guia das quatro funções do NIST

O referencial de gestão de riscos da IA do NIST torna-se útil quando as suas quatro funções orientam decisões reais, evidências e responsabilidades ao longo do ciclo de vida da IA.
Ilustração editorial gerada por IA de uma sala de operações de gestão de riscos com quatro zonas de trabalho interligadas; é conceptual, não uma instalação real do NIST.

As políticas relativas aos riscos da inteligência artificial parecem muitas vezes convincentes até ao momento em que uma equipa tem de decidir se um sistema está preparado para ser utilizado por pessoas reais. O National Institute of Standards and Technology dos Estados Unidos, NIST, concebeu o seu AI Risk Management Framework, ou AI RMF, de adoção voluntária, para ajudar as organizações a integrar considerações de fiabilidade na conceção, desenvolvimento, utilização e avaliação de sistemas de IA. O seu núcleo prático está organizado em torno de quatro funções: Govern, Map, Measure e Manage.

Estas funções não constituem uma sequência executada uma única vez, nem um selo de certificação. São áreas de trabalho interligadas. A governação molda todas as decisões; o mapeamento dá contexto às medições; a medição produz evidências; e a gestão transforma essas evidências em prioridades e ações.

Govern: tornar visível a responsabilidade

Govern é a base. Uma equipa precisa de responsáveis identificados, vias de escalamento, políticas, requisitos de documentação e um método para incluir as perspetivas das pessoas afetadas. Tem de saber quem pode aprovar a entrada em produção, quem a pode interromper, quem investiga um incidente e que evidências devem ser conservadas.

Um registo de governação útil é específico. Em vez de afirmar que «os seres humanos mantêm o controlo», deve indicar que decisão é analisada por uma pessoa, que informações estão disponíveis para quem faz a análise, quanto tempo lhe é concedido e o que acontece quando o nível de confiança é baixo. A governação também abrange os fornecedores: comprar um modelo não transfere a responsabilidade para fora da organização que o utiliza.

Map: compreender o sistema no seu contexto

Map pergunta para que serve o sistema de IA, onde irá funcionar e quem poderá sentir os seus benefícios ou danos. O mesmo modelo pode representar riscos muito diferentes numa ferramenta interna de escrita, num processo de seleção de candidatos ou num fluxo de trabalho clínico. As equipas devem descrever a utilização prevista, a utilização indevida previsível, os grupos afetados, as dependências, a proveniência dos dados e as consequências de uma falha.

Um bom mapeamento também regista pressupostos. O idioma introduzido é suportado? O utilizador saberá que o resultado foi gerado por uma máquina? Uma pessoa pode contestar um resultado? Que ambiente foi utilizado durante os testes e em que difere do ambiente de produção? Um pressuposto explícito pode ser testado; um pressuposto oculto transforma-se numa surpresa.

Measure: recolher evidências que respondam às questões mapeadas

Measure vai além da apresentação de um único valor de exatidão. Conforme o contexto, as evidências podem incluir a fiabilidade perante alterações nas entradas, o desempenho por subgrupo, testes de privacidade e segurança, taxas de conteúdo prejudicial, calibração, acessibilidade, estudos de fatores humanos e observações após a entrada em produção. A métrica deve estar ligada ao risco descrito durante o mapeamento.

As equipas devem definir limiares antes de receberem os resultados, documentar as limitações e conservar os testes que falharam, em vez de selecionarem apenas números favoráveis. Alguns danos são difíceis de reduzir a uma única métrica; por isso, a análise qualitativa e os comentários das pessoas afetadas podem complementar os testes quantitativos. A medição reduz a incerteza, mas não a elimina.

Manage: definir prioridades, responder e continuar a monitorizar

Manage converte o panorama dos riscos em decisões. Uma equipa pode mitigar um risco, limitar o caso de utilização, acrescentar análise humana, monitorizar um indicador antecedente, preparar uma reversão para um estado anterior ou decidir não colocar o sistema em produção. As prioridades devem refletir a probabilidade, a gravidade e a tolerância ao risco da organização, e não apenas qual correção é mais fácil.

A gestão continua depois do lançamento. Os modelos, os dados, o comportamento dos utilizadores e as condições externas podem mudar. Um plano prático inclui, por isso, monitorização, resposta a incidentes, controlo de alterações e um evento que desencadeie uma nova avaliação. Se uma atualização do modelo alterar o seu comportamento, um relatório de testes anterior é evidência histórica, não uma aprovação automática da nova versão.

Utilizar perfis para adaptar o referencial ao contexto local

O NIST descreve os perfis como aplicações das funções, categorias e subcategorias do referencial a um ambiente específico. Um perfil atual pode descrever a forma como uma organização gere hoje um caso de utilização; um perfil-alvo pode descrever o estado pretendido. A diferença entre ambos cria uma lista concreta de melhorias.

Esta adaptação é importante porque o Playbook não é uma lista de verificação que todas as organizações tenham de cumprir na íntegra. O NIST apresenta ações sugeridas entre as quais os utilizadores podem escolher, de acordo com o seu caso de utilização, recursos e interesses. Copiar todas as sugestões sem as associar a uma decisão real pode gerar burocracia sem produzir resultados mais seguros.

Um modelo inicial para uma equipa pequena

  • Govern: identifique o responsável, quem faz a análise, quem tem autoridade para interromper o sistema e onde são conservadas as evidências.
  • Map: documente a utilização prevista, as pessoas afetadas, os principais modos de falha e os pressupostos.
  • Measure: escolha testes e limiares que abordem esses modos de falha.
  • Manage: decida o que tem de mudar antes do lançamento e o que desencadeará posteriormente uma reversão ou uma nova análise.

Repita as quatro funções quando mudar o caso de utilização, o modelo, os dados ou o ambiente operacional. O valor não reside no número de documentos produzidos. Reside na capacidade da organização para explicar o que sabia, o que testou, o que decidiu e quem continua responsável.

O que o referencial pode — e não pode — demonstrar

A utilização do AI RMF pode melhorar a disciplina e a linguagem comum, mas não demonstra, por si só, que um sistema seja seguro, legal ou adequado à finalidade. O NIST descreve o referencial como voluntário e o Playbook de apoio como um recurso flexível. As obrigações legais, as regras setoriais e a avaliação independente podem continuar a aplicar-se.

Uma afirmação responsável é, portanto, moderada: as quatro funções ajudam as equipas a fazer melhores perguntas e a ligar os princípios a decisões sustentadas por evidências. Constituem uma estrutura para a gestão contínua dos riscos, não um distintivo que encerra a discussão.

Fontes primárias

NIST AI Risk Management Framework e NIST AI RMF Playbook. Consultados em 11 de setembro de 2026.