Carga perigosa: a ficha não é a declaração marítima
Tens a ficha de dados de segurança na pasta, a mercadoria separada no armazém e uma declaração pronta para enviar ao transitário. Falta responder à pergunta que interessa: os documentos descrevem aquilo que vai efetivamente sair nesta expedição?
Para um expedidor ou transitário dos Açores ou da Madeira, esta conferência faz parte do trabalho concreto de preparar uma ligação marítima. O problema não é simplesmente faltar um PDF. É haver documentos individualmente plausíveis que não correspondem entre si: uma ficha associada à referência errada, uma quantidade anterior à última alteração ou uma descrição comercial usada onde era necessária a designação oficial de transporte.
Uma IA fundada nos teus dados, só de leitura e auditada pode ajudar a encontrar essas divergências. Mas não deve classificar a mercadoria, substituir o responsável competente ou autorizar o embarque. A diferença entre estas tarefas define se estás a construir uma ferramenta útil ou apenas uma resposta convincente sem prova.
A ficha descreve o produto. A declaração acompanha a expedição
A ficha de dados de segurança, ou FDS, comunica informação sobre o produto e os seus perigos. A secção 14 reúne informação relativa ao transporte, incluindo número ONU, designação oficial de transporte, classes de perigo e grupo de embalagem, quando aplicáveis. É uma fonte importante. Não é, por si só, o retrato da carga que preparaste hoje.
A mesma referência pode sair em quantidades diferentes, em expedições distintas e com apresentações diferentes. A ficha não passa automaticamente a conhecer o número de volumes separados no teu armazém, o conteúdo de cada um ou uma alteração feita depois de alguém preparar o documento de transporte.
A declaração de mercadorias perigosas tem outra função: comunicar os dados relevantes da expedição e incluir a declaração do expedidor nos termos aplicáveis. O código IMDG enquadra o transporte marítimo de mercadorias perigosas embaladas. Segundo a Organização Marítima Internacional, a edição de 2024, com a emenda 42-24, é obrigatória desde 1 de janeiro de 2026. Uma conferência feita hoje precisa, por isso, de regras validadas para o enquadramento atual, não de um modelo antigo encontrado numa pasta.
Há ainda outra distinção: a declaração do expedidor não é o certificado de acondicionamento do contentor ou veículo. A orientação da Maritime and Coastguard Agency sobre o IMDG explica que podem partilhar o mesmo suporte documental, mantendo certificações e assinaturas próprias. Um ficheiro único não transforma responsabilidades diferentes numa só.
O sistema deve preservar estas diferenças. Encontrar uma FDS não equivale a encontrar uma declaração válida. Encontrar uma declaração não demonstra que o acondicionamento foi realizado e certificado por quem lhe compete.
Um exemplo: o produto está certo, a quantidade não
Considera um exemplo hipotético, sem atribuir uma classificação real a um produto inventado.
A referência interna Q-47 tem uma FDS identificada e uma classificação de transporte previamente validada pelo responsável competente. O ERP regista uma expedição com 12 bidões, cada um com 20 litros de conteúdo. O total registado é de 240 litros. No documento preparado para essa expedição aparecem 10 bidões e 200 litros.
A ficha pode estar correta. A classificação pode coincidir. Mesmo assim, existe uma divergência de dois volumes e 40 litros entre as fontes.
A resposta útil não é «a carga está conforme», porque o nome do produto e o número ONU coincidem. Também não é alterar automaticamente a declaração para 240 litros. Pode acontecer que o ERP ainda contenha uma quantidade prevista e só tenham sido preparados dez bidões. É preciso perceber qual dos registos corresponde à operação real.
Um resultado de conferência deveria dizer algo deste género:
A expedição Q-47 regista 12 bidões e 240 L. A declaração consultada indica 10 bidões e 200 L. Existe uma divergência de 2 bidões e 40 L. Confirma a quantidade efetivamente preparada e a versão do documento antes da validação pelo responsável.
Ao lado desta explicação devem estar os registos que a suportam: a linha da expedição, a versão da declaração e o momento da consulta. Sem isso, estás apenas a trocar uma procura manual por uma afirmação difícil de verificar.
O exemplo também mostra por que razão as unidades precisam de tratamento explícito. Vinte litros de conteúdo não são necessariamente a capacidade nominal da embalagem. Uma quantidade líquida não é a massa bruta. E não podes converter litros em quilogramas sem os dados e as condições adequadas.
Se o documento só indicar massa e a fonte interna só indicar volume, sem uma conversão aprovada, o resultado correto é «comparação não concluída». Inventar uma densidade para preencher a lacuna seria precisamente o erro que queres evitar.
A ligação entre documentos dá mais trabalho do que a pergunta
Perguntar «há diferenças nesta carga?» é fácil. Construir a correspondência certa entre as fontes é o trabalho de engenharia.
Uma referência do ERP pode ter várias apresentações. O fornecedor pode usar outra designação. Podem existir duas fichas com datas diferentes, ou uma ficha que deixou de corresponder à formulação fornecida. Escolher o PDF mais recente pelo nome do ficheiro não resolve estes casos.
O primeiro passo é definir como a tua operação associa uma referência, a apresentação expedida e a FDS aplicável. Essa associação precisa de validação humana. A leitura automática pode extrair campos e sugerir correspondências, mas uma semelhança entre nomes não deve tornar-se uma aprovação silenciosa.
Depois, é necessário definir de onde vem cada dado. A quantidade prevista pode estar na encomenda; a preparada, no registo de separação; a expedida, no documento final. Comparar uma declaração com o estado errado do ERP produz alertas inúteis ou esconde diferenças reais.
Há também campos que só fazem sentido em determinadas condições. Grupo de embalagem, perigos subsidiários e informação ambiental não devem ser preenchidos por hábito. O conjunto de verificações é definido para as mercadorias e operações em causa, com base nas regras aplicáveis e na classificação aprovada. Não resulta de uma lista genérica escrita pelo modelo de linguagem.
Quando falta a associação entre fontes ou existe uma leitura ambígua, o sistema deve mostrar a lacuna. «Não consegui confirmar qual é a ficha aplicável» é mais útil do que uma correspondência provável apresentada como certa.
Regras para comparar; IA para consultar e explicar
Nesta proposta, a aritmética não fica entregue à improvisação de um modelo. Somar quantidades, verificar unidades compatíveis e comparar valores são operações determinísticas. As regras de negócio e os campos obrigatórios têm responsáveis e versões identificáveis.
A IA serve para fazer perguntas em linguagem corrente e explicar o resultado: «Que divergências ficaram por resolver nesta expedição?» ou «Em que documento aparece esta quantidade?» A resposta deve apontar para a evidência disponível e respeitar os teus direitos de acesso.
Um chatbot genérico pode produzir uma explicação convincente sobre transporte marítimo sem ter visto a tua carga. Um sistema fundado nos teus dados tem uma obrigação diferente: distinguir o que encontrou, o que calculou e o que não consegue confirmar.
Se um PDF digitalizado estiver ilegível, isso deve aparecer como impedimento à conferência. Se a classificação aprovada e a FDS apresentarem valores diferentes, a ferramenta assinala o conflito para revisão. Não escolhe a classificação que parece mais provável nem consulta conhecimento geral para preencher o campo.
Este é também um limite comercial importante. A proposta não é um classificador automático de mercadorias perigosas. É uma camada de consulta e comparação sobre informação que a tua operação consegue identificar e validar.
Só de leitura não significa sem responsabilidade
O acesso ao ERP deve usar permissões que impeçam alterações. Quando não existe uma interface adequada, uma exportação autorizada pode servir de ponto de partida. Ter um ERP como o PHC, por exemplo, não prova que os campos necessários estejam disponíveis ou que exista um conector pronto: isso verifica-se no teu ambiente.
A aplicação pode guardar o histórico das próprias consultas sem escrever nos registos operacionais de origem. Para cada conferência, interessa conservar quem a pediu, que fontes e versões foram usadas, que regras foram executadas e que divergências foram apresentadas. O acesso e a conservação desse histórico também precisam de regras.
É particularmente importante distinguir o estado consultado do estado atual. Se alguém alterar a expedição depois da conferência, a resposta anterior não deve continuar a aparecer como se cobrisse a nova versão. O mesmo vale para uma declaração substituída.
A auditoria não serve apenas para investigar um erro. Serve para conseguires responder: «Que informação estava disponível quando esta diferença foi sinalizada?» E para deixar claro que a ferramenta não enviou documentos, assinou certificados ou tomou decisões de embarque.
«Mas o meu transitário já verifica isso»
Ótimo. O objetivo não é retirar essa verificação nem presumir que o transitário falha. É fazer chegar à revisão uma expedição com fontes identificadas e divergências visíveis, em vez de obrigar alguém a reconstruir a correspondência entre anexos e registos.
O teu ERP pode conhecer a preparação mais recente. O transitário pode estar a trabalhar sobre uma declaração recebida antes dessa alteração. Ambos podem executar corretamente a sua tarefa e, ainda assim, estar a olhar para estados diferentes. A comparação ajuda a tornar essa diferença explícita.
Também é possível que não precises de IA. Se tens referências estáveis, dados estruturados e poucas regras, uma integração convencional pode resolver grande parte do problema. Acrescentar conversa só faz sentido se facilitar a consulta e a explicação sem enfraquecer o controlo.
A aceitação do sistema deve testar precisamente os casos difíceis: quantidade divergente, ficha não identificada, documento ilegível e fontes contraditórias. O resultado esperado não é obter sempre uma resposta completa. É obter uma resposta verificável ou uma indicação clara de que a conferência não pôde ser concluída.
Começa por uma expedição que consigas reconstruir
Nos Açores e na Madeira, esta proposta começa no teu circuito real de expedição marítima, sem o condicionar à aprovação de financiamento. Não exige trocar o ERP nem entregar a decisão a um assistente.
Escolhe uma expedição concluída e reúne, num ambiente acordado e com acesso restrito, os registos de preparação, a FDS aplicável, a classificação aprovada e a declaração usada. Define com o responsável quais as diferenças que a ferramenta deve detetar e quais as decisões que ficam fora dela.
Mede o tempo de conferência e o trabalho necessário para resolver cada alerta. Sem uma medição inicial, não há uma poupança demonstrada; há uma expectativa.
Na Leiritech, trabalhas diretamente com a pequena equipa que escreve o código. O que propomos delimitar contigo é concreto: fontes identificadas, regras aprovadas, IA fundada nos teus dados, só de leitura e auditada. A validação competente e a autorização de embarque ficam fora da ferramenta.
Escreve para hello@leiritech.com com o assunto «Conferência de carga marítima» e indica que ERP usas e onde guardas estes documentos. Não envies documentação sensível nesse primeiro contacto; começamos por definir o acesso e uma expedição de teste.
