Comprenda por qué Chernóbil no puede reducirse a error humano y cómo se combinaron fallas de diseño, regulación, comunicación, cultura de seguridad y gobernanza.
¡Descúbrelo!
El accidente del Reactor 4 de la central nuclear de Chernóbil suele resumirse en una pregunta aparentemente simple: ¿fue error humano o falla de diseño?
La respuesta técnica es más compleja. Chernóbil no cabe en una causa única. La secuencia que destruyó el Reactor 4 involucró decisiones operativas, características peligrosas del diseño RBMK, una cultura de seguridad insuficiente, comunicación deficiente entre organizaciones técnicas, presión por continuidad operativa y fragilidades de gobernanza.
Por ello, quizá la pregunta más adecuada sea otra: ¿cómo pudo un sistema crítico permitir que tantas barreras fallaran en secuencia?
Este artículo profundiza el eje de gobernanza de la serie Chernóbil. En los textos anteriores explicamos qué ocurrió en Chernóbil, cómo funcionaba el reactor RBMK, la cronología de la noche del accidente, por qué el AZ-5 no impidió la explosión y por qué la caída de potencia a 30 MWt sigue siendo técnicamente inconclusa.
Ahora analizaremos el accidente como un caso de ingeniería, gestión de riesgos y gobernanza técnica.
Un análisis sistémico debe distinguir al menos cinco capas: mecanismos físicos, que explican cómo se desarrolló el transitorio; decisiones operativas, que definieron el estado del reactor; decisiones de diseño, que determinaron márgenes y respuestas de protección; controles organizativos, que debían impedir condiciones inaceptables; y gobernanza institucional, responsable de transformar conocimiento técnico en requisitos, correcciones y autoridad para detener actividades.
La gobernanza, por tanto, no es una causa física que compita con el coeficiente de vacío o con las barras. Es la capa que debía garantizar que los riesgos conocidos fueran comunicados, registrados, tratados e impedidos de llegar a la operación.
La pregunta crucial: ¿fue error humano?
En los grandes accidentes de ingeniería, la búsqueda de un único culpable suele ser una respuesta emocionalmente satisfactoria, pero técnicamente pobre. Los sistemas críticos rara vez fallan por un único acto aislado. Fallan cuando varias capas de protección dejan de cumplir su función.
En Chernóbil hubo acciones operativas inadecuadas, violaciones de procedimientos y decisiones tomadas en una condición de riesgo creciente. Pero detener el análisis en ese punto distorsiona el problema.
El INSAG-7, informe del Organismo Internacional de Energía Atómica que actualizó el análisis inicial del accidente, modificó el peso de esta interpretación. La narrativa inicial, muy concentrada en el error operativo, fue revisada para incorporar fallas de diseño, deficiencias de comunicación, baja cultura de seguridad y limitaciones institucionales.
Este cambio es esencial: Chernóbil no fue solo la historia de operadores conduciendo mal un ensayo. Fue la historia de un sistema que permitió que un ensayo crítico se realizara con márgenes degradados, información incompleta y barreras de seguridad insuficientes.
Gestión de Requisitos, Evidencias y Criterios de Aceptación
Los riesgos críticos deben convertirse en requisitos trazables, límites verificables, evidencias de cumplimiento y criterios formales de interrupción.
La narrativa inicial: el peso colocado sobre los operadores
Inmediatamente después del accidente, la explicación presentada internacionalmente enfatizaba una combinación improbable de violaciones de instrucciones y reglas operativas. Esta lectura aparecía en el contexto de INSAG-1, elaborado con base en la información soviética disponible poco después del accidente.
El problema es que, en aquel momento, mucha información técnica todavía era incompleta, poco accesible o interpretada dentro de una narrativa institucional que favorecía la responsabilización operativa.
Con el avance de los análisis, especialmente después de nuevos datos soviéticos y estudios tridimensionales de física de reactores, quedó más claro que el accidente no podía explicarse únicamente por las acciones de los operadores. El RBMK tenía características que creaban riesgos severos en determinadas condiciones y algunas de ellas no eran plenamente comprendidas, comunicadas o corregidas.
Esto no elimina la responsabilidad operativa. Pero cambia el encuadre: los operadores se equivocaron dentro de un sistema que ya contenía vulnerabilidades técnicas e institucionales profundas.
¿Qué cambió INSAG-7 en la interpretación de Chernóbil?
INSAG-7 es un documento central porque revisa la interpretación inicial del accidente. Reconoce que la explicación basada únicamente en violaciones operativas era insuficiente y pasa a dar más peso a factores de diseño y seguridad.
Entre los puntos destacados están:
- el coeficiente de vacío positivo del RBMK;
- las deficiencias en el diseño de las barras de control y protección;
- el efecto positivo inicial de la parada de emergencia;
- el bajo margen operativo de reactividad, ORM;
- la importancia de seguridad de la ORM mal comprendida;
- la falta de una indicación conveniente de la ORM para los operadores;
- la ausencia de una integración adecuada de la ORM en el sistema de protección;
- fallas de comunicación entre diseñadores, operadores, reguladores y organizaciones responsables.
El documento también es directo al afirmar que muchas evaluaciones pasaron a asociar la gravedad del accidente con defectos en el diseño de las barras de control y seguridad, combinados con características físicas del RBMK que permitían grandes coeficientes positivos de vacío.
Este es un punto de inflexión. La pregunta deja de ser solo “¿por qué continuaron los operadores?” y pasa a incluir: ¿por qué el diseño permitía una configuración tan peligrosa y por qué el sistema de protección no impedía alcanzarla?
La revisión también demuestra la importancia de la independencia técnica. Las investigaciones de accidentes deben confrontar registros, modelos, procedimientos, decisiones de diseño y responsabilidades institucionales sin asumir que la primera explicación disponible es definitiva.
Auditoría Técnica
Las auditorías independientes verifican cumplimiento, evidencias, interfaces, riesgos y brechas entre lo proyectado, documentado, instalado y efectivamente operado.
Falla de diseño: cuando desempeño y seguridad entran en conflicto
El RBMK era un reactor de gran potencia, diseñado para generación eléctrica a gran escala. Desde el punto de vista del desempeño, algunas decisiones tenían sentido dentro de una lógica de eficiencia neutrónica, operación en carga base y producción de energía.
Pero algunas de esas decisiones crearon compromisos peligrosos para la seguridad. El ejemplo más conocido es el diseño de las barras de control con desplazadores de grafito. Como explicamos en el artículo sobre AZ-5, estos desplazadores ayudaban a evitar la absorción parasitaria de neutrones por el agua en los canales de control cuando las barras estaban retiradas. En operación normal, esta solución favorecía la eficiencia del reactor.
El problema es que, en determinadas condiciones, el primer movimiento de inserción de las barras podía sustituir agua por grafito antes de que la parte absorbente actuara eficazmente. Como el agua absorbía parte de los neutrones y el grafito los moderaba, esta sustitución podía aumentar localmente la reactividad.
En la práctica, una solución de desempeño creó un comportamiento transitorio incompatible con la función de seguridad. El “freno” no debería depender de que el sistema estuviera en una condición favorable para empezar a frenar.
Esta es una lección de ingeniería aplicable a cualquier infraestructura crítica: la optimización operativa nunca puede degradar la barrera de seguridad en una condición límite.
ORM: una variable crítica que no se trataba como barrera de protección
La ORM, margen operativo de reactividad, era una variable fundamental en el RBMK. No representaba simplemente la cantidad física de barras insertadas en el núcleo, sino un margen calculado de control, expresado como número equivalente de barras totalmente insertadas.
Según INSAG-7, a potencia nominal y en régimen estable, la ORM debía estar entre 26 y 30 barras equivalentes. Si caía a 15, el reactor debía detenerse inmediatamente. Antes del inicio efectivo del ensayo, cálculos posteriores indicaron valores muy por debajo de ese límite, del orden de 6 a 8 barras equivalentes, según la reconstrucción utilizada.
El punto crítico es que la ORM no estaba disponible de forma conveniente para el operador y no estaba incorporada adecuadamente al sistema de protección. Además, su importancia para la seguridad se comprendía mal. Se consideraba principalmente un margen para maniobra y control de la distribución de potencia, cuando en realidad influía fuertemente en el comportamiento del reactor frente al coeficiente de vacío positivo y a la inserción de las barras.
Desde el punto de vista de gobernanza técnica, esto es grave. Una variable que define la seguridad del sistema no puede ser solo un parámetro difícil de calcular, sin indicación clara y sin integración efectiva con las protecciones automáticas.
En sistemas críticos modernos, la regla debería ser clara: si una variable es crítica para la seguridad, debe ser visible, comprendida, registrada, auditable y capaz de activar barreras de protección.
También debe presentarse dentro de contexto. Un valor instantáneo sin historial, calidad del dato, tendencia, estado operativo y relación con otros márgenes puede producir falsa seguridad. La gobernanza de la información comienza en la instrumentación, pasa por el cálculo y termina en la forma en que el dato orienta la decisión.
Sistemas SCADA
Históricos, alarmas, tendencias, calidad de datos y secuencia de eventos transforman variables dispersas en información operativa trazable.
Presión institucional: energía, cronograma y cultura de metas
Chernóbil también debe entenderse dentro del contexto de la Unión Soviética, la Guerra Fría y una cultura institucional fuertemente orientada por metas de producción, jerarquía y demostración de capacidad tecnológica.
Esto no significa que el contexto político, por sí solo, causara el accidente. No lo hizo. Pero ayuda a comprender el entorno en el que se tomaban las decisiones técnicas.
La noche del accidente, el ensayo fue aplazado porque la red eléctrica todavía necesitaba la generación de la unidad. La operación del Reactor 4 no ocurría en un laboratorio aislado; ocurría dentro de un sistema eléctrico real, con demanda, despacho, presión por disponibilidad y necesidad de continuidad energética.
Este retraso está documentado. Sin embargo, la influencia más amplia de la presión política y de la cultura de metas debe tratarse como contexto institucional, no como una orden directa registrada para producir el accidente. El rigor exige separar lo que consta en los registros operativos de lo que se infiere a partir de la estructura organizativa y del patrón posterior de comunicación.
Además, el entorno soviético hacía más difícil cuestionar jerarquías, exponer fallas de diseño, interrumpir actividades críticas o admitir públicamente limitaciones técnicas. INSAG-7 destaca fallas de comunicación y ausencia de líneas claras de responsabilidad entre diseñadores, ingenieros, fabricantes, constructores, operadores y reguladores.
Este es el punto de gobernanza: cuando una organización valora la entrega, la producción o el cumplimiento del plan por encima de la seguridad técnica, las barreras pasan a depender del valor individual de alguien para decir “pare”. En sistemas críticos, esto es inaceptable.
Ocultamiento, comunicación de riesgos y aprendizaje tardío
Otro elemento esencial es la comunicación. Después del accidente, la información fue tratada de forma lenta, incompleta y políticamente sensible. Esto afectó la respuesta pública, la percepción internacional y la reconstrucción técnica de la secuencia de eventos.
Pero la comunicación deficiente no comenzó después de la explosión. Ya aparecía antes en la forma en que la información crítica sobre el diseño del RBMK, el efecto positivo de la parada de emergencia y la importancia de la ORM era transmitida, comprendida o incorporada a la operación.
INSAG-7 registra que el efecto positivo de inserción de las barras ya había sido identificado en otro RBMK, en la central de Ignalina, durante 1983. Existía la indicación de que se realizarían cambios de diseño para corregir el problema, pero las medidas no se implementaron suficientemente antes del accidente de Chernóbil.
Esta es una de las lecciones más duras del caso: una falla conocida, cuando no se trata con prioridad, deja de ser solo un problema técnico y se convierte en una falla de gobernanza.
¿Hubo sanciones? Sí, pero la rendición de cuentas fue limitada
Es importante tratar este punto con cuidado. Después del accidente hubo responsabilización penal de operadores y gestores locales. La narrativa pública inicial concentró gran parte del peso en las acciones del equipo de la central.
Pero esa responsabilización no agotaba el problema. El análisis técnico posterior mostró que las fallas de diseño, la cultura de seguridad, la comunicación institucional y la gobernanza tuvieron un papel central. En otras palabras, sancionar a personas involucradas en la operación no significó que el sistema institucional responsable de las vulnerabilidades hubiera sido plenamente responsabilizado desde el inicio.
Esta distinción es importante para cualquier análisis de accidentes: responsabilizar a individuos puede ser necesario, pero es insuficiente cuando el sistema en su conjunto produjo las condiciones para la falla.
Falla de gobernanza: ¿quién tenía autoridad para detener?
La pregunta central en los sistemas críticos no es solo “¿quién lo hizo?”, sino también “¿quién podía detenerlo?”
En Chernóbil aparecen varias preguntas de gobernanza:
- ¿quién aprobó el programa del ensayo?
- ¿quién evaluó sus implicaciones nucleares y no solo eléctricas?
- ¿quién validó los criterios de seguridad?
- ¿quién tenía autoridad para abortar el ensayo cuando la potencia cayó a 30 MWt?
- ¿quién garantizaba que la ORM estuviera dentro de un límite seguro?
- ¿quién comunicó a los operadores el riesgo del efecto positivo del AZ-5?
- ¿quién debía impedir la operación en una configuración prohibitiva?
- ¿quién integraba diseño, operación, seguridad y regulación?
Cuando estas respuestas no están claras, la seguridad depende de la improvisación. Y la improvisación es incompatible con sistemas críticos.
PMBOK, en su enfoque basado en principios, refuerza la importancia de gobernanza, responsabilidad, partes interesadas, planificación, calidad, riesgos, complejidad y adaptación al contexto. Aplicado a sistemas críticos, esto significa que las decisiones técnicas necesitan responsables claros, criterios de aceptación, trazas de aprobación, gestión de riesgos y autoridad formal para detener actividades inseguras.
Chernóbil muestra lo que ocurre cuando ingeniería, operación, política, regulación y gestión no forman un sistema de decisión seguro.
En un esquema robusto, la autoridad para detener no puede depender únicamente de la jerarquía operativa inmediata. Debe existir revisión independiente, segregación entre quien produce la evidencia y quien la acepta, criterios de escalamiento y protección institucional para decisiones conservadoras de seguridad.
Owner’s Engineering
La Ingeniería del Propietario crea una capa independiente entre propietarios, diseñadores, proveedores y operación para revisar premisas, riesgos, interfaces y criterios de aceptación.
El ensayo no era “solo eléctrico”
Uno de los puntos más importantes de INSAG-7 es la crítica a la clasificación del ensayo como puramente eléctrico. El ensayo de rundown involucraba la alimentación de las bombas principales, circuitos de energía, sistemas de protección y enclavamientos. Por tanto, tenía implicaciones directas para la seguridad nuclear.
Esta es una falla clásica de interfaz: una actividad aparentemente perteneciente a una disciplina técnica afecta a otra disciplina crítica. En proyectos complejos, muchos accidentes nacen precisamente en las interfaces.
En un proyecto moderno, un ensayo de este tipo exigiría matriz de riesgos, análisis multidisciplinario, validación por seguridad, criterios de aborto, simulación de escenarios, plan de puesta en servicio, aprobación formal y registro detallado de precondiciones.
Cuando una actividad que afecta la seguridad nuclear se trata como un ensayo eléctrico, la gobernanza falló antes de que comenzara el ensayo.
Además, una aprobación no permanece válida indefinidamente. Un cambio de turno, varias horas de retraso, alteración de potencia, reducción de márgenes o indisponibilidad de sistemas exigen una nueva verificación de las precondiciones. Continuar basándose en una autorización emitida para otro escenario convierte el plan de ensayo en una formalidad.
Puesta en Servicio y Aceptación Técnica
Los ensayos integrados necesitan precondiciones verificadas, matriz de responsabilidades, criterios de aborto, registros sincronizados y aceptación basada en evidencias.
Conozca el servicio de Puesta en Servicio y Aceptación Técnica
¿Qué enseña Chernóbil sobre ingeniería consultiva?
Chernóbil es un caso extremo, pero sus lecciones son válidas para sistemas críticos modernos. Subestaciones, data centers, centrales, centros de operación, hospitales, redes industriales y sistemas de telecomunicaciones también dependen de diseño, operación, supervisión, ensayos, documentación y gobernanza.
En todos estos entornos no basta con que el sistema funcione en operación normal. Debe responder correctamente en transiciones, fallas parciales, pérdida de alimentación, cambios de modo, operación degradada y emergencias.
Es en este punto donde entran prácticas de Owner’s Engineering, FEL, EPCM, puesta en servicio, auditoría técnica y due diligence técnica.
Estas prácticas ayudan al propietario del activo a formular preguntas que deben responderse antes de la operación:
- ¿qué variables son críticas para la seguridad?
- ¿esas variables son visibles y están registradas?
- ¿los ensayos cubren transiciones reales de operación?
- ¿los sistemas de protección fueron validados en condición degradada?
- ¿se revisaron las interfaces entre disciplinas?
- ¿quién puede detener una actividad insegura?
- ¿los riesgos están documentados y formalmente aceptados?
- ¿la operación recibió formación suficiente?
Estas preguntas son tan importantes como el cálculo, el plano o el equipo.
De Chernóbil a las infraestructuras críticas actuales
La discusión sobre Chernóbil también dialoga con los sistemas modernos de supervisión y control. En subestaciones e instalaciones críticas, soluciones como SCADA en el sector eléctrico, teleasistencia en subestaciones, monitoreo de seccionadores y proyecto de telecomunicaciones para subestaciones existen precisamente para ampliar la visibilidad operativa, registrar eventos, permitir diagnóstico y apoyar decisiones seguras.
Pero la tecnología de supervisión por sí sola no resuelve la gobernanza. Los datos deben ser interpretables. Las alarmas necesitan jerarquía. Las protecciones deben actuar automáticamente cuando se violan límites críticos. Los operadores deben comprender el significado de las variables. Los gestores deben respetar los criterios de parada.
La seguridad de los sistemas críticos es resultado de arquitectura técnica y cultura organizativa. Una sin la otra es insuficiente.
Entonces, ¿Chernóbil fue error humano, falla de diseño o falla de gobernanza?
Fue una combinación de los tres — pero la expresión “error humano” debe utilizarse con cuidado.
Hubo decisiones operativas inadecuadas. Hubo violación de límites. Hubo continuidad del ensayo en una condición peligrosa. Pero también existía un reactor con características de diseño peligrosas, un sistema de protección con comportamiento inicial desfavorable en ciertas condiciones, una variable crítica de seguridad poco visible, procedimientos insuficientes y fallas de comunicación entre organizaciones técnicas.
Sobre todo, hubo una falla de gobernanza: el sistema no impidió que se alcanzara una condición peligrosa, no hizo suficientemente visibles las variables críticas, no corrigió con urgencia vulnerabilidades conocidas y no estructuró una autoridad clara para detener el riesgo.
Por ello, la conclusión técnica más robusta es:
Chernóbil fue una falla sistémica de ingeniería, operación y gobernanza. El error humano existió, pero no explica por sí solo el accidente. El diseño creó vulnerabilidades; la operación llevó el reactor a una condición crítica; y las estructuras de gobernanza no impidieron que riesgos conocidos, márgenes degradados y decisiones de continuidad se combinaran.
Conclusión: la principal falla fue sistémica
La gran lección de Chernóbil no es únicamente que los operadores pueden equivocarse. La lección es que los sistemas críticos deben diseñarse, probarse, operarse y gobernarse considerando que las personas se equivocan, existen presiones, las señales pueden interpretarse mal y ocurren condiciones degradadas.
Un sistema seguro no depende de la perfección humana. Crea barreras para que los errores no se conviertan en catástrofes. Hace visibles las variables críticas. Impide configuraciones prohibitivas. Prueba transiciones. Registra decisiones. Corrige vulnerabilidades conocidas. Da autoridad real para detener actividades inseguras.
Chernóbil muestra el costo cuando esto no ocurre.
Para la ingeniería consultiva, este es el punto central: en proyectos críticos, la seguridad no es un ítem que se verifica al final. La seguridad es una arquitectura de decisiones, requisitos, pruebas, responsabilidades y gobernanza desde el inicio.
Para continuar el recorrido, el lector puede revisar la arquitectura del RBMK y avanzar hacia las modificaciones implementadas en los reactores RBMK después del accidente, cuando los riesgos reconocidos finalmente se convirtieron en cambios de diseño, protección y reglas operativas.
Referencias técnicas
[1] INTERNATIONAL ATOMIC ENERGY AGENCY. The Chernobyl Accident: Updating of INSAG-1. Safety Series No. 75-INSAG-7. Vienna: IAEA, 1992.
[2] SHTEYNBERG, N. A. et al. Causes and circumstances of the accident at Unit 4 of the Chernobyl Nuclear Power Plant. In: INTERNATIONAL ATOMIC ENERGY AGENCY. INSAG-7, Annex I. Vienna: IAEA, 1992.
[3] ABAGYAN, A. A. et al. Causes and circumstances of the accident and measures to improve the safety of plants with RBMK reactors. In: INTERNATIONAL ATOMIC ENERGY AGENCY. INSAG-7, Annex II. Vienna: IAEA, 1992.
[4] UNITED STATES NUCLEAR REGULATORY COMMISSION. Report on the Accident at the Chernobyl Nuclear Power Station. NUREG-1250. Washington, DC: NRC, 1987.
[5] UNITED STATES NUCLEAR REGULATORY COMMISSION. Implications of the Accident at Chernobyl for Safety Regulation. NUREG-1251. Washington, DC: NRC, 1987.
[6] INTERNATIONAL NUCLEAR SAFETY ADVISORY GROUP. Safety Culture. INSAG-4. Vienna: IAEA, 1991.
[7] INTERNATIONAL ATOMIC ENERGY AGENCY. RBMK Reactors. Technical description and safety characteristics of pressure-tube graphite-moderated reactors.
[8] CHERNOBYL NUCLEAR POWER PLANT. Sequence of events at Unit 4 on 25–26 April 1986. Technical chronology compiled from operating records.
[9] MUELLNER, Nikolaus. Three Decades after Chernobyl: Technical and Institutional Lessons. Vienna: University of Natural Resources and Life Sciences.
[10] PROJECT MANAGEMENT INSTITUTE. A Guide to the Project Management Body of Knowledge — PMBOK Guide. 7th ed. Newtown Square: PMI, 2021.
Preguntas frecuentes
Hubo decisiones operativas inadecuadas, pero no explican el accidente de forma aislada. INSAG-7 atribuye un peso relevante a fallas de diseño, comunicación, cultura de seguridad y gobernanza.
El coeficiente de vacío positivo, el diseño de las barras, la baja visibilidad de la ORM y protecciones insuficientes permitieron alcanzar una configuración vulnerable.
El documento revisó la narrativa inicialmente concentrada en los operadores y pasó a enfatizar deficiencias de diseño, comunicación, regulación y cultura de seguridad.
No como causa única. El contexto institucional influyó en prioridades, transparencia, jerarquía y capacidad de cuestionamiento, pero el accidente resultó de la interacción entre factores técnicos y organizativos.
Responsabilidades poco claras, riesgos conocidos sin tratamiento, ausencia de autoridad efectiva para detener, criterios de aceptación débiles y comunicación deficiente entre diseño, operación y regulación.
Porque modificaba la alimentación de bombas, enclavamientos, protecciones y condiciones termohidráulicas directamente relacionadas con la seguridad del núcleo.
Sí. El fenómeno había sido identificado en otro RBMK durante 1983, pero no se convirtió a tiempo en correcciones completas de diseño, protección y procedimientos.
La seguridad exige arquitectura técnica, gobernanza, independencia de revisión, datos confiables, criterios formales de interrupción y validación integrada de las interfaces.
Materiales técnicos complementarios
Soluciones
- Gestión de Requisitos, Evidencias y Criterios de Aceptación
- Sistemas SCADA
- Sistemas Digitales de Supervisión y Control
Servicios de ingeniería
Recorrido sobre Chernóbil
