AI Act per PMI: il primo adempimento serio è sapere dove usate l'AI
L'AI Act non chiede alle PMI di produrre burocrazia cieca. Chiede prima di sapere quali strumenti AI sono già in uso, chi li fornisce, quali dati trattano e dove possono creare rischio operativo o normativo.
AI Act per PMI: il primo adempimento serio è sapere dove usate l’AI
La prima risposta sbagliata all’AI Act è comprare una policy preconfezionata. La seconda è pensare che riguardi solo chi addestra modelli. Per molte PMI italiane il punto non sarà dimostrare di avere un reparto compliance maturo, ma sapere con precisione dove l’AI è già entrata: nel CRM, nella suite office, nel software HR, nel gestionale, nel customer care, nei tool di marketing, nelle funzioni di ricerca documentale.
L’errore tipico è trattare l’AI come una funzione aggiunta dal fornitore, quindi come un dettaglio tecnico. Non lo è. Quando un fornitore inserisce classificazione automatica, generazione di testi, scoring, sintesi o raccomandazione dentro un servizio usato ogni giorno, cambia il profilo di rischio del processo aziendale. E cambiano le domande da porre: quali dati usa la funzione, dove li elabora, se conserva prompt e output, se addestra modelli, come gestisce i log, come si disattiva.
La tesi è semplice: per una PMI l’AI Act si affronta partendo dall’inventario degli usi reali, non dalla carta. Una mappa corta, concreta e mantenuta viva vale più di un documento elegante che nessuno consulta. È anche il modo migliore per evitare due estremi inutili: bloccare tutto per paura o accendere tutto perché lo include il piano enterprise.
1. L’AI Act non è solo per chi sviluppa modelli
Il Regolamento (UE) 2024/1689, noto come AI Act, distingue ruoli diversi lungo la catena: non esiste solo il grande laboratorio che sviluppa modelli, ma anche fornitori, deployer, importatori e distributori. La parola che interessa a molte PMI è deployer: chi utilizza un sistema di AI sotto la propria responsabilità, salvo l’uso personale non professionale.
Questo punto è decisivo. Una PMI che usa un software di selezione CV con funzioni di ranking non sta addestrando un modello, ma sta impiegando un sistema di AI dentro un processo aziendale sensibile. Un’azienda che usa un assistente per rispondere ai ticket dei clienti non diventa automaticamente fornitore di AI, ma deve capire se l’output viene controllato, se il cliente sa quando interagisce con un sistema automatizzato e se il fornitore rispetta i propri obblighi.
Il Regolamento segue un approccio basato sul rischio. Alcune pratiche sono vietate perché considerate incompatibili con il mercato europeo, come specifiche forme di manipolazione o di sfruttamento delle vulnerabilità. Altri sistemi sono classificati ad alto rischio: l’Allegato III include, tra gli altri, ambiti come occupazione e gestione dei lavoratori, istruzione, accesso a servizi essenziali e alcuni usi nella giustizia e nella sicurezza pubblica.
Per le PMI questo significa una cosa molto concreta: non tutti gli usi dell’AI hanno lo stesso peso. Riassumere una riunione interna non è come filtrare candidature. Generare bozze per il marketing non è come decidere turni, bonus, accessi o priorità di assistenza in modo automatizzato. L’AI Act non impone di trattare ogni chatbot come una centrale nucleare. Impone però di smettere di far finta che una funzione AI dentro il software aziendale sia invisibile.
2. Il vero primo registro: applicazioni, fornitori, dati, decisioni
La parola registro evoca burocrazia, fogli infiniti e responsabilità scaricate sull’IT. Per una PMI dovrebbe essere il contrario: un elenco operativo, breve, utile anche quando cambia un fornitore o quando qualcuno chiede di attivare una nuova funzione AI.
Il primo inventario deve rispondere a quattro domande: quale strumento usa l’AI, quale processo tocca, quali dati vede, quale decisione influenza. Non serve una tassonomia accademica. Serve sapere se l’AI entra in contatto con dati personali, segreti commerciali, offerte economiche, documenti tecnici, informazioni sui dipendenti o comunicazioni con clienti e fornitori.
Una struttura minima può essere questa:
- nome dello strumento e fornitore contrattuale, non solo il nome commerciale della funzione AI;
- reparto che lo usa e processo interessato;
- tipo di dati trattati, distinguendo dati personali, dati clienti, dati dipendenti, documenti riservati e dati tecnici;
- funzione svolta dall’AI: generazione, classificazione, scoring, ricerca, sintesi, automazione;
- impatto dell’output: suggerimento, bozza, decisione assistita, decisione automatizzata;
- possibilità di disattivazione, esportazione dei dati e disponibilità dei log.
Non è un esercizio da consulente. È la base per decidere cosa accendere subito, cosa mettere alla prova in modo controllato e cosa fermare finché il contratto non chiarisce i punti essenziali. In molte aziende, già compilando queste righe, emergono sorprese: plugin installati nei browser, funzioni AI attive di default nei SaaS, tool di marketing collegati al CRM, assistenti usati con account personali.
Qui il parallelo con il GDPR è inevitabile. Il Regolamento (UE) 2016/679 impone principi come minimizzazione, limitazione della finalità, integrità e riservatezza, disciplina i responsabili del trattamento e richiede misure di sicurezza adeguate. Se uno strumento AI tratta dati personali per conto dell’azienda, la domanda non è solo se funziona bene. È se il rapporto con il fornitore regge anche sul piano del trattamento dei dati.
3. Dove una PMI rischia davvero: HR, clienti, produzione, conoscenza interna
La maggior parte delle PMI non finirà nei casi più complessi dell’AI Act perché usa un chatbot per scrivere email. Il rischio nasce quando l’AI tocca persone, denaro, accessi, priorità o continuità operativa.
L’area HR è la più sottovalutata. Filtrare CV, attribuire punteggi ai candidati, suggerire profili da contattare o valutare le performance interne sono attività delicate. L’Allegato III considera ad alto rischio vari sistemi impiegati nell’occupazione e nella gestione dei lavoratori. Non basta dire che la decisione finale la prende una persona, se quella persona vede solo una graduatoria opaca prodotta dal software.
Anche il customer care merita attenzione. Un assistente che genera risposte ai clienti può essere utile, soprattutto in aziende con volumi crescenti e personale limitato. Ma se promette condizioni non approvate, interpreta male i reclami, rivela informazioni interne o tratta dati personali senza controllo, il risparmio iniziale diventa debito operativo. L’AI Act prevede anche obblighi di trasparenza: in alcuni casi la persona deve essere informata quando interagisce con un sistema di AI.
Nel manifatturiero e nella logistica il tema è diverso. L’AI può ottimizzare manutenzione, scorte, qualità, percorsi e pianificazione. Qui il problema non è il testo generato male, ma la dipendenza da una scatola nera integrata nei sistemi di produzione. Se l’algoritmo sbaglia priorità o se il servizio cloud non è disponibile, la domanda diventa: il processo resta governabile? Esiste una modalità manuale? I dati storici sono esportabili? Il fornitore locale o il system integrator che ha implementato la soluzione è in grado di intervenire in fretta?
Infine c’è la conoscenza interna: documenti, offerte, manuali, contratti, ticket, email, procedure. Gli strumenti di AI applicati alla ricerca documentale possono far risparmiare molto tempo. Ma se i permessi sono sporchi, l’AI diventa il modo più rapido per trovare ciò che era stato nascosto male. Qui la compliance non si risolve con una frase nella policy: servono permessi corretti, logging, separazione degli archivi e scelta consapevole di dove vengono elaborati i dati.
4. La clausola AI nel contratto vale più della demo
Il mercato venderà l’AI come una funzione magica già inclusa. Il rischio è che la PMI la compri dentro un pacchetto più grande, senza sapere chi governa davvero modello, dati e infrastruttura. La demo mostra il risultato. Il contratto mostra il potere.
Una buona clausola AI deve chiarire almeno cinque aspetti. Primo: se i dati inseriti dall’azienda vengono usati per addestrare o migliorare i modelli del fornitore. Secondo: dove sono trattati e conservati prompt, output, allegati e log. Terzo: chi può accedervi, inclusi subfornitori e personale di supporto. Quarto: come si disattiva la funzione AI senza perdere il servizio principale. Quinto: come si esportano dati, configurazioni e log in caso di cambio fornitore.
Non sono richieste da grandi gruppi. Sono domande normali per un’azienda che vuole restare padrona dei propri processi. Se il fornitore risponde solo con pagine marketing su sicurezza e innovazione, il segnale è negativo. Se rimanda a documentazione tecnica aggiornata, condizioni contrattuali leggibili e opzioni configurabili, il dialogo è possibile.
La NIS2, la Direttiva (UE) 2022/2555, non è una norma sull’AI. Però richiede misure di gestione del rischio di cybersicurezza che includono continuità operativa, sicurezza della supply chain, gestione degli incidenti e soluzioni di autenticazione. Il messaggio è coerente: il rischio non sta solo dentro il perimetro aziendale, ma nella catena dei fornitori. Un sistema AI integrato in un SaaS è supply chain digitale a tutti gli effetti.
Qui i system integrator italiani possono fare la differenza, se lavorano nel modo giusto. Non come rivenditori di licenze travestiti da consulenti, ma come soggetti capaci di leggere l’architettura reale dell’azienda, distinguere i processi critici, negoziare con i fornitori, predisporre ambienti di test e documentare le scelte. La prossimità operativa conta: quando un assistente AI smette di funzionare o produce risultati anomali, una PMI non può aprire un ticket globale e aspettare che il problema venga capito da qualcuno che non conosce il processo.
5. AI literacy: non il corso motivazionale, ma l’uso corretto
L’AI Act introduce anche l’obbligo di alfabetizzazione in materia di AI. È uno dei requisiti più concreti e più facili da banalizzare. Il rischio è ridurlo a un webinar generico su opportunità e rischi dell’intelligenza artificiale, con slide buone per ogni azienda e inutili per chi deve lavorare il giorno dopo.
Per una PMI, la AI literacy significa tre cose. La prima: insegnare quali dati non vanno inseriti negli strumenti non autorizzati, ossia listini riservati, dati sanitari, informazioni sui dipendenti, credenziali, contratti non pubblici, codice proprietario, offerte in corso. La seconda: spiegare quando l’output va controllato, cioè numeri, clausole, riferimenti normativi, dati tecnici, istruzioni operative. La terza: indicare quali strumenti aziendali sono ammessi e per quali scopi.
La formazione deve essere vicina ai reparti. Il commerciale ha problemi diversi dall’amministrazione, l’HR ha rischi diversi dal marketing, la produzione ha bisogno di esempi diversi dal customer care. Una pagina di regole chiare, affiancata da sessioni brevi per funzione aziendale, vale più di un manuale lungo che nessuno leggerà.
Questa è anche la strada più efficace contro la Shadow AI. Se l’azienda si limita a vietare, le persone useranno account personali. Se mette a disposizione strumenti approvati, spiega i limiti e offre alternative rapide, il comportamento corretto diventa anche il più comodo. La governance funziona quando non costringe i dipendenti a scegliere tra rispettare le regole e fare il proprio lavoro.
6. La buona architettura: poco controllo centrale, molta autonomia guidata
Le PMI italiane funzionano spesso perché decidono in fretta. L’obiettivo non è importare la burocrazia di un grande gruppo, ma costruire un controllo centrale leggero che permetta ai reparti di sperimentare senza generare caos.
Un modello pratico può prevedere tre livelli. Gli usi a basso rischio, come bozze di testi non riservati o sintesi di contenuti pubblici, si autorizzano con regole semplici. Gli usi intermedi, come analisi di documenti interni o assistenza ai ticket, richiedono strumenti aziendali, log, permessi corretti e verifica del fornitore. Gli usi sensibili, come HR, scoring, decisioni su persone, accessi o condizioni economiche, passano da una valutazione specifica prima dell’attivazione.
Questo modello evita sia il blocco sia l’anarchia. Soprattutto, costringe a una domanda spesso rimossa: quanto è reversibile la scelta? Se l’AI è dentro una suite chiusa, con dati e log difficili da esportare, l’azienda compra velocità oggi e rigidità domani. Se invece l’architettura tiene separati documenti, identità, permessi, logging e modello, cambiare fornitore diventa possibile. Non sempre facile, ma possibile.
Il cloud indipendente entra qui senza slogan. Non significa rifiutare i grandi hyperscaler né scegliere un provider solo perché ha una bandiera italiana sul sito. Significa valutare dove conviene tenere dati, indicizzazioni, embedding, backup, log e ambienti di test. In alcuni casi ha senso usare servizi globali. In altri, soprattutto quando si lavora su conoscenza interna e processi critici, un’infrastruttura più vicina e governata da un partner raggiungibile riduce dipendenza e tempi di intervento.
La buona architettura AI per una PMI non è la più sofisticata. È quella che permette di rispondere a domande semplici: chi usa cosa, con quali dati, con quali permessi, con quali log, sotto quale contratto, con quale piano di uscita. Se queste risposte mancano, l’innovazione è solo fiducia nel fornitore.
7. Prima della policy, accendere la luce
L’AI Act non va vissuto come l’ennesimo fascicolo da produrre. Per le PMI può essere l’occasione di fare finalmente ordine in un pezzo dell’IT che sta crescendo più in fretta dei processi interni. L’AI è già nei software, nei browser, nelle suite, nei plugin, nei servizi dei fornitori. Fingere che entri solo quando la direzione approva un progetto è una comodità pericolosa.
Il primo passo serio è accendere la luce: inventario degli strumenti, mappa dei dati, contratti leggibili, formazione concreta, livelli di rischio. Da lì si decide cosa lasciare libero, cosa governare meglio e cosa non usare. Non serve costruire una macchina amministrativa pesante. Serve una disciplina minima, mantenuta nel tempo.
La differenza tra una PMI che usa bene l’AI e una che la subisce non sarà il numero di licenze attivate. Sarà la capacità di non confondere la funzione con il controllo. Il fornitore può dare il modello, l’interfaccia e l’infrastruttura. La responsabilità di sapere dove l’AI entra nei processi aziendali resta in casa. Ed è proprio lì che si gioca la sovranità più concreta: non nella dichiarazione di principio, ma nella possibilità di scegliere, spegnere, cambiare e ripartire senza chiedere permesso.
Riferimenti
Fonti ufficiali
Le versioni autoritative restano quelle pubblicate dagli enti competenti. Verifica sempre alla fonte prima di prendere decisioni operative.
- Regolamento (UE) 2024/1689 (AI Act) - testo su EUR-Lex
- Portale della Commissione UE sull'AI Act e approccio basato sul rischio
- Regolamento (UE) 2016/679 (GDPR) - testo su EUR-Lex
- Direttiva (UE) 2022/2555 (NIS2) - testo su EUR-Lex
- Garante per la protezione dei dati personali - intelligenza artificiale
- Agenzia per la Cybersicurezza Nazionale (ACN) - NIS2 e gestione del rischio
- ENISA - cybersecurity e supply chain digitale
In sintesi
Domande frequenti
Se la mia PMI usa solo funzioni AI incluse nei SaaS che già paghiamo, siamo comunque soggetti all'AI Act?
Sì. Utilizzando un sistema di AI sotto la propria responsabilità l'azienda assume il ruolo di deployer, anche se non sviluppa né addestra modelli. Gli obblighi dipendono dal livello di rischio dell'uso: riassumere riunioni interne pesa molto meno che filtrare candidature o valutare dipendenti. Il punto non è il numero di licenze, ma sapere dove l'AI tocca persone, dati e decisioni.
Da dove parto concretamente se non ho un reparto compliance?
Dall'inventario degli usi reali, non dalla policy. Serve un elenco breve che risponda a quattro domande per ogni strumento: quale AI usa, quale processo tocca, quali dati vede, quale decisione influenza. Già compilandolo emergono plugin del browser, funzioni attive di default e assistenti usati con account personali. È la base per decidere cosa accendere, cosa testare e cosa fermare.
Come capisco se un nostro uso rientra tra i sistemi ad alto rischio?
L'Allegato III del Regolamento elenca gli ambiti sensibili: occupazione e gestione dei lavoratori, istruzione, accesso a servizi essenziali, alcuni usi in giustizia e sicurezza pubblica. In pratica, per una PMI i casi tipici sono HR (ranking CV, scoring candidati, valutazione performance) e decisioni automatizzate su accessi o condizioni economiche. Dire che 'decide una persona' non basta se quella persona vede solo una graduatoria opaca.
Quali clausole devo pretendere dal fornitore prima di attivare una funzione AI?
Almeno cinque punti: se i vostri dati addestrano i suoi modelli, dove trattano e conservano prompt/output/log, chi vi accede (inclusi subfornitori), come si disattiva l'AI senza perdere il servizio principale, come si esportano dati e configurazioni in caso di cambio fornitore. Se il fornitore risponde solo con materiale marketing, è un segnale negativo.
Che rapporto c'è tra AI Act, GDPR e NIS2 nella pratica quotidiana?
Si sovrappongono. Se l'AI tratta dati personali valgono i principi GDPR (minimizzazione, finalità, misure di sicurezza) e il rapporto col fornitore va inquadrato come trattamento. La NIS2, pur non riguardando l'AI, impone gestione del rischio sulla supply chain e continuità operativa: un sistema AI dentro un SaaS è supply chain digitale a tutti gli effetti.
L'obbligo di AI literacy come lo soddisfo senza fare l'ennesimo webinar inutile?
Con formazione vicina ai reparti, non generica. Tre contenuti minimi: quali dati non vanno mai inseriti in strumenti non autorizzati, quando l'output va sempre controllato (numeri, clausole, riferimenti normativi) e quali strumenti aziendali sono ammessi e per quali scopi. È anche la difesa più efficace contro la Shadow AI: se le regole rendono il lavoro più scomodo, le persone useranno account personali.
Discussione (0)
Carico…