Introduzione alla piattaforma distribuita H2O.ai per automatizzare i flussi di lavoro Machine Learning su big data 2026

Che cos'è H2O.ai, come funziona un cluster di calcolo in memoria, che cosa automatizza davvero l'AutoML, quanto costa una piattaforma che non pubblica listini e quando non conviene

H2O.ai è il rovesciamento di un'abitudine. Nel flusso di lavoro normale di chi fa machine learning i dati vengono portati dentro il programma: si carica un file in un DataFrame, lo si trasforma in memoria su una macchina sola, lo si dà in pasto a una libreria. Funziona finché il file entra nella RAM di quella macchina. H2O.ai fa il contrario — tiene i dati dentro un cluster di processi che li conserva compressi in memoria e ci manda sopra il calcolo — e da questa singola scelta discende tutto il resto: la scalabilità senza riscrivere una riga, il formato di modello che poi gira ovunque, la possibilità di installare l'intera piattaforma dentro una rete chiusa.

Questa guida percorre la piattaforma per intero: caratteristiche principali, vantaggi competitivi per machine learning e deep learning, costi, funzionalità avanzate e integrazioni, alternative e confronto, strategie di crescita e tendenze future. Dove un dato non è pubblico — e su H2O.ai capita con i prezzi, che è la domanda che tutti fanno per prima — lo diciamo invece di stimarlo, perché una cifra inventata in un preventivo costa più di una cifra mancante.

Due fatti la rendono meno di nicchia di quanto il nome suggerisca. Il primo: il motore H2O-3 è software libero sotto licenza Apache 2.0, completo di AutoML e di esportazione dei modelli, e si può mettere in produzione commerciale senza parlare con nessuno — l'azienda dichiara oltre 20.000 organizzazioni che lo usano. Il secondo: la parte commerciale è finita in produzione in banche e assicurazioni che devono spiegare a un revisore perché un modello ha detto no, e più della metà delle Fortune 500 risulta fra i clienti. Sono due mercati diversi, serviti dallo stesso codice, separati da un confine commerciale che conviene conoscere prima di iniziare.

Che cos'è H2O.ai, e che cosa non è

La definizione, presa alla lettera

H2O.ai è una piattaforma di machine learning distribuita e in memoria. Le tre parole contano tutte e vale la pena prenderle una per una, perché il fraintendimento più comune nasce dal saltarne una.

In memoria significa che i dati non vengono letti dal disco a ogni passaggio: stanno nella RAM del cluster, in formato colonnare compresso, e ci restano per tutta la durata della sessione. Distribuita significa che quella RAM non è di una macchina sola ma di un insieme di nodi che si comportano come uno solo. Piattaforma, non libreria, significa che il motore non gira dentro il vostro processo Python: è un servizio separato, scritto in Java, che voi comandate da fuori.

Quest'ultimo punto è quello che sorprende chi arriva da scikit-learn. Quando scrivete import h2o e caricate un dataset, il vostro interprete Python non riceve i dati: riceve un riferimento. I comandi viaggiano in REST su un socket e i risultati tornano indietro come riassunti. Il portatile da cui lavorate non ha bisogno della memoria del dataset, perché il dataset non è mai sul portatile. È una differenza di modello mentale, non di sintassi, e chi non la interiorizza finisce per scrivere codice che riporta continuamente i dati sul client, cioè per usare una piattaforma distribuita come se fosse pandas.

Quattro prodotti, un nome

Chi si avvicina per la prima volta si perde nei nomi, e poiché il confine fra ciò che è gratuito e ciò che si paga passa esattamente fra questi nomi, conviene fissare la mappa prima di ogni altra cosa.

La lettura corretta di questa tabella è che H2O.ai non è un prodotto: è un confine commerciale. Sopra il confine c'è software libero che risolve molti più casi d'uso di quanti l'azienda media immagini. Sotto c'è una piattaforma enterprise il cui prezzo si negozia. Confondere i due strati produce preventivi sbagliati in entrambe le direzioni: chi crede che serva la licenza per fare AutoML paga una cosa che aveva già, chi crede che l'open source includa il monitoraggio dei modelli in produzione scopre tardi che deve costruirselo.

Versioni e cadenza di rilascio

H2O-3 pubblica versioni stabili con una regolarità di poche settimane: la 3.46.0.12 è del 12 agosto 2026, preceduta dalla 3.46.0.11 del 22 maggio 2026 e dalla 3.46.0.10 del 12 marzo 2026. È una numerazione conservativa, dove il ramo principale resta fermo e cambia solo l'ultima cifra: per chi deve pianificare aggiornamenti in produzione è una buona notizia, perché significa correzioni frequenti senza rotture di compatibilità.

Sul lato commerciale, Driverless AI è alla versione 2.5.0, rilasciata il 28 agosto 2026. Vale la pena notarlo perché su molti siti di terze parti circola ancora la documentazione della serie 1.x: quando si confrontano funzionalità o requisiti, conviene guardare la documentazione ufficiale e non i comparatori di software, che su questa piattaforma sono sistematicamente indietro.

Chi la sviluppa, e la domanda sulla governance

Il progetto nasce nel 2011 con il nome 0xdata, fondato da Sri Satish Ambati e Cliff Click. Il secondo nome spiega molto della qualità dell'implementazione: Click è l'autore del compilatore JIT HotSpot della Java Virtual Machine, ed è difficile immaginare una biografia più adatta a chi deve costruire un motore di calcolo distribuito in Java. Il comitato scientifico ha incluso nel tempo statistici come Stephen Boyd, Robert Tibshirani e Trevor Hastie, cioè gli autori dei testi su cui si studia la regolarizzazione che H2O implementa.

Sulla governance va detta la cosa che conta: H2O-3 è open source ma non è un progetto di fondazione. Non c'è una Apache Software Foundation né una Linux Foundation a fare da garante: c'è un'azienda privata che ha raccolto 256 milioni di dollari da investitori fra cui NVIDIA, Goldman Sachs, Wells Fargo, Capital One e Commonwealth Bank. La licenza Apache 2.0 vi protegge sul codice già rilasciato — quello nessuno ve lo può togliere — ma la direzione del progetto e la sua cadenza dipendono da decisioni aziendali. È lo stesso profilo di rischio di molti progetti open source sostenuti da un solo attore, e va valutato per quello che è: non un difetto, ma una dipendenza da mettere nel registro.

L'adozione, e come leggerne i numeri

L'azienda dichiara oltre 20.000 organizzazioni che usano la tecnologia open source e più della metà delle Fortune 500 fra i clienti, con nomi verificabili come AT&T, Commonwealth Bank of Australia, Wells Fargo, Bank of America, Workday, Progressive Insurance e i National Institutes of Health statunitensi.

