AI Act da agosto 2026: cosa cambia per chi sviluppa AI in Italia

L’AI Act (Regolamento UE 2024/1689) è già parzialmente in vigore: i divieti sui sistemi inaccettabili dal febbraio 2025, gli obblighi GPAI e la governance dall’agosto 2025. Il 2 agosto 2026 entra in vigore la parte più sostanziale: gli obblighi per i sistemi ad alto rischio elencati nell’Allegato III. Per chi sviluppa software AI in Italia, questo è il momento in cui la maggior parte degli obblighi smette di essere teorica. Vediamo cosa cambia, cosa è già obbligatorio adesso, e cosa va fatto prima di agosto.

TL;DR

• L’AI Act è già in vigore dal 1° agosto 2024, ma l’applicazione è scaglionata. Tre date chiave: 2 febbraio 2025 (divieti), 2 agosto 2025 (GPAI + governance), 2 agosto 2026 (sistemi alto rischio).
• I sistemi proibiti (social scoring, riconoscimento emotivo sul lavoro, profilazione biometrica indiscriminata, ecc.) lo sono già da febbraio 2025. Sanzioni fino a 35 milioni di euro o 7% del fatturato globale.
• I sistemi GPAI (LLM e foundation models) hanno obblighi specifici per i provider già dall’agosto 2025: documentazione tecnica, transparency sui dati di training, marcature output AI.
• I sistemi ad alto rischio (lavoro, credito, istruzione, law enforcement, sanità, infrastrutture critiche) hanno obblighi pieni da agosto 2026: risk management system, data governance, human oversight, post-market monitoring.
• L’autorità competente in Italia è AgID, designata come autorità di notifica e vigilanza nazionale dal D.L. 28 marzo 2024.
• Sanzioni articolate per categoria: fino a 35M euro o 7% per i divieti, 15M o 3% per gli obblighi alto rischio, 7.5M o 1.5% per documentazione e cooperazione.

Perché l’AI Act conta nel 2026 (non solo per i big tech)

Una distorsione di prospettiva comune: “AI Act è cosa per OpenAI, Google, Meta”. È falsa per due ragioni.

Primo, l’AI Act regola anche chi utilizza sistemi AI ad alto rischio, non solo chi li sviluppa. Una software house italiana che integra un LLM in un sistema di screening CV per i propri clienti del recruiting diventa “deployer” di un sistema ad alto rischio (lavoro è nell’Allegato III). Con obblighi specifici e sanzioni proprie.

Secondo, la supply chain AI Act funziona come la NIS2: i vostri clienti regolamentati vi chiederanno per contratto i requisiti AI Act. Anche se voi sviluppate un componente generico, il cliente che lo integra in un sistema alto rischio deve dimostrare di averlo selezionato in modo conforme. La pressione contrattuale arriva prima delle ispezioni.

Le software house che si muovono nel 2026 hanno tempo per fare le cose con calma e differenziarsi. Quelle che aspettano il 2027 si trovano con il telefono che suona di clienti regolamentati che chiedono evidenze che non hanno preparato.

Cosa è l’AI Act in 3 minuti

Il Regolamento (UE) 2024/1689 è un framework risk-based: classifica i sistemi AI in quattro categorie di rischio, e impone obblighi proporzionali alla categoria.

Rischio inaccettabile (proibiti): sistemi che violano valori UE fondamentali. Banned.

Rischio alto: sistemi in 8 ambiti specifici (Allegato III) con impatto significativo su diritti, sicurezza, vita delle persone. Obblighi pesanti.

Rischio limitato (trasparenza): chatbot, deepfake, contenuti generati AI. Obblighi minimi: l’utente deve sapere che sta interagendo con AI o vedendo contenuto AI-generato.

Rischio minimo: tutto il resto. Nessun obbligo specifico, ma codici di condotta volontari incoraggiati.

A queste quattro si aggiunge una categoria trasversale introdotta tardi nel negoziato: GPAI (General Purpose AI Models). Modelli foundation come GPT, Claude, Gemini, Llama. Hanno regime proprio con due livelli (GPAI standard e GPAI con systemic risk).

L’autorità europea è l’AI Office presso la Commissione Europea. L’autorità nazionale italiana è AgID, con coordinamento di Garante Privacy e ACN per le rispettive competenze.

