Prima l’autorità, poi l’autonomia nell’Enterprise AI
L’Enterprise AI non diventa sicura o utile con un unico livello di autonomia. L’autorità va guadagnata azione per azione: osservare, raccomandare, simulare, scrivere dopo approvazione e infine operare entro limiti misurabili. Questa progressione collega capacità tecnica e responsabilità operativa.
La domanda sbagliata sugli agenti
Chiedere se un agente debba essere autonomo è troppo generico. Può leggere l’inventario in sicurezza ma non essere qualificato a cambiare un reorder point; può redigere bene una risposta senza poterla inviare; può riconciliare pattern noti e portare una fee insolita all’attenzione umana.
L’autonomia non è una proprietà del modello. È un permesso associato a un’azione definita in condizioni definite. Lo stesso sistema può avere livelli diversi per retrieval, analisi, comunicazione e mutation. Un solo interruttore blocca automazione utile oppure concede più potere di quanto l’evidenza giustifichi.
Il rapporto BCG e Consumer Goods Forum del giugno 2026 descrive il divario fra sperimentazione e valore su scala, evidenziando governance e operating model. Per noi è un problema di esecuzione: occorre trasformare in modo ripetibile la performance del modello in autorità operativa circoscritta.
Capacità, permesso e accountability
La capacità chiede se il sistema produce un risultato accettabile. Il permesso stabilisce se può eseguire l’azione in quel contesto. L’accountability identifica chi risponde dell’esito, quale evidenza resta e chi interviene in caso di errore.
Un benchmark risponde solo in parte alla prima domanda; non concede permesso. Il nostro metodo per harness design e model routing parte quindi dai gate di privacy e residency: prima si determina il percorso ammesso, poi si confrontano qualità, latenza e costo.
Una scala di autorità per ogni azione
1. Read-only
Il sistema legge dati approvati e osserva eventi, ma non propone ancora una decisione su un canale produttivo. Qui si dimostrano identità, scope, logging e trattamento dei dati. Anche la lettura richiede controllo granulare per record cliente, dati HR, accordi di prezzo e log di sicurezza.
2. Recommend
Il sistema propone un’azione a una persona autorizzata mostrando input, policy, incertezza, alternative ed effetto atteso. Un semplice «approva» non trasferisce comprensione. Misuriamo quindi qualità, correzioni del reviewer e outcome, non soltanto acceptance rate.
3. Dry-run
Il sistema costruisce la scrittura esatta e la valida senza modificare la produzione: endpoint di validazione, shadow table con diff deterministico o messaggio pronto ma non inviabile. Emergono così ID invalidi, stato obsoleto, permessi errati, rate limit e fan-out imprevisto. Il pattern validate_only della nostra guida alle operazioni Google Ads API ne è un esempio.
4. Scrittura approvata
Dopo l’approvazione il sistema esegue una modifica specifica. L’approvazione è legata al payload esaminato e scade se cambiano prezzo, destinatario, quantità o stato. Il write path richiede idempotenza, precondizioni, credenziali least-privilege, audit e recovery. “Human in the loop” è un controllo solo se la persona vede i campi decisivi, sa valutarli e può fermare l’azione.
5. Autonomia circoscritta
Il sistema agisce senza approvazione caso per caso entro un perimetro esplicito: tipo di azione, account, finestra, valore, volume, confidenza, freschezza e classe di eccezione. Fuori dal perimetro rifiuta o scala. L’autorità è guadagnata con evidenza di produzione e può essere ridotta.
Definire l’action contract
| Campo | Domanda |
|---|---|
| Intento | Quale outcome aziendale serve l’azione? |
| Target | Quale sistema, oggetto e campo può cambiare? |
| Eligibilità | Quali account, casi e classi di dati sono ammessi? |
| Precondizioni | Cosa deve essere vero e aggiornato all’esecuzione? |
| Limiti | Quali soglie di valore, volume, tempo e confidenza? |
| Evidenza | Quali input, regole, modelli e approvazioni conservare? |
| Recovery | L’azione è reversibile, compensabile o contenibile? |
| Owner | Chi risponde dell’esito e gestisce il fallimento? |
Il contratto impedisce che un caso conversazionale limitato riceva credenziali amministrative molto più ampie. Rende anche comparabili le azioni per il management e traduce la policy in schema, assertion e test per i builder.
L’evidenza che fa guadagnare autorità
Combiniamo qualità decisionale, esecutiva, operativa e dei controlli: errori pesati per severità, calibrazione, payload validi, precondizioni, duplicati, latenza, escalation, correzioni, outcome, violazioni d’accesso, provenienza e audit.
Le misure richiedono denominatori, coorti e severità. Una media può nascondere una classe minoritaria pericolosa. Quando la scala interna è confidenziale usiamo indici: se il volume d’intervento pesato all’avvio è Baseline = 100, i periodi successivi mostrano la direzione, non provano causalità del modello.
Promozione e retrocessione devono essere simmetriche
Spesso si definisce come l’automazione acquisti autorità, non come la perda. La promozione può richiedere un campione rappresentativo, nessun errore critico aperto, rollback testato e firma dell’owner. Tempo e acceptance rate non bastano.
La retrocessione deve scattare per dati mancanti o obsoleti, policy errata, volume anomalo, riconciliazione fallita, rollback indisponibile, distribution shift o credenziali scadute. Il sistema può tornare da autonomia a scrittura approvata, recommend o read-only senza essere spento interamente.
Separare modelli e controlli deterministici
L’autorità appartiene all’action gateway, non al modello. I modelli interpretano, recuperano evidenze, classificano e redigono; servizi deterministici impongono identità, schema, soglie, campi consentiti, precondizioni e idempotenza.
L’output del modello resta input non fidato: viene convertito in proposta tipizzata, risolto sullo stato corrente, ricalcolato dove possibile, respinto in presenza di campi ignoti e rivalidato all’esecuzione. La nostra guida agli agent skill specifici di dominio descrive workflow circoscritti; il livello di autorità aggiunge il controllo produttivo.
Il ruolo umano cambia
Nel recommend la persona valuta il caso; nella scrittura approvata verifica anche la conseguenza esatta; nell’autonomia circoscritta si concentra su perimetro, campionamento, eccezioni e salute del sistema. L’accountability non scompare: passa dal lavoro ripetitivo alla control ownership.
Override ripetuti dagli operatori sono un segnale di apprendimento, non un problema di adozione. Spesso rivelano contesto mancante prima delle metriche aggregate.
Un rollout pratico
- Definire action contract e owner responsabile.
- Applicare gate di privacy, residency, identità e data readiness.
- Costruire un set valutato con casi rari e avversi.
- Operare read-only e recommend con provenienza completa.
- Provare l’integrazione reale con dry-run e diff deterministico.
- Abilitare approvazioni legate al payload, rollback e incident procedure.
- Concedere un perimetro autonomo stretto a una coorte rappresentativa.
- Riesaminare outcome, eccezioni e controlli; promuovere o retrocedere per regola.
Non ogni azione deve diventare autonoma. Scritture rare, irreversibili o fortemente contestuali possono richiedere sempre un’approvazione individuale. La scala migliora comunque raccomandazione ed esecuzione.
La decisione executive
La governance diventa concreta quando il management approva action contract, non “agenti”. Il budget segue outcome misurabili, il rischio si discute in termini di scope, reversibilità ed evidenza, e Technology confronta modelli nel pool ammesso senza ridisegnare l’autorità.
Il principio è semplice: la capacità merita considerazione, l’evidenza merita permesso, l’ownership mantiene l’autorità.