Agenti AI in azienda: il problema non è il modello, sono i permessi

La prossima ondata di AI nelle PMI non sarà il chatbot che risponde a una domanda. Sarà l’agente che legge una mail, apre il CRM, prepara un’offerta, aggiorna un ticket, scrive al cliente e magari prenota un intervento. È qui che l’AI smette di essere un giocattolo utile e diventa un pezzo del sistema operativo aziendale.

Il punto non è se il modello sia abbastanza intelligente. Il punto è cosa gli viene permesso di fare. Un agente AI con accesso alla posta, ai documenti commerciali e al gestionale non è “un assistente”: è un’identità digitale con privilegi, memoria, strumenti e possibilità di errore. Trattarlo come una licenza software qualsiasi è il modo più rapido per trasformare una buona idea in un incidente operativo.

Per una PMI italiana la risposta non è il blocco ideologico. Gli agenti AI possono ridurre lavoro ripetitivo, accelerare i preventivi, migliorare l’assistenza e mettere ordine in processi che oggi vivono tra Excel, email e telefonate. Ma vanno introdotti come si introduce un nuovo utente con poteri speciali: pochi permessi, log chiari, approvazioni sui passaggi sensibili e la possibilità di spegnere tutto senza fermare l’azienda.

1. L’agente AI non è un chatbot: è un account operativo

Il chatbot tradizionale risponde. L’agente AI agisce. La differenza sembra sottile nelle demo, ma in azienda cambia tutto. Quando un sistema può inviare email, creare record, interrogare basi dati, aprire ticket o chiamare API, entra nella stessa categoria di rischio di un utente umano con accesso agli strumenti aziendali.

Molte PMI hanno già visto questa dinamica con le automazioni no-code: prima una scorciatoia innocua, poi un processo critico che nessuno ricorda più come sia stato costruito. Con gli agenti AI il salto è più delicato, perché la scelta su “cosa fare dopo” non è sempre deterministica. Il flusso non è solo “se succede A, fai B”: spesso è “interpreta il contesto e scegli l’azione più adatta”.

Questo non rende la tecnologia inutilizzabile. Rende sbagliato l’acquisto impulsivo. Un agente collegato al CRM non deve partire con accesso a tutto il database clienti. Un agente che prepara offerte non deve poter inviare sconti senza approvazione. Un agente che legge la posta non deve indicizzare anche comunicazioni sindacali, dati sanitari, contenziosi o messaggi personali finiti per errore nella casella aziendale.

Qui il GDPR non è burocrazia ornamentale. Il principio di minimizzazione dei dati impone di trattare solo i dati adeguati, pertinenti e limitati a quanto necessario. E il principio di protezione fin dalla progettazione e per impostazione predefinita chiede di pensarci prima, non dopo. Un agente AI che nasce con accesso indistinto a “tutta la conoscenza aziendale” parte già male, prima ancora di discutere di modello, cloud o prompt.

La regola pratica è semplice: l’agente non deve vedere ciò che un dipendente nella stessa funzione non vedrebbe, e non deve poter fare ciò che quel dipendente non potrebbe fare senza un controllo.

2. Il vero rischio è l’accoppiata tra AI, identità e integrazioni

Le demo degli agenti AI mostrano i risultati. Raramente mostrano i permessi. Eppure il rischio sta lì: OAuth concesso troppo in fretta, token API condivisi, account tecnici senza scadenza, plugin installati senza una mappa dei dati attraversati. È lo stesso film già visto con il SaaS, ma con un attore più autonomo.

Una PMI che usa Microsoft 365, Google Workspace, un gestionale, un CRM e qualche servizio verticale ha già un ecosistema complesso. Inserire un agente AI significa aggiungere un livello capace di leggere e combinare informazioni da più fonti. Il problema non è solo la fuga di dati verso il fornitore AI: è anche la ricomposizione interna di dati che prima erano separati per funzione, abitudine o prudenza.

