Zusammenfassung

  • pai-auth-ws-client 1.6.0 ergänzt einen Aufruf zur Auflösung eines KI-Verwendungszwecks und einen getrennten Chat-Aufruf; beide Ergebnistypen nennen Anbieter und Modell.
  • Die öffentlichen Java-Klassen enthalten keine gemeinsame Auflösungs- oder Konfigurations-ID, mit der sich der vorher geprüfte Zustand eindeutig dem späteren Ergebnis zuordnen ließe.

Der neue Client beginnt nicht bei null. Die README-Datei des Tags 1.6.0 verlangt ein PAI-Bearer-Token mit der Rolle portal-ai-gateway und eine auf AI_LLM_WS_IP_WHITELIST geführte Absender-IP. Der Client verwendet die übliche TLS- und Hostnamenprüfung, kodiert use als einzelnes Pfadsegment, setzt fünf Sekunden Verbindungs- und 90 Sekunden Antwortzeitlimit und meldet einen Timeout als gateway_timeout mit Status 504. Das Chat-Ergebnis nennt Verwendungszweck, Anbieter, Modell und Latenz. Das sind konkrete Sicherheits- und Betriebsgrenzen.

Ein schlanker Client soll zudem schlank bleiben. Er muss weder geheime Zugangsdaten noch vollständige Prompts oder die gesamte Servertelemetrie transportieren. Aus dem öffentlichen Repository geht nicht hervor, ob diese Version produktiv eingesetzt wird, welche internen Protokolle das Gateway führt oder welche Korrelationswerte eine aufrufende Anwendung ergänzt. Ein fehlendes Feld in einem DTO belegt keinen fehlenden privaten Audit-Trail.

Beobachtbar ist dagegen die Trennung zweier Schritte. Mit resolve(token, use) fragt die Anwendung die für einen Zweck vorgesehene Konfiguration ab. Mit chat(token, use, messages) schickt sie Zweck und Nachrichten später erneut. Laut README bestimmt die Anwendung use; der Client leitet den Wert lediglich an das Gateway weiter.

AiResolveData beschreibt die Auflösung mit Verwendungszweck, Anbieter, Modell-ID und -Bezeichnung, Aktivierungsstatus, Timeout und dem Namen einer Zugangsdatenreferenz. Dazu kommen Erfolg, HTTP-Status und Fehler. AiChatData liefert Text, Zweck, Anbieter, Modell-ID und Latenz. Wer ein Ergebnis archiviert, kennt damit wichtige Herkunftsmerkmale.

Es fehlt die Identität der Auflösung selbst. Weder resolutionId noch configurationId, Konfigurationsversion, Request-, Trace- oder gemeinsame Korrelations-ID tauchen in den beiden Klassen auf. Der Chat-Code übernimmt auch kein Objekt oder undurchsichtiges Ticket aus dem vorangegangenen Resolve-Aufruf. Er sendet use und die Nachrichten neu.

Gleiche Anbieter- und Modellwerte sind nützlich, aber nicht identisch mit einem Zustandsnachweis. Das Resolve-DTO zeigt selbst, dass zur Konfiguration weitere Eigenschaften gehören: Aktivierung, Timeout und Zugangsdatenreferenz. Zwei Revisionen können denselben Anbieter und dasselbe Modell verwenden und dennoch eine andere Regel enthalten. Auch kann sich die Zuordnung eines Verwendungszwecks zwischen den Aufrufen ändern. Die Quellen belegen keine solche Änderung. Sie belegen nur, dass übereinstimmende Namen eine solche Änderung nicht sichtbar machen würden.

Eine Anwendung könnte um 11:00 Uhr eine Zuordnung prüfen und Anbieter A, Modell B sowie 60 Sekunden Timeout erhalten. Um 11:01 Uhr nennt der Chat wieder A und B. Das ist ein gutes Indiz. Falls inzwischen Revision 18 an die Stelle von Revision 17 getreten ist, beide aber A und B nutzen, kann der Client nicht sagen, welche Revision die Antwort erzeugte. Zwei passende Beschreibungen ersetzen keine gemeinsame Transaktionskennung.

