GDPR e AI Act: cosa cambia per chi sviluppa software e soluzioni di Intelligenza Artificiale

Negli ultimi mesi, chi sviluppa software e soluzioni di intelligenza artificiale si è trovato davanti a una nuova parola chiave: AI Act. Un’espressione che sta iniziando a comparire in riunioni, documenti e roadmap di prodotto.

L’AI Act è il nuovo regolamento europeo sull’intelligenza artificiale, pensato per mettere regole chiare su come si sviluppano, vendono e usano i sistemi di IA in Europa. Il suo approccio si basa sul rischio: più un sistema IA può impattare sui diritti delle persone, più stringenti diventano gli obblighi per chi lo sviluppa e lo mette sul mercato.

La domanda che sorge spontanea è: “E il GDPR che fine fa?”

La risposta è semplice, anche se non sempre rassicurante: il GDPR non viene superato dall’AI Act. Resta pienamente valido ogni volta che un sistema di intelligenza artificiale usa dati personali. L’AI Act si aggiunge a questo quadro, portando nuovi obblighi, responsabilità e criteri per valutare i rischi.

Molte aziende tech commettono qui il primo errore: considerare le due normative come alternative, o pensare che basti “adeguarsi all’AI Act” per essere a posto anche sul fronte privacy.

La realtà è diversa: GDPR e AI Act lavorano insieme e incidono direttamente sul modo in cui progetti, documenti e governi i sistemi IA.

C’è poi un secondo equivoco, ancora più diffuso: pensare che gli obblighi riguardino solo chi usa l’intelligenza artificiale, non chi la sviluppa. L’AI Act, invece, guarda molto da vicino anche chi progetta questi sistemi.
Perché è lì che nascono o si prevengono i rischi.

Questo articolo nasce per fare chiarezza. Non per perdersi nel tecnicismo normativo, ma per spiegare cosa cambia davvero, in concreto, per software house, startup e aziende che sviluppano soluzioni IA.

Oggi la privacy by design non è più una buona pratica consigliata, ma una scelta strategica che incide sulla sostenibilità del prodotto, del business e della sua scalabilità nel tempo.

GDPR e AI Act: non una sostituzione, ma una sovrapposizione

Sappiamo che GDPR e AI Act coesistono. Ma nella pratica, se sviluppi software con intelligenza artificiale, cosa cambia davvero?

Cambia che devi tenere d’occhio due aspetti contemporaneamente. Da una parte c’è il GDPR, che ti dice come puoi usare i dati delle persone e come devi tutelarle. Dall’altra c’è l’AI Act, che guarda a come hai costruito il sistema, quali rischi può creare e come lo tieni sotto controllo.
Se il tuo sistema usa dati degli utenti, elabora informazioni che riguardano persone reali, o prende decisioni che le influenzano, pensa a sistemi di raccomandazione, valutazione del credito, selezione del personale, allora devi rispettare entrambe le regole. Non puoi sceglierne una.s
Non basta dire “siamo conformi all’AI Act”. Devi anche dimostrare di rispettare il GDPR: avere un motivo legale per usare quei dati, raccoglierne il minimo necessario, essere trasparente su cosa fai e garantire che le persone possano esercitare i loro diritti.
Qui sta il punto: la maggior parte dei problemi non nasce quando usi il sistema, ma quando lo costruisci. Dataset scelti senza criterio, algoritmi che funzionano ma non sai spiegare come, documentazione inesistente, nessuna valutazione preventiva dei rischi.

L’AI Act rafforza un concetto che era già nel GDPR: se qualcosa va storto, non risponde solo chi usa il software. Risponde anche chi l’ha progettato e sviluppato.

Per chi fa software, la conseguenza è chiara: la compliance non può essere “un problema di cui occuparsi dopo”. Deve entrare nelle scelte di progetto fin dall’inizio, come qualsiasi altra decisione tecnica.

Sistemi di intelligenza artificiale e livelli di rischio: cosa cambia davvero

L’AI Act non tratta tutti i sistemi di intelligenza artificiale allo stesso modo. Il suo impianto ruota attorno a un principio: la gestione del rischio.
Più un sistema IA incide sui diritti e sulle libertà delle persone, più stringenti diventano gli obblighi per chi lo sviluppa e lo usa. Il regolamento distingue quattro categorie in base al livello di rischio.

1. Rischio inaccettabile (vietato)
Sono sistemi considerati incompatibili con i valori europei e quindi vietati.
Parliamo di sorveglianza di massa, social scoring (dare “punteggi” ai cittadini in base ai comportamenti) e tecnologie che manipolano il comportamento umano in modo nascosto o forzato.
Per chi sviluppa software, queste soluzioni non possono essere progettate né vendute in Europa.
È importante precisare che l’AI Act, in linea generale, non si applica ai sistemi utilizzati esclusivamente nel corso di un’attività personale o domestica non professionale.
Tuttavia, rientrano nell’ambito del regolamento i sistemi sviluppati, immessi sul mercato o messi in servizio per finalità professionali o commerciali, anche quando destinati a singoli utenti.

