[Osservatorio Yunqi] La conferenza Yunqi non è la risposta: è una mappa di dove l’industria AI sta scommettendo

A questa edizione della conferenza Yunqi, la cosa più utile che ho portato a casa non sono stati nuovi modelli o nuove aziende da memorizzare, ma il fatto che è cambiato il mio modo di guardare a una fiera.

In passato, alle conferenze tecnologiche, era facile dare per scontati alcuni giudizi: la direzione su cui i big tech puntano i riflettori rappresenta probabilmente il futuro; i concetti che tornano sul palco sono probabilmente il consenso del settore; un prodotto già esposto in stand sembra già abbastanza maturo. Dopo averne viste tante, si rischia poi di scivolare nell’estremo opposto: la conferenza è solo un evento di marketing, lo stand una pubblicità, le slide un involucro.

Entrambe le letture sono troppo comode.

Le fiere hanno certo una componente di marketing, ma il marketing stesso è informazione. Quando un vendor decide di concentrare budget, product manager, team di ingegneria, commerciali e risorse di stand su un’unica direzione, comunica almeno due cose: cosa vuole che il mercato creda, e per quale problema sta cercando di costruire un prodotto.

Per questo oggi preferisco considerare le grandi conferenze tecnologiche come un campo di campionamento industriale ad alta densità. Non danno risposte, ma offrono campioni, segnali, controesempi e una mappa del «futuro su cui l’industria sta scommettendo».

1. Smontare il «rumore» della fiera in diversi livelli di evidenza

In questa edizione ho iniziato a scomporre consapevolmente una direzione tecnologica in cinque livelli:

Livello narrativo → Livello di prodotto → Livello di produzione → Livello di business → Livello di ricavi
(Narrative → Product → Production → Business → Revenue)

In cima troviamo il livello narrativo (Narrative): ciò che i vendor vogliono che il mercato creda. Per esempio, che gli agenti (Agent) diventeranno il nuovo punto d’accesso al lavoro, che le imprese avranno bisogno di architetture AI-native, che il contesto (Context) diventerà un asset strategico, che i sistemi multi-agent saranno chiamati a svolgere compiti sempre più complessi. Sono affermazioni rilevanti, perché ci dicono dove si stanno spostando attenzione e capitali delle organizzazioni, ma restano pur sempre giudizi e scommesse.

Scendendo di un gradino c’è il livello di prodotto (Product): ciò che è già stato costruito e può essere mostrato, richiamato o consegnato. Demo complete, API, console operative, piattaforme di governance: tutto questo segnala che una certa direzione ha superato la fase concettuale ed è entrata nella fase di productizzazione. Tra “essere dimostrabile in una demo” e “funzionare in modo stabile nel tempo” c’è però un distacco enorme.

Più in basso ancora troviamo il livello di produzione (Production): il momento in cui il prodotto entra davvero nei processi del cliente, gira in continuità e inizia a scontrarsi con problemi concreti — permessi, dati, audit, ripristino, costi, coordinamento tra i team. Solo a quel punto si può parlare di ambiente di produzione.

Scendendo ancora troviamo il livello Business — e a questo punto le domande da porsi sono: una volta andato in produzione, cosa è cambiato concretamente? Tempi di rilascio più brevi, tassi di conversione più alti, costi operativi ridotti, un maggior numero di asset creativi testati nelle campagne, oppure un processo prima impraticabile che ora diventa eseguibile?

Alla base — e insieme al più concreto — c’è il livello Revenue: il cliente è disposto a pagare nel tempo, per quale risultato esattamente, e a quali condizioni avviene il rinnovo.

L’utilità di questo schema è evitare di mescolare prove di natura diversa. Lo stand dimostra che una direzione merita di essere messa in vetrina; il forum rivela quale narrazione il vendor intende rafforzare; le case history reali danno credibilità ai livelli Produzione e Business; solo i ricavi ricorrenti convalidano il livello Revenue.

Perciò, il fatto che una direzione sia molto discussa a un grande evento non implica automaticamente che sia il momento giusto per investire.

Due. Il cambiamento più evidente di questa edizione: sopra il modello stanno crescendo sempre più strati

Per anni il dibattito sull’AI si è concentrato quasi esclusivamente sul modello: scala dei parametri, benchmark, capacità di ragionamento, prezzo, finestra di contesto, qualità delle immagini, capacità di coding.

In fiera, questa volta, ho avuto la sensazione netta che il baricentro si stia spostando.

