ISO 42001, NIST AI RMF e o Regulamento da IA: ligar os papéis

A governação da IA pode combinar um sistema de gestão, um referencial de risco e obrigações legais. O desafio de engenharia é ligá-los sem fingir que são intermutáveis. Uma política, um relatório de avaliação e uma decisão de classificação jurídica podem suportar o mesmo serviço de IA, mas cada um responde a uma pergunta diferente.

A ISO/IEC 42001 estabelece a forma como uma organização gere a IA. O AI Risk Management Framework do NIST ajuda as equipas a investigar e gerir riscos no seu contexto. O Regulamento da Inteligência Artificial da UE (AI Act) estabelece deveres legais em função do sistema, da sua finalidade prevista e do papel de operador da organização.

Para um CTO, o resultado útil é uma única cadeia de governação passível de revisão: um caso de uso definido, responsáveis identificados, salvaguardas implementadas, evidências de testes, decisões de lançamento e monitorização. Os mapeamentos entre referenciais devem apontar para essa cadeia, preservando os requisitos que ainda exigem trabalho técnico, jurídico ou relacionado com a conformidade.

Perceba o que cada instrumento estabelece

ISO 42001: tornar a governação repetível

A ISO/IEC 42001 especifica requisitos para estabelecer, implementar, manter e melhorar continuamente um SGIA. Os seus requisitos de sistema de gestão abrangem o contexto da organização, a liderança, o planeamento, o suporte, a operação, a avaliação do desempenho e a melhoria.

Esta estrutura é importante quando várias equipas desenvolvem ou adquirem IA. Fornece uma base para decidir quem autoriza a implementação, como são realizadas as avaliações de impacto e de risco, como são geridas as dependências de fornecedores e como as falhas conduzem a ações corretivas.

A norma inclui também controlos de referência no Anexo A e orientações de implementação. A seleção dos controlos baseia-se no risco e exige uma justificação documentada; copiar o anexo para uma checklist não demonstra que o sistema de gestão funciona.

Um organismo de certificação independente pode avaliar o SGIA dentro do seu âmbito. A própria ISO não certifica organizações. A certificação dá garantias sobre esse sistema de gestão dentro do limite declarado, e não uma afirmação sem restrições de que todos os modelos ou resultados são seguros.

NIST AI RMF: investigar o risco real

O NIST AI RMF organiza o trabalho de risco em torno de Govern, Map, Measure e Manage. A função Govern é transversal; as funções não são simplesmente quatro fases sequenciais de um projeto.

As suas características de fiabilidade incluem validade e fiabilidade, segurança física, segurança e resiliência, responsabilização e transparência, explicabilidade e interpretabilidade, reforço da privacidade e equidade com gestão dos enviesamentos prejudiciais. Estas características podem implicar compromissos entre si. Explicações mais detalhadas, por exemplo, podem divulgar informação que precisa de proteção da privacidade.

As orientações do NIST ajudam as equipas a transformar objetivos gerais em perguntas e avaliações específicas de cada caso de uso. Também abordam a responsabilização; a governação não está reservada à ISO 42001. Não existe um sistema de certificação NIST AI RMF comparável à certificação ISO de sistemas de gestão. Uma avaliação externa pode apoiar a garantia, mas o seu âmbito e a sua metodologia têm de ser indicados.

O Regulamento da IA: determinar deveres, e não apenas riscos

O Regulamento da IA da UE regula determinadas práticas, sistemas de IA e modelos de IA de finalidade geral através de disposições diferentes. A aplicabilidade legal não é determinada apenas por uma pontuação técnica de risco. A finalidade prevista, o âmbito territorial, o papel de operador e as regras de classificação específicas são relevantes.

As obrigações de um prestador diferem das de um responsável pela implantação. Um modelo não é o mesmo que a aplicação que o incorpora, e chamar «agente» a um software não resolve a questão do seu papel jurídico nem da sua classificação.

Comece pelo âmbito e pela aplicabilidade legal

Mantenha um inventário de IA ao nível dos casos de uso operacionais, e não apenas dos nomes dos fornecedores. Um mesmo modelo subjacente pode suportar tanto um assistente interno de redação como uma ferramenta de triagem no recrutamento. Essas implementações têm pessoas afetadas, consequências, controlos e potenciais obrigações diferentes.

Para cada caso de uso, registe:

