La risposta rapida: valutare un fornitore di IA significa chiedere prove invece di promesse. Prima di firmare, vuoi quattro cose per iscritto: risultati di test indipendenti che puoi verificare, termini chiari su come vengono utilizzati e conservati i tuoi dati, un impegno a monitorare il sistema dopo il go-live, e un modo per verificare ogni affermazione di sicurezza che il fornitore fa senza prendere la sua parola. Il resto di questa guida trasforma questo in un processo operativo, una checklist di domande che puoi inviare ai fornitori, e i termini contrattuali che rendono le risposte vincolanti.

La due diligence su IA differisce dalla revisione ordinaria del software perché un sistema di IA può produrre una risposta sicura ma sbagliata, essere persuaso a violare le sue stesse regole, perdere dati, o cambiare comportamento dopo un aggiornamento del modello che il fornitore distribuisce di martedì. Trovi questi rischi testando il comportamento, e li controlli con termini contrattuali che dicono cosa succede quando il comportamento cambia.

Perché la due diligence sui fornitori di IA è ora un'aspettativa formale

L'acquisto di IA era solito essere trattato come un acquisto software con un paragrafo extra sui dati. I buyer pubblici e i legislatori su entrambi i lati dell'Atlantico hanno cambiato questo.

Buyer federali statunitensi: OMB memo M-25-22

Il 3 aprile 2025, l'Office of Management and Budget della Casa Bianca ha emesso il memorandum M-25-22, Driving Efficient Acquisition of Artificial Intelligence in Government. Si applica ai contratti assegnati in base a sollecitazioni emesse 180 giorni o più dopo il memorandum, e alle opzioni di rinnovo esercitate dopo quel momento. La Sezione 4(d) dice che le agenzie "devono includere termini che affrontino" un elenco di argomenti in contratti per sistemi e servizi di IA. Tra loro:

• Monitoraggio continuo delle performance. I contratti devono consentire all'agenzia di monitorare e valutare regolarmente le performance, i rischi e l'efficacia del sistema, con revisioni trimestrali o biennali date come esempi.
• Test indipendenti. Le agenzie dovrebbero testare con i loro dataset che "non dovrebbero essere accessibili al fornitore", i fornitori devono fornire "l'accesso e il tempo necessari alle agenzie per completare la valutazione indipendente", e i risultati dei test dovrebbero essere "dettagliati abbastanza da consentire il test per essere indipendentemente verificato o riprodotto, se praticabile".
• Protezione contro il lock-in. I termini possono includere il trasferimento delle conoscenze, la "portabilità dei dati e del modello", e la trasparenza su licenze e prezzi.
• Limiti sull'addestramento con i tuoi dati. La Sezione 3(e) richiede che i contratti "proibiscano permanentemente l'uso dei dati non pubblici inseriti dall'agenzia e dei risultati in uscita" per addestrare ulteriormente IA pubblicamente o commercialmente disponibili, a meno che l'agenzia non dia esplicitamente il consenso.
• Notifica prima delle modifiche. Le agenzie dovrebbero valutare l'opportunità di richiedere ai fornitori di notificarle prima dell'integrazione di nuovi miglioramenti dell'IA e sono incoraggiate a richiedere ai fornitori di rispettare standard di prestazione prima di distribuire nuove versioni e di eseguire un rollback se necessario.

Un secondo memorandum, OMB M-26-04 dell'11 dicembre 2025, afferma che "integra" M-25-22. Per i contratti relativi ai modelli di linguaggio di grandi dimensioni, elenca le informazioni che le agenzie dovrebbero richiedere ai fornitori: una politica di uso accettabile, carte del modello, del sistema o dei dati, risorse per gli utenti finali e un meccanismo per il feedback degli utenti finali. Consente inoltre alle agenzie di richiedere ulteriori informazioni, come i risultati delle valutazioni.

Questi memorandum vincolano le agenzie federali, non le aziende private. Rimangono comunque la dichiarazione pubblica più dettagliata di ciò che un acquirente sofisticato di IA richiede, e i team di approvvigionamento privati possono prendere in prestito direttamente la loro struttura.

Acquirenti dell'UE: cosa chiede l'AI Act all'utente

