Resumen

  • pai-auth-ws-client 1.6.0 incorpora una consulta para resolver la configuración de un caso de uso de IA y otra para enviar el chat; las dos respuestas tipadas incluyen proveedor y modelo.
  • Falta, en el contrato Java público, una identidad común de resolución o versión de configuración que una lo observado antes del chat con la respuesta efectivamente obtenida.

Conviene empezar por lo que LACNIC hizo bien. El README etiquetado como 1.6.0 no presenta un acceso abierto y sin controles a un modelo. Exige un token Bearer de PAI con el rol portal-ai-gateway y que la dirección del cliente figure en AI_LLM_WS_IP_WHITELIST. La biblioteca utiliza validación estándar de TLS y del nombre del host, codifica use como un solo segmento de ruta, fija cinco segundos para conectar y 90 para recibir respuesta, y convierte el vencimiento en gateway_timeout con estado 504. Además, el resultado del chat declara proveedor, modelo, caso de uso y latencia. Es una base bastante más seria que una función opaca que solo devuelve texto.

También sería injusto pedirle al cliente que revele todo lo que ocurre detrás del gateway. Una biblioteca de integración debe ser pequeña. El repositorio no muestra el registro completo del servidor, la telemetría de la aplicación que llama ni siquiera si la versión se encuentra desplegada en un servicio de LACNIC. Observar que un campo no existe en dos DTO públicos no demuestra que no haya un trace privado en otra capa.

La pregunta precisa aparece porque la propia versión separa la operación en dos tiempos. Primero, resolve(token, use) consulta qué configuración corresponde al uso indicado por la aplicación. Después, chat(token, use, messages) envía ese uso y los mensajes. El README subraya que la aplicación decide el valor de use; el cliente se limita a trasladarlo al gateway.

La clase AiResolveData ofrece una fotografía útil: use, proveedor, identificador y etiqueta del modelo, estado de habilitación, tiempo máximo y nombre de la credencial. La clase AiChatData devuelve el texto, use, proveedor, modelo y latencia. Por tanto, una respuesta conservada no queda totalmente huérfana: dice, al menos, quién la atendió y con qué modelo según el gateway.

Lo que no aparece es la identidad de la fotografía. Ninguna de las dos clases ofrece resolutionId, configurationId, una versión de configuración, un identificador de solicitud o una correlación común. El método de chat tampoco recibe el objeto resuelto ni un comprobante opaco generado durante la consulta previa. Vuelve a mandar use y deja que el gateway decida.

Puede parecer una diferencia menor porque chat repite el proveedor y el modelo. No lo es, aunque tampoco prueba un fallo. La propia estructura de resolución muestra que una configuración incluye más cosas: habilitación, plazo y nombre de credencial. Dos revisiones pueden conservar el mismo proveedor y el mismo modelo y, sin embargo, cambiar otro elemento operativo. O la asociación de use puede actualizarse entre las dos llamadas. El código público no dice que eso ocurra; dice algo más modesto: si ocurriera, las cadenas coincidentes de proveedor y modelo no bastarían para distinguir las revisiones.

Supongamos que una aplicación resuelve MiLACNIC_Query y guarda proveedor X, modelo Y y un plazo de 60 segundos. Un minuto después solicita el chat y recibe proveedor X y modelo Y. La concordancia es una señal positiva. Pero, si entre ambos momentos cambió la política asociada al uso, el cliente no puede demostrar si la respuesta salió del estado anterior o del nuevo. Cuenta con dos descripciones parecidas, no con una identidad transaccional compartida.

Esto no convierte al diseño en una carrera insegura. El servidor puede resolver y ejecutar de forma atómica dentro de la llamada a chat. Puede registrar cada decisión con gran detalle. La aplicación puede añadir su propia correlación. Incluso puede existir documentación privada que establezca garantías que el repositorio no muestra. El límite editorial es no confundir la ausencia de evidencia pública con evidencia de ausencia. La conclusión se restringe a lo que puede conservar un integrador usando las clases públicas de la versión etiquetada.

La fecha del cambio importa. GitHub registra la versión 1.6.0 el 12 de septiembre de 2026. Su nota afirma que 59 pruebas Maven pasaron con Java 17 y que se aprobó una verificación estructural. La comparación con 1.5.1 muestra ocho commits: uno incorpora el cliente del gateway y el siguiente asegura las llamadas. No se está exigiendo un registro perfecto a una API antigua; se está observando el contrato justo cuando la funcionalidad adquiere una versión pública.

Las pruebas de PortalAiClient delimitan bien el objetivo de ingeniería. Verifican el Bearer, el análisis de proveedor y modelo, la codificación de caracteres reservados en use, la serialización de mensajes con roles, el rechazo de un uso vacío, el 504 ante un timeout y la delegación desde PortalWSClient. Son propiedades concretas y valiosas. No hay una prueba que transporte la identidad de resolve a chat porque la interfaz todavía no ofrece esa pieza.

La mejora mínima sería crear un comprobante de resolución, no fusionar a la fuerza las operaciones. resolve podría devolver un resolutionId opaco o una versión de configuración. En modo estricto, chat lo recibiría y fallaría claramente si la resolución caducó o fue sustituida. En modo consultivo, el gateway podría ejecutar el estado actual por razones de disponibilidad, pero devolvería la identidad realmente utilizada. Así se conserva la flexibilidad sin simular una garantía que no existe.

El comprobante privado no necesita copiar prompts ni credenciales. Bastaría con enlazar la identidad de resolución, el caso de uso, la versión de política, proveedor, modelo, hora y solicitud del cliente. Al completarse el chat añadiría la identidad ejecutada, latencia, estado, reintento o caché, y hashes del paquete de evidencia, del prompt y de la respuesta cuando corresponda. Los hashes permiten verificar igualdad sin publicar material sensible.

Ese registro no diría que el modelo acertó. Tampoco convertiría a LACNIC en responsable de cada uso que una aplicación haga de la salida. Resolvería una cuestión anterior a la calidad: qué estado de control produjo el objeto que se conserva. En la disciplina de código en ejecución, el catálogo expresa una intención; la respuesta es un hecho. El puente entre ambos debe ser comprobable.

La trazabilidad también protege al operador del gateway. Cuando no existe una identidad común, cualquier resultado extraño puede atribuirse a una modificación silenciosa aunque la configuración jamás haya cambiado. Con el comprobante, la revisión puede confirmar continuidad o localizar el punto exacto de divergencia. El debate se reduce a hechos y deja de expandirse hacia sospechas sobre todo el sistema.

Este artículo no repite el análisis anterior sobre la documentación de Java 8 y el bytecode de Java 17 del cliente PAI. Esa es una cuestión de compatibilidad de ejecución. Aquí se supone que la aplicación ya puede ejecutar la biblioteca y se pregunta qué evidencia obtiene al usar las dos operaciones nuevas. La diferencia es sencilla: una cosa es arrancar el cliente; otra, reconstruir la decisión que tomó el gateway.

Fuentes