# Capitolato tecnico per la gara di un gateway LLM o di una piattaforma di IA

Aggiornato il 9 novembre 2026. Libero da copiare, modificare e usare nei vostri documenti di gara.

Un'azienda o un ente pubblico che acquista accesso ai modelli linguistici di grandi dimensioni per il personale e le applicazioni acquista di solito un gateway: un account e un'API davanti a più fornitori di modelli. Questo capitolato elenca 43 requisiti per questo acquisto, raggruppati nell'ordine in cui li affronta una verifica di sicurezza e di procurement. Per ogni requisito indica perché conta e quale prova chiedere all'offerente.

È neutrale rispetto al fornitore e funziona come allegato tecnico per una richiesta di offerta, una gara pubblica o una valutazione di sicurezza dei fornitori. Per le condizioni contrattuali specifiche dell'IA, abbinatelo alle clausole contrattuali tipo dell'UE per l'IA (MCC-AI) (https://public-buyers-community.ec.europa.eu/communities/procurement-ai/resources/updated-eu-ai-model-contractual-clauses), volontarie, pubblicate nel marzo 2025 sulla Public Buyers Community della Commissione europea.

Ogni requisito è formulato in modo che l'offerente possa rispondere in un paragrafo e allegare la prova. Segnate quelli obbligatori per voi, pesate gli altri ed eliminate ciò che non si applica.

## 1. Ubicazione dei dati

| Obbligatorio | N. | Requisito | Perché conta | Prova da richiedere |
| --- | --- | --- | --- | --- |
| [ ] | 1 | Regione di trattamento. Il fornitore può limitare l'inferenza a una regione indicata dalla stazione appaltante, come UE/SEE o Europa, per l'intera organizzazione, un team o una singola chiave API, compresi nuovi tentativi e fallback. | I gateway passano da un fornitore all'altro in caso di guasto. Senza una regola di regione che copra ogni tentativo, un fallback può spostare un prompt in un'altra giurisdizione senza che nessuno se ne accorga. | La politica di instradamento per il traffico limitato, gli endpoint ammessi per ogni regione con la loro ubicazione e cosa accade quando nessun endpoint della regione può servire una richiesta. |
| [ ] | 2 | Definizione della regione. Il fornitore indica quali paesi comprende ogni regione, per esempio solo UE/SEE, oppure anche Regno Unito, Svizzera o altri paesi. | I materiali commerciali usano spesso Europa e UE come sinonimi. La vostra valutazione dei trasferimenti dipende dall'elenco esatto. | Una definizione scritta di ogni regione e il luogo di trattamento di ciascun sub-responsabile che ne fa parte. |
| [ ] | 3 | Ubicazione dell'ingresso e del gateway. Il fornitore indica dove termina TLS, dove gira il gateway e quale nome host usare per il trattamento regionale. | Una richiesta può essere servita da un modello nella regione giusta e passare comunque prima per una rete edge globale. | I nomi host per regione, il fornitore di hosting e la regione del load balancer e del gateway, e un diagramma del flusso dei dati. |
| [ ] | 4 | Ubicazione di metadati e log. Il fornitore indica dove sono conservati e trattati dati dell'account, registrazioni d'uso, log operativi, backup ed email. | Le risposte sulla residenza dei dati riguardano spesso solo i prompt. Anche i metadati contengono dati personali come nomi, indirizzi email e indirizzi IP. | Un luogo di conservazione per ogni categoria di dati, compresi backup ed email transazionali. |

## 2. Durata di conservazione e conservazione zero dei dati

