Uso e sicurezza dell'IA

La shadow AI è l'uso di strumenti di IA sul lavoro senza che lo sappiano o lo approvino i responsabili di IT, sicurezza o protezione dei dati. Comprende dipendenti che usano account personali di chatbot per attività di lavoro, estensioni del browser con IA integrata, funzioni di IA attivate in software esistenti, sviluppatori che eseguono modelli locali o assistenti di programmazione e agenti di IA collegati ai sistemi aziendali. Di solito nasce da buone intenzioni: lavorare più in fretta. I rischi sono concreti. Dati dell'azienda o dei clienti finiscono presso fornitori con cui non ha alcun contratto, a condizioni che possono consentire loro di conservarli o di usarli per addestrare modelli. Dati personali possono essere trattati senza base giuridica. I risultati entrano in documenti e codice senza revisione. E nessuno sa rispondere a un cliente o a un revisore che chiede quali servizi di IA abbiano toccato i suoi dati. La risposta non è il divieto, ma visibilità, un'alternativa approvata e una politica chiara. Dal piano Pro NetSenX mostra quali host si collegano a quali servizi di IA e quanti dati vi finiscono, non che cosa è stato scritto.

Sì, dal piano Pro. NetSenX segnala il traffico verso servizi di IA esterni e verso modelli linguistici eseguiti in locale, così l'uso di IA non approvato diventa visibile prima di trasformarsi in un problema di protezione dei dati.

Osservi le connessioni in uscita verso i servizi di IA: la destinazione e il nome del server nell'handshake TLS identificano il servizio senza decifrare nulla. NetSenX segnala questo traffico, e quello verso modelli linguistici eseguiti in locale, dal piano Pro.

Di solito più di quanti qualcuno abbia elencato, ed è proprio questa differenza il motivo per scoprirlo. Un elenco realistico ha quattro livelli: i servizi pagati con account aziendali; le funzioni di IA attivate nel software che già usa, come suite d'ufficio, CRM, helpdesk e strumenti grafici; i servizi che il personale usa con account personali nel browser o in app desktop; e i modelli eseguiti in locale su portatili, server di build o workstation con GPU. Parta da ciò che sa, da contratti, estratti delle carte e console di amministrazione, poi aggiunga ciò che mostra la rete. Raggruppi i risultati per funzione aziendale, perché finanza, vendite e sviluppo usano spesso strumenti diversi per dati diversi, e assegni a ogni servizio uno stato: approvato, tollerato per dati non sensibili o da sostituire. L'elenco è la base della Sua politica sull'IA, della formazione sull'alfabetizzazione in materia di IA richiesta dall'AI Act e delle risposte ai clienti. Dal piano Pro NetSenX mostra quali host raggiungono quali servizi di IA esterni e ambienti locali per modelli, quando e con quanti dati; non mostra ciò che è stato scritto.

Si può misurare a livello di rete, per servizio e per host, e quel numero è più utile di quanto sembri. Il volume non dice che cosa fossero i dati, ma distingue un uso leggero, come domande e risposte brevi, da uno intenso, come il caricamento di interi documenti, fogli di calcolo, repository di codice o registrazioni audio. Un salto improvviso su un host, o un flusso costante da un server che non dovrebbe parlare con servizi di IA, è un motivo per chiedere. Lo segua ogni mese, per funzione aziendale, accanto all'elenco dei servizi approvati: l'uso crescente di uno strumento approvato è una buona notizia; quello di uno non approvato è una lacuna della politica. La console di amministrazione del fornitore di IA può aggiungere il dettaglio per utente negli account aziendali. Dal piano Pro NetSenX mostra quali host raggiungono quali servizi di IA, compresi gli ambienti locali per modelli, e quanti dati vanno a ciascuno nel tempo. Non legge mai il contenuto, quindi non può dire se i dati fossero riservati; questo giudizio spetta a chi ne è responsabile.

In parte. I log DNS mostrano quali host risolvono i domini di servizi di IA noti: un buon inizio, gratuito se il Suo resolver registra già le query; esporti una settimana di interrogazioni e le confronti con un elenco di domini di IA. Sfuggono il DNS cifrato che aggira il resolver, i servizi raggiunti tramite altri domini o reti di distribuzione dei contenuti, le funzioni di IA integrate negli strumenti che già usa e la quantità di dati realmente trasferita. Mostrano inoltre l'host, non la persona, e una singola query può venire da un browser che precarica una pagina. Consideri il DNS una prima vista economica e confermi con i dati di connessione prima di agire. NetSenX combina dal piano Pro le destinazioni con volume e orario delle connessioni, così vede quali host usano quali servizi di IA, compresi gli ambienti locali per modelli, e con quale intensità; non vede il contenuto dei prompt. Per il contenuto lo affianchi ai log di amministrazione del fornitore di IA.

Sì per le connessioni, no per il contenuto. Un'app di chatbot desktop, un assistente di IA in un editor di codice e uno strumento da riga di comando che chiama un'API di IA devono tutti raggiungere il fornitore attraverso la rete, quindi destinazione, tempi e volume sono visibili come per un browser. Conta perché questi strumenti sfuggono spesso ai controlli basati sul browser: una policy sulle estensioni o un proxy web non li vedono, e gli assistenti di IA degli sviluppatori possono inviare come contesto grandi parti di una codebase. Limiti: quando lo strumento parla con un endpoint cloud generico o con un proxy aziendale, il fornitore di IA può restare nascosto dietro; Encrypted Client Hello può nascondere il nome del server; e i portatili usati fuori ufficio sono visibili solo se vi gira l'agente. NetSenX mostra dal piano Pro quali host si collegano a quali servizi di IA esterni e ad ambienti di modelli linguistici eseguiti in locale, e quanti dati vanno a ciascuno, qualunque sia l'applicazione che ha aperto la connessione; non vede quale file o prompt sia stato inviato.

