[AI] - L’app è sul PC, ma dove finiscono i documenti? AI locale e cloud senza equivoci

Una cartella sul computer, un’app installata e una domanda apparentemente semplice: «Riassumi questo documento». 

Il risultato compare sullo schermo. Il file originale è ancora nella sua cartella. Sembra naturale pensare che tutto il lavoro sia rimasto sul PC. È proprio questo passaggio, però, che occorre verificare.

Per orientarsi servono tre informazioni distinte: dove si trova il file, dove vengono eseguite le operazioni e dove gira il modello che genera la risposta. La parola «locale», da sola, non le chiarisce tutte.

Lo stesso documento, tre percorsi diversi

Immaginiamo un esempio: una relazione aziendale contiene nomi di clienti, importi e problemi ancora aperti. La richiesta è: «Prepara una sintesi per la riunione di domani». È un caso illustrativo, non un esperimento eseguito su documenti reali.

Il percorso dei contenuti: tre configurazioni illustrative

Configurazione	Dal documento alla risposta	Che cosa verificare
Servizio web con modello cloud	PC → caricamento o testo incollato → servizio remoto → risposta nel browser	Dati trasmessi, conservazione e accessi previsti dal servizio.
App desktop con modello cloud	File sul PC → lettura locale → contenuti inclusi nella richiesta al modello remoto → risposta e possibile salvataggio sul PC	Il file può rimanere nella cartella anche se il suo contenuto viene trasmesso.
Modello e analisi documentale sul PC	File sul PC → elaborazione locale → modello locale → risposta locale	Il percorso resta locale soltanto per le componenti così configurate: controllare strumenti esterni e condivisioni.

Lo schema rappresenta flussi, non configurazioni universali. Le operazioni possono coinvolgere il file completo, estratti, immagini o risultati degli strumenti. Collegamenti, sincronizzazione e servizi aggiuntivi possono introdurre altri passaggi. Riferimenti: [1], [2], [3], [4].

1. Un’app desktop può usare un modello remoto

L’installazione sul PC descrive dove si trova l’interfaccia. Non basta a stabilire dove viene elaborata la richiesta. Quando un agente usa un modello remoto, il contesto inviato al modello può comprendere contenuti letti dai file e risultati delle operazioni: per esempio un estratto del documento o l’output di un comando. Il percorso concreto va verificato nella configurazione e nella documentazione del prodotto. [1]

Nel nostro esempio il documento potrebbe restare nella cartella aziendale e il riassunto essere salvato accanto all’originale. Questo non dimostrerebbe che i contenuti non siano transitati altrove.

Il documento resta nella cartella, ma il suo contenuto può attraversare la rete. L’assenza di un caricamento manuale non costituisce una verifica del percorso dei dati.

Con strumenti come Codex va controllato anche il tipo di accesso: la documentazione distingue l’accesso con account ChatGPT da quello con chiave API, ai quali si applicano le rispettive regole dell’organizzazione o del workspace. Non è corretto trasferire automaticamente le condizioni di un canale all’altro. [2]

2. Un modello locale può elaborare documenti senza inviarli a un servizio AI remoto

LM Studio documenta la possibilità di utilizzare offline i modelli già scaricati e di analizzare documenti localmente. Occorre procurarsi prima modello e componenti necessari; ricerca di nuovi modelli, download e aggiornamenti richiedono invece connettività. [3]

Nella terza configurazione del diagramma la relazione viene elaborata sul computer. Questa opzione merita una prova quando il requisito è evitare il trasferimento dei contenuti a un servizio di inferenza esterno.

La verifica deve riguardare l’intero percorso: estrazione del testo, eventuale OCR per le scansioni, ricerca nei documenti e generazione della risposta. Un modello locale non rende automaticamente locali gli strumenti che gli vengono collegati. Le impostazioni di LM Studio prevedono, per esempio, collegamenti MCP e la possibilità di rendere il server accessibile ad altri dispositivi della rete; la documentazione segnala rischi legati all’accesso a file e dati privati. [4]

Va controllato separatamente anche dove siano salvati documenti e conversazioni: se una cartella è sincronizzata o condivisa, occorre considerare quel canale oltre all’AI. È una domanda di verifica sul proprio ambiente, non una conclusione che si possa ricavare dal nome dell’app.

3. Web non significa documento pubblico

Caricare un documento in un servizio remoto non equivale, di per sé, a pubblicarlo su Internet. Per capire chi possa accedervi bisogna esaminare servizio, account, condivisioni e condizioni applicabili. Nel caso di ChatGPT Work, la documentazione distingue controlli di accesso, infrastruttura cloud, connessioni autorizzate e conservazione secondo categoria di dati e configurazione. Queste caratteristiche non vanno attribuite indistintamente a qualsiasi prodotto o piano. [5]

La domanda utile diventa concreta: chi può aprire questa conversazione? Chi può vedere il file? È stata attivata una condivisione? Che cosa prevedono le condizioni su accessi del personale autorizzato, fornitori e richieste di legge? Le risposte devono provenire dalle regole del servizio e dell’organizzazione, non dalle rassicurazioni generate dall’assistente.

«Non usato per addestrare» e «non conservato» sono cose diverse

Un esempio documentato aiuta a evitare l’equivoco: OpenAI dichiara che i dati inviati alle proprie API non vengono utilizzati per addestrare i modelli, salvo adesione esplicita alla condivisione. La stessa documentazione descrive però log di monitoraggio e dati conservati per alcune funzionalità. Le condizioni dipendono dalle API, dalle funzioni e dai controlli applicabili; non sono una regola universale per tutte le chat. [6]

