Perché il Suo Contratto con un Vendor AI Deve Includere una Clausola sugli Evals

Se il Suo vendor AI non riesce a mostrarle un insieme di test con punteggio che dimostri il funzionamento del sistema su casi mai visti in precedenza, non sta acquistando un prodotto: sta acquistando una demo. Chieda gli evals prima di firmare, non dopo aver ricevuto la fattura.

I founder e i CTO che valutano vendor AI sono diventati bravi a riconoscere una demo ben confezionata. Quello che i più non hanno ancora imparato è come distinguere una demo che funziona perché è stata provata a tavolino da un sistema che funziona perché è stato testato. Il divario tra le due cose è esattamente lo scopo degli evals, e si tratta della domanda più utile che possa porre durante un processo di selezione di un vendor.

Cos'è concretamente un eval

Un eval è un insieme fisso di input — domande reali, documenti reali, casi limite reali del suo dominio — abbinato a output attesi e valutati, eseguito automaticamente ogni volta che il prompt sottostante, il modello o la logica di recupero cambia. Invece di "sembrava funzionare quando l'ho provato," si ottiene un numero: l'87% dei casi supera il test, rispetto al 74% dello sprint precedente.

Non si tratta di strumenti esotici. OpenAI ha reso open source un framework di base proprio a questo scopo nel 2023 (openai/evals), e ogni studio AI serio da allora ha costruito una propria versione, personalizzata o pronta all'uso. Il concetto precede gli LLM: è semplicemente il testing automatizzato applicato a un sistema i cui modi di fallire sono probabilistici anziché deterministici.

Il motivo per cui questo è più importante per l'AI che per una tipica web app è il seguente: un endpoint REST restituisce il JSON corretto oppure no. Una funzionalità LLM può restituire una risposta errata ma plausibile nel 15% dei casi, e una demo con dieci prompt scelti ad hoc non lo farà mai emergere. Gli evals sono l'unico modo per vedere il tasso di errore prima che lo vedano i suoi clienti.

Perché questo è un problema del committente, non solo degli ingegneri

Se sta assumendo qualcuno per sviluppare un chatbot personalizzato, un sistema di supporto basato su RAG o un workflow agentivo, il pitch deck del vendor le mostrerà sempre e solo il percorso ideale. Non è disonesto, ma non è nemmeno informativo. Le domande che riducono davvero il rischio dell'acquisto sono:

• Quanti casi contiene il vostro insieme di evals e da dove provengono?
• Qual è il tasso di superamento attuale e qual è il trend nell'ultimo mese?
• Cosa succede al punteggio degli evals quando cambiate modello o modificate il prompt?
• Rieseguite gli evals prima di ogni deploy o solo quando qualcosa si rompe?

Un vendor che ha questa strumentazione risponderà con numeri. Uno che non ce l'ha risponderà con aggettivi: "è molto solido," "l'abbiamo testato parecchio." Questo è il segnale rivelatore.

Cosa inserire nel contratto

Tratti gli evals come tratterebbe la copertura dei test in un normale SOW software: come un deliverable, non come un optional:

• Dimensione minima e composizione dell'insieme di evals. Per la maggior parte dei prodotti AI a singola funzionalità, 50-150 casi estratti da dati reali o realistici rappresentano un minimo ragionevole. Un bot di supporto ha bisogno di casi tratti da ticket reali del passato, non da domande sintetiche inventate dal vendor.
• Una soglia di superamento concordata prima dell'inizio dello sviluppo. L'80% può essere sufficiente per uno strumento interno; una funzionalità rivolta ai clienti o qualsiasi cosa riguardi dati sanitari o soggetti a compliance richiede un livello più alto e una revisione umana degli errori, non solo del punteggio.
• Un requisito di riesecuzione. Ogni aggiornamento di versione del modello, modifica del prompt o variazione della logica di recupero dovrebbe innescare lo stesso insieme di evals. Le regressioni silenziose sono il modo più comune in cui "funzionava nella demo" diventa "si è rotto in produzione tre settimane dopo il lancio."
• La proprietà dell'insieme di evals alla consegna. Al termine dell'ingaggio, lei dovrebbe uscirne con i casi di test e la logica di scoring, non solo con la funzionalità rilasciata. Se il vendor non è disposto a cedere tutto questo, vale la pena annotarlo durante la fase di scoping.

Niente di tutto ciò deve appesantire il contratto. Un breve allegato — dimensione dell'insieme di evals, soglia di superamento, trigger di riesecuzione e proprietà del harness alla fine — è sufficiente.

Quanto costa e perché vale la pena

La costruzione di una suite di evals iniziale aggiunge in genere circa il 10-15% al costo della funzionalità AI: tempo impiegato per raccogliere casi rappresentativi, scrivere il criterio di valutazione (o collegare un LLM-as-judge per output a risposta aperta) e integrare il harness nella CI affinché venga eseguito automaticamente. È una voce di costo reale, e un vendor che offre uno sviluppo AI sospettosamente rapido e sospettosamente economico spesso la sta semplicemente ignorando.

È poco rispetto all'alternativa. Il costo reale di un AI MVP non è solo lo sviluppo: è il costo di scoprire dopo il lancio che il sistema fallisce su 1 domanda reale su 5, per poi dover riprogettare tutto sotto pressione mentre i clienti stanno già ricevendo risposte sbagliate. Gli evals anticipano questa scoperta al momento precedente al lancio, quando si tratta di una conversazione in code review invece che di un incidente.

Il segnale d'allarme, in una frase

Se la risposta di un vendor a "mostratemi i vostri evals" è una demo invece di una dashboard, non hanno un sistema testato: hanno un sistema che non hanno ancora testato, e sarebbe lei a scoprire dove si rompe. È lo stesso istinto che sta dietro alla maggior parte degli altri segnali d'allarme in un ingaggio software: chiedere prove concrete, non fiducia.

Valutare i vendor AI non è fondamentalmente diverso dal valutare qualsiasi altro partner software: si cercano prove di rigore, non solo prove di output. Gli evals sono semplicemente il luogo in cui quel rigore emerge specificamente per il lavoro AI, e sono abbastanza economici da richiedere che non ci sia alcuna buona ragione per cui un vendor serio dovrebbe opporsi.

Se sta definendo lo scope di una funzionalità AI e vuole un partner che costruisca la suite di evals insieme alla funzionalità — non dopo che qualcosa si è rotto — parliamone.