3,136 subscribersSubscribed

AI Act e adozione dell’AI in azienda: oltre il marketing, cosa cambia davvero

Antonio Ieranò

Information & Cybersecurity Strategist | Digital Sovereignty • AI Governance • Complex Systems | Author, Researcher & Occasional Philosopher | Views stubbornly my own. 🧠

October 8, 2026

:L’AI Act arriva in un momento in cui le aziende non stanno più valutando l’intelligenza artificiale come una tecnologia sperimentale, ma la stanno incorporando nei sistemi operativi della propria organizzazione. L’AI entra nei SOC, negli strumenti di DLP, nelle piattaforme di data protection, negli ambienti cloud, nei sistemi di ticketing, nelle suite di produttività, nei motori di ricerca interna, nei workflow di data management, nei sistemi HR, nei processi di procurement, nei CRM, nei sistemi di identity governance e negli strumenti di sviluppo software.

Questo cambia il punto di osservazione. Il tema non è più “possiamo usare ChatGPT?” o “il vendor dice di avere un copilota AI?”. La domanda vera è: che cosa significa per un’azienda incorporare componenti AI nei propri sistemi, sotto il profilo normativo, organizzativo, contrattuale, tecnico e di responsabilità?

L’AI Act è una parte della risposta. Non l’unica. Accanto all’AI Act entrano in gioco GDPR, trasferimenti internazionali di dati, Schrems II, SCC, TIA, DPA, misure supplementari, sovranità del cloud, sicurezza contrattuale e sicurezza tecnica. E soprattutto entrano in gioco ruoli aziendali che non possono più lavorare in silos: CISO, DPO, CIO, legal, procurement, risk management, internal audit, data office, HR e vertici aziendali.

1. L’AI Act non regola il marketing dell’AI, regola ruoli, usi e rischi

Il primo errore da evitare è leggere l’AI Act come una normativa “sui prodotti AI” in senso generico. L’AI Act non si interessa tanto a come un vendor descrive la propria soluzione, ma a che cosa fa concretamente il sistema, chi lo mette a disposizione, chi lo usa, con quali dati, con quale livello di autonomia e con quale impatto.

Questo è particolarmente importante perché oggi quasi ogni vendor dichiara di avere funzionalità AI: AI assistant, AI agent, AI SOC analyst, AI copilota, AI-driven DLP, AI-powered data discovery, autonomous response, AI governance, GenAI security, AI threat intelligence, AI for identity, AI for cloud posture management. Ma l’etichetta commerciale non basta a capire il perimetro normativo.

Per l’AI Act contano soprattutto alcune domande:

il sistema è immesso sul mercato europeo?
è usato nell’Unione europea?
l’output prodotto dal sistema è usato nell’UE, anche se il provider è extra-UE?
l’azienda è provider, deployer, importer, distributor o utilizzatore interno?
il sistema rientra in una categoria vietata, high-risk, soggetta a trasparenza, o in un caso a basso rischio?
usa o incorpora un modello general-purpose, come un LLM?
produce contenuti sintetici, raccomandazioni, classificazioni, decisioni o azioni automatiche?
incide su persone fisiche, accessi, lavoro, credito, istruzione, servizi essenziali, sicurezza o diritti fondamentali?

L’ambito dell’AI Act può includere anche operatori stabiliti in paesi terzi quando l’output dell’AI system è usato nell’Unione. Questo è un punto cruciale per i vendor USA e per le architetture cloud globali. AI Act Service Desk, articolo 2

In altre parole: non basta che il sistema giri negli Stati Uniti per sottrarsi automaticamente al perimetro europeo.

2. L’AI Act non è una legge sulla data residency, ma rende visibile il rischio operativo

Un altro equivoco frequente è pensare che l’AI Act imponga, di per sé, che tutti i dati AI restino in Europa. Non è così. L’AI Act non è una normativa di localizzazione dei dati. Il suo impianto è basato sul rischio: alcuni usi sono vietati, alcuni sono ad alto rischio, alcuni richiedono trasparenza, altri restano sostanzialmente liberi ma non per questo privi di responsabilità.

Tuttavia, l’AI Act ha un effetto molto concreto: costringe l’azienda a sapere quali sistemi AI sta usando, per quali finalità, con quali dati, con quale grado di autonomia e con quali controlli.

Questo è già un cambiamento enorme. Molte aziende oggi non hanno un inventario affidabile delle funzionalità AI incorporate nei propri strumenti. L’AI può essere dentro l’EDR, nella piattaforma SIEM, nel motore DLP, nel CASB, nel sistema di data classification, nello strumento di supporto clienti, nel software di collaboration, nella suite HR o nella piattaforma di sviluppo. A volte è visibile come funzione esplicita. A volte è una componente embedded, attivata dal vendor o inclusa in un aggiornamento.