• A finalidade prevista, as decisões suportadas, as utilizações proibidas e os locais de implementação.
• O responsável pelo sistema, o responsável técnico, os utilizadores e as pessoas afetadas.
• Os fornecedores do modelo e da aplicação, os mecanismos de alojamento e as dependências.
• As fontes de dados, os resultados, as integrações e as ações permitidas.
• O papel de operador da organização e o raciocínio que o sustenta.
• A classificação, as obrigações aplicáveis, a data de revisão e as questões por resolver.

Uma organização de fora da UE pode, ainda assim, ficar abrangida pelo âmbito do Regulamento em determinadas circunstâncias. Inversamente, ter clientes na UE não justifica atribuir todas as obrigações possíveis a todos os produtos. Analise as condições territoriais e de papel efetivas.

Separe as práticas proibidas, os requisitos dos sistemas de risco elevado, os deveres de transparência específicos e as obrigações relativas aos modelos de IA de finalidade geral. Não são níveis intermutáveis de uma única escala de gravidade de engenharia. Um chatbot aparentemente de baixo impacto pode ter obrigações de transparência; um caso de uso de alto impacto exige uma avaliação jurídica mais detalhada.

Utilize o calendário de aplicação atual

A visão geral do Regulamento da IA da Comissão Europeia, consultada a 7 de outubro de 2026, apresenta o seguinte calendário:

Avalie separadamente as disposições alteradas, os regimes transitórios e o sistema concreto. Não adie deveres já aplicáveis só porque existe uma data posterior para o risco elevado. Mantenha a avaliação jurídica datada e utilize o nosso guia de preparação para o Regulamento da IA para o contexto do calendário e da avaliação de papéis.

Construa uma cadeia de evidências, e não três bibliotecas de documentos

Uma cadeia de governação prática começa no caso de uso e termina numa decisão revista:

Finalidade → impactos e riscos → requisitos → salvaguardas → avaliações → aprovação → monitorização.

Cada ligação precisa de detalhe suficiente para que alguém de fora da equipa de implementação a possa examinar. «Supervisão humana implementada» é insuficiente se o revisor não conseguir determinar quem pode intervir, o que essa pessoa vê e se a intervenção funciona.

Utilize um registo de requisitos que distinga o requisito de origem da sua implementação. Um esquema mínimo útil inclui a fonte e a versão, o âmbito, o texto ou a referência do requisito, a interpretação local, o responsável pelo controlo, as evidências associadas, o revisor, o estado e a lacuna residual.

Trate esta tabela como um auxiliar de implementação, e não como um mapa de equivalências oficial. As relações são de muitos para muitos: uma avaliação pode suportar vários requisitos, enquanto um requisito pode precisar de vários controlos e registos.

Antes de reutilizar evidências, verifique o seu âmbito, a data, a versão do sistema e a conclusão. Um teste a uma configuração de modelo não pode suportar automaticamente outra configuração. Uma política corporativa prova que existe uma regra documentada; são necessários registos operacionais para demonstrar a sua execução.

Utilize as funções do NIST para definir o trabalho de engenharia

As funções do NIST oferecem uma forma útil de organizar as questões de implementação dentro do SGIA. Devem produzir artefactos concretos, e não apenas campos de questionário preenchidos.

Govern: estabelecer a autoridade de decisão

Defina quem é responsável pelo sistema, quem revê de forma independente os riscos significativos e quem pode aprovar exceções ou interromper a implementação. Especifique os requisitos de competência e as vias de escalada. Ligue estas responsabilidades aos processos existentes de segurança, privacidade, compras e gestão de incidentes.

Um resultado útil é um procedimento de lançamento que identifique os revisores e as evidências exigidos. A aceitação do risco deve indicar o decisor, a fundamentação, as condições e o fator que desencadeia a revisão, em vez de registar apenas «aceite».

Map: descrever o contexto e as consequências

Documente o fluxo de trabalho antes de escolher as métricas. Identifique onde a IA influencia as decisões, quem sofre as consequências e o que acontece quando os resultados estão errados, indisponíveis ou são mal utilizados.

Inclua a utilização indevida previsível e as falhas de dependências. Para um agente que pode executar ações, mapeie as ferramentas, as credenciais, os dados acessíveis, os limites de aprovação e as vias de recuperação. Para IA de terceiros, registe o que o fornecedor controla e o que continua a ser da sua responsabilidade.

Measure: testar as afirmações que importam

Escolha avaliações ligadas aos riscos identificados. Consoante o caso de uso, podem incluir a exatidão nas tarefas, o desempenho por subgrupo, a robustez, a fuga de dados pessoais, a injeção de prompts, as ações não autorizadas e a compreensão por parte dos operadores.

