Le linee guida per l’introduzione dell’Intelligenza Artificiale (IA) nella Pubblica Amministrazione (PA), elaborate dall’Agenzia per l’Italia Digitale, delle quali si è in attesa del rilascio definitivo, a fronte della consultazione pubblica dello scorso anno, promuovono un’adozione etica e progressiva.
Come noto si basano su 20 principi vincolanti che regolano lo sviluppo, la governance, il procurement e la gestione del ciclo di vita dei sistemi di IA e si dividono tra Linee guida per l’adozione, Linee guida per lo sviluppo e Linee guida per il procurement, che in particolare disciplinano le modalità di acquisizione e la gestione contrattuale dei software e dei servizi di IA
Indice degli argomenti
I costi della IA nella PA oltre il prezzo immediato
Quando una pubblica amministrazione valuta l’adozione di un sistema di Intelligenza Artificiale, uno delle questioni su cui deve interrogarsi è quella dei costi che deve affrontare, tematica nella quale il primo errore che rischia di commettere è guardare solo al prezzo immediato del sistema che intende acquistare.
In realtà il costo del sistema per singola chiamata o per singola operazione racconta solo una piccola parte della storia e può rivelarsi pericolosamente ingannevole.
Le nuove Linee Guida introducono a questo proposito una metrica innovativa, mutuata dal settore energetico: il LCOAI, ovvero il Levelized Cost of Artificial Intelligence.
L’idea è semplice ma efficace: invece di chiedersi quanto costa una singola operazione, si calcola quanto costa l’intero sistema nell’arco della sua vita utile, rapportato ai servizi realmente erogati.
Questo calcolo, per essere onesto, deve tenere conto di quattro voci di spesa che troppo spesso vengono dimenticate.
La prima sono i costi di avvio, cioè l’acquisto delle infrastrutture, la configurazione iniziale e l’addestramento del sistema.
La seconda voce riguarda i costi operativi ricorrenti: cloud, energia, aggiornamenti, controlli di sicurezza.
Ed è proprio qui che entra in gioco una figura spesso sottovalutata nella fase di pianificazione economica dell’innovazione dei sistemi nella PA: il Data Protection Officer (DPO) o responsabile della Protezione dei Dati personali.
Il DPO non è un osservatore esterno di quanto accade, ma è chiamato a verificare che i costi legati alla protezione dei dati, dalla valutazione d’impatto sulla privacy alle misure di sicurezza richieste dal GDPR, compresa la formazione dei soggetti autorizzati a trattare i dati personali, siano correttamente inclusi nel budget.
Un piano economico che ignora questi oneri è semplicemente incompleto e potrebbe costare all’ente molto di più in sanzioni di quanto abbia risparmiato in fase di acquisto.
La terza voce, spesso la più trascurata, riguarda i costi di uscita: quanto costa, a fine contratto, portare i propri dati altrove senza restare prigionieri del fornitore.
È un aspetto cruciale per la sovranità tecnologica dell’ente.
Infine ci sono i costi organizzativi, che rappresentano la vera sorpresa per molte amministrazioni, perché può sfuggire l’effettiva rilevanza di investire nella formazione del personale, nella riorganizzazione dei processi interni e nella costruzione di una governance solida, tutte attività necessarie alla gestione adeguata e sicura dell’innovazione.
La Legge 132/2025, a ben vedere, li riconosce espressamente come costi strutturali obbligatori, non come optional.
E sottovalutarli significa prepararsi nella maggior parte dei casi a brutte sorprese.
Procurement IA nella Pubblica Amministrazione e strumenti contrattuali
Chiarito il tema dei costi che la PA deve affrontare per l’introduzione della IA nei suoi processi operativi, occorre chiarire un malinteso molto diffuso: comprare un sistema di Intelligenza Artificiale non è come comprare un qualsiasi strumento, come ad esempio una fotocopiatrice.
L’amministrazione deve rendersi conto che introdurre un sistema IA comporta un importante cambiamento di approccio e di processo, perché non è un prodotto statico che si acquista, si installa e si dimentica, perché è a ben vedere un organismo vivo che evolve, cambia e si aggiorna continuamente, motivo per cui acquistarlo richiede strumenti contrattuali flessibili, pensati per il lungo periodo.
Le Linee Guida descrivono a questo proposito un ventaglio di opzioni che in sostanza ci fanno affermare che quando il bisogno è chiaro e il mercato offre soluzioni consolidate, si possono usare le normali procedure di gara.
Quando invece l’amministrazione è incerta su cosa le serva davvero, è meglio ricorrere al dialogo competitivo o alla procedura competitiva con negoziazione, strumenti che favoriscono un confronto strutturato con i fornitori prima ancora di definire l’architettura del progetto.
Questo perché se la soluzione desiderata di IA non esiste ancora sul mercato, allora si può aprire la strada del partenariato per l’innovazione, una sorta di co-sviluppo tra pubblica amministrazione e imprese private.
Ma lo strumento di acquisizione di sistemi di IA che tra quelli disponibili per legge meglio si adatta alla natura evolutiva dell’IA è l’accordo quadro, perché fissa prezzi e livelli di servizio in anticipo lasciando all’ente la flessibilità di attivare i contratti nel momento più opportuno.
Le Linee Guida suggeriscono inoltre un cambio di prospettiva organizzativo importante, prevedendo che siano Regioni e Centrali di Committenza ad acquistare servizi IA su larga scala per poi distribuirli ai singoli enti.
I vantaggi di tale approccio sono concreti e immediati, perché in tal modo le amministrazioni possono dividersi i costi, e si rafforza il potere contrattuale delle PPAA verso i grandi fornitori tecnologici, consentendo così anche alle piccole amministrazioni di accedere a competenze specialistiche che le ridotte dimensioni, pensiamo ad esempio ad un piccolo Comune, non potrebbero mai permettersi da sole.
DPO nell’adozione della IA nella PA e Data Processing Agreement
In tutto questo processo è evidente che ogni caso, le amministrazioni, qualsiasi sia il tipo di contratto che stipulino per l’introduzione dei sistemi di IA, se questi sono destinati a trattare dati personali, devono responsabilizzare, per legge, il fornitore designandolo Responsabile del trattamento dei dati personali, attraverso un apposito accordo o atto di designazione, il cosiddetto Data Processing Agreement previsto dall’articolo 28 del Regolamento Ue 2016/679.
Spetta al DPO non solo verificare che questo accordo esista, ma aiutare l’ente nel definirne attentamente i contenuti, al fine di individuare chiaramente le responsabilità del fornitore e il mandato a questi conferito, garantendo all’ente il pieno controllo sui dati dei quali è Titolare del trattamento.
In tal contesto è essenziale che l’amministrazione metta a disposizione del DPO le informazioni necessarie per la adeguata “modellazione” dell’atto di nomina a Responsabile alle prescrizioni dell’articolo 28 succitato.
Se il fornitore è extraeuropeo, come spesso accade con i grandi player tecnologici, occorre anche accertarsi che i dati non finiscano in Paesi privi di adeguate garanzie di protezione.
Qualificazione ACN e IA generativa nella PA
A questo punto si incontra quello che le Linee Guida definiscono il nodo più spinoso dal punto di vista operativo: la qualificazione ACN.
I servizi cloud destinati alla Pubblica Amministrazione devono essere, come noto, iscritti nel catalogo dell’Agenzia per la Cybersicurezza Nazionale per garantire la sovranità del dato.
Il paradosso è evidente e molti dipendenti pubblici lo vivono ogni giorno sulla propria pelle, visto che la maggior parte degli strumenti di IA generativa più diffusi e apprezzati, come ChatGPT o Claude nella loro versione consumer, non possiede questa qualificazione.
Non perché siano strumenti poco affidabili, ma semplicemente perché non sono stati progettati per un uso istituzionale da parte delle pubbliche amministrazioni e soprattutto per un utilizzo da parte di queste di dati personali o addirittura dei dati appartenenti alle categorie particolari (ex dati sensibili) di cui all’articolo 9 del Regolamento UE 2016/679.
Per uscire da questo impasse le Linee Guida propongono tre strade percorribili.
La prima prevede di usare un’infrastruttura già certificata ACN e di richiamare i motori di IA esclusivamente tramite API protette, in modo che i dati non escano mai verso server pubblici.
Questa è senza alcun dubbio la soluzione più sicura, ma richiede competenze tecniche interne che non tutti gli enti possiedono.
La seconda strada porta invece alle piattaforme cloud qualificate, come quelle offerte dal Polo Strategico Nazionale, dove le garanzie di sicurezza, backup e segregazione dei dati sono già incorporate nella certificazione della piattaforma, in quanto la sicurezza, in questo caso, è inclusa nel pacchetto.
La terza opzione disponibile è quella più pratica per i Comuni e per le piccole amministrazioni prive di un team tecnico interno, ed è quella di acquistare un’applicazione software già certificata ACN che integra l’IA generativa al proprio interno, scaricando sul fornitore l’intero onere della compliance normativa, AI Act e regole ACN incluse.
In realtà questa terza alternativa deve però essere valutata con estrema attenzione dall’amministrazione nella sua veste di titolare del trattamento, in quanto, per ciò che riguarda le attività di trattamento dei dati personali che sono previste dalla soluzione di IA adottata, queste sono di piena responsabilità dell’ente, che potrebbe comunque successivamente rispondere a pieno titolo di un trattamento di dati svolto in violazione dei diritti degli interessati.
Quindi per l’ente è comunque necessario ma soprattutto strategico, opportuno e prudente una valutazione da parte del proprio DPO sull’adeguatezza delle misure di sicurezza tecnica ed organizzative che la soluzione individuata prevede, da farsi prima di deciderne l’utilizzo.
Privacy by design, privacy by default e valutazione del rischio
Ciò in quanto il titolare risponde in ogni caso del mancato rispetto dei principi di “privacy by design” e “privacy by default” individuati dall’articolo 25 del Regolamento Ue 2016/679, anche in relazione al trattamento di dati personali svolto attraverso l’utilizzo di prodotti già predisposti dal fornitore e da questo messi a disposizione degli enti.
Il primo di tali principi, privacy by design, di cui al paragrafo 1 del suindicato articolo 25 dispone infatti che il titolare del trattamento metta in atto misure tecniche e organizzative adeguate volte ad attuare in modo efficace i principi di protezione dei dati, di cui al precedente articolo 5, e a integrare nel trattamento le necessarie garanzie al fine di soddisfare i requisiti del Regolamento stesso e tutelare i diritti degli interessati.
Il secondo principio, quello di privacy by default, invece dispone al paragrafo 2 che il titolare del trattamento metta in atto misure tecniche e organizzative adeguate per garantire che siano trattati, per impostazione predefinita, solo i dati personali necessari per ogni specifica finalità del trattamento, relativamente alla quantità dei dati personali raccolti, alla portata del trattamento, al periodo di conservazione all’accessibilità.
Nell’applicare tali principi, inoltre, il titolare deve tener conto di una serie di elementi oggettivi, tra i quali è essenziale la valutazione del rischio per i diritti e le libertà delle persone fisiche costituiti dal trattamento dei loro dati con sistemi di intelligenza artificiale, valutazione che deve essere fatta sia al momento di determinare i mezzi del trattamento sia all’atto del trattamento stesso.
Quindi si può affermare che l’apporto consulenziale del DPO in una fase preliminare rispetto alla stipula di qualsiasi contratto per la messa a disposizione di un sistema di IA nella pubblica amministrazione qualora il sistema debba trattare dati personali è da ritenersi doveroso e pienamente conforme al disposto delle lettere a) e b) del primo paragrafo dell’articolo 39 del Regolamento UE 2016/679, che individua i compiti del Responsabile della Protezione dei Dati.
Il divieto di usare strumenti IA non qualificati con dati personali
Detto ciò è da evidenziare che nel frattempo, ed in attesa che le soluzioni di intelligenza artificiale siano pienamente adottate da parte delle pubbliche amministrazioni, vige una regola transitoria categorica per tutti gli operatori che non ammette deroghe: è infatti assolutamente vietato loro di inserire dati personali, o dati appartenenti alle categorie particolari o informazioni comunque sensibili o documenti riservati in qualsiasi strumento di IA generativa non qualificato, anche se si tratta di un semplice test organizzativo.
Ogni diverso comportamento dell’operatore della pubblica amministrazione costituisce una violazione del “Codice di comportamento dei dipendenti pubblici” di cui al Decreto del Presidente della Repubblica n. 62 del 16 aprile 2013, violazione che comporta l’applicabilità delle relative sanzioni disciplinari.
Il DPO ha un ruolo centrale anche in tale contesto, perché deve supportare l’amministrazione, mappando gli strumenti già in uso nell’ente, autorizzati o meno, e predisponendo indicazioni operative chiare per il personale, e verificare che il divieto sia effettivamente comunicato e rispettato.
Principi etici e tecnici per l’intelligenza artificiale pubblica
Al di là delle questioni di procurement e qualificazione, le Linee Guida definiscono anche i principi etici e tecnici che devono guidare lo sviluppo di qualsiasi sistema IA nella PA.
Il quadro normativo di riferimento è solido e articolato: l’AI Act europeo, il Regolamento UE 2016/679, la Legge 132/2025 e il Codice dell’Amministrazione Digitale.
Da questo impianto discendono venti principi cardine che attraversano l’intero ciclo di vita del sistema di IA, dalla progettazione fino al ritiro definitivo.
Il primo gruppo di principi riguarda il rispetto dei diritti fondamentali e il divieto di discriminazione.
Ogni sistema di intelligenza artificiale deve nascere nel rispetto delle libertà individuali, con due valutazioni d’impatto preventive obbligatorie: la DPIA, prevista dall’articolo 35 del Regolamento UE 2016/679 per valutare i rischi sulla privacy e la FRIA, individuata dall’AI Act o Regolamento UE 2024/1689 nell’articolo 27, che stabilisce l’obbligo di redigere la Fundamental Rights Impact Assessment o FRIA per i sistemi di IA ad alto rischio per i rischi più ampi sui diritti fondamentali, come il rischio di discriminazione o di lesione della dignità delle persone.
Il secondo gruppo dei principi cardine affronta la qualità dei dati e la trasparenza dei processi.
I dati usati per addestrare il sistema di intelligenza artificiale devono essere accurati, tracciabili e verificabili.
E questo è un obbligo esplicito e generale dell’AI Act, che dispone che chiunque interagisca con un sistema di IA deve essere chiaramente informato che sta dialogando con una macchina, non con un essere umano.
Il terzo gruppo di principi cardine mette l’uomo al centro.
Nei processi decisionali deve infatti sempre essere presente un intervento umano significativo: la macchina può suggerire, analizzare e preparare, ma non può decidere da sola, soprattutto quando la decisione produce effetti nella vita di un cittadino.
Human-in-the-Loop, decisioni automatizzate e ruolo del DPO
Ed è qui che il DPO torna ancora una volta protagonista nel contesto dell’applicazione dell’intelligenza artificiale nella pubblica amministrazione.
L’articolo 22 del Regolamento UE 2016/679 vieta a tal proposito espressamente di prendere decisioni automatizzate che producano effetti giuridici su una persona senza un controllo umano reale, disponendo al primo paragrafo che “1. L’interessato ha il diritto di non essere sottoposto a una decisione basata unicamente sul trattamento automatizzato, compresa la profilazione, che produca effetti giuridici che lo riguardano o che incida in modo analogo significativamente sulla sua persona”.
Ogni volta che un sistema IA “decide” qualcosa su un cittadino, anche solo in via preliminare, il DPO deve pertanto assicurarsi che ci sia sempre un funzionario che riveda e convalidi quella decisione in modo sostanziale, non solo formale.
Gli ultimi due gruppi di principi cardine riguardano la cybersicurezza, che deve essere costruita ed assicurata fin dall’inizio, non aggiunta a posteriori, e l’accessibilità universale, che impone interfacce usabili da tutti i cittadini, incluse le persone con disabilità.
Stack IA e architettura dei sistemi nella PA
Sul piano tecnico, le Linee Guida prescrivono comunque anche l’architettura che ogni sistema IA della PA dovrebbe adottare.
Si tratta di uno Stack IA, un insieme integrato di tecnologie, framework e strumenti software che collaborano per sviluppare, addestrare, gestire e distribuire applicazioni di Intelligenza Artificiale, che, proprio come una serie ordinata di elementi, organizza le tecnologie in livelli interconnessi, suddividendo compiti complessi in parti più gestibili strutturato su cinque livelli sovrapposti, pensato per essere modulare, scalabile e governabile nel tempo.
Alla base dello Stack IA si trova il livello energetico, che comprende server, consumo elettrico e sistemi di raffreddamento, un aspetto che spesso viene ignorato o sottovalutato, ma che le Linee Guida impongono di stimare fin dalla progettazione, dato l’impatto ambientale significativo dei sistemi IA.
Sopra si collocano il livello computazionale, con il GPU, l’unità di elaborazione grafica, il processore specializzato nei dispositivi informatici progettato per eseguire calcoli matematici complessi in parallelo, e i processori specializzati, e il livello infrastrutturale, che gestisce reti, storage e cloud ed è il più critico dal punto di vista della protezione dei dati, visto che è qui infatti che i dati dei cittadini vengono archiviati, trasmessi e protetti.
Il quarto livello ospita i modelli IA veri e propri, dal machine learning all’IA generativa.
Il quinto livello, infine, è quello applicativo: chatbot, sportelli digitali, dashboard, cioè tutto ciò che il cittadino vede e con cui interagisce direttamente.
La regola d’oro che attraversa tutti e cinque i livelli è la neutralità hardware: ogni componente deve essere progettata per essere intercambiabile, in modo che l’ente possa cambiare fornitore senza dover ricostruire tutto da zero.
Questa libertà è essenziale, non è solo una questione economica, ma anche una garanzia di sovranità del dato.
Un ente che può cambiare fornitore in qualsiasi momento non è mai completamente alla mercé di chi gestisce i suoi dati.
Profili operativi degli enti e responsabilità privacy
Le Linee Guida riconoscono che non tutte le amministrazioni partono dallo stesso punto e classificano gli enti in quattro profili operativi.
- L’Operatore Base, il profilo più diffuso ad esempio tra i Comuni, utilizza soluzioni di intelligenza artificiale già pronte all’uso senza personalizzarle, affidando meramente tutta la relativa gestione tecnica al fornitore.
- L’Operatore Avanzato, profilo tipico delle Regioni o degli enti pubblici di medie dimensioni, modifica e personalizza i sistemi esistenti usando i propri dati, assumendosi anche la responsabilità di valutarne il relativo impatto energetico.
- L’Operatore Esperto costruisce modelli da zero e mette la propria infrastruttura a disposizione di altri enti, agendo come un vero e proprio polo tecnologico territoriale.
- L’Operatore Controllore, profilo riservato ad amministrazioni con funzioni strategiche nazionali, deve avere il controllo completo dell’intera filiera tecnologica, senza dipendere da alcun fornitore privato per le funzioni critiche.
La distinzione delle amministrazioni nei diversi profili operativi non è, a ben vedere, solo una classificazione tecnica, perché determina direttamente anche la profondità e la complessità delle responsabilità e dell’apporto all’amministrazione del DPO.
Un Operatore Base che affida tutto al fornitore deve assicurarsi che il contratto includa tutte le garanzie previste dal Regolamento UE 2016/679.
Un Operatore Avanzato che usa dati dei quali è titolare anche per addestrare il modello di intelligenza artificiale deve verificare anche che quei dati siano stati raccolti e successivamente trattati con una base giuridica appropriata.
In sintesi, più l’ente pubblico è autonomo tecnologicamente, più il DPO deve essere coinvolto in profondità nelle scelte progettuali, più impegno nel suo supporto in termini di risorse è bene che l’ente assicuri, così come indicato dal paragrafo 2 dell’articolo 38 del più volte citato Regolamento, che dispone: “2. Il titolare e del trattamento e il responsabile del trattamento sostengono il responsabile della protezione dei dati nell’esecuzione dei compiti di cui all’articolo 39 fornendogli le risorse necessarie per assolvere tali compiti e accedere ai dati personali e ai trattamenti e per mantenere la propria conoscenza specialistica”.
Agenti autonomi e supervisione umana continua
Uno degli scenari più delicati che le Linee Guida affrontano riguarda poi i cosiddetti agenti autonomi, cioè i sistemi di intelligenza artificiale che non si limitano a rispondere a domande, ma pianificano e compiono sequenze di azioni in autonomia.
Le Linee Guida classificano questo tipo di autonomia su una scala da zero a cinque, ma raccomandano con forza di non superare mai i livelli intermedi senza una supervisione umana robusta e continua.
Il principio Human-in-the-Loop, il modello di interazione uomo-macchina in cui un essere umano è parte integrante del processo operativo o decisionale di un sistema automatizzato o di Intelligenza Artificiale, dove la macchina assiste svolgendo calcoli, ma l’uomo interviene per correggere, approvare o rifiutare il risultato, non è una buona prassi opzionale, ma è quindi un obbligo normativo inderogabile, sancito sia dalla Legge 132/2025 sia dall’AI Act, ma anche dal citato articolo 22 del Regolamento UE 2016/679.
Anche quando un agente può redigere in autonomia una delibera o predisporre un mandato di pagamento, l’autorizzazione finale deve quindi restare una prerogativa esclusivamente umana.
Il DPO deve vigilare che questo presidio non sia solo formale, e che quindi il funzionario che clicca “approvi” senza leggere il risultato dell’elaborazione, ma sia sostanziale, che quindi questi sia una persona che comprende il processo, ne valuta l’output e se ne assume la responsabilità.
L’amministrazione, titolare del trattamento deve essere a tal proposito garante del fatto che i cittadini siano informati dettagliatamente quando una decisione che li riguarda è stata assistita da un sistema automatizzato, e che possano richiedere una revisione umana.
Sicurezza informatica, prompt injection e tutela dei dati
Sul fronte della sicurezza informatica, le Linee Guida segnalano un salto di paradigma che molti addetti ai lavori faticano ancora ad assimilare.
I sistemi tradizionali di difesa informatica sono stati progettati per proteggere software deterministici, dove a un dato input corrisponde sempre lo stesso output prevedibile.
I sistemi di IA sono invece non deterministici: lo stesso input può produrre output diversi, e il sistema può essere manipolato attraverso istruzioni nascoste nel testo che elabora, il cosiddetto prompt injection, una delle nuove frontiere dell’attacco informatico contro le PA.
Per affrontare questa inedita superficie d’attacco, le Linee Guida adottano il NIST AI Risk Management Framework e la tassonomia ENISA, costruendo un sistema di difesa specifico per l’IA fondato su due pilastri.
Il primo pilastro è il Principio del Privilegio Minimo: ogni agente IA deve operare con i soli permessi strettamente necessari al suo compito.
A ben vedere tale richiamato principio è comunque e sempre in piena linea con i principi di privacy by design e privacy by default, ma soprattutto del principio di minimizzazione di cui agli articoli 5 e 25 del Regolamento Ue 2016/679.
Un sistema che gestisce le pratiche di un ufficio non ha, ad esempio, alcun motivo per accedere ai dati fiscali dei dipendenti.
Il secondo pilastro è il presidio Human-in-the-Loop già descritto: nessuna azione critica, come ad esempio pagamenti, atti ufficiali, decisioni su persone, può essere eseguita senza autorizzazione umana esplicita, così come dice anche l’articolo 22 surrichiamato.
In questo scenario il DPO deve lavorare in stretta collaborazione con il CISO, il responsabile della sicurezza informatica dell’ente.
Le minacce alla sicurezza sono quasi sempre anche minacce alla privacy, perché un attacco che manipola un sistema di Intelligenza Artificiale può portare a trattamenti illeciti di dati personali, a decisioni discriminatorie o alla divulgazione di informazioni riservate.
La sicurezza e la protezione dei dati non sono, ed è del tutto evidente, due ambiti separati, ma sono due facce della stessa medaglia.
La responsabilità finale resta umana
Di fronte alla rapidità con cui i sistemi agentici autonomi si moltiplicano, queste Linee Guida segnano un punto fermo importante, con le quali la Pubblica Amministrazione riafferma il proprio ruolo di garante dei diritti dei cittadini, e lo fa con strumenti concreti, il Principio del Privilegio Minimo e i meccanismi Human-in-the-Loop, che non sono semplici misure di cybersecurity, ma veri e propri presidi democratici.
La macchina può analizzare moli immense di dati, redigere sintesi, preparare istruttorie a velocità inaudite.
Ma la responsabilità della scelta finale, la firma in calce all’atto amministrativo e la tutela dell’interesse pubblico restano, e dovranno per sempre restare, una prerogativa esclusivamente umana, consapevole e giuridicamente rendicontabile.
In questo scenario il DPO non è e non deve essere percepito come una figura di controllo burocratico o un soggetto da tenere a margine e lontano dai processi decisionali relativi all’introduzione dei sistemi di intelligenza artificiale nella pubblica amministrazione.
Il DPO, per le sue specifiche caratteristiche professionali e per le specifiche competenze è uno dei pochi soggetti che, per mandato di legge, possiede una visione trasversale su come i dati dei cittadini debbano essere raccolti, trattati, conservati e usati all’interno dell’ente.
E tali competenze sono veramente preziose e indispensabili in un mondo in cui l’Intelligenza Artificiale è ovunque, questa visione trasversale non è un lusso, ma è una necessità per tutelare le persone e i loro diritti anche nella gestione dell‘innovazione.
Partecipa alla community