Appalti pubblici e AI Act: requisiti per fornitori e PA italiana (2026)

Gli appalti pubblici italiani sono diventati il primo banco di prova reale dell'integrazione tra Regolamento (UE) 2024/1689 (AI Act) e Codice dei Contratti Pubblici (D.Lgs. 36/2023). A partire dal 2 agosto 2026 le stazioni appaltanti che acquistano sistemi di intelligenza artificiale, e i fornitori che li propongono, devono dimostrare conformità al regolamento europeo prima ancora di firmare un contratto. Non si tratta più di una dichiarazione di buone intenzioni: il bando di gara, il capitolato tecnico, l'offerta economica e l'esecuzione contrattuale diventano tutti documenti soggetti a verifica di conformità AI.

Questa guida è un manuale operativo per due platee diverse che lavorano sullo stesso processo: chi compra AI per la pubblica amministrazione e chi la vende. Distinguiamo gli obblighi dei fornitori (provider, articoli 6-49 dell'AI Act) dagli obblighi dei deployer pubblici (articoli 26 e 27), spieghiamo come si traducono nei documenti di gara, quali sono le sanzioni e chi le applica, e come il sistema italiano ha allineato il quadro nazionale tramite la Legge 132/2025 e l'istituzione di AESIA.

Il quadro normativo: AI Act, Codice Appalti e Legge 132/2025

L'AI Act è entrato in vigore il 1 agosto 2024 con applicazione scaglionata. Le date che riguardano direttamente gli appalti pubblici sono tre: 2 febbraio 2025 per i divieti su pratiche vietate (articolo 5) e per gli obblighi di alfabetizzazione AI del personale; 2 agosto 2026 per gli obblighi sui sistemi ad alto rischio elencati nell'Allegato III, fra cui la maggior parte degli use case PA; 2 agosto 2027 per i sistemi ad alto rischio integrati in prodotti già regolati da normativa di prodotto UE (Allegato I). Il calendario completo è dettagliato nella nostra guida scadenze AI Act 2026-2027 per l'Italia.

In Italia, la Legge 23 settembre 2025 n. 132 ("Disposizioni e deleghe al Governo in materia di intelligenza artificiale") ha completato l'architettura nazionale, designando AESIA (Agenzia per l'Intelligenza Artificiale, sotto la Presidenza del Consiglio) come autorità di vigilanza sui sistemi AI ad alto rischio in ambiti diversi dalla protezione dei dati personali, e confermando il Garante per la Protezione dei Dati Personali come autorità competente per i sistemi che trattano dati personali in contesti come biometria, lavoro, accesso a servizi pubblici essenziali. Per il quadro generale italiano si veda l'approfondimento AI Act Italia: guida completa per imprese e PA.

Dal lato appalti, il D.Lgs. 36/2023 e il successivo correttivo D.Lgs. 209/2024 hanno introdotto l'articolo 30 sull'uso di procedure automatizzate e di AI da parte delle stazioni appaltanti, stabilendo principi di conoscibilità, trasparenza, non discriminazione algoritmica e supervisione umana. L'articolo 95 del Codice Appalti, sui criteri di aggiudicazione, è quello dove la conformità AI Act si aggancia in concreto: una stazione appaltante che acquista un sistema ad alto rischio deve inserire la conformità al regolamento europeo fra i requisiti di partecipazione (criteri di selezione) o fra gli elementi premianti dell'offerta tecnica (criteri di valutazione).

L'effetto pratico è che dal 2 agosto 2026 una gara per un sistema AI di screening curriculum, di valutazione del rischio sociale, di triage sanitario, di gestione del traffico critico o di analisi documentale per concessione benefici sociali non potrà più essere aggiudicata senza la prova documentale che il sistema sia conforme all'AI Act.

Sistemi AI ad alto rischio negli appalti PA: chi è interessato

L'AI Act classifica i sistemi in quattro livelli: rischio inaccettabile (vietato), alto rischio, rischio limitato, rischio minimo. La quasi totalità degli use case PA che giustificano una gara dedicata cade nella categoria "alto rischio" definita dall'Allegato III. Per gli appalti pubblici italiani si attivano in particolare:

