Un prodotto composto da dodici servizi, tre immagini base diverse e due componenti acquistati da fornitori produce con facilità venti o trenta documenti SBOM per ogni release. Il Cyber Resilience Act¹, però, ne chiede uno: l’unità di evidenza è il prodotto immesso sul mercato, non il repository né la singola build.

È lo scarto fra come funzionano le pipeline e come ragiona il regolatore. La generazione delle SBOM è un problema risolto: Syft², Trivy³ e gli scanner integrati nei registry producono CycloneDX o SPDX in pochi secondi. Quello che manca, nella maggior parte dei setup che abbiamo visto, è la composizione: un documento autorevole per versione di prodotto, che tenga insieme le SBOM dei componenti senza appiattirle in un file monolitico. Questo articolo affronta quel problema: come collegare, firmare e mantenere nel tempo una distinta base di prodotto in architetture multi-servizio.

Perché in un prodotto multi-servizio le SBOM si moltiplicano?

La moltiplicazione non è un difetto di configurazione: è una proprietà strutturale delle architetture cloud native. Agisce su tre assi che si compongono per moltiplicazione, non per somma:

1. Servizi e repository: ogni servizio con un proprio ciclo di rilascio genera i propri documenti, e ogni monorepo con più artefatti pubblicabili si comporta come N sorgenti distinte.
2. Tipologia lungo il ciclo di vita: la tassonomia CISA⁴ distingue Design, Source, Build, Analyzed, Deployed e Runtime SBOM. Sono viste diverse dello stesso software, non copie.
3. Origine dei componenti: codice first-party, immagini base con i loro pacchetti OS, runtime linguistici, firmware, componenti di terze parti consegnati dai fornitori.

Una Source SBOM e una Build SBOM dello stesso servizio non sono ridondanti. La prima descrive ciò che è dichiarato nei manifest e nei lock-file, la seconda ciò che è effettivamente entrato nell’artefatto spedito. Chi genera solo dal sorgente ottiene contemporaneamente falsi positivi, cioè dipendenze dichiarate e mai compilate, e punti ciechi: le librerie di sistema dell’immagine base, i binari statici linkati in fase di build, i moduli vendorizzati. Il primo caso gonfia il triage, il secondo lo rende incompleto proprio dove il rischio è più opaco.

Il failure mode ricorrente ha una forma riconoscibile. Cartelle di artefatti CI con retention limitata nel tempo, un foglio di calcolo che tiene traccia di quale merge sia il più recente, nessun documento che qualcuno sia disposto a dichiarare autorevole per la release in commercio. Questo SBOM sprawl ha un costo che si manifesta esattamente nel momento peggiore: alla comparsa di una vulnerabilità sfruttata attivamente, il team non risponde alla domanda “quale versione di prodotto contiene il componente affetto e in quale servizio”, ma alla domanda molto più povera “dove sta il file giusto”.

La probabilità che quella domanda arrivi non è remota. Il rapporto OSSRA 2024 fotografa il 91% dei repository esaminati con componenti arretrati di dieci versioni o più⁵: in un prodotto con dieci servizi, la presenza di almeno un componente obsoleto e potenzialmente affetto è la condizione normale, non l’eccezione. La visibilità granulare sulle dipendenze è il presupposto di tutto il resto, un punto che abbiamo già trattato analizzando come la Software Bill of Materials rende tracciabili i rischi di terze parti sotto il CRA.

Sul piano tecnico il regolamento chiede quattro cose, e conviene leggerle come specifiche. La SBOM deve essere machine-readable: JSON o XML in formato CycloneDX o SPDX⁶, mentre un PDF allegato alla documentazione non assolve l’obbligo. Il formato comune non è prescritto. Il minimo legale, fissato dall’Allegato I, Parte II del CRA, sono le dipendenze di primo livello, ma in cloud native le transitive sono la sostanza del rischio, quindi il minimo legale è un pavimento, non un obiettivo. Soprattutto: serve la rappresentazione delle relazioni di dipendenza e contenimento, non una lista piatta di nomi.

La SBOM è parte della documentazione tecnica definita dall’Allegato VII del CRA¹: non si trasmette proattivamente, deve esistere all’immissione sul mercato ed essere producibile su richiesta motivata di un’autorità di sorveglianza. Le scadenze fissano il contesto: 11 settembre 2026 per gli obblighi di reporting delle vulnerabilità, 11 dicembre 2027 per la piena applicazione.

Compose o merge: quale strategia regge un audit di prodotto?

Entrambe le strade sono conformi. Il CRA non impone un meccanismo di aggregazione, impone che esista un documento machine-readable che rappresenti il prodotto con le sue relazioni di dipendenza. La scelta fra fondere e collegare è quindi ingegneristica, e va motivata con i costi informativi che comporta.

Cosa perdi quando fondi tutto in un file

Il merge piatto ha un paradosso al centro: la deduplicazione. Nei tool di build eliminare i duplicati è buona pratica; nell’analisi di supply chain, deduplicare i componenti di N documenti cancella l’unica informazione che serve, cioè quale servizio usa quale versione. Restano i nomi, sparisce la mappa.

• Il triage cambia natura: da una query sul grafo (“quali componenti del prodotto 3.4 dipendono da libX < 2.9, e in quale servizio”) a una ricerca testuale seguita da verifica manuale servizio per servizio. È qui che si allunga l’MTTR, non nella scrittura della patch.

• I lifecycle sono disaccoppiati: un documento fuso è uno snapshot che invecchia al primo deploy indipendente di un singolo servizio, e ogni rigenerazione impone di ricostruire l’intero file.

• La provenienza si perde: hash e firme dei documenti originali non sopravvivono alla fusione, quindi l’integrità è verificabile solo sull’aggregato.

Il merge resta la scelta corretta in condizioni precise: prodotto sostanzialmente monolitico, poche decine di componenti, una sola cadenza di rilascio, oppure consumatore della SBOM che non sa risolvere riferimenti esterni. In quei casi produce un artefatto autonomo e verificabile con meno infrastruttura attorno.

Il compose gerarchico: una root BOM che referenzia, non che copia

La struttura è semplice: un documento di prodotto per versione, i cui componenti di tipo application rappresentano i servizi, ciascuno con un riferimento esterno alla propria SBOM. In CycloneDX il meccanismo è l’externalReference di tipo bom che trasporta un BOM-Link⁷ nella forma urn:cdx:<serialNumber>/<version>, capace di puntare a un intero documento o a un singolo bom-ref al suo interno. In SPDX l’equivalente si ottiene con la coppia ExternalDocumentRef più Relationship (DESCRIBES, CONTAINS, DEPENDS_ON).

Le proprietà che ne derivano sono quelle che il merge non può offrire: rigenerazione indipendente per servizio, integrità verificabile documento per documento con checksum e firma separati, provenienza preservata, dimensione dei singoli file gestibile anche con centinaia di componenti per servizio. È la stessa logica dell’assembly gerarchico di una distinta base manifatturiera, dove il livello prodotto referenzia i sotto-assiemi invece di elencare ogni singola vite.

Il vincolo, che va dichiarato: la risoluzione dei riferimenti è a carico del consumatore. Se la root BOM punta a URN non risolvibili o ad artefatti scaduti in un registry con retention di trenta giorni, l’evidenza si spezza e il documento diventa una promessa non mantenuta. Il compose richiede quindi uno storage immutabile e indirizzabile per le SBOM di componente, con la stessa retention del prodotto. Valutare questo tipo di trade-off architetturale, dove una scelta di formato diventa un requisito di infrastruttura, è terreno che abbiamo sistematizzato nella guida ai modelli di difesa per architetture cloud native.

Il diagramma: come si legge una root BOM

Gli archi trasportano riferimenti, non contenuti copiati: la root BOM resta l’unico documento autorevole per la release, e ogni foglia conserva la propria firma. Il nodo laterale è il punto meno ovvio: la SBOM del fornitore non entra come link opaco verso un URL di terzi, perché in quel caso l’evidenza dipenderebbe dalla disponibilità di un endpoint che non controlliamo. Va riconciliata prima, come spiegato più sotto.

Come si costruisce la SBOM di prodotto dentro la pipeline?

Ogni scelta qui va agganciata a un requisito: si genera dall’artefatto perché l’evidenza deve riflettere ciò che è stato spedito, si normalizzano gli identificatori perché il tracciamento per componente lo esige, si firma perché l’integrità dell’evidenza conservata è parte della documentazione tecnica.

Generare dall’artefatto costruito, non dal sorgente

Regola operativa: la Build SBOM si genera dall’immagine OCI o dal binario prodotto dalla pipeline, e si confronta con lock-file e sorgente per rilevare divergenze. Dove il tooling non riesce a inferire, come per binari statici, firmware o dipendenze vendorizzate, si aggiungono record manuali tracciati e datati.

# syft 1.x, trivy 0.5x - si usa il digest, non il tag
IMAGE="registry.example.com/checkout-service@sha256:9f2a...c41d"
DIGEST="9f2a...c41d"

# generatore primario: CycloneDX JSON su file versionato per servizio e digest
syft "$IMAGE" -o cyclonedx-json="sbom/checkout-service-${DIGEST}.cdx.json"

# secondo scanner sullo stesso artefatto, per confronto del set di componenti
trivy image --format cyclonedx \
  --output "sbom/checkout-service-${DIGEST}.trivy.cdx.json" "$IMAGE"

Nota onesta: due generatori sullo stesso artefatto non producono set identici. Syft e Trivy divergono tipicamente su binari compilati staticamente e su pacchetti installati fuori dal package manager. Il delta non è un bug, è informazione sulla copertura degli analizzatori: va registrato accanto alla SBOM, e sicuramente non nascosto scegliendo il tool che restituisce meno righe.

Normalizzare l’identità dei componenti prima di comporre

Il compose funziona solo se un componente è identificabile in modo stabile fra documenti generati da tool diversi, in momenti diversi. I campi minimi, coerenti con gli elementi minimi CISA⁸ e con la guideline tecnica BSI TR-03183⁹, sono:

• nome del componente e versione esatta;

• fornitore o autore;

• Package URL (purl)¹⁰, oppure CPE¹¹ dove il purl non è applicabile;

• hash dell’artefatto (SHA-256);

• relazione con il componente padre.

Il problema è concreto: lo stesso pacchetto compare come openssl fra i pacchetti OS, come libssl3 con il nome della distribuzione, e come dipendenza embedded di un binario Go. Senza purl normalizzato la query di triage sul prodotto restituisce tre entità distinte, e la risposta all’autorità o al cliente è incompleta pur essendo formalmente prodotta. La normalizzazione va eseguita in pipeline, come step deterministico e versionato, mai a mano in fase di audit.

Assemblare, firmare, pubblicare

Il job di release del prodotto costruisce la root BOM con metadata.component valorizzato su prodotto e versione, i componenti applicativi per ogni servizio e i riferimenti esterni alle SBOM già pubblicate.

{
  "bomFormat": "CycloneDX",
  "specVersion": "1.6",
  "serialNumber": "urn:uuid:8f7c1c1e-6a3e-4c0b-9e1a-2d5b7f0a11c4",
  "version": 1,
  "metadata": {
    "component": {
      "bom-ref": "prod-retail-3.4.0",
      "type": "application",
      "name": "retail-platform",
      "version": "3.4.0"
    }
  },
  "components": [
    {
      "bom-ref": "svc-checkout-2.11.3",
      "type": "application",
      "name": "checkout-service",
      "version": "2.11.3",
      "externalReferences": [
        {
          "type": "bom",
          "url": "urn:cdx:3e671687-395b-41f5-a30f-a58921a69b79/1"
        }
      ]
    }
  ],
  "dependencies": [
    { "ref": "prod-retail-3.4.0", "dependsOn": ["svc-checkout-2.11.3"] },
    { "ref": "svc-checkout-2.11.3", "dependsOn": [] }
  ]
}

Quando il consumatore non risolve i riferimenti, la via alternativa è un merge gerarchico, che almeno preserva l’annidamento dei componenti:

# cyclonedx-cli 0.32.x - merge gerarchico, conserva la struttura ad assembly.
# Merge solo delle SBOM canoniche e normalizzate dei servizi del prodotto.
# Una per servizio: non il glob grezzo, che includerebbe sia l'output Syft
# sia quello Trivy dello stesso artefatto.
cyclonedx merge --hierarchical \
  --input-files \
    sbom/canonical/api-gateway.cdx.json \
    sbom/canonical/checkout-service.cdx.json \
    sbom/canonical/frontend.cdx.json \
  --name retail-platform --version 3.4.0 \
  --output-file product-3.4.0.cdx.json

# cosign 2.x - firma keyless via OIDC, bundle verificabile accanto al documento
cosign sign-blob --yes product-3.4.0.cdx.json \
  --bundle product-3.4.0.cdx.json.bundle

L’automazione di questi passaggi dentro CI/CD, con scanner e firma (ad esempio tramite Cosign¹²) come step nativi e non come job opzionali, è la parte del lavoro DevSecOps che abbiamo descritto parlando di tooling e integrazione nelle pipeline cloud. La SBOM firmata finisce poi in storage immutabile, e il riferimento al file entra nella documentazione tecnica della release insieme al nome del tool, alla sua versione e alla data di generazione.

SBOM dei fornitori, informazioni mancanti e ciclo di vita dell’evidenza

Due failure mode restano aperti anche nei setup ben automatizzati: i documenti che arrivano da terzi e la manutenzione dell’evidenza nel tempo.

Le SBOM dei fornitori sono input, non l’artefatto finito

Lo scenario è ricorrente. Un fornitore consegna CycloneDX, un secondo SPDX, un terzo un PDF con l’elenco delle librerie; la cartella di release contiene tre link a tre portali diversi. Quello è materiale dei fornitori, non un record di prodotto, e in caso di richiesta motivata non risponde alla domanda su quale versione del nostro prodotto contenga il componente affetto.

La riconciliazione ha una sequenza precisa:

1. convertire o normalizzare i campi identità (purl, versione, hash) nello schema usato internamente;
2. integrare i componenti nella distinta di prodotto, oppure collegarli via BOM-Link dopo aver verificato che il riferimento sia risolvibile e persistente;
3. conservare i documenti originali upstream come supporto probatorio, con data e canale di ricezione;
4. registrare esplicitamente ciò che non è stato possibile determinare.

Il quarto punto è quello che distingue una documentazione difendibile da una lacunosa. Quando un fornitore non consegna una SBOM completa, il componente non si omette: si documentano i known unknowns, cioè evidenza contrattuale e di acquisto, campi verificabili raccolti in autonomia scansionando i binari ricevuti, hash e prova di versione, nota esplicita di ciò che non è determinabile. Un’assenza dichiarata è evidenza; un’assenza silenziosa è una non conformità.

Le implicazioni di questa catena di responsabilità sui componenti di terze parti e sulle dipendenze upstream sono un tema che il regolamento europeo ha spostato dalla community a chi immette il prodotto sul mercato, e la riconciliazione è il punto in cui quella responsabilità diventa operativa.

Ogni quanto si rigenera e per quanto si conserva

La rigenerazione risponde a trigger, non a un calendario: cambio di versione software o firmware, rilascio di una patch, variazione dello stato di sfruttabilità di una vulnerabilità con conseguente aggiornamento del VEX (Vulnerability Exploitability eXchange), aggiunta, rimozione o sostituzione di un componente, modifica di design rilevante, cambio degli standard applicati. Le cadenze periodiche restano utili come rete di sicurezza: revisione trimestrale di SBOM e stato delle vulnerabilità, revisione annuale della documentazione tecnica, freeze prima della fine del periodo di supporto.

Qui il compose mostra il suo argomento più forte. I trigger sono locali al servizio, quindi si rigenera un documento e si riemette la root BOM alla release di prodotto; nel merge, ogni trigger locale impone di ricostruire il documento intero, con il rischio di introdurre delta non voluti su componenti che nessuno ha toccato.

Sulla conservazione il vincolo è lungo, fissato dall’Articolo 13 del CRA¹: almeno dieci anni dall’immissione sul mercato, o l’intero periodo di supporto se superiore, con il conteggio che parte dall’ultima unità immessa. Questo esclude la CI come luogo di archiviazione.

Ad esempio, se il registry è Google Artifact Registry¹³, il servizio di riferimento per la composizione software è Artifact Analysis, che oltre alla scansione delle vulnerabilità supporta la generazione e la gestione delle SBOM degli artefatti archiviati¹⁴: un punto di partenza solido, ma non un archivio di conformità. La retention di default e le cleanup policy del repository non sono allineate a un obbligo decennale, e vanno configurate o affiancate da uno storage dedicato.

Per gestire questa complessità nel lungo periodo, l’infrastruttura deve evolvere oltre il semplice salvataggio dei file. Vale la pena valutare tooling specifico per fetch, storage e trasformazione dei documenti, come Bomctl¹⁵, affiancato da un livello di interrogazione a grafo come GUAC¹⁶ per rispondere alle query di triage in tempi utili.

Ultimo punto, spesso trascurato: la SBOM è documentazione tecnica confidenziale, non materiale pubblico. È una mappa dei componenti utile a chi cerca un punto di ingresso. Rilascio all’autorità di sorveglianza su richiesta motivata (in Italia il ruolo di riferimento è dell’ACN), ai clienti business sotto NDA, con tracciamento di chi ha ricevuto quale versione e quando. La convergenza internazionale su questi principi è documentata nella guidance congiunta A Shared Vision of Software Bill of Materials for Cybersecurity¹⁷ pubblicata nel settembre 2025 da CISA, NSA e diciannove partner.

Lezioni operative

La regola decisionale sta in due righe: se il prodotto ha più di un ciclo di rilascio indipendente, il compose gerarchico è l’unica strategia mantenibile; sotto quella soglia il merge costa meno e regge un audit senza problemi.

Tre cose che rifaremmo diversamente, dalla nostra esperienza su pipeline multi-servizio:

1. Trattare lo storage delle SBOM di componente come artefatto di lungo periodo dal giorno uno, non come output di CI con retention di default. Recuperare documenti scaduti dopo sei mesi significa rigenerarli da immagini che non esistono più.
2. Normalizzare gli identificatori in pipeline prima che il volume renda l’operazione retroattiva. A trecento documenti la normalizzazione a posteriori diventa un progetto, non uno step.
3. Misurare la qualità dell’orchestrazione con una sola domanda, cronometrata: quanto tempo serve, partendo da un CVE, per elencare le versioni di prodotto affette e i servizi impattati. Se la risposta si misura in ore, l’architettura dell’evidenza non funziona, indipendentemente dalla conformità formale del documento.

Una questione resta aperta, e va dichiarata: la maturità dei consumatori nella risoluzione dei BOM-Link è ancora disomogenea, e questo è oggi l’argomento più solido contro il compose puro. La strategia difendibile mantiene la root BOM linkata come sorgente autorevole ed è in grado di produrre su richiesta una vista appiattita come export derivato, mai come documento di riferimento.

Il prossimo e ultimo articolo della serie affronta l’observability, log, metriche e tracce, come base tecnica per rispondere agli obblighi di notifica e reporting previsti da CRA e NIS2.

Su questi temi lavoriamo quotidianamente nella nostra pratica di software supply chain security, e contribuiamo come membri di OpenSSF¹⁸, CNCF e LF Europe alla definizione degli strumenti che rendono questa evidenza verificabile invece che dichiarata.

Hai bisogno di un confronto, un audit o una consulenza dedicata in ambito di sicurezza, DevSecOps, adeguamento al CRA? Contatta i nostri esperti.

Note e fonti

Drupal 12.0.0 è pianificato per la settimana del 7 dicembre 2026¹. Due giorni dopo, il 9 dicembre 2026, Drupal 10 raggiunge l’End of Life. Sono queste due date insieme, non la nuova major in sé, l’informazione che riscrive l’ordine delle priorità di un piano IT per i prossimi quattro trimestri.

I requisiti di piattaforma sono già ufficiali: PHP 8.5 come runtime minimo, Argon2id come algoritmo di hashing delle password di default, sei moduli che escono dal core. Significa che la preparazione è un’attività eseguibile oggi, non un’emergenza da gestire a ridosso del rilascio.

L’upgrade a Drupal 12 non è un progetto di migrazione: è un progetto di modernizzazione infrastrutturale e di bonifica del codice custom. Come tale, e a seconda della versione di partenza, va avviato con mesi di anticipo, non nelle settimane che precedono il rilascio. Seguono i requisiti verificati, il calendario ufficiale delle milestone, una checklist operativa con gli owner tipici di ciascuna attività e il motivo per cui le novità AI del core arrivano prima di dicembre 2026.

Cosa cambia davvero con Drupal 12: requisiti, sicurezza e core più snello

Drupal 12 alza il runtime minimo a PHP 8.5, adotta Argon2id per l’hashing delle password, rimuove sei moduli dal core e richiede Composer 2.9.3 come versione raccomandata. Non è una riscrittura architetturale: è la rimozione del codice deprecato accumulato durante il ciclo di Drupal 11.

Vale la pena leggere anche la colonna di ciò che non cambia. Lo strato web server e la browser policy restano stabili: nessuna migrazione dell’infrastruttura di rete, nessun intervento su reverse proxy, ingress controller o CDN.

Un discorso a parte merita Drush², per anni lo standard de facto dell’amministrazione da riga di comando, nato per colmare i limiti importanti della CLI di Drupal core. Oggi la direzione si è invertita: Drupal 11.4 introduce una CLI nativa estensibile (vendor/bin/dr), con cui i moduli possono registrare comandi direttamente nel core³, e la community ha già pubblicato una guida ufficiale per il porting dei comandi Drush verso la nuova interfaccia⁴.

L’intenzione dichiarata è scrivere direttamente comandi Drupal, ed è quindi verosimile che con Drupal 12 la migrazione sia completa. Allo stesso tempo, la prima stesura della documentazione di upgrade a Drupal 12⁵ mostra negli snippet di esempio Drush 13, segno che il supporto potrebbe proseguire. Su questo punto non c’è ancora alcuna conferma ufficiale: bisognerà attendere il consolidarsi della documentazione per capire come evolverà.

Riguardo Drush, bisogna specificare che non vi è un’indicazione precisa di versione, ma nella prima stesura della documentazione per upgrade a Drupal 12⁵, gli snippet di codice di esempio indicano Drush 13.

Sul fronte sicurezza, il passaggio da bcrypt ad Argon2id⁶ è la modifica più interessante. Argon2id è un algoritmo memory-hard: satura deliberatamente la RAM durante il calcolo dell’hash, rendendo inefficaci gli attacchi bruteforce accelerati via GPU, che sono esattamente il punto debole di bcrypt. Il re-hashing degli hash esistenti avviene in modo trasparente al primo login di ciascun utente, con fallback automatico a bcrypt se l’ambiente PHP non ha il supporto necessario: nessun reset forzato delle password, nessun downtime.

Qui si apre una nota che la documentazione ufficiale non copre. Le immagini container PHP devono includere il supporto libsodium o l’estensione argon2, altrimenti il sito resta silenziosamente su bcrypt senza alcun errore visibile. E i pod PHP-FPM vanno rivisti nei limiti di memoria, perché i picchi di autenticazione consumano più RAM di prima. Chi lavora in settori regolamentati troverà utile il quadro più ampio su come il core di Drupal risponde ai requisiti di conformità e protezione dei dati, perché la riduzione della superficie d’attacco è parte della stessa strategia.

Sei moduli lasciano il core e passano a contrib (Ban, Contact, Field Layout, History, Migrate Drupal e Migrate Drupal UI): se il sito ne usa anche uno solo, la sostituzione o l’installazione da contrib va messa in roadmap adesso, non a upgrade avviato (soprattutto se il sito usa Contact per i form istituzionali, lato business è una priorità). I benefici di un core più leggero sono concreti: meno superficie d’attacco, build più leggere, suite CI/CD più rapide.

Completano il quadro Gin come tema di amministrazione di default e l’allineamento a Symfony 8, dato che le major pari di Drupal sono ancorate alle release LTS (Long Term Support) di Symfony: un argomento rilevante per chi cerca cicli di vita estesi.

Quando esce Drupal 12 e perché la vera scadenza è Drupal 10?

Drupal 12.0.0 esce nella settimana del 7 dicembre 2026, in parallelo a Drupal 11.5.0. Drupal 10 va in End of Life il 9 dicembre 2026⁷. Drupal 11 resta supportato fino a metà-fine 2028. Chi è su Drupal 10 ha una scadenza reale a fine 2026; chi è già su Drupal 11 ha circa due anni di margine.

Le milestone verificabili del ciclo sono quattro:

1. 11 settembre 2026: deadline per il completamento dei requisiti beta.
2. Settimana del 14 settembre 2026: rilascio di Drupal 12.0.0-beta1 e 11.5.0-beta1.
3. Settimana del 9 novembre 2026: rilascio di rc1 per entrambe le linee.
4. Settimana del 7 dicembre 2026: release stabile.

Le finestre di manutenzione restano fisse: bugfix il primo mercoledì del mese, security release il terzo mercoledì. Questa prevedibilità con dodici-ventiquattro mesi di anticipo è un argomento raramente esplicitato nei confronti con le DXP proprietarie, e per un IT Director vale più di qualsiasi feature: permette di allocare budget su esercizi già approvati.

Il rischio reale, però, non è arrivare tardi a Drupal 12. È il doppio salto. La versione sorgente minima per l’upgrade è Drupal 11.3.0⁸, perché tutti gli update script precedenti sono stati rimossi dal codice di Drupal 12.

Chi si presenta a dicembre 2026 con un’installazione Drupal 10 deve eseguire due passaggi in sequenza sotto pressione, non uno. Le lezioni dei cicli precedenti, dal supporto a Drupal 7 terminato il 5 gennaio 2025 a Drupal 9 chiuso a novembre 2023⁹, sono le stesse che avevamo già raccolto nell’analisi della transizione verso Drupal 10: il costo di un upgrade cresce con il ritardo, non con la distanza tecnica tra le versioni.

La sovrapposizione tra Drupal 11 e Drupal 12 è quindi una leva di governance, non un dettaglio. Con Drupal 11 supportato fino a metà-fine 2028 e le deprecazioni più impattanti di Drupal 11.3 rinviate a Drupal 13, l’upgrade rientra nella manutenzione evolutiva ordinaria. Traduzione a budget: chi è su Drupal 10 deve chiudere il passaggio a Drupal 11 entro il Q3 2026, per non sovrapporlo alla finestra di release di dicembre.

Come preparare oggi un sito Drupal all’upgrade a Drupal 12?

La preparazione si articola in quattro attività parallelizzabili: portare il sito su Drupal 11.3 o superiore, eseguire un audit delle API deprecate con Upgrade Status e Drupal Rector, aggiornare runtime e immagini container a PHP 8.5, integrare i controlli di compatibilità nella pipeline CI/CD. Nessuna delle quattro richiede di attendere il rilascio.

La checklist operativa, con l’owner tipico di ciascuna voce:

1. Allineamento a Drupal 11.3.0 o superiore (tech lead Drupal): è il prerequisito non negoziabile.
2. Audit del codice custom e dei moduli contrib con Upgrade Status (tech lead + sviluppatori): produce l’inventario delle deprecazioni.
3. Refactoring automatico con Drupal Rector¹⁰ (sviluppatori): applica le regole di trasformazione sul codice.
4. Aggiornamento delle immagini container a PHP 8.5 (team platform/DevOps), con verifica delle estensioni necessarie ad Argon2id.
5. Verifica dei database gestiti (team platform): RDS/Aurora e Cloud SQL rispetto alle nuove versioni minime di MariaDB e PostgreSQL.
6. Sostituzione dei sei moduli core rimossi (analista + sviluppatori), a partire da Contact.

Il dato che riduce la percezione di rischio è la copertura del Project Update Bot: oltre l’80% delle API deprecate di Drupal 12 è gestito da regole Rector automatizzate¹¹, alcune generate con il supporto dell’AI, con patch inviate direttamente alle issue queue e controllo finale in mano ai maintainer.

Ma quell'80% riguarda l’ecosistema contrib. Sul codice custom enterprise, dove si concentrano sia il valore sia il debito, la copertura automatica è più bassa: integrazioni proprietarie, temi custom, moduli scritti su misura sono ciò che determina davvero durata e costo dell’upgrade.

È il punto in cui finisce lo script e inizia l’ingegneria. I temi custom vanno verificati contro Gin e contro le nuove Styles API e Design Tokens API introdotte da Drupal 11.3 e 11.4¹², che spostano il theming fuori dall’applicazione. I moduli custom vanno coperti da test automatizzati eseguiti in pipeline. E la gestione delle dipendenze Composer va trattata come questione di software supply chain security, non solo di build: la stessa Composer 2.9.3¹³ raccomandata da Drupal 12 nasce da una patch di sicurezza. Il quadro metodologico completo per la bonifica del codice lo abbiamo raccolto nella guida alla pianificazione degli upgrade e alla migrazione verso Drupal CMS.