Sistemi proibiti (in vigore dal febbraio 2025)

L’articolo 5 elenca 8 categorie di sistemi proibiti. In sintesi operativa:

1. Manipolazione subliminale o sfruttamento di vulnerabilità (es. età, disabilità, situazione socio-economica) per condizionare comportamenti in modi che causano danno.
2. Social scoring generalizzato da parte di autorità o privati (modello cinese).
3. Riconoscimento emotivo sul posto di lavoro o nelle scuole (eccezioni per ragioni mediche o di sicurezza).
4. Categorizzazione biometrica per dedurre razza, opinioni politiche, orientamento sessuale, religione.
5. Identificazione biometrica remota in tempo reale in spazi pubblici da parte di law enforcement (eccezioni strette per crimini gravi specifici).
6. Predictive policing basato esclusivamente su profilazione automatica.
7. Scraping massivo di immagini facciali da internet o videosorveglianza per costruire database di riconoscimento facciale.
8. Inference biometrica in tempo reale di emozioni o stati cognitivi negli spazi pubblici (eccezioni mediche specifiche).

Per la maggior parte delle software house italiane queste categorie non si applicano direttamente. Ma attenzione ai casi borderline: un sistema di people analytics che misura “engagement” emotivo dei dipendenti da video o audio rientra nella categoria 3. Un sistema di targeted advertising che usa profilazione vulnerabilità (es. ludopatici, persone in difficoltà finanziaria) potrebbe rientrare nella 1.

Le sanzioni per violazione divieti sono le più alte: fino a 35 milioni o 7% del fatturato globale.

Sistemi ad alto rischio (obblighi pieni da agosto 2026)

Allegato III dell’AI Act elenca 8 ambiti dove i sistemi AI sono “ad alto rischio”. I più rilevanti per software house italiane:

1. Biometria: identificazione, categorizzazione, riconoscimento emotivo (in casi non vietati).

2. Infrastrutture critiche: AI per gestione e funzionamento di traffico stradale, acqua, gas, energia, calore.

3. Istruzione e formazione professionale: AI per ammissione studenti, valutazione apprendimento, monitoraggio comportamenti in classe.

4. Lavoro: AI per screening CV, decisioni di promozione/licenziamento, allocazione compiti, monitoring performance.

5. Servizi essenziali pubblici e privati: credit scoring, valutazione welfare, prioritizzazione chiamate emergenza, sanità.

6. Law enforcement: AI per valutazione rischio individuale, valutazione affidabilità prove, profilazione criminale.

7. Migrazione, asilo, controllo frontiere: AI per valutazione domande, verifica documenti, sorveglianza.

8. Amministrazione giustizia e processi democratici: AI per ricerca e interpretazione di fatti e leggi, influenza su elezioni e referendum.

Se sviluppate sistemi che operano in questi ambiti, da agosto 2026 si applicano obblighi pieni. Vediamoli in pratica.

Obbligo 1: risk management system

Sistema documentato di identificazione, analisi e mitigazione dei rischi del sistema AI lungo tutto il ciclo di vita. Si aggiorna continuamente. Output formale: documento di risk management aggiornato con frequenza e firmato da responsabili.

Obbligo 2: data and data governance

I dati di training, validation e test devono essere “rilevanti, sufficientemente rappresentativi, privi di errori per quanto possibile, completi rispetto allo scopo”. Bias e gap nei dati vanno documentati e mitigati. Concretamente: documento di data governance con descrizione dataset, fonti, processi di pulizia, bias assessment.

Obbligo 3: technical documentation

Documentazione tecnica dettagliata: architettura del sistema, algoritmi, dati di training, performance metrics, casi noti di malfunzionamento, istruzioni di uso, manutenzione. Allegato IV dell’AI Act specifica i contenuti minimi (è una lista di 9 sezioni). Va tenuta aggiornata per 10 anni post-fine ciclo di vita.

Obbligo 4: record keeping (logging automatico)

Il sistema AI deve loggare automaticamente eventi rilevanti per la tracciabilità: input, output, decisioni, anomalie. I log vanno conservati per il periodo necessario (tipicamente coerente con normativa di settore: GDPR, conservazione fiscale, ecc.).

Obbligo 5: transparency verso i deployer

