I controlli sull’IA aziendale potrebbero contare più dei modelli di frontiera

Dimentichiamo la frontiera dell’IA. I clienti chiedono alle aziende di introdurre più controlli sull’IA già in uso, e l’esperienza con PCI DSS offre un modello utile.

La luna di miele normativa dell’IA è finita. Le recenti rivelazioni hanno dato il via a discussioni su come rallentare lo sviluppo dei modelli di frontiera e imporre controlli. Uno dei pochi punti su cui c’è accordo è che i controlli dovrebbero essere esterni ai modelli e prevedere una verifica indipendente.

Il futuro è ancora oggetto di dibattito, ma le autorità di regolamentazione si stanno muovendo. La legge sull’IA dell’Unione europea sta introducendo gradualmente obblighi di sicurezza, compresa la responsabilità degli acquirenti. Negli Stati Uniti, il framework NIST per la gestione dei rischi dell’IA viene adottato come standard per definire il livello di diligenza ragionevole. A livello globale, l’OWASP Top 10 per le applicazioni LLM è diventato un riferimento comune nelle revisioni di sicurezza e la certificazione ISO/IEC 42001 compare sempre più spesso nei documenti di approvvigionamento.

Questo significa che gli sviluppatori dei modelli non sono gli unici a doverne rispondere. Gli obblighi e i rischi per la sicurezza ricadono anche sulle aziende che utilizzano modelli già rilasciati, soprattutto nei casi d’uso ad alto rischio. Risposte errate a un questionario di sicurezza di un cliente o in una risposta a una RFP potrebbero bloccare un accordo B2B.

PCI DSS indica la strada

Per fortuna, abbiamo già visto questo film. Vent’anni fa, la sicurezza delle applicazioni web si basava soprattutto su controlli periodici del codice, scansioni statiche e disciplina da parte degli sviluppatori. Poi il Requisito 6.6 di PCI DSS, pubblicato nel 2006 e applicato a partire dal 2008, ha imposto alle organizzazioni che trattano dati dei titolari di carte di credito di sottoporre tutto il codice delle applicazioni a una verifica delle vulnerabilità oppure di installare controlli tecnici automatizzati. In seguito, l’opzione di revisione del codice è stata eliminata e sono diventati obbligatori i controlli tecnici.

Ma PCI DSS non è nato come legge. È nato come standard contrattuale che ha trasformato il mercato, probabilmente più rapidamente di quanto avrebbe fatto una legge, perché i contratti si muovono più in fretta delle leggi statali.

Analogamente, oggi le organizzazioni subiscono pressioni affinché adottino controlli sull’IA già distribuita, non da parte delle autorità di regolamentazione, ma di clienti e partner, attraverso questionari di sicurezza, clausole nelle RFP e requisiti delle polizze assicurative.

Risolvere il problema operativo e la conformità seguirà

Può essere difficile rispondere a queste pressioni, perché la governance dell’IA non riguarda soltanto le politiche. Richiede prove tecniche continue.

Molte aziende con cui parlo eseguono in produzione almeno mezza dozzina di modelli e spesso li concatenano o li orchestrano, così che l’output di uno diventi l’input di un altro. Immaginate di dover dimostrare, in queste condizioni, che una determinata regola viene applicata a livello di sistema, per esempio impedendo che l’output del modello contenga informazioni personali identificabili (PII). Sottoporre manualmente a verifica più modelli, ciascuno configurato individualmente, assorbirebbe molto tempo degli sviluppatori. Inoltre, la maggior parte delle organizzazioni fatica a gestire l’uso non autorizzato dell’IA e i casi d’uso ad alto rischio, come quando i dipendenti incollano dati sensibili in strumenti di IA per i consumatori o i fornitori SaaS attivano di nascosto nuove funzionalità di IA. Eppure, la responsabilità ricade interamente sull’azienda.

In scenari così complessi, i requisiti si possono ricondurre a un unico compito semplice: dimostrare di poter limitare continuamente gli input e gli output dei modelli, registrando al contempo tali attività a fini di verifica. Quando le applicazioni chiamano i modelli, gli agenti invocano strumenti e i modelli eseguono azioni o attivano flussi di lavoro, ciò che occorre controllare è l’azione: la chiamata allo strumento, la richiesta API, l’attivazione del flusso di lavoro.

Spostare la sicurezza nel percorso di inferenza

Quell’azione è il punto di applicazione dei controlli che gli esperti di sicurezza delle applicazioni lavorano da 20 anni per integrare nel traffico delle applicazioni. Soprattutto quando l’inferenza passa attraverso un’infrastruttura condivisa, il percorso di inferenza diventa il punto di controllo ideale per diversi modelli e persino per l’uso non autorizzato dell’IA. Il traffico di inferenza dell’IA deve essere instradato, ispezionato, autenticato e gestito come qualsiasi altra interazione importante con un’applicazione, in base alla sua origine e al suo scopo. A differenza delle verifiche manuali, la governance del traffico di inferenza sarà scalabile.

Da dove cominciare

Considerata la direzione che stanno prendendo le normative, le organizzazioni devono iniziare subito a fare tre cose:

1. Mappare la propria area di responsabilità, dalle API SaaS e dagli endpoint ospitati fino all’IA ombra.
2. Separare le politiche di sicurezza e la loro applicazione dai modelli e inserirle nel percorso di inferenza.
3. Assicurarsi che i registri di controllo vengano generati al di fuori del controllo di modelli e agenti, che hanno dimostrato di tentare di alterare le registrazioni delle proprie azioni.

Si sta ancora definendo che cosa costituisca un monitoraggio e un’applicazione dei controlli adeguati, ma i team aziendali e di sicurezza sanno quali misure siano effettivamente applicabili, quanto incidano i controlli su latenza e complessità e in quali casi una regola animata dalle migliori intenzioni possa produrre risultati indesiderati. Coinvolgeteli subito. I rischi per la sicurezza e gli obblighi legati all’uso dell’IA sono reali, e ai vostri clienti e dirigenti stanno senza dubbio più a cuore quelli che affrontano oggi che le minacce dei modelli di frontiera di domani.