AI Procurement Checklist per Enti Pubblici e Sanitari

I responsabili acquisti di enti pubblici e sanitari dovrebbero valutare i fornitori AI su auditabilità, residenza dei dati, controlli di override umano e clausole di uscita, prima ancora di valutare la qualità della demo. Questi requisiti vanno inseriti nell'RFP stesso, perché aggiungerli a posteriori — quando il sistema è già in contatto con dati di cittadini o pazienti — è più lento, più costoso e talvolta impossibile senza un intervento strutturale.

La maggior parte dei team di procurement gestisce ancora la selezione di fornitori AI come un normale RFP software: funzionalità, prezzo, referenze, una demo. Questo approccio non intercetta le modalità di errore che mettono davvero in difficoltà i deployment nel settore pubblico e sanitario: un sistema AI che non sa giustificare una decisione, dati che finiscono nella giurisdizione sbagliata, o un rapporto con il fornitore da cui non si riesce a uscire senza perdere i propri dati. Ecco una checklist costruita attorno alle domande che contano.

Iniziate dall'auditabilità, non dall'accuratezza

Una demo di un fornitore mostrerà sempre il percorso ideale. Quello che dovete vedere è cosa succede quando il sistema sbaglia e se riuscite a ricostruire il perché.

• Chiedete un caso di errore registrato. Non un'ipotetica, ma una trascrizione reale del sistema che sbaglia, con l'audit trail che ha permesso di individuarlo.
• Verificate cosa viene effettivamente registrato. Come minimo: input, output, versione del modello e timestamp. Se il fornitore registra solo la risposta finale, non avrete modo di indagare un reclamo sei mesi dopo.
• Confermate che i log siano esportabili, non bloccati nel dashboard del fornitore. Se il vostro team legale o di compliance dovesse mai richiedere i dati per un audit, dovete poterli estrarre senza dipendere dalla collaborazione del fornitore.

È anche qui che l'architettura del sistema assume un peso silenzioso ma rilevante. Nel nostro lavoro con gli agenti, abbiamo riscontrato che una singola chiamata al modello ben definita è molto più facile da sottoporre ad audit rispetto a una catena di agenti in cinque passaggi, perché c'è un solo input, un solo output e un solo punto in cui cercare quando qualcosa va storto. Un fornitore che esegue una lunga catena di tool call e sub-agent per rispondere a una domanda semplice non sta necessariamente facendo qualcosa di sbagliato, ma si sta prendendo una superficie di spiegazione più ampia per il futuro — e dovreste chiedergli come registra i passaggi intermedi, non solo gli output finali. Se state valutando i fornitori proprio su questo asse, single-call vs agent chains è una lettura utile prima di pubblicare l'RFP.

La residenza dei dati e i diritti di accesso sono clausole contrattuali, non dettagli tecnici

Dove risiedono i dati, chi può accedervi e cosa ne accade alla scadenza del contratto sono questioni di procurement, non questioni IT da definire in un secondo momento.

• Ottenete risposte esplicite su dove vengono elaborati e archiviati i dati, compresi eventuali subprocessori (il provider LLM del fornitore, il cloud host o gli strumenti di analytics).
• Chiedete se i vostri dati vengono usati per addestrare i modelli del fornitore, e in caso affermativo, per conto di chi. Molti prodotti AI basati su API non usano di default i dati dei clienti per il training, ma le offerte gestite o con fine-tuning a volte lo fanno — e deve essere un opt-in esplicito, non una clausola sepolta in un aggiornamento dei termini di servizio.
• Nel settore sanitario, in particolare, verificate che il fornitore sia disposto a firmare un Business Associate Agreement se sono coinvolti dati PHI; un fornitore che esita su questo punto vi sta dicendo qualcosa su quanto prende sul serio il resto della checklist.
• Per tutto ciò che riguarda cittadini UE, comprendete i vostri obblighi ai sensi dell'EU AI Act. Molti degli obblighi ricadono sull'organizzazione che implementa il sistema, non solo sul fornitore — quindi il contratto deve stabilire chi fa cosa: chi conduce la valutazione del rischio, chi gestisce la documentazione tecnica, chi risponde a una richiesta di un'autorità di regolamentazione.

