Il settore pubblico ha bisogno di un procurement che sappia dire di no

La responsabilità di un ente pubblico non nasce quando firma per un sistema di IA, ma quando requisiti, prove, autorità umana, controlli delle modifiche e...

Il settore pubblico ha bisogno di un procurement che sappia dire di no

Il documento che può far cadere un acquisto

Un fascicolo di appalto pubblico spesso inizia con una richiesta che sembra innocua: trovare un sistema che possa aiutare a svolgere un compito. La richiesta attraversa una dichiarazione del problema, una consultazione di mercato, un insieme di requisiti, una valutazione, un contratto e, se il processo è sano, una decisione che può ancora fermare il lavoro. Quest'ultima possibilità è facile da perdere di vista. Quando denaro, calendari e attenzione politica si sono raccolti attorno a un acquisto, la parola no comincia a suonare come un fallimento della consegna. Nel lavoro pubblico, può essere la decisione più utile dell'intero fascicolo.

La normativa europea sugli appalti tratta già un'offerta come qualcosa di più di una gara di promesse attraenti. La direttiva 2014/24/UE stabilisce che i criteri di aggiudicazione devono consentire una concorrenza effettiva ed equa e devono essere accompagnati da disposizioni che permettano all'amministrazione aggiudicatrice di verificare le informazioni fornite dagli offerenti. La direttiva afferma inoltre che i criteri non devono conferire all'amministrazione una libertà di scelta illimitata. Un acquirente pubblico deve descrivere ciò che conta, spiegare come verrà valutato e verificare se l'offerta lo soddisfa davvero. Non si tratta di una nota amministrativa. È la forma giuridica di una decisione che altre persone devono poter comprendere e contestare.

L'IA rende più difficile questa vecchia disciplina, perché un fornitore può offrire un sistema il cui comportamento dipende da dati, aggiornamenti del modello, prompt, soglie, integrazioni, persone e un servizio che può cambiare mentre il contratto è ancora caldo. La brochure può rimanere identica mentre la cosa che c'è dietro si muove. Un team di appalto deve quindi acquistare più di un'interfaccia. Deve acquistare una capacità delimitata, l'evidenza che tale capacità sia adeguata, l'autorità di supervisionarla e un modo credibile di fermarla o sostituirla.

Il settore pubblico ha bisogno di appalti che sappiano dire no, perché il settore pubblico non può esternalizzare il proprio giudizio. Un fornitore può mettere a disposizione un modello, un flusso di lavoro, un servizio ospitato o un insieme di strumenti. Non può fornire la legittimità della decisione presa con essi. L'amministrazione deve comunque sapere quale problema sta risolvendo, quali interessi possono essere coinvolti, quali evidenze supportano il sistema, quale persona può intervenire e come il servizio continuerà se il fornitore cambia rotta. Una firma non è un trasferimento di responsabilità. È una registrazione del fatto che la responsabilità è stata organizzata.

Questo articolo segue tale organizzazione dalla prima frase di un requisito all'ultima riga di un registro di uscita. Utilizza orientamenti pubblici europei e materiale sugli appalti come evidenza. I modelli pratici sono raccomandazioni, non affermazioni che ogni amministrazione debba usare una sola forma. Ogni situazione inventata è etichettata come ipotetica. Un ufficio plausibile, un'offerta ordinata e un fallimento drammatico non sono evidenza soltanto perché si adattano a una storia familiare.

Un acquirente pubblico compra una promessa due volte

Ogni acquisto pubblico porta con sé due promesse. La prima è la promessa del fornitore su un prodotto o servizio. La seconda è la promessa dell'amministrazione alle persone che dipendono dal lavoro: che il denaro è stato speso per uno scopo pubblico definito, che la decisione può essere spiegata, che i diritti rilevanti sono stati considerati e che qualcuno rimane responsabile quando il sistema sbaglia. La seconda promessa è quella che sopravvive all'evento di lancio.

L'appalto di IA spesso rende vivida la prima promessa e vaga la seconda. Una dimostrazione può mostrare un riepilogo fluente, un elenco classificato o una risposta rapida. Raramente mostra chi può rifiutare l'output, cosa succede quando manca una fonte, come viene approvata una modifica, se i registri possono essere esportati o quale persona può mettere in pausa il servizio senza negoziare la propria autorità nel bel mezzo di un incidente. Queste domande sono meno cinematografiche. Sono anche le domande che decidono se un ente pubblico può rimanere al comando.

La Public Buyers Community della Commissione europea descrive le clausole contrattuali modello dell'UE sull'IA in tre parti: una versione completa per l'IA ad alto rischio allineata all'AI Act, una versione leggera personalizzabile per l'IA non ad alto rischio e un commento su come utilizzare e adattare le clausole. La distinzione è importante. Una clausola modello non è un timbro magico che rende idoneo un appalto. È un punto di partenza per ripartire gli obblighi tra un'organizzazione pubblica e un fornitore, in un contratto di cui l'acquirente deve comunque decidere ambito, finalità e prove.

Un acquirente dovrebbe quindi chiedersi cosa sta realmente promettendo al pubblico prima di chiedere cosa un fornitore possa dimostrare. L'autorità sta promettendo un percorso più rapido attraverso l'arretrato, una prima revisione più coerente, un'ispezione più sicura, un uso migliore di competenze scarse o semplicemente un esperimento i cui limiti sono visibili? Ogni finalità comporta prove diverse e motivi diversi per fermarsi. Un sistema che redige note interne può richiedere un confine di autorità diverso da uno che classifica le domande per un servizio che le persone non possono evitare.

Si consideri un ipotetico team di valutazione che esamina uno strumento di sintesi delle proposte dei fornitori. Il team può decidere che il compito è adatto all'assistenza, ma solo se la sintesi preserva esclusioni, condizioni e date e rimanda i revisori ai passaggi originali. Se il fornitore non può dimostrare come tali requisiti verranno testati, il team dovrebbe poter rifiutare lo strumento o restringere il contratto. Non è un'accusa nei confronti del fornitore. È una conclusione sulle prove disponibili per la finalità definita.