Una nota dalla nostra esperienza: abbiamo gestito diversi progetti enterprise di upgrade, come nel caso di Caleffi dove abbiamo curato il passaggio da Drupal 7 a Drupal 10 e successivamente a Drupal 11. In questo contesto, abbiamo anche rilasciato come open source il modulo Drush pre-deploy, che permette di eseguire hook custom prima di update:db durante i rilasci multi-ambiente¹⁴. È esattamente il tipo di controllo che trasforma un upgrade di major version da evento manuale a operazione ripetibile.

L’ondata AI del core: perché Drupal 11.4 è il ponte verso Drupal 12

Le funzionalità che cambieranno il modo di lavorare sui progetti Drupal, AI workflows, Context Control Centre, nuove API di design, non arrivano con Drupal 12: arrivano nelle minor release di Drupal 11. Chi aggiorna oggi ottiene le novità funzionali e prepara l’upgrade in un unico ciclo di lavoro.

Il malinteso da smontare è antico: le major release di Drupal oggi rimuovono codice deprecato, non introducono feature. Per un decision maker la conseguenza è concreta: rimandare l’aggiornamento “in attesa di Drupal 12” significa rinunciare per dodici mesi a funzionalità già disponibili, senza guadagnare un grammo di stabilità.

Cosa è già disponibile o in arrivo nel core e nell’ecosistema:

• Centinaia di moduli AI (già un anno fa, quando è stata annunciata la Drupal AI Initiative, i moduli erano 290+).

• Il Context Control Centre di Drupal CMS 2.1, basato su core 11.3, che codifica una volta sola brand voice, design system e requisiti normativi, così che ogni output AI resti allineato agli standard di compliance¹⁵.

• Il pattern Human in the Loop come governance raccomandata: l’AI produce draft, le persone approvano prima della pubblicazione¹⁶.

• L’integrazione nativa di HTMX¹⁷ in Drupal 11.3¹⁸, che riduce fino al 71% il payload JavaScript¹⁹ delle interazioni browser-server prendendo il posto dell’API AJAX di Drupal; BigPipe resta invece al suo posto, perché risolve un problema diverso, il rendering progressivo lato server.

• Drupal Canvas, il page builder visuale a componenti, e l’interfaccia a riga di comando nativa sperimentale di Drupal 11.4²⁰.

C’è poi il dato che parla al CFO: Drupal core 11.3 (su cui è basato Drupal CMS 2.1) ha introdotto il maggiore performance boost degli ultimi dieci anni dell’ecosistema²¹, riducendo del 50% le query al database sulle pagine non in cache e ottimizzando sostanzialmente altre operazioni, con impatto diretto sui costi infrastrutturali cloud e sulla gestione dei picchi di traffico²². Un beneficio che si incassa aggiornando le minor, non attendendo Drupal 12 a dicembre.

Sul versante contributi, puoi già beneficiare del sistema di Guardrails che abbiamo contribuito nel modulo Drupal AI 1.3: un’architettura che intercetta e filtra le comunicazioni con i LLM applicando regole di validazione pre e post-elaborazione, bloccando l’esposizione di dati sensibili²³. Allo stesso ambito appartiene search_api_typesense, il nostro modulo per la ricerca semantica. Il tema è approfondito in verticale nella panoramica sull’evoluzione di Drupal AI e sull’integrazione dei modelli LLM. Ulteriori annunci sono attesi a DrupalCon Rotterdam, dal 28 settembre al 1 ottobre 2026.

La disciplina è la stessa su entrambi i piani: il processo di aggiornamento continuo che porta le funzionalità AI in produzione è ciò che rende l’upgrade a Drupal 12 un non-evento.

Cosa mettere in roadmap adesso

1. Se sei su Drupal 10 (o precedente), l’upgrade a Drupal 11 va chiuso entro il Q3 2026: dopo, la finestra si sovrappone alla release di dicembre.
2. Se sei su Drupal 11, avvia nei prossimi due trimestri l’audit delle deprecazioni e l’aggiornamento dei container a PHP 8.5.
3. In entrambi i casi, funzionalità AI e nuove API di design si incassano aggiornando le minor, non aspettando dicembre 2026.

Se il vostro processo di rilascio Drupal non è automatizzato in CI/CD con test di compatibilità, l’upgrade a Drupal 12 non sarà un problema di codice: sarà un problema di organizzazione. La documentazione e le guide ufficiali di upgrade da Drupal 11 a 12 coprono i comandi. Non coprono però l’infrastruttura, né il vostro codice custom.

Per un assessment di readiness su codice custom, temi e infrastruttura, parla con il nostro team Drupal: come Drupal Gold Certified Partner con competenze Cloud Native interne, valutiamo insieme cosa va fatto e in quale trimestre.

Note e fonti

Drupal¹ alimenta circa il 14% dei primi 10.000 siti web al mondo². Un dato notevole, in controtendenza con la flessione del CMS nel mercato generalista. La domanda per chi valuta la piattaforma oggi è concreta: cosa cambia davvero con la nuova strategia, e conviene puntarci per un progetto enterprise o mid-market?

Il lancio di Drupal CMS il 15 gennaio 2025, in coincidenza con il 24° compleanno del progetto e la fine del supporto a Drupal 7³, ha segnato una discontinuità. Con la Product Strategy 2.0⁴ pubblicata a giugno 2026, la Drupal Association ha ridefinito la rotta: Drupal CMS 2.0 adotta un approccio agentic-first e apre al mercato medio, senza rinunciare alla solidità enterprise che resta il suo mercato core.

Recipes, Drupal Canvas e AI nativa non sono etichette di marketing. La tesi di questo articolo, dalla nostra prospettiva di contributor storico del progetto, è semplice: semplificare non significa banalizzare, ma potenziare chi costruisce.

Cos’è Drupal CMS e cosa cambia con la strategia 2.0?

Drupal CMS⁵ è una distribuzione pronta all’uso costruita sopra Drupal Core, nata come progetto Starshot ad agosto 2024. Mentre Drupal Core è il framework flessibile pensato per gli sviluppatori, Drupal CMS aggiunge flussi guidati, componenti predefiniti e installazione dal browser, così che anche un profilo non tecnico possa avviare un sito in minuti anziché giornate.

La confusione terminologica tra i due livelli è il punto più cercato da chi si avvicina alla piattaforma. Chiarirlo è dirimente: si sceglie il Core quando serve costruire su misura, si sceglie la distribuzione quando conta il time-to-value. Abbiamo analizzato questo posizionamento in modo esteso spiegando come Drupal CMS ridefinisce il content management per il business, utile a chi deve inquadrare la transizione tecnologica.

Il cuore della semplificazione sono le Recipes⁶: pacchetti di configurazione dichiarativi, definiti in file recipe.yml, che combinano moduli, configurazioni e contenuti di esempio. Non sono limitate all’installazione: si applicano in qualsiasi momento del ciclo di vita del progetto. Renderle possibili ha richiesto lo sviluppo di 4 nuove API integrate nel core. Tramite il Project Browser, un utente può assemblare un sito eventi in pochi minuti installando ricette e moduli senza scrivere codice⁷.

Le tre novità che qualificano la strategia 2.0 rispetto a Starshot sono:

• Recipes e Site Templates⁸, per un onboarding guidato e un time-to-value ridotto;

• Drupal Canvas⁹ per il site building visuale drag-and-drop;

• Drupal AI¹⁰ e l’hosting integrato, con distribuzione semplificata (installabile anche in locale via DDEV).

Il salto tra le due versioni è concreto: la strategia iniziale di Starshot puntava alla facilità d’uso, la 2.0 amplia lo scope a hosting, distribuzione e AI, estendendo la timeline a giugno 2028¹¹. Dalla nostra esperienza sul campo, i componenti predefiniti e i flussi guidati riducono fino al 40% i tempi di implementazione.

Perché l’approccio agentic-first ridefinisce il ruolo del CMS?

Agentic-first significa progettare ogni workflow del CMS perché possa essere operato da un agente AI, non aggiungere un widget che genera testo nell’editor. L’AI diventa infrastruttura: opera dentro tassonomie, permessi e workflow approvativi, con l’essere umano che mantiene la supervisione su qualità e governance. È un cambio di ruolo del CMS, da contenitore a piattaforma orchestrabile.

L’AI in un CMS è una feature o un’infrastruttura? La roadmap di Drupal risponde in modo netto: ogni processo interno deve essere nativamente pronto per essere orchestrato da agenti intelligenti. Abbiamo lavorato a questa visione fin dalle prime fasi di Starshot, contribuendo in particolare alla Drupal AI Initiative con la creazione di agenti AI e del sistema di guardrails, la scrittura di test, il miglioramento della documentazione e la produzione di ricette¹².

Questa idea di Drupal AI come tessuto connettivo, e non come assistente scollegato, è al centro del nuovo approccio agentic-first allo sviluppo Drupal, dove il ruolo del CTO evolve verso l’orchestrazione di agenti.

La governance è la condizione perché tutto questo funzioni in produzione. Drupal la struttura su tre pilastri:

• Context Control Center¹³: definizione centralizzata di brand, persona e topic assegnati ai modelli, così che l’output resti coerente con le linee guida aziendali;

• Human in the Loop: l’AI genera draft, le persone revisionano e approvano prima della pubblicazione, appoggiandosi ai moduli Workflow e Content Moderation nativi;

• versionamento e audit dei contenuti generati, per mantenere ogni modifica trasparente e reversibile.

Qui emerge il gap che i decisori enterprise devono presidiare. Dove girano i modelli? Le API dei LLM esterni hanno un costo per token e sollevano rischi di data leakage, con implicazioni su GDPR e EU AI Act. La scelta tra modelli esterni (come quelli integrati in CKEditor per i suggerimenti di contenuto) e modelli self-hosted su architetture cloud native diventa una decisione di conformità, non solo tecnica. I guardrails servono esattamente a questo: definire cosa l’AI può e non può fare.

L’AI come colmatore di skill gap, non generatore di rumore

L’AI integrata in Drupal non serve a produrre più contenuti, ma contenuti migliori. Democratizza competenze verticali (SEO, copywriting, accessibilità) che spesso mancano nei team editoriali, elevando lo standard qualitativo complessivo.

Il rischio opposto è concreto: velocità senza controllo qualità equivale a rischio per il brand. Un CMS che inonda i canali di testi piatti peggiora il sovraccarico informativo invece di risolverlo.

L’obiettivo dichiarato è produrre valore, non volume, e l’architettura governata di Drupal è la gabbia di regole che lo rende possibile. Inoltre, in Drupal l’AI è vista come un catalizzatore delle competenze umane, non un sostituto delle persone.

La spinta verso il mid-market rafforza o indebolisce l’enterprise?

L’apertura al mid-market non è un ripiego, ma un investimento nella vitalità dell’ecosistema. L’enterprise resta il mercato core di Drupal, dove la piattaforma vanta una penetrazione inusuale tra le organizzazioni con oltre 10.000 dipendenti. Attrarre progetti medi allarga la base di contributori e sviluppatori senza intaccare la robustezza che serve ai grandi.

Il segmento a cui si vuole aprire maggiormente, dichiarato dalla strategia 2.0, sono progetti mid-market, con budget complessivi tra 30.000 e 120.000 dollari (circa 25.000-100.000 euro). Drupal non punta ai siti entry-level né compete con i website builder di fascia bassa, che restano esplicitamente fuori target: l’obiettivo è colmare il divario tra quei siti e le grandi architetture enterprise, offrendo un time-to-value ridotto tramite Site Templates pronti all’uso.

Per un decisore, i numeri che contano sono economici e di solidità:

• Risparmi fino al 60-80% sul TCO triennale rispetto ad altre soluzioni come Adobe Experience Manager, grazie all’eliminazione delle licenze annuali¹⁴;

• un ecosistema di oltre 10.000 sviluppatori attivi a livello globale, con migliaia di moduli pronti all’uso¹⁵;

• natura open source e assenza di vendor lock-in¹⁶, con controllo su codice, dati e roadmap come asset di sovranità digitale.

L’enterprise resta il core per ragioni verificabili. The Economist, la NASA e l’Università di Oxford usano Drupal per le loro digital experience¹⁷. L’American Medical Association ha consolidato siti WordPress e Drupal in un’unica piattaforma. Il caso Nestlé¹⁸, presentato alla DrupalCon Vienna 2025, mostra un design system multi-brand strutturato su tre livelli (core, UI components, brand overrides) che governa oltre 100 siti e permette di istanziare nuovi progetti in giorni invece che settimane. Sono scenari che validano i vantaggi architetturali e di sicurezza che rendono Drupal la scelta per siti aziendali complessi, gli stessi che ora la strategia 2.0 estende al mid-market.

Vuoi ottenere risultati simili per la tua organizzazione? Parla con i nostri specialisti per progettare una transizione su misura a Drupal. 

Canvas, Display Builder e la flessibilità come vero differenziatore

La semplificazione del site building non impone un solo strumento. Drupal Canvas assume un ruolo centrale nella roadmap per l’editing visuale, ma la flessibilità storica di Drupal offre alternative come Display Builder¹⁹ per progetti con esigenze diverse. Non un percorso obbligato, ma opzioni architetturali che si scelgono in base al progetto.

Il Visual Builder, o Experience Builder, unifica Layout Builder e Paragraphs in un’interfaccia drag-and-drop che consente di installare, configurare ed estendere Drupal interamente dal browser²⁰. Canvas è la direzione centrale della roadmap, e ne abbiamo visto l’uso in produzione, insieme ai design system nativi e all’AI enterprise, tra le novità pratiche emerse alla DrupalCon Vienna 2025.

La flessibilità è sempre stata il punto di forza di Drupal, e qui si gioca la differenziazione. All’evento Drupal X Business²¹ abbiamo esplorato Display Builder come alternativa pensata per contesti enterprise con design system complessi, che richiedono controllo granulare sul layout. La scelta pratica dipende dal contesto:

• Drupal Canvas quando serve autonomia editoriale e velocità di assemblaggio delle pagine da parte di team di business;

• Display Builder quando il progetto ha un design system articolato e richiede controllo fine su componenti e struttura.

Il futuro del theming rafforza questa flessibilità. Drupal 11.3 e 11.4²² introducono la Styles API²³ (con utilities per typography, colors, spacing e un sistema di themes & modes) e la Design Tokens API²⁴ (con scoped values che diventano variabili CSS solo a runtime), preparando il terreno per l’arrivo di Drupal 12 previsto per dicembre 2026²⁵, di cui iniziano già a circolare le prime notizie e a cui dedicheremo presto un articolo dedicato.

L’obiettivo è separare il theming dall’applicazione e automatizzare il workflow da Figma al browser, un vantaggio diretto per la coerenza multi-brand e l’accessibilità (WCAG 2.1 AA, European Accessibility Act).

A questo si aggiunge il supporto nativo ad architetture headless, tradizionali o ibride via REST, JSON:API e GraphQL, che distingue Drupal dai headless puri come Contentful, Strapi e Storyblok²⁶. È questa modularità, non un singolo tool, il differenziatore competitivo duraturo. 

Cosa significa per chi valuta Drupal CMS oggi

La Product Strategy 2.0 non banalizza Drupal: potenzia chi lo costruisce, agenzie e sviluppatori, per consegnare valore ai team di business più rapidamente. Chi valuta la piattaforma oggi dovrebbe leggere il cambiamento su tre assi.

• Agentic-first come infrastruttura governata, non come feature: l’AI opera dentro workflow, permessi e pattern Human in the Loop, con la conformità (GDPR, EU AI Act) come vincolo di progetto.

• Apertura al mid-market che dà vitalità senza intaccare l’enterprise, con un TCO fino al 60-80% inferiore ad AEM e un ecosistema open source privo di vendor lock-in.

• Flessibilità architettonica tra Canvas e Display Builder come differenziatore che sopravvive alle mode.

Per massimizzare il ROI della tua presenza digitale, pianifica una migrazione a Drupal o richiedi una valutazione della tua architettura al nostro team. Come contributor storici del progetto e primi Drupal Gold Certified Partner in Italia, ti forniremo un piano d’azione chiaro per ottimizzare le performance, ridurre il debito tecnico e garantire la conformità normativa. 

Note e fonti

Chi risponde legalmente della vulnerabilità di una libreria scaricata da un repository pubblico, mantenuta gratuitamente da un contributore volontario, quando quella libreria finisce nel cuore di un prodotto commerciale marcato CE? Con il Cyber Resilience Act questa domanda smette di essere teorica e diventa un problema di gestione del rischio per ogni CTO europeo.

Le tecnologie open source sono utilizzate dal 90% delle organizzazioni a livello mondiale, secondo la Linux Foundation¹. Non si tratta di un dettaglio marginale: uno studio della stessa Linux Foundation del 2022 stima che il 70-90% di qualsiasi codebase moderna sia composto da componenti free e open source.² In modo simile, il report Synopsys 2024 indica che il 96% delle codebase commerciali contiene open source software ed il 77% di tutto il codice di quelle stesse codebase esaminate originava da codice open source.³

In altre parole: il software che le aziende vendono, in larga parte, non lo hanno scritto loro.

Qui nasce la tensione centrale del Cyber Resilience Act (CRA): il regolamento europeo introduce responsabilità legali su prodotti costruiti in gran parte su componenti che, formalmente, nessuno “possiede”. Quando integri decine di librerie in un prodotto commerciale, di chi è la responsabilità della vulnerabilità? La risposta non è più ovvia.

In questo articolo chiariamo cosa cambia per chi usa e contribuisce all’open source, quali rischi ricadono concretamente sull’azienda e come strutturare una governance della supply chain software conforme al CRA, senza smettere di beneficiare del vantaggio competitivo che il codice aperto garantisce.

Cosa si intende per open source e il software è davvero gratuito?

L’open source è software il cui codice sorgente è pubblicamente accessibile, modificabile e ridistribuibile secondo licenze approvate dalla Open Source Initiative (OSI). Ma accessibilità gratuita del codice non significa costo zero: il costo si sposta su integrazione, manutenzione, sicurezza e conformità. Chi confonde “libero” con “gratuito” sottostima proprio le voci che il CRA ora rende obbligatorie.

La distinzione tra i termini conta più di quanto sembri. Il software libero, nell’accezione della Free Software Foundation (FSF) fondata da Richard Stallman, mette al centro le libertà dell’utente e adotta licenze copyleft come la GNU General Public License (GPL), che obbliga a ridistribuire le opere derivate alle stesse condizioni. L’open source, promosso dalla OSI, ammette anche licenze più permissive orientate all’adozione commerciale. Il software proprietario chiude invece il codice e trasferisce al vendor la responsabilità operativa, al prezzo del vendor lock-in.

La pervasività dell’open source nelle aziende è concreta e quotidiana, ben oltre gli ambienti tecnici:

• Sistemi ERP e CRM open source che gestiscono processi core aziendali (con soluzioni come Odoo o Dolibarr ERP CRM che sfidano i vendor tradizionali).

• Applicazioni intranet open source per la collaborazione interna e la gestione documentale.

• Software di auditing informatico open source per il monitoraggio continuo della sicurezza e la compliance.

• Suite di office applications alternative alle piattaforme proprietarie, come gli storici Apache OpenOffice e LibreOffice, o il nuovo Euro-Office lanciato a giugno 2026.

• Software open source per la gestione finanziaria (ad esempio Money Manager Ex) e piattaforme e-commerce flessibili.

Sotto questa superficie applicativa opera un’infrastruttura interamente aperta: Linux come sistema operativo dei server, Kubernetes per l’orchestrazione dei container sotto l’egida della Cloud Native Computing Foundation, Apache Kafka per lo streaming dei dati, Ansible per l’automazione. La visione dell’open source come bene pubblico e leva di sovranità, che in SparkFabrik consideriamo il fondamento del nostro sviluppo software, nasce proprio dal riconoscere che questo strato invisibile regge l’intera economia digitale.

Open source, software libero o proprietario: la tabella di confronto

La lettura strategica è netta: l’open source riduce il vendor lock-in ma redistribuisce la responsabilità operativa e di sicurezza sull’utilizzatore. È esattamente questo spostamento che il CRA formalizza sul piano giuridico.

Come il Cyber Resilience Act ridistribuisce le responsabilità sull’open source

Il CRA introduce la figura dell’open source steward e trasferisce gli obblighi di sicurezza su chi immette prodotti sul mercato, non su chi sviluppa codice in modo collaborativo. Ma la formulazione originale del regolamento non tracciava questa linea con chiarezza, rischiando di coinvolgere anche i contributori upstream in responsabilità che non potevano ragionevolmente sostenere.

Il nodo giuridico è stato illustrato con efficacia da Mirko Boehm della Linux Foundation Europe: il CRA, nella sua prima versione, non distingueva tra lo sviluppo collaborativo a monte e l’immissione di un prodotto sul mercato, e non limitava la responsabilità all’uso previsto. Un contributore volontario avrebbe potuto rispondere di vulnerabilità anche in scenari d’uso del tutto imprevisti, come nel caso paradossale di un frammento di codice che finisse per controllare una centrale nucleare. È il tipo di rischio che ha allarmato l’intera community, un dibattito che abbiamo ricostruito analizzando le preoccupazioni del mondo open source.

Perché le fondazioni non possono semplicemente assorbire questi obblighi? Per una ragione economica ben documentata. Molti progetti open source non ricevono alcun finanziamento e, anche distribuendo equamente i fondi disponibili su tutti i progetti, si arriverebbe a poco più di 250.000 dollari ciascuno: una cifra che basta forse a pagare un community manager e a organizzare qualche meetup, non certo a mantenere personale di sicurezza a tempo pieno.⁴ Inoltre, come chiarisce la Linux Foundation Europe, quei fondi arrivano inoltre vincolati a progetti specifici dai donatori (donor-directed funds), al punto che nemmeno la fondazione stessa potrebbe dirottarli per risolvere i problemi di sicurezza di un altro progetto; e le altre fondazioni open source dispongono spesso di risorse ancora più limitate.

Caricare i maintainer open source degli obblighi di security-by-design del CRA⁵, in una fase in cui la sostenibilità di lungo termine di molti progetti è già messa in discussione dagli stessi contributori, rischia di rivelarsi controproducente.

La risposta è stata l’iniziativa #FixTheCRA, coordinata da Linux Foundation Europe su cinque fronti: proposta di emendamenti tramite Open Forum Europe, divulgazione delle criticità, una lettera aperta firmata da una coalizione di fondazioni open source, tavole rotonde con le istituzioni europee (con panel a KubeCon Europe e all’Open Source Summit) e la creazione di sedi di collaborazione permanenti. SparkFabrik partecipa a questo ecosistema come membro di Linux Foundation Europe e di OpenSSF⁶, e il nostro CTO Paolo Mainardi siede nell’Advisory Board di LF Europe.

Chi risponde delle vulnerabilità: upstream, steward o produttore?

Il CRA distingue tre ruoli con responsabilità diverse:

• Contributore upstream: sviluppa codice in modo collaborativo, fuori da logiche commerciali. È escluso dagli obblighi diretti del regolamento.

• Open source steward: figura nuova introdotta dal CRA, con obblighi ridotti e proporzionati (tipicamente fondazioni e organizzazioni che sostengono progetti).

• Produttore commerciale: chi immette il prodotto sul mercato con la marcatura CE. Si assume la piena responsabilità legale della sicurezza.

Il takeaway per il decision maker è diretto: se la tua azienda integra open source in un prodotto commerciale, la responsabilità legale ricade su di te, non sul progetto upstream. La marcatura CE certifica che sei tu a garantire la conformità dell’intero stack, dipendenze incluse.

Quali rischi corrono le aziende europee che costruiscono sull’open source?

I rischi principali sono tre: l’aumento dei costi di conformità a carico soprattutto delle PMI, il possibile ritiro di software dal mercato UE da parte delle community e l’impatto su iniziative europee di sovranità digitale. Sono rischi che colpiscono in modo asimmetrico proprio chi usa l’open source per competere.

Analizzati per livello, i rischi si articolano così:

• Rischio economico: il CRA potrebbe imporre costi aggiuntivi sull’uso e sui contributi open source principalmente a carico delle imprese europee, penalizzando le PMI che sull’innovazione aperta fondano la propria capacità di competere con i grandi operatori storici.

• Rischio di continuità della supply chain: le community potrebbero rifiutarsi di rendere disponibile software nell’UE, lasciando la distribuzione a intermediari commerciali extra-UE, con impatto su Gaia-X⁷, SovereignEdge⁸, e Next Generation Internet⁹.

• Rischio strategico: le classi di prodotti critici del CRA coincidono con le tecnologie open source fondamentali.

Questo terzo punto merita attenzione, perché contiene un paradosso. La Classe II del CRA, soggetta a requisiti di sicurezza tra i più severi, include sistemi operativi per server, hypervisor e runtime dei container: esattamente le tecnologie aperte che reggono l’infrastruttura cloud europea. Abbiamo approfondito questa tensione tra normativa e competitività nell’analisi su come il CRA incide sull’autonomia strategica dell’Unione.

Il paradosso si acuisce sul fronte del cloud sovrano. Offerte come AWS European Sovereign Cloud, Google S3NS e il progetto Bleu si presentano come europee, ma restano architetturalmente controllate da hyperscaler non europei¹⁰. In questo quadro l’open source, e non l’etichetta “sovrano” apposta su tecnologie proprietarie, resta la leva reale di indipendenza tecnologica per le organizzazioni del continente. Per un CTO europeo, questo significa privilegiare stack basati su tecnologie open source verificabili nella propria strategia di procurement cloud.

Come gestire le responsabilità open source in modo conforme al CRA

Gestire le responsabilità significa passare dal consumo passivo dell’open source a una governance strutturata: inventario delle dipendenze, security-by-design, contributo attivo ai progetti e trasparenza documentale verso il mercato. Non è un adempimento burocratico, ma un cambiamento nel modo in cui l’azienda concepisce la propria supply chain software.

Il primo pilastro è la governance della supply chain. Serve visibilità totale sulle dipendenze, incluse quelle transitive che nessuno ha selezionato consapevolmente. Su questo terreno la nostra esperienza è diretta: SparkFabrik è maintainer di DruBOM, un modulo Drupal che integra Anchore Syft per generare la Software Bill of Materials completa di un’installazione, dipendenze PHP e JavaScript comprese. È lo stesso approccio che abbiamo descritto parlando di come mappare i rischi delle dipendenze per la marcatura CE.

Il secondo pilastro è metodologico. Uno sviluppo software conforme al CRA richiede controlli di sicurezza integrati fin dalle prime fasi, non aggiunti a posteriori. In SparkFabrik pratichiamo un principio di security enablement over enforcement: la sicurezza non è un gate imposto a valle dai team di compliance, ma una capacità messa nelle mani degli sviluppatori, che diventano attori consapevoli della postura di sicurezza del prodotto.

Il terzo pilastro è culturale: passare da utilizzatori a contributori. Sachiko Muto, nel contesto di Drupal4GovEU, ha sostenuto che le istituzioni devono partecipare ai progetti aperti contribuendo con i propri sviluppatori, non solo finanziandoli¹¹. È la stessa filosofia sintetizzata da Paolo Mainardi, CTO di SparkFabrik¹²:

“Open Source is a public good that must be supported and funded in a new, modern way: like public infrastructure”.

Contribuire attivamente riduce il rischio strategico e rafforza la sostenibilità dei progetti da cui l’azienda dipende.

In termini operativi, il percorso ad alto livello si articola in cinque passi:

1. Mappare tutte le dipendenze, dirette e transitive, con strumenti di analisi composizionale.
2. Classificare i prodotti per classe di rischio secondo il perimetro del CRA.
3. Integrare i controlli di sicurezza nel ciclo di sviluppo, in ottica DevSecOps.
4. Definire policy di aggiornamento e disclosure delle vulnerabilità.
5. Contribuire upstream ai progetti critici per la propria attività.

Vale la pena notare che l’apertura non riguarda solo l’infrastruttura tradizionale, ma si estende al duplice rapporto tra open source e intelligenza artificiale. Da un lato, l’AI permette di gestire progetti aperti su una scala senza precedenti, consentendo a un singolo sviluppatore di raggiungere in poco tempo la produttività di un intero team; dall’altro, l’open source accelera il progresso stesso dell’AI attraverso modelli e framework condivisi. Il 72% degli sviluppatori, secondo il sondaggio Stack Overflow 2024, dichiara una posizione favorevole all’uso di strumenti AI nel proprio workflow¹³. Integrare questi nuovi componenti generativi nei propri prodotti commerciali significa ereditare ulteriori dipendenze: la governance che costruisci oggi dovrà reggere anche questa complessità, garantendo che l’adozione dell’AI rispetti i medesimi obblighi di tracciabilità e sicurezza imposti dal CRA.

