Immagina di aver appena acquistato un motore potentissimo, l’apice dell’ingegneria moderna. Te lo consegnano su un bancale di legno, nudo e crudo. Per poterlo usare in strada, devi costruire da zero l’intera automobile. Dovrai assemblare lo sterzo, i freni, il serbatoio e l’elettronica di bordo. Fino a poco tempo fa, integrare un modello di intelligenza artificiale in un’applicazione aziendale funzionava esattamente così.

Il modello era il motore, ma tutto il resto dell’infrastruttura necessaria per farlo funzionare dovevi costruirtelo da solo.

Nella nostra esperienza diretta con architetture cloud native abbiamo visto spesso tecnologie emergenti ridefinire interi mercati. Oggi, i vendor di modelli di frontiera stanno spostando il campo di battaglia sull’infrastruttura di orchestrazione. Il valore si è spostato dall’intelligenza del modello alla solidità dell’harness che lo governa.

Una lucida analisi di Janakiram MSV pubblicata su The New Stack evidenzia un fatto cruciale. I giganti dell’intelligenza artificiale stanno offrendo questo telaio con modelli di business diametralmente opposti. Anthropic te lo noleggia a ore, come un servizio chiavi in mano. OpenAI ti regala i progetti per costruirlo, sperando che tu usi esclusivamente il suo motore.

Questa divergenza non è una semplice guerra di tariffe cloud. È il momento esatto in cui si definisce il nuovo punto di lock-in architetturale per lo sviluppo di software basati su intelligenza artificiale personalizzata. La scelta tra un servizio gestito o un SDK open source non impatterà solo sulla fattura. Determinerà la portabilità, la flessibilità del sistema e il debito tecnico che le aziende dovranno gestire per il prossimo decennio.

Partiamo da un esempio pratico per capire come questa decisione sull’infrastruttura cambierà radicalmente il modo in cui sviluppiamo software.

Cos’è l’harness e perché è diventato il vero prodotto

La definizione di un nuovo standard

Per comprendere la portata di questo scontro di mercato, dobbiamo prima demistificare l’oggetto della contesa. In estrema sintesi, un modello linguistico (LLM), da solo, si limita a prevedere la parola successiva in base a un calcolo statistico. Non ha memoria delle conversazioni passate, non può interrogare un database aziendale e non può eseguire un’azione su un software esterno.

L’harness è il middleware che colma questo vuoto. È il codice che prende la richiesta dell’utente, recupera il contesto storico, interroga le API necessarie, impacchetta tutto per il modello e poi traduce la risposta testuale in un’azione concreta sul sistema.

Il termine ha iniziato a circolare prepotentemente a febbraio. In quel periodo, OpenAI ha pubblicato un post tecnico sul proprio blog descrivendo come un piccolo team interno fosse riuscito a rilasciare in produzione un sistema complesso da 1 milione di righe di codice. La particolarità? Letteralmente zero righe erano state scritte da mani umane.

A canonizzare definitivamente il concetto ci ha pensato Martin Fowler in un lungo saggio, definendo i confini esatti di questa architettura:

“L’harness è tutto ciò che circonda un modello AI, tranne il modello stesso. È l’infrastruttura di gestione vitale che trasforma un generatore di testo imprevedibile in un operatore software in grado di eseguire compiti in produzione.”

L’harness amministra l’invocazione del modello e la memoria a lungo termine. Si occupa dell’orchestrazione degli strumenti esterni e dell’esecuzione del codice in ambienti isolati (sandbox). Regola inoltre i permessi di sicurezza e il recupero dagli errori. Senza un harness robusto, un agente AI è inutile.

Il costo occulto delle soluzioni fai-da-te

Per 18 mesi, a partire dall’esplosione dell’AI generativa, l’intero mercato ha vissuto in un limbo tecnologico. I vendor cloud e i creatori di framework offrivano solo componenti parziali, frammentati e spesso incompatibili tra loro. Se un’azienda voleva portare un agente AI in produzione, era costretta a fare il lavoro sporco. I team interni dovevano assemblare soluzioni custom incollando parti open source.

Le startup raccoglievano capitali per vendere versioni pre-confezionate di questa infrastruttura. L’harness è diventato un mercato proprio perché i pezzi a disposizione non fornivano una risposta pulita e definitiva alle esigenze enterprise.

Nei nostri percorsi di affiancamento alle aziende, abbiamo osservato le conseguenze dirette di questa frammentazione. Costruire un layer di governo proprietario genera colli di bottiglia. I team devono gestire in prima persona le differenze tra orchestrazione e coreografia nei sistemi complessi. Passano mesi solo per assicurarsi che ogni componente comunichi in modo sicuro e deterministico, distogliendo risorse dallo sviluppo del prodotto reale.

Ora che l’harness ha un nome e un perimetro definito, i creatori dei modelli hanno deciso di riprendersi questo spazio. E lo stanno facendo imponendo visioni del mondo radicalmente diverse.

Il bivio del mercato: l’approccio “tutto compreso” contro l’open source

La via del servizio gestito

La frammentazione degli ultimi diciotto mesi sta per finire, sostituita da una polarizzazione netta. Da un lato abbiamo l’approccio del servizio completamente gestito. Dall’altro troviamo la via dell’infrastruttura aperta ma basata sul principio del bring-your-own-compute.

Anthropic ha tracciato la prima strada lanciando il suo servizio Managed Agents. La promessa è la massima riduzione del carico cognitivo per i team di sviluppo. Tu definisci l’agente, gli strumenti che può usare e i limiti di sicurezza. Anthropic si occupa di far girare l’ambiente di esecuzione. Amministrano le sessioni lunghe, l’esecuzione del codice in sandbox, i permessi e il tracciamento end-to-end.

Il modello di fatturazione è diretto: 0,08 dollari per ora di sessione, in aggiunta al consumo dei token. Non è una tariffa da sandbox o da semplice prototipo. I primi casi d’uso enterprise dimostrano che l’approccio di Anthropic è pronto per la produzione pesante:

• Notion usa questi managed agents per eseguire decine di compiti di delega in parallelo.

• Rakuten ha schierato agenti specializzati in vendite, marketing, finanza e risorse umane.

• Sentry ha costruito un agente che prende un bug segnalato e lo trasforma in una pull request aperta, senza alcun intervento umano intermedio.

• Asana lo ha integrato nella sua funzione AI Teammates.

Siamo davanti al passaggio definitivo dal “fai-da-te” dell’orchestrazione al modello Managed Agents. La vera notizia è la comodità operativa: Anthropic si prende carico dell’infrastruttura di esecuzione (l’harness gestito), lasciando alle aziende solo l’onere della logica di business.

L’alternativa aperta e i costi di ownership

Sette giorni dopo il lancio di Anthropic, OpenAI ha risposto con una mossa speculare e contraria. Ha rilasciato un aggiornamento del suo Agents SDK, rigorosamente open source. Questo strumento include un harness nativo per i modelli OpenAI, offrendo memoria configurabile, orchestrazione e strumenti per il filesystem.

La differenza cruciale è nel modello di delivery e di prezzo.

OpenAI non fa girare il calcolo per te e non applica alcun costo di runtime proprietario o tariffe orarie. Ti fornisce il codice di orchestrazione, ma l’infrastruttura fisica devi mettercela tu. L’SDK supporta nativamente 7 provider di sandbox (Blaxel, Cloudflare, Daytona, E2B, Modal, Runloop e Vercel) e permette di salvare lo stato delle operazioni su sistemi di storage come S3, GCS, Azure Blob e Cloudflare R2.

Il costo totale di ownership cambia radicalmente con questo approccio. Se scegli un agents SDK open source, non paghi la licenza del framework. Tuttavia, dovrai sostenere i costi di elaborazione per i provider di sandbox e le spese di archiviazione cloud per mantenere la memoria degli agenti. Inoltre, dovrai calcolare il costo del tempo ingegneristico necessario per configurare e mantenere questa infrastruttura distribuita.

Questa abbondanza di opzioni infrastrutturali richiama da vicino le sfide della multi cloud orchestration per le organizzazioni. Il costo totale per l’azienda non è zero. Ma OpenAI rinuncia deliberatamente a monetizzare il layer di esecuzione per spingere il consumo puro dei propri modelli.

La terza via: la granularità di Google e Microsoft

Google e Microsoft non stanno a guardare, ma propongono una terza via basata sulla granularità dei servizi. Hanno compreso che le aziende enterprise potrebbero non volere un pacchetto chiuso come quello di Anthropic, ma nemmeno accollarsi l’onere infrastrutturale totale richiesto da OpenAI.

Google, con il suo Gemini Enterprise Agent Platform ha scelto di fatturare a consumo per singoli componenti, frammentando il costo dell’orchestrazione in base a ciò che viene effettivamente utilizzato. Microsoft, con il Foundry Agent Service, applica una tariffazione legata all’uso specifico di strumenti computazionalmente intensivi, come il Code Interpreter. AWS si accoda a questa tendenza preparando uno Stateful Runtime Environment per gestire la memoria a lungo termine in collaborazione con OpenAI e Bedrock AgentCore.

Questi giganti confermano una regola non scritta del nuovo mercato: chi controlla l’harness, controlla i margini di profitto e il lock-in dell’intero ecosistema AI.

La crisi dei framework e il dilemma del team interno

La pressione sulle soluzioni agnostiche

Mentre i titani dell’intelligenza artificiale posizionano le loro pedine infrastrutturali, l’impatto più violento si sta abbattendo sull’ecosistema delle startup. Per mesi, i framework orizzontali hanno prosperato colmando esattamente il vuoto che i grandi vendor avevano lasciato aperto.

Prendiamo il caso dei framework di orchestrazione progettati per essere agnostici rispetto al modello sottostante. Strumenti come LangChain, CrewAI e VoltAgent si trovano ora in una posizione di estrema vulnerabilità. Curiosamente, VoltAgent è sostenuto da investitori di peso come Insight Partners, un fondo che investe anche in OpenAI e Anthropic.

Il loro argomento di vendita principale è sempre stato la flessibilità, promettendo di evitare il legame con un singolo fornitore di AI. Ma come si fa a vendere un layer di orchestrazione agnostico quando il creatore del modello ti regala un harness nativo? Soprattutto se questo strumento è open source, gratuito e perfettamente ottimizzato per le sue API.

La pressione è insostenibile. La promessa di evitare il vendor lock-in perde di attrattiva quando il framework di terze parti introduce latenza o bug di astrazione. Spesso questi strumenti non riescono a tenere il passo con le nuove funzionalità rilasciate dai vendor, spingendo inevitabilmente i team di sviluppo a preferire lo strumento nativo.

Le nicchie di sopravvivenza

Tuttavia, se la competizione sull’orchestrazione di base sembra persa, esistono delle eccezioni strategiche per chi cambia terreno di scontro. Non tutte le startup dell’harness sono destinate a soccombere.

Sycamore, ad esempio, ha recentemente raccolto 65 milioni di dollari in un round seed guidato da Coatue e Lightspeed. Il motivo di questo successo non risiede nel tentativo di competere sull’orchestrazione di base. Si sono concentrati su un problema che i grandi vendor non vogliono risolvere, creando un sistema operativo per l’AI enterprise focalizzato sulla governance e sul controllo multi-modello.

Le grandi aziende hanno bisogno di audit trail inattaccabili. Richiedono strategie architetturali per mitigare i rischi dei sistemi non deterministici e garanzie di compliance rigorose. Sycamore sopravvive perché vende indipendenza e sicurezza a livello aziendale, non solo comodità per lo sviluppatore.

Questa dinamica di mercato ci porta direttamente al cuore del problema per le aziende strutturate. Di fronte alla crisi dei framework orizzontali, l’obiezione classica dei dipartimenti IT riemerge con forza. Molti pensano che se i framework esterni sono a rischio e i servizi gestiti creano lock-in, convenga costruirsi l’harness in casa. Nel contesto dell’intelligenza artificiale generativa, questa è una trappola mortale.

Il vero costo non è in fattura: la lezione del cloud computing

La fine dell’illusione del flat-rate

Il calcolo tra costruire una soluzione interna e acquistarne una di mercato si è arricchito di due nuovi punti di riferimento. Da un lato, il benchmark della comodità: Anthropic ti offre un’infrastruttura completa a 0,08 dollari l’ora. Dall’altro, il benchmark della supervisione: OpenAI ti regala l’architettura base e ti lascia scegliere dove farla girare.

Se pensi che i costi di esecuzione e orchestrazione siano un problema secondario gestibile internamente, guarda cosa sta succedendo ai leader di mercato. Microsoft ha recentemente annunciato che da Giugno 2026 GitHub Copilot abbandonerà il modello di abbonamento flat per passare a una fatturazione a consumo basata su AI Credits.

Il motivo è puramente matematico. I costi di inferenza e di orchestrazione delle sessioni autonome sono diventati insostenibili con una tariffa fissa. Se un gigante come Microsoft deve scaricare i costi di esecuzione sull’utente finale tramite un sistema a consumo, pensare di poter gestire economicamente un’infrastruttura AI custom all’interno di una normale azienda è un azzardo finanziario.

Per i team che sono ancora nella fase di prototipazione, giustificare la costruzione di un’infrastruttura di orchestrazione da zero è diventato indifendibile. Costruire la memoria, gestire i container per il codice e orchestrare i tool era considerato un lavoro differenziante. Oggi è una commodity accessibile tramite una semplice chiamata API o scaricando un SDK gratuito.

L’impatto più duro è per i team che hanno già sistemi in produzione. L’obiezione tipica è che l’harness interno sia perfettamente ottimizzato per i carichi di lavoro specifici dell’azienda. La realtà è molto più spietata:

Un team interno di pochi ingegneri non può fisicamente competere con i budget di ricerca di quattro vendor di frontiera. Mantenere quel sistema custom diventerà progressivamente più lento e immensamente più costoso.

Inoltre, diventerà un incubo per il recruiting. Quale ingegnere talentuoso vorrà lavorare alla manutenzione di un harness interno legacy quando il resto del mondo usa standard di mercato?

Il parallelismo storico con le infrastrutture cloud

Abbiamo già visto questo film. La storia dell’infrastruttura cloud ci insegna esattamente come andrà a finire.

Quando il cloud computing è diventato lo standard, il mercato non è stato assorbito da un’unica soluzione monolitica. Terraform è rimasto uno standard open source dominante anche quando AWS spingeva fortemente il suo servizio gestito CloudFormation. Allo stesso modo, abbiamo visto il potenziale dell’open source nell’orchestrazione di infrastrutture scalabili affermarsi con Kubernetes. È diventato lo standard de facto, costringendo AWS, Google e Microsoft a offrire servizi gestiti basati su di esso.

Il mercato dell’harness per l’AI si dividerà seguendo la stessa faglia geologica. L’open source non ucciderà i servizi gestiti, e i servizi gestiti non elimineranno l’open source. Coesisteranno perché rispondono a profili di acquirenti fondamentalmente diversi.

Le aziende che privilegiano il time-to-market graviteranno verso soluzioni come Anthropic Managed Agents. Le organizzazioni che necessitano di amministrazione granulare adotteranno architetture basate sull’SDK di OpenAI o su framework specializzati.

La vera lezione è chiara. L’harness, che fino a ieri doveva essere il fossato difensivo per molte aziende, è diventato a tutti gli effetti l’infrastruttura di base.

Conclusione

L’analisi di Janakiram MSV mette in luce una verità scomoda per l’industria del software. L’infrastruttura di orchestrazione degli agenti AI non è più l’elemento che differenzia il tuo prodotto sul mercato. I giganti tecnologici hanno deciso che il “telaio” deve essere standardizzato, usando la leva del prezzo per imporre le loro architetture, dall’abbonamento orario al regalo open source.

Costruire questa infrastruttura da zero all’interno della propria azienda significa accumulare un debito tecnico che diventerà presto insostenibile. La vera decisione oggi non è stabilire quale modello linguistico sia marginalmente più intelligente in un benchmark sintetico. La decisione critica è scegliere a quale architettura di orchestrazione vuoi legare il destino operativo del tuo software.

Stiamo assistendo a un cambiamento di paradigma verso un approccio agentic-first. Il valore non risiede più nel costruire i tubi dell’infrastruttura, ma nel modo in cui l’intelligenza artificiale orchestra i processi di business reali. Scegliere l’harness sbagliato oggi significa passare i prossimi cinque anni a fare manutenzione idraulica, mentre i tuoi concorrenti inventano il futuro.

Il Drupal Developer Days (DDD) 2026 di Atene ha mostrato un ecosistema open source concentrato sull’ingegneria strutturale. Le demo dei generatori di testo hanno lasciato il posto a implementazioni concrete. La community sta decidendo attivamente le regole d’ingaggio per l’integrazione dei large language model, preferendo un approccio architetturale solido a un’adozione passiva.

L’Intelligenza Artificiale era il protagonista trasversale dell’evento, declinata attraverso la lente del pragmatismo tecnico. Si è discusso di AI come strumento di sviluppo avanzato, come fenomeno sociale che impatta la formazione dei team e come opportunità per ridefinire i confini del CMS. Se vuoi comprendere il punto di partenza di questa evoluzione, scopri la nostra panoramica completa sulle feature AI in Drupal.

Il messaggio emerso dalla capitale greca è chiaro: l’Open Source rappresenta oggi un solido garante della sovranità digitale in un mercato guidato da vendor proprietari. SparkFabrik ha partecipato portando sul palco codice reale e soluzioni da applicare in produzione, dimostrando che l’innovazione si guida risolvendo problemi complessi.

Day 1 - L’infrastruttura dell’innovazione e le performance estreme

L’integrazione dell’AI in Drupal sta cambiando l’architettura stessa del sistema, richiedendo basi DevOps solide. Gli interventi tecnici di Frederik Wouters, incentrato su Autonomous Drupal, comandi vocali e interfacce conversazionali, e di Marcus Johansson, focalizzato sull’AI module 2.0, i Guardrails e lo shift verso Symfony AI, hanno tracciato la rotta. Parliamo di un layer di intelligenza capace di orchestrare processi complessi, analizzare il contesto e suggerire ottimizzazioni strutturali.

Questa ambizione si confronta con i limiti fisici dell’infrastruttura. L’AI richiede un ecosistema sottostante capace di reggere carichi computazionali anomali, dove le performance del database restano il collo di bottiglia fondamentale.

Passare da 20 secondi a 500 millisecondi per il caricamento di una vista complessa è pura ingegneria dei dati. L’intervento di Robin Colombier ha affrontato il problema della latenza attraverso l’uso strategico delle viste materializzate su PostgreSQL. Invece di calcolare query complesse in tempo reale ad ogni richiesta, i dati vengono pre-calcolati e archiviati, aggiornandosi solo quando necessario.

L’intelligenza artificiale non perdona le architetture fragili. Se il database non è ottimizzato, l’aggiunta di agenti AI in background rischia di sovraccaricare il sistema sotto il peso delle query concorrenti.

Questa ottimizzazione è un prerequisito per un’implementazione AI efficace. Quando un agente autonomo deve analizzare migliaia di nodi per vettorizzare i contenuti, il database deve rispondere in millisecondi. Per sostenere questa scalabilità orizzontale e gestire i picchi di carico generati dalle operazioni asincrone, l’infrastruttura tradizionale on-premise mostra rapidamente i suoi limiti. In questo contesto, approfondisci i vantaggi dell’approccio Cloud Native per la scalabilità, un paradigma architetturale che permette di disaccoppiare i servizi e scalare dinamicamente le risorse di calcolo esattamente dove servono.

Drupal AI 2.0: architettura e stato dell’adozione

Marcus Johansson ha delineato lo stato del modulo AI, ed i piani verso la versione 2.0. L’adozione è misurabile: al 12 aprile 2026, il modulo AI ha raggiunto 13.980 installazioni attive su Drupal.org.

L’architettura è in evoluzione profonda, con l’adozione di Symfony AI come layer di astrazione unificato. Sul fronte della sicurezza è pienamente operativo il sistema di Guardrails, che impedisce ai modelli di esporre dati personali, generare contenuti fuori contesto o rispondere a prompt pericolosi (una contribuzione di SparkFabrik).

Sono anche già disponibili due recipe pronte all’uso: ai_recipe_guardrails_pii, che blocca email, numeri di telefono, IBAN e carte di credito, e ai_recipe_guardrails_prompt_safety, che copre consigli legali o medici, HTML pericoloso e code injection. Entrambe sono installabili con un singolo comando drush recipe, offrendo un’implementazione concreta e rapida per chi vuole partire senza costruire la configurazione da zero.

Inoltre, uno degli sviluppi in corso è il supporto MCP (Model Context Protocol), che trasformerà Drupal in uno strumento interrogabile da agenti AI esterni come Claude o Cursor. Il maintainer del modulo Drupal MCP Client è il nostro Roberto Peruzzo.

La prima giornata ha quindi evidenziato un principio pratico: prima di implementare l’AI nel layer applicativo, è necessario modernizzare il layer dati e l’infrastruttura di hosting.

Ma la giornata non si è focalizzata solo sul codice. C’era anche una prospettiva più ampia da considerare.

Ad aprire la giornata, infatti, c’è stato il fireside chat tra Dries Buytaert e il Prof. Dimosthenis Anagnostopoulos, Segretario Generale per la Trasformazione Digitale del governo greco. Non è scontato vedere un rappresentante di governo seduto sul palco di una conferenza di sviluppatori open source. È un segnale: i temi che la community discute da anni, come la sovranità digitale, il controllo sull’infrastruttura e i rischi del vendor lock-in su modelli proprietari, stanno entrando nell’agenda politica europea. L’Open Source si conferma il garante del controllo istituzionale sui dati, un tema critico che invita ad approfondire l’importanza della sovranità digitale nell’open source.

Day 2 - Automazione, site building e l’ecosistema in evoluzione

Il secondo giorno ha spostato il focus dalla base dati al livello di presentazione e automazione, evidenziando l’evoluzione in corso nella developer experience. La sessione di Pierre Dureau ha acceso i riflettori su Display Builder. In particolare, la sessione si è concentrata su HTMX, una tecnologia che sta guadagnando trazione nella community per la sua capacità di modernizzare il frontend senza introdurre la complessità di framework single page application (SPA) pesanti come React o Vue.

HTMX permette di ottenere interfacce utente dinamiche e parzialmente aggiornabili lavorando direttamente con l’HTML renderizzato dal server. Questo approccio riduce il carico cognitivo per i team di sviluppo, mantenendo la logica di business ancorata al backend di Drupal. In combinazione con strumenti emergenti, la creazione di interfacce diventa un processo fluido e modulare.

A questo proposito, l’ecosistema si sta arricchendo di soluzioni visive avanzate; un esempio eccellente di questa evoluzione è documentato nel talk di Michael Fanini su Display Builder al nostro evento Drupal X Business.

Parallelamente all’evoluzione del frontend, il backend sta vivendo un aggiornamento guidato dagli eventi. Il talk di Jürgen Haas su ECA (Event Condition Action) ha mostrato come l’automazione no-code e low-code si stia evolvendo nativamente dentro Drupal. ECA permette ai site builder di configurare workflow complessi, come l’invio di notifiche basate su trigger specifici o la manipolazione di entità, senza scrivere una riga di PHP personalizzato.

Questa accessibilità della logica di business è un passaggio importante. Se l’AI dovrà interagire con Drupal, lo farà sempre più innescando eventi che il sistema ECA potrà intercettare e gestire.

Al recente DrupalCon Chicago è emerso un dato relativo ad ECA che rende tutto questo molto concreto: Jürgen, in qualità di sviluppatore senior ed orchestrando strumenti AI avanzati, ha scritto, validato e documentato 90.000 righe di codice in sole sei settimane. Non è un esperimento: è un modulo contrib in produzione, usato da migliaia di siti. Il dato mostra che l’AI come amplificatore di competenze non è un concetto astratto, ma è già misurabile. Ne abbiamo parlato anche nel nostro articolo sull’approccio agentic-first allo sviluppo Drupal.

Molto interessante anche il talk di Klaus Purer che ha presentato Mago, un nuovo tool per PHP che può effettuare una verifica di coding standards e problemi del codice in pochi secondi.

L’ecosistema sta maturando per fornire ai team strumenti che astraggono la complessità tecnica, permettendo agli sviluppatori di concentrarsi sull’architettura e sull’integrazione di servizi avanzati.

Se vuoi capire come questi strumenti si inseriscono nella strategia complessiva della piattaforma, esplora l’evoluzione di Drupal CMS verso il no-code.

Day 3 - Etica, SDC e il contributo di SparkFabrik

La tecnologia senza direzione produce solo debito tecnico. Il terzo giorno del DDD si è aperto affrontando la responsabilità che deriva dall’adozione dell’AI, partendo dal keynote di Ifrik sull’etica. La community ha discusso il problema dei bias nei dataset di addestramento e l’impatto sociale dell’automazione. Non si tratta di discorsi astratti, ma di decisioni ingegneristiche: come strutturiamo i permessi affinché un modello AI non esponga dati sensibili? Come garantiamo che i contenuti generati siano accessibili e inclusivi?

Sul fronte dello sviluppo frontend, la spinta verso la modularità ha trovato conferme negli interventi di David Galeano su workflows agentici avanzati e FlowDrop e Anand Toshniwal sui Single Directory Components (SDC). Gli SDC supportano la developer experience: raggruppare markup, stili e logica JavaScript in una singola directory facilita la manutenzione e il lavoro degli agenti AI, che possono analizzare e generare componenti isolati con maggiore precisione.

Symfony Messenger e Drupal Queues: il talk di SparkFabrik

La leadership tecnologica si dimostra scrivendo codice e definendo standard. Il contributo di SparkFabrik a questa evoluzione architetturale è arrivato con il talk di Luca Lusso su Symfony Messenger e l’integrazione in Drupal tramite il modulo sm (drupal.org/project/sm), un esempio di come vogliamo fare la differenza affrontando problemi reali.

L’integrazione di modelli di intelligenza artificiale richiede chiamate API esterne che possono impiegare secondi per rispondere o fallire per timeout di rete. Bloccare il processo PHP principale in attesa di una risposta da OpenAI o Anthropic significa compromettere le performance del sito. Il modulo sm risolve questo problema, permettendo di delegare task pesanti a code di messaggi asincrone gestite da worker in background.

Questo approccio garantisce pipeline resilienti, con logiche di retry automatiche in caso di fallimento delle API, mantenendo l’interfaccia utente reattiva. È la dimostrazione di come SparkFabrik affronti i colli di bottiglia enterprise rilasciando soluzioni open source per l’intera community. Per vedere come portiamo queste competenze sul palco, guarda i nostri tech talk e interventi alle conferenze internazionali. Risolvere problemi asincroni complessi è il fondamento su cui si costruiscono le applicazioni basate sull’AI.

L’impatto umano: formazione e AI come amplificatore di competenze

L’interesse per le nuove architetture si affianca alla sfida della sostenibilità del talento. Durante i tre giorni di Atene, il dibattito sul mentoring nell’era dell’AI ha occupato uno spazio centrale. Se l’intelligenza artificiale generativa è in grado di scrivere istantaneamente il boilerplate, configurare le route e abbozzare i test unitari, come faranno i nuovi sviluppatori a imparare i fondamenti del framework?

Il rischio è l’atrofizzazione della capacità di problem solving. Un junior che si limita ad accettare i suggerimenti dell’AI senza comprenderne le implicazioni architetturali faticherà a intervenire quando i sistemi falliscono in produzione. La risposta emersa dalla community è che l’AI non deve sostituire il mentoring umano, ma trasformarsi in uno strumento di supporto.

La formazione continua diventa quindi una priorità diffusa, che non riguarda solo i profili junior. Anche gli sviluppatori senior e i tech lead devono imparare a governare l’AI, utilizzandola come un mentore digitale per esplorare nuovi linguaggi o per eseguire refactoring complessi, mantenendo però il controllo sulla logica di dominio. L’obiettivo è sviluppare un pensiero critico, spostando l’attenzione dalla sintassi alla progettazione di sistemi sicuri e scalabili.

L’ingegneria del software non consiste nel digitare codice velocemente, ma nel prendere decisioni architetturali corrette. L’AI accelera la digitazione; l’essere umano deve garantire la direzione.

È l’approccio che abbiamo formalizzato nella nostra AI Vision: l’AI come strumento di augmentation, non di sostituzione.

La migliore tecnologia nasce dall’armonia tra competenze tecniche profonde e relazioni umane solide.

In questo scenario, da una parte emerge l’esigenza di implementare un solido approccio AgentOps per l’orchestrazione di agenti autonomi, dall’altra la scelta di tecnologie Open Source assume una valenza strategica. Mantenere il controllo sui propri dati, sui modelli di addestramento e sull’infrastruttura di erogazione aiuta a evitare il vendor lock-in imposto dai grandi player tecnologici, garantendo la sovranità digitale, un tema critico specialmente per le pubbliche amministrazioni e le grandi enterprise europee.

Conclusione

Il Drupal Developer Days di Atene ha mostrato come l’Intelligenza Artificiale nel mondo Drupal si stia integrando come requisito architetturale, spingendo la community ad adottare paradigmi Cloud Native, code asincrone e interfacce ottimizzate.

Il futuro di Drupal è ibrido. Da un lato, richiede efficienza tecnica per supportare agenti autonomi e automazioni; dall’altro, esige responsabilità umana per governare l’etica dei dati, l’accessibilità e la formazione dei team. Non c’è innovazione sostenibile senza un controllo rigoroso sulla qualità del software e sulla sicurezza della supply chain.

La community ha dimostrato ancora una volta che l’Open Source non è solo tecnologia: è il modo in cui si costruisce fiducia collettiva attorno a scelte condivise, come approfondito nella nostra visione sullo sviluppo Drupal agentic-first. Noi ci siamo stati, abbiamo contribuito con codice reale, e siamo già proiettati al prossimo appuntamento con la community, al Drupal Developer Days Valencia 2027.

Ma ancora prima, ci vediamo al DrupalCamp Italy 2026!

Il mercato dello sviluppo web ha subito una frattura irreversibile. Da un lato, la proliferazione di strumenti basati sull’intelligenza artificiale ha ridotto la creazione di siti web basici a una commodity a basso costo. Dall’altro, le architetture aziendali complesse richiedono fondamenta ingegneristiche sempre più solide, ed è in questo scenario che si inserisce il riposizionamento strategico di Drupal. La scelta della tecnologia core non è più una decisione tattica legata al marketing, ma un imperativo strategico per supportare integrazioni profonde e flussi di dati critici.

Il mercato dei siti web semplici, quelli che definiamo siti vetrina o brochureware, è stato completamente commoditizzato. Tra site builder visuali chiusi e la capacità della GenAI di produrre codice frontend, lo scenario è decisamente mutato. Il valore di costruire un sito semplice con un framework robusto è crollato.

Mentre il mercato di fascia bassa si satura, si apre un divario nella fascia alta. Qui nasce la necessità di gestire infrastrutture digitali complesse, dati strutturati e processi business-critical. Per anni, il mercato ha trattato i content management systems come strumenti generici, ma oggi quella visione è obsoleta.

Questa biforcazione è un tema caldissimo, che permea il sottofondo di tutte le discussioni strategiche. Lo abbiamo percepito e vissuto a tutte le principali conferenze degli ultimi mesi.

È emerso come tema centrale a Drupal Pivot EU, l’esclusiva unconference tenutasi a Ghent nel gennaio 2026. Un evento ristretto che ha riunito i principali leader tecnologici europei per ridefinire il ruolo dei sistemi open source nelle architetture enterprise. Noi di SparkFabrik abbiamo partecipato attivamente ai tavoli di lavoro con il nostro CTO Paolo Mainardi, contribuendo a tracciare la rotta per i prossimi anni.

Abbiamo visto lo stesso filo conduttore anche a Drupal4GovEU, l’evento incentrato sull’open source per la Pubblica Amministrazione europea. Ed è ovviamente apparso anche in diversi talk presentati ai grandi eventi, come lo scorso DrupalCon di Vienna ed il recentissimo DrupalCon Chicago.

La conclusione emersa è inequivocabile: continuare a trattare le piattaforme di content management come semplici erogatori di pagine web è un errore di calcolo che genera debito tecnico.

Ed infatti, Drupal si sta affermando e riposizionando non come semplice CMS, ma come il framework d’elezione per le Digital Experience Platform (DXP) ambiziose. Non stiamo più parlando di gestire pagine web, ma di governare API, identità digitali e flussi di lavoro complessi in un ambiente sicuro.

Le aziende lungimiranti stanno riposizionando i propri investimenti. Spostano il budget dai frontend effimeri verso infrastrutture di backend governabili, sicure e progettate per durare nel tempo.

Per un decisore aziendale, comprendere queste dinamiche è fondamentale per allocare correttamente il budget IT. Continuare a trattare Drupal esclusivamente come un gestore di contenuti significa sottostimare un asset strategico fondamentale per la resilienza digitale, soprattutto quando unito a tecnologie cloud native ed AI.

Drupal come abilitatore di business: da CMS a Business Application Framework

Drupal si è evoluto da semplice CMS open source a un vero e proprio framework applicativo per il mercato enterprise. Funziona come abilitatore di business fornendo l’infrastruttura architetturale necessaria per gestire flussi di lavoro complessi, integrazioni API avanzate e dati strutturati, superando i limiti funzionali dei semplici siti vetrina.