L'EU AI Act, Regulation (EU) 2024/1689, chiama "deployer" l'organizzazione che utilizza un sistema di IA sotto la propria autorità. Se acquistate un sistema di IA ad alto rischio e lo mettete in funzione, l'articolo 26 vi pone obblighi specifici, distinti da quelli del fornitore. Nel testo consolidato pubblicato su AI Act Service Desk della Commissione europea, l'articolo 26 prevede:

• I deployer "adottano misure tecniche e organizzative adeguate per garantire di utilizzare tali sistemi conformemente alle istruzioni per l'uso che accompagnano i sistemi" (Articolo 26, paragrafo 1).
• I deployer "devono adottare misure tecniche e organizzative appropriate per garantire l'utilizzo di tali sistemi in conformità alle istruzioni per l'uso che accompagnano i sistemi" (articolo 26(1)).
• I deployer "devono affidare la supervisione umana a persone fisiche che dispongono delle necessarie competenze, della necessaria formazione e dell'autorità richiesta" (articolo 26(2)).
• I deployer "devono monitorare il funzionamento del sistema di IA ad alto rischio sulla base delle istruzioni per l'uso" e, se hanno motivo di ritenere che il sistema presenti un rischio, devono informare il fornitore o il distributore e l'autorità competente di sorveglianza del mercato e sospendere l'utilizzo (articolo 26(5)).
• I deployer "devono conservare i registri generati automaticamente da tale sistema di IA ad alto rischio" nella misura in cui tali registri sono sotto il loro controllo, per almeno sei mesi, a meno che la legge non preveda diversamente (articolo 26(6)).

Ciascuno di questi obblighi dipende da qualcosa che si può ottenere solo dal fornitore. Non è possibile seguire istruzioni per l'uso mai ricevute, conservare registri che il sistema non esporta, o monitorare comportamenti che non si ha modo di misurare. L'Articolo 13 rappresenta la controparte del fornitore nello stesso patto: i sistemi ad alto rischio devono essere accompagnati da istruzioni per l'uso che includano, tra l'altro, "il livello di accuratezza, comprese le relative metriche, la robustezza e la cibersicurezza" (Articolo 13(3)(b)(ii)). La due diligence è il momento in cui si verifica che tale documentazione esista e sia sufficientemente adeguata per svolgere la propria parte.

I tempi contano. In base alle modifiche del Digital Omnibus, l'Articolo 113 prevede ora che le norme sui sistemi ad alto rischio si applichino dal 2 dicembre 2027 per i sistemi stand-alone elencati nell'Allegato III e dal 2 agosto 2028 per l'IA integrata in prodotti disciplinati dall'Allegato I. I contratti che firmate oggi saranno spesso ancora in vigore a quelle date, quindi ha senso inserire fin da ora gli obblighi previsti. Separatamente, l'Articolo 4 chiede ai fornitori e ai deployer di sistemi di IA in generale, non solo a quelli ad alto rischio, di "adottare misure per garantire un livello adeguato di alfabetizzazione in materia di IA" del personale che li utilizza e li gestisce. Per un quadro normativo più ampio, consultate la nostra guida completa all'EU AI Act e alle leggi statunitensi sull'IA.

Anche i framework volontari indicano la stessa direzione

Il NIST AI Risk Management Framework core attribuisce all'IA di terze parti una categoria a sé stante. GOVERN 6.1 recita "Sono in vigore politiche e procedure che affrontano i rischi di IA associati a soggetti terzi", GOVERN 6.2 recita "Sono predisposti processi di emergenza per gestire guasti o incidenti nei dati o nei sistemi di IA di terze parti considerati ad alto rischio", e MANAGE 3.1 afferma che i rischi derivanti da risorse di terze parti devono essere "monitorati regolarmente, con controlli del rischio applicati e documentati." Se la vostra organizzazione è già allineata al NIST AI RMF o gestisce un sistema di gestione ISO/IEC 42001, la due diligence sui fornitori è il modo per soddisfare queste aspettative riguardo all'IA che acquistate. La nostra guida a NIST AI RMF, ISO/IEC 42001 e agli standard correlati illustra come questi framework si integrano tra loro.

Le sei aree da valutare

Ogni valutazione di un fornitore di IA si riduce a sei aree.

1. Cos'è il sistema e a cosa serve

