Google stellt Inferenz-Metadatenprotokolle allgemein bereit, ohne Prompts oder Antworten zu speichern

In den Versionshinweisen vom 30. Oktober 2026 bezeichnet Google Cloud die Protokollierung von Metadaten zu Inferenzanfragen in der Gemini Enterprise Agent Platform als allgemein verfügbar. Nach ausdrücklicher Aktivierung kann für jede unterstützte Anfrage ein strukturierter Eintrag in Cloud Logging entstehen, der Modell, Region, Tokenzahlen, Nutzung von Provisioned Throughput, Latenz und Fehlercode enthält, aber weder Prompt noch Antworttext. Die allgemeine Verfügbarkeit beschreibt den Veröffentlichungsstand; sie bedeutet weder eine automatische Einschaltung in jedem Projekt noch Unterstützung aller Modelle und API-Methoden. Diese Ausgabe erscheint am 2. November.

Zunächst ist die Grenze der erfassten Aufrufe zu prüfen. Die Meldung nennt für Gemini `generateContent` und `streamGenerateContent` und für Claude `rawPredict` und `streamRawPredict`. Die ergänzende Dokumentation erklärt, dass andere Partnermodelle auf diesem Weg nicht protokolliert werden. Sowohl nutzungsabhängige Abrechnung als auch Provisioned Throughput werden unterstützt; trotzdem müssen Betreiber prüfen, welche Methoden ihre Anwendung tatsächlich aufruft. Wer nicht erfasste Aufrufe in einen Gesamtbericht mischt, könnte fehlende Einträge fälschlich als null Nutzung lesen. Es handelt sich um Betriebs- und Nutzungsmetadaten, nicht um eine vollständige Aufzeichnung von Eingabe und Ausgabe. Für deren Inhalt verweist Google auf eine gesonderte Protokollierungsfunktion mit anderen Datenschutzfolgen.

Aktivieren lässt sich die Option auf der Provisioned-Throughput-Seite der Konsole oder über die REST-API, projektweit oder für ein Modell in einer bestimmten Region. Die Einstellung kann einige Minuten bis zur Wirkung brauchen; Zeitpunkt der Änderung und ein danach gesendeter erkennbarer Testaufruf sollten festgehalten werden. Der Leitfaden nennt IAM-Rechte für die Änderung der Modellkonfiguration und die Verwaltung des Log-Buckets. Für SQL-Abfragen in Observability Analytics oder detaillierte Konsolenmetriken muss der Bucket `_Default` aufgerüstet werden. Diese Aufrüstung ist nicht rückgängig zu machen, und ältere Einträge werden dadurch nicht nachträglich per SQL abfragbar. Protokollierung einschalten, Speicher aufrüsten und Analysten berechtigen sind daher getrennte Entscheidungen und keine harmlose Schalterfolge.

Auch Kosten und Aufbewahrung sind Teil der Technik. Cloud Logging berechnet Aufnahme und Speicherung; Abfragen in Observability Analytics werden als Cloud-Monitoring-Nutzung berechnet. Der Standard-Bucket behält Einträge normalerweise 30 Tage. Viele eigene Kennzeichnungen können Einträge vergrößern, und bei sehr vielen Agentenanfragen entstehen entsprechend höhere Logkosten. Google empfiehlt, das Aufnahmevolumen für einen repräsentativen Tag zu messen und daraus Monatswerte abzuleiten. Das Fehlen von Prompt- und Antworttext verkleinert den Datenumfang, verhindert aber nicht, dass eine unbedachte Kennzeichnung vertrauliche Identifikatoren enthält. Namen, Zugriffsrechte, Fristen und Warnungen sind deshalb zu prüfen.

Ein Zweck ist die Zuordnung der Nutzung zu einem Team, einer Anwendung oder einem Mandanten. Clients können Header mit dem Präfix `x-goog-agent-platform-observability-label-` übermitteln und die Kennzeichnungen in Observability Analytics abfragen. Einträge helfen außerdem, Token nach Modell und Region, Fehler, Verzögerung und die Nutzung oder Überschreitung reservierter Kapazität zu untersuchen. Die fachliche Zuordnung entsteht nicht automatisch. Fehlt ein Header oder verwenden Dienste verschiedene Benennungen, bildet die Abfrage nicht die gesamte Nutzung ab. Ein Abgleich mit Rechnungen muss Tokenarten, Cache und den Unterschied zwischen gemessener Nutzung und tatsächlicher Belastung berücksichtigen.

Ein begrenzter Versuch beginnt in einem Testprojekt. Nach Prüfung der IAM-Rechte und der Bucket-Wahl wird die Option ausdrücklich eingeschaltet, ihre Wirkung abgewartet und je ein erkennbarer Aufruf über eine unterstützte Gemini- und Claude-Methode gesendet. In Logs Explorer oder einem vorbereiteten Analyse-Bucket sind Modell, Region, Token und Fehler zu kontrollieren. Ein nicht unterstützter Aufruf zeigt, warum „kein Eintrag“ nicht unbedingt „keine Anfrage“ heißt. Der Weg zurück zur vorherigen Einstellung und der Umgang mit bereits gespeicherten Einträgen gehören ins Verfahren. Weil Kosten und Informationszugriff betroffen sind, ist das Lesen dieses Artikels keine Freigabe zur Aktivierung im Produktivbetrieb.

Ein vorhandener Eintrag beweist nicht den Erfolg eines Geschäftsablaufs, denn fehlgeschlagene Anfragen können ebenfalls aufgezeichnet werden. Umgekehrt können Verzögerung, fehlende Methodenunterstützung oder Abfrageberechtigungen eine Lücke erklären. Zähler und Zeitfenster der aufrufenden Anwendung sollten erhalten bleiben, um Erfassungsprobleme von echter Verkehrsänderung zu unterscheiden.

Die Neuerung liefert feinere Nachweise für den Inferenzbetrieb und die Kostenzuordnung, abhängig von Methodenabdeckung, Aktivierung, Rechten und Logqualität. Teams sollten Einträge mit realen Aufrufen abgleichen und Metadatenprotokolle nicht als vollständige Prompt-Prüfung ausgeben.