L’IA in azienda non ha un solo ufficio di riferimento
Ricerca, prodotto, marketing e sistemi informativi incontrano regole diverse: la mappa va fatta reparto per reparto
In alcune imprese, ormai, l’intelligenza artificiale ha un ufficio o una persona di riferimento e di solito si tratta di chi si occupa di IT.
Questa settimana ho tenuto due mattine di formazione in una grande impresa su GDPR, NIS2, Cyber Resilience Act (CRA), Data Act e AI Act. Le domande arrivate per la seconda mattina mostrano che quella scelta organizzativa non sempre regge.
Le domande non erano molte, ma ognuna nasceva da un’attività diversa: un progetto R&D affidato a fornitori esterni, un prodotto in cui inserire un assistente conversazionale, la documentazione tecnica letta dai chatbot, le immagini prodotte dalle agenzie, l’iniziativa di un dipendente fuori dai sistemi aziendali, i componenti acquistati da terzi.
Nessuna chiedeva quale ruolo rivestisse l’azienda né, soprattutto, in quale classe di rischio rientrasse il sistema.
Eppure la risposta a ciascuna dipendeva proprio da lì: da quale norma regoli la fattispecie e, in particolare, da quale veste assuma l’impresa, da quale sia il caso specifico di applicazione e, per certi versi (come nel CRA), dal momento in cui il prodotto arriva sul mercato.
L’AI Act compare in quasi tutte le risposte, ma in poche basta da solo a deciderle.
Ricerca e acquisti: il segreto passa dal fornitore
Quando un fornitore dell’R&D usa l’IA generativa, il rischio è più sottile e talvolta peggiore della fuga di un documento.
L’assistente del fornitore, qualunque sia il modello, può indicizzare cartelle condivise con permessi ampi: chi lavora al progetto magari non apre il documento, ma riceve una risposta costruita su quel documento.
La clausola di riservatezza tradizionale spesso non copre questo scenario; servono clausole sull’IA. La definizione di informazioni riservate andrebbe estesa anche agli output e ai materiali derivati; il contratto dovrebbe elencare gli strumenti di IA ammessi e, ovviamente, la loro configurazione (nessun addestramento sui dati, nessuna conservazione oltre il servizio, localizzazione dei dati) e vietare gli altri. Spazi e indici del progetto dovrebbero essere accessibili al solo gruppo di lavoro specificamente individuato ed esclusi dagli assistenti conversazionali generalisti; restituzione e cancellazione finali dovrebbero comprendere indici vettoriali, embedding e registri delle richieste. Un aspetto rilevante, da gestire già in negoziazione, è quello dei diritti di audit sul fornitore, perché le “solite” checklist spesso lasciano il tempo che trovano. Gli stessi obblighi dovrebbero valere per i subfornitori, chiaramente individuati, anche qui con diritto di verifica, notifica degli incidenti entro termini brevi, titolarità degli output e penali.
Queste clausole hanno un fondamento preciso, che non è solo quello di una corretta mappatura ai fini del rispetto delle norme e della gestione degli incidenti. Il segreto commerciale è tutelato solo se le informazioni sono sottoposte a “misure da ritenersi ragionevolmente adeguate a mantenerle segrete”: senza clausole sull’IA quella prova diventa difficile. Per i soggetti NIS2 la sicurezza della catena di approvvigionamento è anche una misura obbligatoria. Se dal progetto nasce un prodotto con elementi digitali, dall’11 dicembre 2027 il CRA chiederà al fabbricante una distinta base del software che copra almeno le dipendenze di primo livello (allegato I, parte II, punto 1; ne ho scritto nel #78) e, se il fornitore tratta dati personali per conto dell’impresa, serve l’addendum previsto dall’art. 28 GDPR.
Prodotto: da utilizzatori a fornitori
Il reparto che progetta i prodotti è quello in cui il ruolo dell’impresa cambia più facilmente.
Chi immette sul mercato con il proprio marchio un prodotto dotato di un assistente che dialoga con l’utente sullo stato di un impianto e impartisce comandi è fornitore (provider) del sistema di IA, anche se il modello linguistico è di terzi. Diventerebbe, tra l’altro, fornitore anche del modello per finalità generali se lo modificasse in modo significativo.
La classificazione del sistema richiede più cautela. Per un prodotto di questo tipo il sistema è ad alto rischio solo se ricorrono insieme due condizioni: è componente di sicurezza di un prodotto disciplinato da una normativa dell’allegato I (o è esso stesso quel prodotto) e quel prodotto è soggetto a valutazione della conformità da parte di terzi (art. 6, par. 1; ne ho scritto nel #80). La direttiva sulle apparecchiature radio è nell’allegato I, ma con le norme armonizzate applicate consente di norma il controllo interno: la verifica va fatta prodotto per prodotto. Se il sistema fosse ad alto rischio, gli obblighi si applicherebbero dal 2 agosto 2028; in ogni caso, dal 2 agosto 2026, il fornitore deve progettare l’assistente in modo che chi lo usa sappia di parlare con un’IA, salvo che sia evidente (art. 50, par. 1).
I criteri di progetto vengono anche da altre norme: conferma esplicita dell’utente per i comandi critici (aprire una porta, disattivare un allarme), un elenco chiuso delle azioni che il sistema può eseguire, difese contro la manipolazione dei comandi, registrazione delle azioni eseguite. Le ultime due sono anche requisiti del CRA (allegato I, parte I); se l’assistente trasmette al fabbricante la voce o le abitudini domestiche servono un’informativa adeguata e, con ogni probabilità, una valutazione d’impatto (artt. 13 e 35 GDPR).
Lo stesso reparto incontra il CRA nella domanda sui componenti di terzi che erano conformi al momento della vendita. Conta la data in cui il singolo esemplare è immesso sul mercato, cioè fornito per la prima volta nell’Unione a fabbricazione ultimata: secondo la Guida blu della Commissione basta l’accordo che ne trasferisce la proprietà o il possesso, anche senza consegna materiale. Non contano l’installazione né la successiva vendita al cliente finale: l’esemplare consegnato al distributore prima dell’11 dicembre 2027 si può vendere anche dopo senza adeguamenti.
Per gli esemplari immessi da quella data il fabbricante risponde dell’intero prodotto, componenti di terzi e open source compresi: dovuta diligenza nell’integrarli, segnalazione delle vulnerabilità a chi li mantiene, aggiornamenti di sicurezza gratuiti per tutto il periodo di assistenza, di regola almeno cinque anni.
Per quelli immessi prima il fabbricante deve già notificare, dall’11 settembre 2026, le vulnerabilità attivamente sfruttate e gli incidenti gravi; il CRA si applica loro per intero se dopo l’11 dicembre 2027 una modifica, anche solo software, incide sul rispetto dei requisiti essenziali o sulla finalità prevista. Per i prodotti radio connessi immessi dal 1° agosto 2025 valgono inoltre i requisiti di cybersicurezza del regolamento delegato (UE) 2022/30.
Per la responsabilità civile, ai prodotti immessi sul mercato o messi in servizio dopo il 9 dicembre 2026 si applica la nuova direttiva sui prodotti difettosi, la (UE) 2024/2853 (ne ho scritto nel #23). Resta da chiarire il regime dei prodotti immessi prima del 9 dicembre e messi in servizio dopo. Il fabbricante non si libera provando che il difetto è sorto dopo l’immissione, se dipende dalla mancanza di aggiornamenti software necessari a mantenere la sicurezza e fornirli era sotto il suo controllo (art. 11, par. 2). La tutela riguarda però solo le persone fisiche ed esclude i beni usati esclusivamente a fini professionali e i dati professionali.
Marketing e comunicazione: chi dichiara che cosa
Il marketing riceve immagini e video dalle agenzie e pubblica documentazione che altri sistemi di IA leggono e rielaborano. Sono due problemi diversi.
Per le immagini la regola è chiara: chi usa un sistema di IA per generare o manipolare immagini, audio o video che costituiscono un deep fake deve dichiararlo dal 2 agosto 2026. Il deep fake non riguarda solo i volti: è il contenuto che assomiglia a persone, oggetti, luoghi, entità o eventi esistenti e apparirebbe falsamente autentico.
La revisione umana esonera solo i testi pubblicati per informare su questioni di interesse pubblico, mai immagini e video. Rispetto a quanto scritto nel #84, il rinvio al 2 dicembre 2026 riguarda solo la marcatura tecnica dei sistemi generativi già sul mercato, non questo obbligo.
Per la pubblicità, le linee guida non vincolanti della Commissione sull’art. 50, pubblicate il 20 luglio 2026, adottano un criterio oggettivo. L’immagine realistica di un prodotto che può fuorviare sull’aspetto o sulla qualità è un deep fake; il prodotto reale su uno sfondo generato che non inganna, di norma no; il regime attenuato per le opere creative opera raramente nei contenuti commerciali.
L’obbligo grava sull’agenzia che usa lo strumento, ma a pubblicare è l’impresa: il contratto deve prevedere la dichiarazione dell’uso di IA per ogni consegna, un’etichetta pronta per la pubblicazione, una garanzia sui diritti e una manleva. Sui diritti conviene ricordare che la legge 132/2025 riconosce il diritto d’autore sull’opera creata con l’ausilio dell’IA solo se è il risultato del lavoro intellettuale dell’autore.
Per la documentazione, la domanda era se l’impresa risponda quando un chatbot interpreta male i suoi manuali e ne deriva un danno.
Se l’assistente è dell’impresa (sul sito, nell’app, nel prodotto), ne risponde l’impresa. Se è di terzi, la sola citazione tra le fonti non basta a fondare una responsabilità, salvo che il documento sia esso stesso errato, ambiguo o privo delle avvertenze necessarie. Manca ancora giurisprudenza e questa è la lettura che ritengo più solida. La difesa è redazionale: avvertenze esplicite, manuali versionati con data e codice prodotto, documenti strutturati e leggibili anche dalle macchine.
Sistemi informativi e personale: l’agente fatto in casa
Un dipendente crea un agente fuori dai sistemi aziendali e gli dà accesso a dati di vendita, listini o documentazione brevettuale. L’impresa può tutelarsi, a condizione che le regole esistano prima.
Sul piano disciplinare il dipendente deve diligenza e fedeltà (artt. 2104 e 2105 c.c.), ma la sanzione richiede un codice disciplinare portato a conoscenza dei lavoratori.
Una policy sull’IA richiamata in quel codice, con l’elenco degli strumenti ammessi e il divieto di collegare dati aziendali a servizi non autorizzati, rende la condotta contestabile.
Sul piano dei controlli, i dati raccolti dagli strumenti di lavoro sono utilizzabili solo se il lavoratore è stato adeguatamente informato, nel rispetto del GDPR (art. 4, commi 2 e 3, dello Statuto). Se l’agente ha toccato dati personali si valutano la violazione e l’eventuale notifica (artt. 33 e 34 GDPR).
La prevenzione costa meno della reazione: un elenco degli strumenti approvati con un canale rapido per chiederne di nuovi, il blocco delle autorizzazioni verso servizi esterni non approvati, la formazione.
Una mappa da fare prima di scegliere gli strumenti
Il metodo suggeribile funziona anche in un ambiente lavorativo ridotto:
- elencare gli usi dell’IA reparto per reparto, compresi quelli dei fornitori che lavorano con le vostre informazioni;
- per ogni uso, chiedersi in che veste agisce l’organizzazione: utilizzatore, fornitore, titolare del trattamento, fabbricante;
- per ogni uso, individuare la norma che lo governa davvero, che spesso non è l’AI Act;
- tradurre il risultato in clausole contrattuali e in una policy interna, prima di acquistare strumenti nuovi.
In aula ho chiuso osservando che, in ogni risposta, la domanda giusta era stata la stessa: in che veste agisce l’impresa, qui e ora. Per l’IA la domanda va ripetuta reparto per reparto, perché la veste cambia ogni volta.
Per chi ha in carico i sistemi
Negli assistenti con ricerca documentale l’indice deve ereditare i permessi dei documenti di origine; basi vettoriali, embedding e cronologie delle conversazioni vanno incluse nelle procedure di conservazione e cancellazione. Contro gli strumenti non autorizzati servono un inventario delle chiavi API e degli account aperti sui servizi di IA, il blocco delle autorizzazioni OAuth verso applicazioni non approvate e regole di prevenzione della perdita di dati sui caricamenti. Negli assistenti integrati nei prodotti, oltre alle difese contro la prompt injection (OWASP Top 10 per i modelli linguistici, #69), conviene che il modello proponga e che un componente deterministico esegua solo i comandi presenti in un elenco chiuso; le interazioni registrate possono essere anche dati del prodotto o del servizio correlato ai fini del Data Act. Per i componenti conviene che la distinta base del software comprenda il firmware dei moduli di terzi, oltre alle dipendenze di primo livello che il CRA richiede come minimo. La data di immissione va tracciata per numero di serie, cioè come data della prima fornitura (vendita o consegna al distributore, anche se è una filiale del gruppo) e non come data di installazione: da quella dipende il regime CRA applicabile.
👾 👾 👾
Alla prossima!