Governança de IA na Engenharia: ISO 42001, riscos e responsabilidade técnica

Governança de IA na engenharia: ISO/IEC 42001, NIST AI RMF, riscos, papéis, dados, validação, fornecedores, incidentes e responsabilidade técnica.

Confira!

Governança de IA na engenharia é o conjunto de políticas, responsabilidades, processos, controles e evidências usados para assegurar que sistemas de inteligência artificial sejam selecionados, desenvolvidos, integrados, utilizados e monitorados de forma compatível com o risco técnico e organizacional. Em empresas de engenharia, a governança precisa conectar o ciclo de vida da IA ao ciclo de vida de projetos, documentos e ativos.

A ISO/IEC 42001:2023 fornece um dos principais referenciais para essa estrutura. A norma especifica requisitos para estabelecer, implementar, manter e melhorar continuamente um Artificial Intelligence Management System — AIMS. Seu foco não é ensinar um algoritmo específico, mas criar um sistema de gestão capaz de definir políticas, papéis, avaliação de riscos, controles, monitoramento e melhoria para organizações que desenvolvem ou utilizam IA.

Esse enquadramento é especialmente relevante à engenharia porque uma aplicação de IA pode atuar em atividades com consequências muito diferentes. Resumir uma reunião interna possui risco distinto de classificar um requisito, sugerir uma alteração de projeto, apoiar um aceite técnico ou executar uma ação sobre um sistema. Governança significa reconhecer essa diferença e ajustar autonomia, validação, registro e responsabilidade ao impacto potencial.

O pilar de Inteligência Artificial na Engenharia apresenta as tecnologias ao longo do ciclo de vida. Este artigo aprofunda especificamente a camada de governança: como estruturar papéis, inventário de sistemas, avaliação de impacto, dados, fornecedores, validação, incidentes, monitoramento e melhoria contínua.

O que a ISO/IEC 42001 organiza

A ISO/IEC 42001 é uma norma de sistema de gestão. Assim como outros management system standards, ela estabelece uma estrutura organizacional para transformar princípios em processos repetíveis. Dentro do cluster, o pilar de Inteligência Artificial na Engenharia mantém a visão ampla das tecnologias, enquanto esta peça aprofunda o sistema de governança.

O objetivo é permitir que a organização trate IA como capacidade governada, e não como conjunto de experimentos isolados.

A estrutura pode ser compreendida pela lógica Plan-Do-Check-Act:

Na prática, isso significa definir quem decide, quais aplicações existem, quais riscos são relevantes, quais controles devem ser aplicados e como a organização demonstra que esses controles funcionam.

$1

O sistema precisa partir do contexto: objetivos, obrigações, partes interessadas, tipos de IA, dados utilizados e impacto potencial.

Uma empresa que usa IA apenas em marketing possui exposição diferente de uma empresa que conecta agentes a modelos BIM, documentos controlados ou dados operacionais.

$1

Governança exige uma política aprovada, com responsabilidades e princípios claros.

A política deve dizer, por exemplo, quais classes de uso são permitidas, quais exigem aprovação, quais dados não podem ser enviados a serviços externos e como aplicações de maior risco serão validadas.

$1

O planejamento conecta risco e oportunidade.

A organização precisa identificar riscos de erro, segurança, privacidade, viés, propriedade intelectual, continuidade, dependência de fornecedor e impacto sobre processos técnicos.

$1

Inclui competência, conscientização, comunicação e informação documentada.

Em engenharia, isso significa que usuários precisam saber não apenas “usar IA”, mas interpretar limites, validar resultados e reconhecer quando uma tarefa não deveria ser automatizada.

$1

A operação transforma políticas em controles concretos sobre dados, modelos, fornecedores, prompts, integrações, permissões e workflows.

$1

Métricas, auditorias e análise crítica mostram se o sistema continua adequado.

$1

Incidentes, não conformidades, mudanças de tecnologia e novos riscos alimentam correção e melhoria contínua.

Governança de IA não é apenas compliance

Reduzir governança a uma lista de proibições é um erro.