Lo stesso ragionamento vale quando il problema è attraente ma scarsamente delimitato. Un ente pubblico può voler prevedere la domanda, dare priorità alle ispezioni o instradare la corrispondenza. Questi verbi nascondono le decisioni sottostanti. Cosa conta come domanda. Cosa cambia la priorità. Quale corrispondenza può essere instradata in sicurezza senza che una persona la legga. Il primo no può riguardare l'ambito del problema, non l'uso del software. Rifiutare un acquisto poco chiaro è spesso il modo in cui un'autorità protegge la parte utile del lavoro da una parte non verificabile.

Scrivere il problema prima della soluzione

L'appalto diventa fragile quando una categoria di prodotto arriva prima che un problema pubblico sia stato nominato. L'intelligenza artificiale è particolarmente abile nel creare questo ordine perché lo stesso modello può essere presentato come assistente di scrittura, classificatore, livello di ricerca o agente a seconda della presentazione. L'autorità deve descrivere il lavoro in termini che restino significativi quando fornitore, famiglia di modelli e interfaccia vengono rimossi.

L'Algoritmekader olandese, mantenuto per le organizzazioni pubbliche, inserisce questo lavoro tra le misure raccomandate. Chiede alle organizzazioni di descrivere la finalità prevista e i dati utilizzati, determinare il gruppo di rischio applicabile, stabilire l'impatto se l'algoritmo non funziona come previsto e decidere se una soluzione debba essere sviluppata o acquistata. Indica inoltre un'architettura di avvio del progetto per sviluppare o acquisire algoritmi. Non sono decorazioni per gli appalti. Sono modi per rendere il problema leggibile prima che venga offerta una risposta.

Un buon requisito inizia con la decisione o il servizio che deve migliorare, le persone che lo eseguono o lo ricevono, le informazioni che il sistema può utilizzare, le informazioni che non deve utilizzare e l'autorità umana che rimane. Dichiara le condizioni in cui il sistema è utile e le condizioni in cui non deve essere utilizzato. Nomina i registri che devono esistere quando l'output viene accettato, rifiutato, corretto o inoltrato. Non deve prevedere la progettazione interna del fornitore. Deve definire la capacità pubblica che può essere ispezionata.

È qui che contano i requisiti funzionali e prestazionali. La direttiva 2014/24/UE richiede che le specifiche tecniche siano sufficientemente precise da consentire agli offerenti di comprendere l'oggetto e alle amministrazioni di valutare come le offerte soddisfino i criteri. Un requisito come fornire una soluzione intelligente non è un test utile. Un requisito come conservare i passaggi di origine utilizzati in una bozza, mostrare la data di recupero, consentire a un revisore di respingere la bozza ed esportare il record risultante è più vicino a un bisogno pubblico verificabile. Descrive un comportamento e un percorso di evidenza piuttosto che una moda.

I requisiti dovrebbero anche esporre il confine del compito. Un'amministrazione pubblica può affermare che un sistema può suggerire un percorso ma non può prendere la determinazione finale. Può stabilire che una raccomandazione non debba essere utilizzata quando una fonte specificata è assente o contraddittoria. Può richiedere un percorso umano per una persona interessata che voglia contestare l'esito. Questi non sono vincoli ostili. Sono le condizioni in cui l'acquisto rimane un servizio pubblico piuttosto che un flusso di lavoro privato con un logo governativo.

Una dichiarazione del problema ristretta non è una mancanza di ambizione. È un modo per rendere l'ambizione responsabile. Se l'amministrazione non riesce a spiegare quale fase il sistema modifica, chi ne trae beneficio, cosa può andare storto e cosa può fare una persona successivamente, non è pronta a confrontare i fornitori. L'azione corretta potrebbe essere più scoperta, una soluzione non basata sull'IA, un piccolo progetto pilota controllato o nessun acquisto affatto. Il fascicolo di appalto dovrebbe avere spazio per ciascuna risposta.

Trasformare i requisiti in evidenza

La parola evidenza è usata in modo approssimativo negli appalti tecnologici. La presentazione di un fornitore, una dimostrazione del prodotto e una dichiarazione che il sistema è affidabile possono essere tutti input utili. Nessuno di questi è automaticamente una prova che un requisito è soddisfatto. L'evidenza deve essere collegata a un'affermazione, un test, un ambito e una persona che possa ispezionarla. Senza questo collegamento, la valutazione diventa una competizione in cui vince la frase più curata.

La direttiva sugli appalti è chiara sulla relazione di base: i criteri di aggiudicazione devono essere accompagnati da disposizioni che consentano di verificare efficacemente le informazioni fornite dagli offerenti. Questo principio è particolarmente importante per l'IA perché un risultato può apparire convincente mentre le condizioni che lo hanno prodotto rimangono nascoste. L'acquirente dovrebbe chiedere cosa verrà mostrato, in quali condizioni di dati e di compito, con quale base di riferimento e come un revisore possa riprodurre o contestare il risultato.

L'Algoritmekader olandese formula la stessa richiesta in linguaggio pratico. Le sue misure per gli appalti pubblici includono l'inserimento dei requisiti sugli algoritmi nei documenti di gara e nel contratto, l'obbligo per i fornitori di fornire evidenza che i requisiti siano soddisfatti come parte della valutazione, la valutazione delle condizioni di responsabilità del fornitore, il requisito di capacità di audit nel contratto, l'accordo su cosa accade a dati e artefatti e la richiesta di un piano per l'arresto dell'algoritmo. L'elenco è una guida, non un elenco di controllo legale universale. Il suo valore sta nel trattare la prova come un oggetto dell'appalto.

Un acquirente può separare l'evidenza in tre categorie utili. L'evidenza dimostrata è ciò che il fornitore mostra in una valutazione controllata: input, output, gestione degli errori, uso delle fonti e percorso umano possono essere osservati. L'evidenza ispezionabile è ciò che l'amministrazione può esaminare senza fare affidamento su una dimostrazione: documentazione, risultati dei test, log, interfacce, registri delle modifiche, descrizioni dei dati e capacità di eseguire un controllo concordato. L'evidenza contrattuale è ciò che il fornitore deve continuare a fornire: notifiche di modifiche sostanziali, informazioni sugli incidenti, accesso per un audit, registri di servizio, funzionalità di esportazione e supporto per un'uscita controllata. Le categorie si sovrappongono, ma impediscono che una singola sessione impressionante sostenga l'intero contratto.