L’AI Act spinge le aziende a passare da una logica di fiducia generica nel vendor a una logica di governance verificabile.

3. Security, DLP e data protection: perché l’AI è ormai inevitabile

La cybersecurity è uno dei campi in cui è più difficile evitare l’AI. Il volume di eventi, log, alert, anomalie, identità, endpoint, flussi cloud, dati SaaS e minacce rende sempre meno sostenibile una gestione puramente manuale.

L’AI viene usata per:

correlare eventi di sicurezza;
classificare alert;
prioritizzare incidenti;
generare query e regole di detection;
sintetizzare evidenze;
riconoscere pattern anomali;
individuare esfiltrazioni;
classificare dati sensibili;
suggerire azioni di remediation;
automatizzare playbook;
supportare threat hunting;
analizzare email sospette;
arricchire incidenti con threat intelligence;
interpretare comportamenti utente o macchina;
gestire posture cloud e identity risk.

Lo stesso vale per DLP, data protection e data management. Le aziende hanno bisogno di strumenti capaci di trovare dati sensibili, capire dove risiedono, classificarli, deduplicarli, applicare retention, identificare esposizioni improprie, riconoscere dati personali in ambienti destrutturati, proteggere dataset e prevenire leakage verso strumenti GenAI.

Il punto, quindi, non è “usare o non usare AI”. Il punto è come incorporarla in modo governato.

4. Il confine delicato: dall’assistenza tecnica alla decisione su persone

Nel contesto security, molti casi d’uso AI possono sembrare tecnici e quindi poco problematici. Ma non sempre lo sono.

Un copilota che aiuta un analista a scrivere una query SIEM ha un profilo di rischio diverso da un sistema che assegna un punteggio di rischio a un dipendente. Un motore che classifica malware è diverso da un sistema che segnala un utente come potenziale insider threat. Un tool che suggerisce una remediation è diverso da un agente che blocca automaticamente account, revoca privilegi, isola dispositivi o apre procedimenti interni.

Il punto critico è quando l’AI produce effetti, anche indiretti, su persone fisiche. Alcuni esempi:

scoring comportamentale dei dipendenti;
classificazione di utenti “rischiosi”;
monitoraggio di comunicazioni interne;
analisi di produttività o condotte lavorative;
blocco automatico di account aziendali;
raccomandazioni che influenzano procedimenti disciplinari;
classificazione di clienti o utenti per rischio frode;
correlazione tra identità, dispositivi, posizione e comportamento;
uso di biometria o dati particolarmente sensibili;
profilazione tramite metadati.

Qui l’azienda deve fare attenzione a non farsi tranquillizzare dalla natura “cyber” dello strumento. Un sistema può nascere per proteggere l’organizzazione ma produrre comunque impatti rilevanti su diritti, libertà, lavoro, reputazione e accesso a servizi.

5. AI Act e GPAI: cosa significa usare LLM e modelli general-purpose

Molte soluzioni enterprise incorporano LLM o modelli general-purpose. A volte il vendor usa un modello proprio. A volte integra modelli di hyperscaler o provider terzi. A volte consente al cliente di scegliere tra più modelli. A volte invia prompt, log, documenti, ticket o metadati a un servizio esterno.

L’AI Act disciplina anche i modelli general-purpose. Gli obblighi per i provider di modelli GPAI sono applicabili dal 2 agosto 2025, con enforcement pieno della Commissione dal 2 agosto 2026; i modelli già sul mercato prima del 2 agosto 2025 hanno tempo fino al 2 agosto 2027 per conformarsi, secondo la Commissione europea. Commissione UE sui GPAI

Per l’azienda cliente, questo non significa che ogni uso di un LLM la renda automaticamente provider di GPAI. Ma significa che nel procurement bisogna chiedere:

quale modello viene usato?
chi è il provider del modello?
dove viene eseguito?
quali dati vengono inviati al modello?
i dati del cliente sono usati per training o fine-tuning?
esiste opt-out dal training?
quali log vengono conservati?
per quanto tempo?
chi può accedervi?
ci sono subprocessor?
in quali paesi?
il modello produce output usati in processi aziendali critici?
l’azienda può spiegare e ricostruire l’uso del sistema?

Queste domande sono particolarmente importanti per AI agent e copiloti. Un “agent” non è solo un chatbot. Può leggere dati, chiamare API, interrogare sistemi, aprire ticket, modificare configurazioni, bloccare utenti, generare codice, aggiornare regole o avviare workflow. L’autonomia dell’agente diventa quindi un elemento centrale della valutazione.

