Primeiro, acho importante observar que a responsabilidade legal real varia caso a caso, nunca é tão simples como "Eles eram os engenheiros, a culpa é deles". Nas situações em que algo acontece e ações judiciais são elaboradas, eles provavelmente vão nomear todas as empresas que estão relacionadas e todas as pessoas-chave nas empresas responsáveis pelo design. No entanto, acho que posso dar uma visão geral com base em minhas experiências e no que me foi dito no treinamento em responsabilidade legal.
Pessoalmente, coloco a maior parte da culpa nessa situação no proprietário, que usa planos com anos de idade sem que alguém qualificado os veja e os atualize. Já vi (pequenos) problemas com isso na minha posição. Os desenhos são concluídos e enviados para outro departamento para aprovação e, por qualquer motivo, ficam na mesa de um engenheiro de aplicativos por meses, às vezes perto ou mais de um ano. Os desenhos são enviados como estão, mas as alterações internas que foram feitas nos padrões de desenho desde que os desenhos foram atualizados originalmente não são cumpridas. Esses são problemas menores, mas é fácil ver isso ocorrendo em uma escala de tempo maior e com consequências mais graves.
Os desenhos devem ser datados. Essa é uma prática bastante comum, e esse é um bom motivo. Queremos saber quando os desenhos foram feitos, para determinar o que mudou desde o design, sejam padrões, códigos, leis ou simplesmente peças de interface. Se os desenhos forem feitos com os códigos e normas em vigor naquele momento, não vejo como o engenheiro pode ser responsabilizado por esse projeto, a menos que seja demonstrado que o engenheiro tinha conhecimento do código que precisava de uma revisão de segurança problemas. Nesse caso, ajustar a impressão ao código não é bom o suficiente, porque sabemos que o código não impedirá alguns problemas.
Tudo se resume ao fato de que, no processo de projeto, todas as considerações em relação à segurança precisam ser tomadas e, onde o risco não pode ser eliminado, é preciso esclarecer qual é o risco e como ele pode ser mitigado até o final. do utilizador.
No segundo ponto, isso parece uma área muito cinzenta, e eu realmente não pude discutir nenhum aspecto legal disso. Mas direi que acho que, se um engenheiro souber que o design que está sendo construído está desatualizado e puder causar problemas de alguma maneira, ele terá uma responsabilidade ética de entrar em contato com alguém ainda afiliado ao projeto e avaliá-lo da situação. . Pode não ser sua responsabilidade legal, mas acho que é claramente a coisa certa a se fazer.
É quase desnecessário dizer que qualquer engenheiro ainda afiliado ao projeto tem a mesma obrigação, porém mais forte, de dizer que os projetos precisam ser atualizados e não podem ser usados em sua forma atual.
Para contextualizar isso, o principal produto que minha empresa fabrica pode ser extremamente perigoso em seu ambiente operacional. A proteção é absolutamente necessária, a menos que o produto esteja totalmente protegido por outras partes da máquina. A proteção em si pode variar um pouco de empresa para empresa, mas é basicamente a mesma porque é governada por um padrão ISO. No entanto, esse padrão mudou ao longo dos anos e até a organização que cria o padrão primário mudou. Isso significa que temos projetos antigos que apresentam uma proteção antiga que ainda está ativa em nosso sistema. Temos um funcionário que conhece muito bem o setor e, em particular, os códigos de segurança, e até mesmo participa de alguns comitês de segurança. Ele garante que os novos projetos cumpram os padrões de proteção e que os produtos antigos sejam atualizados conforme necessário. Às vezes, isso significa dizer ao cliente que não venderemos esse produto se ele não nos permitir atualizar a proteção (a proteção mais recente é, em alguns casos, mais cara). Ele nem sempre é a pessoa mais popular, mas esse é o trabalho dele, e é assim que gerenciamos nossa conformidade com códigos em um mundo onde códigos e padrões não são consistentes.