Dieci decisioni da prendere prima di portare l’AI in produzione. Non è una certificazione e non è una consulenza legale: è la traccia che usiamo noi quando un progetto AI passa dalla prova al servizio.
Questa guida è per chi deve decidere: direzione, IT, security, compliance, HR e operations di PMI, industrie, pubbliche amministrazioni e filiere. Si legge qui, per intero, senza registrazione e senza modulo.
Perché questa guida
L’AI sta entrando nei processi: ricerca documentale, gestione dei documenti, assistenza, analisi, controllo qualità, manutenzione, automazione. Il valore non dipende solo da quale modello si sceglie. Dipende dalla capacità di progettare un sistema che funzioni nel contesto reale dell’organizzazione, con dati adeguati, responsabilità chiare e controlli proporzionati.
Le dieci decisioni che seguono non sono un adempimento. Sono le domande che, quando non hanno risposta scritta, si ripresentano tutte insieme il giorno in cui qualcosa va storto.
1. Quale problema vogliamo risolvere?
Partire dalla tecnologia porta quasi sempre a progetti generici; partire da un processo porta a una decisione verificabile. Definite l’attività da migliorare, gli utenti, il risultato atteso e soprattutto ciò che non deve cambiare: qualità del servizio, sicurezza, responsabilità umana.
Domanda chiave: quale scelta o attività sarà migliore grazie all’AI?
2. Quali dati servono davvero?
Mappate dati in ingresso, fonti, proprietari, qualità, aggiornamento e autorizzazioni. Applicate la minimizzazione: un dato non necessario aggiunge complessità, rischio e costo, e non aggiunge accuratezza. Se i dati reali sono riservati o insufficienti, valutate dati sintetici o un perimetro diverso — senza dare per scontato che siano privi di rischio, perché la re-identificazione resta una possibilità da valutare caso per caso.
Domanda chiave: possiamo spiegare perché ogni categoria di dato è necessaria?
3. Chi è responsabile di progetto, dati e decisioni?
Un sistema AI coinvolge business, IT, security, privacy, legal e utenti finali. Nominate un owner di processo e stabilite chi approva dati e fornitori, chi controlla gli output, chi gestisce incidenti e modifiche. Se l’elenco è vuoto, il responsabile di fatto sarà l’ultima persona che ha premuto invio.
Domanda chiave: se l’output è errato, chi può fermarlo, correggerlo e comunicarlo?
4. Dove serve supervisione umana?
L’AI può assistere, raccomandare o automatizzare. Più alto è l’impatto su persone, clienti, sicurezza o continuità, più il controllo umano deve essere sostanziale. E supervisione non significa poter cliccare «approva»: significa che chi approva ha le informazioni, il tempo e la competenza per dire di no.
Domanda chiave: la persona che controlla ha informazioni, competenze e potere reale di intervenire?
5. Come verifichiamo qualità e limiti?
Definite casi di test, soglie, errori accettabili, fonti di confronto e percorsi per gli output incerti. Per i sistemi generativi si valutano aderenza ai fatti, citazioni, tono, copertura e comportamento sulle domande fuori ambito. Per computer vision e modelli predittivi si valutano rappresentatività dei dati e condizioni operative reali, che raramente somigliano a quelle del collaudo.
Domanda chiave: come sappiamo quando non fidarci del sistema?
6. Come proteggiamo dati, segreti e accessi?
Progettate ruoli, permessi, segregazione, gestione delle credenziali, protezione degli input, logging proporzionato e canali di escalation. Non trattate un prompt come un ambiente protetto per definizione. E verificate che cosa accade dopo: ai documenti caricati, agli output prodotti, ai log conservati.
Domanda chiave: quali informazioni non devono mai entrare nel sistema?
7. Come rendiamo il sistema trasparente?
Spiegate a utenti e persone interessate, quando previsto o comunque opportuno, che stanno interagendo con l’AI, quale finalità ha il sistema, quali limiti ha e come ottenere un supporto umano. Valutate gli obblighi di trasparenza dell’AI Act per il vostro ruolo e per il vostro scenario, in particolare per sistemi che interagiscono con persone o che generano e manipolano contenuti.
Domanda chiave: una persona sa che cosa sta usando e come contestare o correggere un risultato?
8. Come scegliamo e governiamo i fornitori?
Un fornitore AI è parte dell’architettura, non un acquisto. Si valutano condizioni contrattuali, ruoli privacy, subfornitori, localizzazione, accessi, configurazioni, gestione degli incidenti, esportazione e cancellazione dei dati, supporto alla documentazione. Il nome del provider non è una garanzia: le condizioni cambiano, e vanno riverificate.
Domanda chiave: abbiamo evidenze aggiornate su come il fornitore tratta i dati e gestisce il servizio?
9. Come gestiamo il ciclo di vita?
Modelli, documenti, prompt, dati e integrazioni cambiano. Definite come rilasciare, monitorare, aggiornare, testare e dismettere un sistema. È il lavoro che LLMOps e AI Engineering trasformano in disciplina operativa, con metriche, revisioni e responsabilità assegnate. Un sistema che nessuno misura non peggiora meno: peggiora senza che si veda.
Domanda chiave: che cosa succede dopo il go-live, e come rileviamo un degrado?
10. Quali evidenze dobbiamo conservare?
Inventari, decisioni, istruzioni, valutazioni, test, log proporzionati, formazione e incidenti servono a governare il sistema e a sostenere un confronto con audit, clienti e funzioni di controllo. Conservate ciò che è utile e lecito: più dati non significano automaticamente più accountability, e un archivio inutile è comunque un rischio da custodire.
Domanda chiave: possiamo spiegare in modo documentato come e perché il sistema viene usato?
La matrice: uso, rischio, controllo, evidenza
| Elemento | Domanda | Controllo | Evidenza |
|---|---|---|---|
| Finalità | Quale processo supporta? | Owner e perimetro approvati | Scheda del caso d’uso |
| Dati | Quali dati utilizza? | Minimizzazione, accessi e qualità | Inventario dati e autorizzazioni |
| Output | Come viene validato? | Test, soglie e human-in-the-loop | Report di test e procedure |
| Persone | Può incidere su diritti o decisioni? | Supervisione e canale di revisione | Istruzioni operative |
| Sicurezza | Quali attacchi o esposizioni sono rilevanti? | Permessi, guardrail, escalation | Analisi del rischio e configurazioni approvate |
| Fornitori | Chi opera i componenti critici? | Due diligence e condizioni contrattuali | Registro fornitori e accordi |
| Ciclo di vita | Come viene aggiornato? | Change management e monitoraggio | Registro versioni e alert |
| Trasparenza | Chi va informato? | Informativa, etichettatura o supporto | Testi approvati e registri |
Checklist di avvio
Dieci righe. Se una resta senza spunta, il progetto può partire lo stesso — ma sapete quale sarà il punto debole.
- Il caso d’uso ha un owner business e un obiettivo operativo chiaro.
- Dati, fonti, qualità e autorizzazioni sono mappati.
- Sono definiti i ruoli per business, IT, security, privacy/legal e utenti.
- È previsto un controllo umano proporzionato alle conseguenze dell’output.
- I test includono casi normali, casi limite, errori e fallimenti attesi.
- Sono stati valutati segreti, dati personali, accessi, fornitori e log.
- Gli utenti ricevono istruzioni su limiti, uso corretto e segnalazioni.
- Sono stati valutati gli obblighi di trasparenza e gli altri requisiti applicabili.
- Il sistema ha un piano di monitoraggio, aggiornamento e dismissione.
- Le decisioni e le evidenze rilevanti sono documentate.
Che cosa significa per AI Act e GDPR
L’AI Act introduce un quadro basato sul rischio e prevede obblighi diversi per provider, deployer e altri soggetti. Dal 2 agosto 2026 si applica la parte generale del Regolamento, compresi gli obblighi di trasparenza dell’articolo 50 nei casi previsti. Per i sistemi ad alto rischio le decorrenze principali sono differenziate nel testo vigente.
Il GDPR continua ad applicarsi quando il progetto tratta dati personali: basi giuridiche, informazioni agli interessati, minimizzazione, privacy by design, sicurezza e valutazione d’impatto quando ne ricorrono i presupposti restano elementi centrali. I ruoli dell’AI Act non coincidono automaticamente con quelli del GDPR: provider e deployer non sono titolare e responsabile, ed è un errore frequente.
Le decorrenze complete e le fonti primarie sono su Trasparenza e AI Act e su Normative e scadenze.
Come possiamo affiancarvi
Infordata lavora su percorsi di AI Engineering e governance che uniscono discovery, integrazione con i sistemi esistenti, knowledge base, LLMOps, sicurezza, computer vision, dati da sensori e monitoraggio. Lavoriamo con le funzioni del cliente per tradurre un caso d’uso in un sistema progettato, validato e gestibile nel tempo.
Come lavoriamo su un progetto AI →
Fonti
- Regolamento (UE) 2024/1689 (AI Act), testo consolidato.
- Regolamento (UE) 2026/1744, modifiche al calendario di applicazione.
- Regolamento (UE) 2016/679 (GDPR).
- Legge 23 settembre 2025, n. 132, disposizioni e deleghe al Governo in materia di intelligenza artificiale.
- Commissione europea, linee guida sugli obblighi di trasparenza e Q&A sull’AI literacy.
⚠️ Nota. Contenuto informativo aggiornato al 22 agosto 2026, versione 1.0. Non costituisce consulenza legale. Gli obblighi applicabili dipendono da ruolo, sistema, dati, contesto e norme di settore. Il testo è citabile con attribuzione.