Permissão de Trabalho Digital e Segregação de Funções HSE

# Permissão de Trabalho Digital: Porque é que o Sistema Tem de Recusar a Sua Própria Assinatura

TL;DR: Se o mesmo utilizador consegue pedir uma permissão de trabalho e emiti-la, o sistema está a gerar um registo de uma aprovação que nunca foi verificada por outra pessoa — e isso invalida o propósito legal e operacional da permissão, mesmo que o formulário esteja tecnicamente completo.

O formulário certo, assinado pela pessoa errada

Uma permissão de trabalho (permit to work, PTW) existe para uma razão muito específica: obrigar uma segunda pessoa, com autoridade e informação que o requisitante não tem, a confirmar que uma tarefa perigosa — trabalho a quente, entrada em espaço confinado, escavação, trabalho em altura, intervenção em linha energizada — pode avançar em segurança naquele momento, naquele local, com aquelas condições. A permissão não é o documento. É o acto de uma pessoa distinta ter olhado para o pedido e dito "sim, mas".

Isto é fácil de dizer em papel. É surpreendentemente fácil de destruir em software.

Quando uma equipa digitaliza o processo de HSE, o instinto natural é replicar o formulário: campos para a descrição do trabalho, riscos identificados, EPI necessário, isolamentos, assinatura do requisitante, assinatura do emissor. O problema aparece na camada que ninguém desenha de propósito — o controlo de acesso. Se o mesmo utilizador tem permissão para preencher o campo "requisitante" e o campo "emissor" na mesma sessão, o sistema não está a impor uma segunda verificação independente. Está a produzir um PDF com duas assinaturas onde só existiu uma decisão.

Isto não é uma falha teórica. É a falha mais comum em sistemas de permissão de trabalho construídos à pressa, porque o caminho de menor resistência em qualquer formulário web é permitir que o utilizador autenticado preencha tudo o que vê no ecrã. Ninguém decide deliberadamente permitir auto-emissão — ela sobrevive porque ninguém decide explicitamente impedi-la.

Segregação de funções não é burocracia, é a definição da prova

Em auditoria financeira, a segregação de funções (quem autoriza uma despesa não pode ser quem a processa, quem recebe mercadoria não pode ser quem a encomendou) existe para que uma assinatura signifique alguma coisa. Já descrevemos este mesmo princípio a propósito de aprovações de capital, onde a folha de cálculo falha precisamente por não conseguir impedir que o mesmo utilizador aprove o seu próprio pedido — ver AFE e Controlo de Capital: Porque é que a Folha de Cálculo Falha Sempre no Momento Errado. O princípio em HSE é idêntico, mas as consequências de o violar são mais graves: em finanças, uma auto-aprovação mal feita produz uma factura incorrecta; numa permissão de trabalho, produz um trabalhador a fazer corte com maçarico junto de uma linha que ninguém confirmou estar despressurizada.

A regulamentação da OSHA sobre controlo de energia perigosa (LOTO — lockout/tagout, 29 CFR 1910.147) contém um exemplo directo e verificável deste princípio aplicado à isolação de energia: a inspecção periódica de cada procedimento de controlo de energia tem de ser realizada por um funcionário autorizado diferente daquele(s) que estão a utilizar esse procedimento, e o empregador tem de certificar quem fez a inspecção, quando e sobre que equipamento — pelo menos uma vez por ano (OSHA, 29 CFR 1910.147; OSHA, Periodic Inspections). Não é um "seria melhor" — é uma exigência regulatória explícita de que a verificação de um controlo de segurança não pode ser feita pela mesma pessoa que o aplicou.

A orientação sectorial sobre permissões de trabalho segue a mesma lógica em ambas as direcções. A guia da EIGA (European Industrial Gases Association) sobre sistemas de permissão de trabalho diz que, para um sistema robusto, devem estar envolvidas no local de trabalho pelo menos duas pessoas — o emissor e o receptor da permissão — e que trabalhadores isolados não devem poder redigir uma permissão para si próprios (EIGA, Doc 040 — Work Permit Systems, secção 2.1). A segunda pessoa é o que traz um olhar independente sobre riscos que o requisitante, focado na tarefa, pode não ver. O Health and Safety Executive do Reino Unido publica uma guia dedicada especificamente à indústria petrolífera, química e afins sobre sistemas de permissão de trabalho, cobrindo formação, competência, planeamento do trabalho e auditoria do sistema (HSE, HSG250) — o facto de existir uma publicação inteira dedicada a este tema, e não apenas uma cláusula genérica, diz alguma coisa sobre quantas vezes a segregação de funções falha na prática.