Come si leggono questi numeri? Con la cautela d'obbligo per qualunque dato di adozione dichiarato dal fornitore, ma con una precisazione a favore: la prima cifra riguarda l'open source, dove «usare» significa aver scaricato ed eseguito qualcosa, ed è quindi una misura larga; la seconda riguarda relazioni commerciali, ed è quindi una misura stretta. Un terzo indicatore, più laterale e più interessante, è la presenza di Kaggle Grandmaster nel gruppo — l'azienda non pubblica un numero, e la formulazione ufficiale parla di alcuni fra i Grandmaster mondiali, inclusi tre che sono arrivati al primo posto assoluto. Non è una metrica di mercato: è un segnale sul fatto che l'AutoML della piattaforma è stato costruito da persone che hanno vinto competizioni con le mani, il che si vede nelle scelte di default.

Le caratteristiche principali

Il cluster in memoria, che è tutto

Il cuore della piattaforma è un insieme di processi JVM, uno per nodo, che condividono un distributed key-value store costruito su una hash map non bloccante. I dati vivono lì dentro in un formato colonnare che la documentazione chiama Fluid Vector Frame, con una gerarchia precisa — Frame, poi Vector, poi Chunk, poi Element — e vengono compressi colonna per colonna. La compressione non è un dettaglio di risparmio: è ciò che permette di tenere in RAM dataset che in formato grezzo non ci starebbero.

Il calcolo si esprime come MRTask, un MapReduce in memoria costruito su un framework Fork/Join modificato. La documentazione tiene esplicitamente distinta questa cosa dal MapReduce di Hadoop, e la distinzione è sostanziale: qui non c'è scrittura su disco fra una fase e l'altra, il che è esattamente il motivo per cui un algoritmo iterativo — e quasi tutti gli algoritmi di machine learning lo sono — gira ordini di grandezza più velocemente.

La conseguenza pratica è quella che va ricordata quando si pianifica un progetto: il codice non cambia fra un portatile e un cluster da quaranta nodi. Cambia il numero di nodi che avviate. Non c'è una versione «locale» e una «distribuita» dell'API, non c'è una riscrittura in mezzo.

Gli algoritmi: pochi, implementati bene

H2O-3 non insegue la copertura enciclopedica di scikit-learn, e la scelta è deliberata: implementare un algoritmo in modo distribuito è molto più difficile che implementarlo, e la piattaforma preferisce farne pochi bene. Il repository ufficiale elenca GLM con regolarizzazione Elastic Net, GBM, XGBoost, Distributed Random Forest, Deep Learning (reti feed-forward), GAM, RuleFit, SVM, Naïve Bayes, Word2Vec e Stacked Ensembles; sul fronte non supervisionato, K-Means e PCA.

È una lista che copre la quasi totalità di ciò che serve davvero su dati tabellari: rischio di credito, abbandono dei clienti, propensione all'acquisto, previsione della domanda, rilevamento delle frodi, determinazione dei prezzi. Non è la lista giusta se state facendo ricerca su architetture nuove, e su questo torniamo parlando di deep learning, perché è il limite più frainteso della piattaforma.

AutoML: che cosa fa esattamente, passo per passo

Una riga di codice avvia una procedura che la documentazione descrive per intero, ed è una lettura che conviene fare, perché è l'unico modo per capire che cosa state ottenendo e che cosa no. AutoML addestra i modelli in gruppi di priorità, in quest'ordine: tre XGBoost GBM con iperparametri prefissati; una griglia fissa di GLM; un Distributed Random Forest di default; cinque H2O GBM prefissati; una rete neurale con parametri quasi di default; un Extremely Randomized Forest; infine griglie casuali di XGBoost GBM, H2O GBM e reti profonde, finché il tempo concesso non finisce.

Dopo ogni gruppo vengono addestrati due Stacked Ensembles: uno su tutti i modelli e uno sui migliori di ciascuna famiglia, al massimo sei. Il metalearner è un GLM non negativo regolarizzato, con scelta fra Lasso ed Elastic Net in cross-validation, e la regolarizzazione serve proprio a favorire una combinazione sparsa: l'ensemble finale pesa pochi modelli, non tutti quelli addestrati.

Il risultato è una leaderboard, ordinata per AUC nella classificazione binaria, per errore medio per classe nella multiclasse e per RMSE nella regressione. Si possono aggiungere due colonne che sembrano minori e non lo sono: il tempo di addestramento e il tempo di predizione per riga. È quest'ultima che dice quali modelli potete davvero mettere dietro un endpoint sincrono, e guardarla dopo aver scelto il modello è una delle cause più comuni di rilavorazione.

Due cose da sapere prima del primo lancio. Se non specificate né un limite di tempo né un numero massimo di modelli, il default è un'ora. E, soprattutto, l'esportazione in formato MOJO è disponibile per i modelli singoli, non per gli Stacked Ensembles: se il piano di rilascio era «prendo il primo della leaderboard e lo esporto», e il primo è quasi sempre un ensemble, il piano va rivisto prima di iniziare e non in fase di consegna.

L'interpretabilità, che non è un accessorio

H2O-3 espone una funzione unica di spiegazione che si applica sia a un modello singolo sia all'intero oggetto AutoML, e restituisce importanza delle variabili, valori SHAP, grafici di dipendenza parziale e curve ICE. Nella versione commerciale, Driverless AI porta un modulo dedicato — MLI, Machine Learning Interpretability — costruito esplicitamente per i settori regolamentati.

MOJO e POJO: il modello che esce dalla piattaforma

Questo è il dettaglio tecnico che più spesso decide un'adozione, e quasi nessuno lo guarda per primo. I modelli addestrati si esportano in due formati: POJO (Plain Old Java Object) e MOJO (Model ObJect, Optimized). Un MOJO è un artefatto autoconsistente che si valuta con una piccola libreria Java: niente cluster acceso, niente Python, niente server di modelli, niente contenitore dedicato.

La conseguenza è che un modello addestrato su un cluster da quaranta nodi può finire dentro un microservizio Java, dentro una funzione serverless o dentro un'applicazione, e rispondere in microsecondi. Dove il consumatore del modello è un'applicazione aziendale Java — la situazione normale in banca, in assicurazione, nella logistica — questo elimina un intero strato di infrastruttura e la squadra che lo manterrebbe. Driverless AI produce a sua volta una MOJO scoring pipeline Java autonoma, oltre a un modulo Python.

Le interfacce: quattro strade, un solo motore