Un esempio concreto: un agente pensato per aiutare il commerciale a preparare offerte accede alla posta condivisa, allo storico clienti e alle marginalità di prodotto. Se non viene limitato, può usare dati di trattative riservate, condizioni speciali o note interne per generare proposte fuori policy. Magari non “ruba” nulla. Semplicemente automatizza una violazione delle regole aziendali.

Il GDPR richiede misure tecniche e organizzative adeguate al rischio: riservatezza, integrità, disponibilità e resilienza dei sistemi. Questo vale anche quando il rischio nasce da una configurazione comoda ma troppo ampia. Per le aziende che rientrano nella NIS2, o che lavorano come fornitori di soggetti essenziali o importanti, il ragionamento si allarga: gestione del rischio, supply chain, continuità operativa, controllo degli accessi e igiene cyber non sono capitoli separati dall’AI.

La domanda da fare prima di attivare un agente non è “quanto è bravo?”. È: con quale identità lavora, quali sistemi può toccare, quali dati può leggere, quali azioni può compiere, dove restano i log e chi può revocare i permessi.

3. Tre casi d’uso buoni, se progettati con il freno a mano giusto

Gli agenti AI non sono tutti uguali. Alcuni casi d’uso sono ragionevoli anche per una PMI senza un reparto IT strutturato, purché costruiti con confini chiari. L’errore è partire dal processo più delicato perché “fa più effetto”. Meglio iniziare dove il valore è alto ma il rischio è controllabile.

Il primo caso è l’assistenza interna. Un agente che risponde ai dipendenti su procedure, manuali, policy, cataloghi prodotto e documentazione tecnica fa risparmiare tempo senza toccare dati clienti o sistemi transazionali. Va però alimentato con fonti curate, non con una cartella condivisa dove negli anni è finito di tutto. La qualità delle fonti è una misura di sicurezza, non un vezzo documentale.

Il secondo caso è la preparazione di bozze: preventivi, risposte a richieste frequenti, riepiloghi di ticket, verbali di riunione, schede tecniche. Qui l’agente produce una bozza e l’umano approva. È un modello sano perché separa produttività e responsabilità. L’AI accelera, ma non conclude.

Il terzo caso è il triage operativo: classificare richieste, proporre priorità, suggerire il reparto corretto, evidenziare anomalie. Qui l’agente può essere molto utile, soprattutto dove la conoscenza è concentrata in poche persone. Ma anche in questo caso non deve chiudere ticket critici, cambiare condizioni contrattuali o inviare comunicazioni definitive senza un passaggio di controllo.

Una lista breve di criteri aiuta a scegliere il primo progetto:

• dati non critici o facilmente segmentabili;
• output reversibile o approvato da una persona;
• integrazioni limitate e documentate;
• beneficio misurabile in ore risparmiate o tempi di risposta;
• possibilità di spegnere l’agente senza bloccare il processo.

Se un caso d’uso non supera questi criteri, non è da scartare per sempre. È da rimandare. Prima si costruisce la disciplina, poi si aumenta l’autonomia.

4. Governance leggera: cinque decisioni prima del primo agente

Governance non significa creare un comitato infinito. Per una PMI significa prendere poche decisioni scritte, comprensibili e applicabili. L’alternativa è lasciare che ogni reparto attivi strumenti diversi, con account personali, contratti accettati al volo e dati caricati dove capita. Quella non è agilità: è debito operativo.

La prima decisione riguarda il proprietario del processo. Ogni agente deve avere un responsabile aziendale, non solo un referente tecnico. Se l’agente lavora sulle offerte, il proprietario è l’area commerciale. Se lavora sui ticket, è l’assistenza. L’IT abilita, controlla accessi, log e integrazioni, ma non può essere l’unico a rispondere di decisioni operative prese da un sistema usato da altri.

La seconda decisione riguarda i dati ammessi. Serve una classificazione minima: pubblico, interno, riservato, vietato all’AI. Non occorre un trattato. Occorre sapere se nell’agente possono entrare listini, contratti, dati personali, dati sanitari, segreti industriali, credenziali o informazioni su contenziosi. Il principio è brutale ma utile: se nessuno sa dire che tipo di dati contiene una fonte, quella fonte non si collega.