Si inizi dall'ambito di applicazione. Quali modelli sono alla base del prodotto, e il fornitore ne è lo sviluppatore oppure un rivenditore che impacchetta la soluzione di terzi? Quale finalità prevista documenta il fornitore, e l'uso che intendete farne rientra in tale finalità? Ai sensi dell'EU AI Act, la finalità prevista è il primo elemento che le istruzioni per l'uso devono indicare, e utilizzare un sistema al di fuori di essa significa assumersi rischi che il fornitore non ha mai testato.

2. Prove di comportamento sicuro

Questa è l'area che la maggior parte degli acquirenti gestisce peggio, perché è la più difficile da indagare in un questionario. "Testate per verificare la presenza di bias?" otterrà un sì da chiunque. Le domande migliori chiedono il metodo e il risultato: cosa è stato testato, rispetto a quali scenari, con quale tasso di superamento, da chi e quando. I rischi comportamentali da coprire corrispondono ai sette pilastri del framework A.E.G.I.S.™:

• Hallucination Integrity: il sistema afferma il falso come se fosse un fatto, specialmente sotto pressione, in condizioni di ambiguità o in caso di domande specifiche di settore?
• Guardrail Resistance: è possibile manipolarlo inducendolo a comportamenti non sicuri tramite tentativi di jailbreak o prompt injection?
• Hallucination Integrity: il sistema afferma falsità come fatti, soprattutto sotto pressione, ambiguità o questionamenti specifici del dominio?
• Guardrail Resistance: può essere manipolato verso comportamenti non sicuri attraverso tentativi di jailbreak o iniezione di prompt?
• Data Handling & Privacy: cosa raccoglie, conserva e perde, inclusi i dati personali?
• Adversarial Robustness: come si comporta di fronte a un attacco mirato?
• Explainability & Transparency: il suo comportamento può essere compreso e verificato successivamente?

Per sapere come ciascuno di questi aspetti viene effettivamente testato, consultare come vengono testati i sistemi di IA per la sicurezza. La distinzione fondamentale per l'acquirente è tra i risultati prodotti dal fornitore su se stesso e i risultati prodotti da terzi indipendenti. I test interni hanno valore, ma è il fornitore che corregge i propri compiti. M-25-22 sottolinea lo stesso aspetto dal lato dell'acquirente, richiedendo test dettagliati al punto da poter essere "verificati o riprodotti indipendentemente".

3. Gestione dei dati

Chiedete dove vanno i vostri dati, quanto tempo rimangono, chi può vederli e se addestrano qualcosa. Lo standard federale M-25-22 è un utile punto di riferimento: i fornitori possono raccogliere e conservare informazioni dell'agenzia solo quando "ragionevolmente necessario" per il contratto, e gli input e output non pubblici non possono essere utilizzati per addestrare modelli pubblici o commerciali senza consenso. Chiedete anche se i log del sistema sono disponibili per voi, poiché i gestori di sistemi ad alto rischio nell'UE devono mantenere i log sotto il loro controllo.

4. Supervisione e controllo

Scoprite cosa può fare un operatore umano quando il sistema sbaglia. Un operatore può rivedere o annullare gli output, o mettere in pausa il sistema? L'articolo 26(2) presuppone che assegnerete persone competenti alla supervisione; il fornitore deve fornire loro qualcosa con cui lavorare.

5. Gestione dei cambiamenti e monitoraggio

I prodotti di IA cambiano sotto i vostri occhi: un nuovo modello base o un nuovo addestramento, e il comportamento che avete approvato non è più quello in produzione. Chiedete come il fornitore vi comunica i cambiamenti significativi, se potete testare prima che una nuova versione raggiunga i vostri utenti, e se una versione può essere ripristinata. M-25-22 chiede alle agenzie di considerare o richiedere tutti e tre gli aspetti. Quindi chiedete quale monitoraggio esiste dopo il lancio e se i risultati vengono condivisi con voi.

6. Incidenti e responsabilità

Chiedete il processo di risposta agli incidenti del fornitore per i guasti specifici dell'IA, come un output dannoso o un jailbreak riuscito. I gestori di sistemi ad alto rischio nell'UE devono informare il fornitore e l'autorità di sorveglianza del mercato quando ritengono che un sistema presenti un rischio, quindi il vostro contratto deve assicurare che il fornitore collaborerà con voi quando ciò accade. La nostra guida su gli incidenti di IA documentati e cosa rileva il testing mostra i modelli di guasto vale la pena pianificare.

