Come testare in pilota una piattaforma di strategia AI: il back-test

Prima di impegnarsi con una piattaforma di strategia AI, la si sottopone a un back-test: si ripete un incarico che il team ha già completato, con il brief e il set di documenti originali, e si valuta l'output rispetto al deck che il consiglio ha visto davvero. Questa guida illustra il protocollo, una griglia di valutazione a sei dimensioni, gli artefatti da richiedere al fornitore e che aspetto hanno un esito positivo e uno negativo.

Come si valuta una piattaforma di strategia AI prima di impegnarsi, e che cosa dovrebbe verificare davvero un pilota? La risposta diretta è questa: si prova la piattaforma su un lavoro che il team ha già completato, con lo stesso brief e gli stessi documenti di cui disponeva allora, e si valuta l'output rispetto al deck che il consiglio o il comitato investimenti ha visto davvero. Un pilota costruito su questo principio dice ciò che nessuna dimostrazione può dire, perché la risposta corretta e i punti difficili sono già noti. Tutto il resto di questo articolo è un protocollo per fare esattamente questo.

L'onere ricade sull'acquirente perché una dimostrazione del fornitore è costruita per provare la scorrevolezza, non il giudizio. Il fornitore sceglie i dati di esempio, formula la domanda e controlla la narrazione intorno all'output. Su materiale selezionato, un modello linguistico apparirà quasi sempre impressionante, perché le condizioni del test hanno eliminato le due cose che mandano davvero in crisi il lavoro di strategia: documenti disordinati e incompleti, e una domanda più difficile di quanto sembri a prima vista. La scorrevolezza in condizioni controllate è una proprietà della tecnologia; la correttezza sul problema specifico è una proprietà del sistema concreto applicato ai documenti reali, e solo chi acquista può misurare la seconda.

Regolatori ed enti di normazione puntano nella stessa direzione. Nel settembre 2024 la Federal Trade Commission degli Stati Uniti ha annunciato l'Operation AI Comply, un'azione coordinata di cinque provvedimenti esecutivi contro operatori che si appoggiavano all'hype sull'AI o avanzavano dichiarazioni di performance senza prove, compresa un'azienda che non aveva verificato se l'output della sua AI fosse all'altezza della competenza dei professionisti che diceva di sostituire^[1]. La posizione della commissione è che non esiste alcuna esenzione per l'AI dalle leggi vigenti sulle affermazioni ingannevoli^[1]. Un acquirente che accetta la narrazione di performance di un fornitore senza prove è esposto esattamente alla falla che la FTC ha perseguito: un'affermazione che nessuno ha verificato.

Anche l'impostazione basata sulla misurazione ha un posto consolidato nel lavoro sugli standard. Il National Institute of Standards and Technology degli Stati Uniti ha pubblicato il suo Artificial Intelligence Risk Management Framework nel gennaio 2023 per l'uso volontario da parte delle organizzazioni che sviluppano, implementano o utilizzano sistemi di AI, costruendolo intorno a quattro funzioni: governare, mappare, misurare e gestire^[2]. Il framework descrive un processo flessibile, strutturato e misurabile per affrontare il rischio dell'AI, e tratta misurazione e monitoraggio come precondizioni della fiducia, non come optional^[2]. Un back-test è quella funzione di misurazione applicata a una concreta decisione di acquisto.

Le sezioni che seguono presentano il protocollo per intero: come selezionare e condurre l'incarico di back-test, la griglia a sei dimensioni per valutare l'output, gli artefatti da esigere dal fornitore, chi dovrebbe condurre e approvare il pilota, e i due disegni di pilota che producono in modo affidabile una risposta sbagliata. L'obiettivo, dall'inizio alla fine, è che la decisione di adozione poggi su prove generate internamente, non su una narrazione fornita dal fornitore.

Un back-test ripete un lavoro di strategia che il team ha già concluso e valuta la piattaforma rispetto a un risultato noto. Prende in prestito la sua logica dalla finanza quantitativa, dove una strategia viene testata su dati storici prima di impegnare il capitale. Il protocollo prevede quattro passaggi.