Dalla dipendenza passiva alla governance dell’open source

Il CRA non è una minaccia all’open source, ma un acceleratore verso una gestione matura delle responsabilità della supply chain software. Il regolamento formalizza sul piano legale una verità che i team tecnici conoscono da tempo: chi vende un prodotto ne risponde interamente, comprese le parti che ha ereditato dal codice aperto.

Le aziende che strutturano oggi una governance dell’open source, con inventario delle dipendenze, sicurezza integrata by design e contributo attivo ai progetti da cui dipendono, trasformano un obbligo normativo in vantaggio competitivo e in leva concreta di sovranità digitale. È la differenza tra subire la conformità e usarla come acceleratore di qualità.

Nel prossimo articolo della serie affronteremo come gestire la complessità di Software Bill of Materials multiple in progetti grandi e multi-servizio, tra i formati SPDX e CycloneDX e l’automazione delle dipendenze transitive.

Se vuoi valutare la maturità della tua supply chain open source e pianificare l’adeguamento normativo, il nostro percorso di supporto sul Cyber Resilience Act mette a disposizione l’esperienza di un team KCSP, membro CNCF, Linux Foundation Europe e OpenSSF. Contattaci e parlaci delle tue sfide. 

Note e fonti

La sicurezza della catena di fornitura del software è in cima alle priorità di sicurezza per il 2026, e analisti come Gartner e vendor specializzati come Chainguard convergono su un punto: gli attacchi alla supply chain non sono più un’eventualità remota, ma il vettore d’ingresso preferenziale. Il problema non è più sapere cosa proteggere, ma come renderlo automatico e dimostrabile.

Con il Cyber Resilience Act¹ la conformità smette di essere un audit annuale e diventa un processo continuo che vive dentro le pipeline. Il regolamento UE impone aggiornamenti di sicurezza per almeno cinque anni e la notifica delle vulnerabilità sfruttate entro 24 ore (come previsto dall’articolo 14)², obblighi incompatibili con verifiche manuali sporadiche. Non a caso il legislatore europeo si è mosso dopo che la criminalità informatica ha superato un costo globale di 5,5 trilioni di euro l’anno già nel 2021³, con proiezioni che stimano 10,5 trilioni di dollari nel 2025 e 15,63 trilioni nel 2029⁴.

La scala del debito tecnico rende il problema concreto. Il rapporto OSSRA 2024 rilevava che il 91% dei codebases esaminati conteneva componenti arretrati di dieci versioni o più⁵. Nell’edizione 2026 del rapporto OSSRA, il debito resta reale: il 41% dei componenti nelle codebases è arretrato di dieci versioni o più, il 22% di sei-dieci versioni e il 18% di tre-cinque (solo il 7% è all’ultima versione). Questi dati vanno letti in un contesto in cui la complessità delle codebases aumenta (+35% file count YoY), il numero di componenti aumenta (+30% YoY) ed il numero di vulnerabilità per singola codebase è più che raddoppiato (+107% YoY).⁶ È chiaro quindi che ripetere una verifica manuale di questo debito tecnico per ogni release, moltiplicata per cinque anni di supporto obbligatorio, è semplicemente insostenibile.

Automatizzare scanner e policy non basta. La responsabilità legale resta in capo al produttore anche quando è una pipeline a eseguire il controllo. Un’automazione architetturalmente corretta e auditabile richiede criteri rigorosi di selezione degli strumenti, integrazione nativa nei processi di sviluppo e la consapevolezza che la delega tecnica non trasferisce l’onere legale.

Cosa significa automatizzare la compliance al Cyber Resilience Act in una pipeline cloud native?

Automatizzare la compliance CRA significa trasformare gli obblighi normativi (generazione della SBOM, scansione delle vulnerabilità, firma degli artefatti e blocco dei rilasci non conformi) in controlli eseguiti automaticamente a ogni commit e deployment, integrandoli nel ciclo di vita del software anziché applicarli a valle come verifica documentale.

Il fondamento metodologico risiede nell’evoluzione delle pratiche operative, dove i controlli di sicurezza anticipano la fase di rilascio per integrarsi direttamente nella pipeline. Questo approccio, noto come DevSecOps, traduce in pratica il principio normativo della security-by-design. Abbiamo descritto in dettaglio come questo modello integri la sicurezza nel ciclo di vita del software in un’analisi dedicata al DevSecOps applicato al cloud, che chiarisce perché i controlli automatizzati aumentino la velocità di rilascio invece di frenarla.

Il secondo concetto chiave è la continuous compliance. Il CRA impone supporto e aggiornamenti di sicurezza per almeno cinque anni o per la vita utile del prodotto. La conformità diventa quindi uno stato da mantenere, non un traguardo da raggiungere una volta. Una libreria sicura oggi può ospitare una CVE critica domani. Le pipeline diventano il braccio operativo che rivaluta la conformità a ogni build, intercettando la deriva prima che raggiunga la produzione.

In pratica, quattro obblighi normativi si traducono in meccanismi operativi. La generazione della SBOM avviene a ogni build producendo un formato versionato e leggibile dalle macchine. Parallelamente, la scansione delle vulnerabilità note incrocia i componenti con i database delle CVE. Il processo richiede poi la firma e la verifica della provenienza degli artefatti immessi sul mercato, culminando nell’enforcement delle policy di deployment per bloccare i rilasci che violano i requisiti.

L’impatto operativo è misurabile. Secondo la nostra esperienza, un approccio strutturato con integrazione nelle pipeline CI/CD, identificazione delle dipendenze dirette e transitive, incrocio con i database delle vulnerabilità e validazione continua, riduce il tempo medio di risoluzione delle vulnerabilità (MTTR) fino all'80%⁷.

Quali strumenti scegliere per il monitoraggio automatico della conformità?

Gli strumenti chiave per il monitoraggio CRA in ambiente cloud native sono Syft per la generazione della SBOM, Trivy o Grype per la scansione delle vulnerabilità, Cosign e Sigstore per la firma e la verifica della provenienza degli artefatti, e OPA Gatekeeper o Kyverno per bloccare i deployment non conformi su Kubernetes.

La selezione degli strumenti richiede criteri architetturali rigorosi. Adottare una soluzione solo per la sua popolarità genera rapidamente debito operativo. I parametri che valutiamo nei nostri progetti sono cinque: integrazione nativa con la pipeline CI/CD esistente, supporto ai formati SBOM standard come SPDX e CycloneDX, capacità di firma verificabile, modello di enforcement (admission control in produzione contro scanning a build time) e, soprattutto, generazione di evidenze auditabili persistenti.

Generazione SBOM e scansione delle vulnerabilità

Syft⁸, sviluppato da Anchore, produce SBOM in formati standard a partire da immagini container e filesystem, mantenendo separati il momento dell’inventario e quello dell’analisi. La scansione vera e propria spetta a Trivy di Aqua Security⁹ o a Grype, che incrociano i componenti rilevati con i database delle CVE.

La distinzione operativa rilevante è tra scansione del filesystem, delle immagini container e delle dipendenze transitive. Quest’ultima è spesso la più insidiosa, perché un componente vulnerabile entra tramite una dipendenza di terzo livello che nessuno ha dichiarato esplicitamente. Il trade-off da governare è il rumore: una soglia troppo aggressiva genera falsi positivi che paralizzano la delivery, una troppo permissiva vanifica la copertura. La prioritizzazione per severità e contesto è la leva per mantenere il segnale affidabile.

Firma degli artefatti e provenienza

Cosign, parte del progetto Sigstore¹⁰, firma le immagini dei container e garantisce integrità e provenienza, con workflow sia key-based sia keyless basati su chiavi effimere e un log di trasparenza a prova di manomissione. Questo allinea la pipeline al framework SLSA per l’integrità degli artefatti.

Per il CRA la firma è centrale perché dimostra la catena di custodia degli artefatti immessi sul mercato. Un’immagine firmata e verificabile è la prova tecnica che il prodotto distribuito è quello costruito dalla pipeline, non un binario alterato a valle. Essendo membri di CNCF e OpenSSF, abbiamo costruito competenza diretta su questi strumenti, condivisa anche in un evento tecnico verticale sulla software supply chain security dedicato all’uso operativo di Sigstore e Kyverno.

Policy enforcement su Kubernetes

OPA Gatekeeper e Kyverno operano come admission controller. Intercettano le richieste di deployment e bloccano in tempo reale i container privi di firma valida o con vulnerabilità critiche, prima che raggiungano il cluster. È il punto in cui la policy smette di essere una raccomandazione e diventa un vincolo applicato.

La scelta tra i due dipende da chi gestisce le policy. OPA Gatekeeper usa Rego, un linguaggio espressivo ma con una curva di apprendimento ripida. Kyverno, policy engine CNCF graduated, definisce policy native Kubernetes in YAML, risultando più leggibile per team compliance non specializzati in linguaggi di policy. Il criterio decisionale si basa su quanto le policy debbano restare ispezionabili da chi risponde dell’audit.

Come integrare i controlli di policy as code nelle pipeline DevSecOps

I controlli si integrano definendo policy as code versionate nello stesso repository del codice, eseguendole come gate bloccanti nelle pipeline CI/CD e applicandole in produzione tramite admission controller su Kubernetes. Questo approccio GitOps rende ogni modifica tracciabile e dimostrabile agli enti certificatori.

Il flusso end-to-end attraversa stadi precisi, producendo per ciascuno un’evidenza persistente. Il commit del codice innesca la pipeline, avviando la generazione della SBOM con Syft sull’artefatto appena costruito. Subito dopo, Trivy o Grype eseguono la scansione delle vulnerabilità contro i database CVE. Se i controlli passano, l’immagine viene firmata con Cosign e registrata nel log di trasparenza Sigstore. Un gate di policy in CI valuta i risultati complessivi per decidere se autorizzare il proseguimento, lasciando infine all’admission control al deployment, gestito da Kyverno o OPA Gatekeeper, il compito di verificare firma e conformità prima dell’ingresso effettivo nel cluster.

L’approccio GitOps garantisce che la compliance sia ripetibile. Le policy vivono in un repository versionato, ogni modifica passa da pull request e review, ogni decisione lascia una traccia firmata. Questo è esattamente il livello di rigore richiesto per i prodotti che il CRA classifica come critici: container runtime e hypervisor rientrano nell’Allegato III come prodotti di Classe II ad alto rischio¹¹, soggetta ad audit obbligatorio da enti certificatori indipendenti. Il modello architetturale di riferimento per impostare questi controlli è descritto nel white paper della CNCF sulla sicurezza cloud native, che fornisce il framework di alto livello su cui costruire le policy concrete.

Il trade-off operativo più delicato è tra gate bloccanti e gate informativi. Bloccare ogni singola vulnerabilità ferma la delivery e spinge i team ad aggirare i controlli; informare soltanto, senza bloccare, vanifica la compliance perché nessuno agisce sui report. La strategia che adottiamo è il blocco selettivo per severità e contesto: si bloccano le vulnerabilità critiche con exploit noto e gli artefatti non firmati, si segnalano le altre con SLA di remediation. Il platform engineering riduce il carico cognitivo fornendo pipeline pre-configurate che rendono la conformità lo stato di default.

Perché l’automazione non trasferisce la responsabilità legale del CRA?

Automatizzare scanner e policy nelle pipeline non sposta la responsabilità legale dal produttore allo strumento. Il CRA attribuisce la responsabilità a chi immette il prodotto sul mercato: anche se è una pipeline a eseguire il controllo, è l’azienda a rispondere delle vulnerabilità e a rischiare le sanzioni.

Il principio normativo stabilisce che il produttore resta responsabile della conformità anche quando il controllo è delegato a un sistema automatico o a un modello di AI. Le sanzioni, definite all’articolo 64, rendono concreto il rischio, fino a 15 milioni di euro o al 2,5% del fatturato annuo globale, a seconda di quale valore sia superiore, oltre alla possibilità per le autorità di imporre il ritiro del prodotto dal mercato¹². Comprendere se il proprio software rientra nelle classi di rischio più severe è il prerequisito di qualsiasi strategia di automazione. Abbiamo dedicato un’analisi alle classi di rischio del CRA e alle responsabilità dei produttori che inquadra dove cade ciascun prodotto.

La conseguenza architetturale impone che l’automazione sia auditabile. Non basta che la pipeline esegua i controlli, deve produrre evidenze immutabili e tracciabili che dimostrino la due diligence in caso di incidente o audit. Nei progetti enterprise questo significa conservare:

• SBOM versionate per ogni release, riconducibili al commit che le ha generate.

• Report di scansione archiviati con timestamp e database CVE di riferimento.

• Firme e log di trasparenza Sigstore che attestano la provenienza degli artefatti.

• Log delle decisioni di policy, firmati, che documentano cosa è stato bloccato e perché.

Queste evidenze permettono di rispondere agli obblighi CRA di notifica delle vulnerabilità sfruttate entro i tempi stretti previsti dal regolamento, dimostrando di aver agito con diligenza.

Esiste inoltre il tema della responsabilità condivisa in ambiente cloud native, dove convivono chi sviluppa il codice, chi gestisce la piattaforma e chi opera in produzione. Policy as code e admission control definiscono confini espliciti tra questi ruoli e riducono l’errore umano, perché il vincolo è codificato e non affidato alla disciplina del singolo. Il nostro CTO, Paolo Mainardi¹³, è Advisory Member della Linux Foundation Europe e ha contribuito all’iniziativa #FixTheCRA, nata per conciliare i requisiti di sicurezza del regolamento con la sostenibilità dell’ecosistema open source¹⁴.

Conclusione

La compliance CRA automatizzata non è un costo, ma un acceleratore di qualità che riduce il debito tecnico e abbassa il tempo medio di risoluzione delle vulnerabilità. Il filo conduttore richiede strumenti adeguati, integrazione nativa nelle pipeline ed evidenze auditabili. Sganciare uno di questi tre elementi compromette l’intero impianto.

Se la tua pipeline esegue scanner ma non conserva evidenze firmate e versionate, non sei pronto per un audit CRA, indipendentemente da quanti tool hai integrato. La differenza tra un’automazione che protegge l’azienda e una che genera solo rumore risiede nella tracciabilità persistente di ogni decisione.

Tradurre questi criteri in una strategia tecnica affidabile richiede competenze trasversali tra cloud native, sicurezza e compliance, un profilo che abbiamo sintetizzato nei requisiti per scegliere un partner tecnologico nella transizione cloud native. Se vuoi valutare la maturità della tua pipeline rispetto agli obblighi CRA, il team SparkFabrik può aiutarti a identificare i gap architetturali prima delle scadenze del 2027: scopri i nostri servizi di supply chain security o contatta i nostri esperti.

Nel prossimo articolo della serie, dedicato alla distinzione tra contributori open source e produttori commerciali secondo il CRA, analizzeremo come si ripartisce la responsabilità lungo la catena dei componenti e perché la differenza tra contribuire e immettere sul mercato cambia radicalmente gli obblighi: dal 90% stimato di prodotti in autovalutazione fino agli scenari in cui un singolo contributor upstream rischia di essere chiamato a rispondere di un uso del tutto inatteso del proprio codice¹⁵.

Note e fonti

I team di sicurezza che si affidano a scansioni trimestrali e fogli di calcolo non possono fisicamente rispettare la finestra di 24 ore per la notifica degli exploit attivi. L’automazione della gestione dei rischi costituisce oggi un vincolo legale per operare nel mercato europeo.

Il Cyber Resilience Act (CRA), naturale evoluzione delle direttive nate con l’EU Cyber Security Act, vincola l’accesso al mercato europeo a rigidi standard di sicurezza¹. Inserendo i sistemi operativi per server e i runtime dei container nella classe II dei prodotti critici², il regolamento sottopone i componenti base delle infrastrutture moderne ai controlli più severi previsti dalla legge.

Il rapporto OSSRA 2024 evidenzia come il 91% dei repository contenga componenti arretrati di almeno 10 versioni³. Tracciare le vulnerabilità su questi volumi per mantenere la marcatura CE supera le capacità di qualsiasi team umano.

Implementare un vulnerability management continuo guidato dall’AI permette di affidare ai sistemi di machine learning l’analisi massiva dei dati. Integrare l’apprendimento automatico nei flussi di lavoro sposta il controllo di sicurezza da un evento isolato a una metrica di processo, a patto di misurare con precisione l’affidabilità dei modelli decisionali impiegati.

Perché il vulnerability management reattivo non basta più per il Cyber Resilience Act?

Il vulnerability management reattivo fallisce sotto il Cyber Resilience Act perché la normativa impone la notifica degli exploit attivi entro 24 ore per l’intero ciclo di vita del prodotto. Le tradizionali scansioni periodiche generano ritardi inaccettabili, esponendo l’azienda a sanzioni fino a 15 milioni di euro e al blocco delle vendite.

L’Articolo 14 del regolamento definisce tempistiche inflessibili di reporting verso ENISA⁴ e i CSIRT nazionali. Il legislatore europeo ha eliminato la distinzione tra sviluppo e manutenzione, obbligando i produttori a garantire standard di sicurezza costanti anche anni dopo il rilascio iniziale.

Per inquadrare il perimetro normativo e capire quali responsabilità ricadono sul produttore, abbiamo già spiegato come identificare le classi di rischio previste dal CRA in un articolo dedicato di questa serie.

Il rischio economico colpisce direttamente la continuità di business, poiché le autorità nazionali ottengono il potere di imporre il ritiro del prodotto e il divieto di immissione sul mercato europeo⁵. A questo si aggiungono multe per la mancata conformità ai requisiti essenziali di sicurezza che arrivano fino a 15 milioni di euro o al 2,5% del fatturato annuo globale dell’azienda, a seconda di quale valore sia superiore.

Di fronte a migliaia di dipendenze software stratificate nel tempo, il volume di CVE (Common Vulnerabilities and Exposures) da valutare manualmente cresce più velocemente della capacità di remediation. Il backlog si accumula, dilatando il MTTR (Mean Time To Remediation), ovvero il tempo medio che intercorre tra la scoperta di una vulnerabilità e la sua risoluzione. Una scansione trimestrale lascia scoperte settimane in cui un exploit attivo può colpire i sistemi. La prioritizzazione manuale risulta inoltre soggetta a bias cognitivi, portando gli analisti a sovrastimare i CVE noti e a sottostimare quelli contestuali. Senza una mappa dell’esposizione reale, ogni vulnerabilità sembra ugualmente urgente, e ricostruire la catena causale di un incidente in poche ore risulta matematicamente impossibile.

Come l’AI trasforma il vulnerability management in un processo continuo

L’intelligenza artificiale trasforma il vulnerability management automatizzando la prioritizzazione e riducendo i falsi positivi. Correlando i CVE con l’effettiva esposizione del codice in produzione, l’AI permette ai team di concentrarsi sui rischi reali, abbattendo il tempo medio di risoluzione e garantendo il rispetto delle finestre di notifica normative.

Nel nostro approccio su progetti fintech complessi nel 2023, gestendo oltre 400 repository e migliaia di CVE storici, l’integrazione di automazione e correlazione contestuale ha generato metriche di efficienza misurabili. Nella nostra esperienza, partendo da un baseline di 14 giorni, riteniamo che il flusso strutturato abbia abbattuto il MTTR a meno di 48 ore, con una riduzione che stimiamo intorno all'80%. Questo risultato deriva da un processo che incrocia identificazione delle dipendenze, database delle vulnerabilità e validazione continua con blocco selettivo. La base tecnologica risiede nell’automazione del ciclo di vita del software, un terreno che abbiamo esplorato analizzando come l’intelligenza artificiale ridisegna le pipeline DevOps e i processi di sicurezza.

Il flusso AI-driven opera in quattro fasi sequenziali:

1. Ingestione: raccolta continua di SBOM, log e dati di runtime dalle pipeline e dagli ambienti di produzione.
2. Correlazione: incrocio automatico dei componenti con i database di vulnerabilità e gli indicatori di exploit attivi.
3. Prioritizzazione: ranking dei CVE in base all’impatto reale sul prodotto, non alla sola severità teorica.
4. Notifica: generazione dell’audit trail necessario a rispettare le tempistiche di reporting verso ENISA.

Prioritizzazione intelligente e riduzione del rumore

La prioritizzazione contestuale distingue un alert utile dal rumore di fondo. L’AI correla ogni CVE con il contesto reale di esposizione, verificando se l’asset si trova in produzione, se il codice vulnerabile viene effettivamente richiamato dal flusso applicativo e se esiste un exploit attivo in circolazione.

Sullo stesso programma fintech del 2023, dove gli scanner sui 400 repository producevano in media oltre un migliaio di segnalazioni a settimana, la correlazione contestuale ha tagliato di circa due terzi il volume di alert che richiedevano un intervento umano. Invece di smistare manualmente centinaia di segnalazioni indifferenziate, il team interveniva esclusivamente sulle falle con impatto reale sul prodotto soggetto a marcatura CE.

Monitoraggio continuo e detection delle anomalie

I modelli di anomaly detection osservano i comportamenti runtime e segnalano le deviazioni rispetto a un baseline appreso. Questo meccanismo anticipa lo sfruttamento di vulnerabilità non ancora catalogate, spostando la postura di sicurezza da reattiva a proattiva.

La normativa DORA⁶, rilevante per chi opera nel settore finanziario, presenta dinamiche simili. Entrambe le direttive spingono verso il monitoraggio continuo del rischio digitale, ma con un focus diverso, come abbiamo analizzato esaminando l’impatto di NIS2 e DORA sulla cybersecurity cloud native.

Il CRA guarda al prodotto, mentre DORA guarda all’entità. Un’azienda finanziaria che sviluppa software ricade spesso sotto entrambi, rendendo il monitoraggio continuo un doppio obbligo legale.

Cosa significa observability dell’AI e perché conta per la conformità?

L’observability ai consiste nel monitorare costantemente la qualità dei dati, il drift dei modelli e l’affidabilità degli output decisionali. Per la conformità normativa, sorvegliare i sistemi intelligenti è obbligatorio: un modello degradato che genera falsi negativi espone il prodotto a vulnerabilità non rilevate, compromettendo la marcatura CE.

L’artificial intelligence observability assicura che gli strumenti di automazione non introducano nuovi punti ciechi. Un sistema che classifica male le vulnerabilità produce un danno attivo, ignorando minacce che dovrebbe bloccare. La ML observability diventa quindi parte integrante della catena di sicurezza. L’introduzione di modelli AI nei processi difensivi richiede trasparenza e gestione del rischio, poiché il produttore deve rendere conto delle decisioni automatizzate per mantenere la conformità.

Monitorare i modelli che monitorano la sicurezza

Tre segnali definiscono lo stato di salute di un modello applicato alla sicurezza: data quality monitoring, drift detection e spiegabilità degli output. Il drift risulta particolarmente insidioso perché agisce in silenzio. Un modello addestrato su un certo profilo di minacce degrada man mano che le tipologie di attacco evolvono, senza generare errori evidenti nei log tradizionali.

La categoria della data observability, rappresentata sul mercato da strumenti come IBM databand⁷, nasce proprio per sorvegliare le pipeline dati che alimentano i modelli. Per approfondire le strategie di controllo sui sistemi probabilistici abbiamo descritto come governare e monitorare gli agenti AI in produzione, un tema che si applica con la stessa logica ai tool di sicurezza.

Guardrails e tracciabilità delle decisioni automatizzate

La conformità richiede la dimostrazione documentata di come una specifica vulnerabilità viene classificata e gestita. Servono un audit trail delle decisioni AI e guardrails che impediscano azioni automatiche non verificate, soprattutto quando l’esito influenza la validità della marcatura CE.

Il nostro approccio di security-by-design stabilisce che l’automazione deve abilitare i team, mantenendo il controllo umano sulle decisioni critiche. Occorre monitorare la qualità dei dati in ingresso al modello e misurare il drift rispetto al baseline di addestramento. Diventa altrettanto importante valutare la latenza decisionale tra rilevazione e classificazione, tenendo sotto stretto controllo il tasso di falsi negativi.

Implementare il vulnerability management continuo: cosa serve davvero

L’implementazione richiede un percorso strutturato: acquisizione della visibilità totale sulle dipendenze tramite SBOM, automazione della prioritizzazione dei rischi e monitoraggio continuo dei modelli AI. Questo approccio trasforma l’adeguamento normativo in un processo integrato nelle pipeline DevSecOps, evitando i colli di bottiglia tipici dei controlli manuali.

La prima fase parte dall’inventario delle dipendenze. Abbiamo approfondito questo aspetto spiegando come la Software Bill of Materials mappa i rischi della supply chain sotto il CRA: senza una SBOM aggiornata, qualsiasi automazione lavora su dati incompleti. I rischi gestionali richiedono attenzione immediata, poiché affidarsi ciecamente all’AI senza supervisione umana trasforma uno strumento di mitigazione in un single point of failure. Seguono la qualità insufficiente dei dati di addestramento e l’attrito nell’integrazione con le pipeline DevSecOps esistenti. In questi flussi, i security gate devono bloccare i rilasci non conformi senza paralizzare la velocità di sviluppo.

La conciliazione tra requisiti CRA e sostenibilità operativa vede il nostro team direttamente coinvolto. Il nostro CTO Paolo Mainardi è Advisory Member di Linux Foundation Europe⁸ e ha sostenuto l’iniziativa #FixTheCRA, nata per evitare che il regolamento penalizzi l’ecosistema open source⁹. Fondazioni come Apache Software Foundation e Eclipse Foundation hanno espresso forti critiche al testo iniziale, per poi accogliere positivamente gli emendamenti di fine 2023¹⁰.

Misurare la maturità reale del processo richiede indicatori precisi:

• Inventario delle dipendenze aggiornato e versionato (SBOM).

• Misurazione del MTTR come metrica di processo effettiva e non come semplice stima.

• Pipeline CI/CD con security gate attivi e bloccanti.

• Monitoraggio continuo dei modelli AI impiegati.

• Processo di notifica capace di operare entro le rigide tempistiche normative.

L’assenza di uno solo di questi requisiti mantiene aperta l’esposizione al rischio legale.

Conclusione e prossimi passi

Automatizzare la gestione delle vulnerabilità tramite l’AI trasforma la conformità al Cyber Resilience Act in un processo sostenibile, eliminando la corsa contro il tempo a ogni nuovo CVE.

Le sanzioni fino a 15 milioni di euro definiscono chiaramente il rischio aziendale. Al contempo, la riduzione del tempo medio di risoluzione (MTTR) dell'80% quantifica il ritorno sull’investimento tecnico.

Valutare la maturità del proprio processo richiede l’analisi dell’inventario, la misurazione del MTTR e la verifica dei modelli AI in uso. Per trasformare questa valutazione in una strategia operativa lungo l’intera filiera, i nostri specialisti possono accompagnarti nella messa in sicurezza della software supply chain.

Il prossimo articolo della serie affronta i criteri architetturali e strategici per scegliere e implementare soluzioni software capaci di mantenere la conformità CE per l’intero ciclo di vita del prodotto, fornendo linee guida agnostiche per la selezione degli strumenti.

Note e fonti

Alla fine di ogni edizione del PHPDay c’è un rituale che si ripete: qualcuno, da qualche parte, sta scrivendo l’ennesimo necrologio del linguaggio. E ogni volta torniamo a casa con la stessa convinzione, nemmeno questa volta PHP è morto. Non è una battuta consolatoria. È quello che si è visto sul palco dell’edizione 2026: un processo di rilascio governato con disciplina, framework agentici in piena competizione, real-time spinto fino a QUIC, e una community che decide consapevolmente quando rompere il proprio passato.

La narrazione del declino di PHP rispetto a Python e Node.js si trascina da anni. È comoda, perché si appoggia ai ranking di popolarità, e fragile, perché confonde la moda con la maturità. La vitalità di un linguaggio non si misura su quante nuove leve lo scelgono per il primo progetto, ma sulla qualità del processo con cui evolve e sulla solidità degli strumenti che lo circondano.

Il PHPDay 2026¹ è stato esattamente questo: una fotografia di un ecosistema adulto. Attraversiamo i talk che lo raccontano meglio, partendo dalla domanda più scomoda di tutte: come decide di evolvere un linguaggio vivo?

Un linguaggio che evolve è un linguaggio che decide come rompere il proprio passato

La prima prova di maturità non è una feature. È un processo.

