Come Valutare la Demo di un'Agenzia AI Prima di Firmare

La demo di un'agenzia AI dimostra esattamente una cosa: che il sistema funziona con gli input che l'agenzia ha scelto di mostrarle. Non dimostra che funziona con i suoi dati, i suoi edge case o i suoi utenti alle 2 di notte. Prima di firmare, deve sostituire i loro input con i suoi, guardare i fallimenti invece dei successi e far inserire il set di test nel contratto.

Questo conta più nei progetti AI che nel software tradizionale. Un'app CRUD o salva il record o non lo salva. Un agente basato su LLM può sembrare perfetto su cinquanta esempi curati e poi produrre con sicurezza risultati privi di senso al cinquantunesimo. Un founder che non riesce a distinguere una demo costruita ad arte da un sistema robusto sta comprando sulla fiducia.

Perché le demo AI sono così facili da falsare, anche involontariamente

Non è necessario che qualcuno sia disonesto perché una demo risulti fuorviante. Tre dinamiche si verificano in modo naturale:

• Gli esempi sono scelti con cura. Il team ha sviluppato il prototipo su un numero limitato di input, e sono quelli che funzionano. Le mostrano ciò che hanno testato. Se il set della demo è composto da dieci record puliti e ben formattati mentre la sua casella di posta reale contiene ticket di assistenza in due lingue senza punteggiatura, sta guardando un prodotto diverso da quello per cui pagherà.
• I fallimenti vengono filtrati prima che lei li veda. Un articolo recente molto condiviso descriveva un benchmark che assegnava a un modello un punteggio perfetto di 1,00 perché il sistema di valutazione saltava silenziosamente le tre domande a cui il modello aveva risposto male. Lo stesso accade nelle demo: un ciclo di retry, un fallback su una risposta predefinita o una riga eliminata in silenzio nascondono gli errori. Un punteggio del "98 percento" senza denominatore e senza un elenco degli errori è lo stesso trucco con un carattere tipografico più elegante.
• Il sistema è ottimizzato per la demo, non per la produzione. Temperatura bassa, una finestra di contesto enorme riempita con i suoi documenti esatti, un operatore umano che pre-elabora l'input. Niente di tutto ciò sopravvive al contatto con il traffico reale e i costi reali. Il contesto riempito in particolare è un segnale: fa sembrare ogni risposta ben fondata, moltiplicando silenziosamente il costo per token per singolo input — un aspetto su cui tornerà a interrogarsi più avanti.

Nulla di tutto ciò è in malafede. Ma l'onere di vedere oltre spetta a lei.

Porti i suoi input

La cosa più utile che può fare è presentarsi con i suoi dati. Non una descrizione dei suoi dati: i record effettivi.

Estragga da 20 a 50 esempi reali dal flusso di lavoro che l'agente dovrà gestire. Includa deliberatamente quelli problematici:

• Un ticket di assistenza scritto in due lingue senza punteggiatura
• Un PDF scansionato in cui la tabella è leggermente ruotata
• Un modulo lead in cui il campo azienda riporta "n/a" e il numero di telefono è nel campo email
• Due record che sembrano duplicati ma non lo sono
• Un messaggio che richiede qualcosa che l'agente dovrebbe rifiutare o scalare

Poi chieda all'agenzia di elaborarli in diretta, davanti a lei, e di mostrarle ogni output. Non una percentuale di accuratezza. Gli output grezzi, affiancati agli input.

Se chiedono una settimana per "preparare l'ambiente", anche questa è un'informazione utile. Un sistema che necessita di una settimana di preparazione per gestire 30 dei suoi record è un sistema che avrà bisogno di una settimana di preparazione per ogni nuovo segmento di clienti che aggiungerà.

Chieda di vedere i fallimenti

Ribalta il consueto copione della demo. Invece di "mostrami come funziona", chieda:

• "Mi mostri gli ultimi cinque input in cui ha prodotto una risposta errata." Un team serio li ha. Tiene un registro dei fallimenti perché è così che si migliora un sistema LLM. Un team che non ha fallimenti da mostrare o non ha testato abbastanza o non è trasparente con lei.
• "Cosa fa il sistema quando il modello sbaglia?" La risposta onesta prevede validazione, soglie di confidenza e un percorso verso un operatore umano. La risposta preoccupante è "raramente sbaglia". Ogni modello sbaglia in una certa percentuale dei casi; la questione progettuale è cosa succede dopo. Abbiamo approfondito i pattern in guardrail deterministici per le funzionalità AI.
• "Come fa a sapere che il sistema non è regredito dopo una modifica a un prompt?" Quello che sta cercando di sentire è la parola evals: un insieme fisso di input con output attesi che viene eseguito ad ogni modifica. Se non ne hanno uno, sarà lei il set di valutazione, in produzione.

Chieda cosa sta effettivamente girando

Una demo nasconde l'architettura, e l'architettura è ciò per cui pagherà nei prossimi due anni. Le chieda di illustrare il percorso di una richiesta per un singolo input, dall'inizio alla fine:

1. Qual è il modello, e si tratta di un'API di un provider o è self-hosted?
2. Quante chiamate al modello per input e quanto impiega la più lenta?
3. Quale retrieval viene eseguito, su quali documenti, aggiornati con quale frequenza?
4. Cosa è codice deterministico e cosa è lasciato al modello?
5. Quanto costa un singolo input in token, e come si traduce nel suo volume mensile atteso?