No. Il contenuto della sessione è cifrato, e NetSenX non lo decifra mai. Mostra che un host ha usato un servizio di IA, quando e quanti dati ha inviato; per il contenuto servono i log della versione aziendale del servizio o uno strumento DLP.

Perché il contenuto viaggia dentro connessioni cifrate verso servizi che l'azienda non controlla. Quando qualcuno incolla un testo in un chatbot dal browser, il firewall vede una connessione HTTPS verso il fornitore e al massimo il nome del servizio; il prompt è cifrato da un capo all'altro tra browser e fornitore. Gli account personali conservano la cronologia presso il fornitore, fuori dalla portata dell'azienda. Le funzioni di IA dentro app approvate sembrano normale traffico di quelle app, e i telefoni con dati mobili non passano affatto dalla rete aziendale. Per vedere il contenuto serve controllo a una delle estremità: un account aziendale la cui console di amministrazione e i cui log di audit mostrino l'uso, prevenzione della perdita di dati nel browser o sul dispositivo, oppure un proxy di intercettazione, ciascuno con le proprie questioni di privacy. Ciò che la rete può dare è la cosa migliore dopo: quali host usano quali servizi di IA, quando e quanto. È esattamente ciò che mostra NetSenX dal piano Pro.

No. Fa parte del piano Pro e superiori. Il piano Free copre il rilevamento comportamentale, per esempio di beaconing, scansioni e movimento laterale, senza limiti di tempo.

Dipende da dove si trova lo strumento, e conviene chiedere la risposta per iscritto a ogni fornitore, perché la stessa etichetta copre cose molto diverse. Uno strumento sull'endpoint vede quali applicazioni di IA ed estensioni del browser sono installate e talvolta quali siti vengono visitati; uno strumento basato sul DNS vede le query verso domini di IA tramite il resolver che controlla; un'estensione del browser vede le pagine e, con i permessi giusti, ciò che vi viene digitato; un sensore di rete vede le connessioni verso servizi di IA con volume e tempi; e le console di amministrazione dei fornitori di IA mostrano l'uso degli account aziendali. Nessuno vede tutto da solo. Chieda in concreto: da quale fonte viene la visibilità, se vede il contenuto o solo le destinazioni, se copre app desktop e modelli locali, come gestisce il DNS cifrato, che cosa fa sui dispositivi non gestiti e quali dati personali dei dipendenti raccoglie. NetSenX appartiene alla categoria di rete: dal piano Pro mostra quali host raggiungono quali servizi di IA esterni e ambienti locali per modelli e quanti dati passano, mai ciò che è stato scritto.

Dipende meno dal servizio che dall'account e dai dati. La connessione è cifrata e i grandi fornitori hanno programmi di sicurezza maturi, quindi i rischi principali sono altrove. Un account personale è regolato da condizioni per consumatori: a seconda del fornitore e delle impostazioni, le conversazioni possono essere conservate e usate per migliorare i modelli, e l'azienda non ha una vista di amministrazione, né un accordo sul trattamento dei dati, né modo di cancellare ciò che è stato condiviso. Un account business o enterprise di solito cambia le cose, con limiti contrattuali all'addestramento, impostazioni di conservazione, single sign-on, controlli di amministrazione e log di audit. Gli altri rischi sono umani: dati riservati o personali incollati senza pensarci, risposte sicure ma sbagliate, codice o testo generati usati senza revisione. Regole pratiche: strumento approvato su account aziendale, un breve elenco di dati che non vi entrano mai, autenticazione a più fattori (MFA) sull'account e revisione dei risultati prima che arrivino ai clienti. NetSenX mostra dal piano Pro quali servizi di IA vengono davvero usati e quanti dati vi finiscono.

Tratti un servizio di IA come qualsiasi altro fornitore che tratta i Suoi dati, e lo configuri con cura. Scelga uno o due servizi approvati e usi account aziendali con single sign-on e autenticazione a più fattori, così chi lascia l'azienda perde l'accesso e gli amministratori vedono l'uso. Verifichi il contratto: se i dati vengono usati per l'addestramento, per quanto tempo sono conservati, dove sono trattati e se esiste un accordo sul trattamento dei dati ai sensi del GDPR. Scriva una politica di una pagina con esempi di ciò che può e non può entrare e a chi rivolgersi. Attivi i controlli di amministrazione del fornitore, come i limiti di conservazione e le restrizioni su plugin o connettori. Decida come vengono rivisti i risultati prima che arrivino ai clienti o al codice di produzione. Formi le persone sulla politica e sull'obbligo di alfabetizzazione in materia di IA dell'AI Act. Poi verifichi la realtà: dal piano Pro NetSenX mostra quali servizi di IA usano davvero gli host, compresi quelli non approvati e i modelli locali, e quanti dati vanno a ciascuno, senza leggere il contenuto.

Parta da una politica che le persone possano seguire: quali strumenti di IA sono approvati, per quali dati e tramite quale account aziendale. Poi renda facile da usare lo strumento approvato, perché le persone aggirano le regole che bloccano il lavoro, e un account aziendale presso un fornitore di IA di solito offre impegni contrattuali sull'uso dei dati, impostazioni di amministrazione e log che un account personale non ha. Spieghi la ragione con esempi concreti: elenchi clienti, contratti, codice sorgente, dati retributivi e tutto ciò che è coperto da un accordo di riservatezza restano fuori dagli strumenti non approvati. Seguono i controlli tecnici: prevenzione della perdita di dati sui dispositivi o nel browser, un proxy web e le impostazioni di amministrazione del fornitore di IA stesso. Verifichi il risultato ogni mese, non una volta sola. NetSenX offre visibilità, non blocco: dal piano Pro mostra quali host parlano con quali servizi di IA e quanti dati vi finiscono, così vede se la politica funziona. Non vede che cosa è stato scritto o caricato.

