Integrare l’intelligenza artificiale non significa aggiungere una chat a ogni prodotto. Il primo passo è distinguere due obiettivi: usare l’AI per assistere il team di sviluppo oppure inserirla in una funzione destinata agli utenti. In entrambi i casi il valore dipende da un problema circoscritto e da criteri di qualità verificabili.

Partire dalla decisione, non dal modello

Una bozza interna che verrà sempre revisionata ha un profilo diverso da una risposta inviata a un cliente o da un’azione su un gestionale. Descrivi input, output e conseguenze dell’errore, poi definisci cosa significa “abbastanza buono”: correttezza dei campi estratti, presenza delle fonti, tasso di escalation, tempo risparmiato o numero di correzioni umane.

Prepara casi di prova rappresentativi, inclusi input incompleti, ambigui e ostili, prima di scegliere modello e fornitore. Modelli, prompt e fonti cambiano: le valutazioni devono essere ripetute e versionate per confrontare qualità, latenza e costo e bloccare una release che peggiora i casi importanti.

Trattare input e output come dati non fidati

Un modello può ricevere istruzioni malevole direttamente dall’utente o indirettamente da documenti, email e pagine che deve analizzare. È il problema della prompt injection. Le sole istruzioni nel prompt non costituiscono un confine di sicurezza.

Le azioni disponibili devono avere parametri strutturati, validazione sul server e autorizzazioni indipendenti dal testo generato. L’output non va passato direttamente a shell, browser, file system o database: deve essere validato e codificato per il contesto; le query restano parametrizzate.

Limitare privilegi e conseguenze

Tool e agenti devono accedere soltanto ai dati e alle operazioni necessari. Per attività irreversibili o ad alto impatto serve un’approvazione esplicita e deve esistere un modo sicuro per annullare o contenere l’azione.

La supervisione umana non è una formula generica: bisogna definire chi controlla, quali informazioni vede, entro quale tempo può intervenire e cosa accade quando il risultato è incompleto.

Dati, fornitori e responsabilità

Prima del pilota, classifica i dati che potrebbero entrare nel sistema. Minimizza ciò che invii, rimuovi segreti e credenziali e verifica contratto, sub-responsabili, conservazione, area di trattamento e impostazioni sull’uso dei dati del fornitore. “Usiamo un servizio enterprise” non equivale automaticamente a conformità.

Assegna un proprietario del sistema, un responsabile delle escalation e una procedura per disattivarlo. Il framework NIST propone di governare, mappare, misurare e gestire i rischi lungo il ciclo di vita. Nell’Unione europea, l’AI Act applica obblighi diversi in base a ruolo e rischio: la classificazione va verificata sul caso concreto.

Un pilota che produce evidenze

Un buon primo progetto dura abbastanza da incontrare casi reali ma resta limitato: un processo, un gruppo di utenti, un insieme di dati autorizzato e una metrica primaria. Confronta il risultato con il processo attuale, registra errori e interventi manuali, poi decidi se estendere, correggere o interrompere.

L’AI diventa utile quando è inserita in un processo osservabile, con limiti comprensibili e responsabilità umane definite. Solo dopo test, sicurezza e governance ha senso valutarne l’estensione alla produzione.

FONTI UFFICIALI

Per approfondire.