Juntaste dois lotes de peixe. Depois dividiste o resultado por várias encomendas. Agora precisas de responder a uma pergunta simples: de onde veio o pescado desta caixa?
O código do lote está no ERP. As entradas e as saídas também. Mas, entre a receção e a expedição, houve uma fusão, uma divisão e talvez uma transferência de armazém. Se esses movimentos não estiverem ligados, conhecer o stock não chega para reconstruir a origem.
Num entreposto dos Açores ou da Madeira, o problema não se resolve com uma resposta convincente de um chatbot. Resolve-se preservando as relações entre lotes, quantidades e documentos. Uma camada de IA pode tornar essa informação consultável em linguagem corrente, desde que seja só de leitura, auditada e fundada nos teus dados. Não pode inventar a relação que falta.
Um código novo não apaga os lotes anteriores
Uma fusão cria uma nova identidade operacional. Não elimina a história dos produtos que entraram nela. Uma divisão cria novas frações. Não transforma cada fração numa nova origem.
A DGRM explicita esta distinção na secção 15 de «Rastreabilidade — Dúvidas comuns», versão V01.C, de 25 de março de 2026. Para os produtos abrangidos pelo capítulo 3 da Nomenclatura Combinada, após a colocação no mercado, a fusão ou divisão está condicionada à disponibilização das informações de rastreabilidade dos novos lotes e à conservação da informação dos lotes que os constituem. O documento remete para o artigo 56.º-A, n.º 5, e para o artigo 58.º, n.º 5, do Regulamento 1224/2009.
Isto não significa que qualquer mistura seja admissível, nem que um programa possa declarar conformidade sozinho. Significa que guardar apenas o código final deixa de fora uma parte essencial da história. O âmbito e as condições aplicáveis ao teu produto têm de ser confirmados pelo responsável técnico.
Há ainda uma distinção importante: saber quem forneceu o pescado não equivale a conhecer todos os elementos da sua origem. Datas de captura, identificação da viagem e restantes elementos aplicáveis têm de continuar acessíveis nos registos de origem. O fornecedor é uma ligação nessa cadeia, não um substituto da cadeia inteira.
O exemplo dos 200 kg: as contas certas podem esconder uma lacuna
Considera este exemplo hipotético, simplificado para explicar o problema. Não corresponde a um cliente nem demonstra um resultado da Leiritech. Assume pescado da mesma espécie e uma operação de fusão admissível, sem transformação nem perdas nesta sequência.
Recebes 120 kg do lote A e 80 kg do lote B. O armazém junta-os no lote M, com 200 kg. Mais tarde, divide M em três frações: C, com 90 kg; D, com 70 kg; e E, com 40 kg.
| Operação | Entradas registadas | Resultado registado |
|—|—|—|
| Fusão | A: 120 kg; B: 80 kg | M: 200 kg |
| Divisão | M: 200 kg | C: 90 kg; D: 70 kg; E: 40 kg |
O balanço fecha: 120 + 80 = 90 + 70 + 40. Sabes que M recebeu pescado de A e B. Sabes também que C, D e E resultaram de M, se essas ligações estiverem efetivamente registadas.
Mas quantos quilos de A existem em C?
Não podes concluir que são 54 kg apenas porque A representava 60% de M. Essa conta distribui proporcionalmente a composição do lote agregado. Não prova como o pescado foi separado fisicamente. Numa operação com caixas ou exemplares inteiros, a divisão pode ter seguido outra distribuição.
Se o registo operacional documentar que C recebeu 60 kg de A e 30 kg de B, essa composição pode ser apresentada com a respetiva fonte. D poderia ter recebido 40 kg de A e 30 kg de B, ficando E com 20 kg de cada origem. Também aqui o balanço fecha, mas a composição de C é diferente da estimativa proporcional.
A mesma soma final admite distribuições diferentes. Por isso, o sistema deve distinguir a ascendência do lote — C resulta de M, que recebeu A e B — da composição quantitativa efetivamente documentada de C. Se só tiver a primeira, deve dizê-lo. Não deve afirmar que cada caixa contém ambas as origens, nem atribuir percentagens por conveniência.
O que o ERP tem de guardar para a resposta ser verificável
O ponto de partida não é o modelo de linguagem. É o registo da operação que liga as entradas às saídas.
Para reconstruir esta sequência, precisas de identificar o movimento de fusão, os lotes de entrada, as quantidades utilizadas e o lote resultante. Na divisão, precisas da ligação entre o lote dividido e cada fração criada. Data, documento de suporte, unidade de medida e utilizador responsável permitem verificar o que aconteceu. Quando existe composição detalhada por origem, essa informação deve ficar ligada à operação que a documenta.
O identificador também precisa de contexto. Dois fornecedores podem usar o mesmo código de lote. Se o sistema juntar tudo o que se chama «123», pode fabricar uma relação entre produtos que nunca estiveram juntos. A identidade interna tem de distinguir os registos de forma inequívoca, preservando a referência original do fornecedor.
Depois há o peso. Quilogramas líquidos de pescado não são o mesmo que peso bruto da caixa com gelo. Uma verificação de quantidades precisa de comparar grandezas equivalentes. Se houver perdas, correções ou transformação, devem existir movimentos próprios, com motivo e suporte. Um desvio não desaparece porque ficou dentro de uma tolerância escolhida pelo programador.
Também não podes contar o mesmo produto duas vezes. Depois de A e B serem integralmente consumidos na criação de M, o histórico continua disponível, mas os 200 kg não ficam simultaneamente disponíveis nos três lotes. A mesma regra vale quando M é totalmente dividido. Histórico de origem e saldo atual são perguntas diferentes.
Onde entra a IA — e onde não entra
Uma integração deste tipo pode deixar-te perguntar: «Que lotes deram origem a C e onde estão os documentos?» O sistema percorre os movimentos autorizados, calcula os balanços com regras determinísticas e devolve as referências que sustentam a resposta. A IA organiza a explicação; não decide as somas nem inventa movimentos.
No exemplo sem composição detalhada, uma resposta útil seria:
C tem 90 kg e resulta da divisão de M. M foi formado com 120 kg de A e 80 kg de B. Os registos consultados não discriminam a quantidade de cada origem presente em C.
A resposta real deve acrescentar os identificadores dos movimentos e documentos consultados, bem como a data de atualização dos dados. Se a integração só recebeu movimentos até ao fecho de ontem, não pode apresentar o resultado como uma posição atualizada deste minuto.
«Só de leitura» tem de ser uma propriedade das permissões técnicas, não uma frase nas instruções do assistente. A ligação ao ERP deve impedir alterações e limitar o acesso às empresas, armazéns e dados autorizados para aquele utilizador. As consultas devem ser controladas, sem permitir que o modelo execute comandos arbitrários sobre a base de dados.
«Auditada» significa conseguir verificar quem perguntou, que consulta foi executada, que registos foram utilizados e que resposta foi apresentada. O registo de auditoria pertence a uma camada própria; não exige dar à IA autorização para escrever no ERP.
É isto que distingue uma resposta fundada nos teus dados de uma resposta apenas plausível. Se faltar a ligação entre M e C, o assistente não deve reconstruí-la pela proximidade das datas ou pela semelhança dos pesos. Pode indicar registos a rever, claramente separados das relações confirmadas. A correção continua a ser feita por uma pessoa autorizada, no sistema de origem, com histórico.
«Mas o meu ERP já gere lotes»
Ótimo. Não há razão para o substituir só para acrescentar uma caixa de conversa.
A pergunta é mais específica: o teu ERP guarda apenas o lote associado a cada linha, ou consegue representar as relações de vários lotes de entrada com vários lotes de saída? E consegues consultar essas relações sem depender da memória de quem estava no turno?
Se já tiveres uma consulta que mostra a cadeia completa e os documentos, talvez não precises de IA para esta tarefa. Pode bastar melhorar o acesso à consulta. A camada conversacional só se justifica se facilitar perguntas variáveis, cruzar fontes autorizadas ou reduzir o trabalho de localizar evidência. Esse benefício tem de ser medido, não presumido.
O discurso geral sobre IA no ERP costuma destacar inventário, previsão ou análise de gestão. Aqui, o requisito é mais estreito: explicar uma composição concreta sem confundir dados confirmados com hipóteses. Uma demonstração que responde depressa ao stock total ainda não demonstra essa capacidade.
Na Leiritech, esta seria uma integração a construir e validar sobre os teus sistemas, não um módulo de pescado que apresentamos como já instalado em clientes. Trabalhas diretamente com a equipa pequena que escreve o código. O primeiro trabalho é perceber o que o ERP regista e onde a cadeia se interrompe.
Testar antes das próximas expedições
Ao preparares as expedições do fim do ano, podes aproveitar para testar uma sequência já concluída. Não é preciso presumir um pico de procura igual em todas as ilhas, nem esperar por uma campanha comercial para descobrir que falta uma ligação.
O teste deve incluir uma fusão e uma divisão documentadas, mas também uma lacuna conhecida. Se a demonstração só usar dados perfeitos, não mostra como o sistema se comporta perante o problema que interessa resolver.
Mede o tempo necessário para reconstruir a sequência, a proporção das frações analisadas com cadeia documental completa e as ligações em falta que o sistema identificou corretamente. Define o universo da medição: dez frações verificadas não representam automaticamente todo o armazém. E confirma que a resposta recusa uma composição exata quando os dados não a suportam. Essa recusa é um resultado correto, não uma falha de inteligência.
Para quem opera nos Açores ou na Madeira, a decisão também não deve assentar numa promessa de apoio. O aviso-convite 07/C05-i14.01/2026 de IA nas PME delimitou os investimentos às regiões NUTS II do Continente. Isso não equivale à inexistência de instrumentos regionais ou à exclusão de toda a linha IA. A viabilidade desta integração tem de partir do processo e dos dados, separadamente da análise de financiamento.
Escreve para hello@leiritech.com para analisarmos uma sequência anonimizada de fusão e divisão do teu ERP. O objetivo inicial é concreto: perceber que origens consegues demonstrar hoje, quais ficam por documentar e se uma consulta só de leitura e auditada pode tornar essa verificação mais simples.
Imagens ilustrativas geradas por IA; não representam instalações de clientes nem interfaces de um produto de pescado já implementado.