Punto 5 dell'Allegato III — Sistemi AI usati da autorità pubbliche per valutare l'idoneità a benefici e servizi pubblici essenziali (assistenza sanitaria, sussidi, accesso a misure di sostegno economico), inclusi sistemi di rilevamento frodi nelle prestazioni sociali e sistemi di valutazione del merito creditizio quando usati da soggetti pubblici.
Punto 6 dell'Allegato III — Sistemi usati da forze dell'ordine per la valutazione del rischio individuale, poligrafi, valutazione dell'attendibilità delle prove, analisi predittiva della criminalità.
Punto 7 dell'Allegato III — Sistemi di gestione della migrazione, asilo e controllo delle frontiere.
Punto 8 dell'Allegato III — Sistemi per l'amministrazione della giustizia e i processi democratici, compresi gli strumenti di supporto decisionale ai giudici e i sistemi che influenzano risultati elettorali.
Punto 4 dell'Allegato III — Sistemi AI usati per il reclutamento, la selezione, la valutazione delle prestazioni e l'attribuzione di compiti nei rapporti di lavoro, inclusi i concorsi pubblici quando si avvalgono di screening automatizzato.
Punto 1 e 2 dell'Allegato III — Identificazione biometrica e infrastrutture critiche (gestione del traffico, fornitura di acqua, gas, energia, riscaldamento).

Restano fuori da questa lista (e quindi non sono "alto rischio" per definizione) gli usi puramente amministrativi e di back-office come la classificazione automatica di documenti interni, l'instradamento delle email, gli assistenti generativi per la redazione di bozze, la trascrizione automatica di verbali, sempre che non incidano in modo determinante su decisioni che producono effetti giuridici verso il cittadino. La distinzione non è banale: un copilota AI per la redazione di un atto è un sistema a rischio limitato; un sistema che assegna un punteggio di rischio ai contribuenti per decidere quali sottoporre a verifica fiscale è alto rischio.

Una buona prassi italiana che si sta consolidando è che le stazioni appaltanti effettuino una pre-classificazione del sistema oggetto di gara nel capitolato tecnico, motivando perché lo collocano in una determinata categoria di rischio e imponendo ai concorrenti l'onere di dichiararne la conformità coerente con quella classificazione.

Obblighi del fornitore (provider): articoli 6-49

Chi sviluppa o mette in servizio un sistema AI ad alto rischio nel mercato europeo è qualificato come "provider" dall'AI Act ed è destinatario del corpo principale del regolamento. Per partecipare a una gara pubblica italiana per un sistema ad alto rischio dal 2 agosto 2026, il fornitore deve poter esibire:

1. Sistema di gestione dei rischi (articolo 9). Un processo documentato e iterativo di identificazione, analisi, valutazione e mitigazione dei rischi prevedibili lungo l'intero ciclo di vita del sistema, comprensivo di test in condizioni realistiche e di misure di mitigazione residua. La documentazione deve essere coerente con la natura specifica del sistema: un modello di credit scoring richiede analisi dei rischi differenti da un modello di triage sanitario.

2. Governance dei dati di addestramento (articolo 10). Datasets di training, validation e test che soddisfano criteri di pertinenza, rappresentatività, accuratezza e completezza. Il fornitore deve documentare l'origine dei dati, le scelte di campionamento, le tecniche di annotazione, le verifiche su distorsioni (bias) e gli interventi di mitigazione. Per la PA italiana questo si intreccia con il GDPR e con le Linee guida dell'Agenzia per l'Italia Digitale (AgID) sull'uso di basi dati pubbliche.

3. Documentazione tecnica (articolo 11 e Allegato IV). È il dossier che descrive il sistema in tutti i suoi aspetti: scopo, architettura, componenti, requisiti hardware e software, metriche di performance, limiti noti, istruzioni di integrazione, procedure di test. Deve essere mantenuto aggiornato e disponibile alle autorità di vigilanza per dieci anni dopo l'immissione sul mercato.