Il solo blocco raramente funziona: le persone passano al telefono, alla rete di casa o ad altri strumenti di IA, e Lei perde di vista l'uso, cioè l'opposto di ciò che vuole. Le liste di blocco inoltre restano indietro, perché ogni mese compaiono nuovi servizi di IA e molti sono integrati in applicazioni che già consente. Una strada più chiara ha tre parti: una politica su quali strumenti di IA sono approvati e quali dati vi possono entrare; uno strumento approvato con account aziendale dove c'è una domanda reale, perché le persone abbiano una buona alternativa; e visibilità su ciò che viene effettivamente usato, rivista con regolarità. Il blocco ha ancora senso per specifici servizi ad alto rischio, per i dispositivi non gestiti sulla rete ospiti o durante un incidente. NetSenX mostra dal piano Pro a quali servizi di IA si collegano gli host della rete, compresi i modelli eseguiti in locale, e quanti dati vanno a ciascuno; vede la destinazione e il volume, non ciò che è stato scritto, e non blocca nulla da solo.

Inizi scoprendo che cosa si usa e perché, prima di scrivere regole. Nella maggior parte delle aziende la prima ondata d'uso dell'IA viene da persone che risolvono problemi reali: scrivere e-mail, riassumere documenti, scrivere codice o tradurre. Un divieto spinge questo uso fuori vista; uno strumento approvato con indicazioni chiare lo mantiene visibile. Poi spieghi i rischi con il linguaggio del lavoro: un contratto con un cliente incollato in un chatbot personale può violare la clausola di riservatezza; un riassunto dell'IA può saltare proprio la frase che conta; il codice generato può portare vulnerabilità o problemi di licenza. Dia un breve elenco di dati che non entrano mai in strumenti non approvati, mostri come usare quello approvato e indichi una persona di riferimento. Formazioni brevi e ripetute funzionano meglio di una sessione lunga, e dal febbraio 2025 l'AI Act chiede alle organizzazioni che usano l'IA di adottare misure per sostenere l'alfabetizzazione in materia di IA del personale. Verifichi i progressi con i fatti: dal piano Pro NetSenX mostra quali servizi di IA vengono davvero usati e quanti dati vi finiscono.

Confronti ciò che la politica consente con ciò che l'azienda usa davvero, partendo da tre fonti. Primo, le console di amministrazione dei servizi di IA approvati: chi ha un account, quanto è attivo, quali funzioni e connettori sono attivati. Secondo, i dati di identità e di spesa: accessi con indirizzi e-mail aziendali a servizi che nessuno ha approvato e abbonamenti di IA su carte aziendali. Terzo, la rete: quali dispositivi si collegano a quali servizi di IA, compresi gli ambienti locali per modelli, e quanti dati vanno a ciascuno. Un buon rapporto mensile mostra i servizi approvati e il loro uso, quelli non approvati ancora in uso e i trasferimenti insolitamente grandi, così la discussione si basa su fatti e non su voci. Resti su strumenti e dispositivi anziché su persone, salvo un sospetto specifico, e coinvolga le risorse umane o le rappresentanze dei lavoratori dove la legge del Suo Paese lo richiede. Dal piano Pro NetSenX fornisce la vista di rete: host, servizi di IA e volumi nel tempo. Non legge ciò che è stato scritto e non blocca nulla.

Solo su un account aziendale approvato, e solo dopo aver verificato che cosa contiene il foglio. Le esportazioni finanziarie contengono spesso più di quanto serva all'analisi: nomi dei clienti e condizioni di pagamento, stipendi, margini, coordinate bancarie e risultati non pubblicati. Su un account personale quei dati restano presso un fornitore con cui non ha contratti, a condizioni che possono consentirne la conservazione o l'uso per l'addestramento. Su un account aziendale con accordo sul trattamento dei dati, impostazioni di conservazione e senza addestramento sui Suoi dati, il rischio è paragonabile a quello di altri servizi cloud che già usa. Regole pratiche per l'area finanza: tolga le colonne che la domanda non richiede, aggreghi o pseudonimizzi i dati personali, non carichi mai risultati non pubblicati di una società quotata né file coperti da accordi di riservatezza, e verifichi le cifre dell'IA sulla fonte prima che entrino in un report, perché i modelli possono calcolare o copiare male i numeri. NetSenX mostra dal piano Pro quali host dell'area finanza raggiungono quali servizi di IA e quanti dati vi finiscono; non vede il file.

Non con la sola rete, ed è bene dirlo con onestà prima di scegliere uno strumento. Il contenuto inviato a un servizio di IA è cifrato, quindi può vederlo solo un controllo a una delle estremità: i log di amministrazione e di audit di un account aziendale di IA, la prevenzione della perdita di dati nel browser o sul dispositivo che riconosca schemi di dati dei clienti, oppure un proxy di intercettazione. Ognuno richiede una politica chiara, l'informazione del personale e, in molti Paesi, il coinvolgimento delle rappresentanze dei lavoratori. Ciò che la rete mostra in modo affidabile è il contesto: quali dispositivi usano quali servizi di IA, con quale frequenza e quanti dati inviano. Un portatile commerciale che invia ogni giorno diversi megabyte a un chatbot non approvato è un motivo per parlare di strumenti e dati, non la prova di una violazione. Spesso la risposta migliore è un'alternativa autorizzata che svolga lo stesso lavoro con un account aziendale. Dal piano Pro NetSenX mostra host, servizi di IA e volumi; non vede mai il testo incollato.

Può esserlo, a seconda dei dati, dell'account e delle condizioni. Secondo il GDPR, regolamento (UE) 2016/679, inviare dati personali a un fornitore di IA è un trattamento che richiede una base giuridica, trasparenza verso gli interessati e, quando il fornitore agisce per Suo conto, un accordo sul trattamento dei dati. I trasferimenti fuori dall'UE richiedono garanzie proprie. Su un account aziendale con tale accordo e impostazioni che escludono l'addestramento sui Suoi dati, l'uso per una finalità definita può essere lecito. Incollare e-mail di clienti in un account personale con condizioni per consumatori è più difficile da giustificare e può costituire una divulgazione non autorizzata, che il GDPR tratta come violazione dei dati personali; se è probabile che comporti un rischio per le persone, il titolare deve notificarla all'autorità di controllo entro 72 ore ai sensi dell'articolo 33. Coinvolga il responsabile della protezione dei dati, annoti che cosa è stato condiviso e con quale servizio, e rimuova la causa con uno strumento approvato. NetSenX mostra dal piano Pro quali host hanno inviato dati a quali servizi di IA, non quali dati fossero.

