Jefferies punta su Amazon AWS, ma il suo assistente AI per il trading deve ancora conquistare la fiducia dei trader

Jefferies ha implementato un assistente per il trading di Amazon AWS che consente ai trader azionari di interrogare milioni di righe di dati senza scrivere codice. L'annuncio del 23 luglio segna il passaggio da dashboard fisse a un agente che interpreta le domande, crea SQL, seleziona le fonti di dati e presenta i risultati. Il conflitto è altrettanto evidente: una maggiore autonomia offre ai trader un accesso più rapido, ma aumenta anche il costo di ogni query imprecisa.

Il sistema utilizza Amazon Bedrock, Anthropic Claude, Amazon Bedrock Knowledge Bases, Strands Agents e Model Context Protocol. Si collega a repository di operazioni, file di messaggi Financial Information Exchange, database in memoria e archivi storici. Jefferies afferma che l'assistente riduce il lavoro sulle dashboard offrendo al contempo ai trader accesso conversazionale ad analisi in tempo reale.

Si tratta di una scommessa operativa più ampia rispetto all'aggiunta di un chatbot a un'applicazione esistente. Gli strumenti tradizionali di business intelligence mantengono analisti e team IT all'interno del flusso di lavoro. Jefferies sta spostando parte di quel flusso in un software che decide come interpretare una domanda e dove eseguirla. Il confronto è ora tra analisi fisse realizzate da specialisti e analisi governate, guidate da agenti.

Jefferies ha portato l'assistente per il trading nel flusso di lavoro del front office

Il cambiamento importante non è soltanto la ricerca conversazionale. Jefferies ha collocato un agente AI tra le domande dei trader e i dati operativi di trading.

Secondo l'architettura dell'assistente per il trading, i trader accedono all'agente tramite un widget integrato in Global Flow Monitor. Quel sistema di business intelligence on-premises fa già parte dell'ambiente di lavoro di Jefferies. L'assistente entra quindi in un'interfaccia familiare anziché chiedere agli utenti di adottare un prodotto di ricerca separato.

Un trader può chiedere una ripartizione dell'attività di trading statunitense per settore. Amazon Bedrock richiama un modello Anthropic Claude per interpretare la richiesta e generare SQL. Il sistema identifica la fonte dati appropriata, esegue la query e restituisce una visualizzazione. Gli utenti possono poi porre domande successive mentre la sessione conserva il contesto conversazionale.

Questo design affronta uno specifico collo di bottiglia del front office. I trader azionari devono esaminare il comportamento dei clienti, le esecuzioni, l'attività di mercato e gli andamenti storici mentre i mercati sono in movimento. Tuttavia, le informazioni sottostanti possono comprendere milioni di righe e diversi sistemi di visualizzazione. Un trader che necessita di una nuova vista dipende spesso da un esperto di dominio o da un team IT per realizzarla.

AWS e Jefferies affermano che in precedenza questo processo richiedeva giorni o settimane. L'assistente per il trading punta a comprimere il ciclo di richiesta, sviluppo e analisi in un'unica conversazione. Non richiede a ogni trader di comprendere gli schemi dei database o di scrivere una query sintatticamente valida.

L'agente lavora inoltre con diverse forme di dati. Può accedere a database strutturati, materiale non strutturato, messaggi FIX e archivi in memoria. FIX è un protocollo standard utilizzato per scambiare informazioni di trading elettronico. I relativi messaggi contengono dettagli che possono aiutare i team a esaminare ordini ed esecuzioni.

Questa ampiezza è importante perché le domande del front office raramente rientrano in un unico database ordinato. Un trader potrebbe iniziare dalle posizioni correnti, confrontarle con l'attività storica e poi esaminare i messaggi di esecuzione. L'assistente espone ogni fonte come strumento separato e consente al modello di scegliere tra tali strumenti.

Il lancio non elimina le dashboard. Jefferies continua a utilizzare un'interfaccia dedicata e componenti di visualizzazione deterministici. Cambia invece chi può avviare nuove analisi e con quale rapidità l'organizzazione può assemblarle.

Questa distinzione separa il progetto da un chatbot generico per il posto di lavoro. L'assistente ha l'autorizzazione per creare ed eseguire query su sistemi sensibili. Il suo valore deriva dall'azione, non soltanto dal riassumere documenti. La stessa capacità crea anche il rischio centrale.