In “Shipping PHP 8.5”, Volker, release manager di PHP 8.5², ha fatto una cosa rara per un talk tecnico: ha parlato meno delle novità del linguaggio e più del come si decide cosa entra in una release e come la si “spedisce”. La nuova estensione nativa per la gestione degli URI conforme a RFC 3986³, per esempio, non nasce da una scelta individuale ma da un percorso pubblico di proposta, discussione e voto. Capire questo meccanismo conta più di memorizzare la singola funzione: dice che PHP non viene “gestito” da un vendor, ma deliberato da una comunità.

Quel meccanismo è diventato palpabile nel “Panel: the future of PHP”, dove Volker, Gary, Gina, Derick e Sara hanno discusso proposte ancora aperte: i generics con type erasure, le scope functions e il pattern matching. Si può essere d’accordo o meno con ogni singola RFC, ma il messaggio del panel era inequivocabile: PHP evolve grazie alla sua community, e l’invito a iscriversi alla mailing list e contribuire non era retorica, era una richiesta operativa.

Il keynote di chiusura di Gina, “Progress lies within Backwards Compatibility breaks”, ha messo a fuoco la verità che spesso preferiamo ignorare: rompere la backwards compatibility è il prezzo necessario e inevitabile del progresso. Gina ha usato analogie con altri settori, il trasporto ferroviario, l’elettricità, che a volte ricostruiscono intere infrastrutture per semplificare le integrazioni e ridurre i costi di manutenzione nel lungo periodo. Trattare le breaking changes come incidenti significa condannarsi al debito tecnico; trattarle come investimenti significa progettare per durare.

Chi gestisce PHP in produzione conosce bene questa dinamica. Quando Drupal 10⁴ è uscito il 14 dicembre 2022 adottando Symfony 6⁵ e alzando il requisito minimo a PHP 8.1⁶, l’intero ecosistema ha dovuto adeguarsi. È un caso reale di come l’evoluzione del linguaggio si propaghi sui grandi CMS, un tema che approfondiamo parlando della nuova era del content management con Drupal CMS. E proprio qui sta la differenza tra subire una breaking change e governarla: strumenti come Rector per il refactoring automatico, PHPStan e Psalm per l’analisi statica permettono di individuare il codice deprecato prima della migrazione, trasformando un salto traumatico in un percorso pianificato.

Un linguaggio che si riprogetta non lo fa nel vuoto. Lo fa per stare sui fronti più caldi del software contemporaneo.

PHP sulle nuove frontiere: AI agentica e comunicazione real-time

L’ecosistema PHP si muove rapidamente sul terreno dei framework agentici. Un framework agentico, per chi non lavora con l’AI quotidianamente, è l’infrastruttura che permette a un Large Language Model di non limitarsi a rispondere, ma di compiere azioni: invocare strumenti, consultare fonti, orchestrare passaggi multipli verso un obiettivo.

Nel talk “The PHP AI Battleground: Choosing Your Agentic Framework”, il nostro Luca Lusso, lead developer di SparkFabrik, ha confrontato tre framework PHP promettenti per i workflow agentici: Laravel AI, Symfony AI e Neuron AI. Ognuno ha pro e contro, e nessuno è la risposta universale. Laravel AI si integra naturalmente con chi vive già nell’ecosistema Laravel; Symfony AI porta il rigore architetturale di Symfony nel dominio degli agenti; Neuron AI nasce più snello e focalizzato. La scelta dipende dallo stack già in uso e dai requisiti del workflow. (Approfondiamo il framework Neuron AI nel nostro webinar dedicato “Costruire agenti AI in PHP con Neuron AI”)

C’è chi legge questa pluralità come frammentazione. Noi la leggiamo all’opposto: tre framework concorrenti sono il segnale di un ecosistema in fermento, che sta scegliendo la propria direzione invece di subirla. Il punto critico arriva nella fase successiva: portare un agente in produzione significa governare un sistema probabilistico, e questo richiede pratiche di osservabilità dedicate, come quelle che descriviamo parlando di AgentOps, dal monitoraggio del consumo di token al rilevamento delle allucinazioni.

La stessa vitalità si è vista sul real-time. In “PHP’s Real-time Toolkit: All the Ways to Notify Clients”, Grzegorz ha ripercorso tutte le strade per spingere dati dal server al client: dal vecchio polling fino ai pattern moderni come WebSocket e Server-Sent Events (SSE), indicando come futuro il WebTransport basato su QUIC⁷ su HTTP/3. Nel suo intervento ha citato Mercure, presentato come soluzione basata sul meccanismo dei Server-Sent Events, e due alternative più strutturate:

• Centrifugo: una piattaforma che supporta molti protocolli, scala bene e gestisce fallback automatici, al prezzo di dover far girare un server separato.

• Nchan: un modulo Nginx concettualmente simile a Centrifugo, ma decisamente più scalabile.

Anche qui, la varietà non è dispersione. È un ecosistema che offre lo strumento giusto per ogni vincolo di scala e infrastruttura.

L’innovazione senza solidità resta fragile. La vera maturità di PHP nel 2026 si vede nei dettagli ingegneristici meno appariscenti.

La maturità sta nei dettagli: dati, serializzazione e resilienza

Ciò che rende un linguaggio adatto alla produzione non sono le feature di facciata. È la capacità di gestire dati a volume, performance ed errori con disciplina. Il PHPDay 2026 ha dedicato a questi temi alcuni dei talk più densi, proprio quelli che non finiscono mai sui titoli.

Si parte dal dato grezzo. In “Data Processing in PHP”, Norbert ha mostrato come estrarre e processare grandi volumi di dati in modo efficiente ed economico, partendo dalle funzioni native di PHP per gestire un semplice file CSV fino a processi ETL completi costruiti con flow-php, lo strumento che ha sviluppato. Il messaggio: PHP regge carichi di dati seri, se sai come strutturare il flusso.

Poi c’è il problema della velocità. Michelle, in “Advanced Serializing in PHP: Speed it up!”, ha confrontato diverse tecniche di serializzazione partendo da un dato controintuitivo: il Symfony Serializer è il più potente ma anche il più lento, perché usa la reflection per accedere allo stato degli oggetti a runtime. La soluzione è spostare la complessità al code time, generando codice PHP veloce, prima con liip/serializer e oggi con il suo successore rebuy-oss/serializer. Il team di Michelle è andato oltre, costruendo un convertitore da PHP a Go per eseguire la fase di serializzazione in Go e spremere ulteriore velocità. È il tipo di ingegneria che si fa solo quando un linguaggio è già in produzione su sistemi che contano.

Infine, la resilienza. In “Mastering Failures: Building Resilient PHP/Symfony Apps with Domain-Driven Exceptions”, Stephane ha insegnato i pattern corretti per le eccezioni di dominio in architetture Domain-Driven Design: non lanciare eccezioni generiche, non fare il parsing dei messaggi di errore per capire cosa è successo, definire un’eccezione specifica per ogni problema reale del dominio. Il suo consiglio più tagliente:

Non lanciare NotFoundHttpException dentro un dominio, perché lo stesso codice potrebbe girare anche in un’applicazione CLI.

È un dettaglio che separa un progetto giocattolo da un sistema enterprise, lo stesso rigore di disaccoppiamento che ritroviamo nelle scelte tra monolite e microservizi. Questi sono i temi su cui si misura se una community è adulta. E PHP, qui, lo è.

Ma PHP non è in declino rispetto a Python e Node? Il fattore che le classifiche ignorano

Affrontiamo l’obiezione più forte senza scappare. È vero: la percezione pubblica vede PHP in declino. I nuovi sviluppatori gravitano verso JavaScript e Python, l’AI e la data science hanno reso Python lo stack di default per intere categorie di progetti, e i ranking di popolarità raccontano una parabola discendente. Ignorarlo sarebbe disonesto.

Eppure le classifiche misurano la moda, non la maturità. I numeri raccontano un’altra storia: PHP resta il linguaggio server-side di circa il 77% dei siti web con un backend rilevabile, e da solo WordPress⁸ alimenta oltre il 43% del web. Aggiungendo Magento nell’e-commerce, Symfony e Laravel nell’enterprise, Drupal nei portali complessi, la presunta fine assume contorni piuttosto vivaci.

Il punto vero non sono nemmeno questi numeri. Sono i fondamentali.

In “Packets, Protocols and PHP: Networking Fundamentals for Developers”, Jessica ha guidato un tour dei layer di rete, dall’Application al Physical del modello OSI, con la verità che ogni sysadmin conosce: “it’s always DNS (or BGP, or more often, both)”. I fondamentali di rete non passano di moda e prescindono dal linguaggio. Chi li padroneggia è un ingegnere migliore, qualunque stack scelga.

La solidità di un ecosistema si legge nel suo tooling. Derick, creatore di Xdebug, in “Better Debugging With Xdebug” ha mostrato dal vivo le novità di Xdebug 3.5⁹: Native Path Mapping, out of band signalling, automatic line discovery e altro, come dettagliato nell’annuncio ufficiale. Un tool di debug così curato è la prova di una community che investe sulla qualità, non solo sulle feature. È lo stesso impegno che come Drupal Certified Partner Gold portiamo nel mantenimento di WebProfiler, il modulo di debug per Drupal con oltre 1.000 installazioni attive.

Il giudizio fa la differenza. Gary, in “It Depends”, ha condotto una sessione interattiva sulle decisioni critiche che ogni sviluppatore affronta ogni giorno: monolite o microservizi, codice scritto a mano o generato dall’AI, framework opinionated o non opinionated. La conclusione, onesta e disarmante, è il titolo stesso: alla fine, it depends. La maturità non è un dogma, è giudizio contestuale.

Infine, le persone. Carolina, psicologa, ha tenuto “Communication for devs: explaining complex ideas simply”, un keynote interattivo in cui abbiamo provato a migliorare la nostra capacità di spiegare: raccontare una storia al vicino di posto, usare un’analogia, inquadrare le idee dalla prospettiva di chi ascolta. Il segreto più importante, ha detto, è respirare.

Le classifiche misurano la popolarità. Un linguaggio adulto si misura sui fondamentali, sul tooling e sulle persone. Ed è esattamente su questi assi che PHP, nel 2026, è solidissimo.

Cosa resta del PHPDay 2026

“PHP non è morto” non è una rassicurazione difensiva. È la constatazione di un fatto: un linguaggio capace di rompere consapevolmente il proprio passato per progredire, come ha argomentato Gina, di competere sui framework agentici e sul real-time, e al tempo stesso di coltivare con disciplina i propri fondamentali, è un linguaggio profondamente vivo.

Il vero rischio non è la fine di PHP. È che la community smetta di partecipare. L’invito emerso dal panel, iscriversi alla mailing list, discutere le RFC, contribuire, non era un dettaglio cerimoniale: è il motore stesso che tiene il linguaggio in vita.

Dalla nostra esperienza su codebase PHP enterprise in produzione, questa lettura è la stessa che vediamo confermata ogni giorno sul campo. La domanda giusta, uscendo dal PHPDay 2026, non è “PHP è morto?”. È: abbiamo la maturità tecnica e umana per usarlo come merita?

Note e fonti

Un fornitore che afferma di essere “sicuro” e uno che esibisce un certificato accreditato con un numero pubblico controllabile sembrano dire la stessa cosa. Non è così. Il primo ti chiede di fidarti, il secondo ti permette di verificare. In fase di due diligence, è l’unica distinzione che protegge davvero chi sceglie.

Per questo è utile chiarire subito un punto: in tema di certificazioni e conformità normativa, i quattro pilastri di cui parliamo, sicurezza, sostenibilità, open source e accessibilità, non sono iniziative nate ieri. Sono processi che portiamo avanti da anni e che oggi hanno una prova esterna al posto di una dichiarazione interna. Le certificazioni ISO SparkFabrik e le validazioni scientifiche rendono questo impegno ispezionabile. Tutte le prove sono raccolte nella pagina che riunisce questi quattro impegni, pensata proprio perché chiunque possa controllare invece di credere sulla parola.

Sono quattro lenti diverse puntate sulla stessa idea. La prima, dove la verifica è più codificata, è la sicurezza.

Perché le certificazioni ISO SparkFabrik sono fondamentali per la sicurezza?

Le certificazioni ISO SparkFabrik (27001:2022, 27017:2015, 27018:2025) garantiscono che la sicurezza delle informazioni e dei dati nel cloud sia gestita tramite processi documentati e verificati da enti terzi. Valide dal 2026 al 2029 (certificato ITA-10325, rilasciate da Scandinavian Certification, accreditata Norwegian Accreditation), assicurano gestione del rischio, continuità operativa e supporto strutturato alla conformità GDPR.

Una certificazione ISO non certifica un prodotto, ma un sistema di gestione. È una distinzione che cambia tutto, e che molti comunicati aziendali confondono volentieri.

Quando un ente accreditato rilascia una ISO/IEC 27001:2022, non sta dicendo che un singolo software è sicuro in un dato momento. Sta attestando che esiste un processo documentato e ripetibile per gestire la sicurezza delle informazioni: come si identificano i rischi, come si reagisce agli incidenti, come si garantisce continuità. La sicurezza, in altre parole, non è un comportamento occasionale ma un metodo verificato.

SparkFabrik ha conseguito tre certificazioni complementari, che insieme coprono i piani su cui un cliente espone i propri dati quando affida un progetto a un partner esterno:

• ISO/IEC 27001:2022, per la sicurezza delle informazioni;

• ISO/IEC 27017:2015, per la sicurezza specifica degli ambienti cloud;

• ISO/IEC 27018:2025, per la protezione dei dati personali nel cloud.

Per chi valuta un fornitore, questo si traduce in tre garanzie concrete: gestione del rischio documentata, continuità del servizio anche in caso di incidente e un supporto strutturato alla conformità GDPR, il regolamento europeo che impone alle organizzazioni precisi obblighi sul trattamento dei dati personali. Un sistema di gestione certificato non rende automatica la conformità, ma fornisce l’impalcatura su cui costruirla.

Un dettaglio cruciale, spesso trascurato, riguarda l’accreditamento. Le nostre certificazioni sono state rilasciate da un organismo accreditato, con un certificato identificato da un codice univoco e una validità temporale precisa. Quei riferimenti non sono decorazione.

Una dichiarazione sul sito non si può controllare. Un numero di certificato rilasciato da un ente accreditato sì.

Chiunque, un security officer in fase di valutazione o un responsabile procurement, può risalire all’ente accreditante e verificare che la certificazione sia reale e attiva. Questa è la sostanza: non l’aver scritto “siamo sicuri”, ma l’aver reso quell’affermazione controllabile da un terzo indipendente. Il significato tecnico e metodologico di affidarsi a un partner con sistemi di gestione certificati ISO sta tutto in questa possibilità di ispezione.

La sicurezza si verifica con un audit periodico. Ma esiste un terreno dove la verifica è ancora più stringente, perché i numeri non finiscono in un report riservato: finiscono su un registro pubblico, validati con metodo scientifico.

Come si riconosce un impegno di sostenibilità aziendale reale?

Un impegno reale si riconosce dalla validazione scientifica indipendente e dalla presenza su registri pubblici. I target di riduzione emissioni di SparkFabrik sono validati dalla Science Based Targets initiative (SBTi ID 40017722), classificati 1.5°C-aligned, con anno base 2024 e target 2030. Questo rende l’impegno misurabile e verificabile.

Sulla sostenibilità il greenwashing è la regola, non l’eccezione. “Carbon neutral”, “green”, “a impatto zero” sono affermazioni che non costano nulla pronunciare e che quasi nessuno è in grado di smentire, perché manca il termine di paragone.

La differenza tra un impegno reale e uno dichiarato si riduce a un solo elemento: la validazione da parte di un ente scientifico indipendente e la presenza su un registro pubblico consultabile. Per valutare la sostenibilità di un’azienda software in modo credibile, non esistono scorciatoie alternative a questa.

I target di riduzione delle emissioni di SparkFabrik sono validati dalla Science Based Targets initiative attraverso il percorso semplificato dedicato alle PMI, e sono classificati come 1.5°C-aligned, cioè coerenti con l’obiettivo dell’Accordo di Parigi di contenere il riscaldamento globale entro 1,5°C. L’anno base è il 2024, l’anno target il 2030, e l’identificativo pubblico è SBTi ID 40017722.

I target, nel wording ufficiale, sono questi: Scope 1 emissioni a zero fino al 2030; Scope 2 riduzione assoluta del 42% entro il 2030 dall’anno base 2024; Scope 3 misurare e ridurre.

C’è un dato che, più di ogni dichiarazione, racconta cosa significhi misurare sul serio. Il 97% delle nostre emissioni totali ricade nello Scope 3, la categoria più difficile da controllare perché comprende le attività indirette. Le voci principali sono:

• pendolarismo e lavoro remoto (38%);

• trasferte (22%);

• acquisti IT (20%);

• beni strumentali (19%).

Dichiarare quel 97% è scomodo. Significa ammettere pubblicamente che la parte più consistente del proprio impatto sfugge al controllo diretto. È esattamente il contrario del greenwashing, che tende a esibire i numeri facili e a nascondere quelli difficili.

Sottoporsi a una metodologia scientifica con anno base, anno target e un ID pubblico significa accettare di essere misurati. E di poter fallire pubblicamente.

È questo che dà valore al numero. Chiunque può controllare l’ID 40017722 sul registro ufficiale delle aziende che hanno preso un impegno climatico validato e confrontare i target con i progressi. Lo stesso vale per il quadro completo del percorso, documentato sulla pagina dedicata alla nostra strategia di riduzione. Un numero che può essere smentito da un terzo è più affidabile di uno slogan che nessuno può contestare.

A questo punto un lettore scettico ha tutto il diritto di obiettare. Certificazioni e validazioni non sono comunque, alla fine, solo “bollini” da esibire nelle gare d’appalto? È un’obiezione seria, e merita una risposta seria.

Le certificazioni sono solo bollini di marketing?

No, se supportate da verifiche continue e contributi ispezionabili. Un audit ISO fallito comporta la revoca del certificato, dimostrando che i processi devono essere mantenuti. Inoltre, diciassette anni di contributi open source pubblici (dal 2008) offrono una trasparenza radicale e non falsificabile che nessun bollino di marketing può replicare.

Prendiamola nella sua versione più forte, senza addolcirla. Molte aziende collezionano certificazioni come trofei di marketing. Le ottengono una volta, mettono il logo in homepage, e nel frattempo i processi reali restano identici a prima. Il certificato diventa decorazione, non garanzia. L’audit annuale si trasforma in un esercizio formale da superare con il minimo sforzo.

Questa critica è legittima. Una certificazione ottenuta e poi disattesa è effettivamente un bollino, e fingere il contrario sarebbe disonesto. Il mantenimento della certificazione richiede audit periodici rigorosi: se durante queste verifiche emergono non-conformità gravi e i processi non vengono rispettati, l’ente accreditato revoca il certificato. Non è un traguardo acquisito per sempre, ma un esame continuo.

Tuttavia, serve una prova di serietà ulteriore che non si possa ottenere una tantum, che non si possa comprare e che non si possa falsificare nel tempo. Quella prova esiste, ed è il contributo pubblico verificabile. Il codice open source è la forma più trasparente di affidabilità, perché ogni commit è datato, pubblico e tracciabile da chiunque, per sempre. Non c’è modo di simularlo retroattivamente.

SparkFabrik realizza contributi pubblici open source dal 2008, seguendo un principio preciso: costruirlo, non limitarsi a usarlo. È una differenza sostanziale rispetto a chi adotta software libero solo per risparmiare sulle licenze. Questa scelta si riflette in credenziali tecniche concrete: siamo Drupal Certified Partner Gold, Kubernetes Certified Service Provider e membri di CNCF, Linux Foundation Europe e OpenSSF, le fondazioni che governano gli standard cloud native e la sicurezza del software open source. I moduli che pubblichiamo sono ispezionabili da chiunque sul profilo ufficiale SparkFabrik su drupal.org.

C’è di più, e tocca direttamente la sicurezza di cui parlavamo all’inizio. La partecipazione a OpenSSF e la mappatura dei rischi delle dipendenze software, al centro delle best practice per la sicurezza della filiera che abbiamo documentato, rispondono alla stessa logica di trasparenza verificabile richiesta da normative come il Cyber Resilience Act, che dal 2027 imporrà requisiti di sicurezza stringenti e documentati per tutto il software immesso sul mercato europeo.

Ed ecco il cuore della tesi. Una certificazione ISO e diciassette anni di commit pubblici dimostrano la stessa cosa da due direzioni opposte:

• la certificazione è una verifica top-down, in cui un ente terzo controlla i tuoi processi;

• l’open source è una verifica bottom-up, in cui chiunque può ispezionare il tuo lavoro, riga per riga.

Insieme rendono l’obiezione “è solo un bollino” insostenibile. Perché un bollino non lo si mantiene pubblico per diciassette anni. La verifica completa di questo approccio è raccolta nella pagina che documenta il nostro lavoro nel software libero.

Resta un pilastro che mette alla prova questa filosofia nel punto esatto in cui le aziende barano di più: l’accessibilità, troppo spesso aggiunta alla fine.

Cosa significa trattare l’accessibilità come requisito di progetto?

Significa integrare l’accessibilità fin dal primo giorno di design e sviluppo, rispettando gli standard WCAG 2.2 AA ed EN 301 549. Questo approccio metodologico garantisce una conformità reale all’European Accessibility Act (in vigore da giugno 2025), evitando soluzioni posticce e superficiali applicate a ridosso del lancio.

Immagina un sito reso “accessibile” la settimana prima del lancio, con uno script aggiunto sopra il sito che promette di sistemare tutto automaticamente. È l’equivalente digitale dell’azienda che colleziona bollini: una toppa applicata sopra un lavoro pensato senza alcuna attenzione a chi naviga con uno screen reader o senza usare il mouse.

L’accessibilità è il banco di prova definitivo della tesi, perché è il pilastro dove la distanza tra “dichiarato” e “fatto” è più visibile a occhio nudo. Una pagina costruita male non diventa accessibile applicando uno strato esterno: cambia solo l’apparenza per gli strumenti automatici di scansione, non l’esperienza reale delle persone.

In SparkFabrik trattiamo l’accessibilità come un requisito di progetto iniziale, non come un’aggiunta finale. La progettazione è conforme allo standard WCAG 2.2 AA, il riferimento internazionale per le linee guida sui contenuti web, e allo standard europeo EN 301 549, in linea con quanto impone l’European Accessibility Act.

Vale la pena spiegare cosa significhino questi acronimi per chi non li maneggia ogni giorno. L’European Accessibility Act è la direttiva europea che, a partire da giugno 2025, obbliga un’ampia gamma di prodotti e servizi digitali, dall’e-commerce ai servizi bancari, a essere accessibili alle persone con disabilità. EN 301 549 è lo standard tecnico che traduce quell’obbligo in requisiti verificabili, e a sua volta si appoggia alle WCAG. Non sono raccomandazioni: sono criteri rispetto ai quali un servizio può essere giudicato conforme o non conforme.

Progettare secondo questi standard fin dall’inizio è l’equivalente dei commit pubblici: un metodo, non una pezza. Significa che la struttura semantica, i contrasti cromatici, la navigazione da tastiera e la gestione del focus sono decisioni di design prese al primo giorno, non correzioni rincorse all’ultimo. Il contesto normativo che rende questo approccio non più rinviabile è ricostruito nell’analisi delle scadenze dell’European Accessibility Act.

Così si chiude il cerchio. I quattro pilastri sono quattro modi della stessa scelta: rendere il lavoro verificabile invece che semplicemente dichiarato. Un audit ISO controlla i processi. Un registro SBTi controlla le emissioni. Un repository pubblico controlla il codice. Uno standard di accessibilità controlla l’interfaccia. In ogni caso, qualcuno di esterno può verificare ciò che noi affermiamo.

Il filo che unisce audit, emissioni, codice e interfacce

La verificabilità di terza parte non è burocrazia. È il modo in cui la fiducia smette di essere una questione di parola data e diventa misurabile.

Per chi seleziona un partner tecnologico, il criterio pratico è semplice e si può ribaltare su qualunque fornitore. Chiedi il numero del certificato. Chiedi l’ID sul registro pubblico. Chiedi il link ai repository. Se la risposta è una pagina di marketing invece di un riferimento controllabile, la differenza tra chi dichiara e chi prova è già emersa, prima ancora di firmare un contratto.

L’asticella di ciò che un cliente può legittimamente pretendere si sta alzando. È un bene per tutto il settore, perché restringe lo spazio in cui basta affermare per essere creduti. Questo movimento si inserisce in una visione metodologica più ampia, la stessa che ci porta a sostenere le nostre certificazioni ISO 27001, 27017 e 27018 con prove verificabili anziché dichiarazioni.

Il senso del nostro lavoro sui quattro pilastri è esattamente questo: trasformare la cura quotidiana in qualcosa che un cliente possa controllare senza doverci credere sulla parola. Tutte le prove sono raccolte e consultabili nella pagina che riunisce i nostri impegni.

L’entrata in vigore del Cyber Resilience Act¹ (CRA) impone nuove responsabilità per i C-level e i decisori tecnici europei: la sicurezza del software cessa di essere una semplice best practice ingegneristica per trasformarsi in un rigido requisito legale per l’accesso al mercato. Il legislatore ha tracciato una linea netta, stabilendo che l’opacità all’interno della supply chain non rappresenta più un rischio di business accettabile. Chi immette prodotti digitali nel mercato unico è ora direttamente responsabile delle vulnerabilità presenti nel codice, incluse quelle derivanti da librerie di terze parti.

Di fronte a queste direttive, la Software Bill of Materials (SBOM) emerge come lo strumento operativo fondamentale e obbligatorio per ottenere la marcatura CE. Senza una mappatura esatta di ciò che compone il software, dimostrare la conformità è impossibile. Questo articolo esplora le metodologie per mappare le dipendenze in modo esaustivo, quantificare il debito tecnico accumulato nei repository e preparare l’infrastruttura aziendale ai nuovi standard di conformità. Il passaggio da un approccio reattivo a una governance strutturata richiede l’integrazione nativa della sicurezza nei processi di sviluppo e distribuzione del software². Questa evoluzione garantisce una visibilità totale sulle fondamenta del proprio prodotto, permettendo di rilasciare aggiornamenti sicuri senza subire blocchi normativi.

Perché il Cyber Resilience Act rende la SBOM un vincolo di business?

La normativa europea trasferisce la responsabilità legale delle vulnerabilità direttamente su chi distribuisce il prodotto. Senza un inventario aggiornato delle dipendenze, mantenere la marcatura CE diventa impossibile. Questa mancanza si traduce nel blocco immediato delle vendite e nell’esposizione a sanzioni calcolate sul fatturato globale dell’azienda.

La transizione imposta dalla nuova normativa europea consiste nell’abbandono del tradizionale patching reattivo in favore di un approccio strutturale basato sulla Security-by-design³. Fino a pochi anni fa, l’integrazione di componenti open source o di terze parti avveniva con controlli minimi, delegando implicitamente la sicurezza ai maintainer esterni. Oggi, il CRA stabilisce che l’onere della prova ricade sull’azienda produttrice.

Quest’ultima deve garantire che ogni riga di codice pacchettizzata e distribuita sia tracciabile, sicura e priva di vulnerabilità note. Questo orientamento normativo europeo si allinea a un movimento globale iniziato negli Stati Uniti con l’Ordine esecutivo 14028⁴, ⁵. Il provvedimento, noto come Executive Order on Improving the Nation’s Cybersecurity⁶, ha imposto l’uso delle distinte base del software per chiunque fornisca soluzioni digitali alle agenzie federali.

Un’attenta analisi delle responsabilità legali dimostra che la conformità non è più una delega operativa per i team di sviluppo, ma un mandato fiduciario per il board aziendale. Integrare codice di cui non si conosce l’esatta provenienza e composizione equivale a immettere sul mercato un prodotto fisico senza conoscerne i materiali di fabbricazione. Questa responsabilità si inserisce a pieno titolo nelle moderne strategie di risk management e governance ESG, dove la trasparenza digitale è un pilastro fondamentale.

L’assenza di una governance rigorosa sulle dipendenze espone l’organizzazione a rischi severi. Il primo ostacolo è il blocco della commercializzazione per invalidazione immediata della marcatura CE in tutto lo Spazio Economico Europeo. A questo si aggiungono sanzioni finanziarie dirette, calcolate in percentuale sul fatturato globale dell’azienda, in caso di incidenti derivanti da negligenza nella mappatura. Infine, si rischiano danni reputazionali catastrofici e la perdita di fiducia da parte di clienti e investitori, come dimostrato da recenti attacchi alla supply chain di pacchetti ufficiali legati a grandi vendor. Senza una visibilità totale, le aziende colpite non sanno di eseguire codice ostile, replicando su scala ridotta i danni sistemici già osservati durante il caso SolarWinds⁷.

