---
title: "O que o seu sistema de garantia não está lhe dizendo"
slug: o-que-o-seu-sistema-de-garantia-nao-esta-lhe-dizendo
series: "What the Wreckage Taught Us — 2025–2026"
audience: csuite
pillar: "Condições latentes"
lang: pt
published_at: Junho de 2026
author: "Bruno Hounkpati"
reading_time: "7 min de leitura"
tags: ["Governança de segurança", "Supervisão do conselho", "Condições latentes", "Garantia"]
description: "Um documento de segurança plenamente aprovado silenciou sobre a condição que matou sete pessoas. O que os conselhos devem exigir de sua garantia."
canonical: https://riskopilot.com/pt/blog/o-que-o-seu-sistema-de-garantia-nao-esta-lhe-dizendo
---
# O que o seu sistema de garantia não está lhe dizendo

*O Bayesian, visto do conselho*

> Os proprietários estavam em conformidade. Mesmo assim, sete pessoas morreram em uma condição que nenhum documento descrevia.

## Executive insight

O veleiro Bayesian estava classificado, certificado e em conformidade quando emborcou perto da Sicília em menos de 15 segundos, matando sete das 22 pessoas a bordo. O MAIB britânico determinou que a falha não foi uma regra descumprida, mas uma condição que seu documento de estabilidade aprovado nunca descreveu — o ângulo em que a embarcação perderia estabilidade em seu estado operacional real, nunca calculado, nunca no caderno. Para um conselho, a lição não é náutica. É que a aprovação não é garantia, e que a metodologia de investigação que você impõe decide as conclusões que tem o direito de ouvir. Daí surgem duas perguntas de governança — e a maioria dos conselhos não respondeu a nenhuma.

## Key numbers

- **70.6°** — Limite de estabilidade na condição real — ausente do documento aprovado _(MAIB, 2025)_
- **84–92°** — Faixa de estabilidade que o documento de fato certificava — para outras condições _(MAIB, 2025)_
- **2008** — Ano de aprovação formal do documento de estabilidade _(MAIB, 2025)_
- **7 / 22** — Vidas perdidas — apesar do pleno cumprimento e certificação _(MAIB, 2025)_

Tire o superiate e as manchetes, e o Bayesian se torna um caso de governança. Eis um ativo que havia passado por todas as barreiras nas quais um conselho se apoia: classificado por uma sociedade reconhecida, certificado conforme o código aplicável, operando com um documento de estabilidade aprovado. Segundo cada elemento que um conselheiro invocaria, era seguro. Sete pessoas morreram mesmo assim — não porque uma regra foi descumprida, mas porque a falha ocorreu em uma condição que nenhum documento havia descrito.

«Estávamos em conformidade» era precisamente a posição dos proprietários. É também, em quase todo incidente grave, a do conselho. Por isso o Bayesian não é uma história sobre um barco. É uma história sobre a distância entre o que a sua garantia lhe diz e o que é realmente verdade.

## Aprovado não é garantido

Um conselho não vê os perigos diretamente. Vê garantia: dossiês de segurança, relatórios de auditoria, declarações de verificação, certificados de conformidade. Cada um é uma promessa de que os controles estão em vigor e são eficazes. Mas cada um também é limitado — válido apenas para as condições que de fato examinou. A confiança do conselho, portanto, nunca é mais ampla do que as condições que sua garantia avaliou.

No Bayesian, o documento de estabilidade aprovado trazia a salvaguarda certa — limites para impedir que uma rajada súbita alagasse a embarcação — mas apenas para suas condições à vela. Para a condição em que realmente estava naquela noite, fundeado a motor, o documento silenciava. O limite de estabilidade ali foi calculado depois em 70,6°, contra os 84,3° a 92,3° que o documento havia certificado para outros estados. A aprovação era inteiramente real. A garantia era parcial. E ninguém sabia qual parte faltava até sete pessoas estarem mortas.

> **O ESTADO SILENCIOSO NO NÍVEL DO CONSELHO**
>
> Cada elemento de garantia que sua organização possui foi validado para um conjunto definido de condições. As condições que nunca avaliou não aparecem como riscos em nenhum painel — não aparecem de forma alguma. Em escala empresarial, esses são os estados silenciosos que um conselho carrega sem saber. A ausência de um alerta não é a presença de segurança.

## Por que suas investigações lhe dizem sempre «erro humano»

Se suas investigações internas chegam repetidamente ao «erro do operador», o conselho está sendo sistematicamente mal informado — e não porque alguém mente. Está mal informado pelo método. Um processo de investigação construído para identificar quem agiu produzirá de forma confiável uma pessoa. Um processo construído para identificar quais condições tornaram o ato inevitável produzirá de forma confiável um sistema. O mesmo evento dá uma ou outra resposta conforme o processo que você encomendou.

Isso é um fato de governança, não técnico. O conselho, ou seu delegado, impõe a norma de investigação que a organização utiliza. Então o conselho é dono do ponto cego que seu método cria. Não se pode delegar a metodologia e renegar as conclusões que ela foi construída para alcançar.

> O único objetivo de uma investigação de segurança é a prevenção de acidentes futuros. Não tem por finalidade determinar a responsabilidade nem atribuir culpa.
>
> — MAIB (R.U.), mandato legal, 2025

O Bayesian mostra isso em público. Sua investigação de segurança, à qual a lei proíbe atribuir culpa, alcançou uma condição latente — uma vulnerabilidade não documentada no estado operacional. A investigação criminal paralela, construída para atribuir responsabilidade, teria olhado para a equipe. Um conselho que discretamente executa um processo interno orientado à culpa toma a mesma decisão que o promotor: escolhe ver atos, e portanto escolhe não ver suas próprias condições latentes.