Lo stesso cluster si comanda da Python, R, Scala, Java, REST e da Flow, il notebook web incluso nella distribuzione. Flow è la parte più sottovalutata: permette a un analista che non scrive codice di caricare un file, lanciare un AutoML e leggere la leaderboard con il mouse, mentre il data scientist del gruppo lavora sullo stesso cluster da Python.

Il punto non è la comodità, è che non sono due ambienti diversi con due motori diversi: è la stessa istanza, con gli stessi dati caricati una volta sola. Nei gruppi misti questo elimina alla radice la divergenza fra «quello che ha provato l'analista» e «quello che poi rifà il data scientist», che è una delle forme di spreco più costose e meno visibili nei progetti di analisi.

I vantaggi competitivi

Scalare senza riscrivere: il costo che sparisce dal preventivo

È il vantaggio fondativo e va ripetuto perché è raro. Nella maggior parte degli stack, il passaggio dal prototipo alla produzione è una riscrittura: pandas diventa PySpark, una libreria diventa un servizio gestito, e il modello che avevate validato non è più esattamente lo stesso modello. Con H2O quel passaggio non esiste.

Per chi deve preventivare un progetto, questo significa che una voce sparisce dal conto — e non una voce piccola: la riscrittura di un pipeline di preparazione dati e addestramento, con la relativa ri-validazione, è spesso una frazione a due cifre del budget complessivo. Vale la pena dirlo al cliente in questi termini, perché è un argomento economico e non tecnico.

La baseline in un pomeriggio

Il valore dell'AutoML non è che trovi modelli migliori: un data scientist esperto, con una settimana, spesso ne trova di migliori. È che produce una baseline difendibile in un pomeriggio, e una baseline difendibile permette di rispondere presto alla domanda che conta davvero: questo problema è risolvibile con i dati che abbiamo?

Se l'AUC massima raggiungibile su quei dati è 0,58, è meglio scoprirlo il primo giorno che al terzo mese, quando il budget è speso e le aspettative sono state create. Usato così, l'AutoML è uno strumento di decisione prima che di modellazione, ed è il modo in cui rende di più.

Deep learning: che cosa c'è davvero

Qui serve precisione, perché è il punto su cui la comunicazione commerciale è più generosa di quanto sia la realtà tecnica.

H2O-3 include un algoritmo di Deep Learning: reti neurali feed-forward multistrato, addestrate in modo distribuito. Sono buone su dati tabellari e inadatte a tutto il resto, per la ragione elementare che non sono convoluzionali, né ricorrenti, né transformer. Non è un sostituto di PyTorch o TensorFlow e non pretende di esserlo. Due limiti documentati vanno messi a verbale: il Deep Learning di H2O non è riproducibile di default, perché l'addestramento distribuito introduce non determinismo, e il supporto per le GPU riguarda schede NVIDIA con CUDA.

Il deep learning applicato, nella piattaforma, sta altrove — e sta nella parte a pagamento: Hydrogen Torch per visione e linguaggio senza scrivere codice, Document AI per l'estrazione strutturata dai documenti, H2O LLM Studio per il fine-tuning dei modelli linguistici. Chi valuta H2O.ai «perché fa anche deep learning» e poi installa H2O-3 non ha sbagliato prodotto: ha sbagliato la lettura del catalogo.

Governance e spiegabilità come struttura, non come plugin

SHAP, dipendenza parziale, curve ICE, motivazioni del rifiuto, MLI, audit trail, validazione dei modelli: nella piattaforma queste cose non sono estensioni, sono parte del percorso ordinario. In un contesto europeo — dove la pressione normativa cresce anche quando le scadenze slittano, e vedremo fra poco che nel 2026 sono slittate — avere la spiegazione prodotta dallo stesso strumento che addestra vale più di quanto valga sulla carta.

C'è anche un argomento meno nobile e altrettanto reale: la spiegabilità è ciò che permette di far approvare un modello internamente. Molti progetti di machine learning non muoiono per performance insufficienti, muoiono perché nessuno se la sente di firmare.

Sovranità del dato: on-premise e air-gapped

È il posizionamento su cui H2O.ai ha spinto di più nell'ultimo biennio, ed è quello con più mercato in Europa. La piattaforma si installa on-premise, in ambienti completamente disconnessi dalla rete, in cloud privato, in configurazione ibrida o dai marketplace di AWS, Azure e Google Cloud.

Due segnali del 2026 confermano la direzione: la certificazione FedRAMP High, annunciata il 20 maggio 2026 per la versione destinata al settore pubblico statunitense, e l'integrazione validata nella Dell AI Factory with NVIDIA per installazioni sovrane. Per una banca italiana, una pubblica amministrazione o una struttura sanitaria che non può far uscire i dati dal perimetro, questo riduce l'insieme dei candidati a poche unità: spesso è il criterio, non uno dei criteri.

Dove il vantaggio si rovescia

Ogni scelta architetturale si paga da qualche parte, e una valutazione onesta elenca anche il retro della medaglia.

• La memoria costa. La documentazione raccomanda di dimensionare il cluster a circa quattro volte la dimensione dei dati, e in un altro punto indica un intervallo di tre-quattro volte. Un dataset da 100 GB vuole 300-400 GB di RAM distribuita. Non è un difetto, è il prezzo dell'in-memory — ma è una voce da mettere nel preventivo il primo giorno, perché su cloud a consumo diventa la voce principale.

• La JVM va governata. Un cluster H2O è un sistema distribuito Java, con dimensionamento dell'heap, garbage collection, timeout di rete e nodi che ogni tanto escono dal gruppo. Chi arriva da un mondo puramente Python trova un livello di amministrazione che non aveva preventivato.

• Poca flessibilità per la ricerca. L'insieme degli algoritmi è chiuso. Se vi serve un'architettura nuova, una funzione di perdita esotica o l'idea di un articolo uscito il mese scorso, questo non è il posto. Driverless AI attenua il problema con le custom recipe, che permettono di iniettare trasformatori, modelli e metriche scritti in Python — ma è la versione commerciale.

• Asperità operative documentate. XGBoost non è disponibile su Windows né su Apple Silicon M1; l'esportazione MOJO non copre gli Stacked Ensembles. Sono limiti noti, non sorprese: il problema nasce quando li si incontra in fase di rilascio anziché in fase di valutazione.

• Il prezzo non è pubblico. È la sezione seguente, e merita più di un elenco puntato.

Costi

La licenza: che cosa è gratis sul serio

Non è un «gratuito» di facciata, e conviene essere espliciti su che cosa comprende. Sotto licenza Apache 2.0, senza limiti d'uso commerciale, avete: H2O-3 completo, AutoML incluso, tutti gli algoritmi, l'esportazione MOJO e POJO, il notebook Flow, le API per Python, R, Scala e Java, e Sparkling Water. A questo si aggiungono h2oGPT, anch'esso Apache 2.0, e i modelli open-weight Danube3 e H2OVL Mississippi.