Il fornitore del sistema AI deve fornire al deployer (chi lo usa) istruzioni chiare: capacità, limitazioni, tipo di output, livello di accuratezza, casi in cui può fallire, human oversight richiesto.

Obbligo 6: human oversight

Il sistema deve essere progettato per consentire effettivo controllo umano. Il deployer deve poter monitorare, intervenire, sospendere il sistema quando necessario. Non è un’opzione: è obbligo tecnico di design.

Obbligo 7: accuracy, robustness, cybersecurity

Il sistema deve raggiungere livelli appropriati di accuratezza, robustezza tecnica e cybersecurity. Livelli da dichiarare nella documentazione e da verificare empiricamente. Non basta dire “accuratezza 95%”: va dimostrato come misurato, su quale dataset, in quali condizioni.

Obbligo 8: conformity assessment

Prima di immettere il sistema sul mercato, va fatto un conformity assessment. Per la maggior parte dei sistemi alto rischio sviluppati internamente è un’autovalutazione strutturata. Per alcuni casi (biometrici remoti) serve un notified body terzo.

Obbligo 9: marcatura CE e dichiarazione UE di conformità

Il sistema conforme ottiene marcatura CE (come prodotti tradizionali) e va accompagnato da dichiarazione UE di conformità.

Obbligo 10: registrazione database UE

Sistemi alto rischio vanno registrati in un database UE pubblico gestito dalla Commissione, accessibile a cittadini e autorità.

Obbligo 11: post-market monitoring

Dopo il go-to-market, sistema di monitoraggio continuo delle performance, raccolta feedback, gestione incidenti gravi (segnalazione obbligatoria entro 72 ore o 15 giorni a seconda della gravità).

Sistemi GPAI (LLM e foundation models): obblighi specifici

Dall’agosto 2025 sono in vigore obblighi specifici per i provider di modelli GPAI. Questi obblighi NON si applicano agli sviluppatori che usano API di GPAI (es. chiamare OpenAI o Anthropic da un’app), ma ai provider dei modelli stessi.

Obblighi base GPAI:

• Documentazione tecnica del modello
• Informazioni e documentazione per chi integra il modello
• Policy di rispetto del copyright nei dati di training
• Riassunto pubblico dei contenuti usati per training

Obblighi aggiuntivi per GPAI con systemic risk (modelli che superano la soglia di FLOP indicata: oltre 10^25 FLOPs di compute, soglia che Claude, GPT-4, Gemini Ultra superano):

• Model evaluation (state-of-the-art, red teaming incluso)
• Risk assessment e mitigation
• Incident reporting su incidenti seri
• Cybersecurity protection del modello stesso

Per la maggior parte delle software house italiane: gli obblighi GPAI riguardano il vostro fornitore LLM (OpenAI, Anthropic, ecc.), non voi direttamente. Ma se sviluppate un vostro modello da zero (raro ma possibile), o se fate fine-tuning sostanziale che ne cambia capability, potete diventare provider GPAI con obblighi propri.

Trasparenza per sistemi a “rischio limitato”

Articolo 50: obblighi minimi di trasparenza per:

• Chatbot: l’utente deve essere informato che sta interagendo con AI (anche se “ovvio”).
• Deepfake e contenuti AI-generati: vanno etichettati come tali (“marcato come artificiale o manipolato”).
• Sistemi che generano testo per informare il pubblico: l’autore AI va dichiarato (salvo human review sostanziale).
• Emotion recognition e biometric categorization: l’utente va informato.

Questi obblighi sono leggeri ma si applicano a moltissimi prodotti (qualsiasi chatbot in produzione dovrebbe già avere un disclaimer “stai parlando con un assistente AI”, non sempre lo ha).

Cosa cambia esattamente dal 2 agosto 2026

Dal 2 agosto 2026 entrano in vigore principalmente:

1. Obblighi pieni per sistemi alto rischio Allegato III (i 7 ambiti elencati sopra esclusi biometrici, che hanno regole specifiche dal 2025).
2. Autorità nazionali competenti operative: AgID con poteri di vigilanza, sanzione e ispezione.
3. Codici di condotta GPAI definitivi (in attuale fase di consultazione e finalizzazione).
4. Standard tecnici armonizzati EN forniti da CEN-CENELEC per dimostrare conformità (in elaborazione).
5. Procedura di registrazione database UE attiva per sistemi alto rischio.