Durante i tavoli di lavoro a Ghent, la discussione ha evidenziato come sia necessaria una ridefinizione ontologica. La percezione del mercato deve allinearsi alle reali capacità tecniche della piattaforma.

Tradizionalmente, un CMS è visto come un repository per testi e immagini, ma questa visione è limitante. Non vendiamo più un prodotto pacchettizzato. Con Drupal forniamo un motore relazionale capace di orchestrare l’intera esperienza digitale di un’azienda, grazie a un’architettura a entità estremamente flessibile.

Questo cambio di prospettiva trasforma il software da centro di costo a vero e proprio Business Application Framework, capace di modellare logiche aziendali uniche senza forzare i processi interni per adattarli a software preimpostati.

Cosa significa in termini pratici per il business? Significa trasformare la piattaforma nella spina dorsale per:

• Intranet aziendali complesse: Gestione granulare dei permessi, flussi di approvazione multilivello e integrazione con Identity Provider aziendali. (Scopri il caso studio CNP Vita Intranet)
• Portali di servizi: Dove la sicurezza dei dati e l’accessibilità sono requisiti non funzionali mandatori.
• Headless Content Hub: Drupal funge da fonte unica di verità, disaccoppiando il backend dal frontend e distribuendo contenuti via API REST o GraphQL a diverse applicazioni consumer.
• Piattaforme di Data Management: Modellazione nativa di relazioni dati complesse senza la necessità di scrivere query SQL o gestire migrazioni di schema manuali.
• Sistemi LMS (Learning Management System): Piattaforme di e-learning proprietarie dove la tracciabilità dei progressi, la certificazione delle competenze e la protezione dei materiali didattici sono requisiti non negoziabili.

Un esempio concreto lo vediamo nel settore manifatturiero, dove Drupal viene adottato come middleware per aggregare dati provenienti da sistemi ERP e CRM, esponendoli in dashboard unificate. Questo è un utilizzo da framework applicativo puro, non da semplice gestore di pagine web.

Per i decisori IT, comprendere questa evoluzione significa entrare in una nuova era del content management per il business, dove la gestione dei contenuti è solo un sottoinsieme di capacità molto più ampie. Esiste oggi un divario incolmabile tra le soluzioni rapide e le piattaforme ingegnerizzate.

La differenza tra i due approcci si manifesta in diverse aree critiche:

• Distinzione tra “codice usa e getta” e “infrastruttura durevole”. AI, site builder visivi e framework frontend moderni eccellono nella creazione rapida di interfacce, ma introducono un alto tasso di obsolescenza. Le landing page generate hanno un ciclo di vita misurabile in mesi e non sopravvivono a pivot aziendali.
• Manutenibilità a lungo termine. Il backend, la logica di business e il modello dei dati devono garantire stabilità duratura. Un’infrastruttura basata su Drupal è progettata per cicli di vita decennali, assorbendo le evoluzioni del business.
• Dati isolati vs hub centralizzati. I sistemi chiusi frammentano le informazioni in silos inaccessibili. Un approccio framework-first espone nativamente ogni entità tramite API REST o GraphQL, fungendo da singola fonte di verità per ecosistemi omnichannel.
• Logica standard vs logica custom. I prodotti SaaS impongono i propri workflow operativi. Un’architettura aperta permette di mappare i permessi granulari e i flussi di approvazione esattamente sulle gerarchie aziendali esistenti.

Scegliere questa strada significa investire in una tecnologia che scala con la complessità del business, garantendo fondamenta solide per il futuro. (Per approfondire: Guida completa - Perché scegliere Drupal per siti aziendali complessi)

Drupal è la soluzione ideale per la sovranità digitale aziendale?

I vantaggi di Drupal per la sovranità digitale risiedono nel controllo totale sull’architettura e sui dati. Essendo open source, elimina il vendor lock-in tipico delle piattaforme SaaS, consentendo ai CTO di implementare modelli di intelligenza artificiale sicuri e mantenere la piena conformità infrastrutturale, senza cedere il controllo a terzi.

Nel mercato enterprise europeo, il concetto di sovranità viene spesso ridotto a una mera questione di compliance normativa e localizzazione geografica dei server per rispettare il GDPR. Questa visione è limitante. La vera sovranità tecnologica si ottiene solo quando un’organizzazione possiede la capacità incondizionata di ispezionare, modificare e migrare il proprio stack software senza chiedere il permesso a terzi.

Quando l’infrastruttura critica poggia su servizi cloud chiusi, l’azienda cede il controllo della propria roadmap tecnologica alle decisioni di un fornitore esterno. Il vendor lock-in rappresenta oggi il rischio operativo più sottovalutato nei bilanci IT. Modifiche arbitrarie ai modelli di pricing, deprecazione improvvisa di API fondamentali o acquisizioni societarie possono paralizzare le operazioni digitali di un’azienda.

L’adozione di standard aperti neutralizza questo rischio alla radice. Restituisce al management il potere contrattuale e la libertà di scegliere dove e come eseguire i propri carichi di lavoro, sia su cloud provider hyperscaler che su infrastrutture private.

Questa indipendenza diventa cruciale nell’era dell’intelligenza artificiale. Le aziende possiedono patrimoni informativi inestimabili che non possono essere ceduti in pasto a modelli linguistici pubblici. La Sovereign AI richiede piattaforme capaci di orchestrare modelli open source o istanze private all’interno del perimetro aziendale, permettendo di sfruttare l’intelligenza artificiale senza esporre dati sensibili a reti esterne.

La community Drupal condivide questa visione, abbracciando un approccio vendor-agnostic facilmente adattabile. Utilizzando un framework aperto, è possibile garantire sicurezza e compliance per i dati aziendali implementando sistemi di Retrieval-Augmented Generation che interrogano i database interni senza mai esporre la proprietà intellettuale su reti non controllate.

Come il platform engineering trasforma Drupal in un’infrastruttura durevole?

Il platform engineering trasforma Drupal in un’infrastruttura durevole applicando pratiche cloud-native che garantiscono massima affidabilità e scalabilità. Standardizzando le operazioni tramite una piattaforma interna, i team di sviluppo riducono il carico cognitivo, abbattono il debito tecnico e accelerano significativamente il time-to-market delle nuove funzionalità.

La trasformazione strategica di Drupal in un’applicazione business-critical non sarebbe possibile senza un’evoluzione dell’infrastruttura sottostante. L’abbandono dei vecchi paradigmi di hosting monolitico è il prerequisito per operare su scala enterprise, in favore di un approccio Cloud Native e di pratiche di Platform Engineering.

La visione di SparkFabrik si basa su un principio ingegneristico rigoroso: il valore del software è inseparabile dalla qualità dell’infrastruttura che lo ospita.

Non si tratta di una scelta stilistica, ma di un requisito di affidabilità. Quando un’applicazione diventa centrale per i processi aziendali, i tempi di inattività o i colli di bottiglia nelle prestazioni non sono tollerabili. Investire nella piattaforma sottostante è l’unico metodo comprovato per mitigare l’obsolescenza e garantire la continuità operativa.

Per trasformare un CMS in una vera applicazione cloud-native, è indispensabile creare una internal developer platform per standardizzare le operazioni. Questo approccio metodologico sposta il focus dalla gestione manuale dei server all’automazione dei processi, offrendo vantaggi tangibili al business:

1. Immutabilità e affidabilità tramite containerizzazione. L’utilizzo di container ed orchestratori moderni (es. Docker, Kubernetes) permette di gestire l’infrastruttura come codice. Gli ambienti di produzione non vengono “aggiornati” manualmente, ma sostituiti interamente a ogni deploy. Questo elimina la “configuration drift” e garantisce che l’ambiente di sviluppo sia identico a quello di produzione, riducendo i bug imprevisti.
2. Scalabilità orizzontale, resilienza e self-healing. Le applicazioni business hanno carichi di lavoro variabili. Un’architettura basata su orchestratori come Kubernetes permette a Drupal di scalare orizzontalmente (aggiungendo pod/nodi) in risposta al traffico reale. Questo garantisce alta disponibilità e self-healing, ripristinando automaticamente i processi falliti senza intervento umano e garantendo l’uptime.
3. Standardizzazione operativa e riduzione del carico cognitivo con l’Internal Developer Platform (IDP). Fornendo agli sviluppatori percorsi standard e risorse preconfigurate, si elimina la necessità di gestire configurazioni infrastrutturali complesse. I team possono così concentrarsi esclusivamente sulla scrittura della logica di business. Questo accelera il time-to-market mantenendo il controllo centralizzato sulla governance dell’infrastruttura.
4. Sicurezza integrata nella supply chain. Spostando i controlli di sicurezza nelle fasi iniziali dello sviluppo, le pipeline CI/CD automatizzate bloccano le vulnerabilità prima che raggiungano gli ambienti di produzione. Questo approccio proattivo è essenziale per rispettare gli standard di sicurezza enterprise, fin dalla prima riga di codice.

Per i decisori IT, l’investimento non è solo nel software applicativo: l’applicazione e la piattaforma devono essere progettate in simbiosi. Senza un’infrastruttura moderna, anche il miglior codice Drupal rischia di diventare debito tecnico ingestibile.

L’impatto di AI ed agenti in Drupal: collaborazione o sostituzione?

L’intelligenza artificiale non sostituisce l’architettura software, ma la potenzia accelerandone l’esecuzione tattica. Drupal fornisce la struttura, le regole di validazione e la verità dei dati su cui i modelli generativi possono operare, garantendo una governance a lungo termine essenziale per proteggere il patrimonio informativo delle aziende.

L’errore prospettico più comune tra i decisori IT è considerare l’AI come un’alternativa ai sistemi di backend tradizionali. Al contrario, i modelli linguistici avanzati necessitano di piattaforme strutturate per non generare allucinazioni o output incontrollabili. L’integrazione tra queste due tecnologie spinge il framework verso l’alto della catena del valore aziendale, trasformandolo nel direttore d’orchestra delle interazioni automatizzate.

Il vero salto di qualità risiede nell’Agentic AI, ovvero la capacità di orchestrare agenti autonomi che operano all’interno di un perimetro governato. Per i team di sviluppo, questo significa passare dalla semplice scrittura di prompt alla progettazione di istruzioni di sistema complesse che permettano agli agenti di interagire in sicurezza con le API della piattaforma (agentic coding).

I CTO devono adottare un nuovo approccio agentic-first nello sviluppo, assicurandosi che l’infrastruttura fornisca le regole di validazione, il contesto semantico e i limiti operativi entro cui l’intelligenza artificiale può muoversi senza corrompere i dati aziendali.

L’AI potenzia Drupal e, a sua volta, Drupal fornisce il contesto strutturato ed orchestrato perfetto in cui l’AI può prosperare. Questa “sinergia tecnologica” (ampiamente dibattuta in tutti gli eventi strategici, dal Drupal Pivot Unconference di Ghent ai grandi DrupalCon), si manifesta attraverso applicazioni pratiche che ridefiniscono l’efficienza dei team:

• Governance dei contenuti AI: I modelli generano volumi massivi di informazioni, contenuti e metadati, e Drupal agisce come layer di controllo. È il framework ad orchestrare gli agenti AI ed imporre i workflow di approvazione, garantendo che ogni output rispetti le linee guida del brand e i requisiti legali prima della pubblicazione.
• RAG (Retrieval-Augmented Generation): In contesti aziendali, l’AI deve fornire risposte basate su dati interni sicuri. La piattaforma funge da hub centrale per orchestrare i dati aziendali verso database vettoriali, permettendo agli agenti AI di rispondere alle query degli utenti basandosi esclusivamente sulla documentazione aziendale certificata, accedendo solo ad informazioni pertinenti e rispettando rigorosamente i permessi di accesso individuali.
• Accelerazione dello sviluppo: La generazione di pagine con la GenAI, il visual building e l’automazione dei compiti ripetitivi liberano risorse ingegneristiche preziose. Questo consente ai team tecnici di concentrarsi sull’architettura, sulle integrazioni complesse e sulla sicurezza.

Per comprendere a fondo come implementare queste architetture ibride nei propri processi aziendali, consigliamo di consultare la nostra panoramica su Drupal AI e la visione di SparkFabrik, dove analizziamo le strategie di integrazione più efficaci.

Nella deep-dive sui Guardrails in Drupal approfondiamo inoltre un sistema fondamentale per applicazioni enterprise, e nell’articolo dedicato a Drupal AI 1.3 esploriamo la maturità dell’integrazione dell’AI raggiunta con la l’ultima versione del modulo.

Il futuro vede i team tecnici concentrarsi sull’architettura dei dati e sulla sicurezza. Nella nostra esperienza in SparkFabrik, l’adozione dell’AI riduce i tempi di sviluppo di task ripetitivi del 30%, ma solo se il framework sottostante impone regole rigide che impediscono al codice generato di compromettere la stabilità del sistema in produzione.

Perché il “Pivot” è necessario ora?

Il riposizionamento strategico di Drupal è necessario oggi perché il mercato si è diviso in modo netto. Mentre la presenza online di base è ormai mercificata, la domanda di integrazioni profonde cresce. I CTO necessitano di piattaforme flessibili per risolvere il dilemma build vs buy senza cedere il controllo architetturale.

L’ottimizzazione dei budget IT impone scelte spietate, a maggior ragione oggi, in un mercato in cui il codice e la presenza online sono diventati commodities. Finanziare lo sviluppo personalizzato per progetti a basso impatto è uno spreco di risorse ingegneristiche, poiché strumenti automatizzati possono coprire quelle esigenze a una frazione del costo. Pensiamo, ad esempio, alla miriade di SaaS, soluzioni “no-code” ed AI builders per creare landing pages. In questi casi, una tecnologia come Drupal è evidentemente inefficiente.

Tuttavia, applicare la stessa logica di risparmio ai sistemi core genera un debito tecnico che si sconta con l’impossibilità di scalare. Le aziende enterprise non chiedono più vetrine digitali, ma ecosistemi transazionali. Le esigenze si sono spostate verso l’integrazione profonda.

Questo livello di complessità si manifesta in casi d’uso avanzati che sfuggono alle capacità dei CMS tradizionali. Business cases strutturati e complessi come portali clienti, intranet, piattaforme di e-learning e repository di dati richiedono fondamenta solide.

In questo scenario, i leader tecnologici affrontano costantemente il dilemma Build vs Buy. Acquistare un prodotto finito garantisce velocità iniziale, ma le scatole nere SaaS mostrano i loro limiti non appena i processi aziendali deviano dallo standard previsto dal vendor. Si presentano rigidità strutturali gravi, come schemi dati non modificabili, limiti API, dipendenza dalla roadmap di sviluppo e vendor lock-in.

Costruire tutto da zero, d’altra parte, comporta costi di manutenzione insostenibili. Un framework applicativo maturo offre la via di mezzo ottimale: fondamenta solide già scritte e testate, combinate con la libertà assoluta di personalizzare la logica di business.

Il tema della sovranità digitale va letto in quest’ottica ingegneristica prima ancora che normativa. Non è solo questione di residenza del dato, ma di controllo sull’architettura. Le aziende europee necessitano di piattaforme dove l’accesso al database, la logica di business e le integrazioni non siano vincolate da scatole nere.

Drupal si posiziona come framework open source che garantisce l’accesso completo allo stack, permettendo di modellare i dati esattamente come richiesto dal business. Offre la flessibilità del custom code e la robustezza di un framework enterprise, lasciando il mercato dei siti semplici ai tool automatizzati.

Quali sono i prossimi passi per i decisori IT?

Possedere la propria tecnologia in un’era di incertezza rappresenta il vantaggio competitivo definitivo per le aziende enterprise. La transizione verso soluzioni robuste richiede un audit approfondito dell’infrastruttura attuale e l’adozione di piattaforme open source governate da rigorose pratiche ingegneristiche, capaci di sostenere la crescita del business nel lungo periodo.

Ecco una checklist strategica:

1. Audit del debito tecnico: Analizzate le vostre proprietà digitali. Quali sono semplici siti vetrina e quali sono applicazioni critiche? Identificate dove avete bisogno di controllo sui dati e longevità del software. Quelli sono i candidati per il nuovo approccio Drupal enterprise.
2. Valutazione dell’indipendenza tecnologica: I vostri sistemi attuali vi permettono di estrarre e migrare i dati senza frizioni? Se la risposta è no, state accumulando rischio operativo. L’adozione di standard aperti e piattaforme open source è la mitigazione tecnica più efficace contro il vendor lock-in.
3. Roadmap Platform-First: Smettete di finanziare progetti a silos. Investite nella piattaforma sottostante. Una base cloud-native ha un costo iniziale di setup, ma riduce il costo marginale di ogni successiva applicazione e garantisce standard di sicurezza uniformi.
4. Selezione dei Partner: Le sfide moderne richiedono competenze che vanno oltre lo sviluppo CMS tradizionale. Serve un partner con expertise in architetture distribuite, sicurezza applicativa e pratiche DevOps. Cercate competenze comprovate in ambito SRE e gestione del ciclo di vita del software.

La linea di demarcazione nel mercato IT è ormai tracciata con chiarezza. Da una parte troviamo le aziende che continuano a disperdere budget in silos applicativi e piattaforme chiuse, accumulando rischi operativi. Dall’altra, i leader di settore che investono in ecosistemi aperti, scalabili e pronti per l’integrazione sicura dell’intelligenza artificiale.

Drupal Pivot e gli altri eventi strategici hanno confermato che la maturità tecnologica non si misura dalla quantità di feature, ma dalla capacità di governare la complessità. Drupal ha scelto di posizionarsi come lo strumento per chi costruisce asset digitali durevoli, offrendo il controllo totale sulla propria tecnologia.

Invitiamo i leader tecnologici a valutare l’infrastruttura attuale con occhio critico. È pronta per supportare processi business-critical per i prossimi dieci anni? O è tempo di “pivotare” verso soluzioni più robuste, in grado di sostenere il business per il prossimo decennio?

Se la vostra architettura non garantisce sovranità sui dati e agilità operativa, vi invitiamo a scoprire i nostri servizi di sviluppo e consulenza Drupal e contattare i nostri esperti per progettare insieme una piattaforma cloud-native a prova di futuro.

Drupal rappresenta oggi non solo la miglior soluzione CMS di livello enterprise, ma anche quella che integra l’intelligenza artificiale in modo più maturo. La release 1.3.0 del modulo Drupal AI, ricchissima di funzionalità, segna un passaggio importante da integrazione sperimentale a piattaforma pronta per la produzione. L’adozione degli LLM nei CMS aziendali è stata finora frenata da rischi tangibili legati alla privacy dei dati, alle allucinazioni dei modelli e alla mancanza di osservabilità sulle operazioni eseguite in background. Questa versione affronta tali criticità strutturali, introducendo funzionalità di governance avanzate, flussi di telemetria standardizzati e strumenti di orchestrazione che trasformano le sperimentazioni in architetture solide.

Il team di SparkFabrik ha svolto un ruolo attivo nello sviluppo del modulo principale, guidando la progettazione dei sistemi di sicurezza e di ricerca avanzata. L’approccio ingegneristico Cloud Native ha permesso di applicare i principi di sicurezza by-design e DevSecOps direttamente all’intelligenza artificiale, garantendo che ogni interazione sia tracciabile e sicura.

Per comprendere l’estensione di questo ecosistema, è utile consultare la nostra panoramica completa sulle funzionalità AI in Drupal. Come illustrato nel video di approfondimento di Marcus Johansson, Tech Lead della Drupal AI Initiative, l’aggiornamento fornisce fondamenta architetturali per operazioni complesse. Abbiamo dettagliato il percorso di queste implementazioni nel nostro articolo dedicato a come abbiamo plasmato il futuro di Drupal AI nel 2025, dimostrando come l’integrazione dei modelli linguistici richieda competenze trasversali tra sviluppo CMS e infrastrutture distribuite.

Perché i Guardrails AI trasformano Drupal in una piattaforma enterprise sicura?

I Guardrails AI trasformano Drupal in una piattaforma sicura fungendo da filtri bidirezionali che intercettano le richieste e validano le risposte dei Large Language Models. Questo sistema di governance blocca la fuga di dati sensibili e previene le allucinazioni, garantendo la conformità necessaria per le applicazioni enterprise in produzione.

L’implementazione di queste policy contribuisce ad aumentare la conformità sulle interazioni con gli LLM, in uscita ed in entrata. Per approfondire il design di questi componenti, è possibile analizzare le strategie architetturali per mitigare i rischi dei modelli linguistici nell’articolo di dettaglio sui Guardrails in DrupalAI.

Durante l’evento Drupal X Business, Luca Lusso ha presentato nel dettaglio il funzionamento di questi meccanismi di protezione. Nel suo talk ha evidenziato come l’implementazione di regole ferree sposti l’intelligenza artificiale da un paradigma sperimentale a uno strumento governabile. L’approccio Cloud Native adottato nella progettazione assicura che questi controlli operino in modo efficiente, mantenendo la latenza molto contenuta così da non impattare negativamente i processi editoriali.

Intercettazione e mascheramento dei dati sensibili

I Guardrails operano a un livello profondo dell’architettura, impedendo la fuga di dati sensibili prima che la richiesta HTTP lasci i server aziendali. Questo include il blocco di PII (Personally Identifiable Information), dati finanziari o proprietà intellettuale. Il sistema può bloccare interamente la richiesta o mascherare l’input utilizzando espressioni regolari o servizi di validazione esterni come AWS Bedrock.

Un esempio pratico illustra l’efficacia di questo approccio. Se un redattore inserisce in un prompt il nome in codice di un prodotto secretato, come il progetto interno “MDX 250”, il Guardrail configurato intercetta immediatamente il testo. O, molto più banalmente, se un utente invia nel prompt i propri dati personali o il codice della carta di credito, il sistema li blocca o li oscura prima dell’invio a LLM pubblici come quelli di OpenAI o Anthropic.

Questa validazione preventiva garantisce la sicurezza della supply chain del dato, assicurando che l’infrastruttura aziendale non diventi un veicolo per la dispersione di segreti industriali. L’applicazione di questi filtri avviene in tempo reale e fornisce un feedback immediato all’utente. Spiegando esattamente quale policy di sicurezza è stata violata, il sistema mantiene un alto livello di consapevolezza tra i team editoriali.

Architettura agnostica e validazione bidirezionale

Il sistema di Guardrails è progettato con una rigorosa architettura agnostica, il che significa che non è legato a un singolo vendor o a un modello linguistico specifico. Questa indipendenza permette alle organizzazioni di definire policy di sicurezza centralizzate. Tali regole rimangono valide anche se si decide di migrare da un provider cloud all’altro, abbattendo i costi di refactoring.

La protezione offerta dal modulo si articola su tre livelli di intervento distinti:

• Blocco preventivo della richiesta in uscita, che analizza il prompt dell’utente e il contesto fornito per identificare violazioni delle policy aziendali prima di qualsiasi comunicazione di rete.
• Riformattazione o blocco della risposta in ingresso, che analizza l’output generato dal modello linguistico per intercettare contenuti inappropriati, linguaggi offensivi o risposte che violano le direttive etiche.
• Prevenzione delle allucinazioni e mantenimento del tone of voice aziendale, garantendo che il modello non inventi fatti inesistenti o utilizzi uno stile di comunicazione estraneo alle linee guida del brand.

Questa validazione bidirezionale assicura che il CMS mantenga l’autorità finale sui contenuti. L’intelligenza artificiale viene trattata come un fornitore di servizi che deve essere costantemente supervisionato da logiche di business rigide.

Come il Reranking semantico migliora le architetture RAG su Drupal AI?

Il Reranking semantico migliora le architetture RAG su Drupal introducendo un secondo passaggio di valutazione basato sull’intelligenza artificiale. Dopo il filtraggio vettoriale iniziale, un modello specializzato riordina i documenti recuperati analizzandone la reale pertinenza contestuale, garantendo che i Large Language Models ricevano informazioni precise per generare le risposte.

Il nuovo operation type di Reranking rappresenta un’altra area di forte contributo da parte di SparkFabrik, essenziale per implementare architetture Retrieval-Augmented Generation efficaci. L’adozione di queste tecniche avanzate richiede un nuovo approccio architetturale orientato agli agenti AI, dove la precisione del recupero delle informazioni determina direttamente la qualità dell’output finale.

Le società di sviluppo si scontrano frequentemente con i limiti della ricerca vettoriale pura, che spesso recupera documenti simili ma non contestualmente rilevanti. Implementando il reranking, abbiamo osservato una riduzione del 70% nei “falsi positivi” durante le interrogazioni documentali complesse ed un ordinamento dei risultati più efficace. Questo filtro semantico profondo assicura che il modello linguistico riceva solo il contesto strettamente necessario, ottimizzando anche il consumo di token.

Superare i limiti della ricerca vettoriale standard

Un database vettoriale standard restituisce risultati basati esclusivamente sulla distanza matematica tra le coordinate dei testi nello spazio multidimensionale. Sebbene questo metodo sia veloce e utile per scremare grandi volumi di dati, non sempre comprende le sfumature linguistiche o l’intento reale dietro una query complessa. L’ordine dei documenti forniti come contesto a un LLM influisce significativamente sulla qualità della risposta finale. I modelli tendono infatti a dare maggiore peso alle informazioni presentate per prime, nonostante le context-windows sempre più ampie.

Il re-ranking opera come un secondo passaggio chiave. Dopo che il motore di ricerca vettoriale ha recuperato un set iniziale di documenti, ad esempio i primi cinquanta risultati, un modello specializzato analizza questo sottoinsieme. Il modello valuta la reale pertinenza semantica di ciascun documento rispetto alla domanda specifica, assegnando un nuovo punteggio di rilevanza.

Questo processo riordina i risultati, portando in cima i documenti che contengono effettivamente la risposta, anche se matematicamente non erano i più vicini alla query originale. Il risultato è un contesto ottimizzato che viene poi passato al modello linguistico generativo, riducendo drasticamente il tasso di errore.

Integrazione nativa tra Vector Database e LLM

Il flusso tecnico implementato nella versione 1.3 prevede una solida integrazione tra un motore di ricerca avanzato, come Typesense (di cui siamo maintainer del modulo Drupal) o un database relazionale con estensione vettoriale, e il provider AI scelto. Drupal orchestra questa comunicazione in modo trasparente. Prima interroga il database per ottenere i candidati, poi invia i risultati al servizio di reranking e infine passa i documenti riordinati al modello generativo.

Questa architettura a due stadi aumenta l’affidabilità dei sistemi conversazionali. Nei chatbot documentali interni, i dipendenti ottengono risposte precise basate sulle procedure aziendali corrette. Sulle piattaforme e-commerce, le ricerche semantiche restituiscono prodotti che corrispondono all’intento di acquisto dell’utente, migliorando sensibilmente i tassi di conversione.

Trattando il reranking come un’operazione agnostica, l’infrastruttura permette di utilizzare modelli specializzati (es. cross-encoder) addestrati appositamente per il task di riordino semantico. Questi modelli sono architetturalmente diversi e molto più precisi in questa fase rispetto all’uso di un LLM generativo. Gli LLM generativi più potenti e costosi possono così essere riservati solo per la generazione finale del testo. Questa separazione dei compiti ottimizza i costi operativi e diminuisce i tempi di latenza complessivi del sistema.

Osservabilità Cloud Native e gestione avanzata delle API

L’osservabilità Cloud Native nel modulo Drupal AI si concretizza attraverso l’integrazione dello standard OpenTelemetry. Questa architettura permette di tracciare ogni singola richiesta ai modelli linguistici, monitorando in tempo reale metriche cruciali come la latenza, il consumo di token e i costi operativi, trattando l’intelligenza artificiale come un microservizio misurabile.

L’implementazione dell’intelligenza artificiale in ambienti di produzione richiede metriche precise e un controllo rigoroso sulle risorse. Questa necessità si collega esplicitamente all’esperienza ingegneristica di SparkFabrik, dove l’AI non è vista come una scatola nera, ma come un componente distribuito. Per comprendere appieno questa filosofia architetturale, è utile esplorare i fondamenti e i vantaggi dell’approccio Cloud Native.

La versione 1.3 di Drupal AI introduce il supporto nativo a OpenTelemetry, permettendo di tracciare l’intero ciclo di vita di un agente autonomo. Questo livello di trasparenza è necessario per diagnosticare colli di bottiglia e ottimizzare le performance. Avere visibilità esatta sui costi per singola transazione AI permette ai CTO di giustificare gli investimenti tecnologici di fronte agli stakeholder aziendali con dati inoppugnabili.

Tracciamento distribuito con OpenTelemetry

L’esportazione standardizzata di metriche, span e trace consente ai team operativi di analizzare ogni singola richiesta AI con una granularità elevata. Quando un redattore richiede la generazione di un riassunto, il sistema registra esattamente quanto tempo il provider ha impiegato per rispondere. Vengono inoltre tracciati quanti token di contesto sono stati inviati e quanti token di completamento sono stati generati.

Questi dati permettono di calcolare i costi operativi in tempo reale, associando la spesa a specifiche funzionalità del sito o a determinati flussi editoriali. L’approccio basato su standard aperti garantisce la compatibilità con gli strumenti di mercato più diffusi, come Honeycomb, Grafana e Datadog. I team DevOps possono visualizzare le prestazioni dell’intelligenza artificiale sulle stesse dashboard utilizzate per monitorare il database o i cluster Kubernetes.

L’adozione di OpenTelemetry evita il lock-in sui tool di monitoraggio proprietari dei singoli vendor cloud. Indipendentemente dal fatto che l’infrastruttura utilizzi modelli ospitati su AWS, Google Cloud o soluzioni locali, il formato dei dati di osservabilità rimane coerente. Questo approccio unificato semplifica enormemente la gestione delle operazioni IT su larga scala.

Rate limiting, failover e metadata normalizzati

La gestione avanzata delle API nella versione 1.3 trasforma il modo in cui Drupal comunica con i provider esterni. Il sistema introduce soglie di rate limit e timeout per le richieste HTTP configurabili direttamente dall’interfaccia utente. Questa novità elimina la necessità di scrivere codice custom per gestire le limitazioni imposte dai servizi cloud.

Questa evoluzione porta con sé vantaggi architetturali rilevanti per la stabilità della piattaforma:

• Implementazione di logiche di failover automatico, che deviano il traffico verso un modello secondario o un provider alternativo quando il servizio principale raggiunge il limite di richieste consentite.
• Gestione sicura delle chiamate asincrone, permettendo agli agenti AI di eseguire compiti complessi in background senza bloccare i processi principali del server web o causare timeout per gli utenti.
• Normalizzazione dei metadati, che fornisce informazioni coerenti sui costi dei modelli e sulle capacità tecniche indipendentemente dal provider scelto, facilitando il passaggio da un fornitore all’altro.

Questi meccanismi di protezione assicurano che un picco di richieste alle funzionalità intelligenti del sito non comprometta la disponibilità generale del CMS. La piattaforma degrada in modo controllato, mantenendo operativi i servizi critici e garantendo una continuità operativa di livello enterprise.

L’ecosistema di automazione: dai workflow editoriali alla moderazione AI

L’ecosistema di automazione di Drupal AI ottimizza i workflow editoriali integrando capacità decisionali direttamente nell’interfaccia di gestione dei contenuti. Attraverso strumenti come le Field Widget Actions e la moderazione automatizzata, il sistema riduce il carico cognitivo dei team, trasformando compiti manuali complessi in processi fluidi e immediati.

Queste funzionalità di automazione rendono l’offerta di un’azienda di sviluppo software AI immediatamente tangibile per il business. L’impatto si traduce in un ritorno sull’investimento basato sul risparmio di tempo e sulla riduzione degli errori umani (un risparmio stimato di oltre 20 ore settimanali di revisione e moderazione manuale per i team editoriali di medie dimensioni). L’obiettivo è semplificare la gestione dei contenuti integrando l’AI in modo trasparente nelle operazioni quotidiane.

I miglioramenti all’interfaccia utente includono un nuovo editor Markdown per la stesura dei prompt di sistema. Questa scelta tecnica è particolarmente utile poiché i modelli linguistici interpretano il formato Markdown in modo molto più efficiente rispetto all’HTML o al testo semplice, ed è anche possibile dare una migliore struttura ai prompt.

Non da ultimo, il Context Control Center permette di definire una sola volta tone of voice, audience, policy e dettagli aziendali specifici, in un unico ambiente ed una sola volta. Le varie parti del contesto possono quindi essere usati dai vari team redazionali, a supporto delle loro attività.

Il CCC supporta anche l’autocompletamento di variabili e token, permettendo quindi agli amministratori di “iniettare” dinamicamente i dati dell’utente corrente o del nodo all’interno delle istruzioni inviate al modello. Questo aumenta la precisione complessiva del contesto, migliorando di conseguenza anche la qualità dell’output dell’LLM.

E, ricollegandoci all’osservabilità, anche il CCC ha funzionalità di usage tracking, logging, agent debugging ed un’ampia gamma di test automatizzati che coprono tutte le sue features, aspetti fondamentali per gli engineers.

Moderazione dei contenuti e Object Detection