Prima di affidare un documento a un servizio, quindi, distinguerei quattro verifiche: dove viene elaborato, quanto viene conservato, chi può accedervi e per quali usi può essere impiegato. Una risposta favorevole sull’addestramento non esaurisce le altre tre.

Come sceglierei nella pratica

Quelli che seguono sono criteri operativi proposti, non una classifica dei prodotti.

• Materiale pubblico o già autorizzato al trasferimento: proverei il servizio approvato dall’organizzazione e valuterei qualità, facilità d’uso e tempi sul compito reale.
• Documenti con vincolo di permanenza su infrastruttura controllata: verificherei prima il flusso completo e sceglierei una soluzione compatibile con quel vincolo. Un’app desktop collegata al cloud non è sufficiente a soddisfarlo.
• Attività su molte cartelle e applicazioni del PC: valuterei un agente con strumenti locali, definendo cartelle consentite, operazioni autorizzate e contenuti trasferibili.
• Soluzione locale: proverei un campione rappresentativo per misurare utilità della risposta e tempo di revisione, considerando hardware, energia, aggiornamenti e manutenzione.

Non assumerei che il cloud sia sempre più accurato o che il locale sia sempre più economico. Per decidere confronterei lo stesso compito, gli stessi criteri di accettazione e il costo del controllo umano.

Un piccolo controllo prima del documento vero

Userei una relazione inventata, con nomi e importi fittizi, per verificare caricamento, file generati e strumenti attivati. Poi confronterei il comportamento osservato con le impostazioni dichiarate. Se serve dimostrare che nessun contenuto esce dal perimetro autorizzato, affiderei all’IT una verifica dei flussi coerente con le regole aziendali.

Una prova offline può verificare che una funzione operi senza rete in quella configurazione e in quel momento. Non dimostra da sola che, una volta ristabilita la connessione, nessun componente possa sincronizzare o trasmettere dati. Analogamente, domandare all’AI «Hai inviato qualcosa?» non sostituisce documentazione, impostazioni e registrazioni verificabili.

Cinque domande da tenere accanto al documento

1. Dove gira il modello? Sul computer, su un server aziendale o presso un fornitore esterno?
2. Quali contenuti vengono trasmessi? File interi, estratti, immagini, schermate o risultati degli strumenti?
3. Chi può accedere alle copie? Controllare account, workspace, condivisioni, amministratori e condizioni del servizio.
4. Che cosa rimane e per quanto tempo? Distinguere originali, allegati, cronologia, log, copie sincronizzate e backup.
5. Questa configurazione è autorizzata per questi dati? La disponibilità tecnica dell’accesso non sostituisce il permesso di utilizzarlo.

Il criterio che propongo è semplice: prima di scegliere il modello, disegna il percorso dei dati. Se non sai indicare dove il contenuto viene letto, elaborato, conservato e condiviso, manca un’informazione necessaria per decidere.

Fonti consultate

Verifica delle fonti: 20 ottobre 2026. Le indicazioni sui prodotti descrivono la documentazione consultata in questa data; vanno ricontrollate quando cambiano configurazione, piano o funzionalità. Gli esempi sono illustrativi e le proposte operative sono valutazioni editoriali.

1. OpenAI, Shell. Esempio di separazione tra modello remoto, esecuzione locale e restituzione dei risultati. Non descrive ogni configurazione desktop.
2. OpenAI, Authentication. Modalità di accesso e regole applicabili ai client Codex.
3. LM Studio, Offline Operation. Funzioni locali e operazioni che richiedono rete.
4. LM Studio, Server Settings. Accesso in rete, autenticazione e collegamenti MCP.
5. OpenAI, ChatGPT Work cloud security. Controlli di accesso, connessioni e conservazione nel perimetro descritto dalla pagina.
6. OpenAI, Data controls in the OpenAI platform. Distinzione fra utilizzo per addestramento e conservazione dei dati API.

[AI] – Le attività che non dovrebbero essere automatizzate

Quando velocità ed efficienza aumentano il rischio invece di ridurlo

Automatizzare un’attività significa molto più che eseguirla più velocemente. Significa decidere chi può agire, quali controlli devono essere superati, come si riconosce un errore e chi risponde delle conseguenze.

L’intelligenza artificiale rende possibile automatizzare operazioni che fino a poco tempo fa richiedevano una persona: analizzare documenti, generare codice, modificare configurazioni, rispondere a clienti, classificare richieste e prendere decisioni operative.

La domanda, però, non dovrebbe essere soltanto:

L’intelligenza artificiale è capace di farlo?

Dovremmo chiederci anche:

Possiamo verificare il risultato, limitare il danno e ripristinare la situazione se qualcosa va storto?

Il NIST AI Risk Management Framework prevede che la valutazione iniziale possa portare anche a una decisione di tipo go/no-go: prima di introdurre un sistema AI bisogna stabilire se quella soluzione sia appropriata e realmente necessaria.

Automatizzare non è una scelta binaria

Un’attività può essere automatizzata a livelli diversi.

L’AI può:

1. raccogliere e organizzare le informazioni;
2. proporre un’azione;
3. preparare l’azione per l’approvazione;
4. eseguire direttamente l’azione;
5. eseguirla senza che una persona ne sia informata.

Il rischio cambia radicalmente passando da un livello al successivo.