Perché Amazon AWS sta spingendo gli agenti oltre la ricerca dei dipendenti

Amazon AWS utilizza Jefferies per dimostrare che gli agenti aziendali possono operare all'interno di flussi di lavoro regolamentati, non soltanto rispondere a domande a basso rischio.

Amazon Bedrock fornisce accesso gestito ai modelli fondazionali, mentre Strands Agents coordina il ragionamento e le chiamate agli strumenti. Un harness per agenti è un software che fornisce a un modello istruzioni, strumenti, stato della sessione e un ciclo di esecuzione. Trasforma una risposta di un modello linguistico in una sequenza di azioni.

AWS descrive Strands Agents come un SDK open-source guidato dal modello. Gli sviluppatori definiscono un prompt e una raccolta di strumenti, quindi lasciano che il modello selezionato pianifichi quali passaggi eseguire. I team possono anche personalizzare la selezione degli strumenti, la gestione del contesto, la memoria e il comportamento di deployment.

Questo approccio guidato dal modello riduce la quantità di logica di flusso di lavoro che gli sviluppatori devono codificare manualmente. In un'applicazione convenzionale, gli ingegneri anticipano ogni richiesta supportata e la mappano a un'operazione predefinita. L'agente di Jefferies interpreta invece l'intento dell'utente in fase di esecuzione e sceglie un percorso attraverso gli strumenti disponibili.

Amazon Bedrock Knowledge Bases fornisce un ulteriore livello. Memorizza rappresentazioni incorporate dei metadati dei database, inclusi schemi, definizioni delle colonne, relazioni e pattern di query. La generazione aumentata dal recupero, o RAG, recupera materiale pertinente prima che un modello produca una risposta. In questo caso, il recupero fornisce a Claude il contesto dello schema necessario per creare SQL.

L'architettura affronta un problema comune del text-to-SQL. Un modello può comprendere le parole di una domanda, ma non conoscere comunque le tabelle di un'azienda e le convenzioni interne di denominazione. Il recupero dello schema pertinente restringe le opzioni del modello e gli offre maggiori possibilità di individuare i campi corretti.

Questo approccio rende inoltre Amazon AWS il piano di controllo per diverse componenti in movimento. Bedrock fornisce l'accesso ai modelli, Knowledge Bases gestisce il recupero e Guardrails applica politiche di sicurezza selezionate. Jefferies può modificare i modelli con l'evoluzione dell'applicazione senza ricostruire ogni componente circostante, secondo AWS.

La scelta riflette una competizione più ampia nel cloud. Anche Microsoft Azure e Google Cloud vogliono che le aziende creino agenti vicini ai loro dati esistenti e ai sistemi di identità. L'implementazione di Jefferies offre ad AWS un caso di riferimento che coinvolge dati operativi, infrastruttura on-premises, controlli di accesso e una grande istituzione finanziaria.

Tuttavia, questo non dimostra che un singolo cloud abbia vinto nell'AI per i servizi finanziari. AWS e Jefferies hanno scritto congiuntamente il resoconto e non forniscono benchmark indipendenti. Il caso pubblicato omette inoltre costi di implementazione, tassi di errore dei modelli, numeri di adozione e confronti con piattaforme concorrenti.

La conclusione più solida è più circoscritta. Amazon AWS dispone ora di un esempio dettagliato di un agente che entra in un flusso di lavoro ad alto valore, nel quale velocità, autorizzazione e verificabilità sono tutte importanti. Questo rende il progetto più rilevante di un altro assistente documentale, ancora prima che il suo impatto commerciale possa essere misurato in modo indipendente.

Il vero confronto è tra analisi guidata da agenti e dashboard fisse

Jefferies sta verificando se gli agenti governati possano abbreviare i cicli di analisi senza sacrificare la prevedibilità delle dashboard create da specialisti.

Le dashboard fisse offrono coerenza. Ingegneri e analisti definiscono la fonte dei dati, la logica di trasformazione, i filtri e l'output visivo prima che gli utenti vedano il risultato. Il processo può essere lento, ma i revisori possono ispezionare ciò che fa ciascun componente. Le richieste ripetute producono una vista familiare.