Detto in modo operativo: un professionista o una PMI possono costruire un intero sistema di scoring in produzione — addestramento distribuito, modello esportato, valutazione dentro un microservizio Java — senza pagare una licenza. È una possibilità concreta e molto usata, ed è la ragione per cui la cifra di adozione dell'open source è di un ordine di grandezza superiore a quella dei clienti commerciali.

La memoria, che è la voce vera

Il software è gratuito, il sistema no, e la voce dominante è l'infrastruttura. La regola del quattro-a-uno sulla RAM significa che un cluster capace di lavorare comodamente su un dataset da 100 GB ha bisogno di qualche centinaio di gigabyte di memoria aggregata. Su un cloud pubblico, acceso otto ore al giorno, è una cifra che si vede in bolletta.

La mitigazione che funziona è architetturale, non contrattuale: cluster effimeri. Il cluster serve per addestrare, non per rispondere; si accende per il lavoro di addestramento, si spegne subito dopo, e la valutazione in produzione gira su un MOJO che del cluster non ha bisogno. Chi imposta il progetto così paga la memoria per le ore in cui la usa davvero, e la differenza fra le due impostazioni, su un anno, è dell'ordine di un fattore dieci.

Il listino che non esiste

Va detto senza giri di parole, perché condiziona ogni pianificazione: H2O.ai non pubblica prezzi per i prodotti commerciali. Non esiste una pagina di listino. La pagina che si raggiunge cercando la prova gratuita è, nella sostanza, un modulo di richiesta demo: non dichiara né una durata né un perimetro. Driverless AI, H2O AI Cloud, Enterprise h2oGPTe e i moduli correlati si acquistano parlando con un commerciale.

Nemmeno i marketplace cloud aiutano. Il listing ufficiale di H2O Driverless AI su AWS Marketplace è BYOL, «bring your own license»: il prezzo, dice la scheda, è gestito attraverso un rapporto di fatturazione esterno fra cliente e fornitore. Non c'è una tariffa oraria, non c'è un canone annuo.

Le cifre che circolano, e perché non vanno usate

Cercando «H2O.ai pricing» si trovano numeri, e questo è il punto in cui un articolo può fare danni. Due categorie di cifre vanno trattate con diffidenza.

La prima sono i prezzi orari attribuiti a H2O.ai sui marketplace: quando sono verificabili, appartengono a listing di terze parti che impacchettano la versione open source dentro un'immagine di sistema operativo. Quella tariffa paga l'impacchettamento e la macchina, non una licenza H2O.ai, e usarla come riferimento per Driverless AI è un errore di categoria.

La seconda sono i comparatori di software e i calcolatori di prezzo generati automaticamente, che riempiono la casella «prezzo» con stime senza metodologia dichiarata. Un preventivo costruito su quelle cifre non regge il primo incontro con il fornitore. La risposta onesta, quando un cliente chiede quanto costa, è: non è pubblico, serve una richiesta formale, e nel frattempo ecco quanto costerebbe farlo con l'open source.

Il costo che non si vede: competenza e manutenzione

Due voci che nei preventivi compaiono raramente e nei consuntivi sempre. La prima è la competenza: serve qualcuno che sappia leggere una leaderboard e sappia perché il modello in cima non è necessariamente quello da mettere in produzione. È la voce più sottovalutata e la più cara quando manca, perché il suo costo si manifesta come un modello sbagliato in esercizio.

La seconda è la manutenzione. Un modello in produzione va monitorato: la distribuzione dei dati in ingresso cambia, e con essa la qualità delle predizioni. Il monitoraggio del drift non è incluso in H2O-3 — sta in MLOps, che è commerciale. Costruirselo è fattibile e costa tempo; non farlo costa di più, solo più tardi.

Come si costruisce un preventivo serio

In assenza di listino, il preventivo si costruisce a rovescio: si parte dal valore, non dal costo. Le domande da avere scritte prima del primo incontro commerciale sono cinque.

1. Quale caso d'uso, con quale numero? «Ridurre del 15% le insolvenze su un portafoglio da X milioni» permette di dire se una licenza costa troppo. «Fare intelligenza artificiale» no.

2. Quanti utenti e quanta capacità di calcolo? Le licenze enterprise di questa famiglia si dimensionano tipicamente su utenti nominali e su nodi o GPU: arrivare con i numeri cambia la trattativa.

3. Quali moduli servono davvero? Driverless AI da solo, o anche MLOps, Feature Store, Document AI, la parte generativa? Ogni modulo è una voce separata.

4. Dove gira? Cloud gestito, on-premise o rete isolata: il costo e la complessità dell'installazione cambiano di conseguenza, e la terza opzione è quella che giustifica il prezzo.

5. Quanto costerebbe farlo con H2O-3 open source? È il vero termine di paragone — infrastruttura più giornate di lavoro — e va calcolato prima di firmare qualunque cosa. In molti progetti la risposta onesta è che l'open source basta.

Funzionalità avanzate e integrazioni

Driverless AI: il feature engineering come prodotto

Se l'AutoML di H2O-3 automatizza la scelta del modello, Driverless AI automatizza il passo precedente, quello dove si gioca la partita vera: la costruzione delle variabili. Genera e valuta trasformazioni — aggregazioni, codifiche sul target, interazioni fra colonne, trasformazioni temporali, estrazione da testo — e tiene quelle che migliorano la metrica in validazione, scartando le altre.

Sopra a questo aggiunge il supporto nativo per serie storiche, linguaggio naturale e immagini, l'esplorazione visuale automatica dei dati, il modulo MLI e l'esportazione della pipeline di valutazione. È progettato per sfruttare le GPU, incluse workstation con più schede, pur girando anche su hardware ordinario.

Vale la pena essere chiari su quale problema risolve, perché è un problema reale: in un progetto di machine learning su dati aziendali, la costruzione delle variabili è dove va la maggior parte del tempo umano ed è dove sta la maggior parte del guadagno di accuratezza. Automatizzare la scelta dell'algoritmo fa risparmiare ore; automatizzare la costruzione delle variabili fa risparmiare settimane.

Le custom recipe, cioè dove rientra il dominio

La caratteristica che più spesso convince i gruppi tecnici sono le custom recipe: la possibilità di scrivere in Python un trasformatore, un modello o una metrica propri e farli entrare nel motore di ricerca automatica, che li valuterà insieme a tutti gli altri.

