La partnership tra IBM e OpenAI punta alle operazioni core, ma la vera prova è il deployment sicuro

IBM e OpenAI hanno annunciato una partnership strategica il 13 agosto, con migliaia di specialisti previsti per deployment in cui un'automazione fallita può avere conseguenze concrete. L'accordo tra IBM e OpenAI punta a finanza, approvvigionamenti, servizio clienti, risorse umane, sviluppo software e cybersecurity. La sua promessa centrale non è semplicemente un accesso più ampio ai modelli. È un deployment controllato nei sistemi complessi che fanno funzionare le grandi organizzazioni.

Questa distinzione crea la tensione alla base dell'accordo. OpenAI collabora già con Accenture, BCG, Capgemini e McKinsey sull'adozione in ambito enterprise. IBM deve dimostrare che la combinazione di consulenza, competenze nell'infrastruttura ibrida e controlli di sicurezza produce qualcosa di più duraturo di un altro grande programma di formazione.

La partnership invita inoltre le imprese a riconsiderare il modo in cui acquistano l'AI. Invece di scegliere un modello e assemblare la governance in un secondo momento, i clienti riceverebbero modelli, servizi di implementazione, riprogettazione dei flussi di lavoro e misure di protezione attraverso un unico rapporto di fornitura. Questo può ridurre la frammentazione, ma può anche aumentare la dipendenza dalle organizzazioni che gestiscono il deployment.

Cosa cambia realmente con l'accordo tra IBM e OpenAI

IBM e OpenAI stanno portando la loro relazione da una collaborazione mirata sulla cybersecurity a un canale più ampio per il deployment enterprise.

Secondo il primo resoconto sulla partnership, IBM prevede di integrare i modelli e i prodotti OpenAI in IBM Consulting Advantage. La piattaforma fornisce strumenti AI, agenti e risorse riutilizzabili ai consulenti IBM che assistono i clienti.

L'integrazione prevista include GPT-5.6, Codex e ChatGPT Work. GPT-5.6 è l'ultima famiglia di modelli di OpenAI per carichi di lavoro professionali e di produzione. Codex supporta le attività di ingegneria del software, mentre ChatGPT Work offre un ambiente per il lavoro della conoscenza e la collaborazione.

IBM prevede inoltre di creare una practice dedicata a OpenAI. Includerà migliaia di consulenti e ingegneri formati attraverso l'OpenAI Partner Network, con certificazioni avanzate previste per gli specialisti partecipanti.

Queste persone contano quanto i prodotti. Un modello può redigere codice o analizzare un documento immediatamente. Non può però stabilire in autonomia quali approvazioni negli approvvigionamenti debbano restare sotto controllo umano o come una banca debba documentare una decisione automatizzata.

L'iniziativa congiunta si concentra su tre aree di deployment. La prima riguarda le operazioni aziendali core, tra cui finanza, approvvigionamenti, servizio clienti e risorse umane. Questi flussi di lavoro attraversano spesso diversi sistemi e contengono dati aziendali o personali sensibili.

La seconda area riguarda la modernizzazione delle applicazioni e lo sviluppo software. IBM prevede di combinare Codex e ChatGPT Work con la propria esperienza nel settore e nell'ingegneria. L'obiettivo è aiutare i team a comprendere i sistemi legacy, rivedere le applicazioni, esaminare il codice e gestire il cambiamento tecnico.

La terza area è la cybersecurity e la gestione dei rischi dell'AI. Questo lavoro estende la partecipazione di IBM all'OpenAI Daybreak Cyber Partner Program. Collega capacità avanzate dei modelli ai servizi di sicurezza IBM, incluso il suo approccio alla gestione dei rischi multi-agente.

L'accordo fa quindi più che aggiungere GPT-5.6 alla cassetta degli attrezzi di un consulente. Stabilisce un canale commerciale congiunto, un gruppo di implementazione formato e una piattaforma di delivery comune per portare i prodotti OpenAI in ambienti business-critical.

IBM non ha divulgato termini finanziari, obiettivi contrattuali o ricavi attesi. Non ha inoltre pubblicato un numero di clienti per la partnership ampliata. Queste omissioni rendono l'annuncio una dichiarazione di intenti, non la prova che l'adozione sia già avvenuta su larga scala.