6. Dati personali, dati trasformati, embeddings e metadati

Uno dei punti più sottovalutati riguarda i dati “trasformati”. Molte architetture AI non inviano necessariamente il documento originale al modello, ma trattano embeddings, vettori, metadati, hash, indici semantici, classificazioni, token, chunk, sintesi o rappresentazioni derivate.

Il rischio è pensare che, perché il dato è trasformato, allora non sia più personale. Non è sempre vero.

Il GDPR distingue tra anonimizzazione e pseudonimizzazione. La pseudonimizzazione riduce la collegabilità del dato a una persona, ma non lo fa uscire automaticamente dal GDPR. Solo dati veramente anonimizzati, cioè non più riferibili a una persona identificata o identificabile, escono dall’ambito del GDPR. EDPB su anonimizzazione e pseudonimizzazione

Questo ha conseguenze dirette per AI, security e data management.

Un embedding generato da un documento contenente dati personali può conservare informazioni semanticamente riconducibili al contenuto originale. Un metadato può essere altamente identificativo: user ID, device ID, indirizzo IP, tenant ID, posizione, ruolo aziendale, timestamp, pattern di comportamento. Una sintesi può contenere informazioni personali anche se il documento originale non viene memorizzato. Un indice vettoriale può permettere inferenze o retrieval di contenuti sensibili.

Quindi la domanda corretta non è: “abbiamo trasformato il dato?”. La domanda corretta è: il dato trasformato è ancora ragionevolmente collegabile a una persona, direttamente o indirettamente, usando mezzi ragionevolmente disponibili?

Se la risposta è sì, l’azienda deve trattarlo come dato personale.

7. GDPR: il vero motore della valutazione sui dati

Quando l’AI tratta dati personali, il GDPR resta centrale. L’AI Act non lo sostituisce.

Per un’azienda che incorpora AI nei propri sistemi, il GDPR richiede di ragionare su:

base giuridica del trattamento;
finalità specifiche;
minimizzazione;
limitazione della conservazione;
trasparenza verso gli interessati;
diritti degli interessati;
sicurezza del trattamento;
ruoli privacy: titolare, responsabile, contitolare;
subresponsabili;
DPIA quando il trattamento presenta rischio elevato;
trasferimenti extra-SEE;
misure tecniche e organizzative.

La DPIA diventa spesso uno strumento essenziale quando l’AI tratta dati personali in modo esteso, innovativo, sistematico, o con potenziale impatto sugli interessati. L’EDPB raccoglie orientamenti e materiali sulle valutazioni d’impatto privacy. EDPB sulle DPIA

Per molte aziende, la sfida non è solo fare una DPIA formale, ma collegarla alla valutazione AI Act, alla valutazione security, al vendor risk assessment e al processo di procurement. Un questionario privacy separato da un questionario security separato da un questionario AI produce spesso una fotografia incompleta.

8. Schrems II, SCC, TIA e trasferimenti internazionali

Molte componenti AI risiedono negli Stati Uniti o sono gestite da vendor globali. Anche quando il data center è in Europa, possono esserci accessi di supporto, telemetry, logging, subprocessor, model hosting, content moderation, abuse monitoring o escalation tecnica fuori dallo Spazio Economico Europeo.

Questo porta al tema dei trasferimenti internazionali.

Dopo Schrems II, le Standard Contractual Clauses restano uno strumento importante, ma non sono una bacchetta magica. La Commissione europea ha adottato nuove SCC per i trasferimenti verso paesi terzi nel 2021, tenendo conto del GDPR e della giurisprudenza Schrems II. Decisione SCC 2021/914 su EUR-Lex

In concreto, quando un’azienda usa un vendor AI extra-UE o un servizio che comporta accesso extra-UE a dati personali, deve chiedersi:

qual è il meccanismo di trasferimento?
esiste una decisione di adeguatezza?
si applicano SCC?
il vendor aderisce a un framework riconosciuto, ove applicabile?
serve un Transfer Impact Assessment?
quali rischi derivano dalla normativa del paese terzo?
quali misure supplementari sono applicate?
i dati sono cifrati?
chi controlla le chiavi?
il vendor può accedere in chiaro?
i subprocessor sono mappati?
gli accessi di supporto sono limitati, tracciati e approvati?
i dati vengono usati per addestramento o miglioramento del servizio?
quali log e retention si applicano?