È il compromesso fra scatola nera e controllo, e soprattutto è il modo in cui la conoscenza di dominio di un'azienda rientra in un processo altrimenti generico. Un attuario sa che una certa combinazione di variabili conta; una recipe la rende una candidata fra quelle che il sistema prova, invece che un suggerimento in una riunione. Ed è anche la risposta all'obiezione ricorrente contro l'AutoML — «non conosce il nostro settore» — che senza questo meccanismo sarebbe fondata.

Da dove legge: i connettori

Driverless AI 2.5.0 abilita di default il caricamento manuale, il filesystem locale e del server, HDFS, Amazon S3 e le recipe da file o URL. Si attivano da configurazione: Azure Blob Storage, Google Cloud Storage, Google BigQuery, Hive, MinIO, Snowflake, KDB+, JDBC, Databricks e Delta Lake, oltre allo storage interno e al Feature Store. Ogni connettore si usa con il proprio prefisso nel percorso.

Per un'architettura dati italiana tipica — un magazzino dati su Snowflake o BigQuery, un lago dati su object storage, un gestionale storico raggiungibile via JDBC — la copertura è sufficiente senza costruire trasferimenti intermedi. Una precisazione per onestà: Kafka non figura fra i connettori documentati. Lo streaming va gestito a monte, facendo atterrare i dati su storage o su una tabella; chi immagina di addestrare direttamente su un flusso sta immaginando un'architettura che questa piattaforma non propone.

Sparkling Water: H2O dentro Spark

Chi ha già un ecosistema Spark non deve scegliere fra i due. Sparkling Water esegue il cluster H2O dentro l'applicazione Spark, con conversione bidirezionale fra DataFrame Spark e frame H2O: si usa Spark per la preparazione dei dati, dove è forte, e H2O per la modellazione. Le versioni di Spark supportate vanno dalla 2.3 alla 3.5.

È un'integrazione che vale soprattutto in fase di adozione, perché permette di introdurre H2O in un'infrastruttura esistente senza smontarla — e quindi senza chiedere a nessuno di approvare una migrazione.

H2O AI Cloud: i pezzi che in open source mancano

La piattaforma commerciale raccoglie ciò che con il solo motore va costruito. La documentazione ufficiale elenca, fra gli altri:

• MLOps — rilascio, ciclo di vita, governance e monitoraggio dei modelli in produzione: è il pezzo che più spesso giustifica da solo il passaggio alla versione a pagamento;

• Feature Store — variabili condivise e versionate fra gruppi e progetti, per non ricalcolare né far divergere le stesse trasformazioni;

• H2O Drive, storage a oggetti integrato, con Admin Center, Audit Trail e analisi di utilizzo;

• Hydrogen Torch per il deep learning senza codice, Document AI, Label Genie per l'etichettatura, Model Validation e Model Analyzer;

• eScorer per la valutazione in produzione, l'AI App Store e i Notebook Labs;

• H2O Workflows, orchestrazione dichiarativa in YAML.

La parte generativa, che nel 2026 pesa

H2O.ai ha attraversato l'ondata generativa senza abbandonare il predittivo, e il risultato è una famiglia insolitamente ampia per un'azienda di queste dimensioni.

h2oGPT, sotto licenza Apache 2.0, fa chat e RAG su documenti in locale: database vettoriali Chroma, Weaviate o FAISS, ingestione di PDF, fogli di calcolo, documenti Word, immagini, fotogrammi video, audio, codice e Markdown, quantizzazione a 4 e 8 bit, adattatori LoRA, backend di esecuzione intercambiabili e un proxy API compatibile con quella di OpenAI. È il modo più rapido per mettere un assistente documentale dentro il perimetro aziendale senza mandare nulla fuori — ed è, non a caso, il progetto H2O.ai più scaricato dopo il motore.

Enterprise h2oGPTe è la versione commerciale, presentata come piattaforma generativa multi-agente: agenti autonomi che eseguono compiti in più passi, con ricerca sul web, accesso a basi di dati ed esecuzione iterativa di codice; RAG multimodale con citazioni tracciabili; estrazione documentale guidata da schema con uscita strutturata; guardrail e controlli sui dati personali; gestione granulare degli accessi. A marzo 2025 ha raggiunto il primo posto sulla leaderboard GAIA per agenti generalisti.

Ci sono poi i modelli propri, tutti open-weight: H2O Danube3, linguistici da 4 miliardi e 0,5 miliardi di parametri, addestrati da zero su circa cento GPU H100 con un corpus curato da 6.000 miliardi di token, pensati per l'esecuzione su dispositivi e per fare da guardrail leggero davanti a modelli più grandi; e H2OVL Mississippi, vision-language da 2 e 0,8 miliardi specializzati in OCR e comprensione di documenti, che a marzo 2026 hanno superato il milione di download mensili.

Infine tabH2O, presentato il 19 maggio 2026: un foundation model per dati tabellari aziendali che produce predizioni con una singola chiamata API, senza addestramento e senza costruzione di variabili. È tecnicamente la novità più interessante dell'anno e la riprendiamo parlando di tendenze, perché mette in discussione il paradigma su cui l'AutoML si regge da quindici anni.

Alternative a H2O.ai e confronto

Il confronto in una tabella

H2O contro DataRobot: la domanda vera

DataRobot è il concorrente diretto di Driverless AI e gioca sullo stesso campo: AutoML aziendale dall'ingestione al monitoraggio, con una copertura di governance più ampia e una presenza più forte in servizi finanziari e assicurativi. Nemmeno DataRobot pubblica prezzi.

La differenza che conta non è tecnica, è strategica: con H2O.ai si può cominciare gratis e salire, con DataRobot si entra dalla porta commerciale. Per un'organizzazione che non sa ancora se il machine learning le serva, questa asimmetria vale più di qualsiasi confronto di funzionalità, perché permette di scoprire se il problema è risolvibile prima di impegnare un budget. Per un'organizzazione che lo sa già e ha decine di modelli in esercizio, il vantaggio si assottiglia e contano la maturità degli strumenti di monitoraggio e l'ampiezza dell'ecosistema di partner.

Dataiku, che spesso compare nella stessa valutazione, non è propriamente un concorrente: è una piattaforma di lavoro collaborativa, con flussi visuali, notebook e ricette, dove l'AutoML è una funzione fra molte. Il suo terreno è la preparazione dei dati e la collaborazione fra profili tecnici e di business, e può integrare H2O anziché sostituirlo.

