A deteção em menos de 200ms não significa nada se o alerta nunca chega à sala de controle. E chegar à sala de controle não significa nada se ninguém sabe o que fazer com ele. E saber o que fazer com ele não significa nada se não houver ninguém com autoridade para agir disponível no momento certo.
O valor de um sistema de deteção por IA é realizado na cadeia que vai desde o evento detetado até a intervenção que o previne. Cada elo dessa cadeia pode falhar. Este artigo mapeia os quatro modos de falha mais comuns e como projetar contra eles.
A cadeia de alerta completa
Uma cadeia de alerta de segurança tem seis elos:
- Deteção: o modelo de IA identifica o evento (conflito veículo-pedestre, violação de zona, queda)
- Classificação: o sistema determina o nível de urgência e o protocolo de resposta
- Roteamento: o alerta vai para o respondedor correto através do canal correto
- Reconhecimento: o respondedor confirma o recebimento do alerta
- Avaliação: o respondedor avalia a situação e determina a ação
- Intervenção: a ação de resposta é executada
A deteção é onde a tecnologia é mais eficaz; a intervenção é onde os humanos são mais eficazes. Os quatro modos de falha entre eles são todos gerenciáveis — mas só se você os projetar explicitamente.
Modo de falha 1: Roteamento errado
O alerta mais rápido do mundo é inútil se vai para um painel que ninguém está a monitorizar. Um sistema que envia alertas de veículo-pedestre para um e-mail verificado duas vezes por dia, ou para o display da sala de controle que fica apagado quando não há ninguém presente, não está a funcionar.
A solução é mapeamento explícito de resposta: para cada tipo de alerta e cada período de tempo, quem recebe o alerta, através de que canal, com que confirmação de entrega, e com que protocolo de escalada se o reconhecimento inicial não acontecer dentro de um tempo de resposta definido.
Modo de falha 2: Fadiga de alerta
Um sistema com uma taxa de falsos positivos de 5% que processa 400 eventos por dia gera 20 falsos alarmes por dia. Numa semana, a equipe de resposta aprendeu que a maioria dos alertas é ruído. Na segunda semana, os alertas genuínos estão a ser ignorados juntamente com os falsos.
A única solução para a fadiga de alerta é reduzir os alertas falsos — o que requer modelos de deteção de qualidade suficientemente alta para manter a taxa de erro abaixo de limiares onde a fadiga não se desenvolve. A taxa de erro abaixo de 0,05% da SecureSafety não é um detalhe técnico; é a condição necessária para que a cadeia de alerta funcione a longo prazo.
Modo de falha 3: Lacuna de autoridade
Um operador de sala de controle que recebe um alerta de veículo-pedestre de alta urgência pode precisar de contactar um supervisor de turno, que precisa de contactar um gestor de operações, antes de alguém com autoridade para parar o veículo ou evacuar a área estar no circuito. Para a maioria dos eventos, isto é demasiado lento.
A solução é pré-autorização: documentar explicitamente que o operador de sala de controle tem autoridade para transmitir um aviso PA de zona, contactar o rádio de supervisor de pátio e instruir paragem de veículo, sem esperar pela aprovação da gestão. Os procedimentos de resposta de emergência devem definir o que cada respondedor de alerta está autorizado a fazer sem aprovação superior.
Modo de falha 4: Falta de ciclo de feedback
O alerta foi enviado. O respondedor reconheceu. A intervenção aconteceu — ou não. A maioria dos sistemas de alerta nunca fecha o loop. Não há nenhum registo de se o respondedor chegou a tempo, se a intervenção foi eficaz, ou se o evento se converteu num incidente apesar do alerta.
Sem esse dado, é impossível melhorar a cadeia de alerta ao longo do tempo. Com ele, o ciclo de revisão semanal de gestão de segurança pode identificar quais tipos de alerta estão a ser geridos eficazmente e quais estão a cair através de lacunas no protocolo de resposta.
O design do alerta é tão importante quanto a deteção
A tecnologia de deteção cria a condição necessária para a intervenção. A design da cadeia de alerta determina se essa condição é realizada. Ambas precisam de receber igual atenção antes que um sistema seja considerado operacional.
