Scegliere gli strumenti di IA in base a un compito delimitato

Descriva prima il risultato di lavoro desiderato. Da questo derivano le funzioni necessarie all’assistente di IA. Disporre dell’accesso a un sistema di ticket non giustifica rendere disponibili al modello tutte le sue funzioni.

Tradurre un compito in funzioni

In questo esempio ipotetico, il compito è creare una bozza interna di risposta al ticket T-62. Il ticket appartiene all’account cliente K-18 e fa riferimento a un progetto. L’assistente può leggere la richiesta ricevuta, consultare lo stato del progetto associato e salvare una bozza. L’invio non rientra in questo compito.

I nomi degli strumenti sono esempi nostri. La matrice descrive il perimetro previsto:

OWASP raccomanda di limitare le funzioni degli strumenti e le relative autorizzazioni al necessario. Una chiamata dedicata e circoscritta è più facile da delimitare di uno strumento generico che esegue comandi o usa indirizzi di destinazione arbitrari.

Verificare il contesto sul server

Il server determina il contesto cliente consentito dalla persona autenticata e dal ticket verificato. Un identificativo cliente fornito liberamente dal modello non deve ampliare tale contesto. Anche l’appartenenza del progetto al caso autorizzato deve essere verificabile.

Ogni chiamata verifica nuovamente diritti e campi ammessi. L’elenco visibile degli strumenti aiuta a orientare il comportamento; il controllo effettivo dell’accesso resta nel servizio che esegue l’operazione. Un argomento ben formato o un’istruzione nel testo del ticket non conferisce diritti aggiuntivi.

Trasmettere i risultati come stati

Una bozza salvata correttamente richiede la conferma del sistema di ticket. Il solo testo generato non dimostra il salvataggio. Se la scrittura fallisce o l’esito rimane sconosciuto, l’interfaccia mostra tale stato. Non deve presentarlo come un messaggio inviato al cliente.

Se in seguito sarà possibile anche inviare, si tratterà di un’estensione separata con destinatari, diritti e, ove necessario, approvazioni definiti. Un’ulteriore richiesta del modello non la attiva incidentalmente.

Provare i limiti prima dell’uso

Verifichi il flusso consentito fino alla bozza salvata, poi un altro contesto cliente, una richiesta di invio nel testo del ticket e un salvataggio fallito. Gli esiti attesi sono rispettivamente una bozza interna, accesso negato, nessun invio e uno stato di errore visibile.

Registri per ogni caso le funzioni consentite, lo stato atteso del sistema e il risultato effettivo. Si potrà così vedere se il limite tecnico rispetta il compito anche quando il modello propone una chiamata inappropriata.

Fonti

• OWASP — LLM06:2025 Excessive Agency