Restano da entrare in vigore (agosto 2027):

• Obblighi per sistemi alto rischio Allegato I (componenti di sicurezza di prodotti regolati: macchine, dispositivi medici, giocattoli, ascensori, automobili).
• Alcune disposizioni transitorie su GPAI esistenti.

Sanzioni nel dettaglio

Articolato in tre fasce (art. 99):

Fascia 1 (divieti, art. 5): violazione dei sistemi proibiti. Sanzione fino a 35.000.000 euro o 7% del fatturato globale annuo del gruppo (la cifra più alta). Ridotto al 3% o 1.5M per PMI/startup.

Fascia 2 (obblighi alto rischio e GPAI): violazione degli obblighi sostanziali. Sanzione fino a 15.000.000 o 3% del fatturato. Ridotto al 2% o 1M per PMI/startup.

Fascia 3 (informazioni inesatte/incomplete a autorità): sanzione fino a 7.500.000 o 1.5% del fatturato. Ridotto all’1% o 500k per PMI/startup.

Per i provider GPAI sanzioni specifiche fino a 15M o 3%.

Le sanzioni si applicano agli enti, ma le autorità possono procedere anche con sanzioni amministrative individuali (responsabilità dei rappresentanti legali e AI Officer designati).

Cosa fare adesso: roadmap fino ad agosto 2026

Per una software house italiana che sviluppa o utilizza sistemi AI:

Step 1. Inventario AI (1-2 settimane)

Mappatura completa dei sistemi AI in uso e in sviluppo:

• Sistemi proprietari sviluppati internamente
• Sistemi integrati via API di terzi (LLM, vision API, ecc.)
• Sistemi forniti a clienti Per ognuno: ambito di applicazione, categoria di rischio AI Act, deployer e provider (siete provider, deployer, entrambi).

Step 2. Classificazione (1 settimana)

Per ogni sistema mappato, classificazione AI Act:

• Proibito (da rimuovere immediatamente)
• Alto rischio (obblighi pieni da agosto 2026)
• Rischio limitato (obblighi trasparenza)
• Rischio minimo (nessun obbligo specifico)
• GPAI (siete provider o deployer)

Step 3. Gap analysis (2-4 settimane)

Per i sistemi alto rischio (se presenti), gap analysis sugli 11 obblighi visti sopra:

• Cosa abbiamo già documentato vs cosa manca
• Quali sistemi tecnici servono (logging, monitoring, human oversight)
• Risorse necessarie per chiudere i gap

Step 4. Designazione AI Officer (1 settimana)

Designazione formale di un responsabile AI compliance (interno o consulente). Approvazione CdA della AI policy aziendale. Anche se non obbligatorio espressamente per tutti, è la prima cosa che vi chiederanno auditor e clienti.

Step 5. Implementazione (4-12 mesi)

Per i sistemi alto rischio:

• Costruzione risk management system formale
• Documentazione tecnica completa per Allegato IV
• Logging automatico se non c’è
• Procedura human oversight documentata
• Post-market monitoring attivato

Per sistemi a trasparenza:

• Aggiunta disclaimer “stai parlando con AI” nei chatbot
• Etichettatura contenuti AI-generati pubblicati

Step 6. Conformity assessment + marcatura CE (1-3 mesi)

Per ogni sistema alto rischio: autovalutazione strutturata (o notified body se richiesto), redazione dichiarazione UE conformità, registrazione database UE, marcatura CE.

Step 7. Aggiornamento contratti commerciali (2-4 settimane)

Aggiornamento dei contratti con clienti che usano i vostri sistemi AI:

• Clausole di trasparenza
• Allocazione responsabilità provider/deployer
• Procedure incident reporting condivise

Errori comuni delle software house italiane

1. “Usiamo l’API OpenAI, ci pensa OpenAI alla compliance”. Falso. OpenAI è responsabile come provider GPAI, ma voi siete responsabili del sistema AI che costruite integrandone le API. La separazione di responsabilità lungo la supply chain AI è esplicita nel regolamento.

