Estrutura de Gestão de Riscos de IA do NIST (NIST AI Risk Management Framework)

Estrutura de Gestão de Riscos de IA do NIST

Uma visão prática do RMF de IA do NIST e de como as equipes o mapeiam para controles.

Visão geral: o que é (e o que não é) o RMF de IA do NIST

A Estrutura de Gestão de Riscos de IA do NIST (NIST AI Risk Management Framework, AI RMF) 1.0 é uma estrutura voluntária do Instituto Nacional de Padrões e Tecnologia dos EUA (National Institute of Standards and Technology, NIST) para identificar, avaliar, gerenciar e comunicar riscos associados a sistemas de IA (AI systems). Ela foi projetada para ser:

  • Orientada ao ciclo de vida (lifecycle-oriented) (da ideação e coleta de dados até a implantação e o monitoramento)
  • Sociotécnica (sociotechnical) (os riscos podem surgir tanto do design técnico quanto do contexto social)
  • Flexível e focada em resultados (outcome-focused) (não prescreve um único conjunto “correto” de controles)
  • Compatível com programas existentes de governança e segurança (por exemplo, gestão de riscos corporativos (enterprise risk management), segurança e privacidade)

O que ela não é: um checklist de conformidade (compliance checklist) ou um padrão de certificação (certification standard). Em geral, as equipes a implementam traduzindo seus resultados em requisitos internos de controle (internal control requirements), práticas de engenharia e artefatos de evidência (evidence artifacts).

Este artigo oferece uma visão prática do RMF de IA e uma abordagem concreta para mapeá-lo para controles (controls) que equipes de engenharia, produto, jurídico, privacidade e segurança consigam realmente executar.

Ideias centrais por trás da estrutura

“Risco” no sentido do RMF de IA

No software tradicional, o risco costuma ser enquadrado como “bugs, violações, indisponibilidades”. O RMF de IA amplia isso para incluir:

  • Riscos de desempenho e confiabilidade (por exemplo, falhas de modelo sob mudança de distribuição (distribution shift))
  • Riscos de segurança operacional (safety) (por exemplo, aconselhamento danoso de um assistente generativo (generative assistant))
  • Riscos de viés e equidade (bias and fairness) (por exemplo, taxas de erro díspares (disparate error rates) entre grupos)
  • Riscos de privacidade (por exemplo, vazamento de dados, inferência de pertencimento (membership inference))
  • Riscos de segurança (security) (por exemplo, injeção de prompt (prompt injection), extração de modelo (model extraction))
  • Riscos de transparência e responsabilização (accountability) (por exemplo, incapacidade de explicar decisões ou auditar o comportamento)

O risco em IA também depende fortemente do contexto: o mesmo modelo pode ser de baixo risco para recomendações de entretenimento e de alto risco para triagem médica.

Sistemas de IA são sociotécnicos

O RMF de IA trata explicitamente a IA como um sistema incorporado a processos, pessoas e instituições — não apenas um modelo. Isso inclui:

  • Interface do usuário e escolhas de experiência do usuário (user experience, UX)
  • Revisão com humano no ciclo (human-in-the-loop)
  • Pipelines de dados (data pipelines) e práticas de rotulagem
  • Incentivos de negócio e configurações de implantação
  • Treinamento de operadores e resposta a incidentes (incident response)

É por isso que documentações como Cartões de Sistema e Cartões de Modelo são frequentemente usadas como evidência ao implementar a estrutura.

Características de confiabilidade

O RMF de IA organiza muitas preocupações sob características de confiabilidade (trustworthiness characteristics) (você pode tratá-las como “atributos de qualidade (quality attributes)” que deseja alcançar e demonstrar):

  • Válido e confiável
  • Seguro
  • Seguro e resiliente
  • Responsabilizável e transparente
  • Explicável e interpretável
  • Com privacidade aprimorada
  • Justo, com viés prejudicial gerenciado

Na prática, as equipes escolhem quais características são mais importantes para seu caso de uso e, então, definem requisitos mensuráveis e controles.

A estrutura do RMF de IA: GOVERNAR, MAPEAR, MEDIR, GERENCIAR

