Alla scoperta delle norme dedicate all’intelligenza artificiale
LLM in azienda: chi coinvolgere e come non sbagliare
Non c’è azienda, organizzazione o studio professionale che non si chieda se sia possibile, utile o necessario, in questo momento, utilizzare un modello LLM, sia esso Chat GPT, Claude, Gemini o i tanti altri disponibili sul web.
La domanda più comune è: “Ok, ma da dove partiamo?”
La risposta non è semplice, in effetti.
Dovremmo considerare che, al di là di una possibile scelta tecnologica o di prodotto, vi sono implicazioni organizzative, legali e di sicurezza che vanno ben oltre il semplice utilizzo di uno strumento; dovrebbero, quindi, essere attentamente soppesate.
Oggi parliamo proprio di questo: come muoversi concretamente quando si decide di adottare un Large Language Model in azienda, quali precauzioni prendere e, soprattutto, chi deve essere coinvolto fin dal primo momento.
Free vs Enterprise: non è solo una questione di prezzo
Sembra una banalità, ma ancora oggi molte persone non percepiscono la differenza tra versioni “free” e versioni a pagamento, siano applicativi tradizionali o più “moderni”, come i modelli di linguaggio naturale.
Ricordiamoci, allora, di un vecchio adagio: “se una cosa è gratis, allora il prodotto sei tu.”
La differenza non è solo economica, ma ha notevoli implicazioni, soprattutto in tema di protezione dei dati.
Quando utilizziamo le versioni gratuite o standard dei principali LLM dobbiamo essere consapevoli che, nella maggior parte dei casi, i nostri input (i prompt e, soprattutto, gli allegati) potrebbero essere utilizzati per addestrare i modelli. “Mettere dati in un applicativo”, il più delle volte, ce ne fa perdere il controllo. Volenti o nolenti.
Questo significa che informazioni aziendali, dati di clienti, strategie commerciali e molto altro potrebbero finire nei dataset di training e, potenzialmente, riemergere nelle risposte fornite ad altri utenti.
Potrebbe non essere così, ma il punto è proprio questo: con le versioni gratis non abbiamo e non possiamo contare su garanzie contrattuali o indicazioni precise su cosa succeda ai dati e alle informazioni che “regaliamo” a questi applicativi.
Al contrario le versioni a pagamento, in genere, offrono garanzie e impegni sul non utilizzo dei dati per il training, accordi e obbligazioni relative al trattamento dei dati (DPA), maggiori controlli sulla sulla sicurezza, sulla localizzazione dei server, funzionalità di amministrazione e controllo e, in taluni casi, possibilità di audit e/o di supporto dedicato, oltre che SLA definiti.
Questo non significa che un’organizzazione debba sempre vietare le versioni free, ma va compreso e fatto comprendere a tutti che non possono e non devono, o non dovrebbero, essere utilizzate con gli stessi dati e per le stesse finalità delle versioni a pagamento.
La scelta deve essere consapevole e il consiglio che gli esperti danno è quello di documentarla ma, soprattutto, di inserirla nelle policy e nelle indicazioni operative e, non per ultimo, di comunicarla efficacemente.
Un esperto: non un optional, una necessità
Come sempre un esperto nel dominio specifico non dovrebbe essere un “ospite di cortesia”, un invitato all’ultimo momento per validare decisioni già prese.
In questi casi il settore o la persona che si occupa delle questioni di compliance, di privacy o, se presente, il DPO, deve essere coinvolto fin dalle fasi iniziali, quando ancora si sta valutando quale soluzione adottare.
Perché? Perché l’esperto deve:
- comprendere il ciclo di vita del sistema o del modello che si vuole implementare: non va coinvolto solo per comunicargli l’utilizzo finale
- valutare se esistono, come quasi sempre, problematiche relative a privacy, regolamentazioni, diritti di proprietà industriale, possibili fuoriuscite di documenti riservati o sensibili e, quindi, alternative meno pericolose per raggiungere lo stesso obiettivo
- se del caso verificare che la base giuridica per il trattamento dei dati, perché gli obiettivi e i desideri dell’azienda non sono sempre e indiscutibilmente perseguibili
- aiutare l’azienda a comprendere se il modello o il sistema sia o meno tra quelli considerati a rischio dal Regolamento sull’intelligenza artificiale e, in tal caso, a quale categoria (per approfondimenti si veda qui)
- coordinare o, in ogni caso, fornire consulenza per la DPIA
- esaminare gli accordi con i fornitori, per verificare non solo che il rapporto sia regolato anche da un’apposita sezione che riguardi il trattamento dei dati (il d.c. DPA), ma analizzi anche cosa preveda concretamente in termini di trattamenti, finalità, tipologie di dati, sub fornitori, tempistiche di comunicazione di eventuali incidenti, trasferimenti internazionali e così via.
Se, per esempio, l’azienda decide di utilizzare un LLM per automatizzare le risposte del customer care, un esperto può valutare e, quindi, suggerire, quali dati dei clienti trattare, con quale base giuridica, se sia necessaria un’informativa specifica, come gestire eventuali richieste di cancellazione o opposizione e così via.
Qualcuno che se ne occupi, per davvero
L’implementazione di sistemi AI generativi non ha, e non dovrebbe avere, un approccio individuale. Serve un approccio di squadra, con competenze diverse che dialoghino fin dall’inizio. La costituzione di un gruppo di lavoro dedicato è più di una buona pratica: è una necessità organizzativa.
Chi dovrebbe farne parte? Qualcuno che sia realmente esperto di protezione dati; l’ufficio legale per valutare gli aspetti contrattuali, di proprietà intellettuale, di responsabilità; il dipartimento IT ovviamente, che deve garantire l’integrazione tecnica, la sicurezza, il monitoraggio degli accessi; i responsabili delle funzioni di business che utilizzeranno effettivamente il sistema, perché sono loro che conoscono i casi d’uso reali e le esigenze operative e, se il modello impatterà su processi che coinvolgono i dipendenti, il referente HR.
Questo gruppo di persone non dovrebbe essere visto, né operare, come un “carrozzone burocratico” che rallenta tutto, ma come un gruppo operativo che si riunisce regolarmente, con un mandato chiaro e capacità decisionali efficaci.
Prima di partire
Arriviamo al pratico. Cosa dovrebbe fare un’azienda prima di attivare un account enterprise di un LLM?
Mappatura della situazione di partenza: prima di introdurre ufficialmente un LLM, bisogna capire se già qualcuno in azienda lo stia usando “di nascosto”. La shadow AI è un fenomeno diffuso: dipendenti che utilizzano ChatGPT o altri strumenti con account personali per velocizzare il lavoro, spesso inconsapevoli dei rischi, sono tutt’altro che una rarità.
Definire chiaramente le finalità: per cosa sarà utilizzato il modello? E’ bene specificare i casi d’uso concreti (assistenza nella redazione di documenti, analisi di contratti, supporto al customer, generazione di contenuti marketing, ecc.): ogni obiettivo ha implicazioni diverse in termini di dati trattati, di rischi, di misure di sicurezza necessarie.
Selezionare il fornitore e negoziare, se possibile, l’accordo: come abbiamo accennato sopra, sono diverse le questioni da tenere presente.
Se il sistema o il modello comporta un alto rischio per i diritti e le libertà delle persone, una DPIA è imprescindibile. Peraltro, anche quando non strettamente obbligatoria, sarebbe molto meglio farla comunque. Perché? Perché impone all’azienda di ragionare sistematicamente su tutti gli aspetti rilevanti: quali dati saranno trattati, perché, con quali rischi, quali misure di mitigazione adottare. È uno strumento di governance prima ancora che un adempimento.
Una volta scelto il sistema e definiti i casi d’uso, servono regole chiare su cosa si può fare e cosa no.
Una Policy relativa al corretto utilizzo, per esempio, potrebbe e dovrebbe stabilire:
- quali dati possono essere inseriti nel sistema e quali no (ad es. no dati sensibili, no informazioni coperte da NDA, no dati relativi agli economics, ecc.)
- come devono essere verificati gli output del sistema prima di utilizzarli esternamente
- chi può accedere al sistema e con quali ruoli
- come segnalare problemi o incidenti
- quali attività sono vietate (come ad esempio le decisioni automatizzate senza supervisione umana).
Non per ultimo, formare le persone. Serve spiegare come usare questi strumenti in modo corretto, quali sono i rischi, cosa fare e non fare. L’AI literacy, di cui abbiamo parlato nelle scorse settimane, parte proprio da qui.
Infine, bisogna monitorare continuamente come viene effettivamente utilizzato il sistema, se emergono problemi o criticità, se le politiche vengono rispettate, se i contratti con i fornitori sono ancora adeguati o necessitano revisione, se cambiano le normative di riferimento.
La leadership
Concludiamo con un aspetto che troppo spesso viene trascurato: l’esempio deve venire dall’alto. Se la direzione decide di implementare un LLM, ma poi il CEO continua a usare ChatGPT free dal suo account personale per rivedere documenti aziendali sensibili, quale messaggio passa ai dipendenti? La compliance non può essere solo “per gli altri”. Se chiediamo ai dipendenti di seguire determinate regole, la leadership deve essere la prima a rispettarle. Altrimenti ogni policy, ogni formazione, ogni controllo diventa inutile.
Quindi 🙂
Adottare un LLM in azienda non è solo una questione tecnologica, è una decisione organizzativa che richiede competenze multidisciplinari e un approccio strutturato.
Le differenze tra versioni free ed enterprise sono sostanziali e vanno comprese prima di fare scelte affrettate.
Un esperto non è un ostacolo burocratico, ma una risorsa importante per navigare la complessità normativa e garantire che l’innovazione tecnologica non comporti rischi inaccettabili per dati e diritti delle persone.
Un gruppo di lavoro dedicato non è un lusso per grandi aziende, ma una necessità per chiunque voglia implementare AI in modo responsabile.
Le regole servono non per rallentare l’innovazione, ma per renderla sostenibile e sicura nel lungo periodo.
Images: @Pixabay
👾 👾 👾
Alla prossima settimana!
👾