L'analisi guidata da agenti modifica questa relazione. L'utente descrive un obiettivo e il sistema costruisce parte del percorso in fase di esecuzione. Può selezionare un archivio, recuperare informazioni sullo schema, generare SQL, eseguire la query e scegliere una presentazione. Questa flessibilità rende accessibili domande precedentemente non supportate, ma amplia anche il numero di decisioni che richiedono controllo.

Jefferies non ha affidato ogni passaggio al modello linguistico. L'architettura pubblicata colloca il modello all'interno di una catena vincolata. L'autenticazione avviene prima dell'accesso. Un esecutore di query esegue l'SQL. Vengono inseriti filtri per applicare autorizzazioni a livello di riga, che limitano i record in base ai permessi dell'utente.

Il modello inoltre non genera grafici da solo. Jefferies afferma di utilizzare Claude per la comprensione del linguaggio e la generazione di query, mentre un motore di visualizzazione dedicato crea i grafici. Questa divisione limita la possibilità che il modello inventi etichette, valori o relazioni visive dopo che il database ha restituito i risultati.

Questo design ibrido è la decisione tecnica più importante del progetto. Assegna il lavoro probabilistico al modello e mantiene il lavoro deterministico selezionato nel software convenzionale. Il modello può interpretare una richiesta ambigua, ma i sistemi esistenti continuano a controllare autenticazione, esecuzione, accesso e rendering.

Model Context Protocol supporta questa separazione. MCP è un'interfaccia aperta per collegare le applicazioni AI a dati e strumenti esterni. La sua specifica di autorizzazione definisce come i server protetti possano partecipare a flussi di autorizzazione standardizzati.

Jefferies espone ogni fonte dati come uno strumento MCP distinto. Una griglia in memoria può essere uno strumento, mentre un archivio storico o un repository FIX può esserne un altro. L'agente valuta gli strumenti e ne seleziona uno in base alla query.

Questa struttura offre una forma pratica di modularità. I team possono aggiungere una fonte creando un altro strumento invece di ricostruire il flusso di lavoro centrale dell'agente. Ogni connettore può incapsulare la logica specifica della fonte, rendendo anche test e manutenzione più mirati.

Il compromesso è che la modularità non produce automaticamente affidabilità. Il modello può comunque selezionare lo strumento sbagliato, recuperare un contesto di schema fuorviante o creare una query valida che risponde alla domanda aziendale sbagliata. La correttezza SQL non coincide con la correttezza analitica.

Una domanda come “Quali clienti hanno cambiato comportamento oggi?” contiene scelte nascoste. Il sistema deve determinare una finestra di confronto, scegliere una misura del comportamento, gestire attività incomplete e decidere cosa costituisca un cambiamento significativo. Una query può essere eseguita perfettamente pur codificando presupposti non previsti dal trader.

Le dashboard fisse rendono visibili molte di queste ipotesi attraverso definizioni consolidate. L'analisi guidata da agenti deve renderle esplicite durante la conversazione o codificarle in pattern di query controllati. Altrimenti, la velocità può nascondere l'ambiguità anziché risolverla.

Ecco perché il progetto dovrebbe essere giudicato come un'interfaccia decisionale governata, non come un benchmark per chatbot. Il linguaggio naturale è solo il punto di ingresso. Il lavoro più difficile consiste nel controllare ciò che accade dopo che un trader preme Invio.

I guardrail di Amazon AWS riducono il rischio, ma non verificano l'analisi

I controlli dell'assistente possono limitare l'accesso e filtrare i contenuti, ma non possono garantire che ogni query generata rifletta l'intento del trader.

Il resoconto AWS identifica diversi livelli di sicurezza. Amazon Bedrock Guardrails gestisce la moderazione dei contenuti e il filtraggio delle informazioni personali identificabili. Jefferies applica inoltre autorizzazioni a livello di riga e registra le conversazioni per creare tracce di audit.

Questi controlli affrontano diverse modalità di errore. L'autenticazione determina se un utente può accedere al sistema. Le autorizzazioni determinano quali righe di dati quella persona può recuperare. La moderazione filtra contenuti selezionati, mentre la registrazione preserva le evidenze per le indagini e le verifiche di conformità.

I filtri per le informazioni sensibili di Amazon possono bloccare o mascherare le informazioni personali rilevate nei prompt e nelle risposte del modello. AWS descrive questa funzionalità come probabilistica e dipendente dal contesto. La sua documentazione avverte inoltre che il mascheramento non copre ogni luogo in cui possono comparire informazioni.

