Oggi la maggior parte degli utenti si approccia ai modelli di linguaggio (LLM) pagando abbonamenti mensili a servizi cloud, ignorando che l’hardware gi� presente nel proprio computer pu� trasformarsi in un motore di calcolo autonomo. Una scheda video di ultima generazione come la NVIDIA GeForce RTX 5070 Ti � in grado di far girare modelli avanzati direttamente in locale, a costo zero e salvaguardando totalmente la privacy dei dati. Abbiamo voluto mettere alla prova questa promessa nel modo pi� funzionale possibile: costruendo due applicazioni funzionanti da zero, senza conoscere la sintassi di Python n� la programmazione web, e affidandoci esclusivamente al dialogo con l’intelligenza artificiale. Vale la pena sottolineare che alcuni passaggi di questo articolo potrebbero risultare ridondanti a chi sa programmare, ma il nostro scopo � un altro: ovvero sottolineare come i moderni LLM possano assottigliare il gap tra chi � competente e chi non lo �, e consentire a questi ultimi di ottenere risultati che fino a poco tempo fa erano inimmaginabili per loro.
Grazie all’evoluzione del Vibe Coding, la terminologia con cui si indica la pratica di sviluppare software descrivendo all’IA ci� che si desidera in linguaggio naturale, l’assenza di competenze di programmazione non � pi� una barriera. Integrando strumenti visivi accessibili e un approccio iterativo, chiunque pu� dare vita a un’applicazione personalizzata senza scrivere manualmente una sola riga di codice. Ecco cosa abbiamo imparato, e cosa siamo riusciti a costruire con questo approccio.
L’architettura software e l’avvio del modello locale
Il primo pilastro di questo ecosistema � la rimozione della complessit� tecnica legata alla gestione dei modelli e per esplicitare ci� che vogliamo qui comunicare abbiamo scelto di utilizzare Unsloth Studio, uno strumento che permette di superare la necessit� di interagire con il terminale di comando, perch� mette a disposizione un’interfaccia grafica per scaricare e avviare gli LLM. Dopo una configurazione guidata che mappa automaticamente i driver della scheda video, l’utente ha accesso a una dashboard centralizzata collegata direttamente ai principali database di modelli open-source.
Per ottimizzare le risorse della GeForce RTX 5070 Ti, la scelta del modello deve ricadere su architetture bilanciate come Gemma 4, Llama 3 o Mistral. Il consiglio � quello di prediligere le versioni quantizzate in formato GGUF. Una volta avviato il modello, Unsloth Studio espone un server locale all’indirizzo http://localhost:8000, dove imita la struttura delle API commerciali pi� note. Questo standard consente a qualsiasi applicazione esterna di comunicare con il modello locale, di inviare istruzioni e di ricevere risposte generate direttamente dalla scheda video.
Per sfruttare in modo equilibrato una RTX 5070 Ti, infatti, non basta “un modello qualsiasi”. Architetture come Llama 3, Gemma 4 o Mistral sono progettate con un occhio preciso all’esecuzione su hardware consumer: supportano tecniche moderne come GQA e FlashAttention, gestiscono context window ampie senza collassare la VRAM e offrono una qualit� di output che, nei compiti generali, � comparabile a quella di molti modelli commerciali. � il compromesso ideale tra numero di parametri, richiesta di memoria e qualit� delle risposte, condizione indispensabile per chi non dispone di una GPU da data center.
La raccomandazione di usare versioni con compressioni matematiche (quantizzazione) in formato GGUF ha una ragione altrettanto pratica: ridurre il peso del modello fino a farlo rientrare nella VRAM disponibile, senza rinunciare al tempo stesso a una qualit� accettabile. In FP16 un modello da 12B parametri occuperebbe circa 24 GB di VRAM, quindi non potrebbe nemmeno essere caricato su una 5070 Ti da 16 GB. La quantizzazione a 4�5 bit porta lo stesso modello a circa 6�8 GB, e lascia inoltre spazio in memoria per la KV cache e per il sistema operativo. GGUF � oggi uno standard de facto per i modelli compressi: � supportato da quasi tutti i runtime locali, permette caricamenti rapidi e rende possibile, in pratica, ci� che in FP16 rimarrebbe solo teorico. Senza quantizzazione, l�idea di “AI avanzata in locale” su un PC di casa si fermerebbe ai modelli piccoli; mentre con GGUF possiamo invece spingerci fino a 7B�12B parametri in modo stabile.
Perch� proprio Unsloth (e non altri)
Inoltre, nel panorama degli strumenti per eseguire LLM in locale, Unsloth Studio non appartiene alla serie “uno vale l�altro”. La scelta nasce da tre motivi reali, che � giusto esplicitare. Primo: Unsloth riduce al minimo la necessit� di usare il terminale in quanto offre un’interfaccia grafica che guida l’utente nel download dei modelli, nella configurazione della GPU e nell’avvio del server locale. Questo ci ha aiutato molto in confronto ad altri strumenti che richiedono pi� uso da terminale e mette l’AI alla portata anche di chi non ha esperienza con riga di comando, Docker o ambienti virtuali Python. Secondo: Unsloth integra ottimizzazioni specifiche per l’esecuzione locale come quantizzazione, kernel pi� efficienti e gestione delle risorse, che permettono a una scheda come la GeForce RTX 5070 Ti di ospitare modelli pi� grandi e veloci rispetto a molte alternative “vanilla” basate su backend generici. Terzo: Unsloth espone il modello tramite un endpoint locale compatibile con le API pi� diffuse, cos� che strumenti e librerie pensate per i servizi cloud possano dialogare con l’LLM in locale senza richiedere una riscrittura completa del codice. In sintesi, � la combinazione di usabilit�, efficienza e compatibilit� a renderlo la scelta pi� sensata per chi parte da zero ma vuole arrivare a un’app reale funzionante su hardware domestico.
La matematica dietro la VRAM: quanto pesa davvero un modello
Un dubbio comune riguarda il calcolo esatto dello spazio occupato da un modello all’interno della VRAM. Esiste una relazione diretta tra il numero di parametri di un LLM e il peso del file in Gigabyte, ma questa equazione � fortemente influenzata dalla precisione numerica con cui il modello � stato convertito, un processo tecnico chiamato quantizzazione.
In un modello non ottimizzato espresso in precisione standard a 16 bit (FP16), ogni singolo parametro richiede esattamente 2 byte di memoria. Di conseguenza, un modello da 12 miliardi di parametri (12B) non compresso occuperebbe circa 24 GB di VRAM solo per essere caricato, una quota che supererebbe ampiamente la memoria fisica di una singola scheda video commerciale, e renderebbe impossibile l’esecuzione locale. Scaricando invece una versione quantizzata a 4 bit, il consumo si riduce drasticamente a circa 0,5 byte per parametro: lo stesso modello da 12B richieder� circa 6-7 GB di file su disco e altrettanti GB di VRAM per il caricamento iniziale. Questo lascia il margine necessario per la Context Window e per il sistema operativo.
Il caso Kimi 3: perch� non tutti i modelli entrano in un PC di casa
Il discorso cambia radicalmente quando l’attenzione si sposta su modelli di scala industriale come Kimi 3, la cui configurazione estesa pu� raggiungere una dimensione stimata di 300 GB. Un file di tale portata non descrive un modello monolitico eseguibile su una postazione desktop, bens� una complessa infrastruttura basata spesso su logiche MoE (Mixture of Experts), in cui il modello globale � suddiviso in sotto-reti specializzate: quando l’utente invia un prompt, un algoritmo di routing attiva soltanto una frazione di questi esperti. Riduce il calcolo istantaneo ma richiede comunque che l’intera struttura sia accessibile in memoria ad altissima velocit�.
Anche a una quantizzazione spinta a 4 bit, un modello di questa mole richiederebbe una base minima di 150-180 GB di VRAM libera solo per l’avvio in sicurezza. Non basterebbe una GeForce RTX 5070 Ti: sarebbe necessaria un’infrastruttura server composta da un cluster di almeno quattro o sei schede NVIDIA RTX 9000 Ada Generation o H100 collegate in parallelo. Questa differenza di scala chiarisce il confine netto tra AI locale e AI cloud: mentre le architetture giganti richiedono data center dedicati, l’ottimizzazione dei modelli open-source da 7B a 12B parametri permette di ottenere assistenti privati eccezionali sfruttando al 100% l’architettura consumer di una singola scheda video domestica.
Naturalmente in condizioni come queste conviene ricorrere all’elaborazione via cloud. Mentre l’esecuzione in locale degli LLM rimarr� sempre appannaggio degli utenti minimamente smaliziati, la stragrande maggioranza delle persone avr� vita progressivamente pi� facile con i modelli disponibili in cloud. Questi non solo vedono miglioramenti praticamente quotidiani nell’interpretazione del prompt (serve sempre meno ottimizzarli per ottenere i risultati) ma forniscono risposte secondo tempistiche sempre pi� immediate. Al tempo stesso si sta assistendo a un continuo aumento dei costi per piattaforme come queste, come abbiamo gi� analizzato in questo altro approfondimento.
Cosa succede dentro la GPU: RAM, VRAM e Tensor Core
Per comprendere l’impatto di un LLM sul computer, � fondamentale monitorare il comportamento dei componenti attraverso la Gestione Attivit� di Windows, mentre � molto importante distinguere nettamente lo stato di riposo dalla fase di calcolo attivo. Quando il modello viene semplicemente caricato in memoria, la percentuale di occupazione della memoria di sistema (RAM) e della memoria video (VRAM) subisce un’impennata immediata, stabilizzandosi su valori elevati anche superiori all’95%. I miliardi di parametri che compongono il modello, invatti, devono risiedere stabilmente all’interno della memoria d’accesso rapido per essere consultabili all’istante.
I Tensor Core della GeForce RTX 5070 Ti vengono attivati in parallelo per eseguire le moltiplicazioni matriciali necessarie a prevedere ogni singolo token successivo. La RAM e la VRAM delimitano la dimensione del modello che il PC pu� ospitare, mentre la potenza pura della GPU determina la velocit� di generazione del testo. Questo scenario, peraltro, apre a considerazioni nuove su come si analizza la capacit� di una CPU, dove il valore di token al secondo tende a rimpiazzare quello di frame al secondo. Una considerazione che va, per�, letta alla luce di diverse puntualizzazioni, a cominciare dal fatto che l’unita di misura del token al secondo non � precisa come quella del frame al secondo se lo scopo � un benchmark classico. Il modello di IA, infatti, affronta le richieste in maniera sempre diversa, e questo vale anche se si tratta di prompt identici.
Context Window e Temperature: i due parametri da conoscere
Possedere alcuni concetti � fondamentale per poter tarare per bene gli strumenti. La Context Window (finestra di contesto) � la quantit� massima di dati che il modello pu� elaborare contemporaneamente in una singola sessione, e tra questi troviamo sia il testo inserito dall’utente sia la risposta generata. All’aumentare dei token gestiti, la scheda video deve mantenere in memoria le relazioni geometriche tra tutte le parole analizzate. Se si imposta una finestra di contesto troppo ampia rispetto alle capacit� della VRAM della RTX 5070 Ti, il sistema sar� costretto a fare offloading sulla RAM di sistema, il che rallenta drasticamente i tempi di risposta. Allo stesso tempo, non bisogna caricare un modello con un quantitativo di parametri che eccede le capacit� di memoria della scheda video, proprio perch� una parte di questa serve a gestire la Context Window.
La Temperature agisce invece come un modulatore di probabilit� matematica durante la selezione delle parole. Quando il valore � impostato vicino a 0.0, l’algoritmo seleziona rigidamente solo i token con la massima probabilit� statistica. Questo rende l’output deterministico, preciso e ideale per compiti logici come l’analisi di contratti o la scrittura di codice. Impostando il valore verso 1.0, si appiattisce la curva di probabilit� e si permette al modello di selezionare anche parole meno scontate, il che aumenta la variabilit� e la creativit� del testo generato.
KV Cache, FlashAttention e GQA: perch� il contesto lungo non deve far collassare la VRAM
Mentre il peso fisso del modello definisce la barriera d’ingresso minima, la Context Window � la variabile dinamica che determina la saturazione della VRAM durante l’uso. Quando un LLM elabora un testo, deve calcolare e conservare le relazioni geometriche tra ogni token presente nella sessione all’interno di un archivio temporaneo chiamato KV Cache (Key-Value Cache). In un modello standard non ottimizzato, il consumo della KV Cache cresce in modo lineare rispetto alla lunghezza del contesto: ogni token aggiunto pu� richiedere circa 1-2 Megabyte di VRAM, per cui una finestra di contesto di 8.000 token pu� comportare un consumo aggiuntivo di 8-16 GB, da sommare al peso statico del modello.
Le architetture pi� recenti mitigano questo problema con due tecnologie chiave: la GQA (Grouped-Query Attention), che raggruppa chiavi e valori invece di allocare memoria per ogni singola testa di attenzione, e conseguentemente abbatte il consumo di VRAM legato al contesto fino all’80% senza compromettere l’accuratezza; e FlashAttention, che ottimizza il passaggio dei dati tra la memoria ad alta velocit� della GPU (SRAM) e la VRAM principale. Quest’ultima tecnica evita la memorizzazione di matrici intermedie ridondanti e mantiene i consumi stabili anche durante l’analisi di interi faldoni di documenti.
Il primo esperimento: costruire l’app usando ricorsivamente lo stesso Unsloth
L’applicazione che abbiamo scelto per portare avanti i nostri esperimenti � stato dapprima un analizzatore di testi e documenti PDF che tutela la privacy aziendale. L’applicazione � stata interamente sviluppata applicando i principi del vibe coding attraverso un dialogo iterativo con l’AI, sfruttando in modo ricorsivo lo stesso Unsloth Studio: prima per generare il codice del programma, poi per far eseguire il modello che l’applicazione avrebbe utilizzato per analizzare i PDF. Anche se non si conosceva la sintassi di Python, lo sviluppo � progredito tramite la risoluzione dei problemi sequenzialmente man mano che si presentavano.
Nel primo tentativo abbiamo chiesto all�AI di creare una semplice interfaccia con Streamlit per inserire del testo e inviarlo al modello locale, ma il programma cercava ancora di collegarsi a server esterni richiedendo una chiave a pagamento. Nel secondo passaggio, abbiamo spiegato all’AI che volevamo usare il server locale di Unsloth Studio su http://localhost:8000. A questo punto, l�AI ha aggiornato il codice sfruttando la libreria Python compatibile con le API OpenAI, ma configurata per puntare all’endpoint locale invece che ai server esterni: base URL impostata su http://localhost:8000/v1 e una chiave fittizia, giusto per soddisfare la struttura dell�API. In altre parole, non stavamo usando il servizio cloud OpenAI, ma un client API gi� esistente per parlare con un modello in esecuzione sulla nostra GPU. Il risultato era un�app capace di interagire correttamente con l’LLM locale, anche se ancora limitata a una sola modalit� di analisi.
Nell’ultimo passaggio, � stato chiesto all’AI di implementare un sistema di controllo degli errori che bloccasse l’invio in caso di campo vuoto e mostrasse un avviso visivo di attesa durante il calcolo intensivo della GPU. Successivamente, durante la fase di integrazione con il modello Gemma-4-12B ospitato sul server locale, sono emerse ulteriori criticit� di rete e autenticazione con errori HTTP 401 e 405 che sono state risolte passando dalla libreria standard OpenAI a richieste HTTP dirette tramite la libreria requests. Questo ha garantito la comunicazione tra interfaccia e motore di inferenza indipendentemente dai vincoli della libreria commerciale. L’ultimo tocco � stato il packaging “zero-install”: una distribuzione portatile di WinPython con ambiente virtuale isolato e uno script di avvio automatico, per permettere di eseguire l’intera suite con un solo clic senza installare nulla sul sistema operativo ospite.
Per rendere operativo lo script � sufficiente installare Python sul proprio sistema, abilitare l’opzione per l’aggiunta delle variabili d’ambiente e installare dal prompt dei comandi le librerie necessarie, come Streamlit per l’interfaccia web e il client API compatibile OpenAI per la chiamata al modello locale. Salvando il codice in un file app.py e avviandolo, si apre una pagina web locale nel browser che comunica direttamente con l’LLM in esecuzione su Unsloth Studio: nessun dato esce dal PC, ma l�esperienza d�uso � quella di un servizio cloud vero e proprio.
Il secondo esperimento: un task alarm per Android e il muro della Sandbox
Il secondo progetto ha segu�to un percorso di sviluppo diverso, incentrato sulla creazione di una PWA (Progressive Web App) per Android pensata come sveglia/task alarm da telefono, con un design mobile-first: pulsanti grandi, disposizione verticale pulita, e un metodo per triggerare automaticamente il selettore di orario nativo del sistema operativo, molto pi� preciso rispetto a menu creati da zero. Da PWA poi si � trasformata in app nativa, come vedremo.
Alla base dell’app c’� un array tasks che funge da Single Source of Truth, con ogni modifica riflessa immediatamente nell’interfaccia tramite una funzione di rendering dedicata, e sulla persistenza tramite LocalStorage, che permette di gestire i dati sul dispositivo senza bisogno di un server esterno in quello che � un esempio di Local-First Software Architecture. Un setInterval funge da loop di controllo che osserva costantemente il tempo, mentre l’allarme sonoro viene generato tramite AudioContext API invece di caricare un file .mp3 esterno, sintetizzando l’onda sonora direttamente nel browser. In realt� questo sistema ha prodotto un suono di sintesi non gradevole, per cui nell’iterazione finale dell’app abbiamo propeso per un mp3. Per completare la trasformazione in PWA vera e propria sono stati aggiunti un manifest.json, che definisce icona e colori dell’app quando installata sulla home di Android, e un service-worker.js, che intercetta le richieste di rete servendo i file dalla cache locale e permette all’app di funzionare offline.
Durante la fase di test � per� emersa la sfida pi� interessante: l’allarme funzionava perfettamente con l’app aperta, ma si arrestava non appena l’utente cambiava applicazione o spegneva lo schermo. La causa � la Sandbox del browser: per preservare batteria e privacy, il sistema operativo Android congela i processi JavaScript non attivi, un limite strutturale delle PWA rispetto alle app native, che godono invece di permessi diretti sul sistema operativo anche in stato di sospensione. � una lezione preziosa: la scelta dello stack tecnologico non dipende solo da cosa pu� fare il codice, ma da quali permessi il sistema concede a quel codice.
Per superare questo vincolo, l’evoluzione naturale del progetto � passata a un’architettura Ibrida tramite Capacitor, un framework che trasforma il codice web in un’app nativa senza rinunciare alla velocit� di sviluppo di HTML, CSS e JavaScript, ma abbattendo i muri della Sandbox attraverso un Bridge che permette all’app di parlare direttamente con i servizi di sistema di Android, come l’Alarm Manager. Tecnicamente, la differenza cruciale emersa in questa fase � che il codice nativo, come Jetpack Compose, disegna ogni singolo pixel dell’interfaccia tramite istruzioni del sistema operativo, mentre una PWA o un’app ibrida si affidano a una WebView, un motore di rendering che interpreta il codice web all’interno di un contenitore nativo. Una volta generato l’APK tramite Android Studio, il risultato � un’app che suona anche a schermo spento e con l’app chiusa, esattamente ci� che la versione puramente web non poteva garantire.
Il passaggio ad Android Studio � stato fondamentale in questa esperienza, uno strumento che personalmente non so usare direttamente. Android Studio, con l’integrazione a sua volta di strumenti IA basati su Gemini 3 Flash, ha risolto gli errori di codice che si erano generati durante le iterazioni ricorsive del modello Gemma incapsulato dentro Unsloth. Questo passaggio � stato fondamentale per ottenere l’APK funzionante.
Non � stato facile superare i controlli incrociati che Android esegue su ci� che le app fanno quando sono chiuse. Ma ora Task Alarm riesce a gestire le sveglie in qualsiasi momento ed � anche possibile spegnere la sveglia subito dopo che si � attivata. Pu� gestire vari task e continua a funzionare anche quando non esecuzione.
Cosa ci portiamo a casa da questi esperimenti
Il filo che unisce entrambi i progetti � lo stesso: costruire strumenti funzionali, privati e autonomi sfruttando solo le risorse gi� presenti sul proprio hardware, senza dipendere da abbonamenti cloud o da competenze tecniche pregresse. L’analizzatore di PDF dimostra come una singola GeForce RTX 5070 Ti, abbinata a un modello quantizzato da 12 miliardi di parametri, sia sufficiente per costruire un assistente specializzato capace di leggere, riassumere e analizzare documenti sensibili senza che un singolo byte lasci il proprio computer. Il task alarm, dall’altro lato, mostra che anche i piccoli progetti “senza internet” nascondono sfide ingegneristiche reali, dai limiti imposti dai browser fino alla necessit� di scendere a compromessi tra velocit� di sviluppo e accesso ai permessi di sistema.
C’� poi un’altra ragione molto importante che evidenzia ancora di pi� il pregio di lavorare in questo modo e di elaborare in locale, e che per chi costruisce strumenti di lavoro conta almeno quanto la privacy: la stabilit� operativa del modello. Quando si usa un servizio cloud come quelli offerti da OpenAI o Anthropic, l’utente non ha alcuna visibilit� su cosa accada realmente “sotto il cofano” del modello che sta chiamando tramite API. Al di l� degli annunci ufficiali di nuove versioni, � pratica comune per i grandi fornitori effettuare aggiustamenti continui ai pesi, ai sistemi di moderazione o ai prompt di sistema, anche tra un annuncio “major” e l’altro. Il risultato � che un’applicazione costruita oggi attorno a un certo comportamento del modello potrebbe, nel tempo, iniziare a restituire output leggermente diversi, senza che lo sviluppatore abbia fatto alcuna modifica al proprio codice e senza nessun avviso preventivo.
Chi esegue un modello in locale tramite strumenti come Unsloth Studio, al contrario, ha il controllo diretto sul file del modello che sta usando: se non lo si aggiorna manualmente, quel modello rester� esattamente lo stesso, con lo stesso comportamento, la stessa qualit� di output e le stesse eventuali “stranezze”, oggi come in un anno. Questo non significa che il modello locale sia necessariamente migliore in termini assoluti, ma garantisce una riproducibilit� che nel cloud semplicemente non esiste: un vantaggio concreto per chi costruisce un’applicazione attorno a un comportamento specifico del modello, e non vuole ritrovarsi a dover rincorrere modifiche silenziose apportate da un fornitore esterno su cui non ha alcun controllo.
Il lato oscuro della “democratizzazione”: qualit�, sicurezza e robustezza del codice
C’� per� un punto cruciale che va necessariamente toccato: la democratizzazione della programmazione non equivale automaticamente a codice sano. Se chiunque pu� “scrivere software” parlando con un LLM, � altrettanto vero che la maggior parte degli utenti non ha gli strumenti per valutare se quel software sia robusto, sicuro ed efficiente.
Questo nuovo scenario, in cui basta descrivere un’idea all’AI per ottenere codice funzionante, ha un rovescio della medaglia che non va ignorato. Un utente che non sa programmare pu� generare un�applicazione perfettamente utilizzabile, ma non ha gli strumenti per giudicare la qualit� del codice che sta eseguendo. Non pu� verificare se ci siano vulnerabilit� banali (input non validati, gestione superficiale degli errori, uso insicuro di file e rete), se l’app regga carichi prolungati o se stia consumando risorse in modo inutile. In pratica, la barriera d’ingresso si abbassa per la produttivit�, ma resta alta sul fronte dell’ingegneria del software.
Nel nostro caso, gli errori emersi come quello dell’app che crasha in assenza di testo fino ai problemi di autenticazione con l’endpoint locale, sono stati risolti proprio grazie al dialogo iterativo con l’LLM. Ma questo non deve far dimenticare che il modello non sostituisce la fase di revisione critica: serve comunque un minimo di consapevolezza per chiedere controlli d�errore, per porsi domande su come vengono gestiti i dati, e idealmente serve un passaggio di auditing da parte di chi conosce almeno i principi base di sicurezza e robustezza. La vera “democratizzazione” non sar� completa finch� gli strumenti non aiuteranno anche a valutare e spiegare la salute del codice, non solo a generarlo. Fino ad allora, il rischio � quello di creare una grande quantit� di software funzionale ma fragile, che fa il suo dovere finch� tutto va bene, ma collassa al primo imprevisto.
Detto questo, il messaggio finale � semplice: la potenza dell’intelligenza artificiale non vive solo nei data center delle grandi aziende tecnologiche. Grazie a strumenti come Unsloth Studio (ma, ribadiamo, non � l’unico, � semplicemente l’esempio che abbiamo scelto di utilizzare per i nostri scopi), che democratizzano l’accesso ai modelli open-source ottimizzandone memoria e velocit�, chiunque possieda una scheda video moderna pu� trasformare il proprio computer in un laboratorio personale di intelligenza artificiale. Non serve saper programmare, non serve un cluster di GPU professionali: serve solo la curiosit� di provare, un dialogo ben costruito con l’AI, e la consapevolezza che il vero limite, oggi, non � pi� la tecnologia disponibile, ma quanto siamo disposti a sperimentare con ci� che gi� abbiamo in casa.
#Adessonews seleziona nella rete articoli di particolare interesse.
Se vuoi leggere l’articolo completo clicca sul seguente link
