Chernobyl foi erro humano, falha de projeto ou falha de governança? Entenda como o INSAG-7 mudou a interpretação do acidente e o que o caso ensina sobre sistemas críticos, cultura de segurança e engenharia consultiva.

Confira!

O acidente no Reator 4 da usina nuclear de Chernobyl costuma ser resumido em uma pergunta aparentemente simples: foi erro humano ou falha de projeto?

A resposta técnica é mais complexa. Chernobyl não cabe em uma única causa. A sequência que destruiu o Reator 4 envolveu decisões operacionais, características perigosas do projeto RBMK, cultura de segurança insuficiente, comunicação deficiente entre organizações técnicas, pressão por continuidade operacional e fragilidades de governança.

Por isso, talvez a pergunta mais adequada seja outra: como um sistema crítico pôde permitir que tantas barreiras falhassem em sequência?

Este artigo aprofunda o eixo de governança da série Chernobyl. Nos textos anteriores, explicamos o que aconteceu em Chernobyl, como funcionava o reator RBMK, a cronologia da noite do acidente, por que o AZ-5 não impediu a explosão e por que a queda de potência para 30 MWt continua tecnicamente inconclusiva.

Agora, vamos olhar para o acidente como um caso de engenharia, gestão de risco e governança técnica.

A pergunta crucial: foi falha humana?

Em grandes acidentes de engenharia, a busca por um culpado único costuma ser uma resposta emocionalmente satisfatória, mas tecnicamente pobre. Sistemas críticos raramente falham por um único ato isolado. Eles falham quando várias camadas de proteção deixam de cumprir sua função.

No caso de Chernobyl, houve ações operacionais inadequadas, violações de procedimentos e decisões tomadas em uma condição de risco crescente. Mas parar a análise nesse ponto distorce o problema.

O INSAG-7, relatório da Agência Internacional de Energia Atômica que atualizou a análise inicial do acidente, mudou o peso dessa interpretação. A narrativa inicial, fortemente concentrada em erro operacional, foi revisada para incorporar falhas de projeto, deficiências de comunicação, baixa cultura de segurança e limitações institucionais.

Essa mudança é essencial: Chernobyl não foi apenas a história de operadores conduzindo mal um teste. Foi a história de um sistema que permitiu que um teste crítico fosse conduzido com margens degradadas, informações incompletas e barreiras de segurança insuficientes.

A narrativa inicial: o peso colocado nos operadores

Logo após o acidente, a explicação apresentada internacionalmente enfatizava uma combinação improvável de violações de instruções e regras operacionais. Essa leitura aparecia no contexto do INSAG-1, elaborado com base nas informações soviéticas disponíveis logo após o acidente.

O problema é que, naquele momento, muitas informações técnicas ainda eram incompletas, pouco acessíveis ou interpretadas dentro de uma narrativa institucional que favorecia a responsabilização operacional.

Com o avanço das análises, especialmente após novos dados soviéticos e estudos tridimensionais de física de reatores, ficou mais claro que o acidente não poderia ser explicado apenas pelas ações dos operadores. Havia características do RBMK que criavam riscos severos em determinadas condições, e algumas dessas características não eram plenamente compreendidas, comunicadas ou corrigidas.

Isso não elimina a responsabilidade operacional. Mas muda o enquadramento: operadores erraram dentro de um sistema que já carregava vulnerabilidades técnicas e institucionais profundas.

O que o INSAG-7 mudou na interpretação de Chernobyl?

O INSAG-7 é um documento central porque revisa a interpretação inicial do acidente. Ele reconhece que a explicação baseada apenas em violações operacionais era insuficiente e passa a dar mais peso a fatores de projeto e segurança.

Entre os pontos destacados estão:

  • o coeficiente de vazio positivo do RBMK;
  • as deficiências no projeto das hastes de controle e proteção;
  • o efeito positivo inicial do desligamento emergencial;
  • a baixa margem operacional de reatividade, a ORM;
  • a importância de segurança da ORM mal compreendida;
  • a falta de indicação conveniente da ORM para os operadores;
  • a ausência de integração adequada da ORM ao sistema de proteção;
  • falhas de comunicação entre projetistas, operadores, reguladores e organizações responsáveis.

