Nel momento in cui il gateway logga prompt e completion, custodisce qualunque cosa l'utente di un agente di customer service abbia digitato in una chat, che può includere un indirizzo, un numero di conto o un reclamo sulla propria salute. Ogni altra decisione di questa serie ha scambiato costo contro latenza, o controllo contro comodità. Questa scambia la debuggabilità contro un obbligo di protezione dei dati, ed è l'ultima perché è quella che ha bisogno che tutto il resto sia già al suo posto. La Parte 9 ha messo la piattaforma in condizione di rilasciare. Questa parte la chiude: cosa registrare, cosa osservare, cosa chiede la regolamentazione, e se i numeri della Parte 1 si sono davvero mossi.

Tre layer, e quello che costruisci tu

La piattaforma ora emette da tre punti, e confonderli è il modo in cui i team finiscono con tre dashboard che non concordano.

  • Gateway telemetry. Metriche di token verso Application Insights con le dimensioni tenant, model alias ed environment della Parte 5, più i log delle richieste verso Azure Monitor. È la vista autoritativa di chi ha chiamato cosa e quanto è costato, ed è l'unico layer che vede ogni richiesta sincrona.
  • Telemetria applicativa. Le trace del layer di orchestrazione: quali tool sono stati eseguiti, quante iterazioni di loop, quali documenti recuperati sono finiti nel prompt. Gli strumenti specifici per LLM come LangSmith o Openlayer vivono qui, e un team di data science che già usa Dataiku vorrà la propria vista sugli stessi dati. Nessuno di questi vede il traffico che non passa dall'applicazione che li emette, cosa che vale la pena dire ad alta voce ogni volta che qualcuno ne propone uno come fonte di verità della piattaforma.
  • Segnali di modello e di safety. Blocchi di content safety, refusal, categorie di filtro attivate. Arrivano dalla policy del gateway e appartengono al layer del gateway, non a quello applicativo, perché il punto è proprio che reggono anche quando l'applicazione si comporta male.

Il layer che il team di piattaforma possiede e che nessun altro costruirà è il join: un correlation ID che segue un'interazione utente attraverso tutti e tre, così una singola domanda che ha attivato quattro tool call e un blocco di content safety è una cosa sola in una query invece di sei record scollegati. La Parte 8 ha messo quell'ID nel record di log. È a questo che serviva.

Cosa loggare, e cosa no

Loggare prompt e completion è genuinamente utile: è così che fai il debug di una risposta sbagliata, costruisci il golden set dal traffico reale e dimostri cosa ha detto il sistema quando qualcuno lo contesta. Trasforma però il log store in un repository di contenuti generati dagli utenti di sensibilità sconosciuta, replicato ovunque vadano quei log.

La posizione praticabile è per prodotto invece che globale, ed è una decisione che il team consumer prende insieme alla piattaforma, non una che la piattaforma prende per tutti:

  • Logga sempre i metadati: tenant, alias, deployment risolto e versione, conteggi di token, latenza, status, cache hit, esito del content safety, correlation ID. Niente di questo è contenuto utente e tutto risponde alle domande operative.
  • Logga il contenuto per eccezione, con una retention più corta di quella dei metadati, limitata ai prodotti che hanno fatto opt-in, e con la subscription key rimossa dalla richiesta come richiesto dalla Parte 5.
  • Fai sampling invece di catturare tutto dove il logging dei contenuti è attivo. Per la maggior parte degli scopi un campione rappresentativo serve al debug quanto una cattura completa, e riduce l'esposizione in proporzione.

Scrivi i periodi di retention e la base giuridica nello stesso documento del modello di chargeback. Una piattaforma che sa dire con precisione cosa conserva, per quanto tempo e perché, sopravvive a una review di protezione dei dati. Una che non sa dirlo si sentirà ordinare di spegnere del tutto il logging, che costa molto di più.

Eval in produzione, non solo nella pipeline

L'eval gate della Parte 9 risponde a "questa modifica è sicura da rilasciare". Non risponde a "il sistema è ancora buono", perché il traffico di produzione non è il golden set e se ne allontana di continuo.

Due meccanismi, e rispondono a domande diverse. Le eval schedulate eseguono il golden set contro la configurazione di produzione a intervalli regolari, il che intercetta la deriva in cose che nessuno ha deployato: una versione del modello che si è mossa nonostante il pin, un indice che si è reindicizzato in modo diverso, un percorso di retrieval diventato più lento. La valutazione online campionata assegna un punteggio a una piccola quota di traffico reale, di solito con un model-as-judge, ed è l'unico modo per accorgersi di una classe di fallimenti che il golden set non ha mai contenuto, perché il golden set è per definizione fatto di fallimenti che già conoscevi.

