Se procura um Exemplo de avaliação de risco ISO 12100, comece por uma verdade desconfortável: o pior tipo de avaliação de risco não é caótico. É bonito. Tem tabela, pontuação, normas, comentários e um PDF final que dá à equipa aquela sensação agradável de assunto fechado. Só que a ISO 12100 não avalia estética. Avalia se alguém conduziu, de facto, o processo de segurança da máquina. E é aqui que muita documentação falha. Uma folha de Excel não vigia a lógica, não obriga a passar das limitações da máquina para os cenários reais de tarefa e não pergunta se a medida de proteção criou risco secundário. Parece profissional. Não prova o processo.
Exemplo de avaliação de risco ISO 12100: porque Excel não é documentação
Convém dizer isto sem rodeios: a ISO 12100 não pede um Excel. Pede documentação da avaliação de risco. E não, não é a mesma coisa.
Uma folha de cálculo pode ser útil. Pode servir de bloco de notas, de apoio de equipa, de rascunho técnico. Pode reunir perigos, pontuações, referências normativas, medidas de proteção e comentários. Tudo isso é válido como matéria-prima. O problema começa quando se finge que essa matéria-prima já é a documentação final.
A documentação da avaliação de risco tem de mostrar mais do que o resultado. Tem de mostrar o caminho. Tem de deixar claro:
- quais são as limitações da máquina;
- qual é a utilização prevista e a utilização indevida razoavelmente previsível;
- quais são as tarefas reais do operador, da manutenção e da assistência técnica;
- que situações perigosas e que eventos perigosos foram analisados;
- como foi feita a estimativa do risco inicial;
- que medida de proteção foi escolhida e porquê;
- em que ordem foi aplicada a lógica de redução exigida pela ISO 12100;
- se apareceu risco secundário;
- como foi avaliado o risco residual;
- quem decidiu o quê e com base em quê.
É aqui que a diferença entre tabela e engenharia se torna gritante. A tabela guarda campos. A engenharia guarda raciocínio. E quando chega a hora de defender o processo num dossiê CE, numa auditoria ou depois de um incidente, não é a tabela bonita que salva ninguém. É a lógica técnica, rastreável e coerente.
Outro erro clássico? Saltar diretamente do perigo para o resguardo, para o procedimento ou para a instrução, como se a sequência da ISO 12100 fosse decoração. Não é. A lógica é esta:
- primeiro, conceção intrinsecamente segura;
- depois, medidas de proteção técnicas e complementares;
- só no fim, informação de utilização.
Se o documento não mostra essa progressão, o processo já nasceu torto. E um ficheiro torto continua torto, mesmo que tenha logótipo, cor institucional e um PDF impecável.
Risco secundário: o ponto onde muita avaliação começa a fingir
Muita gente trata a medida de proteção como ponto final. Colocou-se um resguardo, instalou-se um interbloqueio, definiu-se um rearme manual, escreveu-se um procedimento. Assunto resolvido. Não. A medida de proteção não fecha o processo. Altera o sistema de risco.
É precisamente aí que entra o risco secundário. E não, não é um detalhe para perfecionistas. É um dos testes mais sérios para perceber se a equipa está a avaliar risco ou apenas a preencher colunas.
Exemplo mecânico: o resguardo melhora o movimento, mas piora a intervenção
Imagine uma zona com acesso frequente para limpeza ou remoção de encravamentos. A equipa instala um resguardo móvel com interbloqueio. À primeira vista, excelente: durante o ciclo automático, o acesso à zona perigosa fica limitado.
Mas depois aparece a vida real. Para intervir, o operador tem agora de alcançar mais fundo, trabalhar com a mão em espaço reduzido, ver pior e adotar posturas menos naturais. O risco principal de contacto com o movimento pode baixar, sim. Mas nasceu outro problema: pior acesso, pior visibilidade, pior ergonomia, maior probabilidade de erro na intervenção. Se isto não for revisto, a documentação conta só metade da história.
Exemplo elétrico: melhor proteção contra choque, mais probabilidade de erro de processo
No quadro elétrico, a equipa melhora a segregação de circuitos, reforça a envolvente, formaliza a isolação, a verificação de ausência de tensão e o acesso apenas a pessoas autorizadas. Tudo certo. Só que a operação de diagnóstico fica mais longa, mais sequencial e mais sensível a atalhos organizacionais. E então surge a pergunta séria: ao reduzir o risco de choque elétrico, não aumentámos o risco de passo falhado, responsabilidade difusa ou execução fora de sequência?
É assim que o risco secundário aparece: não como rodapé, mas como consequência direta de uma medida que mexeu no equilíbrio entre pessoa, máquina, energia e processo.
Exemplo de avaliação de risco ISO 12100: quando a medida de proteção cria outro problema
Vamos tornar isto ainda mais concreto. Uma medida de proteção pode mesmo criar um perigo mais grave do que aquele que pretendia reduzir. Sim, acontece. E acontece mais vezes do que se admite em reuniões de projeto.
Resguardo pesado que troca escoriações por esmagamento
Numa máquina existe contacto frequente com a aresta de um componente móvel. O efeito inicial é relativamente ligeiro: escoriações, pancadas superficiais, pequenas lesões. A solução adotada é um resguardo articulado. No papel, ótimo. Na prática, o resguardo é grande, pesado e pode cair sem controlo se for largado ou mal suportado. Resultado: aparece risco de impacto, entalamento ou mesmo esmagamento de mão e dedos entre o resguardo e a estrutura fixa. Formalmente resolveu-se um problema. Tecnicamente pode ter-se criado outro com consequências mais severas.
Lógica de automação correta que incentiva o contorno
Agora imagine uma célula com interbloqueio, rearme manual e bloqueio do rearranque automático após abertura do resguardo. A função de segurança pode estar correta. O erro não está necessariamente na função. O erro pode estar na forma como ela foi integrada na tarefa real. Se cada intervenção passar a demorar mais, quebrar demasiado o ritmo ou exigir passos pouco intuitivos, começa o comportamento de risco: rearme por reflexo, verificação incompleta da zona antes do arranque, tentativas de neutralizar dispositivos de proteção e pressão operacional para acelerar o ciclo fora da lógica prevista.
Neste caso, o problema não é dizer que existe uma função de segurança. O problema é não verificar como essa função altera o comportamento humano. A segurança que existe no esquema pode falhar na fábrica.
Ligação equipotencial parcial que aumenta a diferença de potencial
No domínio elétrico, há outro clássico. Alguém deteta um problema localizado e decide melhorar a segurança criando uma ligação equipotencial apenas num elemento da máquina. A intenção é boa. A execução fragmentada pode ser péssima. Se apenas uma parte do conjunto passa a ter uma referência diferente, podem surgir cenários em que, perante uma falha ou um estado transitório, existe maior diferença de potencial entre partes acessíveis. A pessoa que toca em dois pontos do sistema ao mesmo tempo fica exposta a uma situação perigosa pior do que a anterior.
O padrão repete-se nos três casos: alguém fez algo que parece sensato à primeira vista, mas ninguém verificou o efeito sobre o resto do sistema pessoa-máquina-energia-processo. E é por isso que o risco secundário não é acessório. É central.
Rasto de auditoria: a prova de que alguém pensou
Há outra falha que destrói avaliações de risco aparentemente arrumadas: a ausência de rasto de auditoria. O resultado final pode estar lá. A pontuação também. A medida de proteção idem. Mas passadas duas semanas, ninguém sabe responder ao básico:
- quem alterou a classificação da situação perigosa;
- quando foi feita a alteração;
- porque é que o risco foi considerado aceitável;
- porque é que num caso bastou informação de utilização e noutro foi necessária uma função de segurança;
- em que fundamento técnico assentou a escolha de PL d.
O documento final mostra o destino. O rasto de auditoria mostra a viagem. E, em avaliação de risco, a viagem é tudo.
Pense em três situações muito comuns:
- Alguém baixa a gravidade ou a probabilidade de uma situação perigosa e, um mês depois, já ninguém sabe se isso aconteceu por nova medida de proteção, por revisão do cenário ou apenas para fechar o documento.
- Um risco fica marcado como baixo e aceitável, mas sem justificação técnica sobre frequência de exposição, gravidade previsível, condições de execução e perfil do utilizador.
- Aparece uma linha impecável com função de segurança, ISO 13849 e PL d, mas ninguém consegue explicar o que a função monitoriza, o que corta, em que condição atua e porque foi exigido precisamente esse nível.
Sem rasto de auditoria, tudo isto fica achatado numa versão final que parece estável, mesmo que tenha sofrido cinco mudanças relevantes pelo caminho. Uma folha de Excel permite sobrepor células, corrigir descrições e ajustar números. O que ela faz mal é preservar a lógica das mudanças. E sem lógica preservada, não se defende a avaliação de risco. Defende-se apenas a última versão do ficheiro.
Exemplo de avaliação de risco ISO 12100: caso prático numa célula de embalagem
Vamos à prática. Num Exemplo de avaliação de risco ISO 12100 aplicado a uma célula automatizada de embalagem, a análise não ficou em duas ou três entradas genéricas do tipo risco mecânico, risco elétrico e risco pneumático. Isso é curto. Curto demais para uma máquina real.
Neste caso, foram identificadas dezasseis situações distintas: treze cenários de tarefa e três eventos perigosos segundo a lógica da ISO 12100. Foram analisadas, separadamente, situações como:
- pequenas intervenções durante o funcionamento;
- remoção de encravamentos;
- ajuste de dispositivos de proteção;
- testes funcionais;
- isolação de energia e LOTO;
- substituição de componentes de desgaste;
- diagnóstico de avarias;
- arranque não intencional;
- projeção de objetos;
- libertação de energia pneumática.
É este nível de detalhe que mostra a realidade. Não se avalia a máquina em abstrato. Avalia-se a relação entre a pessoa e a máquina, numa tarefa concreta, numa zona concreta, sob condições concretas.
E o que é que o caso revelou?
Primeiro: o risco principal não estava simplesmente na existência de movimento perigoso. Estava no acesso ao movimento durante intervenção, desbloqueio e diagnóstico. Isto muda tudo, porque obriga a olhar para a tarefa e não apenas para a fonte de perigo.
Segundo: alguns cenários podiam ser considerados de baixo risco e aceites, mas apenas porque estavam claramente limitados em frequência, duração, condições de execução e perfil do utilizador. Não foi o número por si só que os tornou aceitáveis. Foi a justificação técnica.
Terceiro: os cenários intermédios e críticos não se defendiam com a fórmula preguiçosa resguardo mais instrução. Foi necessário descrever a função de segurança, a lógica de interbloqueio, o bloqueio do rearranque, o rearme manual, as condições de acesso e o risco residual. Em alguns pontos, a discussão sobre ISO 13849 e PL d teve de estar ligada ao cenário real e não a um automatismo de catálogo.
Quarto: a reavaliação depois da medida de proteção foi decisiva. Sem ela, não se apanhava o risco secundário nem se justificava o risco residual.
Quinto: o rasto de auditoria mostrou quem aceitou determinados cenários e porquê. E isto não é burocracia. É memória de engenharia.
O que uma boa documentação da avaliação de risco tem de mostrar
Se quiser testar a robustez do seu documento, faça uma verificação simples. Uma boa documentação da avaliação de risco deve permitir perceber, sem adivinhas:
- para que serve a máquina e onde estão as suas limitações;
- quem interage com ela e em que tarefas;
- que perigo, situação perigosa e evento perigoso foram considerados;
- qual foi a estimativa do risco inicial;
- se o risco foi aceite ou enviado para redução;
- que medida de proteção foi escolhida e em que sequência;
- se apareceu risco secundário após a implementação;
- como foi estimado o risco residual;
- quem tomou cada decisão relevante.
Se o documento não permite reconstruir isto, então pode estar bem apresentado, mas continua a ser apenas um conjunto de dados de trabalho.
Conclusão: tabela bonita não fecha processo
A conclusão é simples e pouco simpática: uma avaliação de risco fraca não costuma parecer fraca. Costuma parecer impecável. É precisamente por isso que engana equipas inteiras.
O Excel pode ajudar. Claro que pode. Mas não garante sequência lógica, não força reavaliação, não apanha sozinho o risco secundário e não cria, por magia, rasto de auditoria. E a ISO 12100 não pergunta se o ficheiro está bonito. Pergunta se o processo foi realmente conduzido, documentado e se pode ser verificado mais tarde.
Por isso, antes de celebrar o PDF final, faça três perguntas duras: consegue reconstruir as decisões, consegue justificar o risco residual e consegue provar por que razão aquela medida de proteção tornou a máquina realmente mais segura? Se a resposta for não, ainda não tem uma boa documentação da avaliação de risco. Tem apenas uma tabela com ar sério.