Raramente come primo passo, e mai sulla sola base dei dati di rete. La maggior parte dell'uso non approvato dell'IA viene da persone che cercano di lavorare più in fretta, spesso perché non esiste uno strumento approvato o la politica non è mai stata spiegata. Il licenziamento per una prima violazione in buona fede può essere sproporzionato secondo il diritto del lavoro di molti Paesi dell'UE, e insegna al resto del personale a nascondere l'uso invece di chiedere. Una sequenza più sensata: verificare che la politica fosse chiara, comunicata e ragionevole; offrire un'alternativa approvata; trattare una prima violazione con un colloquio e un richiamo documentato; riservare le misure disciplinari alle violazioni deliberate o ripetute, o ai danni gravi come la divulgazione di dati riservati di un cliente. Decida con le risorse umane e un consulente legale, e coinvolga le rappresentanze dei lavoratori dove la legge del Suo Paese lo richiede. Un sensore di rete non può stabilire chi ha fatto che cosa: NetSenX mostra quale dispositivo si è collegato a quale servizio di IA e quanti dati sono passati, un punto di partenza per fare domande, non una prova dell'intenzione di una persona.

Soprattutto che i dati aziendali escano a condizioni che nessuno ha accettato, e che poi nessuno sappia renderne conto. L'IA personale comprende abbonamenti privati a chatbot, app di IA su telefoni personali, estensioni del browser, registratori di riunioni con IA e modelli eseguiti su hardware privato. Il rischio per i dati: documenti, dati dei clienti o registrazioni finiscono presso fornitori con condizioni per consumatori, magari fuori dall'UE, senza accordo sul trattamento, e restano negli account personali dopo che il dipendente se n'è andato. Il rischio di qualità: lavori costruiti su risultati che nessuno ha verificato. Il rischio di conformità: non può rispondere a un cliente, a un revisore o a un interessato che chiede dove siano finiti i suoi dati. I registratori di riunioni con IA meritano un'attenzione particolare, perché registrano voce e parole di altre persone, spesso senza il consenso di tutti. La risposta pratica è offrire un buon strumento approvato, dire chiaramente quali strumenti personali si possono usare e per che cosa, e chiedere che la registrazione delle riunioni venga annunciata. Dal piano Pro NetSenX mostra quali servizi di IA raggiungono i dispositivi aziendali; i telefoni personali con dati mobili restano fuori da qualsiasi vista di rete.

Spesso più dei chatbot stessi, per via dei permessi che chiedono. Per riassumere pagine, riscrivere e-mail o compilare moduli, un'estensione di IA di solito deve poter leggere e modificare tutto su ogni sito visitato, compresi webmail, CRM, home banking e applicazioni interne. Poi invia il contenuto delle pagine ai propri server o a un fornitore di IA. Alcune estensioni sono ben gestite; altre sono piccoli progetti che cambiano proprietario, vengono vendute o ricevono un aggiornamento con tracciamento o codice malevolo, che il browser installa in silenzio. Passi pratici: consenta solo estensioni da un elenco gestito tramite le policy del browser, esamini permessi ed editore di ciascuna, preferisca le funzioni di IA degli strumenti approvati alle estensioni e rimuova quelle che nessuno sa giustificare. Un sensore di rete vede le connessioni di un'estensione verso i suoi server come qualsiasi altro traffico, ma non può dire quale estensione le abbia aperte; l'inventario spetta alla gestione dei browser o dei dispositivi. Dal piano Pro NetSenX mostra quali host raggiungono quali servizi di IA e quanti dati vi finiscono.

Se la Sua organizzazione usa sistemi di IA nel proprio lavoro, l'articolo 4 del regolamento le impone di adottare misure per sostenere l'alfabetizzazione in materia di IA del personale, e questo obbligo si applica dal 2 febbraio 2025; dal luglio 2026 il testo modificato precisa che non occorre garantire un livello preciso per ogni persona. Sapere quali servizi di IA sono davvero in uso è un primo passo pratico; il Suo consulente legale Le dirà che cos'altro La riguarda.

In parte sì. Il regolamento (UE) 2024/1689 impone obblighi ai deployer, cioè alle organizzazioni che usano sistemi di IA nella propria attività, e non solo ai fornitori che li sviluppano. Dal 2 febbraio 2025 l'articolo 4 chiede a fornitori e deployer di adottare misure sull'alfabetizzazione in materia di IA del personale che si occupa di sistemi di IA; nella versione modificata nel luglio 2026 dal regolamento (UE) 2026/1744, si tratta di sostenere tale alfabetizzazione, senza garantire un livello preciso per ogni persona. Anche i divieti dell'articolo 5 valgono dal 2 febbraio 2025. Altri obblighi dipendono dalla categoria di rischio del sistema e si applicano da date successive: chi usa un sistema ad alto rischio, per esempio nella selezione del personale o nelle decisioni di credito, ha obblighi di sorveglianza umana, monitoraggio e registrazione, e alcuni usi comportano obblighi di trasparenza verso le persone interessate. Usare un chatbot generico per scrivere testi sta all'estremo leggero. Un buon inizio è un inventario dei sistemi di IA effettivamente usati e degli scopi, poi una formazione costruita su quell'elenco. Verifichi i dettagli con un consulente legale, perché le linee guida vengono ancora pubblicate.