O objetivo não é impedir inovação, mas criar condições para que aplicações úteis possam ser escaladas com controle.

Uma boa governança responde perguntas práticas:

• Quem pode aprovar um novo caso de uso?
• Quais dados podem ser utilizados?
• Como a solução é testada?
• Quem valida a saída?
• Como mudança de modelo é tratada?
• O que precisa ser registrado?
• Como incidentes são reportados?
• Quem pode suspender uma aplicação?
• Como fornecedores são avaliados?
• Como o sistema é desativado?

Essas perguntas conectam gestão a engenharia.

$1

Nenhuma organização consegue governar o que não conhece.

O primeiro ativo de governança é um inventário de IA.

Cada registro pode conter:

Campo	Exemplo
caso de uso	consulta a acervo técnico
processo	Design Review
responsável	gerente de engenharia
tecnologia	LLM + RAG
dados	projetos e especificações
criticidade	moderada
fornecedor	plataforma X
validação	golden set + revisão técnica
status	piloto / produção
última revisão	data

O inventário também deve registrar aplicações individuais relevantes, integrações e agentes.

$1

Quando profissionais usam ferramentas sem registro, cria-se shadow AI.

O problema não é apenas segurança. Uma equipe pode passar a depender de uma ferramenta, prompt ou processo que não está documentado e que ninguém consegue auditar.

Política clara e alternativas aprovadas ajudam a reduzir esse comportamento.

$1

Governança precisa ser proporcional.

Uma classificação prática pode usar quatro níveis.

Nível	Exemplo	Controle
baixo	brainstorming ou resumo interno	orientação e revisão amostral
moderado	minuta de relatório	revisão integral
alto	requisito, projeto ou análise técnica	validação independente
crítico	ação sobre sistema ou decisão de segurança	barreiras, aprovação explícita e fail-safe

A classificação deve considerar consequência, reversibilidade, detectabilidade e alcance do erro.

$1

O que acontece se a saída estiver errada?

$1

A ação pode ser desfeita sem impacto relevante?

$1

O erro tende a ser identificado antes de gerar consequência?

$1

Quantos projetos, ativos ou usuários podem ser afetados?

Esses fatores ajudam a definir autonomia admissível.

$1

A ISO/IEC 23894 complementa a governança ao orientar gestão de riscos relacionados à IA.

A lógica de risco precisa acompanhar todo o ciclo: identificação, análise, avaliação, tratamento, monitoramento e comunicação.

Em engenharia, riscos de IA devem ser integrados a práticas já existentes de risco de projeto e operação.

Uma matriz pode incluir probabilidade e consequência, mas também incerteza e dificuldade de detecção.

$1

O NIST AI Risk Management Framework organiza o trabalho em quatro funções:

• Govern: cultura, políticas, papéis e accountability;
• Map: contexto, finalidade, usuários e impactos;
• Measure: métricas, testes, avaliação e monitoramento;
• Manage: priorização, tratamento, resposta e melhoria.

Essa estrutura é particularmente útil para transformar princípios em atividades operacionais.

O perfil NIST AI 600-1 amplia o framework para riscos de IA generativa, incluindo confabulação, segurança, proveniência e conteúdo.

$1

Governança falha quando “todos são responsáveis” e ninguém possui autoridade clara.

$1

Define direção, apetite de risco e recursos.

$1

Mantém política, inventário, processo de aprovação e métricas.

$1

Define requisitos técnicos, casos de teste e validação do uso.

$1

Mantêm integrações, identidades, ambientes e observabilidade.

$1

Avalia acesso, dados, fornecedores, incidentes e superfície de ataque.

$1

Avaliam contratos, propriedade intelectual, retenção, dados pessoais e obrigações.

$1

Opera dentro das regras, valida saídas e reporta problemas.

$1

Em casos de maior criticidade, autoridade técnica independente pode aprovar ou rejeitar utilização.

A Technical Authority em Engenharia é uma referência útil para estruturar independência decisória.

$1

A expressão human-in-the-loop pode esconder controles fracos.

