La consultazione pubblica è attiva dal 12/03/2026 al 11/04/2026.
Questo argomento accoglie i commenti relativi allo Strumento B - Schema di Capitolato Tecnico.
I commenti dovranno includere il numero del paragrafo o sotto-paragrafo (se presente) e un riferimento puntuale al brano di testo al quale si riferiscono (ad esempio paragrafo 4.3, terzo capoverso).
Strumento B - Schema di Capitolato Tecnico
Osservazione. Questo strumento può avere un impatto applicativo molto elevato.
Proposta di integrazione. Si suggerisce di includere in modo esplicito, nello schema di capitolato, sezioni dedicate a orchestratore, modelli, dati, logiche di aggiornamento, livelli di servizio, logging, sicurezza, audit, portabilità, formazione, affiancamento e condizioni di uscita o subentro.
Osservazione. I casi di GenAI e di sistemi composti meritano un presidio contrattuale più specifico.
Proposta di integrazione. Si suggerisce di prevedere clausole-tipo dedicate a sistemi basati su GenAI, servizi a consumo, componenti di terze parti, architetture composte e dipendenze da API esterne, così da aiutare le PA a governare meglio costi, trasparenza, responsabilità e lock-in tecnologico.
Il CSIG (Centro studi di informatica giuridica di Ivrea e Torino, al fine di garantire il rispetto del divieto di sorveglianza dei lavoratori previsto dall’art. 4 dello Statuto dei lavoratori, suggerisce di inserire le seguenti clausole tipo per il Procurement (Riferimento Tabella 1):
• “Il Fornitore DEVE garantire e certificare l’assenza di funzionalità di monitoraggio della performance lavorativa individuale o di analisi comportamentale nel codice e nelle logiche dell’Orchestratore.”
• “La PA si riserva il diritto di audit sui criteri di feature extraction dei modelli per verificare la conformità all’art. 8 L. 300/1970.”
Il CSIG (Centro studi di informatica giuridica di Ivrea e Torino, con riferimento ai casi nei quali attraversi sistemi di IA vengano trattati dati personali, suggerisce di richiamare l’obbligo di designare il fornitore del sistema quale responsabile del trattamento di dati personali previsto dall’art. 28 del GDPR.
Inoltre, suggerisce di prevedere i seguenti requisiti Minimi per i Capitolati:
• Restituzione integrale: Obbligo di consegna di tutti i dati generati (output e metadati) in formati aperti e interoperabili al termine del contratto.
• Portabilità tecnica: Garanzia di migrazione dei dataset verso altre infrastrutture senza oneri ingiustificati.
• Divieto di riuso non autorizzato: Clausole che impediscano al fornitore di utilizzare dati della PA per addestrare modelli esterni al servizio affidato.
Confintesa FP — Federazione Funzione Pubblica (organizzazione sindacale maggiormente rappresentativa nel Comparto Funzioni Centrali) presenta le seguenti osservazioni nell’ambito della consultazione pubblica (Determinazione AgID n. 43 del 10 marzo 2026). Il testo integrale delle osservazioni sarà trasmesso formalmente ad AgID.
OSSERVAZIONE — Clausola sociale e obblighi lavoristici nel capitolato tipo
Lo schema di capitolato tecnico non include clausole relative all’impatto del sistema di IA sul personale della PA committente, né obblighi informativi verso i dipendenti che utilizzeranno il sistema. In assenza di tali clausole, il fornitore non è tenuto a documentare le mansioni impattate né a garantire il trasferimento di conoscenze al personale PA. Il principio accolto al cap. 3 in materia di clausole sociali resta privo di effetto operativo se non tradotto nel template contrattuale.
L’art. 57 del D.Lgs. 36/2023 e l’art. 26, par. 7, del Reg. (UE) 2024/1689 costituiscono la base giuridica per l’inserimento di tali prescrizioni nel capitolato tipo.
Proposta di integrazione allo Schema di Capitolato Tecnico:
Inserire una sezione «Impatto sul personale e obblighi lavoristici» con le seguenti clausole obbligatorie per i sistemi di IA che incidano sull’organizzazione del lavoro:
– Il fornitore DEVE fornire, prima della messa in produzione, documentazione dettagliata sulle mansioni del personale PA impattate dal sistema, aggiornata in caso di modifiche sostanziali.
– Il fornitore DEVE garantire il trasferimento di conoscenze tramite sessioni formative congiunte con il personale PA designato, con attestazione della partecipazione.
– Il fornitore NON DEVE raccogliere, elaborare o trasferire a terzi dati comportamentali dei dipendenti della PA committente per finalità proprie.
– Il fornitore DEVE fornire documentazione tecnica sufficiente a consentire l’esercizio del diritto alla spiegazione (art. 86 Reg. UE 2024/1689) in relazione alle decisioni adottate con il supporto del sistema.
– La PA committente DEVE notificare al fornitore l’istituzione del Comitato paritetico per l’IA e trasmettere al Comitato le modifiche sostanziali proposte dal fornitore prima della loro implementazione.
Confintesa FP — Segretario Generale Claudia Ratti | www.confintesafp.it
Art. 12 “Sicurezza e robustezza” richiama “manipolazione dei dati di addestramento, attacchi adversarial, estrazione del modello o uso improprio dei sistemi generativi” e un “piano di gestione delle vulnerabilità”; Art. 16 disciplina il monitoraggio post-deployment; Art. 19 prevede verifiche di conformità anche “in occasione di aggiornamenti rilevanti del sistema o dei modelli”; Art. 20 regola penali e responsabilità; gli Allegati D, F e G strutturano rispettivamente rischi, collaudo e livelli di servizio.
Lo schema mostra una chiara consapevolezza delle minacce specifiche per l’IA, ma non traduce tale consapevolezza in un obbligo autonomo, esplicito e verificabile di attività di red-teaming adversarial sul sistema di IA. Manca infatti la disciplina delle sue occorrenze, pre-collaudo, periodiche e a evento, nonché il collegamento espresso tra esito del red-teaming, accettazione della fornitura, monitoraggio post-deployment, penali e indicatori di servizio. Il riferimento di Art. 19 agli “aggiornamenti rilevanti” costituisce un aggancio già presente nel testo, ma resta privo di contenuto operativo sul fronte avversariale. In coerenza con i commenti alle Linee guida procurement, il red-teaming dovrebbe diventare un requisito di capitolato esplicito, proporzionato al rischio e verificabile contrattualmente.
Raccomandazione: integrare lo Schema di Capitolato Tecnico come segue:
(a) Art. 12 – Sicurezza e robustezza: inserire un comma autonomo che richieda al Fornitore l’esecuzione di attività di red-teaming adversarial sul sistema di IA oggetto di fornitura, condotte secondo metodologie riconosciute e ampiamente utilizzate, tra cui OWASP GenAI Red Teaming Guide, NIST AI 100-2, NIST AI 600-1 e MITRE ATLAS, con copertura almeno di prompt injection diretta e indiretta, jailbreak, bypass delle guardrail, abuso di tool/connettori, attacchi a pipeline RAG, estrazione di modello e di dati, e scenari dominio-specifici coerenti con l’uso previsto.
(b) Art. 16 – Monitoraggio post-deployment: estendere il monitoraggio per includere red-teaming periodico e a evento, con eventi trigger minimi quali aggiornamento del modello o delle sue versioni, modifica del system prompt, aggiunta o rimozione di tool/connettori, variazione del corpus RAG, nuovo fine-tuning, modifica delle guardrail o introduzione di nuove finalità d’uso. Gli esiti dovrebbero confluire nei report periodici già previsti.
(c) Art. 19 – Verifica di conformità: qualificare il red-teaming pre-collaudo come condizione di accettazione della fornitura e, in coerenza con il rinvio del testo agli “aggiornamenti rilevanti”, come condizione di ri-accettazione delle modifiche significative. I rilievi critici non sanati dovrebbero precludere il buon esito del collaudo o della nuova verifica.
(d) Art. 20 – Penali e responsabilità: prevedere penali specifiche per mancata esecuzione nei tempi, mancata remediation dei rilievi critici entro i termini concordati, e omessa o tardiva notifica di vulnerabilità significative emerse dalle attività di red-teaming.
(e) Allegato D – Matrice di gestione del rischio: includere, tra gli scenari tipizzati, le famiglie di minacce avversariali sopra richiamate, così da vincolarne la copertura anche nella fase di offerta.
(f) Allegato F – Matrice di collaudo: aggiungere una riga dedicata al red-teaming pre-collaudo, con evidenza documentale richiesta, piano, report e stato dei rilievi, come requisito di verifica.
(g) Allegato G – Matrice KPI/SLA: introdurre indicatori minimi relativi a tempestività di esecuzione del red-teaming a evento, tempi di remediation per severità ed esito dei re-test dopo mitigazione.
Requisiti di indipendenza del fornitore di red-teaming e criteri premiali di specializzazione sono trattati nei commenti al thread principale delle Linee guida procurement, cui si rinvia.
Contributo a cura di Traent Srl.
Si propone di integrare lo Schema di Capitolato Tecnico con una sezione autonoma dedicata all’infrastruttura di verifica e certificazione della conformità: (a) Art. 12 – Sicurezza e robustezza: aggiungere un comma che richieda la registrazione degli esiti di ogni verifica di sicurezza (inclusi audit, vulnerability assessment e red-teaming) su infrastruttura di notarizzazione indipendente, con marcatura temporale certificata e garanzia di integrità crittografica, producendo evidenze non ripudiabili e opponibili a terzi. Tale requisito è complementare all’obbligo di red-teaming già proposto da altri commentatori: il red-teaming definisce cosa verificare, l’infrastruttura di notarizzazione garantisce che i risultati siano affidabili. (b) Art. 16 – Monitoraggio post-deployment: estendere i report periodici richiedendo che ogni milestone di monitoraggio sia accompagnata da registrazione notarizzata, creando una cronologia certificata dell’intero ciclo di vita operativo. (c) Art. 19 – Verifica di conformità: qualificare la verifica come processo che produce evidenze certificate, base probatoria in caso di contenzioso. (d) Art. 20 – Penali e responsabilità: prevedere che le contestazioni si fondino su evidenze certificate e non ripudiabili, eliminando l’asimmetria informativa PA-fornitore. (e) Nuovo Allegato – Infrastruttura di fiducia e verificabilità: definire requisiti minimi dell’infrastruttura di notarizzazione (indipendenza dal fornitore, marcatura temporale qualificata, interoperabilità, conformità eIDAS 2.0), tipologie di evidenze da registrare e formati di esportazione per garantire la portabilità del registro di conformità in caso di cambio fornitore.
Questo argomento è stato automaticamente chiuso dopo 26 giorni. Non sono permesse altre risposte.