Sul posizionamento degli analisti, con la cautela d'obbligo: nel Magic Quadrant di Gartner per le AI Platforms del 22 giugno 2026 — quadrante rinominato quest'anno rispetto al precedente «Data Science and Machine Learning Platforms», proprio per includere i flussi agentici e i modelli linguistici, e che valuta 18 fornitori — H2O.ai è collocata fra i Visionary per il quarto anno consecutivo, mentre Dataiku, DataRobot e IBM dichiarano il posizionamento a Leader. Nella Forrester Wave sulle AI Platforms del terzo trimestre 2026, che valuta 15 fornitori, H2O.ai non è fra i valutati. Sono indicatori di visibilità nei comitati d'acquisto, non di qualità tecnica: utili per capire come soffia il vento, inutili per scegliere un algoritmo.

H2O contro le piattaforme del cloud

Su Google Cloud c'è un fatto del 2026 che cambia il quadro: la documentazione ufficiale dichiara che i servizi Vertex AI sono ora parte della Gemini Enterprise Agent Platform e che quella documentazione non è più aggiornata attivamente. Sul fronte AutoML, il modulo per il testo è stato spento il 15 giugno 2025 e quello per il video il 31 luglio 2025, sostituiti dal tuning di Gemini: restano attivi il tabellare e le immagini. Il prezzo pubblico dell'AutoML tabellare è di 21,252 dollari per node-hour, che scendono a 19,1268 con impegno annuale e a 17,0016 con impegno triennale.

Azure Machine Learning ha il modello di costo più chiaro del gruppo: la pagina ufficiale dichiara che non c'è alcun sovrapprezzo per l'uso del servizio, si pagano il calcolo e lo storage sottostanti. L'AutoML copre tabellare, linguaggio, visione e previsione di serie storiche, con un cruscotto dedicato all'AI responsabile. Per un'azienda già su Microsoft, è la scelta con meno attrito organizzativo.

SageMaker Autopilot condivide con H2O una filosofia da scatola trasparente: genera notebook ispezionabili che mostrano che cosa ha fatto e con quali parametri. L'interfaccia senza codice, Canvas, costa 1,9 dollari l'ora per postazione, con voci aggiuntive oltre i 5 GB di dati e per l'addestramento su immagini. La difficoltà, come spesso su AWS, non è il prezzo unitario: è la somma.

La differenza di fondo con H2O.ai è sempre la stessa, e si riassume in una frase: le piattaforme del cloud tolgono l'infrastruttura e, insieme, il controllo.

L'open source, che non è più quello di due anni fa

È il confronto che più è cambiato, e chi ha convinzioni ferme al 2024 conviene che le aggiorni.

La lettura è netta. AutoGluon oggi batte H2O-3 in accuratezza su dati tabellari quando tutto entra in una macchina sola, e lo fa grazie all'integrazione dei foundation model tabellari. Il vantaggio residuo di H2O-3 non è più l'accuratezza: è di essere l'unico AutoML open source realmente distribuito su cluster, e di produrre un artefatto di modello che gira dentro un'applicazione Java. Chi sceglie H2O-3 per un dataset da due milioni di righe su un server sta scegliendo lo strumento sbagliato per ragioni di abitudine.

Come si decide: cinque domande

1. I dati possono uscire dal perimetro aziendale? Se no, restano H2O.ai, Dataiku e DataRobot on-premise, e poco altro. È la domanda che elimina più candidati, ed è quella da fare per prima.

2. Il dataset entra nella memoria di una macchina sola? Se sì — ed è la situazione più comune, molto più di quanto si ammetta nelle riunioni — AutoGluon o FLAML risolvono gratis e meglio. H2O-3 diventa interessante quando la risposta è davvero no.

3. Dove gira il modello in produzione? Se il consumatore è un'applicazione Java, il formato MOJO vale da solo la scelta.

4. C'è già un lakehouse o un cloud dominante? Se tutto è su Databricks o su Azure, l'AutoML nativo parte con un vantaggio di integrazione difficile da colmare, e il costo organizzativo di introdurre un altro strumento è reale.

5. Quanto conta spiegare il modello a un revisore? Più conta, più gli strumenti di interpretabilità nativi spostano l'ago — ed è il terreno su cui H2O.ai e le piattaforme enterprise battono le scatole nere gestite.

Strategie di crescita usando H2O.ai

Quando ha senso adottarla, in concreto

Tre situazioni in cui la scelta si difende da sola, e una in cui non si difende.

Si difende quando i dati non possono uscire e serve comunque una piattaforma completa; quando il volume supera la memoria di una macchina e non si vuole riscrivere il codice per Spark; quando il modello deve essere consumato da software Java esistente e non si vuole introdurre un servizio di inferenza.

Non si difende quando il dataset sta comodamente in una macchina, non ci sono vincoli di perimetro e nessuno chiederà mai di spiegare il modello: in quel caso una libreria a nodo singolo fa lo stesso lavoro con meno amministrazione, ed è la raccomandazione onesta da dare.

Il percorso di adozione che funziona

Il progetto di machine learning che fallisce non fallisce quasi mai per ragioni tecniche: fallisce perché nessuno aveva definito che cosa volesse dire riuscire. Prima di aprire un notebook serve una frase della forma «oggi questo processo costa X, con un modello di precisione Y costerebbe Z». Se quella frase non si riesce a scrivere, il problema non è ancora pronto per un modello.

Dopo la frase, il percorso che funziona è breve e disciplinato: un'ora di AutoML su un estratto di dati storici, con il dataset di validazione separato per tempo e non a caso, se il fenomeno ha una dinamica temporale; la metrica scelta prima di vedere i risultati; e un confronto esplicito con la regola euristica che l'azienda usa oggi. Se l'AutoML non batte la regola del capo reparto, quella è l'informazione più preziosa dell'intero progetto — e va comunicata, non nascosta.

Dalla leaderboard alla produzione

Il modello in cima alla leaderboard raramente è quello da mettere in produzione, per tre motivi che vale la pena ricordare insieme: è quasi sempre uno Stacked Ensemble, e quindi non esportabile in MOJO; ha un tempo di predizione per riga più alto, e la leaderboard ve lo mostra apposta; ed è più difficile da spiegare a chi deve approvarlo.

La scelta ragionevole è il miglior modello singolo entro una soglia accettabile di perdita: spesso un GBM che cede mezzo punto di AUC rispetto all'ensemble, si esporta in un file e risponde in microsecondi dentro l'applicazione che deve usarlo. Mezzo punto di AUC contro un'intera infrastruttura di servizio è uno scambio che conviene quasi sempre, e dirlo al cliente in questi termini evita la discussione sul «ma il modello migliore era l'altro».

Monitorare, perché il mondo cambia