Significa che l'azienda deve adottare misure che sostengano l'alfabetizzazione in materia di IA del personale che si occupa di sistemi di IA, e di solito sono le risorse umane a organizzarlo. L'articolo 4 del regolamento (UE) 2024/1689 si applica dal 2 febbraio 2025 sia ai fornitori sia ai deployer, quindi riguarda anche le normali aziende che usano strumenti di IA; nella versione modificata nel luglio 2026 dal regolamento (UE) 2026/1744, precisa che l'azienda non deve garantire un livello preciso di alfabetizzazione per ogni persona. Misure ben fatte continuano a tenere conto delle conoscenze tecniche, dell'esperienza, dell'istruzione e della formazione delle persone, oltre che del contesto in cui i sistemi di IA vengono usati. L'articolo 4 non prescrive un certificato, un numero fisso di ore né un corso unico. Passi pratici: elenchi i sistemi di IA effettivamente in uso e chi li usa; definisca che cosa deve sapere ogni gruppo, dai rischi di base e dalla politica aziendale per tutti a una formazione più approfondita per chi configura l'IA o vi si affida nelle decisioni; tenga un registro semplice di chi è stato formato su che cosa e quando; e ripeta quando gli strumenti cambiano. NetSenX può aiutare nel primo passo: dal piano Pro mostra quali servizi di IA usano davvero i dispositivi aziendali.

Quelli che le persone usano davvero, che raramente coincidono con l'elenco della politica. Parta da un inventario: servizi approvati su account aziendali, funzioni di IA dentro il software che già paga, servizi usati dal personale con account personali e modelli locali sulle macchine di sviluppatori o ingegneri. Poi adatti la formazione all'uso. Tutti hanno bisogno delle basi: quali sono gli strumenti approvati, quali dati non entrano mai in nessuno strumento di IA, perché le risposte possono essere sbagliate e come segnalare un problema. Chi usa l'IA su dati di clienti o personali, in finanza, risorse umane o vendite, ha bisogno delle regole di protezione dei dati e riservatezza che lo riguardano. Gli sviluppatori hanno bisogno di un uso sicuro di assistenti di programmazione e agenti, compreso ciò a cui questi strumenti hanno accesso. I manager che si affidano ai risultati dell'IA per decidere devono capirne i limiti. Formare su strumenti che nessuno usa fa perdere tempo; trascurare quelli quotidiani lascia intatto il rischio reale. Dal piano Pro NetSenX mostra quali servizi di IA esterni e ambienti locali per modelli raggiungono i dispositivi aziendali, così l'elenco della formazione corrisponde alla realtà.

In generale no. L'articolo 5 dell'AI Act, regolamento (UE) 2024/1689, vieta l'immissione sul mercato, la messa in servizio e l'uso di sistemi di IA per inferire le emozioni di una persona fisica nell'ambito del luogo di lavoro e degli istituti di istruzione, tranne quando il sistema è destinato a motivi medici o di sicurezza. Il divieto si applica dal 2 febbraio 2025. Riguarda strumenti che leggono emozioni o intenzioni da volto, voce, digitazione o altri segnali biometrici, per esempio in software per call center, componenti aggiuntivi per videoconferenze o monitoraggio della produttività, e le sanzioni per le pratiche vietate sono le più alte del regolamento. Il diritto del lavoro e la protezione dei dati pongono ulteriori limiti al controllo del personale. Prima di acquistare uno strumento che promette di misurare coinvolgimento, stress o stato d'animo dei dipendenti, chieda per iscritto al fornitore quali dati usa e come si colloca rispetto all'articolo 5, e coinvolga il consulente legale e il responsabile della protezione dei dati. NetSenX non fa nulla di simile: monitora dispositivi e connessioni di rete, mai persone, e non valuta individui.

Con una risposta specifica e verificabile, non con una rassicurazione. Clienti e uffici acquisti chiedono sempre più spesso quali servizi di IA toccano i loro dati, a quali condizioni e con quali controlli. Una buona risposta nomina i servizi di IA approvati e come sono contrattualizzati, per esempio account aziendali senza addestramento sui Suoi input, con un accordo sul trattamento dei dati e luoghi di trattamento dichiarati; dice quali dati del cliente possono entrarvi e quali no; descrive i controlli, come la politica sull'IA, la formazione del personale, le restrizioni di accesso e la revisione dei risultati; e spiega come verifica che la pratica corrisponda alla politica. Se oggi la risposta onesta è che non lo sa, dica che cosa sta facendo per scoprirlo ed entro quando, invece di promettere qualcosa che non può dimostrare. Mantenga la risposta coerente con i contratti e con il registro dei trattamenti. Dal piano Pro NetSenX mostra quali servizi di IA raggiungono davvero i dispositivi della Sua azienda e quanti dati vanno a ciascuno, così la risposta al cliente si basa sul Suo stesso traffico e non su supposizioni; non mostra di quale cliente fossero i dati.

Spesso sì, almeno come impegno su cui il cliente può contare, ma il contratto deve restare più breve della politica. I clienti aggiungono sempre più spesso clausole sull'IA: nessun uso dei loro dati per addestrare modelli, nessun trattamento da parte di servizi di IA al di fuori dei sub-responsabili o delle regioni concordati, informazione quando i deliverable sono realizzati con l'aiuto dell'IA e notifica se i loro dati sono stati esposti tramite uno strumento di IA. Invece di allegare l'intera politica interna, che cambia spesso, si impegni nel contratto o nell'accordo sul trattamento dei dati su pochi principi stabili, elenchi come sub-responsabili i servizi di IA che trattano dati del cliente quando è così e rimandi alla politica da Lei aggiornata. Si assicuri di poter mantenere ogni promessa nella pratica: una clausola secondo cui nessun dato del cliente entra mai negli strumenti di IA non vale nulla se il personale usa account personali di chatbot e Lei non lo vede. Concordi che cosa conta come lavoro assistito dall'IA, perché la maggior parte dei software d'ufficio ha ormai funzioni di IA. Faccia rivedere il testo da un consulente legale. Dal piano Pro NetSenX mostra quali servizi di IA raggiungono davvero i Suoi dispositivi, una verifica utile prima di firmare una clausola del genere.