Revisão humana só funciona quando o revisor possui competência, tempo, autoridade e acesso à evidência necessária.

Se o usuário recebe uma resposta de IA sem fonte e precisa aprovar dezenas de itens em pouco tempo, a presença humana é formal, não efetiva.

O controle deve especificar:

• o que revisar;
• contra qual fonte;
• qual critério usar;
• quando rejeitar;
• o que registrar;
• quando escalar.

Quanto maior o risco, maior deve ser a independência.

$1

Dados são parte do sistema de IA.

Em engenharia, governança precisa cobrir documentos, modelos, sensores, imagens, históricos e bases estruturadas.

$1

Dados devem ser suficientemente corretos, completos e representativos.

$1

É necessário saber de onde vieram.

$1

Documentos substituídos não devem receber o mesmo peso de documentos vigentes.

$1

Acesso precisa seguir classificação e função.

$1

Definir por quanto tempo dados, prompts e logs serão mantidos.

$1

Contratos e políticas precisam esclarecer se dados podem ser usados pelo fornecedor para treinamento.

Quando a aplicação utiliza documentação técnica, a Gestão BIM e Informação de Engenharia fornece um elo natural entre governança documental e governança de IA.

$1

Prompts de sistema, instruções, parâmetros e ferramentas conectadas podem alterar significativamente o comportamento.

Em aplicações críticas, esses elementos precisam de controle de configuração.

Um registro deve incluir versão, autor, data, objetivo, testes associados e aprovação.

Mudança aparentemente pequena pode alterar resultado. Por isso, alterações relevantes devem passar por teste de regressão.

$1

Agentes aumentam risco porque podem executar ações.

Uma aplicação que apenas responde perguntas possui impacto informacional. Um agente que altera um modelo, envia documento, modifica registro ou executa código possui impacto operacional.

Controles adicionais incluem:

• menor privilégio;
• aprovação antes de ação crítica;
• allowlist de ferramentas;
• logs de chamadas;
• limitação de escopo;
• sandbox;
• timeout;
• reversão;
• kill switch.

O satélite sobre Agentes de IA na Engenharia aprofunda essa arquitetura.

$1

Grande parte das empresas utilizará modelos e plataformas de terceiros.

A governança precisa avaliar:

$1

Onde são processados e armazenados?

$1

Quanto tempo permanecem?

$1

São utilizados para melhorar modelos do fornecedor?

$1

Quais terceiros recebem os dados?

$1

O que acontece se o serviço mudar ou encerrar?

$1

É possível migrar prompts, embeddings, corpus e logs?

$1

Quais controles, certificações e mecanismos de acesso existem?

$1

Atualizações são notificadas? É possível fixar versão?

Contrato deve refletir essas respostas.

Validação antes da produção

Nenhum caso de uso de maior relevância deveria entrar em produção sem teste.

A validação pode incluir:

1. conjunto de referência;
2. métricas;
3. casos de borda;
4. tentativa de abuso;
5. avaliação de segurança;
6. teste de acesso;
7. teste de ausência de resposta;
8. revisão técnica.

Para IA em Projetos de Engenharia, isso significa testar requisitos, documentos, exceções e fontes antes de integrar ao workflow.

Quando a saída influencia projeto ou aceite, Design Review pode funcionar como barreira independente.

$1

Validação inicial não encerra o controle.

Modelos, dados, usuários e processos mudam.

Métricas operacionais podem incluir:

• taxa de erro;
• respostas sem fonte;
• incidentes;
• rejeições humanas;
• drift;
• latência;
• custo;
• uso por caso;
• exceções;
• ações bloqueadas.

Monitoramento ajuda a detectar perda de desempenho.

$1

Mudança de modelo, prompt, corpus, integração ou política pode alterar risco.

A organização precisa definir o que exige revalidação.

Uma matriz simples pode classificar mudanças como menores, significativas ou críticas.

$1

Ajuste de interface sem impacto no comportamento.

$1

Mudança de prompt ou corpus.

$1

Mudança de modelo, ferramenta ou autonomia.