> **Takeaway:** A metodologia que você impõe decide as conclusões que tem o direito de ouvir. Encomende um processo que termine em uma pessoa, e lhe falarão de pessoas — nunca das condições que produzirão o próximo evento.

## O custo de uma investigação que termina em uma pessoa

Quando uma investigação se fecha sobre um indivíduo, a condição latente que produziu o evento permanece exatamente onde estava. O controle é «recapacitação» ou «um lembrete»; a vulnerabilidade fica intacta. Então o evento se repete — e da segunda vez carrega o nome do conselho, porque o registro agora mostra que a organização sabia e agiu apenas contra a pessoa. Essa é a sequência que converte uma falha operacional em uma falha de governança e responsabilidade.

Os processos paralelos do Bayesian tornam a exposição concreta: «erro do operador» e «causa sistêmica» competem agora em público, na imprensa e nos tribunais, pelas mesmas sete mortes. Um conselho a quem só foi entregue a versão «erro do operador» de seus próprios incidentes não tem defesa preparada para o dia em que a versão sistêmica vier à tona — porque nunca encarregou ninguém de encontrá-la.

## Três perguntas que um conselho deveria fazer

Não é preciso profundidade técnica para governar isto. São precisas três perguntas — utilizáveis em qualquer revisão de garantia e obrigatórias após qualquer incidente grave.

1. **Quais condições operacionais nossa garantia avaliou de fato — e quais estão em silêncio?** — Exija a lista de estados operacionais reais do ativo, confrontada com o que o dossiê de segurança avaliou. Sinal de alerta: a gestão descreve os controles mas não consegue produzir a lista de condições não avaliadas.
2. **O que nossa última investigação grave foi construída para encontrar — condições do sistema ou atos individuais?** — Audite o método, não apenas o relatório. Sinal de alerta: as recomendações são dominadas por recapacitação, disciplina e lembretes, e nenhuma condição organizacional latente é nomeada.
3. **Para cada conclusão de «erro humano» dos últimos 12 meses, qual condição latente permanece em vigor?** — Reabra as que terminaram em uma pessoa. Sinal de alerta: ninguém consegue responder, porque a condição nunca foi buscada — o que significa que ainda está ativa e ainda é capaz de produzir o próximo evento.

Essas três perguntas convertem a garantia de um exercício de conforto — receber a confirmação de que tudo está bem — em um de supervisão: sondar ativamente as condições que ninguém avaliou. Essa virada é toda a função de segurança do conselho.

## Ponto a reter

O dever de segurança de um conselho não é receber garantia. É testar o que a garantia não cobre, e exigir um método que alcance o sistema em vez de um nome. «Aprovado» é uma afirmação sobre um conjunto de condições, não sobre a realidade. As conclusões que você está disposto a ouvir são as que construiu a capacidade de tratar — e a condição latente sobre a qual nunca perguntou é a que chegará com o seu nome.

> Um conselho que apenas recebe garantia governa as condições que alguém escolheu avaliar — não as que realmente falharão.
>
> — Bruno Hounkpati

## Glossary

- **Garantia da segurança** — Os dispositivos — dossiês de segurança, auditorias, verificação, certificados — que dão ao conselho a confiança de que os controles estão em vigor e são eficazes.
- **Dossiê de segurança** — Argumento estruturado, apoiado por evidências, de que os perigos maiores de um ativo estão controlados — válido apenas para as condições avaliadas.
- **Condição latente** — Decisão, documento ou defeito incorporado a um sistema muito antes de um incidente, adormecido até se combinar com um gatilho (Reason, 1997).
- **Falha ativa** — Ato inseguro no ponto do incidente; a camada visível em que para um método orientado à culpa.
- **Investigação sem atribuição de culpa** — Investigação cujo único fim é a prevenção, explicitamente separada da responsabilidade — projetada para revelar as condições do sistema.
- **Estado silencioso** — Condição operacional que existe na prática mas nunca foi avaliada pelo documento aplicável; um perigo não avaliado, não um perigo baixo.
- **Alcance de condições validadas** — Conjunto de condições para as quais um elemento de garantia foi realmente avaliado; as condições fora dele são estados silenciosos.
- **Gestão da mudança (MOC)** — Processo formal para avaliar os perigos introduzidos por qualquer modificação, recapacitação de regime ou novo modo operacional.

## Frequently asked questions

**O que um conselho deve aprender com o naufrágio do Bayesian?**

Que a aprovação não é garantia: um documento de segurança plenamente certificado pode silenciar sobre a condição operacional que realmente falha. Os conselhos devem perguntar quais condições sua garantia avaliou e tratar as não avaliadas como perigos ativos.

**Por que as investigações internas concluem sempre em «erro humano»?**

Porque a metodologia é construída para encontrar atos individuais em vez de condições do sistema. O conselho impõe a metodologia, então o conselho é dono do ponto cego.

**O que é um sistema de garantia da segurança?**

Os dispositivos — dossiês de segurança, auditorias, verificação, certificados — que dão ao conselho a confiança de que os controles estão em vigor e são eficazes. Cada elemento só é válido para as condições que avaliou.

## References

- UK Marine Accident Investigation Branch (2025). Interim report: foundering of the yacht Bayesian. https://www.gov.uk/maib-reports
- US Chemical Safety Board (2025–2026). Incident Reports, Volumes 1–4. https://www.csb.gov/investigations/
- Reason, J. (1997). Managing the Risks of Organizational Accidents. Ashgate.

---

*Este artigo é publicado pela HSESKILLS Ltd apenas para fins educacionais e informativos. Não constitui aconselhamento jurídico. Cenários compostos ilustram padrões comuns e não fazem referência a nenhuma organização específica, salvo menção explícita.*