La scena è sempre la stessa e non sembra mai grave. Qualcuno del team se ne va — offerta migliore, cambio di città, fine contratto —, c’è la torta, ci sono i buoni auguri e c’è una checklist di uscita che qualcuno ripassa con diligenza: restituire il portatile, chiudere la mail, togliere l’accesso al CRM, saldare la busta paga. Tutto corretto. E da qualche parte, il flusso che quella persona ha montato quattordici mesi fa per classificare le fatture che arrivano via mail continua a partire alle 7:05 del mattino, come ogni giorno. Nessuno lo mette nella checklist, perché il processo non si è rotto. Funziona. È esattamente questo il problema.
La tesi in una riga: il rischio operativo dell’IA in un’azienda senza team di piattaforma non entra da un attacco, entra da un’uscita. Nessuna intrusione, nessuna vulnerabilità, niente che un antivirus rilevi. C’è un processo vivo che gira con l’identità di qualcuno che non c’è più, e una logica che viveva nella sua testa. Il guasto non arriva il giorno del saluto: arriva settimane dopo, quando scade un token, quando si ruota una password, o quando qualcuno decide — con tutto il criterio del mondo — di chiudere finalmente quell’account che non si usava da mesi.
E quando arriva, arriva senza indizi. Non è un errore di codice che un log ti spiega: è un processo che ha smesso di accadere e che nessuno rimpiange finché un cliente non chiede della sua fattura.
Cosa succede alle automazioni quando un dipendente se ne va: niente, fino a quando non scade una credenziale
Vale la pena capire il meccanismo, perché qui l’intuito sbaglia. Quando una persona se ne va, la sua automazione non si ferma. I flussi non sono legati al contratto di lavoro: sono legati a credenziali, e le credenziali sopravvivono alla persona per come sono fatte. Un token di API è valido fino alla sua data di scadenza. Un’autorizzazione OAuth concessa a uno strumento resta in piedi finché esiste l’account che l’ha concessa. Una chiave incollata nel pannello di un connettore non sa se chi l’ha incollata è ancora in azienda.
Così il giorno dell’uscita non succede niente di visibile, e questo genera la falsa sensazione che non ci fosse dipendenza. C’è, e si materializza in uno di questi quattro momenti, sempre con settimane o mesi di ritardo:
- Scade il token. Quasi ogni credenziale di integrazione ha vita limitata. Il giorno in cui scade, il flusso comincia a restituire un errore di autenticazione che nessuno legge, perché le notifiche andavano alla mail di chi se n’è andato.
- L’account viene cancellato per davvero. All’inizio l’utente si sospende, per non rompere niente. Mesi dopo, in una pulizia di licenze — che è una conversazione sui costi, non sul rischio —, viene eliminato. E con lui se ne vanno tutte le autorizzazioni che aveva concesso.
- Cambia qualcosa dall’altra parte. Il fornitore aggiorna la sua API, la banca cambia il formato dell’estratto conto, il CRM rinomina un campo. Il flusso ha bisogno di un aggiustamento da dieci minuti che può fare solo chi capisce perché era montato così.
- Compare un’eccezione nuova. Il caso raro che la logica non copriva. La persona che se n’è andata sapeva cosa farne perché l’aveva deciso lei; chi resta non sa nemmeno che quella decisione esistesse.
Non è shadow AI e non si risolve contando agenti
Questo si confonde con due problemi vicini, e la confusione costa cara perché le tre cose si risolvono con leve diverse.
Lo shadow AI è uso non autorizzato: gente che usa strumenti che l’azienda non ha approvato. È un problema di domanda non soddisfatta e si risolve offrendo una via ufficiale. L’inventario è un problema di conteggio: non sapere quante automazioni hai né cosa toccano. Si risolve guardando.
L’uscita è un’altra cosa: è ciclo di vita. Un’automazione può essere perfettamente autorizzata, perfettamente inventariata e perfettamente descritta in un foglio di calcolo, e restare fragile, perché quello che le manca non è un permesso né un registro: le manca un proprietario vivo e un’identità propria. Un inventario ti dice che il flusso esiste. Non ti dice che gira con le credenziali di Giulia, e che Giulia se n’è andata a marzo.
La differenza pratica: lo shadow AI e l’inventario si risolvono con una fotografia. Il ciclo di vita si risolve solo con un processo, perché la gente continuerà a entrare e uscire dalla tua azienda per tutto il tempo in cui l’azienda esisterà.
Il dato: il mercato non sa ancora revocare le credenziali a un agente
C’è un numero che conviene guardare con attenzione, non perché parli di PMI italiane — non lo fa — ma per chi misura. Nel suo report 2026 Identity Security Landscape, basato su un’indagine su 2.930 responsabili della sicurezza di tutto il mondo, Palo Alto Networks pubblica due cifre che lette insieme descrivono questo buco meglio di qualunque aneddoto: il 99 % delle organizzazioni ha già adottato agenti di IA, e solo il 37 % può revocare le credenziali di un agente. Solo il 30 % ha un audit log immutabile di quello che quegli agenti fanno. Fonte: How to Assess Maturity When Machine Identities Outnumber Humans 109:1, Palo Alto Networks, maggio 2026.
L’ambito conta e va detto chiaro: è un’indagine mondiale su grandi imprese, con team di sicurezza, budget e un CISO che risponde al questionario. Non è un campione di PMI italiane, né spagnole, né portoghesi. Ma proprio per questo è utile come pavimento: se due organizzazioni su tre con un team di sicurezza non riescono a tagliare l’accesso a un agente, la domanda su cosa succeda in un’azienda di quaranta persone, dove il flusso l’ha montato il responsabile operativo un giovedì pomeriggio, si risponde da sola.
Lo stesso report indica dov’è esattamente il vuoto: la maggior parte delle organizzazioni sa spiegare a cosa serve ogni agente, e molte meno sanno definire a cosa accede, come si limita quell’accesso, quando si revocano i suoi permessi e quali altri sistemi ereditano quell’accesso. Non è un problema di non conoscere lo scopo. È un problema di fine vita.
| Cosa la checklist di uscita copre | Cosa non copre | Cosa si rompe |
|---|---|---|
| Mail, portatile, accesso al CRM, busta paga | Le credenziali con cui girano le sue automazioni | Il flusso resta vivo con l’identità di qualcuno che non c’è più |
| Passaggio di clienti e attività aperte | Il criterio con cui decideva i casi rari | Alla prima eccezione nuova nessuno sa come risolverla |
| Togliere la persona dalle liste di distribuzione | Reindirizzare gli alert di errore dei suoi flussi | Il guasto accade e l’avviso va in una casella chiusa |
| Firmare l’uscita nel gestionale documentale | Annotare chi eredita quel processo | Il processo resta senza proprietario senza che nessuno lo decida |
Le tre domande che mancano nella tua checklist di uscita
Non serve un progetto per chiudere questa cosa. Servono tre domande nel colloquio di uscita, fatte prima dell’ultimo giorno, quando la persona c’è ancora e ha ancora voglia di aiutare:
- Con quale identità gira ognuna delle cose che hai montato? Non « cosa hai montato »: con quale account. La risposta utile è un elenco di flussi e, accanto a ognuno, l’account o la chiave che usa. Se qualche riga dice « il mio account », hai già individuato il lavoro di lunedì. È questa la domanda che decide se un’uscita è una formalità o un incidente rinviato.
- Cosa hai deciso tu che non è scritto da nessuna parte? Ogni automazione utile ha uno strato di criterio che non sta nella configurazione: cosa si considera una fattura duplicata, quando una mail merita una risposta umana, quale fornitore è l’eccezione di sempre. Mezz’ora a registrare quella persona mentre racconta i casi rari vale più di qualunque manuale scritto di corsa.
- Chi deve avvisare questa cosa quando si rompe? Non « chi avvisavi tu ». Chi deve essere avvisato da ora in poi. Un flusso i cui alert vanno in una casella che sta per essere chiusa è un flusso che sta già fallendo in silenzio, solo che ancora non lo sai.
Le tre stanno in una riunione da quaranta minuti e risolvono la maggior parte del rischio. La versione completa della prima — quale identità, con quale perimetro e cosa può toccare — è sviluppata nella guida sui permessi di un agente IA, che è dove si decide se questo colloquio di uscita sarà scomodo o banale.
Cosa fare se sei già rimasto senza la persona
Il caso più comune non è quello preventivo: è quello reattivo, con la persona fuori da tre mesi e nessuno sicuro di cosa stia ancora girando. Ordine di lavoro, dal più economico al più caro:
- Non cancellare l’account, non ancora. È tentante chiuderlo per igiene, ed è il modo più rapido di trasformare un rischio latente in un fermo di servizio. Sospendi l’accesso interattivo — che nessuno possa entrarci — e lascia vive le credenziali di integrazione fino a quando non hai finito il passo 3.
- Guarda cosa continua a succedere con quell’identità. I log di accesso dei tuoi strumenti principali (mail, CRM, ERP, la piattaforma di automazione) ti dicono quale attività risulta ancora a nome di quell’account. Quello è il tuo inventario vero, molto meglio di quello che metteresti insieme a memoria.
- Riemetti ogni credenziale a nome dell’azienda. Crea un service account con permessi circoscritti per flusso e riautentica le connessioni. È lavoro noioso, di un pomeriggio, ed è l’unico che elimina il problema invece di rinviarlo.
- Reindirizza gli alert a una casella di team. Non a un’altra persona: a un indirizzo che sopravviva alla prossima uscita. È questo che trasforma il prossimo guasto in qualcosa che qualcuno legge.
- Scrivi la logica che recuperi mentre la recuperi. Quello che ti raccontano i log e le persone che restano, scrivilo sul momento. Quel documento non si scriverà dopo; non si scrive mai dopo.
Se durante il passo 2 scopri che un flusso sta fallendo da settimane senza che nessuno lo sapesse, il problema non è più l’uscita: è che nessuno stava guardando. Quella è un’altra conversazione, e sta nella guida su chi risponde quando si rompe un’automazione.
L’errore di progettazione sta prima, il giorno in cui è stato montato
Tutto quello che precede è gestione del danno. La causa sta in un momento molto anteriore e molto economico da sistemare: il giorno in cui qualcuno ha montato il flusso con il proprio account, perché era quello che aveva a portata di mano e funzionava. Nessuno ha fatto niente di male. Semplicemente nessuno ha deciso il contrario, perché quella decisione non stava in nessun elenco.
Il modo di non farlo succedere di nuovo sono tre regole che non costano soldi, solo accordo: nessuna automazione gira con l’account di una persona — service account con permessi circoscritti, sempre —; ogni flusso vivo ha un nome accanto, quello di chi ne risponde, e quel nome si rivede quando qualcuno cambia ruolo; e gli alert vanno in una casella di team, mai a un individuo. Le tre insieme trasformano un’uscita in una pratica amministrativa, che è quello che dovrebbe essere. Il quadro completo di quella decisione sta nella guida su governance e controllo dell’automazione con IA.
E c’è un caso in cui nessuna regola interna arriva: quando la persona che ha montato il sistema non è mai stata di casa. Se le tue automazioni le ha tirate su un consulente o un’agenzia, il giorno in cui finisce il contratto si ripete esattamente questa stessa scena, con la differenza che non c’è colloquio di uscita né caffè di addio. Per questo la manutenzione di quello che gira è un servizio e non un favore: qualcuno deve mantenere gli agenti IA quando chi li ha montati non c’è più, e a quella domanda si risponde prima di firmare, non dopo.
Un’automazione che capisce una sola persona non è un asset. È un debito con data di scadenza sconosciuta, e la data la mette il mercato del lavoro, non tu.