Un progetto open source sviluppato da João Silva mostra come un agente di intelligenza artificiale possa essere collegato direttamente a una stampante 3D desktop e occuparsi di una parte significativa del workflow che normalmente richiede l’intervento dell’operatore. Il sistema utilizza Hermes Agent insieme a una serie di “skills” sviluppate specificamente per una Flashforge AD5X: l’agente può ricevere un modello STL o 3MF, selezionare un profilo di stampa, eseguire OrcaSlicer senza interfaccia grafica, verificare alcuni parametri, controllare quali filamenti sono presenti nei quattro canali del sistema IFS e trasferire il G-code alla stampante attraverso la rete locale. Un secondo modulo permette persino di partire da uno schizzo, una fotografia annotata o una descrizione dimensionale, generare un modello parametrico in OpenSCAD, verificarne alcune caratteristiche geometriche ed esportarlo come STL prima di passarlo automaticamente alla fase di slicing.
Il progetto è interessante soprattutto perché mostra una possibile evoluzione dell’interfaccia fra software e macchine additive. Non introduce una nuova tecnologia di deposizione e non modifica fisicamente il processo FFF della stampante: costruisce invece un livello software capace di collegare linguaggio naturale, CAD parametrico, slicer e API della macchina. Un utente può quindi descrivere ciò che vuole ottenere senza dover necessariamente aprire manualmente tutti i programmi intermedi.
È però importante delimitare con precisione l’autonomia raggiunta. L’implementazione descritta pubblicamente da Silva mantiene intenzionalmente un human-in-the-loop prima dell’inizio della stampa. L’agente può preparare il lavoro e caricarlo sulla macchina, ma prima di avviare fisicamente una stampa di diverse ore richiede una conferma all’utente. Non siamo quindi ancora davanti a una fabbrica autonoma governata da un LLM che progetta, produce, osserva e corregge un componente senza supervisione.
Che cosa significa realmente “agente AI” in questo progetto
Un agente AI non deve essere confuso con un normale chatbot e nemmeno con un modello linguistico che possiede direttamente la capacità di pilotare una stampante.
Il modello linguistico interpreta l’intenzione dell’utente e decide quali strumenti utilizzare. L’esecuzione materiale delle operazioni viene però affidata a programmi tradizionali: script, API, utility a riga di comando, OrcaSlicer e software di comunicazione con la stampante.
Hermes Agent funziona come un agent harness, cioè un ambiente di esecuzione che fornisce al modello strumenti, memoria procedurale e capacità di orchestrare operazioni esterne. Una componente fondamentale è costituita dalle cosiddette skills. Nel sistema Hermes una skill è essenzialmente un insieme strutturato di istruzioni contenuto in un file SKILL.md, eventualmente accompagnato da script, riferimenti e template.
La skill non “addestra” nuovamente il modello AI e non contiene necessariamente un algoritmo di machine learning. Funziona più come una procedura operativa dettagliata: spiega all’agente quali strumenti sono disponibili, in quale ordine devono essere usati, quali controlli effettuare, quali errori evitare e quando richiedere l’intervento dell’utente.
Nel caso della stampa 3D, Silva ha quindi trasformato l’esperienza accumulata con la propria Flashforge AD5X in un workflow riutilizzabile dall’agente.
Il workflow dal file STL alla stampante
La skill denominata 3dprinter è specificamente progettata per Flashforge AD5X. Il flusso dichiarato dal repository segue sostanzialmente questa sequenza:
- ricezione del file STL o 3MF;
- preparazione dello slicing;
- esecuzione headless di OrcaSlicer;
- applicazione dei profili e delle preferenze definite dall’utente;
- controllo delle temperature;
- verifica dei canali dell’Intelligent Filament System;
- generazione e controllo del G-code;
- caricamento sulla stampante;
- conferma dell’operatore prima dell’avvio.
La parte interessante è l’utilizzo di OrcaSlicer in modalità headless. Normalmente un utente apre il modello nello slicer, seleziona stampante, materiale, altezza layer, supporti, riempimento, velocità e altri parametri, quindi genera manualmente il file destinato alla macchina.
Nel workflow agentico il programma viene invece chiamato dal software senza che l’interfaccia grafica costituisca il centro dell’operazione. L’agente fornisce parametri e profili e legge il risultato dell’elaborazione.
L’intelligenza artificiale non sostituisce quindi il motore di slicing. È ancora OrcaSlicer a calcolare perimetri, infill, supporti, temperature e toolpath secondo gli algoritmi implementati nello slicer.
AI agent e slicer svolgono lavori differenti
Questa distinzione è fondamentale per evitare di attribuire al modello linguistico capacità che non possiede.
| Operazione | Componente principale |
|---|---|
| Comprendere la richiesta dell’utente | LLM/agente |
| Decidere quale workflow utilizzare | Hermes + skill |
| Generare parametri OpenSCAD | LLM + skill OpenSCAD |
| Calcolare la mesh | OpenSCAD |
| Verificare manifold/envelope | script della skill |
| Generare toolpath | OrcaSlicer |
| Generare G-code | OrcaSlicer |
| Modificare problemi specifici del G-code Flashforge | script del progetto |
| Comunicare con la stampante | API di rete Flashforge |
| Gestire i canali del materiale | API/IFS |
| Avviare fisicamente la stampa | soggetto a conferma umana nel workflow descritto |
Il valore dell’agente è soprattutto nell’orchestrazione. Invece di costringere l’utente a passare manualmente da un programma all’altro, il sistema interpreta l’obiettivo generale e coordina gli strumenti necessari.
La Flashforge AD5X offre una base particolarmente adatta all’esperimento
Il progetto è stato sviluppato specificamente sulla Flashforge AD5X, una stampante CoreXY desktop con volume di costruzione di 220 × 220 × 220 mm e sistema IFS capace di gestire fino a quattro filamenti.
Flashforge dichiara una velocità massima di movimento di 600 mm/s, velocità di stampa massima di 300 mm/s, accelerazione fino a 20.000 mm/s², hotend fino a 300 °C e piano riscaldato fino a 110 °C. Il sistema utilizza un singolo estrusore e cambia automaticamente il materiale attraverso l’Intelligent Filament System.
Dal punto di vista del progetto AI, la caratteristica determinante è però la connettività di rete. AD5X supporta Ethernet e Wi-Fi e Flashforge stessa permette già di trasferire lavori e controllare la macchina attraverso Orca-Flashforge e i propri strumenti.
Esiste inoltre una documentazione comunitaria delle API HTTP e TCP utilizzate dalle stampanti Flashforge più recenti. Per AD5X viene documentata un’interfaccia HTTP sulla porta 8898 e una TCP sulla porta 8899. Il controllo HTTP richiede indirizzo IP, numero seriale e un “check code” associato alla macchina.
Silva racconta che proprio questa parte ha richiesto una certa attività di debugging: inizialmente l’API HTTP sembrava non funzionare, mentre il problema era legato alla necessità di abilitare la modalità LAN direttamente dal touchscreen della stampante.
Il progetto utilizza API reali, ma non un’integrazione ufficiale Hermes-Flashforge
Questo è un altro aspetto da precisare. Flashforge supporta ufficialmente la stampa tramite Orca-Flashforge e il trasferimento dei file attraverso la rete, ma la skill Hermes sviluppata da Silva non è un prodotto ufficiale Flashforge.
La documentazione dettagliata delle API utilizzate dal progetto proviene in larga misura dal lavoro della comunità, ottenuto attraverso analisi del firmware, osservazione del traffico di rete e prove dirette sulle macchine.
Il repository open source flashforge-api-docs, per esempio, documenta per AD5X informazioni sulla material station IFS, listing dei file, stato della macchina e vari endpoint di controllo.
Questo rende tecnicamente possibile costruire strumenti alternativi all’interfaccia Flashforge, ma introduce anche un elemento di fragilità. Un aggiornamento firmware potrebbe modificare endpoint, autenticazione o comportamento delle API e richiedere un aggiornamento della skill.
La gestione dei quattro filamenti è più complessa di quanto sembri
AD5X può lavorare con un massimo di quattro bobine attraverso IFS. In una stampa multicolore non è sufficiente sapere che sono disponibili quattro slot: occorre anche conoscere materiale e colore caricati e associare correttamente i tool virtuali dello slicer alle posizioni fisiche.
Il progetto conserva quindi informazioni relative alle bobine presenti nella stazione.
Prima dello slicing o dell’invio, l’agente può chiedere conferma su ciò che è effettivamente montato. Questo è importante perché un G-code preparato assumendo PLA rosso nel canale 1 e PETG nero nel canale 2 potrebbe produrre risultati imprevedibili se la configurazione fisica fosse differente.
Anche Flashforge, nella propria documentazione ufficiale di Orca-Flashforge, specifica che AD5X gestisce fino a quattro filamenti e richiede la corretta associazione dei materiali prima dello slicing multicolore.
L’agente non “vede” necessariamente la bobina: utilizza lo stato dichiarato o fornito dalla macchina e dall’utente.
Il controllo della temperatura è un esempio di automazione utile
La skill include inoltre controlli sulle temperature generate dallo slicer.
Questo è un buon esempio della differenza tra un agente generalista e un workflow strutturato. Un LLM lasciato completamente libero potrebbe generare un comando plausibile ma scorretto. Inserendo nella skill un passaggio obbligatorio di verifica della temperatura, l’autore trasforma invece una conoscenza operativa in un guardrail.
Per esempio, se un profilo destinato a PLA generasse una temperatura del piano incompatibile con il materiale o con le impostazioni previste, il sistema può intercettare l’anomalia prima di inviare il lavoro.
Questo non garantisce che qualsiasi combinazione di parametri sia corretta. Evita però una parte degli errori grossolani che potrebbero derivare dall’automazione.
La skill modifica anche alcuni problemi del G-code Flashforge
Il repository dichiara inoltre una fase di “fix-up” di problemi conosciuti nel G-code destinato alla AD5X.
È importante interpretare correttamente questa funzione. Non significa che l’AI riscriva liberamente il G-code basandosi sulla propria conoscenza del processo. Il progetto contiene procedure e script predisposti dall’autore per correggere situazioni specifiche osservate durante l’utilizzo della macchina.
È una distinzione fondamentale per la sicurezza: in un sistema affidabile, modifiche ripetitive al G-code dovrebbero essere deterministiche e verificabili, non improvvisate ogni volta da un modello linguistico.
L’LLM può decidere quando richiamare lo strumento; l’operazione tecnica può invece essere affidata a codice convenzionale.
Dal disegno al modello OpenSCAD
La seconda skill sviluppata da Silva è forse ancora più interessante perché estende il workflow verso la progettazione.
openscad-cad può ricevere:
- uno schizzo;
- una fotografia annotata;
- dimensioni fornite verbalmente;
- una descrizione geometrica.
L’agente produce quindi codice OpenSCAD, genera una mesh STL e applica alcuni controlli prima di consegnare il file alla skill di stampa.
OpenSCAD è particolarmente adatto a questo tipo di automazione perché descrive la geometria tramite codice. Invece di manipolare direttamente una mesh opaca, il modello AI può scrivere istruzioni come cubi, cilindri, traslazioni, rotazioni, differenze booleane e parametri dimensionali.
Il risultato può essere quindi più facilmente controllato e modificato rispetto a una mesh prodotta direttamente da un generatore text-to-3D.
Parametrico non significa automaticamente corretto
Il fatto che un modello sia espresso attraverso OpenSCAD non significa che sia necessariamente ingegneristicamente corretto.
Il workflow dichiara controlli su:
- manifold della mesh;
- bounding envelope;
- preview;
- correttezza dell’esportazione STL.
Questi controlli possono verificare che il modello sia formalmente utilizzabile dallo slicer e che rientri in determinati limiti dimensionali.
Non dimostrano però automaticamente:
- resistenza meccanica;
- corretto dimensionamento strutturale;
- tolleranze di accoppiamento;
- orientamento ottimale;
- adeguatezza del materiale;
- resistenza termica;
- sicurezza del componente.
Un agente può quindi progettare un bracket perfettamente manifold che si rompe appena viene caricato.
Questa distinzione diventa ancora più importante se il workflow viene utilizzato per produrre parti funzionali.
Mesh verificata ≠ componente qualificato
Uno dei rischi dell’automazione end-to-end è che una serie di check superati possa generare l’impressione di aver “validato” il componente.
In realtà ogni fase verifica aspetti differenti:
OpenSCAD → STL valido: la geometria è traducibile in una mesh.
Manifold check: la mesh ha una topologia utilizzabile per la stampa.
Slicer senza errori: è possibile generare un toolpath.
G-code valido: la macchina può teoricamente interpretare i comandi.
Upload completato: il file è arrivato sulla stampante.
Nessuno di questi passaggi dimostra automaticamente che la parte finale soddisferà le proprie specifiche funzionali.
Per componenti critici rimangono necessari criteri ingegneristici, test, metrologia e qualificazione appropriati.
La parte più importante del progetto è forse il pulsante che l’AI non preme
Fabbaloo descrive uno scenario nel quale, anche mentre l’utente si trova lontano dalla stampante, potrebbe chiedere all’agente di realizzare tre copie di un modello e lasciare che Hermes svolga l’operazione.
La documentazione pubblicata dallo stesso autore del progetto introduce però un’importante precisazione.
Silva scrive esplicitamente che, dopo aver controllato i materiali, eseguito lo slicing e caricato il G-code, l’agente si ferma e chiede conferma prima di iniziare fisicamente la stampa.
Questa scelta è intenzionale.
Una stampa FFF può durare molte ore e coinvolge hotend a temperature nell’ordine di centinaia di gradi, movimenti meccanici e chilogrammi di materiale potenzialmente disponibili in una stazione automatica. Un file errato può produrre spaghetti, collisioni, spreco di materiale o, in casi più seri, situazioni che richiedono l’intervento dell’utente.
L’autore stesso utilizza l’esempio di una bobina da circa 40 euro che potrebbe essere sprecata da un lavoro avviato senza controllo.
Da questo punto di vista il progetto non dimostra tanto “l’eliminazione dell’uomo” quanto la possibilità di spostare l’intervento umano nel punto nel quale ha maggior valore: l’approvazione dell’azione fisica irreversibile.
Non è ancora un vero closed loop di processo
Il termine automazione AI può far pensare a un agente che controlla continuamente la stampa attraverso una telecamera, identifica difetti e modifica parametri in tempo reale.
Non è ciò che viene dimostrato in questo progetto.
La skill documentata si concentra principalmente su:
- preparazione;
- slicing;
- configurazione materiali;
- controllo del G-code;
- upload;
- comunicazione di rete.
Non risulta documentata una catena nella quale una rete neurale osservi continuamente l’estrusione, riconosca under-extrusion, warping o spaghetti e modifichi automaticamente feed rate, temperatura, flow o traiettorie.
Anche l’hardware della AD5X di serie è significativo: la macchina non integra nativamente una telecamera nella configurazione standard; Flashforge indica il remote monitoring come espandibile.
Per parlare di closed-loop autonomous manufacturing sarebbe necessario almeno un sistema sensoriale in grado di osservare il risultato reale, confrontarlo con quello atteso, prendere una decisione e modificare il processo.
Qui siamo invece soprattutto davanti a un agentic workflow per preparazione e controllo macchina.
Automazione e autonomia sono concetti diversi
La distinzione può essere riassunta così:
| Livello | Esempio |
|---|---|
| Manuale | utente apre CAD, slicer e invia il file |
| Automazione tradizionale | script esegue sempre la stessa sequenza |
| Workflow agentico | l’AI interpreta la richiesta e sceglie strumenti/parametri |
| Human-in-the-loop | AI prepara il lavoro, persona approva l’avvio |
| Autonomous supervision | AI monitora la produzione e identifica problemi |
| Closed-loop control | AI/sistema modifica automaticamente il processo in risposta ai sensori |
Il progetto di Silva si colloca principalmente tra workflow agentico e human-in-the-loop.
Questo è già un cambiamento significativo rispetto al normale utilizzo desktop, ma è molto distante da una macchina completamente autonoma.
Perché le skills sono probabilmente più importanti del modello AI utilizzato
Un aspetto particolarmente interessante del progetto è che gran parte del valore non deriva da un modello linguistico specifico.
Le informazioni realmente operative sono codificate nella skill:
- quale slicer usare;
- quale profilo richiamare;
- quali controlli eseguire;
- come contattare la stampante;
- quali dati della material station verificare;
- quando fermarsi;
- cosa chiedere all’utente.
Questo significa che lo stesso approccio potrebbe essere trasferito ad altri agenti compatibili con strumenti analoghi.
La documentazione ufficiale di Hermes descrive infatti le skills come documenti di conoscenza caricati quando necessario e compatibili con lo standard aperto agentskills.io.
Non è quindi obbligatorio addestrare un modello specializzato su una determinata stampante. In linea di principio il produttore potrebbe pubblicare una procedura ufficiale che spiega a diversi agenti come utilizzare in sicurezza le proprie API.
Qui emerge il possibile interesse per i produttori di stampanti
È proprio questa la considerazione avanzata da Fabbaloo: in futuro i costruttori potrebbero pubblicare direttamente skills ufficiali per i propri sistemi.
Una stampante potrebbe essere accompagnata non soltanto da:
- driver;
- slicer;
- app mobile;
- API;
ma anche da una descrizione machine-readable del modo corretto di utilizzarla attraverso un agente.
Una skill ufficiale potrebbe specificare:
- capacità hardware;
- volume di costruzione;
- materiali supportati;
- limiti di temperatura;
- procedure di caricamento;
- API autorizzate;
- mapping del materiale;
- controlli di sicurezza;
- operazioni che richiedono conferma;
- procedure in caso di errore.
L’agente potrebbe così disporre di informazioni definite dal costruttore invece di ricostruirle attraverso reverse engineering o documentazione comunitaria.
Le API standard potrebbero diventare un vantaggio competitivo
Per molti anni le stampanti desktop hanno utilizzato ecosistemi relativamente chiusi, ciascuno con la propria applicazione, cloud e protocollo.
L’arrivo degli agenti AI potrebbe premiare l’approccio opposto.
Una macchina con API ben documentate e strumenti facilmente automatizzabili è più semplice da collegare a:
- ERP;
- MES;
- sistemi di preventivazione;
- code di produzione;
- magazzini digitali;
- sistemi CAD generativi;
- chatbot aziendali;
- automazioni domestiche;
- agenti AI.
L’utente potrebbe, per esempio, chiedere:
“Trova l’ultima versione del supporto, verificane le dimensioni, prepara quattro copie in PETG nero e fammi vedere il job prima di avviarlo.”
L’agente potrebbe recuperare il file, controllarne la revisione, generare il G-code, interrogare il magazzino dei filamenti e presentare all’operatore una schermata di approvazione.
Questa prospettiva è più interessante, dal punto di vista industriale, della semplice possibilità di impartire a voce il comando “stampa questo oggetto”.
Il concetto non è limitato alla Flashforge AD5X
Anche se il progetto di Silva è specifico per AD5X, l’idea si sta già manifestando in altri ecosistemi.
Sono comparsi server MCP e strumenti open source capaci di esporre stampanti Klipper/Moonraker, OctoPrint, Bambu Lab, Creality, Prusa ed Elegoo a client AI.
Un progetto come Kiln, per esempio, utilizza Model Context Protocol per fornire agli agenti numerosi strumenti relativi a progettazione, slicing, code di produzione e controllo delle stampanti. Altri repository espongono direttamente Moonraker o API Bambu come strumenti richiamabili da un agente.
Questo suggerisce che il progetto Hermes/AD5X non sia un caso isolato, ma parte di una tendenza più ampia: rendere le macchine fisiche accessibili allo stesso tipo di agenti che oggi lavorano su browser, database e repository software.
MCP, skills e API non sono la stessa cosa
In questo scenario è utile distinguere tre livelli che vengono spesso confusi.
API della stampante: definisce tecnicamente comandi come carica file, restituisci temperatura, avvia job o pausa.
Tool/MCP server: trasforma queste operazioni in strumenti strutturati che un agente può invocare.
Skill: descrive quando e come utilizzare quegli strumenti all’interno di un workflow affidabile.
È possibile avere un’API senza agenti; un MCP server senza una procedura operativa sofisticata; oppure una skill che richiama utility locali e API senza utilizzare MCP.
Il progetto di Silva è particolarmente interessante perché mostra il terzo livello: non soltanto “rendere disponibile il comando START”, ma codificare il processo che deve precedere START.
La sicurezza diventa più importante quando l’AI passa dal digitale al fisico
Un errore di un agente che genera una frase sbagliata ha conseguenze limitate. Un errore di un agente che modifica un file può essere recuperato da una copia. Un errore di un agente che ordina a una macchina fisica di muovere assi o riscaldare un estrusore appartiene invece a una categoria diversa.
Per questo i sistemi agentici destinati al manufacturing devono probabilmente prevedere più livelli di controllo.
Un’architettura prudente potrebbe includere:
- limiti hard-coded alle temperature;
- whitelist dei comandi consentiti;
- dry-run;
- verifica della compatibilità macchina/G-code;
- controllo del volume di costruzione;
- conferma prima delle operazioni fisiche;
- monitoraggio dello stato;
- timeout;
- emergency stop indipendente dal modello;
- log completo delle decisioni;
- possibilità di riprodurre l’intera catena di comandi.
La sicurezza non dovrebbe dipendere dal fatto che l’LLM “ricordi” di comportarsi correttamente.
Un agente può sbagliare macchina, profilo o materiale
Uno dei rischi più importanti è quello del contesto errato.
Una geometria può essere valida ma venire slicerata per una macchina differente. Un nozzle da 0,6 mm può ricevere un G-code destinato a 0,4 mm. Il materiale fisicamente caricato può essere diverso da quello previsto dal profilo. Una stampante può essere occupata o avere ancora un componente sul piano.
In un workflow completamente manuale queste informazioni vengono spesso controllate implicitamente dall’operatore.
Quando il processo viene automatizzato, devono diventare verifiche esplicite.
Il vantaggio delle skills è proprio la possibilità di trasformare queste conoscenze tacite in una checklist eseguibile dall’agente.
Il prossimo passo non è necessariamente togliere la conferma umana
Potrebbe sembrare naturale considerare la conferma introdotta da Silva come un limite da eliminare. In realtà, dal punto di vista dell’ingegneria dei sistemi, mantenerla potrebbe essere la scelta corretta anche in sistemi molto più avanzati.
Se l’agente può svolgere automaticamente il 95% delle operazioni amministrative e preparatorie, il costo di una singola approvazione dell’operatore è molto basso.
L’automazione industriale utilizza da decenni interlock, autorizzazioni e livelli di supervisione. L’arrivo degli LLM non elimina questi principi.
Una futura cella potrebbe quindi progettare, slicerare, schedulare e controllare automaticamente decine di job, ma chiedere ancora una conferma esplicita prima di particolari operazioni ad alto impatto.
L’obiettivo non deve necessariamente essere zero intervento umano, ma utilizzare l’intervento umano soltanto dove fornisce un reale valore di controllo.
Dal prompt alla parte fisica: il vero salto è l’orchestrazione
Il progetto Hermes-Skills mostra quindi un cambiamento concettuale interessante. Fino a oggi i sistemi AI per la stampa 3D si sono concentrati spesso sulla generazione di mesh, sull’ottimizzazione delle geometrie o sul riconoscimento visivo dei difetti. Qui l’intelligenza artificiale viene invece utilizzata come orchestratore dell’intero workflow digitale.
Un unico comando in linguaggio naturale può potenzialmente attraversare questa catena:
richiesta → OpenSCAD → STL → verifica → slicing → G-code → controllo materiale → upload → approvazione → stampa.
La maggior parte dei singoli passaggi esiste da anni. La novità consiste nel fatto che l’utente non deve necessariamente conoscere e coordinare manualmente ciascuno strumento.
Questo è probabilmente il contributo più importante del progetto.
Non dimostra che un LLM abbia imparato a stampare in 3D autonomamente e non dimostra una fabbrica closed-loop governata dall’intelligenza artificiale. Dimostra invece che un agente generalista, quando dispone di procedure sufficientemente dettagliate e accesso controllato alle API della macchina, può assumere una parte consistente del lavoro che oggi separa una richiesta in linguaggio naturale dall’avvio di un processo produttivo fisico.
È un esperimento open source relativamente piccolo e legato a una specifica stampante, ma il modello architetturale può essere esteso. Se produttori di stampanti, slicer e sistemi CAD inizieranno a pubblicare API e skills ufficiali, l’interfaccia quotidiana con una stampante 3D potrebbe diventare molto meno centrata sui menu del software e molto più vicina a una conversazione con un agente capace di coordinare strumenti specializzati.
Il punto decisivo sarà però mantenere una distinzione chiara tra ciò che l’agente può preparare, ciò che può verificare realmente e ciò che deve ancora essere approvato o controllato da una persona. Nel passaggio dal software al mondo fisico questa distinzione non è un dettaglio: è una delle condizioni necessarie perché l’automazione sia realmente utilizzabile.
Questo articolo è stato redatto con il supporto di strumenti di intelligenza artificiale (AI).