4. Logging automatico (articolo 12). Il sistema deve registrare automaticamente eventi che consentano di ricostruire il funzionamento durante l'uso, con un livello di dettaglio appropriato allo scopo, sufficiente a identificare situazioni che possono comportare rischi per la salute, la sicurezza o i diritti fondamentali. I log devono essere conservati per un periodo coerente con la finalità d'uso (tipicamente almeno sei mesi, con estensioni nei contesti più sensibili).

5. Trasparenza e istruzioni d'uso (articolo 13). Il sistema deve essere accompagnato da istruzioni d'uso comprensibili che descrivano scopi, capacità, limiti, livello di accuratezza atteso, robustezza, potenziali rischi, requisiti di supervisione umana, manutenzione e calibrazione. Per la PA è il documento operativo che il deployer userà per impostare la propria istruzione organizzativa interna.

6. Supervisione umana (articolo 14). Il sistema deve essere progettato per consentire una supervisione umana effettiva da parte di persone fisiche durante l'uso, con la possibilità concreta di sovrascrivere o disattivare l'output del sistema. Questo è il punto in cui il fornitore deve dimostrare di aver progettato per la supervisione, non solo di averla raccomandata: interfacce con override visibile, tempi di risposta umana realistici, formazione per gli operatori.

7. Accuratezza, robustezza, cybersicurezza (articolo 15). Livelli appropriati di prestazione documentati, resistenza a errori, guasti e tentativi di manipolazione (data poisoning, adversarial attacks), procedure di backup e ripristino. La documentazione deve riportare le metriche concrete e le condizioni nelle quali sono state misurate.

8. Conformity assessment (articoli 43-44). Prima dell'immissione sul mercato, il sistema ad alto rischio deve passare una valutazione di conformità. Per la maggior parte dei sistemi dell'Allegato III è ammessa l'autovalutazione del provider; per alcuni casi (in particolare biometrici e prodotti regolati dall'Allegato I) è richiesta la valutazione da parte di un organismo notificato. L'esito si concretizza nella dichiarazione UE di conformità (articolo 47) e nell'apposizione del marchio CE sul prodotto o sulla documentazione che lo accompagna (articolo 48).

9. Registrazione nella banca dati UE (articolo 49). I sistemi ad alto rischio elencati nell'Allegato III devono essere registrati nella banca dati pubblica UE prima dell'immissione sul mercato. La registrazione contiene una scheda informativa pubblica e identifica il provider responsabile.

10. Sistema di qualità (articolo 17). Il fornitore deve adottare un sistema di gestione della qualità documentato, proporzionato alle dimensioni dell'organizzazione, che copra tutto il ciclo di vita del sistema. La certificazione ISO/IEC 42001 costituisce ad oggi il riferimento più solido per dimostrare conformità a questo obbligo, ed è già richiesta come elemento premiante in diverse gare PA.

11. Monitoraggio post-commercializzazione (articolo 72). Dopo l'immissione sul mercato il fornitore deve monitorare le prestazioni del sistema in uso, raccogliere segnalazioni di malfunzionamenti, e segnalare incidenti gravi alle autorità competenti entro tempistiche definite (15 giorni per incidenti gravi, 2 giorni per violazioni diffuse).