Le prove richiedono anche un ambito di validità. Un fornitore può dimostrare che un sistema funziona bene su un insieme di esempi. L'acquirente deve comunque sapere se gli esempi rappresentano la lingua prevista, la qualità dei documenti, il mix di casi, le esigenze di accessibilità e i vincoli operativi. Un'affermazione su un modello in laboratorio non equivale automaticamente a un'affermazione su un servizio pubblico. È un'affermazione sull'esperimento che è stato condotto. Il team di procurement dovrebbe conservare il compito, le condizioni dei dati, la versione e il risultato, così che la decisione successiva non resti sganciata dal test.

Si immagini, come ipotesi, che un offerente fornisca un campione di riassunti generati e una dichiarazione generale di accuratezza. L'autorità può chiedere i documenti di origine, la regola di selezione, la versione utilizzata, il trattamento del materiale mancante, la procedura di revisione e l'artefatto che resterà dopo l'accettazione. Se la risposta è che i dettagli sono proprietari e non possono essere ispezionati, il team ha imparato qualcosa di importante. Non ha imparato che il sistema è scarso. Ha imparato che il confine proposto per le prove potrebbe essere troppo debole per la finalità pubblica.

Le prove dovrebbero essere proporzionate. Un piccolo strumento interno di redazione non richiede lo stesso pacchetto di ispezione di un sistema che influenza l'accesso a un servizio pubblico. La proporzionalità non significa accettare uno slogan a basso rischio. Significa allineare la profondità della prova alla conseguenza, alla reversibilità, alle persone coinvolte e alla capacità di individuare e correggere un errore. Il fornitore dovrebbe conoscere le prove richieste prima che l'offerta venga presentata. In caso contrario, l'autorità modifica la gara dopo la corsa, un modo noto per produrre una sorpresa costosa.

Un requisito dovrebbe portare a una prova, e la prova dovrebbe poter modificare la decisione di aggiudicazione.

L'acquirente deve poter dissentire

La responsabilità pubblica non equivale alla trasparenza del fornitore. Un fornitore può spiegare il proprio servizio mentre l'autorità non dispone ancora di un canale attraverso cui un residente, un lavoratore, un'impresa o un professionista possa contestare il modo in cui il servizio è stato utilizzato. Il fascicolo di procurement dovrebbe quindi chiedere come funziona il dissenso, non solo come il sistema produce una risposta.

L'Algoritmekader colloca il controllo umano, i diritti fondamentali, la trasparenza e le vie di reclamo tra i suoi ambiti per il settore pubblico. Le misure raccomandate includono un intervento umano significativo nel processo decisionale, una procedura attraverso cui i cittadini o altri portatori di interesse possono presentare un reclamo, un'obiezione o un ricorso, una decisione pubblica sull'uso dell'algoritmo e un modo per pubblicare gli algoritmi con impatto rilevante nel Registro degli algoritmi olandese. Queste misure non trasformano ogni algoritmo in uno spettacolo pubblico. Rendono la responsabilità dell'autorità abbastanza visibile da poter essere messa in discussione.

Un requisito di procurement per la supervisione umana dovrebbe nominare l'azione umana. Può il revisore vedere le informazioni che hanno formato la raccomandazione. Può correggere il registro. Può rifiutare il risultato senza prima ottenere il permesso dal sistema. Può chiedere un percorso alternativo quando manca una fonte. Può fermare un lotto, isolare una versione o segnalare un problema a qualcuno con autorità. Se la risposta è solo che una persona è presente da qualche parte nel processo, il requisito descrive mobili, non supervisione.

Il disaccordo richiede anche tempo. Un revisore che deve controllare ogni output mantenendo il carico di lavoro originale può essere tecnicamente nel circuito e praticamente fuori da esso. Il procurement può richiedere formazione, supporto, prove utilizzabili e un'ipotesi di carico di lavoro per la revisione. Può definire quali casi necessitano di approvazione preventiva e quali azioni reversibili e a bassa conseguenza possono procedere con registrazione e campionamento successivo. Può chiedere al fornitore di supportare il percorso piuttosto che nasconderlo dietro un'interfaccia di programmazione delle applicazioni.

L'autorità deve anche dissentire dal proprio entusiasmo. Un progetto pilota di successo può creare pressione per estendere uno strumento a una popolazione o a una decisione che non faceva mai parte del test. Il contratto dovrebbe preservare lo scopo originale e richiedere una nuova decisione quando cambiano lo scopo, i dati, le persone coinvolte o le conseguenze. Un aggiornamento non è automaticamente innocuo perché viene fornito come servizio. Un nuovo utilizzo non è automaticamente coperto perché lo stesso logo appare in cima allo schermo.

Quando un fornitore dice che il modello è solo consultivo, l'autorità dovrebbe guardare a ciò che il lavoro fa realmente. Se al personale viene detto di accettare la classifica, se non c'è tempo per rivederla o se il sistema controlla quali casi raggiungono una persona, il consiglio può essere diventato una decisione nella pratica. Il team di procurement non deve discutere sull'etichetta perfetta. Deve documentare il percorso dall'output alla conseguenza e mantenere l'autorità di cambiare quel percorso.

I confini del fornitore fanno parte del contratto

Il procurement di IA è spesso descritto come una scelta tra costruire e comprare. La scelta più difficile è come dividere il confine tra fornitore e organizzazione pubblica. Il fornitore può controllare un modello, un servizio, un percorso di aggiornamento, l'infrastruttura, il team di supporto e parte del trattamento dei dati. L'autorità controlla lo scopo pubblico, la decisione, la popolazione interessata e il dovere di fornire un servizio legale e utilizzabile. Un contratto deve collegare queste responsabilità piuttosto che lasciarle come due diagrammi educati.