Ad esempio, un sistema progettato per influenzare decisioni personali sfruttando dati comportamentali in modo non trasparente o manipolatorio potrebbe rientrare tra le pratiche vietate, se sviluppato o commercializzato nell’ambito di un’attività economica.
La valutazione del rischio non riguarda solo cosa fa il sistema, ma come lo fa e quali effetti produce sulle persone.

2. Sistemi di intelligenza artificiale ad alto rischio
Questa è la categoria più delicata dell’AI Act e quella che riguarda più da vicino software house e aziende tech.
Un sistema IA è considerato ad alto rischio non perché “usa algoritmi complessi”, ma perché incide in modo significativo sulla vita delle persone. Rientrano qui i sistemi usati in ambiti come lavoro, sanità, credito, istruzione, pubblica amministrazione, giustizia o sicurezza.
Ad esempio:

• Sistemi di selezione o valutazione del personale
• Algoritmi che decidono sull’accesso al credito
• Soluzioni a supporto di decisioni cliniche
• Strumenti di profilazione avanzata per valutare comportamenti o affidabilità

In questi casi, un errore, un dataset distorto o una logica decisionale opaca possono avere conseguenze dirette e gravi sulle persone. Qui cambiano le regole del gioco per chi sviluppa software.
Per i sistemi ad alto rischio, l’AI Act impone obblighi stringenti già in fase di progettazione.
Chi sviluppa deve dimostrare che:

• Dataset e funzionamento del sistema sono controllati e documentati
• Le decisioni del modello sono tracciabili
• C’è una supervisione umana effettiva
• I rischi sono stati valutati e ridotti prima del rilascio

Non è più possibile sviluppare “a scatola chiusa”, affidandosi solo alla performance tecnica. La conformità diventa parte dell’architettura del sistema, non un controllo finale.

3. Sistemi di intelligenza artificiale a rischio limitato
Qui rientrano sistemi che interagiscono con l’utente ma senza prendere decisioni importanti sulla sua vita.
Parliamo di chatbot, assistenti virtuali, sistemi che generano testi, audio o immagini.
Proprio perché sembrano “meno critici”, questi sistemi vengono spesso sottovalutati. Invece l’AI Act introduce un obbligo chiaro: la trasparenza.
L’utente deve sapere, in modo immediato e comprensibile, quando sta parlando con un’intelligenza artificiale e non con una persona.
Sembra semplice, ma non lo è. La trasparenza non è una frase di cortesia nascosta nelle condizioni d’uso. Deve essere integrata nell’interfaccia, coerente con come funziona davvero il sistema e supportata da documentazione chiara.
Chi sviluppa deve chiedersi: l’utente capisce con chi sta interagendo? Posso spiegare come il sistema genera le risposte? Le informazioni che do sono coerenti con la realtà?
E c’è un altro aspetto: se il sistema usa dati personali, anche solo per personalizzare le risposte,  il GDPR si applica completamente, con tutti i suoi obblighi.
È proprio in questi sistemi “apparentemente semplici” che nascono le prime non conformità, perché la trasparenza viene data per scontata invece che progettata.

4. Sistemi di intelligenza artificiale a rischio minimo
Rientrano qui le applicazioni IA considerate a basso impatto: strumenti di supporto, ottimizzazione di processi interni, analisi statistiche, raccomandazioni di base. Per questi sistemi, l’AI Act non introduce obblighi aggiuntivi. Ed è qui che molte aziende abbassano la guardia.

Perché questa classificazione cambia davvero il lavoro degli sviluppatori

Con l’AI Act, la domanda non è più: “Il mio sistema è legale?”
La domanda corretta diventa: “In quale categoria di rischio rientra il mio sistema e sono in grado di dimostrarlo?”

Oggi non basta che un sistema funzioni o sembri innocuo. Chi sviluppa software deve saper spiegare e documentare le scelte fatte lungo tutto il ciclo di vita del prodotto.
Per le aziende tech, questo significa un cambio di approccio concreto: la conformità non può più essere un controllo finale, deve entrare nel ciclo di sviluppo fin dall’inizio. Le scelte su dataset, logiche decisionali e output devono essere tracciabili. E l’impatto su privacy e diritti va valutato prima del rilascio, non dopo un problema.

In pratica, lo sviluppo “a tentativi” o “a scatola chiusa” diventa sempre più rischioso.