| Obbligatorio | N. | Requisito | Perché conta | Prova da richiedere |
| --- | --- | --- | --- | --- |
| [ ] | 5 | Nessuna conservazione dei contenuti da parte del fornitore. Il fornitore tratta prompt e output solo per servire la richiesta, oppure indica esattamente quali contenuti conserva, dove e per quanto tempo. | Il gateway vede ogni prompt inviato dalla vostra organizzazione. La sua conservazione è la prima esposizione da verificare. | Una descrizione del flusso dei dati, lo schema dei log con i campi scritti e la clausola corrispondente dell'accordo sul trattamento dei dati. |
| [ ] | 6 | Conservazione zero dei dati presso i fornitori di modelli. La stazione appaltante può esigere che le richieste vadano solo a endpoint di modelli che si impegnano a non conservare alcuna copia dei contenuti, a livello di organizzazione, team o chiave, senza che i livelli inferiori possano disattivarlo. | I fornitori di modelli conservano di norma i prompt per un periodo a fini di monitoraggio degli abusi, salvo che per l'endpoint valga un accordo di conservazione zero. | Le condizioni di conservazione di ogni fornitore, come l'impostazione viene applicata a ogni richiesta e quali funzioni sono disattivate mentre è attiva. |
| [ ] | 7 | Funzioni che conservano contenuti. Il fornitore elenca ogni funzione che conserva contenuti (caching dei prompt, risposte memorizzate, stato della conversazione, file, job batch) con il periodo di conservazione e l'impostazione che la disattiva. | Gli impegni di conservazione prevedono di solito eccezioni per alcune funzioni. L'elenco mostra dove si trovano. | Un elenco delle funzioni con il periodo di conservazione di ciascuna e il controllo che la disattiva. |
| [ ] | 8 | Cancellazione a fine contratto. Il fornitore cancella o restituisce i dati della stazione appaltante entro un termine stabilito dopo la fine del servizio e lo conferma per iscritto. | L'articolo 28, paragrafo 3, lettera g), del GDPR richiede che il contratto con il responsabile del trattamento disciplini la cancellazione o la restituzione al termine della prestazione dei servizi. | La clausola dell'accordo sul trattamento dei dati con il termine, la gestione dei backup e un esempio di conferma di cancellazione. |

## 3. Addestramento e uso dei dati

| Obbligatorio | N. | Requisito | Perché conta | Prova da richiedere |
| --- | --- | --- | --- | --- |
| [ ] | 9 | Nessun addestramento da parte del fornitore. Il fornitore non usa prompt, output o metadati per addestrare o migliorare modelli. | L'addestramento è l'uso che gli acquirenti escludono più spesso, e l'esclusione vincola solo se è nel contratto. | La clausola del contratto o dell'accordo sul trattamento dei dati e la sezione corrispondente dell'informativa privacy. |
| [ ] | 10 | Nessun addestramento da parte dei fornitori di modelli. Il fornitore instrada il traffico della stazione appaltante solo verso fornitori che si impegnano a non usarlo per l'addestramento, e spiega come ciò viene applicato a ogni richiesta. | L'impegno del gateway non vincola i fornitori di modelli che stanno dietro. | Le condizioni di ogni fornitore per endpoint, il meccanismo di applicazione e il traffico che copre. |
| [ ] | 11 | Altri usi secondari. Il fornitore indica se contenuti o metadati sono usati per analisi, benchmark, miglioramento del prodotto o revisione umana, e come opporsi. | Gli usi secondari restano fuori dalle istruzioni che un titolare del trattamento dà a un responsabile, salvo che siano concordati. | Un elenco degli usi secondari, la politica di revisione umana e l'impostazione per opporsi. |

## 4. Sub-responsabili e accordo sul trattamento dei dati

