Primero, creo que es importante tener en cuenta que la responsabilidad legal real variará caso por caso, nunca es tan simple como "Ellos fueron el ingeniero, es su culpa". En situaciones donde sucede algo y se formulan demandas, probablemente nombrarán a todas las compañías relacionadas y a todas las personas clave en esas compañías responsables del diseño. Sin embargo, creo que puedo dar una idea general basada en mis experiencias y lo que me han dicho en el entrenamiento de responsabilidad legal.
Personalmente, atribuyo la mayor parte de la culpa en esta situación al propietario, que utiliza planes que tienen años sin que nadie calificado los mire y los actualice. He visto problemas (pequeños) con esto en mi posición. Los dibujos se completan y se envían a otro departamento para su aprobación, y por cualquier motivo, se sientan en el escritorio de un ingeniero de aplicaciones durante meses, a veces cerca de un año o más. Los dibujos se envían tal cual, pero no se cumplen los cambios internos que se han realizado en los estándares de dibujo desde que los dibujos se actualizaron originalmente. Estos son problemas menores, pero es fácil ver que esto ocurra en una escala de tiempo más grande y con consecuencias más serias.
Los dibujos deben estar fechados. Esa es una práctica bastante común, y esta es una buena razón por la cual. Queremos saber cuándo se hicieron los dibujos, para determinar qué cosas han cambiado desde ese diseño, ya sean estándares, códigos, leyes o simplemente partes de interfaz. Si los dibujos se hacen con los códigos y estándares vigentes en ese momento, no veo cómo el ingeniero puede ser considerado responsable de ese diseño, a menos que se pueda demostrar que el ingeniero tenía conocimiento del código que necesitaba una revisión por seguridad cuestiones. En este caso, hacer que la impresión se ajuste al código no es lo suficientemente bueno, porque sabemos que el código no evitará algunos problemas.
Realmente se reduce al hecho de que, en el proceso de diseño, se deben tomar todas las consideraciones hacia la seguridad, y donde no se puede eliminar el riesgo, se debe aclarar cuál es el riesgo y cómo se puede mitigar al final. usuario.
En el segundo punto, esto suena como un área muy gris, y realmente no podría discutir ningún aspecto legal de esto. Pero diré que creo que, si un ingeniero sabe que el diseño que se está construyendo está desactualizado y podría causar problemas de alguna manera, tienen la responsabilidad ética de contactar a alguien que todavía esté afiliado al proyecto y comunicarles la situación. . Puede que no sea su responsabilidad legal, pero creo que claramente es lo correcto.
Casi debería dejar de decir que cualquier ingeniero aún afiliado al proyecto tiene la misma obligación, solo que más fuerte, de decir que los diseños deben actualizarse y que no pueden usarse en su forma actual.
Para dar un poco de contexto a esto, el producto principal que fabrica mi empresa puede ser extremadamente peligroso en su entorno operativo. Se requiere protección a menos que el producto esté completamente protegido por otras partes de la máquina. La protección en sí misma puede variar ligeramente de una compañía a otra, pero en gran medida es la misma porque se rige por un estándar ISO. Sin embargo, este estándar ha cambiado con los años, e incluso la organización que crea el estándar primario ha cambiado. Esto significa que tenemos diseños antiguos que cuentan con protecciones antiguas que aún están activas en nuestro sistema. Tenemos un empleado que conoce muy bien la industria y, en particular, los códigos de seguridad e incluso forma parte de algunos comités de seguridad. Se asegura de que los nuevos diseños cumplan con los estándares de protección y que los productos antiguos se actualicen según sea necesario. A veces, esto significa ir tan lejos como para decirle al cliente que no les venderemos este producto si no nos permiten actualizar la protección (la protección más nueva en algunos casos es más costosa). No siempre es la persona más popular, pero este es su trabajo, y así es como gestionamos el cumplimiento de nuestro código en un mundo donde los códigos y estándares no son consistentes.