L’EDPB ha lavorato sulle misure supplementari per i trasferimenti post-Schrems II, proprio per valutare se lo strumento di trasferimento scelto garantisca in concreto un livello di protezione adeguato. EDPB, raccomandazioni sulle misure supplementari

Nel mondo AI questo diventa ancora più importante perché i dati possono apparire in forme diverse: prompt, output, log, embedding, telemetry, feedback, esempi di errore, dataset di fine-tuning, cache, memory, audit trail, trace degli agenti.

9. DPA e contratti: cosa chiedere davvero ai vendor

Il Data Processing Agreement non deve essere un allegato generico firmato a fine procurement. Nel caso AI deve diventare uno strumento operativo.

Un buon processo di vendor assessment dovrebbe chiarire almeno:

ruolo privacy del vendor: responsabile, titolare autonomo, contitolare;
finalità del trattamento;
categorie di dati trattati;
categorie di interessati;
localizzazione dei dati;
accessi da paesi terzi;
subprocessor;
training, fine-tuning e miglioramento del servizio;
uso dei dati cliente per telemetry o product analytics;
retention di prompt, output e log;
cancellazione e restituzione dei dati;
gestione degli incidenti;
audit rights;
segregazione tenant;
cifratura in transito e a riposo;
gestione delle chiavi;
logging amministrativo;
support access;
vulnerability management;
model monitoring;
misure contro prompt injection, data leakage e abuso;
responsabilità in caso di output errato o azione automatica dannosa.

Per gli AI agent bisogna aggiungere domande specifiche:

quali azioni può eseguire l’agente?
con quali privilegi?
può modificare configurazioni?
può bloccare account?
può inviare comunicazioni?
può accedere a dati sensibili?
può chiamare tool esterni?
esiste approvazione umana?
esistono limiti di autonomia?
esiste un audit trail delle azioni?
si può ricostruire perché una certa azione è stata presa?
si possono disabilitare funzioni agentiche non necessarie?

La clausola contrattuale più importante, spesso, non è quella che dice “il vendor è compliant”, ma quella che vieta usi secondari non autorizzati, limita retention e training, disciplina i subprocessor, impone trasparenza sugli accessi e consente audit o evidenze tecniche.

10. Sovranità del cloud: non solo dove stanno i dati, ma chi li può controllare

La sovranità del cloud non coincide semplicemente con la regione del data center. Dire “i dati sono in Europa” è utile, ma non sufficiente.

Bisogna distinguere:

residenza del dato;
luogo di elaborazione;
luogo di accesso amministrativo;
nazionalità e controllo societario del provider;
accessibilità da parte di personale extra-UE;
gestione delle chiavi crittografiche;
subprocessor;
telemetry e log;
supporto tecnico;
resilienza e continuità operativa;
possibilità di exit;
portabilità;
dipendenze da modelli o servizi proprietari.

Nel contesto AI, la sovranità si complica perché non sempre il dato principale è l’unico asset da proteggere. Anche embeddings, prompt, output, feedback, policy, classificazioni, knowledge base, traces degli agenti e regole generate possono avere valore sensibile.

Per un CISO, questo significa che la valutazione di sovranità non deve fermarsi all’infrastruttura. Deve includere la supply chain AI.

11. Cosa significa in concreto per l’azienda

Per un’azienda, l’AI Act dovrebbe tradursi in un programma pratico, non in un documento isolato.

Il primo passo è l’inventario. L’azienda deve sapere dove l’AI è già presente. Questo include strumenti acquistati formalmente, funzioni attivate nei SaaS esistenti, componenti cloud, API usate dai team di sviluppo, copiloti individuali, estensioni browser, strumenti security, strumenti data, funzioni di automazione e agenti.

Il secondo passo è la classificazione. Per ogni caso d’uso bisogna capire:

che cosa fa il sistema;
quale output produce;
se l’output è usato nell’UE;
quali dati tratta;
se tratta dati personali;
se tratta dati particolari;
se incide su persone;
se rientra in aree high-risk;
se richiede trasparenza;
se incorpora GPAI;
se produce contenuti sintetici;
se agisce autonomamente.

Il terzo passo è la governance. Ogni sistema AI rilevante deve avere un owner, un processo di approvazione, controlli, evidenze, documentazione e monitoraggio.

Il quarto passo è il procurement. I vendor AI devono essere valutati con domande specifiche, non con questionari generici riciclati dal cloud risk assessment.

Il quinto passo è il controllo operativo. L’azienda deve poter limitare dati, privilegi, azioni, logging, retention e accessi.

Il sesto passo è la formazione. Non basta formare “gli utenti su ChatGPT”. Bisogna formare procurement, IT, security, legal, privacy, data owner, sviluppatori, HR e management su come riconoscere un caso d’uso AI rilevante.