| Obbligatorio | N. | Requisito | Perché conta | Prova da richiedere |
| --- | --- | --- | --- | --- |
| [ ] | 12 | Accordo sul trattamento dei dati. Un accordo ai sensi dell'articolo 28 del GDPR è disponibile prima della firma e disciplina materia, durata, istruzioni, riservatezza, sicurezza, assistenza, cancellazione e audit. | L'articolo 28, paragrafo 3, elenca ciò che il contratto con il responsabile del trattamento deve contenere. Un gateway tratta dati personali in ogni prompt che menziona una persona. | Il testo dell'accordo, la legge applicabile e le modalità di firma. |
| [ ] | 13 | Elenco dei sub-responsabili. Il fornitore pubblica ogni sub-responsabile del trattamento con la finalità, i dati trattati e l'ubicazione, compresi i fornitori di modelli e di inferenza. | In un gateway, ogni fornitore di modelli che può servire il vostro traffico è un sub-responsabile. | L'URL dell'elenco e la data dell'ultima modifica. |
| [ ] | 14 | Preavviso di nuovi sub-responsabili. Il fornitore dà un preavviso di durata stabilita prima di aggiungere o sostituire un sub-responsabile, con diritto di opposizione. | L'articolo 28, paragrafo 2, richiede che il titolare del trattamento sia informato delle modifiche e abbia la possibilità di opporsi. | La clausola dell'accordo con il termine di preavviso e il canale usato per le comunicazioni. |
| [ ] | 15 | Trasferimenti internazionali. Per ogni trattamento fuori dal SEE, il fornitore indica lo strumento di trasferimento (decisione di adeguatezza, clausole contrattuali tipo, UK IDTA). | I trasferimenti richiedono una base giuridica ai sensi del capo V del GDPR, e la stazione appaltante documenta la propria valutazione. | Gli allegati delle clausole contrattuali tipo e una sintesi della valutazione d'impatto sui trasferimenti del fornitore. |
| [ ] | 16 | Notifica delle violazioni. Il fornitore notifica le violazioni dei dati personali senza ingiustificato ritardo ed entro un numero di ore stabilito. | Il titolare del trattamento ha 72 ore per notificare l'autorità di controllo ai sensi dell'articolo 33, quindi il termine del responsabile deve essere uguale o più breve. | La clausola dell'accordo, una sintesi del processo di risposta agli incidenti e il contatto per la sicurezza. |

## 5. Identità e accesso

| Obbligatorio | N. | Requisito | Perché conta | Prova da richiedere |
| --- | --- | --- | --- | --- |
| [ ] | 17 | Single sign-on. Accesso con SAML 2.0 o OpenID Connect tramite il provider di identità della stazione appaltante, come Microsoft Entra ID, Okta o Google Workspace, per la console di amministrazione e per gli utenti. | Gli account di lavoro legano l'accesso al rapporto di lavoro e applicano le politiche di MFA e di accesso dell'acquirente. | Protocolli e provider di identità supportati, la guida di configurazione e una connessione di prova. |
| [ ] | 18 | SSO obbligatorio. La stazione appaltante può imporre l'SSO a tutti gli utenti e disattivare password e altri metodi di accesso. | Un SSO affiancato alle password lascia account fuori dal controllo del provider di identità. | L'impostazione e come tratta le sessioni aperte e le chiavi API esistenti. |
| [ ] | 19 | Provisioning degli utenti. Provisioning e deprovisioning SCIM 2.0 dal provider di identità, con mappatura dei gruppi su ruoli o team. | Senza deprovisioning, chi lascia l'organizzazione mantiene l'accesso finché qualcuno non si ricorda di toglierlo. | Le risorse SCIM supportate (utenti, gruppi) e in quanto tempo il deprovisioning revoca sessioni e chiavi. |
| [ ] | 20 | Ruoli e chiavi API. Accesso basato sui ruoli, una chiave per persona e per applicazione, chiavi con ambito limitato e revoca immediata. | Le chiavi condivise nascondono chi ha inviato quale richiesta e non si possono revocare per una sola persona. | La matrice dei ruoli e il ciclo di vita delle chiavi: creazione, ambito, rotazione e revoca. |
| [ ] | 21 | App desktop e agenti di programmazione. Il fornitore indica come i dipendenti si autenticano nelle app di IA desktop e negli agenti di programmazione (per esempio Claude Desktop, Claude Code ed estensioni per IDE): con l'account di lavoro o con chiavi distribuite. | È in questi strumenti che compaiono account personali e chiavi copiate al di fuori del procurement. | La guida di configurazione e l'elenco degli strumenti supportati. |