Il modello resta importante, ma lo strato di sistema che lo avvolge si è decisamente ispessito. Data foundation, accesso al modello, governance dei Token, Agent Runtime, Sandbox, Context, Memory, Skill, Browser Use, Computer Use, Verification, Observability, permessi, audit, controllo dei costi: un numero crescente di capacità viene impacchettato come prodotto autonomo.

Il motivo è immediato: tra un modello che sa rispondere alle domande e un modello che entra nei processi produttivi portando a termine il lavoro in modo affidabile, c’è di mezzo un intero sistema ingegneristico.

Se passi un’intera giornata in fiera, vedi cinque o sei prodotti con nomi completamente diversi, ma che in realtà stanno convergendo verso la stessa struttura. QwenWork mostra agenti che operano in ambienti isolati richiamando strumenti eterogenei per portare a termine il lavoro. Qoder parla di contesto, specifiche (Spec), framework di test (Harness), verifica (Verification), memoria e instradamento multi-modello. TinyFish, vendor indipendente presente allo stand, fa entrare gli agenti nel mondo reale del web per eseguire operazioni. WonderClip scompone la produzione video in sceneggiatura, storyboard, materiali, generazione, revisione, versioning e produzione in batch. L’Agentic Search di Alibaba Cloud OpenSearch estende a sua volta la ricerca verso pianificazione (Planning), ragionamento (Reasoning), memoria (Memory), azione (Action) e valutazione (Evaluation).

Apparentemente appartengono a settori del tutto diversi, eppure la struttura sottostante sta convergendo:

Contesto → Pianificazione → Skill → Esecuzione → Verifica → Memoria → Risultato di business
（Context → Planning → Skill → Execution → Verification → Memory → Business Outcome）

I modelli stanno progressivamente diventando uno dei componenti chiave, mentre il valore del prodotto si sposta sempre più sugli strati superiori del sistema.

III. Il contesto (Context) sta passando da “materiale di input” ad asset di lungo periodo

Una slide di Qoder è piuttosto esplicita:

Model power is a commodity. Context is the asset.

La frase, comprensibilmente, riflette la posizione di un vendor, ma mette a fuoco un problema reale: più i modelli diventano potenti e a basso costo, più ciò che determina se un agente (Agent) può lavorare a lungo in modo efficace non è la potenza del modello in sé, ma ciò che effettivamente “sa”.

Un progetto software maturo contiene vincoli architetturali, decisioni pregresse, dipendenze tra moduli, standard di codifica, insidie già incontrate, log di rilascio. Un’azienda contiene relazioni organizzative, permessi, SOP, documentazione, chat interne, regole operative, stato dei clienti. Un brand contiene informazioni di prodotto, linee guida visive, asset storici, dati sulle campagne, vincoli di canale.

Queste informazioni non compaiono automaticamente passando a un modello più potente.

Quindi Qoder realizza Repo Wiki, Memory e Knowledge Cards per il repository di codice; QwenWork punta sul contesto aziendale (Enterprise Context); OpenSearch insiste invece su memoria a lungo termine, memoria di task e compressione del contesto. Tutti quanti stanno cercando di risolvere lo stesso problema: evitare che l’agente debba ogni volta capire il mondo partendo da zero.

Questo significa anche che le tanto amate Prompt Library, in cui molti team hanno investito finora, nel lungo periodo potrebbero valere molto meno di quanto si pensi. Il Prompt è più che altro la modalità di invocazione di un singolo task; ciò che davvero accumula valore nel tempo è il contesto di business, lo storico delle decisioni, i risultati di validazione, le cause dei fallimenti e le skill riutilizzabili.

4. L’unità competitiva dei prodotti AI si sposta da “una singola funzione” al “lavoro completo”

WonderClip mi ha colpito in modo particolare.

Se ci si limita a guardare l’elenco delle capacità, molte non sono una novità: generazione di immagini, generazione di video, traduzione, doppiaggio, sostituzione di materiali, produzione in batch. Prese singolarmente, ognuna di queste funzioni può essere facilmente replicata e assorbita dai modelli, dai software di editing o da altri SaaS.

Ma la struttura di prodotto che hanno mostrato dal vivo sta già evolvendo verso un sistema di produzione più completo:

Carica lo script → Esamina il breakdown → Prepara gli asset → Genera in blocco

Seguono poi Storyboard, Canvas, competenze personalizzate, asset condivisi, collaborazione in team e gestione delle versioni. Il prodotto reinserisce la “generazione” al centro del workflow.

Da qui arriva un’indicazione diretta per chi realizza applicazioni di AI.

Se il nucleo di un prodotto resta “carica qualcosa, l’AI lo lavora, scarica il risultato”, il prossimo salto di modello rischia di eroderne il valore in un colpo solo. La direzione più solida è presidiare l’intero lavoro che l’utente deve portare a termine, dall’inizio alla fine.