O que muda quando se desenha isto a sério

A diferença entre um formulário digital e um controlo real está em três decisões de desenho concretas.

1. Dois utilizadores reais, não dois campos. O sistema tem de identificar o requisitante e o emissor como duas contas distintas, autenticadas separadamente, com um userId diferente gravado em cada campo de assinatura. Isto parece óbvio, mas exige que o modelo de dados separe explicitamente requestedByUserId de issuedByUserId — e que a lógica de negócio rejeite a gravação sempre que os dois IDs coincidirem, independentemente do que o formulário do lado do cliente mostra ou esconde. Validação apenas na interface (esconder o botão "emitir" para quem pediu) não é controlo — é decoração, contornável por qualquer utilizador que chame a API directamente.

2. Papéis distintos, não apenas utilizadores distintos. Não basta que sejam duas pessoas — a segunda pessoa tem de ter autoridade formal para emitir aquele tipo específico de permissão. Uma permissão de trabalho a quente, por exemplo, tipicamente exige um emissor com competência e autorização registadas para esse risco específico, não apenas alguém com uma conta activa no sistema. Isto liga-se directamente ao modelo de RBAC (controlo de acesso baseado em papéis) do sistema, onde o papel "Emissor de Permissões — Trabalho a Quente" é uma autorização concedida deliberadamente, não um efeito colateral de ter uma sessão iniciada — ver Permissões que Não Mentem: RBAC e Trilho de Auditoria Imutável num ERP Industrial.

3. Trilho de auditoria imutável, gravado ao nível da transacção. Cada mudança de estado da permissão — pedida, revista, emitida, suspensa, encerrada — tem de ficar registada com o utilizador, o timestamp e, quando aplicável, a justificação, num registo que não pode ser reescrito depois do facto. Se um inquérito a um incidente precisar de reconstruir "quem sabia o quê, e quando", a resposta tem de estar na base de dados, não na memória de quem estava de turno.

A tabela seguinte resume o que separa um formulário de um controlo:

Elemento	Formulário digital	Controlo com segregação de funções
Campos requisitante/emissor	Dois campos de texto no mesmo ecrã	Duas contas de utilizador distintas, obrigatórias por regra de negócio no servidor
Verificação da regra	Apenas na interface (esconder botão)	Aplicada na camada de serviço/API, rejeitando `requestedByUserId == issuedByUserId`
Autoridade do emissor	Qualquer utilizador com sessão iniciada	Papel RBAC específico para o tipo de risco (ex.: trabalho a quente, espaço confinado)
Registo de decisão	PDF gerado, sem histórico de estados	Trilho de auditoria imutável por evento, com timestamp e utilizador
Ligação ao isolamento de energia	Nenhuma, ou manual	Permissão bloqueada até o isolamento estar confirmado como lista separada e testável

Ligar a permissão ao ciclo de isolamento de energia

A parte que mais frequentemente falta em implementações apressadas é a ligação bidireccional entre a permissão e o isolamento físico de energia (LOTO). Uma permissão de trabalho a quente ou de manutenção mecânica não deveria poder ser emitida enquanto a lista de isolamentos associada — que válvulas foram fechadas, que disjuntores foram desligados e bloqueados, que linhas foram despressurizadas e testadas — não estiver registada como confirmada por quem executou fisicamente o isolamento. E o inverso também tem de ser verdade: o isolamento não deveria poder ser removido enquanto a permissão dependente ainda estiver aberta.

Isto exige um terceiro papel distinto do requisitante e do emissor: quem aplica e confirma o isolamento no terreno. Em muitas operações esse é o mesmo "funcionário autorizado" a que a OSHA se refere no 1910.147 — a pessoa que coloca o cadeado e a etiqueta —, mas o ponto de desenho é o mesmo: o sistema tem de recusar tecnicamente que a permissão avance sem essa confirmação separada, exactamente como recusa a auto-emissão. Já descrevemos como este tipo de disciplina de registo de inspecções e incidentes se estende ao resto do programa de HSE em HSE Digital em Angola: Inspecções, EPI e Incidentes Que Deixam Rasto Auditável.

O enquadramento legal em Angola