Le clausole contrattuali modello aggiornate dell'UE per l'IA sono utili perché riconoscono che i compratori pubblici necessitano di approcci distinti per l'IA ad alto rischio e non ad alto rischio e necessitano di indicazioni su come personalizzare le clausole nella pratica. Non sostituiscono una strategia di procurement o una revisione legale. Sono un vocabolario comune per rendere esplicite le responsabilità. Il compratore deve ancora decidere quali prove, diritti sui dati, accesso agli audit, preavviso di modifica, supporto, responsabilità e condizioni di uscita siano proporzionati al sistema acquistato.

Dati e artefatti meritano particolare attenzione. Un sistema può toccare documenti di origine, etichette, prompt, incorporamenti, bozze generate, correzioni umane, set di valutazione, log e registri finali. Il contratto dovrebbe distinguere ciò che l'autorità fornisce, ciò che il fornitore crea, ciò che ciascuna parte può utilizzare, ciò che deve essere restituito, ciò che deve essere eliminato e quale prova di eliminazione o conservazione è richiesta. Dire che l'autorità possiede i propri dati non risponde a dove vivono gli artefatti derivati o a come l'autorità può recuperare i registri che spiegano un risultato.

I diritti di audit devono avere una forma pratica. L'acquirente deve sapere quali registrazioni possono essere ispezionate, come si richiede l'accesso, quale preavviso è ragionevole, quali tutele di riservatezza si applicano e cosa accade quando un audit rileva una lacuna. Una clausola di audit senza un percorso utilizzabile è una condanna in attesa di una controversia. Lo stesso vale per una clausola sugli incidenti che afferma che il fornitore coopererà senza indicare le informazioni, i tempi e il responsabile necessari per la cooperazione.

Il controllo delle modifiche non dovrebbe essere lasciato alle note di rilascio. L'autorità può richiedere la notifica di una modifica sostanziale al modello, alle fonti dei dati, alla sede di trattamento, ai subappaltatori, alle interfacce, alle soglie, al metodo di valutazione o al percorso umano. Può definire quali prove sono necessarie prima che una versione modificata venga utilizzata per il compito pubblico. Può richiedere il diritto di sospendere, rifiutare o ripristinare quando il servizio modificato non soddisfa più un requisito sostanziale. Queste sono raccomandazioni per rendere operabile il contratto. Non sono affermazioni che una singola clausola possa risolvere ogni rapporto con il fornitore.

La responsabilità include anche ciò che il fornitore non può fornire. Un servizio può dipendere da un modello o da un'infrastruttura di terze parti i cui cambiamenti sono al di fuori del controllo diretto del fornitore. L'acquirente deve essere informato di tale dipendenza e deve sapere quali obblighi si trasmettono a lui. Un'organizzazione pubblica non può valutare una catena ispezionando solo la porta d'ingresso. Il contratto dovrebbe preservare un percorso verso le prove pertinenti, oppure l'acquirente dovrebbe riconoscere che l'incertezza è un motivo per restringere o rifiutare l'acquisto.

Confini ben definiti proteggono anche i fornitori. Un acquirente pubblico che chiede ogni possibile documento, ogni dettaglio del codice sorgente e supporto illimitato senza uno scopo definito può ridurre la concorrenza e rendere il contratto poco attraente per i fornitori europei più piccoli. Proporzionalità, chiarezza e un ambito di prove credibile consentono a un fornitore di dire cosa può fare e a un acquirente di dire cosa gli serve. Gli appalti pubblici dovrebbero essere esigenti senza essere teatrali. Un muro fatto di requisiti impossibili tiene fuori i sistemi scadenti e quelli buoni con uguale efficienza.

Il cambiamento dopo l'aggiudicazione è ancora appalto

L'aggiudicazione non è la fine della decisione. È il punto in cui il servizio entra in un diverso tipo di scrutinio. Durante l'esercizio, i dati cambiano, le politiche si modificano, le interfacce vengono sostituite, il personale impara scorciatoie, i fornitori rivedono i modelli e un sistema può essere utilizzato in situazioni che il team originale non aveva immaginato. L'autorità ha bisogno di un modo per notare questi cambiamenti prima che diventino un nuovo scopo pubblico per caso.

L'Algoritmekader raccomanda controlli regolari che un algoritmo funzioni come previsto, il monitoraggio dei cambiamenti nei dati e la valutazione delle prestazioni e dei risultati quando i dati cambiano, e il mantenimento di un piano per il monitoraggio continuo. Include anche una misura per un piano di emergenza per arrestare l'algoritmo. Queste raccomandazioni inseriscono il tempo nel modello di governance. Un appalto che cattura solo la specifica iniziale ha comprato una fotografia di un servizio in movimento.

Non ogni aggiornamento dovrebbe innescare la stessa procedura. Una patch di sicurezza che lascia invariati il modello, il confine dei dati e il ruolo decisionale può seguire un percorso diverso da una nuova famiglia di modelli, una fonte di recupero modificata o una nuova soglia. Il contratto può definire la materialità in termini operativi: una modifica è sostanziale quando altera il compito, le persone interessate, il percorso delle prove, la conseguenza decisionale, la giurisdizione di implementazione, il subappaltatore, l'uso dei dati o la capacità di intervenire. La definizione esatta richiede giudizio legale e tecnico. Il principio è semplice: il cambiamento fa parte della capacità acquistata.

Il monitoraggio dovrebbe preservare le informazioni necessarie per prendere una decisione. Una dashboard può mostrare che un servizio è occupato; potrebbe non mostrare che una fonte è diventata obsoleta o che i revisori stanno ignorando la stessa raccomandazione. L'autorità dovrebbe conservare la versione pertinente, l'ambito dell'attività, le condizioni relative alle prove, l'azione umana e il motivo di una modifica. Dovrebbe sapere quali modifiche sono state accettate, quali sono state annullate, quali sono state limitate e quali hanno creato una nuova questione di approvvigionamento.

