Il primo Capo di Gabinetto IA va trattato come una funzione, non come un assistente

La conversazione che sento più spesso nelle stanze direzionali è sbagliata. Si discute di quanto un Capo di Gabinetto IA debba essere autonomo — se possa rispondere alle email da solo, se possa muovere appuntamenti, se possa scrivere su HubSpot senza chiedere. È la domanda sbagliata.

Il rischio vero non è l'eccesso di autonomia. È distribuire uno strumento potente senza dirgli — per iscritto — cosa può toccare, quanto può spendere, e quando deve fermarsi e chiamare un umano.

Quando manca quel perimetro succede una cosa precisa: si crea shadow ops. Operazioni che funzionano, che producono output apparentemente buono, ma che nessuno ha autorizzato, nessuno controlla e nessuno può ricostruire a posteriori. È esattamente il punto cieco che vedo nelle aziende che corrono.

Nel 2026 l'87% delle aziende sta aumentando i budget IA, ma solo il 14% ha chiarito chi risponde dei risultati. Quel divario non è una sfumatura organizzativa. È la ragione per cui il 48% dei progetti IA manca gli obiettivi di business. Il problema non sta nel modello. Sta nel fatto che nessuno ha scritto le regole d'ingaggio.

Ho lavorato con abbastanza founder e COO da riconoscere la differenza tra un buon Capo di Gabinetto e un task manager. Il task manager esegue ciò che gli dici. Il Capo di Gabinetto opera dentro un mandato: sa quali decisioni può prendere da solo, quali deve riportare, e di quali budget dispone senza chiedere ogni volta.

Quella delega non è implicita. In un'organizzazione seria è scritta. Definisce ambito, autorità di spesa, sistemi a cui ha accesso e i casi in cui deve scalare.

Il primo Capo di Gabinetto IA va trattato esattamente così. Non come un assistente intelligente da 'configurare', ma come una funzione governata. La logica che la regolamentazione sta imponendo alla pubblica amministrazione vale, identica, per chi dirige un'azienda: serve una linea di proprietà chiara, audit regolari e valutazioni del rischio documentate.

La frase che gli esperti di governance ripetono è netta: chi decide il budget deve portare la responsabilità della governance. Qualunque altra cosa crea uno scarto tra decisione e responsabilità. Tradotto sul tuo lavoro quotidiano: se il tuo Capo di Gabinetto IA scrive a un cliente su Gmail o aggiorna una trattativa su Pipedrive, deve essere chiaro chi risponde di quell'azione. E deve esserlo prima, non dopo l'incidente.

Una funzione si definisce dal controllo che ha sulle risorse. Il tuo Capo di Gabinetto IA, se gli permetti di agire, prima o poi tocca qualcosa che costa: un abbonamento su Stripe, un rinnovo, una sponsorizzazione, un upgrade di tool. La domanda non è se lo farà, ma con quale tetto.

Il mandato deve fissare una soglia di spesa autonoma. Sotto quella cifra agisce. Sopra, scala. È banale da scrivere ed è la cosa che quasi nessuno scrive.

L'autorità di budget è anche ciò che rende il sistema reattivo. Un Capo di Gabinetto che deve aspettare un'approvazione per ogni movimento da cinquanta euro non ti fa risparmiare tempo: ti aggiunge un passaggio. Uno con un tetto chiaro e un audit trail su ogni spesa ti libera davvero, perché puoi controllare a posteriori invece di approvare a priori.

La regola pratica che do agli operatori: definisci tre fasce. Spesa autonoma sotto soglia, spesa che richiede una tua conferma a un tocco, spesa che il sistema non può proprio iniziare. Scrivile. Sono la prima riga del mandato operativo.

Il secondo blocco del mandato sono i permessi. Non in senso tecnico — chi ha l'accesso OAuth — ma in senso operativo: quali decisioni il Capo di Gabinetto IA può prendere su ciascun sistema.

Leggere Gmail e proporre una bozza è una cosa. Inviare in autonomia è un'altra. Aggiornare lo stage di una trattativa su HubSpot è diverso dal chiudere un deal. Creare un issue su Linear è diverso dal riassegnare priorità a tutto il team. Spostare un meeting su Calendly è diverso dal cancellare la call trimestrale con un investitore.