La moderazione dei contenuti basata sull’intelligenza artificiale introduce un livello di controllo automatizzato sui testi inseriti dagli utenti o dai redattori. Il sistema analizza il contenuto in tempo reale e può alterare autonomamente lo stato di moderazione del nodo. Ad esempio, se viene rilevato un linguaggio inappropriato, lo stato passa automaticamente da pubblicato a segnalato, richiedendo l’intervento di un supervisore umano.

Parallelamente, l’integrazione dell’Object Detection espande le capacità di analisi ai contenuti multimediali. Utilizzando modelli di computer vision o algoritmi di deep learning, spesso eseguiti localmente o tramite piattaforme come Hugging Face, il sistema riconosce oggetti specifici all’interno delle immagini caricate. Questa tecnologia restituisce le coordinate esatte degli elementi identificati, permettendo validazioni complesse.

Un caso d’uso tipico riguarda il blocco degli upload che non rispettano le linee guida aziendali. Il sistema può impedire il caricamento di un’immagine se non rileva la presenza di un dispositivo di sicurezza specifico in una foto di cantiere. Oppure può rifiutare immagini che contengono loghi della concorrenza, automatizzando un processo di controllo qualità che richiederebbe ore di lavoro manuale.

Field Widget Actions per dati strutturati

Le Field Widget Actions rappresentano l’integrazione più profonda dell’automazione all’interno dell’esperienza editoriale, portando le capacità generative direttamente sui singoli campi di Drupal. Invece di utilizzare un chatbot generico, il redattore dispone di pulsanti contestuali che eseguono operazioni specifiche sui dati in fase di inserimento.

I casi d’uso tecnici introdotti (o migliorati) nella versione 1.3 coprono un ampio spettro di necessità operative:

• Estrazione di indirizzi fisici da testi non strutturati, normalizzando le informazioni geografiche tramite integrazioni con servizi come Google Places per popolare automaticamente i campi mappa.
• Generazione di meta tag SEO ottimizzati, creando titoli accattivanti e descrizioni pertinenti basandosi sull’analisi del contenuto testuale del nodo.
• Conversione di dati testuali grezzi in formati JSON rigorosamente strutturati, un passaggio essenziale per esporre informazioni coerenti tramite API in architetture headless.
• Creazione automatica di sezioni FAQ a partire da documenti lunghi e operazioni di text-to-speech che trasformano gli articoli testuali in file audio associati ai campi media.

Queste azioni trasformano il CMS da un semplice contenitore di informazioni a un assistente attivo. Costringendo i modelli linguistici a rispettare schemi di dati predefiniti, il sistema garantisce che l’output generato sia immediatamente utilizzabile dalle logiche di visualizzazione del sito. Questo approccio riduce drasticamente la necessità di interventi manuali di pulizia e formattazione. Non da ultimo, tali funzioni sono facilmente utilizzabili da chiunque, senza particolari competenze tecniche.

Conclusione

Drupal AI 1.3 rappresenta un aggiornamento importante che mette in evidenza la maturità dell’ecosistema. Fornendo strumenti avanzati come i Guardrails per la sicurezza, il Reranking per la precisione semantica e l’integrazione con OpenTelemetry per l’osservabilità, il modulo offre l’infrastruttura necessaria per operare in ambienti enterprise complessi e regolamentati.

L’integrazione sicura dei modelli linguistici all’interno dei processi aziendali richiede competenze trasversali che vanno ben oltre la semplice installazione di un plugin. È necessaria una profonda comprensione dello sviluppo CMS, delle architetture distribuite Cloud Native e delle rigorose pratiche di data governance. Solo un approccio integrato, guidato da metodo ed esperienza, garantisce che l’innovazione tecnologica non comprometta la sicurezza o le prestazioni del sistema.

Per orchestrare queste tecnologie in modo scalabile e sicuro, il valore aggiunto risiede nell’affidarsi a partner tecnologici con una comprovata esperienza nelle dinamiche open source e nello sviluppo di software basato sull’intelligenza artificiale personalizzato. L’evoluzione di Drupal dimostra che il futuro della gestione dei contenuti appartiene alle piattaforme capaci di unire la flessibilità editoriale con il rigore ingegneristico. Contatta i nostri esperti e parlaci delle tue sfide per scoprire come implementare queste soluzioni nella tua architettura.

L’intelligenza artificiale ha trasformato la scrittura del codice in una commodity: questa è la verità ineludibile per i CTO. Ed è il punto centrale del keynote di Dries Buytaert al DrupalCon Chicago 2026, durante l’evento che ha celebrato i 25 anni del progetto open source Drupal. Il codice sorgente sta diventando letteralmente una risorsa usa e getta. Il vero valore dello sviluppo software si sposta rapidamente dalla mera scrittura di codice, alla definizione rigorosa delle specifiche e alla progettazione dell’architettura di sistema. Il risultato? Un passaggio massiccio dalla programmazione manuale all’orchestrazione di agenti autonomi.

Le osservazioni emerse riflettono perfettamente un principio cardine del Playbook SparkFabrik. Il codice effimero libera risorse, ma l’intelligenza artificiale non sostituisce l’ingegneria del software, la espone in modo spietato. Se un’azienda ha una visione chiara e requisiti solidi, l’AI moltiplica l’efficienza operativa; in assenza di una direzione strategica, si limita ad amplificare gli errori su larga scala.

In questo scenario, i nostri servizi di sviluppo e consulenza Drupal si evolvono in modo radicale, posizionandoci come partner strategici per la governance dei processi digitali e per l’implementazione di soluzioni AI di livello enterprise.

Esploriamo nel dettaglio le evoluzioni principali emerse dall’evento:

• L’architettura di DrupalCMS 2.1 e i nuovi site templates che abbassano le barriere all’ingresso e accelerano il time-to-market.
• Il Context Control Centre, che permette di configurare una sola volta tono, audience e policy aziendali per ogni interazione AI.
• L’evoluzione del visual building con Canvas e la creazione di pagine production-ready tramite AI.
• L’aggiornamento del modulo Drupal AI alla versione 1.3, con novità importanti tra cui il sistema di guardrails contribuito da SparkFabrik.
• L’approccio agentic-first ed il ruolo ridefinito del codice nell’era dell’AI.

Quali sono le novità introdotte da DrupalCMS 2.1 per l’ecosistema enterprise?

Le principali novità introdotte da DrupalCMS 2.1 per l’ecosistema enterprise comprendono un’architettura avanzata basata sul core 11.3, capace di ridurre del 50% le query al database per le pagine non in cache. Inoltre, si aggiorna il marketplace nativo con 11 site templates settoriali, progettati specificamente per abbattere drasticamente i tempi di rilascio delle piattaforme aziendali complesse.

L’infrastruttura tecnologica presentata a Chicago ridefinisce le aspettative di performance per le grandi organizzazioni. Il motore di DrupalCMS 2.1 non si limita ad aggiornare le dipendenze di sistema, ma riscrive le logiche profonde di accesso ai dati. Questa ottimizzazione strutturale si traduce in un risparmio immediato sulle risorse computazionali in cloud. Le metriche dimostrano che le infrastrutture aziendali possono ora gestire picchi di traffico intensi con una frazione del carico sui server tradizionali, ottimizzando i costi operativi secondo i principi FinOps.

Parallelamente alla potenza bruta, il focus ingegneristico si sposta sulla velocità di implementazione operativa. Il nuovo marketplace introduce 11 site templates specifici per settori verticali, dalla sanità all’istruzione fino ai servizi finanziari e alla pubblica amministrazione, disponibili direttamente nel marketplace integrato.

Questa architettura modulare trasforma radicalmente la concezione classica dello sviluppo Drupal. Vengono eliminati i mesi di lavoro tipicamente necessari per il setup iniziale delle logiche di business standard e della modellazione dei contenuti.

Per i decision maker IT, adottare questa piattaforma rappresenta l’ingresso in una nuova era del content management per il business. I vantaggi tecnici rispetto a architetture legacy e soluzioni proprietarie sono tangibili e misurabili:

• Riduzione drastica del time-to-market grazie a configurazioni pre-assemblate per specifiche industry.
• Ottimizzazione del carico infrastrutturale con un calo netto delle query database e un caching più aggressivo.
• Integrazione nativa con servizi e soluzioni di GenAI per snellire flussi editoriali complessi.
• Standardizzazione delle best practice di sicurezza ereditate direttamente dall’evoluzione del core 11.3.
• L’adozione di una soluzione completamente open-source riduce il Total Cost of Ownership ed azzera il vendor lock-in.

L’impatto di queste innovazioni sui bilanci IT è diretto e quantificabile. Quando i team di ingegneria non devono più spendere decine o centinaia di ore per configurare ruoli, permessi e flussi di pubblicazione di base, il budget può essere interamente reindirizzato verso l’integrazione di sistemi core e la personalizzazione avanzata.

Il ruolo del Context Control Centre nella governance dei dati

Il Context Control Centre (CCC) è il nuovo sottosistema nativo progettato per risolvere il problema delle allucinazioni nei modelli linguistici applicati all’enterprise. Senza questo strumento, ogni volta che si utilizza l’AI si riparte da zero, costringendo i team a rispiegare il brand, correggere l’output e rifare il lavoro. Il CCC elimina questa inefficienza permettendo di definire una sola volta tono di voce, audience, policy e design.

Attraverso il CCC, i team IT codificano il contesto aziendale tramite linee guida, brand voice, tone of voice, design system, dati analitici e requisiti normativi (anche in diverse lingue). E lo fanno una volta solo, direttamente nel CCC.

Quando l’intelligenza artificiale interroga il CMS per creare nuovi contenuti, il CCC garantisce che l’output finale sia perfettamente allineato agli standard di compliance aziendale. In questo modo, viene bloccata alla fonte qualsiasi deviazione dal perimetro comunicativo autorizzato.

Ma il contesto aziendale non è statico. Prodotti evolvono, metriche fluttuano, informazioni diventano obsolete. Il team di sviluppo del CCC sta esplorando il concetto di contesto dinamico: la possibilità di aggiornare nel tempo il contesto e di collegare fonti dati esterne (come Google Analytics) direttamente al motore di orchestrazione.

L’obiettivo è un sistema capace di monitorarsi autonomamente. Immagina ad esempio un calo improvviso di metriche chiave, oppure pagine con dettagli obsoleti che non riflettono più le caratteristiche attuali di un prodotto o servizio. Con un contesto dinamico, il sistema sarebbe in grado di rilevare queste anomalie.

La direzione è chiara: passare da un contesto definito una volta sola a un contesto che evolve con l’azienda stessa. Un CMS che non si limita a produrre contenuti allineati al brand, ma che segnala proattivamente quando quei contenuti richiedono un aggiornamento e propone correzioni contestualizzate. Certo, è ancora una fase embrionale, ma rappresenta la frontiera naturale dell’orchestrazione AI applicata al content management enterprise.

Canvas e Display Builder: come cambia la creazione visiva nello sviluppo Drupal?

La creazione visiva nello sviluppo Drupal cambia radicalmente attraverso l’uso di agenti AI capaci di trasformare documenti testuali in pagine production-ready. Strumenti come Canvas (lo strumento di punta promosso dalla AI Initiative) permettono una prototipazione rapida guidata dall’intelligenza artificiale, mentre soluzioni più mature come Display Builder assicurano l’applicazione rigorosa di design system complessi su larga scala.

L’ultima dimostrazione pratica delle capacità di Canvas, nella sessione plenaria di Chicago, mostra un’evoluzione costante dello strumento, che unisce capacità di visual building e generazione AI. Un documento di testo grezzo, contenente solo specifiche di prodotto e copy non formattato, è stato convertito in una pagina web completa in una manciata di minuti.

Questo livello di automazione posiziona saldamente l’ecosistema Drupal al vertice degli strumenti potenziati dall’AI per accelerare il delivery di interfacce complesse.

A differenza dei prototipi usa e getta creati da tool esterni, Canvas opera nativamente all’interno del CMS. I modelli linguistici interpretano l’intento del creatore e mappano i contenuti sui componenti visivi disponibili nel sistema, mantenendo intatta la struttura dei permessi, le logiche di traduzione, il cross-linking e i metadati SEO. Il risultato non è un mockup da ricostruire, ma una pagina production-ready inserita nel flusso editoriale aziendale.

Il nuovo flusso di lavoro assistito dall’AI trasforma le operazioni tradizionali di frontend:

1. Caricamento delle specifiche testuali o dei brief di prodotto direttamente nel motore di interpretazione del CMS.
2. Analisi semantica da parte dell’AI per identificare la struttura logica, inclusi titoli, call to action e dati strutturati.
3. Generazione automatica del layout visivo applicando i componenti predefiniti e le regole tipografiche di Canvas.
4. Intervento umano per la validazione finale dell’accessibilità, il raffinamento estetico e l’approvazione formale per la pubblicazione.

Per i direttori IT e i responsabili di prodotto, comprendere l’integrazione di Canvas e design system nativi diventa fondamentale per valutare il trade-off tra velocità di esecuzione e standardizzazione visiva globale. Mentre Canvas eccelle nel generare rapidamente nuove viste, le architetture aziendali di grandi dimensioni richiedono spesso un livello di controllo architetturale superiore sui token di design.

La solida alternativa: Display Builder e l’integrazione dei design system

In contrapposizione all’approccio generativo e focalizzato sulla prototipazione, l’ecosistema open source offre soluzioni progettate specificamente per la governance visiva su scala globale. Nel corso del nostro evento Drupal X Business, Michael Fanini ha presentato Display Builder, un visual builder più maturo sviluppato per rispondere alle esigenze più stringenti delle grandi organizzazioni omnicanale.

A differenza degli strumenti focalizzati sulla velocità istantanea, Display Builder offre un supporto profondo e nativo per i design system aziendali complessi (ed integrandosi perfettamente con l’ecosistema di moduli e temi UI Suite). Questa caratteristica garantisce che ogni singolo componente inserito nella pagina rispetti millimetricamente i vincoli di brand, un requisito non negoziabile quando si parla di soluzioni enterprise ed istituzionali, come per istituti bancari o multinazionali farmaceutiche.

Per approfondire le potenzialità di questa architettura visiva enterprise, vi invitiamo a visionare il talk completo sul nostro canale YouTube.

Come il modulo Drupal AI 1.3 garantisce la sicurezza dei dati aziendali?

Il modulo Drupal AI 1.3 garantisce la sicurezza dei dati aziendali attraverso un sistema nativo di Guardrails che intercetta e filtra le comunicazioni con i Large Language Models. Questa architettura applica regole di validazione pre e post-elaborazione, bloccando l’esposizione di informazioni sensibili e assicurando la totale conformità normativa prima della pubblicazione.

La maturità raggiunta dall’ecosistema open source trasforma il CMS Drupal in una vera e propria piattaforma di livello enterprise per l’orchestrazione sicura dei modelli linguistici. Con il rilascio della versione 1.3 del modulo Drupal AI, la community ha stabilito un nuovo standard de facto per le organizzazioni che cercano architetture affidabili nel campo dell’ ai software development.

Questa release affronta frontalmente i problemi principali di sicurezza che affliggono i CTO in ambito AI: il rischio concreto di fuga dei dati e la conseguente perdita di controllo sulle informazioni proprietarie, le allucinazioni dei modelli probabilistici, i potenziali danni reputazionali di output ai non in linea con il brand.

Il cuore di questa sicurezza infrastrutturale è rappresentato dal sistema di Guardrails, una componente architetturale fondamentale sviluppata e contribuita direttamente dal team di SparkFabrik (scopri tutte le nostre contribuzioni a Drupal AI).

Come dettagliato nell’articolo Guardrails AI in Drupal, abbiamo progettato questo layer di protezione per agire come un firewall semantico bidirezionale e in tempo reale. Prima che una richiesta venga inviata a provider esterni, il sistema verifica proattivamente l’assenza di dati personali identificabili (PII), credenziali di accesso o segreti industriali.

Allo stesso modo, la fase di post-elaborazione analizza l’output generato per garantire la compliance con le normative vigenti, le policy interne e le restrizioni di copyright. Questo approccio architetturale dimostra come le soluzioni moderne debbano integrare reti di sicurezza robuste, osservabili tramite standard come OpenTelemetry, attorno ai modelli generativi.

La sicurezza dei dati non è più un add-on opzionale da valutare a fine progetto, ma il fondamento imprescindibile su cui costruire qualsiasi iniziativa di automazione aziendale. Una volta blindato il perimetro di sicurezza dei dati, le aziende possono finalmente concentrarsi sul vero moltiplicatore di valore: l’orchestrazione strategica degli agenti autonomi.

Perché l’approccio agentic-first ridefinisce il ruolo delle AI software development companies?

L’approccio agentic-first ridefinisce il ruolo delle aziende di sviluppo trasformandole da esecutrici di codice a orchestratrici di sistemi intelligenti. L’intelligenza artificiale non sostituisce gli ingegneri, ma ne amplifica le capacità architetturali, permettendo a un singolo professionista esperto di generare l’output qualitativo e quantitativo di un intero team.

L’implementazione pratica di questo modello agentic-first implica l’integrazione dell’Intelligenza Artificiale come componente architetturale nativa. Il baricentro operativo viene spostato dalla programmazione manuale alla orchestrazione di modelli ed agenti AI e alla configurazione di flussi di lavoro automatizzati. E questo richiede conoscenze tecniche precise maturate dall’esperienza in progetti reali, pratiche di Spec Driven Development e una governance rigorosa dei dati per garantire scalabilità e sicurezza.

Invece di scrivere singole funzioni, i team IT definiscono le regole di ingaggio per molteplici agenti AI che collaborano per risolvere task complessi, dal refactoring del codice alla generazione di test automatizzati. Questo significa poter esplorare scenari applicativi concreti basati sull’agentic AI che riducono i colli di bottiglia nei rilasci software, garantendo una scalabilità operativa prima inimmaginabile.

La visione di SparkFabrik abbraccia questa trasformazione strutturale. Trattare l’Intelligenza Artificiale come una semplice API esterna limita enormemente il potenziale di una piattaforma. Al contrario, progettare sistemi dove gli agenti autonomi operano all’interno di un perimetro sicuro permette di automatizzare interi processi di business.

Nel nostro framework operativo quotidiano, codifichiamo questa trasformazione con un principio inequivocabile: l’intelligenza artificiale non ti sostituisce, ti espone.

Se sai cosa vuoi, moltiplica; se non lo sai, amplifica gli errori.

La dimostrazione più lampante e documentata di questa produttività aumentata è arrivata dal lavoro dello sviluppatore Jurgen Haas sul modulo ECA (Event-Condition-Action). Assistito da strumenti di intelligenza artificiale avanzati, un singolo sviluppatore senior ha scritto, validato e documentato 90.000 righe di codice in sole sei settimane.

Questo volume di lavoro certifica che l’output individuale è destinato a scalare in modo vertiginoso, ma solo se sai cosa vuoi e se parti da una base solida di competenze che ti permettono di orchestrare il lavoro, tenendo saldamente le redini.

Per implementare con successo l’approccio agentic-first, l’architettura si fonda su tre fasi cruciali:

• La progettazione e l’implementazione di sistemi di orchestrazione centralizzati per gestire in modo robusto ma flessibile skills, system prompts, agent profiles, protocolli MCP e tools personalizzati.
• L’integrazione di guardrails e sistemi di sicurezza avanzati, applicando rigorosamente le pratiche DevSecOps per proteggere i flussi di dati aziendali.
• L’applicazione di policy di governance automatizzate che validino l’output degli agenti AI attraverso test automatizzati prima della pubblicazione.

Le aziende di sviluppo software che si limitano a vendere ore di programmazione manuale sono destinate a una rapida obsolescenza. Il mercato enterprise premia esclusivamente chi sa governare la complessità sistemica e orchestrare ecosistemi di agenti intelligenti.

Spec Driven Development e l’armonia tra competenze e relazioni

In un ecosistema guidato dall’Intelligenza Artificiale, la qualità dell’output generato dipende interamente dalla precisione delle specifiche iniziali. La strategia operativa di SparkFabrik si fonda saldamente sullo Spec Driven Development. I modelli linguistici operano esclusivamente all’interno dei confini delineati dai prompt di sistema e dalle regole architetturali. Un requisito ambiguo, che in passato avrebbe richiesto un chiarimento tra sviluppatori, oggi si traduce in un’allucinazione su larga scala o in un disservizio applicativo.

Di conseguenza, il ruolo del CTO e del VP Engineering si concentra sempre di più sulla validazione dell’architettura dell’informazione e sulla sicurezza dei dati. Il valore del management tecnico si sposta dalla revisione del codice sorgente alla definizione di contratti API inattaccabili e alla verifica delle policy di accesso. Il successo di un progetto di sviluppo drupal enterprise si misura oggi dalla robustezza delle sue specifiche, che fungono da vero e proprio codice sorgente per gli agenti AI.

Il mercato sta chiaramente premiando le realtà capaci di colmare questo gap, trasformando le agenzie da semplici fornitori di forza lavoro a consulenti strategici. Fondamentale per la transizione è però comprendere che la commoditizzazione del codice non è qualcosa da temere, ma un cambiamento profondo da gestire con strategia e governance chiare.

L’AI automatizza l’esecuzione, ma la strategia richiede empatia e profonda comprensione del business del cliente da una parte, formazione e gestione del cambiamento all’interno. Come dichiariamo apertamente nel nostro Playbook aziendale, la tecnologia cambia a ritmi vertiginosi, ma i nostri principi fondanti restano saldi.

“What won’t change is why this company exists. Our vision has always been harmony between skills and human relations.”

Il futuro dell’IT appartiene a chi saprà bilanciare la potenza computazionale degli agenti autonomi con l’insostituibile capacità umana di costruire relazioni di fiducia durature.

DrupalCon Chicago 2026: quali sono gli impatti e cosa portare a casa?

Cosa dobbiamo portare a casa dal DrupalCon Chicago 2026? Il messaggio per i decision maker è chiaro: la modernizzazione dei sistemi enterprise non passa più per la riscrittura manuale e infinita di codice, ma dall’approccio agentico.

Lo sviluppo Drupal contemporaneo rappresenta la vera avanguardia nell’orchestrazione di agenti autonomi all’interno di un framework intrinsecamente sicuro, scalabile e governato da regole chiare. Dalle performance ottimizzate del core 11.3 fino alla gestione rigorosa del contesto semantico tramite il Context Control Centre, la piattaforma open source si conferma la scelta d’elezione per le grandi organizzazioni che rifiutano il vendor lock-in dei modelli proprietari.

SparkFabrik non si limita a osservare le tendenze del mercato o a utilizzare passivamente questi nuovi strumenti generativi. Come dimostrato dal rilascio del sistema di Guardrails e dalle altre contribuzioni, ci impegniamo attivamente a forgiare le tecnologie che definiscono i nuovi standard di sicurezza, governance e sviluppo a livello globale. Ci posizioniamo come il partner strategico ideale per guidare le aziende attraverso le complessità insidiose della modernizzazione applicativa e dell’adozione sicura dei modelli di intelligenza artificiale.

Esplora le nostre soluzioni ai su misura e parla con i nostri esperti per una consulenza architetturale su misura, progettata per risolvere le sfide specifiche della vostra organizzazione.

L’integrazione dei Large Language Models (LLM) in ambienti di produzione introduce sfide architetturali inedite per i team di ingegneria del software. I modelli di intelligenza artificiale generativa sono per natura sistemi non deterministici, il che significa che lo stesso input può produrre output differenti nel tempo.

Questa variabilità espone le applicazioni enterprise a rischi critici, tra cui allucinazioni, divulgazione involontaria di dati sensibili (PII) e generazione di contenuti in aperto contrasto con le policy aziendali.

▶ Guarda questo passaggio nel video

Per mitigare questi rischi, non è sufficiente affidarsi a un prompt engineering accurato. È necessario implementare un livello di controllo strutturale che agisca da intermediario tra l’utente, il content management system (CMS) e il modello linguistico. Durante il talk “Drupal X Business: Next-Gen Digital Experiences”, Luca Lusso, sviluppatore presso SparkFabrik, ha illustrato come l’ecosistema Drupal stia affrontando questa sfida. L’obiettivo è trasformare l’AI da un rischio potenziale a un asset governabile e sicuro.

Con questo articolo esploriamo l’implementazione pratica di queste barriere di sicurezza all’interno del CMS, dalla prospettiva unica di contributors diretti al sistema di guardrails in Drupal. Analizzeremo come configurare le policy di validazione, come orchestrare i flussi di dati tramite agenti autonomi e quali strategie architetturali adottare per proteggere il brand. Per una visione più ampia su come stiamo guidando questa trasformazione, ti invitiamo a leggere come abbiamo plasmato il futuro di Drupal AI nel 2025 e la nostra panoramica completa sulle novità di Drupal AI e la visione di SparkFabrik.

L’adozione di un approccio metodologico rigoroso è l’unico modo per portare l’intelligenza artificiale fuori dalle fasi di sperimentazione e integrarla nei processi mission-critical. I team di Platform Engineering e gli sviluppatori devono collaborare per costruire pipeline dove la sicurezza sia garantita dal design stesso dell’infrastruttura.

Cosa sono i Guardrails AI e perché proteggono il business?

I guardrails AI sono un’infrastruttura di sicurezza architetturale progettata per intercettare, validare e filtrare in tempo reale le comunicazioni tra gli utenti e i Large Language Models (LLM). Operano secondo un approccio security-by-design per garantire che gli output generati rispettino rigorosamente le policy aziendali e le normative sulla privacy.

Questi strumenti non si limitano a essere semplici filtri basati su parole chiave. Rappresentano un vero e proprio strato middleware intelligente che analizza semanticamente il contesto delle conversazioni. Quando un utente invia una richiesta, il sistema la valuta prima che raggiunga il provider esterno, bloccando tentativi di manipolazione o richieste fuori contesto.

▶ Guarda questo passaggio nel video

La protezione del brand è il principale motore di business per l’adozione di queste tecnologie. Un modello linguistico privo di vincoli espone l’azienda a danni reputazionali enormi, potendo generare risposte non in linea con il tone of voice aziendale, o peggio, contenuti offensivi o discriminatori. Inoltre, l’invio accidentale di dati personali a provider di terze parti costituisce una grave violazione di normative come il GDPR.

Implementare un sistema di validazione robusto si traduce in un immediato vantaggio competitivo. Le aziende che riescono a governare l’imprevedibilità degli LLM possono scalare l’utilizzo dell’intelligenza artificiale su tutti i processi aziendali, dal customer care interno alla generazione automatizzata di contenuti. Questo approccio trasforma un potenziale rischio legale e di immagine in uno strumento di automazione affidabile e certificabile.

Anatomia di un sistema di controllo AI

Un’architettura di validazione moderna si compone tipicamente di due elementi logici fondamentali: i Checker e i Corrector. I Checker sono algoritmi o modelli specializzati che analizzano il payload in transito, verificando la presenza di anomalie, pattern malevoli o violazioni delle policy configurate. Il loro compito è unicamente quello di emettere un verdetto sulla conformità del dato.

I Corrector entrano in gioco successivamente, applicando le azioni di mitigazione necessarie. A seconda della gravità della violazione, possono mascherare parti del testo, riscrivere la risposta in un formato sicuro o bloccare interamente la transazione restituendo un messaggio di errore predefinito. Questa separazione delle responsabilità facilita la manutenzione delle regole.

Nelle architetture Cloud Native gestite dai team di Platform Engineering, questi componenti vengono spesso distribuiti come microservizi indipendenti o sidecar container all’interno di un cluster Kubernetes. Questo isolamento garantisce che le operazioni di validazione, che possono essere computazionalmente intensive, non impattino sulle performance dell’applicazione principale e possano scalare orizzontalmente in base al carico di richieste.

Come funzionano i Guardrails AI: input, output e agenti?

Il funzionamento dei guardrails AI si basa su un controllo bidirezionale continuo. In fase di input, applicano il prompt filtering per bloccare injection malevole o argomenti vietati. In fase di output, eseguono il response filtering per censurare allucinazioni, linguaggio inappropriato e impedire l’esposizione di dati sensibili.

La sicurezza di un’applicazione basata su LLM richiede che nessuna delle due direzioni venga trascurata. Se ci si limita a filtrare l’input, il modello potrebbe comunque produrre allucinazioni basate su dati di addestramento pregressi. Se si filtra solo l’output, si espone l’infrastruttura a costi computazionali inutili per processare prompt malevoli che andavano scartati a monte.

Per comprendere meglio le dinamiche di questo controllo, è utile analizzare i tre ambiti principali di applicazione:

• Filtro in Input (Prompt Filtering): Analizza le intenzioni dell’utente per prevenire attacchi di prompt injection, dove l’utente cerca di sovrascrivere le istruzioni di sistema del modello. Serve anche a mantenere la conversazione confinata agli argomenti pertinenti al business aziendale.
• Filtro in Output (Response Filtering): Valuta la risposta generata dal modello prima di mostrarla all’utente. Rileva e blocca linguaggi tossici, risposte non coerenti con il contesto fornito o informazioni che violano le direttive di compliance aziendale.
• Gestione dei Dati Sensibili (PII Redaction): Identifica informazioni personalmente identificabili, come indirizzi email, numeri di telefono o codici fiscali, all’interno del prompt dell’utente e li sostituisce con placeholder sicuri prima dell’invio al modello.

La gestione delle informazioni sensibili è forse l’aspetto più critico dal punto di vista normativo. Durante l’elaborazione, un sistema di redazione automatica intercetta stringhe come “test@example.com” e le converte in token anonimi come “[EMAIL]”. In questo modo, il modello elabora la richiesta senza mai “vedere” il dato reale, garantendo la totale conformità ai requisiti di data privacy.

▶ Guarda questo passaggio nel video

Queste policy di sicurezza non si limitano alle interfacce di chat esposte agli utenti umani. Assumono un’importanza ancora maggiore quando si gestiscono workflow automatizzati. Se desideri approfondire come orchestrare queste architetture complesse, puoi leggere la nostra guida su come sviluppare applicazioni cloud native AI-powered, dalla code review ai sistemi multi-agente.

Nei sistemi moderni, gli agenti autonomi comunicano costantemente tra loro e con API di terze parti per eseguire task complessi. In questi scenari, i sistemi di validazione agiscono come veri e propri firewall semantici tra i vari nodi del sistema. Assicurano che un agente con accesso al database non trasmetta inavvertitamente l’intero schema a un modello esterno durante una richiesta di generazione di query.

Implementare i Guardrails in Drupal: configurazione e workflow

Per implementare i guardrails in Drupal, si utilizza il modulo Drupal AI che permette di configurare policy di validazione tramite interfaccia grafica, orchestrare workflow complessi con Flowdrop AI e automatizzare operazioni tramite Runner API. Questo approccio centralizzato garantisce un controllo rigoroso sugli agenti autonomi e sui flussi di dati.

Il vantaggio principale dell’ecosistema Drupal è la possibilità di gestire logiche complesse di validazione direttamente dal back office, senza dover scrivere codice custom per ogni nuova regola. Il modulo base fornisce l’infrastruttura necessaria, mentre moduli aggiuntivi espandono le tipologie di controlli disponibili, permettendo agli amministratori di sistema di reagire rapidamente a nuove minacce o requisiti di business.

▶ Guarda questo passaggio nel video

La configurazione di una policy di sicurezza segue un processo logico ben definito, progettato per integrarsi con i flussi di lavoro esistenti dei site builder e degli sviluppatori. Ecco i passaggi fondamentali per attivare un controllo operativo:

1. Creazione della singola policy: Si accede alla sezione dedicata nel back office e si seleziona il plugin di validazione desiderato (ad esempio, un controllo basato su servizi cloud esterni o un filtro locale).
2. Definizione delle regole di blocco: Si istruisce il sistema sui parametri specifici, come ad esempio la configurazione del plugin “Restrict to Topic” per impedire al modello di generare risposte riguardanti un competitor diretto.
3. Impostazione del messaggio di fallback: Si definisce il testo esatto che il sistema deve restituire all’utente quando la policy viene infranta, garantendo un’esperienza utente controllata (es. “Non sono autorizzato a parlare di questo argomento”).
4. Assegnazione a un Guardrail Set: Si raggruppano le policy create in insiemi logici, specificando quali regole applicare in fase di input (pre-generazione) e quali in fase di output (post-generazione).

▶ Guarda questo passaggio nel video

Oltre alla configurazione delle regole statiche, la gestione avanzata richiede strumenti di orchestrazione visiva. In questo contesto si inserisce Flowdrop AI, una soluzione innovativa che permette di disegnare workflow logici attraverso un’interfaccia a nodi. Questo strumento è essenziale per i team di sviluppo che devono costruire pipeline in cui l’output di un modello diventa l’input di un altro, con step di validazione intermedi.

▶ Guarda questo passaggio nel video

Attraverso Flowdrop AI, è possibile mappare visivamente l’intero ciclo di vita del dato. I nodi di validazione possono essere inseriti strategicamente per verificare che un task intermedio, come l’estrazione di metadati da un PDF, non contenga informazioni sensibili prima di essere passato al nodo incaricato di generare un riassunto pubblico.

Il vero potenziale di questa architettura si esprime quando l’AI non si limita a generare testo, ma compie azioni sul sistema. Le Runner API di Drupal permettono a un agente AI di eseguire operazioni complesse sul CMS partendo da un prompt in linguaggio naturale. Un utente autorizzato potrebbe chiedere all’agente di “creare un nuovo tipo di contenuto per gli Eventi con campi per data e luogo”.