Un fornitore potrebbe non essere in grado di dare un preavviso di ogni modifica interna. Il contratto può comunque richiedere una notifica utilizzabile e un pacchetto di prove prima che il comportamento modificato venga utilizzato come riferimento. L'autorità può scegliere una distribuzione graduale, una valutazione controllata o una sospensione temporanea. La capacità di mettere in pausa non è una punizione. È ciò che consente a un servizio pubblico di rimanere responsabile mentre i fatti vengono accertati.

Una registrazione delle modifiche protegge anche dalla falsa certezza. Se l'autorità non riesce a stabilire se una differenza derivi da un nuovo modello, da una modifica dei dati, da un prompt, da un intervento manuale o da una dipendenza esterna, non dovrebbe affermare che il sistema si è comportato in modo coerente. La risposta corretta potrebbe essere limitare l'uso, raccogliere prove migliori o interrompere il percorso interessato. Il denaro pubblico non diventa più sicuro solo perché la spiegazione è ordinata.

L'interoperabilità è la parola educata per andarsene

Le persone discutono spesso dell'interoperabilità come se fosse una cortesia tecnica tra sistemi. Nell'approvvigionamento pubblico è anche un controllo di continuità. Se un servizio pubblico non può trasferire i propri registri, configurazioni, prove, interfacce e conoscenze operative verso un altro percorso, l'autorità potrebbe essere legalmente libera di andarsene ma di fatto impossibilitata a farlo. Il contratto ha creato una dipendenza che il fascicolo di approvvigionamento non aveva nominato.

Il rapporto JRC della Commissione sull'avanzamento dell'adozione dell'IA nelle pubbliche amministrazioni dell'UE definisce l'approvvigionamento un ruolo abilitante cruciale e afferma che l'interoperabilità dovrebbe essere integrata fin dall'inizio. Presenta inoltre l'approvvigionamento strategico come un modo per ridurre la dipendenza da fornitori extra-UE e sostenere le startup europee di IA, le soluzioni open-source e GovTech. Questo non è un argomento per acquistare europeo per slogan o per trattare l'open source come una garanzia automatica. È un argomento per rendere la capacità tecnica e istituzionale di cambiare rotta parte del valore acquistato.

L'uscita inizia con un elenco di ciò che deve sopravvivere. Ciò può includere registri di origine, identificatori, etichette, prompt, versioni di modelli e configurazioni, set di valutazione, registri di audit, mappature di utenti e ruoli, contratti di integrazione, stato di conservazione, materiale di sicurezza e il significato dei campi. L'elenco dipende dal servizio. Un file portabile senza contesto può essere meno utile di un registro più piccolo con la sua semantica e le sue autorizzazioni intatte. L'esportazione è una capacità da testare, non una casella da spuntare.

L'interoperabilità significa anche che l'autorità può eseguire un confronto significativo. Una destinazione può elaborare i registri senza modificarne silenziosamente il significato. I revisori possono confrontare un output vecchio e uno nuovo nelle stesse condizioni di attività. Il servizio pubblico può continuare in modalità ridotta se una dipendenza non è disponibile. Le prove possono rimanere leggibili dopo che l'interfaccia è sparita. Queste domande appartengono ai requisiti, alla valutazione e al contratto, perché un'uscita scoperta durante un'emergenza è di solito uno scavo archeologico.

La portabilità non significa necessariamente che un fornitore debba consegnare ogni dettaglio interno di implementazione. Significa che l'amministrazione può preservare la funzione pubblica e i documenti di cui è responsabile, nel rispetto dei diritti legittimi e dei vincoli di sicurezza. Il confine dovrebbe essere dichiarato prima della firma. Se il modello del fornitore è inaccessibile, l'amministrazione può comunque richiedere input portabili, output, registri delle decisioni, valutazioni, configurazione e una via per ricostruire gli obblighi pubblici del servizio. Se non riesce a ottenere quella via, dovrebbe valutare onestamente la dipendenza o rifiutarla.

Una prova di uscita è preziosa perché trasforma una promessa contrattuale in una capacità osservata. Un acquirente pubblico può testare un'esportazione, ispezionare i campi, eseguire un carico di lavoro rappresentativo in una destinazione controllata e confrontare i registri risultanti. Può annotare ciò che non si è spostato e decidere se il divario è accettabile. L'esercizio non deve essere drammatico. Una piccola prova svolta prima del rinnovo è meglio di una migrazione eroica eseguita dopo che il fornitore è diventato l'unica persona che ricorda il sistema.

Uscire è una sequenza di autorità, esportazione, significato, verifica, continuità e chiusura. Un pulsante etichettato export non è la sequenza.

Il costo è più della riga nel bando

Il prezzo è facile da confrontare quando l'oggetto dell'acquisto è stabile. L'approvvigionamento di IA ha un orizzonte di costo più lungo. Possono esserci lavoro di integrazione, preparazione dei dati, tempo di revisione, controlli di sicurezza, archiviazione, valutazione, aggiornamenti del modello, lavoro di accessibilità, risposta agli incidenti, supporto, esportazione e sostituzione. Alcuni costi sono a carico dell'amministrazione. Altri vengono trasferiti ai lavoratori o al pubblico quando un servizio diventa più difficile da contestare. Un approvvigionamento che confronta solo la tariffa iniziale non è necessariamente economico. Sta semplicemente contando una parte visibile.

La direttiva 2014/24/UE prevede la valutazione del costo del ciclo di vita quando l'amministrazione sceglie questo approccio. La direttiva descrive costi quali acquisizione, uso, manutenzione, fine vita e, ove pertinenti e verificabili, esternalità ambientali. Richiede inoltre che i documenti di gara indichino i dati che gli offerenti devono fornire e il metodo utilizzato per valutare il costo del ciclo di vita. Questa è una disciplina utile per l'IA perché richiede all'acquirente di dire cosa verrà conteggiato, invece di invitare ogni fornitore a portare una definizione diversa di convenienza.

Lo stesso principio vale per l'attenzione umana. Se un sistema produce raccomandazioni che richiedono una revisione, il lavoro di revisione fa parte del modello operativo. Se un servizio pubblico necessita di un canale per le correzioni, quel canale deve avere un responsabile e del tempo. Se un aggiornamento del fornitore richiede una nuova valutazione, l'autorità deve avere la capacità di svolgerla. Non sono argomenti contro l'automazione. Sono promemoria che l'automazione sposta il luogo in cui avviene il lavoro. Un risparmio in fattura può diventare un costo in coda se l'appalto non nomina il nuovo lavoro.