O documento também é direto ao afirmar que a gravidade do acidente passou a ser associada por muitas análises aos defeitos no desenho das hastes de controle e segurança, combinados com as características físicas do RBMK que permitiam grandes coeficientes positivos de vazio.

Esse é um ponto de virada. A pergunta deixa de ser apenas “por que os operadores continuaram?” e passa a incluir: por que o projeto permitia uma configuração tão perigosa e por que o sistema de proteção não impedia que ela fosse alcançada?

Falha de projeto: quando performance e segurança entram em conflito

O RBMK era um reator de grande potência, projetado para geração elétrica em larga escala. Do ponto de vista de performance, havia escolhas que faziam sentido dentro da lógica de eficiência neutrônica, operação em base load e produção de energia.

Mas algumas dessas escolhas criaram compromissos perigosos para a segurança. O exemplo mais conhecido é o projeto das hastes de controle, com deslocadores de grafite. Como discutimos no artigo sobre o AZ-5, esses deslocadores ajudavam a evitar absorção parasita de nêutrons pela água nos canais de controle quando as hastes estavam retiradas. Em operação normal, essa solução favorecia a eficiência do reator.

O problema é que, em certas condições, o primeiro movimento de inserção das hastes podia deslocar água por grafite antes que a parte absorvedora atuasse de forma eficaz. Como a água absorvia parte dos nêutrons e o grafite moderava nêutrons, essa substituição podia aumentar localmente a reatividade.

Na prática, uma solução de performance criou um comportamento transitório incompatível com a função de segurança. O “freio” não deveria depender de o sistema estar em uma condição favorável para começar a frear.

Essa é uma lição de engenharia aplicável a qualquer infraestrutura crítica: otimização operacional nunca pode degradar a barreira de segurança em condição-limite.

ORM: uma variável crítica que não era tratada como barreira de proteção

A ORM, margem operacional de reatividade, era uma variável fundamental no RBMK. Ela não representava simplesmente a quantidade física de hastes inseridas no núcleo, mas uma margem calculada de controle, expressa em número equivalente de hastes totalmente inseridas.

Segundo o INSAG-7, em potência nominal e regime estável, a ORM deveria estar entre 26 e 30 hastes equivalentes. Se caísse para 15, o reator deveria ser desligado imediatamente. Antes do início efetivo do teste, cálculos posteriores indicaram valores muito abaixo desse limite, na ordem de 6 a 8 hastes equivalentes, dependendo da reconstrução utilizada.

O ponto crítico é que a ORM não estava convenientemente disponível para o operador e não estava incorporada de forma adequada ao sistema de proteção. Além disso, sua importância para a segurança foi mal compreendida. Ela era vista principalmente como uma margem para manobra e controle da distribuição de potência, quando na verdade influenciava fortemente o comportamento do reator frente ao coeficiente de vazio positivo e à inserção das hastes.

Do ponto de vista de governança técnica, isso é grave. Uma variável que define a segurança do sistema não pode ser apenas um parâmetro calculado com dificuldade, sem indicação clara e sem integração efetiva às proteções automáticas.

Em sistemas críticos modernos, a regra deveria ser clara: se uma variável é crítica para a segurança, ela precisa ser visível, compreendida, registrada, auditável e capaz de acionar barreiras de proteção.

Pressão institucional: energia, cronograma e cultura de metas

Chernobyl também precisa ser entendido dentro do contexto da União Soviética, da Guerra Fria e de uma cultura institucional fortemente orientada por metas de produção, hierarquia e demonstração de capacidade tecnológica.

Isso não significa dizer que o contexto político, sozinho, causou o acidente. Não causou. Mas ele ajuda a entender o ambiente em que decisões técnicas eram tomadas.

