Guardrail, migrazioni AI, MCP: cosa abbiamo portato a Rotterdam

La DrupalCon Europe 2026 si è svolta a Rotterdam dal 28 settembre al 1 ottobre 2026. Il formato aveva tre momenti: il primo giorno dedicato per la prima volta a summit tematici, poi le giornate di conferenza, infine il General Contribution Day. Il team SparkFabrik ha partecipato a tutti e tre, portando sul palco e nelle issue queue il lavoro che facciamo durante l’anno sull’AI in Drupal. I nostri contributi tecnici, fatti di talk, moderazione e codice, si raccolgono in tre filoni:

• Guardrail: il talk di Luca Lusso all’AI Dev Summit sul sottosistema dei Guardrail del modulo Drupal AI, il tavolo di lavoro su guardrail e security che ha moderato e il contributo alla issue che ha portato i modelli decisionali nella 1.6.0-dev.

• Migrazioni AI: il talk di Roberto Peruzzo “163 → 42: Dismantling and Reassembling a Drupal Migration with AI”, sul palco della conferenza, dedicato a una grande migrazione di un sito verso Drupal 11 assistita dall’AI.

• MCP: il lavoro sul modulo MCP Client al General Contribution Day di giovedì 1 ottobre.

A questi filoni si aggiunge inoltre lo Splash Award: con il progetto di Università Luiss abbiamo vinto l’International Splash Award nella categoria Education, il primo riconoscimento di questo tipo assegnato a un progetto italiano.

Accanto ai nostri contributi tecnici abbiamo seguito talk su AI, core e community. A Rotterdam, per come l’abbiamo vissuta, il lavoro più concreto sull’AI in Drupal riguardava ciò che circonda il modello: verificare cosa entra e cosa esce, dare struttura alle decisioni, fornire il contesto, stabilire chi può fare cosa e come si autenticano le connessioni. Questi controlli si costruiscono nelle issue queue: chi vuole orientarne lo sviluppo deve portare lì codice e proposte.

Guardrail all’AI Dev Summit: il primo giorno è partito dal controllo

Per la prima volta in una DrupalCon Europe, il primo giorno dell’evento è stato dedicato a summit su temi diversi, ciascuno con un proprio programma. Noi abbiamo partecipato all’AI Dev Summit, il summit sullo sviluppo dei tool AI all’interno di Drupal, dove Luca Lusso ha tenuto un talk sul sottosistema dei Guardrail del modulo Drupal AI.

Abbiamo contribuito a sviluppare quel sottosistema, che fa parte del core del modulo Drupal AI dall’anno scorso. Il framework dei Guardrails valida input e output dell’AI contro contenuti tossici, prompt injection ed esposizione di PII, cioè dati personali che permettono di identificare una persona. I controlli si basano su espressioni regolari, keyword e API di moderazione come quelle di Azure e OpenAI, e si inseriscono nell’architettura del modulo Drupal AI che abbiamo descritto nella nostra panoramica, insieme alle iniziative della community.

Per chi mette un LLM davanti agli utenti di un sito Drupal, questi controlli lavorano su due momenti distinti¹. In ingresso possono fermare un messaggio che tenta di sovrascrivere le istruzioni di sistema, oppure che contiene un indirizzo email da non inoltrare al provider. In uscita possono bloccare una risposta con linguaggio tossico prima che venga mostrata in pagina. La responsabilità del controllo resta sulla piattaforma, qualunque sia il modello scelto per generare il testo.

Lo schema seguente semplifica il flusso senza entrare nei dettagli dell’implementazione: il guardrail si colloca prima e dopo la chiamata al modello. Tra i tipi di controllo abbiamo incluso anche i modelli decisionali, che la 1.6.0-dev rende utilizzabili proprio in questi punti.

Il resto dell’agenda ha seguito una direzione simile. Nick Veenhof ha presentato i tool che GitLab sta sviluppando per semplificare e incoraggiare le contribuzioni open source alla codebase del prodotto. Marcus Johansson ha mostrato gli avanzamenti del Context Control Center, un modulo Drupal che fornisce contesto agli agenti che operano sulla piattaforma, un po’ come le skill, ma per gli agenti che lavorano su un sito Drupal. Jurgen Haas ha mostrato l’evoluzione di ECA nel campo dei workflow agentici, e Shibin Das ha fatto lo stesso con il suo FlowDrop.

