Guida applicativaApprovazione e supervisione

Delega il lavoro, non un'autorità senza limiti

Quando il tuo agente può modificare sistemi, l'autorità delimitata rende l'autonomia verificabile con i principi Blueprint P5, P7, P8 e P10.

Di Michelangelo Zampogna · Pubblicata il 13 ottobre 2026

Fatti chiave

Best fit: Team di prodotto, sicurezza e piattaforma che introducono agenti con accesso ai sistemi aziendali.
Primary risk: Deriva dell'autorità: l'agente agisce oltre i permessi o l'approvazione ricevuti.
Core shift: Autonomia generalizzata → autorità esplicita e applicata a ogni azione.
Success signal: Le azioni fuori perimetro vengono bloccate prima dell'esecuzione; quelle approvate conservano una traccia decisionale ricostruibile.
Doctrine mapping: P5, P7, P8, P10

L'autorità è un accordo da far rispettare

Al tuo agente non bastano un obiettivo e un modello capace: serve un perimetro operativo preciso. Definisci cosa può leggere, proporre ed eseguire, quali decisioni spettano a una persona responsabile e come puoi intervenire. Blueprint collega questi confini a capacità comprensibili, decisioni verificabili, approvazioni esplicite e controlli disponibili per tutta l'esecuzione.

Un'illustrazione editoriale astratta senza testo mostra i percorsi ramificati di un agente dentro un confine con finestre di ispezione, un punto di approvazione e un controllo di arresto. — L'autonomia utile resta entro un confine di autorità effettivo.

Perché l'autorità delimitata conta oggi

Quando il tuo agente può inviare messaggi, modificare record o cambiare accessi, una raccomandazione utile può diventare un'azione con conseguenze concrete. L'autorità delimitata rende comprensibili capacità e limiti attraverso P5 – Sostituire la magia implicita con modelli mentali chiari, mentre P8 – Rendere espliciti i passaggi di consegne, le approvazioni e i blocchi chiarisce dove l'esecuzione deve attendere una decisione.

Separa lettura, proposta ed esecuzione: poter accedere a un contenuto non significa essere autorizzati ad agire su quel contenuto. (P5)

Assegna un responsabile dell'approvazione a ogni azione rilevante e definisci un sostituto quando non è disponibile. (P8)

Mantieni per impostazione predefinita le decisioni finali sulle revisioni degli accessi in capo a una persona; lascia che l'agente raccolga elementi e prepari raccomandazioni entro un perimetro documentato. (P8)

Perché i permessi standard degli agenti non bastano

Un account di servizio con ampi privilegi e l'istruzione di chiedere prima non creano un confine di approvazione effettivo. P7 – Stabilire la fiducia attraverso l'ispezionabilità richiede una traccia decisionale verificabile, e P10 – Ottimizzare per orientare il lavoro, non solo per avviarlo richiede controlli capaci di reindirizzare o fermare il lavoro già iniziato.

Approvazione affidata alle istruzioni: chiedi al modello di attendere, ma le credenziali degli strumenti consentono comunque l'esecuzione immediata. Applica il vincolo fuori dal modello. (P8)

Approvazione senza contesto: chi decide vede solo “Approvare?”, senza destinatario, modifica proposta, elementi di supporto o impatto. Prepara invece un pacchetto decisionale. (P7)

Approvazione non più valida: l'oggetto o la modifica differiscono da quelli accettati. Invalida l'approvazione quando cambiano dati rilevanti per la decisione. (P8)

Arresto solo apparente: l'interfaccia indica che l'esecuzione è ferma, ma i lavori in coda possono ancora partire. Collega il controllo al blocco delle nuove azioni e alla revoca delle credenziali. (P10)

Come Blueprint sostituisce l'autonomia indiscriminata

Sostituisci un unico livello di autonomia con un accordo operativo per ciascun flusso: risorse consentite, operazioni ammesse, condizioni di approvazione e azioni vietate. La tua interfaccia spiega questo accordo, mentre un livello di esecuzione indipendente lo fa rispettare e registra ogni decisione. (P5, P7, P8)

