GOVERN GOVERN (Governar)

GOVERN.1.1
Requisitos legais e regulatórios envolvendo IA são compreendidos e documentados. É a base de tudo: sem saber quais leis e regulações se aplicam ao seu sistema de IA (LGPD, EU AI Act, setoriais), não dá para saber o que precisa ser feito nem quando.
Básico
GOVERN.1.2
As características de IA confiável estão integradas às políticas e práticas da organização. Confiabilidade não é um adjetivo solto — precisa virar critério objetivo dentro das políticas (segurança, privacidade, viés, explicabilidade) para orientar decisões reais.
Intermediário
GOVERN.1.3
Existem processos para determinar o nível de gestão de risco necessário, conforme a tolerância a risco da organização. Nem todo sistema de IA merece o mesmo nível de rigor. Um chatbot de FAQ e um sistema de crédito não podem ter o mesmo processo de gestão de risco.
Intermediário
GOVERN.1.4
O processo de gestão de risco de IA é estabelecido por políticas transparentes, baseadas em prioridades organizacionais. Um processo de risco que não é transparente vira caixa-preta dentro da própria organização — ninguém sabe por que uma decisão de risco foi tomada.
Intermediário
GOVERN.1.5
Monitoramento contínuo e revisão periódica do processo de gestão de risco são planejados, com papéis e frequência definidos. Risco de IA muda com o tempo (novos dados, novos usos, novos ataques). Sem revisão periódica planejada, o controle vira uma foto antiga de um problema que já mudou.
Intermediário
GOVERN.1.6
Existe mecanismo para inventariar os sistemas de IA da organização, com recursos alocados conforme a prioridade de risco. Não dá para gerir risco de sistemas de IA que ninguém sabe que existem. O inventário é o pré-requisito de qualquer programa de governança de IA.
Básico
GOVERN.1.7
Existem processos para descomissionar e desativar sistemas de IA com segurança, sem aumentar risco. Desligar um sistema de IA sem processo pode ser tão arriscado quanto ligá-lo mal — dados residuais, dependências quebradas, usuários sem alternativa.
Avançado
GOVERN.2.1
Papéis, responsabilidades e linhas de comunicação sobre risco de IA são documentados e claros para todos os times. Se ninguém sabe quem é responsável pelo risco de um sistema de IA específico, o risco não é gerido por ninguém — cai no vão entre times.
Básico
GOVERN.2.2
O pessoal e os parceiros recebem treinamento em gestão de risco de IA compatível com suas funções. Política escrita que ninguém entende não muda comportamento. Treinamento é o que transforma a política em prática do dia a dia.
Intermediário
GOVERN.2.3
A liderança executiva assume responsabilidade formal pelas decisões de risco associadas a sistemas de IA. Sem responsabilização formal da liderança, decisões de risco de IA ficam só no nível técnico, e questões estratégicas (reputação, regulação, ética) passam despercebidas.
Intermediário
GOVERN.3.1
Decisões sobre mapeamento, medição e gestão de risco de IA são informadas por uma equipe diversa (disciplinas, experiência, formação). Equipes homogêneas tendem a não enxergar riscos e vieses que afetam grupos diferentes do seu próprio — diversidade na decisão reduz pontos cegos reais.
Avançado
GOVERN.3.2
Políticas definem e diferenciam papéis e responsabilidades para configurações humano-IA e supervisão humana. Definir explicitamente o que é decisão humana e o que é decisão da IA evita a ambiguidade perigosa de "ninguém sabe quem decidiu isso".
Intermediário
GOVERN.4.1
Políticas organizacionais fomentam uma mentalidade de segurança e pensamento crítico no design e desenvolvimento de IA. Uma cultura que só pensa em segurança depois que o sistema já está em produção sempre chega tarde — o design é o momento mais barato de prevenir.
Intermediário
GOVERN.4.2
Os times documentam os riscos e impactos potenciais da tecnologia de IA que projetam, desenvolvem ou usam, e comunicam isso amplamente. Risco não documentado é conhecimento que morre com a pessoa que o percebeu. Documentar e comunicar espalha esse conhecimento pela organização.
Intermediário
GOVERN.4.3
Práticas organizacionais habilitam testes de IA, identificação de incidentes e compartilhamento de informação sobre eles. Sem espaço seguro para testar e reportar falhas, incidentes de IA só aparecem quando já causaram dano visível — tarde demais para agir preventivamente.
Intermediário
GOVERN.5.1
Políticas coletam, consideram e priorizam feedback externo sobre impactos individuais e sociais potenciais do sistema de IA. Quem constrói o sistema tem um ponto de vista limitado sobre seus impactos. Ouvir quem é afetado de fora revela riscos que a equipe interna não veria.
Avançado
GOVERN.5.2
Existem mecanismos para incorporar regularmente o feedback de atores relevantes no design e na implementação do sistema. Coletar feedback e nunca usá-lo é teatro de governança. O mecanismo de incorporação é o que fecha o ciclo e gera mudança real.
Avançado
GOVERN.6.1
Políticas endereçam riscos de IA associados a terceiros, incluindo violação de propriedade intelectual. Um sistema de IA construído sobre dados ou modelos de terceiros herda os riscos deles — inclusive risco jurídico de propriedade intelectual.
Intermediário
GOVERN.6.2
Existem processos de contingência para falhas ou incidentes em dados ou sistemas de IA de terceiros de alto risco. Quando um fornecedor de dados ou modelo de IA falha, sem plano de contingência a falha se propaga direto para o seu sistema e para os seus usuários.
Avançado