Letti insieme, questi interventi compongono una mappa piuttosto netta. Controllo su cosa entra ed esce dal modello, contesto su cosa l’agente può sapere, workflow su cosa l’agente può fare e in quale ordine, strumenti per rendere più semplice contribuire: tra gli interventi che abbiamo seguito, nessuno era centrato sul confronto tra un modello e un altro.

La giornata si è chiusa con 4 tavoli di lavoro, pensati per approfondire i temi emersi e fare brainstorming sulle innovazioni future. Luca Lusso ha moderato quello sui guardrail e sulla security dei sistemi AI in Drupal, portando al tavolo l’esperienza di chi ha lavorato sul codice del sottosistema.

Modelli decisionali in Drupal AI

Un guardrail basato su espressioni regolari riconosce un numero di carta di credito con affidabilità, ma fatica davanti alle domande che richiedono un giudizio. Una richiesta è fuori ambito? Un testo appartiene a una categoria sensibile? Un messaggio formulato in modo nuovo è un tentativo di manipolazione? Per domande come queste la risposta più utile ha la forma di un sì, un no, oppure una classificazione in un elenco chiuso di opzioni.

Il 15 settembre 2026 TypeSafe AI ha rilasciato Jev, un modello che risponde con un formato strutturato a domande decisionali, e nel team di sviluppo del modulo Drupal AI il tema è diventato subito uno degli argomenti caldi. Circa due settimane dopo, in tempo per la chiusura della DrupalCon Europe 2026, è uscita la versione 1.6.0-dev, con pieno supporto ai modelli decisionali, Jev compreso. Il lavoro è tracciato nella issue #3586751 del modulo Drupal AI, e anche noi abbiamo contribuito a portare in Drupal questa nuova direzione della frontiera AI.

Chiedere al modello una decisione invece di un testo semplifica il controllo per una ragione meccanica: lo spazio delle risposte possibili è chiuso e noto in anticipo. Se il modello risponde vero o falso, il codice che lo chiama gestisce due rami e nient’altro; se risponde con una categoria, la confronta con l’elenco ammesso e scarta tutto ciò che non vi appartiene. Una risposta in testo libero va invece interpretata di nuovo, magari con un’altra chiamata a un modello, e ogni interpretazione aggiunge un punto in cui il controllo può sbagliare. Con un output chiuso la decisione diventa verificabile: si può registrare, testare con casi noti e usare per instradare il flusso in modo deterministico.

Per questo i modelli decisionali o “classificatori” hanno un posto naturale nei punti strategici della piattaforma, a partire dai guardrail. Crediamo che Drupal sia la prima piattaforma open source già disponibile sul mercato a supportare out of the box i modelli decisionali.

Nella stessa conferenza il talk AI-Assisted Contrib Module Maintenance ha offerto una panoramica dei tool, deterministici e non, che il team dietro il modulo Drupal AI usa per fare triage della issue queue, categorizzare le issue e validare le merge request. Anche categorizzare un’issue è, a sua volta, una scelta in un elenco chiuso. Secondo noi queste strategie possono essere applicate a tutti i moduli contrib, per aiutarli a gestire le code di issue, lavorare in modo più efficiente e produrre codice migliore.

Migrazioni AI e clean code: l’LLM ragiona su quello che vede

Sul palco della conferenza, il nostro Roberto Peruzzo ha presentato “163 → 42: Dismantling and Reassembling a Drupal Migration with AI”. Il talk descrive un approccio end-to-end a una grande migrazione di un sito verso Drupal 11, assistita dall’AI e organizzata in quattro fasi: analyse, decompose, implement, assemble.

La scelta che ci interessa di più sta nell’ordine delle fasi: prima si analizza e si scompone, poi si implementa e si riassembla. Nella nostra lettura è questa struttura a rendere governabile l’aiuto dell’AI lungo tutto il percorso, in coerenza con l’approccio agentic-first allo sviluppo Drupal, che sposta il valore dalla scrittura del codice alla definizione del contesto e delle specifiche.

