Resumo

  • O pai-auth-ws-client 1.6.0 acrescenta uma operação de resolução do uso de IA e outra de chat; os dois tipos de retorno mostram fornecedor e modelo.
  • O contrato Java público não fornece um ID de resolução ou uma versão de configuração que prove que a resposta veio exatamente do estado consultado antes do chat.

Há bastante coisa a favor da nova implementação. O README da versão 1.6.0 exige um Bearer PAI com o papel portal-ai-gateway e um IP incluído em AI_LLM_WS_IP_WHITELIST. As chamadas usam validação padrão de TLS e hostname, tratam use como um único segmento codificado da URL e aplicam limites fixos: cinco segundos para conectar e 90 para esperar a resposta. Um timeout vira gateway_timeout com status 504. O resultado do chat ainda registra uso, fornecedor, modelo e latência. É uma superfície de integração com controles explícitos.

Também faz sentido manter o cliente enxuto. Ele não precisa expor credenciais, prompts completos ou todos os detalhes do log do servidor. O repositório não demonstra se a versão está em produção, o que o gateway armazena nem quais IDs uma aplicação adiciona por conta própria. A ausência de um campo nas classes públicas não autoriza afirmar que LACNIC não tenha rastreamento privado.

O ponto desta análise é menor e mais verificável. A biblioteca oferece resolve(token, use) para consultar a configuração ligada a um uso e chat(token, use, messages) para executar a conversa. São duas solicitações. O README esclarece que a aplicação escolhe use; o cliente apenas encaminha esse valor ao gateway.

AiResolveData descreve o resultado da primeira etapa com uso, fornecedor, ID e rótulo do modelo, situação de habilitação, timeout e nome da credencial, além de sucesso, status e erro. AiChatData devolve texto, uso, fornecedor, ID do modelo e latência. Esses campos permitem responder algo importante depois do fato: qual fornecedor e qual modelo o gateway declarou para aquela saída.

O que eles não permitem identificar é a resolução em si. Não há resolutionId, configurationId, versão de configuração, ID de requisição, trace ou correlação comum. O método de chat envia novamente use e as mensagens; não recebe o objeto da primeira chamada nem um token opaco criado por ela.

Repetir fornecedor e modelo reduz a incerteza, mas não estabelece identidade. A própria classe de resolução mostra que uma configuração envolve mais do que o nome do modelo: há habilitação, limite de tempo e referência de credencial. Duas revisões podem continuar apontando para o mesmo fornecedor e o mesmo modelo e mudar outra regra. O mapeamento de use também pode ser alterado entre as chamadas. Nada no material público indica que isso aconteceu. A questão é que, se acontecer, a igualdade de dois textos não diferencia os estados.

Pense num sistema que, antes de resumir um documento, consulta a resolução e salva fornecedor A, modelo B e timeout de 60 segundos. Um minuto depois, o chat retorna A e B. A coincidência é boa evidência descritiva. Ainda não prova se a revisão consultada foi a que executou o pedido ou se uma revisão nova, com os mesmos nomes e outra política, entrou em vigor. Há duas fotos compatíveis, não uma chave que as prenda ao mesmo acontecimento.

Isso não é uma acusação de corrida, falha ou desvio. O servidor pode resolver e executar de maneira atômica dentro do chat e manter um log completo. A aplicação pode inserir um ID próprio. Pode existir uma garantia fora do repositório. A regra editorial é manter as duas fronteiras: não transformar o que não vemos em ausência; não transformar uma possibilidade privada em evidência do contrato público.

A novidade é recente. O GitHub marca o lançamento 1.6.0 em 12 de setembro de 2026. A nota diz que a suíte Maven completa teve 59 testes aprovados com Java 17 e que a verificação estrutural passou. A comparação com a versão 1.5.1 registra oito commits de avanço; os dois últimos adicionam o cliente do gateway e fortalecem suas chamadas. É o momento apropriado para definir a prova que a interface deve carregar.

Os testes do cliente verificam o Bearer, a leitura dos dados do catálogo, a codificação de caracteres reservados em use, a serialização de mensagens com papéis, a rejeição de uso vazio, a tradução do timeout para 504 e a delegação pela fachada anterior. Eles fixam comportamentos concretos. Não existe um teste que leve a identidade de uma resolução para o chat porque essa identidade não faz parte da API.

Uma solução proporcional seria um recibo de resolução opaco. resolve retornaria um resolutionId ou uma versão de configuração. O chat poderia aceitar esse valor em modo estrito, recusando uma revisão vencida, ou apenas devolver o valor realmente executado em modo flexível. O modo estrito favorece previsibilidade; o flexível preserva a capacidade de mudar de rota quando um fornecedor falha. Ambos são legítimos se a aplicação souber qual contratou.

O recibo privado ligaria o ID ao uso, versão de política, fornecedor, modelo, horário e requisição de origem. Ao final, acrescentaria o estado efetivamente executado, latência, resultado, retry ou cache e hashes do prompt, do pacote de evidências e da resposta, quando necessários. O conteúdo sensível continuaria privado e o valor da credencial ficaria de fora. A finalidade é provar igualdade de estado, não criar mais exposição.

Esse recibo não atesta que a resposta está correta. Antes de avaliar precisão, imparcialidade ou utilidade, ele responde a uma pergunta básica: qual estado de controle produziu a saída? O catálogo é uma intenção de roteamento. A resposta é um fato de execução. Se a ligação entre os dois não sobrevive, a auditoria começa com uma suposição.

Para LACNIC, a vantagem é limitar disputas. Sem o vínculo, uma resposta inesperada pode ser atribuída a uma mudança silenciosa mesmo que nenhuma mudança tenha ocorrido. Com o vínculo, o operador demonstra continuidade ou aponta a divergência. O sistema fica mais responsabilizável justamente porque cada parte responde por um fato menor e verificável.

Existe um tema próximo que não deve ser confundido com este. Um artigo anterior mostrou a diferença entre a promessa de Java 8 na documentação do cliente e o requisito Java 17 do build e do bytecode recente. Essa é a pergunta sobre conseguir executar a biblioteca. Aqui, a biblioteca já está rodando; a pergunta é se ela consegue conservar a identidade da decisão do gateway.

Fontes