L'override umano è un requisito di progettazione, non un optional

Per qualsiasi sistema che influenzi l'idoneità a prestazioni sociali, una diagnosi o un esito legale, deve esserci una persona reale in grado di intervenire prima che si verifichi un danno, non dopo.

• Chiedete al fornitore di mostrarvi l'interfaccia di override reale, non di descriverla. Dove vede un operatore o un clinico il livello di confidenza dell'AI, e come può rifiutare o escalare una decisione?
• Verificate che il percorso di override sia abbastanza rapido da essere utile. Un processo di revisione che richiede tre giorni non aiuta chi si è visto negare una prestazione oggi.
• Capite il comportamento predefinito in caso di errore. Il sistema fallisce in modo chiuso (flag per revisione umana) o in modo aperto (procede con una stima)? Per le decisioni ad alto rischio, volete il fail closed come comportamento predefinito, non come opzione di configurazione che qualcuno potrebbe dimenticare di attivare.

Questo si collega direttamente all'architettura del sistema sottostante. Se state costruendo o specificando il sistema internamente anziché acquistarlo già pronto, court-ready architecture for healthcare AI illustra come appare concretamente un sistema auditabile e difendibile a livello infrastrutturale.

Le clausole contrattuali che vi tutelano dopo la firma

Il procurement non finisce con la firma del contratto. Le clausole più importanti sono quelle che sperate di non dover mai utilizzare.

• Diritti di esportazione di dati e modelli. Se interrompete il rapporto con il fornitore, conservate i vostri dati storici e i pesi del modello fine-tuned, oppure si azzera tutto?
• Notifica preventiva per gli aggiornamenti del modello. I sistemi basati su LLM cambiano comportamento quando cambia il modello sottostante. Volete un preavviso e, idealmente, una finestra di staging prima che una nuova versione del modello vada in produzione.
• SLA per la risposta agli incidenti, specifici per il sistema AI, non solo per l'uptime generale. Una diagnosi errata o una prestazione ingiustamente negata appartengono a una classe di gravità diversa rispetto a una pagina lenta — e il contratto dovrebbe rifletterlo.
• Clausole di responsabilità e manleva che nominino esplicitamente le modalità di errore specifiche dell'AI (allucinazione, bias, data leakage) anziché ricorrere al linguaggio generico sui difetti software scritto prima che gli LLM esistessero.

Se desiderate un framework più generale per valutare i fornitori al di là di questa checklist, la nostra AI agent vendor evaluation checklist copre i criteri più ampi (struttura dei costi, latenza, modello di supporto) applicabili anche al di fuori dei settori ad alta intensità di compliance. E se le evals fanno già parte del vostro processo di valutazione — o dovrebbero — inserire le evals nel contratto stesso è una lettura da fare prima di finalizzare i termini.

Come si traduce tutto questo nella pratica

Nulla di tutto questo richiede uno specialista AI nel vostro team di procurement. Richiede di chiedere prove invece di promesse: un caso di errore reale invece di una demo impeccabile, un'esportazione effettiva dei log invece di una descrizione di cosa viene registrato, una dimostrazione live dell'interfaccia di override invece di una slide sull'"human-in-the-loop". I fornitori che hanno davvero costruito sistemi difendibili avranno tutto questo pronto. Quelli che non lo hanno fatto avranno bisogno di settimane per produrlo — e anche questa è un'informazione utile prima di firmare qualsiasi cosa.

Se state definendo il perimetro di un sistema AI per un contesto pubblico o sanitario e volete un secondo parere sull'RFP o sulla shortlist di fornitori, contattateci.