12. Il ruolo del CISO

Il CISO è centrale, ma non può essere lasciato solo.

Dal punto di vista del CISO, l’AI introduce almeno quattro livelli di rischio:

AI come strumento di difesa SOC copilots, detection, DLP, data classification, response automation.
AI come superficie d’attacco Prompt injection, data leakage, model abuse, agent hijacking, supply chain del modello, plugin/tool abuse.
AI come rischio di governance Shadow AI, uso non autorizzato di tool esterni, assenza di logging, output non verificati.
AI come dipendenza critica Vendor lock-in, indisponibilità del modello, cambi di policy, modelli aggiornati senza controllo, regressioni.

Il CISO deve quindi chiedere controlli concreti:

inventory delle soluzioni AI;
classificazione dei dati inviati ai sistemi AI;
controllo degli accessi;
segregazione dei privilegi;
logging e audit trail;
red teaming o testing su prompt injection e data leakage;
controllo dei connettori;
approvazione umana per azioni ad alto impatto;
monitoraggio delle azioni degli agenti;
incident response specifica per AI;
requisiti di sicurezza nei contratti vendor;
integrazione con risk management e DPO.

13. Il ruolo del DPO

Il DPO deve essere coinvolto presto, non alla fine.

Molti progetti AI partono come iniziative tecnologiche, ma diventano rapidamente trattamenti di dati personali. Questo è vero soprattutto quando l’AI è integrata in strumenti di productivity, security, HR, customer care, analytics, data management o identity.

Il DPO deve aiutare l’azienda a valutare:

se vi sono dati personali;
se vi sono categorie particolari di dati;
se il trattamento è compatibile con la finalità originaria;
se serve una DPIA;
se ci sono trasferimenti extra-SEE;
se embeddings e metadati restano dati personali;
se l’informativa privacy è adeguata;
se i diritti degli interessati sono esercitabili;
se il vendor agisce da responsabile o titolare;
se il DPA è adeguato;
se i subprocessor sono accettabili;
se esistono decisioni automatizzate o profilazione.

Nel caso degli strumenti security, il DPO deve collaborare con il CISO per evitare due errori opposti: bloccare tutto per prudenza astratta, oppure accettare tutto perché “è cybersecurity”. La protezione dell’azienda e la protezione dei diritti delle persone devono essere progettate insieme.

14. Il ruolo del CIO, del CTO e dei team IT

CIO e CTO devono tradurre la governance in architettura.

Le decisioni più importanti non sono solo legali, ma tecniche:

quali modelli sono autorizzati;
quali API possono essere usate;
dove risiedono dati e log;
quali ambienti possono inviare dati a modelli esterni;
quali strumenti di sviluppo possono usare AI;
quali dati possono entrare nei prompt;
come si gestiscono secrets e credenziali;
come si controllano plugin, connettori e agenti;
come si versionano prompt, policy e configurazioni;
come si testa un aggiornamento di modello;
come si disattiva una funzione AI se emergono rischi.

Senza un’architettura governata, l’AI diventa rapidamente una costellazione di scorciatoie locali.

15. Il ruolo del procurement e del legal

Procurement e legal devono evolvere. L’acquisto di una soluzione AI non può essere trattato come una normale subscription SaaS.

Nel processo di acquisto bisogna distinguere:

AI dichiarata dal vendor;
AI embedded non evidente;
AI opzionale attivabile;
AI usata solo per supporto interno del vendor;
AI usata sul dato cliente;
AI usata per training o miglioramento;
AI agentica con azioni operative;
AI con output usato in decisioni aziendali.

Procurement deve chiedere evidenze, non solo dichiarazioni. Legal deve trasformare queste evidenze in obblighi contrattuali: limiti d’uso, audit, subprocessor, data transfer, retention, incident notification, responsabilità, exit, cancellazione, diritti sul dato, uso del dato per training.

16. Il ruolo del board e delle funzioni di vertice

L’AI Act rende evidente che l’AI non è solo un tema tecnico. È un tema di governance aziendale.

Le funzioni di vertice devono porsi alcune domande:

quali processi critici dipendono già da AI?
quali decisioni vengono influenzate da AI?
quali rischi sono accettabili?
chi approva i casi d’uso AI?
chi può fermare un sistema AI?
quali metriche vengono monitorate?
quali evidenze sono disponibili in caso di audit o incidente?
quali fornitori AI sono diventati critici?
quali competenze mancano?
quale livello di autonomia degli agenti è accettabile?

La responsabilità non può restare distribuita informalmente tra IT, security e business unit. Serve una governance esplicita.