Un sistema che prepara una query SQL da revisionare non ha lo stesso potere di un agente che la esegue autonomamente sul database di produzione. Un’AI che prepara una risposta email non produce le stesse conseguenze di un sistema che la invia automaticamente al cliente.

Spesso, quindi, il problema non è stabilire se utilizzare l’intelligenza artificiale, ma decidere fino a quale punto debba arrivare la sua autonomia.

Le attività rare e poco conosciute

Un’attività eseguita frequentemente genera esempi, controlli, eccezioni conosciute e risultati confrontabili.

Un’operazione rara presenta invece meno evidenze. Potrebbero mancare:

• casi precedenti affidabili;
• procedure consolidate;
• test rappresentativi;
• persone che sappiano riconoscere rapidamente un errore;
• modalità di ripristino già sperimentate.

Automatizzare un’operazione rara può sembrare conveniente proprio perché nessuno desidera eseguirla manualmente. Ma la rarità riduce anche la possibilità di verificare che l’automazione funzioni in condizioni reali.

In questi casi l’AI può essere utile per raccogliere informazioni, confrontare documenti e preparare un piano. L’esecuzione dovrebbe però restare sotto il controllo di una persona competente.

Le azioni difficili da annullare

Alcune operazioni sono tecnicamente reversibili, ma le loro conseguenze non lo sono.

È possibile ripristinare un database da un backup, ma non sempre si possono eliminare le decisioni prese utilizzando dati errati. È possibile cancellare un messaggio, ma non impedire che sia stato letto. È possibile correggere una pubblicazione, ma non ritirare tutte le copie già diffuse.

Rientrano in questa categoria:

• cancellazioni di dati;
• modifiche in produzione;
• invio di comunicazioni esterne;
• pubblicazioni;
• assegnazione o revoca di autorizzazioni;
• decisioni che incidono su persone, pagamenti o servizi;
• operazioni che possono interrompere sistemi aziendali.

L’automazione può preparare queste attività e controllarne i prerequisiti. L’esecuzione finale richiede invece un’autorizzazione consapevole e riferita all’azione precisa.

Le attività il cui risultato non è verificabile

Un processo automatico è più affidabile quando il suo risultato può essere controllato con criteri indipendenti.

Una compilazione può produrre un esito verificabile. Una query può essere confrontata con conteggi attesi. Un file può essere controllato attraverso un hash. Una procedura può essere provata in un ambiente separato.

Il problema nasce quando la verifica dipende dallo stesso sistema che ha generato il risultato.

Se un’AI produce un’analisi e poi dichiara che l’analisi è corretta, non abbiamo una verifica indipendente. Abbiamo soltanto una seconda affermazione dello stesso sistema.

Il NIST raccomanda processi di test, valutazione, verifica e validazione e osserva che una revisione indipendente può ridurre errori, distorsioni interne e conflitti di interesse. Inoltre, il costo degli errori dovrebbe essere valutato insieme ai benefici attesi dell’automazione. (NIST AI RMF Core)

Quando il risultato non può essere verificato in modo proporzionato, l’AI dovrebbe fornire supporto e informazioni, non produrre autonomamente la decisione definitiva.

Le decisioni che riguardano persone e diritti

Se un errore modifica soltanto una bozza interna, il danno è normalmente limitato. Se lo stesso errore incide su una persona, il rischio cambia.

Questo vale, per esempio, per decisioni relative a:

• selezione e valutazione del personale;
• concessione di servizi o benefici;
• credito e assicurazioni;
• salute e sicurezza;
• istruzione;
• accessi e autorizzazioni;
• procedimenti amministrativi o giudiziari.

Il Regolamento europeo sull’intelligenza artificiale richiede, per i sistemi classificati ad alto rischio, una sorveglianza umana proporzionata al rischio, al livello di autonomia e al contesto di utilizzo. La persona incaricata deve poter comprendere limiti e anomalie, interpretare il risultato, evitare di affidarsi automaticamente all’output e intervenire o fermare il sistema. (Regolamento UE 2024/1689, articolo 14)

Queste disposizioni riguardano specificamente i sistemi ad alto rischio definiti dal Regolamento. Il principio organizzativo è però più generale: all’aumentare delle conseguenze deve aumentare anche la qualità del controllo.

Il falso controllo umano

Inserire una conferma non garantisce che esista una vera supervisione.

Un operatore che riceve decine di richieste identiche potrebbe iniziare ad approvarle senza leggerle. Una persona priva delle competenze necessarie potrebbe non riconoscere un errore. Un dipendente potrebbe individuare il problema ma non avere l’autorità per fermare il processo.

Il controllo umano è effettivo soltanto se la persona:

• dispone delle informazioni necessarie;
• comprende l’operazione e le sue conseguenze;
• ha tempo sufficiente per valutarla;
• può respingere o modificare la proposta;
• possiede l’autorità per interrompere il sistema;
• non viene penalizzata quando decide di fermarsi.

Un controllo umano che non può comprendere, contestare o fermare il sistema è soltanto un passaggio formale.

Il profilo NIST dedicato all’AI generativa sottolinea che applicazioni e contesti diversi possono richiedere livelli differenti di supervisione, revisione, tracciamento e controllo organizzativo.

Un criterio operativo

Non esiste una formula universale che stabilisca automaticamente cosa non debba essere automatizzato. Prima di concedere autonomia operativa a un sistema AI possiamo però porre alcune domande.