Cosa significa SBOM e come differisce da una distinta base tradizionale?

Una SBOM è l’inventario formale e strutturato di tutti i componenti, librerie e dipendenze utilizzati per costruire un’applicazione software. A differenza di una distinta base tradizionale, include versioni specifiche, licenze d’uso, relazioni gerarchiche tra i pacchetti e firme crittografiche necessarie per garantire l’integrità dell’intera catena di fornitura.

Per comprendere il valore di questo strumento, è utile un’analogia con l’industria manifatturiera. Quando un’azienda automobilistica assembla un motore, traccia esattamente l’origine, il lotto e le specifiche di ogni singola vite; se un fornitore segnala un difetto metallurgico, la casa madre sa esattamente quali veicoli richiamare. L’ingegneria del software, per decenni, ha operato assemblando librerie senza mantenere questo livello di tracciabilità. Nei sistemi PLM (Product Lifecycle Management) tradizionali, il software viene spesso trattato all’interno di una EBOM⁸ (Engineering Bill of Materials) o di una MBOM⁹ (Manufacturing Bill of Materials) come un singolo componente scatola nera, un aggregato monolitico privo di dettagli interni.

La distinta base del software rompe questa opacità. Tuttavia, un semplice elenco testuale di pacchetti non è sufficiente per l’automazione richiesta dalle moderne normative. Per questo motivo, l’industria ha sviluppato standard specifici. CycloneDX¹⁰ e SPDX¹¹ sono i formati standardizzati utilizzati per documentare le informazioni sulle componenti software all’interno di una SBOM. Questi formati, raccomandati anche dalle linee guida della CISA¹², permettono alle macchine di leggere l’inventario e incrociarlo automaticamente con i database globali delle minacce, come il National Vulnerability Database¹³.

Per le organizzazioni enterprise, mantenere la totale visibilità della supply chain tramite un inventario strutturato dei componenti rappresenta l’unico metodo scalabile per gestire la complessità applicativa.

Le differenze sostanziali tra una distinta generica e una SBOM standardizzata emergono su tre fronti. Sulla profondità di risoluzione, la distinta generica elenca solo le librerie di primo livello, mentre la SBOM standardizzata mappa l’intero albero gerarchico. Per la gestione delle licenze, l’inventario moderno include automaticamente i metadati legali per prevenire violazioni di copyright derivanti da codice open source restrittivo. Infine, la verifica crittografica integra hash univoci per ogni componente, garantendo che la libreria scansionata sia esattamente quella compilata nell’artefatto finale.

Come mappare le dipendenze per mitigare il rischio della supply chain?

Mappare le dipendenze richiede l’integrazione di strumenti di analisi composizionale direttamente nelle pipeline di sviluppo, tracciando sia i pacchetti importati direttamente sia le dipendenze transitive. Questo approccio continuo identifica le vulnerabilità prima del rilascio in produzione, trasformando l’inventario da documento statico a presidio di sicurezza dinamico e automatizzato.

Il rischio maggiore per i CTO non risiede nel codice scritto internamente, e spesso nemmeno nelle librerie importate direttamente dagli sviluppatori. Il vero punto cieco è costituito dalle dipendenze transitive: il codice scritto da terzi che richiama a sua volta altro codice di terzi, creando una catena profonda e invisibile. Come sottolineato dal nostro CTO Paolo Mainardi, le organizzazioni hanno ormai raggiunto un punto di non ritorno nella gestione delle dipendenze software: ignorare la complessità di questo albero significa accettare un debito tecnico incalcolabile. Il rapporto OSSRA 2024 rivela che il 91% dei repository di codice esaminato include componenti arretrati di 10 versioni o più.

Come possiamo governare questa complessità? L’ingegneria del software moderna si basa sull’integrazione continua di librerie terze. Questo approccio componibile è corretto e necessario per accelerare i rilasci, ma espone le applicazioni a una fragilità strutturale se non governato. La debolezza di queste architetture è dimostrata da una serie di attacchi recenti che hanno compromesso ecosistemi considerati sicuri. Nel mondo degli strumenti di sviluppo, la compromissione dell’estensione Nx Console per VS Code ha dimostrato come un token rubato su GitHub possa distribuire codice malevolo a milioni di macchine. L’ecosistema Python ha subito colpi critici su PyPi, dove pacchetti legati allo stack AI come LiteLLM sono stati manipolati per sottrarre chiavi di root.

Anche le infrastrutture enterprise non sono immuni. Red Hat ha dovuto gestire vulnerabilità critiche legate ad accessi non autorizzati nelle proprie organizzazioni GitHub, mentre piattaforme cloud native come Vercel hanno affrontato incidenti di sicurezza che minacciano i deployment frontend. Nell’ecosistema PHP, attacchi mirati hanno colpito i pacchetti Laravel Lang iniettando stealer di credenziali direttamente nelle dipendenze di traduzione. Questi incidenti dimostrano che fidarsi ciecamente del codice importato equivale a lasciare le chiavi dell’infrastruttura a sconosciuti.

Dalla nostra esperienza sul campo nei progetti enterprise che seguiamo, abbiamo constatato che la generazione dell’inventario non può essere un’attività manuale eseguita a fine progetto. Deve diventare un processo nativo all’interno delle pipeline di Continuous Integration (CI). Implementare standard industriali come Sigstore¹⁴ e OpenSSF per validare l’integrità degli artefatti OCI garantisce che il codice distribuito corrisponda esattamente a quello scansionato, prevenendo attacchi sui repository dei pacchetti.

L’approccio strategico per una mappatura efficace si articola in tre fasi operative:

1. Identificazione diretta e transitiva: scansione automatizzata dei file di manifesto (come package.json o pom.xml) durante la fase di build per risolvere l’intero albero delle dipendenze, esponendo i livelli più profondi.
2. Incrocio con i database delle vulnerabilità: confronto in tempo reale degli hash dei componenti con i feed di intelligence sulle minacce, assegnando uno score di rischio immediato a ogni build.
3. Validazione continua e blocco selettivo: configurazione di policy as code che interrompono automaticamente la pipeline di CI se viene rilevata l’introduzione di una libreria con vulnerabilità critiche o licenze non approvate.

Quali metriche definiscono il ROI di una gestione automatizzata?

Il ROI di una gestione automatizzata si misura attraverso una riduzione del Mean Time To Remediation (MTTR) fino all'80% durante gli incidenti critici e l’abbattimento delle ore dedicate agli audit manuali. L’automazione trasforma la compliance da costo operativo a vantaggio competitivo, accelerando il time-to-market dei rilasci software sicuri.

L’implementazione di un sistema di tracciamento del software non deve essere valutata esclusivamente come una spesa legata alla conformità normativa. L’automazione della generazione e dell’analisi delle distinte base riduce significativamente il carico cognitivo dei team di sviluppo, un principio cardine della disciplina del Platform Engineering. Quando i developer non devono preoccuparsi di tracciare manualmente le librerie o gestire fogli di calcolo per le licenze, possono concentrarsi sulla scrittura di feature a valore aggiunto. In questo contesto, l’efficienza operativa derivante dall’adozione di pratiche cloud native e DevOps agisce come un motore di crescita diretto per l’intera organizzazione.

L’impatto sul business diventa evidente durante le crisi di sicurezza. Quando emerge una vulnerabilità zero-day diffusa, come accaduto con Log4j¹⁵, le aziende prive di un inventario automatizzato impiegano settimane per scoprire dove il componente vulnerabile è in esecuzione, accumulando costi di remediation che superano facilmente i 100.000 euro per singolo incidente. Con un sistema automatizzato, l’interrogazione richiede pochi secondi. Le previsioni di Gartner indicavano che entro il 2025 il 60%¹⁶ delle organizzazioni¹⁷ avrebbe imposto l’uso di questi inventari strutturati nei propri processi di acquisto software. Oggi, nel 2026, questa dinamica si è concretizzata: la richiesta di SBOM è diventata uno standard di fatto nei contratti B2B. Inoltre, standard di settore rigorosi come il PCI DSS 4.0¹⁸ (l’evoluzione del framework PCI DSS per la sicurezza dei pagamenti) richiedono esplicitamente inventari dettagliati dei componenti software per mantenere la certificazione.

Le metriche concrete per valutare il ritorno sull’investimento includono:

• Contrazione del Mean Time To Remediation (MTTR): passaggio da settimane di indagine manuale a pochi minuti per l’identificazione e la localizzazione dei pacchetti compromessi.
• Riduzione delle ore di audit di sicurezza: eliminazione totale delle revisioni manuali del codice per la verifica delle licenze open source e delle dipendenze obsolete.
• Accelerazione del time-to-market: pipeline di rilascio più fluide in cui i controlli di sicurezza avvengono in modo asincrono, evitando colli di bottiglia prima del deployment in produzione.

I prossimi passi per la conformità continua

L’adeguamento ai requisiti normativi europei rappresenta un percorso di maturità tecnologica che inizia necessariamente dalla visibilità totale sull’infrastruttura software. La distinta base dei componenti non è un documento statico da archiviare dopo il rilascio, ma un set di dati dinamico che richiede un’orchestrazione continua per riflettere l’evoluzione quotidiana del codice e delle minacce globali. Per i C-level, governare questo processo significa proteggere la continuità aziendale e garantire l’accesso ininterrotto al mercato.

Le organizzazioni che intendono implementare i framework richiesti dal Cyber Resilience Act e proteggere i propri asset digitali possono richiedere un audit specializzato o esplorare i nostri servizi di Supply Chain Security per garantire la piena conformità.

Nel prossimo articolo della serie, esamineremo l’uso dell’intelligenza artificiale per simulare attacchi e automatizzare il reporting delle vulnerabilità entro le 24 ore, come richiesto dalle finestre temporali del CRA.

Note e fonti

📌 Vedi anche: la pagina dedicata al nostro status di partner: Drupal Certified Partner

SparkFabrik è la prima azienda italiana a ottenere il livello Gold del programma Drupal Certified Partner, il riconoscimento con cui la Drupal Association certifica le aziende che contribuiscono all’ecosistema con codice, eventi e supporto finanziario diretto.

Non è un titolo onorario: richiede una soglia minima verificata di contribuzioni, apportate dalle persone che lavorano ogni giorno sul progetto, unita a una quota finanziaria annuale. È la prova che il lavoro dedicato all’ecosistema aveva già un peso, anche prima che qualcuno lo certificasse.

Ci sono decisioni che sulla carta sembrano minuscole, ma che quando vengono rilette a distanza di anni pesano come macigni. Riguardando i profili su Drupal.org di Paolo Mainardi e Stefano Mainardi, si nota subito un dettaglio: sono stati aperti quasi 18 anni fa. All’epoca l’open source era pura artigianalità digitale, non c’erano le dinamiche enterprise di oggi. Era codice scritto di notte, patch inviate per risolvere un problema che qualcun altro, dall’altra parte del globo, avrebbe incontrato il giorno dopo.

Ma questa non è la storia di due sole persone. Anche gli altri founder e diversi Sparkers sono attivi sulla piattaforma da quasi vent’anni. Allora unirsi all’ecosistema Drupal sembrava una piccola decisione. Da quelle radici è nata un’azienda, o meglio, un’evoluzione. Prima ancora di SparkFabrik c’erano Twinbit ed Agavee, le società da cui siamo nati dieci anni fa, già allora delle vere e proprie Drupal companies.

Non abbiamo scelto questo CMS per convenienza di mercato: ci siamo formati su Drupal, abbracciando l’open source. Oggi abbiamo ottenuto il Drupal Certified Partner Gold, i primi in Italia. Ma questo non è un trofeo da mettere in vetrina. È la fotografia esatta di quel percorso iniziato quasi due decenni fa.

Oltre il badge: SparkFabrik è l’azienda che più contribuisce in Italia

Il programma Drupal Certified Partners certifica con un badge le aziende che innovano, avanzano e finanziano l’ecosistema del progetto Drupal. Queste contribuzioni sono misurate tramite i cosiddetti Contribution Credits. In tal senso, questi crediti segnano la demarcazione tra chi si limita a consumare il lavoro altrui nell’ecosistema e chi se ne fa carico e restituisce valore.

Nelle parole del nostro CEO, Stefano Mainardi, per noi questo non è un badge di marketing. È il peso finanziario che mettiamo dietro a ciò che facciamo già da quasi due decenni con le nostre mani, il nostro codice e il nostro tempo. I Contribution Day, le interviste su YouTube con chi ha costruito questa community. Tutto quel lavoro persistente e per nulla affascinante che serve a tenere in piedi un progetto condiviso.

Nel tempo siamo cresciuti enormemente. La nostra evoluzione verso paradigmi cloud native e architetture moderne ci ha portato ad abbracciare il DevOps e l’Intelligenza Artificiale. Ma l’open source è rimasto la filosofia di fondo: non solo uno strumento, ma un modo di lavorare che promuove collaborazione, trasparenza e condivisione della conoscenza, nei progetti Drupal come in quelli per lo sviluppo e per le architetture cloud native.

Un impegno che portiamo anche nelle membership. Siamo membri di CNCF, Linux Foundation Europe e OpenSSF, con Paolo Mainardi (CTO) nell’Advisory Board della LFE. Le radici rimangono lì, salde nel codice aperto.

Diventare anche Drupal Certified Partner è il modo in cui aggiungiamo il nostro peso finanziario al lavoro artigianale di sempre. Perché l’open source è gratuito da scaricare, ma tremendamente costoso da mantenere in vita.

C’è un altro punto fondamentale. Le fondazioni come la Drupal Association sono l’unico vero terreno neutrale rimasto. Sono gli unici spazi dove vendor, agenzie e singoli sviluppatori possono incontrarsi alla pari.

Senza una struttura indipendente, qualsiasi progetto open source finirebbe fagocitato dagli interessi commerciali di una singola azienda. La mancanza di una governance neutrale espone i progetti a conflitti tra parti che nulla hanno a che vedere con il software, come insegna il recente caso WordPress e il disastro con WP Engine.

Sostenere finanziariamente queste fondazioni non è una mossa strategica. È semplicemente la cosa giusta da fare, punto.

Quando un’azienda basa il proprio fatturato su un software libero, ha un debito morale verso chi quel software lo mantiene sicuro e aggiornato. Non basta inviare una patch ogni tanto. Serve costanza. Serve garantire che l’infrastruttura che ospita il codice non crolli.

Il livello Gold che abbiamo raggiunto certifica proprio questo equilibrio: una quota finanziaria vitale unita a un volume di Contribution Point reali, generati dalle persone che lavorano con noi ogni giorno. È la misurazione di un impegno invisibile che diventa tangibile.

Tra le aziende italiane, crediamo di essere quella che ha investito nella community Drupal con più profondità e costanza. Lo abbiamo sempre fatto in modo sano e trasparente, fedele ai valori dell’open source.

Stefano Mainardi, CEO SparkFabrik

Il valore per i clienti

Il nostro impegno nell’open source è una garanzia di valore per i clienti. Non è una facciata. Contribuire codice, partecipare ai gruppi di lavoro internazionali, organizzare eventi: tutto questo ci mantiene in osservazione costante su ciò che accade nella tecnologia, nell’ecosistema, nel mercato. Non per curiosità, ma perché è così che garantiamo ai clienti soluzioni sempre aggiornate e solide.

Un impegno che si concretizza anche nella sponsorizzazione e partecipazione attiva a tanti eventi nel territorio italiano, e nella organizzazione di appuntamenti come il Cloud Native Days Italy e DrupalCamp Italy. Lo facciamo perché crediamo che finanziare gli ecosistemi in cui noi stessi prosperiamo sia una responsabilità concreta, e ci mantiene vicini alle community, alle tecnologie e a ciò che accade prima che diventi mainstream.

Drupal è la piattaforma scelta per progetti digitali di livello enterprise, come portali istituzionali, intranet aziendali, piattaforme di servizi digitali.

In questi contesti, un partner tecnologico affidabile, in grado di essere l’unico punto di riferimento del cliente, è un vantaggio dal valore enorme.

Scegliere il Partner Certificato Drupal con le contribuzioni reali più alte in Italia significa ridurre il rischio progettuale, avere un interlocutore che conosce Drupal dall’interno e garantirsi continuità su archi di vita del progetto che si misurano in anni.

In SparkFabrik crediamo che la migliore tecnologia nasca dall’armonia tra competenze tecniche profonde e relazioni umane solide. È un valore saldo nel nostro manifesto e nella nostra visione sull’AI.

Non vogliamo essere uno specialista verticale tra dieci fornitori: siamo il punto di riferimento unico nel percorso digitale di chi ci sceglie. Diventare DCP è un’ulteriore riconferma di qualità per chi ci sceglie.

Sedersi al tavolo: non usare il software, ma deciderne il futuro

Sostenere l’infrastruttura neutrale è solo il primo passo. Il vero impatto arriva quando decidi di non subire la direzione tecnologica, ma di contribuire a tracciarla. Significa portare una voce italiana ai tavoli internazionali che contano.

Come membro dell’Advisory Board della Linux Foundation Europe, Paolo Mainardi partecipa attivamente alle discussioni strategiche su open source, AI e sovranità digitale a livello europeo.

A gennaio 2026, è stato invitato al Drupal Pivot di Ghent per discutere il futuro del progetto direttamente con i leader mondiali delle agenzie, affrontando temi cruciali come la sovranità digitale e l’open source per la PA. È stato un momento di confronto che ha confermato quanto sia vitale per i decision makers la scelta di Drupal per ecosistemi aziendali complessi. Non siamo andati lì per ascoltare, ma per portare una visione concreta su dove deve andare la tecnologia nei prossimi anni.

Il riconoscimento di questo sforzo è arrivato direttamente dai vertici.

“Thank you Stefano Mainardi and the entire team at SparkFabrik for all you do for the Italian Drupal community and for your support in helping the Drupal Association maintain Drupal’s infrastructure and ensure it’s freely available worldwide and to the 8,000+ sites in Italy. I too would like to thank Paolo Mainardi for helping discuss Drupal’s future with agency leaders at Drupal Pivot, Ghent.”

Tim Doyle, CEO Drupal Association

I fatti parlano più delle intenzioni. Nell’ultimo anno abbiamo mantenuto una densità tecnica altissima. Abbiamo scritto codice per il sistema AI Guardrails della Drupal AI Initiative, tracciato e visibile sulla pagina ufficiale SparkFabrik su Drupal.org.

Solo sul tema Drupal, abbiamo prodotto oltre 40 articoli tecnici, un whitepaper strategico dedicato a Drupal come DXP, e condiviso 100+ post sui nostri canali social. È un impegno costante per la promozione dell’ecosistema, che si aggiunge alla nostra produzione sugli altri argomenti che ci riguardano da vicino, come AI, cloud native, DevOps e Security.

La nostra presenza internazionale non si è fermata a Ghent. Abbiamo portato talk in 3 sessioni al DrupalCon Vienna 2025, al Drupal Mountain Camp e ai Drupal Dev Days Leuven, e più di recente siamo stati ai Drupal Dev Days 2026 ad Atene.

Crediamo enormemente nella condivisione della conoscenza: lo abbiamo dimostrato co-organizzando un webinar tecnico con FreelyGive, e lo abbiamo fatto di recente con il webinar “Multilingual websites, AI and quality translations in Drupal” insieme a Lara Translate. Questa è la differenza tra usare uno strumento e diventarne custodi.

Ricostruire la community italiana

Dall’influenza globale passiamo alla responsabilità locale. Perché da sempre ci teniamo a supportare la community nazionale. Senza impegno e costanza rischia di scomparire: per questo lavoriamo ogni anno per rafforzarla.

Tra il 2012 e il 2018 abbiamo co-organizzato i DrupalDay insieme a Bmeme. Sono stati sei anni di eventi fisici intensi, completamente autofinanziati, che hanno costruito un tessuto connettivo reale tra i developer italiani.

Poi c’è stato un lungo periodo di stasi. Un silenzio che non rendeva giustizia al talento e alla dedizione degli sviluppatori italiani.

Ma non ci siamo mai fermati del tutto. Anche durante questa fase più silenziosa, abbiamo continuato a investire tempo e budget in altre iniziative, ad esempio ospitando il Drupal Global Contribution Day nella nostra sede nel 2025 e 2026.

Un progetto a cui teniamo particolarmente è il nostro format online Talks on my Machine, il nostro modo di condividere conoscenza e best practice con l’ecosistema, in modo completamente gratuito. Due edizioni sono state dedicate proprio a Drupal: Drupal X Business (2026) e Drupal: Driving Digital Experiences (2024). Gen AI X Business (2025) e Supply Chain Security (2024) hanno esplorato altri temi a noi cari, ed entro la fine dell’anno torneremo con una nuova edizione dedicata all’AI.

Tuttavia, sapevamo che serviva tornare a guardarsi negli occhi. Abbiamo lavorato per riportare in vita il ritrovo fisico per eccellenza: prima con il DrupalCamp Italy 2025 a Roma, portando 2 sessioni sul palco, e ora guardando alla prossima edizione del DrupalCamp Italy a Bologna, fissata per il 22 ottobre. Non lo facciamo per piantare una bandierina o rivendicare primati. Lo facciamo perché crediamo che gli sviluppatori italiani abbiano bisogno di spazi sani, trasparenti e privi di agende personali per crescere insieme.

È un lavoro faticoso, ma le risposte ci dicono che siamo sulla strada giusta. Anche chi ha creato tutto questo, Dries Buytaert, se ne è accorto, ricordando l’intervista che abbiamo fatto con lui qualche anno fa (la prima volta che Dries è intervenuto live in un evento italiano).

“Thank you so much for all your support and contributions! 💙”

Dries Buytaert, Founder & Project Lead, Drupal

Questa è la nostra idea di community. Una presenza costante, che non si tira indietro quando c’è da rimboccarsi le maniche. Costruire spazi di aggregazione richiede pazienza. Significa gestire la logistica, la comunicazione, i rapporti con gli speaker, togliendo tempo al lavoro quotidiano.

Ma è un investimento che rifaremmo domani mattina, perché un ecosistema sano restituisce sempre cento volte quello che assorbe in termini di energie.

I fatti, in sintesi:

Il lavoro continua

Ottenere il Drupal Certified Partner di livello Gold, ed essere i primi in Italia a farlo, non rappresenta una linea di traguardo. È piuttosto la validazione di un metodo di lavoro. L’open source richiede cura, tempo e investimenti reali. Richiede aziende che scelgano di non essere solo spettatrici.

Noi continueremo a fare la nostra parte, fedeli ai valori del codice aperto, lavorando per mantenere gli ecosistemi in cui operiamo neutrali e prosperi. L’impegno continua, senza scorciatoie. Continueremo a costruire, riga di codice dopo riga di codice, la community che abbiamo sempre voluto.

Il prossimo passo lo faremo insieme alla community, faccia a faccia. Ci vediamo il 22 ottobre a Bologna per il DrupalCamp Italy: i biglietti sono disponibili e le Call for Papers e Call for Sponsors sono aperte.

L’integrazione di sistemi autonomi all’interno delle architetture aziendali impone una revisione profonda delle pratiche di ingegneria del software. L’AgentOps è la nuova disciplina che governa il ciclo di vita degli agenti AI autonomi, un prerequisito per governance, sicurezza ed osservabilità, specialmente per flussi critici in contesti enterprise.

Fino a poco tempo fa, il monitoraggio delle applicazioni si basava su un presupposto fondamentale: il software tradizionale è deterministico. A parità di input e di stato iniziale, un microservizio restituisce sempre lo stesso output.

L’adozione dei Large Language Models ha infranto questa certezza, introducendo componenti intrinsecamente probabilistici all’interno dei flussi di lavoro critici.

Questo articolo si rivolge a DevOps engineer, tech lead e platform engineer che si trovano ad affrontare una sfida operativa inedita. Non si tratta più di verificare semplicemente se un servizio risponde alle richieste di rete, ma di valutare se le decisioni prese da un’entità autonoma siano corrette, sicure e allineate agli obiettivi di business. Quando un agente AI fallisce, raramente genera un errore di sistema evidente; più spesso produce un’allucinazione semantica, entra in un loop di ragionamento infinito o esegue chiamate API non previste.

I tradizionali sistemi di monitoraggio, focalizzati su metriche infrastrutturali come l’utilizzo della CPU, il consumo di memoria RAM o la latenza di rete, risultano del tutto inefficaci di fronte a queste anomalie comportamentali. Un pod Kubernetes può apparire perfettamente sano sulle dashboard operative, mentre al suo interno un agente sta consumando migliaia di token in un ciclo decisionale errato.

L’AgentOps nasce esattamente per risolvere questo vuoto di visibilità e controllo. Non si tratta di un semplice insieme di nuovi strumenti software, ma dell’evoluzione necessaria per portare l’intelligenza artificiale autonoma a un livello enterprise-ready.

Abbracciare questa disciplina significa estendere il rigore ingegneristico, tipico degli ambienti Cloud Native, alla gestione del ciclo di vita dei modelli generativi, garantendo che la loro autonomia si traduca in un vantaggio competitivo reale e non in un rischio operativo incontrollabile.

Cosa definisce l’AgentOps rispetto alle tradizionali discipline operative?

L’AgentOps è la disciplina ingegneristica dedicata alla gestione, al monitoraggio e alla governance del ciclo di vita degli agenti AI autonomi in produzione. A differenza delle operazioni IT tradizionali, si concentra sull’osservabilità e la governance dei processi decisionali stocastici, garantendo che i sistemi multi-agente operino in modo sicuro e prevedibile.

Definire il perimetro esatto di questa materia richiede di tracciare i confini rispetto alle metodologie preesistenti, seppur vi siano ovviamente legami profondi. Come evidenziato in recenti studi accademici, il passaggio epocale consiste nel transitare dalla gestione di macchine che eseguono istruzioni deterministiche alla supervisione di entità decisionali stocastiche. Un cambiamento non solo tecnico, ma anche mentale e di approccio.

L’AgentOps non deve essere confuso con l’AIOps, che utilizza algoritmi di machine learning per ottimizzare le operazioni IT classiche prevedendo guasti o analizzando log. Allo stesso modo, si distingue nettamente dall’LLMOps, che si limita all’addestramento, al fine-tuning e al deployment dei modelli base. Il focus dell’AgentOps è il comportamento dell’agente nel suo complesso: l’uso degli strumenti, la gestione della memoria, la pianificazione delle azioni e l’interazione con l’ambiente circostante.

Questa transizione comporta una profonda evoluzione del ruolo del DevOps engineer. I professionisti dell’infrastruttura devono ora acquisire competenze per gestire l’imprevedibilità semantica. Non basta più garantire l’uptime del cluster; diventa essenziale configurare sistemi capaci di intercettare derive comportamentali prima che si traducano in azioni distruttive.

Se l’obiettivo iniziale era capire cos’è il DevOps per automatizzare il rilascio del codice, oggi la sfida è governare l’intelligenza artificiale. Per esplorare le origini di questo cambiamento metodologico, ti invitiamo ad approfondire l’approccio DevOps e la sua evoluzione nello sviluppo applicativo.

La natura stocastica degli agenti AI

Il cuore del problema operativo risiede nella natura probabilistica dei modelli generativi. Le sfide di questo nuovo paradigma si dividono tipicamente tra anomalie intra-agente e anomalie inter-agente all’interno dei sistemi multi-agente. A livello intra-agente, i fallimenti assumono forme subdole: un agente può perdere il contesto operativo durante una conversazione prolungata, oppure soffrire di un’allucinazione di memoria all’interno di un’architettura Retrieval-Augmented Generation (RAG), recuperando documenti irrilevanti e basando su di essi azioni successive.

Nei sistemi multi-agente, la complessità scala rapidamente. Le anomalie inter-agente includono fenomeni come le tempeste di messaggi, dove due o più agenti entrano in un ciclo infinito di richieste e risposte senza mai giungere a una conclusione, consumando budget computazionale in modo silente.

In questi scenari, i log tradizionali sono ciechi. Un loop infinito di ragionamento non genera picchi anomali di CPU o latenze di rete tali da innescare gli allarmi standard. Il sistema infrastrutturale funziona perfettamente, è la logica applicativa autonoma a essere fallata. Per questo motivo, l’ingegneria operativa deve spostarsi dal monitoraggio delle risorse fisiche al monitoraggio semantico dei payload e delle catene di pensiero.

Quali sono le differenze tra AgentOps, DevOps, MLOps, LLMOps e AIOps?

Per orientarsi nel complesso ecosistema delle metodologie operative moderne, è utile mettere a confronto le diverse discipline. Ognuna di esse affronta un livello specifico dello stack tecnologico, contribuendo in modo incrementale alla stabilità e all’innovazione aziendale. L’AgentOps si posiziona al vertice di questa piramide, orchestrando l’automazione decisionale proattiva.