Descrivi ogni azione indicando risorsa, operazione, destinazione, limiti e reversibilità; distingui “preparare una risposta” da “inviare una risposta”. (P5)

Fai passare le azioni proposte attraverso un gateway che verifica regole, permessi e approvazioni prima di invocare uno strumento. Blocca per impostazione predefinita le operazioni non riconosciute. (P8)

Mostra stati utili per intervenire: “Raccolta degli elementi”, “In attesa dell'approvazione del responsabile”, “Bloccato: inventario non aggiornato” e “Fermato: nuove azioni non consentite”. (P5, P8)

Conserva riferimenti alle fonti, modifica proposta, versione delle regole, versione del modello, approvatore ed esito; una spiegazione convincente non sostituisce questa traccia. (P7)

Mantieni disponibili pausa, riduzione del perimetro e arresto durante l'esecuzione, spiegando cosa ciascun controllo può e non può interrompere. (P10)

Come implementare l'autorità delimitata

Parti da un solo flusso e definisci il suo accordo operativo prima di collegare strumenti capaci di scrivere nei sistemi. Verifica i permessi al momento dell'esecuzione, poi prova approvazioni e arresto con richieste intenzionalmente non valide. (P5, P8, P10)

Censisci operazioni e responsabili. Per ogni operazione definisci risorse consentite, requisiti di aggiornamento dei dati, limiti di spesa o volume, condizioni di approvazione e destinazioni vietate. (P5, P8)

Assegna all'agente un'identità dedicata con credenziali limitate e di breve durata, dove supportato. Tieni le credenziali di esecuzione fuori dal contesto visibile al modello e verifica gli argomenti strutturati degli strumenti rispetto all'accordo operativo. (P8)

Tratta documenti e messaggi recuperati come elementi informativi, non come autorizzazioni. Rifiuta i tentativi di ampliare il perimetro attraverso quei contenuti e segnala la mancanza di accesso invece di provare credenziali alternative. (P5, P8)

Prepara pacchetti di approvazione con azione esatta, oggetto interessato, aggiornamento delle fonti, regola applicabile, impatto previsto e opzioni di recupero. Vincola l'approvazione ai parametri dell'azione, alla versione della risorsa, alla versione delle regole e a una scadenza; rifiuta riutilizzi e dati modificati. (P7, P8)

Ricontrolla l'autorità immediatamente prima di eseguire. Usa scritture condizionali, dove disponibili, per evitare modifiche tra verifica e azione; altrimenti impedisci modifiche concorrenti o richiedi una nuova revisione. (P8)

Registra tentativi consentiti, negati e falliti in un archivio di audit con accesso controllato e alterazioni rilevabili. Applica regole di conservazione e oscuramento; non registrare credenziali in chiaro o dati personali non necessari. (P7)

Monitora chiamate negate, destinazioni inattese, dati non aggiornati e tentativi ripetuti. Blocca l'avvio di nuove azioni, annulla quelle in coda e revoca le credenziali quando necessario; mostra separatamente le azioni già in corso, perché annullarle potrebbe non invertirne gli effetti. (P7, P10)

In un ambiente isolato, prova violazioni del perimetro, approvazioni scadute, approvatori indisponibili, richieste duplicate e arresto durante l'esecuzione. Usa la validazione Blueprint per verificare che l'interfaccia renda comprensibili questi confini, insieme ai test tecnici dei controlli. (P5, P8, P10)

Brief di partenza

Task: Preparare raccomandazioni di revisione degli accessi per una sola applicazione
Scope: Leggere snapshot autorizzati di permessi e utilizzo; nessuna modifica agli accessi
Escalate when: I dati non sono aggiornati, manca un responsabile o serve una decisione finale sugli accessi
Success signal: Ogni raccomandazione ha riferimenti alle fonti e un responsabile umano della decisione

Livelli di escalation e governance

Classifica ogni operazione in base all'impatto e applica il requisito di approvazione prima dell'esecuzione; un'elevata confidenza dichiarata dal modello non giustifica un livello di autonomia superiore. (P8)