1. Selezionare un incarico completato e congelare gli input. Recuperare il brief originale esattamente come fu consegnato e il set di documenti di cui il team disponeva effettivamente all'epoca. Nulla di successivo: nessun dato finale, nessun feedback del consiglio, nessun documento prodotto dopo la raccomandazione. Il test è valido solo se la piattaforma vede esattamente ciò che ha visto il team.
2. Far girare la piattaforma fino a un deck finito e registrare le condizioni di esecuzione. Annotare quale configurazione del modello è stata usata, quanto è durata l'esecuzione, quali prompt o input di perimetro sono stati necessari e dove sono intervenute persone. Queste condizioni fanno parte della prova: un risultato che regge solo dopo pesanti correzioni manuali è un prodotto diverso da uno che regge in un'esecuzione pulita.
3. Valutare l'output rispetto al deck finale prodotto dal team, con la griglia fissa a sei dimensioni descritta nella sezione successiva. Valutare ogni dimensione, comprese quelle in cui la piattaforma va bene, così che il profilo sia confrontabile tra fornitori e nel tempo.
4. Confrontare e decidere. Dove l'output della piattaforma differisce dal deck del team, chiedersi quale versione avrebbe preferito il consiglio e dove la piattaforma ha trovato qualcosa che il team aveva trascurato. Sono quelle differenze, non la rifinitura complessiva, il vero risultato.

Il valore del protocollo sta nella verità di riferimento che offre a chi valuta: si sa già quali dati erano trappole e quali slide il consiglio ha contestato, quindi ogni affermazione può essere verificata rispetto a un risultato che il fornitore non controlla. È ciò che rende impossibile spacciare per analisi un output scorrevole ma vuoto.

Una cautela sul perimetro. Un singolo back-test è un solo dato su una sola classe di problemi. Se il budget del pilota lo consente, si conducono due incarichi di tipo diverso, per esempio uno screening di ingresso in un mercato e una revisione di portafoglio, per verificare se la performance regge sul tipo di lavoro che si commissiona davvero. Il protocollo è abbastanza economico da ripetere, perché gli input esistono già.

L'output del back-test va valutato su sei dimensioni fisse. Fissarle in anticipo conta: impedisce alla valutazione di scivolare verso ciò che la piattaforma fa bene per caso, e rende confrontabili i risultati se si testa più di un fornitore. La griglia ha anche un'eco normativa. L'AI Act dell'UE richiede che le istruzioni per l'uso dei sistemi di AI ad alto rischio indichino il livello di accuratezza, comprese le relative metriche, rispetto al quale il sistema è stato testato e convalidato, affinché i deployer possano interpretare l'output e usarlo in modo appropriato^[3]. Un acquirente che applica questa griglia fa, in miniatura, ciò che quella disposizione si aspetta dal deployer: testare rispetto a metriche dichiarate prima dell'uso.

Due dimensioni meritano particolare attenzione perché è lì che i sistemi scorrevoli falliscono. La verificabilità delle fonti è la dimensione che distingue uno strumento di analisi da un generatore di testi ben scritti. Le omissioni sono la dimensione che gli acquirenti dimenticano più spesso di valutare: una piattaforma può produrre un deck corretto e ben documentato che manca il punto a cui il consiglio teneva davvero, e solo il confronto con il deck reale lo rivela. Vanno valutate tutte e sei le dimensioni ogni volta, registrando le prove di ogni punteggio, perché la scheda di valutazione è essa stessa l'artefatto su cui poggia l'approvazione.

L'incarico scelto determina quanto il back-test può dire. Tre criteri governano la selezione, e tirano in direzioni opposte: ci si aspetti un compromesso più che un caso perfetto.

• Abbastanza recente da poter essere ricostruito. Il brief originale, il set di documenti così com'era all'epoca e il deck finale devono ancora esistere ed essere recuperabili. Questo riflette il principio di limitazione della conservazione nel GDPR del Regno Unito, articolo 5(1)(e), in base al quale i dati personali non devono essere conservati in forma identificabile più a lungo del necessario per le finalità del trattamento^[4]. Se la politica di conservazione ha già fatto il suo lavoro, i materiali sono andati perduti e l'incarico non può essere sottoposto a back-test, per quanto buono sia come candidato.
• Abbastanza contestato da essere informativo. Va scelto un incarico in cui il consiglio o il comitato investimenti ha opposto resistenza: dove un'ipotesi chiave è stata messa in discussione, un exhibit è stato contestato o la raccomandazione è stata rielaborata. Un incarico senza attriti non mette alla prova nulla, perché non c'erano trappole. Uno contestato mostra come la piattaforma gestisce l'ambiguità, le prove deboli e una domanda che ha cambiato forma in corso d'opera, che è esattamente dove il lavoro di strategia generato dall'AI tende a fallire.
• Non più riservato di quanto consentano i termini sui dati del pilota. Il set di documenti viene caricato presso il fornitore in base all'accordo di trattamento dei dati del pilota, quindi l'incarico deve essere uno che si è autorizzati a trattare su infrastrutture esterne. Tutto ciò che riguarda dati personali, transazioni in corso o materiale riservato di un'operazione è fuori perimetro per un primo pilota, a meno che l'accordo non lo copra esplicitamente.