Cerchi i servizi che gli ambienti di modelli locali espongono e il traffico intorno a essi. Gli strumenti che eseguono modelli linguistici in locale di solito aprono un'API HTTP su una porta predefinita nota, offrono un'interfaccia web e alla prima configurazione scaricano grandi file di modelli da archivi pubblici. Aiutano quindi tre controlli: una scansione autorizzata degli intervalli interni alla ricerca delle porte predefinite degli ambienti più diffusi e di interfacce web inattese; un'analisi di quali macchine hanno scaricato file di diversi gigabyte da archivi di modelli; e un elenco degli host con GPU potenti, che l'IT spesso conosce già. Poi chieda ai responsabili a che cosa serve ogni server, chi può raggiungerlo e quali dati vi entrano. Molti sono esperimenti innocui; alcuni restano aperti a tutta la rete senza autenticazione. NetSenX mostra dal piano Pro il traffico verso ambienti di modelli linguistici eseguiti in locale: quale host ne esegue o ne chiama uno e quanti dati passano, accanto ai servizi di IA esterni. Non vede i prompt né le risposte del modello.

Può esserlo, soprattutto per normali errori di configurazione più che per qualcosa di esotico. Tenere i dati sul proprio hardware evita di inviarli a un fornitore esterno, e questo è un vantaggio reale. I rischi sono quelli di ogni server nuovo e non pianificato: l'API o l'interfaccia web ascoltano spesso su tutte le interfacce senza autenticazione, così chiunque in rete può usare il modello, leggere la cronologia delle conversazioni o caricare file; il server esegue software non aggiornato che cambia rapidamente; i file di modelli scaricati da archivi pubblici possono contenere codice malevolo se usano formati non sicuri; e i documenti inseriti per la ricerca possono essere leggibili da chiunque raggiunga il server. Lo tratti come qualsiasi servizio interno: un responsabile designato, autenticazione, ascolto limitato a localhost o a un segmento ristretto, aggiornamenti, formati di modello sicuri da fonti affidabili e una decisione su quali dati possono entrare. Dal piano Pro NetSenX mostra quali host eseguono o chiamano ambienti locali di modelli linguistici e quanti dati passano, e i suoi rilevamenti di base segnalano in ogni piano scansioni o movimento laterale da quell'host.

È il rischio che un modello, un dataset o una libreria di IA scaricati o acquistati siano compromessi, descritti in modo falso o semplicemente non siano ciò che crede. Gli archivi pubblici di modelli ospitano centinaia di migliaia di modelli caricati da chiunque. Alcuni formati di file dei modelli possono eseguire codice al caricamento, quindi un modello malevolo può compromettere la macchina che lo apre; esistono formati più sicuri, da preferire. Un modello può essere messo a punto per comportarsi normalmente tranne che davanti a un innesco nascosto, oppure addestrato su dati avvelenati. I nomi possono essere copiati per sembrare il modello di un editore noto. E le librerie e i plugin intorno ai modelli, come ambienti di esecuzione, connettori e framework per agenti, cambiano in fretta e hanno normali vulnerabilità software. Passi pratici: prenda modelli solo da editori verificabili, controlli firme o hash quando vengono pubblicati, usi formati di file sicuri, esegua i nuovi modelli prima in un ambiente isolato, tenga un inventario dei modelli e delle versioni in uso e aggiorni il software circostante come qualsiasi altro. Un sensore di rete vede i grandi download di modelli e quali host eseguono ambienti per modelli; non può ispezionare i pesi di un modello.

Può esserlo, allo stesso modo del codice copiato da internet, solo più in fretta e in quantità maggiori. Gli assistenti di programmazione producono codice plausibile che di solito funziona, ma che può contenere schemi di vulnerabilità noti come falle di injection, crittografia debole o controlli mancanti sugli input; chiamare pacchetti che non esistono, che gli attaccanti registrano poi con quel nome e contenuto malevolo; riprodurre codice con una licenza che il Suo prodotto non può accettare; e incorporare segreti presi da esempi. Gli strumenti stessi inviano anche il codice sorgente al fornitore come contesto, quindi la scelta del servizio e dell'account conta per la riservatezza. Tratti l'output dell'IA come la pull request di un collega junior: stessa revisione del codice, test di sicurezza automatici, scansione di dipendenze e licenze e rilevamento dei segreti nella pipeline, con la responsabilità che resta allo sviluppatore. Decida quali repository possono essere condivisi con quale assistente. Dal piano Pro NetSenX mostra quali macchine degli sviluppatori e server di build inviano dati a quali servizi di IA e quanti; non può giudicare la qualità del codice.

La prompt injection è un attacco in cui un testo letto da un sistema di IA è scritto per fargli ignorare le istruzioni e fare altro. L'injection diretta arriva dall'utente che la digita. Quella indiretta è la più seria per le aziende: l'istruzione si nasconde in contenuti che l'IA elabora per conto di qualcuno, come una pagina web, un'e-mail, un documento condiviso o un ticket di assistenza, e il modello la segue come se venisse dal suo operatore. Se l'IA può solo rispondere in una finestra di chat, il danno si limita a una risposta sbagliata o imbarazzante. Se può leggere una casella di posta, chiamare strumenti, interrogare un database o navigare, un'istruzione iniettata può farle divulgare dati o compiere azioni. Oggi non esiste una soluzione completa, perché i modelli non separano in modo affidabile istruzioni e dati. Ciò che aiuta: dare agli strumenti di IA meno permessi possibile, richiedere l'approvazione umana per le azioni con conseguenze, tenere i sistemi sensibili fuori dalla portata degli agenti che leggono contenuti non fidati e registrare ciò che l'IA ha fatto. OWASP mette la prompt injection al primo posto tra i rischi delle applicazioni basate su modelli linguistici di grandi dimensioni (LLM).