17. Un modello operativo minimo

Un’azienda che vuole affrontare seriamente AI Act e AI governance dovrebbe costruire almeno questi elementi:

AI inventory Elenco dei sistemi AI usati o incorporati nei sistemi aziendali, compresi vendor SaaS e strumenti security.

AI use case register Registro dei casi d’uso, con finalità, owner, dati trattati, output, utenti, vendor e livello di autonomia.

Risk classification Classificazione secondo AI Act, GDPR, sicurezza, business criticality e impatto sugli interessati.

Vendor AI assessment Questionario specifico per vendor AI, con attenzione a modelli, dati, training, retention, subprocessor, trasferimenti, sicurezza e agentic capabilities.

Privacy assessment e DPIA Valutazione privacy integrata, con DPIA quando necessaria.

Transfer assessment Valutazione di trasferimenti extra-SEE, SCC, TIA, misure supplementari, accessi remoti e subprocessor.

Security architecture review Analisi tecnica di accessi, privilegi, logging, cifratura, key management, connettori, API e agenti.

Human oversight model Definizione di quando l’umano deve approvare, verificare o poter bloccare il sistema.

Incident response AI-specifica Procedure per data leakage via AI, output dannosi, azioni agentiche errate, compromissione di connettori o abuso del modello.

Board reporting Report periodico su esposizione AI, vendor critici, rischi, incidenti, remediation e decisioni richieste.

18. La domanda finale: non “AI sì o no”, ma “AI sotto quale controllo?”

Per molte aziende, soprattutto in security, DLP, data protection e data management, evitare l’AI non è realistico. La complessità operativa è troppo alta e i vendor stanno incorporando AI in modo sempre più profondo nelle proprie piattaforme.

Ma proprio per questo il tema deve uscire dal marketing.

L’AI Act non dice alle aziende di fermarsi. Dice, in sostanza, che l’AI deve essere compresa, classificata, documentata e governata. Il GDPR ricorda che i dati personali restano protetti anche quando vengono trasformati, pseudonimizzati o incorporati in flussi complessi. Schrems II, SCC, TIA e misure supplementari ricordano che l’uso di servizi globali richiede una valutazione concreta dei trasferimenti e degli accessi. La sicurezza tecnica ricorda che un AI agent con privilegi operativi è anche una nuova superficie d’attacco.

Il punto non è inseguire ogni claim del vendor. Il punto è costruire una capacità aziendale stabile: sapere dove l’AI è usata, con quali dati, da chi, per cosa, con quali limiti, con quali responsabilità e con quali prove.

L’azienda che affronta l’AI Act solo come compliance arriverà tardi. L’azienda che lo usa come occasione per mettere ordine in AI, dati, security, cloud e procurement avrà invece un vantaggio concreto: potrà adottare AI più velocemente, con meno rischio e con più controllo

Nota finale: checklist pratica per valutare una tecnologia che incorpora AI

Quando un vendor propone una tecnologia che incorpora elementi di intelligenza artificiale, l’azienda dovrebbe evitare di fermarsi alla descrizione commerciale della soluzione. La domanda non è se il prodotto “usa AI”, ma come la usa, con quali dati, con quali effetti, con quale autonomia e sotto quale responsabilità.

Di seguito una checklist pratica da usare in fase di procurement, risk assessment, legal review, security review e privacy assessment.

1. Identificazione del sistema AI

Il prodotto incorpora effettivamente un sistema AI ai sensi dell’AI Act?
La funzionalità AI è core, opzionale, embedded o attivabile successivamente?
Il sistema usa un modello proprietario, un modello di terzi o un modello general-purpose?
Il vendor è provider del sistema AI, integratore, rivenditore o deployer?
L’azienda cliente diventa deployer, provider o modifica il sistema in modo sostanziale?
L’output del sistema AI sarà usato nell’Unione europea, anche se il vendor è stabilito fuori dall’UE?

Funzioni coinvolte: legal, compliance, CIO/CTO, procurement, business owner, risk management.

Riferimento: AI Act, art. 2, ambito di applicazione; art. 3, definizioni.

2. Classificazione del rischio AI Act

Il caso d’uso rientra tra le pratiche vietate?
Il sistema può essere classificato come high-risk?
Il sistema incide su persone fisiche, lavoro, accesso a servizi, credito, istruzione, salute, sicurezza, law enforcement o infrastrutture critiche?
Il sistema produce contenuti sintetici, raccomandazioni, classificazioni, scoring o decisioni?
Sono applicabili obblighi di trasparenza verso utenti o interessati?
È necessario mantenere logging, documentazione tecnica, human oversight o istruzioni d’uso specifiche?

