Durante un audit interno la prima domanda sull'IA non riguarda l'accuratezza del modello. Riguarda l'elenco. Il revisore chiede quali strumenti sono in uso e l'IT ne indica tre, mentre HR, credito e marketing ne usano altri che non compaiono da nessuna parte. Chatbot pubblici, funzioni generative già dentro il gestionale e automazioni comprate dal singolo reparto restano fuori dal perimetro. Senza owner, dati trattati, fornitore e approvazione datata non c'è un controllo da verificare. C'è una policy. Il focus di questo testo è operativo, non legale: serve a rendere difendibili i rischi intelligenza artificiale, senza sostituire il parere del legale o del DPO.
Indice
- Il rischio che nessuno ha inventariato
- Rischi intelligenza artificiale e prove che li dimostrano
- Dati imprecisi e bias quando un errore diventa una decisione
- Dati personali, fornitori e trasferimenti fuori dall'UE
- Decisioni automatiche sulle persone e controllo umano
- Il quadro AI Act tra scadenze e sanzioni
- Confermare l'inventario dei sistemi IA prima del prossimo audit
- Errori comuni e domande frequenti
Il rischio che nessuno ha inventariato
Lo scenario si ripete nelle PMI e anche nelle imprese più strutturate. L'auditor apre il registro e chiede data, finalità, fornitore e chi ha autorizzato l'uso. Il responsabile IT conosce le licenze centrali. Non conosce il copilota attivato da un power user, né il connettore pagato con carta di reparto.
Nel 2025 il 15,7% delle PMI italiane utilizzava almeno una tecnologia di IA, contro il 53,1% delle imprese con oltre 250 addetti. Nello stesso periodo, quasi il 60% delle aziende che avevano valutato investimenti senza realizzarli indicava la mancanza di competenze come ostacolo principale, secondo il rapporto Istat sulle imprese e le ICT. Meno competenza formale non significa meno uso. Significa più uso non tracciato.
Conviene separare tre rischi che in audit finiscono nello stesso finding.
- Tecnico: l'output è errato o instabile.
- Di conformità: manca base giuridica, informativa o valutazione.
- Probatorio: dopo un incidente nessuno ricostruisce strumento, versione, dati e controllo umano.
La prima misura utile, per molte organizzazioni, non è un modello più accurato. È un inventario vivo, con owner, dati, fornitore ed evidenza di approvazione.
La domanda da portare in comitato è concreta. Quali strumenti usiamo, con quali dati, approvati da chi, e dove sono le prove?
Rischi intelligenza artificiale e prove che li dimostrano
Una policy firmata non dimostra che il controllo sia partito. L'auditor cerca un owner, un'evidenza datata e un riesame già in calendario. La tabella è la mappa di lavoro.
| Categoria di rischio | Cosa può accadere | Evidenza minima verificabile |
|---|---|---|
| Qualità e provenienza dei dati | Modello addestrato su dati non autorizzati, incompleti o non rappresentativi | Registro delle fonti, versione del dataset, autorizzazione d'uso |
| Errore sistematico e discriminazione | Decisioni distorte su gruppi di persone | Metriche separate per gruppi, soglie di errore documentate, test datati |
| Trattamento illecito di dati personali | Dati personali inseriti nei prompt o usati per il fine-tuning senza base giuridica | Valutazione d'impatto, informativa, configurazione del servizio |
| Trasferimenti fuori dall'UE | Dati conservati su server in Paesi terzi senza garanzie adeguate | Contratto con il fornitore, localizzazione dei trattamenti, sub-responsabili |
| Uso non governato | Strumenti IA adottati dai reparti senza registrazione | Inventario aggiornato, responsabile per ogni strumento, approvazione |
| Dipendenza da fornitori terzi | Interruzione o modifica del servizio senza preavviso | Clausole contrattuali, piano di sostituzione, evidenze di riesame |
| Decisioni automatiche su persone | Esiti su selezione, valutazione o assegnazione senza revisione effettiva | Log della decisione, motivazione, traccia della revisione umana |
| Manipolazione del sistema | Prompt injection o estrazione di informazioni memorizzate | Risultati di test documentati, log degli incidenti |
| Deriva nel tempo | Prestazioni che peggiorano dopo modifiche a dati o modello | Test periodici, data di riesame, azioni correttive chiuse |
Come si legge una riga
Prendi la qualità dei dati. Un'analisi OCSE sui mercati finanziari italiani rileva che soltanto il 22% degli operatori intervistati ha dichiarato di utilizzare dati autorizzati di terzi, mentre appena il 18% ha indicato dataset acquisiti in modo specifico per l'addestramento o la messa a punto, nel rapporto OCSE sui mercati finanziari italiani. Se il registro delle fonti manca, il finding non è "il modello sbaglia". È "non sai su cosa ha imparato".
La stessa logica vale per le altre righe. Il rischio resta accettabile solo con tre condizioni insieme: un responsabile nominato, un'evidenza attribuibile a una data, un riesame con scadenza. Manca uno dei tre e la riga è aperta. Uno screenshot in una chat di reparto non chiude nulla.
C'è anche un effetto sulle persone che i test di accuratezza non catturano. In stati di incertezza gli utenti tendono a fidarsi di un tono fluente. Per questo lato, scopri i rischi cognitivi dell'IA di Psicologia Cognitiva Applicata aiuta a capire perché un output convincente non è una decisione verificata.
Io partirei dalla riga più debole del registro, non dal modello più discusso in riunione.
Dati imprecisi e bias quando un errore diventa una decisione
L'errore che pesa in audit non è la singola allucinazione. È la catena che trasforma uno storico distorto in una decisione su una persona. Il Garante per la protezione dei dati personali chiede misure tecniche e organizzative per correggere i fattori che causano inesattezze, minimizzare gli errori e proteggere i dati personali, tenendo conto degli effetti discriminatori e del rischio di reidentificazione.
Dallo storico alla firma
Immagina uno scoring creditizio, o uno screening di curriculum, addestrato sulle decisioni degli ultimi anni. I passaggi sono sempre gli stessi.
- I dati storici portano correlazioni spurie, per zona, età o percorso scolastico.
- L'ottimizzazione della metrica predittiva le amplifica, perché il modello premia ciò che "spiega" il passato.
- L'output entra nel fascicolo come se fosse un fatto.
- La decisione operativa o lavorativa produce un effetto su una persona, e a quel punto l'errore statistico è già un atto.
Un output stampato non prova che il risultato sia corretto. Prova solo che il sistema ha risposto.
Cosa rende la mitigazione verificabile
Servono dataset versionati, metriche separate per i gruppi rilevanti, soglie di errore scritte prima del go-live, monitoraggio del drift e revisione umana quando l'impatto è alto. Nel registro di ogni modello tieni proprietario, finalità, livello di rischio, dataset e versione, metriche di accuratezza e fairness, esiti dei test, incidenti, azioni correttive e data di riesame. Accanto alla decisione conserva motivazione, controllo umano e la prova che l'uso resti proporzionato alla finalità dichiarata.
Un modello preciso sulla media può restare inaccettabile su un gruppo. Senza la metrica separata quel difetto non compare nel report che firmi.
Dati personali, fornitori e trasferimenti fuori dall'UE
Il caso DeepSeek mostra che il problema non è teorico. Il Garante per la protezione dei dati personali ha chiesto di chiarire quali dati personali siano raccolti, le fonti, le finalità, la base giuridica e l'eventuale conservazione su server in Cina, stimando un possibile impatto sui dati di milioni di persone in Italia, come risulta dal provvedimento sul caso DeepSeek. Un'autorità può limitare il trattamento in tempi brevi quando il fornitore non rende conto di tipologia dei dati, fonti e localizzazione.
Il rischio non si ferma al nome incollato nel prompt. Parametri, log, cronologia, telemetria e dataset di fine-tuning possono consentire inferenze, memorization o ricostruzione. Per questo un chatbot "solo interno" va trattato come un trattamento, non come un'utility.
Cosa registrare su ogni fornitore
Per ogni sistema tieni questi elementi, datati e riconducibili a un owner.
- Fornitore e localizzazione: dove avvengono i trattamenti e chi sono i sub-responsabili.
- Categorie e retention: quali dati entrano, per quanto restano prompt e output.
- Base giuridica e anonimizzazione: su quale fondamento e con quali misure tecniche.
- Valutazione d'impatto: esito della DPIA prima dell'avvio, non dopo la contestazione.
- Test: prompt injection, estrazione di dati memorizzati, verifica dei trasferimenti verso Paesi terzi.
La policy non basta. Servono configurazioni esportate, contratti, registri dei trattamenti, risultati dei test e approvazioni del responsabile privacy e sicurezza. Lo stesso criterio vale per i minori e per l'informativa. Il Garante ha sanzionato Character Technologies Inc., gestore di Character.AI, con 158.000 euro, rilevando criticità sulla tutela dei minori, sulla verifica dell'età e sull'informativa, oltre a una DPIA e a un rappresentante UE predisposti in ritardo, nel provvedimento su Character.AI.
Il collegamento con il GDPR non è un doppione burocratico. È lo stesso caso d'uso visto dal trattamento. Una guida operativa su GDPR e intelligenza artificiale aiuta a tenere ROPA, basi giuridiche e informative allineate al sistema, senza confondere il registro privacy con la scheda del modello.
Decisioni automatiche sulle persone e controllo umano
Il rischio, qui, non è la macchina che "decide da sola". È la firma formale su un output che nessuno ha davvero letto. Nel quadro richiamato dal Garante sul rapporto di lavoro, le decisioni su costituzione, modifica o cessazione non devono basarsi unicamente su un trattamento automatizzato. La decisione finale spetta a una persona fisica con potere effettivo e autonomo.
Un clic di ratifica non è controllo umano. L'organizzazione deve scrivere quattro cose, prima dell'uso.
- Chi riesamina il risultato, con nome e ruolo, non "il team HR".
- Cosa verifica, per esempio coerenza con il fascicolo, eccezioni e dati mancanti.
- Quando si discosta, con criteri di escalation già noti a chi opera.
- Come motiva, in un testo riconducibile alla persona, non al modello.
Le prove sono il log della decisione, i criteri di escalation, l'evidenza della revisione, la gestione degli errori e la formazione degli utenti autorizzati. HR propone il caso d'uso. Il DPO verifica il trattamento. Internal Audit campiona i fascicoli. L'Organismo di Vigilanza entra quando il processo tocca il Modello 231, per esempio su selezione o cessazione.
AuditReady non promette governance automatica, compliance magica o responsabilità delegate al software. La piattaforma può conservare log e collegamenti. Non firma al posto della persona che ha il potere di dire di no.
Il quadro AI Act tra scadenze e sanzioni
In audit la domanda sull'AI Act suona sempre allo stesso modo: quando è entrato in perimetro questo sistema, e chi l'ha deciso? Il Regolamento europeo 2024/1689 si applica a scadenze diverse, e un sistema oggi a rischio limitato può cambiare profilo se lo colleghi a dati personali, a una decisione su persone o a un fornitore nuovo. La classificazione va quindi trattata come una voce del registro con una data di riesame, registrata e firmata.
Secondo la FAQ di AI Act Italia sul Regolamento 2024/1689, dal 2 febbraio 2025 si applicano i divieti sulle pratiche inaccettabili e l'obbligo di alfabetizzazione, dal 2 agosto 2025 gli obblighi per i modelli di IA per finalità generali e dal 2 agosto 2026 gli obblighi di trasparenza per chatbot, contenuti generati dall'IA e deepfake, mentre i massimali previsti arrivano a 35 milioni di euro o al 7% del fatturato mondiale per l'uso di pratiche vietate e a 15 milioni di euro o al 3% per le altre violazioni. Per i modelli a finalità generale gli obblighi comprendono documentazione tecnica, politiche sul copyright e sintesi dei contenuti di addestramento: sono carte da chiedere al fornitore e conservare, non da produrre alla richiesta dell'ispettore. Alcuni obblighi sui sistemi ad alto rischio seguono date ulteriori. In Italia la Legge 23 settembre 2025, n. 132 ha previsto un quadro nazionale con ruoli per ACN e AgID.
| Data o importo | Cosa si applica | Implicazione per il controllo |
|---|---|---|
| 2 febbraio 2025 | Divieti sulle pratiche di IA inaccettabili e obbligo di alfabetizzazione del personale | Evidenza di formazione del personale e screening dei casi vietati |
| 2 agosto 2025 | Obblighi per i modelli di IA per finalità generali | Documentazione tecnica, politica sul copyright, sintesi dei dati di addestramento richiesti al fornitore |
| 2 agosto 2026 | Obblighi di trasparenza per chatbot, contenuti generati dall'IA e deepfake | Informative verificate e registrate nei sistemi interessati |
| Date successive | Ulteriori obblighi per i sistemi ad alto rischio | Calendario di riesame nel registro dei sistemi IA |
| Massimale più alto | Uso di sistemi o pratiche vietate | Prova che il sistema non rientra nelle pratiche vietate |
| Massimale intermedio | Altre violazioni | Evidenze di classificazione, controlli e azioni correttive |
I massimali sopra sono i tetti fissati dal regolamento, non una stima del tuo rischio. In audit conta la traccia: la data della classificazione, chi l'ha approvata e il riesame successivo a ogni modifica di dati, finalità o contesto d'uso. Un classificatore del rischio AI Act aiuta a ordinare il caso d'uso. Il verbale della decisione e la data del prossimo riesame restano responsabilità dell'organizzazione.
Confermare l'inventario dei sistemi IA prima del prossimo audit
Un audit sull'IA inizia quasi sempre allo stesso modo: l'auditor prende un sistema a campione e chiede chi lo usa, su quali dati e chi ne ha autorizzato l'attivazione. Se proposta, approvazione, esecuzione e verifica stanno nella stessa persona, la risposta non regge. CISO, DPO, acquisti e Internal Audit lavorano sullo stesso elenco, con tempi diversi.
- Costruisci l'inventario completo. Includi le funzioni IA già dentro i software e gli strumenti adottati dai reparti, anche quelli attivati senza procedura formale. Altrimenti l'audit parte da un perimetro falso.
- Assegna owner, finalità, stato del ciclo di vita e classificazione. Senza questi quattro campi la scheda non è interrogabile.
- Collega trattamenti, fornitori e controlli. Un sistema senza registro dei trattamenti o senza contratto con il fornitore è un uso, non un asset governato.
- Fissa la prova minima e la data di riesame per ogni categoria che ti riguarda. La scadenza evita il "lo rivediamo".
- Apri un finding per ogni scostamento, con severità, responsabile, scadenza ed evidenza di chiusura. Un finding dentro una mail non esiste per l'auditor.
- Campiona con una domanda da auditor. Se in venti minuti non ricostruisci uso, dati e firmatario, il campione è un finding.
| Fase | Responsabilità | Evidenza minima verificabile |
|---|---|---|
| Proposta del sistema IA | Owner di processo | Scheda sistema con finalità e dati trattati |
| Approvazione | CISO, DPO o responsabile acquisti | Verbale datato prima dell'uso |
| Esecuzione dei controlli | Control owner operativo | Output del controllo con data e versione |
| Verifica indipendente | Internal Audit o Organismo di Vigilanza | Campione testato e report di verifica |
Campi minimi del registro: ID, sistema, owner, finalità, dati trattati, fornitore, rischio inerente e residuo, controlli compensativi, data di riesame, evidenza di chiusura.
Per ogni sistema IA l'inventario di AuditReady registra finalità, owner, stato del ciclo di vita e classificazione del rischio. I findings da audit, incidenti, test, privacy o inserimento manuale restano centralizzati con severità, responsabile, scadenza, intervento ed evidenza di chiusura. Il dettaglio operativo sta nella governance e inventario dei sistemi IA. Il registro non valuta la conformità giuridica e non assegna un rating automatico del rischio.
Checklist prima dell'audit
- Ogni sistema in inventario ha un owner e una data di riesame?
- Le approvazioni sono datate prima dell'uso, non ricostruite a posteriori?
- Per ogni categoria di rischio esiste un'evidenza dell'ultimo ciclo?
- Ogni eccezione ha scadenza e motivazione, e non è stata rinnovata senza riesame?
- Ogni finding ha responsabile, scadenza ed evidenza di chiusura verificata?
- Il campione mostra timestamp e versione, non solo uno screenshot?
- Le decisioni sulle persone hanno un firmatario umano che può discostarsi?
Errori comuni e domande frequenti
Errori comuni che indeboliscono l'audit
- Approvazioni retroattive. Il verbale porta la data della review, non quella in cui il reparto ha acceso lo strumento. L'auditor lo legge come ricostruzione.
- Eccezioni senza fine. Una deroga rinnovata da mesi, senza nuova valutazione, non è più un'eccezione. È un uso non governato.
- Prove sparse. Email, chat e cartelle personali non formano un audit trail. Manca versione, hash o almeno un riferimento stabile al sistema.
- Chiusure dichiarate. Il finding risulta "chiuso" e nessuno ha ricontrollato il controllo. La remediation non è verificata.
- Screenshot muti. Manca timestamp, utente e identificativo del sistema. L'immagine non dice quando il controllo è girato.
Tre eventi vanno tenuti distinti. L'eccezione autorizzata è una deroga approvata, motivata e a tempo. La non conformità è il finding emerso dalla verifica. L'incidente è l'evento che ha già prodotto effetti, su dati, persone o servizio. Trattarli con lo stesso stato nel registro rende il report illeggibile.
Domande frequenti
Chi risponde di una classificazione prodotta da uno strumento? Il firmatario umano, con potere di modificarla. Lo strumento non è owner e non è il soggetto che l'auditor interroga.
Un reparto usa uno strumento non inventariato. Lo spengo e basta? No. Apri un finding, registra sistema, dati e owner, poi decidi sospensione o regolarizzazione. Cancellare l'uso cancella anche la prova.
Quando rivaluto la classificazione AI Act? A ogni cambio di dati, finalità o contesto d'uso, e comunque alla data di riesame già scritta in scheda. La rivalutazione lascia una traccia datata.
Il log del fornitore basta come evidenza? No. Va integrato con approvazioni interne, configurazione e test vostri. Il log di un terzo dice cosa ha registrato lui, non che il vostro controllo sia stato eseguito.
AuditReady centralizza inventario dei sistemi IA, controlli, evidenze versionate e findings con responsabile e scadenza, così il prossimo audit parte da prove datate e non da una raccolta dell'ultima settimana. Non sostituisce il legale e non dichiara la conformità al posto tuo. Se vuoi vedere come si prepara il fascicolo sul tuo perimetro, passa da AuditReady.