Tier	Action type	Risk level	Required approval
Livello 1: Autonomia delimitata	Leggere snapshot autorizzati, confrontare permessi e preparare raccomandazioni senza modificare accessi	Inferiore entro il perimetro approvato; resta il rischio di esposizione dei dati	Il responsabile approva il perimetro iniziale; le regole verificano ogni azione
Livello 2: Esecuzione con approvazione umana	Inviare messaggi esterni o applicare una modifica consentita agli accessi dopo una decisione umana responsabile	Conseguenze rilevanti o difficili da annullare	Un revisore autorizzato approva l'azione esatta; modifiche o scadenza invalidano l'approvazione
Livello 3: Azioni vietate o eccezionali	Ampliare i propri permessi, disabilitare l'audit o agire su risorse fuori dal perimetro approvato	Fuori dalle condizioni operative autorizzate	Esecuzione negata; cambiare il perimetro richiede una revisione di governance separata, non un'approvazione durante l'esecuzione

Anti-pattern e pattern Blueprint

Usa questi confronti per individuare differenze tra ciò che promette la tua interfaccia e ciò che il livello di esecuzione fa realmente rispettare. (P5, P8)

Anti-pattern: Una sola credenziale con ampi privilegi per leggere, preparare ed eseguire
Pattern Blueprint: Capacità separate e limiti sulle risorse verificati a ogni chiamata agli strumenti (P5, P8)

Anti-pattern: Un prompt chiede di ottenere il consenso prima di agire
Pattern Blueprint: Un gateway di esecuzione blocca le azioni rilevanti senza un'approvazione valida (P8)

Anti-pattern: L'approvazione vale per tutta la conversazione senza scadenza
Pattern Blueprint: L'approvazione riguarda un'azione esatta, una versione della risorsa e una scadenza (P8)

Anti-pattern: La spiegazione dell'agente è l'unica traccia di audit
Pattern Blueprint: Fonti, decisioni sulle regole, approvazioni ed esiti degli strumenti restano verificabili (P7)

Anti-pattern: Il pulsante di arresto cambia solo lo stato visualizzato
Pattern Blueprint: L'arresto blocca nuove azioni e distingue quelle in coda, in corso e completate (P10)

Anti-pattern: Le approvazioni precedenti diventano nuove regole senza revisione
Pattern Blueprint: Modifiche a modello e regole sono versionate, testate e riviste prima di cambiare l'autorità (P7, P8)

Scenario illustrativo

Queste ricostruzioni composite e anonime illustrano come può comportarsi il tuo confine di approvazione.

Un team usava un flusso di revisione degli accessi in sola lettura con un gateway di esecuzione separato. L'agente ha tentato di raccomandare la rimozione di un permesso inutilizzato. Il sistema ha segnalato un blocco perché lo snapshot di utilizzo superava il limite di aggiornamento previsto. Il revisore ha richiesto dati recenti e nessuna modifica agli accessi è stata inoltrata mentre la raccomandazione restava irrisolta.

Un team usava approvazioni vincolate alle azioni per le notifiche ai clienti. L'agente ha tentato di inviare una bozza approvata dopo una modifica ai destinatari. Il sistema ha richiesto una nuova decisione perché i parametri non corrispondevano più all'approvazione. Il revisore ha fermato l'esecuzione; gli invii in coda sono stati annullati e un messaggio già inoltrato è rimasto visibile per gli interventi successivi, senza essere indicato come revocato.

Domande frequenti

Le domande più comuni quando il tuo team trasforma l'autonomia degli agenti in autorità delimitata e verificabile.

L'autorità delimitata richiede di approvare ogni chiamata agli strumenti?

No: il tuo agente può leggere dati autorizzati e preparare bozze entro un perimetro già approvato. Introduci approvazioni in base a impatto, sensibilità e reversibilità, invece di chiedere un clic a ogni passaggio. Fai rispettare queste distinzioni fuori dal modello. (P5, P8)

L'agente può prendere decisioni finali nelle revisioni degli accessi?

Per impostazione predefinita, lascia le decisioni finali a una persona responsabile. Il tuo agente può organizzare i permessi, individuare anomalie e preparare raccomandazioni basate su elementi verificabili. Un'eventuale delega successiva dell'autorità finale richiede una decisione di governance separata, sostenuta da controlli sulla qualità dei dati, regole stabili, comportamento validato e registrazioni verificabili. (P7, P8)

