Cambiare modello richiede anche una verifica del comportamento

Un adattatore comune per i modelli può semplificare il collegamento tecnico. Per esempio traduce i formati dei fornitori in un protocollo interno per gli strumenti. Così si definisce come arriva una chiamata. L’applicazione deve ancora verificare se il nuovo modello interpreta correttamente una richiesta fallita.

Stessa chiamata, continuazione diversa

Nell’esempio interamente inventato, un assistente chiede lo stato di un progetto. Entrambe le varianti possono usare soltanto lo strumento di lettura previsto a questo scopo. Nome dello strumento, argomento e codice d’errore sono valori del nostro esempio, non l’interfaccia di un fornitore identificato.

La tabella mostra due continuazioni ipotetiche della stessa richiesta negata. Non riporta osservazioni su modelli reali.

L’adattatore può tradurre entrambe le chiamate allo stesso modo. Eppure la seconda continuazione afferma uno stato che lo strumento non ha fornito. Nell’esempio l’accesso è stato bloccato; la risposta inventata resta un errore di merito. Non deve valere come prova che la richiesta sia riuscita.

L’applicazione mantiene i propri limiti

OWASP raccomanda di limitare i poteri degli strumenti e applicare le autorizzazioni nei sistemi a valle. Anche dopo un cambio di modello ogni richiesta deve essere verificata nel contesto utente appropriato. Un argomento sintatticamente valido non autorizza l’accesso né l’aggiramento di un rifiuto.

Nell’esempio l’applicazione deve gestire chiaramente accessi negati, dati mancanti ed errori temporanei. Questi casi possono richiedere passaggi successivi diversi. Un errore non deve provocare automaticamente una richiesta più ampia o permessi aggiuntivi.

Che cosa facilita davvero l’adattatore

Un’interfaccia circoscritta e documentata può limitare le modifiche. Se ambito degli strumenti, modello dati e contratto degli errori restano stabili, dopo il cambio di modello potrebbe bastare adattare il collegamento specifico del fornitore e le relative istruzioni. Non è quindi necessariamente richiesta una ricostruzione completa.

In un flusso che mostra direttamente dati dello strumento verificati senza generare una continuazione libera, il punto di errore qui illustrato può essere più limitato. Restano pertinenti gli altri controlli su input, permessi e risultati. Conta il flusso effettivamente utilizzato.

Valutare il cambio attraverso il comportamento

Microsoft descrive confronti sugli stessi casi con attenzione separata ai singoli errori. Includa rifiuti degli strumenti e risultati mancanti. Registri se dopo un errore nasce una limitazione corretta, un’azione successiva non autorizzata o un’affermazione priva di riscontro.

Un collegamento funzionante è una parte utile dell’intercambiabilità. Per il rilascio conta anche che la nuova configurazione rispetti limiti e decisioni previsti nel flusso applicativo.

Fonti

• OWASP 2025 — Excessive Agency

• Microsoft — Evaluate models, prompts, and agents