Todo fornecedor de software marítimo diz que "suporta conformidade". A maioria quer dizer uma pasta de PDFs e uma coluna de datas. A diferença entre isso e um software que de fato mantém uma operação pronta para auditoria não é uma funcionalidade — é uma decisão de arquitetura tomada no primeiro dia. Chamamos isso de conformidade por design, e é o primeiro pilar de tudo o que construímos.
A armadilha do módulo acoplado
O ciclo de vida típico de um módulo de conformidade é assim: constrói-se um produto para gerenciar operações, um cliente falha em uma inspeção, e em um sprint acrescenta-se uma "aba de conformidade". O resultado é uma contabilidade paralela — o software diz uma coisa, a regulação exige outra, e um humano fica conciliando as duas numa planilha.
A falha é estrutural. Regulações como a STCW (emendada por Manila 2010) e a MLC 2006 não são listas de documentos; são sistemas de regras que dependem do posto, do departamento, do tipo de navio, do estado de bandeira e do tempo. Um contramestre e um segundo maquinista não carregam os mesmos certificados. Um certificado válido sob uma bandeira pode exigir endosso sob outra. Um certificado médico tem um ciclo de validade diferente do de um Certificado de Competência. Se o seu modelo de dados não conhece essas distinções, nenhuma interface vai consertar.
Como é a conformidade "de fábrica"
Na prática, conformidade por design significa que a lógica regulatória vive na camada de dados e todo o resto deriva dela:
- Os requisitos são definidos por posto. O sistema sabe qual conjunto de documentos se aplica a cada posto e categoria de frota — convés versus máquinas, mercante versus offshore — em vez de uma lista genérica para todos.
- O vencimento é um estado calculado, não armazenado. "Válido", "a vencer" e "vencido" são calculados continuamente a partir de datas de emissão, ciclos de validade e janelas de alerta configuráveis — nunca digitados à mão.
- A verificação deixa rastro. Quem verificou um documento, quando, contra qual registro e com qual resultado fica gravado como dado de primeira classe. Um auditor deve poder reconstruir cada decisão.
- O catálogo é dado, não código. Quando uma administração de bandeira atualiza um requisito, muda o catálogo de regras — não o código-fonte. A regulação se move mais rápido que os ciclos de release.
| Pergunta | Conformidade acoplada | Conformidade por design |
|---|---|---|
| Quem sabe quais documentos um posto exige? | O usuário, de memória | O modelo de dados |
| O que acontece quando uma regra muda? | Um release novo, um dia | Uma atualização do catálogo |
| Você consegue provar quem verificou o quê? | Às vezes, no e-mail | Sempre, na trilha de auditoria |
| Quando você descobre um certificado vencido? | Na inspeção | Trinta dias antes |
Por que isso importa comercialmente, não só tecnicamente
Em setores regulados, o software vale o quanto vale a sua pior auditoria. Uma operação de crewing que descobre um certificado vencido durante uma inspeção de port state control não se importa com a elegância do dashboard. Sistemas projetados em torno da regulação transformam a conformidade de uma emergência recorrente em um processo de fundo — e isso é um custo operacional mensurável, não uma abstração: menos detenções, menos trocas de tripulação de última hora, menos contratos perdidos por papelada.
O Panamá abriga o maior registro de navios do mundo, e a distância entre a expectativa regulatória e as ferramentas operacionais por aqui é enorme. Essa distância é exatamente onde trabalhamos.
Pontos-chave
- Conformidade acrescentada depois sempre vira contabilidade paralela.
- STCW/MLC são sistemas de regras — posto, bandeira, tempo — não listas de documentos.
- Vencimentos devem ser calculados, a verificação deve deixar rastro e as regras devem viver em dados.
- O valor comercial do software de conformidade se mede na auditoria, não no demo.
Trabalha em um setor regulado e luta com os problemas descritos aqui? Construímos software exatamente para isso.
Fale com a PBS