Di seguito, un’analisi strutturata delle principali discipline operative e del loro impatto sul business:

Qual è il framework operativo per il ciclo di vita e l’osservabilità dell’AgentOps?

Il framework operativo dell’AgentOps struttura il ciclo di vita degli agenti attraverso sviluppo, validazione, deployment e manutenzione. Introduce l’osservabilità del ragionamento per tracciare le decisioni e implementa cicli di remediation per gestire anomalie semantiche, garantendo interventi rapidi e mirati sui comportamenti imprevisti in produzione.

Strutturare il ciclo di vita di un agente richiede un approccio metodologico rigoroso. Durante la fase di sviluppo, la definizione dei prompt e l’assegnazione degli strumenti devono essere trattate come codice sorgente, sottoposte a versionamento e peer review.

La validazione rappresenta un punto di svolta: i test unitari tradizionali non bastano, rendendo necessaria l’adozione di pattern come LLM-as-a-judge, dove modelli specializzati valutano la qualità, la pertinenza e la sicurezza delle risposte fornite dall’agente in ambienti di staging.

Anche in assenza di un LLM specializzato, è opportuno l’utilizzo di skill dedicate e di modelli differenti per le fasi di valutazione e generazione. Un paio di occhi freschi e imparziali, come nella peer review tra umani, è essenziale. Il modello giudice deve essere tipicamente diverso e preferibilmente dotato di capacità di ragionamento superiori rispetto al modello dell’agente per evitare bias di auto-valutazione.

Solo dopo aver superato questi benchmark dinamici, l’agente può passare alla fase di deployment e successiva manutenzione adattiva.

Il secondo pilastro del framework è la reasoning observability, ovvero l’osservabilità del ragionamento. Tracciare l’output finale di un agente è insufficiente per eseguire il debugging di un errore complesso. È indispensabile registrare l’intera catena di pensieri, i log di contesto, l’attivazione di guardrails e le specifiche chiamate ai tool esterni.

Questo livello di trasparenza è fondamentale per innescare un ciclo di gestione delle anomalie efficace, che consenta di eseguire una root cause analysis (RCA) accurata e di applicare risoluzioni mirate, come l’ottimizzazione del prompt o il rollback dello stato. Per comprendere come questi principi derivino dalla gestione di sistemi complessi, scarica la guida gratuita sulla SRE per garantire l’affidabilità delle applicazioni.

Osservabilità del ragionamento degli Agenti AI e telemetria

Estendere gli stack di osservabilità Cloud Native per supportare l’intelligenza artificiale autonoma è una delle sfide tecniche più affascinanti dell’AgentOps. Strumenti consolidati come Prometheus, Grafana e Jaeger, originariamente concepiti per il tracciamento dei microservizi, vengono ora configurati per supportare il tracing distribuito delle decisioni prese dai modelli generativi. Ogni passo del ragionamento dell’agente viene trattato come uno span all’interno di una traccia distribuita.

Questo approccio permette agli ingegneri di visualizzare esattamente quale frammento di contesto ha innescato una determinata chiamata API o perché l’agente ha deciso di ignorare un’istruzione specifica. Tuttavia, l’osservabilità del ragionamento introduce sfide inedite legate al volume dei dati. Il logging ad alta frequenza dei payload di input e output genera un carico enorme sui sistemi di telemetria.

Parallelamente, emerge la necessità cruciale di monitorare i costi. Poiché le API dei fornitori di modelli linguistici fatturano in base al consumo dei token, un agente bloccato in un loop decisionale può esaurire rapidamente il budget assegnato. Le dashboard di Grafana devono quindi essere estese per correlare le metriche di performance tecnica con le metriche finanziarie in tempo reale, implementando circuit breaker automatici che interrompano l’esecuzione quando le soglie di spesa vengono superate in modo anomalo.

In modo simile, nel caso si utilizzino modelli locali per garantire la massima sicurezza del dato, l’observability e il monitoraggio dei costi sono fondamentali e presentano sfide dedicate, richiedendo ad esempio un’attenta misurazione dell’utilizzo delle GPU e dei tempi di inferenza.

Gestione delle anomalie e remediation

I flussi di incident response specifici per l’intelligenza artificiale differiscono radicalmente da quelli tradizionali. Quando un agente AI manifesta un comportamento anomalo, l’obiettivo primario è contenere il raggio d’azione per prevenire danni all’infrastruttura o ai dati aziendali. Un rischio concreto è il tool poisoning, di cui un vettore d’attacco ben conosciuto è l’Indirect Prompt Injection. L’agente riceve dati manipolati recuperati da una fonte esterna che lo inducono a corrompere l’applicazione o eseguire chiamate API distruttive, come la cancellazione di database o la modifica di permessi di rete.

Per gestire queste emergenze, il framework AgentOps deve prevedere meccanismi di interruzione immediata. I sistemi di orchestrazione devono poter revocare istantaneamente le credenziali temporanee assegnate all’agente o isolarlo a livello di rete, bloccando qualsiasi comunicazione in uscita. La remediation non si limita al contenimento, ma richiede un’analisi profonda per evitare il ripetersi dell’incidente.

L’integrazione di concetti di versioning e rollback sicuri diventa essenziale. Ogni aggiornamento del comportamento di un agente deve essere trattato come una release software formale, sia esso una modifica al prompt di sistema, o l’aggiunta di un nuovo strumento o una nuova skill (ovvero un set di capacità o funzioni specifiche, come il tool-calling, che l’agente può invocare per risolvere sotto-task).

Se un nuovo comportamento si rivela instabile in produzione, i team operativi devono poter eseguire un rollback allo stato precedente in modo deterministico, ripristinando immediatamente l’affidabilità del servizio mentre conducono l’analisi post-mortem in ambienti isolati.

AgentOps nel platform engineering: come evolve l’Internal Developer Platform?

Nell’ambito del Platform Engineering, l’AgentOps trasforma le Internal Developer Platform, ovvero i portali centralizzati per il self-service degli sviluppatori, in ecosistemi intelligenti. Gli agenti autonomi innalzano la DevEx e riducono il carico cognitivo, orchestrando risorse complesse, abilitando il self-service ed operando all’interno di perimetri ben definiti dalle policy aziendali.

I dati di mercato confermano che ci troviamo in una fase di profonda trasformazione architetturale. Il report di ESG e Google Cloud evidenzia come il 55% delle aziende a livello globale abbia già adottato pratiche di platform engineering, e oltre il 90% preveda di espanderne l’uso nei prossimi anni.

Questa adozione massiccia crea il terreno infrastrutturale perfetto per l’AgentOps. Le piattaforme centralizzate forniscono le API, gli strumenti di orchestrazione e i sistemi di identity management necessari affinché gli agenti AI possano operare su larga scala.

La Developer Experience (DevExp) è un parametro fondamentale nel Platform Engineering per misurare l’efficacia di un team di ingegneria. Gli agenti AI integrati in una IDP rivoluzionano questa esperienza.

La transizione in atto vede le Internal Developer Platform evolversi da portali statici self-service, dove lo sviluppatore deve compilare moduli complessi, a ecosistemi realmente intelligenti e proattivi. Tuttavia, questa efficienza non può esistere senza una governance ferrea: l’automazione deve essere vincolata da policy as code per prevenire configurazioni errate.

Per approfondire l’impatto di queste dinamiche sull’efficienza dei team, ti consigliamo di leggere come migliorare la Developer Experience per ridurre il carico cognitivo dei team e la nostra guida dedicata.

Da portali statici a ecosistemi intelligenti

L’evoluzione delle piattaforme interne è guidata dalla necessità di ridurre il carico cognitivo sui team di sviluppo. In un’architettura a microservizi moderna, richiedere il provisioning di un nuovo ambiente comporta la configurazione di repository, pipeline CI/CD, cluster Kubernetes, database e policy di rete. Richiedere agli sviluppatori di padroneggiare ogni singolo strumento rallenta drasticamente la consegna del software.

Gli agenti AI risolvono questo collo di bottiglia orchestrando le risorse in autonomia. Uno sviluppatore può interagire con la piattaforma in linguaggio naturale, richiedendo ad esempio un ambiente di staging ottimizzato per test di carico su un servizio specifico. L’agente analizza la richiesta, deduce le dipendenze necessarie, genera i manifesti infrastrutturali e avvia il provisioning dinamico delle risorse, notificando l’utente a operazione conclusa.

L’abbattimento del carico cognitivo è immediato e quantificabile ed il valore di business generato da questa transizione è duplice. Da un lato, si ottiene un onboarding accelerato: i nuovi assunti possono diventare produttivi in pochi giorni anziché settimane, guidati dall’agente attraverso le complessità dell’infrastruttura aziendale. Dall’altro, si ottimizza il tempo degli sviluppatori senior, che vengono liberati da task operativi ripetitivi per concentrarsi sulla scrittura di logica di business e sull’innovazione architetturale.

AgentOps e DevSecOps: la sicurezza come prerequisito nell’era degli agenti autonomi

L’autonomia degli agenti AI genera valore solo se operano all’interno di un perimetro di sicurezza definito e automatizzato. Con l’AgentOps, il DevSecOps smette di essere una best practice e diventa un prerequisito infrastrutturale: ogni azione autonoma, dal provisioning di risorse alla modifica di una configurazione, deve essere validata prima di raggiungere la produzione. L’approccio Shift-Left, che integra la sicurezza fin dalle prime fasi del ciclo di vita del software, diventa il principio architetturale su cui costruire la fiducia nei sistemi autonomi.

Come validare le azioni degli agenti nelle pipeline DevSecOps?

L’implementazione pratica richiede che gli agenti AI operino all’interno di una pipeline DevSecOps rigorosa e immodificabile. Ogni proposta di modifica generata da un agente AI deve essere trattata come una pull request standard, soggetta all’intera catena di controlli automatizzati. Non esistono eccezioni: che l’azione sia stata prodotta da un ingegnere o da un agente, il processo di validazione è identico.

Questo significa integrare i giusti strumenti operativi direttamente nel flusso di lavoro dell’agente. Ogni modifica infrastrutturale generata dall’AI, prima di essere applicata, deve passare attraverso test di sicurezza statici (SAST), che analizzano il codice proposto alla ricerca di vulnerabilità note, e test dinamici (DAST) che verificano il comportamento dell’applicazione a runtime. Questo avviene direttamente nelle pipeline CI/CD, validando così le azioni proposte dagli agenti prima del deploy.

I sistemi di container scanning completano il quadro, confermando che le immagini utilizzate non contengano dipendenze compromesse. Se un agente suggerisce l’aggiornamento di una libreria per risolvere un bug prestazionale, lo scanning verifica che la nuova versione non introduca vulnerabilità note. Solo dopo aver superato questi controlli, la modifica può procedere.

Inoltre, in alcuni framework AgentOps avanzati, i segnali prodotti da questi processi, come rifiuti della pipeline, approvazioni, falsi positivi, risultati degli scan ed altre istruzioni specifiche, diventano dei feedback che affinano progressivamente il comportamento dell’agente. Un sistema che apprende e migliora la postura di sicurezza con l’uso.

Policy as Code e guardrail di sicurezza

L’autonomia concessa agli agenti all’interno della piattaforma richiede la definizione di confini rigidi e invalicabili. La governance di questo processo si fonda sull’adozione di Policy as Code. In ambito AgentOps, la sicurezza si implementa attraverso due tipologie distinte di controlli: i policy guardrail, che limitano le azioni infrastrutturali concrete, e gli AI guardrail, che filtrano semanticamente gli input e gli output dei modelli linguistici.

I policy guardrail sono vincoli infrastrutturali che limitano le azioni dell’agente e ne circoscrivono il raggio d’azione effettivo. Utilizzando standard come Open Policy Agent, le aziende definiscono regole che impediscono all’intelligenza artificiale di eseguire operazioni non conformi o distruttive (come l’esposizione di un database su reti pubbliche), indipendentemente dalle istruzioni ricevute o dalle deduzioni del modello.

Un esempio concreto chiarisce l’importanza di questi vincoli: immaginiamo un agente incaricato di ottimizzare i costi cloud che identifica un Web Application Firewall (WAF) apparentemente sottoutilizzato e decide autonomamente di spegnerlo per risparmiare risorse. Senza policy infrastrutturali, l’azione verrebbe eseguita, esponendo l’azienda a rischi critici. I policy guardrail intercettano la chiamata API, la bloccano in millisecondi e restituiscono all’agente un errore di conformità.

Un altro concetto distinto ma collegato è quello degli AI guardrail. Si tratta di sistemi che filtrano l’input e l’output semantico dell’agente, bloccando la generazione di contenuti dannosi o mascherando dati sensibili prima che vengano inviati ai modelli linguistici. Sono anche utilizzati per bloccare tentativi di prompt injection e risposte non in linea con il brand, evitando altrettanto seri danni reputazionali.

Anche questi filtri contribuiscono alla sicurezza delle applicazioni aziendali che integrano funzionalità AI, e richiedono monitoring e logging dettagliato per verificarne l’efficacia.

Un esempio pratico è illustrato nel nostro approfondimento sui Guardrails AI in Drupal: un contributo di SparkFabrik all’ecosistema open source che dimostra come configurare filtri di sicurezza avanzati per i dati in entrata e in uscita.

Come si applica l’AgentOps in contesti operativi reali?

L’AgentOps si applica trasversalmente a infrastruttura e software. Le regole di monitoraggio e governance governano sia i Virtual SRE per la gestione proattiva dei cluster Kubernetes, sia gli agenti applicativi che automatizzano la software delivery, il customer care e le operazioni di marketing.

Dimostrare l’universalità del framework AgentOps è fondamentale per comprenderne la portata strategica. L’errore più comune è relegare questa disciplina esclusivamente al monitoraggio dei chatbot. Al contrario, le pratiche di osservabilità, la gestione dei fallimenti semantici e l’imposizione di guardrail si applicano con la stessa efficacia sia all’infrastruttura di base che al software applicativo di alto livello. I principi ingegneristici non cambiano al variare del dominio di competenza dell’agente.

Per comprendere a fondo le fondamenta su cui operano questi agenti infrastrutturali, consulta la nostra guida completa a Kubernetes per l’orchestrazione dei container in ambienti complessi.

Virtual SRE per le operations infrastrutturali

Un Virtual SRE è un agente autonomo progettato per identificare, diagnosticare e risolvere incidenti in produzione senza richiedere un intervento umano continuo. A differenza dei tradizionali copilot passivi, opera come un’estensione attiva del team di ingegneria, segnando uno dei traguardi più avanzati dell’AgentOps applicato all’infrastruttura.

Immaginiamo uno scenario operativo su un cluster Kubernetes: un microservizio inizia a manifestare un memory leak progressivo durante il fine settimana. I sistemi di alerting tradizionali invierebbero notifiche a un operatore reperibile, richiedendo un intervento manuale per analizzare i log, identificare il pod problematico e riavviarlo.

Un Virtual SRE (o SRE agent), dotato degli strumenti adeguati, intercetta l’anomalia in tempo reale. L’agente correla le metriche di consumo della memoria con i log applicativi recenti, identifica la causa probabile e applica una patch di configurazione temporanea, come l’aumento dei limiti di memoria o il riavvio controllato dei pod, notificando il team con un report dettagliato dell’incidente già risolto. Questo livello di automazione richiede un’osservabilità profonda per garantire che le azioni dell’agente non causino disservizi a cascata.

Scenari simili si applicano all’ottimizzazione delle pipeline CI/CD. Operando su ambienti cloud complessi, un agente può analizzare i tempi di esecuzione dei test interagendo direttamente con i repository Git. Se rileva che una suite di test end-to-end rallenta sistematicamente i rilasci senza trovare bug significativi, l’agente può proporre una riorganizzazione dei job o un parallelismo più efficiente, aprendo una pull request automatizzata per modificare le configurazioni della pipeline.

È cruciale sottolineare che l’AgentOps non sostituisce i team operativi, ma li potenzia. Il Virtual SRE affianca i team umani 24 ore su 24, ma il controllo strategico resta saldamente nelle mani degli ingegneri. Per abilitare questo livello di collaborazione servono osservabilità profonda, monitoraggio continuo, formazione dedicata e una forte propensione alla sperimentazione.

Agenti applicativi per software delivery e workflow

Spostando il focus fuori dall’infrastruttura, l’AgentOps dimostra il suo valore nella gestione di agenti specializzati in domini applicativi. Nella software delivery, i coding agent non si limitano a suggerire snippet di codice, ma generano intere funzionalità, eseguono revisioni di pull request e scrivono test unitari in autonomia. Il framework AgentOps assicura che il codice generato rispetti gli standard aziendali attraverso l’analisi statica automatizzata.

Un ambito in rapida espansione è il marketing agentico. In questo contesto, l’AgentOps governa sistemi complessi che analizzano le performance di centinaia di creatività pubblicitarie, le ricreano rispettando il tone of voice aziendale e orchestrano batch di A/B test in completa autonomia. Altri agenti specializzati si occupano di generare e ottimizzare landing page dinamiche in base al comportamento degli utenti. Sebbene il dominio sia creativo, la necessità di governance è prettamente ingegneristica.

Ancora, altri scenari applicativi si hanno nel customer care, nei processi commerciali e nella logistica, dove gli agenti gestiscono interazioni complesse con i clienti o ottimizzano le rotte di approvvigionamento elaborando enormi moli di dati in tempo reale.

La gestione di questi workflow richiede le medesime garanzie operative dell’infrastruttura. La necessità di implementare funzionalità di session replay per analizzare le interazioni passate, la valutazione continua della qualità tramite modelli giudicanti e la limitazione dell’autonomia per prevenire danni d’immagine o sprechi di budget rimangono identiche. L’AgentOps fornisce la struttura di controllo necessaria affinché l’intelligenza artificiale possa operare in modo sicuro in qualsiasi processo di business.

Come strutturare una roadmap di adozione dell’ AgentOps?

L’adozione dell’AgentOps richiede una roadmap pragmatica che parte dal consolidamento delle basi Cloud Native. Attraverso un approccio human-in-the-loop, i team costruiscono fiducia nel sistema validando le decisioni in sola lettura, prima di delegare operazioni a basso rischio all’autonomia supervisionata in produzione.

Fornire una guida chiara ai leader tecnologici è essenziale per evitare i fallimenti tipici dei progetti di innovazione non strutturati. Il percorso verso l’AgentOps non può prescindere dal consolidamento delle pratiche di automazione preesistenti. Implementare agenti intelligenti su infrastrutture gestite manualmente o prive di versionamento non porta all’efficienza, ma amplifica il debito tecnico.

Per esplorare l’impatto strategico di questa trasformazione, scopri come gli agenti intelligenti trasformano i processi e il business.

L’evoluzione verso l’autonomia si articola tipicamente attraverso una progressione logica:

1. Assessment e standardizzazione GitOps: Le aziende devono mappare i propri processi operativi, identificare i colli di bottiglia e assicurarsi che l’infrastruttura sia dichiarativa e i deployment completamente automatizzati. Tentare di applicare l’AgentOps su processi manuali significa delegare all’intelligenza artificiale la gestione del caos. Inoltre, le pipeline DevSecOps diventano i gate obbligatori attraverso cui passano tutte le azioni degli agenti. Senza DevSecOps, dare autonomia a un agente è pericoloso.
2. Osservabilità AI-Assisted (sola lettura): Gli agenti vengono introdotti senza alcun permesso di modifica. Il loro compito è analizzare enormi volumi di log, correlare eventi provenienti da sistemi distribuiti e generare reportistica avanzata sugli incidenti. Questo permette ai team di calibrare i sistemi di telemetria e valutare l’accuratezza del ragionamento.
3. Remediation in ambienti non-prod: Gli agenti ottengono i permessi per applicare modifiche architetturali e risolvere incidenti, ma esclusivamente in ambienti di sviluppo e staging. In questo perimetro controllato, si testano le capacità di auto-correzione e si affinano i policy guardrail.
4. Automazione human-in-the-loop in produzione: Gli agenti monitorano i cluster produttivi e propongono piani di risoluzione dettagliati, ma l’esecuzione effettiva richiede l’approvazione esplicita di un ingegnere senior. Questo garantisce la sicurezza assoluta in scenari reali ad alto stress.
5. Autonomia supervisionata: Dopo mesi di validazione, compiti operativi specifici e a basso rischio, come l’ottimizzazione dei costi cloud o l’auto-scaling predittivo, vengono delegati completamente agli agenti. L’enfasi si sposta sulla robustezza dei sistemi di orchestrazione, capaci di isolare l’agente al primo segnale di anomalia.

Gestire l’incertezza dell’AgentOps come tecnologia emergente

Integrare l’AgentOps richiede un forte allineamento delle aspettative a livello direzionale. I CTO devono promuovere una cultura organizzativa caratterizzata da una spiccata propensione alla sperimentazione e da una sana tolleranza verso i fallimenti iniziali. Le “allucinazioni” dei modelli linguistici rappresentano un rischio concreto e, trattandosi di tecnologie emergenti, è naturale esplorare varie strategie di mitigazione.

Per gestire in sicurezza queste incertezze, è imperativo progettare sistemi che prevedano azioni di rollback istantaneo e immutabilità dell’infrastruttura. Se un agente AI applica una configurazione errata, il sistema di orchestrazione deve essere in grado di ripristinare rapidamente lo stato precedente. La resilienza è un valore sempre più centrale nelle architetture moderne e diventa il prerequisito per poter sperimentare in sicurezza con l’automazione autonoma.

L’approccio dello “human-in-the-loop” si conferma essenziale non solo come misura di sicurezza, ma come strumento di apprendimento organizzativo. La transizione da un approccio puramente AI-assisted (dove l’agente suggerisce e l’umano approva) a uno AI-autonomous deve essere graduale. Questo permette agli ingegneri di costruire fiducia nelle capacità decisionali dei modelli prima di allentare i vincoli operativi, e di mantenere l’intervento umano per le operazioni più critiche in produzione.

Conclusione

L’AgentOps non rappresenta una tendenza passeggera destinata a esaurirsi con il ciclo di hype dell’intelligenza artificiale. Al contrario, si afferma come un’evoluzione strutturale profonda, imprescindibile per gestire la complessità crescente dei sistemi distribuiti moderni.

Delegare l’operatività a entità decisionali stocastiche richiede un nuovo approccio, dove l’osservabilità del ragionamento e la gestione proattiva delle anomalie diventano le nuove metriche di successo per i team operativi.

È fondamentale ribadire che il successo dell’intelligenza artificiale autonoma in produzione poggia interamente sulla solidità delle fondamenta infrastrutturali. Senza un’architettura Cloud Native matura, priva di pratiche DevSecOps rigorose e di una gestione dichiarativa delle risorse, l’AgentOps rischia di amplificare le inefficienze esistenti. L’automazione intelligente non corregge i processi fallati, li esegue semplicemente a una velocità maggiore.

CTO, Tech Lead e responsabili dell’infrastruttura devono valutare con oggettività la maturità della propria Internal Developer Platform e le competenze interne in sicurezza, prima di delegare operazioni critiche agli agenti AI. Costruire ecosistemi intelligenti richiede pianificazione, competenze specialistiche e un approccio security-by-design.

Se desideri esplorare come la nostra esperienza possa accelerare questa transizione nella tua azienda, scopri come integriamo agenti intelligenti nei flussi di lavoro aziendali e prenota una consulenza per parlarci del tuo progetto e delle tue sfide.

Affidare i propri dati aziendali a un sistema chiuso è come vivere in affitto. Puoi usare l’appartamento ed hai sicuramente alcuni diritti, ma non hai il controllo. Il proprietario può alzare il canone, importi nuove regole, decidere di non apportare migliorie o, nel peggiore dei casi, anche sfrattarti. In ambito aziendale, la sovranità dei dati rappresenta esattamente questo concetto: la necessità vitale di mantenere il controllo assoluto sulle proprie informazioni, decidendo in modo indipendente cosa farne, dove risiedono e chi può accedervi.

La sovranità dei dati non riguarda solo gli addetti ai lavori, e non si tratta di una semplice questione tecnica. È una scelta strategica che tocca la sopravvivenza del business. Oggi, l’unica reale garanzia di indipendenza per le aziende e per l’Europa intera risiede nell’adozione di software open source. Solo quando il codice è accessibile, trasparente e non vincolato a un singolo fornitore, un’organizzazione può dirsi veramente padrona del proprio destino digitale.

Secondo la definizione ufficiale dell’Open Source Initiative, il software libero deve garantire l’accesso al codice sorgente e la libertà di ridistribuzione senza discriminazioni. Senza questi pilastri, la tua azienda rischia di rimanere intrappolata in ecosistemi rigidi, perdendo la capacità di innovare e di proteggere adeguatamente i dati dei propri clienti.

Questo articolo è pensato per guidare i decisori aziendali, i manager e i professionisti non tecnici in un percorso di consapevolezza. L’obiettivo è fornire gli strumenti pratici per orientarsi tra le vere soluzioni aperte e le finte promesse commerciali che affollano il mercato. Scopriremo insieme perché la scelta dell’open source non riguarda solo il risparmio sui costi delle licenze, ma rappresenta l’assicurazione sulla vita del patrimonio informativo della tua azienda.

Cosa significa realmente possedere i propri dati?

Possedere i propri dati significa avere il controllo esclusivo e permanente su dove le informazioni vengono archiviate, chi può accedervi e come vengono elaborate, senza dipendere da un singolo fornitore tecnologico. Questa indipendenza operativa garantisce che l’azienda possa spostare i propri sistemi liberamente, proteggendo il business da rincari improvvisi, cambi di licenza o ingerenze esterne.

L’Europa, gli Stati Uniti e la corsa al cloud sovrano

La gestione delle informazioni digitali è diventata un tema centrale nelle dinamiche geopolitiche globali. Storicamente, il mercato tecnologico è stato dominato da fornitori degli Stati Uniti, le cui normative interne spesso entrano in conflitto con le rigide leggi europee sulla privacy. Infatti, il governo statunitense si sta opponendo attivamente alle iniziative di sovranità dei dati europee, temendo di perdere il controllo strategico e commerciale sui flussi di informazioni globali. Questa tensione ha spinto l’Unione Europea a cercare una maggiore indipendenza, dando vita a una vera e propria corsa verso infrastrutture digitali autonome.

I grandi player tecnologici hanno compreso rapidamente questa esigenza di mercato. Oltre all’annuncio dell’AWS European Sovereign Cloud, stiamo assistendo alla nascita di iniziative analoghe come Google S3NS e il progetto Bleu (joint venture di Capgemini e Orange basato su tecnologia Microsoft Azure), a dimostrazione di come i colossi del cloud proprietario debbano adattarsi alla richiesta di infrastrutture fisicamente e legalmente separate per l’Europa.

C’è però una distinzione importante che vale la pena fare, e che permette di leggere questi annunci con la giusta lente. Queste offerte possono ridurre i rischi legali legati alla residenza delle informazioni, ma non consegnano una vera sovranità tecnologica.

Un cloud operato da un hyperscaler non europeo rimane, per sua stessa architettura, controllato e strategicamente allineato fuori dall’Europa.

Alla luce di queste limitazioni, cosa cerca esattamente un’azienda quando valuta un cloud realmente sovrano? I requisiti fondamentali sono tre:

• Residenza dei dati: le informazioni devono rimanere fisicamente all’interno dei confini europei, protette dalle normative locali e inaccessibili a governi esteri.

• Controllo degli accessi: solo l’azienda proprietaria e il personale autorizzato europeo devono poter visualizzare o gestire i dati archiviati.

• Indipendenza operativa: l’infrastruttura deve poter funzionare in totale autonomia, garantendo la continuità aziendale anche in caso di disconnessione dai sistemi globali del fornitore principale.

Il ruolo delle normative e l’impatto del Cyber Resilience Act (CRA)

Le normative europee definiscono regole precise per l’indipendenza tecnologica. Il Cyber Resilience Act (CRA) è la nuova legge europea nata per garantire la sicurezza dei prodotti digitali connessi alla rete. Questa normativa stabilisce requisiti rigorosi per i produttori di software e hardware, obbligandoli a fornire aggiornamenti di sicurezza continui e a dichiarare tempestivamente eventuali vulnerabilità.

L’impatto sulle aziende sarà tangibile e trasversale. Ad esempio, un’impresa che produce dispositivi medici connessi non potrà più ignorare le falle di sicurezza del software integrato. Allo stesso modo, pensiamo ai sensori industriali IoT utilizzati nelle fabbriche, ma anche ai dispositivi consumer (come smart TV, router e smartphone).

Tutte queste aziende dovranno integrare la sicurezza fin dalle fasi iniziali di progettazione, il cosiddetto approccio security-by-design. Dovranno inoltre garantire che il software riceva aggiornamenti di sicurezza tempestivi per tutta la vita utile del prodotto.