Domanda	Se la risposta è negativa
L’errore può essere rilevato prima che produca conseguenze?	Limitare l’AI alla preparazione o alla proposta
L’azione può essere annullata completamente?	Richiedere un’approvazione umana specifica
Il risultato può essere verificato con un controllo indipendente?	Non affidare all’AI la decisione finale
Esistono procedure provate per errori ed eccezioni?	Mantenere l’esecuzione manuale
Una persona competente può fermare realmente il processo?	Non considerare presente una supervisione effettiva
Responsabilità e destinatari delle notifiche sono definiti?	Non avviare l’automazione operativa

Questa tabella è una proposta editoriale di valutazione, non una formula normativa e non sostituisce l’analisi tecnica, organizzativa o legale del singolo caso.

Automatizzare la preparazione, preservare la decisione

Rifiutare l’automazione completa non significa rinunciare all’intelligenza artificiale.

L’AI può:

• raccogliere le evidenze;
• evidenziare anomalie;
• preparare comandi e documenti;
• confrontare alternative;
• simulare gli effetti;
• verificare prerequisiti;
• registrare le operazioni;
• segnalare quando è necessaria una decisione.

La persona mantiene invece la responsabilità della scelta e dell’esecuzione nei passaggi che producono conseguenze rilevanti.

Questa collaborazione può essere meno spettacolare di un sistema completamente autonomo, ma spesso è più utile: riduce il lavoro ripetitivo senza nascondere la responsabilità dietro l’automazione.

La domanda decisiva

L’attività più pericolosa da automatizzare non è necessariamente quella tecnicamente più complessa.

È quella nella quale l’errore:

• arriva troppo tardi per essere fermato;
• non può essere riconosciuto con certezza;
• produce conseguenze difficili da annullare;
• coinvolge persone che non possono contestarlo;
• non ha un responsabile chiaramente identificato.

Prima di automatizzare un’attività bisogna quindi progettare anche il modo in cui potrebbe fallire.

La vera maturità non consiste nel concedere all’AI il massimo livello di autonomia possibile. Consiste nel sapere dove fermarla.

---

Fonti consultate

• National Institute of Standards and Technology, Artificial Intelligence Risk Management Framework 1.0, pubblicato il 26 gennaio 2023. Il NIST segnala che la versione 1.0 è attualmente in revisione.
• NIST AI Resource Center, AI RMF Core.
• National Institute of Standards and Technology, Artificial Intelligence Risk Management Framework: Generative Artificial Intelligence Profile – NIST AI 600-1, 26 luglio 2024.
• Unione europea, Regolamento (UE) 2024/1689, articolo 14 – Sorveglianza umana.

Fonti e formulazioni caratteristiche verificate il 14 ottobre 2026. 

[AI] – Codex e LM Studio: modelli locali, costi, benefici e privacy reale

 Quando l’intelligenza artificiale lavora sul nostro computer, i dati restano davvero in casa?

Codex può utilizzare LM Studio come fornitore di un modello linguistico eseguito direttamente sul proprio computer. L’integrazione permette di impiegare Codex per analizzare codice, creare script e lavorare sui file senza affidare necessariamente l’elaborazione del modello ai server di OpenAI.

È però importante distinguere tre aspetti diversi:

• dove viene eseguito il modello;
• quali strumenti esterni vengono utilizzati;
• quali dati tecnici possono essere trasmessi dal programma che ospita il modello.

Dire semplicemente «uso un modello locale» non è sufficiente per concludere che nessuna informazione lasci il computer.

Come funziona l’integrazione

LM Studio può esporre sul computer un servizio compatibile con l’API Responses utilizzata da Codex. Normalmente il servizio viene pubblicato all’indirizzo locale:

http://localhost:1234

Codex invia le richieste a questo indirizzo invece di trasmetterle a un modello ospitato sui server di OpenAI.

Il percorso diventa quindi:

Utente
   ↓
Codex installato sul computer
   ↓
LM Studio su localhost
   ↓
Modello caricato nella RAM o nella GPU
   ↓
Risposta restituita a Codex

La documentazione ufficiale di LM Studio conferma che Codex può collegarsi al suo endpoint locale /v1/responses. La modalità può essere avviata tramite il parametro --oss. 

[LM Studio – Integrazione con Codex]

Un esempio essenziale è:

lms server start --port 1234
codex --oss --local-provider lmstudio

È anche possibile indicare espressamente un modello già scaricato:

codex --oss --local-provider lmstudio -m nome-del-modello

Codex supporta ufficialmente lmstudio come provider locale e consente di impostarlo come predefinito nella configurazione personale. [OpenAI – Comandi di Codex]

I dati restano davvero in locale?

La risposta corretta è: sì, ma soltanto se l’intero percorso di elaborazione è configurato per essere locale.

Secondo l’informativa privacy di LM Studio, quando si scarica un modello e lo si esegue localmente, messaggi, documenti e cronologia non vengono trasmessi da LM Studio verso i suoi server. L’elaborazione avviene sul dispositivo e i dati vengono eventualmente conservati localmente. 

[LM Studio – Privacy Policy]

In una configurazione correttamente locale:

• il prompt viene inviato da Codex a localhost;
• l’inferenza viene eseguita dalla CPU o dalla GPU del computer;
• la risposta torna a Codex attraverso la rete locale interna;
• OpenAI non riceve la richiesta attraverso i propri server di inferenza;
• non si sostengono costi API a token per quella elaborazione.

Ci sono però alcune eccezioni importanti.

La telemetria di Codex

La documentazione di OpenAI indica che Codex invia per impostazione predefinita una quantità limitata di dati anonimi relativi all’utilizzo e allo stato del programma. OpenAI dichiara che queste metriche non contengono informazioni personali. Possono comprendere, per esempio, versione dell’applicazione, modello selezionato, modalità di autenticazione e tipo di strumento utilizzato.