Documente a proveniência dos conjuntos de dados, a representatividade, as condições de teste, as métricas, as limitações e os limiares de aceitação. Meça a aplicação completa sempre que possível: a recuperação de informação, os prompts, as permissões, as interfaces e o fluxo de trabalho humano podem alterar os resultados, mesmo quando o modelo subjacente se mantém constante.

Manage: implementar o tratamento e o acompanhamento

Traduza as constatações em salvaguardas, restrições, remediação ou numa decisão de não implementar. Exemplos incluem reduzir as permissões das ferramentas, exigir aprovação para ações com consequências, excluir utilizações não suportadas ou disponibilizar uma alternativa fiável sem IA.

Defina limiares de monitorização e procedimentos de resposta. Uma métrica sem responsável nem regra de resposta é apenas telemetria. Registe que eventos desencadeiam uma nova avaliação, incluindo atualizações do fornecedor, alterações nas fontes de dados, alargamento das utilizações e incidentes.

Torne a ISO 42001 auditável através de registos operacionais

Se a certificação for um objetivo, defina o limite do SGIA antes de preparar uma auditoria externa. O âmbito pode abranger um produto concreto, uma unidade de negócio ou um conjunto de atividades do ciclo de vida, mas deve descrever claramente as atividades e as interfaces incluídas. Um âmbito restrito não pode ser apresentado como garantia para toda a organização.

Realize uma análise de lacunas face aos requisitos do sistema de gestão e aos controlos aplicáveis. Estabeleça a política, os objetivos, os métodos de avaliação do risco e do impacto, a aplicabilidade documentada dos controlos, as responsabilidades e os procedimentos operacionais. Depois produza evidências de que estes processos funcionam efetivamente.

Registos úteis incluem avaliações concluídas, revisões de fornecedores, registos de formação, aprovações de lançamento, revisões da monitorização, ações corretivas, constatações da auditoria interna e decisões da revisão pela gestão. A auditoria interna e a revisão pela gestão são atividades distintas: uma avalia a conformidade e a eficácia; a outra apoia a avaliação e a orientação do sistema de gestão pela liderança.

Um processo de certificação independente inclui normalmente fases de avaliação da preparação e da implementação. Acorde o âmbito e as condições da auditoria com o organismo de certificação, em vez de tratar a certificação como a entrega de papelada. Mantenha a monitorização, a revisão interna e a melhoria após a certificação.

Nem um certificado nem uma avaliação segundo o RMF substituem uma avaliação da conformidade aplicável ao abrigo do Regulamento da IA. A via de conformidade depende do sistema e das disposições relevantes; nem todos os sistemas de risco elevado exigem a mesma via com intervenção de terceiros. Os requisitos de declaração, registo, marcação e notificação têm igualmente de ser verificados para o papel e o sistema em causa.

Exemplo prático: uma implementação de IA relacionada com o recrutamento

Pressupostos ilustrativos: um empregador da UE adquire uma aplicação que ordena os candidatos para a fase de seleção para entrevista. O fornecedor disponibiliza a aplicação, enquanto o empregador configura os critérios das vagas e utiliza as classificações. Os recrutadores tomam as decisões finais de contratação. Suponha que a análise jurídica identifica uma utilização de risco elevado no domínio do emprego, prevista no Anexo III, e identifica inicialmente o empregador como responsável pela implantação.

A questão não fica resolvida dizendo «um ser humano toma a decisão final». A ordenação pode influenciar significativamente quem é tido em consideração. A avaliação tem de examinar o fluxo de trabalho real, incluindo se os recrutadores ignoram habitualmente os candidatos abaixo de um determinado limiar.

Estabeleça o registo específico do sistema

O responsável técnico regista os campos de entrada, a informação sobre a lógica de ordenação disponibilizada pelo fornecedor, a versão da aplicação, a configuração, os utilizadores e os destinos das exportações. A área de compras solicita ao fornecedor as instruções, as limitações, as evidências de avaliação relevantes, as notificações de alterações e o apoio ao cumprimento das obrigações da organização.

A análise jurídica documenta os pressupostos de classificação e de papel, incluindo se uma futura modificação ou alteração de marca poderá alterar o papel. A análise de privacidade avalia separadamente o tratamento dos dados dos candidatos. A governação da IA não substitui a análise de proteção de dados.

Teste e implemente salvaguardas

Utilizando as funções Map e Measure do NIST, a equipa avalia cenários de recrutamento representativos, o comportamento perante dados em falta e as diferenças de desempenho entre grupos relevantes, quando tal for lícito e viável. Documenta a incerteza e as limitações da amostra, em vez de apresentar uma métrica de equidade como prova de que todos os enviesamentos prejudiciais desapareceram.