Un modello di abbandono addestrato prima di un cambio di listino è un modello sbagliato dal giorno del cambio di listino. Il monitoraggio — distribuzione delle variabili in ingresso, distribuzione delle predizioni, performance sui casi già risolti — è parte del progetto, non un'aggiunta successiva.

Con la piattaforma commerciale c'è il modulo MLOps; con il solo open source va costruito, e la costruzione va messa nel preventivo iniziale, non presentata sei mesi dopo come un imprevisto.

Per un professionista: che cosa vale questa competenza

Un freelance che lavora con il machine learning trova in H2O.ai una leva commerciale precisa, e vale la pena renderla esplicita. Il cliente non compra un modello: compra una decisione automatizzata che oggi prende a mano. La proposta che funziona ha tre tempi.

1. Una valutazione di fattibilità a prezzo fisso: pochi giorni, con H2O-3 open source, che finisce con un numero — c'è segnale utile, oppure no. Costa poco al cliente e protegge voi dai progetti impossibili.

2. Un progetto di sviluppo che arriva al modello esportato e integrato nel sistema esistente, con la documentazione di quali variabili contano e perché.

3. Un canone di manutenzione per monitoraggio e riaddestramento periodico, che è la parte di cui il cliente ha davvero bisogno e quella che rende sostenibile il rapporto.

Il fatto che il motore sia gratuito non abbassa il valore della consulenza: lo sposta dove sta realmente, cioè nella capacità di scegliere il problema giusto, preparare i dati, leggere i risultati con onestà e portare il modello dentro un sistema che funziona. È esattamente la competenza che l'AutoML non automatizza.

Formazione e mercato italiano

La documentazione ufficiale è completa e la curva d'apprendimento del motore è breve per chi conosce già il machine learning: il salto da fare è architetturale, non algoritmico. Il tempo di formazione vero non va sull'API, va sulla comprensione di che cosa significhi lavorare su dati che non stanno nel proprio processo.

Sul mercato italiano vale un'osservazione di posizionamento. La domanda esplicita per «H2O.ai» è ridotta, e cercarla direttamente non porta lontano. La domanda implicita — modelli predittivi che devono restare dentro l'azienda, in settori regolamentati come banche, assicurazioni, sanità e pubblica amministrazione — è invece consistente e cresce. Per un professionista, la competenza si vende meglio descrivendo il vincolo che risolve che nominando lo strumento: «modelli che non escono dal vostro perimetro e si spiegano a un revisore» è una frase che apre porte, «conosco H2O.ai» molto meno.

Tendenze future

I foundation model tabellari, che è il fatto tecnico dell'anno

Per quindici anni l'AutoML ha significato una cosa sola: cercare, fra molte combinazioni di algoritmi e iperparametri, quella che funziona meglio su questi dati. Nel 2026 quel paradigma ha un concorrente serio. I foundation model per dati tabellari arrivano pre-addestrati e producono predizioni con una sola inferenza, senza cercare nulla — come fa un modello linguistico con il testo.

I segnali sono due e convergono. AutoGluon 1.6 integra modelli di questa famiglia e dichiara un tasso di vittoria del 67% contro la versione precedente, con un addestramento ventisette volte più rapido. E H2O.ai ha presentato tabH2O a maggio 2026, con la stessa promessa: predizioni con una chiamata API, senza addestramento e senza costruzione di variabili.

Se la traiettoria regge — ed è presto per darla per acquisita, perché i confronti pubblicati vengono dagli autori — il vantaggio competitivo dell'AutoML classico, cioè cercare bene nello spazio dei modelli, si assottiglia parecchio. Restano in piedi le altre due gambe: dove girano i dati e come si spiega il risultato. Non è un caso che H2O.ai stia spingendo esattamente lì.

Gli agenti entrano nella data science

Che Gartner abbia rinominato il proprio quadrante da «Data Science and Machine Learning Platforms» a «AI Platforms» non è un fatto di marketing: certifica che il perimetro del mercato si è spostato. L'automazione non riguarda più solo la ricerca degli iperparametri, ma la formulazione delle ipotesi, la preparazione dei dati e la valutazione dei risultati — compiti che un agente può eseguire in più passi. È la direzione di Enterprise h2oGPTe, con agenti che accedono a basi di dati, eseguono codice iterativamente e citano le fonti di ciò che affermano.

La cautela d'obbligo: un agente che prepara i dati sbagliando in silenzio è più pericoloso di un analista che sbaglia lasciando una traccia. La tracciabilità — citazioni, registri di controllo, notebook generati — è ciò che rende questa automazione utilizzabile invece che soltanto impressionante, ed è il criterio con cui valutare le promesse dei prossimi due anni.

Modelli piccoli e intelligenza artificiale sovrana

La corsa ai modelli sempre più grandi ha prodotto, per reazione, un mercato per quelli piccoli: Danube3 da mezzo miliardo e quattro miliardi di parametri, Mississippi da 0,8 e 2 miliardi. Girano su hardware ordinario, dentro il perimetro, senza chiamare nessuno.

In Europa, dove la combinazione di normativa sui dati personali, vincoli settoriali e diffidenza verso fornitori extra-UE è la norma nelle grandi organizzazioni, questa è una domanda reale e in crescita. È lo stesso movimento che spiega la certificazione per il settore pubblico americano e l'integrazione con l'infrastruttura Dell: la scommessa dichiarata dell'azienda è che il valore si stia spostando dal modello più grande al modello che potete tenere in casa.

AI Act: che cosa vale davvero nel 2026

Il quadro normativo europeo è cambiato quest'anno e conviene averlo esatto, perché molte presentazioni circolano ancora con le scadenze vecchie. Il pacchetto Digital Omnibus, oggetto di accordo politico nel maggio 2026, ha rinviato una parte degli obblighi sui sistemi ad alto rischio. Secondo le analisi legali disponibili, la situazione che ne risulta è questa:

Il rinvio sposta le scadenze, non l'esigenza. Un modello che decide su un affidamento, su una selezione del personale o su una priorità sanitaria dovrà comunque essere documentato, tracciabile e spiegabile, e chi costruisce oggi conviene che lo costruisca già così: rimettere mano a un sistema in esercizio per aggiungere la tracciabilità costa molto più che prevederla. Schede di modello, tracciamento della provenienza dei dati, valori SHAP e registri di controllo restano il criterio di scelta reale fra piattaforme — ed è il terreno su cui gli strumenti nativi di interpretabilità valgono più di mezzo punto di AUC.

Che cosa non cambierà

Due cose, ed è utile tenerle presenti quando si legge l'entusiasmo per le novità. La prima: i dati aziendali continueranno a essere tabellari. Fatture, transazioni, anagrafiche, letture di sensori, righe d'ordine. Qualunque cosa succeda ai modelli generativi, il grosso delle decisioni automatizzabili in un'azienda riguarda tabelle, ed è il terreno su cui questa piattaforma è nata.