Questa telemetria è separata dal contenuto del prompt e può essere disabilitata. [OpenAI – Configurazione avanzata di Codex]

Nel file personale:

C:\Users\<utente>\.codex\config.toml

si può inserire:

oss_provider = "lmstudio"
web_search = "disabled"

[analytics]
enabled = false

[feedback]
enabled = false

Questa configurazione:

• seleziona LM Studio come provider locale predefinito;
• disabilita la ricerca web;
• disabilita le metriche analitiche;
• disabilita l’invio di feedback.

Gli strumenti esterni

Anche con un modello locale, i dati possono uscire dal computer se Codex utilizza:

• ricerca sul Web;
• browser;
• plugin o connettori;
• server MCP remoti;
• repository o servizi cloud;
• modelli OpenAI o altri modelli cloud;
• LM Link verso un altro computer;
• funzioni cloud o Web Search di LM Studio.

Un modello locale non rende automaticamente locali anche gli strumenti che può richiamare.

Questa chat non diventa locale

La conversazione svolta nell’applicazione ChatGPT o attraverso un servizio OpenAI non deve essere confusa con una sessione Codex CLI collegata direttamente a LM Studio.

Il fatto di installare LM Studio non rende retroattivamente locale una chat già trasmessa a un servizio cloud. Per lavorare realmente in locale bisogna avviare Codex con il provider LM Studio e verificare che la sessione utilizzi effettivamente quel provider.

Locale non significa cancellato

I dati possono non uscire dal computer ma rimanere memorizzati sul disco sotto forma di:

• cronologia delle conversazioni;
• sessioni Codex;
• log;
• cache;
• file temporanei;
• risultati prodotti;
• cronologie conservate da LM Studio.

Quindi «resta in locale» non significa necessariamente «non viene conservato». Significa che la conservazione avviene sul proprio dispositivo e deve essere gestita con adeguate politiche di accesso, cifratura, backup e cancellazione.

Quattro possibili scenari

Configurazione	Dove avviene l’elaborazione	I dati possono uscire dal PC?
Codex CLI, LM Studio locale, strumenti esterni disabilitati	Sul computer	Non per l’inferenza; può restare telemetria se non disabilitata
Codex con LM Studio e ricerca Web	Modello sul PC, ricerca su Internet	Sì, attraverso il servizio di ricerca
Codex con modello OpenAI	Server OpenAI	Sì, secondo le condizioni del servizio utilizzato
LM Studio con modello cloud	Infrastruttura cloud di LM Studio	Sì, anche se LM Studio dichiara Zero Data Retention per tali servizi

Configurazione minima del computer

I requisiti ufficiali di LM Studio per Windows prevedono:

• sistema x64 oppure ARM supportato;
• CPU x64 con istruzioni AVX2;
• almeno 16 GB di RAM raccomandati;
• GPU con almeno 4 GB di memoria video dedicata raccomandati.

Questi requisiti permettono di avviare LM Studio, ma non garantiscono prestazioni adeguate per un modello destinato ad attività complesse di programmazione. [LM Studio – Requisiti di sistema]

Una configurazione pratica può essere valutata così:

Componente	Minimo funzionale	Minimo pratico per Codex	Configurazione consigliata
CPU	x64 con AVX2	6 core moderni	8–16 core moderni
RAM	16 GB	32 GB	64 GB
GPU dedicata	4 GB VRAM	12–16 GB VRAM	24 GB VRAM
Disco	SSD	NVMe con almeno 100 GB liberi	NVMe con 200 GB o più
Sistema	Windows x64/ARM supportato	Windows 11 a 64 bit	Windows 11 aggiornato
Modelli indicativi	3–4 miliardi di parametri	7–20 miliardi quantizzati	modelli più grandi o contesti più estesi

La colonna “minimo funzionale” deriva dai requisiti ufficiali; le altre due sono raccomandazioni pratiche e non requisiti dichiarati dal produttore.

Per gpt-oss-20b, una guida OpenAI archiviata indicava almeno 16 GB di VRAM. Per gpt-oss-120b indicava circa 60 GB o più, collocandolo fuori dalla portata di un normale PC. Questi valori devono essere considerati indicativi perché dipendono da quantizzazione, contesto e versione del runtime. [OpenAI – Esecuzione di gpt-oss con LM Studio]

Prima di caricare un modello si può ottenere una stima delle risorse:

lms load --estimate-only nome-del-modello

LM Studio calcola la memoria prevista considerando modello, contesto e utilizzo della GPU. 

[LM Studio – Caricamento dei modelli]

Costi

Costi che si riducono

Con un modello locale non si paga a OpenAI o a LM Studio un prezzo per ogni token generato localmente.

Il piano gratuito di LM Studio comprende l’esecuzione dei modelli locali. I modelli locali non consumano crediti destinati all’inferenza cloud. [LM Studio – Prezzi]

Questo può risultare conveniente quando:

• vengono eseguite molte elaborazioni;
• si analizzano frequentemente repository estesi;
• il computer è già sufficientemente potente;
• non occorre sempre la qualità di un modello cloud di frontiera;
• la riservatezza è più importante della velocità.

Costi che rimangono

L’elaborazione locale non è completamente gratuita. I costi vengono trasferiti dal consumo a token all’infrastruttura:

• acquisto o aggiornamento della GPU;
• maggiore quantità di RAM;
• spazio su disco per i modelli;
• consumo elettrico;
• manutenzione e aggiornamenti;
• tempo necessario per scegliere e collaudare i modelli;
• prestazioni generalmente inferiori rispetto ai migliori modelli cloud;
• eventuale abbonamento OpenAI utilizzato per funzioni separate da quelle locali.

La convenienza dipende quindi dal carico di lavoro. Per un uso occasionale, il cloud può essere economicamente più conveniente. Per attività frequenti e ripetitive, un computer già disponibile può ridurre il costo marginale di ogni elaborazione.

Benefici principali

Maggiore controllo sui dati

Codice sorgente, documenti e prompt possono essere elaborati senza inviarli a un servizio di inferenza esterno.

Funzionamento offline

Dopo aver scaricato applicazione, runtime e modelli, LM Studio può funzionare senza connessione Internet. La connessione rimane necessaria per scaricare modelli, controllare aggiornamenti o usare funzioni cloud. [LM Studio – Funzionamento offline]

Nessun costo per token locale

È possibile effettuare molte prove senza incrementare il costo di una API cloud.

Scelta del modello

Si possono confrontare modelli, quantizzazioni e configurazioni differenti in base alle risorse disponibili e al tipo di lavoro.

Controllo tecnico verificabile

È possibile misurare utilizzo di RAM, GPU, prestazioni e traffico di rete, costruendo una configurazione sottoposta a controlli tecnici anziché affidarsi soltanto a una dichiarazione di riservatezza.

Limiti e svantaggi

Qualità non sempre equivalente

Un modello locale di piccole o medie dimensioni può essere meno affidabile di un modello cloud avanzato nel:

• comprendere repository molto estesi;
• coordinare numerosi strumenti;
• mantenere contesti lunghi;
• produrre modifiche complesse;
• individuare errori sottili;
• seguire istruzioni articolate per molte fasi.

Hardware necessario

Le prestazioni dipendono direttamente da GPU, memoria disponibile, quantizzazione e lunghezza del contesto.

Maggiore responsabilità dell’utente

Chi usa il modello deve gestire:

• aggiornamenti;
• sicurezza del server locale;
• accesso ai file;
• backup e cronologie;
• licenze dei modelli;
• verifica della qualità;
• protezione della rete.

Compatibilità variabile

Non tutti i modelli supportano nello stesso modo ragionamento, chiamata degli strumenti e generazione strutturata. La compatibilità con l’API non garantisce che un modello sappia usare Codex con la stessa efficacia di un modello progettato specificamente per attività agentiche.

Configurazione prudente per dati riservati

Per avvicinarsi a un ambiente realmente locale conviene:

1. usare Codex CLI con --oss --local-provider lmstudio;
2. mantenere il server LM Studio su 127.0.0.1;
3. non abilitarne l’accesso dalla rete locale;
4. disabilitare Web Search, plugin e MCP remoti;
5. non selezionare modelli cloud;
6. disabilitare analytics e feedback;
7. cifrare il disco e proteggere l’account Windows;
8. controllare log e cronologie locali;
9. limitare a Codex l’accesso alle sole directory necessarie;
10. verificare il traffico di rete con firewall o strumenti di monitoraggio.

Se il server LM Studio viene esposto in rete, è opportuno abilitarne l’autenticazione mediante token. Per impostazione predefinita, infatti, il server locale non richiede autenticazione. [LM Studio – Autenticazione del server]

Per requisiti particolarmente rigorosi, la garanzia non dovrebbe dipendere soltanto dalla configurazione dichiarata: l’accesso alla rete dovrebbe essere tecnicamente bloccato o limitato e il comportamento verificato osservando il traffico effettivo.

Conclusione

Codex e LM Studio permettono di costruire un ambiente nel quale il modello elabora codice e documenti direttamente sul proprio computer. In questa configurazione OpenAI non riceve il prompt attraverso i propri server di inferenza e non applica un costo API per i token generati localmente.

Non basta però selezionare un modello locale per rendere locale l’intero processo. Telemetria, ricerca Web, plugin, MCP remoti, servizi cloud e cronologie devono essere considerati separatamente.

La soluzione più affidabile consiste nel combinare modello locale, strumenti locali, telemetria disabilitata, accesso alla rete controllato e verifiche tecniche. La riservatezza non deve dipendere esclusivamente da una promessa software: deve essere sostenuta da una configurazione nella quale le comunicazioni non autorizzate siano impedite e quelle consentite possano essere controllate.

Fonti consultate

Fonti ufficiali verificate l’11 ottobre 2026:

• OpenAI – Comandi di Codex e provider locali
• OpenAI – Configurazione avanzata, modalità OSS e telemetria
• OpenAI – Riferimento della configurazione Codex
• LM Studio – Integrazione con Codex
• LM Studio – Requisiti di sistema
• LM Studio – Funzionamento offline
• LM Studio – Informativa privacy
• LM Studio – Prezzi
• LM Studio – Autenticazione del server

[AI] – Codex: Astra, Sol o Luna? Come scegliere modello e livello di ragionamento

Lavorando con codex e di conseguenza chatgp spesso ci si chiede ma quale modello posso utilizzare per il mio lavoro e soprattutto quale livello di ragionamento. Da tenere ben presente che la scelta sbagliata di un modello non fa altro che prolungare i tempi mentre l'utilizzo sbagliato del livello non fa altro che aumentare i costi. Di seguito un breve confronto tra modelli e livelli che al momento sono presenti in codex.

