Tuttavia, mentre molti hanno potuto usare deep research a livello individuale per cercare e sintetizzare informazioni online, pochi ne hanno beneficiato in ambito aziendale. Non perché non sarebbe utile, anzi, ma per timori più ampi relativi all’affidabilità, alla frammentazione delle fonti di dati e alla capacità di un modello di gestire grandi quantità di contesto, per esempio moltissimi file di tipi diversi.
La nostra esperienza nella creazione di strumenti di deep research di livello aziendale negli ultimi 12 mesi dimostra che una progettazione attenta può mitigare sempre più queste criticità. In questo articolo analizziamo i principali ostacoli alle applicazioni aziendali efficaci di deep research, come li supereremmo e come prevediamo che il settore evolverà nel 2026.
Il limite operativo è aumentato drasticamente. L’arrivo di gpt-5 nell’agosto 2025 ha segnato una svolta per l’IA aziendale. Nei nostri sistemi di produzione, tra cui una piattaforma per l’individuazione di bersagli farmacologici destinata a una delle maggiori aziende farmaceutiche al mondo, le allucinazioni relative alle fonti sono scese dal 3-4% praticamente a zero. A dicembre, gpt-5.2 ha poi esteso ulteriormente la lunghezza effettiva del contesto. Il risultato pratico: ora possiamo passare da centinaia a migliaia di fonti per ogni ricerca, senza sacrificare l’affidabilità. Il collo di bottiglia non è più la capacità del modello, ma è tornato dove dovrebbe essere: nei dati, nelle valutazioni e nella progettazione del programma.
Strategia dei dati: meglio accessibili che unificati. È comprensibile voler trattare l’IA aziendale come un problema di integrazione dei dati, ma spesso è controproducente. L’unificazione completa è lenta, genera attriti politici e impone scelte premature, prima di capire quali domande contino davvero. Nel 2026, la scelta pragmatica è una connettività sparsa. Rendete i dati accessibili tramite punti di riferimento ad alto valore informativo, come specifiche, policy, SKU e clausole contrattuali, invece di attendere anni per unificare tutto. I modelli di frontiera possono ora creare «join flessibili» tra sistemi durante l’inferenza, collegando termini correlati senza mappature formali. Così mantenete la rapidità di implementazione e la flessibilità necessaria per aggiungere altre fonti in seguito.
Una buona navigazione evita di perdersi. I dati aziendali non sono il web. Sono sparsi, ricchi di convenzioni locali e spesso esiste una sola fonte corretta per un determinato fatto. Senza indicazioni, i modelli tendono a eseguire query senza fine per trovare un’ultima fonte, consumando tempo e pazienza degli utenti. Un livello semantico leggero, con mappe hash, ricerche di entità e grafi essenziali delle relazioni, offre al sistema modi rapidi ed economici per raggiungere il contesto giusto. È come il consiglio di un collega esperto a un neoassunto: «Salva questi siti nei preferiti; se hai problemi con AWS, parla con Ross». Non deve essere complicato. Deve solo aiutare il sistema a trovare rapidamente ciò che gli serve.
Meccaniche (eseguite a ogni query): qualità delle citazioni, corretto uso degli strumenti, latenza e costi. Sono le vostre misure di sicurezza: ordinarie, ma essenziali.
Analitiche (eseguite periodicamente): il sistema sceglie gli strumenti giusti, segue direzioni di ricerca sensate, seleziona fonti autorevoli e sa quando fermarsi? In genere, il punteggio viene assegnato con il metodo LLM-as-judge rispetto a esempi etichettati.
Utente (continue): tassi di completamento delle attività, feedback qualitativo degli utenti esperti e analisi dell’utilizzo. La prova decisiva. Abbiamo creato qualcosa che le persone trovano utile?
Il ROI nasce dai problemi difficili, non da quelli facili. Dopo i rapporti secondo cui la maggior parte dei progetti aziendali di IA non genera ROI, la tolleranza verso demo spettacolari che non arrivano in produzione è svanita. I dirigenti vogliono prove, e le vogliono subito. Paradossalmente, questa pressione può spingere i team verso scelte sbagliate. Si è tentati di partire da attività a basso rischio perché sono facili da implementare e difficilmente creano attriti. Ma questi casi d’uso raramente producono un impatto sufficiente a giustificare ulteriori investimenti. I sistemi aziendali di deep research sono nella posizione ideale per dimostrare il proprio valore perché affrontano attività già costose: flussi di lavoro complessi e critici, in cui il costo dello status quo è evidente. I casi d’uso più solidi che abbiamo osservato riguardano la generazione di RFP e offerte, l’analisi del panorama scientifico e la ricerca sugli investimenti: ambiti in cui l’impatto si misura in tassi di successo, tempi più brevi per arrivare alla sperimentazione e rapidità nel maturare una convinzione, non solo in ore risparmiate.
La svolta nella UX: dalla chat alla delega, dalle risposte agli elaborati. Riteniamo che questo sarà uno dei cambiamenti nell’esperienza utente che definiranno il 2026. Esaminando le soluzioni adottate più rapidamente negli ultimi tempi, emergono un paio di aspetti. Con l’aumento dell’affidabilità di questi sistemi, gli utenti hanno iniziato a considerarli meno come chatbot da interrogare e più come analisti a cui delegare il lavoro. Due elementi lo rendono possibile: consentire ai team di personalizzare modelli e criteri di arresto in base ai propri flussi di lavoro, e permettere l’esportazione diretta nel formato realmente necessario, come una nota, una presentazione o un brief, anziché chiedere loro di ricavare un elaborato finale da una conversazione. Quando entrambi sono presenti, il sistema smette di essere uno strumento di consultazione e diventa il modo in cui il lavoro viene svolto.
L’anno scorso abbiamo parlato di come portare deep research nelle aziende. Abbiamo preso il paradigma di deep research incentrato sul web, reso inizialmente popolare da OpenAI, e lo abbiamo esteso alle fonti di dati proprietarie delle aziende senza perdere provenienza né controllo. Abbiamo inoltre sottolineato che i sistemi di deep research non vanno considerati una rottura rispetto ai sistemi RAG più tradizionali, bensì una loro evoluzione.
All’inizio del 2026, ciò che è cambiato non è tanto l’idea di deep research quanto il limite entro cui è possibile operare.
Quando abbiamo iniziato a creare questi sistemi, all’inizio del 2025, i modelli di frontiera includevano o1, gpt-4o e claude-3.5-sonnet. Quanta strada abbiamo fatto in soli 12 mesi… Nei primi mesi dell’anno sono poi arrivati importanti progressi con modelli come o3 e gemini-2.5-pro. Per l’epoca erano eccellenti e consentivano certamente di creare solide applicazioni di deep research, ma solo fino a un certo punto. Il limite si aggirava in genere sulle poche centinaia di fonti; oltre quella soglia era necessario ridurre drasticamente il contesto, altrimenti si ottenevano risposte con perdita di informazioni, un peggioramento nel rispetto delle istruzioni o vere e proprie allucinazioni.
Chi ha creato questi sistemi riconoscerà alcune di queste modalità di errore.
Per fare un esempio concreto: a metà del 2025 abbiamo iniziato a sviluppare una soluzione aziendale di deep research con una delle maggiori aziende farmaceutiche al mondo. Il sistema accelera l’individuazione di bersagli farmacologici, un processo in cui i ricercatori cercano geni, ormoni o altri elementi del corpo umano su cui intervenire per trattare una patologia. All’epoca, il modello più efficace disponibile era o3. Pur offrendo prestazioni elevate, nel 3-4% delle risposte generate il modello citava fonti che non gli erano state fornite tramite chiamate agli strumenti collegate ai dati proprietari del cliente. Abbiamo mitigato il problema con controlli a posteriori delle citazioni, che segnalavano le sezioni delle risposte non supportate dal contesto fornito. Nella fase iniziale di PoC, questo approccio ha consolidato la fiducia degli stakeholder nello strumento e ci ha aiutato a progredire rapidamente. Abbiamo però continuato a lavorare per ridurre questi errori, cercando di mitigare i limiti dei modelli e, al contempo, soddisfare le richieste degli stakeholder di aggiungere altre fonti al sistema.
Una svolta fondamentale per la creazione di soluzioni di deep research di frontiera, e più in generale di soluzioni agentiche, è arrivata con gpt-5 ad agosto. Dopo il passaggio da o3 a gpt-5, le nostre valutazioni hanno mostrato un calo immediato allo 0% del tasso di allucinazioni relative alle fonti.
Per essere precisi, questa metrica rileva esclusivamente se il modello cita l’ID o l’URL di un documento assente dal contesto recuperato. Nell’era di o3 e dei modelli precedenti, a volte i modelli inventavano nomi di file o articoli plausibili per colmare le lacune nelle proprie conoscenze. gpt-5 ci ha permesso di eliminare di fatto questa specifica patologia.
Questo problema è distinto dagli errori di fedeltà, in cui viene citato il documento corretto ma il testo è interpretato male, una difficoltà che continuiamo a gestire tramite i controlli a posteriori descritti sopra.
È stato un enorme passo avanti. Abbiamo quindi iniziato a testare il sistema per capire fino a che punto potessimo spingerlo con la nuova generazione di modelli. Abbiamo scoperto di poter aumentare di circa dieci volte il numero di fonti considerate in una ricerca, arrivando a circa 3.000-5.000. Il limite finale non era il mancato rispetto delle istruzioni, ma le prestazioni sul contesto lungo: la lunghezza effettiva del contesto dei modelli è spesso molto inferiore a quella dichiarata, soprattutto con dati densi come quelli farmaceutici.
Questa limitazione è stata in parte attenuata dal rilascio di gpt-5.2 a metà dicembre. I nostri benchmark interni sul contesto lungo hanno evidenziato un netto miglioramento delle prestazioni effettive, permettendoci di spingere ancora oltre i sistemi di deep research di frontiera. Questo ci ha infine consentito di aumentare il numero di token trasmessi direttamente al modello che produce l’output per l’utente, offrendo così una risposta più ricca. Vorremmo comunque che nel 2026 la lunghezza effettiva del contesto dei modelli di frontiera continuasse ad aumentare.
Grazie a questi progressi nelle capacità di base dei modelli, i colli di bottiglia nella creazione di sistemi di deep research efficaci sono, sotto molti aspetti, tornati dove avrebbero sempre dovuto essere: nei dati, nelle valutazioni e nel modo in cui il programma di deep research viene strutturato in azienda. Ognuno di questi passaggi richiede decisioni pragmatiche su ciò che produce un impatto concreto nella creazione di un sistema di deep research.
Il resto dell’articolo illustra il nostro approccio a queste decisioni.
Si può essere tentati di trattare i progetti di ricerca aziendale come un problema di integrazione dei dati. Unificare le fonti, normalizzare lo schema e lasciare che i modelli lavorino sui dati.
E, sia chiaro, a volte è esattamente la scelta giusta. Se operate in un ambito in cui le entità principali sono stabili, le query sono ripetibili e l’obiettivo finale è industrializzare il flusso di lavoro, l’unificazione può produrre benefici concreti. I casi classici includono l’unione dei dati su clienti e ricavi, i dati sui prezzi di mercato o qualsiasi attività che richieda report affidabili tra più sistemi.
Nella pratica, però, oggi i leader più innovativi cercano qualcosa di diverso nei sistemi aziendali di deep research.
Con la crescente attenzione al ROI della spesa per l’IA, un obiettivo fondamentale per chi prende decisioni è dimostrare rapidamente il valore nella complessa realtà operativa dell’azienda. L’unificazione completa delle fonti di dati è uno dei modi più lenti per arrivare a questa prima prova. È onerosa. Genera attriti politici. E spesso costringe a scegliere una direzione prima di aver capito quali domande contino davvero.
Riteniamo quindi che, nel 2026, il punto di partenza pragmatico per creare sistemi di deep research di frontiera sia solitamente questo: rendere i dati accessibili prima di renderli perfetti.
Se è realistico prevedere l’aggiunta di altre fonti nel tempo, come accade nella maggior parte delle aziende, le connessioni più sparse sono sottovalutate. Potete esporre decine di fonti tramite un’interfaccia di recupero uniforme. Il sistema sarà comunque in grado di funzionare e, soprattutto, manterrete la capacità di fornire risultati rapidamente. Quando dovrete aggiungere altre fonti, non sarà necessario rivoluzionare tutto. Basterà collegare un nuovo connettore, spiegare al sistema centrale di cosa si tratta e come usarlo, quindi lasciare che i modelli facciano il resto. Questo funziona perché oggi i modelli di frontiera possono creare join flessibili tra due o più fonti di dati durante l’inferenza, collegando «Customer ID» in un sistema a «Client Reference» in un altro, senza che nessuno debba scrivere una mappatura formale. Non siamo l’unico team a pensarla così. Non siamo l’unico team a pensarla così: l’agente interno di OpenAI per i dati è progettato per consentire ai modelli di ragionare su 70.000 set di dati eterogenei, rendendo accessibili contesto e connessioni al momento della query anziché imporre una completa unificazione preliminare.
Vale la pena chiarire una sfumatura: «sparso» non significa necessariamente «superficiale».
L’integrazione sparsa funziona meglio quando le connessioni create sono significative ed espresse in modo che il sistema possa sfruttarle facilmente. Un buon approccio consiste nel trattare alcune informazioni come punti di riferimento: specifiche, policy, definizioni di prodotto, SKU, clausole contrattuali e simili. Non occorre unificare ogni set di dati per rendere efficaci questi punti di riferimento: basta un identificatore stabile con alcune relazioni ad alto valore informativo.
Immaginate, per esempio, che un modello o un utente cerchi una specifica. In un sistema elementare, l’interazione finisce qui. Si recupera la specifica, la si riassume e magari la si cita. Quando progettiamo strutture di dati utili, invece, vogliamo trasformare quella ricerca nell’inizio di un’espansione controllata. Potremmo, per esempio, collegare facoltativamente il record della specifica a elaborati storicamente pertinenti. Qui «pertinente» può assumere vari significati, ma in genere dipende dall’attività svolta dal sistema e può includere RFP che citavano la specifica, risposte precedenti che hanno vinto gare basate su quella specifica, modifiche richieste dall’ufficio legale e così via. Questo approccio può migliorare enormemente la qualità delle risposte e la latenza, facendo emergere rapidamente le informazioni più importanti per il sistema di deep research al momento della query.
Questo introduce la domanda successiva: una volta creato un mondo di fonti di dati collegate in modo sparso da poche relazioni ad alto valore informativo, come si evita che il sistema di deep research vaghi come un bambino in un negozio di dolci e lo si induce invece a orientarsi come un analista esperto?
Le fonti di dati aziendali non si comportano come il web. Sono sparse, ricche di convenzioni locali e spesso hanno una sola fonte «corretta» per un determinato fatto, ammesso che si riesca a trovarla. Inoltre, oggi i modelli tendono a cercare sempre di massimizzare il richiamo nelle domande di ricerca, eseguendo spesso molte query per trovare un’ultima fonte e consumando tempo e pazienza degli utenti. Un prompting accurato può mitigare in parte il problema.
La soluzione più efficace è uno strumento leggero che aiuti il modello a orientarsi nel disordinato panorama dei dati aziendali. Alcuni team lo chiamano ontologia. Altri lo chiamano livello semantico, servizio di ricerca, grafo o archivio di concetti. Il nome non conta davvero.
Ciò che conta è che offra al sistema una serie di passaggi rapidi ed economici, consentendo al modello di muoversi in modo efficiente tra le parti giuste del contesto anziché vagare apparentemente all’infinito.
Una semplice metafora è quella di chi è appena entrato in un’azienda o in un nuovo progetto e si sente dire dai colleghi: «Devi salvare questi siti nei preferiti, li userai sempre» oppure «Ogni volta che hai un problema con AWS, parla con Ross: ti darà le informazioni che ti servono», e così via. Allo stesso modo, qui cerchiamo semplicemente di aiutare il sistema di deep research a trovare rapidamente ciò che gli serve.
In pratica, questo sistema non deve essere complicato né gestito manualmente. Le implementazioni migliori che abbiamo trovato vengono generate dagli LLM durante la pipeline di acquisizione, estraendo entità per popolare automaticamente il grafo, oppure sono semplici collegamenti a sistemi di registrazione esistenti, come una ricerca tramite l’API di Salesforce. Alcuni esempi comuni includono:
Ricerche in mappe hash, per esempio interrogare con il nome del prodotto e restituirne la descrizione
Una ricerca essenziale delle relazioni «comuni», per esempio le malattie più frequentemente associate a un gene nel nostro grafo delle relazioni causali tra geni
Modelli di riconoscimento delle entità denominate, utili soprattutto in ambiti con problemi complessi di disambiguazione, come il settore farmaceutico
Per le relazioni tra dati più complesse, grafi RDF leggeri possono offrire la soluzione più estensibile per un’ontologia
… e altro ancora
Una volta predisposto tutto questo, il sistema può muoversi in modo efficiente tra le fonti di dati. La domanda successiva è semplice: come si verifica che faccia sempre la cosa giusta durante l’utilizzo reale?
Ora che i dati sono accessibili e il livello di navigazione fornisce una mappa, il sistema è in grado di svolgere il lavoro. Ma in un contesto aziendale, la capacità non vale nulla senza affidabilità.
È qui che si trova il più grande cimitero di progetti di IA. Molti team sono caduti nella trappola delle valutazioni «a sensazione». Eseguivano una query, leggevano l’output, annuivano soddisfatti e lo distribuivano. Questo approccio non funziona quando si crea un sistema di deep research che potrebbe analizzare autonomamente 5.000 documenti per formulare una raccomandazione su una decisione multimilionaria relativa alla catena di approvvigionamento.
Il cambiamento fondamentale è che non si valuta più un modello, ma un sistema. Interpretazione delle domande, pianificazione, chiamata degli strumenti, interpretazione, selezione del contesto, riordinamento dei risultati e persino dettagli apparentemente banali dei connettori, come i timestamp, incidono tutti sull’esperienza utente.
Valutazioni strutturate e ripetibili ci aiutano a risolvere questi problemi.
Nel definire le valutazioni, possiamo suddividerle a grandi linee in tre categorie, da quelle meccaniche a quelle soggettive.
È la parte più simile ai test unitari e spesso quella in cui i team possono progredire più rapidamente nelle fasi iniziali. In genere sono anche le valutazioni più stabili nel tempo: una volta configurate, continuano a produrre benefici per l’intera durata del progetto.
Le «valutazioni meccaniche» sono generalmente controlli eseguibili a ogni query senza intervento umano. Ci aiutano ad acquisire fiducia nel comportamento prevedibile e sicuro del sistema con carichi di utenti reali.
Ecco alcuni esempi:
Qualità delle citazioni: tutte le citazioni rimandano a passaggi effettivamente recuperati? Ci sono affermazioni prive di citazioni? Ci sono affermazioni non supportate dal materiale di partenza? Le citazioni sono troppo generiche, per esempio un intero documento citato a sostegno di una sola affermazione?
Corretto uso degli strumenti: il sistema ha usato tutti gli strumenti che dichiara di aver usato? Ha usato correttamente gli strumenti di navigazione? Ha formattato in modo errato qualche richiesta agli strumenti? In caso di errore, ha riprovato in modo sensato?
Limiti di latenza e costo: ha rispettato il tempo obiettivo per il primo token? Ha superato il numero previsto di chiamate agli strumenti o il budget? Ha consumato molta latenza e capacità di calcolo per un miglioramento marginale?
Sembrano aspetti banali, ma sono proprio i test che impediscono a un sistema aziendale di deteriorarsi.
Come esempio concreto, nel progetto di deep research per l’individuazione di bersagli farmacologici abbiamo adottato due livelli di controllo delle citazioni, eseguiti a ogni query. Innanzitutto, durante la generazione di una risposta, chiediamo al modello di produrre frequenti citazioni nel testo. Anche la capacità degli LLM di farlo in modo affidabile è relativamente recente: si è affermata nella prima metà del 2025. Chiunque abbia provato prima a farlo con quantità significative di dati sa quanto fosse difficile. Possiamo così eseguire semplici controlli tramite espressioni regolari per verificare, per esempio, se viene menzionato il link a un articolo assente dalle fonti fornite.
Il secondo livello di controlli viene eseguito a posteriori, dopo lo streaming della risposta. La risposta viene prima suddivisa in blocchi, poi ciascun blocco viene valutato cercando nei dati recuperati fonti che supportino le affermazioni in esso contenute. Se non vengono trovate prove a sostegno, il caso viene segnalato come possibile allucinazione.
Se le valutazioni meccaniche sono i test unitari, quelle analitiche sono la revisione del codice.
Qui cerchiamo di capire se il sistema svolge bene il lavoro. In genere vogliamo capire, tra le altre cose, se usa gli strumenti corretti, segue le giuste direzioni di ricerca, sceglie le fonti più autorevoli e sa quando fermarsi.
In pratica, assumono solitamente la forma di una serie di coppie domanda-risposta (D-R), per le quali sono noti, per esempio, ordini sensati di chiamata degli strumenti o la decisione corretta da prendere sulla base delle ricerche ottenute dal primo strumento. È importante notare che le coppie D-R non devono corrispondere uno a uno all’input e all’output dell’intero sistema di deep research: questi metodi consentono anche di testare i sottoprocessi. Con queste etichette, generate da una persona o da un modello di etichettatura efficace, dove «efficace» è relativo, possiamo usare il metodo LLM-as-judge per assegnare un punteggio alle ricerche e valutarne le prestazioni. Monitorando questi punteggi nel tempo, possiamo capire se le modifiche migliorano il sistema nella direzione desiderata o introducono regressioni delle prestazioni.
Dato il maggiore costo economico e temporale di queste esecuzioni, in genere vanno effettuate periodicamente, a intervalli prestabiliti o prima degli aggiornamenti di versione.
C’è anche un interessante vantaggio indiretto: queste valutazioni analitiche possono orientare direttamente i miglioramenti delle connessioni sparse descritte in precedenza. Se notate che il modello compie ripetutamente lo stesso collegamento di qualità, per esempio «specifica → esempi di RFP storicamente pertinenti», anche quando oggi le persone non collegano esplicitamente questi elaborati, è un’informazione utile. Potete trasformare quel collegamento in una relazione o scorciatoia di primo livello, così le esecuzioni future beneficeranno di minore latenza e maggiore coerenza.
È anche qui che si individua una delle patologie più costose dei sistemi di deep research: la tendenza a massimizzare il richiamo per impostazione predefinita. Un modello può sempre trovare un’altra fonte. La domanda è se debba farlo. Possiamo regolare il modello per rafforzare comportamenti di arresto sensati: il sistema riconosce quando è improbabile che ulteriori recuperi cambino la conclusione e sceglie di fornire una risposta ben supportata e pertinente alla domanda dell’utente.
Le valutazioni meccaniche indicano che il sistema è sicuro. Le valutazioni analitiche indicano che è competente. Le valutazioni degli utenti indicano se è davvero utile.
Questo è un altro ambito in cui molti team inciampano. Creano qualcosa di tecnicamente straordinario che nessuno vuole usare una seconda volta. In un contesto aziendale, è la differenza tra un’implementazione riuscita e un costoso progetto di ricerca.
Le valutazioni degli utenti servono essenzialmente a capire se il sistema risolve il problema giusto nel modo giusto. Significa andare oltre «ha dato la risposta corretta?» e chiedere «mi ha dato qualcosa su cui posso agire?»
In pratica, le valutazioni degli utenti assumono generalmente alcune forme:
Studi sul completamento delle attività: gli utenti riescono davvero a svolgere il proprio lavoro più rapidamente o meglio con il sistema? Non si tratta di stabilire se il modello potrebbe rispondere a una domanda, ma se un utente reale, nel proprio flusso di lavoro, ha ottenuto ciò che gli serviva.
Cicli di feedback qualitativo: conversazioni strutturate e periodiche con gli utenti esperti. Quali query eseguono ripetutamente? In quali momenti perdono fiducia? Quando rinunciano e tornano al vecchio metodo? Queste sessioni rivelano spesso modalità di errore che non compaiono mai nei set di test, perché gli utenti pongono domande in modi imprevisti o applicano criteri di qualità impliciti di cui non conoscevate l’esistenza.
Analisi dell’utilizzo: quali query vengono eseguite di nuovo? Quali risposte vengono copiate e usate altrove? Dove fanno clic sul pollice verso? Un calo dell’utilizzo non indica sempre un fallimento, perché talvolta gli utenti ottengono la risposta e proseguono. Tuttavia, le modalità e i momenti in cui abbandonano le query rivelano molto sulle aspettative che il sistema non soddisfa.
Nel complesso, questi elementi consentono di misurare l’utilità senza affidarsi alle supposizioni e aiutano a individuare i problemi prima che compromettano la fiducia degli utenti.
Tuttavia, anche un sistema perfetto nell’accuratezza meccanica e apprezzato dai primi utenti può fallire la prova decisiva: aumentare il fatturato dell’azienda. Affidabilità e soddisfazione degli utenti sono soltanto prerequisiti. Per superare il divario tra un progetto pilota riuscito e una risorsa aziendale trasformativa, bisogna guardare oltre il funzionamento del sistema e concentrarsi su dove viene applicato.
Abbiamo spiegato come mettere i dati al servizio del sistema e poi il sistema al servizio degli utenti. Ora dobbiamo parlare di come mettere questo sistema al servizio dell’azienda.
Di recente i leader aziendali si sono concentrati intensamente su questo aspetto, e a ragione. Dopo rapporti come l’affermazione del MIT secondo cui il 95% dei progetti aziendali di IA non genera ROI, la tolleranza verso demo spettacolari che non arrivano in produzione è svanita. I modelli sono pronti. Le architetture sono collaudate. La domanda ora è: riuscite davvero a implementare tutto questo in modo da creare valore per l’azienda?
La buona notizia è che i sistemi di deep research di frontiera, costruiti sui principi descritti sopra, sono nella posizione ideale per superare questa soglia. Non cercano di automatizzare tutto o sostituire intere funzioni professionali. Cercano di rendere le persone migliori molto più efficaci nel lavoro di alto valore che già svolgono.
Ma per passare da «tecnicamente funzionante» a «capace di generare ROI» servono altri fattori abilitanti: scelte organizzative, di esperienza utente (UX) e di misurazione che determinano se diventerà uno strumento quotidiano o una scheda dimenticata.
In base alla nostra esperienza, sono due.
Spesso si è tentati di iniziare con attività interne a basso rischio, come “summarise this meeting”. Sebbene sicuri, questi casi d’uso raramente dimostrano un valore sufficiente a giustificarne il costo.
I sistemi di deep research funzionano meglio quando affrontano attività grandi e difficili: problemi costosi in cui un miglioramento della qualità o della velocità produce un aumento dimostrabile dei ricavi o un vantaggio strategico.
Osserviamo il ROI più elevato quando le aziende puntano su ambiti come:
Generazione di offerte complesse e RFP: i sistemi di deep research possono recuperare automaticamente i successi storici più simili, e anche gli insuccessi, estrarre le clausole che provocano sempre modifiche, trovare le prove più solide per un determinato requisito e altro ancora, per poi trasformare il tutto in un posizionamento solido e coerente per la gara. Il parametro non è il tempo risparmiato, ma il tasso di successo, la tutela dei margini e la riduzione delle sorprese legali o commerciali nelle fasi finali.
Analisi del panorama scientifico: nelle organizzazioni ad alta intensità di R&S, come farmaceutica, biotecnologie e semiconduttori, il punto d’ingresso consiste nel condensare settimane di letteratura e conoscenze interne in una direzione di ricerca utilizzabile. Un sistema di deep research può esaminare migliaia di articoli, brevetti, rapporti interni, appunti di laboratorio e precedenti revisioni dei programmi per mappare ciò che è noto e ciò che è controverso, producendo un quadro fondato sulle prove. Può così accelerare i cicli di iterazione, ridurre le strade senza sbocco e, soprattutto, abbreviare i tempi per la prima sperimentazione sull’uomo.
Analisi di mercato: per banche e hedge fund, il valore sta nel trasformare ricerche interne frammentate, come note, modelli, trascrizioni e commenti dei broker, insieme a segnali esterni, come documenti ufficiali, risultati, dati macroeconomici e notizie, in supporto operativo di qualità decisionale. Un sistema di deep research può creare e aggiornare continuamente una visione di un’azienda, un tema o una questione macroeconomica, evidenziare i cambiamenti chiave rispetto alla settimana precedente, riconciliare fonti contrastanti e produrre una nota d’investimento o un dossier operativo con provenienza completa.
Il filo conduttore è che non si tratta di chat. Sono flussi di lavoro complessi che in genere richiedono costosi consulenti esterni o settimane di lavoro del personale senior. Quando un sistema di deep research viene applicato a questi problemi, il valore è innegabile.
Questo sarà uno dei cambiamenti nell’esperienza utente che definiranno il 2026.
Se il sistema di deep research è semplicemente un chatbot che gli utenti interrogano per trovare informazioni, può rapidamente finire per essere usato solo sporadicamente. Rimane uno strumento di consultazione e spetta comunque agli utenti assemblarne gli output per ottenere il risultato finale desiderato. Se invece sembra un analista sempre disponibile a cui assegnare attività, può cambiare completamente il modello operativo del team.
Stiamo osservando il passaggio dalla «chat», fatta di brevi scambi, alla delega: definire ambito, modello e obiettivo, quindi lasciare lavorare il sistema.
Tre cambiamenti specifici lo rendono possibile:
Output come elaborati: il lavoro di alto valore raramente vive in una finestra di chat; vive in documenti, note e presentazioni. I moderni sistemi di deep research dovrebbero saltare la fase della chat e generare direttamente l’elaborato aziendale finale. Quando un utente può chiedere “3-page investment memo in our corporate format” e ricevere un file scaricabile anziché un flusso di testo, il tempo necessario per ottenere valore diminuisce drasticamente. Spesso questo approccio viene esteso alle generazioni pianificate: gli utenti possono richiedere che email o rapporti vengano creati automaticamente con nuove analisi e distribuiti alle parti interessate quando emergono nuovi dati.
Ottimizzazione locale tramite modelli personalizzati: i modelli sono diventati abbastanza robusti da consentire alle unità aziendali o persino ai singoli utenti di definire prompt e comportamenti senza compromettere il sistema. Un rapporto sui rischi ha un aspetto diverso a Londra rispetto a New York. Consentendo ai team di caricare o progettare modelli strutturali, definire criteri di arresto, per esempio “always check these three specific internal databases”, e scegliere il formato di output, gli utenti possono ottenere molto più valore dal sistema e creare qualcosa che desiderano usare sempre più spesso.
La fiducia come interfaccia: quando un utente delega un’attività che richiede oltre 20 minuti, la fiducia diventa una priorità. Non si può presentare una scatola nera. L’interfaccia deve rendere visibili il ragionamento e le scelte del sistema, mostrando quali strumenti vengono usati, generando citazioni e altro ancora. Spesso la UX migliore per questi sistemi mostra per impostazione predefinita informazioni generali sull’avanzamento della ricerca e permette all’utente di approfondire espandendo una barra laterale o un elemento simile.
Immaginiamo un futuro in cui ogni azienda leader disponga di un sistema di deep research su misura a supporto dei flussi di lavoro più critici. Assumerà la forma di una serie di analisti sempre operativi, capaci di esaminare in modo affidabile migliaia di elaborati interni e produrre decisioni e risultati concreti su cui agire. Mentre i modelli di frontiera innalzano il limite operativo, il fattore distintivo si sposta sui fondamentali: rendere accessibili i dati, fornire al sistema una mappa e rendere operativa l’affidabilità tramite valutazioni.
I progressi osservati nell’ultimo anno nelle capacità dei modelli sono il segnale più chiaro della direzione intrapresa. Nel 2026, l’opportunità per i leader consiste nell’agire in anticipo. Scegliete un punto d’ingresso dal valore evidente, conquistate la fiducia con provenienza e misure di sicurezza e trasformate la soluzione aziendale di deep research da progetto pilota a capacità cumulativa usata ogni giorno dall’azienda.