Il costo dovrebbe includere anche il costo di non poter uscire. Una dipendenza può sembrare economica quando è nuova e diventare costosa quando attorno a essa si sono accumulate registrazioni, competenze, integrazioni e aspettative del pubblico. Il committente può chiedere una stima della migrazione, un inventario di dati e artefatti, un obbligo di supporto e un calendario di prove. Può confrontare queste condizioni come parte del valore dell'offerta. La scelta non è tra ottimismo e pessimismo. È tra una dipendenza visibile e una nascosta nel tempo futuro.

Il pensiero sul ciclo di vita aiuta il team di approvvigionamento a dire no senza fingere che l'offerta visibile più economica sia l'opzione neutrale. Il team può rifiutare una proposta perché le sue prove, il carico di revisione, il percorso di modifica o il costo di uscita non sono compatibili con lo scopo pubblico. Può spiegare la decisione sulla base di criteri pubblicati. Non è un gesto contro il mercato. È ciò che un mercato con requisiti verificabili dovrebbe consentire.

I committenti pubblici devono avere l'autorità di dire no

Un team di approvvigionamento non può esercitare un potere che l'organizzazione non gli ha conferito. Molte autorità hanno persone in grado di valutare questioni legali, tecniche, finanziarie e di servizio, ma l'autorità di combinare queste valutazioni in una sospensione o in un rifiuto non è chiara. Il risultato è noto: le preoccupazioni sono registrate in un documento, l'entusiasmo in un altro e la procedura di aggiudicazione prosegue perché nessuno sa quale ruolo possa chiudere il cancello.

L'autorità dovrebbe nominare i ruoli che possono accettare, rifiutare, restringere o sospendere un acquisto in ogni fase. I ruoli devono avere accesso alle prove pertinenti e un canale per registrare il motivo. Un funzionario degli appalti può gestire il processo, un responsabile del servizio lo scopo pubblico, un responsabile della protezione dei dati una condizione di privacy, un responsabile della sicurezza un controllo, un revisore tecnico un test e un ruolo dirigenziale senior la decisione finale. La disposizione esatta varia. L'assenza di una disposizione è la parte pericolosa.

Una condizione di arresto utile non è un badge rosso che indica alto rischio. È un fatto che blocca la decisione successiva. Lo scopo previsto non è sufficientemente definito. Il fornitore non può fornire prove per un requisito sostanziale. La persona interessata non ha un canale di revisione utilizzabile. L'autorità non può ispezionare la modifica pertinente. I diritti su dati o artefatti non sono chiari. Il sistema non può essere esportato o sostituito nell'ambito del piano di continuità. Il revisore umano ha responsabilità ma non autorità. Ogni condizione può avere un rimedio diverso. Alcune richiedono chiarimenti, alcune una modifica contrattuale, alcune un ambito più ristretto e alcune un no.

Le condizioni di arresto dovrebbero essere note prima della valutazione dell'offerta. Dovrebbero essere collegate ai criteri di aggiudicazione e al contratto, così che il committente non inventi un nuovo standard dopo aver visto la risposta del fornitore. Dovrebbero inoltre essere riviste dopo l'aggiudicazione. Un requisito soddisfatto al lancio può diventare insoddisfatto dopo una modifica sostanziale o un nuovo utilizzo. La capacità di dire no non è un unico cancello alla fine. È un'autorità mantenuta per tutta la vita del servizio.

Si consideri un ente pubblico che, a titolo ipotetico, acquista un servizio di instradamento documentale. I requisiti pubblicati includono la tracciabilità della fonte, un percorso di revisione umana, un avviso per modifiche sostanziali al modello, un esportazione dei registri e una procedura di cessazione definita. Un offerente presenta una dimostrazione convincente, ma non può consentire all'ente di ispezionare la selezione della fonte o di conservare le prove di instradamento versionate. Un altro offerente offre meno funzionalità, ma soddisfa i requisiti di prova e di uscita. L'ente non è obbligato a preferire la dimostrazione più appariscente. Può applicare i criteri dichiarati, porre domande proporzionate e rifiutare la prima offerta se un requisito sostanziale rimane non dimostrato.

Questa decisione non dovrebbe essere formulata come un giudizio morale sul fornitore o sulla tecnologia. Dovrebbe indicare la finalità pubblica, il requisito, le prove ricevute, la condizione non risolta e la decisione consentita dai documenti di gara. Un no chiaro è più rispettoso di un forse vago che in seguito diventa un rinnovo obbligatorio. Inoltre, offre al mercato un segnale utile: i committenti pubblici pagheranno per prove e controllo, non solo per una messa in scena di capacità.

L'autorità umana di interrompere deve poter essere esercitata in caso di incidente. L'operatore deve sapere chi chiamare, quale stato del sistema preservare, quale percorso di servizio può continuare e quale comunicazione è richiesta. Il registro della decisione dovrebbe distinguere il contenimento immediato da una decisione di approvvigionamento più ampia. Un ente pubblico non deve attendere un'indagine perfetta prima di prevenire ulteriori danni, ma dovrebbe evitare di affermare più certezza di quanta ne abbia. Lo stop è un controllo. La spiegazione può svilupparsi.

L'approvvigionamento plasma il mercato

L'approvvigionamento pubblico è uno dei modi in cui l'Europa decide quali capacità vale la pena costruire. Il rapporto del JRC sull'adozione dell'IA nelle amministrazioni pubbliche dell'UE descrive il settore pubblico come una forza importante nel plasmare il mercato. Collega un'adozione riuscita a governance, preparazione della forza lavoro, approvvigionamento responsabile, interoperabilità e fiducia pubblica. Afferma inoltre che un approvvigionamento strategico può ridurre la dipendenza da fornitori extra-UE e sostenere startup europee, soluzioni open-source e GovTech. Il punto non è che un ente pubblico debba diventare un fondo di venture capital. Il punto è che i suoi requisiti possono premiare una capacità responsabile oppure premiare una confezione persuasiva attorno alla dipendenza.