Il meccanismo dietro questa intuizione l’ha descritto Len Swaneveld in Clean Code in the Age of AI. La sua tesi è che codice e architettura puliti sono una forma di context engineering e una salvaguardia contro gli LLM che vanno fuori strada, perché un LLM può ragionare solo su ciò che vede e indovina il resto. Il clean code, con responsabilità singola, nomi significativi, funzioni piccole, livelli di astrazione coerenti, nesting ridotto e DRY, è più gestibile anche per un modello, perché richiede meno contesto e meno token. Swaneveld ha distinto due scale: il clean code mette il contesto necessario in una finestra piccola, la clean architecture lo organizza in una finestra grande. Per l’architettura le indicazioni erano precise: niente logica in hook o controller, servizi per la business logic, dependency injection e dipendenze esplicite.

Per mantenere il codice pulito Swaneveld ha indicato tre fonti di feedback. La prima è la review umana, cioè essere lo human in the loop; la seconda è l’analisi statica con PHPStan e PHPCS, che dà un riscontro deterministico; la terza sono i test con code coverage e CRAP score (Change Risk Anti-Patterns), un riscontro numerico da restituire all’LLM. Sulla review ha aggiunto un avvertimento:

“Don’t commit anything you don’t understand (or you won’t understand anything in a few months/years).”

Len Swaneveld, “Clean Code in the Age of AI”

Il talk From Drupal Content to AI Answers: Learnings from EPSY ha portato lo stesso principio sul piano dei contenuti. Ha raccontato come un ente dell’Unione Europea ha sviluppato il chatbot di supporto per gli utenti della sua piattaforma. Il caso ha messo in evidenza come portare un chatbot in produzione vada ben oltre il capire cos’è la RAG (Retrieval-Augmented Generation, la tecnica che recupera documenti pertinenti e li passa al modello come contesto), e che senza documenti fatti bene le risposte restano insoddisfacenti.

La struttura riguarda anche le persone. Nel talk Culture mapping the human side of AI Timi Csontos ha definito la cultura come l’insieme degli assunti di base di un gruppo. Ha poi ripreso i cinque stadi di evoluzione delle culture organizzative descritti da Frederic Laloux in “Reinventing Organizations”, ciascuno associato a un esempio:

• Impulsive (red): le startup, con potere concentrato, autorità, command & control e paura.

• Conformist (amber): la pubblica amministrazione, con gerarchia, processi e stabilità.

• Achiever (orange): le grandi aziende internazionali, orientate a obiettivi, accountability, competizione, merito, incentivi e innovazione.

• Pluralistic (green): le ONG, con valori condivisi, community ed equità.

• Evolutionary (teal): Patagonia e Morning Star, con uno scopo superiore e decisioni distribuite.

Ogni stadio mantiene i punti di forza dei precedenti. Il change-culture gap, per Csontos, è la distanza tra dove si è e dove si vuole arrivare: si può cercare di chiuderlo il più in fretta possibile, oppure lavorare sull’autoconsapevolezza, chiedendosi cosa si fa meglio e come migliorare, puntando sui propri punti di forza con empatia e comprensione. Sull’adozione dell’AI nei team il suo consiglio è stato esplicito.

“Don’t split people based on experience, but give more personal attention to those who are lagging behind.”

Timi Csontos, “Culture mapping the human side of AI”

Mikaela Kindstedt e Sanna Kramsi, in Hidden Skills of Development, hanno parlato di come rendere visibile l’invisibile nella salute dei team, indicando la sicurezza psicologica come fondamento. Uno dei passaggi più diretti è stato “Silence doesn’t equal agreement”: il silenzio non equivale ad accordo, quindi bisogna chiedere chiarimenti. Il talk ha toccato anche linee guida e aspettative chiare, diversità cognitiva e comunicazione, framework per una comunicazione sana, resilienza e prevenzione del burnout con una energy matrix derivata dalla matrice di Eisenhower.