La seconda: il lavoro difficile resterà davanti al modello, non dentro. Capire quale decisione vale la pena automatizzare, ottenere i dati storici giusti, definire l'etichetta senza farsi ingannare da informazioni che al momento della predizione non esistono. Nessun foundation model tabellare risolve un problema mal posto — e chi sa porre bene il problema continuerà a valere più dello strumento che usa.

Domande frequenti

H2O.ai è davvero gratuito?

H2O-3, il motore distribuito con tutti i suoi algoritmi, l'AutoML, l'esportazione MOJO e POJO e le API per Python, R, Scala e Java, è rilasciato sotto licenza Apache 2.0 e si può usare in produzione commerciale senza pagare nulla. Lo stesso vale per h2oGPT e per i modelli open-weight Danube3 e H2OVL Mississippi. Sono a pagamento Driverless AI, H2O AI Cloud — quindi MLOps, Feature Store, Document AI e Hydrogen Torch — ed Enterprise h2oGPTe. Il costo del percorso gratuito non è però zero: è infrastruttura, perché la documentazione raccomanda una memoria di cluster pari a circa quattro volte la dimensione dei dati, più competenza e manutenzione.

Quanto costa H2O Driverless AI?

H2O.ai non pubblica un listino per i prodotti commerciali: il prezzo si concorda con il reparto commerciale. Nemmeno i marketplace cloud lo espongono, perché il listing ufficiale di Driverless AI su AWS Marketplace è «bring your own license», con la fatturazione gestita direttamente fra cliente e fornitore. Le cifre orarie che si trovano online e vengono attribuite a H2O.ai riguardano in genere immagini di terze parti che impacchettano la versione open source: non sono prezzi H2O.ai e non vanno usate in un preventivo.

Serve un cluster per usare H2O?

No. H2O-3 gira perfettamente su un singolo portatile, come processo Java locale comandato da Python o da R, ed è il modo corretto di iniziare. Il cluster serve quando i dati non entrano più nella memoria di una macchina sola. Il vantaggio della piattaforma è che il codice non cambia fra i due scenari: cambia soltanto quanti nodi si avviano.

H2O.ai serve anche per il deep learning?

In parte, e conviene sapere quale parte. H2O-3 include reti neurali feed-forward distribuite, adatte ai dati tabellari, ma non è un sostituto di PyTorch o TensorFlow: non ha architetture convoluzionali, ricorrenti o transformer, e il suo Deep Learning non è riproducibile di default. Il deep learning applicato — visione, linguaggio, documenti — nella piattaforma sta nei prodotti commerciali Hydrogen Torch, Document AI e H2O LLM Studio. Chi valuta H2O.ai per fare deep learning sta quindi valutando la parte a pagamento.

Posso mettere in produzione un modello H2O senza tenere acceso il cluster?

Sì, ed è il modo consigliato. Il modello addestrato si esporta in formato MOJO, un artefatto autoconsistente che si valuta con una piccola libreria Java: gira dentro un microservizio, una funzione serverless o un'applicazione, senza cluster e senza Python, con latenze nell'ordine dei microsecondi. L'eccezione da conoscere è che gli Stacked Ensembles prodotti dall'AutoML non sono esportabili in MOJO, quindi per la produzione si sceglie di norma il miglior modello singolo.

Conviene H2O.ai o l'AutoML del cloud che uso già?

Dipende da tre vincoli. Se i dati non possono uscire dal perimetro aziendale, le piattaforme cloud gestite escono dalla valutazione e H2O.ai — installabile on-premise e in rete isolata — resta fra le poche opzioni. Se invece siete già interamente su un cloud e il dataset è di dimensioni ordinarie, l'AutoML nativo è più rapido da adottare: Azure Machine Learning, per esempio, non applica alcun sovrapprezzo sul servizio e fa pagare solo il calcolo. Se il modello deve girare dentro un'applicazione Java esistente, il formato MOJO è un argomento che le altre piattaforme non hanno.

Esistono alternative open source valide a H2O-3?

Sì, ed è il panorama che più è cambiato di recente. AutoGluon, alla versione 1.6.1 dell'agosto 2026, è oggi la scelta più accurata su dati tabellari quando tutto entra in una macchina sola; FLAML è ottimo quando il vincolo è il budget di calcolo; MLJAR genera report di spiegabilità automatici. Vanno invece considerati con prudenza PyCaret, la cui ultima release risale all'aprile 2024, e auto-sklearn, fermo al settembre 2022. Il vantaggio residuo di H2O-3 non è più l'accuratezza: è essere l'unico AutoML open source realmente distribuito su cluster.

H2O.ai è adatto a una PMI italiana?

Se il volume di dati è quello tipico di una PMI, qualche milione di righe, H2O-3 open source è ampiamente sufficiente e il costo del progetto è tutto in infrastruttura e competenze, non in licenze. Il caso in cui la piattaforma commerciale diventa interessante è diverso: molti modelli da mantenere contemporaneamente, obblighi di spiegabilità verso un revisore o un'autorità, oppure vincoli che impongono di tenere ogni cosa dentro il perimetro aziendale.

In sintesi

H2O.ai è una scelta architetturale prima che un prodotto: tenere i dati in memoria, distribuirli su un cluster e mandare il calcolo da loro anziché il contrario. Da quella scelta discende tutto il resto — la scalabilità senza riscrittura, l'artefatto di modello che gira ovunque, la possibilità di installare l'intera piattaforma dentro una rete chiusa.

Le tre cose da tenere a mente quando la si valuta nel 2026 sono queste. Il confine fra gratuito e commerciale è netto, e l'open source copre molti più casi d'uso di quanti l'azienda media immagini: vale la pena verificarlo prima di aprire una trattativa. I prezzi commerciali non sono pubblici, quindi il preventivo si costruisce partendo dal valore del caso d'uso e tenendo come termine di paragone il costo di farlo con il motore libero. E il vantaggio competitivo si sta spostando: i foundation model tabellari erodono il valore della ricerca automatica, mentre la sovranità del dato e la tracciabilità del modello diventano il terreno decisivo — che è esattamente dove l'azienda ha scelto di posizionarsi.

Per chi sviluppa software o lavora come professionista indipendente, la conclusione operativa è breve: si comincia con H2O-3 su un portatile, un dataset reale e un'ora di AutoML. La risposta che arriva da quel pomeriggio — c'è segnale, oppure no — vale più di qualunque valutazione fatta sulla carta, e non costa niente ottenerla.