12. Cooperazione con le autorità (articolo 21). Il fornitore deve fornire alle autorità di vigilanza (in Italia AESIA o Garante Privacy a seconda dell'ambito) tutte le informazioni e la documentazione necessaria a dimostrare la conformità, su richiesta.

In gara, questi obblighi diventano tutti elementi documentali. Un capitolato tecnico ben scritto chiede al concorrente di allegare: dichiarazione UE di conformità, riferimento alla registrazione nella banca dati UE, riassunto del fascicolo tecnico, certificato ISO/IEC 42001 (se posseduto), descrizione del sistema di gestione dei rischi, descrizione delle misure di supervisione umana, piano di monitoraggio post-commercializzazione, garanzie sui livelli di servizio (SLA) per la disponibilità dei log e la collaborazione con le autorità.

Obblighi del deployer pubblico: articoli 26 e 27

Il "deployer" è chi usa il sistema sotto la propria autorità. Le pubbliche amministrazioni italiane sono deployer per definizione, e l'articolo 26 dell'AI Act fissa una serie di obblighi che entrano in vigore al 2 agosto 2026 e che le stazioni appaltanti devono già oggi prevedere come capacità organizzativa.

Obblighi dell'articolo 26 (deployer di sistemi ad alto rischio):

Adottare misure tecniche e organizzative appropriate per garantire che il sistema sia usato secondo le istruzioni d'uso del fornitore. Tradotto: la PA non può usare il sistema in modi non documentati senza assumersi responsabilità da provider.
Affidare la supervisione umana a persone fisiche qualificate, formate e dotate dell'autorità necessaria. Questo è il punto di contatto diretto con l'obbligo di alfabetizzazione AI dell'articolo 4, già in vigore dal 2 febbraio 2025.
Assicurare che i dati di input siano pertinenti e sufficientemente rappresentativi per la finalità d'uso, nei limiti del controllo del deployer.
Monitorare il funzionamento del sistema sulla base delle istruzioni d'uso e segnalare al fornitore o al distributore eventuali rischi rilevati. In caso di incidente grave, segnalare anche all'autorità di vigilanza entro le tempistiche previste.
Conservare i log generati automaticamente dal sistema per un periodo appropriato alla finalità (almeno sei mesi, di norma più a lungo nel contesto pubblico).
Informare il personale interessato (lavoratori e loro rappresentanti) prima di mettere in servizio un sistema AI ad alto rischio sul luogo di lavoro.
Informare le persone fisiche soggette alle decisioni del sistema. Quando il sistema produce effetti giuridici o significativi, l'interessato ha diritto a una spiegazione chiara e significativa.

Obblighi dell'articolo 27 (Fundamental Rights Impact Assessment, FRIA). Per le PA che usano sistemi AI ad alto rischio dell'Allegato III in alcuni ambiti specifici (servizi pubblici essenziali, servizi privati essenziali quando erogati da soggetti pubblici, scoring del rischio creditizio per persone fisiche), prima del primo uso è obbligatorio condurre una valutazione d'impatto sui diritti fondamentali. La FRIA descrive: la finalità del sistema, il periodo e la frequenza d'uso, le categorie di persone interessate, i rischi specifici per i diritti fondamentali, le misure di supervisione umana, le misure di mitigazione e di rimedio in caso di pregiudizio. La FRIA va trasmessa all'autorità di vigilanza prima dell'uso e mantenuta aggiornata.

In Italia, la FRIA si sovrappone parzialmente con la valutazione d'impatto sulla protezione dei dati (DPIA) richiesta dal GDPR. La prassi che si sta consolidando, anche grazie alle indicazioni del Garante e alle prime linee guida AESIA, è di condurre una valutazione integrata che soddisfi entrambi i requisiti, distinguendo chiaramente la sezione sui diritti fondamentali (più ampia: dignità, non discriminazione, libertà, accesso alla giustizia) dalla sezione sui dati personali.

Documentazione di gara: cosa scrivere e cosa chiedere

La conformità AI Act diventa concreta nei tre documenti chiave della procedura: bando, capitolato tecnico, contratto.

Nel bando di gara (e nel disciplinare). Inserire il riferimento normativo (Regolamento UE 2024/1689 e Legge 132/2025) e indicare se il sistema oggetto della gara è classificato come ad alto rischio ai sensi dell'Allegato III, con la motivazione. Specificare se la conformità AI Act è requisito di partecipazione (causa di esclusione se assente) o elemento di valutazione qualitativa (punteggio premiante). Per i sistemi che ricadono nell'Allegato III è di norma corretto trattarla come requisito di partecipazione: chi non è conforme non può legalmente fornire alla PA dopo agosto 2026.

Nel capitolato tecnico. È il documento operativo. Deve includere almeno:

Descrizione tecnica del bisogno con classificazione di rischio motivata.
Lista della documentazione AI Act che il fornitore deve allegare all'offerta (dichiarazione UE di conformità, riassunto del fascicolo tecnico ai sensi dell'Allegato IV, riferimento di registrazione nella banca dati UE, istruzioni d'uso secondo articolo 13, descrizione delle misure di supervisione umana, piano di monitoraggio post-commercializzazione).
Specifiche sui dati: origine, qualità, aggiornamento, gestione di datasets PA forniti dal committente.
Requisiti di logging: contenuto minimo dei log, formato, durata di conservazione, accessibilità per il deployer.
Requisiti di explainability adeguati al contesto: il fornitore deve fornire al deployer le informazioni necessarie a soddisfare gli obblighi di informativa verso il cittadino.
Requisiti SLA su accuratezza, latenza, disponibilità, e tempi di risposta in caso di richieste delle autorità di vigilanza.
Procedure di handover e documentazione operativa per la fase di esecuzione.
Obbligo di aggiornamento documentale lungo tutta la durata contrattuale: ogni versione del sistema rilasciata implica aggiornamento della documentazione tecnica e, se materiale, una nuova valutazione di conformità.

Nel contratto. Inserire clausole specifiche che riflettano la ripartizione di responsabilità AI Act tra provider e deployer:

Clausola di garanzia di conformità AI Act per tutta la durata contrattuale, con obbligo del fornitore di adeguarsi a evoluzioni normative, atti delegati e standard armonizzati che dovessero intervenire.
Clausola di accesso del deployer al fascicolo tecnico e alla documentazione di test, anche in forma controllata, per supportare le proprie verifiche.
Clausola di cooperazione del fornitore con le autorità (AESIA, Garante Privacy) su richiesta del deployer.
Clausola di notifica obbligatoria al deployer di incidenti gravi entro tempistiche più stringenti dell'articolo 73 (per esempio 24 ore), per consentire al deployer di rispettare i propri obblighi di segnalazione.
Clausola di indennizzo specifica per sanzioni AI Act derivanti da non conformità del sistema.
Diritto di audit del deployer (anche tramite terzi indipendenti) sul sistema di gestione della qualità del fornitore.
Clausola di reversibilità dei dati e dei log a fine contratto, per consentire la migrazione e mantenere la conservazione documentale richiesta.

Per la PA italiana esiste un modello operativo già consolidato di fornitura digitale via convenzioni Consip e MePA. Le centrali di committenza stanno aggiornando i propri capitolati standard per includere requisiti AI Act, e per le procedure dirette restano applicabili le stesse logiche che spieghiamo nella nostra guida compilazione automatica di gare Consip con AI e in quella su risposta a gare MePA assistita da AI — strumenti che, va sottolineato, devono essi stessi essere conformi all'AI Act se vengono usati per supportare decisioni che incidono sull'esito di una gara.

Sanzioni: gerarchia e applicazione in Italia

L'articolo 99 dell'AI Act fissa una gerarchia di sanzioni amministrative che gli Stati membri devono recepire e che entreranno in vigore dal 2 agosto 2026 per la gran parte degli illeciti, dal 2 febbraio 2025 per le pratiche vietate.

Pratiche vietate (articolo 5): fino a 35 milioni di euro o il 7% del fatturato mondiale annuo, se superiore. È la fascia più alta, riservata a comportamenti come social scoring, manipolazione subliminale, riconoscimento emotivo sul luogo di lavoro o nelle scuole, scraping non mirato di volti per database biometrici.
Violazione degli obblighi su sistemi ad alto rischio (articoli 8-49 per i provider, 26-27 per i deployer): fino a 15 milioni di euro o il 3% del fatturato mondiale annuo, se superiore.
Informazioni false, incomplete o fuorvianti alle autorità di vigilanza: fino a 7,5 milioni di euro o l'1% del fatturato mondiale.

Per le PMI e le start-up il regolamento prevede che si applichi il valore inferiore tra la cifra fissa e la percentuale di fatturato, con possibilità per gli Stati di prevedere ulteriori mitigazioni proporzionate. La Legge 132/2025 italiana ha confermato l'impianto sanzionatorio europeo, articolando le competenze: AESIA per le sanzioni relative a sistemi ad alto rischio in ambiti diversi dalla protezione dati, Garante Privacy per le violazioni che riguardano biometria, lavoro, dati sensibili e accesso a servizi pubblici essenziali quando coinvolgono trattamento di dati personali. Il Garante ha confermato (provvedimento di indirizzo del 2025) che la sanzione AI Act è autonoma rispetto a quella GDPR: lo stesso fatto può configurare un illecito sotto entrambi i regolamenti, con cumulo di procedimenti e sanzioni.

Per il contesto specifico degli appalti pubblici, l'effetto delle sanzioni si propaga anche al Codice Appalti: una sanzione AI Act per non conformità grave può integrare un grave illecito professionale ai sensi dell'articolo 95 del Codice, attivabile come causa di esclusione da future gare. È un'ulteriore ragione per cui chiunque venda alla PA deve trattare la conformità come un asset, non come un costo.

Audit trail e tracciabilità: la spina dorsale operativa

Tutto quello che abbiamo descritto si regge su una capacità trasversale: la tracciabilità. AI Act, GDPR e Codice Appalti convergono sullo stesso principio: ciò che non è documentato non è dimostrabile, e ciò che non è dimostrabile è esposto a sanzione.

Per fornitori e deployer questo significa adottare un'architettura di audit trail strutturata, non un mero archivio di file. Le componenti minime sono:

Registrazione automatica e versionata del sistema AI: ogni versione del modello, ogni dataset di training, ogni test di validazione deve avere un identificatore univoco e una data certa.
Log operativi con conservazione coerente con la finalità d'uso e con l'articolo 12 dell'AI Act, archiviati in modo immodificabile (write-once o equivalente).
Tracciatura delle decisioni umane di supervisione: quando un operatore PA sovrascrive un output del sistema, l'evento deve essere registrato con motivazione.
Documentazione della conformità di gara: collegamento esplicito tra l'offerta del fornitore (e gli allegati AI Act) e l'esecuzione contrattuale, in modo che alla fine del contratto sia ricostruibile cosa il fornitore ha promesso, cosa ha consegnato, e quali deviazioni ci sono state.
Pista di controllo per l'aggiornamento normativo: ogni atto delegato della Commissione, ogni standard armonizzato, ogni guideline AESIA o Garante che incide sul sistema deve essere tracciato e tradotto in un task di adeguamento documentato.

Le PA che già operano sotto regimi di tracciabilità avanzata (sanità per il fascicolo sanitario elettronico, fiscale per la fatturazione elettronica, sicurezza per i registri di audit) hanno un vantaggio organizzativo: stanno integrando la layer AI sopra un'infrastruttura di compliance già esistente. Per chi parte da zero, lo sforzo è significativo ed è il principale motivo per cui la nostra checklist di conformità AI 2026 raccomanda di iniziare il lavoro almeno dodici mesi prima della scadenza applicabile.

AESIA, Garante Privacy, AgID: chi fa cosa

La governance italiana sull'AI Act è plurale per scelta legislativa. Per evitare confusione, ecco la mappa delle competenze rilevanti per gli appalti pubblici aggiornata ad aprile 2026:

AESIA — Agenzia per l'Intelligenza Artificiale. Autorità di vigilanza per i sistemi AI ad alto rischio in ambiti diversi dalla protezione dei dati personali. Competente sulla certificazione, sulla notifica degli organismi di valutazione di conformità, sul registro nazionale di applicazioni AI ad alto rischio in uso nel settore pubblico, sull'irrogazione delle sanzioni AI Act per i casi di sua competenza. È il principale interlocutore della PA per ottenere chiarimenti e segnalare incidenti gravi non legati a dati personali.
Garante per la Protezione dei Dati Personali. Autorità di vigilanza AI Act in tutti gli ambiti in cui il sistema tratta dati personali, in particolare biometria, sistemi sul luogo di lavoro, sistemi che incidono su servizi pubblici essenziali. Resta inoltre l'autorità competente per il GDPR su tutti i trattamenti di dati personali. Le PA che acquistano sistemi che processano dati di cittadini hanno il Garante come interlocutore primario.
AgID — Agenzia per l'Italia Digitale. Non è autorità di vigilanza AI Act, ma resta competente sulle Linee guida di interoperabilità, sulle Linee guida per il design dei servizi pubblici digitali, sull'accreditamento dei fornitori di servizi cloud per la PA. Le sue Linee guida sull'uso dell'AI nella PA, in via di consolidamento, costituiscono il principale strumento operativo per orientare le stazioni appaltanti nella scrittura di capitolati.
ANAC — Autorità Nazionale Anticorruzione. Vigila sull'applicazione del Codice dei Contratti Pubblici e quindi anche sulla coerenza tra le procedure di gara e gli obblighi normativi sostanziali, AI Act incluso. ANAC sta lavorando a bandi-tipo aggiornati che includano clausole AI Act standardizzate.
Organismi notificati. Per i pochi casi in cui l'AI Act richiede valutazione di conformità da parte di terzi (sistemi biometrici, sistemi integrati in prodotti regolati dall'Allegato I), la notifica avviene tramite AESIA e si appoggia agli organismi accreditati Accredia secondo gli standard armonizzati che la Commissione UE pubblicherà progressivamente.