Il panorama legislativo sta riconoscendo sempre più ufficialmente il codice aperto come un pilastro fondamentale per la sicurezza collettiva. Quando il codice sorgente è visibile e verificabile da migliaia di esperti e sviluppatori in tutto il mondo, i difetti vengono individuati e corretti molto più velocemente rispetto ai sistemi chiusi e segreti.

La sicurezza informatica trasparente è il primo, indispensabile passo per non essere ostaggi di fornitori terzi. Se non puoi ispezionare il software che gestisce i tuoi dati, devi fidarti ciecamente delle promesse del venditore. Al contrario, l’approccio aperto permette di condurre audit indipendenti e di verificare che non ci siano porte di servizio nascoste.

In questo modo, la conformità alle normative come il CRA diventa un processo collaborativo e trasparente, rafforzando la vera sovranità digitale delle organizzazioni.

Per verificare l’impatto di questa normativa sul tuo business, abbiamo preparato una guida pratica per capire se il tuo prodotto rientra nel CRA.

Perché l’open source è il motore della sovranità digitale europea?

L’open source è il motore della sovranità digitale perché elimina la dipendenza da un unico fornitore, permettendo alle aziende di ispezionare, modificare e spostare liberamente il proprio software. Questa trasparenza tecnologica garantisce il controllo totale sui dati, abbattendo i costi di migrazione e favorendo un’innovazione sicura, collaborativa e priva di vincoli commerciali.

Oltre il codice: indipendenza e riduzione del vendor lock-in

Ti sei mai chiesto quanto costerebbe alla tua azienda migrare l’intero sistema gestionale se il tuo attuale fornitore decidesse di raddoppiare le tariffe dall’oggi al domani? Per comprendere il rischio di affidarsi a sistemi chiusi, immagina di comprare una macchina fotografica di altissima qualità, per poi scoprire che i suoi obiettivi funzionano esclusivamente con quel marchio. Se un domani volessi cambiare corpo macchina, dovresti ricomprare tutto il corredo di lenti da zero. Nel mondo del software, questa costosa trappola si chiama vendor lock-in.

L’adozione di soluzioni open source permette alle aziende di cambiare fornitore cloud o partner tecnologico senza dover ricostruire l’intera infrastruttura. Questa libertà si applica a tutti i livelli aziendali. Ad esempio, sviluppare solide applicazioni intranet open source assicura che i processi interni non vengano paralizzati se un fornitore decide di cambiare le condizioni contrattuali.

Inoltre, l’utilizzo di software di auditing open source garantisce una trasparenza assoluta sui processi di verifica, un requisito essenziale per la vera indipendenza. Questa libertà di innovare si estende anche alle tecnologie più all’avanguardia. Per capire come questa filosofia stia trasformando settori complessi, ti consigliamo di leggere il nostro approfondimento su AI per sviluppatori: la rivoluzione open source del software.

L’innovazione aperta è l’unico modo per adottare nuove tecnologie mantenendo il timone saldamente nelle proprie mani, restituendo ai manager il vero potere decisionale.

La differenza tra SaaS proprietario e soluzioni aperte

Il modello del software as a service proprietario ha semplificato l’accesso a molti strumenti digitali, ma ha un prezzo nascosto: la perdita di controllo. In un SaaS chiuso, i tuoi dati risiedono sui server di un’altra azienda, che detta unilateralmente le regole di esportazione e di utilizzo. Al contrario, le alternative aperte ti permettono di ospitare il software sui tuoi server o su un cloud di tua scelta.

Oggi le aziende cercano flessibilità in ogni settore. Nel commercio elettronico, ad esempio, valutare piattaforme di e-commerce aperte (ad esempio basate su Drupal) rispetto ai rigidi ecosistemi SaaS permette di personalizzare l’esperienza di acquisto senza limiti artificiali. Questa necessità di controllo copre ogni esigenza aziendale quotidiana, dalla stesura di documenti alla contabilità.

Pensiamo alle suite da ufficio storiche come Apache OpenOffice o LibreOffice, che hanno dimostrato come sia possibile gestire documenti complessi senza pagare licenze ricorrenti. Anche a livello più strategico, l’adozione di sistemi ERP e CRM open source (come Odoo o Dolibarr) consente alle imprese di gestire la contabilità, il magazzino e i clienti mantenendo la proprietà assoluta dello storico aziendale. Pensiamo anche a Drupal, il CMS open source principale per contesti enterprise ed istituzionali.

Scegliere questi strumenti significa investire in un patrimonio tecnologico che cresce con l’azienda, anziché pagare un affitto perpetuo a fornitori terzi.

Inoltre, è importante evidenziare come la validità delle alternative open source è confermata dalla crescente adozione di tali soluzioni da parte di governi ed istituzioni pubbliche (ad esempio, la transizione del governo francese da Microsoft 365, Teams e Zoom a LaSuite).

Non tutto l’open source è uguale: la scala della sovranità

Non tutto il software open source offre lo stesso livello di indipendenza, vi sono diverse sfumature. La vera sovranità dipende dalla governance del progetto, dal grado di libertà in capo all’utilizzatore. Le soluzioni gestite da fondazioni neutrali garantiscono il controllo totale, mentre i progetti guidati da una singola azienda espongono le organizzazioni al rischio di improvvisi cambi di licenza o restrizioni d’uso.

I diversi livelli di apertura del software

È fondamentale comprendere che il concetto di apertura non è un semplice interruttore acceso o spento, ma uno spettro con diverse sfumature. Per orientarsi in questo panorama, risulta estremamente utile fare riferimento al recente articolo in cui Dries Buytaert, il creatore di Drupal, ha formalizzato questo concetto proponendo la cosiddetta “Scala della Sovranità del Software”.

Questa scala aiuta i decisori a valutare il reale livello di indipendenza offerto da una tecnologia. La differenza cruciale risiede in chi detiene il potere decisionale: un progetto guidato da una singola azienda, che detiene il marchio registrato, può cambiare licenza in qualsiasi momento per motivi di profitto. Al contrario, un progetto governato da una fondazione neutrale protegge gli utenti da queste derive commerciali, garantendo stabilità.

Possiamo riassumere i livelli principali della scala in questo modo:

1. Controllo totale della community: Il software è governato da una fondazione no-profit. Le decisioni sono prese democraticamente e nessun singolo attore può privatizzare il codice. È il livello massimo di sovranità.
2. Controllo aziendale con licenza aperta: Il codice è accessibile, ma una singola azienda decide le sorti del progetto e detiene i marchi. Il rischio di cambi di rotta commerciali è sempre presente.
3. Software proprietario: Il codice è chiuso, segreto e totalmente controllato dal fornitore. La sovranità dell’utente sui propri strumenti è nulla.

Drupal come esempio principe di ecosistema aperto

Quando parliamo del livello massimo di sovranità, Drupal rappresenta l’esempio perfetto. Spesso ridotto alla semplice etichetta di sistema di gestione dei contenuti, Drupal è in realtà un framework e un ecosistema estremamente potente e flessibile, utilizzato dalle più grandi organizzazioni mondiali.

Ciò che rende Drupal unico è la sua governance distribuita. Non esiste un singolo proprietario aziendale che possa decidere di chiudere il progetto o di renderlo a pagamento dall’oggi al domani. La sua evoluzione è guidata dalla Drupal Association, una fondazione no-profit, e supportata da una forza lavoro globale di migliaia di sviluppatori e agenzie partner.

Questa struttura organizzativa garantisce alle organizzazioni che lo adottano una vera indipendenza a lungo termine. Se l’agenzia che ha sviluppato il tuo sito chiude o non soddisfa più le tue esigenze, puoi facilmente trovare un altro fornitore. Il codice è aperto e appartiene alla comunità: nessun trasferimento è bloccato.

Questa architettura solida e sicura è ideale per costruire piattaforme digitali complesse, portali governativi e sistemi aziendali critici senza mai cedere il controllo dei propri dati. Scegliere una piattaforma con questo livello di apertura significa investire in una tecnologia che mette gli interessi degli utenti al di sopra dei profitti di un singolo vendor.

In SparkFabrik non ci limitiamo a utilizzare questa tecnologia, ma partecipiamo attivamente ai tavoli in cui si definisce il futuro dell’ecosistema. Negli eventi più recenti sono emerse proprio le dimensioni della sovranità e dell’open source: temi che riguardano tanto le pubbliche amministrazioni, come discusso a Drupal4GovEU, quanto le valutazioni strategiche dei CTO nelle realtà private, come approfondito nel nostro articolo su Drupal, AI e platform engineering.

Grazie a questo coinvolgimento diretto nell’ecosistema, e alle nostre verticalizzazioni in Cloud Native, AI e supply chain security, progettiamo e sviluppiamo piattaforme Drupal moderne ottimizzate per performance, scalabilità e sicurezza. Con oltre un decennio di esperienza, siamo il partner tecnologico di riferimento in Italia. Scopri i nostri servizi di sviluppo e consulenza Drupal.

Come riconoscere (e difendersi) dal fenomeno dell’openwashing?

L’openwashing è una pratica di marketing ingannevole in cui aziende proprietarie promuovono i propri prodotti come open source per attirare clienti, pur mantenendo un controllo esclusivo sul codice. Per difendersi, le aziende devono verificare chi detiene i diritti del progetto e privilegiare software governato da fondazioni indipendenti e neutrali.

Cos’è l’openwashing e come riconoscerlo

L’etichetta di software aperto vende bene, perché è sinonimo di fiducia, sicurezza e innovazione. Purtroppo, questo ha generato il pericoloso fenomeno dell’openwashing. Si tratta di una pratica di marketing ingannevole con cui aziende fondamentalmente proprietarie si fregiano dell’etichetta aperta per attirare clienti, pur mantenendo un controllo chiuso sul codice core, sulle funzionalità avanzate o sui dati degli utenti.

Per i manager non tecnici, il rischio di cadere in questa trappola è altissimo. Si crede di acquistare indipendenza, investendo tempo e risorse nell’adozione di una piattaforma, per ritrovarsi poi intrappolati in dinamiche di monopolio. Di recente, abbiamo assistito a numerosi casi di grandi aziende che hanno improvvisamente revocato le licenze aperte ai propri prodotti, passando a modelli commerciali restrittivi e lasciando i clienti senza alternative praticabili se non quella di pagare tariffe maggiorate.

Come puoi difendere la tua azienda da queste trappole commerciali? Ecco due consigli pratici:

• Verifica la proprietà del marchio: cerca di capire se il software è gestito da una fondazione indipendente, come la Apache Software Foundation, oppure se i diritti appartengono a una singola società a scopo di lucro.

• Controlla le funzionalità bloccate: se le funzioni essenziali per la sicurezza o per l’integrazione enterprise sono disponibili solo a pagamento e il loro codice è chiuso, sei di fronte a un evidente caso di openwashing.

Il vero impegno: l’approccio di SparkFabrik all’ecosistema

La vera sovranità digitale non si ottiene semplicemente consumando codice gratuito scaricato da internet. Si costruisce partecipando attivamente alle community, contribuendo al miglioramento continuo degli strumenti e sostenendo finanziariamente e operativamente le fondazioni che ne garantiscono la neutralità.

Questo è il principio che guida le nostre scelte quotidiane. Dalla nostra esperienza diretta nello sviluppo di portali enterprise complessi, abbiamo visto come l’adozione di standard aperti riduca drasticamente il time-to-market e garantisca una reale scalabilità.

L’impegno concreto della nostra azienda si traduce in una partecipazione diretta agli ecosistemi che plasmano il futuro della tecnologia. Siamo orgogliosi di appartenere a organizzazioni internazionali di rilievo come LF Europe, la divisione europea della Linux Foundation, e alla OpenSSF, la fondazione dedicata alla sicurezza del software aperto.

Ma l’impegno non si ferma alle membership. Contribuiamo attivamente al codice degli ecosistemi open source che utilizziamo, investiamo nella diffusione della cultura tecnica attraverso articoli e contenuti social, e organizziamo webinar ed eventi come il Cloud Native Days Italy e il DrupalCamp Italy, che portano in Italia le comunità globali su cloud native e Drupal. (Scopri tutti i nostri eventi!)

Per approfondire la nostra visione, ti invitiamo a scoprire il nostro manifesto e il nostro impegno verso la comunità globale, un approccio che si riflette anche nelle nostre recenti contribuzioni a Drupal e all’AI nel 2025.

Questo livello di coinvolgimento non è solo una medaglia da appuntarsi al petto, ma si traduce in un vantaggio diretto e tangibile per i nostri clienti. Lavorare con un partner che siede ai tavoli dove si definiscono gli standard tecnologici garantisce l’adozione di protocolli di sicurezza elevati e sempre aggiornati. Soprattutto, assicura che le soluzioni architetturali proposte siano realmente libere da vincoli commerciali occulti, mettendo al primo posto la protezione e la sovranità dei dati aziendali.

Quali sono i prossimi passi per garantire la sovranità dei dati?

La sovranità dei dati non è un semplice problema tecnico, ma una decisione strategica fondamentale che spetta al management. Affidare il proprio patrimonio informativo a standard aperti e governati da fondazioni neutrali è l’unico vero antidoto al vendor lock-in, garantendo libertà di innovazione e sicurezza a lungo termine.

A questo punto, un concetto dovrebbe essere chiaro: affidare il proprio patrimonio informativo a sistemi chiusi equivale a cedere il controllo del futuro aziendale a soggetti terzi. I rischi economici e operativi di lungo periodo sono concreti e difficilmente reversibili.

L’adozione di standard aperti, rigorosamente governati da fondazioni neutrali e supportati da ampie comunità globali, rappresenta oggi l’unico vero antidoto al vendor lock-in. Questa scelta garantisce la libertà di innovare, la conformità alle stringenti normative europee sulla sicurezza e la certezza di poter cambiare rotta tecnologica senza subire ricatti commerciali. Dal cloud alle applicazioni aziendali, passando per i sistemi di gestione dei contenuti, le alternative libere e sicure esistono e sono pronte per le sfide di livello enterprise.

Questo percorso verso l’indipendenza non significa demonizzare le Big Tech. Senza gli enormi investimenti di player come Google, Microsoft, Amazon o Red Hat, l’ecosistema open source attuale semplicemente non esisterebbe.

Il problema non è chi ha costruito gli strumenti, ma chi li governa.

Oggi l’Europa contribuisce in modo significativo allo sviluppo del codice aperto, ma investe pochissimo nel suo ecosistema. La vera sfida per le nostre aziende è diventare attori protagonisti di questa tecnologia, non solo fruitori passivi.

Valutare criticamente lo stato della propria infrastruttura è il primo passo per costruire una vera indipendenza. I tuoi dati sono veramente tuoi? Sei libero di spostarli domani mattina senza bloccare i processi aziendali? Per rispondere a queste domande e pianificare una transizione sicura verso la vera indipendenza digitale, è essenziale affidarsi a partner tecnologici esperti come SparkFabrik.

Parla con i nostri esperti e scopri come possiamo aiutarti a proteggere il valore del tuo business mettendo la trasparenza, la sicurezza e la libertà al primo posto.

Costruire il core business su un’API di frontiera significa delegare la continuità operativa alla geopolitica. Un’infrastruttura può bloccarsi all’improvviso non per un guasto tecnico, ma perché il proprio Paese è stato escluso da una whitelist.

L’accesso ai modelli di intelligenza artificiale di frontiera non sarà universale: sta già diventando scarso, selettivo e regolato dalla geopolitica. La promessa che i token degli LLM seguano la traiettoria del software tradizionale, ovvero sempre più abbondanti e sempre più economici, si scontra con i limiti fisici dell’infrastruttura e con scelte strategiche già in atto da parte dei fornitori statunitensi. Lo ha messo a fuoco Anton Leicht nella sua analisi Cut Off: l’accesso ai modelli di punta sta diventando una risorsa per pochi. I primi segnali di chiusura dei rubinetti californiani impongono un cambio di rotta preventivo. Le organizzazioni non possono più limitarsi a consumare servizi esterni, ma devono iniziare a ingegnerizzare sistemi interni capaci di operare in autonomia, svincolando il proprio business dalle future decisioni prese oltreoceano.

La fine del modello Microsoft e il caso Mythos

Chi lavora nell’IT è abituato a una logica precisa: il software ha un costo marginale pari a zero. Quando Microsoft sviluppa un sistema operativo, il costo per distribuire la prima copia è immenso, ma quello per distribuire la milionesima è irrilevante. Questa dinamica ha convinto molti decisori che l’intelligenza artificiale di frontiera seguirà lo stesso percorso del mercato di massa. Purtroppo, l’IA generativa non risponde a queste regole economiche.

La prova più diretta arriva dallo stesso Microsoft. Il colosso di Redmond ha annunciato che da giugno 2026 GitHub Copilot abbandona l’abbonamento flat per una fatturazione a consumo basata su AI Credits (github.blog). Se il leader del settore developer-tools non riesce a sostenere economicamente il flat-rate sui costi di inferenza, l’illusione che i token IA seguano la curva di prezzo del software tradizionale è ufficialmente smentita. La frattura economica tra servizi gestiti e infrastrutture self-hosted è il tema dell’analisi Harness per agenti AI: la grande divergenza del pricing.

I modelli di frontiera non sono beni di consumo scalabili all’infinito. Ne abbiamo avuto un assaggio all’inizio di aprile, quando Anthropic ha annunciato Mythos, un modello di eccellenza dedicato alla cybersecurity. Le aziende europee si aspettavano di poterlo integrare nei propri flussi di lavoro. Invece, scorrendo la pagina dell’annuncio, le startup e i system integrator del Vecchio Continente hanno trovato una lista chiusa di partner privilegiati, quasi esclusivamente corporazioni basate negli Stati Uniti. L’Europa è rimasta tagliata fuori, un fatto riportato anche da Politico.

Osservando le mosse dei concorrenti, emerge un quadro chiaro. OpenAI ha recentemente lanciato l’iniziativa Daybreak per il suo modello gpt-5.5-cyber. Anche in questo caso, la promessa di un rilascio universale è stata sostituita da un accesso strettamente limitato. Le aziende leader stanno dando i primi segnali di voler chiudere i recinti.

Perché succede questo? Le aziende americane stanno affrontando questioni di sopravvivenza fisica, economica e strategica. Il valore si sta spostando dall’algoritmo nudo e crudo all’infrastruttura necessaria per farlo girare in sicurezza, e quell’infrastruttura oggi non basta per tutti.

Il collasso computazionale e la minaccia della distillazione

Fornire accesso a un modello di frontiera è un gioco a somma zero. Ogni token generato consuma energia reale, potenza di calcolo reale e hardware fisico che non può essere allocato altrove. Stiamo assistendo a un compute crunch, un deficit di fornitura globale analizzato a fondo da The Economist. La situazione è così tesa che persino giganti come Anthropic sono costretti a cercare accordi per la capacità di calcolo con aziende rivali come xAI.

Esattamente come i servizi cloud gratuiti impongono limiti rigidi di archiviazione (ad esempio i classici 15 GB massimi offerti da Google Drive per gli account base), le infrastrutture IA stanno sbattendo contro il muro invalicabile del costo marginale per token. Non c’è ottimizzazione software che tenga di fronte all’attrito della fisica.

A questo limite si aggiunge un problema commerciale devastante, ovvero la distillazione. I fast follower, come l’azienda cinese DeepSeek, riescono a mantenere un ritardo di soli 6-9 mesi rispetto alla frontiera tecnologica americana. Ci riescono sfruttando l’accesso API aperto per addestrare i propri modelli sui risultati generati dai leader di mercato. La proliferazione di strumenti open source di intelligenza artificiale generativa per lo sviluppo ha accelerato enormemente questo processo di trasferimento delle conoscenze.

L’economia di questa dinamica è insostenibile per chi fa ricerca primaria. Secondo uno studio dell’istituto IAPS, gli sviluppatori di modelli di frontiera hanno oggi una finestra di soli 6 mesi per recuperare gli immensi investimenti in ricerca e sviluppo prima che il loro modello venga clonato attraverso attacchi di distillazione. Aprire un’API al mondo intero significa vendere i propri segreti industriali a pochi centesimi per milione di token. La reazione logica a cui potremmo assistere su larga scala è la chiusura dell’accesso, l’implementazione di controlli rigorosi sull’identità dei clienti (KYC) e la limitazione dell’uso a partner fidati. Se l’infrastruttura scricchiola e la proprietà intellettuale evapora, la politica interviene per decidere chi ha diritto a sedersi al tavolo.

La geopolitica dei token: quando l’accesso diventa un’arma

Il governo degli Stati Uniti ha smesso di considerare l’intelligenza artificiale come un semplice settore software. Oggi la tratta come un asset critico di sicurezza nazionale e un potente strumento di leva diplomatica. Le dinamiche in gioco ricordano da vicino quelle della cybersecurity militare.

La logica è spietata ma coerente. Anton Leicht solleva un punto inequivocabile: se fossi la NSA e sedessi su una pila di vulnerabilità zero-day, vorrei assolutamente sapere quali di questi exploit un modello come Mythos è in grado di trovare. Vorrei usare quel vantaggio strategico prima che i vendor pubblichino le patch. Non è una teoria del complotto, è la storia recente dell’informatica, come ci insegna il caso EternalBlue. Fornire un modello avanzato di cybersecurity a governi stranieri o aziende non allineate significa cedere un vantaggio tattico inaccettabile per l’intelligence americana.

Questa postura protezionistica si riflette in iniziative legislative concrete. La proposta del GAIN Act segue esattamente questa traiettoria, garantendo che gli acquirenti americani abbiano il diritto di prelazione sulle risorse computazionali e sui token generati sul suolo nazionale. L’accesso all’IA diventa moneta di scambio nelle relazioni internazionali, influenzando accordi commerciali e alleanze, come evidenziato dalle tensioni sulle intese tecnologiche discusse da Donald Trump e Keir Starmer riportate dal The Guardian, o dalle nuove regolamentazioni analizzate dal Washington Post.

L’illusione di un accesso democratico all’IA rischia di svanire presto. Ci stiamo dirigendo verso una spaccatura globale tra chi controlla i modelli di frontiera e chi ne è escluso.

Warhol diceva che la cosa bella della Coca-Cola è che il presidente degli Stati Uniti beve la stessa identica Coca-Cola che bevi tu. Fino a ieri, una piccola agenzia europea interrogava la stessa API di OpenAI usata dal Pentagono, ma la traiettoria futura punta in un’altra direzione. Questo potenziale AI divide, analizzato da Foreign Affairs e dai report RAND sulla sicurezza globale, trasforma gli impatti del quadro normativo sulla sovranità digitale dell’Unione Europea in questioni di pura sopravvivenza economica. Il cronometro è già partito: come ha avvertito il CEO di Mistral su Business Insider, l’Europa ha una finestra di soli due anni per evitare una dipendenza tecnologica irreversibile dagli Stati Uniti. Per questo motivo, le aziende europee e le medie potenze globali (FAI) non possono restare a guardare sperando in un invito al club esclusivo.

Oltre il recinto: l’architettura ibrida come unica via

Se l’accesso illimitato alle API di frontiera non sarà più garantito per tutti, come deve comportarsi un’azienda europea per continuare a rilasciare software competitivo? La risposta non è costruire un modello linguistico da mille miliardi di parametri nel seminterrato aziendale. La soluzione risiede nell’ingegneria del software, specificamente nella stratificazione dell’IA e nell’adozione di architetture ibride.

Dobbiamo spostare il focus dal “quale modello usare” al “come orchestrare i modelli”. Costruire un’applicazione vincolandola direttamente alle API di un singolo fornitore americano è oggi un rischio architetturale inaccettabile. Le imprese devono costruire layer di astrazione intermedi. Un buon design architetturale permette di fare routing dinamico, valutando in tempo reale la complessità della richiesta e instradandola verso il modello più adatto, disponibile ed economico in quell’istante.

Nella pratica, immagina un sistema di supporto clienti. Una semplice richiesta di classificazione di un ticket viene instradata a un modello locale veloce ed economico, mentre solo l’analisi di un contratto legale complesso raggiunge il costoso modello di frontiera.

Non serve un modello generalista avanzato per risolvere l'80% dei problemi aziendali. L’infrastruttura locale diventa il vero scudo difensivo.

L’estrazione di dati da una fattura o la generazione di documentazione tecnica interna possono essere gestite brillantemente da modelli open-source locali, addestrati e ottimizzati per domini specifici. Questo approccio riduce drasticamente i costi operativi, garantisce la privacy del dato e azzera il rischio di lock-out geopolitico. Come sottolineato da Leicht nelle sue riflessioni sugli imperativi di importazione e ribadito dai report RAND sulla sicurezza dei datacenter, mantenere il controllo sui propri ambienti di calcolo è l’unica strategia sostenibile.

L’integrazione dell’intelligenza artificiale in architetture enterprise orientate alla sovranità dimostra che è possibile mantenere il controllo totale sulle proprie operation. Riservare le chiamate ai modelli di frontiera solo per i task di ragionamento complesso significa ottimizzare le risorse e proteggere il business, dimostrando che l’indipendenza è prima di tutto una scelta architetturale. In un periodo che Anton Leicht definisce il momento più pericoloso per le policy sull’IA, chi progetta sistemi a compartimenti stagni sopravvive ai futuri blocchi esterni.

Conclusione

L’esaurimento dell’accesso universale all’IA di frontiera non frena lo sviluppo tecnologico, ma ne ridefinisce le regole: il vantaggio competitivo si sposta dall’utilizzo passivo dei modelli al loro controllo.

La scarsità dei token e le restrizioni geopolitiche stanno tracciando una linea netta tra chi subisce le decisioni dei grandi provider e chi mantiene il controllo della propria infrastruttura.

Le aziende che prospereranno nel prossimo decennio non saranno quelle dotate del budget più alto per pagare costosi abbonamenti API d’oltreoceano. Saranno quelle che avranno compreso come proteggere i processi di trasformazione digitale dalle interruzioni di servizio. Progettare sistemi capaci di funzionare, scalare e generare valore anche nel giorno in cui il rubinetto di San Francisco dovesse chiudersi non è più un esercizio teorico. È l’unico piano industriale sensato per garantire la sovranità e il futuro del proprio business.

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!

Per decenni, l’industria del software ha operato secondo una logica implicita molto permissiva: rilascia il prodotto velocemente, correggi bug e falle di sicurezza dopo tramite aggiornamenti. Un difetto nel codice poteva avere effetti gravi, come paralizzare ospedali o filiere logistiche,ma larga parte dei rischi ricadeva sugli utenti finali. Il Cyber Resilience Act (CRA) mette fine a questa logica.

Nel mondo dei prodotti fisici, invece, i produttori sono sottoposti a vincoli e responsabilità molto più stringenti. Ad esempio, Se un’azienda immette sul mercato un elettrodomestico con un difetto di fabbrica che rischia di causare un cortocircuito, il prodotto viene immediatamente ritirato e il produttore ne risponde legalmente. Finora, per i prodotti digitali, questo livello di responsabilità diretta non esisteva.

Con questa nuova normativa, l’Unione Europea ha deciso di equiparare il mondo digitale a quello fisico. Se vendi software nel mercato unico europeo, devi garantirne la sicurezza dalla fase di progettazione fino al termine del suo ciclo di vita.

Non si tratta di una semplice raccomandazione. La sicurezza informatica cessa di essere una caratteristica opzionale e diventa un requisito vincolante per l’accesso al mercato.

Prima di affrontare le complesse sfide tecniche legate all’adeguamento, devi rispondere a una domanda fondamentale: il tuo prodotto rientra in questa normativa?

Nelle prossime sezioni esploreremo esattamente chi è coinvolto, chi è escluso e come funzionano le classi di rischio. Ti guideremo attraverso i concetti chiave con l’esperienza di chi ha seguito l’evoluzione di questa legge fin dalle sue prime bozze, aiutandoti a trasformare un obbligo normativo in un reale vantaggio competitivo per la tua azienda.

Perché l’Europa ha deciso che il software non può più ignorare la sicurezza?

L’Europa ha introdotto il Cyber Resilience Act per rendere la sicurezza informatica un requisito legale obbligatorio per i prodotti digitali. L’obiettivo è proteggere il mercato dalle vulnerabilità sistemiche, superando la frammentazione normativa e trasferendo la responsabilità della sicurezza dai consumatori finali ai produttori di software.

Prima dell’approvazione di questa legge, mancavano requisiti minimi obbligatori. Ogni stato membro aveva linee guida diverse, creando un mosaico normativo che penalizzava le aziende virtuose e lasciava enormi falle nella protezione delle infrastrutture. L’onere della sicurezza ricadeva sulle spalle degli utenti, costretti a districarsi tra aggiornamenti costanti e configurazioni complesse.