I modelli e i livelli di ragionamento sono due cose diverse:

• il modello determina capacità, velocità e costo di base;
• il livello determina quanto quel modello deve approfondire prima di rispondere.

Modelli principali

Modello	Caratteristiche	Quando conviene
GPT-6 Astra	È il modello più potente. Migliore per ragionamento complesso, software engineering, navigazione, uso di applicazioni e attività professionali articolate.	Analisi molto ambigue, architetture importanti, diagnosi difficili, documenti complessi, decisioni basate su fonti contrastanti.
GPT-6.1 Sol	Prestazioni vicine ad Astra, ma con un rapporto migliore tra qualità, velocità e consumo.	Scelta abituale per sviluppo, database, Oracle, analisi di dati, documenti e attività quotidiane complesse.
GPT-6 Luna	Il più veloce ed economico. È adatto a compiti circoscritti e ad alto volume.	Estrazioni, classificazioni, modifiche semplici, riepiloghi, conversioni, controlli ripetitivi e codice poco complesso.
GPT-6 Sol	Predecessore di GPT-6.1 Sol, progettato per coding complesso e flussi agentici.	Compatibilità con lavori già iniziati oppure confronto con risultati precedenti. Per nuovi lavori preferirei normalmente 6.1 Sol.
GPT-5.6 Sol	Modello precedente ancora valido per lavoro professionale e sviluppo.	Riproduzione di risultati esistenti o progetti già calibrati su questa versione. Non è normalmente la prima scelta per un nuovo progetto.

OpenAI presenta Astra come il modello di massima capacità, GPT-6.1 Sol come quello bilanciato e Luna come il più efficiente. [Documentazione ufficiale GPT-6, catalogo dei modelli]

Come riferimento, nelle API Astra costa per token molto più di Sol e Luna; ciò non significa necessariamente che questi siano i costi applicati al tuo abbonamento Codex, perché disponibilità e limiti dell’app dipendono dal piano. [Confronto ufficiale dei modelli]

Livelli di ragionamento

Livello	Comportamento	Utilizzo consigliato
None	Nessun ragionamento esteso; massima velocità.	Estrazioni, classificazioni e trasformazioni elementari. Non disponibile su Astra e GPT-6.1 Sol.
Low	Ragionamento breve ed efficiente.	Piccole modifiche, query semplici, bozze, riepiloghi e problemi ben delimitati.
Medium	Equilibrio tra accuratezza, tempo e consumo.	Coding ordinario, analisi dati, SQL, documenti e ricerca. È il punto di partenza consigliato nella maggior parte dei casi.
High	Analisi più approfondita e maggior controllo delle alternative.	Debug complesso, progettazione, tuning, architettura, correlazione di molte evidenze.
Extra High / xhigh	Ragionamento molto esteso.	Revisione critica, ricerca profonda, sicurezza, migrazioni e attività agentiche lunghe.
Max	Massimo ragionamento disponibile.	Solo problemi eccezionalmente difficili, dove qualità e verifica contano più di tempo e consumo.

Aumentando il livello, generalmente aumentano:

• tempo necessario;
• token di ragionamento;
• consumo delle risorse;
• probabilità di esplorare alternative e individuare errori.

Non è però garantito che max produca sempre un risultato migliore: per attività semplici può soltanto rallentare il lavoro. OpenAI consiglia xhigh e max solamente quando verifiche rappresentative dimostrano un vantaggio concreto. [Guida ufficiale ai livelli di ragionamento]

Modalità Standard, Pro e Ultra

Queste non vanno confuse con i livelli precedenti:

• Standard: esecuzione normale.
• Pro: il modello svolge più lavoro interno prima di fornire una risposta unica. Può migliorare l’affidabilità dei problemi difficili, ma aumenta latenza e token.
• Ultra, quando disponibile in Codex: è associata a un’esecuzione più ampia, che può comprendere orchestrazione parallela e più agenti. Non è semplicemente un livello superiore a max.

La modalità Pro e il reasoning effort sono indipendenti: per esempio può esistere Pro + Medium oppure Pro + High. [Documentazione sul reasoning mode]

Scelta pratica per le tue attività

Per i tuoi progetti userei questa impostazione:

Attività	Scelta consigliata
Normale sviluppo Oracle, SQL e PL/SQL	GPT-6.1 Sol – Medium
Diagnosi di performance	GPT-6.1 Sol – High
Analisi con fonti e regole articolate	GPT-6.1 Sol – High
Valutazione strategica o requisiti molto ambigui	Astra – High
Produzione di documentazione	Astra – High oppure GPT-6.1 Sol – High
Modifiche ripetitive, classificazioni e semplici CSV	Luna – Low o Medium
Migrazioni particolarmente rischiose o diagnosi eccezionali	Astra – xhigh, passando a max solo se necessario

In sintesi: 

• GPT-6.1 Sol con livello Medium è la scelta predefinita migliore per un lavoro da sviluppatore.
• Passerei a High quando servono diagnosi o progettazione approfondita; 
• Userei Astra nei casi più delicati, ambigui o importanti; 
• Luna per risparmiare tempo e risorse nei lavori semplici e ripetitivi.

[AI] - Quando due agenti AI concordano e hanno entrambi torto

Un secondo agente AI che conferma il lavoro del primo può sembrare una garanzia. Uno produce una risposta, l’altro la controlla, entrambi arrivano alla stessa conclusione: dunque deve essere corretta.

Non necessariamente.