La regolamentazione che oggi vincola la PA è esplicita su questo: per i sistemi a rischio più alto serve un'autorità chiara di approvare o fermare un'azione, accesso a log e audit trail, e la possibilità di imporre correzioni. Lo stesso principio si traduce nel tuo stack. Per ogni integrazione devi sapere se il Capo di Gabinetto può agire, proporre, o solo osservare.

È qui che apprezzo come lavora Moments: l'IA è collegata a email, calendario, contatti, documenti e browser, e proprio perché vede tutto, il punto non è quanto può fare ma cosa è stato deciso che faccia su ognuno di quei canali. Un Capo di Gabinetto che vede tutto e agisce senza perimetro non è un assistente: è un rischio operativo travestito da efficienza.

Il terzo blocco è quello che protegge te. Le soglie di escalation sono i criteri predefiniti che fanno scattare l'intervento umano. Un cliente irritato che alza il tono su un thread. Un pagamento contestato su Stripe. Una richiesta legale. Una decisione che impegna l'azienda oltre una certa cifra o un certo orizzonte.

Senza queste soglie, l'IA fa una scelta implicita ogni volta che incontra un caso limite. E le scelte implicite sono esattamente ciò che dopo non riesci a ricostruire.

Gli SLA vanno nella direzione opposta: definiscono cosa il Capo di Gabinetto deve garantire. Tempi di risposta su una certa categoria di email, frequenza di aggiornamento del CRM, finestra entro cui un thread caduto viene ripreso. Sono le promesse della funzione, e ti permettono di misurarla come misureresti una persona.

L'audit trail tiene insieme tutto. Ogni azione tracciata, ricostruibile, leggibile. La normativa europea spinge verso la trasparenza e la registrazione delle decisioni proprio perché senza traccia non c'è responsabilità. Per te significa una cosa concreta: poter aprire il registro di un lunedì mattina e vedere cosa è stato fatto, da chi è stato autorizzato, e dove il sistema si è fermato a chiedere. È la differenza tra delegare e perdere il controllo.

Mettere budget, permessi e soglie in un documento non è burocrazia. È la condizione perché la delega funzioni. La normativa lo chiama mandato operativo; nella pratica direzionale è il contratto tra te e la tua funzione IA.

Deve dire poche cose, chiaramente: l'ambito di autorità del Capo di Gabinetto, i suoi tetti di spesa, i permessi per ogni sistema, le soglie che fanno scattare l'escalation, e il modo in cui la supervisione umana resta documentata. Le linee guida italiane per la PA chiedono regole interne scritte e una classificazione della maturità — e suggeriscono di rivedere i piani ogni due anni, perché la tecnologia si muove troppo in fretta per un documento congelato.

Vale anche per te. Un mandato non è un atto unico. Lo rivedi quando aggiungi un'integrazione, quando alzi un tetto di spesa, quando il Capo di Gabinetto dimostra di gestire bene una categoria di decisioni e gliene affidi una in più.

E c'è un dettaglio che gli esperti di governance non si stancano di ripetere: il mandato deve allinearsi alle strutture di potere reali, non all'organigramma. Se nella pratica sei tu a decidere su una certa area, il perimetro dell'IA su quell'area deve rispondere a te. Quando autorità e responsabilità non coincidono, si aprono i buchi. E i buchi, con un sistema che agisce da solo, si riempiono in fretta.

Non serve un progetto da sei mesi. Serve un foglio.

Elenca i sistemi a cui il tuo Capo di Gabinetto IA ha accesso — Gmail o Outlook, il CRM che usi, Slack, lo strumento di project management, il calendario. Per ognuno scrivi tre colonne: cosa può fare da solo, cosa deve farti confermare, cosa non può iniziare. Aggiungi il tetto di spesa autonoma. Aggiungi due o tre soglie di escalation che contano davvero per la tua attività.

È il novanta per cento del valore in un'ora di lavoro.

Il founder che salta questo passaggio non sta correndo più veloce. Sta accumulando decisioni implicite che un giorno dovrà ricostruire senza traccia. Quello che lo scrive trasforma uno strumento potente in una funzione di cui si fida — e di cui risponde.

La delega senza mandato non è fiducia. È solo rischio che non hai ancora visto.