▶ Guarda questo passaggio nel video

Le Runner API traducono l’intenzione testuale in chiamate API strutturate, creando le entità nel database. In questo scenario, le policy di sicurezza diventano fondamentali per validare i permessi dell’agente e assicurarsi che le operazioni richieste non compromettano l’integrità dell’architettura informativa del sito, mantenendo al contempo un log di audit completo di tutte le azioni eseguite.

Gestione dichiarativa delle policy come codice

Per i DevOps Engineer che gestiscono l’infrastruttura tramite approcci dichiarativi, le policy di sicurezza possono essere definite e versionate come codice. Questo approccio garantisce che le regole aziendali siano replicabili in modo identico in tutti gli ambienti, dallo staging alla produzione.

Invece di operare esclusivamente tramite l’interfaccia utente, i team tecnici possono strutturare file YAML di configurazione che definiscono interi set di regole per mascherare i dati sensibili e bloccare il linguaggio inappropriato. All’interno di queste configurazioni, si stabiliscono identificatori univoci e descrizioni per ogni policy, suddividendo i controlli in due fasi distinte.

Nella fase di pre-generazione, si attivano plugin per la redazione delle PII, specificando entità come email, carte di credito o numeri di telefono da mascherare con appositi caratteri, affiancati da filtri per il linguaggio offensivo in modalità restrittiva.

Nella fase di post-generazione, si configura invece il controllo delle allucinazioni, impostando una soglia di tolleranza e un messaggio di fallback nel caso in cui le informazioni generate non siano presenti nei documenti aziendali.

Questa struttura permette di integrare facilmente le regole di sicurezza all’interno delle pipeline di Continuous Integration, validando le policy prima di ogni rilascio infrastrutturale.

Quali sono le alternative e l’ecosistema tecnologico?

Le alternative ai guardrails in Drupal includono servizi cloud gestiti come Amazon Bedrock, framework open source come Guardrails AI e LangChain, oppure Small Language Models (SLM) on-premise per la massima sicurezza dei dati sensibili. La scelta dipende dai requisiti di compliance, dal budget e dalle competenze del team.

L’ecosistema tecnologico per la validazione dei modelli linguistici offre approcci diversificati che possono essere combinati per creare un’architettura di difesa a strati.

I servizi gestiti dai grandi cloud provider offrono il percorso di adozione più rapido. Amazon Bedrock, ad esempio, mette a disposizione policy pre-configurate per filtrare contenuti tossici, bloccare argomenti specifici e rimuovere PII. Il vantaggio principale di queste soluzioni è la scalabilità nativa e la riduzione del carico operativo per i team interni, che non devono preoccuparsi di aggiornare i dizionari di blocco o mantenere l’infrastruttura di validazione.

Per i team di sviluppo che necessitano di un controllo più granulare, il panorama open source offre strumenti potenti. Esplorando repository github di guardrails ai, si trovano soluzioni flessibili per ogni stack. Ad esempio, Guardrails AI (si chiama proprio così) è un framework in python che permette di scrivere logiche custom complesse, spesso orchestrate tramite LangChain per validare le pipeline di agenti autonomi. Con questi strumenti, uno sviluppatore può implementare controlli strutturali sull’output, assicurandosi ad esempio che il modello restituisca sempre un JSON valido che rispetti uno specifico schema aziendale, bloccando la pipeline in caso contrario.

Nel caso di dati altamente confidenziali, inviare informazioni a un LLM pubblico, per quanto protetto da filtri, potrebbe non essere accettabile. In questi scenari, la strategia architetturale migliore prevede l’adozione di Small Language Models (SLM) specializzati. Questi modelli, più leggeri e focalizzati su task specifici, possono essere eseguiti interamente all’interno dell’infrastruttura aziendale.

Ospitare un SLM su un cluster Kubernetes proprietario garantisce che i dati sensibili non lascino mai il perimetro di rete dell’azienda. Per gestire efficacemente questa complessità infrastrutturale, è fondamentale adottare pratiche moderne di provisioning. A questo proposito, ti suggeriamo di esplorare i vantaggi dell’Infrastructure as Code nello sviluppo Cloud Native, un approccio indispensabile per automatizzare e scalare i deployment di modelli AI on-premise in modo sicuro e riproducibile.

La scelta dell’approccio corretto dipende da diversi fattori, in primis dai requisiti di compliance dell’azienda, dal budget a disposizione e dalle competenze del team di engineers ed architects. Non esiste una soluzione unica per tutti, ma piuttosto un ventaglio di opzioni che possono essere combinati per creare un’architettura di difesa a strati.

Il contributo di SparkFabrik alla Drupal AI Initiative

SparkFabrik contribuisce attivamente alla Drupal AI Initiative sviluppando componenti core per l’integrazione dell’intelligenza artificiale enterprise-grade nel CMS. Il nostro approccio unisce le pratiche di Platform Engineering allo sviluppo applicativo, garantendo soluzioni Cloud Native scalabili, sicure by-design e pronte per ambienti multi-cloud complessi.

In qualità di Kubernetes Certified Service Provider (KCSP) e membro attivo della Cloud Native Computing Foundation (CNCF), la nostra visione va oltre la semplice implementazione di feature. Crediamo che l’adozione dell’AI debba basarsi su fondamenta infrastrutturali solide, dove l’osservabilità, la sicurezza della supply chain del software e la resilienza operativa dei servizi siano garantite fin dalle prime fasi di progettazione.

Il nostro impegno nell’Open Source si traduce in contributi concreti al codice sorgente di Drupal, come discusso anche nel nostro report su DrupalCon Vienna 2025. Sviluppatori del nostro team, come Luca Lusso e Roberto Peruzzo, lavorano quotidianamente per estendere le capacità del modulo AI, introducendo funzionalità avanzate che rispondono alle reali esigenze del mercato enterprise. Per scoprire nel dettaglio le innovazioni tecniche che abbiamo introdotto, ti invitiamo a leggere l’articolo su come abbiamo plasmato il futuro di Drupal AI nel 2025.

▶ Guarda questo passaggio nel video

La nostra visione architetturale considera il CMS non più come un monolite isolato, ma come un hub intelligente all’interno di un ecosistema distribuito. Quando implementiamo funzionalità di reranking per migliorare le ricerche vettoriali, o sviluppiamo sistemi di orchestrazione per agenti autonomi, lo facciamo pensando a come questi processi si comporteranno sotto stress in un ambiente di produzione containerizzato.

Questo approccio olistico ci permette di supportare le aziende nella creazione di Internal Developer Platforms (IDP) dove l’intelligenza artificiale è integrata in modo nativo e sicuro. L’obiettivo finale non è solo fornire un CMS più intelligente, ma dotare i team IT di strumenti governabili che accelerino il time-to-market senza mai compromettere la stabilità e la sicurezza dell’infrastruttura aziendale.

Conclusioni e prossimi passi

L’implementazione dei guardrails AI rappresenta uno snodo cruciale per l’evoluzione tecnologica delle piattaforme digitali. Queste barriere di sicurezza non devono essere interpretate come un freno all’innovazione, ma piuttosto come il presupposto tecnico e architetturale che rende l’intelligenza artificiale effettivamente utilizzabile in contesti mission-critical e altamente regolamentati.

La roadmap futura per l’ecosistema Drupal prevede sviluppi ancora più avanzati. I prossimi passi si concentreranno sulla generazione automatizzata e intelligente di intere pagine, basata su prompt complessi e contestualizzati. Inoltre, il context management diventerà sempre più sofisticato, permettendo agli agenti autonomi di comprendere a fondo le linee guida del brand e la struttura semantica del sito prima di proporre o eseguire qualsiasi modifica sui contenuti.

Per i Tech Lead, i DevOps Engineer e i CTO, il momento di agire è ora. Integrare l’AI nei propri processi di business richiede una pianificazione architetturale attenta e competenze specifiche nel Platform Engineering.

Scopri come SparkFabrik può aiutarti a implementare guardrails AI enterprise-grade nel tuo Drupal. Contatta il nostro team di architetti certificati per una consulenza personalizzata.

Fonte video

Questo articolo è basato sul video “Guardrails e altre novità dal mondo Drupal AI”.

Negli ultimi mesi lo sviluppo software con l’AI è passato dai primi esperimenti di curiosità a una pratica quotidiana per molti team. Strumenti come Copilot e gli altri LLM per sviluppatori ti permettono di generare codice partendo da prompt sempre più ricchi, ma quando il progetto cresce emergono limiti chiari del semplice vibecoding. È qui che entra in gioco lo Spec Driven Development (SDD), un paradigma che prova a mettere ordine nel modo in cui usi l’intelligenza artificiale per scrivere software.

Perché il vibe-coding non basta più?

Vediamo uno scenario tipico. Scrivi un prompt al tuo assistente AI:

“Implementa un form di registrazione React con validazione real‑time per email e password, gestione errori, invio POST a /api/register, stile moderno con Tailwind, gestione stato tramite Zustand e chiamate con Axios.”

In pochi secondi l’LLM genera un componente completo. Sembra ben strutturato, ha validazioni, feedback visivi, persino un piccolo toast di successo. Lo integri, testi l’happy path, tutto funziona. Commit e deploy. Poi la realtà bussa alla tua porta, e il team di quality segnala una infinità di anomalie.

Questo è un esempio di sviluppo software con AI basato esclusivamente su prompt “di pancia”, ossia vibecoding. Da qui emergono chiaramente i limiti concreti del vibe‑coding:

• Imprecisione e ambiguità semantica. Espressioni generiche vengono interpretate in modo diverso a ogni generazione.
• Assenza di riproducibilità. Lo stesso prompt, eseguito più volte, produce implementazioni semanticamente differenti.
• Manutenzione e refactoring complessi, a causa di difficile standardizzazione del modo in cui il codice viene generato.
• Rischi di sicurezza e performance latenti, come ad esempio: validazione esclusivamente clientside, parsing non sicuro di input non fidati e problemi che passano inosservati nel momento della generazione, ma che diventano costosi quando il prodotto scala.

Insomma, il vibecoding ha avuto (e ha ancora) un ruolo importante: ha accelerato la prototipazione, ha abbassato la barriera d’ingresso e ha fatto scoprire a molti team il potenziale reale degli AI coding agent e dell’AI al servizio degli sviluppatori. Però non è più sufficiente quando si parla di software che deve operare in contesti enterprise.

Per andare oltre il semplice prompt engineering “a sensazione”, serve un cambiamento di paradigma. Bisogna cambiare prospettiva: dal codice guidato dall’intuizione e dall’apparenza, al codice guidato da specifiche esplicite, verificabili e condivise. È qui che si inserisce lo Spec Driven Development.

Lo spec driven development: definire le regole del gioco per l’AI

Spec Driven Development (SDD) significa trattare le specifiche come l’elemento centrale e più importante del progetto, la vera fonte di verità, invece del codice che viene generato. Non si parla però delle classiche specifiche in Word, PDF o Confluence che diventano obsolete subito dopo il rilascio.

Parliamo di specifiche eseguibili, nate per lo sviluppo software con l’AI, scritte in un linguaggio comprensibile sia dagli esseri umani che dalle macchine, che descrivono in modo preciso e non ambiguo lo scopo del sistema, gli scenari d’uso e i vincoli.

Se conosci il Test Driven Development (TDD) e/o il Behavior Driven Development (BDD), queste sono le analogie: pensa allo SDD come a un TDD portato al livello superiore e reso collaborativo con l’AI:

• TDD: scrivi prima il test, poi il codice minimo che lo fa passare.
• BDD: specifichi il comportamento atteso in linguaggio naturale strutturato.
• SDD: fa la stessa cosa, ma spinge il formato ancora più in là verso la macchina, diventando l’artefatto primario da cui tutto il resto discende.

In altre parole, l’intento dello sviluppatore (il tuo intento) diventa la vera “spec” che governa l’LLM.

Le fasi operative: dall’idea all’implementazione guidata

Per capire come questo approccio cambi il tuo modo di lavorare, è utile schematizzare il workflow tipico di uno sviluppatore che adotta Spec Driven Development. Possiamo tenere a mente le fasi descritte qui sotto.

Specify

Nella fase di specifica lo sviluppatore descrive in linguaggio naturale ma strutturato il comportamento atteso del sistema: il percorso dell’utente passo dopo passo, gli obiettivi di business, i casi d’uso principali insieme agli scenari limite rilevanti e tutte le regole di validazione o i vincoli non negoziabili.

Qui il tuo lavoro è soprattutto di analisi e di formalizzazione dell’intento, più che di scrittura di codice.

L’AI, a partire da questa narrazione, genera una specifica formale e dettagliata: schemi JSON per request e response, regole di validazione con esempi concreti, casi attesi e di fallimento in formato GivenWhenThen, invarianti di business e mock di eventuali servizi esterni.

Importante, non è un’attività “one-shot”, ovvero non c’è semplicemente una definizione iniziale da parte dello sviluppatore, seguita da una rifinizione e strutturazione da parte dell’AI. Piuttosto, si tratta di un processo iterativo in cui lo sviluppatore lavora assieme all’AI, definendo le specifiche, il cosa ed il perché del progetto.

Altrettanto importante, le specifiche devono essere mantenute nel tempo, affinché non diventino obsolete a seguito della fase di implementazione vera e propria e dell’evoluzione naturale di un progetto.

Plan

Nella fase di pianificazione lo sviluppatore definisce i vincoli tecnici non negoziabili: lo stack tecnologico, l’architettura preferita, le librerie da utilizzare per validazione, gestione dello stato, chiamate HTTP e testing, oltre a eventuali limiti di performance o bundle size.

L’AI elabora quindi un piano tecnico completo e realistico, indicando la struttura delle cartelle, i componenti principali con le rispettive responsabilità, il flusso dei dati, le librerie scelte e le motivazioni, la strategia di gestione degli errori e degli stati di caricamento, oltre ai mock necessari per i test.

Qui il prompting diventa vero e proprio prompt engineering: non chiedi più “fammi X”, ma guidi un agente AI con vincoli chiari e verificabili.

Scomposizione / Tasks

Nella fase di scomposizione in task l’AI prende il piano approvato e lo suddivide in attività atomiche, ordinate e indipendenti. Ogni task è progettato per essere piccolo, testabile in isolamento e associato a criteri di accettazione chiari, spesso collegati direttamente a uno o più esempi presenti nella specifica.

Questo passaggio rende il lavoro molto più vicino a un classico backlog agile, ma generato e mantenuto in coerenza con la spec.

Implement

Infine, c’è la fase di implementazione. L’AI genera il codice un task alla volta, sempre rispettando la specifica e il piano concordati. Lo sviluppatore legge e valida chunk di codice ridotti e mirati: verifica che il codice soddisfi i casi tipici e gli edge case previsti, esegue test locali o visualizza il risultato in anteprima, approva il risultato oppure richiede correzioni puntuali. Il ciclo è rapido, di solito 5-15 minuti per task.

In questo modo l’LLM per sviluppatori diventa un collaboratore sotto controllo, non un generatore di blocchi monolitici difficili da capire.

A questo punto hai un flusso completo: dalla specifica all’implementazione, con l’AI che segue regole chiare invece di improvvisare. Il passo successivo è scegliere gli strumenti giusti per supportare questo modo di lavorare.

Gli strumenti essenziali: da Spec Kit ad alternative emergenti

Il panorama degli strumenti per lo Spec Driven Development si è evoluto rapidamente. Oggi esistono soluzioni che vanno da framework leggeri open source a piattaforme complete che integrano l’intero ciclo di sviluppo software con AI.

GitHub Spec Kit resta il punto di riferimento open source. È un toolkit modulare che permette di scrivere specifiche in markdown strutturato (con schema JSON, esempi GivenWhenThen e invarianti), di validarle automaticamente e di generare codice tramite prompt contestualizzati verso qualsiasi LLM.

La sua forza sta nella semplicità, nella trasparenza e nel fatto che non lega a un singolo provider: puoi usarlo con Claude, GPT, Gemini o modelli locali. È il punto di partenza ideale per team che vogliono sperimentare SDD senza lock-in.

OpenSpec è un framework open source per lo SDD di coding agents. Le particolarità di questo strumento è l’essere particolarmente adatto a contesti brownfield con codice legacy. Piuttosto che requirements di alto livello, la sua forza è la definizione di requirements operativi per singoli agents, partendo dal contesto della codebase esistente e “dandogli in pasto” una singola issue.

È facile da usare, basta un openspec init per integrarlo in una codebase e installa solo 3 comandi: proposal (propone un nuovo cambiamento), apply (lo implementa), archive (lo archivia e aggiorna le specifiche). Interessante è come vengano tenute separate le specifiche attuali (la “source of truth”) dalle proposte di modifiche, in due cartelle separate che vengono riconciliate quando archivi le modifiche.

In questo modo i diffs sono sempre gestibili e tracciati, un requisito importante in molti contesti. È anche molto leggero, usa solo file markdown, e supporta tutti i coding assistants principali che stai già usando (Claude Code, GitHub Copilot, OpenCode, Cursor, Windsurf…).

Naturalmente, ci sono anche numerosi altri framework di SDD, più di nicchia e con funzionalità particolari. Un esempio è Spec-Kitty, dedicato a chi cerca capacità di orchestrazione elevate (esecuzione parallela di Agenti multipli senza conflitti) unità ad elevata visibilità su cosa sta effettivamente succedendo e su cosa stanno lavorando gli agenti. La feature più evidente è una dashboard visuale che traccia automaticamente tutti i progressi, permettendo la rappresentazione in una kanban board delle lavorazioni pianificate, in corso da revisionare e completate, nonché vedere quali agenti stanno lavorando a quale task.

Nel video “So you think you know Copilot?” affrontiamo anche un approfondimento pratico che mostra l’interazione con l’agente AI, mettendo in evidenza come uno Spec Driven Development ben fatto cambi il modo di usare strumenti come GitHub Copilot.

Per chi cerca un’esperienza più integrata rispetto al classico Copilot, le alternative più interessanti sono Kiro e Tessl. Kiro punta su un workflow collaborativo con “costituzioni” (regole di stile e architettura imposte a livello di progetto) e checklist automatiche per ogni generazione. È particolarmente utile in team grandi dove serve uniformità.

Tessl, invece, rappresenta l’approccio più radicale: è il primo tool vero spec-as-source. La specifica è l’unico artefatto modificabile, il codice viene rigenerato da zero a ogni cambiamento, e la storia del progetto vive quasi interamente nella spec stessa. È la scelta per chi vuole spingere al massimo l’idea che il codice sia un output derivato e non la fonte di verità.

Se vuoi vedere come l’AI può supportare anche la parte di DevOps e delivery, puoi approfondire il tema in questo articolo su AI, DevOps e Platform Engineering.

Da esecutore a direttore d’orchestra: il nuovo ruolo del developer

Lo SDD non riduce lo sviluppatore a un semplice “revisore di codice generato dall’AI”. Al contrario, lo eleva a un ruolo strategico e di altissimo valore: da chi scriveva ogni riga a chi definisce, orchestra e garantisce la qualità dell’intero sistema.

Nel modello tradizionale lo sviluppatore era spesso esecutore di requisiti: traduceva in codice dettagli tecnici e logiche di business che arrivavano già parzialmente formalizzate. Con lo Spec Driven Development il focus si sposta decisamente verso l’alto:

• Formalizzare con precisione chirurgica l’intento e i vincoli
• Progettare architetture sostenibili e scalabili
• Scegliere gli strumenti e i pattern giusti nel contesto del prodotto reale
• Validare che il codice generato rispetti i requisiti funzionali e non funzionali
• Ragionare su tradeoff complessi che nessuna AI può decidere da sola

In sostanza, si scrive molto meno codice boilerplate, ma si investe molto di più in pensiero critico, system design, comunicazione chiara dei requisiti e capacità di validazione profonda. Queste sono competenze rare, difficili da automatizzare e sempre più richieste dal mercato.

In SparkFabrik vediamo questo cambiamento come una grandissima opportunità. La nostra missione non è sostituire i team di sviluppo con l’intelligenza artificiale, ma aiutarti a far evolvere il tuo team verso ruoli di maggiore impatto e valore.

Vantaggi concreti: quando adottare un approccio spec-driven

Lo Spec Driven Development porta in dote diversi vantaggi:

• Codice di qualità superiore con meno bug
• Implementazioni più fedeli ai requisiti reali
• Manutenzione molto più semplice grazie a specifiche chiare che fungono da documentazione viva e sempre aggiornata
• Allineamento reale tra business e sviluppo attraverso l’espressione esplicita dell’intento prima della generazione
• Throughput più veloce e una riduzione drastica degli errori introdotti dall’AI grazie a validazione sistematica e Human-in-the-Loop

Naturalmente non tutti i contesti traggono lo stesso beneficio. Lo SDD esprime il massimo valore in tre scenari principali:

Progetti Greenfield

Per greenfield si intendono i progetti avviati da zero, in assenza di vincoli legacy, architetture preesistenti o debito tecnico accumulato. In questo contesto lo Spec-Driven Development esprime il massimo potenziale: le specifiche diventano il vero punto di origine del sistema e guidano l’intero processo fin dal primo commit.

L’architettura nasce già allineata ai requisiti funzionali e non funzionali, le decisioni tecniche sono tracciabili e motivate, e il rischio di divergenza tra visione progettuale e implementazione concreta si riduce drasticamente.

Le specifiche non sono solo documentazione iniziale, ma diventano una struttura portante che riduce le sorprese, previene incoerenze evolutive e limita la formazione di debito tecnico precoce, creando basi solide per la scalabilità futura del sistema.

Progetti Brownfield

Per brownfield si intendono invece i contesti in cui si interviene su sistemi esistenti: piattaforme legacy, architetture stratificate nel tempo, ecosistemi complessi già in produzione. In questi scenari lo Spec-Driven Development non serve a “costruire da zero”, ma a rendere esplicito ciò che spesso è solo implicito: vincoli architetturali, dipendenze, contratti di integrazione, comportamenti emergenti e limiti strutturali del sistema.

Le specifiche diventano uno strumento di formalizzazione del contesto reale, definendo con precisione punti di contatto, regole di compatibilità e confini funzionali. Questo consente all’AI di generare codice realmente contestualizzato, riducendo il rischio di regressioni, errori di integrazione e incoerenze sistemiche.

Il risultato è un aumento del throughput evolutivo, una maggiore sicurezza nei rilasci e una semplificazione concreta della manutenzione nel lungo periodo, anche in ecosistemi software altamente complessi.

Evoluzione del legacy

In questo caso lo SDD rende la transizione graduale e controllata: si descrivono prima i comportamenti desiderati del nuovo codice, si affronta il reverse engineering in modo strutturato, si ridefiniscono o aggiornano le specifiche e si sostituiscono porzioni obsolete. Così si riducono regressioni, overhead manuale e rischi di rottura, pur richiedendo un investimento iniziale per contestualizzare il sistema esistente.

Le sfide dello spec driven development: come evitare le trappole comuni

Come ogni paradigma emergente, lo Spec Driven Development porta benefici reali ma anche rischi concreti. Vediamo quali sono le trappole più frequenti.

Verschlimmbesserung, ovvero peggiorare le cose nel tentativo di migliorarle.

Workflow elaborati con decine di file markdown, checklist e costituzioni possono creare un overhead maggiore del beneficio, trasformando un piccolo fix in un processo burocratico pesante. O peggio, il tentativo di miglioramento può invece finire per peggiorare la situazione iniziale (letteralmente “peggioramento-miglioramento”).

Eccessiva verbosità delle specifiche

Le spec generate tendono a essere ridondanti, ripetitive e noiose da revisionare. Invece di chiarire, aumentano il carico cognitivo: più testo da leggere che codice da scrivere.

Occorre evitare di considerare lo SDD come scrittura esaustiva ma “vuota” di requisiti che nessuno legge, come creazione di burocrazia o come “waterfall planning”, ovvero un esercizio sterile di pianificazione estensiva nel tentativo di considerare tutte le eventualità e l’intero futuro di sviluppo.

Piuttosto, lo Spec-Driven Development riguarda il rendere le decisioni tecniche esplicite e revisionabili, nonché facilmente comprensibili (non solo da macchine, ma soprattutto da persone) ed agevolmente evolvibili.

Livello di dettaglio sbagliato

Troppo vago, l’AI fraintende e genera codice sbagliato. Troppo rigido, il processo diventa inflessibile, impossibile da adattare a cambiamenti rapidi o contesti brownfield. Trovare il “giusto mezzo” richiede pratica e iterazioni.

Falso senso di controllo

Anche con spec dettagliate, checklist e large context, l’AI ignora spesso istruzioni, duplica codice esistente o esagera nell’applicare regole. Il nondeterminismo resta: la stessa spec può produrre output diversi a ogni rigenerazione.

Questo è il nodo centrale del nuovo paradigma della programmazione, non più deterministico, ma legato a strumenti AI di natura probabilistica. Questo shift di paradigma è esplorato in profondità nel talk di Enrico Zimuel durante il nostro evento GenAI x Business.

Amnesia

In codebase complesse o in sessioni di lavoro particolarmente lunghe, gli agenti possono perdere parte del contesto: relazioni implicite tra componenti, decisioni già prese o modifiche effettuate in precedenza. Senza un ancoraggio continuo alle specifiche, questo può portare a incoerenze, duplicazioni o regressioni non intenzionali.

Limiti generali dello SDD

Per fix banali l’overhead è sproporzionato, per feature molto complesse o ambigue spesso non basta, e introdurlo su codebase legacy richiede uno sforzo iniziale elevato. Inoltre, se la specifica non viene mantenuta aggiornata diventa una fonte di inganno più pericolosa del codice stesso, ripetendo errori storici del modeldriven development: rigidità unita a imprevedibilità.

Essere consapevole di questi limiti ti permette di applicare lo Spec Driven Development dove ha davvero senso, evitando di trasformarlo in un nuovo dogma.

Il futuro dello sviluppo: spec-driven-development, spec-as-source, agenti sempre attivi

Lo Spec Driven Development rappresenta una nuova frontiera dello sviluppo AI, una direzione in cui molti stanno sperimentando diversi approcci. In tale contesto, si inserisce un’evoluzione ancora più radicale: lo spec-as-source development.

Secondo questo approccio, la specifica diventa l’unico artefatto stabile e modificabile. Quando cambiano requisiti, stack tecnologico o modello LLM, aggiorni solo la spec → piano, task e codice si rigenerano di conseguenza, automaticamente. La storia del progetto vive nella spec stessa, compreso il “commit history”. Il codice perde centralità: diventa un output derivato, temporaneo e rigenerabile.

Strumenti come Tessl stanno già spingendo in questa direzione, sebbene siano in fase molto sperimentale (attualmente con il limite 1-a-1 di una specifica-un codice), mentre le Agent Skills(inizialmente di Claude e ora open source, donati alla Agentic AI Foundation) mostrano un trend parallelo: agent autonomi che eseguono task complessi sotto guardrail definiti dalle specifiche. Un esempio è Superpowers di Obra su GitHub per task di sviluppo, mentre Skills.sh raccoglie migliaia di Skills per gli ambiti più disparati, dal design frontend, al brainstorming, al copywriting.

Questo paradigma cambia profondamente il ruolo del developer. Una persona inesperta resta nel vibe-coding, affidandosi a prompt generici (ed ottenendo risultati generici). Un senior invece esplode di potenziale: fornisce specifiche precise, guardrail rigorosi e architettura solida, trasformando l’AI da generatore casuale a esecutore affidabile e instancabile.

Lo SDD in contesto AI è ancora giovane, con sfumature in evoluzione e best practice in fase di scoperta. La direzione però è chiara: non sarà più “ecco il mio prompt, eseguilo, io aspetto”, ma “ecco i task, le regole e la direzione, tu continua a lavorare”.

A tendere assisteremo ad un “cambio di workforce”, con le macchine e gli agent che opereranno 24/7, mentre gli umani supervisionano, definiscono intento, specifiche, architettura e altri aspetti a valore elevato. Scrivere codice diventerà meno centrale; scrivere specifiche chiare, verificabili e durature diventerà una skill core del developer moderno.

Lanciare un sito web multilingue è una decisione strategica che apre le porte a nuovi mercati, aumenta la fiducia degli utenti e rafforza l’identità del tuo brand a livello globale. Allo stesso tempo, gestire un ecosistema digitale multilingua è, da sempre, un esercizio di equilibrio.

Chiunque abbia amministrato una piattaforma enterprise sa che la sfida non risiede tanto nella tecnologia di traduzione in sé, quanto nell’orchestrazione dei processi: volumi di contenuti in crescita esponenziale, cicli di revisione che rallentano il time-to-market, governance dei dati e costi operativi.

Oggi, l’avvento della Generative AI (GenAI) ha impresso un’accelerazione brutale a questo scenario. La promessa di traduzioni istantanee e a costo quasi nullo è seducente, ma porta con sé nuovi rischi : la perdita di coerenza del brand , le allucinazioni dei modelli probabilistici, il livello di qualità non sempre all’altezza dei modelli generalisti e la difficoltà di mantenere un controllo editoriale rigoroso su migliaia di pagine generate automaticamente.

In SparkFabrik lavoriamo quotidianamente su progetti complessi basati su Drupal, servendo clienti che gestiscono grandi ecosistemi digitali , dalle università ed enti pubblici che devono pubblicare bandi importanti e informazioni ufficiali, alle aziende enterprise con ampi portafogli prodotto e presenza globale.

Per queste realtà, la precisione linguistica non è un dettaglio estetico, non è solo per “apparire e suonare bene”: è un requisito di brand identity e di reputazione (e, in certi contesti, anche di compliance).

In questo scenario, Drupal si conferma non solo come una scelta solida, ma come il CMS enterprise meglio posizionato per trasformare la rivoluzione della GenAI in un vantaggio operativo concreto, anche per le esigenze multilingua, e senza sacrificare la qualità.

La Sfida del Multilingua

Affrontiamo subito il nodo centrale: il multilingua non è una banale questione di traduzione di parole da una lingua A a una lingua B.

Se fosse così semplice, basterebbe un plugin di Google Translate. Il multilingua è strategia. È SEO tecnica internazionale, è adattamento culturale (localizzazione), è manutenzione evolutiva di contenuti che devono restare sincronizzati nel tempo.

Insomma, avere una presenza multilingua è una decisione strategica multisfaccettata per il brand. Ed in tale ambito, la scelta della piattaforma di Content Management è la decisione fondante per qualsiasi strategia di internazionalizzazione.

Drupal si distingue nel panorama dei CMS enterprise** , eccellendo nella gestione strutturale di queste complessità grazie alla sua architettura che concepisce il multilinguismo come un attributo nativo del dato.

Al contempo, un grande “tallone d’Achille” di qualunque sistema multilingua è sempre stato l’automazione dei flussi di traduzione, in termini di bilanciamento tra costi e qualità. I metodi tradizionali, come l’invio di file via email alle agenzie o l’uso di traduttori automatici di vecchia generazione, sono ormai obsoleti per i ritmi ed i livelli qualitativi richiesti dal mercato odierno.

La nostra tesi è chiara: l’unica via percorribile per le organizzazioni moderne è l’uso intelligente della GenAI, ma rigorosamente affiancata da un controllo umano strategico.

Perché il multilingua è tornato ad essere un tema attuale?

Per comprendere la portata e l’attualità del tema dei contenuti multilingua, è doveroso gettare un occhio sul contesto storico che stiamo vivendo.

Anzitutto, nel landscape digitale formatosi in questi anni, abbiamo assistito ad una convergenza che, in definitiva, ha portato ad un aumento esplosivo della quantità di contenuti e traduzioni :

• La maturazione delle tecnologie di Intelligenza Artificiale Generativa (GenAI).
• Un’esplosione nella produzione di contenuti digitali, carburato soprattutto alla GenAI che ha potenziato il lavoro di team di ogni dimensione.
• Un conseguente aumento della domanda di localizzazione dei contenuti prodotti (un recente report indica un’impennata nella domanda di traduzioni enterprise del 30% annuo). Inoltre, le traduzioni si inseriscono in un trend più generale del mercato, nella direzione di contenuti coerenti e personalizzati per l’utente finale (ne abbiamo parlato nell’ambito dell’omnicanalità con Drupal).

Ma non si tratta solo di quantità di contenuti, vi è un altrettanto importante aumento di pressione sulla velocità. Campagne marketing, comunicazioni ed altri contenuti devono uscire simultaneamente in tutte le lingue. Non ci sono più settimane di tempo per la localizzazione manuale.

Terzo, la necessità di qualità. Le organizzazioni enterprise si trovano di fronte a un bivio: continuare ad affidarsi a processi manuali, ormai insostenibili per costi e tempi, o abbracciare l’automazione rischiando però di compromettere la reputazione del brand con traduzioni di bassa qualità (non solo letterale, ma in termini di tone-of-voice del brand).

La GenAI può in quest’ambito rappresentare il “sacro Graal” che bilancia quantità, velocità e qualità. Parallelamente, però, c’è la necessità di controllo : in un mondo in cui i contenuti sono generati dalle macchine, la governance editoriale diventa l’ultimo baluardo della brand identity. Fondamentali diventano quindi tanto il fine-tuning dei sistemi AI secondo l’identità di ciascun brand, quanto la supervisione e revisione umana.