È un elenco dei principali rischi di sicurezza delle applicazioni costruite su modelli linguistici di grandi dimensioni (LLM), pubblicato dall'Open Worldwide Application Security Project (OWASP), la comunità che sta dietro al noto Top 10 per le applicazioni web. L'edizione 2025 elenca prompt injection, divulgazione di informazioni sensibili, rischi della catena di fornitura, avvelenamento di dati e modelli, gestione impropria degli output, autonomia eccessiva, fuga del prompt di sistema, debolezze di database vettoriali ed embedding, disinformazione e consumo illimitato di risorse. Per un'azienda che si limita a usare strumenti di IA contano soprattutto tre voci: la divulgazione di informazioni sensibili, cioè il problema della shadow AI; l'autonomia eccessiva, cioè agenti di IA con più permessi del necessario; e la prompt injection, che trasforma ogni documento o pagina web letti da un agente in un possibile attacco. Per un'azienda che integra funzioni di IA nel proprio prodotto, l'intero elenco è una checklist sensata per revisioni di progetto e test, e un vocabolario comune per i questionari di sicurezza dei clienti. È una guida, non una norma né una certificazione.

Progetti in modo che il modello veda solo ciò che serve al compito, e dia per scontato che tutto ciò che vede possa uscire di nuovo. In concreto: scelga un'implementazione con condizioni contrattuali adatte ai Suoi dati, come un'API enterprise senza addestramento sugli input, con un periodo di conservazione definito e trattamento nell'UE dove richiesto, oppure un modello ospitato in proprio; minimizzi e pseudonimizzi ciò che entra nei prompt; nei sistemi di recupero documentale applichi i diritti di accesso dell'utente ai documenti che il modello può recuperare, perché non riassuma file che l'utente non può aprire; tenga segreti, chiavi e credenziali di sistema fuori da prompt e contesto; filtri gli output per dati personali e segreti prima che arrivino agli utenti o ai log; limiti gli strumenti che il modello può chiamare e richieda l'approvazione per le azioni; e registri prompt e risposte in modo protetto per le indagini, con una conservazione adeguata. Provi la resistenza a prompt injection e tentativi di estrazione dei dati prima del lancio e dopo ogni modifica. Dal piano Pro NetSenX mostra quali server inviano dati a quali servizi di IA esterni e quanti, il che aiuta a confermare che il traffico di produzione vada solo dove prevede il progetto.

Il Model Context Protocol (MCP) è un protocollo aperto, introdotto da Anthropic nel novembre 2024 e poi ampiamente adottato, che consente ad assistenti e agenti di IA di collegarsi in modo standard a strumenti e fonti di dati. Un server MCP espone capacità, come leggere file, interrogare un database, cercare in un sistema di ticket o inviare messaggi, e un client di IA le chiama quando un compito lo richiede. Questo rende l'IA molto più utile, ma trasforma anche ogni server MCP in un varco: ciò che lui può raggiungere, lo raggiunge l'IA, con i permessi dell'account che sta dietro. Le domande di sicurezza seguono subito. Chi ha installato il server e da dove? Quali credenziali conserva e quanto sono ampie? Gira in locale su un portatile o come servizio remoto? Richiede un'approvazione prima di agire? Viene registrato? Tratti i server MCP come software con accesso privilegiato: li approvi, limiti strettamente i loro token, li tenga aggiornati e preferisca server di editori verificati. Un sensore di rete vede i server MCP remoti come connessioni verso i loro host; quelli locali su un portatile restano fuori dalla sua vista.

Uno shadow MCP server è un server Model Context Protocol che qualcuno ha collegato a un assistente di IA all'insaputa dell'IT, di solito per risparmiare tempo: un connettore verso la casella di posta aziendale, una cartella condivisa, un repository di codice, un database o un sistema di ticket, installato da un catalogo pubblico o scritto in un pomeriggio. Il rischio è che crei in silenzio un nuovo percorso di accesso. Spesso conserva un token di accesso personale o una chiave API con ampi diritti, salvati in un file di configurazione su un portatile; può provenire da un autore sconosciuto e aggiornarsi da solo; consente all'IA di agire sui sistemi aziendali con i permessi di quella persona; e tutto ciò che l'IA legge, compresa un'istruzione malevola nascosta in un documento o in una pagina web, può orientare ciò che fa tramite quel connettore. Nessuno lo esamina né lo registra, e sopravvive all'uscita del dipendente se il token non viene revocato. Passi pratici: pubblichi un elenco di server MCP approvati, limiti strettamente i token e li ruoti, controlli nei log del fornitore di identità le nuove autorizzazioni OAuth concesse a client di IA e includa i connettori nella procedura di uscita. Un sensore di rete vede le connessioni di un portatile verso servizi remoti, non la configurazione MCP che vi si trova.

Cerchi là dove gli agenti prendono il loro potere: identità, connettori e piattaforme di automazione, poi confermi con il traffico di rete. Un agente di IA è un software che usa un modello linguistico per decidere ed eseguire dei passi, come leggere ticket, interrogare sistemi, scrivere codice o inviare e-mail, di solito tramite chiavi API, account di servizio o autorizzazioni OAuth. Le migliori prime fonti sono quindi il fornitore di identità e le console di amministrazione dei servizi SaaS: nuove applicazioni OAuth con ambiti ampi, account di servizio o token personali creati di recente e funzioni di IA con connettori attivati. Poi verifichi piattaforme di automazione e low-code, pipeline di CI e macchine degli sviluppatori alla ricerca di framework per agenti e server MCP, e chieda direttamente ai team, perché molti agenti sono progetti pilota che nessuno ha registrato. La rete aggiunge la vista comportamentale: quali server o postazioni chiamano regolarmente API di IA, di notte o a raffiche, e quali raggiungono anche sistemi interni. Dal piano Pro NetSenX mostra quali host parlano con quali servizi di IA esterni e ambienti locali per modelli e quanti dati passano. Non identifica un agente per nome, e i segnali comportamentali specifici degli agenti non sono ancora allarmi.