O “Núcleo (Core)” do RMF de IA é organizado em quatro funções:

  • GOVERNAR (GOVERN): estabelecer a capacidade organizacional de gerenciar riscos de IA
  • MAPEAR (MAP): entender o contexto, o uso pretendido e os impactos potenciais
  • MEDIR (MEASURE): analisar e avaliar riscos de IA usando métricas, testes e avaliação
  • GERENCIAR (MANAGE): priorizar, mitigar, monitorar e responder a riscos ao longo do tempo

Um modelo mental útil é:

  • GOVERNAR constrói o sistema operacional da gestão de riscos de IA
  • MAPEAR define o que você está construindo e o que pode dar errado
  • MEDIR produz evidências sobre como o sistema se comporta
  • GERENCIAR transforma evidências em decisões e controles contínuos

GOVERNAR na prática

GOVERNAR é onde as organizações estruturam:

  • Papéis e responsabilização (por exemplo, responsável pelo produto, responsável pelo modelo, responsável pelo risco)
  • Políticas e guardrails (uso aceitável, critérios de liberação, documentação)
  • Treinamento e competência (engenharia + não engenharia)
  • Gestão de terceiros e da cadeia de suprimentos (fornecedores, modelos fundacionais (foundation models), provedores de dados)
  • Supervisão e escalonamento (comitês de revisão, aceitação de risco, exceções)

Exemplo: uma empresa que implanta um agente de suporte baseado em modelo de linguagem grande (LLM) cria uma política de “Revisão de Liberação de IA” exigindo:

  • preenchimento de um modelo de Avaliações de Risco,
  • testes de equipe vermelha (red-team) para injeção de prompt,
  • uma contingência/transferência documentada para suporte humano,
  • aprovação por um responsável pelo risco nomeado antes do rollout em produção.

MAPEAR na prática

MAPEAR responde: Qual é o sistema, quem ele afeta e qual é o impacto se ele falhar?

Atividades comuns de MAPEAR:

  • Definir propósito pretendido, usuários e ambiente operacional
  • Identificar partes interessadas, incluindo grupos impactados que não são “usuários”
  • Enumerar cenários de dano (harm scenarios) (uso indevido e uso indevido previsível)
  • Documentar dependências (fontes de dados, provedores de modelo, ferramentas, plugins, APIs)
  • Definir tolerâncias preliminares de risco vinculadas à severidade do impacto

Exemplos de cenários de dano para um app de tutoria generativa:

  • O modelo fornece aconselhamento médico inseguro ou sobre autoagressão.
  • O modelo revela dados pessoais do treinamento ou do histórico de chat.
  • O conteúdo do modelo é sistematicamente enviesado contra certos grupos.
  • Injeção de prompt faz com que o modelo revele prompts do sistema (system prompts) ou políticas.

Esses cenários se tornam insumos para planos de avaliação (MEDIR) e mitigações (GERENCIAR).

MEDIR na prática

MEDIR responde: Como sabemos que o sistema está atingindo as metas de confiabilidade?

Técnicas típicas de medição:

  • Avaliação offline (offline evaluation) (benchmarks, conjuntos de teste, testes de estresse)
  • Testes de equidade (métricas por grupo, análise de erros, verificações de calibração)
  • Testes de robustez (mudança de distribuição, perturbações adversariais)
  • Testes de segurança (injeção de prompt, exfiltração de dados (data exfiltration), sondagens de extração de modelo)
  • Testes de privacidade (verificações de vazamento de informações de identificação pessoal (personally identifiable information, PII), controles de acesso, revisões de retenção)
  • Avaliação humana para qualidade generativa e conformidade com políticas
  • Métricas de monitoramento para deriva em produção e sinais de incidente

Exemplo: para um assistente de atendimento ao cliente baseado em modelo de linguagem grande, MEDIR pode incluir:

  • taxa de sucesso de evasão de salvaguardas (jailbreak) / injeção de prompt,
  • correção de recusa (recusar quando a política exige, cumprir caso contrário),
  • taxa de vazamento de PII a partir de canários sintéticos (synthetic canaries),
  • taxa de alucinação para intenções “precisa estar correto” (cobrança, cancelamentos),
  • latência e SLAs de disponibilidade (service-level agreements, SLAs),
  • taxa de concordância em revisão humana para escalonamentos.

GERENCIAR na prática