IBM e OpenAI avvertono inoltre che le dichiarazioni sui loro piani futuri rappresentano obiettivi e possono cambiare. Questo linguaggio è standard negli annunci aziendali, ma qui è importante. La practice dedicata, le certificazioni, le integrazioni e i risultati per i clienti richiederanno verifiche separate man mano che arriveranno.

IBM e OpenAI vendono integrazione, non accesso ai modelli

La partnership si basa su una semplice valutazione: l'accesso a un modello capace non è più il principale ostacolo all'adozione dell'AI in ambito enterprise.

Molte grandi organizzazioni possono già accedere a modelli commerciali tramite un'API, un marketplace cloud o una suite per la produttività. Il problema più difficile inizia dopo l'approvazione dell'accesso.

Un sistema di produzione utile deve connettersi con controlli delle identità, database, applicazioni interne, catene di approvazione e registri di audit. Deve rispettare i confini dei dati producendo al contempo risultati che i dipendenti possano esaminare. Deve inoltre essere monitorato quando cambiano i modelli o le regole aziendali.

Andy Baldwin, senior vice president di IBM Consulting, ha definito la sfida come un'integrazione sicura all'interno di ambienti e flussi di lavoro enterprise complessi. Questa posizione spiega perché IBM pone Consulting Advantage al centro dell'accordo.

IBM Consulting Advantage è una piattaforma di delivery AI utilizzata dai consulenti dell'azienda. Organizza assistenti, agenti, metodi e componenti riutilizzabili che i team possono applicare durante gli incarichi con i clienti. IBM afferma che la piattaforma ha supportato oltre 150 incarichi e aumentato la produttività dei consulenti fino al 50%.

Questi dati sono misurazioni di IBM stessa e non dimostrano i ritorni per i clienti derivanti dai deployment OpenAI. Ciononostante, la piattaforma offre alla partnership un livello di delivery operativo. IBM non deve inventare un nuovo sistema operativo per ogni incarico.

Il meccanismo previsto è diretto. OpenAI fornisce modelli e applicazioni. IBM li confeziona con processi di settore, integrazione tecnica, supervisione umana e servizi continuativi. Team formati adattano poi questo pacchetto ai sistemi di ciascun cliente.

Si consideri un flusso di lavoro per gli approvvigionamenti. Un modello potrebbe confrontare documenti dei fornitori, segnalare clausole insolite, redigere una raccomandazione e raccogliere prove a supporto. Tuttavia, il sistema necessita ancora di regole di accesso, soglie di escalation, tracciamento delle fonti e un percorso di approvazione finale.

Un deployment nel servizio clienti presenta un'altra versione dello stesso problema. Un agente AI può recuperare informazioni sull'account e proporre una risposta. Deve anche evitare di esporre i dati di un altro cliente, seguire le politiche regionali e affidare i casi difficili a un dipendente.

La modernizzazione delle applicazioni alza ulteriormente la posta in gioco. Il software legacy contiene spesso regole aziendali non documentate, sviluppate nel corso di decenni. Codex può aiutare a ispezionare le dipendenze, spiegare il codice, generare test e proporre modifiche. IBM deve comunque verificare se tali modifiche preservano il comportamento operativo da cui dipende un cliente.

È qui che la partnership potrebbe diventare preziosa. Il modello gestisce analisi e generazione, mentre il framework di delivery controlla accesso, prove, test ed escalation. Nessuna delle due parti è sufficiente da sola per un flusso di lavoro ad alte conseguenze.

Per i knowledge worker, lo stesso schema si applica su scala minore. L'AI offre assistenza più affidabile quando può utilizzare materiale pertinente senza perdere il contesto delle fonti. Una base di conoscenza AI ben mantenuta può aiutare le persone a organizzare quel contesto prima che l'automazione raggiunga una decisione critica.

La proposta IBM OpenAI dipende quindi meno da una singola vittoria nei benchmark che da una progettazione operativa disciplinata. Le imprese valuteranno se il sistema combinato completa un lavoro utile senza creare oneri di revisione inaccettabili o nuove lacune di sicurezza.

Accenture e altre alleanze occupano già questo mercato

IBM entra in una corsa all'implementazione affollata, nella quale OpenAI ha deliberatamente evitato di affidarsi a un unico partner di consulenza.