Prendiamo lo scenario dei contenuti nell’e-commerce: cambiare singolarmente il prodotto, lo sfondo, la lingua o il voice-over resta un intervento superficiale. Salendo di un livello, l’oggetto del prodotto dovrebbe diventare progressivamente il brand, lo SKU, la campagna, il mercato, la strategia creativa, le varianti di asset, i canali di distribuzione e le performance di campagna. La generazione è solo l’esecutore: il vero valore risiede nell’intero Creative Operations Workflow.

5. Gli agent (Agent) stanno passando dal “rispondere alle domande” al “completare i task”

Ascoltando oggi la presentazione sulla ricerca agent-based di Alibaba Cloud OpenSearch, mi ha colpito una slide sull’evoluzione del search che vale la pena riprendere.

Nella prima fase la ricerca risolveva il passaggio da Query a Results. L’AI generativa ha fatto un passo avanti, portando da Question ad Answer. La ricerca ad agenti spinge oltre l’asticella: da Goal ad Action.

Cambia, di fatto, il posizionamento stesso della ricerca.

In prospettiva, un Research Agent potrebbe scomporre in autonomia un quesito, generare un piano di query, interrogare fonti diverse, fare retrieval aggiuntivo, incrociare le evidenze, arrivare a conclusioni intermedie e poi chiamare altri tool per proseguire. L’interfaccia di ricerca, l’API, diventa sempre più simile a un’infrastruttura attraverso cui l’agente recupera contesto esterno.

Questo cambia anche il modo in cui si osservano SEO e GEO. Prima si guardavano Impression, Click e Ranking. Adesso entrano in gioco nuove metriche: AI Visibility, Citation, Mention, AI Referral, e soprattutto la domanda se quei flussi si traducono poi in Signup, Paid e Retention.

La ricerca non scompare: viene inglobata in un loop operativo più ampio.

VI. La vera sfida dell’AI enterprise entra nel vivo a livello organizzativo

Al congresso si è parlato molto delle questioni tecniche dell’AI in azienda: dati, permessi, sicurezza, governance, accesso ai modelli, architettura cloud, piattaforme Agent.

Tutti temi rilevanti. Ma dopo aver ascoltato alcuni casi reali, la domanda che mi interessa di più è un’altra:

Chi ha davvero un incentivo a usarla?

Ipotizziamo che un dipendente usi l’AI e riduca un’attività da 8 ore a 5. Cosa succede delle 3 ore risparmiate? Se la risposta è semplicemente “diamogli altro lavoro da fare”, è probabile che la spinta spontanea del dipendente verso l’AI resti molto debole.

Facciamo un altro esempio: se il KPI del team AI è il numero di Agent messi in produzione e il volume di invocazioni, il team avrà tutto l’interesse ad aggiungere continuamente funzionalità; il team di business si accolla i costi del ridisegno dei processi; IT e security si assumono il rischio di eventuali errori; il delta di ricavi, alla fine, non è riconducibile in modo chiaro a un’unica causa. In una struttura organizzativa del genere, anche quando la tecnologia è pronta, l’adozione rischia di procedere lentissima.

L’AI enterprise non si giudica solo sull’Architecture: è l’Incentive Design il vero tetto.

I problemi tecnici si risolvono con il budget. Quelli organizzativi, anche con il budget, non è detto che si risolvano. In ogni progetto occorre chiarire almeno sei aspetti: ruolo (Role), indicatori di performance (KPI), benefici (Benefit), costi (Cost), rischi (Risk) e diritti decisionali (Decision Right). Chi ottiene i benefici, sostiene i rischi; chi detiene il diritto decisionale, si assume la responsabilità dei risultati.

Spesso i cosiddetti “problemi di adozione dell’AI” si rivelano, alla fine, problemi di design organizzativo.

7. Gli indicatori più fuorvianti sono spesso quelli che sembrano più intuitivi

Una slide di Qoder (coding assistant) mi è rimasta impressa:

Generation rate is a vanity metric.

Nella presentazione hanno messo a confronto la quota di codice generato dall’AI nelle diverse fasi, sottolineando che il ciclo di consegna del software (Delivery Cycle) non si è ridotto nella stessa proporzione. I numeri specifici arrivano da un caso reale mostrato dal vendor e non possono essere presi come benchmark di settore, ma la logica di fondo regge.

Quando l’IA riduce il costo della scrittura di codice (Coding), il collo di bottiglia si sposta verso i requisiti (Requirement), il contesto (Context), l’architettura (Architecture), la revisione (Review), il testing (Test), l’integrazione (Integration), il deployment (Deployment) e la validazione (Validation).

