Il procurement enterprise ha imparato a valutare software, servizi cloud e piattaforme SaaS con strumenti sempre più maturi. Capitolati tecnici, analisi del total cost of ownership, SLA, clausole di sicurezza, audit sui fornitori e verifiche di compliance fanno ormai parte del mestiere. L’arrivo del software agentico, però, sposta il problema su un terreno più complesso. Non si acquista soltanto un’applicazione con funzionalità definite. Si introduce una capacità operativa che può interpretare contesto, usare strumenti, accedere a dati sensibili, prendere iniziative entro limiti predefiniti e, in alcuni casi, coordinare altre componenti autonome.
Questo cambia il senso stesso della selezione. Prezzo, facilità d’uso e promessa di produttività restano importanti, ma non bastano se non sono accompagnati da auditabilità, osservabilità, controllo dei dati, chiarezza sulla catena dei fornitori e sostenibilità economica lungo il ciclo di vita. Il procurement non può più limitarsi a negoziare condizioni commerciali vantaggiose. Deve diventare un presidio di rischio, qualità architetturale e governo dell’autonomia.
La difficoltà nasce dal fatto che il software agentico non è ancora una categoria standardizzata in modo stabile. Il mercato usa la stessa etichetta per prodotti molto diversi: assistenti AI con accesso a strumenti, agenti specializzati in singoli workflow, piattaforme di orchestrazione, sistemi multi-agente e soluzioni embedded in suite enterprise. Proprio per questo la valutazione deve essere più rigorosa.
Quando il linguaggio commerciale è ampio, l’audit deve diventare più concreto.
Indice degli argomenti:
Il procurement deve guardare al comportamento, non solo alle funzionalità
Nel software tradizionale il processo di selezione parte spesso da una domanda chiara. Che cosa fa il prodotto? Con il software agentico, questa domanda è necessaria ma insufficiente. Bisogna chiedere anche come il sistema esegue un compito, quali strumenti interpella, quali dati riceve, quali azioni può intraprendere, quando si ferma, quando chiede conferma e come rende ricostruibile il proprio comportamento.
Una demo brillante può dire poco sulla maturità reale della soluzione. Un agente può apparire efficace quando lavora su casi lineari e perdere affidabilità davanti a dati incompleti, policy ambigue o eccezioni operative. Può generare output convincenti ma difficili da auditare. Può automatizzare un passaggio e spostare il costo su controlli successivi, integrazioni fragili o revisione umana non prevista.
Dal catalogo funzionale alla verifica del percorso operativo
Nelle gare tradizionali si chiede al fornitore quali funzionalità siano disponibili. Con l’agentic software serve analizzare il percorso operativo. Quali passaggi segue il sistema per completare un task? Usa un modello unico o più componenti specializzati? Quando accede a strumenti esterni? Quali dati vengono caricati nel contesto? Come viene gestito un errore? Quali log restano disponibili per audit, sicurezza e troubleshooting?
Due prodotti possono offrire la stessa funzionalità apparente, per esempio la gestione automatica di richieste interne o la classificazione di documenti, ma differire radicalmente sul piano della governabilità. Uno può lasciare tracce leggibili, applicare permessi granulari e prevedere fallback. L’altro può funzionare bene in superficie ma rendere difficile capire perché abbia prodotto un determinato esito. Per il procurement questa differenza è sostanziale.
Il prezzo di licenza racconta solo una parte del costo
Il costo di licenza è sempre meno rappresentativo del costo reale. Nel software agentico contano integrazione, consumo inferenziale, uso di token, logging, monitoraggio, compliance, formazione, supervisione umana e adattamento ai processi interni. Una soluzione con tariffa competitiva può rivelarsi più onerosa di una apparentemente più costosa, se richiede molto lavoro di governo o produce costi variabili difficili da prevedere.
Il procurement deve quindi ragionare in ottica di TCO esteso. Il punto non è soltanto quanto costa entrare nel servizio, ma quanto costa mantenerlo sotto controllo quando cresce l’uso. In molti casi il business case si indebolisce non per il prezzo iniziale, ma per spese ricorrenti poco visibili: chiamate ai modelli, storage dei log, audit periodici, verifiche sui dati, gestione delle eccezioni e interventi correttivi dopo il rilascio.
I nuovi criteri di audit partono da architettura, dati e autonomia
I criteri di audit devono riflettere la natura del software che si sta acquistando. Il primo riguarda la trasparenza architetturale. Serve capire quali modelli, strumenti, connettori e componenti esterne entrano nella catena esecutiva. Il secondo riguarda il trattamento dei dati, compresi log, metadati e contesto inviato ai modelli. Il terzo tocca i limiti dell’autonomia. Il quarto riguarda la sicurezza e la possibilità di tracciare ogni azione rilevante.
A questi elementi si aggiungono aspetti economici e contrattuali: portabilità, dipendenza da sub-responsabili, clausole di aggiornamento, responsabilità in caso di incidente, supporto alle verifiche di conformità, granularità dei permessi, segregazione tra ambienti e capacità di uscita dal servizio.
Un audit serio non cerca un’impossibile assenza di rischio. Cerca evidenze sufficienti per capire se il rischio sia governabile.
Auditabilità tecnica, log e spiegabilità operativa
Uno dei primi elementi da verificare è la qualità dei log. Non basta che il sistema produca tracce tecniche abbondanti. Devono essere utili a chi dovrà governarlo. Serve sapere che cosa è stato chiesto, quali strumenti sono stati usati, quali passaggi intermedi hanno orientato l’esito, quali autorizzazioni sono state applicate e quale livello di confidenza accompagna il risultato.
La spiegabilità operativa conta almeno quanto quella algoritmica. In azienda non basta sapere che un output è stato generato. Serve poter ricostruire il percorso che ha portato a quell’output, soprattutto se il sistema può influenzare decisioni rilevanti, interazioni con clienti, processi regolamentati o azioni su sistemi transazionali.
Senza questa capacità, ogni incidente diventa più difficile da attribuire e correggere.
Dati, metadati e sub-responsabili nella catena del trattamento
Il secondo grande capitolo riguarda i dati. Che cosa viene conservato, dove, per quanto tempo e con quale finalità? Il fornitore riutilizza input, output, prompt, log o metadati per migliorare il servizio? I dati del cliente possono essere consultati da personale del vendor o da terzi? Esiste una filiera di sub-responsabili? Come viene gestita l’uscita dal servizio e l’eventuale cancellazione dei dati residui?
Queste domande non sono un dettaglio legale. Sono parte dell’audit sul valore del prodotto. Se i dati vengono gestiti in modo opaco, aumentano rischio regolatorio, rischio reputazionale e costo potenziale dell’adozione.
Le linee guida europee sui ruoli di controller e processor, insieme alle indicazioni più recenti sui sub-responsabili, rendono particolarmente importante chiarire la catena di trattamento prima della firma.
Limiti dell’autonomia e controllo delle azioni
Il procurement deve capire non solo quali output il sistema produce, ma quali azioni può compiere. Un agente che sintetizza documenti ha un profilo di rischio diverso da uno che aggiorna un CRM, modifica un ordine, invia comunicazioni esterne, apre ticket o richiama API transazionali. Più il sistema può agire, più servono permessi granulari, soglie di approvazione, sandbox, limiti di spesa e registri completi.
Questo punto è spesso sottovalutato perché il linguaggio commerciale dell’AI tende a enfatizzare l’autonomia come valore in sé. In azienda, invece, l’autonomia ha valore solo se è circoscritta e verificabile. Un agente troppo libero può sembrare potente, ma diventa difficile da accettare nei processi dove contano responsabilità, sicurezza e audit.
La selezione deve coinvolgere più funzioni fin dall’inizio
Nel software agentico il procurement non può operare da solo. La decisione riguarda un sistema che può entrare in aree sensibili dell’operatività e modificare il rapporto tra persone, dati e processi. Serve quindi una valutazione congiunta tra chi conosce l’architettura, chi presidia la sicurezza, chi legge i vincoli regolatori, chi controlla i costi e chi possiede il processo di business.
Spostare questa collaborazione a valle è rischioso. Se il procurement acquista sulla base di criteri prevalentemente commerciali e solo dopo emergono limiti di sicurezza, opacità sui dati o costi di integrazione inattesi, la correzione diventa più onerosa. Il rigore va anticipato, quando si possono ancora negoziare condizioni, chiedere evidenze, imporre limiti o scartare soluzioni non allineate.
CIO, CISO, legal e finance devono condividere la stessa griglia
Il CIO valuta integrazione, sostenibilità tecnica e compatibilità con l’ecosistema esistente. Il CISO osserva superfici di rischio, gestione degli accessi, identità degli agenti e tracciabilità. Il legal verifica ruoli, contratti, sub-responsabili, uso dei dati e compatibilità normativa. Il finance legge costo totale, variabilità della spesa e impatto sul business case. Nessuna di queste prospettive è sufficiente da sola.
La selezione efficace nasce quando queste funzioni lavorano su una griglia comune. Una soluzione tecnicamente forte ma ingestibile sul piano contrattuale non è una buona soluzione enterprise. Allo stesso modo, un prodotto economicamente interessante ma opaco sul piano del controllo può diventare un problema al primo incidente. La maturità del procurement si misura dalla capacità di tenere insieme queste letture.
Prove pilota, benchmark e test su casi reali
Le imprese più attente affiancano alla documentazione formale prove pilota costruite su casi reali. Non basta chiedere al vendor esempi generici o scenari dimostrativi. Occorre osservare il sistema su task coerenti con il proprio contesto, valutare come gestisce eccezioni, quanto contesto richiede, quando chiede supporto umano, quali log produce e quanto è facile ricostruirne il comportamento.
Questo tipo di benchmark è più impegnativo ma molto più rivelatore. Fa emergere latenza decisionale, qualità del routing, costo effettivo per task, robustezza dell’orchestrazione e capacità di rimanere entro limiti definiti. È una forma di audit sperimentale che integra la due diligence documentale e riduce la dipendenza dal racconto commerciale del fornitore.
I costi variabili dell’AI cambiano il ruolo del procurement
L’AI rende più instabile la struttura dei costi del software. La spesa può dipendere dal numero di richieste, dalla complessità del contesto inviato, dal tipo di modello, dal volume dei log, dal livello di supervisione richiesto, dalla frequenza dei controlli e dal consumo di servizi esterni. Un procurement maturo non può ignorare questa variabilità.
Il tema non è soltanto negoziare sconti, ma costruire un assetto di controllo. Soglie di consumo, reportistica, visibilità sui costi unitari, alert, limiti di utilizzo per categorie di task e chiarezza sulle componenti fatturabili diventano elementi decisivi. Qui il procurement deve lavorare a stretto contatto con FinOps, IT finance e product owner, perché il valore dell’AI dipende dalla relazione tra consumo, risultato e controllo.
Stimare il costo dell’autonomia oltre il listino
L’autonomia ha un prezzo che va oltre il listino commerciale. Ogni margine di iniziativa concesso al software implica costi di osservabilità, policy, audit, supervisione e talvolta redesign dei processi. Se queste voci non vengono considerate in anticipo, il business case risulta artificialmente ottimistico.
Il procurement deve focalizzarsi sul rendimento del software enterprise oltre il semplice costo licenza. Il vero confronto tra soluzioni si gioca su quanto valore netto resti dopo aver incluso tutte le misure necessarie per usare il sistema in modo stabile, conforme e sicuro. È qui che si distinguono i prodotti maturi da quelli costruiti soprattutto per impressionare in fase dimostrativa.
Dal contratto alla gestione continua del fornitore
Con il software agentico il rapporto con il vendor non finisce alla firma. Aggiornamenti del modello, evoluzione degli standard, nuovi sub-responsabili, cambi nelle politiche di logging, modifiche dei costi di consumo e nuove funzionalità autonome possono alterare il profilo di rischio e di valore della soluzione. Per questo il vendor management deve diventare continuo.
Review periodiche, audit ricorrenti, monitoraggio dei KPI, controlli su sicurezza e verifiche di compliance aiutano a evitare che una decisione inizialmente corretta degradi nel tempo. L’acquisto è solo il primo atto. Il governo del fornitore è la parte che determina la sostenibilità reale.
Data Act, AI Act e standard di governance cambiano le aspettative di mercato
Il procurement dell’AI non si muove in un vuoto normativo. In Europa, l’AI Act introduce un quadro basato sul rischio, con obblighi differenziati per operatori, sistemi e modelli. Il Data Act rafforza il tema della portabilità e del cambio di fornitore nei servizi di data processing, con l’obiettivo di ridurre barriere allo switching e favorire interoperabilità.
In parallelo, standard come ISO/IEC 42001 e framework come il NIST AI RMF offrono riferimenti utili per strutturare governance, gestione del rischio e controlli lungo il ciclo di vita.
Per il procurement questo significa che le domande da porre ai fornitori diventano più precise. Non basta sapere se una soluzione è conforme in senso generico. Serve capire quali obblighi ricadano sul provider, quali sul deployer, quali controlli siano disponibili, quali evidenze possano essere fornite e come la soluzione si comporti quando cambia il contesto normativo o tecnico.
La portabilità è una componente del valore
La capacità di uscire dal servizio è parte del valore del software. Se dati, configurazioni, log, workflow o conoscenza operativa non possono essere esportati in modo utile, la dipendenza dal fornitore aumenta. Questo è particolarmente rilevante nei sistemi agentici, dove il patrimonio informativo accumulato non riguarda solo dataset statici, ma anche contesto operativo, regole, memorie, integrazioni e tracciati di decisione.
Una soluzione che rende difficile la migrazione può apparire conveniente all’inizio e diventare costosa nel tempo. Per questo portabilità, interoperabilità e clausole di uscita devono essere valutate già in fase di procurement. Non sono dettagli contrattuali di chiusura. Sono condizioni della libertà operativa futura.
La compliance non deve essere delegata interamente al vendor
Il fornitore ha responsabilità proprie, ma l’impresa che integra il sistema nei propri processi conserva un ruolo decisivo. La stessa tecnologia può avere profili di rischio diversi a seconda del contesto d’uso. Un agente impiegato per assistenza interna non ha lo stesso peso di uno inserito in un processo di credito, selezione del personale, compliance finanziaria o gestione di reclami sensibili.
Per questo la compliance non può essere trasferita integralmente al vendor. Il procurement deve chiedere evidenze, ma l’organizzazione deve anche valutare il modo in cui userà davvero il sistema. La responsabilità nasce dall’intersezione tra prodotto, processo e decisione aziendale.
Acquistare software agentico senza comprare opacità
Il compito del procurement enterprise sta cambiando. Non basta più acquistare funzionalità al miglior prezzo possibile. Occorre selezionare sistemi che possano entrare nell’operatività aziendale senza trasformarsi in centri di costo opachi, fonti di rischio o dipendenze difficili da gestire. Questo richiede più competenza tecnica, più collaborazione interfunzionale e una disciplina di audit meno superficiale.
Le organizzazioni che sapranno acquistare bene avranno un vantaggio vicino a quello di chi saprà sviluppare bene. Il software agentico promette molto, ma il suo valore emerge solo quando autonomia, controllo e sostenibilità economica restano in equilibrio.
E quell’equilibrio comincia già nella fase di procurement, molto prima che il sistema arrivi in produzione.
Bibliografia
McKinsey, The State of AI: Global Survey 2025
ISO/IEC 42001:2023, Artificial intelligence — Management system
NIST, Artificial Intelligence Risk Management Framework
NIST, Artificial Intelligence Risk Management Framework: Generative Artificial Intelligence Profile
EDPB, Guidelines 07/2020 on the concepts of controller and processor in the GDPR
European Commission, Data Act explained
European Commission, AI Act Service Desk — Frequently Asked Questions
FinOps Foundation, FinOps for AI Overview
FinOps Foundation, FinOps for AI — Technology Category
OECD, The agentic AI landscape and its conceptual foundations