OpenAI ha introdotto le sue Frontier Alliances a febbraio con BCG, McKinsey, Accenture e Capgemini. Il programma distribuisce il lavoro di adozione enterprise tra strategia, progettazione del modello operativo, integrazione dei sistemi, modernizzazione dei dati, gestione del cambiamento e supporto a lungo termine.

BCG e McKinsey si concentrano fortemente sulla strategia e sulla riprogettazione organizzativa. Accenture e Capgemini mettono a disposizione grandi organizzazioni di delivery in grado di collegare i modelli ai sistemi di produzione. OpenAI afferma che queste aziende aiutano i clienti a passare dagli esperimenti a capacità estese all'intera azienda.

Accenture rappresenta il punto di pressione più evidente per IBM. La sua relazione ampliata con OpenAI include decine di migliaia di professionisti che utilizzano ChatGPT Enterprise. Quando l'alleanza è stata annunciata, OpenAI ha descritto questo deployment come il più grande gruppo di professionisti formati attraverso le certificazioni OpenAI.

Il modello delle Frontier Alliances offre a OpenAI più percorsi per entrare nelle grandi imprese. Mantiene inoltre le società di consulenza in competizione per budget di trasformazione simili, talenti tecnici e attenzione dei dirigenti.

IBM non può vincere questa competizione solo attraverso dichiarazioni sul personale. Migliaia di specialisti certificati sembrano una dotazione considerevole, ma la certificazione non dimostra se tali specialisti possano riprogettare un processo di gestione dei sinistri o modernizzare in sicurezza un sistema di pagamenti.

L'elemento distintivo di IBM è la sua presenza nella consulenza, nel software, nell'infrastruttura e nelle operazioni enterprise di lunga durata. Ha relazioni profonde nei settori bancario, governativo, delle telecomunicazioni, sanitario e manifatturiero. Molti clienti gestiscono inoltre ambienti ibridi che includono mainframe, sistemi privati e diversi cloud pubblici.

Questa posizione potrebbe aiutare IBM ad affrontare carichi di lavoro che non si inseriscono facilmente in un singolo cloud o in una suite applicativa. Potrebbe anche creare tensioni interne. IBM vende il proprio portafoglio watsonx, mantenendo al contempo ampie partnership con Microsoft, AWS, Google Cloud e altri fornitori di tecnologia.

A giugno, IBM ha annunciato una practice separata con Google Cloud che amplia Consulting Advantage con le capacità di Gemini Enterprise. Gestisce inoltre una rilevante practice Microsoft e ha già fornito servizi Azure OpenAI.

Questa impostazione multi-modello è utile per i clienti che desiderano scegliere. Rende però più difficili da interpretare gli incentivi di IBM. Un acquirente deve stabilire se IBM selezioni la tecnologia per il flusso di lavoro o dia priorità alla partnership con il maggiore slancio commerciale.

OpenAI affronta un compromesso simile. Vuole che le società di consulenza espandano la distribuzione, ma queste aziende possono anche raccomandare modelli concorrenti. IBM può affiancare GPT-5.6 a Gemini, modelli watsonx, modelli a pesi aperti o sistemi specializzati quando un cliente li richiede.

Il risultato non è un'alleanza esclusiva tradizionale. È una partnership di distribuzione e implementazione all'interno di un portafoglio più ampio. IBM ottiene accesso alla domanda di OpenAI e OpenAI ottiene la portata enterprise di IBM. Ciascuna parte mantiene altre opzioni.

Questa struttura limita il lock-in tra i partner, ma non protegge automaticamente i clienti. Un flusso di lavoro può comunque diventare dipendente dal comportamento di un modello, dagli strumenti di un consulente o da un livello proprietario di agenti e integrazioni.

Gli acquirenti enterprise dovrebbero quindi confrontare le architetture operative, non i loghi delle partnership. Devono sapere se prompt, valutazioni, sistemi di retrieval e regole di approvazione possano spostarsi tra modelli. Dovrebbero inoltre chiedere quali componenti gestisca IBM e quali restino sotto il controllo del cliente.

Un'AI enterprise sicura richiede più del linguaggio della governance

La parte più solida della partnership è la sua base di sicurezza, ma quella base espone anche le questioni irrisolte più difficili dell'accordo.

