L’assistente che prepara le risposte commerciali funziona da settimane. Il fornitore aggiorna il modello e, su una domanda già nota, il sistema comincia a promettere una consegna che il listino non autorizza. Il caso è ipotetico: serve a mostrare perché il collaudo iniziale non basta a descrivere il comportamento futuro di un agente AI.
Un aggiornamento può riguardare il modello, le istruzioni, i documenti consultati oppure gli strumenti collegati. La verifica dovrebbe seguire ciò che cambia e includere alcuni comportamenti che devono rimanere stabili.
Propongo un piccolo repertorio di casi ripetibili, gestito da chi conosce il processo insieme al team tecnico.
Indice degli argomenti:
Conservare casi e criteri di accettazione
Il punto di partenza è raccogliere esempi utili del lavoro reale, dopo aver rimosso o protetto le informazioni che non servono alla prova. Per ogni caso occorrono la richiesta, il contesto disponibile e un criterio di accettazione. Una risposta modello può aiutare, ma non dovrebbe diventare l’unica formulazione ammessa.
Per l’assistente commerciale, il criterio potrebbe essere «non promettere una data quando manca una conferma logistica». Due risposte scritte diversamente possono entrambe rispettarlo. Una risposta elegante che inventa la data deve invece fallire. Questo modo di valutare rende il test comprensibile anche al responsabile commerciale.
Il repertorio dovrebbe includere richieste ordinarie e casi che in passato hanno generato problemi. Un documento mancante, due indicazioni in conflitto o una domanda fuori perimetro sono occasioni per osservare quando l’assistente chiede aiuto. Non occorre fingere che questo piccolo insieme rappresenti ogni possibile uso: la sua copertura va dichiarata.
Collegare ogni risultato alla configurazione
Per confrontare due esecuzioni bisogna sapere che cosa era in uso: modello dichiarato dal servizio, istruzioni applicate, versione dei documenti e configurazione degli strumenti. Se il fornitore non rende disponibile una versione precisa, questa limitazione va registrata e discussa, senza attribuire al test una riproducibilità che non possiede.
Una stessa richiesta può produrre esiti differenti. Ripetere i casi più delicati aiuta a vedere questa variabilità, pur senza garantire di averne esplorato ogni forma. Il numero di ripetizioni dipende dall’impiego e dal costo dell’errore. Va scelto prima del confronto, evitando di fermare la prova appena compare una risposta convincente.
Conviene conservare anche l’esito precedente. Una valutazione assoluta dice se la nuova versione supera il criterio; il confronto mostra se ha introdotto un difetto in una funzione già utilizzata. Sono informazioni diverse, entrambe utili a chi deve autorizzare il cambiamento.
Separare gli errori che richiedono decisioni diverse
Una variazione di tono non ha lo stesso peso di un’informazione inventata o di un’azione eseguita senza autorizzazione. Per questo suggerisco di classificare gli esiti in poche categorie leggibili, legate alle conseguenze. Non serve una tassonomia elaborata se nessuno saprà usarla durante un rilascio.
Il responsabile del processo dovrebbe stabilire quali errori impediscono l’attivazione e quali consentono una correzione successiva. Queste soglie non vanno dedotte dal punteggio medio. Nell’esempio commerciale, un miglioramento della cortesia non compensa l’introduzione di promesse di consegna infondate.
Se l’agente dispone di azioni operative, la prova deve considerare anche il loro esito nel sistema collegato. Leggere il messaggio «operazione completata» non dimostra che il dato sia stato aggiornato correttamente. Per i test conviene usare un ambiente separato, con conseguenze controllate.
Decidere il rilascio e imparare dagli incidenti
La scheda finale può indicare che cosa è cambiato, casi eseguiti, errori aperti e persona che autorizza il passaggio. Dopo il rilascio, gli incidenti pertinenti diventano nuovi casi di prova. In questo modo il repertorio cresce con l’esperienza del processo, invece di trasformarsi in un esercizio ripetuto senza utilità.
Il NIST AI Risk Management Framework è un riferimento volontario per questa attenzione alla valutazione nel ciclo di vita. Il metodo descritto qui non dimostra assenza di rischio. Offre però una base concreta per spiegare perché una modifica sia stata accettata e quali comportamenti rimangano sotto osservazione.
A proposito di AIPIA
AIPIA, Associazione Italiana Professionisti dell’Intelligenza Artificiale, è un’associazione professionale senza scopo di lucro con oltre 800 soci iscritti. Promuove formazione, aggiornamento e confronto sull’uso responsabile dell’AI nel lavoro. È socio effettivo UNINFO e partecipa alla UNI/CT 533 Intelligenza Artificiale. Il suo Comitato tecnico-scientifico è presieduto da Rafael Patron. L’associazione mette a disposizione risorse divulgative, tra cui un glossario pubblico dell’intelligenza artificiale, per aiutare professionisti e organizzazioni a comprendere termini, opportunità e limiti degli strumenti.
Questo contributo propone criteri operativi da discutere e adattare al proprio contesto; non presenta risultati di un’indagine sui soci né una validazione di prodotti commerciali.
Partecipa alla community