La scala di delega

Un agente AI che opera per conto di un utente: quali azioni può compiere da solo, quali con conferma, quali non può compiere?

Definire la scala o lasciarla all’implementazione

Se la decisione non è presa consapevolmente, l’effetto viene determinato da come il servizio è stato implementato: lo sviluppo decide caso per caso, senza una scala condivisa.

Non è un’omissione passiva. È una delega implicita della scala a chi implementa la singola feature, che decide con criteri locali e senza vista d’insieme, senza colpa: nessuno gli ha dato una scala.

Bloccare tutte le azioni eseguibili da un agente AI è una scelta legittima, ma farlo senza saperlo no.

Cosa dice la letteratura

• Il modello a tre gradini è argomentato in L’utente si aspetta che il sistema agisca, con l’esempio: consultare il catalogo, sì; modificare un ordine, forse; disdire un contratto, probabilmente no. I criteri per salire di livello sono reversibilità dell’azione, impatto economico, presenza di dati personali o di terzi. Lo stesso fenomeno fissa il vincolo di architettura: una funzione raggiungibile unicamente percorrendo una gerarchia di menu non è delegabile a un agente.
• La letteratura sui fattori umani descrive un modello più granulare. Parasuraman, Sheridan e Wickens (2000) individuano dieci livelli di automazione applicabili a quattro funzioni distinte: acquisizione delle informazioni, analisi, selezione della decisione, esecuzione dell’azione. Nello stesso sistema queste funzioni possono stare a livelli diversi, e il modello a tre gradini usato qui ne è una semplificazione operativa. Lo stesso corpus dà un nome al problema che la scala prova a risolvere: la trust calibration (Lee e See, 2004). È la distanza tra ciò che l’utente crede che il sistema sappia fare e ciò che il sistema fa davvero. I due fallimenti tipici sono il misuse, quando si accetta un’azione automatica che andava verificata, e il disuse, quando si disattiva un’automazione affidabile. Corrispondono agli indicatori proposti in Come si misura: annullamenti e abbandoni ai punti di conferma misurano una calibrazione fuori asse, non fenomeni a sé.

Cosa comporta ciascuna scelta

Scegliere un approccio rigido. Limitare l’azione autonoma evita che un’azione dell’agente diventi un problema dell’organizzazione senza conferma umana. Il costo è che ogni richiesta di conferma può diventare un punto di uscita e rendere il sistema meno utile dell’aspettativa già osservata.

Scegliere un approccio permissivo. Un margine ampio rende la delega più comoda e consente all’agente di fare più cose. Gli errori ricadono però sull’organizzazione senza essere contrattualizzati: una prenotazione può partire da sola ma essere confermata troppo tardi, oppure un ordine può essere modificato senza un punto di conferma chiaro.

Non decidere. La scala viene definita caso per caso dallo sviluppo, senza criteri condivisi. L’abbandono può diventare inoltre invisibile, perché non esistono più punti di conferma da osservare.

Criterio per decidere

Definire tre livelli, azione autonoma, azione con conferma, azione vietata, usando reversibilità, impatto economico e presenza di dati personali o di terzi. Verificare anche che le funzioni siano esposte in modo diretto, perché una funzione raggiungibile solo attraverso una gerarchia di menu non è delegabile.

La policy deve diventare un vincolo verificabile di prodotto e sviluppo: markup semantico, stati e label espliciti, dati strutturati, selettori stabili e test automatici dei task. Il perimetro tecnico include sanificazione e prompt-injection boundary, separazione del traffico agentivo da quello umano, task success e audit trail. Le responsabilità su autorizzazione, conferma, logging e risposta agli errori restano organizzative: non possono essere lasciate alla singola feature.

I log delle azioni, la conferma esplicita sulle operazioni irreversibili e l’escalation a un operatore umano sono richiesti dal punto 5 del perimetro normativo. Sui pagamenti delegati il quadro PSD3 è ancora in fase di pubblicazione (PSD3 and PSR: 2026 readiness — Norton Rose Fulbright): non c’è ancora una data di applicazione, ma esiste già un vincolo da anticipare.

Come si misura

Tasso di annullamento dopo un’azione automatica: segnala una scala troppo larga. Abbandono ai punti di conferma e quota di disattivazione dell’automazione dopo la prova: segnalano una scala troppo stretta, o mal posizionata.

Chi decide

Leadership & Strategia. Product & Design e Ricerca & Architettura dell’Informazione preparano la proposta tecnica; Leadership & Strategia approva i tre livelli, con il vincolo legale sulle azioni irreversibili verificato contro il perimetro normativo. Senza questo secondo passaggio, la proposta tecnica resta un elenco di divieti, non una scala approvata.

Dove ricade sui ruoli

È una decisione unica che diventa lavoro in punti diversi dell’organizzazione. Se non viene presa, ciascuno di questi punti la decide per conto proprio, con criteri locali.

• Leadership & Strategia — È la funzione titolare: approva i tre livelli e la policy agentiva, cioè azioni consentite, soggetti autorizzati, responsabilità, audit e condizioni di uscita. Non approvarla non lascia il sistema fermo: lo lascia alla somma delle scelte di implementazione.
• Prodotto & Design — Traduce la scala in interfaccia: dove cade la conferma, come si annulla, quando si passa a una persona, quali segnali dicono che il sistema non è sicuro. Una scala larga sposta il lavoro sul recupero dall’errore; una scala stretta lo sposta sui punti di conferma, che sono anche punti di uscita. Sono responsabilità di calibrazione della fiducia che nella maggior parte dei team non hanno un titolare dichiarato (si veda Fiducia, AI literacy e calibrazione).
• Ricerca & Architettura dell’Informazione — Il vincolo è architetturale prima che normativo: una funzione raggiungibile solo percorrendo una gerarchia di menu non è delegabile. Vanno identificate le azioni che il servizio deve esporre, altrimenti la scala assegna permessi su cose che l’agente non può comunque compiere.
• Operazioni & Dati — La scala si verifica solo se è misurata: annullamenti dopo un’azione automatica, abbandoni ai punti di conferma, disattivazioni dell’automazione dopo la prova. Va inoltre separato il traffico agentivo da quello umano, o i numeri descrivono il software e non le persone.

Fenomeni correlati

• L’utente si aspetta che il sistema agisca — È la pressione che rende operativo il vincolo: si può delegare solo ciò che il servizio espone come azione identificabile.
• Fiducia, AI literacy e calibrazione — Contiene gli indicatori con cui si capisce se la scala è tarata: annullamenti, verifiche esterne dell’output, abbandoni alle conferme, disattivazioni dopo la prova.
• Il perimetro normativo (voci 5 e 8) — Fissa il pavimento non negoziabile: conferme sull’irreversibile, logging e politica di accesso agentivo sono obblighi, non preferenze di prodotto.