Iscriviti al feed

Questo blog è un adattamento dell'omonimo documento di ricerca di Red Hat (Bestavros, Chen, Fox, Mollett & Sidhpurwala, 2024). Puoi consultare il documento completo qui.

Con la rapida evoluzione dei modelli di intelligenza artificiale (IA) disponibili al pubblico, aumentano anche le potenziali implicazioni in termini di sicurezza, rendendo necessaria una maggiore comprensione dei rischi e delle vulnerabilità. Per porre le basi della sicurezza e della trasparenza nello sviluppo e nel funzionamento dei modelli di IA, nonché dei loro ecosistemi e community aperti, dobbiamo cambiare il modo in cui affrontiamo le sfide attuali, tra cui la coerenza delle informazioni sui modelli, la mancanza di distinzioni tra i vari problemi legati alla sicurezza, e valutazioni dei rischi insufficienti e non standardizzate da parte di chi crea modelli.

Rischi e vulnerabilità

Sebbene siano simili, safety e security sono aspetti distinti della gestione dei rischi nei sistemi di IA. In ambito IA, con il termine security si intende la protezione dei sistemi dalle minacce esterne e interne, mentre safety indica la garanzia che il sistema e i dati non minaccino o danneggino gli utenti, la società o l'ambiente a causa del funzionamento, dell'addestramento o dell'utilizzo del modello. Tuttavia, la relazione tra safety e security dell'IA è spesso confusa.

Un attacco che in genere è considerato un rischio per i sistemi può portare a problemi di sicurezza per gli utenti (o viceversa), come il modello che produce contenuti nocivi o dannosi o espone informazioni personali. L'intersezione tra security e safety nell'ambito della sicurezza dell'IA evidenzia l'esigenza fondamentale di un approccio completo alla gestione dei rischi che affronti i problemi di sicurezza di diverso tipo in sinergia.

Sfide e metodi attuali

Sebbene il settore dell'IA abbia adottato misure per risolvere i problemi di sicurezza, permangono diverse sfide importanti, come la priorità della velocità rispetto alla sicurezza, una governance inadeguata e pratiche di reporting carenti. Le tendenze emergenti suggeriscono che l'obiettivo di queste aree di crescita è fondamentale per lo sviluppo di pratiche efficaci in materia di sicurezza, protezione e trasparenza nell'IA.

Velocità e sicurezza

Con l'obiettivo di sviluppare e distribuire rapidamente le tecnologie di IA per "proteggere" l'aumento della quota di mercato, molte organizzazioni preferiscono accelerare il passo sul mercato rispetto ai test di sicurezza e alle considerazioni etiche. Come si è visto attraverso gli incidenti di sicurezza passati, la sicurezza è spesso indietro di anni rispetto alla tecnologia nascente, e in genere porta a un grave incidente prima che il settore inizi a correggersi. È ragionevole prevedere che, in assenza di individui che spingono per la gestione del rischio nell'IA, potremmo riscontrare incidenti di sicurezza significativi e critici. Mentre vengono introdotti nuovi modelli che tengono conto degli aspetti di safety e security, la mancanza di consenso su come trasmettere le informazioni necessarie su sicurezza e trasparenza li rende difficili da valutare, sebbene l'aumento dei modelli attenti alla sicurezza rappresenti un passo avanti positivo per il settore dell'IA.

Governance e autoregolamentazione

Con le pochissime leggi in vigore, il settore dell'IA si è affidato all'autoregolamentazione volontaria e a linee guida etiche non vincolanti, che si sono rivelate insufficienti per affrontare i problemi di sicurezza. Inoltre, la legislazione proposta spesso non è in linea con le realtà del settore tecnologico o con le preoccupazioni sollevate dai leader del settore e dalle community, mentre le iniziative aziendali di IA possono non risolvere i problemi strutturali o dare garanzie significative, perché sono sviluppate appositamente per uno uso interno.

L'autoregolamentazione ha avuto un successo limitato e tende a coinvolgere un insieme definito di procedure consigliate implementate indipendentemente dallo sviluppo delle funzionalità principali. Come si è visto storicamente in tutti i settori, dare la priorità alla sicurezza a scapito della produttività è spesso un compromesso che le parti interessate non sono disposte a fare. L'intelligenza artificiale complica ulteriormente questo aspetto, con un impatto diretto sulla sicurezza.

Procedure di reporting carenti