Em Angola, a Lei Geral do Trabalho (Lei n.º 12/23, de 27 de Dezembro de 2023) estabelece o quadro geral de segurança e saúde no trabalho, e o Decreto n.º 31/94, de 5 de Agosto, continua a ser a base regulamentar que fixa os princípios de promoção da Segurança, Higiene e Saúde no Trabalho (LEX.AO — Decreto n.º 31/94). Mais recentemente, o Decreto Presidencial n.º 179/24, de 1 de Agosto, aprovou o Regulamento sobre o Licenciamento para o Exercício de Serviços de Segurança, Higiene e Saúde no Trabalho (SHST): fixa as regras dos serviços de SHST e o seu registo e autorização junto da Inspecção Geral do Trabalho, aplica-se também às empresas que já tinham esses serviços em funcionamento e impõe um relatório anual dos serviços de SHST (Miranda Advogados, 2024; LEX.AO — Decreto Presidencial n.º 179/24).

Nenhum destes diplomas prescreve o desenho de um sistema informático — mas todos partilham a mesma lógica que sustenta a exigência da OSHA sobre inspecções periódicas de LOTO: a competência formal e a independência de quem verifica um controlo de segurança são elementos do próprio controlo, não um detalhe administrativo. Um sistema que permite que a mesma pessoa peça e emita uma permissão está, na prática, a documentar uma competência de emissor que nunca foi exercida — o que é uma exposição tanto operacional como perante uma inspecção do trabalho ou uma investigação de incidente.

O erro que reaparece em produção: o "modo super-utilizador"

Mesmo sistemas bem desenhados falham aqui de uma forma previsível: alguém, normalmente um administrador com boas intenções durante um período de pressão operacional, ganha acesso a um papel que devia estar reservado à emissão e ao pedido de permissões ao mesmo tempo — "só desta vez, porque não há mais ninguém de serviço". Cada excepção destas, se não for tecnicamente impossível ao nível do modelo de dados e da API, torna-se eventualmente a norma silenciosa, porque a pressão para contornar o processo é constante e a pressão para o respeitar só aparece depois de um incidente.

É por isso que a segregação de funções não pode viver na política escrita nem no manual de procedimentos. Tem de estar na estrutura das tabelas, nas restrições da base de dados e na lógica de validação do lado do servidor — o tipo de trabalho que exige software construído para o processo real da operação, e não um formulário genérico adaptado depois dos factos. É esse o motivo pelo qual este tipo de controlo, tal como outros fluxos de aprovação sensíveis em ambientes industriais, normalmente só se consegue de forma fiável com software à medida desenhado em torno do processo de segurança real, e não encaixado num produto genérico de gestão de tarefas.

Perguntas frequentes

Uma pessoa pode acumular o papel de requisitante e emissor em situações de equipa reduzida, como um turno nocturno com pouco pessoal?

Do ponto de vista de desenho de sistema, não deveria ser tecnicamente possível para o mesmo utilizador desempenhar ambos os papéis na mesma permissão, independentemente do tamanho da equipa. Se a operação tem de funcionar com pessoal reduzido, a resposta correcta é ter um plano de contingência com um segundo emissor à distância (por telefone ou vídeo, com registo dessa autorização remota), não abrir uma excepção no sistema. A OSHA aplica exactamente esta lógica à inspecção periódica de LOTO, exigindo sempre um funcionário diferente daquele que usa o procedimento.

Isto aplica-se só a trabalho a quente, ou a todos os tipos de permissão?

O princípio aplica-se a qualquer permissão que autorize uma actividade de alto risco — trabalho a quente, entrada em espaço confinado, escavação, trabalho em altura, intervenção eléctrica. O nível de competência exigido ao emissor varia consoante o risco (um emissor de trabalho a quente pode não ter autorização para emitir uma entrada em espaço confinado), mas a regra de que requisitante e emissor têm de ser utilizadores distintos, com papéis distintos, não muda.

Que diferença faz isto numa investigação de incidente ou numa inspecção regulatória?

Um trilho de auditoria que mostra requestedByUserId diferente de issuedByUserId, com timestamps e o papel RBAC de cada utilizador nesse momento, prova que a segunda verificação ocorreu. Sem esse registo, uma permissão assinada duas vezes pela mesma pessoa é, na prática, indistinguível de uma permissão nunca revista — e essa é precisamente a pergunta que um inspector do trabalho ou um investigador de acidente vai fazer primeiro.

Vale a pena adaptar um sistema de gestão de tarefas genérico para isto, ou é preciso construir de raiz?

Depende do quanto o produto genérico permite impor regras de validação ao nível do servidor (não apenas da interface) e de gerar um trilho de auditoria imutável e consultável. Muitos produtos de checklist digital replicam o formulário em papel sem impor a regra de negócio subjacente — nesse caso, a "digitalização" preserva a aparência do controlo sem preservar o controlo em si.

Permissão de Trabalho Digital: Porque é que o Sistema Tem de Recusar a Sua Própria Assinatura