Ad esempio, la documentazione afferma che il mascheramento dei dati PII si applica agli input e agli output del modello, ma non automaticamente al contenuto originale nei log di invocazione del modello. Anche l'output della traccia dei guardrail può contenere il valore corrispondente. Le aziende necessitano quindi di controlli separati sui log e di politiche di protezione dei dati.

Le chiamate agli strumenti introducono un ulteriore confine. AWS rileva che il filtro per le informazioni sensibili non rileva i dati PII all'interno dei parametri di output dell'uso degli strumenti tramite API supportate. Un agente può essere protetto a livello conversazionale, mentre un connettore o una traccia espone comunque materiale sensibile.

Queste limitazioni non significano che i controlli siano inefficaci. Mostrano perché un guardrail deve essere trattato come uno strato, non come un sistema di conformità completo. L'uso da parte di Jefferies di autorizzazioni, intercettazione delle query e logging di audit riconosce questa distinzione.

L'incertezza maggiore riguarda l'errore analitico. Un filtro dei contenuti può rilevare determinate categorie vietate, ma non sa se “l'attività dei clienti di oggi” utilizza il fuso orario o il benchmark corretto. La sicurezza a livello di riga può impedire accessi non autorizzati, ma non può stabilire se la tabella selezionata risponda alla domanda aziendale.

Anche l'allucinazione assume diverse forme in questo contesto. Il modello potrebbe inventare una colonna che non esiste, cosa che l'esecuzione dovrebbe rifiutare. Potrebbe generare SQL valido sulla colonna sbagliata, un errore più difficile da intercettare. Potrebbe anche restituire un risultato accurato con un'interpretazione in linguaggio naturale eccessivamente assertiva.

Jefferies afferma che la sua Knowledge Base recupera dettagli sullo schema e modelli di query per migliorare l'accuratezza del SQL. Questo dovrebbe ridurre alcuni errori strutturali, ma l'azienda non ha pubblicato un tasso di accuratezza. L'annuncio non fornisce inoltre informazioni sulla frequenza con cui le query richiedono correzioni o escalation umane.

Non esiste nemmeno un benchmark di latenza riportato. AWS afferma che Jefferies ha scelto database in-memory perché i trader necessitano di insight in frazioni di secondo. Tuttavia, il resoconto pubblico non quantifica i tempi di risposta per query semplici, flussi di lavoro multi-sorgente o periodi di domanda elevata.

L'adozione resta un'altra questione aperta. Jefferies afferma che gli utenti si sono comportati in modi inaspettati e hanno modificato i propri schemi nel tempo. Questa osservazione ha portato il team a investire in osservabilità e cicli di feedback, ma l'azienda non ha divulgato quanti trader utilizzino l'assistente.

Il comportamento degli utenti può rivelare debolezze che i test controllati non colgono. I trader possono usare abbreviazioni, omettere assunzioni, porre più domande contemporaneamente o interpretare un grafico ben rifinito come più certo di quanto sia. L'interfaccia deve aiutare gli utenti a riconoscere quando un risultato richiede convalida.

È qui che una base di conoscenza tecnica ricercabile può sostenere la governance oltre il recupero delle informazioni. I team hanno bisogno di registri accessibili di schemi, modelli di query approvati, responsabilità, risultati delle valutazioni e decisioni sugli incidenti. Questi materiali aiutano i revisori a comprendere perché un agente abbia intrapreso un determinato percorso.

La regolamentazione finanziaria aggiunge un ulteriore motivo di cautela. Un assistente per l'analisi delle operazioni non è automaticamente un sistema di raccomandazioni per il mercato retail. Ciononostante, le autorità di regolamentazione hanno sottolineato che l'uso dell'AI non elimina gli obblighi di condotta esistenti. La SEC ha dichiarato che i professionisti degli investimenti restano responsabili di servire gli interessi dei clienti quando gli algoritmi influenzano consulenze o raccomandazioni.

La SEC ha poi ritirato le sue proposte di norme sull'analisi predittiva nel giugno 2025. L'avviso di ritiro affermava che qualsiasi azione futura avrebbe richiesto una nuova proposta. Quel ritiro ha ridotto una specifica incertezza normativa, ma non ha eliminato gli obblighi esistenti in materia di conservazione delle registrazioni, supervisione, privacy o condotta di mercato.