IBM ha aderito all'OpenAI Daybreak Cyber Partner Program il 22 giugno. Il programma offre ai fornitori di sicurezza approvati l'accesso a capacità avanzate per attività difensive autorizzate.

Il servizio iniziale di IBM utilizza un security harness basato su Consulting Advantage. Un security harness è un livello controllato che limita il modo in cui un sistema di IA accede a codice, strumenti e ambienti dei clienti.

IBM afferma che il suo progetto può operare nell'ambiente di un cliente con accesso in sola lettura ai repository ed esecuzione delimitata. L'esecuzione delimitata restringe le azioni che un modello può compiere, riducendo la probabilità che un'analisi si trasformi in una modifica incontrollata del sistema.

Il servizio è pensato per analizzare l'esposizione delle applicazioni, identificare percorsi di attacco pertinenti e supportare il monitoraggio continuo mentre codice e minacce evolvono. IBM ha annunciato che il primo servizio di sicurezza applicativa era disponibile al momento dell'adesione a Daybreak.

Questo approccio risponde a una preoccupazione comune sugli strumenti di sicurezza basati sull'IA. Concedere a un modello molto capace un accesso senza restrizioni a codice e infrastruttura può creare un rischio proprio. L'accesso in sola lettura e l'esecuzione vincolata definiscono confini operativi più ristretti.

IBM ha inoltre collegato Daybreak a Project Lightwell, un'iniziativa incentrata sulle catene di fornitura del software open source. L'azienda ha dichiarato che IBM e Red Hat avevano impegnato 5 miliardi di dollari nel progetto, che combina un centro di coordinamento per la sicurezza con ingegneri che correggono e convalidano il codice.

Il più ampio programma Daybreak di OpenAI riflette un cambiamento nella sicurezza difensiva. I modelli stanno diventando più efficaci nell'individuare vulnerabilità, ma le organizzazioni faticano ancora a stabilire priorità, applicare patch, testare e distribuire correzioni.

Le capacità avanzate presentano anche un problema di duplice uso. Lo stesso ragionamento che aiuta un difensore a convalidare una vulnerabilità può aiutare un aggressore a sfruttarla. OpenAI limita quindi alcune funzioni cyber a organizzazioni verificate e ambienti autorizzati.

GPT-5.6 accentua questo dilemma. OpenAI riporta miglioramenti sostanziali nella revisione sicura del codice, nel patching, nel threat modeling e nei test di vulnerabilità. I risultati pubblicati includono punteggi superiori a GPT-5.5 in diverse valutazioni cyber.

Per esempio, OpenAI riporta che GPT-5.6 Sol ha ottenuto il 73,5 percento su ExploitBench, rispetto al 47,9 percento di GPT-5.5. Ha raggiunto il 71,2 percento su SEC-Bench Pro, contro il 45,8 percento del modello precedente.

Si tratta di risultati di benchmark pubblicati dal fornitore, non della prova di prestazioni sicure nell'ambiente di un cliente IBM. Un benchmark isola un compito definito. Un flusso di lavoro in produzione introduce inventari incompleti, responsabilità ambigue, dipendenze in evoluzione e priorità operative concorrenti.

La partnership tra IBM e OpenAI deve inoltre affrontare il prompt injection. Questo attacco manipola un sistema di IA tramite istruzioni dannose nascoste in documenti, siti web o contenuti recuperati. Un modello connesso a strumenti interni può trattare tali contenuti come comandi, a meno che il sistema circostante non separi i dati dall'autorità.

La governance dei dati presenta un'altra sfida. Un agente usato nelle risorse umane può incontrare registri occupazionali, informazioni sulle prestazioni o adattamenti sanitari. Uno usato in finanza può accedere a previsioni, pagamenti e cronologie delle transazioni.

La sicurezza non può quindi restare un documento di policy allegato dopo la distribuzione. Deve comparire nella progettazione delle identità, nella minimizzazione dei dati, nei permessi degli strumenti, nel logging, nei test e nella risposta agli incidenti. I revisori umani devono avere un'autorità chiara per fermare o annullare azioni automatizzate.

Il security harness controllato di IBM è un punto di partenza credibile. Tuttavia, la nuova partnership copre molto più dell'analisi del codice. IBM non ha illustrato pubblicamente come gli stessi controlli si applicheranno a finanza, approvvigionamenti, assistenza clienti e risorse umane.

