sinc-LLMResposta para o integrador: Aceite a integração pela alteração autorizada no destino, reconciliada com a origem. Uma resposta do conector ou um log de envio não prova que o registo correcto foi aplicado. Defina também o resultado de duplicados, falhas parciais, dados inválidos e acesso negado.
Ferramenta prática para esta decisão
Exemplo sintético: o evento E-42 recebeu uma resposta de transporte, mas o destino não mostra o efeito esperado. INT01 permanece por satisfazer. Se a resposta se perdeu depois de aplicar o efeito, INT06 exige reconciliação antes da repetição. A mesma sequência observável impede que a falta de resposta seja tratada como autorização para duplicar uma operação.
Usar o recurso original deste artigo. É um modelo proposto, sem execução num projecto de cliente.
O conector responde com sucesso. O fornecedor mostra um log verde. A equipa de destino, porém, não encontra o registo esperado. Para o integrador responsável pela entrega completa, o problema é simples: um sinal de envio não demonstra que a informação chegou correctamente ao sistema que a deve utilizar.
Uma integração contratável precisa de uma fronteira observável: entrada autorizada, transformação prevista, estado no destino e evidência que permita reconstruir o percurso. Isto vale para componentes determinísticos e para uma camada de IA colocada entre sistemas.
Do requisito institucional ao pacote executável
Os termos do IMA para acompanhamento da interoperabilidade referem critérios, matrizes de evidências e testes integrados. Distinguem o acompanhamento técnico da execução pelos fornecedores. Essa distinção ajuda a estruturar responsabilidades; não identifica um pedido de subcontratação para a SincLLM. TdR, secções 4.3–4.6 e 10.
O trabalho de um especialista deve começar num subconjunto autorizado: um par de sistemas, uma família de mensagens e um conjunto de operações. Evite contratar «a interoperabilidade» como um resultado indivisível quando existem vários fornecedores e decisões que o especialista não controla.
Uma ficha útil descreve: quem publica a interface, quem a consome, que autenticação é aceite, que esquema será validado, qual o efeito permitido e como o destino o confirma. Inclua o que fica de fora: outras instituições, produção, migração histórica ou alterações nas plataformas de terceiros, salvo acordo expresso.
Defina o significado de cada estado
Use estados que correspondam a observações diferentes. «Recebido» pode significar apenas que uma fila aceitou a mensagem. «Validado» significa que passou as regras de entrada. «Aplicado» exige confirmação do efeito no destino. «Reconciliado» indica que o efeito corresponde à origem e que não faltam nem sobram operações no conjunto verificado.
Não é obrigatório adoptar estes nomes. É obrigatório que a equipa compreenda o significado escolhido e não promova um estado porque outro sistema respondeu sem erro.
| Caso | Resultado esperado no ensaio | Evidência conservada |
|---|---|---|
| Mensagem válida | Um efeito previsto, no destino autorizado | ID de correlação, payload permitido, confirmação no destino |
| Repetição da mesma mensagem | Sem duplicação indevida | Chave de idempotência e contagem de efeitos |
| Campo inválido | Rejeição identificável, sem aplicação parcial oculta | Erro de validação e estado inalterado |
| Identidade sem permissão | Acesso negado | Registo de negação sem exposição de conteúdo |
| Destino indisponível | Estado pendente ou falha explícita, segundo contrato | Tentativas, limite e encaminhamento para intervenção |
| Resposta perdida após aplicação | Reconciliação antes de repetir o efeito | Leitura do destino e decisão registada |
Estes são testes propostos. A equipa deve adaptar quantidades, estados e limites à interface real; a tabela não relata resultados de um projecto executado.
Mostre onde a IA pode interferir
Se um modelo normaliza texto, extrai campos ou sugere classificação, desenhe uma fronteira adicional. A saída do modelo precisa de esquema e validação antes de produzir efeito. A ausência de informação não deve transformar-se num campo inventado. Uma baixa confiança declarada pelo próprio modelo não substitui uma regra de aceitação.
Por exemplo, num cenário sintético de encaminhamento documental, o classificador propõe uma categoria e apresenta os campos extraídos. O integrador valida a categoria contra uma lista autorizada e encaminha casos incompletos para revisão. A decisão administrativa continua com o responsável competente. O teste compara tanto a proposta como o percurso posterior, incluindo a hipótese de retirar a camada de IA.
Se o fluxo funciona com a IA desligada, documente esse modo. Se depende dela, registe a indisponibilidade como condição de bloqueio em vez de inventar um fallback que ninguém consegue operar.
Entregue um dossiê que outra equipa consiga ler
O dossiê deve ligar requisito, versão, caso de teste, resultado e decisão. Guarde o contrato de interface, os esquemas, o código entregue, a configuração autorizada, as fixtures e as instruções de repetição. Inclua o inventário das dependências externas e as lacunas conhecidas.
Para cada execução, conserve identificação do ambiente, revisão do software, hora, IDs de correlação e localização da prova no destino. Reduza ou anonimize os dados dos logs de acordo com as regras aprovadas; um dossiê de aceitação não deve tornar-se uma cópia desnecessária dos dados do cidadão.
O responsável pela aceitação precisa de distinguir defeito do componente, falha de uma dependência e especificação em aberto. Nenhuma das três desaparece por ter sido atribuída a outra equipa. Registe a consequência, o dono e a condição para repetir o teste.
Feche a entrega com operação e reversibilidade
Antes da promoção, combine quem acompanha alertas, quem decide uma repetição, como se revogam acessos e qual é a sequência de recuperação. Ensaiar rollback em ambiente autorizado dá evidência sobre aquele procedimento; escrever um runbook não equivale a tê-lo executado.
O especialista entrega o pacote acordado. O integrador demonstra o seu encaixe na solução completa. A função de aceitação conserva a autoridade que lhe foi atribuída. Onde o contrato exigir independência, uma autoavaliação do implementador não satisfaz essa obrigação.
Para transformar esta abordagem num âmbito comercial, consulte Integração de serviços. Para continuidade e entrega dos activos, reutilize o guia de saída de fornecedor. Uma conversa com a SincLLM deve identificar as interfaces, o efeito permitido e a prova que o integrador precisa de conservar — antes de estimar custo ou calendário.
Este artigo não certifica uma integração, fornecedor ou plataforma nacional.
Delimitar uma conversa técnica
A SincLLM apresenta serviços de integração, recuperação documental e avaliação com âmbito a confirmar. O código público é evidência técnica limitada, não prova de experiência governamental, elegibilidade ou capacidade de mobilização.
Preparar uma conversa com a SincLLM: indique o papel da sua empresa, o componente, as interfaces conhecidas e a decisão que precisa de suportar. Não envie documentos reservados nem dados pessoais de terceiros. O envio não confirma disponibilidade, proposta ou parceria.
Guia técnico com referências consultadas em 31 de Outubro de 2026. A aplicabilidade jurídica, as condições do procedimento e a capacidade para a entrega concreta precisam de confirmação pelos responsáveis competentes.