Un prompt di sistema basta a definire il confine?

Un prompt può spiegare il confine, ma non garantisce il rispetto dei permessi degli strumenti. Il livello di esecuzione deve verificare operazioni consentite, risorse e validità dell'approvazione prima di agire. Le azioni negate devono comparire come blocchi espliciti, non avviare tentativi di aggiramento. (P5, P8)

Cosa deve vedere chi approva?

Mostra azione esatta, risorsa interessata, fonti, aggiornamento dei dati, regola applicabile, impatto previsto e opzioni di recupero. Includi incertezza e informazioni mancanti, non soltanto un punteggio di confidenza. Consenti di consultare gli elementi di supporto senza rileggere tutta la conversazione. (P7, P8)

Cosa deve garantire il controllo di arresto?

Definisci esplicitamente la garanzia: bloccare nuove azioni, annullare quelle in coda dove possibile e revocare le credenziali di esecuzione quando opportuno. Un'azione già accettata da un sistema esterno potrebbe comunque completarsi. Mostra questa attività residua e le eventuali azioni compensative separatamente dall'esecuzione fermata. (P5, P10)

Come devono influire gli aggiornamenti del modello sull'autorità?

Non lasciare che un aggiornamento o un ciclo di apprendimento ampli automaticamente i permessi. Registra le versioni del modello e delle regole per ogni esecuzione e prova le modifiche sugli stessi casi di approvazione e rifiuto. Tratta i cambiamenti di autorità come decisioni di governance, non come normali miglioramenti del modello. (P7, P8)

Dove si inserisce la validazione Blueprint?

Usala per verificare se gli utenti possono comprendere il perimetro, esaminare la decisione, identificare chi approva e intervenire durante l'esecuzione. Affianca questa revisione progettuale ai test isolati su permessi, approvazioni non più valide e arresto. La validazione dell'interfaccia non è una certificazione di sicurezza e non sostituisce i test tecnici. (P5, P7, P8, P10)

Checklist iniziale

Definisci risorse consentite, operazioni ammesse e azioni vietate per un solo flusso. (P5)
Separa lettura, preparazione ed esecuzione nei permessi degli strumenti. (P5, P8)
Assegna responsabili delle approvazioni, scadenze e un percorso che mantenga il blocco se il revisore non è disponibile. (P8)
Vincola l'approvazione all'azione esatta e ricontrolla lo stato della risorsa prima di eseguire. (P8)
Conserva fonti, versioni delle regole, approvazioni ed esiti con controlli sui dati sensibili. (P7)
Collega pausa e arresto all'avvio delle azioni, alle code e alla revoca delle credenziali. (P10)
Prova azioni negate, dati non aggiornati, parametri modificati e arresto durante l'esecuzione in un ambiente isolato. (P7, P8, P10)

Valida l'architettura

Prossimi passi per l'autorità delimitata

Rendi il primo perimetro abbastanza ristretto da poterlo testare e abbastanza chiaro da poterlo spiegare a chi approva. Amplialo solo quando il tuo team sa ricostruire le decisioni e dimostrare il funzionamento dei controlli di intervento. (P5, P7, P10)

Nel repository del flusso, documenta una matrice delle operazioni con risorse, permessi, responsabili e punti di approvazione. (P5, P8)

Nel gateway degli strumenti, implementa il rifiuto predefinito e la verifica delle approvazioni vincolate alle azioni per una sola operazione rilevante. (P8)

Nel tuo strumento di design, prototipa il pacchetto di approvazione, lo stato bloccato e il riepilogo dell'arresto; rivedili usando i principi Blueprint. (P5, P7, P10)

Nell'ambiente di test, prova approvazione scaduta, risorsa modificata e arresto durante l'esecuzione, poi allega le tracce alla revisione del rilascio. (P7, P8, P10)

Principi di riferimento

Run Validation

Rendere espliciti i passaggi, le approvazioni e i blocchi

Leggi →Save to Workspace

Stabilire fiducia attraverso l'ispezionabilità

Leggi →