Funzioni coinvolte: legal, compliance, DPO, risk management, business owner, HR se il caso d’uso impatta dipendenti o candidati, CISO se il sistema ha rilevanza cyber o accessi privilegiati.

Riferimenti: AI Act, art. 5 sulle pratiche vietate; art. 6 e Annex III sui sistemi high-risk; art. 50 sugli obblighi di trasparenza.

3. Uso di LLM e modelli general-purpose

Quale modello viene usato?
Chi è il provider del modello?
Il modello è general-purpose o specializzato?
I dati dell’azienda vengono usati per training, fine-tuning, evaluation o miglioramento del servizio?
È possibile escludere contrattualmente l’uso dei dati cliente per training?
Dove vengono conservati prompt, output, log, embeddings e feedback?
Il vendor fornisce documentazione adeguata sul modello, sui limiti e sui rischi?
Il modello può produrre output usati in processi decisionali o operativi critici?

Funzioni coinvolte: CIO/CTO, CISO, data office, legal, procurement, DPO, business owner, enterprise architecture.

Riferimenti: AI Act, disposizioni sui GPAI models, in particolare art. 53 e 55; linee guida della Commissione UE sui modelli general-purpose.

4. Dati trattati

Quali dati vengono inviati al sistema AI?
Sono presenti dati personali?
Sono presenti categorie particolari di dati personali?
Sono presenti dati aziendali confidenziali, segreti commerciali, credenziali, log di sicurezza o dati regolati?
Il sistema tratta dati originali, dati trasformati, metadati, embeddings o vettori?
I dati trasformati sono davvero anonimizzati o solo pseudonimizzati?
Esiste una data retention policy chiara per input, output, log e dati derivati?
Il vendor può accedere ai dati in chiaro?

Funzioni coinvolte: DPO, data office, CISO, CIO/CTO, legal, business data owner, compliance.

Riferimenti: GDPR, art. 4 sulle definizioni di dato personale e pseudonimizzazione; art. 5 sui principi del trattamento; art. 25 su privacy by design e by default; art. 32 sulla sicurezza del trattamento.

5. Privacy e DPIA

Qual è la base giuridica del trattamento?
Le finalità sono determinate, esplicite e legittime?
Il trattamento è compatibile con le informative privacy esistenti?
Gli interessati devono essere informati dell’uso dell’AI?
Il sistema comporta profilazione o decisioni automatizzate?
È necessaria una DPIA?
Il DPO è stato coinvolto prima dell’acquisto o dell’attivazione?
I diritti degli interessati possono essere esercitati anche rispetto a dati, log e output AI?

Funzioni coinvolte: DPO, legal, compliance, business owner, HR se riguarda lavoratori o candidati, customer operations se riguarda clienti, CISO per le misure di sicurezza.

Riferimenti: GDPR, art. 6 sulla base giuridica; art. 12-15 sulla trasparenza e accesso; art. 22 sulle decisioni automatizzate; art. 35 sulla DPIA.

6. Trasferimenti internazionali

I dati vengono trasferiti fuori dallo Spazio Economico Europeo?
Ci sono accessi remoti da paesi terzi?
I subprocessor si trovano fuori dall’UE?
Quale meccanismo di trasferimento viene usato?
Esiste una decisione di adeguatezza applicabile?
Sono state sottoscritte Standard Contractual Clauses?
È stato svolto un Transfer Impact Assessment?
Sono previste misure supplementari tecniche, organizzative e contrattuali?
Chi controlla le chiavi crittografiche?
Il vendor può essere soggetto a richieste di accesso da autorità extra-UE?

Funzioni coinvolte: DPO, legal, procurement, CISO, CIO/CTO, vendor management, risk management.

Riferimenti: GDPR, art. 44-49 sui trasferimenti internazionali; sentenza Schrems II; SCC della Commissione europea; raccomandazioni EDPB sulle misure supplementari.

7. Sicurezza tecnica e agentic AI

Il sistema AI può agire autonomamente o solo suggerire?
Quali azioni può eseguire?
Con quali privilegi?
Può modificare configurazioni, bloccare account, cancellare dati, inviare comunicazioni o aprire ticket?
Esiste un meccanismo di approvazione umana?
Le azioni dell’agente sono tracciate e ricostruibili?
Il sistema è protetto da prompt injection, data leakage, abuso dei connettori e privilege escalation?
È possibile limitare tool, API, connettori e fonti dati accessibili dall’agente?
Esistono test di sicurezza specifici per le funzionalità AI?

