Un agente che apre ticket, aggiorna il gestionale e scrive ai clienti lo fa con l'account di qualcuno. Quasi nessuno, in riunione, chiede di chi.
E appena gli agenti diventano più di uno, le domande diventano tre: chi esegue, con quale identità, su direttiva di chi.
Nella maggior parte dei progetti che vediamo partire, la risposta è arrivata prima della domanda. L'agente usa le credenziali di qualcuno: il consulente che ha fatto l'integrazione, l'utente di servizio che c'era già, o l'account della persona che quel processo lo faceva a mano.
Funziona subito. È esattamente il problema.
Perché succede
Succede perché è l'unica strada che non richiede di aprire un ticket a qualcun altro.
Creare un'utenza nuova nel gestionale significa parlare con chi lo amministra, decidere che permessi darle, capire se il contratto di licenza la conta come utente aggiuntivo. Sono tre conversazioni e un costo. Riusare un account esistente significa incollare una password in un file di configurazione e vedere il pilota funzionare oggi pomeriggio.
In un progetto che deve dimostrare qualcosa entro il mese, quella scelta non sembra nemmeno una scelta. Sembra buon senso.
E in effetti per due settimane non succede niente.
Cosa si rompe, e quando
Il conto arriva dopo, e arriva in quattro momenti diversi.
Il registro smette di rispondere. Diciamo che l'agente scrive con l'utenza di Marco, il capo ufficio che quel processo lo faceva a mano. Da quel momento ogni riga di log dice «Marco». Se fra sei mesi qualcuno chiede perché quell'ordine è stato modificato, la risposta che il sistema può dare è sbagliata: dice il nome di una persona che non c'era. Marco non c'entra. Il registro ha smesso di essere una fonte di verità, e nessuno se ne accorge finché non serve.
I permessi non si possono stringere. Un agente che aggiorna lo stato degli ordini ha bisogno di scrivere su un campo. Marco, da capo ufficio, ha accesso a molto di più: listini, marginalità, anagrafiche. L'agente eredita tutto. Nessuno gliel'ha dato apposta, e proprio per questo nessuno lo toglierà: per stringere quei permessi bisognerebbe toglierli anche a Marco.
Il turnover diventa un guasto. Marco cambia ruolo, o se ne va. L'IT disattiva l'utenza, che è la cosa giusta da fare. L'automazione si ferma, e il messaggio d'errore parlerà di credenziali scadute, non di un progetto costruito su un'identità che non doveva essere lì. Le due ore che servono per capirlo sono il costo minimo dell'incidente: il costo vero è la settimana in cui il processo è tornato manuale senza che nessuno l'avesse deciso.
La revoca non è selettiva. Se domani l'agente comincia a fare qualcosa di sbagliato — un prompt cambiato, un aggiornamento del modello, un caso che nessuno aveva previsto — la sola leva che hai è disattivare l'account. Che è anche l'account di una persona che sta lavorando.
Il caso che conosciamo meglio
Il problema l'abbiamo visto per primo nel nostro lavoro, non nel gestionale di un cliente.
In un team di cinque sviluppatori, oggi, ognuno lavora in due modi nello stesso giorno: scrive codice a mano e lo fa scrivere a un agente. Non sono due squadre, sono cinque persone che passano dall'una all'altra modalità nel giro di mezz'ora, sullo stesso codice.
Da noi l'agente pesa circa il 75% del lavoro di ogni sviluppatore. Prima di usarlo come argomento va detto cosa significa e cosa no: è una misura interna su cinque persone, non un confronto con altre aziende, e dice quanta parte del lavoro passa dall'agente — non che la squadra vada quattro volte più veloce.
Quello che dice davvero è il motivo per cui questo articolo esiste: tre quarti del lavoro passa da un agente, e se il registro non lo distingue, la firma resta quella di una persona.
Il momento in cui questo diventa un problema di identità è banale: bisogna sapere chi ha fatto cosa. E la domanda si scompone in due.
Chi ha eseguito. Il codice l'ha scritto una persona o un agente? La risposta cambia il tipo di revisione che serve: un blocco prodotto da un agente va letto sapendo da dove viene.
Su direttiva di chi. Questa è la domanda che nei sistemi aziendali non si pone quasi mai, e che con gli agenti che scrivono codice diventa subito concreta. L'agente ha eseguito, ma l'istruzione l'ha data una persona. Se la modifica è firmata dall'agente, hai perso chi ha deciso. Se è firmata dallo sviluppatore, hai perso che l'ha fatta un agente. Servono entrambe le informazioni, ed è per questo che l'identità dell'agente non può essere l'identità di chi lo comanda: sono due ruoli diversi nella stessa riga di registro.
È la stessa struttura del caso del gestionale, con una differenza: qui il problema si vede subito, perché il registro — la cronologia delle modifiche al codice — qualcuno lo legge tutti i giorni. Nel gestionale nessuno lo legge finché non serve, e quando serve è tardi.
Il rischio ha già un nome
Quello che abbiamo descritto finora compare in una classifica di rischi.
OWASP — la fondazione che pubblica la Top 10 sulle vulnerabilità web — mantiene dal dicembre 2024 una Top 10 dei rischi delle identità non umane. «Identità non umana» è il nome generico di ogni utenza che non appartiene a una persona: account di servizio, chiavi API, token. Un agente è una di queste.
La decima voce, NHI10, si chiama Human Use of NHI e descrive il caso opposto al nostro: la persona che usa l'utenza dell'automazione. Ma fra le conseguenze che elenca ci sono proprio le nostre: la mancanza di tracciabilità e di responsabilità, e un'attività umana e automatica che diventano indistinguibili. Delle altre voci, tre ci riguardano da vicino. NHI5 (permessi eccessivi) è il secondo guasto dell'elenco qui sopra. NHI9 (la stessa identità riusata fra più applicazioni) è il motivo della prima regola più sotto. NHI1 (Improper Offboarding, identità lasciate attive quando non servono più) è il rovescio del terzo.
Su questa fonte va detta una cosa. Il progetto è un incubator OWASP, non uno standard maturo. Il primo dei responsabili, Tal Skverer, lavora per Astrix Security, che vende prodotti proprio su questo problema ed è anche l'unico sponsor dichiarato del progetto. Non lo squalifica — è comunque un progetto OWASP formale, con una metodologia dichiarata — ma la classifica di rischi la scrive anche chi vende la soluzione, e conviene saperlo mentre la si legge.
Vale ancora di più per i numeri sulla crescita delle identità non umane. Il più citato, 109 identità macchina per ogni identità umana, viene dal 2026 Identity Security Landscape di Palo Alto Networks (maggio 2026): un sondaggio fra oltre 2.900 responsabili della sicurezza informatica, condotto da un'azienda che vende proprio sicurezza informatica. Una misura indipendente della stessa cosa non l'abbiamo trovata. Prendilo per quello che è: un ordine di grandezza raccontato da una parte interessata. Il numero che conta, per te, è un altro, e più avanti c'è come trovarlo.
Quello che dice la norma, e quello che non dice
L'AI Act chiede i log, ma non ancora. L'articolo 26(6) del Regolamento (UE) 2024/1689 riguarda chi utilizza un sistema ad alto rischio, quindi l'azienda: deve conservare i log generati automaticamente dal sistema, per un periodo adeguato allo scopo e comunque di almeno sei mesi, «nella misura in cui tali log sono sotto il loro controllo». Vale solo per i sistemi classificati ad alto rischio, che non sono la maggior parte delle automazioni aziendali.
E quell'obbligo non è ancora applicabile. Il regolamento Digital Omnibus del luglio 2026 ha rinviato gli obblighi sui sistemi ad alto rischio al 2 dicembre 2027 e, per i sistemi di IA inseriti in prodotti già regolati (allegato I), all'agosto 2028. Chi ti dice che oggi sei fuori norma sui log dell'AI Act ti sta vendendo qualcosa. Ma se da dicembre 2027 un tuo sistema rientra fra quelli ad alto rischio, i log che produce andranno conservati per almeno sei mesi. Sono i log del sistema di IA, non il registro del gestionale: ma se l'agente scrive come Marco, i due racconteranno storie diverse.
Il GDPR non vieta gli account condivisi. Nessun articolo lo dice. Chiede però misure tecniche e organizzative adeguate (articolo 32), ed è lì che un'autorità contesterebbe un account condiviso. Il punto più solido ha una base testuale precisa: l'articolo 5(2) e l'articolo 24(1) chiedono al titolare di essere in grado di dimostrare la conformità. Un registro che attribuisce a Marco tremila operazioni che Marco non ha fatto non dimostra niente. Non è la violazione di un divieto: è l'impossibilità di soddisfare un onere.
E l'agente non sposta la responsabilità altrove. Per il GDPR è uno strumento, non una persona autorizzata al trattamento. Quello che fa, per il regolamento, l'ha fatto il titolare, o il fornitore che lo gestisce per suo conto come responsabile del trattamento. In entrambi i casi bisogna poterlo dimostrare, e l'unica cosa che lo permette è il registro.
La verifica che puoi fare oggi
Non serve un'analisi formale. Apri la lista utenti del gestionale, o del CRM, o di qualunque sistema in cui un'automazione scrive, e cerca due cose.
La prima: un'utenza il cui nome non corrisponde a una persona. integrazione, api, bot, automazione, sync. Se c'è, è già qualcosa: qualcuno ha pensato al problema. Guarda che permessi ha e chi conosce la sua password.
La seconda, più scomoda: un'utenza intestata a una persona vera che ha fatto migliaia di operazioni negli orari in cui quella persona non lavora. Quello è un agente che si è messo il cappotto di qualcun altro.
Se non trovi né l'una né l'altra e in azienda c'è un'automazione che scrive da qualche parte, non vuol dire che il problema non c'è. Vuol dire che non sai ancora dove sia.
Come si fa, senza fermare tutto
L'identità dell'agente è una riga in più nella lista di cose da preparare, se la si mette prima e non dopo.
Un'utenza per agente, non una per progetto. Se lo stesso account serve tre automazioni diverse, torni al punto di partenza: il registro non distingue quale delle tre ha scritto.
I permessi si scrivono partendo da zero. Non «gli stessi di Marco meno qualcosa», ma l'elenco delle operazioni che l'agente deve poter fare. Se l'elenco è lungo da scrivere, è un segnale utile: significa che nessuno aveva descritto per intero cosa fa quel processo — ed è la stessa descrizione che serve quando si sceglie quale processo automatizzare.
L'istruzione si registra insieme all'azione. Chi ha eseguito e chi ha dato la direttiva sono due campi, non uno. Un registro che ne tiene uno solo risponde bene alla domanda sbagliata.
Un proprietario umano, con nome e cognome. La persona che risponde alla domanda «perché questo agente ha fatto questo», e che riceve l'avviso quando l'agente fallisce.
Le credenziali con una scadenza. Una scadenza costringe qualcuno a guardare quell'agente almeno una volta l'anno e chiedersi se serve ancora.
Prima di collegare il prossimo agente
L'identità dell'agente sembra un dettaglio infrastrutturale, di quelli che si sistemano dopo. Non lo è. Da noi tre quarti del lavoro passa dagli agenti. Nei gestionali che vediamo, quasi nessun registro sa distinguere un agente da una persona.
Rimediare dopo costa quanto costava all'inizio: le stesse tre conversazioni. Quello che non si recupera sono i mesi di registro già scritti: quello che è successo con l'account di Marco resta, per sempre, qualcosa che ha fatto Marco.
Non serve un progetto e non serve fermare niente. Servono tre domande prima di collegare il prossimo agente, invece che sei mesi dopo: chi esegue, con quale identità, su direttiva di chi. Se una delle tre non ha una risposta scritta, non è ancora il momento di dargli i permessi di scrittura.
Nel tuo gestionale, quante righe di registro portano il nome di una persona, ma le ha scritte un'automazione?