Mettendo insieme i due talk, la sicurezza psicologica è il presupposto della review umana chiesta da Swaneveld. Uno human in the loop che non si sente libero di dire «non capisco questo codice» smette di fare da controllo, e l’LLM resta senza il feedback più importante.

Hook, test, form e CLI: dove il core di Drupal sta diventando più testabile

Diversi talk della conferenza hanno mostrato un core che si sposta verso codice più organizzato e più facile da verificare. Leggiamo questo movimento alla luce della tesi di Swaneveld: se il codice pulito è contesto per l’LLM, un core più testabile cambia la base su cui lavorano sia le persone sia gli strumenti AI, e rende più solidi nel tempo anche i contributi sull’AI.

Fabian Bircher (Bircher su drupal.org) ha aperto Refactor to #[Hook] spiegando perché aveva scelto il tema. Qualche mese prima Dries gli aveva detto che nessuno parlava dell’attributo #[Hook] alle conferenze, e che quindi era ancora poco conosciuto dalla community. Da Drupal 11.1 la maggior parte degli hook può essere scritta come metodi di una classe marcata con #[Hook], con migliore organizzazione del codice e dependency injection: due proprietà che rendono il codice degli hook molto più facile da testare.

La differenza rispetto alla funzione procedurale nel file .module è che le dipendenze arrivano dal costruttore. Un esempio minimo, con un servizio ipotetico, mostra la forma di un hook sulle entità.

<?php

declare(strict_types=1);

namespace Drupal\my_module\Hook;

use Drupal\Core\Entity\EntityInterface;
use Drupal\Core\Hook\Attribute\Hook;
use Drupal\my_module\ArticleNotifier;

/**
 * Hook del modulo: le classi in src/Hook vengono scoperte automaticamente.
 */
final class MyModuleHooks {

  // La dipendenza arriva dal container: niente chiamate a \Drupal::service().
  public function __construct(
    private readonly ArticleNotifier $notifier,
  ) {}

  // Sostituisce my_module_entity_insert() nel file .module.
  #[Hook('entity_insert')]
  public function entityInsert(EntityInterface $entity): void {
    if ($entity->getEntityTypeId() === 'node') {
      // In un test unitario basta passare un mock di ArticleNotifier.
      $this->notifier->notify($entity);
    }
  }

}

I messaggi di Bircher sono stati tre: scrivere un hook nel nuovo modo è facile quanto nel vecchio modo procedurale, il refactoring degli hook nei file .module non deve spaventare, e passare ora agli hook OOP mantiene il codice compatibile con le future versioni di Drupal. Per chi mantiene moduli contrib o custom, la sua indicazione è di farlo subito.

Il talk di Francesco Placella (Plach), Inside the Pyramid - A path to faster, clearer Drupal testing, è partito da un’osservazione semplice: la test suite di Drupal è lenta anche per ragioni strutturali. Il core non ha linee guida ufficiali su quale tipo di test usare per ogni scenario, quindi si scrivono test Kernel o Functional anche dove un test Unit basterebbe, sarebbe più rapido ed economico e altrettanto valido. La sua proposta è adottare la piramide dei test come strategia esplicita e condivisa dalla community, per core, contrib e codice custom.

• Una base larga di test Unit, veloci ed economici da eseguire.

• Uno strato più sottile di test Kernel, cioè di integrazione.

• Pochi test Functional e FunctionalJavascript in cima, evitando i FunctionalJavascript per verificare singoli elementi di form.

• La copertura E2E riservata ai comportamenti critici per il business, e a nient’altro.

Secondo Placella l’entity system è da tempo il principale ostacolo allo unit testing in Drupal. La proposta lavora su due fronti: nel core, rendere l’entity system più accessibile ai test unitari; nel codice contrib e custom, nascondere le entità dietro interfacce proprie, così che la business logic resti disaccoppiata e testabile in isolamento. La sua libreria Deuteros fornisce test double per le entità e serve soprattutto sul codice legacy, dove quel refactoring non è praticabile. Ai core maintainer Placella ha presentato proposte concrete su strategia, tooling e documentazione dei test, con un obiettivo preciso: fare di test più veloci e leggibili la norma.