## 6. Controllo della spesa

| Obbligatorio | N. | Requisito | Perché conta | Prova da richiedere |
| --- | --- | --- | --- | --- |
| [ ] | 22 | Budget ai livelli che gestite. Limiti mensili rigidi per utente, per applicazione e per team o reparto, che bloccano la spesa al raggiungimento del limite. | Agenti e job batch possono consumare in poche ore il budget di un mese. Un limite che si limita ad avvisare è solo un report. | I livelli supportati e cosa accade al limite: blocco, avviso o sforamento fatturato. |
| [ ] | 23 | Tetto per l'organizzazione e avvisi. Un tetto per l'intera organizzazione e avvisi prima che un limite venga raggiunto. | L'amministrazione ha bisogno di una cifra che non può essere superata, qualunque cosa accada ai livelli inferiori. | Le impostazioni e i canali di avviso. |
| [ ] | 24 | Prezzi e fatturazione. Prezzo per modello o per piano, la valuta di fatturazione, fatture con i dati aziendali e la partita IVA dell'acquirente, e report dei costi per utente e applicazione per il riaddebito interno. | I prezzi per token variano tra i modelli di ordini di grandezza, quindi la valutazione richiede la base di prezzo e la reportistica. | Il listino prezzi, una fattura di esempio e un report d'uso di esempio. |

## 7. Accesso ai modelli ed elenchi consentiti

| Obbligatorio | N. | Requisito | Perché conta | Prova da richiedere |
| --- | --- | --- | --- | --- |
| [ ] | 25 | Catalogo dei modelli. I modelli di frontiera e open-weight offerti, e quali sono disponibili con ciascuna regola di regione. | Un modello non disponibile nella vostra regione non è più disponibile per voi appena la regola di regione è attiva. | Un elenco dei modelli per regione e la politica di aggiunta di nuovi modelli. |
| [ ] | 26 | Elenchi di modelli consentiti. Gli amministratori scelgono quali modelli può usare ogni team, applicazione o chiave. Le richieste ad altri modelli vengono rifiutate. | Un'approvazione di modello che esiste solo in un documento di policy non impedisce a nessuno di chiamare un altro modello. | L'impostazione e l'errore restituito per un modello non consentito. |
| [ ] | 27 | Elenchi di fornitori consentiti. Gli amministratori scelgono quali fornitori di inferenza possono servire il traffico. I fallback rispettano l'elenco e nessun nuovo fornitore viene aggiunto senza approvazione. | Un fornitore aggiunto dall'offerente è un nuovo luogo in cui i vostri dati vengono trattati. | L'impostazione, come i fallback la applicano e cosa accade quando l'offerente aggiunge un fornitore. |
| [ ] | 28 | Modifiche ai modelli. Il fornitore dà preavviso del ritiro dei modelli e dei cambi di versione, e la stazione appaltante può fissare una versione. | Un cambio di modello silenzioso altera la qualità degli output e può invalidare la valutazione fatta per un caso d'uso. | La politica di ritiro dei modelli e il canale di comunicazione. |
| [ ] | 29 | Trasparenza dell'instradamento. Se il fornitore instrada automaticamente tra modelli o fornitori, per costo o disponibilità, documenta le regole e registra quale modello e quale fornitore hanno servito ogni richiesta. | L'instradamento automatico ha valore solo se potete vedere dove è andata ogni richiesta. | La documentazione dell'instradamento e una registrazione di esempio per richiesta. |

## 8. Log di audit ed esportazione

