L'AI come infrastruttura critica: la visione di IBM

L'intelligenza artificiale sta rapidamente trascendendo il ruolo di semplice prodotto o piattaforma per affermarsi come infrastruttura fondamentale all'interno delle architetture aziendali. Questa transizione, come evidenziato da Rob Thomas, SVP e CCO di IBM, ridefinisce completamente le regole di governance e le aspettative. Se inizialmente un controllo stretto e ambienti di sviluppo chiusi potevano offrire vantaggi in termini di rapidità iterativa e gestione dell'esperienza utente, la situazione cambia radicalmente quando una tecnicia diventa un pilastro operativo su cui si basano sistemi esterni e mercati più ampi.

Oggi, i Large Language Models (LLM) e altre applicazioni AI sono sempre più integrati nei processi chiave delle organizzazioni, dalla sicurezza delle reti alla generazione di codice sorgente, dalle decisioni automatizzate alla creazione di valore commerciale. L'AI non è più una semplice utilità sperimentale, ma un componente operativo centrale. Questa evoluzione impone ai responsabili tecnici di affrontare nuove vulnerabilità strutturali e di ripensare l'approccio alla gestione e al Deployment di queste tecnicie, con un'attenzione particolare alla sovranità dei dati e al Total Cost of Ownership (TCO).

Le sfide dei modelli proprietari e l'impatto sul TCO

L'analisi di IBM mette in luce come la concentrazione della comprensione di questi sistemi in un numero limitato di fornitori tecnicici possa esporre le aziende a rischi operativi significativi. Un esempio lampante è il modello Claude Mythos di Anthropic, capace di scoprire e sfruttare vulnerabilità software a un livello paragonabile a quello di esperti umani. Di fronte a tale potenza, l'opacità dei modelli proprietari introduce una notevole frizione nelle architetture di rete esistenti.

Connettere modelli proprietari chiusi a database vettoriali aziendali o a data lake interni altamente sensibili genera spesso colli di bottiglia nella risoluzione dei problemi. Quando si verificano output anomali o picchi di allucinazioni, i team mancano della visibilità interna necessaria per diagnosticare se l'errore provenga dalla pipeline di Retrieval-Augmented Generation (RAG) o dai pesi del modello base. Inoltre, l'integrazione di architetture on-premise legacy con modelli cloud altamente “gated” introduce latenza nelle operazioni quotidiane. Le stringenti normative di governance dei dati, che proibiscono l'invio di informazioni sensibili a server esterni, costringono i team a processi di anonimizzazione e pulizia dei dati che creano un enorme rallentamento operativo. A ciò si aggiungono i costi crescenti delle chiamate API continue a modelli bloccati, che erodono i margini di profitto che questi sistemi dovrebbero migliorare. L'opacità impedisce agli ingegneri di rete di dimensionare accuratamente i Deployment hardware, costringendo le aziende a costosi accordi di over-provisioning per mantenere la funzionalità di base, impattando negativamente sul TCO complessivo.

L'Open Source come pilastro della resilienza operativa

IBM sostiene che, su scala infrastrutturale, la sicurezza migliora tipicamente attraverso un rigoroso scrutinio esterno, piuttosto che tramite una stretta segretezza. Questa è la lezione duratura dello sviluppo software Open Source. Il codice Open Source non elimina il rischio aziendale, ma cambia attivamente il modo in cui le organizzazioni lo gestiscono. Una base aperta consente a una più ampia platea di ricercatori, sviluppatori aziendali e difensori della sicurezza di esaminare l'architettura, individuare le debolezze sottostanti, testare le ipotesi fondamentali e rafforzare il software in condizioni reali.

Nel contesto delle operazioni di cybersecurity, un'ampia visibilità è raramente nemica della resilienza operativa; al contrario, ne è spesso un prerequisito. Le tecnicie considerate di importanza critica tendono a rimanere più sicure quando un pubblico più vasto può metterle alla prova, ispezionarne la logica e contribuire al loro miglioramento continuo. L'infrastruttura aperta, inoltre, sposta la competizione di mercato più in alto nello stack tecnicico, trasferendo valore finanziario anziché distruggerlo. I vincitori commerciali a lungo termine non sono coloro che possiedono lo strato tecnicico di base, ma piuttosto le organizzazioni che sanno come applicarlo nel modo più efficace, un pattern già osservato con le generazioni precedenti di strumenti aziendali, infrastrutture cloud e sistemi operativi. Per chi valuta Deployment on-premise, AI-RADAR offre framework analitici su /llm-onpremise per valutare i trade-off tra soluzioni Open Source e proprietarie, considerando aspetti come la sovranità dei dati e i requisiti hardware specifici.

Trasparenza e governance: requisiti irrinunciabili per l'AI aziendale

Un altro motivo pragmatico per abbracciare i modelli aperti riguarda l'influenza sullo sviluppo del prodotto. IBM sottolinea che un accesso ristretto al codice sottostante porta naturalmente a prospettive operative limitate. Al contrario, un accesso ampio consente a governi, istituzioni diverse, startup e ricercatori di influenzare attivamente l'evoluzione della tecnicia e le sue applicazioni commerciali. Questo approccio inclusivo promuove l'innovazione funzionale e, al contempo, costruisce adattabilità strutturale e la necessaria legittimità pubblica.

Quando l'AI autonoma assume il ruolo di infrastruttura aziendale centrale, l'opacità non può più servire come principio organizzativo per la sicurezza del sistema. Il modello più affidabile per un software sicuro ha sempre combinato fondazioni aperte con un ampio scrutinio esterno, una manutenzione attiva del codice e una seria governance interna. Con l'AI che entra permanentemente nella sua fase infrastrutturale, IBM sostiene che una logica identica si applica direttamente ai foundation models stessi. Maggiore è la dipendenza aziendale da una tecnicia, più forte è la necessità di esigere apertura. Se questi workflow autonomi stanno realmente diventando fondamentali per il commercio globale, allora la trasparenza cessa di essere oggetto di dibattito casuale per diventare un requisito di progettazione assoluto e non negoziabile per qualsiasi architettura aziendale moderna.