MAP MAP (Mapear)

MAP.1.1
Propósitos, usos benéficos, leis aplicáveis e contexto de implantação do sistema de IA são compreendidos e documentados. Sem entender para que o sistema serve de verdade e onde será usado, toda avaliação de risco que vem depois parte de uma suposição errada.
Básico
MAP.1.2
Atores interdisciplinares que participam da definição de contexto refletem diversidade demográfica e de experiência. A mesma lógica do GOVERN.3.1, aplicada à etapa de mapeamento: equipe pouco diversa mapeia contexto de forma incompleta.
Avançado
MAP.1.3
A missão da organização e as metas relevantes para a tecnologia de IA são compreendidas e documentadas. Um sistema de IA desalinhado com a missão da organização tende a virar projeto isolado, sem apoio nem recursos quando o risco aparece.
Básico
MAP.1.4
O valor de negócio ou o contexto de uso do sistema de IA está claramente definido ou reavaliado. Se o valor de negócio não está claro, fica difícil justificar investimento em mitigação de risco — e fácil de o projeto ser abandonado no primeiro problema.
Intermediário
MAP.1.5
As tolerâncias a risco da organização são determinadas e documentadas. Tolerância a risco não declarada leva a decisões inconsistentes: o mesmo tipo de risco é aceito num projeto e rejeitado noutro, sem critério.
Intermediário
MAP.1.6
Requisitos do sistema são levantados junto aos atores relevantes, e as decisões de design consideram implicações sociotécnicas. Requisito técnico que ignora implicação social (ex.: "o sistema deve respeitar a privacidade dos usuários") é requisito incompleto — a parte sociotécnica é parte do sistema.
Intermediário
MAP.2.1
As tarefas específicas e os métodos usados pelo sistema (ex.: classificadores, modelos generativos) são definidos. Chamar tudo genericamente de "IA" esconde diferenças de risco enormes — um classificador simples e um modelo generativo têm perfis de risco muito diferentes.
Básico
MAP.2.2
Os limites de conhecimento do sistema e como a saída é usada e supervisionada por humanos são documentados. Um sistema que ninguém sabe onde erra (limites de conhecimento) é usado por humanos que confiam demais nele justamente nos pontos mais frágeis.
Intermediário
MAP.2.3
Integridade científica e considerações de teste/avaliação/verificação/validação (TEVV) são identificadas e documentadas. Sem rigor científico na forma como o sistema foi testado e validado, os resultados de qualquer avaliação posterior não são confiáveis.
Avançado
MAP.3.1
Benefícios potenciais da funcionalidade e do desempenho pretendidos do sistema de IA são examinados e documentados. Documentar o benefício esperado (não só o risco) evita decisões de mitigação desproporcionais que matam o valor do projeto sem necessidade.
Intermediário
MAP.3.2
Custos potenciais, incluindo não monetários, decorrentes de erros ou falhas de confiabilidade do sistema são examinados e documentados. Custo não é só financeiro — inclui dano reputacional, discriminação, erosão de confiança. Ignorar custos não monetários subestima o risco real.
Intermediário
MAP.3.3
O escopo de aplicação pretendido é especificado com base na capacidade e no contexto do sistema. Um sistema usado fora do escopo para o qual foi validado é, na prática, um sistema não testado — o escopo delimita onde a confiança é válida.
Intermediário
MAP.3.4
Processos para avaliar a proficiência de operadores com o sistema de IA são definidos e avaliados. Um operador mal treinado pode neutralizar qualquer controle técnico bem feito, usando o sistema de um jeito que ele nunca foi pensado para suportar.
Avançado
MAP.3.5
Processos de supervisão humana são definidos e avaliados, de acordo com as políticas da função GOVERN. Supervisão humana genérica ("tem um humano no loop") não é suficiente — o processo de supervisão precisa ser desenhado e avaliado como qualquer outro controle.
Intermediário
MAP.4.1
Abordagens para mapear riscos tecnológicos e legais dos componentes do sistema, incluindo os de terceiros, são seguidas e documentadas. Risco legal de um componente de terceiro (dado ou modelo) vira risco legal do seu sistema no momento em que você o incorpora.
Intermediário
MAP.4.2
Controles internos de risco para os componentes do sistema de IA, incluindo tecnologia de terceiros, são identificados e documentados. Sem controle interno sobre componentes de terceiros, você depende inteiramente da governança de risco de outra empresa, que você não controla.
Avançado
MAP.5.1
Probabilidade e magnitude de cada impacto identificado (benéfico ou prejudicial) são identificadas e documentadas. Impacto raro mas catastrófico e impacto comum mas leve exigem respostas diferentes — sem estimar probabilidade e magnitude juntas, a priorização fica arbitrária.
Intermediário
MAP.5.2
Práticas e pessoal para engajamento regular com atores relevantes e integração de feedback sobre impactos estão em vigor. Impacto muda com o tempo e com o contexto de uso real. Engajamento pontual (uma vez, no lançamento) não captura impactos que só aparecem depois.
Avançado