La spinta decisiva per legiferare è arrivata dalla realtà dei fatti. Negli ultimi anni, abbiamo assistito a incidenti che hanno dimostrato come una singola falla possa mettere in ginocchio migliaia di organizzazioni simultaneamente. Questi eventi hanno reso evidente la necessità di comprendere i rischi e le vulnerabilità della software supply chain per evitare effetti a catena devastanti.

Tra i casi storici che hanno guidato il legislatore europeo troviamo:

• L’attacco a SolarWinds, dove un codice malevolo inserito in un aggiornamento legittimo ha compromesso agenzie governative e aziende Fortune 500.

• La vulnerabilità sistemica di Log4Shell, un difetto in una minuscola libreria di logging che ha esposto milioni di server a livello globale.

• La compromissione di Codecov, che ha permesso agli attaccanti di esfiltrare credenziali direttamente dagli ambienti di CI/CD.

Questi incidenti hanno aperto gli occhi dei legislatori, mettendo in evidenza falle sistemiche in grado di innescare effetti a catena devastanti. Hanno dimostrato che il problema risiede nella base stessa dello sviluppo, colpendo la Supply Chain Security, ovvero letteralmente la sicurezza della catena di approvvigionamento del software.

Il CRA ribalta questa logica: si passa da un approccio reattivo, basato sul rilascio frenetico di patch dopo un attacco, a una sicurezza preventiva. La sicurezza deve essere integrata fin dalla fase di progettazione, adottando il principio della  Security by Design, e le aziende dovranno adottare pratiche rigorose di software supply chain management.

Sarà necessario garantire che ogni componente di terze parti sia tracciato, verificato e mantenuto sicuro fin dal primo giorno di sviluppo. Ad esempio, l’uso di strumenti per generare e monitorare le distinte base del software (SBOM) diventerà uno standard operativo per una secure software supply chain. Non basta più reagire bene; la legge ora impone di progettare in modo sicuro.

Quali prodotti software rientrano nel perimetro del Cyber Resilience Act?

Il Cyber Resilience Act si applica a tutti i “prodotti con elementi digitali” immessi sul mercato europeo. La normativa coinvolge produttori, importatori e distributori di applicazioni, sistemi operativi, firmware e componenti software, stabilendo regole di sicurezza obbligatorie per chiunque sviluppi e commercializzi tecnologia nell’Unione Europea.

Per capire se la tua azienda è coinvolta, devi guardare alla definizione di prodotto digitale. Il concetto di “Prodotti con Elementi Digitali”  è stato volutamente formulato in modo ampio per evitare scappatoie legali. In termini semplici, se il tuo prodotto contiene del codice e comunica con l’esterno, è quasi certamente soggetto alla normativa.

La legge non fa distinzione tra un’applicazione mobile scaricata da uno store, un software gestionale installato on-premise o il firmware che fa funzionare un router aziendale. Se il tuo codice elabora dati o si connette a una rete, è altamente probabile che rientri nel raggio d’azione del legislatore.

La normativa definisce con precisione chi deve assumersi l’onere della conformità:

• I produttori di software commerciale, indipendentemente dalle dimensioni dell’azienda, che vendono licenze o distribuiscono app nel mercato UE.

• I fornitori di componenti software, inclusi coloro che sviluppano SDK, librerie o moduli che verranno poi integrati nei prodotti di altre aziende.

• Gli importatori e distributori che immettono sul mercato europeo tecnologie sviluppate al di fuori dei confini dell’Unione.

Un aspetto cruciale da comprendere è il legame con la secure software supply chain. Il perimetro della legge non si limita al codice scritto dai tuoi sviluppatori, ma include tutte le librerie open source e i componenti di terze parti integrati nel prodotto finale.

In altre parole, sei legalmente responsabile anche per le vulnerabilità presenti nei pacchetti esterni che hai deciso di includere. Per questo motivo, diventa vitale adottare i principi e le best practice per la sicurezza applicativa del software fin dalle primissime fasi di sviluppo.

Un altro nodo molto dibattuto riguarda le piattaforme SaaS (Software as a Service). Sebbene l’infrastruttura cloud in sé possa ricadere sotto altre direttive, il software fornito tramite modello SaaS è spesso considerato un prodotto con elementi digitali.

Se la tua azienda offre servizi cloud, è essenziale valutare tempestivamente la propria posizione e implementare strategie di software supply chain security conformi per evitare sanzioni.

Tuttavia, il legislatore ha previsto delle esclusioni specifiche per evitare sovrapposizioni normative:

• Il software a uso interno, sviluppato su misura e utilizzato esclusivamente all’interno dell’azienda senza essere commercializzato.

• I prodotti già coperti da normative settoriali altrettanto stringenti, come i dispositivi medici regolati dal Medical Devices Regulation o i sistemi software per l’automotive.

• I progetti open source sviluppati e mantenuti al di fuori di qualsiasi logica commerciale, per tutelare la ricerca e la collaborazione libera.

L’obiettivo è creare una catena di fornitura sicura a livello continentale, colpendo i prodotti commerciali che pongono rischi reali agli utenti, senza soffocare l’innovazione interna o sovra-regolamentare settori già presidiati.

Come funzionano le classi di rischio del Cyber Resilience Act?

Il Cyber Resilience Act classifica i prodotti in tre livelli: la Classe Default per la maggior parte dei software, e due classi di “Prodotti Importanti” (Classe I e Classe II) per i sistemi critici. A ogni livello corrispondono requisiti di valutazione della conformità progressivamente più severi.

Per un Project Manager o un responsabile IT, capire in quale “cassetto” inserire il proprio progetto è il primo passo operativo.

L’Europa ha scelto un approccio proporzionale. Non ha senso imporre gli stessi controlli di sicurezza a un’app per la gestione delle note e a un firewall di livello enterprise. Per questo motivo, il legislatore ha strutturato un sistema a piramide che determina l’impegno richiesto alle aziende.

Per precisione tecnica, è utile notare che la Classe I e la Classe II compongono la categoria dei cosiddetti “Prodotti Importanti” (Allegato III del regolamento). Esiste poi una categoria ancora più ristretta di “Prodotti Critici” (Allegato IV) soggetta a regole specifiche. La tabella seguente riassume come sono suddivise le categorie di rischio principali.

L’impatto sulle moderne architetture IT della classificazione stabilita dal CRA è profondo. Tecnologie fondamentali per il paradigma Cloud Native, come i container runtime e gli hypervisor, sono state inserite esplicitamente nella Classe II. Questo significa che i motori che fanno girare i microservizi di mezza Europa dovranno superare gli esami più severi previsti dalla legge.

Se la tua azienda sviluppa o fornisce infrastrutture basate su Kubernetes o ambienti virtualizzati, il livello di attenzione deve essere massimo. Diventa fondamentale approfondire le sfide e le strategie di Cloud Native Security per capire come questi requisiti cambieranno il modo in cui orchestriamo e distribuiamo le applicazioni moderne. La sicurezza dell’infrastruttura di base non è più solo una best practice operativa, ma un obbligo di legge certificato.

Quali sono le scadenze e le date da segnare per il Cyber Resilience Act?

Il Cyber Resilience Act prevede un’applicazione graduale per permettere alle aziende di adeguarsi. Le date chiave sono l'11 giugno 2026 per l’operatività degli organismi di valutazione, l'11 settembre 2026 per l’obbligo di notifica delle vulnerabilità, e l'11 dicembre 2027 per la piena conformità dei prodotti.

Il regolamento è ormai in vigore, e le aziende devono iniziare a pianificare l’adeguamento al CRA. Il legislatore ha previsto un periodo di transizione a tappe per permettere al mercato di organizzarsi senza subire blocchi improvvisi.

Ecco le scadenze legali che ogni Project Manager e CTO deve conoscere:

• 11 giugno 2026: Diventano operative le disposizioni relative agli organismi di valutazione della conformità. Inizierà ufficialmente l’infrastruttura di certificazione per i prodotti di Classe I e II.

• 11 settembre 2026: Scatta l’obbligo di notifica. I produttori dovranno segnalare alle autorità competenti le vulnerabilità attivamente sfruttate e gli incidenti di sicurezza significativi entro limiti di tempo stringenti.

• 11 dicembre 2027: Entrano in vigore tutti i requisiti obbligatori per i nuovi prodotti. Da questa data, nessun software soggetto al regolamento potrà essere venduto nell’UE senza dimostrare la piena conformità al CRA.

Da proposta controversa a legge: cosa cambia per l’open source?

Il Cyber Resilience Act esclude esplicitamente dal perimetro normativo diretto il software open source sviluppato al di fuori di logiche commerciali. Questa è una tutela fondamentale per l’ecosistema che sta alla base delle tecnologie Cloud Native e protegge i contributor indipendenti dell’ecosistema open source.

Eppure questa esclusione non è scontata: è il risultato diretto di una forte mobilitazione della community, che ha ottenuto una revisione della proposta originale ed un testo finale molto più equilibrato.

Oggi, la legge fa una distinzione molto chiara e pragmatica. Se un programmatore sviluppa un software o una libreria nel tempo libero e la pubblica online come progetto open source senza fini di lucro, non è soggetto agli obblighi del CRA.

Tuttavia, se un’azienda prende quel progetto gratuito, lo integra nel proprio software proprietario e vende il prodotto finale, l’azienda si assume la totale responsabilità legale della sicurezza di quel componente.

Questo meccanismo sposta la responsabilità esattamente dove risiede il profitto. Le aziende che utilizzano componenti open source per costruire i propri servizi dovranno investire risorse per verificare il codice open source che scelgono di adottare. Un compromesso che tutela i creatori indipendenti obbligando le aziende a fare la loro parte.

SparkFabrik e il #FixTheCRA: quando la community si è fatta sentire

Il raggiungimento di questo equilibrio normativo non è avvenuto per caso. È il risultato di una forte mobilitazione globale in cui la community tecnologica ha fatto sentire la propria voce in modo coeso e strutturato.

Quando il regolamento era ancora in fase di bozza, il testo originale presentava un rischio enorme per l’innovazione. La formulazione iniziale non distingueva in modo chiaro tra il rilascio di codice open source da parte di volontari e l’immissione sul mercato di un prodotto commerciale.

Questo avrebbe reso i contributor upstream legalmente responsabili per le vulnerabilità dei loro progetti, anche quando questi venivano usati da multinazionali per generare profitti.

Comprendendo la gravità della situazione, SparkFabrik e molti altri attori del settore si sono uniti alla campagna #FixTheCRA promossa dalla Linux Foundation Europe. Il nostro obiettivo era chiaro: difendere la competitività europea e sovranità digitale dell’UE senza distruggere il modello collaborativo su cui si basa il software moderno.

Il nostro CTO, Paolo Mainardi, in qualità di Advisory Member della Linux Foundation Europe, ha partecipato attivamente a questo sforzo di advocacy. Abbiamo documentato e diffuso le preoccupazioni della community per l’open source, spiegando ai decisori politici che strangolare i manutentori indipendenti avrebbe reso l’Europa meno sicura, non il contrario.

Questo sforzo riflette il profondo impegno di SparkFabrik nei confronti dell’ecosistema open source, che consideriamo il vero motore dell’innovazione digitale.

La mobilitazione della community ha funzionato, portando a un testo finale molto più equilibrato e consapevole delle dinamiche di sviluppo reali. Anzi: oggi la posizione dell’Europa e delle PA verso l’open source software è sempre più favorevole, riconoscendone l’importanza per gli obiettivi di sovranità digitale.

Cosa significa il CRA per la tua azienda e quali sono i prossimi passi?

Per la tua azienda, il CRA significa dover mappare accuratamente tutto il software prodotto e utilizzato, valutare le classi di rischio e preparare una documentazione trasparente sulle dipendenze. Il primo passo è eseguire un assessment completo per identificare le vulnerabilità attuali.

Il messaggio centrale è inequivocabile: il CRA trasforma la sicurezza informatica da una caratteristica opzionale del prodotto a un requisito legale indispensabile per accedere al mercato europeo. Oggi non è più possibile pensare di rilasciare un software senza pensare anche alla sicurezza, già a partire dalla fase di progettazione.

Il primo passo è comprendere se il tuo prodotto rientra nella normativa e in quale livello di rischio si colloca. Questa mappatura iniziale è fondamentale per evitare di disperdere risorse o, al contrario, sottovalutare obblighi legali stringenti.

Il passo successivo è capire come affrontare l’adeguamento tecnico. Si tratta di un impatto profondo che richiede conoscenze specifiche, dalla gestione sicura delle dipendenze all’implementazione di controlli automatizzati nelle pipeline di rilascio.

Inoltre, non bisogna dimenticare che questa legge non opera in isolamento, fa parte di una strategia europea molto più ampia. L’Unione Europea sta costruendo uno scudo normativo integrato.

Mentre il CRA si concentra sulla sicurezza intrinseca dei prodotti, è fondamentale anche analizzare l’impatto di NIS2 e DORA sulla cybersecurity per comprendere come proteggere le infrastrutture critiche, tenendo sempre d’occhio l’AI Act per i sistemi ad alto rischio.

Per navigare questa complessità e la transizione verso la compliance senza rallentare il time-to-market, è opportuno valutare il supporto di un partner esperto come SparkFabrik, in grado di unire competenze normative e profonda padronanza delle architetture Cloud Native.

A garanzia della nostra competenza in questo ambito, SparkFabrik è in fase di certificazione ISO 27001, lo standard internazionale per la gestione della sicurezza delle informazioni. La sinergia con il CRA è diretta: il risk management e i controlli operativi della ISO 27001 facilitano i risk assessment e il secure lifecycle management obbligatori del CRA. Chi già implementa i processi ISO 27001, infatti, ha un vantaggio significativo per raggiungere la compliance.

Nonostante le sfide tecniche, il Cyber Resilience Act non deve essere vissuto solo come un onere burocratico. Questa transizione è un’opportunità straordinaria per eliminare il debito tecnico, migliorare la stabilità dei prodotti e conquistare la fiducia dei clienti enterprise, trasformando un obbligo di legge in un solido vantaggio competitivo.

Se la tua azienda sviluppa software commerciale o gestisce piattaforme complesse, non aspettare il 2027 per scoprire che la tua architettura non è conforme. Scopri come SparkFabrik può supportarti con il Cyber Resilience Act attraverso servizi di assessment, modernizzazione e implementazione di pipeline sicure by design.

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.

Vi è mai capitato di sedervi al computer una sera per prenotare una visita medica tramite il portale della vostra regione, oppure per pagare la tassa sui rifiuti del vostro comune? Inserite i vostri dati anagrafici, fornite informazioni sensibili sulla vostra salute o sul vostro patrimonio, e cliccate su “invia”. Ma vi siete mai chiesti dove finiscono fisicamente quei dati? Chi possiede i server su cui sono archiviati? E soprattutto, chi ha scritto il codice che gestisce quelle informazioni così delicate?

Queste domande non sono più semplici speculazioni per addetti ai lavori, ma rappresentano il nucleo di un dibattito fondamentale per il nostro futuro. Il 29 gennaio 2026, la città di Bruxelles ha ospitato la prima edizione di Drupal4Gov EU. Questo evento, organizzato durante la Open Source Week dalla Drupal Community of Practice della Commissione Europea e degli EUIBAs, si è rivelato un momento cruciale per definire le linee guida dei servizi pubblici del domani.

Durante la conferenza è emersa una verità inequivocabile. La sovranità digitale non è un concetto astratto o un vezzo burocratico, ma una necessità pratica e urgente. I governi e le istituzioni europee stanno affrontando questa sfida attraverso l’adozione strategica di tecnologie aperte. In questo scenario di profonda trasformazione, piattaforme open source come Drupal si trovano in prima linea, offrendo gli strumenti necessari per costruire un’infrastruttura pubblica sicura, trasparente e realmente indipendente.

Cos’è la sovranità digitale e perché riguarda tutti noi?

La sovranità digitale è la capacità di uno Stato o di un’istituzione di esercitare il pieno controllo sulle proprie infrastrutture tecnologiche, sui dati dei cittadini e sui software utilizzati. Senza questa autonomia, gli enti governativi dipendono da fornitori esterni, perdendo il potere decisionale sui servizi pubblici essenziali.

Per comprendere questo concetto, possiamo usare una metafora molto vicina alla vita quotidiana: la differenza tra vivere in affitto e possedere una casa. Un’istituzione che non controlla la propria tecnologia è esattamente come un inquilino. Può usare l’appartamento, ma non ha le chiavi per cambiare la serratura, non può decidere di ristrutturare le stanze e, peggio ancora, il proprietario potrebbe decidere di aumentare l’affitto a dismisura o di sfrattarlo con poco preavviso. Costruire i servizi per i cittadini su piattaforme chiuse e proprietarie significa, di fatto, consegnare le chiavi della casa pubblica a entità private.

Per garantire una vera indipendenza, il controllo deve articolarsi su tre livelli fondamentali:

• Il controllo sui dati: Riguarda il luogo fisico in cui le informazioni vengono salvate. I dati sanitari, fiscali e anagrafici dei cittadini devono risiedere in server soggetti alle normative europee, protetti da ingerenze o sorveglianze di nazioni terze.
• Il controllo sulle operazioni: Definisce chi gestisce materialmente i sistemi giorno per giorno. Le amministrazioni devono avere la garanzia che le infrastrutture critiche non vengano interrotte o alterate da decisioni aziendali prese dall’altra parte del mondo.
• Il controllo sulla tecnologia: Riguarda chi scrive, ispeziona e modifica il codice sorgente. Solo avendo accesso ai meccanismi interni del software è possibile verificare l’assenza di vulnerabilità nascoste e adattare gli strumenti alle reali necessità della collettività.

L’impatto di tutto questo sui cittadini è diretto e tangibile. La tutela della privacy non può esistere senza la certezza matematica di come i dati vengano processati. La sicurezza nazionale richiede che i sistemi governativi resistano a ricatti tecnologici o attacchi informatici. Infine, la continuità dei servizi pubblici essenziali deve essere garantita in ogni momento, assicurando che un ospedale, un tribunale o un municipio possano sempre operare senza dipendere dalle sorti commerciali di un singolo fornitore di software.

Come l’open source garantisce la sovranità digitale della PA?

L’open source garantisce la sovranità digitale della Pubblica Amministrazione eliminando il vendor lock-in, ovvero la dipendenza forzata da un singolo fornitore tecnologico. Adottando codice aperto, i governi mantengono la libertà di ispezionare, modificare e trasferire i propri sistemi senza subire vincoli commerciali o limitazioni tecniche esterne.

Il concetto di vendor lock-in è uno dei rischi più gravi per un ente pubblico. Quando un’amministrazione acquista un software chiuso, i cui meccanismi interni sono segreti, si lega a doppio filo all’azienda che lo produce. Se quell’azienda decide di raddoppiare i prezzi delle licenze, di interrompere il supporto tecnico o di cambiare le funzionalità del prodotto, l’ente non ha alternative. Migrare verso un nuovo sistema costerebbe troppo tempo e denaro, costringendo il governo ad accettare condizioni sfavorevoli pagate con i soldi dei contribuenti. Il codice aperto spezza questa catena, restituendo alle istituzioni la totale libertà di scelta e di manovra.

Durante l’evento di Bruxelles è stata utilizzata un’analogia estremamente efficace per spiegare questa dinamica: l’analogia dell’acquedotto. Un governo ha il dovere assoluto di garantire che l’acqua potabile che arriva nelle case dei cittadini sia sicura, pulita e priva di agenti patogeni. Per farlo, non può limitarsi a fidarsi della parola di un fornitore privato; deve poter ispezionare le tubature, analizzare le fonti e controllare i filtri.

Lo stesso identico principio si applica alla tecnologia. Un governo deve conoscere e verificare in modo indipendente il software su cui si basano i servizi ai cittadini. Se il codice è segreto, l’ispezione è impossibile. Ed è anche una questione di responsabilità: un governo è anche responsabile di sapere quali progetti software open source sono sicuri e affidabili da utilizzare. E l’unico modo reale per farlo è essere direttamente coinvolti nel modo in cui questi progetti vengono creati e mantenuti.

Questo richiede un profondo cambio di paradigma culturale e finanziario da parte delle istituzioni, simile alla trasformazione digitale accelerata durante la pandemia. Non basta più acquistare licenze come si comprano articoli di cancelleria. In qualità di azienda fortemente impegnata nello sviluppo e nella promozione dell’ecosistema open source, conosciamo bene questa dinamica.

Come ha sottolineato con precisione il nostro CTO Paolo Mainardi durante le riflessioni scaturite dalla conferenza:

“Open Source is a public good that must be supported and funded in a new, modern way: like public infrastructure”.

Il software libero deve essere trattato, finanziato e manutenuto esattamente come si fa con le autostrade, i ponti o, per l’appunto, gli acquedotti pubblici.

Drupal4GovEU: lezioni di sovranità digitale dal cuore dell’Europa

La prima edizione di Drupal4GovEU ha dimostrato che per raggiungere una reale sovranità digitale, le istituzioni europee devono smettere di essere semplici consumatori di software e diventare contributori attivi. Partecipare all’ecosistema open source è l’unico modo per garantire la sicurezza e l’evoluzione continua dei servizi pubblici.

Le nostre osservazioni dirette dalla conferenza confermano un trend inequivocabile. Le amministrazioni che si limitano a scaricare e utilizzare il codice aperto ottengono solo un beneficio parziale. Per governare davvero la tecnologia, è necessario sedersi ai tavoli decisionali delle community, proporre modifiche e investire risorse nello sviluppo condiviso. Per chi desidera approfondire i singoli interventi, è disponibile la playlist ufficiale dell’evento su YouTube, una risorsa preziosa per comprendere la direzione dell’innovazione pubblica europea.

Il ruolo attivo dei governi e l’intelligenza artificiale locale

Il passaggio da fruitori passivi a creatori attivi è stato il fulcro del keynote di Sachiko Muto, intitolato “Unlocking Public Sector Contributions to Open Source”. Il suo intervento ha chiarito come i governi debbano strutturarsi per essere effettivamente coinvolti nei progetti open source.

Essere direttamente coinvolti, finanziare lo sviluppo e permettere ai propri sviluppatori interni di scrivere codice per i progetti aperti è l’unico modo per comprendere appieno come funzionano (davvero) questi progetti ad alto interesse pubblico. Solo contribuendo direttamente, le istituzioni possono assicurarsi che i software rispondano esattamente alle complesse esigenze della macchina amministrativa pubblica.

“Public institutions should take part in open-source projects not only by providing funding, but also by actively contributing to them.”

Questa necessità di controllo si fa ancora più stringente quando si parla di nuove tecnologie. Josef Kruckenberg ha illustrato un caso pratico illuminante nella sua presentazione “How AI is Supporting End Users and Editors at the Canton of Basel-Stadt”. Il Cantone di Basilea ha implementato un chatbot basato sull’intelligenza artificiale per aiutare i cittadini a sbrigare le pratiche burocratiche in modo rapido e intuitivo. La vera innovazione, tuttavia, risiede nell’architettura del sistema.

Per mantenere i dati sensibili al sicuro e garantire la sovranità digitale, l’intero modello di intelligenza artificiale è ospitato in data center svizzeri, come quelli forniti da Infomaniak. Questo approccio dimostra che è possibile unire l’innovazione tecnologica più avanzata con la protezione rigorosa dei dati locali, senza cedere informazioni a provider oltreoceano.

Accessibilità e scalabilità per i cittadini europei

Oltre alla sicurezza, le piattaforme pubbliche devono gestire volumi di traffico immensi mantenendo coerenza strutturale ed accessibilità. Sandro d’Orazio e Massimiliano Molinari hanno raccontato il percorso di successo della Commissione Europea nella creazione di una soluzione centralizzata per il dominio Europa.eu. Utilizzando un’architettura basata su Drupal, sono riusciti a consolidare centinaia di siti web frammentati in un ecosistema coerente, migliorando drasticamente la sicurezza, la scalabilità e l’esperienza utente per milioni di cittadini europei.

Ma un servizio scalabile è inutile se non è utilizzabile da tutti. Il talk di Mike Gifford ha affrontato l’accessibilità non come un semplice requisito tecnico, ma come un diritto fondamentale. Gifford ha spiegato l’impatto pratico della Web Accessibility Directive (WAD) e dell’European Accessibility Act (EAA).

Costruire un sito governativo accessibile, che permetta a persone con disabilità visive, motorie o cognitive di navigare senza ostacoli, non è solo un obbligo per evitare sanzioni legali. È un dovere civico imprescindibile. Le piattaforme aperte permettono alle community di sviluppare moduli e temi già conformi a queste direttive, facilitando il lavoro delle amministrazioni nel garantire l’inclusione digitale totale.

Perché Drupal è il motore di innovazione per le istituzioni complesse ed i settori fortemente regolamentati?

Drupal si è affermato come il motore di innovazione per le istituzioni complesse grazie alla sua architettura flessibile, ai massimi standard di sicurezza e al supporto di una vasta community globale. Questa piattaforma open source permette di gestire enormi volumi di dati garantendo la totale aderenza alle normative.

Durante le sessioni di Bruxelles è emerso chiaramente come questo CMS (Content Management System, ovvero il sistema di gestione dei contenuti) non sia più considerato una semplice opzione tra le tante, ma la piattaforma definitiva per i portali governativi di alto livello. Un esempio concreto di questa eccellenza è proprio il portale ufficiale dell’Unione Europea, Europa.eu, che gestisce informazioni vitali per milioni di cittadini in decine di lingue diverse.

La forza di Drupal risiede nella capacità di modellare architetture informative estremamente complesse, tipiche dei ministeri o delle grandi agenzie pubbliche. Inoltre, la natura aperta del codice permette a migliaia di sviluppatori in tutto il mondo di identificare e risolvere potenziali vulnerabilità con una rapidità che i software proprietari non possono eguagliare.

La sicurezza e la conformità normativa sono pilastri non negoziabili per il settore pubblico. Un’architettura basata su tecnologie aperte facilita enormemente il rispetto di normative stringenti. Come abbiamo analizzato nel nostro approfondimento su l’impatto di NIS2 e DORA sulla cybersecurity nel Cloud Native, le istituzioni devono garantire una resilienza proattiva contro gli attacchi informatici. Drupal si integra perfettamente in ecosistemi cloud moderni, permettendo di applicare policy di sicurezza rigorose e di mantenere il pieno controllo su chi accede alle informazioni critiche.

L’esperienza diretta del nostro team conferma queste potenzialità. In SparkFabrik progettiamo e sviluppiamo soluzioni per organizzazioni che non possono permettersi il minimo margine di errore. Abbiamo realizzato progetti complessi in ambiti dove la sicurezza e la stabilità sono vitali, fornendo soluzioni digitali per i financial services. Parliamo di piattaforme critiche per clienti del calibro di London Stock Exchange e Borsa Italiana/Euronext, soluzioni che si basano su architetture robuste e che richiedono livelli di affidabilità paragonabili, se non superiori, a quelli governativi.

Allo stesso modo, gestiamo modernizzazioni su larga scala nel settore dell’istruzione, come dimostra il nostro lavoro per La Scuola, dove abbiamo implementato un’infrastruttura sicura e scalabile basata su Drupal 10. Queste esperienze dimostrano che le tecnologie aperte sono pronte per sostenere i carichi di lavoro più critici e sfidanti.

Conclusione

La prima edizione di Drupal4GovEU ha tracciato una linea netta per il futuro dei servizi digitali europei. La sovranità digitale, l’accessibilità senza compromessi e l’adozione strategica dell’open source non sono più concetti teorici, ma i tre pilastri su cui costruire una Pubblica Amministrazione moderna, efficiente e realmente vicina ai bisogni del cittadino. Abbiamo visto come il controllo sui dati e sul codice sia l’unico scudo efficace contro il vendor lock-in e come la partecipazione attiva alle community di sviluppo sia vitale per la sicurezza nazionale.

Questo cambiamento di paradigma richiede coraggio e visione. I decisori pubblici, i project manager e i responsabili dell’innovazione all’interno delle organizzazioni complesse devono valutare con priorità elevata l’adozione di tecnologie aperte e sicure per i propri portali istituzionali.

Ma il passaggio verso l’indipendenza tecnologica è un percorso che non va affrontato in solitudine. SparkFabrik si pone come partner tecnologico chiave in questa transizione, grazie alla nostra comprovata esperienza nella contribuzione open source, nello sviluppo di architetture cloud native sicure, nella profonda expertise tecnica e strategica in Drupal.

Contattaci per una consulenza personalizzata con i nostri esperti: è il primo passo per trasformare le sfide normative in straordinarie opportunità di innovazione.