Publicado em 21 Setembro de 2026

A IA no controle de processo deixou de ser piloto de laboratório. Modelos ajustam setpoint, preveem falhas e disparam ação, e visão computacional já aparece ligada a intertravamento. A proposta chega como projeto de produtividade, quase nunca com a pergunta de segurança de processos.

Quando um modelo estatístico passa a atuar sobre uma malha que protege pessoas e ativos, ele vira um elemento do sistema de segurança. E, na maioria das plantas, esse elemento não aparece em nenhum nó de HAZOP, em nenhum cenário de LOPA e em nenhuma análise de camadas de proteção. A planta ganhou um modo de falha novo que a análise de riscos ainda não enxerga.

IA no aconselhamento e IA no acionamento

• IA no aconselhamento: o modelo recomenda um ajuste, uma parada, uma intervenção de manutenção. Um operador avalia e decide. O erro do modelo passa por um filtro humano antes de chegar ao processo.
• IA no acionamento: o modelo escreve direto na malha, altera setpoint, abre ou fecha, libera ou bloqueia. Não há filtro. O erro do modelo é o desvio de processo.

A natureza do risco muda entre os dois. No aconselhamento, o risco dominante é o de confiança excessiva: o operador aprende a aceitar a recomendação sem questionar. No acionamento, o modelo passa a ser causa possível de desvio, e precisa ser tratado como tal em cada nó onde atua.

Por que o HAZOP tradicional não captura esse risco

O HAZOP foi construído sobre uma premissa: desvios têm causas identificáveis e os sistemas de controle respondem de forma determinística.

Um modelo de aprendizado de máquina não se comporta assim. O desempenho pode degradar aos poucos, sem alarme, quando o processo real se afasta dos dados de treino. E a resposta a uma condição nunca vista antes não é conhecida até que ela aconteça.

Modos de falha que precisam entrar no nó

• Deriva do modelo (model drift): mudança de matéria-prima, desgaste de equipamento ou nova campanha operacional tiram o processo do padrão aprendido, e a qualidade da resposta cai sem sinal visível.
• Entrada fora do envelope de treinamento: partida, parada e emergência têm poucos dados históricos e as maiores consequências.
• Dados de treino contaminados: histórico com instrumento descalibrado, período de operação anormal ou manipulação intencional ensina o modelo a errar.
• Dependência de conectividade e de fornecedor: modelo hospedado fora da planta, atualização remota, suporte de um único provedor.
• Perda do modo degradado: depois de meses com o modelo operando, a equipe ainda sabe conduzir a unidade sem ele? Esse modo foi testado?

IA não é camada de proteção independente na LOPA

Na LOPA, uma salvaguarda só recebe crédito como camada de proteção independente se atende a critérios consolidados nos guias do CCPS: independência em relação à causa e às demais camadas, efetividade para impedir a consequência, integridade mantida ao longo do tempo e auditabilidade. Um modelo de IA na malha de controle falha em quase todos.

• Independência: o modelo se alimenta dos mesmos sensores e roda na mesma infraestrutura do controle básico. Se o sensor falha, a causa e a proteção falham juntas.
• Auditabilidade: não há como inspecionar o raciocínio de uma rede neural da forma como se lê uma lógica de intertravamento.
• Probabilidade de falha sob demanda: não existe hoje método aceito para demonstrar a PFD de um modelo estatístico da forma como se calcula a de um instrumento de segurança.

A IEC 61511, referência para sistemas instrumentados de segurança na indústria de processo, já é restritiva com o próprio sistema básico de controle: quando se reivindica dele redução de risco maior que 10, ele precisa ser projetado e gerenciado segundo os requisitos da norma. Um modelo de IA dentro desse sistema torna esse crédito mais difícil, não mais fácil.

O vazio normativo, dito com precisão

A edição vigente da IEC 61511 e a da IEC 61508 não trazem requisitos para inteligência artificial. O documento internacional que trata diretamente do tema é a ISO/IEC TR 5469:2024, sobre segurança funcional e sistemas de IA. Ela é um relatório técnico: descreve riscos, propriedades e métodos, mas não estabelece requisitos certificáveis. Quem coloca IA numa malha de segurança hoje decide sem critério normativo de aceitação.

A decisão está sendo tomada no nível errado

Este é o ponto que interessa à diretoria. A adoção de IA em malha de controle é uma decisão de risco corporativo, e hoje ela nasce com um gerente de operação, com a área de TI ou dentro de um projeto de ganho de produtividade. Não sobe para o comitê de riscos, não entra na matriz de riscos corporativos e não é testada contra o apetite a risco declarado pela empresa.

A exposição não é local. Um modelo que atua na malha cria risco de continuidade operacional, risco de terceiro e fornecedor, risco de conformidade e risco reputacional. Em artigo publicado pelo Fórum Econômico Mundial, o CEO da Dragos aponta dois cenários que mostram isso: a tecnologia de IA ficar indisponível de uma hora para outra, por uma correção de mercado, e a complexidade do sistema impedir a análise de causa raiz depois de um incidente.

Onde essa decisão deveria estar registrada

• No registro de riscos corporativos, com dono nomeado.
• Na due diligence de fornecedor crítico, incluindo a descontinuidade do provedor.
• No plano de continuidade de negócios, com o modo de operação sem o modelo definido e testado.
• No reporte ao conselho ou ao comitê de riscos, como qualquer mudança que altera o perfil de risco da operação.

A ISO 31000 e o COSO ERM oferecem a estrutura para isso: integração da gestão de riscos à estratégia, definição de apetite a risco e supervisão pela alta administração. Para quem já trabalha com critérios de tolerabilidade, o raciocínio é o mesmo do ALARP em gerenciamento de riscos: o risco residual precisa ser demonstrado, não presumido.

A pergunta para levar à diretoria

Quem aprovou colocar um modelo estatístico dentro de uma malha que protege pessoas e ativos, e contra qual critério de apetite a risco essa aprovação foi feita? Se a resposta for um nome de projeto, e não um registro de risco, a decisão foi tomada abaixo do radar de quem responde por ela.

O que fazer, nesta ordem

• Revisitar o HAZOP dos nós com IA, incluindo os modos de falha do modelo como causas de desvio.
• Nunca creditar a IA como camada de proteção independente na LOPA, enquanto não houver forma aceita de demonstrar independência e PFD.
• Documentar dependências e exigir modo manual testado, com critério claro de quando o modelo sai da malha.
• Elevar a decisão ao registro de riscos corporativos e ao comitê, com dono nomeado e revisão periódica, tratando cada nova aplicação como gestão de mudança.

Nada disso é contra a IA: é a disciplina que a indústria de processo já aplica a qualquer elemento que possa causar ou impedir um acidente. A Avoid apoia empresas na avaliação e gerenciamento de riscos, da revisão de HAZOP e LOPA à integração desses riscos na governança corporativa. Se a sua planta está recebendo propostas de IA para otimizar a operação, esse é o momento de fazer as perguntas certas, antes da assinatura.