Attualmente mancano metodi e pratiche condivisi per gestire le carenze dei modelli segnalate dagli utenti. Ciò è in parte dovuto al fatto che il sistema di divulgazione e segnalazione delle vulnerabilità del software funziona, ma è imperfetto e non è una soluzione valida per la creazione di report nell'IA. L'intelligenza artificiale è un'evoluzione tecnica della scienza dei dati e dell'apprendimento automatico (ML), distinta dall'ingegneria del software e dallo sviluppo tecnologico tradizionali perché si concentra su dati e calcoli e meno sulla creazione di sistemi per gli utenti che hanno stabilito metodologie per la modellazione delle minacce, per l'interazione con gli utenti e la sicurezza dei sistemi. Senza un sistema di divulgazione e segnalazione dei rischi per la sicurezza ben compreso, segnalare un problema contattando direttamente chi ha creato il modello potrebbe essere complicato e irrealistico. Senza un processo di segnalazione condiviso e standardizzato, l'impatto di un incidente di sicurezza dell'IA potrebbe essere molto più grave di quanto dovrebbe essere, a causa dei ritardi nel coordinamento e nella risoluzione.

Soluzioni e strategie

Sulla base del precedente lavoro di Cattel, Ghosh & Kaffee (2024), riteniamo che l'utilizzo di system card e model card e la promozione del rilevamento dei rischi siano fondamentali per migliorare la sicurezza nel settore dell'IA.

Diffondere l'utilizzo di model/safety card

Le model card vengono utilizzate per documentare il possibile utilizzo di un modello di IA, la sua architettura e, occasionalmente, i dati di addestramento utilizzati per il modello. Le model card sono attualmente utilizzate per fornire un insieme di risorse generate dall'uomo sul modello che viene poi utilizzato per valutarne la fattibilità. Le model card potrebbero avere più potenziale e applicabilità rispetto al loro utilizzo attuale, indipendentemente dalla destinazione del loro utilizzo.

Per confrontare i modelli in modo efficace, utenti e ingegneri necessitano di un insieme coerente di campi e contenuti presenti sulla card, che può essere ottenuto attraverso le specifiche. Oltre ai campi consigliati da Barnes, Gebru, Hutchinson, Mitchell, Raji, Spitzer, Vasserman, Wu & Zaldivar, 2019, proponiamo le seguenti modifiche e integrazioni:

  • ampliare l'intento e l'utilizzo per descrivere gli utenti (chi) e gli scenari di utilizzo (cosa) del modello, nonché le modalità di utilizzo del modello.
  • aggiungere la finalità per escludere problemi noti che il produttore del modello non intende o non è in grado di risolvere. In questo modo, gli addetti al reporting dei rischi potranno comprendere lo scopo del modello prima di segnalare un problema che è considerato non risolvibile rispetto al suo utilizzo definito.
  • modificare i dati di valutazione per fornire una struttura nidificata per comunicare se è stato utilizzato anche un framework e gli output della valutazione eseguiti sul modello. Le valutazioni standardizzate della sicurezza consentirebbero a un utente esperto di creare un modello sostenibile equivalente.
  • aggiungere informazioni sulla governance del modello per capire in che modo utenti o consumatori possono interagire con chi crea i modelli o capire come sono stati prodotti.
  • fornire riferimenti facoltativi, come artefatti e altri contenuti, per aiutare i potenziali consumatori a comprendere il funzionamento del modello e dimostrare la maturità e la professionalità dello stesso.

La richiesta di questi campi per le model card consente al settore di iniziare a definire contenuti essenziali per il ragionamento, il processo decisionale e la riproduzione dei modelli. Sviluppando uno standard di settore per le model card, saremo in grado di promuovere l'interoperabilità dei modelli e dei relativi metadati tra gli ecosistemi.

Monitoraggio dei rischi

Sebbene il processo di divulgazione delle vulnerabilità utilizzato per tenere traccia delle falle di sicurezza sia efficace nella sicurezza software tradizionale, la sua applicazione nei sistemi di IA deve affrontare diverse problematiche. In primo luogo, i problemi del modello di ML devono soddisfare le soglie di validità statistica. Ciò significa che qualsiasi problema identificato in un modello di IA, come le distorsioni, deve essere misurato e valutato rispetto a standard statistici consolidati per garantire che siano utili e rilevanti. In secondo luogo, le preoccupazioni legate all'affidabilità e ai pregiudizi spesso vanno oltre l'ambito delle vulnerabilità di sicurezza e potrebbero non essere in linea con la definizione accettata. Riconoscendo questi limiti, riteniamo che l'inclusione nell'ecosistema di un comitato per la divulgazione e l'esposizione dei rischi, neutrale e coordinato, e un numero CFE (Common Errors and Exposure Number) possano eliminare queste preoccupazioni. È quanto è avvenuto con la creazione del CVE da parte di MITRE, nel 1999, per identificare e classificare le vulnerabilità nel software e nel firmware.