Daraus folgt weder ein Rennen noch eine Schwachstelle. Das Gateway könnte beim Chat atomar auflösen und ausführen und intern eine vollständige Spur führen. Die Anwendung könnte eigene IDs setzen. Eine private Schnittstellenbeschreibung könnte zusätzliche Garantien geben. Die Beweisgrenze wirkt in beide Richtungen: Was öffentlich nicht sichtbar ist, darf weder als abwesend behauptet noch als vorhanden vorausgesetzt werden.

Der Zeitpunkt ist bemerkenswert. GitHub verzeichnet die Version 1.6.0 am 12. September 2026. Die Release-Notiz berichtet von 59 bestandenen Maven-Tests unter Java 17 und einer erfolgreichen Strukturprüfung. Im Vergleich zu 1.5.1 liegt der neue Tag acht Commits vorn; ein Commit fügt den KI-Gateway-Client hinzu, der nächste härtet die Aufrufe. Die öffentliche Form dieser Funktion ist also gerade erst festgeschrieben worden.

Die Tests für PortalAiClient zeigen die gewählten Invarianten: Übermittlung des Bearer-Tokens, Auslesen der Katalogbindung, Kodierung reservierter Zeichen in use, Serialisierung der Nachrichtenrollen, Ablehnung eines leeren Zwecks, 504-Abbildung bei Timeout und Delegation über PortalWSClient. Sie prüfen reale Integrationsrisiken. Eine über beide Aufrufe laufende Auflösungs-ID können sie nicht prüfen, weil die API sie nicht anbietet.

Die kleinste Ergänzung wäre eine undurchsichtige Quittung. resolve könnte eine resolutionId oder Konfigurationsversion liefern. Im strikten Modus würde der Chat sie entgegennehmen und bei einer veralteten Auflösung klar scheitern. Im flexiblen Modus dürfte das Gateway wegen Ausfall oder Kapazität neu zuordnen, müsste aber die tatsächlich verwendete ID zurückgeben. Beide Betriebsarten haben ihren Zweck; entscheidend ist, dass die Anwendung den Unterschied kennt.

Eine private Modellauflösungsquittung würde ID, Zweck, Richtlinien- oder Konfigurationsversion, Anbieter, Modell, Auflösungszeit und aufrufende Request-ID verbinden. Nach dem Chat kämen tatsächlich ausgeführte ID, Status, Latenz, Retry- oder Cache-Zustand sowie Hashes von Prompt, Belegpaket und Antwort hinzu. Hashes ermöglichen einen späteren Gleichheitsnachweis, ohne vertrauliche Inhalte offenzulegen. Geheime Zugangsdaten gehören nicht hinein.

Die Quittung beurteilt weder Wahrheit noch Qualität der Antwort. Sie beantwortet die vorgelagerte Frage, welcher Steuerungszustand sie hervorgebracht hat. Der Katalog beschreibt beabsichtigtes Routing; die Antwort ist ein Ereignis des laufenden Systems. Zwischen Absicht und Ereignis braucht es eine überprüfbare Identität.

Das begrenzt auch LACNICs Risiko. Ohne Bindung kann ein unerwartetes Ergebnis vorschnell einer stillen Umstellung zugeschrieben werden. Mit einer Bindung lässt sich Kontinuität belegen oder die Abweichung lokalisieren. Mehr Nachweis führt hier nicht zu grenzenloser Verantwortung, sondern zu einer engeren und faireren Zuständigkeit.

Der frühere Theo-March-Beitrag zum selben Repository hatte eine andere These: In der Dokumentation stand Java 8, während aktuelle Build- und Bytecode-Artefakte Java 17 verlangten. Das war eine Laufzeitfrage. Dieser Beitrag setzt einen lauffähigen Client voraus und untersucht den Nachweis seiner Gateway-Entscheidung. Startfähigkeit und Entscheidungsprovenienz sind getrennte Kontrollflächen.

Quellen