GERENCIAR é onde você decide o que fazer com os riscos medidos:

  • Selecionar o tratamento do risco: mitigar, transferir, evitar ou aceitar
  • Implementar mitigações (técnicas, procedimentais, de UX, contratuais)
  • Definir portões de liberação (release gates) e gatilhos de reversão (rollback)
  • Estruturar monitoramento, resposta a incidentes e gestão de mudanças (change management)
  • Comunicar limitações e riscos residuais às partes interessadas

Exemplos de mitigação para o assistente de suporte:

  • Restringir a uma base de conhecimento curada (geração aumentada por recuperação (RAG)) e bloquear navegação na web.
  • Adicionar filtragem de injeção de prompt e listas de permissão de chamadas de ferramentas (tool-call allowlists).
  • Exigir que ações de alto risco (reembolsos, mudanças de conta) sejam confirmadas por um humano.
  • Adicionar avisos voltados ao usuário e caminhos claros de escalonamento.
  • Manter um playbook de incidentes (incident playbook) e um pipeline de reporte (ver Relato de Incidentes e Transparência).

Da estrutura à realidade: como as equipes “mapeiam o RMF de IA para controles”

O que “controles” significam para sistemas de IA

Um controle é uma salvaguarda que reduz risco ou aumenta a probabilidade de atingir um objetivo. Controles podem ser:

  • Controles de governança: políticas, aprovações, treinamento, responsabilização
  • Controles de processo: checklists, revisões obrigatórias, gestão de mudanças
  • Controles técnicos: controle de acesso, logging, filtros, portões de avaliação em integração contínua/entrega contínua (CI/CD)
  • Controles detectivos: monitoramento, alertas, auditorias, exercícios de equipe vermelha
  • Controles corretivos: rollback, resposta a incidentes, gatilhos de retreinamento

Na prática, as organizações traduzem os resultados do RMF de IA em uma biblioteca de controles (control library) com:

  • uma declaração de controle (“o que deve ser verdade”),
  • um responsável,
  • frequência (por liberação, mensal, contínua),
  • artefatos de evidência (logs, relatórios, aprovações),
  • observações sobre ferramentas e automação.

Um fluxo de trabalho prático de mapeamento (repetível e auditável)

Uma abordagem comum se parece com isto:

  1. Criar um Perfil do RMF de IA (AI RMF Profile) para o caso de uso

    • Selecionar os resultados relevantes de GOVERNAR/MAPEAR/MEDIR/GERENCIAR.
    • Ajustar a profundidade com base no impacto (baixo/médio/alto) e no domínio.

  2. Converter resultados em objetivos de controle

    • Exemplo de resultado: “Os riscos do sistema de IA são medidos e documentados.”
    • Objetivo de controle: “Antes da liberação, a equipe deve executar e documentar uma bateria de avaliação definida.”

  3. Definir controles implementáveis

    • Escrever controles de um modo que a engenharia consiga executar (e auditorias consigam verificar).
    • Incluir a posição no ciclo de vida: dados, treinamento, avaliação, implantação, monitoramento.

  4. Mapear controles para evidências

    • Decidir o que conta como prova: relatórios de avaliação, entradas no registro de modelos (model registry), painéis de monitoramento, logs de acesso, aprovações.

  5. Fazer um mapeamento cruzado (crosswalk) com estruturas existentes

    • Se sua organização já usa NIST SP 800-53, ISO 27001, SOC 2 etc., mapeie cada controle de IA para essas famílias de controles (control families) para reduzir duplicidade.
    • O RMF de IA costuma ser a “camada de IA”, enquanto estruturas existentes fornecem o arcabouço corporativo de controles.

  6. Automatizar quando possível

    • Transformar verificações recorrentes em portões de CI/CD e alertas de monitoramento.
    • Manter revisão humana para julgamentos que dependem muito de contexto (por exemplo, avaliar novos cenários de dano).

Exemplo: mapeando resultados do RMF de IA para controles concretos (agente de suporte com modelo de linguagem grande)

A seguir está um mapeamento ilustrativo. Não é o texto oficial do RMF de IA; ele mostra como as equipes normalmente o operacionalizam.