Na noite do acidente, o teste foi adiado porque a rede elétrica ainda precisava da geração da unidade. A operação do Reator 4 não ocorria em um laboratório isolado; ocorria dentro de um sistema elétrico real, com demanda, despacho, pressão por disponibilidade e necessidade de continuidade energética.

Além disso, o ambiente soviético tornava mais difícil contestar hierarquias, expor falhas de projeto, interromper atividades críticas ou admitir publicamente limitações técnicas. O INSAG-7 destaca falhas de comunicação e ausência de linhas claras de responsabilidade entre projetistas, engenheiros, fabricantes, construtores, operadores e reguladores.

Esse é o ponto de governança: quando a organização valoriza entrega, produção ou cumprimento de plano acima da segurança técnica, as barreiras passam a depender da coragem individual de alguém dizer “pare”. Em sistemas críticos, isso é inaceitável.

Ocultação, comunicação de risco e aprendizagem tardia

Outro elemento essencial é a comunicação. Depois do acidente, informações foram tratadas de forma lenta, incompleta e politicamente sensível. Isso afetou a resposta pública, a percepção internacional e a reconstrução técnica da sequência de eventos.

Mas a comunicação deficiente não começou depois da explosão. Ela já aparecia antes, na forma como informações críticas sobre o projeto do RBMK, o efeito positivo de desligamento emergencial e a importância da ORM foram transmitidas, compreendidas ou incorporadas à operação.

O INSAG-7 registra que o efeito positivo de inserção das hastes havia sido identificado anteriormente em outro RBMK, na usina de Ignalina, em 1983. Havia indicação de que mudanças de projeto seriam feitas para corrigir o problema, mas as medidas não foram implementadas de forma suficiente antes do acidente em Chernobyl.

Essa é uma das lições mais duras do caso: uma falha conhecida, quando não é tratada com prioridade, deixa de ser um problema técnico e se torna uma falha de governança.

Houve punição? Sim, mas a responsabilização foi limitada

É importante tratar esse ponto com cuidado. Após o acidente, houve responsabilização criminal de operadores e gestores locais. A narrativa pública inicial concentrou grande peso nas ações da equipe da usina.

Mas essa responsabilização não esgotava o problema. A análise técnica posterior mostrou que falhas de projeto, cultura de segurança, comunicação institucional e governança tiveram papel central. Em outras palavras, a punição de pessoas envolvidas na operação não significou que o sistema institucional responsável pelas vulnerabilidades tivesse sido plenamente responsabilizado desde o início.

Essa distinção é importante para qualquer análise de acidentes: responsabilizar indivíduos pode ser necessário, mas é insuficiente quando o sistema como um todo produziu as condições para a falha.

Falha de governança: quem tinha autoridade para parar?

A pergunta central em sistemas críticos não é apenas “quem fez?”, mas também “quem poderia interromper?”

Em Chernobyl, várias perguntas de governança aparecem:

  • quem aprovou o programa do teste?
  • quem avaliou suas implicações nucleares e não apenas elétricas?
  • quem validou os critérios de segurança?
  • quem tinha autoridade para abortar o teste quando a potência caiu para 30 MWt?
  • quem garantia que a ORM estivesse dentro de limite seguro?
  • quem comunicou aos operadores o risco do efeito positivo do AZ-5?
  • quem deveria impedir a operação em uma configuração proibitiva?
  • quem integrava projeto, operação, segurança e regulação?

Quando essas respostas não são claras, a segurança depende de improviso. E improviso é incompatível com sistemas críticos.

O PMBOK, em sua abordagem baseada em princípios, reforça a importância de governança, responsabilidade, partes interessadas, planejamento, qualidade, riscos, complexidade e adaptação ao contexto. Aplicado a sistemas críticos, isso significa que decisões técnicas precisam ter donos claros, critérios de aceitação, trilhas de aprovação, gestão de riscos e autoridade formal para interromper atividades inseguras.