Il problema non è che due agenti siano inutili. Possono migliorare il lavoro, trovare omissioni e rendere più espliciti i dubbi. Il problema nasce quando il loro accordo viene trattato come una prova, pur senza verificare se i due abbiano ragionato davvero in modo indipendente e, soprattutto, se abbiano controllato fonti esterne affidabili.

L’accordo che sembra una verifica

Immaginiamo un caso semplice. Il primo agente riceve una documentazione incompleta e deduce che una tabella sia la sorgente corretta di un dato. Il secondo agente legge la stessa documentazione, riceve lo stesso prompt e trova plausibile la stessa deduzione.

Il risultato finale può apparire rassicurante:

• Agente 1: “La sorgente è questa tabella.”
• Agente 2: “Confermato.”

Ma nessuno dei due ha verificato il database, letto il SQL originario o confrontato il risultato con un caso reale. Il secondo agente non ha validato un fatto: ha validato la plausibilità della risposta del primo.

Due conferme non diventano una prova solo perché sono due.

Perché gli agenti possono sbagliare insieme

L’indipendenza non dipende dal numero di finestre aperte. Dipende da ciò che ciascun agente vede, dagli strumenti che usa e dalle fonti che può controllare.

Due agenti possono condividere:

• lo stesso modello o modelli addestrati su fonti simili;
• lo stesso prompt ambiguo;
• lo stesso documento incompleto;
• gli stessi dati obsoleti;
• lo stesso errore iniziale presentato in modo convincente;
• la stessa tendenza a completare un vuoto con una risposta plausibile.

In questi casi il secondo agente può diventare un amplificatore del primo. L’errore non viene corretto: riceve una seconda voce, una forma più ordinata e un’apparenza di consenso.

Questa è la parte più insidiosa: il fallimento non appare come conflitto. Appare come collaborazione riuscita.

Il dibattito tra agenti può aiutare, ma non è una garanzia

La ricerca sui sistemi multi-agente mostra che il confronto fra più modelli può migliorare alcuni compiti di ragionamento e ridurre certe risposte errate. Non è quindi ragionevole concludere che usare più agenti sia inutile.

• Du et al., Improving Factuality and Reasoning in Language Models through Multiagent Debate

Ma il beneficio non autorizza una scorciatoia: “se concordano, allora è vero”.

Un lavoro di ricerca più recente descrive proprio una “illusione di coerenza”: agenti che raggiungono la stessa risposta possono non condividere una catena di ragionamento coerente o dimostrabile. È una ricerca preliminare e non una regola universale, ma evidenzia un controllo utile: verificare non soltanto la risposta finale, bensì le evidenze che l’hanno prodotta. 

• Wang e Yang, The Consistency Illusion

Il consenso, quindi, può essere un segnale da investigare. Non è il criterio di accettazione.

Come rendere utile il secondo agente

Un secondo agente deve avere un compito diverso dal primo.

Se il primo produce una bozza, il secondo non dovrebbe limitarsi a dire se la bozza “sembra corretta”. Dovrebbe lavorare come un revisore con esiti limitati e verificabili:

Esito	Significato
Confermato	La fonte primaria dimostra l’affermazione.
Non dimostrato	La bozza afferma qualcosa che le fonti disponibili non provano.
In contrasto	La fonte dice qualcosa di diverso.
Proposta	È una scelta progettuale, non un fatto estratto.

Il secondo agente deve ricevere le fonti originali, non solo il riassunto del primo. Deve poter segnalare una lacuna invece di essere spinto a raggiungere per forza una conclusione.

Meglio ancora se i due agenti hanno percorsi differenti:

• il primo interpreta requisiti e prepara una soluzione;
• il secondo confronta ogni affermazione con evidenze primarie;
• uno script controlla elementi oggettivi, come nomi di tabelle, colonne, date, importi o riferimenti;
• l’operatore decide sui punti che restano ambigui.

Questa separazione non elimina ogni errore, ma impedisce che il consenso sia scambiato per dimostrazione.

La verifica esterna resta indispensabile

Il punto non è diffidare dell’AI per principio. È attribuire a ogni controllo il valore che possiede davvero.

Un agente che conferma un altro agente può aumentare la qualità della revisione. Un controllo automatico può rilevare incongruenze ripetitive. Un test può dimostrare un comportamento specifico. Una fonte primaria può dimostrare un fatto.

Nessuno di questi elementi, da solo, prova tutto il resto.

Il NIST raccomanda una gestione del rischio AI continua, con attività di governo, mappatura, misurazione e gestione: l’affidabilità non deriva da un singolo segnale positivo, ma da controlli proporzionati al rischio. 

• NIST AI RMF NIST Generative AI Profile

La domanda utile non è: “Quanti agenti sono d’accordo?”

È: “Quale evidenza indipendente dimostra che hanno ragione?”

Conclusione

Due agenti AI possono collaborare bene. Possono anche condividere lo stesso errore con una sicurezza raddoppiata.

Per questo un sistema affidabile non usa il secondo agente come timbro di approvazione. Lo usa per cercare contraddizioni, fonti mancanti, assunzioni nascoste e punti non dimostrati.

Quando due agenti concordano, il lavoro non è finito.

È il momento di chiedere: su quali prove?

Fonti consultate

• NIST, Artificial Intelligence Risk Management Framework: Generative AI Profile, verificata l’8 ottobre 2026.
• Du et al., Improving Factuality and Reasoning in Language Models through Multiagent Debate, 2023.
• Wang e Yang, The Consistency Illusion: How Multi-Agent Debate Hides Reasoning Misalignment, preprint, 2026.