L'accordo non specifica nemmeno come i clienti valuteranno gli aggiornamenti del modello. GPT-5.6 può comportarsi diversamente da una versione precedente, anche quando un flusso di lavoro mantiene le stesse istruzioni. Le imprese hanno bisogno di test di regressione che misurino accuratezza, conformità alle policy e comportamenti non sicuri prima che le modifiche raggiungano la produzione.

Finché IBM non pubblicherà prove di implementazione, la distribuzione sicura resterà un impegno anziché un risultato dimostrato. Gli acquirenti dovrebbero distinguere tra le funzionalità di sicurezza esistenti oggi e le integrazioni future descritte come obiettivi della partnership.

Il compromesso centrale è tra velocità e controllo del cliente

IBM può abbreviare il percorso dal progetto pilota alla produzione, ma ogni scorciatoia deve preservare la capacità del cliente di ispezionare, governare e sostituire il sistema.

Le grandi imprese spesso ripetono lo stesso lavoro preparatorio nei progetti di IA. I team stabiliscono controlli di accesso, connettono dati, definiscono valutazioni, creano flussi di approvazione e documentano i rischi. Gli asset riutilizzabili possono ridurre questa duplicazione.

Una practice OpenAI dedicata dovrebbe inoltre rendere più facile individuare le competenze. Invece di assemblare un team da gruppi non correlati, IBM può assegnare consulenti formati sugli stessi prodotti e metodi di delivery.

L'attività congiunta sul mercato può semplificare gli acquisti. I clienti possono rivolgersi a un unico rapporto di delivery per modelli, implementazione e servizi gestiti. Ciò riduce il coordinamento tra diversi fornitori.

Tuttavia, la velocità di integrazione può nascondere decisioni architetturali. Un agente riutilizzabile può arrivare con presupposti sui formati dei dati, sul comportamento del modello o sul monitoraggio. Tali presupposti diventano costosi da modificare dopo che il flusso di lavoro si è diffuso tra i reparti.

Le imprese dovrebbero mantenere il controllo su quattro livelli. Il primo è l'accesso ai dati, comprese le fonti che un agente può leggere e i record che non deve mai recuperare. Il secondo è l'autorità d'azione, che determina ciò che l'agente può modificare.

Il terzo livello è la valutazione. I clienti hanno bisogno di casi di test propri, soglie di accettazione e registrazioni del comportamento del modello. Non dovrebbero dipendere interamente dal benchmark o dalla dimostrazione di un fornitore.

Il quarto livello è la portabilità. Un flusso di lavoro dovrebbe identificare quali componenti appartengono a IBM, OpenAI, un altro fornitore o al cliente. Questa mappa determina quanto sarà difficile un futuro cambio di modello o servizio.

Questo requisito è importante perché IBM supporta apertamente più fornitori di modelli. Un'architettura multi-modello può ridurre la dipendenza, ma solo se il passaggio è tecnicamente realistico. Un menu a discesa contenente diversi modelli non garantisce un comportamento equivalente.

Le modifiche al modello possono alterare chiamate agli strumenti, formattazione, schemi di ragionamento e comportamento di rifiuto. I team devono testare l'intero processo dopo un cambio. Potrebbero inoltre dover rivedere prompt, permessi e criteri di valutazione.

La responsabilità umana non può scomparire all'interno di un servizio gestito. Se una decisione di approvvigionamento assistita dall'IA viene contestata, il cliente deve poter ricostruire quali dati sono stati usati e chi ha approvato il risultato. Se il codice generato causa un'interruzione, i team hanno bisogno di registrazioni della modifica proposta e dei relativi test.

I knowledge worker affrontano un rischio parallelo quando automatizzano ricerche, sintesi e decisioni. I sistemi utili mantengono i collegamenti tra output e materiale di origine. Una base di conoscenza ricercabile può supportare tale tracciabilità per i documenti tecnici, ma i controlli organizzativi devono comunque determinare accesso e conservazione.

Il risultato migliore combinerebbe un'implementazione più rapida con una governance del cliente più solida. IBM potrebbe fornire modelli collaudati lasciando policy, prove e autorità finale sotto il controllo del cliente.

Il risultato più debole impacchetterebbe modelli e servizi in una scatola nera difficile da verificare. Potrebbe offrire rapidamente un progetto pilota impressionante, per poi creare dipendenza a lungo termine e costi di revisione.