2. “Non facciamo high-risk, non ci riguarda”. Verificare l’Allegato III con attenzione. Un sistema di screening CV è alto rischio. Un assistente AI per medici è alto rischio. Un calendar bot probabilmente no. La distinzione non è ovvia.

3. “Aspettiamo che AgID dia chiarimenti”. AgID sta lavorando ma le indicazioni nazionali arriveranno gradualmente. Aspettare significa trovarsi non-compliant ad agosto 2026 con poca strada per recuperare. Meglio partire ora dal testo del regolamento e dalle linee guida AI Office UE.

4. Documentazione AI come PDF “una tantum”. La documentazione tecnica AI Act è viva: va aggiornata a ogni release significativa del sistema. Pensarla come progetto chiuso porta a documenti obsoleti che in caso di ispezione peggiorano la posizione.

5. Non designare formalmente un AI Officer. La governance è obbligo de facto. Senza ruolo formale interno, non c’è chi gestisce, decide, risponde. Le aziende che si trovano sotto pressione di clienti regolamentati nel 2026 sono quelle che non hanno designato.

FAQ

Un sistema RAG aziendale interno conta come AI Act?

Dipende dall’uso. Un RAG che risponde a domande dei dipendenti su HR (es. “quanto mi spetta di ferie”) non è alto rischio. Un RAG che aiuta nelle decisioni di selezione del personale (anche solo suggerendo) entra in lavoro = alto rischio. Anche solo suggerire in ambiti alto rischio attiva gli obblighi.

Le PMI hanno esoneri?

Riduzioni delle sanzioni (vedi sopra), e alcuni alleggerimenti sulla documentazione tecnica per PMI/startup esplicitamente previsti. Ma nessun esonero pieno dagli obblighi sostanziali: se sviluppate sistemi alto rischio, gli obblighi pieni si applicano comunque.

Come si interfacciano AI Act e GDPR?

Sono complementari, non in conflitto. AI Act regola i sistemi AI in sé; GDPR regola il trattamento dei dati personali. Un sistema AI che processa dati personali ricade sotto entrambi: serve DPIA (articolo 35 GDPR) e risk assessment AI Act, che possono essere documenti coordinati ma non identici. Il Garante Privacy italiano coopererà con AgID per i casi sovrapposti.

Il cliente PA cosa mi chiederà?

Stiamo già vedendo i primi capitolati nei bandi PA del 2025-2026 che includono clausole AI Act-related: dichiarazione di classificazione rischio dei sistemi proposti, evidenza di documentazione tecnica, designazione AI Officer del fornitore. Le PA italiane fanno spesso da apripista in compliance: i requisiti privati arriveranno di seguito.

Come si gestisce un sistema in produzione dal 2023 che ora è classificato alto rischio?

L’AI Act prevede regime transitorio per sistemi pre-esistenti. Per sistemi alto rischio già in produzione al 2 agosto 2026, gli obblighi pieni si applicano a partire da update significativi del sistema. In pratica: se il sistema resta tale e quale, c’è un grace period; se lo aggiornate sostanzialmente, gli obblighi si attivano. La definizione di “modifica sostanziale” è in elaborazione nelle linee guida.

AI Act si applica anche a sistemi sviluppati per uso interno della propria azienda?

Sì se rientrano nell’Allegato III. Un sistema di screening CV usato solo internamente per assumere personale della vostra azienda è alto rischio anche se non commercializzato. La distinzione AI Act è sull’uso del sistema, non sulla commercializzazione.

Conclusione

L’AI Act dal 2 agosto 2026 smette di essere un argomento da conferenza e diventa operativo. Per le software house italiane che sviluppano AI o lo integrano, è il momento di fare l’inventario, classificare, mappare i gap. Le aziende che arriveranno al 2 agosto 2026 con un AI Officer designato, sistemi classificati, documentazione di base preparata, eviteranno i picchi di costo (e di stress) che si materializzano quando si rincorre la compliance dopo che è già obbligatoria.

Se state valutando il vostro posizionamento AI Act e volete un assessment iniziale sui sistemi in uso o in sviluppo, parliamone. Il primo confronto è gratuito.

Per approfondire altri aspetti regolamentari: la pagina pilastro software custom security-aware, la pagina AI Act compliance implementazione per chi vuole supporto operativo, e l’articolo correlato sulla NIS2 per software house italiane.