Chernobyl mostra o que acontece quando engenharia, operação, política, regulação e gestão não formam um sistema de decisão seguro.

O teste não era “apenas elétrico”

Um dos pontos mais importantes do INSAG-7 é a crítica à classificação do teste como puramente elétrico. O teste de rundown envolvia a alimentação de bombas principais, circuitos de energia, sistemas de proteção e intertravamentos. Portanto, tinha implicações diretas sobre a segurança nuclear.

Essa é uma falha clássica de interface: uma atividade aparentemente pertencente a uma disciplina técnica afeta outra disciplina crítica. Em projetos complexos, muitos acidentes nascem justamente nas interfaces.

Em um projeto moderno, um teste desse tipo exigiria matriz de riscos, análise multidisciplinar, validação por segurança, critérios de abortagem, simulação de cenários, plano de comissionamento, aprovação formal e registro detalhado de pré-condições.

Quando uma atividade que afeta segurança nuclear é tratada como teste elétrico, a governança falhou antes do teste começar.

O que Chernobyl ensina sobre engenharia consultiva?

Chernobyl é um estudo extremo, mas suas lições valem para sistemas críticos modernos. Subestações, data centers, usinas, centros de operação, hospitais, redes industriais e sistemas de telecomunicações também dependem de projeto, operação, supervisão, testes, documentação e governança.

Em todos esses ambientes, não basta que o sistema funcione em operação normal. Ele precisa responder corretamente em transições, falhas parciais, perda de alimentação, mudança de modo, operação degradada e emergência.

É nesse ponto que entram práticas de Owner’s Engineering, FEL, EPCM, comissionamento, auditoria técnica e due diligence técnica.

Essas práticas ajudam o dono do ativo a fazer perguntas que precisam ser respondidas antes da operação:

  • quais variáveis são críticas para segurança?
  • essas variáveis são visíveis e registradas?
  • os testes cobrem transições reais de operação?
  • os sistemas de proteção foram validados em condição degradada?
  • as interfaces entre disciplinas foram revisadas?
  • quem pode interromper uma atividade insegura?
  • os riscos estão documentados e aceitos formalmente?
  • a operação recebeu treinamento suficiente?

Essas perguntas são tão importantes quanto o cálculo, o desenho ou o equipamento.

De Chernobyl às infraestruturas críticas atuais

A discussão sobre Chernobyl também dialoga com sistemas de supervisão e controle modernos. Em subestações e instalações críticas, soluções como SCADA no setor elétrico, teleassistência em subestações, monitoramento de chaves seccionadoras e projeto de telecomunicações para subestações existem justamente para ampliar visibilidade operacional, registrar eventos, permitir diagnóstico e apoiar decisões seguras.

Mas tecnologia de supervisão sozinha não resolve governança. Dados precisam ser interpretáveis. Alarmes precisam ter hierarquia. Proteções precisam atuar automaticamente quando limites críticos são violados. Operadores precisam entender o significado das variáveis. Gestores precisam respeitar critérios de parada.

A segurança de sistemas críticos é resultado de arquitetura técnica e cultura organizacional. Uma sem a outra é insuficiente.

Então, Chernobyl foi erro humano, falha de projeto ou falha de governança?

Foi uma combinação dos três — mas a expressão “erro humano” precisa ser usada com cuidado.

Houve decisões operacionais inadequadas. Houve violação de limites. Houve continuidade do teste em condição perigosa. Mas também havia um reator com características de projeto perigosas, um sistema de proteção com comportamento inicial desfavorável em certas condições, uma variável crítica de segurança pouco visível, procedimentos insuficientes e falhas de comunicação entre organizações técnicas.

Acima de tudo, havia falha de governança: o sistema não impediu que uma condição perigosa fosse alcançada, não tornou variáveis críticas suficientemente visíveis, não corrigiu vulnerabilidades conhecidas com urgência e não estruturou autoridade clara para interromper o risco.

Por isso, o veredito técnico mais robusto é:

