Cinque domande da porre prima che un sistema di IA entri in produzione

Il vostro team vuole mettere in produzione un sistema di intelligenza artificiale. La demo ha funzionato, il business case è convincente e tutti sono entusiasti. Prima di dare il via libera, queste cinque domande vi diranno sul rischio più di qualsiasi presentazione.

Non serve essere tecnici per farle. Serve però ricevere risposte chiare.

1. Da quali dati impara, e chi può modificarli?

I modelli di IA imparano dai dati, e molti continuano ad adattarsi man mano che arrivano dati nuovi. È questo che li rende utili; ed è anche ciò che li distingue dal software tradizionale. Se qualcuno può manomettere i dati di addestramento o di riferimento, può influenzare il comportamento del modello. Si chiama avvelenamento dei dati (data poisoning). In sanità potrebbe significare una decisione sbagliata su un paziente; nella finanza o nella logistica potrebbe distorcere silenziosamente decisioni che sembrano del tutto ordinarie.

Chiedete da dove provengono i dati, chi può scriverci e come ne viene verificata la qualità.

2. Chi può accedere al modello, e cosa può ottenerne?

Un modello è un asset. Gli attaccanti cercano di copiarlo (furto del modello), sondarlo o fornirgli input progettati per farlo sbagliare (attacchi avversari). Se il sistema usa un modello linguistico di grandi dimensioni (LLM), aggiungete alla lista la prompt injection: istruzioni nascoste in un documento o in una pagina web che il modello esegue come se provenissero da voi.

Chiedete chi ha accesso al modello, ai suoi output e a tutto ciò su cui può agire. Se la risposta è "il team che l'ha sviluppato", continuate a chiedere.

3. Come ci accorgeremmo se iniziasse a comportarsi male?

I sistemi tradizionali di solito falliscono in modo evidente. I sistemi di IA possono fallire in silenzio; gli output sembrano ancora plausibili, semplicemente sono sbagliati. Il monitoraggio deve osservare derive, output anomali e usi insoliti, non solo la disponibilità.

Chiedete chi sta osservando, cosa sta osservando e quanto velocemente noterebbe un problema prima di un cliente.

4. La sicurezza è stata coinvolta nella progettazione, o solo nella revisione?

Correggere una lacuna di sicurezza dopo il lancio costa più che progettare per evitarla. È la stessa lezione che abbiamo imparato con il software decenni fa, e vale anche qui. L'OWASP AI Exchange lo sottolinea più volte: integrate la sicurezza nel ciclo di sviluppo dell'IA fin dall'inizio, non come controllo finale.

Chiedete quando la sicurezza ha visto per la prima volta questo progetto, e cosa è cambiato di conseguenza.

5. Chi è il responsabile del rischio una volta in produzione?

È la domanda che di solito provoca la pausa più lunga. Qualcuno deve "possedere il rischio" dopo il go-live; una persona con un nome, non un comitato. Quella persona decide cosa monitorare, quando riaddestrare il modello e quando spegnerlo.

Chiedete un nome. Se non c'è, avete trovato la vostra prima azione da intraprendere.

In sintesi

Se il vostro team sa rispondere chiaramente a tutte e cinque, siete in buona posizione. Se due o tre ricevono un'alzata di spalle, non è un motivo per fermare il progetto; è un motivo per rallentare un paio di settimane e ottenere le risposte. Preparate il piano, poi seguite il piano.

Se desiderate un secondo parere prima della vostra prossima approvazione di un progetto di IA, offro una call conoscitiva gratuita di 30 minuti per le organizzazioni idonee. Prenotate qui.

Dan Sorensen è un leader nella cybersecurity, collaboratore del Forbes Technology Council, membro del core team dell'OWASP AI Exchange e CISO frazionale.