Quanto maior a mudança, maior o reteste.

$1

Incidente não é apenas vazamento.

Pode ser:

• resposta incorreta com impacto;
• decisão baseada em documento errado;
• acesso indevido;
• ação não autorizada;
• alteração de modelo sem teste;
• geração de conteúdo incompatível;
• perda de rastreabilidade.

O processo de incidente deve definir detecção, contenção, investigação, correção e lições aprendidas.

$1

Uma auditoria precisa reconstruir o que ocorreu.

Dependendo da criticidade, evidências podem incluir:

• versão do modelo;
• prompt de sistema;
• consulta;
• fontes;
• saída;
• ferramentas chamadas;
• usuário;
• aprovação;
• data;
• decisão final.

Isso aproxima IA de outras disciplinas de engenharia: controle exige evidência.

Governança e responsabilidade técnica

IA não assume responsabilidade profissional.

Quando uma saída influencia decisão de engenharia, o profissional precisa compreender sua origem, verificar adequação e assumir ou rejeitar a recomendação.

A governança deve impedir que linguagem persuasiva substitua verificação.

Em atividades sujeitas a responsabilidade técnica, a organização deve definir quais usos são permitidos e como a utilização é documentada.

Como implantar um AIMS em uma empresa de engenharia

A implantação não precisa começar com certificação.

Um roadmap prático pode seguir:

$1

Mapear aplicações existentes e shadow AI.

$1

Definir princípios, usos permitidos, dados e responsabilidades.

$1

Registrar sistemas e casos de uso.

$1

Avaliar risco e criticidade.

$1

Definir validação, acesso, logs e mudança.

$1

Aplicar controles em casos reais.

$1

Medir eficácia e incidentes.

$1

Verificar aderência.

$1

Corrigir lacunas antes de ampliar.

Quando essa estrutura precisa integrar engenharia, gestão documental e processos organizacionais, Serviços Continuados de Engenharia Consultiva podem apoiar implantação progressiva.

Como especificar e contratar governança de IA

O objeto não deve se limitar a “consultoria de IA”.

$1

Inventário, gaps e maturidade.

$1

Papéis, processos, critérios e documentação.

$1

Metodologia de classificação e avaliação.

$1

Dados, acesso, validação, mudança, incidentes e fornecedores.

$1

Aplicação do framework a casos reais.

$1

Política, inventário, matriz de risco, procedimentos, templates e relatório de implantação.

$1

Cobertura, completude, testes e aderência ao processo acordado.

$1

Treinamento e transferência para owners internos.

Quando fornecedores diferentes desenvolvem IA, dados e integrações, Owner’s Engineering pode manter requisitos e aceite sob perspectiva independente do proprietário.

$1

A norma não substitui CDE, BIM, cybersecurity ou gestão de qualidade.

Ela cria uma camada de sistema de gestão sobre essas capacidades.

Um agente que acessa BIM depende de governança BIM. Um RAG depende de governança documental. Uma aplicação preditiva depende de dados operacionais.

A maturidade de IA é limitada pela maturidade das fontes e processos que a alimentam.

$1

Princípios como transparência, segurança e responsabilidade só produzem efeito quando se transformam em controles observáveis. Em engenharia, isso significa converter cada princípio em uma regra de processo, uma evidência ou um gate de decisão.

Por exemplo, “transparência” pode exigir que respostas usadas em análise técnica apresentem fontes; “accountability” pode exigir owner e aprovador; “segurança” pode exigir segregação de dados e menor privilégio; “confiabilidade” pode exigir conjunto de testes, métricas e monitoramento.

Princípio	Controle operacional	Evidência
Transparência	fontes e versionamento	log e citação
Responsabilidade	papéis e alçadas	aprovação registrada
Segurança	acesso mínimo	permissões e trilhas
Confiabilidade	testes e monitoramento	métricas e relatórios
Melhoria	tratamento de incidentes	ações corretivas

$1

Nem todo modelo consegue explicar internamente como chegou a uma saída, mas a organização precisa conseguir explicar por que decidiu utilizá-la. Essa é uma forma prática de explicabilidade organizacional.