Função do RMF de IA Objetivo prático Exemplo de controle (o que você exige) Evidência (o que você guarda) Responsável
GOVERNAR Responsabilização e supervisão Responsável pelo modelo + responsável pelo risco nomeados, exigidos para todo modelo/sistema implantado Registro de titularidade no registro de modelos; ticket de aprovação Eng + GRC
MAPEAR Identificação de contexto e danos Modelagem de ameaças (threat modeling) + workshop de cenários de dano para cada novo caso de uso e mudança relevante Avaliação de risco concluída; cenários de dano atualizados Produto + Segurança
MEDIR Avaliação de confiabilidade Bateria de avaliação pré-liberação deve passar limiares (conformidade com políticas, testes de vazamento de PII, taxa de evasão de salvaguardas) Relatório de avaliação; logs do job de CI; exceção assinada (se houver) Eng. de ML
GERENCIAR Tratamento e monitoramento de riscos Riscos de alta severidade devem ter mitigações ou aceitação documentada; monitoramento em produção com playbook de incidentes Registro de riscos; PRs de mitigação; painéis de monitoramento; runbooks de incidentes Produto + SRE

Escrevendo controles que engenheiros consigam executar

Um bom controle é testável. Compare:

  • Fraco: “Garanta que o modelo seja justo.”
  • Forte: “Antes da produção, avalie impacto dispar (disparate impact) entre grupos definidos; se a taxa de erro de qualquer grupo exceder a do melhor grupo em >X%, mitigação ou aceitação de risco é obrigatória.”

Os controles devem especificar:

  • Escopo: quais sistemas/modelos são cobertos?
  • Gatilho: novo modelo, novo conjunto de dados, mudança de prompt, mudança de ferramenta/plugin?
  • Procedimento: quais etapas devem ser executadas?
  • Critérios de aprovação/reprovação ou de decisão
  • Artefatos: o que deve ser armazenado e por quanto tempo?

Exemplo de “controle como código (control as code)” (portões de política em CI)

Muitas equipes implementam controles de MEDIR/GERENCIAR como portões de pipeline. Um exemplo simplificado em YAML:

ai_release_gates:
  system: "customer-support-llm"
  release: "2026-01-rc1"
  required_checks:
    - name: "pii_leakage_test"
      metric: "pii_leakage_rate"
      threshold: 0.001
      evidence: "reports/pii_leakage.json"
    - name: "prompt_injection_redteam"
      metric: "injection_success_rate"
      threshold: 0.02
      evidence: "reports/redteam_injection.md"
    - name: "policy_compliance"
      metric: "disallowed_content_rate"
      threshold: 0.0005
      evidence: "reports/policy_eval.csv"
  approvals:
    - role: "Model Owner"
    - role: "Risk Owner"
  exception_process:
    ticket_required: true
    max_duration_days: 30

Isso não substitui o julgamento, mas torna a governança repetível e reduz a “conformidade de papelada”.

Como o RMF de IA se conecta à documentação e às auditorias

O RMF de IA enfatiza documentação porque riscos em IA são difíceis de avaliar sem contexto. Artefatos comuns incluem:

  • Um documento de Cartões de Sistema descrevendo:
    • limites do sistema, dependências e fluxos do usuário,
    • pontos de supervisão humana,
    • monitoramento e comportamento de fallback,
    • limitações conhecidas e uso pretendido.
  • Um documento de Cartões de Modelo descrevendo:
    • dados de treinamento e abordagem de avaliação,
    • características de desempenho e limitações,
    • considerações de equidade, privacidade e segurança,
    • usos pretendidos e usos fora de escopo.
  • Um registro de riscos e pacote de avaliação (ver Avaliações de Risco)
  • Especificações de política de moderação para sistemas generativos (ver Política de Conteúdo e Moderação)
  • Processos de incidentes e práticas de divulgação (ver Relato de Incidentes e Transparência)

Esses artefatos tornam-se a “camada de evidência” que operacionaliza o RMF de IA.

Exemplos práticos por domínio

Exemplo 1: Modelo de decisão de crédito (alto impacto)

  • MAPEAR: Identificar classes protegidas (protected classes) e restrições regulatórias; definir requisitos de ação adversa (adverse action).
  • MEDIR: Avaliar:
    • calibração por grupo,
    • equal opportunity / disparidades de taxa de erro,
    • estabilidade sob mudanças econômicas,
    • qualidade de explicabilidade para razões de ação adversa.
  • GERENCIAR: Adicionar controles:
    • portões de aprovação para mudanças em features,
    • monitoramento de deriva com gatilhos de retreinamento,
    • revisão humana para decisões limítrofes,
    • controles de acesso rígidos para dados de treinamento e features.

