Nella maggior parte dei contratti ICT un'amministrazione paga per avere qualcosa: una licenza, un canone, giornate di sviluppo. Il pay-per-performance inverte l'ordine dei fattori e fa pagare per ciò che quel qualcosa produce, soltanto dopo che l'ha prodotto. È un'idea semplice che nel 2026 ha smesso di essere teorica: sta comparendo nei capitolati italiani, e conviene conoscerla prima di incontrarla.
Per il roll-in dell'intelligenza artificiale — la sua introduzione progressiva dentro processi che già esistono e continuano a girare — la risposta breve è sì: è probabilmente la formula più adatta fra quelle che il Codice consente, perché è l'unica in cui l'ente non anticipa nulla su una tecnologia il cui rendimento si può misurare soltanto sul campo. Diventa però un buon contratto solo quando cinque punti sono scritti nero su bianco, e vale la pena vedere quali.
Nelle prossime righe: come funziona il modello, cosa introduce di nuovo rispetto all'acquisto tradizionale, quali vantaggi porta e quali cautele richiede — dal lato di chi acquista e dal lato di chi fornisce. Come esempio useremo una richiesta d'offerta con cui ACI Informatica ha acquistato una piattaforma di agenti AI per la gestione dei ticket di assistenza: è il caso più leggibile in circolazione, perché tutti i parametri economici sono pubblici.
Cos'è il pay-per-performance e cosa introduce di nuovo
Nel pay-per-performance la stazione appaltante non compra un software: compra un risultato misurato, e paga solo quello. Niente costi di sviluppo, niente setup, niente canone. Il corrispettivo matura sull'unità di lavoro completata — un ticket chiuso, una pratica istruita, un documento estratto e validato — al prezzo unitario definito in contratto.
La novità non sta nella formula di pagamento: i contratti a consumo esistono da sempre. Sta nell'oggetto, che si sposta da una cosa a un esito. E quando cambia l'oggetto cambiano, a cascata, tutte le altre voci del capitolato.
| Voce | Fornitura tradizionale | Affidamento a performance |
|---|---|---|
| Oggetto del contratto | Licenza, canone o giornate di sviluppo | Unità di risultato prodotte |
| Momento del pagamento | Anticipato o per stati d'avanzamento | A consuntivo, sul risultato misurato |
| Chi finanzia la costruzione | L'amministrazione | Il fornitore |
| Collaudo | Fase separata, con verbale | Coincide con l'esercizio |
| Requisiti di partecipazione | Fatturato e referenze pregresse | Prevalentemente di ordine generale |
| Rischio di riuscita | In capo all'amministrazione | In capo al fornitore |
Nessuna delle due colonne è migliore in assoluto. La fornitura tradizionale resta la scelta giusta quando il risultato è prevedibile e il perimetro è stabile: un gestionale, un sito, una migrazione. Il modello a performance dà il meglio dove il rendimento non è prevedibile in anticipo — ed è esattamente il caso dei progetti di intelligenza artificiale, che vanno calibrati sui dati e sui processi di quella specifica organizzazione prima di poter dire quanto renderanno.
Un esempio concreto: una gara AI pagata a ticket risolto
Nel giugno 2026 ACI Informatica ha pubblicato una richiesta d'offerta sul Mercato Elettronico della P.A. per una piattaforma di automazione basata su AI generativa e agentica, destinata alla gestione dei ticket di assistenza, con una durata di 18 mesi dalla messa in esercizio. Il documento è utile perché mette per iscritto, in modo trasparente, tutti gli ingredienti del modello.
La remunerazione è interamente legata al risultato: nessun costo di sviluppo, di setup o canone fisso, con progettazione, rilascio, manutenzione, monitoraggio, consumi cloud e API dei modelli a carico del fornitore. Il corrispettivo è un prezzo per ticket gestito con successo, decrescente nel tempo per riflettere la curva di apprendimento del sistema: più il catalogo dei problemi si consolida, meno costa risolverne uno.
| Fase | Periodo | Tetto per ticket | Peso nel ribasso |
|---|---|---|---|
| T1 — Start-up e censimento | mesi 1–6 | 3,00 € | 50% |
| T2 — Consolidamento | mesi 7–12 | 2,50 € | 30% |
| T3 — Regime | dal 13° mese | 1,95 € | 20% |
Il contratto si chiude al raggiungimento di 215.000 euro complessivi oppure al diciottesimo mese, a seconda di quale condizione arrivi per prima. L'amministrazione mette a disposizione documentazione e API previa NDA e dichiara una stima di 60.000 ticket annui automatizzabili, precisando che è fornita per la valutazione del rischio e non costituisce garanzia di volume: una trasparenza corretta, che permette a chi offre di fare i conti con dati reali.
Interessante anche il modo in cui il capitolato àncora la qualità tecnica. Oltre ai vincoli architetturali — soluzione containerizzata su Kubernetes, agenti specializzati con commutazione dinamica, erogazione su Azure o Google Cloud — chiede che almeno uno dei modelli impiegati in produzione si collochi nelle prime dieci posizioni della graduatoria pubblica della Chatbot Arena. È un requisito elegante: lega lo standard a un benchmark aggiornato e verificabile invece che a un nome commerciale destinato a invecchiare.
Cosa cambia per l'amministrazione
Per una stazione appaltante il vantaggio più immediato del pay-per-performance è che la spesa improduttiva non può esistere: se il sistema non produce risultati, non matura corrispettivo. Non c'è un impegno di spesa da giustificare davanti a un progetto fermo, né un canone che decorre mentre la piattaforma è ancora in collaudo. Per un RUP che deve firmare un affidamento in materia di intelligenza artificiale — dove nessuno può garantire il rendimento in anticipo — è una posizione solida e facile da motivare.
Ci sono almeno altri tre benefici. Gli incentivi sono allineati, perché il fornitore guadagna nella misura in cui il sistema funziona. Il collaudo coincide con l'esercizio, il che elimina buona parte delle discussioni su cosa sia «conforme». E la platea si allarga: senza requisiti di fatturato possono presentarsi anche operatori piccoli e specializzati, spesso i più adatti su perimetri verticali.
Ci sono, in parallelo, tre aspetti da presidiare in fase di stesura — nessuno dei quali riguarda il denaro.
- La definizione di risultato. È il punto più importante di tutto il contratto. Cosa conta come unità remunerabile, come si misura e chi la certifica vanno scritti prima della firma: in un contratto a performance è lì che si concentra tutto ciò che può diventare oggetto di discussione.
- La sostenibilità dell'offerta. Poiché il fornitore anticipa l'investimento, un'offerta molto aggressiva va letta con attenzione: la verifica di congruità serve proprio a distinguere l'operatore più efficiente da quello che ha stimato il rischio con troppo ottimismo.
- La continuità a fine contratto. Vale la pena definire fin dall'inizio cosa succede alla scadenza o al raggiungimento del tetto: subentro, proroga tecnica, portabilità dei dati e della configurazione. È l'aspetto che si dimentica più spesso e che pesa di più il giorno dopo.
Il pay-per-performance non fa sparire il rischio: lo sposta dal bilancio dell'ente alla capacità di consegna del fornitore. Per un'amministrazione è quasi sempre uno scambio conveniente, e diventa un ottimo scambio quando il contratto è scritto con cura.
Cosa cambia per l'operatore economico
Per un operatore economico questo modello apre una porta che nel mercato pubblico era rimasta stretta a lungo. Negli affidamenti a performance i requisiti di partecipazione tendono a ridursi a quelli di ordine generale — assenza delle cause di esclusione, iscrizione camerale, abilitazione alla categoria merceologica — senza fatturato pregresso né referenze pluriennali. È il caso anche della richiesta d'offerta citata sopra.
Chi frequenta le gare ICT sa quanto conti. I requisiti di capacità sono storicamente il filtro che tiene fuori le software house piccole e verticali: quelle che hanno la competenza esatta che serve, ma non i tre esercizi di bilancio con l'importo giusto. Qui quel filtro non serve, perché il filtro è il risultato. È un'impostazione meritocratica, e va riconosciuta come tale.
La contropartita è altrettanto chiara, e va messa a budget prima di offrire.
- Capitale anticipato. I mesi di sviluppo e messa in produzione precedono il primo incasso: serve capitale circolante per attraversarli.
- Volume stimato, non garantito. Lo scostamento fra previsione e realtà incide direttamente sui ricavi, quindi va prezzato in offerta.
- Indicatori solo in parte controllabili. La quota di richieste risolvibili dipende anche dalla qualità di documentazione, API e base di conoscenza messe a disposizione dall'ente.
- Tariffa decrescente, costi che non decrescono da soli. Se il prezzo unitario cala nel tempo, l'efficienza del sistema deve migliorare almeno alla stessa velocità.
- Proprietà intellettuale. Molti capitolati prevedono che la soluzione passi all'amministrazione a scadenza. È una scelta legittima, che però va considerata nel prezzo — o riequilibrata, come vediamo fra poco.
Come si valuta la sostenibilità di un contratto a performance
In un contratto a performance l'importo massimo scritto nel bando non è un corrispettivo: è un tetto. Il valore atteso si costruisce con una moltiplicazione semplice, e conoscerla serve a entrambe le parti — al fornitore per formulare un'offerta sostenibile, all'amministrazione per capire quali offerte lo sono.
La formula è volume effettivo × tariffa al netto del ribasso × quota di richieste effettivamente risolte. Applicata al caso visto sopra, con 60.000 ticket annui a tariffa piena i diciotto mesi varrebbero circa 223.500 euro, cioè poco più del tetto di 215.000: il tetto corrisponde in sostanza allo scenario di stima piena. Da lì in giù, ogni variabile lavora in modo indipendente.
| Ipotesi | Volume annuo | Ribasso | Quota risolta | Valore su 18 mesi |
|---|---|---|---|---|
| Stima piena, nessun ribasso | 60.000 | 0% | 100% | 215.000 € (tetto) |
| Con il ribasso d'asta | 60.000 | 21,5% | 100% | ~177.000 € |
| Ipotesi prudente | 42.000 | 21,5% | 60% | ~74.000 € |
La distanza fra la prima e l'ultima riga non è un difetto del modello: è la sua natura, ed è precisamente ciò che rende il pay-per-performance conveniente per l'ente. Serve però che entrambe le parti guardino la stessa tabella. Un'offerta costruita sulla prima riga è fragile; un'offerta costruita sull'ultima è solida e, di solito, anche più onesta nel prezzo unitario.
Le cinque clausole che tengono il contratto in equilibrio
Un contratto a performance funziona bene quando cinque punti sono espliciti. Valgono sia per chi scrive il capitolato sia per chi decide se presentarsi, e sono gli stessi che proponiamo quando lavoriamo a risultato.
- Una base sul volume. Un minimo di lavorazioni, oppure un corrispettivo di attivazione se le richieste effettive restano sotto una soglia della stima. Conviene anche all'ente: riduce il ricarico prudenziale che altrimenti finisce nel prezzo unitario.
- Un indicatore verificabile da entrambi. L'unità remunerabile va definita su ciò che il sistema fa e che si legge nei log, con una regola di chiusura decorso un termine, una soglia di confidenza dichiarata e un riferimento tecnico per i casi dubbi.
- Date certe sui prerequisiti. Documentazione, API, base di conoscenza e ambiente di test sono l'input del servizio: fissarne la consegna, e prevedere che i termini di rilascio slittino di pari passo, protegge il cronoprogramma di tutti.
- Proprietà intellettuale su due livelli. La soluzione realizzata per l'amministrazione va all'amministrazione; il framework e i componenti riusabili restano al fornitore, con licenza d'uso perpetua e irrevocabile a favore dell'ente. Il riuso è ciò che tiene basso il prezzo dei contratti successivi.
- Una scala di riequilibrio del prezzo. Sotto una soglia di volume concordata il prezzo unitario risale secondo una scala scritta in contratto. Lo strumento esiste già: l'art. 60 del D.Lgs. 36/2023 prevede la revisione prezzi, e nulla vieta di parametrarla anche alle quantità.
Sono cinque righe di capitolato, non un negoziato complesso. Se state impostando un affidamento a risultato e volete metterle alla prova su un caso concreto, confrontiamoci sul vostro capitolato: è lì che questi progetti si decidono, molto prima che sulla tecnologia.
Come adottarlo senza gara, sotto i 140.000 euro
Adottare il pay-per-performance non richiede di replicare una procedura da 215.000 euro. Sotto i 140.000 euro per servizi e forniture, l'art. 50, comma 1, lettera b) del D.Lgs. 36/2023 consente l'affidamento diretto anche senza consultazione di più operatori economici, scegliendo soggetti con documentata esperienza pregressa. Il modello a performance non cambia la procedura: cambia solo come è costruito il corrispettivo.
Ed è la scala giusta per la gran parte delle amministrazioni. Un comune medio non ha decine di migliaia di ticket l'anno: ne ha qualche migliaio, distribuiti fra URP, tributi, edilizia e anagrafe. Su quei volumi un affidamento diretto su un singolo flusso, con un corrispettivo unitario e una durata di dodici mesi, ottiene lo stesso risultato con una frazione dell'attrito amministrativo. È anche il modo più sensato di impostare il roll-in: si parte da un flusso solo, lo si misura, e si estende quando i numeri lo giustificano.
Quello che non cambia mai sono le tre righe da mettere nero su bianco prima della firma: cosa si misura, come si misura e chi certifica la misura. Con quelle tre righe il contratto è snello e liquidabile senza discussioni; senza, diventa ambiguo proprio nel momento in cui va pagato.
È il modello con cui lavoriamo. Le nostre pipeline AI per la Pubblica Amministrazione non si vendono a licenza: le costruiamo, le configuriamo sul flusso dell'ente e ci remuneriamo sul risultato misurato, con la proprietà del motore che resta nostra e l'uso garantito all'amministrazione. Se volete capire se un vostro flusso regge questo schema — quale volume serve, cosa misurare, cosa vi verrebbe chiesto — scriveteci due righe e lo verifichiamo sui vostri numeri, non su una demo.
Il criterio da portarsi via
Torniamo alla domanda del titolo. Per integrare l'AI in un'amministrazione il pay-per-performance è il modello adatto, e per una ragione specifica: è l'unico che non chiede all'ente di scommettere in anticipo su un rendimento che nessuno può conoscere prima di averlo misurato sui suoi dati. In più sostituisce requisiti che selezionavano per dimensione con un criterio che seleziona per risultato. Vale la pena adottarlo, e vale altrettanto la pena scriverlo bene: senza le cinque clausole viste sopra resta un buon modello dentro un contratto fragile.
Il criterio operativo è uno solo, e si applica prima di qualsiasi capitolato: affidate al fornitore il rischio che il fornitore può governare, e tenete quello che governate voi. Qualità della risoluzione, tempi, accuratezza del modello sono suoi e devono pesare sul suo compenso. Volume delle richieste, qualità delle API, puntualità della base di conoscenza restano vostri: tenerli dalla vostra parte non è una concessione, è ciò che rende l'affidamento attraente per i fornitori giusti.