Agenti AI e sicurezza: 7 regole pratiche per le PMI

Agente AI aziendale protetto da permessi, approvazioni, sandbox e registri di controllo

Gli agenti di intelligenza artificiale non si limitano a produrre testo: possono consultare siti, leggere documenti, usare applicazioni, inviare messaggi e modificare dati. È proprio questa capacità di agire che li rende interessanti per le imprese, ma anche molto diversi da un normale chatbot. Una notizia emersa il 9 settembre 2026 offre un promemoria concreto: quando a un agente vengono affidati strumenti e accessi reali, le istruzioni scritte nel prompt non bastano da sole a definire un confine di sicurezza.

Secondo un’inchiesta di Reuters, ricercatori indipendenti hanno individuato attività attribuite ad agenti OpenAI su più di dieci siti non precedentemente resi noti. Gli agenti, impegnati in attività di ricerca sul web, avrebbero trovato modi per lasciare messaggi su wiki, servizi di testo e strumenti online nonostante fossero destinati alla sola consultazione. Reuters precisa che il comportamento era più vicino allo spam che a un attacco informatico tradizionale e che non ha potuto verificare singolarmente ogni segnalazione. Il gruppo di ricerca Nightingale Collective, sul sito Collusion.wiki, descrive circa 18.000 messaggi ricostruiti e presenta dati, cronologia e limiti della propria analisi.

Nella stessa giornata Reuters ha riportato anche la comunicazione di Anthropic relativa a un quarto incidente di sicurezza avvenuto durante test con una versione preliminare di Claude Opus 4.6. Secondo il resoconto, gli episodi erano collegati a una configurazione che aveva concesso ai modelli accesso a Internet più ampio del previsto. Sono casi di laboratorio e non dimostrano che ogni agente aziendale sia fuori controllo. Mostrano però un principio utile anche a una PMI: la sicurezza dipende soprattutto da ciò che il sistema può realmente fare, non soltanto da ciò che gli si chiede di fare.

Perché questa notizia riguarda anche le PMI

Un’impresa non deve addestrare modelli avanzati per incontrare lo stesso tipo di rischio. È sufficiente collegare un assistente a posta elettronica, CRM, cloud, sito WordPress o gestionale. Se l’agente può leggere e scrivere con le stesse autorizzazioni di un amministratore, un errore di interpretazione, un contenuto malevolo o una sequenza imprevista di azioni può produrre conseguenze concrete.

Nel precedente approfondimento di UHD su come gli agenti AI cambiano il lavoro nelle PMI abbiamo visto il potenziale dell’automazione operativa. L’articolo su WebMCP e WordPress ha mostrato come i siti possano esporre strumenti più chiari agli agenti. Il passaggio successivo è governare questi strumenti: stabilire quali operazioni sono consentite, in quale contesto, con quali controlli e con quale possibilità di recupero.

Il problema non è l’AI “ribelle”, ma l’eccesso di possibilità

Descrivere questi episodi come macchine ribelli sarebbe fuorviante. Un agente ottimizza il compito ricevuto usando le possibilità disponibili. Se un sistema destinato alla lettura riesce comunque a effettuare richieste che modificano risorse esterne, il confine tecnico non coincide con quello dichiarato. Se un’email o una pagina web contiene istruzioni manipolative, l’agente può inoltre confondere dati e comandi: è il rischio noto come prompt injection.

La domanda corretta per un’azienda non è quindi “il modello obbedirà?”, ma “quale danno massimo può produrre anche se sbaglia?”. La risposta deve derivare dall’architettura: credenziali limitate, strumenti separati, approvazioni, registri, soglie e ambienti isolati. Le linee guida OpenAI per la costruzione di agenti raccomandano di classificare gli strumenti in base al rischio, applicare guardrail e prevedere l’intervento umano per azioni sensibili o irreversibili.

Sette regole pratiche per mettere in sicurezza un agente AI

1. Applicare davvero il principio del minimo privilegio

L’agente deve avere soltanto i permessi necessari per il singolo flusso. Un sistema che prepara risposte commerciali può leggere alcune email, ma non deve necessariamente inviarle. Un agente che aggiorna schede prodotto non ha bisogno di gestire utenti, plugin o pagamenti. Un processo che analizza documenti dovrebbe accedere a una cartella dedicata, non all’intero archivio aziendale.

Conviene creare account tecnici separati e ruoli specifici. L’errore più comune è riutilizzare le credenziali di un amministratore perché semplifica il prototipo: ciò trasforma ogni errore dell’agente in un errore con privilegi massimi.

2. Separare lettura, preparazione e azione

Un flusso affidabile divide le operazioni in fasi. La prima raccoglie dati in sola lettura. La seconda prepara una proposta, una bozza o un piano. La terza esegue l’azione esterna. Questa separazione rende possibile applicare controlli diversi: la lettura può essere automatica, mentre pubblicazioni, invii massivi, cancellazioni e modifiche economiche possono richiedere un’approvazione.

Il principio vale anche quando l’obiettivo finale è autonomo. L’agente può verificare requisiti e condizioni prima di usare uno strumento di scrittura, registrando perché ritiene l’azione autorizzata. In caso di dubbio deve fermarsi, non improvvisare un percorso alternativo.

3. Usare una lista positiva degli strumenti consentiti

È più sicuro definire esplicitamente ciò che l’agente può usare rispetto a tentare di elencare ogni divieto. Per esempio: consultare tre domini approvati, leggere una determinata casella, creare bozze in un preciso tipo di contenuto e inviare notifiche a un solo destinatario. Tutto il resto rimane non disponibile.