La relazione speciale n. 28/2023 della Corte dei conti europea è intitolata Public procurement in the EU: less competition for contracts awarded for works, goods and services in the ten years up to 2021. Il suo riepilogo pubblico descrive la concorrenza per gli appalti pubblici in Europa come in calo. Un mercato con meno concorrenti effettivi è un luogo inadeguato per nascondere requisiti vaghi. Se l'ente non può confrontare le prove, potrebbe scegliere tra stili di marketing piuttosto che tra servizi. Dire no a un'offerta non verificabile può preservare le condizioni per una migliore concorrenza in seguito.

Allo stesso tempo, un acquirente può escludere accidentalmente fornitori utili chiedendo prove in una forma che solo il fornitore più grande può produrre. Requisiti proporzionati, interfacce chiare, formati aperti e valutazioni a fasi possono consentire a organizzazioni più piccole di dimostrare una capacità limitata senza fingere di avere le risorse di una multinazionale. L'acquirente dovrebbe essere rigoroso sulla finalità pubblica e flessibile sull'implementazione, laddove l'implementazione non incida su tale finalità. È così che un no diventa una domanda migliore invece di una porta chiusa.

Plasmare il mercato significa anche rifiutarsi di fare dell'architettura privata di un singolo fornitore la definizione del bisogno pubblico. Se un requisito menziona un modello, un cloud o un flusso di lavoro proprietario specifico senza un collegamento giustificato al compito, la concorrenza può essere limitata prima ancora di vedere le prove. Requisiti funzionali e risultati verificabili offrono ai committenti pubblici più spazio per confrontare gli approcci. Rendono inoltre il contratto meno fragile quando il componente scelto cambia.

Un’autorità pubblica può essere un committente esigente senza diventare un cliente difficile. Può pubblicare le evidenze che si aspetta, spiegare il motivo di una condizione di arresto, offrire un percorso per i chiarimenti e pagare per un lavoro che crea capacità pubblica duratura. Il mercato ha allora qualcosa di utile a cui rispondere. Non deve indovinare se il fattore vincente sia stato una preferenza nascosta, una demo accattivante o il prezzo di un problema futuro.

Un modello operativo per un appalto che può rifiutare

Il modello che segue è una raccomandazione pratica, non una nuova procedura legale. È un modo per mantenere visibile la decisione pubblica mentre un sistema passa dall’idea all’operatività. Un’autorità dovrebbe adattarlo alla propria legge, al proprio settore, al proprio rischio e al proprio metodo di appalto. La parte importante è che ogni gate abbia un responsabile, delle evidenze e un esito consentito che includa la pausa o il rifiuto.

In primo luogo, scrivere lo scopo pubblico. Nominare il servizio, le persone che lo svolgono, le persone che lo ricevono, la decisione o l’azione che può cambiare e il motivo per cui si sta valutando un sistema. Dichiarare cosa è fuori ambito. Se lo scopo non può essere descritto senza il vocabolario di prodotto del fornitore, l’autorità è ancora in fase di scoperta del mercato. L’output di questo gate è una dichiarazione del problema e una decisione se l’appalto sia il passo successivo giusto.

In secondo luogo, scrivere il confine delle evidenze. Per ogni affermazione sostanziale, indicare cosa dimostrerebbe che è vera nel compito previsto. Nominare le condizioni dei dati, la lingua, le esigenze di accessibilità, i registri di origine, la versione, la baseline e il percorso di revisione che rendono significativo il test. Specificare cosa deve essere ispezionabile, cosa può rimanere riservato e cosa deve essere consegnato come documento contrattuale. L’output di questo gate è un insieme di requisiti che i candidati possono comprendere e un piano di valutazione che può modificare l’aggiudicazione.

In terzo luogo, scrivere il confine dell’autorità. Nominare le azioni che il sistema può suggerire, le azioni che può intraprendere, le azioni che richiedono approvazione e le azioni che sono vietate. Nominare chi può correggere una fonte, rifiutare un output, modificare una regola, mettere in pausa un servizio e parlare con una persona interessata. Definire cosa accade quando il sistema è incerto o le evidenze sono in conflitto. L’output di questo gate è un percorso umano più specifico di una casella di spunta.

In quarto luogo, scrivere il confine del cambiamento. Identificare i cambiamenti che richiedono notifica, valutazione, approvazione o una nuova decisione di appalto. Includere modello, dati, fornitore, subappaltatore, infrastruttura, luogo di trattamento, interfaccia, soglia, popolazione, scopo e percorso umano. Decidere quali evidenze restano con il registro delle modifiche e quali possono essere oscurate per motivi legittimi. L’output di questo gate è un registro mantenuto, non una promessa che il sistema rimarrà statico.

In quinto luogo, scrivere il confine di uscita. Elencare i registri, i dati, la configurazione, le evidenze, le autorizzazioni, le integrazioni e le conoscenze operative che devono sopravvivere. Definire formati, tempi, supporto, verifica, servizio ridotto, cut-over, chiusura degli accessi ed eliminazione. Provare un’esportazione di piccole dimensioni prima del rinnovo o di un’espansione sostanziale. L’output di questo gate è un percorso che può essere testato mentre il fornitore è ancora un partner, non solo dopo che il rapporto è diventato una controversia.

In sesto luogo, scrivere il registro pubblico. Decidere cosa può essere pubblicato su scopo, ruolo del sistema, evidenze, percorso umano, modifiche, incidenti e contatto per il ricorso. Proteggere le informazioni riservate e personali senza trasformare l’intera decisione in una conversazione privata. Un registro pubblico può dire cosa è noto, cosa non è noto e quando avverrà la prossima revisione. Il suo compito non è far sembrare il sistema perfetto. È rendere ispezionabile il giudizio dell’autorità.

Infine, scrivete il rifiuto. Il rifiuto non è un comunicato stampa drammatico. È un esito normale nel registro delle decisioni: il requisito era sostanziale, le prove non lo soddisfacevano, il rimedio è stato preso in considerazione e l'autorità ha scelto di declinare, restringere, sospendere o cercare una strada diversa. Una procedura di acquisto che non può produrre questo registro ha reso l'acquisto inevitabile prima di aver meritato quella conclusione.