L'architettura di Jefferies sembra progettata tenendo presenti queste realtà. Tuttavia, il materiale pubblicato resta un caso di studio supportato dal fornitore, non un audit. Evidenze indipendenti su accuratezza, falsi rifiuti, prevenzione delle query non autorizzate e incidenti operativi offrirebbero una verifica più chiara.

L'impatto sul business dipende da qualcosa di più di risposte più rapide

Jefferies afferma che l'assistente ha migliorato l'efficienza, ma le evidenze pubbliche non mostrano ancora in che modo questi guadagni incidano sulla performance di trading o sui costi tecnologici.

AWS riferisce che il sistema ha ridotto il lavoro manuale sui dati nelle operazioni globali di sales and trading. Secondo le aziende, i trader possono reindirizzare il proprio tempo verso le relazioni con i clienti e le decisioni strategiche. Anche i team tecnologici dedicano meno impegno alla creazione di dashboard ripetitive.

Questi benefici sono plausibili perché l'assistente punta a una coda misurabile. Ogni dashboard personalizzata richiede lavoro di raccolta dei requisiti, competenze sui dati, tempo di sviluppo, test e manutenzione. Se un trader può rispondere a una domanda ad hoc tramite generazione di SQL governata, alcune richieste non devono mai entrare in quella coda.

Il sistema può anche abbreviare l'analisi esplorativa. Un trader può iniziare con una panoramica ampia di un settore e poi approfondire il risultato attraverso domande successive. Il contesto della sessione conservato riduce la necessità di ripetere filtri e confronti a ogni turno.

Tuttavia, l'efficienza non può essere misurata solo dal numero di dashboard evitate. Jefferies deve anche considerare l'uso dei modelli, l'infrastruttura di recupero, la valutazione, il monitoraggio, le revisioni degli accessi e la risposta agli incidenti. Le query generate possono far risparmiare tempo di sviluppo creando al contempo nuovo lavoro di supervisione.

Il calcolo del valore dipende dalla qualità delle query. Un risultato rapido che necessita di correzioni ripetute non supera necessariamente una dashboard affidabile. Un risultato tecnicamente accurato che i trader utilizzano raramente genera poco ritorno operativo. Il sistema deve migliorare l'intero percorso dalla domanda alla decisione difendibile.

Jefferies deve inoltre distinguere tra vari tipi di utilizzo. Alcune domande sono routinarie e ripetibili, quindi candidate a report consolidati. Altre sono esplorative e traggono vantaggio da un'interfaccia conversazionale. Il miglior modello operativo probabilmente conserverà entrambi i percorsi.

L'annuncio non fornisce metriche finanziarie. Non divulga spese di sviluppo, costi operativi, effetti sui ricavi, cambiamenti nella fidelizzazione dei clienti o ore risparmiate. Non afferma neppure se i trader prendano decisioni migliori dopo aver utilizzato l'assistente.

Questa omissione dovrebbe moderare l'espressione “vantaggio competitivo”. Un accesso più rapido può creare un vantaggio, ma solo se i concorrenti non possono riprodurlo rapidamente o se Jefferies lo integra in modo più efficace. I componenti sottostanti sono disponibili per altri clienti Amazon AWS e MCP riduce alcune barriere all'integrazione.

Il vantaggio proprietario di Jefferies risiede quindi meno nel modello che nei suoi dati, nei modelli di query, nella progettazione dei flussi di lavoro, nei controlli e nell'adozione. I concorrenti possono acquisire in licenza modelli fondazionali simili. Non possono copiare istantaneamente i dati storici dell'istituzione, le definizioni interne, le strutture dei permessi o le abitudini del front office.

Questo schema si applica oltre il settore bancario. Le imprese si concentrano spesso sulla scelta di un modello, anche se la differenziazione operativa deriva da contesto affidabile e azioni controllate. Il modello fornisce capacità di ragionamento generale, mentre l'organizzazione fornisce le informazioni e i confini che rendono utile il sistema.

Il caso Jefferies mostra anche perché l'architettura applicativa conta dopo che la qualità dei modelli migliora. Bedrock permette al team di cambiare modelli nel tempo. MCP isola i connettori dati. Knowledge Bases organizza il contesto dello schema. I servizi deterministici mantengono il controllo su accesso e rendering.