Funzioni coinvolte: CISO, security architecture, SOC, IAM, CIO/CTO, enterprise architecture, risk management, DPO se sono trattati dati personali.

Riferimenti: AI Act, requisiti di robustezza, accuratezza e cybersecurity per sistemi high-risk; GDPR, art. 32; NIS2 ove applicabile a soggetti essenziali o importanti.

8. Contratti, DPA e responsabilità

Il DPA descrive correttamente il trattamento AI?
Il vendor agisce come responsabile, titolare autonomo o contitolare?
Sono indicati subprocessor, localizzazioni, finalità, retention e misure di sicurezza?
È vietato l’uso dei dati cliente per training non autorizzato?
Sono previsti obblighi di notifica per incidenti, data breach e malfunzionamenti AI?
Sono previsti audit right o evidenze equivalenti?
Il contratto disciplina cambi di modello, nuove funzionalità AI e modifiche sostanziali?
Sono previsti obblighi di cancellazione, restituzione ed exit?
Sono chiare le responsabilità in caso di output errati o azioni automatiche dannose?

Funzioni coinvolte: legal, procurement, DPO, CISO, vendor management, risk management, finance se vi sono impatti assicurativi o di responsabilità economica.

Riferimenti: GDPR, art. 28 sui responsabili del trattamento; art. 32-34 su sicurezza e data breach; AI Act, obblighi di provider e deployer.

9. Governance interna

Chi è l’owner aziendale del caso d’uso AI?
Sono stati coinvolti CISO, DPO, legal, procurement, CIO/CTO, risk management e business owner?
Il board o il top management ha visibilità sui casi d’uso AI più critici?
Esiste un registro interno dei sistemi AI?
Esiste un processo di approvazione prima dell’attivazione di nuove funzioni AI?
Esiste un processo per sospendere o disabilitare una funzione AI rischiosa?
Sono previsti controlli periodici su performance, sicurezza, bias, errori, incidenti e modifiche del vendor?
Gli utenti sono formati sui limiti del sistema?

Funzioni coinvolte: top management, board ove rilevante, compliance, risk management, internal audit, CISO, DPO, CIO/CTO, legal, procurement, business owner.

Riferimenti: AI Act, governance dei sistemi AI e obblighi dei deployer; GDPR, principio di accountability, art. 5(2) e art. 24.

10. Mappa sintetica delle responsabilità interne

Board e top management: definiscono appetito al rischio, priorità, responsabilità e livello di autonomia accettabile per l’AI.
CISO: valuta sicurezza tecnica, esposizione cyber, accessi, privilegi, logging, incident response e rischio degli agenti AI.
DPO: valuta dati personali, DPIA, informativa, diritti degli interessati, trasferimenti e ruoli privacy.
Legal: traduce rischi e obblighi in contratti, DPA, SCC, clausole di responsabilità, audit, exit e limiti d’uso.
Compliance e risk management: classificano il rischio, mantengono il framework di controllo e assicurano coerenza con normative applicabili.
CIO/CTO: valutano architettura, integrazione, modello operativo, controlli tecnici, scalabilità e dipendenze tecnologiche.
Data office: valuta qualità, classificazione, lineage, minimizzazione, data governance e uso di dati derivati.
Procurement e vendor management: verificano vendor, subprocessor, documentazione, evidenze, condizioni contrattuali e rischio di fornitura.
HR: deve essere coinvolta quando l’AI riguarda dipendenti, candidati, performance, monitoraggio o organizzazione del lavoro.
Internal audit: verifica che policy, controlli e registri non restino dichiarazioni, ma siano effettivamente applicati.
Business owner: resta responsabile della finalità d’uso e dell’impatto operativo del sistema nel processo aziendale.

11. Domanda finale da porre al vendor

Prima di approvare una tecnologia AI, l’azienda dovrebbe chiedere al vendor una risposta documentata a questa domanda:

“Potete descrivere, in modo verificabile e contrattualmente vincolante, quali componenti AI usate, quali dati trattate, dove li trattate, se li usate per training, quali output producete, quali azioni automatizzate potete eseguire, quali subprocessor coinvolgete, quali trasferimenti extra-UE avvengono, quali misure di sicurezza applicate e quali obblighi AI Act/GDPR ritenete applicabili?”

La risposta a questa domanda interessa direttamente CISO, DPO, legal, procurement, CIO/CTO, risk management e business owner. Nei casi più critici deve arrivare anche al top management, perché l’adozione dell’AI non è più una semplice scelta tecnica: è una decisione di governance.

Se la risposta è vaga, incompleta o puramente commerciale, il rischio non è stato compreso. E se il rischio non è stato compreso, non può essere governato.