Questi gate possono essere rappresentati in una risposta a una gara, in un'architettura di avvio del progetto, in un calendario contrattuale, in una riunione di revisione e in un playbook per gli incidenti. Non dovrebbero diventare un modulo più grande fine a se stesso. Se un gate non cambia ciò che il team può decidere, probabilmente è teatro documentale. Se dà a una persona prove e autorità per agire, fa parte del servizio.

Domande che vale la pena inserire in una gara

Le domande migliori non sono quelle che spingono un fornitore a ripetere il proprio linguaggio di marketing. Sono quelle che rendono visibili lo scopo pubblico e il confine delle prove. Un acquirente può adattare le seguenti domande al sistema e alla procedura:

  • Quale compito pubblico preciso supporta la capacità proposta e quali compiti sono al di fuori dell'uso previsto?
  • Quali persone, registri e fonti di dati sono in ambito e quali devono essere esclusi?
  • Quale output produce il sistema e quale decisione o azione può derivarne?
  • Quale requisito può essere dimostrato, quale può essere ispezionato e quale sarà mantenuto contrattualmente?
  • Come riprodurrà l'autorità un risultato con la versione, le fonti, la configurazione e le condizioni operative pertinenti?
  • Cosa può vedere, modificare, rifiutare, inoltrare o fermare un revisore umano prima che si verifichi un'azione consequenziale?
  • Quali modifiche a modello, dati, infrastruttura, subappaltatori o politiche richiedono preavviso e rivalutazione?
  • Quali registri e artefatti può esportare l'autorità, in quali formati, con quale significato, diritti e stato di conservazione?
  • Cosa succede quando il servizio non è disponibile, le prove sono incomplete o una persona contesta il risultato?
  • Quali obblighi di supporto, audit, incidenti, formazione e uscita continuano dopo il primo rilascio?

Queste domande non sostituiscono la direttiva sugli appalti, l'AI Act, la legge sulla protezione dei dati o le norme settoriali. Sono stimoli affinché l'autorità renda operativi i propri obblighi. Un fornitore che sa rispondere chiaramente potrebbe comunque non essere il fornitore giusto. Un fornitore che non sa rispondere potrebbe comunque avere un componente utile, ma l'autorità non dovrebbe confondere un componente utile con una capacità pubblica completa.

La nostra breve nota

In Dweve, il nostro AI Compas include un percorso di procurement e governance neutrale rispetto ai fornitori per le organizzazioni europee regolamentate. Il materiale RFI e RFP chiede ai team di classificare il caso d'uso, applicare criteri di esclusione, confrontare i fornitori, eseguire una prova di concetto e conservare le prove attraverso il monitoraggio. Questo è il nostro contesto di implementazione, non una prova indipendente sugli appalti pubblici e non un'affermazione che un unico quadro si adatti a ogni autorità. Lo menzioniamo perché la disciplina descritta qui è anche la disciplina che cerchiamo di usare nel nostro lavoro: definire il confine, richiedere prove, mantenere la decisione umana e rendere visibile l'uscita.

Il nostro Trust Centre fa la stessa distinzione in un registro diverso. Un registro pubblico può descrivere ciò che è documentato, ciò che è preparato e ciò che rimane un evento futuro senza trasformare una dichiarazione di intenti in una prova. Un team di procurement merita la stessa onestà dai propri fornitori. L'acquirente dovrebbe poter vedere lo stato di un'affermazione, le prove dietro di essa e la via per contestarla.

La lezione

Un’autorità pubblica non diventa responsabile quando firma per un sistema di IA. Diventa responsabile quando la procedura di appalto può spiegare perché il sistema appartiene al lavoro, quali prove sostengono questa conclusione, chi può intervenire, cosa succede quando il sistema cambia e come la funzione pubblica può continuare se il fornitore non può.

Le norme europee sugli appalti offrono già abitudini importanti: i criteri dovrebbero essere collegati all’oggetto, le informazioni dovrebbero essere verificabili, i pesi dovrebbero essere dichiarati e le condizioni contrattuali dovrebbero essere chiare. Le clausole sugli appalti di IA della Commissione europea offrono ai committenti pubblici un modo per discutere i sistemi ad alto rischio e non ad alto rischio e per ripartire le responsabilità. L’Algoritmekader olandese trasforma l’appalto responsabile in misure pratiche su scopo, dati, prove, audit, controllo umano, arresto e uscita. Il rapporto del JRC colloca l’appalto all’interno del dibattito europeo su capacità e sovranità. L’avvertimento della Corte dei conti europea sulla riduzione della concorrenza ricorda che una gara debole non si ripara con un’aggiudicazione sicura di sé.

La parola difficile resta no. No, lo scopo non è definito. No, le prove non possono essere ispezionate. No, il percorso umano è decorativo. No, il percorso di modifica è invisibile. No, il registro pubblico non può essere mantenuto. No, il servizio non può andarsene senza perdere il lavoro che doveva proteggere. Ogni no può essere un rifiuto, una restrizione, una pausa o una richiesta di una risposta migliore. L’autorità dovrebbe decidere quale, registrare il perché e mantenere la decisione aperta al confronto.

Un appalto che sa dire no non è un appalto che teme la tecnologia. È un appalto che conosce la differenza tra una capacità e una promessa. Paga per un sistema che può essere testato, supervisionato, modificato e abbandonato. Offre ai fornitori una gara più equa perché la domanda è visibile. Offre ai funzionari pubblici una via per intervenire prima che un problema diventi una politica. Offre alle persone interessate dal servizio qualcosa di più utile di una dichiarazione che un fornitore è stato approvato.

Un acquisto pubblico dovrebbe concludersi con un servizio che l’autorità può ancora governare. Se le prove sono solide, dire sì ha significato. Se le prove sono deboli, dire no è il lavoro pubblico. Il fascicolo di appalto dovrebbe poter contenere entrambe le frasi.

Fonti