Ecco perché l'accordo IBM OpenAI dovrebbe essere valutato in base all'architettura e alle prove operative. La scala della partnership è rilevante, ma la distribuzione del controllo determinerà se le implementazioni resteranno gestibili.

Tre segnali mostreranno se la partnership funziona

La prossima fase sarà decisa dalle prove in produzione, dall'adozione misurabile e da controlli che resistano al contatto con flussi di lavoro reali.

Il primo segnale è un'implementazione presso un cliente nominato in un'operazione centrale. Un caso credibile dovrebbe identificare il flusso di lavoro, il processo precedente, il grado di automazione e il modello di revisione umana. Dovrebbe riportare risultati operativi senza basarsi solo su aneddoti dei dipendenti.

Finanza, approvvigionamenti, assistenza clienti e risorse umane sono tutte aree promettenti. Comportano però requisiti legali, di sicurezza e qualità diversi. Le prove provenienti da un flusso di lavoro non possono convalidarne automaticamente un altro.

Un caso pubblicato relativo alla modernizzazione di applicazioni legacy sarebbe particolarmente istruttivo. Potrebbe mostrare come Codex opera con documentazione incompleta, dipendenze estese e test obbligatori. Dovrebbe inoltre descrivere come IBM gestisce le modifiche generate che non superano la valutazione.

Il secondo segnale è l'effettiva preparazione della practice dedicata. IBM afferma di voler formare migliaia di consulenti e ingegneri tramite l'OpenAI Partner Network. I lettori dovrebbero osservare certificazioni completate, copertura regionale, specializzazione settoriale e team clienti attivi.

Il solo organico non risolverà la questione. La misura rilevante è se i team formati possano portare ripetutamente i progetti in produzione. IBM dovrebbe infine distinguere tra chi ha completato la formazione e gli specialisti che forniscono sistemi sottoposti ad audit.

Il terzo segnale è la documentazione tecnica per governance e portabilità. IBM dovrebbe spiegare come Consulting Advantage gestisce selezione dei modelli, identità, logging, valutazioni, permessi degli strumenti, aggiornamenti e risposta agli incidenti nelle implementazioni OpenAI.

I clienti dovrebbero inoltre cercare prove che i flussi di lavoro possano incorporare un altro modello quando i requisiti cambiano. Le relazioni di IBM con Google Cloud, Microsoft, AWS e fornitori di modelli aperti rendono questa un'aspettativa ragionevole.

Questi segnali rafforzerebbero l'affermazione centrale della partnership. Un caso in produzione mostrerebbe che l'integrazione funziona. Le metriche di delivery mostrerebbero che la nuova practice è operativa. La documentazione di governance mostrerebbe che la scala non richiede di rinunciare al controllo.

La loro assenza indebolirebbe la narrazione. Se IBM pubblicasse solo numeri sulla formazione e un linguaggio generico sulla trasformazione, l'iniziativa potrebbe restare principalmente un canale di vendita. Se le implementazioni dei clienti omettessero tassi di fallimento o costi di revisione, gli acquirenti non disporrebbero delle informazioni necessarie per il confronto.

I risultati di GPT-5.6 di OpenAI mostrano perché le imprese sono interessate. La famiglia di modelli è rivolta al lavoro professionale complesso, all'ingegneria del software, all'uso di strumenti, al contesto lungo e alla cybersecurity. Queste capacità possono supportare flussi di lavoro di valore.

La sfida rimanente è organizzativa, non meramente tecnica. Le imprese devono connettere l'intelligenza a dati affidabili, permessi limitati, persone responsabili e processi che tollerino gli errori.

Questa è la vera opportunità dietro IBM OpenAI. IBM può avvicinare i modelli di OpenAI ai sistemi in cui si svolge il lavoro con conseguenze rilevanti. Può anche fornire l'esperienza di settore necessaria per riconoscere quando l'automazione dovrebbe fermarsi.

Gli acquirenti aziendali dovrebbero ora chiedere prove su questo confine. Quali azioni può compiere l'agente, chi le approva, come vengono rilevati gli errori e il flusso di lavoro può sopravvivere a un cambio di modello? La partnership diventa significativa quando IBM e OpenAI rispondono a queste domande attraverso sistemi funzionanti, non con affermazioni più grandi.