Entrambi hanno bisogno di un posto dove mettere il risultato, ed è lo stesso posto di tutto il resto: un punteggio con le dimensioni tenant e alias, sulla stessa dashboard di spesa e latenza. Un numero di qualità che vive in uno strumento separato viene guardato durante gli incident e ignorato il resto del tempo.

Governance, e cosa chiede davvero la regolamentazione

Sotto l'EU AI Act, la maggior parte di ciò che questa azienda esegue è a rischio limitato invece che ad alto rischio, e gli obblighi che ne derivano riguardano soprattutto trasparenza e tracciabilità invece che certificazione. Non è un motivo per trattare la governance come un esercizio di documentazione, perché le domande che pone un auditor corrispondono quasi esattamente a cose che la piattaforma registra oppure no.

  • Quali modelli sono in uso, in quali applicazioni, in quali versioni? Il model catalog e la mappa degli alias rispondono. Senza di loro è un sondaggio.
  • Quali dati sono andati a quale provider, e dove sono stati processati? La configurazione del backend pool e i log delle richieste rispondono per singola richiesta, che è anche la risposta a una domanda di data residency su una regione specifica.
  • Quali controlli di safety erano in vigore, e sono scattati? La policy di content safety è versionata nel repository e i suoi esiti sono loggati per richiesta.
  • Chi poteva chiamare cosa, e quando è cambiato? La configurazione dei tenant è Terraform, quindi la risposta è una git history invece di un ricordo.
  • Una specifica interazione può essere ricostruita? Solo se il logging dei contenuti era attivo per quel prodotto, che è esattamente il motivo per cui quella decisione è per prodotto e messa per iscritto invece che implicita.

Il punto da portare a casa: è il gateway a rendere queste domande rispondibili. Cinque applicazioni che chiamano direttamente cinque endpoint di modello possono produrre cinque risposte diverse a ciascuna domanda, e lo sforzo per riconciliarle è il costo di compliance che l'investimento in piattaforma ha rimosso.

La scorecard

La Parte 1 ha fissato cinque obiettivi. Punteggio onesto, incluso quello che non è atterrato in modo pulito.

  • Ogni product owner vede la propria spesa di token entro un giorno. Raggiunto, con le classi di accuratezza della Parte 3 dichiarate sul report: esatte per non-streamed e batch, stimate per streamed, con un residuo pubblicato.
  • Nessuna applicazione detiene una credenziale di modello a lunga vita. Raggiunto. Le applicazioni detengono una client credential di Entra ID e una subscription key di prodotto; nessuna delle due raggiunge un endpoint di modello, e la revoca è una modifica di configurazione.
  • Un avviso di ritiro produce una query, non un'indagine. Raggiunto, e ha richiesto tre decisioni precedenti invece di uno strumento: versioni bloccate, alias e il logging per richiesta del deployment risolto.
  • Un tenant non può esaurire la quota di un altro. Raggiunto per il traffico sincrono attraverso counter key per subscription. Il batch è vincolato dal fatto che il control plane è l'unico submitter, che è un controllo di processo invece che uno imposto tecnicamente, e quel gap va nominato invece che levigato.
  • Latenza del gateway sotto i 60 ms al 95° percentile per le chiamate non in cache. Questo è il numero da misurare invece che assumere, ed è il più sensibile a scelte fatte per altre ragioni: il check di content safety aggiunge una chiamata prima del modello, il lookup della semantic cache aggiunge una chiamata di embedding, ed entrambi sono stati adottati per buone ragioni che costano millisecondi. Una piattaforma che li ha aggiunti tutti senza rimisurare ha cambiato in silenzio il proprio SLO.

Cosa è costato, e quando non ne vale la pena

La serie sarebbe disonesta senza questa sezione. Un gateway centrale è un team di piattaforma, un'istanza di API Management in un tier scelto per uno schema invece che per il carico, una cache Redis con un modulo che non può essere aggiunto dopo, un deployment di embeddings che serve due scopi, e un control plane che è un servizio vero con un on-call vero. È un costo fisso, e compra attribuzione, governance e una storia di lifecycle.

Sotto circa tre applicazioni consumatrici, non ne vale la pena. Il costo di coordinamento che il gateway rimuove non esiste ancora, e la stessa disciplina si ottiene con un modulo Terraform condiviso e una convenzione. La soglia non è un numero di token, è il punto in cui una modifica a come si accede ai modelli richiede l'azione di più di un team. È lì che la seconda porta inizia a costare più di quanto sia costata la prima.

Leggi questo dopo

Per il lato infrastruttura e piattaforma di come far girare tutto questo su scala, gli appunti tecnici sono su ercan.cloud, e l'hub è su ercanermis.com.

Riferimenti