La terza decisione riguarda i permessi. L’agente deve usare un’identità dedicata, non l’account di un dipendente e non un token amministrativo riciclato. I permessi devono essere minimi e revocabili. Dove possibile, lettura separata dalla scrittura. Dove necessario, scrittura consentita solo su ambienti o record specifici.

La quarta decisione riguarda il punto di approvazione umano. Non tutte le azioni richiedono lo stesso controllo. Riassumere un documento può essere automatico. Inviare un’offerta, cancellare dati, modificare un ordine, applicare uno sconto o comunicare al cliente una decisione contrattuale deve passare da una persona. La produttività non giustifica l’assenza di responsabilità.

La quinta decisione riguarda i log. Senza log, un agente AI diventa una scatola nera aziendale. Bisogna poter ricostruire input rilevanti, fonti consultate, azioni proposte, azioni eseguite, utente che ha approvato e sistemi coinvolti. Non serve registrare tutto in eterno, ma serve una traccia proporzionata al rischio. Quando qualcosa va storto, “lo ha fatto l’AI” non è una spiegazione accettabile.

L’AI Act aggiunge un tassello culturale: prevede obblighi di alfabetizzazione in materia di AI per chi fornisce e per chi utilizza questi sistemi, in base al contesto d’uso. Per una PMI si traduce in una cosa molto pratica: chi usa un agente deve sapere cosa può fare, cosa non deve fare e quando fermarsi. Non basta una circolare. Serve formazione breve, vicina ai casi reali, aggiornata quando cambiano gli strumenti.

5. Contratti e fornitori: la demo non basta, servono risposte scritte

Il mercato degli agenti AI è affollato e rumoroso: grandi piattaforme internazionali, startup verticali, system integrator, estensioni di prodotti già installati e strumenti no-code che promettono automazioni in un pomeriggio. Per una PMI è facile farsi guidare dalla demo più brillante. È comprensibile, ma pericoloso.

Il fornitore va interrogato su aspetti precisi. Dove vengono trattati i dati? I prompt e gli output sono usati per addestrare modelli? Esiste un’opzione per disattivare l’uso dei dati a fini di miglioramento del servizio? Quali subfornitori intervengono? I log sono esportabili? I connettori verso email, CRM e documentale usano permessi granulari? È possibile cancellare dati e configurazioni a fine contratto? Quanto costa uscire?

Se il servizio tratta dati personali per conto dell’azienda, il fornitore agisce come responsabile del trattamento e il GDPR impone un contratto con contenuti precisi. Non basta una pagina web con scritto “GDPR compliant”. Servono istruzioni documentate, misure di sicurezza, gestione dei sub-responsabili, assistenza per le richieste degli interessati e restituzione o cancellazione dei dati al termine del servizio. Sono obblighi noti, ma spesso evaporano proprio nei servizi AI acquistati con carta di credito.

Attenzione anche al lock-in silenzioso. Un agente che apprende procedure aziendali e incorpora prompt, workflow, connettori e basi documentali diventa rapidamente difficile da sostituire. Non perché il modello sia insostituibile, ma perché l’integrazione è diventata conoscenza operativa. La sovranità qui non è una bandiera: è la possibilità concreta di esportare configurazioni, dati, log e basi di conoscenza in formati riutilizzabili altrove.

Un system integrator italiano ben scelto può fare la differenza, soprattutto nelle PMI. Non perché “italiano” sia automaticamente sinonimo di migliore, ma perché la prossimità operativa conta quando bisogna mappare un gestionale locale, parlare con chi segue l’infrastruttura, separare i permessi in Active Directory o Entra ID, capire il ciclo reale di un ordine e intervenire senza aprire ticket in tre fusi orari. La misura non è il patriottismo: è la capacità di prendere in carico il problema dall’inizio alla fine.

6. Architettura minima: sandbox, dati selezionati e kill switch