In tale contesto, è opportuno considerare anche l’impatto della GenAI sulle redazioni: i team di content management non devono essere sostituiti, ma potenziati, liberandoli da task ripetitivi per concentrarsi sulla creatività e sulla supervisione qualitativa, anche in termini di localizzazione (in tal senso, Drupal abbraccia pienamente questo approccio all’AI).

Non da ultimo, rendere (o mantenere) un brand multilingua è una decisione strategica che apre le porte a nuovi mercati e rafforza il brand a livello internazionale o globale. È quindi assolutamente evidente l’interesse per i brand per tale strategia, oggi resa decisamente più accessibile a realtà di ogni dimensione grazie alla GenAI.

Drupal e multilingua: cosa funziona, cosa cambia

Drupal non ha bisogno di presentazioni quando si parla di capacità multilingua, anzi: la centralità di Drupal nel settore enterprise è in buona parte attribuibile anche alla sua maturità architettonica riguardo alle strutture dati multilingua.

A differenza di altri CMS che richiedono plugin pesanti per gestire le traduzioni, Drupal gestisce il multilingua a livello di Core**. Questo significa che ogni entità (dai nodi ai blocchi di contenuto, dalle tassonomie ai menu) è nativamente traducibile.

Tuttavia, la capacità di memorizzare le traduzioni è inutile senza un processo operativo efficiente per crearle e gestirle. Questo è il dominio di moduli come il Translation Management Tool (TMGMT).

Analizziamo quindi più nel dettaglio gli aspetti multilingua nel Core di Drupal e in TMGMT.

Multilingua e localizzazione nel Core di Drupal

Drupal incorpora il multilinguismo nel suo Core principale, al livello più profondo del suo framework applicativo. Questo significa che robustezza e scalabilità sono garantite, non dipendendo da plugin terzi che possono rompersi in qualunque momento.

Più nel dettaglio, Drupal integra il supporto linguistico a livello di Entità e di Campo. Ogni elemento di contenuto è un’entità (sia esso una pagina, un blocco, un termine di tassonomia, un menu o un media asset). Il sistema di traduzione nativo permette di creare varianti linguistiche per ciascuna entità mantenendo un unico ID univoco.

Allo stesso tempo, è possibile configurare quali specifici campi di un contenuto devono essere tradotti (es. titoli e descrizioni prodotto) e quali devono rimanere invariati (es. codici prodotto, specifiche tecniche numeriche, immagini globali). Questo non solo ottimizza i costi di traduzione riducendo il volume di parole, ma garantisce l’integrità dei dati tecnici attraverso i mercati.

L’architettura linguistica di Drupal opera quindi su quattro livelli:

Inoltre, le organizzazioni possono scegliere se mantenere una struttura simmetrica (ogni pagina esiste in tutte le lingue) o asimmetrica (contenuti specifici per mercati locali), gestendo tutto all’interno di un’unica istanza o attraverso un’architettura multisite governata centralmente. Anche la logica che determina quale variante servire all’utente è configurabile: prefissi URL (es. /it/), domini di primo livello, preferenze dell’utente autenticato o impostazioni del browser.

Altrettanto importante, la gestione dei permessi granulare di Drupal è un aspetto fondamentale per le realtà più strutturate, permettendo di impostare permessi role-based precisi e pipelines di revisione, approvazione e pubblicazione per ciascuna lingua o regione.

Insomma, Drupal supporta una flessibilità essenziale per supportare le strategie prodotto, content e SEO più complesse e internazionali.

Superiorità Architetturale di Drupal rispetto ai concorrenti

Quando confrontato con alternative come WordPress o Adobe Experience Manager (AEM), l’architettura nativa di Drupal offre vantaggi di business indiscutivili.

• Confronto con WordPress: WordPress richiede tipicamente plugin come WPML o Polylang. Questi spesso memorizzano le traduzioni come post separati collegati da metadati, il che può portare a un ingrossamento del database e all’inefficienza delle query su larga scala. La traduzione basata su entità di Drupal memorizza le traduzioni all’interno dello stesso record di entità, ottimizzando le performance, semplificando le query API e garantendo una maggiore coerenza dei dati.
• Confronto con Adobe Experience Manager (AEM): Mentre AEM offre robuste “Language Copies”, comporta costi di licenza elevati e spesso richiede pesanti personalizzazioni per flussi di lavoro complessi. Drupal offre capacità enterprise comparabili (permessi granulari, integrazione del flusso di lavoro, gestione multi-sito) senza le commissioni di licenza, riducendo significativamente il Total Cost of Ownership (TCO) e permettendo di reinvestire il budget in innovazione e qualità dei contenuti.
• Confronto con Headless CMS: L’evoluzione delle architetture digitali verso modelli “Composable” e “Headless” ha reso ancora più critica la capacità di un CMS di fungere da repository centrale di contenuti multilingua. Drupal, grazie al suo approccio API-first, espone nativamente i contenuti tradotti tramite JSON:API e GraphQL. Importante, i dati sono esposti in formato strutturato e consumabile per qualsiasi frontend (React, Vue, Angular), facilitando la distribuzione omnicanale senza la necessità di middleware complessi per la gestione della logica linguistica.

TMGMT come orchestratore dei flussi

Mentre il Core di Drupal fornisce la capacità di memorizzare le traduzioni, non gestisce completamente il processo operativo della traduzione. Qui entra in gioco il Translation Management Tool (TMGMT).

Utilizzato da oltre 10.000 siti ad alto traffico, si tratta di una suite di strumenti che standardizzano il processo di traduzione. In contesti enterprise, e comunque per chi gestisce workflow editoriali avanzati, TMGMT diventa davvero il cuore pulsante del sistema.

La gestione manuale delle traduzioni (export copia-incolla via email) è il principale collo di bottiglia per la scalabilità. TMGMT risolve questo problema introducendo un layer di astrazione e automazione.

Anzitutto, TMGMT permette di disaccoppiare completamente la fonte del contenuto dal fornitore della traduzione. Possiamo quindi vedere due livelli:

1. Sorgenti (Sources): TMGMT può estrarre testo da qualsiasi elemento di Drupal (Nodi, Blocchi, I18n Strings). Non importa se il contenuto risiede in un paragrafo, in un campo personalizzato o in una stringa di configurazione; TMGMT lo normalizza in un formato pronto per la traduzione.
2. Traduttori (Translators): Grazie alla sua architettura a plugin, TMGMT è agnostico rispetto a chi esegue la traduzione. Può essere un utente umano, un’agenzia esterna collegata via file XLIFF, o un servizio di traduzione automatica. Oggi, tra i traduttori sono inclusi anche gli LLM, offerti dai vari provider (OpenAI, Gemini, Ollama, Lara…).

Il vantaggio di questa flessibilità è chiaro: permette di cambiare fornitore di traduzione senza dover riscrivere codice o formare nuovamente il personale editoriale , riducendo drasticamente il rischio di vendor lock-in.

Le funzionalità di governance sono un altro valore aggiunto centrale di TMGMT. Permette di assegnare job di traduzione a utenti specifici, di gestire stati di avanzamento granulari (“pending”, “translated”, “reviewed”, “accepted”) e di avere una visione d’insieme su cosa è stato tradotto e cosa no. Questo approccio strutturato assicura che le traduzioni non vengano pubblicate alla cieca, ma secondo pipeline avanzate di review e validazione.

Infine, una funzionalità avanzata (particolarmente utile per siti ad alto volume di aggiornamento) è quella dei Continuous Translation Jobs.

Questa feature inverte il paradigma tradizionale: invece di aspettare che un editor crei manualmente un “pacchetto” di traduzione, il sistema monitora proattivamente i contenuti. Quando un contenuto viene creato o aggiornato, TMG lo rileva ed il nuovo contenuto viene automaticamente aggiunto ad un Job, inviato poi al provider di traduzione.

Questo meccanismo elimina i “tempi morti” e il rischio di drift tra contenuto originale e tradotto, essenziale per mantenere la coerenza in ecosistemi e-commerce o news in tempo reale.

Tuttavia, fino a poco tempo fa, esisteva un limite tradizionale. Le opzioni erano polarizzate: da un lato la traduzione manuale (alta qualità, costi e tempi elevati), dall’altro la Machine Translation classica (bassa qualità, basso costo). Mancava un “ponte” efficace verso servizi capaci di coniugare la velocità dell’automazione con una qualità degna di pubblicazione enterprise.

La GenAI sta cambiando questo paradigma, inserendosi esattamente in questo spazio e abilitando workflow ibridi che prima erano impensabili.

Traduzioni AI + human-in-the-loop: velocità sì, ma non a scapito della qualità

L’automazione linguistica basata su LLM (Large Language Models) permette oggi di gestire volumi di traduzione che sarebbero stati umanamente ed economicamente impossibili solo pochi anni fa. Pensiamo alla traduzione di migliaia di schede prodotto, di knowledge base tecniche o di archivi storici di news.

Tuttavia, la velocità non può diventare una scusa per il degrado qualitativo.**

Per i contenuti istituzionali, strategici o legati al core business, l’apporto umano rimane imprescindibile. L’AI, per quanto avanzata, può mancare di sensibilità sul contesto culturale specifico o può fraintendere sfumature di tono cruciali per il brand. La strategia vincente che stiamo osservando non è la sostituzione, ma l’approccio ibrido : AI + Revisione (Human-in-the-loop).

Qui sorge un problema critico : molti tentano di risolvere la questione collegando Drupal a modelli generalisti come ChatGPT o Gemini tramite API generiche. Sebbene tecnicamente possibile, questo approccio è spesso inefficace per l’enterprise. I modelli generalisti sono “tuttologi”: traducono una poesia con la stessa probabilità statistica con cui traducono un manuale tecnico, spesso inserendo allucinazioni o perdendo la coerenza terminologica necessaria.

I clienti Enterprise e Accademici non possono permettersi questi rischi. Un termine legale tradotto in modo approssimativo o un tono di voce troppo colloquiale in una comunicazione istituzionale possono creare danni reali.

Quando la qualità è un KPI fondamentale, affidarsi a sistemi generalisti significa spostare il costo dalla traduzione alla revisione massiccia, annullando il vantaggio economico.

Se vogliamo sfruttare la potenza della GenAI in contesti in cui l’accuratezza è centrale, serve un modello AI specializzato. Serve un partner tecnologico che abbia risolto il problema della qualità alla radice. È in questo scenario che introduciamo Lara Translate.

L’integrazione con Lara Translate: perché l’abbiamo costruita

Mentre il Drupal Core fornisce la capacità di memorizzare le traduzioni e TMGMT fornisce l’infrastruttura logistica e l’integrazione con i provider, la qualità dell’output dipende dal motore di traduzione.

Se i Large Language Models (LLM) generici hanno dimostrato una fluidità impressionante, spesso mancano della specificità di dominio e della coerenza terminologica richieste per l’uso enterprise.

È qui che si distinguono i Language Models specializzati come Lara Translate. Si tratta di un’AI creata dall’italiana Translated, azienda specializzata verticalmente in traduzioni e tecnologie AI di alta qualità.

La nostra scelta di integrarla in Drupal nasce dall’esigenza specifica di un cliente istituzionale di integrare un provider di traduzioni di qualità. Da un’analisi approfondita delle soluzioni disponibili sul mercato, Lara si posiziona costantemente un gradino sopra la traduzione automatica standard, avvicinandosi alle performance dei migliori traduttori professionisti umani.

Ma cosa differenzia Lara da altre soluzioni? La differenza risiede nel DNA del progetto. Lara è l’LLM sviluppato da Translated, azienda che opera nel settore delle traduzioni professionali dal 1999.

A differenza dei modelli generalisti addestrati su tutto il web (compresi contenuti di bassa qualità), Lara è stata addestrata e fine-tuned su un dataset proprietario di milioni di traduzioni professionali.

Parliamo di decenni di lavoro svolto da oltre 500.000 linguisti professionisti per 397.000 clienti enterprise, in più di 200 lingue, per un totale di oltre 25 milioni di traduzioni professionali reali.

Lara ha “imparato” a tradurre guardando come lavorano i migliori umani, non leggendo forum online. Questa specializzazione sui dati di addestramento è ciò che garantisce un output superiore.

Per portare questa potenza all’interno dei nostri progetti, in SparkFabrik abbiamo sviluppato e rilasciato il modulo TMGMT Lara Translate, un plugin che introduce Lara come translation provider per tutti i contenuti in Drupal.

Il plugin permette ai team editoriali di inviare contenuti a Lara e ricevere le traduzioni direttamente nell’interfaccia di Drupal, mantenendo intatte tutte le funzionalità di governance, revisione e workflow di TMGMT.

Il risultato è un processo fluido: niente più copia-incolla, tutti i vantaggi del multilingua in Drupal, uniti a qualità altissima in automatico. Ma per raggiungere tale livello di qualità, alcune funzionalità peculiari sono state sviluppate in Lara (e sono pienamente supportate in Drupal).

Inoltre, Translated offre anche la possibilità di integrare una revisione umana professionale(human-in-the-loop) per quelle traduzioni che richiedono uno strato in più di garanzia. Come visto, Lara è un modello di Gen AI altamente performante nei task di traduzione proprio grazie alla filosofia umano-centrica di Translated, che ha portato all’addestramento basato su milioni di traduzioni professionali umane (puoi approfondire qui).

Funzionalità distintive di Lara Translate integrata in Drupal

• Stili di traduzioni
  Le aziende non comunicano in un unico modo. Un contratto legale richiede precisione assoluta, mentre una campagna marketing richiede creatività. In egual modo, Lara non traduce in modo piatto, ma integra nativamente tre stili di traduzione distinti.
• Faithful (Fedele): Ideale per manuali tecnici, contratti legali e contenuti dove la precisione terminologica è vitale.
• Fluid (Fluido): Perfetto per contenuti editoriali generali, blog post e news.
• Creative (Creativo): Pensato per il marketing e lo storytelling, dove l’AI si prende la libertà di adattare il messaggio per massimizzare l’impatto emotivo.

• Context awareness e coerenza documentale.
  A differenza dei vecchi sistemi che traducevano frase per frase perdendo il filo del discorso, Lara analizza l’intero documento. Comprende le relazioni tra le frasi, mantiene la coerenza del genere grammaticale e dei riferimenti attraverso tutto il testo, garantendo un flusso naturale.
• Glossari.
  Consentono di specificare le traduzioni corrette per termini e frasi specifiche che sono cruciali per il tuo particolare contesto. Questo assicura che Lara applichi la terminologia giusta in modo coerente a tutte le traduzioni.
• Trust Attention.
  Lara utilizza un meccanismo proprietario per “pesare” le informazioni. Durante la generazione, dà priorità ai dati provenienti da traduzioni professionali verificate rispetto a fonti meno affidabili. Queste includono anche revisioni, correzioni e la “memoria dell’errore”.
• Lara Feedback.
  Grazie al suo dataset che include anche correzioni reali, Lara è in grado di “spiegare” le proprie scelte traduttive, fornendo un livello di trasparenza inedito per un sistema AI (la cosiddetta “AI Explainability” o spiegabilità).
• Accesso Scalabile agli Esperti.
  L’ecosistema di Translated permette, quando l’AI non basta (ad esempio per contenuti ultra-sensibili), di attivare tramite la stessa pipeline i servizi di traduttori umani professionisti. Il passaggio da traduzione AI a traduzione umana professionale su richiesta è quindi reso più immediato.

Come utilizzare Lara come provider di traduzioni in Drupal

Se sei pratico di TMGMT, per te sarà immediato iniziare ad utilizzare Lara. Se sei nuovo, ecco una rapida overview della procedura (è comune agli altri provider).

1. Assicurati ovviamente di aver installato ed attivato TMGMT e di aver installato il plugin TMGMT Lara Translate.
2. Vai su ​ Translation Management → Providers. Crea una istanza per Lara aggiungendo le tue credenziali API (ti servirà ovviamente un account Lara). Le impostazioni ti permettono di personalizzare il modulo secondo il tuo contesto specifico, ad esempio selezionando lo stile di default e collegando glossari.
3. Tramite TMGMT, scegli le entità che andranno tradotte (nodi, paragrafi, ecc) e le lingue necessarie. Crei così i Job per inviare i contenuti a Lara.
4. Lara traduce in automatico e restituisce a Drupal l’output. Qui si vede la qualità di Lara: le traduzioni rispettano contesto, tono e terminologia specifici.
5. Tipicamente, l’output richiede editing umano minimo. Inoltre, Lara supporta la review evidenziando ambiguità e fornendo spiegazioni.
6. Una volta approvate, le traduzioni sono pubblicate automaticamente.

L’approccio ibrido, nativo ma moderno

Come forse avrai notato dalla procedura, l’utilizzo di Lara sembra assolutamente nativa in Drupal, a maggior ragione se hai già messo le mani su un sito multilingua con TMGMT. Ciò che è diverso è il “motore” dietro le quinte, un LLM super specializzato.

Anche con Lara alla base del processo automatico di traduzione, non viene in ogni caso eliminato o sminuito il ruolo umano nel processo. Si tratta del concetto di “Human in the Loop” (HITL), che qui assume una duplice accezione.

• AI di qualità come base. Lara fornisce una “prima traduzione” di alta qualità che è spesso già definitiva, riducendo drasticamente il tempo di editing.
• Controllo editoriale in Drupal. Grazie a TMGMT, l’editor umano può rivedere la traduzione direttamente nel CMS prima della pubblicazione ed editare manualmente il contenuto. Grazie alla qualità dell’output si tratta tipicamente di interventi minori, soprattutto se Lara è configurata correttamente con glossari e tono del brand. Il revisore viene così potenziato e trasformato in un supervisore strategico.
• Traduzioni professionali. Per casi più specifici e particolari, è possibile richiedere i servizi dei traduttori professionisti di Translated, la casa madre dietro Lara.

L’adozione di questo stack tecnologico genera un impatto economico immediato e misurabile: l’azienda può ridurre il budget di traduzione fino all'80% o, a parità di budget, tradurre 5 volte più contenuti, aprendo nuovi mercati precedentemente irraggiungibili per limiti di costo.

Infatti, i dati di mercato del 2025 evidenziano una disparità enorme tra i costi di traduzione umana e AI, e l’approccio ibrido permette di avere il meglio di entrambi i mondi: la tabella seguente offre una stima indicativa (vedi gli approfondimenti qui e qui).

Ma i vantaggi di questo approccio non si fermano agli aspetti economici. Altrettanto rilevanti sono:

• l’accelerazione del Time-to-Market , con conseguente aumento non solo della velocità, ma anche della competitività nei mercati locali)
• la coerenza del brand , attraverso l’uso di una terminologia corretta ed un tone of voice unificato, altrimenti difficilmente ottenibile con team umani frammentati. Di coerenza abbiamo parlato ampiamente in termini di Design System, ma altrettanto importante è la coerenza in termini di contenuto testuale.
• la scalabilità operativa : il team di marketing (o le figure esterne a supporto) non deve crescere linearmente con il numero di contenuti e di lingue supportate. È possibile automatizzare la traduzione di contenuti a “basso rischio” e concentrare l’attenzione umana su contenuti sensibili, sulla strategia e su altri aspetti dall’elevato valore aggiunto.

Use cases

L’adozione di questa architettura (Drupal + TMGMT + Lara Translate) non è un esercizio teorico, ma una soluzione pratica a problemi reali. Non per niente, questa integrazione nasce proprio dalla richiesta di un cliente in un business case reale.

È la configurazione ideale per siti ad alto volume di contenuti che non possono permettersi i costi di un’agenzia tradizionale per ogni singola parola, ma che non possono nemmeno accettare la qualità scadente della machine translation grezza.

Pensiamo a progetti in cui tono di voce, coerenza e chiarezza sono asset non negoziabili : portali di marketing internazionale, documentazione tecnica di prodotto, siti legali o istituzionali. In questi contesti, l’automazione deve essere intelligente.

Un esempio immediato? Pensa ad un ecommerce enterprise con 50.000 SKU: può tradurre automaticamente le descrizioni dei prodotti (in stile Fluid) e le specifiche tecniche (con stile Faithful), riservando il budget umano per la revisione dei dettagli tecnici, per le pagine di campagna marketing e l’home page, massimizzando il ROI.

Business Case: L’Università Digitale

Vediamo più nel dettaglio un business case specifico. Un esempio concreto del valore di questa soluzione è il lavoro svolto per una prestigiosa Università italiana (cliente reale per cui abbiamo originariamente sviluppato il modulo).

• Il contesto.
  Un’Università è una macchina editoriale enorme a cui lavorano centinaia di persone, in diverse lingue: siti istituzionali, siti dipartimento, notizie, highlight di ricerca, bandi di concorso, regolamenti, descrizioni dei programmi di corso, informazioni amministrative… sono solo una parte dei contenuti gestiti dai team editoriali universitari. E tipicamente, devono essere divulgati in diverse lingue. Nel contesto education, Drupal si rivela essere il CMS ideale.
• Il problema.
  I tempi di traduzione manuale sono incompatibili con la velocità delle news. Soluzioni come Google Translate e continuo copia-incolla (che rompono anche la formattazione) sono ormai impensabili. Ma anche utilizzando LLM generalisti si incontravano limiti qualitativi importanti, con conseguente investimento importante di risorse nella fase di revisione. Era necessario un sistema alternativo, di alta qualità ed integrato direttamente in Drupal, in un workflow familiare per gli operatori ed in grado di garantire la piena governance.
• La soluzione.
  Dopo un’approfondita ricerca, Lara è stata identificata come provider ed abbiamo implementato il modulo TMGMT Lara Translate.
• Il nuovo workflow.
  Oggi, gli editor dell’Università creano il contenuto in italiano (o comunque nella lingua iniziale) su Drupal. Con un click, selezionano le lingue target e inviano il job a Lara direttamente dall’interfaccia di editing. Lara restituisce una traduzione di alta qualità, rispettando la terminologia accademica (grazie all’addestramento specifico, all’uso dei glossari ed alle istruzioni personalizzate) e mantenendo intatti i tag HTML. Il contenuto torna in Drupal nello stato “Da revisionare”. L’editor dà una rapida occhiata, approva, eventualmente ottimizza, e pubblica.
• Il risultato.
  I tempi di pubblicazione multilingua si sono ridotti dell'80%. I costi di traduzione sono crollati, permettendo di tradurre molti più contenuti a parità di budget e con qualità elevata. Il controllo editoriale è rimasto saldamente nelle mani dell’Ateneo, senza duplicazioni o perdite di dati.

Conclusioni, raccomandazioni e prossimi passi

La GenAI ha avuto un impatto disruptive su tutto il mondo dei contenuti. Eppure, a dispetto di quanto possa sembrare, l’era della GenAI non ci chiede di scegliere tra l’automazione e la qualità umana, ma di orchestrarle in modo da sfruttare le parti migliori di entrambe.

La gestione di un ecosistema multilingua è una leva strategica che impatta direttamente sulla crescita, sul Time-to-Market, sulla reputazione del brand. In un mondo di sovrabbondanza di tool automatici, la differenza la fanno alcuni dettagli fondamentali: la qualità, il workflow, la supervisione.

La combinazione di Drupal CMS , con la sua architettura solida, API-first e intrinsecamente sicura, TMGMT , per gestire efficacemente il processo di localizzazione, e Lara Translate , con la sua intelligenza contestuale specializzata, offre finalmente una risposta concreta.

I brand non sono più costretti a sacrificare la qualità sull’altare della velocità, né a dissanguare i budget operativi per garantire la coerenza terminologica su scala globale. La soluzione ibrida identificata e l’approccio “Human-in-the-Loop” (validato attraverso casi studio reali), sono il compromesso ideale. I team editoriali possono liberarsi dal lavoro ripetitivo e a basso valore aggiunto di “data entry” linguistico e di elevarsi a curatori della strategia globale, concentrandosi sulle sfumature culturali e comunicative che rendono i brand unici in ogni mercato.

Raccomandazioni per i Decision Maker

Per i decision maker che intendono trasformare questa visione in realtà operativa, la roadmap consigliata si articola in quattro passaggi essenziali:

1. Audit dei flussi attuali: Mappa il ciclo di vita esistente “contenuto-traduzione”. Identifica i colli di bottiglia causati dall’intervento umano, dalla gestione manuale dei file o dagli scambi di email. Effettivamente, quanto tempo passa dalla creazione di un contenuto master in italiano alla sua pubblicazione effettiva in cinese, tedesco o arabo? Se la risposta si misura ancora in settimane anziché in ore, il gap competitivo sta crescendo.
2. Adottare lo stack strutturale: Implementa la gestione del multilingua in Drupal con il modulo TMGMT. Per siti enterprise non è un optional, ma un requisito architetturale necessario per “disaccoppiare” la creazione del contenuto dalla sua traduzione.
3. Optare per AI specializzate: Avvia un pilot iniziale su segmenti non critici, sostituendo LLM generalisti o processi manuali con Lara Translate. Sfrutta la capacità unica del modello di comprendere il contesto dell’intero documento e di aderire programmaticamente allo stile del vostro brand (“Faithful”, “Fluid”, “Creative”) per ridurre drasticamente il tempo e il costo della revisione umana.
4. Definire la governance: Stabilisci linee guida chiare su quali tipi di contenuto richiedono post-editing umano rispetto alla traduzione solo AI, utilizzando gli stati del flusso di lavoro di TMGMT per applicare queste regole. Per i contenuti critici, valutare di mantenere un intervento manuale da parte di professionisti della localizzazione.

Spostando il baricentro dalla traduzione manuale alla supervisione strategica di un’IA affidabile e contestuale, le aziende possono superare le barriere linguistiche con una velocità e una qualità senza precedenti.

SparkFabrik, attraverso la sua profonda expertise tecnica e strategica in Drupal e lo sviluppo di strumenti come il connettore Lara per Drupal, si pone come partner tecnologico chiave per guidare le organizzazioni in questa transizione, trasformando la sfida della complessità linguistica in un vantaggio competitivo strutturale.

Se la tua organizzazione sta esplorando l’adozione di Drupal come CMS aziendale robusto, affidabile e personalizzabile, l’introduzione di strategie multilingua o l**’integrazione di AI** per le sue iniziative digitali, ti invitiamo a:

1. Esplorare i nostri case study di implementazioni Drupal enterprise
2. Contattare il nostro team per una valutazione delle tue esigenze specifiche
3. Scoprire come la nostra suite di servizi Drupal può supportare la tua strategia AI

Questo articolo è parte della nostra serie dedicata a Drupal. Per esplorare altri aspetti della piattaforma, vi invitiamo a consultare i nostri precedenti articoli su caratteristiche e vantaggi, confronto con le alternative, strategie di migrazione, sicurezza e compliance, architettura composable, Design System, Drupal headless omnicanale, panoramica e novità di Drupal AI e le nostre contribuzioni a Drupal AI.

Per la community Drupal, gennaio è il mese in cui si spengono le candeline: oggi, il 15 gennaio 2026, festeggiamo 25 anni di una tecnologia che ha plasmato il web. 🎂

Ma nell’Open Source, il modo migliore per onorare un progetto è costruirne il futuro e raccontarlo. Quale momento migliore, quindi, per fermarsi, mettere ordine e condividere le nostre contribuzioni all’ecosistema?

Il 2025 è stato l’anno in cui l’intelligenza artificiale è passata da “feature interessante” a infrastruttura. Un po’ come il cloud un decennio fa: prima curiosità, poi sperimentazione, infine inevitabilità. In mezzo, una domanda che chi lavora su piattaforme digitali non può più rimandare: “Come portiamo l’AI in produzione… senza perdere controllo, sicurezza e qualità?”.

È esattamente qui che si inserisce la Drupal AI Initiative: un progetto nato per trasformare l’energia (molto reale) della community in una visione coordinata, con l’obiettivo di rendere Drupal non solo “compatibile con l’AI”, ma CMS enterprise-grade anche quando l’AI entra nel cuore dei flussi editoriali e di business.

In SparkFabrik non siamo rimasti a guardare, abbiamo capito che non volevamo essere semplici utilizzatori di questa nuova tecnologia, ma dei “makers”. D’altronde, l’Open Source non è una “strategia di marketing” per noi, è parte della nostra storia e del nostro DNA.

Abbiamo scelto di esserci, con contribuzioni concrete, su aree che abbiamo identificato come decisive per l’adozione reale: developer experience , governance & sicurezza (guardrails), RAG & search, agentic workflows (MCP e toolchain) , integrazioni enterprise e, cosa spesso sottovalutata, comunicazione e community building.

Ecco come abbiamo contribuito a costruire il futuro di Drupal nel 2025 (spiegato con un taglio tecnico, ma pensato anche per chi deve prendere decisioni).

E a proposito di contribuzione: quale occasione migliore per annunciare che sabato 31 gennaio ospiteremo il Drupal Contribution Day a Milano? È ormai un appuntamento ricorrente e irrinunciabile nei nostri uffici, un momento per incontrarsi, scrivere codice insieme (ma non solo!) e “restituire” alla community. Registrati qui per partecipare assieme a noi!

Cos’è la Drupal AI Initiative

La Drupal AI Initiative è un progetto strategico che ha l’obiettivo di integrare l’AI in Drupal in modo efficace, evolvendo il sistema per posizionarlo come il miglior “CMS agentico ” open-source.

L’ecosistema Drupal parlava già AI da tempo, con funzionalità, integrazioni e moduli che crescevano e fornivano un assaggio di ciò che era possibile. Tuttavia, si è capito che per portare un impatto strategico reale era necessario andare oltre le contribuzioni frammentate, incanalando gli sforzi.

Con questa consapevolezza, il 9 giugno 2025 è stata lanciata la Drupal AI Initiative, con l’obiettivo di portare struttura, strategia e direzione condivisa all’innovazione (ed una visione comune di AI a supporto delle persone, sicura e pienamente governabile anche in ambienti enterprise). In altre parole: non solo “moduli AI”, ma una direzione comune, un framework e un ecosistema capace di crescere senza perdere governabilità.

Per chi prende decisioni (CTO, CDO, responsabili digital, marketing lead) questo punto è enorme: significa poter portare AI nelle esperienze digitali senza lock-in su un provider, senza dover ricostruire tutto da zero, e con l’ossatura di governance tipica di Drupal.

Prima di tutto: chi ha contribuito (persone, non solo codice)

L’innovazione è guidata dalle persone. La nostra contribuzione non sarebbe stata possibile senza un investimento strutturale importante: da giugno 2025, abbiamo dedicato il 50% del tempo lavorativo di due dei nostri migliori talenti tecnici esclusivamente alla Drupal AI Initiative.

Non parliamo di ritagli di tempo, ma di un impegno costante, quotidiano. Una quantità di risorse giustificata dalla visione strategica interna, e spesso alimentata ulteriormente da una passione personale che va ben oltre l’orario d’ufficio.

L’esperienza pregressa del team è stata fondamentale, perché molte delle nostre contribuzioni 2025 non sono state esercizi teorici, besì scelte tecniche fatte da chi ha già visto cosa funziona (e cosa si rompe) quando un progetto deve vivere nel mondo reale.

Come abbiamo lavorato: governance, ritmo e allineamento

A guidare la visione strategica è stato il nostro CTO, Paolo Mainardi , che ha coordinato le attività con metodo preciso per assicurare di produrre valore in modo continuativo (e non solo per l’ecosistema e la community, ma anche per affrontare le veresfide enterprise dei nostri clienti).

Nel 2025 abbiamo lavorato per sprint, con issue e milestone dedicate, allineandoci con weekly calls interne di coordinamento. Inoltre, abbiamo sempre partecipato agli allineamenti settimanali asincroni della community per portare la nostra prospettiva. Questo modello ci ha permesso di:

• scegliere priorità e “tagliare” ciò che non portava valore
• esplorare e approfondire diverse soluzioni, oltre alle contribuzioni
• definire e far evolvere i PoC in soluzioni riusabili
• mantenere un flusso costante di contribuzioni, nonostante la pressione dei progetti commerciali
• creare un ponte stabile tra lavoro tecnico e comunicazione.

In merito all’ultimo punto, infatti, un aspetto importante è stato il lavoro insieme al team marketing: Stefano Mainardi (CEO) e Alessandro De Vecchi hanno lavorato costantemente per raccontare Drupal, l’AI Initiative, e ciò che stavamo costruendo.

Perché l’open source funziona davvero quando si costruisce e si condivide.

Ambiente di sviluppo AI in Drupal: il nostro add-on DDEV per abbassare la barriera all’ingresso (DDEV development environment)

La prima grande sfida che abbiamo affrontato è stata infrastrutturale. A giugno, all’inizio della Drupal AI Initiative, contribuire allo sviluppo era complesso e rallentato da un fondamentale collo di bottiglia in termini di Developer Experience (DevEx).

La nostra prima grande contribuzione è stata quindi unambiente di sviluppo basato su DDEV, pensato per rendere replicabile e veloce il setup locale, e per permettere di lavorare su più moduli contemporaneamente senza impazzire.