MEASURE MEASURE (Medir)

MEASURE.1.1
Abordagens e métricas de medição dos riscos de IA identificados no MAP são selecionadas, priorizando os riscos mais significativos. Medir tudo com o mesmo nível de rigor desperdiça esforço. Priorizar pelos riscos mais significativos concentra o esforço de medição onde importa.
Intermediário
MEASURE.1.2
A adequação das métricas de IA e a eficácia dos controles existentes são avaliadas e atualizadas regularmente. Uma métrica que fazia sentido no lançamento pode ficar obsoleta conforme o sistema, os dados ou o contexto de uso mudam.
Intermediário
MEASURE.1.3
Especialistas internos independentes (que não desenvolveram o sistema) ou avaliadores externos participam das avaliações regulares. Quem desenvolveu o sistema tem interesse (mesmo que inconsciente) em vê-lo bem avaliado. Avaliação independente reduz esse viés de confirmação.
Avançado
MEASURE.2.1
Conjuntos de teste, métricas e ferramentas usados no processo de TEVV são documentados. Sem documentar como o sistema foi testado, ninguém consegue reproduzir a avaliação nem confiar nela — é a diferença entre teste e alegação.
Básico
MEASURE.2.2
Avaliações que envolvem sujeitos humanos atendem aos requisitos aplicáveis e são representativas da população relevante. Avaliações mal desenhadas com pessoas reais podem causar dano direto aos participantes e ainda produzir resultado que não representa o público real do sistema.
Avançado
MEASURE.2.3
O desempenho do sistema é medido qualitativa ou quantitativamente em condições próximas às de uso real. Testar em laboratório, em condições ideais, não prova nada sobre como o sistema vai se comportar no mundo real, com dados reais e ruidosos.
Intermediário
MEASURE.2.4
A funcionalidade e o comportamento do sistema de IA e de seus componentes são monitorados quando em produção. Um sistema que passou em todos os testes antes do lançamento ainda pode degradar (data drift, uso fora do esperado) depois que está em produção.
Básico
MEASURE.2.5
O sistema a ser implantado é demonstrado como válido e confiável, com as limitações de generalização documentadas. Validade e confiabilidade não são absolutas — só valem dentro das condições em que foram testadas. Fora disso, é aposta, não garantia.
Intermediário
MEASURE.2.6
O sistema de IA é avaliado regularmente quanto a riscos de segurança (safety) identificados no MAP. Risco de segurança física ou operacional de um sistema de IA (ex.: um sistema que controla um processo físico) precisa de avaliação contínua, não só no lançamento.
Intermediário
MEASURE.2.7
Segurança (security) e resiliência do sistema são avaliadas e documentadas. Um sistema resiliente a falhas técnicas normais pode não resistir a um ataque deliberado — segurança (security) e robustez são avaliações distintas e complementares.
Intermediário
MEASURE.2.8
Riscos associados a transparência e prestação de contas são examinados e documentados. Um sistema pode ser tecnicamente seguro e ainda assim opaco demais para que alguém seja responsabilizado quando algo dá errado.
Intermediário
MEASURE.2.9
O modelo é explicado e validado, e a saída do sistema é interpretada em seu contexto de uso. "A IA decidiu" não é explicação suficiente para ninguém — nem para o usuário afetado, nem para quem precisa auditar a decisão depois.
Intermediário
MEASURE.2.10
O risco de privacidade do sistema de IA é examinado e documentado. Sistemas de IA processam muito mais dado do que uma pessoa processaria manualmente — o risco de privacidade cresce com a escala, não só com a sensibilidade do dado.
Intermediário
MEASURE.2.11
Equidade e viés do sistema são avaliados e os resultados documentados. Viés não avaliado não desaparece — só fica invisível até que alguém de fora (ou um processo judicial) o encontre primeiro.
Intermediário
MEASURE.2.12
O impacto ambiental e a sustentabilidade das atividades de treinamento e manutenção do modelo são avaliados. Treinar modelos grandes tem custo ambiental real (energia, água de resfriamento) — cada vez mais relevante em relatórios de sustentabilidade corporativa.
Avançado
MEASURE.2.13
A efetividade das próprias métricas e processos de TEVV usados na função MEASURE é avaliada e documentada. Medir errado dá falsa sensação de segurança — por isso a própria forma de medir precisa, periodicamente, ser questionada e validada.
Avançado
MEASURE.3.1
Abordagens, pessoal e documentação para identificar e rastrear riscos de IA existentes e emergentes estão em vigor. Risco de IA não é estático — surgem riscos novos conforme o sistema é usado de formas que ninguém previu no design original.
Intermediário
MEASURE.3.2
Abordagens de rastreamento são consideradas mesmo para cenários em que as técnicas de medição disponíveis são limitadas. Nem todo risco tem métrica pronta (ex.: impacto sociocultural de longo prazo). Ignorar esses riscos só porque são difíceis de medir é um erro comum.
Avançado
MEASURE.3.3
Processos de feedback para usuários finais reportarem problemas e contestarem resultados do sistema estão estabelecidos. Sem canal de contestação, o usuário afetado por uma decisão errada do sistema não tem como reportar isso nem como pedir revisão.
Intermediário
MEASURE.4.1
As abordagens de medição de risco são conectadas ao contexto real de implantação do sistema. Medir fora do contexto real de uso produz números que parecem bons no relatório e não significam nada na prática.
Intermediário
MEASURE.4.2
Os resultados de medição sobre a confiabilidade do sistema são informados por consulta a especialistas de domínio. Quem mede tecnicamente nem sempre entende o domínio de aplicação (ex.: medicina, crédito) — o especialista de domínio valida se a métrica faz sentido de verdade.
Avançado
MEASURE.4.3
Melhorias ou pioras mensuráveis são identificadas a partir de consultas a atores relevantes e dados reais de uso. Sem comparar consultas e dados de campo ao longo do tempo, não dá para saber se o sistema está melhorando, piorando ou só mudando.
Avançado

