“Se devi usare il kill switch, il sistema non sta funzionando: sei già morto, gli errori sono già stati commessi”. Alan Trefler, fondatore e CEO di Pegasystems, liquida così una delle promesse più ricorrenti dell’AI agentica: lasciare migliaia di agenti liberi di agire e affidare a una control tower il compito di fermarli quando qualcosa va storto. In un processo aziendale critico, sostiene, il controllo deve arrivare prima dell’errore ed essere incorporato nell’architettura.
Da questa premessa discende la sua idea di AI enterprise responsabile: i modelli possono esplorare, progettare, interpretare richieste e svolgere compiti circoscritti, mentre l’esecuzione deve seguire workflow governati. Una banca, un’assicurazione, un’amministrazione pubblica o un’organizzazione sanitaria devono sapere quali regole saranno applicate, quanto costerà ogni operazione e chi potrà intervenire quando cambieranno una norma o una politica interna. La stessa esigenza riguarda le imprese che vogliono trattare i clienti in modo equo, razionale, personale e coerente. La responsabilità assume così una proprietà misurabile: la prevedibilità di risultati, costi e cambiamenti.
La posizione nasce da oltre quarant’anni trascorsi a sviluppare software per grandi organizzazioni. Trefler ha fondato Pegasystems nel 1983 per creare un linguaggio comune tra chi conosce il business e chi realizza la tecnologia, in modo che entrambi potessero condividere una rappresentazione del funzionamento dell’impresa e affidarne l’esecuzione al software. Citibank e Bank of America, entrate in produzione nel 1984, sono state i primi due clienti. Da allora Pega si concentra sui processi complessi e regolamentati, nei quali una decisione deve restare comprensibile e modificabile anche molti anni dopo la sua introduzione.
L’adozione dell’AI come prova da esibire
Trefler individua il primo errore prima ancora della scelta tecnologica. Molte imprese partono dal bisogno di dimostrare al management e al consiglio di amministrazione che stanno usando l’AI, senza definire il risultato da raggiungere. “L’AI è diventata una fonte di spavalderia e di ego, invece di essere un modo pratico per applicare una nuova tecnologia importante”, afferma. “L’aspetto più evidente della conversazione è la confusione: su ciò che le organizzazioni dovrebbero cercare di ottenere, su come dovrebbero farlo e su come capire se stanno avendo successo”. L’impiego dell’AI diventa il traguardo da comunicare, quando dovrebbe essere uno strumento valutato attraverso tempi, costi, qualità del servizio, conformità e capacità di adattamento. Nei processi regolamentati un risultato plausibile non è sufficiente: l’impresa deve poter ricostruire una decisione, dimostrare quali regole siano state applicate e sapere come il sistema si comporterà davanti a casi ricorrenti.
Trefler teme che gli errori compiuti in questa fase provochino una reazione capace di danneggiare sia i clienti sia l’intero settore. “Molto di ciò che viene detto oggi e molto di ciò che fanno i tecnologi non raggiunge gli standard che saranno necessari. Stiamo cominciando a vedere il contraccolpo prodotto da decisioni terribili, con conseguenze che potrebbero essere negative per i clienti e per l’industria”. La responsabilità non viene quindi presentata come un principio astratto, ma come una condizione per evitare che applicazioni incontrollate compromettano la fiducia nell’AI enterprise.
La corsa è alimentata anche da un messaggio contraddittorio. Trefler richiama gli avvertimenti dei vertici delle maggiori società di AI, da Sam Altman a Dario Amodei, sui rischi dei modelli più potenti e sulla difficoltà di controllarli. “Salgono in televisione e dicono: dobbiamo rallentare, non sappiamo come controllarla. Nello stesso momento, queste aziende e i loro consulenti dicono alle imprese: cedete all’AI il controllo di parti del vostro business”. L’affermazione secondo cui un modello sarebbe tanto potente da richiedere cautela alimenta inoltre il timore di restare indietro. “Che brillante operazione di marketing: abbiamo creato qualcosa di molto spaventoso e non potete averlo”, commenta Trefler a proposito di questo meccanismo.
Dietro questa comunicazione Trefler vede la pressione prodotta da investimenti senza precedenti e da rapporti finanziari che giudica poco trasparenti. “Cose che anni fa mi sarei chiesto se fossero legali sono diventate comuni: un’azienda presta denaro a un’altra perché questa possa comprare qualcosa, e il rapporto non appare con chiarezza nei bilanci. Non mi dà una buona sensazione”. Il riferimento è alle operazioni circolari con cui finanziamento, capacità di calcolo e acquisti di tecnologia possono alimentarsi a vicenda. Trefler riconosce somiglianze con precedenti bolle speculative, pur distinguendo l’AI perché alla base esiste una tecnologia reale e capace di produrre risultati utili.
Trefler riconosce esplicitamente il valore della tecnologia. “Qui c’è una tecnologia reale e alcune delle cose che fa sono davvero entusiasmanti, quasi magiche. Quando ricevo un’email in italiano, posso ottenerne subito una traduzione perfetta. È notevole”. La questione riguarda il contesto d’uso e il livello di autonomia concesso. Un responsabile marketing può impiegare un modello per generare idee, perché l’esplorazione ammette proposte sbagliate o inattese; un processo che concede un prestito, gestisce una contestazione o verifica l’accesso a un sussidio pubblico richiede un esito affidabile e verificabile.
La cucina sperimentale e le ricette di produzione
Trefler spiega l’architettura di Pega attraverso la metafora di un ristorante. “Usiamo l’AI come se fosse nella cucina sperimentale di un nuovo ristorante. Lo chef progetta piatti e ricette e prova molte cose con grande libertà. Se in quella cucina si commette un errore, non è un problema: vogliamo la sperimentazione e forse anche un po’ di allucinazione”. Le ricette migliori vengono poi selezionate, organizzate e verificate prima di entrare nel menu. Durante il servizio, il cliente può chiedere una variazione, per esempio eliminare le carote, e l’AI può interpretare la richiesta; il piatto continua però a essere preparato seguendo una ricetta conosciuta.
Questa distinzione tra design time e runtime è alla base di Pega Predictable AI. “Le ricette sono la governance”, sintetizza Trefler. “Si usa la capacità di ragionamento dell’agente per creare buone ricette e mettere alla prova il cuoco. Quando gli agenti entrano in funzione, però, non possono inventarne di nuove”.
Una fattoria di lama per mettere alla prova Blueprint
Per spiegare che cosa intende quando parla di “ricette”, Trefler sceglie un caso molto lontano da banche e assicurazioni: il noleggio di lama per feste di compleanno. “Negli Stati Uniti esiste davvero. Se arrivi alla festa di tuo figlio cavalcando un lama, o anche soltanto portandone uno, posso assicurarti che quel bambino di otto anni non lo dimenticherà mai”. Gli animali vengono richiesti anche per visite in fattoria, dove il contatto con i lama viene proposto come esperienza rilassante.
Nel test, l’utente scrive soltanto di voler aprire un ranch che affitta lama. Da poche indicazioni Blueprint ricostruisce una prima struttura dell’attività: personale capace di occuparsi degli animali, autorizzazioni, assistenza veterinaria, marketing, prenotazioni e calendario degli eventi. “È sorprendente: Blueprint crea tutto questo partendo soltanto da poche frasi”, afferma Trefler.
La prima proposta può comprendere una ventina di processi, dal marketing alla cura degli animali. L’imprenditore può esaminarli, eliminarne alcuni, modificarne altri e decidere quali trasformare in procedure operative. La generazione serve quindi a esplorare possibilità e a far emergere attività o regole non considerate inizialmente; la versione che entra in produzione viene invece selezionata e definita prima dell’esecuzione.
Se un cliente chiede un animale grigio e il ranch possiede soltanto lama bianchi, l’AI può interpretare la richiesta e formulare un’alternativa. “Mi dispiace, non abbiamo il colore che desidera, ma abbiamo un lama molto simpatico che si chiama Susan e sono sicuro che andrà benissimo per i suoi bambini”, esemplifica Trefler. Il workflow deve però conoscere le disponibilità, impedire una prenotazione impossibile e sapere anche “quali lama sputano e quali no”, così da assegnare gli animali alle situazioni appropriate.
L’AI può quindi contribuire alla progettazione dell’attività e sostenere una conversazione naturale con il cliente, mentre prenotazioni, controlli e assegnazioni seguono processi definiti. Trefler contrappone questa impostazione alla possibilità di creare un unico “agente dei lama” incaricato di gestire autonomamente il ranch. Un sistema del genere, osserva, potrebbe arrivare a consumare “centinaia di migliaia di token al giorno”, perché dovrebbe ragionare nuovamente su ogni operazione. Il risultato sarebbe una minore prevedibilità sia del comportamento sia dei costi.
Blueprint dal linguaggio naturale al sistema eseguibile
Dietro l’esempio del ranch c’è il metodo con cui Pega applica questa filosofia alla progettazione dei processi. Blueprint è accessibile gratuitamente su Pega.com a clienti, prospect, partner e a chiunque voglia provarlo. È multilingue e può lavorare interamente in italiano. Per iniziare bastano due o tre frasi che descrivano l’attività da organizzare o il risultato desiderato.
Da quella descrizione Blueprint sviluppa una prima mappa dei processi. Il sistema attinge a un database vettoriale che raccoglie la conoscenza maturata da Pega sul funzionamento dei workflow e la combina con informazioni pertinenti reperite online. Queste fonti esterne alimentano l’esplorazione, senza diventare automaticamente regole operative. “Non crede a nulla di ciò che trova: mette tutto insieme”, spiega Trefler. Modelli come Claude o Gemini aiutano a interpretare il materiale e a trasformarlo in una proposta strutturata di processi e regole.
Il risultato prende la forma di un progetto visibile, modificabile e condiviso. L’utente può esaminare i processi proposti, eliminare quelli inutili, conservarne altri e chiedere correzioni. È qui che Trefler colloca la collaborazione tra competenze aziendali, IT e AI: “I progetti erano molto buoni: potevi vederli e lavorarci sopra. Business e IT potevano collaborare con l’AI per definire le ricette”. La qualità della prima proposta conta, ma il controllo deriva dalla possibilità di ispezionarla e modificarla prima che governi un’attività reale.
Una volta approvato il progetto, Blueprint passa dalla rappresentazione alla realizzazione. “Poi creerà davvero il sistema”, afferma Trefler descrivendo l’esempio dei lama: un’applicazione capace di ricevere prenotazioni, gestire il calendario e applicare i processi definiti nella fase di design. Il linguaggio naturale serve quindi ad avviare e correggere il progetto, mentre il risultato approvato viene tradotto in workflow, regole e decisioni eseguibili. Questo passaggio conserva una rappresentazione comprensibile della logica aziendale e permette di aggiornarla senza dover ricostruire il sistema a partire dal codice generato.
Durante l’esecuzione, l’AI interviene nei punti in cui serve una capacità probabilistica: può comprendere l’intento dell’utente, leggere un documento, tradurre o riassumere un testo. L’architettura stabilisce quale workflow eseguire, quali strumenti richiamare e quali variazioni siano ammesse. “Possono fare piccole variazioni, ma il workflow della ricetta viene rispettato dall’architettura”, precisa Trefler. Il modello non deve ridefinire ogni volta l’obiettivo, l’ordine delle attività o i criteri decisionali.
Pega non sviluppa un proprio modello di frontiera. Blueprint e la piattaforma possono utilizzare Claude, Gemini o i modelli di OpenAI, scegliendo la tecnologia adatta al singolo passaggio. Il riconoscimento di un documento, una traduzione o una sintesi possono essere affidati a un modello più piccolo e specializzato, perché il compito da svolgere è già definito. “Se devi mescolare una salsa, non vai a comprare un mixer industriale: usi qualcosa di adeguato alla quantità di salsa che devi preparare”, osserva Trefler. Per il CEO di Pega, applicare lo stesso criterio alla scelta dei modelli rende l’architettura più solida e limita costi e risorse impiegate inutilmente.
Le dimostrazioni di Blueprint hanno un ruolo centrale anche nella strategia italiana di Pega, che conserva una presenza contenuta nel Paese e intende ampliarla. Trefler cita tra i clienti primarie banche e istituti assicurativi italiani, oltre al rafforzamento della squadra locale e al lavoro avviato per far conoscere maggiormente l’azienda. Il mercato, osserva, è affollato da fornitori e annunci che rendono difficile distinguere una piattaforma adatta alla produzione da una dimostrazione efficace soltanto in condizioni controllate. “Ogni settimana compaiono altre cento aziende di AI. È un mercato estremamente rumoroso”. Gli incontri con clienti e prospect servono quindi a mostrare la differenza tra un agente libero di ragionare a ogni passaggio e un processo con risultati e costi prevedibili. Trefler richiama inoltre il recente posizionamento di Pega tra i leader della Forrester Wave dedicata alle piattaforme di AI come conferma della strategia adottata dall’azienda.
Il codice generato e il ritorno del debito tecnico
La generazione automatica di codice rappresenta la prima delle due scorciatoie che Trefler contesta. I modelli sono capaci di programmare e possono risultare utili per software semplice o destinato a cambiare poco. Nei sistemi grandi e complessi, la prova decisiva arriva mesi dopo, quando occorre recepire un requisito normativo, modificare un prodotto o ricostruire le dipendenze di una funzione.
“Il problema non è scrivere il codice. Il problema arriva sei mesi dopo, quando devi fare una modifica o cambia una norma: come fai anche solo a sapere che cosa hai?”, domanda Trefler. Un modello può produrre volumi enormi di software; chiedergli in seguito di leggere ciò che ha generato richiede altri token e introduce un costo proporzionale alla complessità accumulata. La difficoltà precede anche l’intervento tecnico: per una persona di business può essere complicato descrivere una modifica normativa composta da molte parti e tradurla in istruzioni abbastanza precise da aggiornare il sistema senza effetti collaterali. “È nel loro interesse finanziario generare enormi quantità di codice, perché quando lo leggeranno di nuovo produrranno più token e più ricavi”.
Il CEO colloca l’entusiasmo attuale in una sequenza già vista. Prima l’open source avrebbe dovuto eliminare il software commerciale; ha trasformato il settore e risolto molti problemi, ma non ha sostituito le piattaforme necessarie ai processi più sofisticati. In seguito, l’esternalizzazione dello sviluppo verso Paesi con costi inferiori avrebbe dovuto rendere superflui i prodotti software; le imprese hanno ottenuto grandi quantità di codice e scoperto problemi di qualità, comprensione e manutenzione. L’AI può moltiplicare lo stesso effetto se la velocità di produzione viene scambiata per sostenibilità dell’architettura.
È il motivo per cui Trefler richiama il principio “Build for Change”, adottato da Pega da più di trent’anni. “La cosa più importante nel portare una tecnologia in azienda non è che faccia ciò che volevi il primo giorno, ma che un anno dopo tu possa farle fare ciò che serve allora”. Blueprint punta a trasformare le indicazioni espresse in linguaggio naturale in modelli visuali di processi, dati e regole che business e IT possano esaminare insieme, evitando che la logica aziendale resti sepolta in un nuovo debito tecnico.
Agenti autonomi e controlli che arrivano troppo tardi
La seconda scorciatoia consiste nel sostituire il codice con agenti ai quali viene descritto un obiettivo in linguaggio naturale. Un’impresa può chiedere a un agente di acquisire un cliente o gestire una contestazione, poi crearne altri per le diverse parti del processo.
Secondo Trefler, alcuni concorrenti arrivano a ipotizzare 6.000, 10.000 o 15.000 agenti all’interno di una sola organizzazione. A sorvegliarli dovrebbe esserci una control tower, con un kill switch per bloccare quelli che deviano dal comportamento previsto.
È una proposta seducente perché riduce la costruzione di un processo alla scrittura di un prompt. “Per sua natura è ambiguo, ma può entusiasmare l’ingegnere perché le demo costruite in un giorno o in una settimana sono bellissime. La domanda è: dov’è il controllo?” Il salto dalla dimostrazione alla produzione cambia infatti la natura del problema. Una demo deve mostrare che l’agente riesce a completare un percorso; un sistema enterprise deve garantire che lo completi entro regole, autorizzazioni e costi accettabili anche davanti a eccezioni non preparate in anticipo.
Per Trefler, control tower e kill switch arrivano comunque troppo tardi. “Sarebbe come dire: l’aereo non è molto affidabile, qualche volta cade dal cielo, ma daremo un paracadute a tutti. No, bisogna capire come evitare di aver bisogno dei paracadute”.
Trefler richiama anche l’incidente che nel luglio 2026 ha coinvolto OpenAI e Hugging Face. Durante alcune valutazioni interne di cybersecurity, modelli di OpenAI riuscirono ad aggirare i controlli che li isolavano da Internet, a comunicare attraverso canali non autorizzati e ad accedere a sistemi di Hugging Face. OpenAI ha attribuito il ruolo principale a un modello di ricerca interno utilizzato con salvaguardie ridotte durante i test.
“Nessuno glielo aveva permesso e nessuno aveva detto loro di farlo. Si sono creati degli obiettivi e hanno generato migliaia di agenti aggiuntivi che comunicavano tra loro per attaccare un’altra azienda, che non aveva idea di ciò che stava arrivando”.
“Non capisco come una banca, una compagnia assicurativa o un’istituzione medica possa considerare responsabile mettere gli agenti al comando del ragionamento senza governance”. La governance, nella sua impostazione, deve essere incorporata nell’architettura prima dell’esecuzione. Un agente può contribuire alla definizione del workflow e metterne alla prova la logica; in produzione deve operare dentro quel percorso, con permessi e variazioni limitati.
La stessa critica viene estesa alle proposte presentate da Salesforce a Dreamforce. “Non vedo dove ciò che hanno annunciato introduca il controllo. Mi sembra che abbiano trasferito a Claude una parte molto ampia della responsabilità”. Per i clienti entra in gioco anche il rapporto contrattuale con Salesforce e quello con Anthropic per il consumo dei token. “Che cosa controlla il ragionamento svolto da Anthropic, dal punto di vista dei costi o dei risultati? Quando ho letto l’annuncio non ho visto nulla”.
La posizione va letta anche alla luce del fatto che Pega compete direttamente con Salesforce. Il criterio indicato da Trefler resta però coerente con il resto dell’intervista: capire dove risiedano le regole, chi governi il ragionamento e come venga controllata la spesa.
I token trasformano l’autonomia in un costo variabile
Il modello economico dei fornitori è parte del problema. “Se hai un agente che consuma token e parla con un altro agente, l’intera conversazione è composta da token. Questa situazione non migliorerà, perché le aziende dell’AI hanno un interesse finanziario a far usare quanti più token possibile”. I modelli più recenti consumano inoltre token interni durante le fasi mostrate all’utente come “ragionamento” o “valutazione”, anche quando quel testo non compare nella risposta finale. Nei prototipi il costo può sembrare irrilevante; quando l’applicazione gestisce milioni di richieste, diventa una variabile difficile da stimare.
Trefler usa un’immagine volutamente provocatoria per descrivere la fase iniziale del mercato: nel 2023 i “pusher dell’AI” distribuivano token gratuitamente o a prezzi molto bassi, mentre progettavano data center da miliardi di dollari. “Allora si parlava soltanto di miliardi. Adesso si arriva perfino a parlare di data center da mille miliardi”. Pega decise allora di trattare ogni token come una risorsa che prima o poi avrebbe avuto un costo significativo. La crescita degli investimenti in infrastrutture e l’arrivo di modelli capaci di produrre lunghe catene di ragionamento hanno, secondo il CEO, reso quella cautela ancora più importante.
Durante la progettazione, il consumo di token resta utile perché il modello esplora alternative e aiuta a creare la ricetta. “Se vuole pensare e proporre idee mentre crei la ricetta, va benissimo. Una volta che la ricetta è pronta, non vuoi rifare tutto ogni singola volta che cucini un pasto”. Se una pratica di prestito o una richiesta di assistenza seguono una procedura già definita, gran parte del lavoro può essere svolta senza interrogare continuamente un modello di frontiera.
Pega ha applicato questa logica a Infinity 26. La parte più intensa del ragionamento viene concentrata nel design; al runtime, interrogazioni più leggere riconoscono l’intento e selezionano il workflow appropriato. “Quando si crea un prestito o si gestisce un cliente, più del 95% del lavoro è già stato definito. Quel 95% gira su una normale CPU, non sulle GPU Nvidia estremamente costose, ed è migliaia di volte più veloce perché il compito è più semplice”. In questa architettura oltre il 95% del lavoro segue dunque un percorso già definito; Pega associa il servizio a un prezzo per caso risolto, senza addebitare i token a consumo durante l’esecuzione.
La scelta rende prevedibili risultato e spesa. Trefler ritiene che l’incentivo dei fornitori di modelli, remunerati in base ai token, favorisca agenti che ragionano a lungo e comunicano tra loro. Pega concentra invece l’AI generativa nella progettazione e nell’interpretazione del caso, affidando l’esecuzione ordinaria a un motore di workflow.
CPU, GPU ed effetti ambientali
La quantità di calcolo influenza anche il consumo di energia. “Il fatto che un modello funzioni localmente non significa che usi meno elettricità. La domanda è quanta CPU impiega e quanta parte del lavoro finisce sulle GPU, molto più potenti e costose”. I modelli capaci di operare interamente su CPU sono in genere i meno onerosi; le configurazioni ibride dipendono dal rapporto tra le due risorse.
Pega prevede una crescita degli impieghi ibridi, sia tra cloud e infrastrutture locali sia tra modelli diversi. L’architettura della piattaforma nasce già con questa impostazione: il workflow ordinario utilizza calcolo tradizionale, mentre GPU e modelli generativi intervengono dove il compito lo richiede. Evitare di ripetere lo stesso ragionamento per ogni esecuzione riduce insieme token, costi e risorse ambientali necessarie ad alimentare i data center.
Cloud sovrano: dati, infrastruttura e chiavi di cifratura
Per le organizzazioni europee, il controllo comprende la sovranità dei dati e dell’infrastruttura. Nell’intervista la questione viene posta anche alla luce del Cloud Act statunitense: conservare le informazioni in un data center europeo non esaurisce il problema se il fornitore resta soggetto alla giurisdizione di un Paese terzo o conserva la capacità tecnica di accedere al servizio, amministrarlo e interromperlo. La sovranità, in questa prospettiva, riguarda dove risiedono i dati, chi può leggerli, chi controlla le chiavi, quale personale amministra l’ambiente e da quale ordinamento dipende il gestore.
Pega offre lo stesso software nel proprio cloud e in installazioni on premise, oggi spesso definite private cloud. Trefler cita il ministero della Difesa francese, che utilizza Pega in un ambiente qualificato SecNumCloud e gestito in Francia, come esempio dei requisiti più rigorosi. Per altri clienti, gli accordi con AWS e Google permettono di eseguire il software nella regione scelta e, nelle configurazioni previste, di affidarne la gestione a cittadini dell’Unione europea.
La risposta più netta riguarda il controllo tecnico. “Il modo più completo per affrontare il problema è questo: se il cliente esegue il software, noi non possiamo spegnerlo. E se, anche nel cloud, conserva le proprie chiavi di cifratura, come prevediamo, non possiamo vedere i dati”. Residenza, cifratura e autonomia operativa diventano quindi livelli distinti. Un servizio può essere ospitato nell’Unione europea e restare accessibile al fornitore; può essere cifrato, ma dipendere comunque da componenti che il cliente non governa; può infine funzionare nell’infrastruttura del cliente, riducendo la possibilità che un soggetto esterno ne interrompa l’esecuzione.
Il problema, secondo Trefler, è che questi livelli vengono definiti in modo diverso nei vari Paesi. “In Germania e in Francia esistono regole differenti su quali siano i diversi livelli. Sarebbe molto utile che l’Unione europea arrivasse a un’unica definizione di sovranità e la sostenesse in tutta l’UE, invece di lasciare che ogni Paese ne elabori una propria”. La Francia, con SecNumCloud, valuta aspetti tecnici, operativi e giuridici e richiede protezioni rispetto alle leggi extraterritoriali. Il catalogo tedesco C5 nasce invece come insieme di criteri per verificare sicurezza, trasparenza e controlli interni dei servizi cloud, includendo anche il trattamento delle richieste provenienti dalle autorità. I due strumenti non sono equivalenti e rispondono a priorità in parte diverse, proprio il tipo di frammentazione richiamato dal CEO di Pega.
L’Unione europea ha già iniziato a costruire un terreno comune. Il Cloud Sovereignty Framework della Commissione valuta i fornitori attraverso 48 criteri raggruppati in otto aree, che comprendono dimensione strategica, giurisdizione, dati e AI, operazioni, catena di fornitura, autonomia tecnologica, sicurezza e sostenibilità ambientale. Il framework assegna inoltre livelli SEAL per distinguere la sovranità dei dati, l’autonomia tecnologica e la piena sovranità. È stato applicato inizialmente a una gara per i servizi cloud delle istituzioni europee, quindi costituisce un metodo di valutazione e un riferimento per gli acquisti, non ancora una definizione vincolante che sostituisca tutti i regimi nazionali.
Il pacchetto sulla sovranità tecnologica presentato dalla Commissione nel giugno 2026 prevede anche un quadro unico europeo per valutare la sovranità di cloud e AI. È la direzione auspicata da Trefler, che la considera utile sia per le imprese europee sia per i fornitori internazionali. Per i clienti, criteri comuni renderebbero confrontabili offerte che oggi usano la parola “sovrano” per indicare garanzie molto diverse. Per i fornitori, ridurrebbero la necessità di progettare varianti nazionali della stessa architettura. L’armonizzazione potrebbe comunque mantenere più livelli di protezione, perché un ministero della Difesa, una banca e un’impresa con dati meno sensibili non richiedono necessariamente la stessa combinazione di controllo giuridico, tecnico e operativo.
Dalla sperimentazione diffusa al governo centralizzato
Nei prossimi anni Trefler si aspetta maggiore disciplina negli investimenti in AI. Distribuire Copilot a tutti i dipendenti può essere una scelta ragionevole; lasciare che centinaia di persone costruiscano agenti capaci di eseguire parti dell’attività aziendale crea un problema diverso. Un agente personale che raccoglie ogni mattina le notizie o i risultati sportivi ha conseguenze limitate. Un agente che approva operazioni, modifica dati o comunica con i clienti entra nell’architettura dell’impresa e deve essere trattato come tale.
Il precedente è l’end user computing. Fogli Excel e piccoli programmi creati dai singoli uffici hanno finito per gestire attività essenziali senza che l’IT riuscisse a comprenderli o controllarli. Una proliferazione di agenti può diventare il nuovo debito tecnico. “In alcune aziende stanno sbocciando mille fiori. Ma qualcuno dovrà annaffiarli, potarli e pagare i token”. La comparsa di un costo visibile può almeno aiutare l’azienda a capire quanta attività automatizzata stia avvenendo. “È positivo che adesso i token debbano essere pagati, perché almeno le persone possono capire che cosa sta succedendo. Prima di pagarli, non sapevi nemmeno che cosa stesse accadendo nella tua azienda”. I servizi apparentemente gratuiti nascondono più facilmente la scala del fenomeno.
Trefler riconosce la causa organizzativa che spinge gli utenti a costruire da soli le proprie soluzioni: l’IT centrale e i grandi sistemi monolitici spesso non riescono a rispondere abbastanza rapidamente alle esigenze dei reparti. L’AI può democratizzare la progettazione delle “ricette”, permettendo a chi conosce il processo di descriverlo e modificarlo senza attendere un lungo ciclo di sviluppo. “Le ricette non devono restare a casa dell’utente. Devono stare nella scatola delle ricette, dove tutti possano vedere che sono quelle a far funzionare l’azienda”. La formula è creazione distribuita e governo centralizzato: “la gestione e la funzione di libreria devono essere centralizzate”, conclude Trefler.