O registro de decisão pode indicar problema, modelo, dados, resultado, limitações, revisão e responsável. Mesmo quando o modelo é opaco, o processo de decisão não precisa ser.

Em projetos de maior criticidade, esse registro pode ser integrado a stage-gates, Design Review ou Technical Authority, garantindo que a decisão fique vinculada a uma instância de governança.

$1

Governança precisa ser medida para não se tornar apenas política documental. Indicadores devem mostrar adoção, risco, controle e eficácia.

• percentual de casos inventariados;
• percentual de casos classificados por risco;
• percentual de aplicações com conjunto de teste;
• número de incidentes por período;
• tempo médio de tratamento;
• percentual de mudanças revalidadas;
• taxa de uso de ferramentas não aprovadas;
• percentual de fornecedores avaliados;
• taxa de respostas críticas rejeitadas na revisão.

A meta não deve ser “zero rejeição”. Se revisão nunca rejeita saída, pode indicar que o controle não é efetivo ou que a aplicação opera em escopo excessivamente simples.

$1

Quanto mais crítico o ativo, maior a necessidade de integrar governança de IA a cybersecurity, segurança funcional, gestão de mudanças e procedimentos operacionais. Nesses ambientes, autonomia não pode crescer apenas porque o modelo demonstra boa performance em testes.

É necessário avaliar comportamento em condições degradadas, indisponibilidade de dados, erro de sensor, perda de comunicação e conflito entre recomendações. A arquitetura deve prever estado seguro e autoridade humana para interromper o sistema.

Em 2026, o NIST também passou a trabalhar em um perfil de AI RMF voltado a trustworthy AI em infraestrutura crítica, reforçando a necessidade de adaptar gestão de risco ao contexto operacional e à consequência de falhas.

$1

Empresas de engenharia raramente partem do zero. Já existem processos de qualidade, segurança da informação, riscos, projetos, documentos e fornecedores. Um AIMS pode reutilizar parte dessa estrutura.

Controles de documentos podem apoiar versionamento de prompts e políticas. Gestão de mudanças pode tratar atualizações de modelos. Procurement pode incorporar avaliação de fornecedores de IA. Auditoria interna pode incluir verificações sobre inventário, dados e evidências.

Essa integração reduz burocracia duplicada. O objetivo é incorporar IA à governança corporativa, mantendo controles específicos apenas onde a tecnologia cria riscos novos.

$1

Antes da entrada em produção, a organização pode utilizar um checklist mínimo para verificar se o caso de uso possui base suficiente de governança.

• objetivo e usuário da decisão definidos;
• owner identificado;
• dados e fontes classificados;
• risco e criticidade avaliados;
• fornecedor e termos analisados;
• conjunto de teste definido;
• métricas e critérios de aceite registrados;
• responsável por validação nomeado;
• logs e evidências previstos;
• processo de mudança e incidente estabelecido;
• mecanismo de suspensão ou rollback disponível quando aplicável.

Esse checklist não substitui análise específica, mas impede que aplicações cheguem à produção apenas porque funcionaram em uma demonstração. A exigência de evidência antes da escala é uma das diferenças entre experimentação e governança.

$1

Alguns padrões indicam maturidade insuficiente: política genérica sem processo de aprovação, inventário desatualizado, validação baseada apenas em percepção, uso de credenciais compartilhadas, ausência de owner e confiança excessiva em contratos padrão de fornecedores.

Outro anti-pattern é centralizar toda responsabilidade em TI. Em engenharia, os riscos dependem do contexto técnico; portanto, governança precisa ser multidisciplinar e incluir quem compreende a consequência da saída.

Considerações finais

Governança de IA na engenharia transforma tecnologia em capacidade controlada.

ISO/IEC 42001 fornece uma estrutura de sistema de gestão; ISO/IEC 23894 e NIST AI RMF ajudam a aprofundar risco e avaliação. A engenharia adiciona requisitos de rastreabilidade, validação técnica, responsabilidade e consequência.