Sì, e di solito con controlli più stretti di quelli per una persona con gli stessi diritti. Un agente agisce a velocità di macchina, non si stanca né si insospettisce, può essere pilotato dal testo che legge e spesso funziona con un token che non scade mai. Dia quindi a ogni agente un'identità propria invece dell'account di una persona, conceda solo i permessi che il compito richiede, preferisca l'accesso in sola lettura, separi gli ambienti perché un agente di test non tocchi la produzione, richieda l'approvazione umana per pagamenti, cancellazioni, messaggi esterni e modifiche dei permessi, imposti scadenza e rotazione delle sue credenziali e registri ogni sua azione in un luogo che non può modificare. Esamini gli agenti nelle stesse revisioni degli accessi degli account di servizio e li includa nella procedura di uscita. Il costo di saltare tutto questo è concreto: il Cost of a Data Breach Report 2025 di IBM ha rilevato che il 13% delle organizzazioni ha segnalato violazioni di modelli o applicazioni di IA, e il 97% di queste ha dichiarato di non avere controlli di accesso adeguati per l'IA. Sul lato rete, NetSenX rileva in ogni piano il comportamento di un'identità abusata, come movimento laterale e caricamenti insoliti, dall'host su cui gira l'agente.

Sì, e senza che nessuno lo voglia. A un agente con accesso a CRM, casella di posta o unità condivisa si può chiedere, oppure lo si può ingannare con un'istruzione nascosta in un documento, un'e-mail o una pagina web che legge, di riassumere, inoltrare o caricare dati ben oltre ciò che serve al suo compito. Percorsi tipici: un agente che risponde a messaggi esterni e inserisce dati interni nella risposta, un agente che può inviare e-mail o pubblicare su servizi esterni, un agente di programmazione che carica su un repository pubblico codice con segreti incorporati, e un agente i cui log o la cui memoria conservano dati dei clienti dove nessuno se li aspetta. Il rimedio è il perimetro: solo i dati necessari al compito, nessun canale in uscita se non serve, approvazione umana prima che qualcosa esca dall'azienda e separazione tra agenti che leggono contenuti non fidati e agenti con accessi sensibili. Verifichi questi percorsi prima della messa in produzione. In ogni piano NetSenX rileva un volume di dati in uscita insolito da un host, qualunque processo lo abbia causato, e dal piano Pro mostra con quali servizi di IA comunica l'host; non vede che cosa ha inviato l'agente.

In parte oggi, e NetSenX dice chiaramente quale parte. Ciò che funziona: dal piano Pro, il traffico da un host verso servizi di IA esterni e verso ambienti di modelli linguistici eseguiti in locale, con tempi e volumi; e in ogni piano, i comportamenti che un agente abusato condividerebbe con qualsiasi host compromesso, come raggiungere molti sistemi interni mai usati prima, scansionare, contattare regolarmente un server sconosciuto o inviare volumi di dati insoliti. Ciò che non è attivo: i segnali mirati specificamente agli agenti, come azioni a ritmo di macchina subito dopo una chiamata a un modello linguistico, o una prima connessione verso una nuova destinazione che segue una risposta del modello. NetSenX li misura in modalità ombra, senza generare allarmi, finché non saranno abbastanza affidabili da essere utili; non vanno presentati né usati come rilevamenti. I controlli più forti stanno altrove: permessi ristretti, approvazione umana per le azioni con conseguenze e i log delle azioni dell'agente stesso. Un sensore di rete inoltre non vede mai quale istruzione abbia fatto agire l'agente.

Soprattutto per condurre attacchi noti più in fretta, a minor costo e con una lingua migliore, non per inventarne di nuovi. Le e-mail di phishing non si tradiscono più con una grammatica goffa e possono essere adattate alla Sua azienda in pochi minuti partendo da informazioni pubbliche. La clonazione della voce e i video deepfake rendono più convincenti le false chiamate di un dirigente o di un fornitore. Gli attaccanti usano l'IA per scrivere e variare script, studiare gli obiettivi e ordinare rapidamente i dati rubati. Questo cambia la difesa in due modi. I controlli basati sul notare una scrittura scadente o un tono strano perdono valore, quindi i processi non devono dipendere dal riconoscere un falso: confermi le modifiche dei dati di pagamento tramite un canale noto, usi un'autenticazione a più fattori resistente al phishing e limiti ciò che un singolo account rubato può raggiungere. E i passi successivi al primo punto d'appoggio appaiono uguali in rete, chiunque o qualunque cosa abbia scritto gli strumenti: un dispositivo che contatta un server sconosciuto, scansioni, movimento laterale e dati in uscita. NetSenX rileva questi comportamenti in ogni piano, anche Free, senza bisogno di riconoscere il malware o il messaggio da cui è partito tutto.

Sì, e la difesa è un processo, non una tecnologia. Con pochi minuti di audio o video pubblici, un attaccante può imitare voce e volto di un dirigente o di un fornitore abbastanza bene da superare una telefonata o una videochiamata, soprattutto sotto pressione. All'inizio del 2024 la polizia di Hong Kong ha descritto un caso in cui un dipendente di una multinazionale ha trasferito somme ingenti dopo una videoconferenza in cui gli altri partecipanti, compreso un alto dirigente, erano deepfake. Protezione: una regola per cui nessun pagamento, cambio di coordinate bancarie o bonifico urgente viene approvato solo sulla base di una chiamata o di un messaggio; conferma tramite un canale separato già noto, come richiamare il numero in anagrafica, mai quello indicato nella richiesta; due persone per approvare i pagamenti sopra una soglia; se vuole, una parola d'ordine per le vere urgenze; e un personale che sa di essere sostenuto se rallenta un pagamento. Nessun sensore di rete distingue una voce vera da una falsa. NetSenX non è la risposta in questo caso: non analizza chiamate né video e non vede gli ordini di pagamento.