Più nel dettaglio, il problema principale era la complessità nel configurare un ambiente di sviluppo locale per lavorare efficacemente in un contesto come quello di Drupal AI, in cui occorre lavorare e testare simultaneamente più moduli. La gestione delle dipendenze era decisamente poco flessibile (con il rischio di doverle reinstallare ogni volta), solo un progetto per volta poteva essere clonato (rendendo necessari tanti git clone manuali quando si doveva lavorare su più moduli) e la necessità di dover aggiungere (e mantenere) alcuni file di configurazione specifici di DDEV rendevano tutto tedioso e poco scalabile.

Il nostro impegno si è rivolto quindi ad abbassare queste barriere all’ingresso e accelerare il ciclo di innovazione per l’intera community, fornendo agli sviluppatori un ambiente locale di sviluppo AI pre-configurato e funzionante in brevissimo tempo.

La nostra strategia si è evoluta in due fasi, con una soluzione generale ed una specializzata. Il primo passo è stata la proposta di un nuovo add-on DDEV (DDEV Drupal Suite add-on) , uno strumento generico che può essere usato da qualunque modulo contrib, semplifica drasticamente il setup e rende snella la contribuzione a più moduli contemporaneamente.

Sulla base di questo, abbiamo sviluppato prima una “Drupal recipe” (AI Dev Recipe) che installa e configura un set minimo di moduli AI, quindi anche un wizard interattivo via CLI (DDEV Drupal AI Add-on) che orchestra l’intera configurazione delle funzionalità AI, gestisce automaticamente dipendenze, config e install, e risulta anche facilmente estensibile con semplici istruzioni YAML.

Inoltre, lo sviluppo è continuato per rendere la soluzione ancora più flessibile, ad esempio includendo il supporto per database vettoriali pronti all’uso (PostreSQL, pgvector), ma anche il supporto opzionale per scenari ad alte prestazioni (Milvus) e per strumenti di quality assurance (GrumPHP).

Oggi, questa soluzione è utilizzata dalla community globale ed è rintracciabile come add-on. In parallelo, per agevolare ulteriormente l’adozione, abbiamo anche proposto di trasferirla nel namespace ufficiale di DDEV, così da renderla lo standard assoluto per lo sviluppo AI in Drupal. È stato uno dei nostri primi contributi, ma ha gettato le basi per tutto il resto.

Perché questa contribuzione conta anche per il business? Perché quando l’AI entra in un CMS enterprise, l’impatto è tanto funzionale quanto organizzativo. La velocità con cui un team può fare test, fix, iterazioni e release determina il vero time-to-market. E un ambiente di sviluppo standardizzato è spesso un primo, potente moltiplicatore di produttività.

Guardrails: portare sicurezza, governance e controllo nell’AI di Drupal

Ogni volta che parliamo di AI in produzione, prima o poi arriviamo qui: fiducia.

L’AI può creare contenuti, riassumere, classificare, orchestrare azioni, chiamare tool esterni. Ma può anche “allucinare” (con grande sicurezza), deviare da policy aziendali, esporre dati sensibili, generare output non sicuri o non appropriati.

Pensa ad esempio: come possiamo garantire che un chatbot non fornisca risposte inappropriate, suggerendo il prodotto di un competitor, offendendo l’utente o inventando informazioni false? E come possiamo impedire che dati sensibili (PII) vengano inviati a provider terzi (tramite i nostri prompt, oppure tramite informazioni raccolte da agenti autonomi)?

I rischi sono reali e, nel mondo enterprise, un’AI che “allucina” o che risponde in modo inappropriato non è solo un bug, è un rischio reputazionale inaccettabile. E se condivide dati sensibili, è una violazione ancora più grave. Mentre molti si concentravano sulla generazione di testo, noi ci siamo concentrati sul controllo.

Per questo, abbiamo lavorato nella definizione dei cosiddetti “Guardrails”, delle regole intelligenti che controllano e guidano il comportamento dell’AI, effettivamente limitandola per far si che rispetti indicazioni, valori ed obiettivi di ciascuna realtà.

Nella nostra visione, i guardrails non sono opzionali : sono un requisito strategico per rendere l’AI deployable in contesti reali.

Definizione dei guardrails in Drupal AI

La contribuzione di Luca su questo fronte è stata sostanziale, a partire dalla definizione stessa del concetto di Guardrails in Drupal (che ha rivelato un’ampiezza molto maggiore di quanto inizialmente ipotizzato).

• I guardrails sono infatti necessari come layer trasversale per tutte le interazioni con gli LLM : moduli, agenti, chatbots, generatori di contenuti, ecc. Importante, i guardrail sono essenziali anche per rendere sicure le comunicazioni con altri sistemi esterni , proteggendo lo scambio di parametri e dati sensibili, come quelli gestiti tramite MCP.

• Devono analizzare sia l’input dell’utente e sanitizzare i dati prima che arrivino all’LLM (es. rimuovendo dati personali o bloccando topic vietati), sia l’output dell’AI , analizzando la risposta prima che venga mostrata all’utente.

• In caso di check fallito un guardrail può bloccare completamente l’esecuzione di una richiesta (“Scusa, non posso rispondere per violazione delle policy”) o riscrivere input/output rimuovendo i dati problematici (“Ecco la risposta omettendo le informazioni personali”).

• Un singolo filtro non è tipicamente sufficiente. Serve piuttosto un “Set di Guardrails ” che operano in contemporanea, ognuno specializzato su diversi tipi di controlli (es. uno dedicato alle informazioni personali, uno ai contenuti vietati, uno dedicato ai permessi utente).

La nostra contribuzione è culminata con la creazione di una nuova architettura a plugin per gestire i guardrails. La soluzione è altamente personalizzabile: non solo supporta la configurazione dei singoli guardrails, ma anche la possibilità di combinare più controlli in diversi set.

Sono supportati sia controlli sugli input degli utenti (controlli “pre-LLM”), sia sull’output dell’AI (controlli “post-LLM”), ed è possibile definire check diversi nelle due fasi, per esigenze differenti. Non da ultimo, sono implementati guardrails di due tipologie distinte: di tipo deterministico (regex) e di tipo non deterministico (LLM-based topic detection).

Per i decision-maker, il valore di questo contributo è immenso: i guardrail trasformano Drupal AI da un promettente esperimento tecnologico a una piattaforma affidabile, sicura e pronta per l’impresa, in cui l’AI lavora sempre per il business, e mai contro di esso.

Supporto per Bedrock e sovranità dei dati

Durante gli esperimenti abbiamo esplorato le principali soluzioni di Guardrails già presenti, con un particolare focus su AWS Bedrock, una delle soluzioni più potenti sul mercato.

I nostri testi hanno confermato l’ottima compatibilità con moltissime lingue (compreso l’italiano), in particolare delle funzioni di PII masking, guardrails specifici per la rimozione di informazioni personali senza bloccare l’esecuzione.

Ma è importante raccontare la realtà con onestà: un servizio esterno (extra-europeo) introduce implicazioni di privacy, interrogativi di compliance e dipendenza tecnologica (vendor lock-in).

Tali preoccupazioni sono particolarmente rilevanti in contesti regolamentati (o nella PA), in cui va valutato seriamente quali dati sono trasmessi all’esterno, come vengono trattati, quale rischio residuo resta.

Per questo, pur supportando Bedrock, la nostra architettura è pensata per essere agnostica. Permette di integrare in futuro altre soluzioni (come Azure, Google Cloud, Guardrails.ai) e, alternativa molto interessante, anche modelli locali, per garantire la sovranità dei dati.

Streaming, guardrails, evoluzioni

Un altro punto tecnico che abbiamo affrontato è la complessità dei guardrails in presenza di risposte in streaming , ovvero quando l’AI invia ogni pezzo della risposta man mano che la genera, e non solo l’output completo alla fine della generazione.

Per l’esperienza utente, lo streaming è una feature decisamente apprezzata. Tuttavia, in presenza di streaming non è sufficiente eseguire un check finale dell’output, perchè l’utente potrebbe già essere stato esposto a informazioni non idonee. Piuttosto, il controllo dei guardrails va effettuato ad ogni aggiornamento della risposta da parte dell’LLM (ad ogni nuovo token di output).

Validare output token-by-token, gestire tool call nel flusso e contemporaneamente attivare set di guardrails ad ogni aggiornamento è un tema non banale.

La soluzione temporanea è stata disabilitare lo streaming quando i guardrails sono attivi , in attesa di un approccio più robusto. È un dettaglio importante per l’usabilità, passando da soluzione “sicura” a “sicura e piacevole da usare”.

E c’è un altro fronte che nel 2026 dovrà essere affrontato: guardrails per contenuti multimediali (immagini, video). È un tema ancora da approfondire, ma sappiamo già che non potrà essere lasciato alla buona.

AI Agents in produzione: task asincroni e streaming con Symfony Messenger (per superare i limiti di PHP)

Gli Agenti AI sono tutt’altra entità rispetto ai semplici chatbot di una volta. Un agente complesso pianifica, esegue step multipli, chiama tool, gestisce errori, interroga database, elabora dati. Insomma, gli Agenti richiedono tempo per “ragionare”, con processi che possono durare anche diversi minuti.

Ed è qui che il classico modello sincrono di una web request PHP mostra i suoi limiti: timeout, sessioni che si chiudono, UI che interrompe l’esecuzione, difficoltà di retry/monitoraggio.

Il problema è quindi: come facciamo girare agenti complessi su un sito Drupal, senza che la pagina vada in timeout? Un problema reale, emerso anche su un progetto per un nostro cliente.

Per rispondere a questo limite, abbiamo sviluppato una soluzione ed un PoC di “AI Agent Runner” basato su Symfony Messenger, con due obiettivi chiari:

1. esecuzione asincrona di task agentici (robusta, retryable, monitorabile), disaccoppiando l’esecuzione dell’agente dalla richiesta web dell’utente.
2. streaming delle risposte verso il frontend quando serve un’esperienza conversazionale fluida, continuando a supportare l’esecuzione sincrona con (quasi) lo stesso codice.

Questa contribuzione è stata anche portata in un contesto pubblico: un webinar tecnico organizzato insieme al team che coordina la Drupal AI Initiative, in cui Luca ha mostrato come Symfony Messenger possa diventare un pezzo chiave per superare i limiti architetturali di Drupal e PHP quando si parla di agenti.

Per un decision maker, il punto è molto semplice: con la sola esecuzione sincrona, gli agenti restano prototipi belli ma limitati e fragili. Con un’architettura asincrona, l’automazione può diventare complessa e affidabile.

RAG e Typesense

Uno dei modi più rapidi per perdere fiducia nell’AI è chiederle qualcosa che dovrebbe sapere… e vedere una risposta plausibile ma sbagliata. La RAG (Retrieval-Augmented Generation) nasce per questo: ancorare le risposte a una base di conoscenza reale e controllabile.

SparkFabrik è storicamente maintainer del modulo Search API Typesense, cosa che ci ha conferito esperienza profonda sia sulla ricerca “classica”, sia sull’evoluzione verso la ricerca semantica e i database vettoriali. Con l’avvento dell’AI, era naturale per noi evolvere questo strumento.

Roberto Peruzzo ha lavorato sull’implementazione del supporto Typesense per la RAG nel modulo AI, con un approccio che punta a migliorare pertinenza ed efficienza.

Uno degli elementi più interessanti che abbiamo introdotto è il concetto di “Router Agent”, un sub-agent che determina “dove cercare”. In un sistema complesso con molti indici (es. Manuali Tecnici, Blog, Prodotti), interrogare tutto è inefficiente. Dato un input dell’utente, l’agente principale attiva il sub-agent per selezionare la collezione più pertinente da interrogare su Typesense (in base all’intento), prima di formulare la risposta finale.

Questo riduce il “rumore” (dati irrilevanti inviati all’AI) e le allucinazioni, abbassa i costi dei token e aumenta drasticamente la precisione delle risposte. In più, il routing dinamico evita di dover hardcodare la mappatura delle collezioni ed aggiungere nuove collections non richiede nuovo codice.

Insomma, si ottiene un’esperienza utente migliore, codice scalabile ed un risparmio economico.

MCP: Drupal che diventa contesto e toolchain per gli agenti

MCP (Model Context Protocol) è uno dei “pezzi” che rendono Drupal dialogante con sistemi, strumenti e agenti esterni in modo standardizzato. È una delle prossime grandi frontiere, e nel 2025 abbiamo lavorato e contribuito su MCP in più fasi.

Esplorazione e direzione

Siamo partiti con un’esplorazione dello stato dell’ecosistema Drupal MCP: capire cosa era già possibile fare, cosa mancava e dove avesse senso investire per generare valore anche per i nostri progetti reali. In questa fase abbiamo anche ipotizzato l’uso di JsonAPI tramite MCP per costruire frontend disaccoppiati.

PoC: generare un frontend React via JSONAPI + Tools

Dopo l’esplorazione, abbiamo realizzato un esperimento più concreto con l’obiettivo di testare l’efficacia dell’approccio ed il potenziale del protocollo: creare un’app React completa tramite un AI connessa al server MCP di Drupal, in grado di leggerne struttura e contenuti (content types, campi…).

Realizzato tramite un prompt molto dettagliato e suddiviso in diverse fasi (“spec-driven development”), l’esperimento è stato un successo: ha dimostrato che Drupal può esporre la sua struttura (“intelligenza”) a sistemi esterni, permettendo all’AI di agire non solo come generatore di testo, ma come sviluppatore junior guidato dal contesto del CMS (e supervisionato).

Brainstorming su use case concreti e lavoro in corso

Successivamente abbiamo fatto un brainstorming interno per definire use case solidi e ripetibili, per stakeholder diversi. Ne sono emersi due:

• per Drupal developer: partire da un modello SDC e generare entità, paragrafi e campi via MCP
• per frontend developer/site builder: costruire un frontend disaccoppiato usando solo il server MCP

Abbiamo scelto di approfondire il primo use case, oggi ancora in corso con l’esplorazione sull’automazione della generazione della struttura backend a partire da template SDC.

Migliorare MCP in Drupal e diventare maintainer

Parallelamente, abbiamo anche contribuito direttamente al miglioramento dell’implementazione di MCP in Drupal.

Roberto è diventato maintainer del modulo Drupal MCP Client, modernizzandolo per supportare la nuova Tool API e migliorando la sicurezza con il supporto per gli header di autenticazione (come bearer token). Non da ultimo, Roberto ha contribuito anche con bugfix al modulo Drupal MCP per rendere Drupal un server MCP.

Perché MCP conta anche per chi guarda al business? Perché è una tecnologia “abilitante”. È ciò che permette agli agenti di non essere solo interfacce conversazionali, ma operatori che sanno usare strumenti, interagire con API, eseguire azioni e automatizzare processi.

Integrazione Lara Translate: traduzioni AI enterprise, multi-lingua di qualità

La traduzione è uno dei casi d’uso più immediati e concreti dell’AI nei sistemi di contenuto enterprise: siti multi-country, cataloghi, knowledge base, documentazione, compliance.

Parallelamente ai lavori infrastrutturali, SparkFabrik ha risposto ad un’esigenza cliente specifica sviluppando il modulo TMGMT Lara Translate. Lara è un modello AI specializzato nei task di traduzione, con output qualitativamente superiori agli LLM generalisti (ChatGPT, Gemini, Llama…) e mantenendo coerenza lessicale e stilistica.

Il modulo integra Lara come translation provider all’interno del sistema TMGMT (Translation Management Tool) di Drupal, supportando tutte le features uniche di Lara e con attenzione anche a dettagli pratici come lo splitting efficace del testo e logiche di gestione degli errori.

Un aspetto interessante è che questa contribuzione ha anche innescato un contatto diretto, aprendo opportunità di collaborazione e dimostrando come le esigenze di progetto possano trasformarsi in contribuzioni di valore per la community.

Oltre il codice: divulgazione e community

Contribuire non significa solo scrivere codice. Significa anche raccontare : spiegare cosa stiamo facendo, cosa è pronto, cosa è in evoluzione, e soprattutto perché vale la pena investire. Nel 2025, siamo davvero fieri del lavoro corale tra team tecnico e marketing per tradurre il nostro lavoro in cultura condivisa.

Content: Drupal AI Logs e articoli blog

Abbiamo raccontato alcune delle contribuzioni anche sui nostri canali social tramite la serie Drupal AI Logs, rendendo trasparente il processo contribuzione, trasformando update tecnici in insight fruibili e (speriamo) ispirando altri contributors e teams a sperimentare.

Un grande effort è stato dedicato anche nella produzione di articoli blog dedicati a Drupal e Drupal AI (anche nel tech blog), condividendo le nostre prospettive e promuovendo l’ecosistema del nostro CMS preferito (nel solo 2025 abbiamo condiviso ben 13 articoli verticali su Drupal).

DrupalCamp Italy 2025: due talk, due prospettive complementari

A novembre 2025, non abbiamo solo contribuito all’organizzazione di DrupalCamp Italy. Abbiamo anche portato la Drupal AI Initiative sul palco, con due talk che, insieme, raccontano bene il nostro approccio.

• Lo stato della Drupal AI Initiative.
  Luca Lusso ha condiviso lo stato complessivo dell’iniziativa ed alcune nostre contribuzioni, offrendo una visione da insider, realistica e priva di hype. L’obiettivo: ispirare la community italiana e promuovere l’iniziativa. (Registrazione del talk e slides).
• Agenti AI in Drupal e MCP (con PoC)
  Roberto ha mostrato come implementare agenti AI in Drupal, sia via UI sia via codice. Nel talk ha mostrato un PoC di AI Customer Assistant per e-commerce : un agente che conversa con l’utente, cerca prodotti, suggerisce opzioni, aggiunge al carrello e notifica eventi in Slack tramite MCP. (Registrazione del talk e slides).

Webinar tecnico: AI Agents on Symfony Messenger per agenti AI “robusti”

Come accennato sopra, abbiamo contribuito anche a un webinar tecnico internazionale , organizzato con il team che sta coordinando la Drupal AI Initiative (James Abrahams e Marcus Johansson).

Luca ha mostrato il suo PoC basato su Symfony Messenger, mostrando agenti in grado di eseguire task asincroni e di supportare lo streaming dei messaggi (anche in caso di invocazione di tools).

L’obiettivo era mostrare come SM possa diventare un pezzo chiave per superare i limiti architetturali di Drupal e PHP quando si parla di agenti. Interessante, nello stesso webinar è stata condivisa una seconda demo incentrata su FlowDrop e sono intervenuti altri esponenti della community per partecipare alla discussione.

Un extra che nasce dall’iniziativa: workshop su GitHub Copilot

Nel percorso di studio e R&D legato alla Drupal AI Initiative, abbiamo anche investito nella formazione e condivisione su strumenti di sviluppo AI, come GitHub Copilot.

Abbiamo condiviso la nostra esperienza in un workshop tecnico e pratico tenuto da Luca Lusso, per spiegare nella pratica come integrare Copilot come partner nel ciclo di sviluppo in VS Code.

Il workshop Copilot è gratuito e liberamente accessibile, non verticale su Drupal ma volutamente più aperto al mondo dello sviluppo.

Un anno di innovazione e prospettive future

Il 2025 si è chiuso con un bilancio estremamente positivo per l’ecosistema Drupal, un anno di costruzione in cui SparkFabrik ha contribuito a posare i mattoni fondamentali: un ambiente di sviluppo solido, un framework di sicurezza (Guardrails), un motore di esecuzione robusto (Async Runner su Symfony Messenger) e protocolli di interoperabilità (MCP).

Sotto la guida del nostro CTO Paolo Mainardi, le nostre contribuzioni si sono concentrate su ambiti a grande valore aggiunto e su nodi critici da sciogliere per portare l’AI in progetti reali dei clienti , con forte accento su governance e sicurezza, agenti AI autonomi in grado di compiere azioni complesse (da site building a configurazione).

Abbiamo anche riconosciuto (e promosso) la necessità di supportare stack completamente open source e locali (agnosticismo tecnologico), anticipando le esigenze di sovranità digitale e privacy dei dati richieste dai clienti enterprise europei, soggetti a normative come GDPR, AI Act e Cyber Resilience Act).

Riepilogo delle principali contribuzioni tecniche 2025 (Drupal AI)

Area | Contribuzione Principale | Impatto / Risultato
Infrastruttura | Ambiente di sviluppo unificato DDEV | Standardizzazione del setup per tutti i contributori globali.
Sicurezza | Guardrail Agents Architecture | Framework per la sicurezza degli input/output AI, visualizzabile e configurabile.
Performance | AI Agents su Symfony Messenger: Async Runner & Streaming | Esecuzione di agenti complessi senza timeout, esecuzione sincrona e asincrona, UX reattiva grazie allo streaming in tempo reale.
Ricerca | RAG e Router Agent | Sistema intelligente per indirizzare le query all’indice corretto, riducendo costi e rumore.
Interoperabilità | Drupal MCP Server & Client | POC per la generazione di frontend React da Drupal via AI con MCP; modernizzazione del client MCP.
Localizzazione | TMGMT Lara Translate Provider | Integrazione di servizio di traduzione professionale nel flusso editoriale Drupal.

Guardando al 2026, la nostra visione è chiara. Drupal non è più “solo un CMS”. Si sta posizionando come la piattaforma ideale per l’Enterprise AI : un luogo dove i dati sono strutturati, sicuri e accessibili, e dove l’intelligenza artificiale non è un giocattolo solo per “effetto wow”, ma uno strumento governato da regole precise di compliance e sicurezza. È esattamente il tipo di AI che serve per la produzione, non per le demo.

SparkFabrik continuerà a essere in prima linea. Non ci limiteremo a usare l’AI; continueremo a scrivere il codice che la rende possibile, aperta e sicura per tutti, per progetti reali.

In SparkFabrik, combiniamo una profonda expertise tecnica su Drupal con competenze avanzate in AI integration, architetture composable e governance enterprise. I nostri servizi di sviluppo Drupal coprono l’intero spettro: da consulenza strategica sull’AI readiness della tua architettura attuale, a implementazione di soluzioni AI-powered custom, fino a sicurezza, supporto continuativo e ottimizzazione.

Se stai valutando come integrare AI in Drupal (o in un ecosistema enterprise più ampio), e vuoi farlo con un partner che ci ha messo le mani davvero (a livello di prodotto, di community e di delivery) parliamone.

Questo articolo è parte della nostra serie dedicata a Drupal. Per esplorare altri aspetti della piattaforma, vi invitiamo a consultare i nostri precedenti articoli su caratteristiche e vantaggi, confronto con le alternative, strategie di migrazione, sicurezza e compliance, architettura composable, Design System, Drupal headless omnicanale e panoramica e novità di Drupal AI.

Abbiamo passato quattro giorni alla DrupalCon Vienna 2025 (14-17 ottobre) seguendo oltre venti sessioni tecniche, workshop e BOF. Il messaggio più forte? Drupal non sta rincorrendo tendenze ma consolidando una leadership tecnica in tre aree critiche: AI enterprise-grade con governance reale, Canvas come primo CMS “design system native”, e maturità operativa per progetti a scala.

Questo non è un report di marketing ma un resoconto pratico di cosa abbiamo visto funzionare in produzione, quali problemi rimangono aperti, e dove dovresti investire attenzione nei prossimi sei mesi. Per team italiani che pianificano progetti 2026, ci sono decisioni da prendere adesso, non dopo.

Ottobre a Vienna ha quel freddo secco che rende tutto più nitido. Perfetto per quattro giorni di immersione totale in quella che si è rivelata una delle DrupalCon più dense di contenuto tecnico degli ultimi anni. Non è stata una conferenza di annunci sensazionalistici, ma di demo funzionanti e problemi risolti sul campo, nonché quella rara combinazione di visione strategica e pragmatismo operativo che distingue le community mature da quelle in fase hype.

Tutti i video delle sessioni saranno presto disponibili nella playlist ufficiale DrupalCon Vienna 2025.

Il keynote di Dries Buytaert ha dato il tono: quattro pilastri (Canvas, AI, Orchestration, Site Templates, Marketplace) e una dichiarazione netta. L’AI è una tecnologia destinata a rimanere , indipendentemente dal fatto che la bolla finanziaria prima o poi esploderà. Drupal è uno dei CMS open-source meglio posizionati per sfruttarla. Niente difensivismo, niente “anche noi abbiamo l’AI”, ma roadmap implementativa strategica e chiara.

Quello che ci ha colpito di più? La distanza tra annunci e realtà era minima. Canvas non è vaporware: è in alpha funzionante con agenzie che stanno già facendo pilot con clienti reali. L’AI non è un chatbot appiccicato: è architettura pensata per governance enterprise con observability production-grade. I site templates hanno superato la fase di concept: i primi sono già qui.

Organizziamo questo report per aree tematiche, non per cronologia. Quello che conta non è “cosa è stato detto martedì” ma “cosa cambia per i tuoi progetti del 2026”.

Canvas: demo vera, risposte vere

Drupal Canvas (il nuovo nome di Experience Builder) è il nuovissimo builder visuale di Drupal che promette di semplificare e snellire il modo in cui disegniamo e costruiamo le pagine in Drupal. Ne abbiamo già parlato nel nostro articolo sulle innovazioni di Drupal CMS 2.0 e nella panoramica completa su Drupal AI, in cui abbiamo analizzato l’architettura e il posizionamento strategico. A Vienna abbiamo visto cosa significa portarlo in produzione, e soprattutto dove ci sono ancora gap.

La sessione “Drupal Canvas Unleashed” ha fatto sold-out con oltre 400 partecipanti. Il messaggio chiave: Canvas combina Single Directory Components (SDC) e blocks come componenti “backend”, ma con Canvas non serve più sapere come funzionano una volta che sono stati sviluppati.

I settings in Canvas sono le properties degli SDC, mentre in un pannello a sinistra si controllano gli slots, una nuova “entità” che permette di gestire l’alberatura dei componenti in layers, potenzialmente concatenati l’uno dentro l’altro. Inoltre, nelle configurazioni del theme c’è un setting per lasciare che Canvas gestisca le global regions come header e footer, importandole in pochi click in ogni nuova pagina. Davvero efficace ed intuitivo: chi conosce Figma o altri builder visuali come Framer e Webflow si ritroverà in un ambiente molto familiare.

Ma la feature più interessante? I Code Components , che supportano la scrittura di componenti React direttamente nel browser. Questi componenti possono utilizzare elementi e CSS components definiti in Canvas, supportano anche props per aggiungere dati dinamici (ad esempio, un titolo). In più, è anche possibile fare query tramite JSON:API per costruire componenti dinamici che recuperano dati dal backend.

Cosa funziona già:

• Content Templates per definire layout di content type strutturati (perfetto per landing pages)
• Global regions e componenti riutilizzabili
• AI (in beta) che permette di costruire code component direttamente via prompt
• Views supportate nativamente

Gap ancora aperti:

• Paragraphs e layout sono ancora work in progress
• Alcuni moduli contrib che funzionano solo su node non sono compatibili
• Alcuni contrib field type non funzionano ancora
• Multilingua non è supportato completamente
• Server-side rendering non è implementato (bloccato da implicazioni di security, non è assicurato supporto per qualunque server providers)
• API per estendere Canvas (non solo in termini di integrazione di moduli, ma anche di web apps embeddate in Canvas) ed offrire esperienze utente veramente ricche
• Sistema di permessi standard (ad es. per creare nuovi componenti o per usarne di esistenti)

La sessione “Strategies for Integrating Drupal Canvas in Your Existing Platform” ha dato indicazioni pratiche. Canvas crea un nuovo content type “canvas pages”, quindi moduli che lavorano solo su node potrebbero avere problemi di compatibilità. Canvas è una React app sul frontend, la compilazione e il rendering nell’editor avvengono nel browser in real time.

Per sviluppatori frontend la sessione “JavaScript Frontend Development with Drupal Canvas: Beyond Decoupling” ha mostrato workflow avanzati. È possibile sviluppare componenti JS esterni e sincronizzarli con utility dedicate. C’è un workflow bidirezionale per passare da Drupal a Storybook e viceversa. Canvas supporta l’aggiunta di CSS globale per il preview. Ogni componente passa dati a Drupal, il componente è renderizzato con nuxt client-side, e i componenti esterni sono standard Vue component.

Takeaway pratico: Se stai pianificando progetti Drupal per Q1-Q2 2026, Canvas è production-ready (rilascio stable novembre 2025, default in Drupal CMS 2.0 da gennaio 2026). Nel budget è fondamentale tenere in considerazione il tempo per lo sviluppo di component library, più che per l’implementazione di singole pagine. Il ROI è immediato per team con alto volume di page creation.

Design System nativo: finalmente un CMS che capisce il design

La sessione “Drupal, the first design-system native CMS” di Pierre Dureau (Beyris) ha presentato un cambio di paradigma che merita attenzione.

Infatti, in Drupal i theme presentano dei problemi storici non indifferenti : non sono condivisibili (un theme è per un progetto specifico), non sono plug-and-play (c’è sempre un template mancante), hanno una DX poco friendly.

La soluzione proposta: business agnostic coding. Come per il backend, il frontend deve essere disaccoppiato dal business tramite plugin, ovvero, un design deve essere concepito in modo agnostico da business e brand. Qui entrano i design system ben strutturati, che abilitano un grande punto di forza: “un design, molti prodotti”.

E Drupal è un ecosistema che riesce in modo particolarmente efficace a sfruttare appieno un design system , in quanto un design strutturato, organizzato e ben descritto è un design che Drupal può comprendere ed usare facilmente (ne abbiamo parlato anche nel nostro recente articolo Design System e Drupal CMS).

In modo davvero interessante, nel talk viene introdotto un metodo che propone un’inversione del workflow Drupal tradizionale (site builder / backend dev → templates → frontend dev). Al contrario, ora è il frontend developer che fornisce plugin frontend modulari, e questo implica anche ownership per il frontend developer e YAML come strumento di lavoro principale.

Più di un mero esercizio stilistico, a supporto di questo metodo, di questo shift, ci sono funzionalità concrete già disponibili direttamente nel core di Drupal:

• breakpoints.yml per breakpoint images
• layouts.yml per layout grid system (layouts in Layout Builder)
• SDC per UI components
• icons.yml per icon packs

Certo, la copertura delle features è ancora piuttosto limitata. Tuttavia, in arrivo in Drupal 11.3 e 11.4 ci saranno importanti nuovi endopoint API dedicati al design, che permetteranno di alzare decisamente l’asticella e separare ulteriormente il theming dalla app di Drupal:

• Styles API con Utilities & Helpers (set di attributi HTML mutuamente esclusivi, auto-descrittivi, single-purpose e universali come Typography, Borders, Colors, Spacing, Elevation) e Themes & Modes (switch di branding predefinito, color scheme, accessibility settings)
• Design Tokens API con scoped values disponibili per override locali o globali, che diventano variabili CSS solo a runtime

Nonostante rimangano ancora diversi gap, questo talk pone l’accento su un obiettivo ambizioso ma realizzabile per la prima volta nella storia di Drupal: la possibilità di un design workflow completamente automatizzabile, dalla fase di design in Figma al rendering finale nel browser.

Ma non è stato l’unico talk focalizzato sulla coppia vincente Design System + Drupal. Davvero di rilievo è la sessione sul design system scalabile multi-brand di Nestlé, che ha mostrato un’implementazione reale. In questo caso studio si è parlato di riorganizzazione e progettazione del design system su tre livelli: core, ui components, brand overrides.

Questa struttura si è rivelata fondamentale tanto per gestire la complessità di decine di brand diversi, quanto per dare una coerenza complessiva all’ecosistema di brand. Il sistema di theming Drupal basato su starterkit ha garantito deploy rapidi, update efficienti, e possibilità di istanziare nuovi siti in giorni invece che settimane. Ora, oltre 100 siti sviluppati in Drupal adottano questo approccio.

Takeaway pratico: Se stai costruendo o ripensando il tuo design system, considera approccio “design system first” invece che “Drupal theme first”. L’investimento iniziale è maggiore ma la scalabilità e manutenibilità sono ordini di grandezza migliori. Per organizzazioni multi-brand è praticamente obbligatorio.

Accessibilità digitale: EAA e AI

Uno dei vantaggi principali di un design system è l’ottimizzazione e la coerenza dell’esperienza utente. Ma oggi, il design system è anche uno strumento strategico per essere conformi all’European Accessibility Act. Due talk hanno affrontato il tema dell’accessibilità, ed in particolare la sessione “AI in EAA” ha esplorato come l’AI possa supportare compliance con gli standard di accessibilità, sempre più critici con l’EAA in vigore da giugno 2025.

L’AI può accelerare QA teams (crawling automatici), content editor (sommari, alt-text automatici, text editors intelligenti), designers (analisi colori e contrasti, object recognition, suggerimenti proprietà e stati ARIA) e developer (linting tools, IDE extensions, autocomplete per creare componenti accessibili) nell’intercettare problemi di accessibilità.

Tuttavia, non può sostituire il vero testing umano. Anche in quest’ambito infatti, è fondamentale mitigare i rischi di eccesso di fiducia nell’AI, mantenendo la supervisione umana per superare limiti e bias dei tool automatici, come particolarità culturali e linguistiche e la sensibilità culturale, particolarità linguistiche e interpretazioni errate del contesto.

Fondamentale è in ogni caso la comprensione della tematica dell’accessibilità , non più un elemento accessorio, ma tanto un obbligo quanto un’opportunità per il business. Abbiamo approfondito il tema in due risorse chiave: il whitepaper Accessibilità e Design System e la checklist operativa all’accessibilità.

