Legare ogni chiamata IA a un flusso e a una persona

Il tuo fornitore di modelli sa esattamente quanti token hai consumato il mese scorso. Non ha la minima idea di quale automazione li abbia consumati, e non l’avrà mai. Quell’attribuzione può essere fatta solo dalla tua parte, e finché non è fatta una fattura IA è un numero che puoi pagare ma non governare.

Non è un problema di fatturazione. È un problema di governance travestito da problema di fatturazione.

Che cosa la fattura può e non può dirti

Una fattura del fornitore ti dà, al massimo: un totale, una ripartizione per modello e a volte una ripartizione per chiave API. Basta a rispondere «quanto» e a nient’altro.

Le domande che nascono davvero in una riunione di revisione sono altre:

• Quale automazione ha trainato l’aumento di questo trimestre?
• È cresciuta perché è cresciuto il volume, o perché qualcuno ha cambiato un prompt?
• A quale reparto va imputata?
• Questo flusso sta usando un modello molto più capace di quanto il suo compito richieda?
• Se tagliamo tutto questo a metà, che cosa smette di funzionare?

Ognuna di queste ha bisogno di un legame tra una chiamata e un flusso. Nessuna si risponde dalla fattura.

Perché le chiavi API non sono attribuzione

Il primo tentativo tipico è una chiave API per team, o per progetto. Aiuta, e smette di aiutare in fretta.

Le chiavi si condividono, perché crearne una richiede un ticket e copiarne una richiede un secondo. Una chiave creata per un progetto gli sopravvive. Un flusso costruito dal team A viene duplicato dal team B con dentro ancora la chiave. Sei mesi dopo, la ripartizione delle chiavi descrive l’organigramma di allora, non quello di adesso.

E più a fondo: una chiave ti dice chi ha creato la credenziale, non che cosa ha fatto la chiamata. Sono fatti diversi, e quello che ti serve è il secondo.

Che cosa richiede davvero l’attribuzione

Tre informazioni, unite:

1. La chiamata. Quale modello, quanti token in ingresso, quanti in uscita, quando. Disponibile dal fornitore, richiesta per richiesta, se la catturi.

2. Il flusso che l’ha fatta. Esiste soltanto nella tua piattaforma di automazione. È la chiave di join, ed è il pezzo che nessuno ha per impostazione predefinita.

3. Il responsabile di quel flusso. Esiste soltanto nei tuoi registri, e spesso da nessuna parte, il che è l’altra metà del problema.

Una volta uniti i tre, la fattura IA smette di essere un totale e diventa una tabella che puoi ordinare. Tutto ciò che è utile viene da quella tabella.

Fare il join

Ci sono due modi onesti per ottenere il legame tra una chiamata e un flusso, e uno che sembra un terzo e non lo è.

Etichettare nel punto di chiamata. La maggior parte dei fornitori accetta metadati su una richiesta: un campo utente, un header, un identificatore personalizzato. Se ogni flusso che chiama un modello manda il proprio identificatore, sono i log del fornitore stesso a portare l’attribuzione e il join è banale. È la risposta pulita, e richiede di toccare tutti i flussi che già esistono.

Riconciliare dai due lati. Leggere le definizioni dei flussi dalla piattaforma, individuare quelli che chiamano un modello, estrarre che cosa mandano e incrociarli con i registri di utilizzo del fornitore per orario e per forma. Meno esatto, non richiede alcuna modifica ai flussi esistenti, e funziona retroattivamente: cosa che conta, perché i flussi che più ti interessa capire sono quelli già in funzione.

Stimare dal solo flusso. Leggere il prompt, contare i token, moltiplicare per il numero di esecuzioni. Sembra attribuzione ed è aritmetica. È un utile controllo di coerenza e non è una misura: non vede i retry, i troncamenti, né la dimensione variabile degli input reali. Non presentarlo come la fattura.

In pratica, un parco nuovo dovrebbe etichettare nel punto di chiamata. Un parco esistente deve riconciliare, almeno finché ogni flusso non sarà stato ripreso in mano.

Che cosa cambia una volta che ce l’hai

Ottimizzare smette di essere un’ipotesi. «Dovremmo usare un modello più piccolo» è un’opinione. «Questo singolo flusso è il 60 % della nostra spesa IA, sta classificando tre categorie, e chiama il modello più grande disponibile» è una decisione che si prende in dieci secondi.

Il riaddebito diventa possibile. Un costo per flusso si aggrega in un costo per team. Quel solo cambiamento sposta la conversazione da «l’IA è cara» a «le automazioni del tuo reparto costano questo, ecco il dettaglio», che è una conversazione su cui qualcuno può agire.

La deriva diventa visibile. Il costo di un flusso che sale del 30 % senza che cambi il numero di esecuzioni significa che è cambiato qualcosa in ciò che manda. Senza attribuzione, si vede come una fattura un po’ più alta e nessuno guarda. Con l’attribuzione, si vede come un flusso che sale nell’elenco.

Le revisioni trovano un ancoraggio. «Quali delle nostre automazioni dipendono da un LLM, e chi l’ha approvato?» è una domanda che verrà posta, da un comitato rischi, da un revisore o da un cliente. Rispondere partendo da una fattura non è possibile. Rispondere partendo da un elenco di flussi con responsabili nominati occupa una sola schermata.

Il prerequisito che nessuno cita

Tutto questo presuppone che ogni flusso abbia un responsabile. Se non ce l’ha, l’attribuzione si ferma un passo prima: saprai che Flow_v3_FINAL è quello che ti costa di più, e non saprai con chi parlarne.

Ecco perché attribuzione dei costi e responsabilità sono lo stesso progetto, anche se arrivano come due lamentele separate, una dal finance e una dall’IT. Risolvile separatamente e otterrai due mezze risposte. Il flusso è l’unità di cui entrambe hanno bisogno, ed è l’unità che nessuna delle due piattaforme ti dà.

È tutta qui la ragione per cui Synoptial esiste, ed è il motivo per cui la prima cosa che chiede non è un budget ma un nome.