Gli utenti che rilevano problemi di sicurezza devono coordinarsi con i provider di modelli per valutare e analizzare ulteriormente il problema. Una volta che il problema è stato identificato come un pericolo per la sicurezza, il comitato assegna un numero CFE. Chi crea e distribuisce modelli può anche richiedere i codici CFE per tenere traccia dei rischi per la sicurezza riscontrati nei propri modelli. Il comitato coordinato per la divulgazione e l'esposizione dei rischi è il custode dei codici CFE ed è responsabile di assegnarli ai rischi per la sicurezza, monitorarli e pubblicarli. Inoltre, la formazione di un comitato aggiuntivo avrà il compito di facilitare la risoluzione dei rischi per la sicurezza contestati.

Il passo successivo

I modelli sviluppati secondo i principi dell'open source possono svolgere un ruolo significativo nel futuro dell'IA. I framework e gli strumenti necessari per lo sviluppo e la gestione di modelli in linea con le aspettative del settore e dei consumatori richiedono apertura e coerenza per consentire alle organizzazioni di valutare i rischi in modo ragionevole. Maggiore è la trasparenza e l'accesso alle funzionalità critiche, maggiore è la nostra capacità di individuare, tracciare e risolvere i rischi per la sicurezza prima che abbiano un impatto diffuso. Le nostre proposte mirano a garantire flessibilità e coerenza grazie alla governance, ai flussi di lavoro e alla struttura esistenti. Una volta implementati, potrebbero fornire soluzioni più efficienti per risolvere l'urgenza di gestire in modo efficace la sicurezza dell'IA.


Sugli autori

Emily Fox is a DevOps enthusiast, security unicorn, and advocate for Women in Technology. She promotes the cross-pollination of development and security practices.

Read full bio

Huzaifa Sidhpurwala is a Senior Principal Product Security Engineer - AI security, safety and trustworthiness, working for Red Hat Product Security Team.

 
Read full bio

Dr. Huamin Chen is a Senior Principal Software Engineer at Red Hat's CTO office. He is one of the founding members of Kubernetes SIG Storage, member of Ceph, Knative and Rook. He co-founded the Kepler project and drives community efforts for Cloud Native Sustainability.

Read full bio

Mark Bestavros is a Senior Software Engineer at Red Hat. In his six years at the company, Mark has contributed to a wide variety of projects in the software supply chain security space, including Sigstore, Keylime, Enterprise Contract, and more. Currently, Mark is actively contributing to the InstructLab project, working to apply traditional software supply chain security techniques to the rapidly-evolving AI space. Mark graduated from Boston University in 2019 with a combined BA/MS in Computer Science.

Read full bio

With over 25 years of experience in the technology industry, Garth has dedicated more than a decade to Red Hat, where as part of the Product Security leadership team he plays a pivotal role in defining the companies product security strategy and capabilities.

Garth is the author of Red Hat’s security guiding principles and is responsible for delivering the companies annual Product Security Risk Report.  

Read full bio
UI_Icon-Red_Hat-Close-A-Black-RGB

Ricerca per canale

automation icon

Automazione

Novità sull'automazione IT di tecnologie, team e ambienti

AI icon

Intelligenza artificiale

Aggiornamenti sulle piattaforme che consentono alle aziende di eseguire carichi di lavoro IA ovunque

open hybrid cloud icon

Hybrid cloud open source

Scopri come affrontare il futuro in modo più agile grazie al cloud ibrido

security icon

Sicurezza

Le ultime novità sulle nostre soluzioni per ridurre i rischi nelle tecnologie e negli ambienti

edge icon

Edge computing

Aggiornamenti sulle piattaforme che semplificano l'operatività edge

Infrastructure icon

Infrastruttura

Le ultime novità sulla piattaforma Linux aziendale leader a livello mondiale

application development icon

Applicazioni

Approfondimenti sulle nostre soluzioni alle sfide applicative più difficili

Original series icon

Serie originali

Raccontiamo le interessanti storie di leader e creatori di tecnologie pensate per le aziende