Qui GDPR e AI Act si incontrano sul serio. La valutazione del rischio IA e la DPIA iniziano a sovrapporsi. Chi sviluppa sistemi IA deve avere una visione che tiene insieme tecnologia, regole e responsabilità.
È qui che entra in gioco la privacy by design, già prevista dal GDPR e oggi rafforzata dall’AI Act. Non più come buona pratica consigliata, ma come requisito sostanziale che incide su legittimità, sostenibilità e scalabilità delle soluzioni IA.

Privacy by design nei sistemi IA: cosa significa davvero

Per chi sviluppa software e soluzioni di intelligenza artificiale, privacy by design non è uno slogan né un adempimento da rimandare. È un criterio di progettazione che incide su scelte tecniche, architetturali e funzionali del sistema.
Cosa significa in pratica? Che la valutazione dell’impatto sulla privacy avviene prima e durante lo sviluppo, quando le decisioni sono ancora modificabili.
Fin dalle prime fasi, chi progetta un sistema IA dovrebbe porsi domande precise:

• Quali dati personali servono davvero?
• Il sistema può funzionare con dati resi anonimi o pseudonimizzati?
• Come prende decisioni l’algoritmo?
• I risultati sono spiegabili e ricostruibili?
• C’è un intervento umano nei casi critici?

Queste domande non sono opzionali. Sono esattamente le valutazioni che il GDPR e l’AI Act pretendono, soprattutto per i sistemi ad alto rischio.

La privacy by design nei sistemi IA non serve solo a evitare sanzioni. Serve a costruire soluzioni sostenibili, difendibili e governabili nel tempo.

Quando entra in gioco la DPIA e perché è centrale per l’IA

Nei sistemi di intelligenza artificiale, la Valutazione d’Impatto sulla Protezione dei Dati (DPIA) è uno degli strumenti centrali del GDPR per valutare e governare i rischi derivanti dal trattamento di dati personali.

La DPIA diventa obbligatoria quando un sistema IA:

• effettua profilazione avanzata o sistematica
• prende decisioni automatizzate con effetti significativi sulle persone
• produce impatti rilevanti sui diritti e le libertà degli individui

In questi casi, la DPIA non è una scelta. È un obbligo giuridico previsto dall’art. 35 GDPR e uno dei primi elementi che l’Autorità Garante verifica in sede ispettiva.
Non basta dichiarare di aver effettuato una valutazione: è decisivo quando è stata svolta (prima o dopo lo sviluppo), se viene aggiornata nel tempo e se descrive il funzionamento reale del sistema.
Una DPIA costruita in modo meramente formale, copiata da modelli generici, non protegge l’azienda. Può anzi diventare un elemento critico in caso di controllo.

È importante chiarire che la DPIA è uno strumento proprio del GDPR.

L’AI Act introduce, per specifiche categorie di sistemi e soggetti coinvolti nella loro messa in servizio, ulteriori obblighi di valutazione del rischio, tra cui la valutazione dell’impatto sui diritti fondamentali (FRIA).
Nei sistemi di IA che trattano dati personali e rientrano tra quelli ad alto rischio, DPIA (GDPR) e valutazioni previste dall’AI Act possono coesistere e integrarsi, ma restano strumenti distinti, con presupposti e finalità differenti.

Decisioni automatizzate e supervisione umana

Un altro punto di forte sovrapposizione tra GDPR e AI Act riguarda le decisioni automatizzate e il ruolo dell’intervento umano.

Il GDPR pone già limiti chiari: quando le decisioni automatizzate producono effetti giuridici o incidono sulle persone, il Regolamento riconosce diritti specifici (intervento umano, espressione della propria opinione, contestazione).
L’AI Act rafforza questo impianto. Per i sistemi ad alto rischio, la supervisione deve essere reale, efficace e documentabile, non solo dichiarata sulla carta.
Serve, quindi, progettare sistemi che permettano un intervento umano effettivo, che si possano correggere o bloccare in caso di anomalie e che rendano chiara l’attribuzione delle responsabilità.

Per chi sviluppa, la conseguenza è chiara: la supervisione umana deve essere incorporata nell’architettura fin dall’inizio. Servono sistemi controllabili (modificabili o arrestabili), auditabili (con log e tracciabilità) e spiegabili (nei passaggi chiave).
Non è più accettabile un algoritmo che “funziona e basta”. Oggi devi poter spiegare, controllare e intervenire.

Fin qui abbiamo visto il quadro: quando GDPR e AI Act si sovrappongono, come funziona la classificazione del rischio e perché privacy by design, DPIA/FRIA e supervisione umana non sono “pezzi legali”, ma requisiti di progetto.

Il punto, però, è sempre lo stesso: sapere cosa dice la norma non basta.
Se sviluppi software o sistemi IA, devi tradurre questi principi in scelte operative, ruoli, documentazione e processi che reggano nel tempo.
Nel secondo articolo entriamo nel concreto: cosa devi mettere in piedi in una software house per essere davvero governabile (e difendibile) davanti a clienti, audit e Autorità.