Una shortlist pratica è questa: una valutazione di mercato o dei concorrenti degli ultimi uno o due anni, una decisione make-or-buy o di portafoglio passata per almeno due iterazioni del consiglio, oppure uno screening di due diligence in cui il team ha poi scoperto quale sarebbe dovuta essere la risposta. Meglio evitare l'incarico più recente se le sue lezioni sono ancora politicamente delicate, ed evitare il più semplice, perché un back-test che non chiede nulla non insegna nulla.

Prima che un qualsiasi documento venga condiviso, il fornitore dovrebbe essere in grado di produrre un insieme di artefatti che permettano di esaminare come si comporta la piattaforma e come verrebbero trattati i dati. Vanno richiesti per iscritto all'inizio del pilota, e un rifiuto o un ritardo su uno qualsiasi di essi va considerato un risultato in sé.

• Un deck di esempio con fonti cliccabili. È l'artefatto più rivelatore in assoluto e non richiede alcun dato da parte dell'acquirente. Si aprono le fonti di un campione di affermazioni e si verifica se ciascuna fonte dice ciò che la slide afferma. Se il deck di esempio dello stesso fornitore non supera quell'ispezione, la dimensione della verificabilità del pilota ha già la sua risposta.
• L'accordo di trattamento dei dati. Ai sensi dell'articolo 28(3) del GDPR del Regno Unito, un contratto tra titolare e responsabile deve contenere otto clausole minime: trattamento solo secondo le istruzioni documentate del titolare, un obbligo di riservatezza, misure di sicurezza adeguate, condizioni sui sub-responsabili, assistenza per i diritti degli interessati, assistenza per gli obblighi di sicurezza e di notifica delle violazioni del titolare, cancellazione o restituzione dei dati a fine contratto, e audit e ispezioni^[5]. La bozza del fornitore va verificata rispetto a quell'elenco, invece di darla per completa.
• L'elenco nominativo dei sub-responsabili. Un responsabile non può avvalersi di un sub-responsabile senza la previa autorizzazione scritta, specifica o generale, del titolare, e resta responsabile della conformità del sub-responsabile^[5]. Bisogna sapere, per nome, quali fornitori di modelli, provider di hosting e altri terzi toccherebbero i documenti, prima che il pilota inizi.
• La dichiarazione sulla residenza dei dati. Dove i documenti sono conservati ed elaborati, in quali giurisdizioni e con quali meccanismi di trasferimento. Per un'azienda europea si tratta spesso di un requisito bloccante, e dovrebbe essere enunciato con precisione sufficiente a essere verificabile, non come uno slogan di marketing.
• La politica di conservazione e cancellazione. Che cosa viene conservato, per quanto tempo e che cosa accade alla fine del contratto. L'articolo 28(3) richiede che, a scelta del titolare, il responsabile cancelli o restituisca tutti i dati personali alla fine del contratto e cancelli le copie esistenti, salvo che la conservazione sia richiesta per legge^[5]. La stessa domanda va posta per i documenti aziendali riservati, non solo per i dati personali.
• Un export della traccia di audit. Il registro di ciò che la piattaforma ha fatto: quali documenti sono stati letti, che cosa è stato prodotto, che cosa è stato modificato e da chi. Va richiesto un export di esempio durante il pilota, confermando che sia abbastanza completo da permettere a un revisore di ricostruire come si è arrivati a una conclusione.

Due di questi artefatti svolgono un doppio ruolo. Il deck di esempio con fonti cliccabili anticipa la verificabilità della piattaforma prima che sia stato condiviso qualsiasi cosa, e l'export della traccia di audit anticipa se il funzionamento della piattaforma possa essere verificato affatto. Un fornitore che produce entrambi senza esitazione dice qualcosa su come la piattaforma è stata costruita; un fornitore che non ci riesce ha già risposto in negativo alla domanda di acquisto.

Un pilota senza governance produce un'opinione, non una decisione. Tre ruoli vanno fissati prima che il back-test venga eseguito.