| Obbligatorio | N. | Requisito | Perché conta | Prova da richiedere |
| --- | --- | --- | --- | --- |
| [ ] | 30 | Log di audit amministrativo. Ogni modifica a utenti, chiavi, budget e policy, con autore, data e ora, e valori precedente e nuovo. | I revisori chiedono chi ha cambiato una policy e quando. Senza i valori precedente e nuovo, il log non può dire cosa è cambiato. | Una voce di log di esempio e il periodo di conservazione. |
| [ ] | 31 | Log delle richieste. Per ogni richiesta: data e ora, utente o chiave, modello, fornitore che l'ha servita, regola di regione, stato, token e costo, senza contenuti salvo attivazione da parte dell'acquirente, con un periodo di conservazione stabilito. | Per gli usi ad alto rischio, l'articolo 26, paragrafo 6, dell'AI Act chiede ai deployer di conservare i log sotto il loro controllo per almeno sei mesi. Il log delle richieste è anche la prova dell'inventario dell'IA. | L'elenco dei campi, il periodo di conservazione e un'esportazione di esempio. |
| [ ] | 32 | Esportazione. I log si esportano in CSV o tramite API e possono essere inviati al SIEM della stazione appaltante. | Le registrazioni che l'acquirente non può estrarre non gli servono per il proprio audit. | Formati, limiti di righe o di periodo e documentazione dell'API. |

## 9. Obblighi del deployer secondo l'AI Act

| Obbligatorio | N. | Requisito | Perché conta | Prova da richiedere |
| --- | --- | --- | --- | --- |
| [ ] | 33 | Supporto per inventario e alfabetizzazione. Il fornitore fornisce le informazioni di cui l'acquirente ha bisogno per l'inventario dell'IA e per le misure di alfabetizzazione in materia di IA dell'articolo 4: i modelli usati da ogni applicazione, i loro fornitori e i loro limiti documentati. | L'articolo 4 si applica dal 2 febbraio 2025, e l'inventario è il punto di partenza di ogni altro obbligo dell'AI Act. | Registrazioni di modello e fornitore per applicazione e link alla documentazione dei modelli. |
| [ ] | 34 | Usi ad alto rischio. Se l'acquirente userà il servizio per una finalità elencata nell'allegato III, il fornitore indica il proprio ruolo ai sensi dell'AI Act e accetta le clausole pertinenti delle clausole contrattuali tipo dell'UE per l'IA. | Gli obblighi del deployer per l'allegato III si applicano dal 2 dicembre 2027 e dipendono da informazioni che hanno solo il fornitore e il fornitore del modello. | La dichiarazione del fornitore sul proprio ruolo e un allegato MCC-AI compilato (High Risk o Light). |
| [ ] | 35 | Documentazione dei modelli di IA per finalità generali. Per ogni modello di IA per finalità generali offerto, il fornitore indica il link alla documentazione che il suo fornitore mette a disposizione dei fornitori a valle e alla sintesi pubblica dei contenuti usati per l'addestramento. | L'articolo 53 obbliga i fornitori di modelli di IA per finalità generali a renderla disponibile, e gli acquirenti la archiviano per modello. | I link per modello e la data di consultazione. |
| [ ] | 36 | Trasparenza. Il fornitore indica se gli output recano una marcatura leggibile da una macchina e come supporta gli obblighi di informazione dell'acquirente. | Gli obblighi di trasparenza dell'articolo 50 si applicano dal 2 agosto 2026. | Le informazioni sulla marcatura per modello e indicazioni per l'informativa. |

## 10. Uscita e portabilità

| Obbligatorio | N. | Requisito | Perché conta | Prova da richiedere |
| --- | --- | --- | --- | --- |
| [ ] | 37 | Interfaccia standard. L'API segue un'interfaccia diffusa, come il formato chat completions compatibile con OpenAI, così che le applicazioni possano cambiare fornitore senza essere riscritte. | Un'interfaccia proprietaria trasforma il cambio di fornitore in un progetto software. | Il riferimento dell'API e gli SDK e gli strumenti noti per funzionare con essa. |
| [ ] | 38 | Esportazione dei dati all'uscita. La stazione appaltante può esportare configurazione, utenti, metadati delle chiavi, utilizzo e log in un formato leggibile da una macchina prima e dopo la cessazione del contratto. | Se il servizio è un servizio di trattamento dei dati ai sensi del regolamento sui dati (Data Act), il capo VI dà al cliente diritti di passaggio ad altro fornitore, e dal 12 gennaio 2027 non possono essere imposte tariffe di passaggio. | I formati di esportazione, l'assistenza offerta per la transizione e per quanto tempo i dati restano disponibili dopo la disdetta. |
| [ ] | 39 | Durata e disdetta. Durata del contratto, termine di preavviso, eventuali corrispettivi per la cessazione e periodo di transizione. | Durate lunghe e corrispettivi di cessazione determinano quanto costa uscire. | Le condizioni commerciali e la clausola di cessazione. |