A supervisão humana inclui a formação dos recrutadores, limitações visíveis, uma via para rever as candidaturas excluídas e a possibilidade de suspender a ordenação. A equipa testa se os revisores compreendem os resultados e se os conseguem anular sem obstáculos operacionais.

Os controlos de segurança restringem o acesso aos registos dos candidatos e impedem exportações não aprovadas. A gestão de alterações exige uma nova avaliação quando mudam os critérios de ordenação, os modelos ou os mecanismos de tratamento do fornecedor.

Mantenha as três conclusões separadas

O registo do SGIA demonstra como funcionaram as avaliações, a atribuição de responsabilidades, a revisão do fornecedor e os processos de aprovação. O registo do RMF explica os riscos contextuais, os testes, o tratamento e a incerteza residual. O registo jurídico identifica os deveres aplicáveis ao responsável pela implantação, o calendário e o trabalho pendente.

Suponha que o fornecedor não disponibilizou instruções suficientes para uma supervisão fiável. O registo de lançamento deve mostrar essa lacuna, o seu responsável e a decisão de adiar ou restringir a implementação, e não um estado verde herdado do certificado ISO do empregador.

Escolha as prioridades e mantenha as evidências após o lançamento

Dê prioridade, em primeiro lugar, aos deveres legais aplicáveis e aos riscos operacionais inaceitáveis. A certificação ISO pode avançar em paralelo com a remediação, mas um objetivo de auditoria não deve afastar controlos urgentes.

Se as equipas não tiverem processos coerentes de atribuição de responsabilidades e de revisão, construa a base do SGIA. Se a governação existir, mas as avaliações dos sistemas forem fracas, utilize o RMF para melhorar a análise contextual e os testes. Se um cliente exigir certificação, confirme o âmbito esperado antes de orçamentar.

Evite pressupostos universais de custo ou de duração. O esforço depende do número de sistemas, da governação existente, das necessidades de avaliação, da visibilidade sobre os fornecedores e da remediação. O RMF está disponível gratuitamente, mas a implementação consome na mesma tempo das equipas; a certificação ISO acrescenta considerações relativas ao acesso à norma e à avaliação externa.

Após o lançamento, associe fatores de revisão aos artefactos. Uma atualização do modelo do fornecedor pode invalidar os resultados das avaliações; uma nova permissão de ação pode alterar o modelo de ameaças; um novo mercado pode exigir uma nova avaliação jurídica. Conserve as versões e decisões anteriores, para que os revisores possam reconstruir o que foi aprovado em cada momento.

Os erros comuns incluem tratar os mapeamentos como conformidade, recolher políticas sem evidências operacionais, aceitar as alegações dos fornecedores sem uma análise específica da implementação e registar o risco residual sem um responsável pela decisão. Outro é medir a qualidade do modelo ignorando as permissões da aplicação e o comportamento humano.

A Secani pode apoiar o fluxo de trabalho de evidências ligando requisitos, controlos, material de origem, responsáveis, tarefas e decisões revistas. Comece com um âmbito definido, associe as evidências àquilo que suportam e transforme o material em falta ou desatualizado em trabalho atribuído. Trate as sugestões assistidas por IA como rascunhos: uma pessoa deve rever os mapeamentos e as conclusões, preservando as fontes e o raciocínio da aprovação. Isto mantém a base da governação examinável, sem substituir o juízo técnico ou jurídico.

Perguntas que afetam a implementação

Os controlos de segurança existentes podem ser reutilizados?

Sim, quando a sua implementação e as suas evidências abrangem a implementação de IA. O controlo de acessos, a resposta a incidentes e a gestão de fornecedores contribuem muitas vezes. Por si sós, não respondem a questões sobre enviesamentos prejudiciais, finalidade prevista ou supervisão humana eficaz.

E se um fornecedor não divulgar o funcionamento interno do modelo?

Registe a limitação de visibilidade. Procure evidências proporcionais ao caso de uso, avalie a aplicação implementada e determine se são necessárias garantias contratuais, restrições ou fornecedores alternativos. A falta de visibilidade não é automaticamente aceitável só porque o serviço está disponível comercialmente.

O que deve a equipa fazer primeiro?

Escolha um caso de uso com consequências relevantes e reúna o seu responsável, a finalidade, a avaliação do papel, o registo de risco, as salvaguardas, os testes e a aprovação. Reveja as lacunas à luz dos três instrumentos. Esse exercício delimitado revela se a organização precisa de melhor governação, de melhores evidências técnicas ou de resolver questões jurídicas pendentes antes de expandir.