Le eval AI di terze parti sono ora un requisito d'acquisto — leggile da buyer

OpenAI ha appena pubblicato un playbook condiviso per valutazioni affidabili di terze parti, un framework strutturato su come le eval dei modelli frontier dovrebbero essere progettate, condotte e documentate. Per i ricercatori è metodologia. Per i CTO è qualcos'altro: un'anteprima dello standard che i team di procurement e infosec dovranno applicare nel giro di uno o due trimestri. La parte che quasi nessuna coverage coglie è che questo documento consegna ai buyer una checklist — e la vera domanda è se sai come usarla.

Come è cambiato il modo in cui le eval vengono inquadrate

Le linee guida di OpenAI organizzano le eval di terze parti in tre track distinte: capability evaluations (cosa sa fare davvero il modello?), safeguard evaluations (quali comportamenti è stato addestrato o istruito a sopprimere?) e validity assessments (i benchmark misurano davvero quello che dicono di misurare?). Ogni track, sostiene il documento, richiede competenze diverse da parte dell'evaluator, diversi livelli di accesso agli internals del modello e standard di reporting differenti.

Il documento fa anche una distinzione netta tra eval condotte con la cooperazione del provider e quelle condotte in modo avversariale o indipendente. Le eval cooperative ottengono un accesso più completo, ma rischiano di orientare i risultati verso la narrativa preferita dal provider. Le eval indipendenti preservano l'obiettività, ma spesso lavorano solo sugli output del modello, perdendo gli artefatti di instruction-tuning o i default del system prompt — dettagli che contano moltissimo in produzione.

Questo è il framework che i tuoi vendor stanno per adottare nella loro documentazione di sicurezza. Il tempismo non è casuale: gli obblighi di conformity assessment dell'EU AI Act per i sistemi ad alto rischio entrano in piena applicazione quest'anno, e diversi grandi framework di procurement enterprise — incluse le linee guida AI per i contractor federali statunitensi — stanno convergendo sui requisiti di eval di terze parti come prova accettabile di due diligence.

Perché questo cambia i conti sul fidarsi delle dichiarazioni di sicurezza dei vendor

Fino a poco tempo fa, un vendor di modelli frontier poteva consegnarti una model card, citare qualche benchmark accademico e considerare il lavoro fatto. Quell'era sta finendo. Quello che il playbook di OpenAI segnala — anche involontariamente — è che il settore si sta coagulando attorno a un vocabolario condiviso su cosa rende un'eval credibile. Quel vocabolario verrà usato contro di te in un vendor review se non riesci a parlarlo.

Il problema più difficile è che la maggior parte dei report di eval in circolazione fallisce almeno una delle tre track. Le capability claim sono spesso ottimizzate per il benchmark, addestrate su dati che si sovrappongono al test set in modi che il report non rivela. Le safeguard claim sono quasi sempre eval cooperative — il che significa che il provider ha selezionato i prompt, definito le categorie di danno e in alcuni casi ha eseguito la valutazione in prima persona, con una firma nominale di terze parti sulla copertina. La validity è la track che quasi ogni report di vendor salta completamente, perché richiede all'evaluator di spiegare perché il proprio benchmark predice il comportamento nel mondo reale — un argomento difendibile, ma difficile.

Per il tuo stack, questo conta soprattutto quando stai facendo il deploy di un modello in contesti dove un errore ha conseguenze normative, reputazionali o contrattuali: automazione customer-facing, elaborazione di documenti legali, strumenti di HR screening, recupero di informazioni mediche. In quei contesti, una capability claim senza una sezione sulla validity non è una prova — è marketing.

→ Prenota un architecture audit con Domani AI se sei a metà procurement su un modello frontier e hai bisogno di un parere esterno su quanto regge la documentazione delle eval.

La mossa del lunedì mattina: un decision tree per leggere un report di eval

Quando un vendor ti consegna un report di eval — o quando stai valutando un modello per il deploy interno — passalo attraverso questi gate prima che influenzi una decisione di build o buy.

Gate 1: Chi ha condotto l'eval, e a cosa aveva accesso?

• Se l'evaluator è stato pagato direttamente dal provider del modello e non aveva un protocollo pre-registrato: tratta le capability claim come indicative, non definitive.
• Se l'evaluator aveva accesso ai pesi o al fine-tuning: le safeguard claim sono più affidabili rispetto agli audit solo sugli output, ma verifica la disclosure dei conflitti di interesse.
• Se l'evaluator era completamente indipendente senza accesso al provider: la validità della scelta del benchmark conta più del punteggio in sé.

Gate 2: Le claim su capability, safeguard e validity sono separate o raggruppate?

• I report raggruppati che usano un unico punteggio per coprire tutte e tre le track sono quasi sempre documenti di marketing. Separali manualmente se necessario: trova dove finiscono le capability claim e dove iniziano quelle di sicurezza.
• L'assenza di una sezione sulla validity è un campanello d'allarme. Chiedi al vendor: perché questo benchmark predice il tuo caso d'uso in produzione?

Gate 3: Qual è lo scope della safeguard evaluation?

• Chiedi esplicitamente: le categorie di danno sono state definite dall'evaluator o dal provider?
• Chiedi: quale metodologia di adversarial prompting è stata usata, ed era coerente con il tuo contesto di deployment (accesso API, system prompt, tool use)?
• Se la safeguard eval è stata eseguita sul modello base ma stai deployando una variante fine-tuned o con system prompt: l'eval non si applica al tuo deployment. Richiedine una nuova o delimita la tua responsabilità di conseguenza.

Gate 4: Il report è riproducibile?

• Il benchmark è pubblico? I prompt sono divulgati? Se nessuno dei due: il report non può essere verificato in modo indipendente, e dovresti incorporare quell'incertezza nella tua valutazione del rischio.

Questa settimana: recupera la documentazione delle eval per ogni modello frontier attualmente in procurement o già live nel tuo stack. Esegui prima i gate 1 e 3 — catturano la maggior parte dei fallimenti di validity con il minimo investimento di tempo. Segnala tutto ciò che non supera il gate 3 per una revisione legale e di compliance immediata, prima del prossimo incremento di deployment.

Quanto costa, e quanto ti fa risparmiare

Leggere un report di eval in modo critico aggiunge da 2 a 4 ore per vendor al tuo ciclo di procurement. Commissionare un architecture review indipendente rispetto a un contesto di deployment specifico — il passo successivo quando un report non supera il gate 2 o 3 — richiede da 3 a 6 settimane e costa soldi veri. Non è una richiesta piccola in un trimestre sotto pressione di rilascio.

Il costo controfattuale è più difficile da vedere finché non arriva. Una safeguard claim che non regge sotto il tuo system prompt effettivo è un'esposizione di responsabilità, non un problema del vendor. L'enforcement normativo sotto l'EU AI Act per i fallimenti di sistemi ad alto rischio può arrivare al 3% del fatturato annuo globale — e "l'eval del vendor diceva che era sicuro" non è mai stata accettata, in nessuna linea guida pubblicata, come difesa di compliance. La mossa del lunedì mattina non riguarda la perfezione; riguarda il sapere quali claim nel tuo stack attuale sono portanti e quali sono teatro, prima che qualcun altro lo scopra al posto tuo.