MANAGE MANAGE (Gerenciar)

MANAGE.1.1
É determinado se o sistema de IA atinge seus objetivos pretendidos e se o desenvolvimento/implantação deve prosseguir. Continuar desenvolvendo ou operando um sistema que não atinge seu objetivo original é desperdício de recurso e prorrogação de risco desnecessária.
Intermediário
MANAGE.1.2
O tratamento dos riscos documentados é priorizado por impacto, probabilidade e recursos disponíveis. Recurso de mitigação é sempre limitado — priorizar por impacto e probabilidade garante que o esforço vá para onde reduz mais risco real.
Intermediário
MANAGE.1.3
Respostas aos riscos de alta prioridade são desenvolvidas, planejadas e documentadas (mitigar, transferir, evitar ou aceitar). Identificar um risco sem desenvolver uma resposta formal para ele é o mesmo que não ter identificado — o risco continua lá, sem plano.
Intermediário
MANAGE.1.4
Os riscos residuais negativos (a soma dos riscos não mitigados) são documentados. Nenhum controle zera risco. Documentar o que sobra (residual) é o que permite decidir conscientemente se aquele nível de risco é aceitável.
Intermediário
MANAGE.2.1
Os recursos necessários para gerir o risco de IA e alternativas viáveis sem IA são considerados. Às vezes a resposta certa ao risco de um sistema de IA é não usar IA. Considerar essa alternativa evita forçar uma solução que carrega risco desnecessário.
Avançado
MANAGE.2.2
Existem mecanismos para sustentar o valor dos sistemas de IA já implantados ao longo do tempo. Um sistema de IA se degrada com o tempo (dados mudam, o mundo muda) — sustentar valor exige manutenção ativa, não só o lançamento inicial.
Intermediário
MANAGE.2.3
Existem procedimentos para responder e se recuperar quando um risco previamente desconhecido é identificado. Risco desconhecido, por definição, não estava no plano original. O procedimento de resposta é o que evita improviso quando ele aparece.
Intermediário
MANAGE.2.4
Existem mecanismos, com responsabilidades definidas, para suspender ou desativar sistemas de IA com desempenho inconsistente. Todo sistema de IA em produção precisa de um "botão de desligar" real e testado — sem isso, um problema identificado continua causando dano enquanto se decide o que fazer.
Básico
MANAGE.3.1
Riscos e benefícios vindos de recursos de terceiros são monitorados regularmente, com controles aplicados e documentados. Um fornecedor de dado ou modelo de IA pode mudar de comportamento (qualidade, política, disponibilidade) sem aviso — monitorar continuamente é o que detecta isso a tempo.
Intermediário
MANAGE.3.2
Modelos pré-treinados usados no desenvolvimento são monitorados como parte da manutenção regular do sistema. Modelos pré-treinados de terceiros recebem atualizações que você não controla — sem monitoramento, uma mudança upstream pode quebrar seu sistema silenciosamente.
Avançado
MANAGE.4.1
Planos de monitoramento pós-implantação incluem mecanismos de apelação, override, descomissionamento e resposta a incidentes. Sem mecanismo de apelação, quem é prejudicado por uma decisão errada do sistema não tem para onde recorrer — isso é tanto um risco ético quanto legal.
Intermediário
MANAGE.4.2
Atividades mensuráveis de melhoria contínua são integradas às atualizações do sistema, com engajamento regular de atores relevantes. Melhoria contínua sem engajamento externo tende a otimizar só pelas métricas que a própria equipe já enxerga, perdendo problemas que só quem usa o sistema percebe.
Avançado
MANAGE.4.3
Incidentes e erros são comunicados aos atores relevantes, com processos de rastreamento, resposta e recuperação seguidos e documentados. Comunicar incidentes de IA (mesmo os pequenos) constrói o histórico que permite identificar padrões — sem isso, cada incidente parece um caso isolado.
Básico

NIST AI RMF 1.0 Governança de IA

GOVERN GOVERN (Governar)

MAP MAP (Mapear)

MEASURE MEASURE (Medir)

MANAGE MANAGE (Gerenciar)