Takeaway pratico: Per molte organizzazioni, l’accessibilità non è ancora una priorità chiara. Tool automatici ed AI possono offrire un supporto significativo , ma l’educazione sui requisiti, la formazione interna, la comunicazione sono dei pilastri imprescindibili. Per essere davvero in regola, e per innestare davvero l’accessibilità nel DNA aziendale serve un approccio che integri l’accessibilità fin dalla progettazione: un metodo “design-to-code” che unisca interventi tecnici, formazione e cultura, che solo un partner specializzato può orchestrare.

AI Enterprise: governance prima di tutto

Abbiamo già scritto un articolo approfondito su Drupal AI analizzando features come generazione di contenuti, gestione del contesto, agenti autonomi e observability. A Vienna abbiamo visto implementazioni concrete e scoperto pattern che funzionano (e alcuni che no).

La sessione “The AI Agent Swarm has come to Drupal Canvas” ha mostrato integrazioni pratiche. Canvas template agent può costruire landing page intere assemblando componenti e l’AI beta configurata in Canvas permette di costruire code component via prompt (alcune impostazioni sono preconfigurate per accelerare l’adoption, ma è tutto personalizzabile).

La sessione ha anche esplorato come gli agents possano essere usati ovunque in Drupal per task piccoli o grandi , anche costruendo siti da zero con tool esterni via MCP (Model Context Protocol), tutto senza scrivere una riga di codice.

Per un utilizzo efficace degli LLM, “context is king”. Nel nostro precedente articolo, abbiamo esaminato la possibilità di definire un contesto per determinate azioni richiamabili tramite i Field Widget Actions. Questo sistema era ancora abbastanza macchinoso ed embrionale.

Un bel salto in avanti in tal senso è rappresentato dal Context Control Center , che permette di definire in modo centralizzato tutte le informazioni di contesto, come il proprio brand, persona e topic (in modo del tutto simile a quanto avviene in Claude Code o Copilot tramite files claude.md o agents.md, ma direttamente nella UI di Drupal).

Inoltre, la centralizzazione dei contesti permette una governance decisamente più efficace. I diversi contesti sono poi facilmente richiamabili ed utilizzabili dalle diverse features ed agenti AI di Drupal. Se vuoi approfondire il tema del Context Engineering, ti rimandiamo all’interessantissimo talk di Enrico Zimuel durante il nostro evento dedicato alla GenAI.

Pattern che funziona. AI per content generation con supervisione umana per l’approvazione (Human in the Loop): l’AI crea un draft, una persona revisiona e approva prima della pubblicazione. Questo approccio risolve il trade-off tra velocità e controllo, e si sposa con la filosofia di Drupal in cui l’AI potenzia le persone, non le sostituisce.

Pattern che non funziona ancora bene: Full automation senza supervisione umana. Anche con Context Control Center ben configurato, l’AI può generare contenuti che tecnicamente rispettano le linee guida ma hanno sfumature sbagliate che solo un umano può cogliere. La full automation rischia quindi di non essere in linea con il livello di qualità del brand e la supervisione umana è fortemente raccomandata.

Takeaway pratico: Investi in AI per accelerare execution (drafting, ricerca, assembly), non per sostituire decision-making strategico. Il Context Control Center è il differenziatore chiave: senza governance centralizzata, l’AI enterprise scala male e introduce rischi. Budget tempo per configurazione iniziale robusta del Context Control Center, non pensare sia “plug and play”.

DevOps e Release Management: lezioni dal campo

Alcune delle sessioni più dense di valore pratico erano su DevOps, CI/CD e release management: topics che fanno davvero la differenza tra progetti che scalano e progetti che collassano.

GitHub Actions + Docker + Cypress = CI/CD Nirvana

Nel talk viene descritta una configurazione ideale (il “CI/CD Nirvana”) per il processo di sviluppo: tool per sviluppo locale che automatizzano QA (grumPHP), visual regression test (BackstopJS), e2e test (Cypress), e audit di sicurezza. Questi stessi tool devono essere usati anche in CI per garantire rilascio di codice sicuro e senza regressioni.

Su GitHub questo è possibile con GitHub Actions. L’ideale è scrivere le proprie custom Actions, personalizzate per il caso d’uso specifico. In questo modo, i vantaggi ottenuti sono evidenti: eviti di utilizzare immagini Docker con software non necessario, puoi inserire tool specifici (es di debug), hai pieno controllo di cosa viene deployato.

Ma è imperativo prestare molta attenzione alle implicazioni di sicurezza. Le GitHub Actions possono agire anche su codice in production e bisogna quindi limitarne l’accesso, le chiavi ssh devono essere secretate, occorre molta attenzione alle Actions di terze parti e dump di database. Come sempre, è fondamentale programmare audit e verifiche regolari del codice.

Mastering the Release Flow: 5 anni di continuous improvement

Caso studio molto istruttivo che include una istanza Drupal che distribuisce contenuti a 5 React apps, 20 servizi esterni connessi, 40 paesi con fino a 3 lingue ciascuno (il multilingual era a dir poco essenziale in questo progetto), 13.000 step di test distribuiti su 700 Behat feature files.

I test in particolare hanno seguito un approccio molto rigoroso: erano strutturati in aderenza alle user journeys identificate, separando production e non-production tests, funzionalità core e country-specific, runnando tutte le notti. L’obiettivo? Identificare bugs ed anomalie prima degli utenti (e del cliente).

Nonostante la meticolosità, alcuni problemi emergenti hanno reso evidente che non era comunque sufficiente. In particolare i problemi incontrati dal team sono:

• Behat non è più sviluppato attivamente
• L’estensione Mink ha avuto a lungo un bug critico per le ultime versioni di Chrome (non fixato per 3 mesi)
• I test notturni su AWS duravano ormai più di 8 ore

Per superare questi limiti, il team ha creato un nuovo framework chiamato Cuppet che combina Cucumber (per non riscrivere i test) e Puppeteer (mantenuto attivamente da Google), basato su NodeJS.

I nostri takeaways da questo case studies?

• Se è “doloroso”, automatizzalo o risolvilo
• L’eccellenza operativa non è opzionale
• Make it work → make it right → make it fast (in quest’ordine, in questo caso studio il processo è durato ben 5 anni di miglioramenti iterativi)
• L’affidabilità è più importante delle nuove feature (cura il debito tecnico)
• Essere una “brava persona” è più importante delle skill tecniche, ancora di più in un mondo in cui tutti interagiscono con l’AI, ma in cui gli sviluppatori e gli utenti finali sono sempre persone.

Questo ultimo punto è emerso in diverse sessioni. Il keynote “Neurodiversity: An Underrated Superpower in Business” ha aperto il secondo giorno con discussione sulla neurodiversità e su come capacità peculiari di persone spesso messe in disparte possano portare contributi preziosi a team e organizzazioni.

Testing in Era AI

La sessione “Test All the Things” ha sottolineato che con l’AI che genera sempre più codice, il testing assume importanza ancora maggiore. Gli LLM rendono il coding alla portata di chiunque, anche di chi non ha competenze pregresse, sviluppando un falso senso di sicurezza. L’affidamento crescente a questi tool aumenta la probabilità di difetti o comportamenti imprevisti difficili da individuare.

Molto interessante è la panoramica su diversi approcci al testing in ambienti differenti, ad esempio:

• Eseguire test in un ambiente che replica la produzione garantisce un’elevata fedeltà, ma è un processo complesso, con implicazioni legate alla privacy e tempi lunghi, soprattutto in presenza di database di grandi dimensioni
• Installare sito con contenuti di test risulta invece molto più rapido e gestibile, ideale per cicli di sviluppo e verifica più agili, a scapito necessariamente della fedeltà all’ambiente in produzione

La static code analysis (PHPStan, psalm) è strumento valido per prevenire bug e mantenere sotto controllo la qualità complessiva del codice. Il workflow descritto nel talk è molto simile a quello che adottiamo in SparkFabrik , confermandone quindi la qualità, con la differenza che da quest’anno abbiamo adottato Symfony Panther per i behavioural tests, sostituendo Behat. Interessante anche l’accenno a Pa11y per l’analisi dell’accessibilità, strumento spesso sottovalutato ma di grande supporto per garantire conformità agli standard ed esperienze inclusive.

Takeaway pratico: Se stai adottando AI per la code generation, investi proporzionalmente di più in test automation e static analysis. Il codice AI-generated funziona spesso ma ha edge case inaspettati che solo test robusti cattureranno.

Security by Design: da requisito a cultura

In SparkFabrik, il tema della sicurezza ci sta particolarmente a cuore. Oltre ad essere un requisito normativo per molte aziende, la sicurezza è fondamentale per proteggere dati, fiducia degli utenti e reputazione online delle aziende.

La sessione “Secure by Design: Integrating Security into Drupal Development” ha presentato una valida overview sull’approccio “secure by design” , con indicazioni teoriche e pratiche delle strategie da mettere in atto per garantire la sicurezza di siti e portali sviluppati in Drupal, dai requisiti di business fino alle implementazioni tecniche.

L’assunto di partenza: la Security deve essere intesa come core business requirement , non come “afterthought”.

Ed in Drupal, questo assunto è preso molto seriamente, con un Security team dedicato che pubblica regolarmente avvisi di sicurezza. A ottobre 2023 è anche partita la Security by Design Initiative nella community Drupal, supportata dalla Cybersecurity and Infrastructure Security Agency degli USA, assieme a partner internazionali, compresi Stati europei come Germania e UK.

Nel talk vengono condivide indicazioni pratiche (anche molto tecniche e specifiche), tra cui citiamo:

• Implementare la sicurezza fin dalla fase requirements
• Code review periodico con focus security
• Automated security scanning in CI/CD
• Penetration testing regolare per progetti critici
• Security training per tutto il team (non solo developer)

Da citare anche la sessione “Better Debugging with Xdebug”, in cui sono state presentate feature avanzate di debugging, comprese experimental features come “control sockets” per debuggare running processes, ed il concetto di “time traveling” per “andare indietro nel processo di esecuzione”.

Se vuoi approfondire i temi della sicurezza, guarda i nostri articoli sulla sicurezza e compliance con Drupal CMS, su Software Security e Cloud Security, sull’impatto di NIS2 e DORA nel Cloud Native (abbiamo anche creato una guida operativa completa).

Takeaway pratico: Per progetti enterprise, è importante mettere a budget tempo e risorse specifiche per attività di sicurezza (threat modeling, security testing, security reviews), idealmente un budget del 10-15% del tempo totale. Può sembrare tanto, ma è una frazione minima del costo di un security incident.

Marketplace e Site Templates: economics reali

Ryan Szrama di Centarro ha presentato “How to Sell Drupal Site Templates” con onestà rara.

Anzitutto, cosa è un site template? È una combinazione di Drupal CMS, tema front-end, eventualmente anche un tema per il back-end, recipes che forniscono funzionalità e dei contenuti predefiniti che, assieme, creano un’installazione di Drupal su misura per uno specifico scopo e permettono di avviare rapidamente un nuovo progetto. Pensa ad esempio ad un Template per aziende che offrono SaaS, oppure a un sito ecommerce: use cases con necessità specifiche che possono essere impacchettate.

Commerce Kickstart è proprio uno dei primi Site Templates disponibili. Da distribuzione Drupal, è stato convertito in site template, arricchito da recipes per eCommerce, con esperienza di checkout moderna, diverse opzioni di configurazione e semplificazione dell’installazione.

L’appeal dei Site Templates è abbastanza chiara: fornire una soluzione specifica ad un problema specifico. Anche dal punto di vista dell’offerta dovrebbe essere una strategia di vendita “migliore”, o almeno più immediata e diretta, rispetto ad un’idea di progetto, una “soluzione astratta”. Qui si innestano i punti più interessanti e pragmatici del talk: i punti critici e l’esperienza fino ad ora.

Tre sono i punti più critici :

• Nella pratica, come e dove pubblicare un site template? Attualmente infatti non c’è ancora un marketplace centralizzato su drupal.org, non c’è un sistema di gestione delle transazioni, e neanche di distribuzione dei files. Affinché i templates decollino, è fondamentale trovare una risposta operativa, evitando che si debbano gestire manualmente e individualmente gli acquisti.
• Come proteggere la proprietà intellettuale quando distribuisci l’intero prodotto come codice? Tema caldissimo, ed anche qui non vi è una risposta chiara.
• Ma il punto prioritario è: come convincere un cliente reale a comprare un Site Template? Il focus è su questo punto, testando la vendita sul campo. La value proposition su cui si sta facendo leva è il risparmio monetario e di tempo per il cliente finale, accettando però il trade-off di assenza di personalizzazione (prodotto “off the shelf”). Importante disclaimer, allo stato attuale non è stata conclusa ancora alcuna vendita (ai prospect non era chiaro cosa stessero comprando e le richieste viravano su necessità di coaching, personalizzazione, servizi dedicati).

Affinché la vendita dei Site Templates sia sostenibile, sono quindi fondamentali tre cose: un modo per distribuirli efficacemente, e comunicazione chiara su cosa include il pacchetto.

A riguardo, la sessione “Decision-making at Scale: Drupal Marketplace Process Behind the Scene” ha mostrato come un committee di 12 persone si è occupata di decidere se Drupal dovesse creare un marketplace per site templates (un processo durato 14 settimane). La risposta è positiva, con un rilascio graduale.

Nella pagina ufficiale della Drupal Marketplace Initiative, viene dettagliato il piano complessivo su Site Templates e Drupal Marketplace :

• entro DrupalCon Vienna, un pilot con il semplice rilascio di 1-2 templates;
• entro DrupalCon Chicago (Marzo 2026), rilascio di un MVP del Marketplace, con 10-15 templates, sia gratuiti sia a pagamento;
• inizialmente, i Site Template Makers saranno limitati ad alcuni Drupal Certified Partners selezionati, per poi espandere progressivamente ad altri makers;
• per i templates a pagamento occorrerà rispettare requisiti di pricing trasparente, garantire maintenance, avere termini di supporto chiari;
• l’MVP includerà esperimenti in termini di pricing models e di divisione delle revenues;
• si ipotizza che inizialmente il 10% dei ricavi andranno alla Drupal Association;
• in iterazioni future, il marketplace gestirà direttamente le transazioni e la divisione delle revenues potrebbe cambiare in 60% al creatore, 30% alla DA, 10% ad un fondo a supporto dell’ecosistema.

Takeaway pratico: Il marketplace lancerà ufficialmente nei prossimi mesi, e si evolverà gradualmente ma velocemente. Per agenzie, considera sviluppare template verticali (e-commerce, no-profit, education) per differenziarti. Il modello economico sta ancora emergendo ma il timing è ideale per early movers.

Orchestration e Architetture Composable

La sessione “From CMS to Platform: How to Build Future-Proof Digital Ecosystems with Drupal” ha presentato vision importante. Quando un cliente chiede un sito web, in realtà la richiesta nasconde spesso la necessità di un ecosistema digitale completo , composto di siti web, applicazioni, integrazioni con sistemi terzi per servizi specifici.

Nella Drupal Core Strategy pubblicata a luglio, Dries ha definito esplicitamente Drupal una “platform” perché parlare di CMS è ormai limitato. Drupal ha potenzialità per fungere da cuore di piattaforma digitale per svariati touchpoint.

In questo talk è stato portato anche un esempio, un progetto basato su NodeHive, ma l’architettura di base può essere generalizzata per qualunque piattaforma che sfrutti Drupal come unico backend headless, con un Orchestration layer che permetta di gestire i vari touchpoint.

Come abbiamo discusso nel nostro articolo su architettura composable, questo approccio è sempre più rilevante per organizzazioni che devono servire esperienze su web, mobile app, digital signage, voice assistant ed altro ancora, contemporaneamente e coerentemente.

In termini di orchestrazione dei workflow, un’importante novità è il supporto di Drupal in tool di automazione no-code / low-code come Activepieces (orchestration platform open-source con licenza MIT). Questo è stato annunciato durante il Driesnote ed approfondito nell’articolo dedicato di Dries.

Takeaway pratico: Non pensare più “sito Drupal” ma “Drupal come content hub”. Architetta fin dall’inizio per una content delivery multi-channel. Il costo iniziale è leggermente più alto ma la flessibilità futura è incomparabilmente maggiore.

Gestione del cambiamento di scope: l’arte di dire NO senza dire NO

Oltre ai talk tecnici, la sessione “Navigating Scope Creep” è stata particolarmente apprezzata dai project managers. Infatti, ha affrontato tema universale nei progetti software: lo scope creep , l’espansione incontrollata dei requisiti, delle funzionalità e dei deliverables di un progetto oltre quanto approvato inizialmente.

Tipicamente lo scope creep si manifesta durante alcune fasi: raccolta dei requisiti, feedback dei clienti, vicino al completamento del progetto (le modifiche all’ultimo minuto sono particolarmente rischiose), e quando cambiano gli stakeholders (ad esempio nuovi membri del team, che possono portare nuove idee).

Le cause principali? Obiettivi o requirements poco chiari, comunicazione inadeguata, desiderio di evitare il conflitto (probabilmente il problema più comune), ma anche framework normativi e di mercato in continua evoluzione.

Nel talk viene proposto un approccio chiaro: accetta il cambiamento dello scope, ma fallo in modo efficace. L’approccio si basa su tre pilastri:

1. Awareness: è fondamentale conoscere il progetto nel dettaglio, monitorare il comportamento stakeholder ed il processo di richiesta di modifica.
2. Allineamento: fin dalle prime fasi, occorre creare una visione condivisa degli obiettivi, allineare priorità, parlare di aspettative, formalizzare la documentazione sullo scope.
3. Processi chiari: implementa processi di Change Management chiari, non accettare richieste verbali, documenta richieste e decisioni, poni limiti chiari.
4. Evita incomprensioni: Comunica in modo aperto e trasparente (anche esprimendo il tuo disaccordo, motivandolo), coinvolgi il cliente nei test, spiega sfruttando wireframes e prototipi.

Ciliegina sulla torta: in conclusione sono state condivise quattro tattiche concrete.

• The alternative offer: possiamo lavorare sulla nuova richiesta, ma dovremo aggiustare la timeline e il budget.
• Priority shift: aggiungere la richiesta significa togliere qualcos’altro dal backlog, a cosa dobbiamo togliere priorità?
• Future release: pianifichiamo questa aggiunta per la fase due, dopo aver completato le funzionalità chiave.
• Data-driven approach: in base alla nostra analisi, questa aggiunta porterebbe poco valore, soprattutto se raffrontato al costo di sviluppo (se hai statistiche contro una feature, portale al tavolo).

Takeaway pratico: Investi nel formalizzare il Change Management Process fin dal kick-off. Sembra un costo iniziale, ma previene ore (o settimane) di rework e tensioni con gli stakeholder. Usa tool come AI notetaker per meeting notes automatiche che diventano “single source of truth” condivise da tutti.

Real Talk: Drupal vs Storyblok

Un’altra sessione è stata una ventata di onestà: “Why We Left Drupal, Tried Storyblok, and What Happened Next”. Un’agenzia ha tentato il passaggio da Drupal a Storyblok , spinti dalla volontà di diversificare gli strumenti e dal marketing massivo di questo CMS alternativo. In breve? La nuova soluzione non si è rivelata all’altezza.

La frustrazione principale è stata l’assenza di funzionalità base date quasi per scontate in Drupal, come la costruzione di moduli, la complessità nel gestire URL e redirect, la gestione delle configurazioni (e relativo versioning) in Git. Il team si è essenzialmente ritrovato nella condizione di dover innovare in autonomia per replicare funzionalità basilari già disponibili in Drupal (“ Abbiamo letteralmente ricostruito il Configuration Management di Drupal per Storyblok ”).

Non meno importante, il tech stack limitato. Il team aveva scelto Storyblok + Next.js, data la loro expertise, ma Storyblok era ottimizzato per Vue.js. Come risultato, l’agenzia ha dovuto costruire in autonomia dei workaround, anche per sfruttare le funzionalità della nuova versione di Next.js rilasciata durante il progetto.

Funzionalità a parte, il supporto stesso di Storyblock non all’altezza delle aspettative, con risposte non tempestive ed indicazioni poco chiare che hanno causato importanti ritardi. Non si può fare affidamento neanche sulla community , essendo estremamente ridotta e poco ingaggiata. Essenzialmente, ogni problema richiede una soluzione custom.

La scoperta: Una tecnologia come Storyblok può essere utile in contesti molto specifici, ma per soluzioni enterprise, Drupal continua a rappresentare standard di alto livello. Solido, testato in oltre 20 anni di lavoro community, con soluzioni rodate che rischiamo di dare per scontate dimenticando che non tutti i CMS le hanno.

Una tagline memorabile: “Product before marketing.” Questo risuona con il tema generale della conferenza. Drupal non sta facendo marketing aggressivo ma sta consolidando il suo posizionamento come prodotto d’eccellenza in aree critiche che contano davvero per il business. Come abbiamo discusso nel nostro confronto tra CMS, Drupal eccelle dove complessità, governance e longevità sono requisiti primari.

Takeaway pratico: Se stai valutando alternative CMS, guarda oltre feature list sulla carta e l’UI scintillante. Fai domande dure: come gestisci multi-brand? Come gestisci configurazioni e versioning? Come garantisci il controllo degli accessi granulare? Come migri quando inevitabilmente dovrai? Come è il supporto e la community attorno all’ecosistema? Drupal ha risposte rodate, le alternative spesso hanno promesse.

Performance: HTTP/3 e ottimizzazioni network-level

Come si evince dal titolo “TCP Fast Open and HTTP/3: Network-Level Optimizations for Lightning-Fast Drupal” è stata un’interessante disamina sul funzionamento dello stack HTTP/3 e TCP e delle sue ottimizzazioni a livello di performance. Ovvero come risparmiare preziosi millisecondi con le giuste configurazioni , e un’attenzione ai possibili vettori di attacco.

Secondo i dati condivisi, tra i top 1000 siti, il 60% supporta HTTP/3, di cui l’85% via CDN (Cloudflare, Fastly, etc) ed il 15% direttamente. Per quanto riguarda Drupal nello specifico, Drupal.org, Acquia Cloud e Platform.sh/Upsun supportano HTTP/3.

Un talk tecnico, ma il messaggio chiave è chiaro: È tempo di abilitare HTTP/3.

Takeaway pratico: Se non hai ancora HTTP/3 abilitato, questo è il momento. I performance gains sono significativi e misurabili specialmente per connessioni mobili e applicazioni che richiedono bassa latenza. Controlla con il tuo hosting provider se è disponibile (Acquia, Platform.sh, Pantheon lo supportano tutti).

Conclusione: action items concreti per i tuoi progetti

Quattro giorni a Vienna hanno confermato una tesi: Drupal sta attraversando momento di rinnovamento tecnico profondo senza perdere l’affidabilità enterprise che lo caratterizza. Questa è combinazione rara e preziosa.

Per team italiani che pianificano progetti 2026, ecco action items concreti da considerare in modo attento.

Se stai pianificando nuovo progetto Drupal:

• Budget Canvas come authoring layer (stable da novembre 2025, default da gennaio 2026)
• Architetta per design system first, non per Drupal theme first
• Includi AI Readiness Assessment nella fase di discovery del progetto (introdurre funzionalità AI come il Context Control Center richiede pianificazione)
• Pianifica per composable architecture anche se parti con un singolo touchpoint

Se hai Drupal in produzione:

• Review delle pipeline di CI/CD per includere security scanning automatica
• Valuta la realizzazione di un pilot con Canvas, limitandoti a una sezione del sito (non full migration subito)
• Check della compliance per l’accessibilità in vista dei nuovi requisiti EAA (ma anche come nuova opportunità)
• Verifica il supporto per HTTP/3

Se sei agenzia o system integrator:

• Considera sviluppare site template verticale per tuo target market, non appena possibile (e preparati a venderlo come prodotto, non come soluzione)
• Investi in design system, riutilizzabile e coerente cross-project
• Evalua partnership per integrare soluzioni e features AI nella tua offerta

Se hai un team in-house:

• Proponi un pilot di Canvas, per favorire in futuro la creaione di un elevato volume di pagine e contenuti
• Se hai necessità di generazione di contenuti, sperimenta e definisci dei business case da impostare nel Context Control Center
• Fai una review del tuo change management process (riduci il problema dello scope creep, costa più del processo di formalizzazione)
• Pianifica training intensivo sul nuovo stack di features e strumenti (Canvas, tools AI, approccio al design system)

La sensazione uscendo da Vienna? Drupal ha fatto scelte architetturali nel 2015 (structured content, API-first, configuration management rigoroso) che allora sembravano overkill. Nel 2025, tali scelte risultano vincenti. Sono esattamente l’infrastruttura necessaria per AI enterprise-grade, visual page building senza sacrificare governance, e composable architecture scalabile.

Come ha detto Dries al keynote: “AI is the storm, but it’s also the way through it.” Drupal non sta evitando la tempesta. Sta navigando meglio di chiunque altro.

In SparkFabrik, combiniamo una profonda expertise tecnica su Drupal con competenze avanzate in AI integration, architetture composable e governance enterprise. I nostri servizi di sviluppo Drupal coprono l’intero spettro: da consulenza strategica sull’AI readiness della tua architettura attuale, a implementazione di soluzioni AI-powered custom, fino a sicurezza, supporto continuativo e ottimizzazione.

Se la tua organizzazione sta considerando l’adozione di AI per le sue iniziative digitali, ti invitiamo a:

1. Esplorare i nostri case study di implementazioni Drupal enterprise
2. Contattare il nostro team per una valutazione delle tue esigenze specifiche
3. Scoprire come la nostra suite di servizi Drupal può supportare la tua strategia AI

Questo articolo è parte della nostra serie dedicata a Drupal CMS. Per esplorare altri aspetti della piattaforma, vi invitiamo a consultare i nostri precedenti articoli su caratteristiche e vantaggi, confronto con le alternative, strategie di migrazione, sicurezza e compliance, architettura composable, Design System, Drupal headless omnicanale e panoramica e novità di Drupal AI.

Secondo una ricerca condotta da GitLab su oltre 5.000 professionisti IT, l’adozione di tecnologie di machine learning e IA è in costante crescita : il 51% degli intervistati utilizza l’IA per le procedure di checking, il 37% per il testing dei software e il 31% per la revisione del codice, con percentuali in aumento rispetto all’anno precedente.​

Le tecnologie principali che stanno guidando questa evoluzione includono il machine learning , che consente ai sistemi di apprendere dai dati e migliorare nel tempo; l’elaborazione dellinguaggio naturale (NLP) , che permette ai computer di comprendere e generare linguaggio umano; la visione artificiale , che consente di interpretare dati visivi; e l’integrazione di assistenti virtuali e chatbot , che facilitano l’interazione tra gli utenti e i sistemi.

Queste tecnologie stanno rivoluzionando il ciclo di vita del software , automatizzando processi complessi, migliorando l’efficienza operativa e la produttività degli sviluppatori. L’AI completa le competenze e il set di strumenti a disposizione, come abbiamo analizzato nell’articolo AI per Developer.

Oltre all’integrazione dell’IA nel DevOps, sta emergendo una nuova frontiera: l’IA applicata alPlatform Engineering. Questa evoluzione naturale del DevOps , ovvero una sua implementazione concreta e mirata, si concentra sulla creazione e gestione di piattaforme di sviluppo scalabili e automatizzate , sfruttando l’intelligenza artificiale per ottimizzare l’infrastruttura e migliorare l’esperienza degli sviluppatori. L’IA + Platform Engineering rappresenta quindi il prossimo passo nell’evoluzione delle pratiche DevOps, promettendo di portare ulteriori innovazioni ed efficienze nel mondo dello sviluppo software.​

Vantaggi dell’IA in DevOps

Sempre più organizzazioni stanno guardando all’IA come un acceleratore di valore per la produzione di software di qualità. In un contesto dove la velocità nel portare nuovi prodotti o nuove funzionalità sul mercato è sempre più importante, l’automazione delle catene DevOps rappresenta una risposta concreta alle sfide di complessità e scalabilità che le aziende si trovano ad affrontare. Una infusione dell’IA nei processi DevOps consente alle organizzazioni di aumentare la produttività, ridurre i margini di errore e rafforzare l’intero ecosistema tecnologico.

Uno degli aspetti più evidenti di questa trasformazione è la velocità con cui si riescono a completare le fasi di sviluppo e deploy. Secondo l’indagine di GitLab, oltre il 60% dei team DevOps ha registrato una riduzione dei tempi di rilascio grazie all’impiego di strumenti AI-driven per la code review, il test e il deployment automatico. Un caso emblematico è quello di Bosch , che ha introdotto tecnologie di machine learning nelle sue pipeline DevOps ottenendo un’accelerazione del 30% nei tempi di rilascio del software per i sistemi embedded automobilistici, senza sacrificare la qualità del prodotto finale.

L’IA, tuttavia, non è solo questione di rapidità , ma anche di coerenza. L’intelligenza artificiale, infatti, si rivela utile anche nelle attività di pianificazione e gestione delle risorse a consumo (tipiche dei Cloud provider) supportando le organizzazioni anche nelle attività collegate al mondo del Cloud Management e FinOps.

Standardizzando attività complesse e time consuming come le code review, la validazione dei test o la generazione della documentazione tecnica, è possibile ridurre significativamente gli errori umani. È quanto emerge dal caso di Microsoft , che ha integrato GitHub Copilot nel proprio ciclo di sviluppo: secondo i dati pubblicati, oltre il 40% del codice scritto dai team interni è stato co-generato dall’assistente IA, contribuendo a una maggiore coerenza e qualità.

Oltre DevOps: AI e Platform Engineering

Il Platform Engineering una pratica molto vantaggiosa per le organizzazioni che cercano di industrializzare i processi del ciclo di vita dello sviluppo software. Se DevOps costruisce ponti tra Dev e Ops in termini di cultura interna e pratiche, il Platform Engineering fornisce l’infrastruttura concreta e i prodotti interni per metterlo in pratica e renderlo sostenibile e scalabile, in particolare in contesti aziendali complessi. Ovviamente le innovazioni nel mondo IA vanno ad arricchire anche questo approccio, aumentando ulteriormente i benefici di piattaforme, ora, intelligenti.

Con l’IA integrata a livello di piattaforma, compiti ripetitivi e time-consuming come il provisioning delle risorse, la configurazione degli ambienti o il monitoraggio delle performance vengono affidati ad agenti intelligenti , capaci di adattarsi dinamicamente al contesto. L’infrastruttura diventa così sempre più autonoma , in grado di autoregolarsi e di apprendere nel tempo dai comportamenti delle applicazioni e dei team che la utilizzano. In ambienti complessi come quelli multi-cloud o ibridi, questa capacità si traduce in un abbattimento dei tempi di configurazione e in una drastica riduzione degli errori di setup.

Ma forse il beneficio più significativo riguarda l’esperienza degli sviluppatori. Le piattaforme intelligenti permettono di ridurre il “cognitive load” legato alla gestione dell’ambiente di sviluppo, consentendo ai developer di concentrarsi esclusivamente sul codice. Tool come Humanitec, Backstage o le soluzioni interne di aziende come Spotify e Zalando dimostrano come una developer platform ben progettata, potenziata da IA, possa migliorare la produttività, ridurre il numero di ticket operativi e aumentare il senso di ownership all’interno dei team.

Tuttavia, questa nuova frontiera non è priva di insidie. L’affidabilità dei modelli di intelligenza artificiale, specialmente quelli non supervisionati, rappresenta un punto critico: un sistema che apprende autonomamente potrebbe generare comportamenti imprevisti se non correttamente monitorato. Inoltre, delegare processi chiave a modelli IA introduce nuove superfici d’attacco e vulnerabilità , costringendo i team di platform e security engineering a ripensare i meccanismi disoftware security , in termini di osservabilità, audit e controllo.

Applicazione dell’intelligenza artificiale nel DevOps e Platform Engineering

La declinazione di una tecnologia innovativa come l’IA ha portato alla nascita di numerosi use case e sperimentazioni, fatte proprio per cercare di validare quei benefici che nella maggior parte dei casi sono ancora su carta. La nascita dei Copilot ha aiutato a velocizzare questo processo, ma organizzazioni più coraggiose hanno anche provato a spingersi oltre, con casi d’uso come questi:

Suggerimento di codice

Gli assistenti di codifica basati su IA, come GitHub Copilot e Claude Code, stanno diventando strumenti indispensabili per gli sviluppatori. Questi strumenti forniscono suggerimenti in tempo reale, migliorando la qualità del codice e accelerando il processo di sviluppo. Ad esempio, JPMorgan Chase ha riportato un aumento dell’efficienza degli ingegneri del software fino al 20% grazie all’adozione di un assistente di codifica basato su IA.

Testing automatizzato

L’IA sta trasformando il testing del software, permettendo l’automazione dei test e l’identificazione proattiva degli errori. Secondo GitLab, l’integrazione dell’IA nel processo di testing consente di rilevare anomalie nei dati di log e in altre fonti, aiutando i team DevOps a identificare potenziali problemi prima che diventino critici.

CI/CD

