Anche la vostra AI è una superficie di attacco.

Una funzionalità AI è composta da più di un semplice prompt. Può recuperare documenti, accedere a dati interni, inviare informazioni a servizi o innescare azioni tramite strumenti. L'impatto rilevante per la sicurezza nasce da questo sistema nel suo insieme. Per questo esaminiamo insieme le fonti di dati, i ruoli e le azioni consentite. I contenuti provenienti da documenti o risposte di strumenti vengono classificati come input potenzialmente non attendibili. Le conseguenze possibili dipendono dalle autorizzazioni e dall'integrazione nella vostra applicazione.

L'analisi unisce le tradizionali questioni di sicurezza del software ai rischi specifici dell'AI. Autenticazione, separazione dei tenant e autorizzazione lato server restano importanti anche quando l'interfaccia è una chat. Un modello non dovrebbe decidere da solo a quali dati una persona può accedere. Architettura e punti di controllo vengono valutati con l'obiettivo che le decisioni critiche siano prese in modo tracciabile, al di fuori di una risposta formulata liberamente. L'attuazione concreta dipende dal sistema e viene definita insieme ai vostri responsabili dello sviluppo.

Per un test significativo vengono preparati ruoli di prova e set di dati rappresentativi. In un'applicazione RAG, ad esempio, occorre capire se i risultati di ricerca e la preparazione del contesto rispettano i limiti di accesso previsti. Per gli agenti conta inoltre soprattutto quali strumenti siano raggiungibili e come vengano approvati gli incarichi. L'indagine resta all'interno dell'ambito autorizzato. Per un'evidenza non dovrebbero servire dati di altri clienti; un set di dati di test adeguato rende visibili gli effetti in modo mirato e controllabile.

Gli output del modello possono variare. Per questo un singolo tentativo riuscito o fallito non viene trattato acriticamente come un'affermazione di validità generale. Presupposti, configurazione e comportamento osservato vengono documentati. Se un problema si manifesta solo in determinate condizioni, questa limitazione fa parte del riscontro. Al contrario, il fatto di non osservare un problema non è una garanzia per tutti gli input possibili. Il report distingue tra impatti dimostrati, ipotesi formulate e ambiti che richiedono un'ulteriore verifica.

Build fast e ship fast non significano per forza scoprire i rischi solo in produzione. I risultati dell'analisi vengono tradotti insieme al vostro team in modifiche prioritarie. Tra queste possono rientrare autorizzazioni più ristrette, accessi ai dati separati, chiamate agli strumenti validate e approvazioni aggiuntive per le azioni con conseguenze rilevanti. La misura adeguata dipende dall'applicazione effettiva. Una raccolta di regole generali per i prompt non sostituisce il lavoro su architettura, identità e percorsi dati consentiti.

I casi di test rilevanti possono essere integrati nel processo di rilascio. Le modifiche al modello, alle fonti documentali o agli strumenti vengono così confrontate con requisiti noti. OTOKO® porta in questo lavoro 15 anni di esperienza nell'analisi del software e la collaborazione di un team internazionale di 95 persone. Per il vostro progetto vengono definiti referenti adeguati e un ambito di servizio concreto. Il lavoro congiunto con il vostro team di sviluppo unisce risultati verificabili a correzioni attuabili e a una base per le release successive.