## 11. Supporto e SLA

| Obbligatorio | N. | Requisito | Perché conta | Prova da richiedere |
| --- | --- | --- | --- | --- |
| [ ] | 40 | SLA di disponibilità. Un impegno di disponibilità mensile con crediti di servizio, il metodo di misura e le esclusioni. | L'IA sta entrando nei processi produttivi, dove un'interruzione ha un costo. | Il documento SLA, la pagina di stato pubblica e la disponibilità degli ultimi 12 mesi. |
| [ ] | 41 | Failover tra fornitori. Quando un fornitore di modelli non è disponibile, le richieste passano a un altro fornitore approvato dello stesso modello, nel rispetto delle regole di regione e degli elenchi consentiti. | Un failover che ignora la regione o l'elenco consentito viola le regole proprio quando un incidente è già in corso. | Il design del failover e il numero di fornitori per modello con ogni regola di regione. |
| [ ] | 42 | Supporto e comunicazione degli incidenti. Canali di supporto, tempi di risposta per gravità, lingue e modalità di comunicazione degli incidenti. | Il processo di gestione degli incidenti dell'acquirente dipende da quello del fornitore. | La politica di supporto, l'URL della pagina di stato e i rapporti sugli incidenti recenti. |
| [ ] | 43 | Documentazione di sicurezza. Una panoramica della sicurezza, un questionario di sicurezza compilato e i report di assurance o le certificazioni del fornitore e dei suoi fornitori di hosting. | È ciò che il team di sicurezza dell'acquirente esamina prima dell'approvazione. Chiederlo già in gara fa risparmiare un giro. | La pagina sulla sicurezza, un questionario compilato come il questionario di sicurezza aperto per gateway LLM (https://standardcompute.com/questionario-di-sicurezza-gateway-llm) ed eventuali report. |

---

## Fonti

- [Clausole contrattuali tipo dell'UE per l'IA aggiornate (MCC-AI High Risk e Light), Public Buyers Community, 5 marzo 2025](https://public-buyers-community.ec.europa.eu/communities/procurement-ai/resources/updated-eu-ai-model-contractual-clauses)
- [Regolamento (UE) 2016/679, regolamento generale sulla protezione dei dati (GDPR), articoli 28 e 33, EUR-Lex](https://eur-lex.europa.eu/legal-content/IT/TXT/?uri=CELEX:32016R0679)
- [Regolamento (UE) 2024/1689 sull'intelligenza artificiale (AI Act), articoli 4, 26, 50 e 53, EUR-Lex](https://eur-lex.europa.eu/legal-content/IT/TXT/?uri=CELEX:32024R1689)
- [Regolamento (UE) 2023/2854, regolamento sui dati (Data Act), capo VI sul passaggio tra servizi di trattamento dei dati, EUR-Lex](https://eur-lex.europa.eu/eli/reg/2023/2854/oj)
- [RFC 7644, protocollo SCIM 2.0](https://www.rfc-editor.org/rfc/rfc7644) e [SAML 2.0 Core, OASIS](https://docs.oasis-open.org/security/saml/v2.0/saml-core-2.0-os.pdf)

_Capitolato tecnico gratuito per la gara di un gateway LLM o di una piattaforma di IA da https://standardcompute.com/capitolato-tecnico-gateway-llm-gara (versione del 9 novembre 2026). Libero da copiare e modificare. Non costituisce consulenza legale._