Prima di comprare un assistente AI, sottoponilo a 20 casi reali

Mossa 1 — Costruisci venti casi che assomiglino al lavoro, non alla demo

Per ogni caso scrivi prima la risposta attesa o una rubrica. Un’estrazione può avere campi esatti; una risposta scritta può essere valutata su correttezza, completezza, tono e citazioni; una classificazione ha un’etichetta di riferimento. Segna l’errore bloccante in modo binario. OpenAI, nella guida agli eval, usa dataset con input rappresentativi e una ground truth, cioè una risposta corretta fornita da una persona. La procedura vale anche se nessuno dei due assistenti è OpenAI. MODELLO DEL CASO ID: [01-20]. TIPO: [normale, difficile, bloccante]. INPUT: [testo o file anonimizzato]. RISULTATO ATTESO: [campi o criteri]. FONTE DELLA RISPOSTA: [documento, regola, esperto]. ERRORE BLOCCANTE: [evento preciso]. PUNTEGGIO: correttezza 0-4; completezza 0-3; formato 0-2; chiarezza 0-1. NOTE: [eccezioni]. Non includere casi scelti perché uno dei prodotti li sa già risolvere. Crea due sessioni nuove. Usa identico input, lingua, allegati, istruzioni, accesso al web e strumenti. Se un assistente non supporta una funzione essenziale, registralo come limite: non compensare manualmente soltanto per un concorrente. Annota nome commerciale, versione o modello dichiarato, data, piano e impostazioni. Ripeti almeno i tre casi bloccanti due volte, perché i modelli generativi possono produrre risposte diverse allo stesso input.

CRITERIO DA COPIARE Usa esclusivamente l’input e le fonti fornite. Produci il risultato nel formato richiesto. Non inventare dati mancanti: scrivi NON DISPONIBILE. Se due fonti sono in conflitto, mostra entrambe e non decidere senza una regola. Cita la pagina o la riga per ogni numero decisivo. Prima della risposta finale elenca i controlli eseguiti. Non inviare, modificare o approvare nulla. Questo testo non rende identici i sistemi, ma fissa le regole del compito. Salva le risposte come A e B senza il marchio e consegnale a chi conosce il processo. La valutazione alla cieca riduce l’effetto del nome, dell’interfaccia o delle aspettative. Il revisore assegna il punteggio senza correggere il testo durante la lettura e annota minuti necessari per arrivare a un risultato approvabile. Un errore bloccante porta il caso a zero anche se il resto è scritto bene.

Esempio: due assistenti devono estrarre consegna, importo e condizioni da un preventivo. A riporta tutti i campi ma trasforma «consegna indicativa» in data confermata; B lascia il campo da verificare e cita la pagina. Il testo di A può sembrare più completo, ma commette l’errore che il processo voleva impedire. Il test premia B. La guida su come leggere benchmark e classifiche AI aiuta a distinguere questa prova locale da una graduatoria generale.

Mossa 3 — Unisci qualità, costo, tempo e rischio in una decisione

La matrice finale contiene una riga per caso e colonne per punteggio, errore bloccante, tempo del modello, minuti di revisione, costo stimato e note. Calcola il tasso di casi approvati al primo tentativo e la mediana dei minuti umani. Non sommare semplicemente tutti i punti: se uno strumento sbaglia due dei tre casi bloccanti, deve essere escluso dal processo anche se vince sui testi facili. Definisci prima la regola d’acquisto. Esempio: almeno 17 casi su 20 approvabili, zero errori bloccanti in sei esecuzioni, non più di cinque minuti mediani di revisione e costo totale entro il budget. Poi confronta licenza, consumi, integrazione, formazione e tempo umano. Un prodotto più caro può costare meno per risultato; uno rapido può diventare lento se richiede continui controlli. Il NIST AI Risk Management Framework insiste su misurazione, valutazione, validità e affidabilità nelle condizioni reali di uso. Non usare i venti casi una volta sola. Conserva input, rubriche e risultati senza dati personali e ripeti il test quando cambia modello, piano, prompt o strumento collegato. Aggiungi gli errori reali emersi in produzione, ma tieni separato un piccolo gruppo di casi mai usato per ottimizzare le istruzioni: altrimenti finirai per insegnare il test invece di migliorare il processo. Per agenti con azioni, affianca anche i controlli della guida su come valutare un agente AI prima della produzione.