Cosa fare adesso: piano operativo

Per il fornitore che vuole presentarsi a gare PA dal 2026 con un dossier AI Act solido:

Mappare il portafoglio prodotti rispetto alle categorie dell'Allegato III. Sapere quali sistemi sono ad alto rischio e quali no è il primo gate.
Costruire il fascicolo tecnico secondo l'Allegato IV per ogni sistema ad alto rischio, con un proprietario unico responsabile dell'aggiornamento.
Avviare il percorso ISO/IEC 42001 anche se non obbligatoria, perché diventa il passport più riconoscibile in gara e copre l'articolo 17 (sistema di qualità).
Implementare il logging in linea con l'articolo 12, prima ancora che venga richiesto da una specifica gara.
Predisporre la dichiarazione UE di conformità in formato standard, pronta da allegare alle offerte.
Aggiornare i template contrattuali con clausole AI Act compatibili con i contratti standard PA.
Formare le persone che presidiano l'offerta tecnica, perché un commerciale che non sa rispondere su FRIA o supervisione umana fa fallire la gara.

Per la stazione appaltante che deve bandire una procedura per un sistema AI dopo agosto 2026:

Classificare il sistema in modo motivato nel capitolato (Allegato III sì o no, e perché).
Predisporre la FRIA in parallelo al capitolato, prima dell'aggiudicazione, integrata con la DPIA quando ricorrono dati personali.
Definire la struttura di supervisione umana prima di scrivere i requisiti tecnici: chi controlla, con quale potere, con quale formazione.
Inserire i requisiti documentali AI Act come causa di esclusione e/o elemento valutativo, con allegati tecnici da fornire all'offerta.
Definire SLA contrattuali che riflettano gli obblighi del deployer (tempi di accesso ai log, tempi di notifica incidenti, supporto alle autorità).
Pianificare il monitoraggio post-aggiudicazione con metriche misurabili e con un calendario di verifica della conformità (almeno annuale, più frequente in ambiti sensibili).
Iscrivere l'uso del sistema nel registro nazionale che AESIA renderà disponibile, una volta operativo.

L'AI Act non è più una cornice astratta: dal 2 agosto 2026 è una variabile di gara quanto la garanzia provvisoria o il PassOE. Trattarla con la stessa serietà è oggi la differenza tra un fornitore che vincerà commesse PA nei prossimi anni e uno che resterà fuori. Per la PA, è la differenza tra un'amministrazione che adotta AI in modo difendibile davanti al cittadino e una che si espone a contenziosi e sanzioni cumulate.

La complessità è reale. La buona notizia è che il quadro normativo, pur articolato, è oggi sufficientemente stabile per costruirci sopra. Quello che serve è un metodo: classificare, documentare, tracciare, aggiornare. È il metodo che applichiamo nella nostra guida completa all'EU AI Act per le aziende e che traduciamo in pratica nelle procedure di gara per i clienti che assistiamo. La conformità AI Act non è un punto di arrivo, è una pratica continua. Negli appalti pubblici italiani, da aprile 2026 in poi, è anche una condizione di accesso al mercato.