Padrão fora de tolerância: que trabalhos rever?
O padrão voltou da calibração fora de tolerância. Já trataste de o retirar de utilização. Agora falta a pergunta difícil: «Em que trabalhos usámos isto e o que é que pode ter ficado comprometido?»
O certificado novo está num ficheiro. As utilizações estão no QMS, o sistema de gestão da qualidade. Os resultados vivem nas folhas de trabalho. Os contactos dos clientes estão no ERP. Alguém tem de juntar estas peças sem confundir uma suspeita com uma conclusão técnica.
Um chatbot consegue explicar o procedimento de trabalho não conforme. Mas, sem acesso às relações entre os teus registos, não consegue identificar os trabalhos que precisam de avaliação. A diferença útil não está numa resposta mais bem escrita. Está em consultar o histórico certo, mostrar a origem de cada associação e deixar explícito o que ainda não se sabe.
Retirar o padrão de serviço não fecha o problema
A retirada evita novas utilizações indevidas. Não resolve o possível efeito nas medições anteriores.
A lista de avaliação da PJLA baseada na ISO/IEC 17025:2017, revisão 1.0 de agosto de 2021, relaciona o ponto 6.4.9 com equipamento defeituoso ou fora dos requisitos e com o tratamento de trabalho não conforme. No ponto 7.10.1(c), inclui a avaliação da importância desse trabalho e do impacto em resultados anteriores. É uma referência para compreender o problema, não um novo prazo legal português nem uma substituição da norma e do teu procedimento.
Há uma distinção essencial: um padrão fora de tolerância não torna automaticamente inválidos todos os certificados em que foi utilizado. Obriga a perceber o que aconteceu, onde pode ter influência e que decisões são necessárias.
Importam a característica afetada, o desvio observado, a incerteza, as correções aplicadas, o método e as condições de utilização. Também importa quando poderá ter começado o problema. A data da descoberta não é necessariamente a data de início da deriva.
O sistema deve ajudar a reunir esta evidência. A avaliação e a decisão pertencem ao responsável técnico.
A relação que interessa não é «este cliente tem certificados»
Imagina um bloco-padrão de 10 mm utilizado na calibração de micrómetros. Saber que pertence ao laboratório e tem um certificado não chega. Para investigar o impacto, precisas de ligar aquele bloco concreto às operações em que foi efetivamente usado.
A cadeia começa no identificador individual do padrão. Passa pelo registo de utilização, pela folha de trabalho e pelos pontos medidos. Continua até ao resultado emitido, à versão do certificado e ao cliente correspondente.
Um campo que diga apenas «jogo de blocos» pode ser insuficiente. O bloco de 10 mm e o de 20 mm não são intercambiáveis numa investigação sobre o primeiro. Da mesma forma, um padrão previsto no método não prova que tenha sido usado numa execução específica.
A integração tem de distinguir material previsto, material efetivamente utilizado e informação em falta. Se os registos não permitem essa distinção, a resposta correta é «não consigo determinar com estes dados». Não é escolher o padrão mais provável.
É por isso que carregar os procedimentos num assistente não resolve, por si só, a rastreabilidade. Os procedimentos explicam o que deveria acontecer. Os registos mostram o que aconteceu — quando foram preenchidos com esse detalhe.
Um exemplo: 28 trabalhos não significam 28 certificados inválidos
O cenário seguinte é hipotético, com números apenas para explicar a análise. Não descreve um cliente, um resultado medido ou uma funcionalidade já entregue pela Leiritech.
Em 19 de outubro, o laboratório recebe um resultado fora do critério de aceitação para o bloco identificado como BP-010. Existe uma verificação intermédia satisfatória de 8 de setembro. O responsável técnico define inicialmente esse intervalo para pesquisa, sujeito a revisão da sua adequação.
Essa data não é uma fronteira automática de segurança. É preciso perceber se a verificação tinha sensibilidade e âmbito suficientes para detetar o problema agora observado. Se não tinha, a pesquisa poderá ter de recuar.
Uma consulta inicial encontra 28 trabalhos associados ao jogo de blocos nesse intervalo. Ao cruzar os registos detalhados, obtém-se a seguinte separação:
| Evidência encontrada | Trabalhos | Tratamento inicial |
|—|—:|—|
| Utilização explícita do BP-010 | 18 | Incluir na avaliação técnica |
| Só está identificado o jogo, não o bloco | 6 | Manter em investigação por falta de detalhe |
| Registos demonstram utilização exclusiva de outros blocos | 4 | Propor exclusão deste incidente, com justificação verificável |
O resultado não é «28 trabalhos afetados». É «18 utilizações confirmadas, 6 trabalhos por esclarecer e 4 exclusões propostas com evidência». Mesmo os 18 confirmados são trabalhos a avaliar, não uma declaração de resultados inválidos.
Suponhamos que, nesses 18, há 14 trabalhos com certificado emitido e 4 ainda em curso. A prioridade operacional já é diferente. Nos primeiros, é necessário avaliar resultados comunicados; nos restantes, o responsável pode ter de impedir a emissão até concluir a análise, através do processo autorizado do laboratório.
Depois vem a questão metrológica. O bloco foi usado em que ponto? Que correção entrou no cálculo? O desvio e a incerteza podem alterar o resultado ou uma declaração de conformidade, quando exista? Uma utilização num ponto de 10 mm não prova, sozinha, que todos os pontos da gama do micrómetro estejam comprometidos.
Também não basta aplicar retroativamente a correção da calibração mais recente a todas as medições antigas. Sem evidência sobre a evolução do padrão, isso pode produzir números muito precisos para uma hipótese errada.
O ganho da integração é entregar ao responsável uma base verificável para estas perguntas. Não é saltar diretamente para a decisão.
O que o agente deve executar, só de leitura
Neste caso, «executar» significa fazer a consulta e reunir o dossier de avaliação. Não significa alterar certificados nem tomar controlo do QMS.
Uma implementação adequada começaria por resolver a identidade do padrão. Se existirem dois equipamentos com designações semelhantes, pede confirmação do identificador. Depois consulta utilizações, resultados, documentos e versões, sempre dentro das permissões do utilizador.
O dossier deve permitir abrir cada registo de origem. Para cada trabalho, interessa apresentar a data, o padrão registado, o método e a respetiva versão, os pontos relevantes, o certificado associado e a razão pela qual entrou na pesquisa. As lacunas devem aparecer ao lado da evidência, não escondidas numa nota final.
Convém ainda separar três coisas: facto recuperado, critério aplicado e decisão pendente. «O BP-010 consta da folha de trabalho» é um facto. «Pesquisar desde 8 de setembro» é um critério definido para a investigação. «O resultado continua aceitável» é uma conclusão que exige avaliação técnica.
O acesso só de leitura deve ser imposto pelas credenciais e pelos serviços disponíveis, não apenas por uma instrução escrita ao modelo. O assistente não deve conseguir modificar resultados, retirar certificados ou comunicar decisões aos clientes.
A auditoria regista quem fez a consulta, quando, com que âmbito e quais os registos e versões utilizados. Como os dados podem mudar depois, é necessário conservar uma referência reproduzível ao conjunto consultado, de acordo com as regras de retenção do laboratório. O registo desta consulta pertence à camada de auditoria; não altera os dados técnicos de origem.
E há um limite importante: se o utilizador não tem acesso a parte dos trabalhos, o assistente não pode apresentar a pesquisa como completa para todo o laboratório. Nem deve revelar dados fora das suas permissões para tentar preencher essa lacuna.
«Mas o meu QMS já tem um relatório para isso»
Ótimo. Se o relatório é completo, rastreável e fácil de utilizar, não precisas de acrescentar IA para repetir a mesma função.
O acesso conversacional faz sentido quando a pergunta exige navegar por várias relações, reunir fontes dispersas ou explicar por que motivo um trabalho entrou no conjunto em avaliação. Mesmo aí, o assistente deve usar consultas controladas e regras verificadas. O modelo interpreta a pergunta e explica o resultado; não inventa relações entre registos.
Outro limite aparece quando faltam dados estruturados. Se o padrão usado só consta de uma nota manuscrita, a primeira tarefa pode ser melhorar o registo de utilização. A integração não deve transformar ausência de evidência em certeza. É preferível entregar seis trabalhos por esclarecer do que omiti-los para produzir uma resposta mais limpa.
O teste de aceitação deve, por isso, incluir casos difíceis: um trabalho sem identificação individual do padrão, um certificado com várias versões e um utilizador com acesso limitado. Uma demonstração que só funciona com o histórico perfeito não prova que consegue apoiar um incidente real.
O preço do bot não prova a profundidade da integração
Na oferta consultada da 3HASH, publicada em 21 de junho de 2026, o serviço para website e WhatsApp é anunciado por 100 € de implementação e 25 €/mês, com IVA. A página descreve conhecimento preparado a partir do website, oferta, horários e perguntas frequentes. Não documenta uma integração ERP incluída. Isso não prova que o fornecedor seja incapaz de a desenvolver.
Também seria errado dizer que as plataformas maiores só respondem a perguntas frequentes. A Meta já anunciou ligações a sistemas no Business Agent, e ferramentas como a Landbot disponibilizam API e webhooks em determinados planos.
A distinção defensável é outra: esta implementação conhece o teu modelo de dados e consegue demonstrar o percurso entre o padrão e cada trabalho? Ter uma API é uma condição técnica possível. Entregar aquela análise, com permissões, versões, lacunas e auditoria, é trabalho de integração.
Um serviço mais caro não passa automaticamente este teste. E uma resposta simpática sobre a ISO não é equivalente a um dossier construído a partir dos teus registos.
Começa por um incidente encerrado, não por uma promessa
Se estás a preparar o fecho do ano, um incidente antigo pode servir de ensaio controlado. Não porque exista uma obrigação sazonal nova, mas porque já tens uma decisão humana documentada contra a qual comparar a consulta.
Escolhe um padrão, um intervalo e um incidente concluído. O primeiro objetivo é reproduzir a lista de trabalhos considerados, justificar inclusões e exclusões e expor as faltas de informação. Não é medir quantas mensagens o assistente consegue trocar.
A Leiritech desenvolve acesso conversacional aos dados em modo só de leitura e auditado, e trabalha no domínio de calibração e QMS com o PrüfMittel. O fluxo descrito neste artigo é uma demonstração a preparar sobre o sistema e os registos de cada laboratório, não uma promessa de conector pronto nem de decisão técnica automática.
Envia para hello@leiritech.com uma descrição anonimizada de um incidente encerrado e indica onde guardas as utilizações dos padrões. É um ponto de partida concreto para avaliar se a integração consegue reunir a evidência de que o teu responsável técnico precisa.
Imagens editoriais geradas para ilustrar o cenário; não representam instalações ou casos de clientes.