Perciò metriche come il tasso di generazione di codice, il numero di token, il numero di agenti, le invocazioni di API o le immagini generate possono diventare indicatori locali di efficienza. Ciò che conta davvero è il risultato end-to-end: il Lead Time si è accorciato? I Human Minutes sono diminuiti? Il First-pass Acceptance Rate è salito? Il Cost per Accepted Task è sceso? E, soprattutto, sono cambiati gli indicatori di business finali?

Questa conferenza mi ha ricordato una cosa: non lasciarsi abbagliare da “quanto ha fatto l’IA”, ma guardare a “cosa è cambiato nell’intero sistema”.

Otto. La conferenza propone scommesse, ma la discrezionalità decisionale resta nelle proprie mani

La trappola più comune quando si partecipa a una conferenza è che il mondo esterno inizi a decidere le nostre priorità al posto nostro.

Se un argomento viene citato spesso sul palco, si finisce per pensare di doverlo studiare; se un grande player investe molto in una direzione, si sente il bisogno di seguirlo; se un prodotto sembra avanzato, si pensa di doverne costruire uno anche per sé.

Nota di traduzione: ho mantenuto i termini tecnici inglesi (Lead Time, Human Minutes, First-pass Acceptance Rate, Cost per Accepted Task, Coding, Review, Testing, Deployment) perché ormai ampiamente adottati anche nella letteratura tecnica italiana. Il numero di sezione “八” è stato reso con “Otto”.

Questa volta preferisco riportare tutte queste informazioni dentro una domanda più semplice:

Quali delle mie Decisioni cambieranno, in forza di questa informazione?

Se mi fa solo pensare «che interessante», resta un input.

Se mi fa invece riconsiderare se costruire (Build), comprare (Buy) o ignorare (Ignore); se mi sposta i confini del prodotto; se mi fa interrompere un investimento a basso valore; se mi fa riprogettare un flusso di lavoro; o se mi fa ridefinire una metrica sperimentale — allora è davvero entrata nel processo decisionale.

La Apsara Conference (la conferenza annuale di Alibaba Cloud) non è la risposta.

È piuttosto una mappa delle scommesse del settore. Una mappa che ti dice dove si stanno dirigendo gli altri, quali strade iniziano a congestionarsi, quali infrastrutture stanno prendendo forma, quali problemi stanno diventando prodotti su larga scala.

Quale strada intraprendere, alla fine, va riportata ai propri obiettivi, vincoli, risorse ed evidenze.

È anche ciò che voglio portarmi a casa da una conferenza tecnologica: vedere più scommesse, mantenendo però il potere decisionale nelle mie mani.

Stai valutando dove far entrare l’AI in azienda, quali direzioni meritano un investimento, quali sono solo bolle gonfiate dalla narrazione? Parliamone. Lavoriamo come consulenti specializzati nella trasformazione AI in impresa — dalla selezione tecnologica al design organizzativo fino ai sistemi di misurazione — per trasformare «il fermento delle conferenze» in «scelte che sai sostenere». Email di contatto: [email protected].

Approfondimento: «Il Framework di Trasformazione AI in Sette Passi», che illustra sistematicamente il percorso completo di adozione dell’AI in azienda.

Su questa serie

Imparare l’AI con calma — una serie di approfondimenti per CIO e decision maker che vogliono leggere l’AI con lucidità, oltre la narrativa.

「Osservazioni da Yunqi」 è la serie di IAIUSE dedicata al campo industriale: a partire dall’Apsara Conference 2026, analizza con lo sguardo del ricercatore i cambiamenti reali in corso nell’industria dell’AI — niente inseguimento di hype, solo le direzioni su cui si scommette e la solidità delle evidenze.

La serie affronta il system layer sopra i modelli, l’adozione degli Agent, gli asset di Context, il design organizzativo per l’AI in azienda e lo spostamento dell’unità competitiva nei prodotti AI — circa dieci articoli in totale.

Ho quasi otto anni di esperienza in consulenza per grandi imprese e in business analysis, con un passato in IBM su progetti in telecomunicazioni, finanza, assicurazioni e manufacturing. Successivamente ho continuato a lavorare in prima linea su prodotti telco, prodotti internet e sviluppo di applicazioni AI, occupandomi di analisi dei requisiti, product design e delivery cross-team. Le valutazioni di questa serie nascono dalla mia osservazione sul campo e da una verifica incrociata con l’industria: portano una posizione d’autore esplicita e non rappresentano la visione di alcun vendor.