Queste scelte riducono la dipendenza da una singola versione del modello. Non eliminano la dipendenza da Amazon AWS, poiché Bedrock, Knowledge Bases, Guardrails e le future funzionalità di AgentCore rientrano nello stack previsto. Jefferies ottiene flessibilità sui modelli concentrando al contempo una maggiore orchestrazione all'interno di un'unica piattaforma cloud.

Questa concentrazione comporta compromessi familiari alle imprese. Una piattaforma condivisa può semplificare le revisioni di sicurezza e le operazioni. Può anche rendere più costose le migrazioni future se il comportamento dell'applicazione diventa strettamente legato a servizi proprietari.

L'importanza commerciale del progetto dipenderà in ultima analisi da risultati ripetibili. Jefferies necessita di evidenze che i trader ottengano risposte affidabili più rapidamente, che l'IT riceva meno richieste a basso valore e che i team di controllo possano ricostruire le azioni degli agenti. Senza queste misure, l'assistente resta un'architettura impressionante con un business case incompleto.

Cosa osservare mentre Jefferies espande l'assistente per il trading

La prossima prova sarà verificare se Jefferies riuscirà a scalare l'assistente su più desk preservando accuratezza, latenza e decisioni di accesso tracciabili.

Il primo segnale è il previsto lancio globale su prodotti e desk aggiuntivi. Diverse attività di trading utilizzano terminologia, strutture dati, misure di rischio e orizzonti temporali differenti. Un sistema ottimizzato per i flussi di lavoro azionari avrà bisogno di nuovi strumenti, contesto dello schema e valutazioni man mano che il suo ambito si espande.

Un'espansione riuscita rafforzerebbe l'ipotesi di un'architettura di agenti riutilizzabile. Eccezioni persistenti o ricostruzioni specifiche per desk suggerirebbero che i flussi di lavoro finanziari restano più difficili da generalizzare di quanto implichi il design modulare. Jefferies dovrebbe infine divulgare i livelli di adozione e la quota di query completate senza intervento di specialisti.

Il secondo segnale è una migliore auditabilità. Jefferies prevede di potenziare le capacità di audit con strumenti di generazione del codice che utilizzano l'elaborazione del linguaggio naturale. La domanda importante è se i revisori possano ricostruire il contesto recuperato, il SQL generato, lo strumento selezionato, i filtri di accesso iniettati, i dati restituiti e la presentazione finale.

I soli log delle conversazioni sono insufficienti se omettono le decisioni intermedie. Una traccia di audit difendibile deve collegare le parole dell'utente a ciascuna azione rilevante del sistema. Dovrebbe inoltre conservare le versioni del modello e dei prompt, perché richieste identiche possono comportarsi diversamente dopo un aggiornamento.

Il terzo segnale è la prevista aggiunta delle funzionalità Amazon Bedrock AgentCore. Questa espansione verificherà se una piattaforma di agenti AWS più completa migliora osservabilità e controllo senza introdurre complessità non necessaria. Rivelerà inoltre quanto l'implementazione di Jefferies diventi strettamente accoppiata ai servizi di Amazon.

I lettori non dovrebbero attendere un'unica metrica di successo. Accuratezza, tassi di correzione, latenza, adozione da parte degli utenti, test di accesso non autorizzato e domanda di dashboard descrivono tutti parti diverse del risultato. Jefferies ha pubblicato l'architettura, ma saranno le evidenze operative a stabilire se il progetto diventerà un modello per il deployment di agenti in contesti regolamentati.

Per gli sviluppatori, la lezione è circoscrivere l'autonomia attorno a sistemi verificati. Per gli acquirenti aziendali, è pretendere misurazioni che separino dimostrazioni attraenti da flussi di lavoro affidabili. Per i knowledge worker, è considerare l'accesso conversazionale come una nuova interfaccia ai dati governati, non come un sostituto del giudizio.

Amazon AWS e Jefferies hanno spostato il dibattito oltre la domanda se un agente possa generare SQL. La vera domanda è se possa produrre analisi utili ripetutamente mentre i mercati si muovono e gli obblighi di conformità restano invariati. Osservate il lancio, la traccia di audit e i dati sugli errori prima di considerare risolta questa questione.