Le due proposte si sommano. Un hook in una classe con dipendenze iniettate, che lavora su un’interfaccia propria invece che su un’entità concreta, è esattamente il tipo di codice che può stare alla base della piramide.

Sul fronte front end, il talk The joy and power of SDC, finally for form inputs ha mostrato che i Single Directory Components, i componenti che raccolgono in una cartella template, stili, script e schema, ora si possono usare anche come componenti per le form. Il supporto è ancora limitato, ma quando sarà completo il core potrà rimuovere decine di migliaia di righe di codice PHP oggi usate per dichiarare il markup delle form. Per noi dichiarare quel markup in PHP ha poco senso, perché le form dovrebbero essere materia di front end e non di back end.

A joyful tour through the CLI now in Drupal Core ha presentato dr, o doctor, un tool CLI nativo nel core di Drupal basato su Symfony Console e pensato come successore di Drush. Drush ha servito Drupal per anni ed è stato uno dei punti di forza del CMS, ma il nuovo tool vuole migliorare standardizzazione e developer experience. Non tutti i suoi comandi sono già stati migrati e ci vorrà tempo prima che dr diventi l’unico tool CLI per gestire Drupal. Per ora Moshe suggerisce di supportare entrambi i comandi, drush e dr, nei propri moduli contrib: sono wrapper dei servizi del modulo, quindi il codice duplicato è poco.

Per chi mantiene moduli, le indicazioni pratiche di questi quattro talk si possono mettere una accanto all’altra. La tabella le riassume usando solo ciò che è emerso dalle sessioni.

Rikkert Steenbergen ed Esmeralda Tijhoff, in When the roadmap is a battleground, hanno raccontato come DICTU, ente governativo olandese, costruisce prodotti digitali per la pubblica amministrazione con una piattaforma Drupal condivisa. Secondo i relatori DICTU è la più grande realtà Drupal nei Paesi Bassi, con circa 1800 FTE e oltre 450 milioni di fatturato. Il modello, ispirato a LocalGov Drupal, prevede Drupal as a service, una sola codebase per molte istanze, un prezzo fisso annuale e DICTU come owner di visione, roadmap e backlog. La governance finanziaria è basata sul recupero dei costi, secondo il principio «public money, public code».

Il dettaglio che ci ha colpito riguarda le Drupal Recipes, i pacchetti che applicano moduli e configurazione a un sito in un’unica operazione. In DICTU le recipe vengono installate e poi scartate; per gestire gli upgrade path si riapplica la recipe aggiornata, cosa possibile perché il cliente non può modificare la configurazione. Nella nostra lettura è un esempio di piattaforma che regge grazie a vincoli espliciti, lo stesso principio dei guardrail applicato alla configurazione invece che all’output di un modello.

MCP Client, Contribution Day e perché contribuire conta

Giovedì 1 ottobre 2026 si è tenuto il General Contribution Day, una giornata in cui la community lavora insieme sul Core di Drupal, i moduli e la documentazione. Il nostro Roberto Peruzzo ha partecipato e ha passato gran parte della giornata su MCP Client, un modulo che co-mantiene con il supporto di SparkFabrik².

Il Model Context Protocol (MCP) è un protocollo aperto che standardizza il modo in cui un’applicazione si collega a server esterni che espongono tool e dati a un modello. MCP Client permette a Drupal di connettersi a server MCP esterni ed espone i loro tool al modulo Drupal AI e a ECA, quindi sia agli agenti sia ai workflow configurati sul sito. Dalla issue queue, il bilancio della giornata è questo:

• Pagina “Add MCP Server”: corretto il problema per cui la pagina restituiva Page not found (#3618561).

• Permessi: corretto il supporto a un permesso meno restrittivo dell’accesso admin completo per gestire i server MCP (#3618560).

• Sessioni: aperto un follow-up per riprendere le sessioni MCP tra una richiesta e l’altra (#3618562), basato sul lavoro sulle sessioni persistenti (#3565713).

• OAuth: discusso con Marcus Johansson un piano per aggiungere l’autenticazione OAuth ai server MCP, basata sul modulo OpenID Connect, così che Drupal possa connettersi a server MCP che richiedono OAuth senza rinnovare i token a mano (#3618563).

Nelle parole di Roberto, “i contribution day sono l’occasione per fare progressi mirati, incontrare di persona chi sta dietro la issue queue, dedicare in modo costruttivo il proprio tempo all’open source”.

SparkFabrik stessa è nata su progetti Drupal e da sempre sostiene e mette al centro l’open source: il lavoro su MCP Client al Contribution Day fa parte di un impegno che portiamo avanti da più di 10 anni, in modo continuativo e verificabile nelle issue queue (ad esempio, quelle per Drupal AI³). Anche per questo il 14 maggio 2026 la Drupal Association ci ha riconosciuto come primo Drupal Certified Partner di livello Gold in Italia ⁴.

Contribuire però non significa solo scrivere codice. Nel Driesnote di Rotterdam il progetto Drupal è stato descritto in buona salute e con una community solida. Il punto dolente indicato è che molte persone continuano a parlare male di Drupal, forse perché non lo conoscono o si sono fermate a una versione di molti anni fa. L’idea presentata è un programma di reward (in termini di contribution credits) per chi fa advocacy, da blog post a post sui social, podcast e altro.

È una forma di contribuzione rimasta finora in secondo piano, che noi pratichiamo da sempre: condividiamo conoscenza e buone pratiche con l’ecosistema Drupal attraverso articoli, eventi e post social.

Raccontare con precisione cosa si è fatto e cosa si è visto alla DrupalCon è una forma di quella advocacy. Chi vuole ascoltare la proposta direttamente da Dries trova la registrazione completa del keynote su YouTube.

Va nella stessa direzione la menzione degli International Splash Awards, in cui è stato premiato il progetto di Università Luiss nella categoria Education. È un modo diverso di rendere visibile ciò che si costruisce con Drupal, su cui ci siamo soffermati per capire cosa premia davvero.

Cosa portiamo a casa da Rotterdam e cosa fare subito

Ogni anno la community Drupal europea si ritrova in presenza. Per noi Rotterdam è servita soprattutto a questo: il networking, dalla chiacchierata spontanea in corridoio al confronto con chi sviluppa i moduli che usiamo nei progetti dei clienti. All’AI Dev Summit abbiamo discusso di guardrail e integrazione con strumenti esterni con chi scrive quel codice. Dai talk abbiamo portato a casa approcci da provare nei nostri progetti. Durante il Contribution Day abbiamo lavorato assieme alla community sulle issue che decideranno le prossime release.

Cosa si può usare da subito? I modelli decisionali sono nella 1.6.0-dev del modulo Drupal AI e si possono usare nei guardrail, accanto ai controlli basati su espressioni regolari, keyword e API di moderazione. Su MCP Client restano aperte la ripresa delle sessioni tra richieste (#3618562) e l’autenticazione OAuth basata su OpenID Connect (#3618563): è lì che si deciderà come Drupal si collega in modo controllato a strumenti esterni.

Chiudiamo con un consiglio. Prima di portare in produzione una funzionalità AI su Drupal, o esporre un LLM o un server MCP agli utenti di un sito, verifica questi quattro controlli:

• Input: cosa arriva al modello e quali filtri lo intercettano prima della chiamata.

• Output: quali guardrail validano la risposta prima che raggiunga l’utente o il contenuto.

• Permessi: quali ruoli possono attivare l’AI e configurare i server MCP, su quali entità l’AI può agire e con quale ruolo operano i tool.

• Autenticazione: come il sito si identifica verso i servizi esterni, punto che per MCP dipende ancora dalle issue aperte.

Il prossimo appuntamento con la community italiana è DrupalCamp Italy 2026, il 22 ottobre 2026 a Bologna. SparkFabrik è tra gli organizzatori. Ci vediamo lì per discutere di questi temi dal vivo.

Se nel frattempo stai valutando come integrare agenti AI in un progetto Drupal, contatta il team di SparkFabrik.

Note e fonti