Una buona introduzione degli agenti AI non richiede per forza una piattaforma enorme. Richiede un’architettura minima sensata. La parola chiave è separazione: separare ambienti, dati, permessi e responsabilità. Ogni scorciatoia presa all’inizio diventa più costosa quando l’agente entra nei processi quotidiani.

La sandbox è il primo elemento. Prima di collegare l’agente a sistemi reali, va provato su dati campione o copie controllate. Non su export completi del CRM lasciati in una cartella temporanea, ma su dataset ridotti e ripuliti. La sandbox serve a capire errori, allucinazioni operative, risposte fuori tono, uso improprio delle fonti e limiti del modello.

Il secondo elemento è una base di conoscenza selezionata. Molti progetti AI falliscono perché partono dall’idea di indicizzare tutto: manuali vecchi, offerte superate, bozze, documenti duplicati, policy contraddittorie. L’agente non risolve il disordine, lo amplifica. Meglio una base più piccola, mantenuta e con un responsabile chiaro. La qualità documentale diventa un vantaggio competitivo.

Il terzo elemento è il controllo degli strumenti. Ogni tool concesso all’agente deve avere uno scopo. Lettura email? Solo caselle o cartelle definite. CRM? Solo i clienti del perimetro interessato. Gestionale? All’inizio consultazione, non modifica. Invio comunicazioni? Bozze, non invio automatico. Quando l’agente dimostra affidabilità, i permessi si possono estendere. Non il contrario.

Il quarto elemento è il kill switch. Deve esistere un modo semplice per disabilitare l’agente, revocare i token, bloccare i connettori e tornare al processo manuale. Se spegnere l’AI significa fermare il commerciale o l’assistenza, l’azienda non ha adottato uno strumento: ha creato una dipendenza non governata. La continuità operativa non riguarda solo server e backup, ma anche le automazioni che diventano invisibili finché non si rompono.

Il quinto elemento è il monitoraggio. Non serve un SOC per ogni agente, ma servono indicatori minimi: numero di azioni eseguite, errori, approvazioni negate, fonti più usate, utenti più attivi, tentativi di accesso a dati non consentiti. Questi segnali aiutano a correggere prima che il problema diventi incidente.

7. Il percorso realistico per una PMI: 30 giorni, non un piano quinquennale

La buona notizia è che una PMI può partire bene senza trasformare l’AI in un progetto faraonico. Serve un perimetro piccolo, un fornitore che accetti vincoli chiari e una disciplina minima. Il contrario dell’approccio “proviamo tutto e poi vediamo”.

Nei primi 30 giorni conviene scegliere un solo caso d’uso, preferibilmente interno o con output approvato da una persona. Si raccolgono le fonti, si eliminano i documenti obsoleti, si definiscono utenti pilota, permessi, log e criteri di successo. Il criterio non deve essere “sembra intelligente”, ma “riduce tempi, errori o passaggi manuali senza aumentare il rischio”.

Poi si misura. Quante ore sono state risparmiate? Quante bozze sono state accettate senza modifiche pesanti? Quanti errori sono stati intercettati? Quali dati l’agente ha chiesto ma non doveva vedere? Quali utenti lo aggirano perché è scomodo? Queste domande valgono più di cento slide sull’innovazione.

Solo dopo si decide se aumentare l’autonomia, integrare un secondo sistema o estendere l’uso a un altro reparto. Questo approccio non frena l’AI: la rende sostenibile. Un agente che nasce piccolo, tracciato e revocabile può crescere. Un agente nato onnivoro, opaco e indispensabile diventa un problema politico interno prima ancora che tecnico.

La tesi è netta: l’AI agentica non si governa scegliendo “il modello migliore”, ma decidendo quali permessi meritano di esistere. Per le PMI italiane è un’occasione concreta. Chi imposta bene identità, dati, contratti e controllo umano potrà usare l’AI senza regalare processi e conoscenza al primo vendor convincente. Chi salta questi passaggi scoprirà che l’automazione più costosa è quella che nessuno sa più spegnere.