Il permesso permanente è il vero rischio del Capo di Gabinetto IA, non l'autonomia

Quando un founder o un operatore mi chiede se fidarsi di un Capo di Gabinetto IA, la domanda che pone quasi sempre è: quanto può decidere da solo? Può rispondere a un cliente senza chiedermi conferma? Può muovere un deal in Pipedrive senza che io lo veda prima?

È una domanda legittima, ma è la domanda sbagliata. Il dibattito giuridico e amministrativo italiano su intelligenza artificiale e decisioni automatizzate ha già affrontato questo punto: la legge 132/2025 stabilisce che l'IA deve avere una funzione di supporto, con la persona che resta l'unica responsabile della decisione finale. L'autonomia, insomma, è già formalmente contenuta.

Il problema che nessuno guarda con la stessa attenzione è quello che resta acceso dopo. Non la decisione singola, ma l'accesso permanente che ha permesso di prenderla.

Nel 2026 il Consiglio di Stato ha annullato un concorso pubblico gestito tramite una piattaforma IA esterna. Il motivo non era che l'algoritmo avesse deciso male. Il motivo era che non esisteva il codice sorgente, non esistevano le specifiche tecniche, non esistevano i log del sistema. Nessuno poteva verificare cosa fosse successo, quindi l'intero processo è stato dichiarato illegittimo.

La lezione non riguarda solo la pubblica amministrazione. Riguarda qualsiasi contesto in cui un sistema opera con un accesso che nessuno rivede: se non c'è traccia di cosa è cambiato, di chi ha ancora accesso a cosa e perché, l'intero impianto diventa impossibile da controllare nel momento in cui qualcosa va storto.

Un Capo di Gabinetto IA che ha accesso a Gmail, al calendario, al CRM e magari a Stripe per la fatturazione è esattamente in questa posizione. Il permesso concesso al setup — 'accesso completo alla casella, ai contatti HubSpot, alle scadenze di pagamento' — resta valido per default, finché qualcuno non lo revoca attivamente. E nessuno lo revoca mai attivamente, perché nessuno ci pensa più.

Il TAR Veneto, nella sentenza 1845/2025, ha introdotto un principio che chiamano 'legalità algoritmica': una procedura interamente automatizzata è lecita solo se autorizzata espressamente e accompagnata da garanzie adeguate. Non basta che il sistema funzioni. Deve esserci un quadro che stabilisce quando e come quella autorizzazione va rivista.

Il GDPR, all'articolo 22, va nella stessa direzione: nessuno deve essere sottoposto a una decisione che produce effetti significativi basata solo su un trattamento automatizzato, senza un meccanismo di verifica umana. Il principio non è 'l'IA non può decidere'. È: 'la decisione e l'accesso che l'hanno rese possibile devono poter essere riesaminati'.

Nella maggior parte dei setup aziendali che ho visto, questo riesame non esiste. Si configura l'integrazione con Gmail o Outlook una volta, si collega il CRM, si dà il via libera alla lettura del calendario e delle email finanziarie, e poi si passa ad altro. Il permesso diventa permanente per inerzia, non per scelta.

Ho visto questo pattern ripetersi: un founder assume un operations manager, gli dà accesso completo al Capo di Gabinetto IA — email, Linear, HubSpot, calendario condiviso — per gestire l'onboarding dei clienti. Sei mesi dopo l'operations manager cambia ruolo, si occupa solo di partnership, non tocca più i ticket dei clienti. L'accesso che il sistema IA aveva configurato per lui resta identico. Nessuno lo ha aggiornato perché nessuno aveva un motivo per accorgersene: il sistema continuava a funzionare, quindi sembrava tutto a posto.

È lo stesso meccanismo dell'inerzia amministrativa descritto nel contesto dei permessi di soggiorno di lungo periodo: una volta concesso lo status, gli ostacoli burocratici e legali per rivederlo sono così alti che gli errori si radicano invece di essere corretti. Con un Capo di Gabinetto IA il costo di correggere non è burocratico, è semplicemente l'assenza di un trigger. Nessuno ha impostato una scadenza, quindi non scatta nessuna revisione.

Lo stesso vale per i clienti che vanno via o per i fornitori con cui non si lavora più: l'accesso del sistema IA ai loro thread email o alle loro schede in Pipedrive resta lì, valido, finché qualcuno non se ne ricorda per caso durante un audit.

Il principio di legalità algoritmica applicato a un contesto operativo si traduce così: ogni mandato del Capo di Gabinetto IA dovrebbe avere una data di scadenza incorporata, non un'autorizzazione configurata al setup e lasciata correre. Non perché il sistema sia pericoloso in sé, ma perché il contesto che ha giustificato quel permesso — un ruolo, un progetto, un livello di fiducia — cambia molto più spesso di quanto cambino le impostazioni di accesso.

In pratica significa poche cose concrete: la revisione dei permessi va agganciata a eventi che già succedono — un cambio di ruolo, la chiusura di un progetto in Linear, la fine di un rapporto con un cliente in HubSpot — non lasciata a una revisione trimestrale che nessuno fa mai davvero. Significa anche che l'accesso a dati sensibili, come le email finanziarie o le informazioni di pagamento collegate a Stripe, dovrebbe avere una scadenza più corta e più rigida rispetto all'accesso a un calendario condiviso, perché il danno potenziale è diverso.

È lo stesso ragionamento della sentenza del Consiglio di Stato sulla tracciabilità: se non c'è un log di quando un permesso è stato concesso, perché, e quando dovrebbe essere rivisto, non c'è modo di sapere se quell'accesso è ancora giustificato. La differenza tra un Capo di Gabinetto che protegge l'operatore e uno che accumula rischio silenzioso non è la sofisticatezza del modello. È se qualcuno ha mai deciso quando quell'accesso dovrebbe finire.