In dem Moment, in dem das Gateway Prompts und Completions loggt, hält es, was der Nutzer eines Customer-Service-Agenten in eine Chatbox getippt hat, und das kann eine Adresse sein, eine Kontonummer oder eine Beschwerde über die eigene Gesundheit. Jede andere Entscheidung in dieser Serie hat Kosten gegen Latenz oder Kontrolle gegen Bequemlichkeit getauscht. Diese tauscht Debugbarkeit gegen eine datenschutzrechtliche Pflicht, und sie kommt zuletzt, weil sie diejenige ist, die alles andere bereits an seinem Platz braucht. Teil 9 hat die Plattform zum Shippen gebracht. Dieser Teil schließt sie ab: was aufzuzeichnen ist, was zu beobachten ist, was die Regulierung verlangt und ob sich die Zahlen aus Teil 1 tatsächlich bewegt haben.

Drei Schichten, und die, die man selbst baut

Die Plattform emittiert jetzt aus drei Stellen, und wer sie vermengt, endet mit drei Dashboards, die sich widersprechen.

  • Gateway telemetry. Token-Metriken in Application Insights mit den Dimensionen Tenant, Modell-Alias und Environment aus Teil 5, plus Request-Logs in Azure Monitor. Das ist die maßgebliche Sicht darauf, wer was aufgerufen hat und was es gekostet hat, und die einzige Schicht, die jeden synchronen Request sieht.
  • Application telemetry. Die eigenen Traces der Orchestrierungsschicht: welche Tools liefen, wie viele Loop-Iterationen, welche abgerufenen Dokumente es in den Prompt geschafft haben. LLM-spezifische Tools wie LangSmith oder Openlayer leben hier, und ein Data-Science-Team, das bereits Dataiku benutzt, will seine eigene Sicht auf dieselben Daten. Keines davon sieht Traffic, der nicht durch die Anwendung geht, die es emittiert, und das sollte man laut aussprechen, wann immer jemand eines davon als Source of Truth der Plattform vorschlägt.
  • Modell- und Safety-Signale. Content-Safety-Blocks, Refusals, ausgelöste Filterkategorien. Diese kommen aus der Gateway-Policy und gehören zur Gateway-Schicht, nicht zur Anwendungsschicht, denn der ganze Punkt ist, dass sie auch dann halten, wenn die Anwendung sich falsch verhält.

Die Schicht, die das Plattform-Team besitzt und die sonst niemand bauen wird, ist der Join: eine correlation ID, die einer Nutzerinteraktion über alle drei folgt, sodass eine einzelne Frage, die vier Tool-Aufrufe und einen Content-Safety-Block ausgelöst hat, in einer Query ein Ding ist statt sechs unzusammenhängender Records. Teil 8 hat diese ID in den Log-Record gelegt. Dafür war sie da.

Was zu loggen ist, und was nicht

Prompts und Completions zu loggen ist wirklich nützlich: So debuggt man eine schlechte Antwort, baut das golden set aus echtem Traffic und beweist, was das System gesagt hat, wenn jemand es bestreitet. Es verwandelt den Log-Store aber auch in ein Repository nutzergenerierter Inhalte unbekannter Sensibilität, repliziert überallhin, wo diese Logs hingehen.

Die tragfähige Position ist pro Produkt statt global, und es ist eine Entscheidung, die das konsumierende Team gemeinsam mit der Plattform trifft, statt eine, die die Plattform für alle trifft:

  • Die Metadaten immer loggen: Tenant, Alias, aufgelöstes Deployment samt Version, Token-Zahlen, Latenz, Status, Cache-Hit, Content-Safety-Ergebnis, correlation ID. Nichts davon ist Nutzerinhalt, und alles davon beantwortet die operativen Fragen.
  • Inhalte nur als Ausnahme loggen, mit einer retention, die kürzer ist als die der Metadaten, beschränkt auf Produkte, die sich dafür entschieden haben, und mit dem Subscription Key aus dem Request entfernt, wie Teil 5 es verlangt hat.
  • Sampling statt Vollerfassung, wo Content-Logging aktiv ist. Ein repräsentatives Sample debuggt für die meisten Zwecke genauso gut wie eine vollständige Erfassung und reduziert die Exposition proportional.

Die retention-Zeiträume und die Rechtsgrundlage gehören in dasselbe Dokument wie das Chargeback-Modell. Eine Plattform, die präzise sagen kann, was sie aufbewahrt, wie lange und warum, übersteht ein Datenschutz-Review. Eine, die das nicht kann, bekommt gesagt, das Logging komplett abzuschalten, was weit mehr kostet.

Evals in Produktion, nicht nur in der Pipeline

Das eval gate aus Teil 9 beantwortet "ist diese Änderung sicher zu shippen". Es beantwortet nicht "ist das System noch gut", denn Produktions-Traffic ist nicht das golden set und driftet kontinuierlich davon weg.

Zwei Mechanismen, und sie beantworten verschiedene Fragen. Scheduled evals lassen das golden set auf einem Timer gegen die Produktionskonfiguration laufen, was Drift in Dingen fängt, die niemand deployt hat: eine Modellversion, die sich trotz Pin bewegt hat, ein Index, der anders reindexiert wurde, ein Retrieval-Pfad, der langsamer geworden ist. Sampled online evaluation bewertet einen kleinen Anteil des echten Traffics, üblicherweise mit einem model-as-judge, und ist der einzige Weg, eine Fehlerklasse zu bemerken, die das golden set nie enthielt, denn das golden set besteht per Definition aus Fehlern, die man schon kannte.