Resultado típico do mapeamento de controles: o RMF de IA direciona controles de risco de modelo, enquanto estruturas corporativas cobrem controle de acesso, logging e gestão de mudanças.

Exemplo 2: Triagem por imagem médica (crítico para segurança operacional)

  • MAPEAR: Definir uso pretendido (suporte à triagem vs. diagnóstico), integração ao fluxo clínico e impacto de falhas.
  • MEDIR: Métricas clinicamente significativas (sensibilidade na especificidade exigida), desempenho por subgrupo, validação prospectiva.
  • GERENCIAR: Controles:
    • travamento de versão e rastreabilidade,
    • vigilância pós-mercado (post-market surveillance),
    • escalonamento rígido de incidentes para equipes de segurança clínica,
    • rotulagem clara e limitações na UI.

Aqui, o RMF de IA ajuda a garantir que o sistema de IA seja tratado como parte de um sistema de segurança, com controle de mudanças rigoroso.

Exemplo 3: Ferramenta de conteúdo generativo (risco de política + abuso)

  • MAPEAR: Casos de uso indevido (assédio, fraude, autoagressão, manipulação política), menores, restrições jurisdicionais.
  • MEDIR: Eficácia da moderação, taxa de evasão de salvaguardas, taxa de conclusões inseguras, falsos positivos afetando uso legítimo.
  • GERENCIAR: Controles:
    • moderação em camadas (entrada + saída + chamadas de ferramenta),
    • limites de taxa e detecção de abuso,
    • fluxos de escalonamento humano,
    • transparência e comunicações de incidentes.

Isso normalmente se integra fortemente com Política de Conteúdo e Moderação.

Armadilhas comuns ao implementar o RMF de IA

  • Tratar como checklist: o RMF é baseado em resultados; você precisa adaptá-lo ao contexto e ao impacto.
  • Medir apenas a acurácia do modelo: muitas falhas envolvem segurança operacional, viés, privacidade, segurança e integração de UX.
  • Ausência de gestão de mudanças: mudanças em prompts, integrações de ferramentas e atualizações de dados podem alterar materialmente o comportamento.
  • Riscos sem responsável: se todo risco é “problema da engenharia”, decisões críticas não serão tomadas nem documentadas.
  • Lacunas de evidência: se você não consegue reproduzir avaliações ou mostrar quem aprovou o quê e por quê, a governança se rompe.

Como começar: um plano leve de adoção

  1. Defina sua linha de base de governança (GOVERNAR)

    • Atribua responsáveis, crie uma política mínima de IA, defina autoridade para aceitação de risco.

  2. Comece com um perfil de alto valor

    • Escolha um sistema e crie um conjunto adaptado de resultados do RMF (“perfil”), em vez de tentar cobrir tudo.

  3. Construa uma pequena biblioteca de controles

    • 10–20 controles que cubram documentação, avaliação, portões de liberação, monitoramento e tratamento de incidentes.

  4. Instrumente a captura de evidências

    • Armazene relatórios de avaliação, cartões de modelo/sistema e aprovações em um local consistente.

  5. Automatize verificações recorrentes

    • Portões de CI para baterias de avaliação; alertas de monitoramento para deriva e sinais de segurança operacional.

  6. Itere

    • Expanda para sistemas adicionais, aumente a maturidade e refine limiares com base em incidentes observados e quase-incidentes.

Resumo

O RMF de IA do NIST oferece uma estrutura prática e amplamente adotada para gerenciar riscos de IA por meio de quatro funções: GOVERNAR, MAPEAR, MEDIR, GERENCIAR. A forma mais eficaz de implementá-lo é traduzir seus resultados em controles explícitos — com responsáveis, evidências e automação — e então integrar esses controles aos fluxos de trabalho existentes de engenharia e de governança, risco e conformidade (governance, risk and compliance, GRC).

Quando bem utilizado, o RMF de IA se torna mais do que um documento: ele vira a espinha dorsal de operações de IA responsável (responsible AI operations) repetíveis, auditáveis e em melhoria contínua.