A sequência mais consistente é inventariar → classificar → controlar → validar → monitorar → melhorar.

Sem governança, IA pode escalar mais rápido que a capacidade da organização de entender seus próprios riscos. Com governança proporcional, a empresa consegue aumentar uso e autonomia sem perder controle técnico.

Referências técnicas

[1] INTERNATIONAL ORGANIZATION FOR STANDARDIZATION; INTERNATIONAL ELECTROTECHNICAL COMMISSION. ISO/IEC 42001:2023 — Information technology — Artificial intelligence — Management system. Geneva: ISO, 2023. Disponível em: https://www.iso.org/standard/42001

[2] INTERNATIONAL ORGANIZATION FOR STANDARDIZATION; INTERNATIONAL ELECTROTECHNICAL COMMISSION. ISO/IEC 23894:2023 — Information technology — Artificial intelligence — Guidance on risk management. Geneva: ISO, 2023. Disponível em: https://www.iso.org/standard/77304.html

[3] NATIONAL INSTITUTE OF STANDARDS AND TECHNOLOGY. AI Risk Management Framework. Gaithersburg: NIST. Disponível em: https://www.nist.gov/itl/ai-risk-management-framework

[4] NATIONAL INSTITUTE OF STANDARDS AND TECHNOLOGY. Artificial Intelligence Risk Management Framework: Generative Artificial Intelligence Profile. NIST AI 600-1. Atualizado em 2026. Disponível em: https://www.nist.gov/publications/artificial-intelligence-risk-management-framework-generative-artificial-intelligence

Perguntas frequentes

O que é governança de IA?

É o conjunto de políticas, papéis, processos, controles e evidências utilizados para orientar e supervisionar o desenvolvimento e uso de inteligência artificial ao longo de seu ciclo de vida.

O que é a ISO/IEC 42001?

É uma norma internacional de sistema de gestão que especifica requisitos para estabelecer, implementar, manter e melhorar continuamente um Artificial Intelligence Management System (AIMS).

ISO 42001 é obrigatória?

A obrigatoriedade depende de requisitos legais, contratuais ou organizacionais aplicáveis. A norma fornece um framework voluntário de sistema de gestão e pode também ser utilizada como referência para auditoria e certificação quando adotada.

Qual a diferença entre ISO 42001 e NIST AI RMF?

ISO/IEC 42001 é uma norma de sistema de gestão com requisitos organizacionais. NIST AI RMF é um framework de gestão de risco estruturado em Govern, Map, Measure e Manage. Eles podem ser usados de forma complementar.

Como classificar o risco de um uso de IA em engenharia?

Considerando consequência do erro, reversibilidade, detectabilidade, alcance, dados envolvidos e nível de autonomia. Quanto maior o impacto, maiores devem ser validação e supervisão.

O que deve entrar no inventário de IA?

Caso de uso, processo, owner, tecnologia, fornecedor, dados, criticidade, validação, status, versão e última revisão.

Como governar agentes de IA?

Com menor privilégio, ferramentas autorizadas, sandbox, logs, aprovação para ações críticas, limites de escopo, reversão e mecanismo de interrupção.

IA transfere a responsabilidade técnica do engenheiro?

Não. A saída de IA pode apoiar análise, mas o profissional e a organização continuam responsáveis por verificar adequação e tomar decisões dentro de suas atribuições.

Materiais técnicos complementares

Serviços relacionados

• Serviços Continuados de Engenharia Consultiva
• Engenharia do Proprietário (Owner’s Engineering)
• Gestão BIM e Informação de Engenharia
• Design Review em Projetos de Engenharia
• Gerenciamento de Projetos de Engenharia

Conteúdos principais sobre o tema

• Inteligência Artificial na Engenharia
• IA Generativa na Engenharia
• IA para Projetos de Engenharia
• RAG na Engenharia

Conteúdos técnicos correlatos

• Technical Authority em Engenharia
• Gestão de Riscos em Projetos de Engenharia
• Governança Técnica Digital para Empresas de Engenharia
• Gestão de Engenharia: processos, governança, projetos e desempenho