CHECKLIST FINALE [ ] 12 casi normali, 5 difficili, 3 bloccanti. [ ] Dati anonimizzati o sintetici. [ ] Risposta attesa scritta prima. [ ] Condizioni identiche e versioni annotate. [ ] Casi bloccanti ripetuti. [ ] Valutazione A/B alla cieca. [ ] Minuti di revisione e costi inclusi. [ ] Soglia fissata prima. La conclusione corretta può essere anche «nessuno dei due»: evita di comprare una demo e crea un elenco preciso di ciò che deve migliorare. Una guida tecnica produce valore quando trasforma un concetto in una sequenza applicabile. Ogni passaggio deve indicare input, controllo ed esito, così il lettore può adattarlo al proprio contesto senza affidarsi a una ricetta opaca. Nel caso di “Prima di comprare un assistente AI, sottoponilo a 20 casi reali”, questo significa leggere la novità oltre l’annuncio e capire quali parti del lavoro vengono realmente modificate. Il rischio è saltare direttamente allo strumento. Dati disordinati, obiettivi vaghi e responsabilità assenti non vengono risolti dall’AI. Prima dell’automazione occorre rendere osservabile il lavoro e stabilire cosa significa un risultato accettabile. Le pratiche migliori convergono su valutazioni ripetibili, fonti tracciabili e supervisione proporzionata. Strumenti e modelli cambieranno; un metodo documentato rimarrà riutilizzabile e permetterà di confrontare alternative con criteri coerenti. La notizia è quindi un indicatore di una trasformazione più ampia, che va seguita attraverso risultati e condizioni operative anziché con la sola successione degli annunci.

Quello che conta adesso

Raccogliere venti casi anonimizzati e rappresentativi, con risposta attesa o criteri di correttezza scritti da una persona competente. Questo primo passo serve a trasformare il tema in un perimetro verificabile: un responsabile, un input conosciuto, un risultato atteso e una misura precedente con cui confrontarsi. Senza questi elementi il progetto rimane una dimostrazione difficile da valutare. Eseguire i due assistenti con stesso input, allegati, lingua, strumenti e limiti, registrando versione, data, costo e tempo. L’azione deve essere documentata insieme ai criteri di controllo, indicando quali casi possono procedere e quali devono fermarsi. È così che l’esperienza delle persone diventa una regola applicabile e migliorabile nel tempo. Valutare alla cieca, separare errori bloccanti e scegliere soltanto se una soluzione supera la soglia definita prima del test. Prima di estendere il metodo è utile raccogliere correzioni, tempi e costi per alcune settimane. Gli errori vanno raggruppati per causa: dati, istruzioni, strumenti o eccezioni del processo. Ogni categoria richiede un intervento diverso. Una demo del fornitore seleziona condizioni favorevoli e non misura gli errori sul processo reale. È il punto da cui partire perché definisce l’effetto più immediato per professionisti e imprese. La sua importanza va misurata sul lavoro quotidiano: quante attività coinvolge, quali persone tocca e cosa accade quando il risultato non è corretto.

Venti casi ben scelti possono offrire un primo segnale operativo se includono esempi normali, difficili e bloccanti e se i limiti del campione sono dichiarati. Questo secondo elemento chiarisce perché non basta scegliere un prodotto. Servono un processo, dati affidabili e una responsabilità finale. L’adozione diventa sostenibile quando la tecnologia può essere osservata e corretta senza interrompere l’operatività. Qualità, costo, tempo e revisione umana vanno misurati insieme; un errore grave può annullare il punteggio di un caso. Il terzo punto indica la prospettiva di medio periodo. La decisione migliore non è necessariamente quella con più funzioni, ma quella che mantiene valore, controllo e possibilità di evoluzione quando cambiano modelli, prezzi o requisiti.