Per molto tempo Ollama è stato associato soprattutto a un’idea semplice: scaricare un modello open e farlo funzionare sulla propria macchina.

Il 31 agosto 2026 l’azienda ha compiuto un altro passo nella direzione di una piattaforma ibrida, introducendo per i nuovi piani Pro, Max e Team un sistema di pricing cloud basato sui token. La notizia ufficiale è disponibile sul blog di Ollama.

Il cambiamento è interessante non tanto perché introduce un nuovo listino, quanto perché rende più evidente una trasformazione del mercato. La distinzione tra AI locale e AI cloud sta diventando meno rigida. Lo stesso ecosistema può offrire modelli eseguiti sul computer o sul server dell’organizzazione e, quando necessario, accesso remoto a modelli più grandi o a capacità di calcolo non disponibili localmente.

Ollama dichiara che i piani Pro, Max e Team includono ora un pool mensile di crediti consumato in base ai token utilizzati

  • Pro costa 20 dollari al mese e comprende 60 dollari di utilizzo,
  • Max 100 dollari con 300 dollari inclusi
  • e Team 500 dollari con 1.000 dollari di utilizzo condiviso e utenti illimitati.

Terminato il credito incluso, è possibile continuare alla tariffa per token pubblicata. Ollama dichiara inoltre zero data retention per le richieste cloud, di non registrare i prompt e di non utilizzarli per l’addestramento.

Non solo Ollama: dal “locale contro cloud” a una scelta per workload

Per un’azienda la parte più interessante è il cambio di prospettiva. Fino a poco tempo fa la decisione veniva spesso presentata come una contrapposizione: utilizzare un modello locale per avere maggiore controllo oppure un servizio cloud per ottenere maggiore capacità. Oggi questa distinzione può essere fatta a livello di singolo workload.

Leggi anche:  AI in azienda: il costo vero è l’infrastruttura

Un modello locale può essere adatto alla classificazione di documenti, all’estrazione di informazioni, alla generazione di bozze interne o alle domande su una knowledge base. Un modello esterno più grande può essere utilizzato soltanto per richieste complesse, quando la qualità aggiuntiva giustifica il costo e l’esposizione controllata del contesto.

Il pricing per token rende questo confronto più misurabile: un’organizzazione può calcolare quanto costa completare una determinata attività e confrontarlo con il costo dell’hardware locale, dell’energia, della manutenzione e della capacità inutilizzata.

Non esiste una risposta universale: un server locale può essere conveniente per workload continui e prevedibili, mentre il cloud può essere efficiente per picchi, attività sporadiche o modelli troppo grandi per l’infrastruttura disponibile.

Il vero asset non è il modello, ma la conoscenza aziendale

Questa evoluzione rende ancora più importante separare la knowledge base dal modello generativo.

Documenti, email, database, procedure, newsletter, siti e altre fonti costituiscono il patrimonio informativo dell’organizzazione. Il modello è invece un motore che può cambiare rapidamente.

Se l’intera architettura viene costruita attorno a un singolo provider, sostituire il modello può diventare costoso. Se invece ingestion, indicizzazione, retrieval, permessi e workflow sono indipendenti, il motore può essere scelto in funzione del task.

Leggi anche:  Intelligenza Artificiale: solitudine e mercato digitale

È qui che il RAG mantiene un ruolo centrale anche con modelli dotati di finestre di contesto sempre più ampie. Inviare indiscriminatamente grandi quantità di documentazione a un modello remoto non è necessariamente la scelta migliore.

Il retrieval può selezionare localmente soltanto i passaggi pertinenti e costruire un contesto minimo. Questo può ridurre token, latenza ed esposizione dei dati.

L’approccio non garantisce automaticamente conformità normativa: GDPR, AI Act e altre regole dipendono dal caso d’uso, dai dati trattati, dai ruoli e dagli obblighi applicabili. Tuttavia, minimizzazione, controllo degli accessi e tracciabilità sono proprietà architetturali utili per una governance più solida.

I costi dell’AI diventano un parametro di routing

Quando il costo è espresso per token, può diventare una variabile del routing.

Un sistema aziendale può decidere che una richiesta semplice venga gestita da un modello locale, mentre un’analisi complessa venga inviata a un modello remoto. La scelta può considerare qualità, sensibilità dei dati, latenza, costo e disponibilità dell’hardware.

Questo approccio è particolarmente interessante per studi professionali e PMI. Non tutte le organizzazioni hanno bisogno di una grande infrastruttura GPU, ma molte possono utilizzare modelli locali per una parte rilevante del lavoro.

Allo stesso tempo, rinunciare completamente ai modelli cloud può significare non poter utilizzare capacità frontier quando servono.

Leggi anche:  AI aziendale: perché capire il modello non basta

Un’architettura ibrida consente di evitare entrambe le rigidità. Il modello locale non deve essere una scelta ideologica e il cloud non deve diventare una dipendenza totale.

Gol-IA: governare locale e cloud dallo stesso hub

Questo scenario coincide con uno dei principi alla base di Gol-IA.

L’obiettivo non è imporre un modello specifico, ma mantenere sotto il controllo dell’organizzazione applicazione, knowledge base, retrieval, utenti, fonti e workflow.

Per realtà con pochi utenti Gol-IA può funzionare completamente on-premise con modelli open. Quando il carico cresce o un’attività richiede capacità maggiori, l’architettura può utilizzare modelli esterni inviando soltanto il contesto selezionato necessario alla risposta. La documentazione proprietaria e la knowledge base non devono quindi essere trasferite integralmente al provider.

Contattaci per avere informazioni in anteprima su Gol-IA:


La Consulenza AI può aiutare a costruire questa matrice decisionale: quali workload restano locali, quali possono utilizzare il cloud, quali dati possono uscire dal perimetro, quali modelli offrono il miglior rapporto tra qualità e costo e quali controlli devono essere applicati.

Il nuovo pricing di Ollama è quindi più di un aggiornamento commerciale. È un altro segnale del fatto che l’AI enterprise si sta spostando verso architetture multi-modello e ibride.

La domanda non sarà più semplicemente quale LLM scegliere, ma come orchestrare modelli diversi mantenendo stabile e governabile il patrimonio informativo dell’organizzazione.


Lascia un commento

Il tuo indirizzo email non sarà pubblicato. I campi obbligatori sono contrassegnati *