Come definire gli SLO di un workflow AI

Il workflow chiude la richiesta in 14 secondi. Il file arriva vuoto.

La dashboard segna success. Per la persona che aspettava il documento, il servizio ha fallito. Succede quando misuri la chiamata tecnica e perdi il risultato che doveva uscire.

Un SLO per un workflow AI definisce il livello di servizio atteso su un esito osservabile. Indica cosa conta come buono, su quali casi, entro quale finestra e quale azione parte quando la soglia non regge. L'uptime può entrare nel quadro. Da solo non basta.

SLO, SLI e SLA hanno lavori diversi

Google SRE usa tre termini separati. L'SLI è una misura quantitativa del servizio. L'SLO è il valore o l'intervallo target associato a quella misura. L'SLA aggiunge un accordo con conseguenze esplicite.

Per un workflow interno puoi avere un SLO senza contratto commerciale. Serve a decidere quando fermare nuove modifiche, alzare la revisione umana o tornare a una modalità più semplice.

Formula minima:

SLI = esiti buoni / occasioni valide di servizio
SLO = SLI >= soglia, misurata nella finestra scelta
azione = cosa cambia quando il margine si consuma

Il numero acquista senso soltanto se esito buono e occasione valida hanno una definizione condivisa.

Parti da ciò che riceve l'utente

La pagina sul monitoraggio dei workflow AI in produzione spiega quali segnali osservare. Qui il punto viene prima: quale promessa operativa devono proteggere quei segnali?

Scrivila senza nominare il tool.

Quando arriva una richiesta completa, il workflow produce una bozza verificabile entro la finestra concordata, senza esporre dati vietati e senza avviare azioni fuori autorità.

Da questa frase emergono almeno quattro dimensioni:

Dimensione	Domanda di servizio
Completezza	la bozza contiene i campi richiesti?
Correttezza verificabile	claim, fonti e controlli sono collegati?
Tempo	il risultato arriva quando può ancora essere usato?
Confine	dati e azioni restano nel perimetro approvato?

Non sommare tutto in un voto opaco. Un errore privacy non deve essere compensato da una risposta veloce. Mantieni separati i gate bloccanti e gli indicatori graduati.

Definisci il denominatore

Richieste totali sembra chiaro. Non lo è.

Una richiesta senza allegato obbligatorio è un'occasione valida di servizio? Dipende dalla promessa. Se il workflow deve riconoscere il campo mancante e chiedere integrazione, quella richiesta entra. Se il servizio parte soltanto dopo una validazione esterna, resta fuori dall'SLI di produzione e dentro una metrica di intake.

Segna quattro stati:

• eligible, il caso rientra nel servizio
• rejected_expected, il caso viene fermato come previsto
• failed_service, il caso doveva riuscire e non è riuscito
• unknown, mancano prove per classificarlo

Lo stato unknown non va nascosto tra i successi. Se cresce, il problema è la misurazione prima ancora del modello.

L'inventario dei workflow AI aiuta a fissare scopo, owner, input e azioni. Usa quella scheda per delimitare la popolazione. Un SLO senza scope misura casi diversi come se fossero lo stesso servizio.

Scrivi l'SLI come una prova ripetibile

Un indicatore utile dice esattamente come viene calcolato.

sli_id: outcome-verificabile
population: richieste_eligible
good_event:
  output_complete: true
  required_checks: green
  delivered_within_minutes: 30
blocking_failures:
  - restricted_data_exposed
  - action_outside_authority
window: rolling_28_days
measurement_point: delivery_receipt
owner: operations

Il punto di misura conta. Il server può registrare un output generato, mentre il sistema di consegna lo ha perso. Misura il più vicino possibile al risultato ricevuto.

Per la qualità AI serve spesso un controllo su campioni congelati. Il dataset di test per workflow AI può funzionare da prober di correttezza. Non sostituisce il traffico reale. Copre casi noti in condizioni controllate.

Raccogli la baseline prima del target

Un numero scelto in riunione può diventare una promessa senza prova.

Prima la baseline.

Raccogli una finestra iniziale e documenta:

• volume dei casi validi
• quota di esiti buoni
• distribuzione per tipo di richiesta
• cause dei fallimenti
• quota di casi unknown
• aiuto umano già presente

Non chiamare autonoma una prestazione ottenuta con correzioni silenziose. Registra il livello di intervento. Buono dopo revisione e buono senza intervento sono due esiti diversi.