Beide brauchen einen Ort für das Ergebnis, und es ist derselbe Ort wie für alles andere: ein Score mit den Dimensionen Tenant und Alias, auf demselben Dashboard wie Spend und Latenz. Eine Qualitätszahl, die in einem separaten Tool lebt, wird während Incidents angeschaut und den Rest der Zeit ignoriert.

Governance, und was die Regulierung tatsächlich verlangt

Unter dem EU AI Act ist das meiste, was dieses Unternehmen betreibt, limited-risk statt high-risk, und die Pflichten, die daraus folgen, drehen sich überwiegend um Transparenz und Nachvollziehbarkeit statt um Zertifizierung. Das ist kein Grund, Governance als Dokumentationsübung zu behandeln, denn die Fragen, die ein Auditor stellt, bilden sich fast exakt auf Dinge ab, die die Plattform entweder aufzeichnet oder nicht.

  • Welche Modelle sind im Einsatz, in welchen Anwendungen, in welchen Versionen? Der model catalog und die Alias-Map beantworten das. Ohne sie ist es eine Umfrage.
  • Welche Daten gingen an welchen Provider, und wo wurden sie verarbeitet? Die backend-pool-Konfiguration und die Request-Logs beantworten es pro Request, was zugleich die Antwort auf eine Data-Residency-Frage zu einer bestimmten Region ist.
  • Welche Safety-Kontrollen waren aktiv, und haben sie ausgelöst? Die Content-Safety-Policy ist im Repository versioniert, und ihre Ergebnisse werden pro Request geloggt.
  • Wer konnte was aufrufen, und wann hat sich das geändert? Tenant-Konfiguration ist Terraform, die Antwort ist also eine Git-Historie statt einer Erinnerung.
  • Lässt sich eine bestimmte Interaktion rekonstruieren? Nur wenn Content-Logging für dieses Produkt aktiv war, und genau deshalb wird diese Entscheidung pro Produkt getroffen und aufgeschrieben statt implizit gelassen.

Der Punkt, den man mitnehmen sollte: das Gateway ist es, was diese Fragen überhaupt beantwortbar macht. Fünf Anwendungen, die fünf Modell-Endpoints direkt aufrufen, können auf jede Frage fünf verschiedene Antworten produzieren, und der Aufwand, sie abzugleichen, ist genau der Compliance-Preis, den die Plattform-Investition beseitigt hat.

Die Scorecard

Teil 1 hat fünf Ziele gesetzt. Ehrliche Bewertung, einschließlich des einen, das nicht sauber gelandet ist.

  • Jeder Product Owner sieht seinen eigenen Token-Spend innerhalb eines Tages. Erreicht, mit den Genauigkeitsklassen aus Teil 3 auf dem Report ausgewiesen: exakt für non-streamed und Batch, geschätzt für streamed, mit einem veröffentlichten Residual.
  • Keine Anwendung hält ein langlebiges Modell-Credential. Erreicht. Anwendungen halten ein Entra-ID-Client-Credential und einen Produkt-Subscription-Key; keines von beiden erreicht einen Modell-Endpoint, und Revocation ist eine Konfigurationsänderung.
  • Eine Retirement-Ankündigung produziert eine Query, keine Untersuchung. Erreicht, und es brauchte drei frühere Entscheidungen statt eines Tools: gepinnte Versionen, Aliasse und das Logging des aufgelösten Deployments pro Request.
  • Ein Tenant kann die Quota eines anderen nicht erschöpfen. Erreicht für synchronen Traffic über Counter Keys pro Subscription. Batch ist dadurch begrenzt, dass die Control Plane der einzige Submitter ist, was eine Prozesskontrolle ist und keine erzwungene, und diese Lücke sollte benannt statt glattgezogen werden.
  • Gateway-Latenz unter 60 ms im 95. Perzentil für nicht gecachte Aufrufe. Das ist das Ziel, das man messen statt annehmen sollte, und die Zahl, die am empfindlichsten auf Entscheidungen reagiert, die aus anderen Gründen getroffen wurden: Der Content-Safety-Check fügt einen Aufruf vor dem Modell hinzu, der Semantic-Cache-Lookup einen Embedding-Aufruf, und beide wurden aus guten Gründen eingeführt, die Millisekunden kosten. Eine Plattform, die all das hinzugefügt hat, ohne neu zu messen, hat ihr eigenes SLO stillschweigend verändert.

Was das gekostet hat, und wann es sich nicht lohnt

Die Serie wäre unehrlich ohne diesen Abschnitt. Ein zentrales Gateway ist ein Plattform-Team, eine API-Management-Instanz in einem Tier, das wegen eines Schemas statt wegen der Last gewählt wurde, ein Redis-Cache mit einem Modul, das sich später nicht nachrüsten lässt, ein Embeddings-Deployment, das zwei Zwecken dient, und eine Control Plane, die ein echter Service mit echtem On-Call ist. Das sind laufende Kosten, und sie kaufen Attribution, Governance und eine Lifecycle-Story.

Unter ungefähr drei konsumierenden Anwendungen lohnt es sich nicht. Die Koordinationskosten, die das Gateway beseitigt, existieren dann noch nicht, und dieselbe Disziplin bekommt man mit einem geteilten Terraform-Modul und einer Konvention. Die Schwelle ist keine Token-Zahl, sie ist der Punkt, an dem eine Änderung daran, wie auf Modelle zugegriffen wird, mehr als ein Team zum Handeln zwingt. Das ist der Moment, in dem die zweite Tür mehr zu kosten beginnt, als die erste gekostet hat.

Weiterlesen

Für die Infrastruktur- und Plattform-Seite, so etwas in diesem Maßstab zu betreiben, gibt es die Field Notes auf ercan.cloud, und der Hub liegt auf ercanermis.com.

Referenzen