Presti particolare attenzione al teatro della complessità. Le agenzie presentano a volte una pipeline a cinque agenti con planner, critic e orchestratori perché sembra sofisticata su una slide. Nei nostri strumenti di outreach, dove analizziamo il sito di ciascun prospect e utilizziamo un modello locale per redigere una singola email personalizzata, la versione che estraeva i dati e redigeva la bozza in una singola chiamata ha superato la catena multi-step sia per costo che per qualità dell'output. Ogni passaggio aggiuntivo era un ulteriore punto in cui la pipeline poteva perdere contesto o allucinare un collegamento tra i passi. Abbiamo analizzato i compromessi in singola chiamata vs catene di agenti.

La semplicità non è automaticamente migliore, ma un team capace di spiegare perché ogni componente esiste è un team che comprende il sistema. Un team che non ci riesce sta manutenendo qualcosa che ha ereditato da un tutorial.

Valuti la storia della produzione, non solo il prototipo

Il divario tra una demo e un sistema in produzione è il punto in cui muoiono la maggior parte dei progetti AI. La buona notizia è che i 30 record che ha portato e la descrizione del percorso della richiesta a cui ha appena assistito le forniscono tutto il necessario per rendere concrete queste domande invece di lasciarle ipotetiche:

• Chi è il proprietario dei prompt e del set di valutazione dopo il lancio? Dovrebbe esserlo lei. Il set di valutazione è composto dai suoi 30 record più ogni fallimento che le hanno mostrato, con output corretti concordati. Si assicuri che sia esplicitamente citato nei deliverable, non descritto genericamente come "documentazione".
• Cosa succede quando il provider del modello depreca la versione su cui ha testato? I provider ritirano i modelli secondo un calendario preciso. La risposta che vuole sentire è: "sostituiamo il modello, rieseguiamo il set di accettazione e le mostriamo le differenze". Se rieseguire il set non è un'operazione da un solo comando, chieda perché.
• Come viene limitato il costo? Prenda il costo per token per singolo input ricavato dalla descrizione, lo moltiplichi per il suo volume mensile e chieda cosa impedisce che il conto sia dieci volte superiore. Un ciclo di retry fuori controllo o uno spam burst contro un endpoint non protetto lo scopriranno per lei. I rate limit e i budget per utente appartengono alla build, non a una fase successiva.
• Cosa viene monitorato? Come minimo: latenza, tasso di errore, tasso di fallback e una revisione qualitativa campionata. Il tasso di fallback è quello a cui prestare attenzione. È la versione in produzione di "cosa succede quando il modello sbaglia", e se sale dal 5 al 20 percento dopo una modifica a un prompt, quello è il suo campanello d'allarme per le regressioni. Se la risposta è "aggiungeremo il logging", non hanno mai messo in produzione un sistema di questo tipo.
• Come appare il terzo mese? Arrivano nuovi edge case, il set di valutazione cresce, un prompt viene modificato, un modello viene aggiornato. Chi riesegue il set ogni volta, e quanto costa al mese?

Un team che ha portato agenti dal pilota alla produzione risponderà a queste domande senza esitazione, perché è stato scottato da ciascuna di esse. La nostra guida dal pilota alla produzione elenca i failure mode specifici che riscontriamo più spesso.

Inserisca il set di test nel contratto

Ecco la mossa che separa un accordo rischioso da uno sicuro. Prenda gli input che ha portato alla demo, concordi con l'agenzia cosa costituisce un output corretto per ciascuno e inserisca tutto questo nello statement of work come test di accettazione.

Questo fa tre cose contemporaneamente. Costringe entrambe le parti a definire "funzionante" in termini concreti prima che cambino mano i soldi. Fornisce all'agenzia un obiettivo raggiungibile, che le buone agenzie apprezzano. E le dà una suite di regressione che continuerà a eseguire per tutta la vita del prodotto.

Concordi una soglia, non la perfezione. Qualcosa come "almeno il 90 percento del set di accettazione corretto, zero output nella categoria non sicura e ogni output errato instradato alla revisione" è realistico per la maggior parte dei flussi di lavoro documentali e di vendita. Il cento percento è un segnale che nessuno ha pensato al percorso di fallimento.

Una breve checklist per l'incontro

Si presenti con questa lista e imparerà più in un'ora che in tre presentazioni curate:

• Elabori i miei 30 input reali in diretta e mi mostri ogni output
• Mi mostri cinque fallimenti recenti e cosa ha modificato di conseguenza
• Mi illustri una richiesta dall'inizio alla fine: modelli, chiamate, retrieval, costo
• Cosa succede quando il modello sbaglia?
• Chi è il proprietario di prompt, eval e monitoraggio dopo il lancio, e quanto costa il terzo mese?
• Inserirà il set di accettazione e la soglia nel contratto?

Un'agenzia che accoglie queste domande è quella con cui può lavorare. Una che le tratta come ostili le sta dicendo come andrà il progetto.

Se sta valutando partner AI in questo momento e vuole un secondo parere su una proposta, o vuole vedere come gestiremmo i suoi 30 record più difficili, parliamone.