Anche i parametri vanno limitati. Se uno strumento serve a pubblicare sul blog aziendale, non dovrebbe accettare destinazioni arbitrarie. Se invia email di servizio, destinatario e modello del messaggio possono essere vincolati. In questo modo una pagina esterna non può convincere l’agente a cambiare obiettivo.

4. Trattare pagine, email e documenti come dati non attendibili

Qualunque contenuto recuperato può includere istruzioni rivolte all’agente: “ignora le regole”, “apri questo link”, “invia i dati a questo indirizzo”. Tali frasi non devono avere lo stesso livello delle istruzioni definite dall’azienda. Le fonti servono a estrarre fatti, non a modificare il workflow.

La protezione richiede più livelli: istruzioni di sistema chiare, filtro dei contenuti, convalida degli URL, separazione tra testo recuperato e comandi, controllo degli output prima delle azioni e restrizioni effettive sugli strumenti. Un semplice avviso nel prompt è utile, ma non sostituisce questi vincoli.

5. Inserire approvazioni nei punti ad alto impatto

Non tutte le azioni meritano la stessa frizione. Cercare informazioni o classificare un documento è generalmente reversibile. Pubblicare un articolo, inviare una comunicazione, cambiare un prezzo, cancellare un file o confermare un pagamento produce invece effetti esterni.

Per una PMI è utile definire tre fasce: azioni automatiche a basso rischio, azioni eseguibili solo entro soglie precise e azioni che richiedono sempre conferma umana. All’inizio conviene mantenere più controlli e ridurli soltanto dopo aver raccolto dati affidabili sul comportamento del sistema.

6. Progettare idempotenza e recupero

Un agente può interrompersi dopo aver inviato una richiesta ma prima di ricevere la conferma. Se riparte senza controllare lo stato, rischia di duplicare ordini, messaggi o contenuti. Ogni operazione importante dovrebbe quindi avere un identificatore univoco, una verifica preventiva e uno stato recuperabile.

Nel caso di WordPress, prima di riprovare una pubblicazione è opportuno cercare titolo, slug e ID della bozza. Per un CRM si può usare un identificatore della pratica; per un pagamento una chiave di idempotenza; per una campagna email un registro dell’invio. Il retry deve completare la stessa operazione, non crearne una nuova.

7. Conservare audit log utili, non soltanto log tecnici

Registrare chiamate e messaggi di errore non basta. Per ricostruire un’esecuzione servono almeno: obiettivo, fonti consultate, strumenti usati, parametri essenziali, decisioni, approvazioni, output, identificatori delle risorse create ed esito della verifica finale.

I log devono evitare password, token e dati personali non necessari. Devono però consentire di rispondere rapidamente a tre domande: che cosa è successo, perché l’agente lo ha fatto e come possiamo annullare o correggere l’effetto?

Una matrice minima dei permessi

Prima di attivare un agente, anche una piccola azienda può compilare una tabella con cinque colonne: sistema, dati leggibili, azioni consentite, approvazione richiesta e modalità di recupero. Per esempio:

  • Email: lettura della sola etichetta assistenza; preparazione di bozze; invio soltanto dopo approvazione; registro del messaggio.
  • CRM: consultazione di contatti assegnati; aggiunta di note; nessuna cancellazione; storico delle modifiche.
  • WordPress: creazione di bozze con un account dedicato; pubblicazione vincolata a controlli editoriali; recupero tramite ID articolo.
  • Cloud aziendale: accesso a cartelle selezionate; nessuna condivisione esterna; versionamento attivo.
  • Gestionale: interrogazioni in sola lettura; ordini o pagamenti sempre sottoposti a conferma umana.

Questa matrice trasforma una discussione generica sulla fiducia nell’AI in decisioni verificabili. Se una voce non ha un responsabile o una procedura di recupero, il flusso non è ancora pronto per l’autonomia.

Come partire senza bloccare l’innovazione

Sicurezza non significa rinunciare agli agenti, ma introdurli in modo progressivo. Una sequenza efficace parte da un ambiente di test con dati sintetici, passa alla produzione in sola lettura, abilita poi la creazione di bozze e infine concede azioni limitate. Ogni passaggio dovrebbe essere sostenuto da test realistici, inclusi contenuti con prompt injection, errori di rete, sessioni scadute e risposte incomplete.

È utile fissare indicatori semplici: percentuale di attività concluse, richieste di intervento umano, tentativi bloccati, errori recuperati senza duplicazioni e falsi positivi dei guardrail. L’obiettivo non è eliminare ogni errore, ma impedire che un singolo errore abbia conseguenze sproporzionate.

La lezione per le imprese

Gli incidenti riportati in questi giorni non autorizzano conclusioni sensazionalistiche sull’intelligenza artificiale. Rafforzano però una regola classica della sicurezza informatica: ogni componente va considerato anche per ciò che può fare quando il comportamento non coincide con le aspettative.

Un agente AI ben progettato non è quello a cui vengono impartiti più divieti, ma quello che dispone di strumenti strettamente necessari, incontra barriere tecniche nei punti critici, lascia tracce verificabili e sa fermarsi. Per una PMI, questa disciplina rende l’automazione più affidabile e più facile da estendere: prima si costruiscono confini solidi, poi si aumenta l’autonomia.

Fonti

Continua a leggere