mercoledì 14 ottobre 2026

[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.

DomandaSe 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

Fonti e formulazioni caratteristiche verificate il 14 ottobre 2026. 

domenica 11 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

ConfigurazioneDove avviene l’elaborazioneI dati possono uscire dal PC?
Codex CLI, LM Studio locale, strumenti esterni disabilitatiSul computerNon per l’inferenza; può restare telemetria se non disabilitata
Codex con LM Studio e ricerca WebModello sul PC, ricerca su InternetSì, attraverso il servizio di ricerca
Codex con modello OpenAIServer OpenAISì, secondo le condizioni del servizio utilizzato
LM Studio con modello cloudInfrastruttura cloud di LM StudioSì, 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ì:

ComponenteMinimo funzionaleMinimo pratico per CodexConfigurazione consigliata
CPUx64 con AVX26 core moderni8–16 core moderni
RAM16 GB32 GB64 GB
GPU dedicata4 GB VRAM12–16 GB VRAM24 GB VRAM
DiscoSSDNVMe con almeno 100 GB liberiNVMe con 200 GB o più
SistemaWindows x64/ARM supportatoWindows 11 a 64 bitWindows 11 aggiornato
Modelli indicativi3–4 miliardi di parametri7–20 miliardi quantizzatimodelli 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:

[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

ModelloCaratteristicheQuando 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 SolPrestazioni 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 LunaIl 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 SolPredecessore 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 SolModello 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

LivelloComportamentoUtilizzo consigliato
NoneNessun ragionamento esteso; massima velocità.Estrazioni, classificazioni e trasformazioni elementari. Non disponibile su Astra e GPT-6.1 Sol.
LowRagionamento breve ed efficiente.Piccole modifiche, query semplici, bozze, riepiloghi e problemi ben delimitati.
MediumEquilibrio tra accuratezza, tempo e consumo.Coding ordinario, analisi dati, SQL, documenti e ricerca. È il punto di partenza consigliato nella maggior parte dei casi.
HighAnalisi più approfondita e maggior controllo delle alternative.Debug complesso, progettazione, tuning, architettura, correlazione di molte evidenze.
Extra High / xhighRagionamento molto esteso.Revisione critica, ricerca profonda, sicurezza, migrazioni e attività agentiche lunghe.
MaxMassimo 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/SQLGPT-6.1 Sol – Medium
Diagnosi di performanceGPT-6.1 Sol – High
Analisi con fonti e regole articolateGPT-6.1 Sol – High
Valutazione strategica o requisiti molto ambiguiAstra – High
Produzione di documentazioneAstra – High oppure GPT-6.1 Sol – High
Modifiche ripetitive, classificazioni e semplici CSVLuna – Low o Medium
Migrazioni particolarmente rischiose o diagnosi eccezionaliAstra – 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.

giovedì 8 ottobre 2026

[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.

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. 

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:

EsitoSignificato
ConfermatoLa fonte primaria dimostra l’affermazione.
Non dimostratoLa bozza afferma qualcosa che le fonti disponibili non provano.
In contrastoLa 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. 

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.

lunedì 5 ottobre 2026

[AI] - Codex - COMPUTER USE E DESKTOP REMOTO: Configurare l'AI per lavorare sotto controllo

Un assistente AI che spiega dove cliccare è utile.

Un assistente che può osservare un’applicazione, leggere un errore e interagire con la sua interfaccia offre possibilità ulteriori, ma richiede anche maggiore attenzione.

La configurazione non riguarda soltanto l’abilitazione di un componente. Occorre stabilire quale ambiente l’AI può utilizzare, quali operazioni sono autorizzate e come verificare il risultato.

In questo articolo vediamo un caso concreto:

Codex sul computer locale, una sessione di Desktop remoto e un browser aperto sulla macchina remota, utilizzato per lavorare con Oracle Data Transforms.

1. LA CONFIGURAZIONE CHE VOGLIAMO OTTENERE

Nella prova da cui nasce questo articolo, il percorso operativo è stato questo:

Computer locale Windows
        |
        v
Codex con Computer Use
        |
        v
Finestra di Connessione Desktop remoto
        |
        v
Browser sulla macchina remota
        |
        v
Oracle Data Transforms

L’assistente ha potuto osservare il contenuto della finestra remota e interagire con l’interfaccia: aprire dettagli, scorrere elenchi e leggere messaggi di errore.
Questo non equivale a una connessione diretta al database.
L’AI utilizza la sessione grafica già aperta dall’operatore.
Non abbiamo utilizzato Zoom e non è stato necessario condividere lo schermo attraverso una videoconferenza.
Questa è una verifica relativa alla configurazione provata, non una garanzia di compatibilità con qualsiasi ambiente remoto.

2. ABILITARE COMPUTER USE

La documentazione OpenAI indica la disponibilità di Computer Use nell’app desktop, su Windows e macOS, nelle regioni supportate e secondo le abilitazioni dell’ambiente.
Il percorso di configurazione documentato è:
1. Aprire l’app desktop e selezionare Codex oppure   ChatGPT Work.
2. Aprire Plugins → Computer Use.
3. Installare o abilitare il plugin, secondo quanto mostrato.
4. Verificare che siano attivi il server e la relativa skill.
5. Aprire Settings → Computer use e controllare gli accessi alle applicazioni.

Gli amministratori possono imporre restrizioni. Il permesso di utilizzare un’applicazione resta distinto
dall’autorizzazione a compiere una specifica operazione.
Non conviene quindi interpretare un’opzione come “consenti sempre” come un mandato generale a modificare tutto ciò che appare sullo schermo.

La domanda tecnica è:
“L’assistente può accedere a questa applicazione?”

La domanda operativa è diversa:
“Che cosa gli abbiamo autorizzato a fare al suo interno?”

3. PREPARARE LA SESSIONE REMOTA

Su Windows, Computer Use opera sul desktop attivo e mouse e tastiera in primo piano.
La documentazione raccomanda di mantenere visibile l’applicazione e di evitare attività concorrenti
sulla stessa interfaccia.
Per il nostro scenario, propongo questa preparazione:
- L’operatore apre Desktop remoto e completa personalmente   l’autenticazione.
- Sulla macchina remota apre il browser e accede   all’applicazione.
- Porta in evidenza la pagina interessata.
- Comunica all’assistente quale finestra utilizzare.
- Durante le azioni dell’assistente evita di spostare contemporaneamente mouse, finestre e selezioni.

Bisogna anche distinguere il browser locale da quello remoto. Nella configurazione provata, il browser Oracle era dentro la finestra di Desktop remoto: il controllo avveniva attraverso quella finestra, non attraverso un collegamento diretto al browser.
Dire soltanto “usa Chrome” sarebbe stato ambiguo.
Una richiesta iniziale più precisa è:
  1.     Usa Computer Use sulla finestra di Connessione Desktop remoto.
  2.     L’applicazione interessata è Oracle Data Transforms, aperta nel browser della macchina remota.
  3.     Per ora descrivi soltanto la schermata visibile.
  4.     Non cliccare e non digitare.
Questo primo controllo serve a verificare che utente e assistente stiano parlando dello stesso ambiente.

4. RENDERE PERSISTENTI LE REGOLE DI COMPORTAMENTO

Codex può leggere istruzioni persistenti da file AGENTS.md.
La configurazione prevede istruzioni globali e istruzioni specifiche del progetto.
Il percorso globale predefinito è nella directory .codex dell’utente, salvo configurazioni differenti.
Su Windows, normalmente:

    C:\Users\<utente>\.codex\AGENTS.md

Occorre verificare quali istruzioni siano effettivamente caricate: esistono precedenze, file di override e limiti di dimensione.
Un file molto lungo non è automaticamente una configurazione migliore.
Per un utilizzo guidato, una regola proposta potrebbe essere:

  UTILIZZO GUIDATO DI COMPUTER USE
    Prima di interagire con un’applicazione, identifica la finestra e chiedi all’utente quale operazione eseguire. Esegui soltanto il passo autorizzato, verifica il risultato e fermati in attesa della successiva indicazione.
    Non effettuare autonomamente salvataggi, esecuzioni, importazioni, cancellazioni o modifiche.
    Se l’utente autorizza esplicitamente una sequenza delimitata, completala soltanto entro il perimetro  indicato. 
    In caso di errore, finestra diversa, risultato inatteso o richiesta di autenticazione, fermati e informa l’utente. Alla richiesta “fermati”, interrompi le ulteriori azioni.

Questa è una proposta di istruzioni operative, non una funzione di sicurezza aggiuntiva.
AGENTS.md orienta il comportamento dell’assistente;
non revoca i privilegi dell’account utilizzato.

OpenAI raccomanda di affiancare le istruzioni a controlli tecnici che ne facciano rispettare le regole.
In un ambiente aziendale, questo significa valutare anche account dedicati, privilegi limitati e ambienti
di prova.
Scrivere “non modificare il database” non equivale a utilizzare un account tecnicamente incapace
di modificarlo.

5. ESEMPIO: VERIFICARE UN’IMPORTAZIONE DI METADATI ORACLE

 Supponiamo di avere modificato una tabella di staging e di averne rilanciato l’importazione nel repository di Data Transforms.
La verifica richiesta riguarda una nuova colonna, chiamata nell’esempio ID_CARICAMENTO.
Non chiediamo all’AI di correggere automaticamente qualsiasi problema. Definiamo invece una sequenza precisa:

    Ti autorizzo esclusivamente a questa sequenza di verifica:
    1. Apri i dettagli del job di importazione indicato.
    2. Leggi lo stato finale.
    3. Se è terminato correttamente, apri l’entità  STG_ATTIVITA.
    4. Verifica se compare ID_CARICAMENTO e riporta il tipo.
    5. Se il job è in errore, leggi il messaggio del passo fallito.
    Non rilanciare il job.
    Non modificare l’entità.
    Non salvare.
    Non eseguire query o procedure.
    Alla fine riferisci ciò che hai verificato e fermati.

Il risultato utile non è un generico “tutto a posto”. È un resoconto che separa le evidenze:
  •     Job controllato:    identificativo e nome.
  •     Stato osservato:    successo oppure errore.
  •     Entità controllata:    nome esatto.
  •     Colonna:    presente, assente oppure non verificabile.
  •     Tipo osservato:    valore mostrato dall’interfaccia.
  •     Modifiche eseguite:    nessuna.
  •     Limiti della verifica:  eventuali controlli non completati.
Se il job fallisce, l’assistente deve riportare il punto di errore.
Non dovrebbe trasformare automaticamente la diagnosi in una cancellazione delle entità o in un nuovo tentativo di importazione.
Anche una verifica riuscita ha un limite: vedere la colonna nel repository conferma quel metadato, ma non dimostra che tutti i dataflow siano già aggiornati o che il caricamento dei dati funzionerà.

6. PREPARARE NON SIGNIFICA ESEGUIRE


Un secondo incarico potrebbe riguardare la preparazione di una variabile o di un dataflow.
È importante concordare il punto di arresto:

  •     Apri la configurazione e compila esclusivamente i campi concordati.
  •     Fermati prima di Salva, Convalida, Anteprima  o Esegui.
  •     Mostrami i valori inseriti e attendi la mia conferma.

La prudenza non riguarda soltanto i pulsanti evidentemente distruttivi.
Prima di utilizzare una funzione di anteprima o convalida occorre capire se comporti una semplice verifica oppure l’esecuzione di qualcosa.

La regola proposta è:
“Se non è chiaro l’effetto di un comando, prima si chiarisce il comportamento e poi si autorizza l’azione.”

7. LIMITI PRATICI: PUÒ ESSERE PIÙ LENTO DELL’OPERATORE


Nella nostra prova, la navigazione ha richiesto più passaggi di osservazione, azione e controllo.
L’utente ha poi scelto di riprendere manualmente alcune operazioni perché il procedimento risultava lento. È un limite da dichiarare. Computer Use può essere utile per leggere errori, verificare configurazioni o accompagnare un’attività poco familiare.
Non è necessariamente il mezzo più efficiente per ripetere decine di operazioni identiche.
Per attività ripetibili, la documentazione OpenAI suggerisce di preferire integrazioni strutturate, quando disponibili.
La mia raccomandazione operativa è quindi:
  • - Usare l’interfaccia per osservare e comprendere.
  • - Usare script, procedure o integrazioni documentate per le elaborazioni ripetitive.
  • - Mantenere un operatore responsabile delle autorizzazioni e delle verifiche.
Il processo consegnato dovrebbe restare eseguibile anche senza la presenza dell’assistente.

8. IL CONFINE RIGUARDA ANCHE I DATI VISIBILI


Computer Use può elaborare contenuti visibili e schermate delle applicazioni autorizzate.
Prima di utilizzarlo occorre quindi valutare quali informazioni saranno esposte e se il loro trattamento
sia consentito.
Per questo esempio sono sufficienti nomi dimostrativi e metadati tecnici.
Non servono password, indirizzi di collegamento, dati personali o contenuti aziendali estranei
alla verifica.
Il fatto che un’applicazione sia accessibile all’operatore non autorizza automaticamente a condividerne ogni contenuto con un servizio AI.

CONCLUSIONE
Configurare un assistente per utilizzare il computer richiede due lavori distinti: rendere disponibile
lo strumento e definire il metodo operativo.
  • La prima parte abilita l’interazione. 
  • La seconda stabilisce dove deve fermarsi.
Il risultato da cercare non è un assistente che clicchi autonomamente il maggior numero possibile di pulsanti, ma un collaboratore che sappia identificare l’ambiente, rispettare il perimetro e distinguere un’azione eseguita da un risultato realmente verificato.

La possibilità di agire è una capacità tecnica. 
Il diritto di agire dipende dall’autorizzazione ricevuta.

FONTI CONSULTATE

  • Documentazione ufficiale OpenAI, verificata il 5 ottobre 2026:
    • - Computer Use:  configurazione, permessi e limiti.
    • - Use your computer with ChatGPT:  utilizzo operativo e gestione delle sessioni.
    • - Custom instructions with AGENTS.md:  istruzioni persistenti.
    • - Customization:  distinzione tra istruzioni e controlli tecnici.