L’IA migliora i processi di continuous integration e deployment (CI/CD) automatizzando l’analisi dei dati e ottimizzando i flussi di lavoro. Strumenti come quelli offerti da Dynatrace utilizzano l’IA per analizzare i dati di osservabilità, fornendo insight predittivi e suggerimenti per migliorare le pipeline CI/CD.

Monitoraggio e sicurezza

L’IA consente un monitoraggio continuo e proattivo dell’infrastruttura tramite agent, migliorando la sicurezza e la resilienza dei sistemi. Ad esempio, Dynatrace utilizza un motore IA proprietario, Davis, per fornire analisi predittive e identificare automaticamente le cause principali dei problemi, migliorando la sicurezza e l’efficienza operativa.

Applicazioni dell’IA nel Platform Engineering

Nel contesto del Platform Engineering, l’IA automatizza compiti come la gestione delle modifiche al codice, il testing del software, le integrazioni complesse e la gestione delle problematiche di sicurezza. Inoltre, l’IA facilita l’analisi dei dati centralizzati delle piattaforme, come i log CI/CD, le storie di deployment, le configurazioni e le metriche di sistema, generando insight accurati con poco rumore. Ad esempio, può analizzare rapidamente i dati di log prevedibili e gli alert per produrre sintesi focalizzate, come evidenziare i fallimenti delle ultime 24 ore.

DevOps AI tools: strumenti utili per migliorare la produttività

Con l’ingresso dell’IA nel panorama DevOps, strumenti di mercato e nuove soluzioni open source stanno piano piano evolvendo per essere AI-Powered o per integrare verticalmente le toolchain (come nel caso del Platform Engineering per il mondo AI/ML). Ecco alcuni esempi:

• GitHub Copilot: assistente AI per la programmazione che utilizza il modello GPT di OpenAI per suggerire codice in tempo reale, migliorando la produttività e l’apprendimento.
• Datadog: piattaforma di monitoraggio e analisi che utilizza algoritmi di machine learning per rilevare le anomalie, analizzare le cause principali e prevedere i problemi.
• PagerDuty: piattaforma per la gestione degli incidenti, che utilizza l’IA per ottimizzare la risposta agli eventi critici, analizzando i pattern per prevenire problemi futuri.
• KitOps: controllo centralizzato delle versioni per tutte le risorse del progetto AI/ML.
• Kubeflow: gestione semplificata del flusso di lavoro ML in Kubernetes.
• DVC (Data Version Control): garantisce la riproducibilità tracciando set di dati, codice ed esperimenti.
• Prometheus: monitoraggio dell’infrastruttura e dell’implementazione ML in tempo reale.
• MLflow: gestisce il ciclo di vita, inclusi il rilevamento, la distribuzione e il controllo delle versioni del modello.

Il futuro dell’IA in DevOps e Platform Engineering

È evidente come, nel contesto DevOps e Platform Engineering, l’IA esprima attualmente solo una piccola parte del potenziale atteso – come sottolinea anche Patrick Debois nel suo talk dedicato all’AI Platform Engineering. La costante spinta delle Big Tech alla ricerca del prossimo vantaggio competitivo, così come gli investimenti delle organizzazioni in questa direzione, rappresentano sicuramente segnali positivi. Tuttavia, è importante tenere a mente una serie di sfide, come ad esempio:

• La necessità di mantenere una supervisione umana. Per quanto sofisticati siano gli algoritmi, l’intervento umano resta essenziale per garantire il buon funzionamento dei sistemi. L’IA non sostituisce il giudizio, ma lo amplifica: permette di operare più rapidamente, con maggiore precisione, ma va comunque guidata.
• La qualità e la sicurezza dei dati. I modelli di IA sono tanto efficaci quanto i dati che li alimentano. Se questi dati sono incompleti, distorti o poco rappresentativi, il risultato sarà altrettanto inaffidabile.
• Prototipazione sicura e locale. Per facilitare l’adozione dell’AI, ma soprattutto per aumentare la comprensione reale di tali tecnologie, è cruciale fornire ai team aziendali degli ambienti di prototipazione e ambienti di sviluppo locali (LDE). Senza tali condizioni, è difficile passare dall’entusiasmo tecnico all’implementazione pratica, sperimentando e prototipando con l’AI in modo rapido e sicuro.
• Trasparenza e responsabilità. In un ecosistema tecnologico dove l’IA prende decisioni autonome o semi-autonome, diventa imprescindibile sapere come e perché quelle decisioni sono state prese. Se da una parte l’AI aumenta l’output ed automatizza intelligentemente, dall’altra bisogna evitare di cadere nelle classiche “ironie dell’automazione”, mantenendo sorveglianza, controllo, comprensione e responsabilità dell’operato di questi strumenti. Questo implica la tracciabilità degli output generati dai modelli, la possibilità di audit su determinati processi automatizzati e la presenza di linee guida condivise sull’uso corretto dell’IA.

L’Intelligenza Artificiale Generativa e la sua accessibilità attraverso strumenti open source stanno trasformando il panorama dello sviluppo. In questo articolo, esploriamo i vantaggi e gli strumenti AI per sviluppatori, analizzando come stiano rivoluzionando il processo di sviluppo software e ridefinendo i processi del settore IT.

L’open source e la diffusione di tool AI per sviluppatori

L’open source sta giocando un ruolo fondamentale nell’evoluzione delle tecnologie di Intelligenza Artificiale Generativa, dimostrando ancora una volta la sua capacità di guidare l’innovazione in ambiti tecnologici emergenti. Standard de facto per le moderne soluzioni software e le tecnologie cloud, le tecnologie open sono ormai utilizzate dal 90% delle organizzazioni a livello mondiale. Una tendenza che si sta estendendo anche al settore dell’AI, che ha visto una crescita esplosiva nel 2023-2024 e continua ad espandersi rapidamente.

Tuttavia, l’applicazione dei principi open source all’AI generativa solleva nuove sfide senza precedenti, come l’adattamento della definizione di software open source ai modelli di linguaggio di grandi dimensioni (LLM), che coinvolgono dataset massivi, hardware dedicato e codice.

Nonostante queste complessità, l’ecosistema open source per GenAI si sta rapidamente evolvendo in tutti i settori dello sviluppo; dalle piattaforme runtime e motori di inferenza, ai database vettoriali e framework di sviluppo. Fatto che dimostra come questo approccio stia permettendo a comunità e aziende di collaborare per sbloccare il pieno potenziale di tecnologie che altrimenti potrebbero essere controllate da pochi attori.

Cosa ne pensano gli sviluppatori di questa rivoluzione in atto? Il sentiment del mondo dello sviluppo - ovvero la percezione di questo scenario - si direbbe positivo, con il 72% degli sviluppatori che dichiara una posizione favorevole o molto favorevole riguardo l’uso degli strumenti di AI nel workflow di sviluppo.

Vediamo quindi più nel dettaglio quali sono le aree di lavoro interessate dai nuovi strumenti AI per sviluppatori, e in particolare gli strumenti open source analizzati dal Paolo Mainardi, CTO di SparkFabrik, per Linux Foundation Newsroom.

Cos’è Open Source AI?

L’AI Open Source rappresenta un approccio all’Intelligenza Artificiale in cui modelli, strumenti e dataset sono accessibili pubblicamente, consentendo a sviluppatori e aziende di contribuire, modificare e distribuire le tecnologie senza dover dipendere da soluzioni proprietarie. Questo modello segue i principi dell’open source già affermati nel mondo del software tradizionale, con l’obiettivo di rendere l’AI più trasparente, collaborativa e accessibile a un’ampia comunità di innovatori.

Mozilla ha recentemente proposto una definizione più strutturata di Open Source AI , sottolineando che “per essere veramente open source, un sistema di AI deve garantire l’accesso e la possibilità di modifica a tutti i suoi componenti chiave: codice, dati e modelli” 【Mozilla, Open Source AI Definition】. Questo punto è cruciale, perché molte soluzioni di AI, pur dichiarandosi open, limitano l’accesso ai dataset di training o ai pesi dei modelli, creando una sorta di “open source a metà”.

Anche McKinsey evidenzia questo problema, affermando che “l’AI open source offre maggiore trasparenza e personalizzazione, ma pone domande cruciali su governance, sicurezza e scalabilità” 【McKinsey, Open Source in the Age of AI】. L’adozione di modelli AI aperti richiede quindi un bilanciamento tra innovazione e gestione dei rischi, specialmente considerando le implicazioni etiche e normative emergenti, come l’AI Act europeo.

Un contributo fondamentale alla definizione dell’AI Open Source arriva anche dalla Open Source Initiative (OSI) , che sta lavorando a una definizione chiara e strutturata. Secondo la loro bozza più recente, “affinché un sistema AI possa essere considerato realmente open source, devono essere garantite quattro libertà fondamentali: libertà di usare il sistema per qualsiasi scopo, libertà di studiare e comprendere il funzionamento del modello, libertà di modificarlo e libertà di condividerlo” 【OSI, Open Source AI Definition Draft】. Tuttavia, OSI sottolinea che queste libertà devono applicarsi non solo al codice, ma anche ai dati di training e ai pesi del modello, elementi spesso esclusi dalle licenze open tradizionali.

L’importanza dell’AI Open Source non risiede solo nella democratizzazione della tecnologia, ma anche nel ruolo fondamentale che può avere nel favorire una maggiore fiducia negli strumenti di intelligenza artificiale. La possibilità di analizzare, modificare e migliorare il codice permette infatti di evitare situazioni in cui pochi attori controllano interamente il panorama dell’AI, con impatti significativi sulla sicurezza e sulla competitività del settore.

Piattaforme runtime e modelli open source

Partiamo dalle piattaforme open source e i modelli di linguaggio di grandi dimensioni (LLM), che stanno diventando veri e propri pilastri nell’ambito dell’Intelligenza Artificiale Generativa. Similmente a soluzioni come OpenAI e DeepSeek, queste piattaforme richiedono diversi componenti che lavorano insieme per funzionare efficacemente. In questo contesto, la scelta del motore di inferenza è fondamentale, poiché deve essere compatibile con l’hardware utilizzato, come CPU o GPU, per evitare rallentamenti.

Una volta scelto il motore, è importante sapere come interagire con esso utilizzando strumenti di programmazione. Tuttavia, spesso questi strumenti possono essere complessi per gli sviluppatori meno esperti. Ecco che le potenzialità dell’AI per developers entrano in gioco, attraverso piattaforme più facili da usare, capaci di gestire la complessità tecnica per l’utente.

Tra le soluzioni open source più interessanti troviamo Ollama, LocalAI, GPT4ALLe e Jan, che offrono funzionalità simili ma si adattano a esigenze diverse; dall’esperto, all’utente finale in cerca di un’alternativa alle piattaforme commerciali.

Database vettoriali

Anche i database vettoriali stanno emergendo come elementi protagonisti nell’ecosistema delle applicazioni di Intelligenza Artificiale Generativa, in particolare per implementare tecniche avanzate come la Retrieval-Augmented Generation (RAG).

La RAG è diventata fondamentale per superare i limiti degli LLM, addestrati su dataset pubblici statici. La RAG consente di collegare gli LLM a fonti di dati esterne, migliorando significativamente l’accuratezza e l’attualità delle risposte generate.

Il processo RAG si articola in tre fasi principali: preparazione dei dati, recupero e generazione. La fase di preparazione dei dati è particolarmente critica e coinvolge la raccolta di informazioni da diverse fonti, la conversione in testo semplice, la suddivisione in chunk significativi e il salvataggio in un database insieme alla loro rappresentazione vettoriale.

Questa rappresentazione vettoriale, ottenuta attraverso il processo di embedding utilizzando modelli AI specializzati, permette di eseguire operazioni matematiche per cercare documenti simili basandosi sulla distanza tra punti vettoriali. I database vettoriali sono progettati specificamente per gestire queste operazioni, dalla fase di embedding alla ricerca di similarità, rendendo possibile l’implementazione efficiente di applicazioni RAG.

Roberto Peruzzo, nel suo talk “AI e Typesense: come integrare la ricerca semantica in Drupal”, fornisce un esempio pratico dell’uso dei database vettoriali nello sviluppo. Nel suo talk, illustra Typesense, un motore di ricerca open-source che migliora l’esperienza di ricerca su un sito, dimostrando come l’AI e la ricerca semantica possono rivoluzionare il modo in cui gli utenti trovano contenuti su siti Drupal.

Altri progetti di database vettoriali da segnalare sono: Chroma, Weaviate, pgvector, Milvus e Qdrant.

Framework di sviluppo

I framework di sviluppo stanno fungendo da veri e propri acceleratori per l’innovazione in questo campo. Questo perché lo sviluppo di applicazioni GenAI richiede inevitabilmente l’integrazione di molteplici componenti, dalla gestione dei dati all’interazione con diversi tipi di modelli AI, ciascuno con le proprie API, pesi e configurazioni.

È proprio questa complessità che ha portato alla creazione di framework specializzati che semplificano e accelerano il processo di sviluppo. Proprio come l’invenzione di Docker e Kubernetes ha rivoluzionato il panorama dello sviluppo software negli ultimi dieci anni, i framework GenAI stanno ridefinendo rapidamente l’industria tecnologica.

In questo frangente, possiamo citare framework completi come Langchain e Llama Index. Altri progetti notevoli includono Microsoft Semantic Kernel e Autogen, che si concentrano su aspetti specifici dello sviluppo AI. Framework come Haystack e Vercel AI offrono invece soluzioni più mirate per casi d’uso specifici.

IDE e assistenti di sviluppo

Vediamo ora come gli Integrated Development Environments (IDE) e gli assistenti di sviluppo basati sull’Intelligenza Artificiale Generativa (GenAI) stanno ridefinendo il panorama della programmazione, promettendo di rivoluzionare il modo in cui gli sviluppatori scrivono, comprendono e mantengono il codice.

Il concetto di assistente di codifica automatizzato risale agli anni ‘70, ma l’avvento dei modelli di linguaggio di grandi dimensioni ha portato questa tecnologia a un livello completamente nuovo. Strumenti come GitHub Copilot hanno aperto la strada a una nuova generazione di assistenti AI, stimolando lo sviluppo di modelli open source specificamente addestrati per l’assistenza alla codifica. Oltre a migliorare la qualità del codice, uno dei benefici più significativi di questi tool è l’aumento della sicurezza del codice, grazie a suggerimenti di codice che riducono gli errori comuni.

A differenza dei tradizionali sistemi IntelliSense, che offrono suggerimenti deterministici basati su analisi statica, questi nuovi assistenti AI sfruttano la capacità dei modelli GenAI di produrre testo basato sul contesto, generando interi blocchi di codice pertinente. Anche se, questa capacità porta con sé il rischio di “allucinazioni”.

Un esempio emblematico di IDE è certamente Claude e il suo nuovissimo strumento, Claude Code, che permette ai programmatori di delegare compiti complessi direttamente dal terminale, migliorando l’efficienza e la precisione nella programmazione.

Altri progetti open source che spiccano sono Cody di Sourcegraph e Continue. Questi strumenti offrono funzionalità avanzate come il completamento del codice basato sul contesto, la spiegazione del codice esistente e la generazione automatica di test e documentazione.

AI per sviluppatori: casi d’uso di successo

La rivoluzione dell’AI per sviluppatori non è solo teoria; in SparkFabrik abbiamo implementato due casi d’uso concreti che stanno trasformando i nostri processi di sviluppo, migliorando l’efficienza e la qualità del nostro lavoro.

SparkBot: l’intelligenza contestuale al servizio dei team

SparkBot rappresenta la nostra implementazione di una piattaforma RAG (Retrieval-Augmented Generation) integrata direttamente nel nostro ecosistema Gitlab. Sviluppato dal Platform Team nel contesto R&D, questo assistente AI ha due obiettivi principali: acquisire confidenza con la tecnologia RAG e diffonderne la conoscenza all’interno dell’azienda.

Il bot si distingue per la sua capacità di accedere e contestualizzare informazioni specifiche dell’organizzazione, rispondendo a domande sui progetti, sulle configurazioni dei servizi e sull’organizzazione dei team. Ad esempio, uno sviluppatore può chiedere: “Quali progetti gestisce il team Alpha?” o “Chi sono gli owner interni ed esterni del progetto X?”, ricevendo risposte precise basate su dati aggiornati.

L’architettura di SparkBot è basata su Python, Langchain e ChromaDB, con integrazione diretta con Slack per facilitare l’interazione. Il sistema attinge a diverse fonti dati interne, tra cui:

• Il portale di documentazione aziendale
• Il catalogo dei componenti CI/CD
• Libri di riferimento come “Cloud Native Transformation” e “Team Topologies”

Questa implementazione, pur essendo ancora in fase sperimentale, dimostra come la tecnologia RAG possa essere utilizzata per creare una “intelligenza aziendale” accessibile e contestuale, che valorizza il patrimonio di conoscenze dell’organizzazione.

PR Agent: code review automatizzata per migliorare la qualità del codice

Il secondo caso d’uso implementato in SparkFabrik è l’adozione del Codium PR Agent, un assistente AI che interviene direttamente nelle pipeline di Gitlab per migliorare il processo di revisione del codice. Questo strumento monitora automaticamente le nuove merge request e fornisce feedback istantaneo, trasformando radicalmente l’approccio alla code review.

Quando viene aperta una MR, il PR Agent genera automaticamente una descrizione basata sul titolo e sul contenuto, analizza il codice e suggerisce miglioramenti specifici. Gli sviluppatori possono anche interagire con il bot attraverso comandi specifici come /review per richiedere una revisione completa, /improve per ottenere suggerimenti di miglioramento, o semplicemente /ask per porre domande sul codice.

L’implementazione del PR Agent è basata su un’architettura containerizzata con un’immagine Docker estesa con un entrypoint personalizzato e un container Nginx come reverse proxy. Il sistema supporta modelli AI di OpenAI e Anthropic, con la possibilità di selezionare il modello preferito tramite variabili di ambiente.

Questo strumento si è rivelato particolarmente prezioso per:

• Identificare potenziali bug e vulnerabilità prima che raggiungano l’ambiente di produzione

• Assicurare l’aderenza agli standard di codice aziendali

• Accelerare il processo di revisione , permettendo ai revisori umani di concentrarsi su aspetti più strategici

• Fornire un’opportunità di apprendimento continuo per gli sviluppatori attraverso suggerimenti contestuali

Impatto e risultati

L’implementazione di questi strumenti AI ha portato a benefici tangibili in SparkFabrik:

1. Riduzione del tempo di onboarding : i nuovi sviluppatori possono rapidamente familiarizzare con progetti e standard aziendali grazie a SparkBot.
2. Aumento della qualità del codice : il PR Agent ha contribuito a standardizzare le best practice e ridurre potenziali bug in produzione.
3. Crescita delle competenze : entrambi gli strumenti fungono da mentori virtuali, esponendo gli sviluppatori a pattern e tecniche ottimali.
4. Efficienza operativa : la velocizzazione delle code review e la riduzione del tempo speso nella ricerca di informazioni hanno ottimizzato il flusso di lavoro complessivo.

Questi casi d’uso dimostrano come l’AI per sviluppatori non sia solo uno strumento per completare attività di base, ma un vero e proprio moltiplicatore di produttività e qualità, capace di trasformare i processi di sviluppo e valorizzare il capitale umano e di conoscenza dell’azienda.

Sfide e best practices per l’uso etico dell’AI nello sviluppo

In conclusione, l’adozione dell’Intelligenza Artificiale Generativa (GenAI) nello sviluppo software sta rapidamente trasformando il settore, offrendo molti vantaggi e introducendo altrettante nuove sfide. Una su tutte è la formazione di modelli di linguaggio di grandi dimensioni, che richiede un hardware costoso. Ad esempio, Meta ha dichiarato che l’allenamento di Llama 3.1 ha richiesto oltre 16.000 GPU Nvidia H100, con costi che possono raggiungere i 640 milioni di dollari. Costo che limita di gran lunga la competizione e suggerisce la necessità di sviluppare tecniche di addestramento decisamente più accessibili.

Inoltre, questioni etiche e legali, come il nuovo European AI Act, richiedono un’attenzione continua, poiché la definizione di open source nell’AI è ancora in evoluzione grazie al lavoro della OSI Foundation.

Nonostante queste sfide, il panorama è promettente. I casi d’uso di successo, come quelli implementati in SparkFabrik, dimostrano come l’AI per sviluppatori possa trasformare i processi di sviluppo e valorizzare il capitale umano e di conoscenza dell’azienda.

Gli strumenti AI open source non solo assistono nel completamento del codice, ma aiutano anche a semplificare i flussi di lavoro complessi, rendendo l’intero processo di sviluppo più fluido e gestibile. L’81% degli sviluppatori riconosce un aumento della produttività grazie agli strumenti AI, anche se solo il 43% si fida dei risultati, con un 31% che rimane scettico.

La strada da percorrere è ancora lunga e non mancherà di sorprenderci. Rimane una certezza (oggi per lo meno): siamo fortunati a vivere in un’epoca in cui l’open source è il modello di sviluppo predominante, offrendo a tutti l’opportunità di partecipare a questa rivoluzione.

Hai un progetto AI, vuoi integrare l’intelligenza artificiale nei tuoi sistemi o vuoi sfruttare l’IA nei tuoi processi? Scopri i Servizi AI di SparkFabrik.

Quanto tempo perdono i tuoi sviluppatori ogni giorno per configurare ambienti, cercare documentazione o attendere l’approvazione di un ticket infrastrutturale? Se la risposta supera il 20% del loro tempo lavorativo, la tua organizzazione sta bruciando risorse preziose.

Il platform engineering fa riferimento all’attività di progettazione e sviluppo di toolchain e processi di lavoro interni. Queste soluzioni permettono di rendere i team di un’organizzazione autosufficienti in tutte le attività di software engineering. Questa pratica risulta particolarmente efficace nei contesti in cui si adotta un modello di sviluppo Cloud Native, con l’obiettivo primario di ottimizzare la Developer Experience (DevX).

Che cos’è il Platform Engineering?

Il platform engineering è la disciplina che progetta e costruisce toolchain e flussi di lavoro self-service per lo sviluppo software. Attraverso la creazione di una internal developer platform (IDP), astrae la complessità infrastrutturale, riduce il carico cognitivo dei team e accelera il rilascio di valore sul mercato.

Nel 2026, questa disciplina si è consolidata come lo standard architetturale di fatto per governare la frammentazione dei sistemi distribuiti. Le organizzazioni che gestiscono architetture a microservizi affrontano costantemente la proliferazione incontrollata di strumenti, nota come tool sprawl. Per comprendere l’urgenza di questa standardizzazione, è utile analizzare le principali tendenze e innovazioni del panorama Cloud Native, che evidenziano come la gestione dell’infrastruttura richieda un approccio radicalmente diverso dal passato.

La risposta metodologica a questa complessità è l’adozione di un approccio orientato al prodotto applicato all’infrastruttura. Il team di piattaforma tratta gli sviluppatori interni come i propri clienti principali. L’obiettivo non è semplicemente fornire server o cluster Kubernetes. Si tratta invece di offrire un prodotto interno coeso, documentato e facile da consumare tramite API.

Un moderno IDP si fonda tipicamente su tre pilastri architetturali:

• Portale per sviluppatori centralizzato: Un’interfaccia unificata, spesso basata su framework come Backstage. Raggruppa catalogo dei servizi, documentazione tecnica e metriche di monitoraggio in un unico cruscotto.
• Automazione dell’infrastruttura: L’utilizzo intensivo di approcci infrastructure as code. Garantisce che la creazione di nuovi ambienti sia ripetibile, sicura e priva di interventi manuali.
• Template standardizzati: Modelli pre-configurati per la pipeline di continuous integration e continuous delivery. Incorporano nativamente le policy di sicurezza aziendali fin dal primo commit.

Implementare questi pilastri significa spostare il focus dalla manutenzione reattiva. Si passa alla creazione proattiva di percorsi dorati (golden paths) che guidano lo sviluppatore verso le best practice aziendali in modo naturale.

Come funziona il Platform Engineering?

Operativamente, il platform engineering funziona trattando l’infrastruttura come un prodotto software. Un team dedicato raccoglie i requisiti degli sviluppatori, seleziona gli strumenti migliori e li integra in una internal developer platform centralizzata. Questo approccio trasforma le operazioni manuali in flussi di lavoro automatizzati e self-service.

I team di piattaforma non sono differenti da un normale team di prodotto nell’era DevOps. Le figure solitamente presenti includono Site Reliability Engineers (SRE), DevOps Engineers e Product Manager. Tutti insieme collaborano per definire approcci tecnologici e metodologici. Risolvono le problematiche quotidiane di developer e architect creando workflow adatti alla propria organizzazione.

Come ogni team di prodotto, conducono ricerche interne e sollecitano il feedback da parte dei propri utenti. Si occupano inoltre di favorire l’adozione della piattaforma. Questo ciclo di feedback continuo è essenziale per massimizzare l’impatto. Garantisce un reale aumento di produttività all’interno di tutta l’organizzazione, evitando di costruire strumenti complessi che nessuno utilizzerà.

Quali sono i vantaggi del Platform Engineering per le aziende?

Un’azienda che mira a creare un team interno di platform engineers può misurare il successo dell’iniziativa osservando fattori tangibili. Tra questi spiccano l’efficienza operativa, la riduzione dei costi, la flessibilità architetturale e una migliore Developer Experience complessiva.

Efficienza e riduzione dei costi

Un’organizzazione priva di processi automatizzati subisce un forte spreco di risorse. Perde tempo e competenze in attività a basso valore aggiunto, come la predisposizione manuale di ambienti per i test. Al contrario, una completa automazione offre valore immediato. Nei progetti curati da SparkFabrik, l’adozione di un IDP ha portato a una riduzione del 40% dei costi operativi legati all’infrastruttura. Inoltre, abbiamo osservato un abbattimento dei tempi di setup dei nuovi progetti da diverse settimane a poche ore.

Scalabilità e flessibilità

Quando si pensa alla scalabilità, ci si concentra solitamente sulla capacità di un’applicazione di sopportare picchi di traffico. Tuttavia, questa necessità riguarda anche il ciclo di vita dei team di prodotto. L’ingresso di nuovi membri richiede un onboarding efficace. Tramite una piattaforma ben ingegnerizzata, queste dinamiche vengono gestite fluidamente. I nuovi assunti sono operativi dal primo giorno con ambienti di lavoro pre-configurati.

Affidabilità e sicurezza

Standardizzare lo sviluppo del software tramite un IDP permette di governare in modo centralizzato i framework e le librerie. In questo modo diventa possibile bloccare l’uso di dipendenze insicure. Si garantisce che aspetti critici come il logging, la telemetria e la gestione dei segreti siano sempre inclusi di default. Queste funzionalità sono fondamentali per diagnosticare il funzionamento degli applicativi e ridurre drasticamente la superficie di attacco.

Migliore DevX

Il platform engineering restituisce agli sviluppatori il controllo sulle capability tecnologiche di cui hanno bisogno. Lo fa senza esporli alla complessità sottostante. Ogni sviluppatore può accedere con facilità a risorse, documentazione e template condivisi. Questo approccio riduce la frustrazione legata alla burocrazia interna. Permette ai team di focalizzarsi esclusivamente sulla logica di business e sulla qualità del codice prodotto.

In che modo il Platform Engineering evolve il DevOps?

Il platform engineering non sostituisce il DevOps, ma ne rappresenta la naturale evoluzione pratica. Mentre il DevOps promuove la collaborazione culturale tra sviluppo e operation, il platform engineering fornisce gli strumenti concreti. Trasforma le interazioni manuali in piattaforme self-service che eliminano definitivamente i colli di bottiglia operativi.

Nella nostra esperienza di consulenza, vediamo spesso aziende che rimangono bloccate in un modello operativo obsoleto pur avendo abbracciato la filosofia DevOps. In questi scenari, il team operations diventa un centro di smistamento per innumerevoli richieste. Dall’apertura di una porta sul firewall al provisioning di un database, tutto passa per un sistema di ticketing. Questo approccio genera latenza, frustrazione e allontana gli sviluppatori dal loro obiettivo principale. Per comprendere le differenze e le sinergie con il DevOps, è fondamentale osservare come cambia il flusso di lavoro quotidiano.

Con l’introduzione del platform engineering, il paradigma si ribalta completamente. Il team operations non esegue più le singole richieste manualmente. Al contrario, costruisce le API, i portali e le automazioni che permettono agli sviluppatori di servire se stessi in totale autonomia. Se un team necessita di un nuovo cluster, non apre un ticket su Jira. Effettua semplicemente una chiamata API o compila un form sull’IDP aziendale.

La piattaforma, dietro le quinte, esegue il provisioning dell’infrastruttura. Applica automaticamente le policy di sicurezza e i limiti di budget definiti a monte. Questa transizione dal modello ticket-based al modello API-driven self-service è il vero salto di qualità. I team di piattaforma si concentrano sull’ingegnerizzazione di astrazioni robuste, mentre i team applicativi guadagnano velocità e indipendenza.

Come l’intelligenza artificiale trasforma il Platform Engineering?

L’intelligenza artificiale trasforma il platform engineering evolvendo le piattaforme interne da portali passivi ad assistenti attivi. L’integrazione di agenti AI automatizza il provisioning tramite linguaggio naturale, fornisce troubleshooting intelligente e applica policy di sicurezza in tempo reale, abbattendo drasticamente i tempi di configurazione dell’infrastruttura.

L’evoluzione verso l’AI-augmented IDP rappresenta un cambio di paradigma fondamentale per la produttività aziendale. Fino a poco tempo fa, un portale per sviluppatori facilitava la ricerca di documentazione o l’esecuzione di script predefiniti. Oggi, l’integrazione di modelli linguistici di grandi dimensioni (LLM) permette agli sviluppatori di dichiarare il proprio intento in linguaggio naturale.

Invece di scrivere complesse configurazioni infrastrutturali, un ingegnere può richiedere all’IDP di predisporre un ambiente di test. L’assistente AI traduce l’intento nel codice infrastrutturale corretto, lo valida e lo invia alle pipeline di automazione per il deploy. Questo garantisce tracciabilità e gestione sicura dello stato tramite approcci GitOps.

L’impatto di questa automazione avanzata è misurabile e profondamente trasformativo. I dati provenienti dalle implementazioni più mature mostrano un abbattimento dei tempi di provisioning da diverse settimane a poche ore. Parallelamente, il tempo speso nella ricerca di documentazione tecnica si riduce drasticamente, passando da 45 minuti a meno di 5 minuti per query. Per approfondire l’impatto di queste dinamiche, è utile esplorare il ruolo dell’intelligenza artificiale nel rivoluzionare le pratiche DevOps.

Tuttavia, l’adozione dell’AI generativa porta con sé il rischio della Shadow AI. L’utilizzo di strumenti intelligenti non approvati può infatti compromettere la sicurezza dei dati aziendali. Qui entra in gioco il ruolo cruciale dei guardrail forniti dal platform engineering. La piattaforma offre ambienti sandbox isolati e applica regole di policy as code rigorose.

I tre casi d’uso principali dell’AI all’interno di un IDP moderno sono:

1. Provisioning automatizzato e intent-based: Traduzione di richieste in linguaggio naturale in template di infrastruttura pronti per il deploy.
2. Troubleshooting intelligente: Analisi predittiva della telemetria per identificare anomalie nei cluster e suggerire soluzioni mirate.
3. Governance della sicurezza dinamica: Revisione automatica del codice infrastrutturale generato dall’AI per garantire il rispetto dei vincoli di compliance.

Platform Engineering: alcuni esempi di successo

Un esempio di successo che ha portato alla realizzazione di una internal developer platform è il progetto di SparkFabrik per il Centro Medico Santagostino. Questa società italiana gestisce una rete di ambulatori offrendo un’ampia gamma di servizi specialistici di alta qualità a un prezzo accessibile.

La sfida in questione prevedeva di arrivare a standardizzare e organizzare il modo in cui i servizi digitali interni andavano a operare. Questa transizione ha affrontato due aspetti fondamentali. Il primo è stato quello di creare un IDP per centralizzare servizi e documentazione. Il secondo è stato quello di implementare una serie di servizi di interconnessione per facilitare la comunicazione dei principali prodotti interni.

Con una soluzione basata su stack tecnologico AWS e Backstage, il progetto ha velocizzato drasticamente lo sviluppo. A seguito della messa in produzione della piattaforma, il rilascio di nuovi servizi e funzionalità ha richiesto solo tre mesi di operatività.

Conclusioni

Il platform engineering rappresenta un elemento strategico imprescindibile per le organizzazioni che vogliono scalare le proprie operazioni IT. Attraverso la costruzione di piattaforme interne solide, le aziende possono aumentare l’efficienza dei processi di sviluppo. Al contempo, garantiscono elevati standard di sicurezza e affidabilità.

Predisporre team dedicati consente di ridurre drasticamente il time-to-market. Il platform engineering è lo step di maturità successivo in un percorso di modernizzazione. Trasforma i principi agili in strumenti concreti e abilita un’adozione sicura delle nuove tecnologie Cloud Native e AI-augmented. Se la tua organizzazione sta affrontando sfide legate alla complessità infrastrutturale, esplorare i servizi di consulenza DevOps e Platform Engineering su misura è il primo passo per accelerare realmente il tuo business.