• Il valutatore dovrebbe essere una persona che ha lavorato all'incarico originale, perché solo lei può fornire la verità di riferimento da cui dipende la valutazione: quale ipotesi il consiglio ha contestato, e quale slide ha richiesto al team tre riscritture. Senza quella conoscenza diretta, la valutazione di omissioni ed errori si riduce a congetture, che è esattamente la modalità di fallimento che un back-test esiste per prevenire.
• Un secondo revisore dovrebbe valutare l'output in modo indipendente prima che i punteggi vengano confrontati. Non serve nulla di elaborato: due valutatori, la stessa griglia e una breve sessione di riconciliazione in cui i punteggi divergenti vengono discussi alla luce delle prove. Così il risultato non poggia sulla memoria di una sola persona.
• L'approvazione spetta al responsabile del budget o, in una società di consulenza, al managing partner. Chi detiene la decisione di acquisto dovrebbe vedere la scheda di valutazione, le condizioni di esecuzione e i controlli a campione sulle fonti, e dovrebbe essere in grado di spiegare il risultato a un consiglio o a un comitato investimenti senza che il valutatore sia presente.

Esito positivo e negativo vanno definiti prima dell'esecuzione, per iscritto, così che i criteri non possano essere rinegoziati una volta noto il risultato. Un esito positivo significa che l'output ottiene punteggi accettabili su tutte e sei le dimensioni della griglia, con ogni fonte campionata verificata: l'inquadramento è solido o migliore, la struttura reggerebbe una lettura da parte del consiglio, il so-what è presente sugli exhibit che contano, e omissioni ed errori rientrano nella tolleranza fissata in anticipo. I risultati parziali vanno registrati come tali, perché una piattaforma che supera cinque dimensioni e ne fallisce una è una conversazione di acquisto diversa da una che le supera tutte e sei.

Il caso di esito negativo più importante da nominare esplicitamente è il fallimento scorrevole: l'output si legge bene, la linea narrativa è pulita e le fonti non reggono. Quando si aprono i documenti citati e si scopre che non affermano ciò che le slide dichiarano, è un esito negativo su verificabilità ed errori, per quanto rifinito sia il deck, ed è un motivo di esclusione, non una detrazione. Altri casi di esito negativo sono un output che ha richiesto correzioni umane sostanziali e non documentate per raggiungere lo stato finale, e una traccia di audit troppo esile per ricostruire come si sia arrivati alle conclusioni.

La maggior parte dei piloti falliti fallisce in fase di disegno, prima che la piattaforma abbia fatto qualsiasi cosa. Due disegni spiegano la maggior parte dello spreco.

• Giudicare sulla base di una demo del fornitore. Una dimostrazione serve a una cosa sola: decidere se la piattaforma merita un back-test.
• Giudicare solo sulla velocità. Il tempo fino al deck è la metrica più facile da misurare e la meno informativa, perché la velocità misura la produttività, non se l'analisi è corretta. Una piattaforma che produce un deck scorrevole in un pomeriggio ha risolto la metà facile del problema; la metà che conta è se ogni affermazione sopravvive al confronto con la sua fonte. La velocità va misurata solo dopo che la verificabilità è stata superata, e mai al suo posto.

Ciò che il pilota dovrebbe lasciare è una piattaforma che si possa sottoporre a back-test affatto. Significa un sistema che accetta il brief e i documenti, produce un deck pronto per il consiglio ed espone le proprie prove: ogni affermazione riconducibile alla fonte su cui poggia, così che la griglia a sei dimensioni possa essere davvero applicata.

Decisity è una piattaforma di consulenza strategica AI-native che trasforma un brief e dei documenti in deck pronti per il consiglio, con ogni affermazione riconducibile alla sua fonte. È progettata per essere valutata esattamente con questo protocollo: la si esegue su un incarico completato, si valuta l'output rispetto al deck che il consiglio ha visto e si ispezionano le fonti dietro ogni affermazione. Per vedere quel flusso di lavoro dall'inizio alla fine, la pagina come funziona descrive il processo in tre fasi, dall'ingestione dei documenti al deck finito, ed è possibile richiedere una demo come primo passo verso un back-test sul proprio materiale.

Letture correlate:

• Presentare un'analisi assistita dall'IA a un consiglio scettico
• Come verificare una presentazione strategica generata dall'IA
• Documenti riservati e strumenti di IA: cosa verificare

• FTC: FTC Announces Crackdown on Deceptive AI Claims and Schemes (25 September 2024)
• NIST: NIST Risk Management Framework Aims to Improve Trustworthiness of Artificial Intelligence (26 January 2023)
• EU AI Act Service Desk: Article 13, Transparency and provision of information to deployers
• ICO: Principle (e): Storage limitation (UK GDPR guidance)
• ICO: What needs to be included in the contract (contracts between controllers and processors, UK GDPR Article 28(3))