Chernobyl foi uma falha sistêmica de engenharia, operação e governança. O erro humano existiu, mas não explica sozinho o acidente. O projeto criou vulnerabilidades; a operação levou o reator a uma condição crítica; a governança não impediu que essas vulnerabilidades se combinassem.

Conclusão: a principal falha foi sistêmica

A grande lição de Chernobyl não é apenas que operadores podem errar. A lição é que sistemas críticos precisam ser projetados, testados, operados e governados considerando que pessoas erram, pressões existem, sinais são mal interpretados e condições degradadas acontecem.

Um sistema seguro não depende de perfeição humana. Ele cria barreiras para que erros não se transformem em catástrofes. Ele torna variáveis críticas visíveis. Ele impede configurações proibitivas. Ele testa transições. Ele registra decisões. Ele corrige vulnerabilidades conhecidas. Ele dá autoridade real para interromper atividades inseguras.

Chernobyl mostra o custo de quando isso não acontece.

Para a engenharia consultiva, esse é o ponto central: em projetos críticos, segurança não é um item a ser verificado no final. Segurança é uma arquitetura de decisões, requisitos, testes, responsabilidades e governança desde o início.

No próximo passo da série, faz sentido aprofundar o projeto do RBMK sob a ótica da engenharia: quais decisões de arquitetura priorizavam eficiência, quais criavam vulnerabilidades e como esses compromissos técnicos prepararam o terreno para o acidente.

Fale com um especialista da A3A Engenharia

Perguntas frequentes sobre falha de projeto e governança em Chernobyl

Chernobyl foi erro humano?

Houve erro humano e decisões operacionais inadequadas, mas o acidente não pode ser explicado apenas por isso. O INSAG-7 mostra que falhas de projeto, cultura de segurança, comunicação e governança também foram decisivas.

Qual foi a principal falha de projeto do RBMK?

Entre as principais falhas estavam o coeficiente de vazio positivo e o projeto das hastes de controle, que em certas condições podia inserir reatividade positiva no início do desligamento emergencial.

O que o INSAG-7 mudou sobre Chernobyl?

O INSAG-7 revisou a explicação inicial centrada em violações dos operadores e deu mais peso a deficiências de projeto, baixa cultura de segurança, comunicação inadequada e falhas institucionais.

A pressão política causou o acidente?

Não sozinha. O contexto político e institucional da União Soviética ajudou a moldar o ambiente de decisão, mas o acidente resultou da combinação entre projeto, operação, cultura de segurança e governança.

O que é falha de governança técnica?

É quando responsabilidades, autoridade de decisão, gestão de riscos, critérios de parada, comunicação técnica e barreiras de proteção não estão claros ou não funcionam de forma eficaz em um sistema crítico.

Por que o teste de Chernobyl não era apenas elétrico?

Porque envolvia alimentação de bombas principais, sistemas de proteção, intertravamentos e condições que afetavam diretamente o resfriamento do núcleo e a segurança nuclear.

Qual é a principal lição de Chernobyl para projetos atuais?

A principal lição é que sistemas críticos precisam de projeto seguro, testes integrados, variáveis críticas visíveis, autoridade para interromper riscos e governança técnica robusta.

Referências Técnicas

IAEA — INSAG-7, The Chernobyl Accident: Updating of INSAG-1, Safety Series No. 75-INSAG-7, 1992.

U.S. Nuclear Regulatory Commission — NUREG-1250, Report on the Accident at the Chernobyl Nuclear Power Station, 1987.

PMI — Guia PMBOK®, 7ª edição: princípios de gerenciamento de projetos, governança, riscos, partes interessadas, qualidade, complexidade e incerteza.

ASHRAE Guideline 0-2019 — The Commissioning Process: requisitos do proprietário, base de projeto, plano de comissionamento, testes funcionais e documentação.

Materiais Técnicos Complementares

Conteúdos da série Chernobyl

Conteúdos A3A relacionados

Serviços relacionados