Un elenco di domande che potete inviare ai fornitori di IA

Copiatele nella vostra RFP. Ciascuna chiede qualcosa che potete verificare.

Ambito e scopo

1. Quali modelli alimentano il prodotto, chi sviluppa ciascuno e quali versioni sono in produzione oggi?
2. Qual è lo scopo documentato previsto e ci sono usi che sconsigliate? Condividete le istruzioni per l'uso o documentazione equivalente.
3. Pubblicate schede di modello, sistema o dati per il prodotto? Allegatele.
4. Qual è la vostra policy di utilizzo accettabile per gli utenti finali?

Test e prove

5. Contro quali rischi di sicurezza avete testato il prodotto (ad esempio, allucinazione, jailbreak e prompt injection, perdite di privacy, comportamento con utenti vulnerabili, limiti dell'autonomia, attacchi avversariali, spiegabilità)? Per ciascuno, quale è stato il metodo e il risultato?
6. Alcuni di questi test sono stati eseguiti da una parte indipendente? Chi, quando, contro quale versione e possiamo verificare il risultato da soli?
7. Ci darete accesso e tempo per eseguire la nostra valutazione, utilizzando dati di test che non vedete?
8. Quali sono i livelli documentati di precisione, robustezza e sicurezza informatica e come sono stati misurati?

Dati

9. Quali dati dal nostro utilizzo raccogliete e conservate, per quanto tempo, e perché ogni elemento è necessario?
10. I nostri input o output verranno utilizzati per addestrare o migliorare un modello, vostro o di terzi? Possiamo proibirlo contrattualmente?
11. Quali subappaltatori, inclusi i fornitori di modelli, ricevono i nostri dati?
12. Quali log genera il sistema e possiamo esportarli e conservarli?

Controllo, modifiche e incidenti

13. Quali controlli di supervisione umana e override sono disponibili per i nostri operatori?
14. Come e quando ci notificherete prima di una modifica sostanziale al modello o al suo comportamento? Possiamo testare una nuova versione prima che raggiunga i nostri utenti e possiamo tornare alla versione precedente?
15. Come monitorate il prodotto dopo il deployment e condividerete i risultati del monitoraggio con noi?
16. Qual è il vostro processo di risposta agli incidenti per i guasti specifici dell'IA e quali sono i vostri impegni di notifica verso di noi?
17. Se interrompiamo il rapporto, come recuperiamo i nostri dati e personalizzazioni, e in quale formato?

Trasformare le risposte in termini contrattuali

Le risposte al questionario sono rappresentazioni. Il contratto è dove diventano obblighi. M-25-22 fornisce un modello per gli argomenti e i buyer privati possono adattarlo senza molti cambiamenti.

• Impegni su prestazioni e sicurezza. Inserite il comportamento testato nell'accordo: i livelli documentati di accuratezza e sicurezza, un calendario di revisioni periodiche e cosa accade se i risultati scendono al di sotto di essi.
• Diritto di valutazione. Riservate il diritto di eseguire test indipendenti o di farli eseguire da una parte terza, con accesso e tempo da parte del fornitore.
• Limiti all'uso dei dati. Proibite l'addestramento sui vostri input e output senza consenso scritto, limitate la conservazione al necessario e specificate gli subappaltatori.
• Notifica di modifiche. Richiedete preavviso di modifiche sostanziali al modello e una finestra di test prima che raggiungano la produzione, con opzione di rollback.
• Logging e registrazioni. Richiedete al sistema di generare ed esportare i log necessari e stabilite quanto a lungo il fornitore conserva i propri.
• Cooperazione per gli incidenti. Stabilite tempistiche di notifica per gli incidenti di IA e un obbligo di assistenza per adempiere a qualsiasi dovere di comunicazione che abbiate.
• Portabilità. Coprite la portabilità di dati e modelli, il trasferimento di conoscenze e le licenze trasparenti per consentirvi di cambiare fornitore se necessario.

M-26-04 aggiunge una tecnica di redazione utile: dice alle agenzie di identificare certi requisiti come "materiali per l'ammissibilità e il pagamento secondo il contratto". Rendere i termini di sicurezza e trasparenza materiali dà loro peso, perché la loro violazione diventa base per rimedi anziché una nota a margine.

Dove la due diligence di solito fallisce

La maggior parte delle revisioni fallite di fornitori di IA fallisce in uno di pochi modi prevedibili.

Il questionario è un modulo di sicurezza con domande di IA aggiunte. Una relazione SOC 2, secondo la stessa descrizione dell'AICPA, è un esame dei controlli presso un'organizzazione di servizi rilevanti per la sicurezza, disponibilità, integrità dell'elaborazione, riservatezza o privacy. È prezioso e risponde a una domanda diversa da quella se il modello può essere jailbroken o quanto spesso inventa fatti. Mantenete la sicurezza delle informazioni e il comportamento dell'IA come sezioni separate con prove separate.

Ogni risposta è auto-dichiarata. Il revisore non ha modo di verificare il modulo o le politiche allegate, quindi il buyer o accetta affermazioni che non può verificare o commissiona test propri.

L'approvazione è trattata come permanente. Sei mesi dopo l'acquisto il fornitore ha modificato il modello e nessuno ha ricontrollato. Sia M-25-22 che NIST AI RMF trattano il monitoraggio come continuo per esattamente questo motivo.

Le prove non sono comparabili tra i fornitori. Tre fornitori descrivono i loro test in tre modi diversi, quindi il prezzo e le funzionalità decidono per default.

Perché una valutazione indipendente verificabile accorcia i tempi

Gli ultimi due problemi sono i più costosi. Quando un sistema di IA è stato valutato da una terza parte indipendente rispetto a un framework standardizzato, tre cose cambiano per l'acquirente.

In primo luogo, l'evidenza è indipendente. RateAI non ha interesse nel rating di un sistema e i suoi compensi sono legati alle milestone di valutazione, non agli esiti. Un sistema può non ottenere la certificazione; quando accade, lo sviluppatore riceve un rapporto dettagliato dei risultati e un percorso di correzione, e può rientrare in valutazione una volta risolti i problemi.

In secondo luogo, l'evidenza è comparabile. Ogni valutazione A.E.G.I.S.™ valuta gli stessi sette pillar, e i parametri di scoring sono fissati da un'epoca di scoring in modo che le valutazioni rimangano comparabili nel tempo. I sistemi certificati ricevono una scorecard A.E.G.I.S.™ con un Overall Safety Rating da A (Maximum Safety) a F (Dangerous), un grade per ogni pillar, e un sigillo di certificazione da A-5 Guardian fino a A-1 Unrestricted. I vostri revisori possono vedere in un unico posto dove il sistema è forte e dove la cautela è consigliata, e confrontare due fornitori sulla stessa scala.

In terzo luogo, l'evidenza è verificabile e attuale. Ogni prompt case, validator vote e decisione di certificazione è concatenato con hashing SHA-256 in un audit trail write-once, quindi i record non possono essere alterati o backdatati. Chiunque può controllare una certificazione RateAI nel Safety Registry pubblico senza effettuare il login, e confermare che è attuale e non è stata declassata. Le certificazioni portano anche un ciclo di ri-certificazione, e i cambiamenti significativi a un sistema provocano una rivalutazione, il che risponde direttamente al problema di change-management di cui sopra.

Un rating non sostituisce la vostra due diligence. Avete ancora bisogno di risposte su scope, termini contrattuali, data flows e adeguatezza per il vostro caso d'uso, e una certificazione RateAI non è una determinazione legale: supporta il vostro lavoro di compliance, e le decisioni normative rimangono con le autorità competenti. I tier Pro e Enterprise di RateAI includono compliance mapping con EU AI Act, NIST AI RMF e ISO 42001. Quello che una valutazione verificabile fa è rispondere alle domande di evidenza, numeri 5 a 8 nell'elenco di cui sopra, con qualcosa che il vostro team può verificare invece di assumere per fiducia. Per un'analisi più approfondita del funzionamento della certificazione di terze parti, leggete che cosa è la certificazione di sicurezza dell'IA e come funziona.

Un workflow di due diligence pratico

1. Classificare il caso d'uso. Chi è interessato dal sistema, può agire autonomamente, e potrebbe essere ad alto rischio secondo l'EU AI Act? Posti di maggiore importanza significano una revisione più profonda.
2. Inviare la lista di domande presto. Includetela nella RFP in modo che i fornitori che non riescono a rispondere si ritirino prima di investire tempo nelle demo.
3. Controllare l'evidenza indipendente. Cercate il prodotto del fornitore in qualsiasi registry indipendente in cui sostiene di essere listato, e confermate che il rating, la data e la versione corrispondono a quello che state acquistando.
4. Testare quello che rimane. Dove l'evidenza indipendente manca o non copre il vostro caso d'uso, eseguite la vostra valutazione su dati che il fornitore non ha visto, oppure commissionatene una.
5. Negoziare i termini. Convertite le risposte in obbligazioni contrattuali: performance, diritti di testing, uso dei dati, notifica di cambio, logging, incident e portability.
6. Impostare la cadenza di monitoraggio. Concordate quanto spesso esaminerete la performance e cosa attiva una ri-revisione, come un cambio di modello o un incident segnalato.
7. Registrare la decisione. Mantenete l'evidenza, il vostro scoring e le ragioni dell'approvazione.

Se siete dalla parte del fornitore in questo processo, la stessa lista vi dice cosa gli acquirenti vi chiederanno. Avere l'evidenza indipendente pronta prima che arrivi il questionario accorcia ogni sales cycle che segue. I tier di certificazione e monitoraggio di RateAI descrivono come viene delimitato un engagement, e un benchmark di sicurezza gratuito per un agente di IA è disponibile come punto di partenza.

Domande frequenti

Che cosa è la due diligence su un fornitore di IA?

È il processo di verifica del sistema, delle pratiche dati e dei controlli di un fornitore di IA prima di acquistare, e di mantenere quelle verifiche aggiornate in seguito. Rispetto alla revisione ordinaria di software, aggiunge il testing del comportamento del sistema, come l'hallucination, la resistenza al jailbreak e le perdite di privacy.

Un rapporto SOC 2 è sufficiente per approvare un fornitore di IA?

Di solito non da solo. Un rapporto SOC 2 esamina i controlli di un'organizzazione di servizi rilevanti per la sicurezza, disponibilità, integrità dell'elaborazione, confidenzialità o privacy, quindi avete ancora bisogno di evidenza separata su come il modello di IA si comporta, come risposte false, manipolazione e perdita di dati attraverso gli output.

Che cosa richiede l'EU AI Act dalle aziende che acquistano IA?

Le organizzazioni che utilizzano sistemi di IA ad alto rischio sono "deployer" secondo l'Articolo 26, e devono utilizzare il sistema secondo le sue istruzioni, assegnare una supervisione umana competente, monitorarne il funzionamento, mantenere i log sotto il loro controllo e, in alcuni casi, informare le persone interessate. Quelle regole ad alto rischio si applicano dal 2 dicembre 2027 per i sistemi Annex III e dal 2 agosto 2028 per l'IA incorporata in prodotti coperti da Annex I.

Quali condizioni contrattuali dovrebbe includere un acquisto di IA?

Come minimo: impegni di performance e sicurezza, il diritto a testing indipendente, limiti sull'utilizzo dei vostri dati per l'addestramento, notifica anticipata e testing dei cambi di modello, accesso ai log, cooperazione su incident e portability. Il memo OMB M-25-22 elenca la maggior parte di questi come argomenti richiesti per i contratti di IA federali statunitensi.

Come aiuta una valutazione indipendente di sicurezza dell'IA gli acquisti?

Sostituisce le affermazioni auto-dichiarate con risultati standardizzati prodotti da una terza parte e che potete verificare. Un rating A.E.G.I.S.™ valuta un sistema secondo gli stessi sette pilastri di ogni altro sistema valutato, consentendovi di confrontare i fornitori e confermarne la certificazione aggiornata nel Registro della Sicurezza pubblico.

Una certificazione RateAI rende un sistema di IA legalmente conforme?

Nessuna certificazione può determinarlo; le decisioni normative formali rimangono in capo alle autorità competenti. La certificazione RateAI supporta il lavoro di conformità e i suoi tier Pro ed Enterprise includono la mappatura della conformità all'EU AI Act, NIST AI RMF e ISO 42001.

Verificate il rating di un fornitore prima di firmare

La domanda di due diligence più veloce è se il sistema è già stato valutato indipendentemente. Cercate nel Registro della Sicurezza RateAI per vedere come sono elencati i sistemi di IA certificati, con il loro rating A.E.G.I.S.™ e stato di certificazione, e chiedete ai vostri fornitori se il loro prodotto è presente.