La baseline non autorizza a mantenere un servizio debole. Serve a capire la distanza, il costo di difesa e la qualità della misura.

Scegli soglia, finestra e margine

Google SRE sconsiglia il 100% come obiettivo automatico. Un target assoluto può portare lavoro sproporzionato o nascondere il fatto che alcuni errori hanno peso diverso.

Per iniziare, scrivi:

Su tutte le richieste eligible degli ultimi 28 giorni,
almeno [soglia proposta] deve produrre un esito verificabile
entro [tempo], senza fallimenti bloccanti.

La soglia resta proposta finché owner tecnico e owner del processo non la approvano. Conserva il motivo. Dato osservato, vincolo operativo oppure ipotesi.

L'error budget è il margine tra il target e il 100%. Non è un permesso per ignorare errori. Trasforma una deviazione in decisione. Se il margine si consuma, il team applica la politica concordata.

Segmenta prima di mediare

Una media può nascondere il caso che fa più male.

Se il workflow tratta richieste standard e casi ad alto impatto, misura due classi. Se una lingua ha poche osservazioni, non fonderla con la lingua principale per ottenere un numero tranquillo. Se un canale ha dati incompleti, dichiaralo.

Segmenti utili possono essere:

• tipo di compito
• livello di rischio
• presenza di allegati
• lingua
• canale di ingresso
• versione del workflow

Evita segmenti personali non necessari. Il NIST AI RMF chiede di scegliere metriche rispetto ai rischi più significativi e al contesto d'uso. La segmentazione serve a vedere un rischio, non a raccogliere dati per abitudine.

Collega la soglia a un'azione

Un SLO che finisce nel report è una metrica decorativa.

Decisioni, non decorazioni.

Prepara una scala corta:

Stato	Evidenza	Azione
Verde	margine stabile	prosegue il cambiamento controllato
Giallo	consumo rapido o unknown in crescita	aumenta campione e ferma l'espansione
Rosso	soglia mancata o gate bloccante	passa a fallback, apre analisi e congela modifiche

Assegna owner e tempo di risposta. L'azione non deve dipendere da chi nota per primo il grafico.

Un esempio fittizio

Un workflow prepara schede da richieste interne. La baseline sintetica contiene 120 casi validi. Novantotto arrivano completi entro 30 minuti, 12 richiedono correzione, 6 vengono fermati correttamente e 4 restano senza ricevuta.

Non possiamo dichiarare 98 su 120 buoni e chiudere. I 6 rifiuti attesi possono essere esiti corretti. I 4 casi senza ricevuta restano unknown. Prima si aggiusta la prova di consegna, poi si propone la soglia.

Il team definisce due SLI separati: esito verificabile e classificazione completa. I numeri sono parte dell'esempio, non un benchmark MAIKER HUB.

Misura servizio e pagina su due piani

Il workflow usa SLI e SLO definiti dal processo. La pagina SEO usa impressioni, query non-brand e invii form aggregati con source_page e source_form.

Non attribuire un miglioramento del workflow all'articolo. E non attribuire domanda organica a un pacchetto che non è stato rilasciato. L'impatto SEO richiede almeno 28 giorni comparabili dopo un eventuale rilascio.

Gli errori che rendono l'SLO inutile

Il primo è misurare soltanto uptime. Il servizio può essere disponibile e consegnare output sbagliati.

Il secondo è cambiare il denominatore dopo un mese difficile. Le esclusioni devono essere versionate e approvate.

Il terzo è scegliere una soglia senza baseline. Sembra precisione, ma è una preferenza scritta con il simbolo percentuale.

Il quarto è nascondere l'aiuto umano. La dashboard attribuisce al workflow un lavoro svolto dal reviewer.

Il quinto è non decidere cosa succede al rosso. Si continua a misurare mentre il danno continua.

Think, Build, Enable applicato agli SLO

Think: definisci l'esito utile, i casi validi e i fallimenti bloccanti. Parti da chi riceve il risultato.

Build: scrivi SLI, punto di misura, baseline, soglia proposta, finestra e politica di azione. Prova la classificazione su casi reali ripuliti.

Enable: assegna owner, rende visibile il margine e collega giallo e rosso a decisioni già autorizzate.

Il numero arriva alla fine. Prima devi sapere cosa stai promettendo.