Oggi costruiamo in tre mesi quello che prima ci richiedeva tre anni. È qui che inizia la parte difficile.

Qualcosa è cambiato quest’anno nel nostro team di sviluppo, e ancora devo abituarmici. Negli ultimi tre mesi, un piccolo gruppo di persone in Guardian360 ha ricostruito la nostra piattaforma Lighthouse e l’ha estesa con più funzionalità nuove di quante ne consegnassimo in oltre tre anni. Non abbiamo assunto un team più numeroso e non abbiamo trovato un budget più grande. Lo sviluppo software assistito dall’AI ha semplicemente rimosso il vincolo che ha plasmato ogni decisione di roadmap che abbiamo mai preso: la carenza di persone e strumenti.

Sembra una buona notizia, e in gran parte lo è. Ma ha svelato un nuovo vincolo, e non si trova dove mi aspettavo. Quando costruire non è più scarso, lo diventa l’implementazione. I nostri partner, i managed service provider (MSP) che portano la nostra piattaforma di cybersecurity ai loro clienti, non riescono ad assorbire le nuove funzionalità alla velocità con cui ora possiamo produrle. E due ulteriori domande mi tengono occupato. Il software costruito così in fretta è davvero sicuro? E più funzionalità potrebbero erodere la semplicità che ci ha sempre contraddistinto?

Cosa cambia quando costruire non è più il collo di bottiglia?

Per la maggior parte della storia di Guardian360, la nostra roadmap è stata un elenco di cose che volevamo costruire, ordinate in base a ciò che potevamo permetterci di costruire. I partner hanno chiesto certe funzionalità per anni, e molti di loro hanno dovuto aspettare.

Oggi i nostri sviluppatori lavorano affiancati dall’AI per la generazione di codice, il testing e la documentazione. Abbiamo iniziato con Claude, il modello di Anthropic, e stiamo spostando sempre di più quel lavoro su Hermes. Hermes non è un modello ma uno strato che abbiamo costruito noi stessi. Utilizza large language model open source per alimentare quello che chiamiamo un cervello aziendale, e facilita gli agenti AI che ci aiutano in un’ampia gamma di compiti. Hermes, e i modelli open source che utilizza, girano nel nostro cluster di server nei Paesi Bassi, ed è una questione di principio tanto quanto di praticità. Claude non ha mai avuto accesso ai dati dei clienti sulla nostra piattaforma, perché i nostri accordi con i partner non consentono a quei dati di lasciare l’EU. Spostare una parte maggiore del nostro lavoro su infrastrutture che controlliamo segue la stessa logica.

Siamo tutt’altro che un’eccezione. Secondo il 2026 GenAI Code Security Report di Veracode, l’AI genera ormai circa la metà di tutto il codice committato. La domanda non è più se i team di sviluppo usano l’AI, ma cosa succede dopo.

Il software costruito con l’AI è davvero sicuro?

Questa è la preoccupazione che prendo più sul serio, e sospetto sia la prima domanda che molti lettori si porranno. La ricerca offre pochi motivi di conforto. Veracode ha riscontrato che circa il 44 percento dei task di generazione di codice AI ha introdotto una vulnerabilità rischiosa, con un tasso medio di superamento in sicurezza del 56 percento, appena cambiato rispetto al 55 percento del suo primo report. Lo studio di IOActive dell’aprile 2026 ha analizzato quasi 20.000 campioni di codice e ha riscontrato che il 31,6 percento dei campioni generati dall’AI era pienamente sfruttabile; nessun modello ha prodotto output interamente sicuro.

Ciò che mi preoccupa ancora di più è il divario tra percezione e realtà. La Cloud Security Alliance riporta che oltre il 75 percento degli sviluppatori in un sondaggio riteneva che il codice generato dall’AI sia più sicuro di quello scritto da umani, mentre il 56 percento ha ammesso che introduce frequentemente problemi di sicurezza. La velocità sembra competenza. Non lo è.

La conclusione di IOActive è che le organizzazioni devono trattare l’output dell’AI come input non attendibile e imporre una revisione di sicurezza obbligatoria prima del deployment. È esattamente così che lavoriamo: l’AI può scrivere il codice, ma ogni modifica viene revisionata da una persona che la comprende prima che raggiunga la produzione. Ora stiamo andando un passo oltre, rivolgendo il nostro stesso pentesting AI contro noi stessi, inclusa un’analisi crystal box del nostro codice sorgente, dove gli agenti di testing hanno pieno accesso al codice. Eseguiamo quell’analisi con diversi modelli, così che i punti ciechi di un modello abbiano meno probabilità di passare inosservati.

Lo stesso principio plasma il pentesting AI che stiamo portando ai nostri partner, dove l’AI esegue il test e il consulente del partner lo firma. Gli sviluppatori sembrano condividere questo istinto. Nel 2026 Developer Survey di Stack Overflow, quasi la metà degli intervistati ha dichiarato di fidarsi dell’output dell’AI quando può verificarlo, mentre solo il 6,6 percento affiderebbe all’AI una decisione importante.

Perché più funzionalità non significano automaticamente più valore?

La seconda preoccupazione è meno tecnica ma altrettanto reale. No Jitter ha recentemente descritto un “diluvio di funzionalità” nel software di comunicazione, dove i fornitori rilasciano centinaia di nuove funzionalità ogni anno mentre l’adozione resta indietro. I benchmark di Pendo suggeriscono che circa l’80 percento delle funzionalità costruite non raggiunge mai un’adozione significativa, e che il 6,4 percento delle funzionalità genera l’80 percento di tutti i clic. Quel pattern esisteva molto prima dell’AI. L’AI rende semplicemente più economico ripeterlo.

Guardian360 ha sempre cercato di offrire una piattaforma che un MSP possa spiegare a un membro del consiglio in pochi minuti. Ogni funzionalità che aggiungiamo rende tutto questo più difficile. Il costo di costruire una funzionalità è crollato; il costo di comprenderla no.

I nostri partner stanno già portando parecchia complessità. Una ricerca di CRN, pubblicata dal fornitore di sicurezza Coro, ha riscontrato che gli MSP gestiscono tra 6 e 20 o più fornitori per erogare servizi di sicurezza, valutano l’integrazione tra quegli strumenti appena 6,2 su 10, e che solo il 7 percento è soddisfatto del ritorno sui propri strumenti di sicurezza. L’ultima cosa di cui hanno bisogno da noi è un ulteriore strato di complessità, per quanto ben intenzionato.

Dove si è spostato il collo di bottiglia?

La ricerca DORA di Google offre una lente utile. Il suo report 2025 ha riscontrato, per la prima volta, una relazione positiva tra adozione dell’AI e throughput di delivery, ma l’adozione dell’AI correlava ancora con una minore stabilità di delivery: più fallimenti nelle modifiche, più rilavorazione e tempi di recupero più lunghi. DORA ha anche concluso che l’AI tende a rispecchiare e amplificare i tratti organizzativi esistenti, nel bene e nel male.

Estenderei quell’osservazione oltre il team di sviluppo. Una funzionalità crea valore solo quando un partner la comprende, la configura, la spiega a un cliente e costruisce un servizio attorno a essa. Quella catena procede a velocità umana. L’AI accelera il primo anello e lascia intatto il resto, il che significa che la coda si sposta semplicemente a valle, verso i nostri partner e i loro clienti.

Il sondaggio di Stack Overflow punta nella stessa direzione: le persone si fidano di ciò che possono verificare. Un partner che non ha mai visto una funzionalità funzionare non può verificarla, non può spiegarla e non la venderà.

Dovremmo semplicemente rallentare?

Alcuni partner sosterrebbero esattamente questo: fermatevi per un po’, stabilizzate, lasciateci recuperare. È un argomento legittimo e in parte sono d’accordo. Un fornitore che rilascia più velocemente di quanto il suo canale riesca a seguire sta ottimizzando per la propria soddisfazione, non per quella dei suoi partner.

Eppure rallentare artificialmente sprecherebbe un’opportunità che i piccoli fornitori europei raramente ottengono. La risposta, credo, è disciplina piuttosto che frenata. Significa decidere cosa non rilasciare, trattare la semplicità come un requisito di progettazione anziché come un ripensamento, e coinvolgere i partner prima che una funzionalità sia finita anziché dopo.

Parte di quella disciplina è integrata nella piattaforma stessa. Stiamo introducendo i workspace: invece di presentare ogni funzionalità su un’unica schermata, raggruppiamo le funzionalità per compito, così un partner vede solo ciò che il lavoro in corso richiede. L’interfaccia guidata dall’AI va oltre. Pagine, report e navigazione diventano definizioni anziché codice, e un agente costruisce la vista che un utente richiede entro i limiti del suo ruolo. Non è più un concetto. Lo mostreremo in funzione il 3 novembre, e vogliamo un feedback onesto dai nostri partner su se li aiuta davvero.

C’è un secondo modo per tenere bassa la complessità: lasciare che sia la piattaforma a fare una parte maggiore del lavoro. Oggi Lighthouse ti dice cosa potrebbe essere migliorato. In futuro lo correggerà anche, dove il partner e il suo cliente glielo consentono. Ogni compito che la piattaforma assume è un compito che un partner non deve più imparare, spiegare o pianificare.

Perché apriamo le porte della sala di controllo

Il logo di Guardian360 contiene un faro, e la metafora non è mai sembrata più accurata. Un faro è utile solo se la sua luce raggiunge la riva. Possiamo costruire la luce più brillante del mondo, ma sono i nostri partner a portarla ai loro clienti.

Ecco perché ospitiamo “Uno sguardo dalla sala di controllo” martedì 3 novembre 2026, dalle 09:30 alle 13:00 presso il Van der Valk Hotel di Woerden. Mostreremo ciò che abbiamo costruito, in funzione dal vivo anziché su slide, e daremo una prima occhiata a ciò che Guardian360 offrirà nel 2027. La partecipazione è gratuita, c’è spazio per circa 50 ospiti, e le iscrizioni sono aperte fino al 30 ottobre. Più delle dimostrazioni, apprezzo la conversazione. Preferirei sentirmi dire il 3 novembre che qualcosa è troppo complesso piuttosto che scoprirlo nei dati di adozione tra un anno.

Quindi, qual è adesso il tuo vincolo?

Se costruire non è più il tuo vincolo, e per molti MSP quel momento è più vicino di quanto sembri, qual è? Per noi la risposta è chiara. Quando costruire non è più scarso, lo diventa l’implementazione. È qui che inizia la parte difficile, ed è un lavoro che possiamo fare solo insieme ai nostri partner.

Fonti

Veracode: 2026 GenAI Code Security Report: AI Is Writing More of Your Code but Security Hasn’t Caught Up (July 2026)
IOActive: The Security Gap in AI-Generated Code (April 2026)
Cloud Security Alliance: Vibe Coding Security Debt: AI-Generated Vulnerabilities at Scale (April 2026)
IT Brief UK: Stack Overflow survey finds developers wary of AI tools (October 2026)
Google Cloud / DORA: Announcing the 2025 DORA report: State of AI-assisted Software Development
No Jitter: Vendors ship thousands of features, users adopt dozens (July 2026)
Coro / CRN: Your Tool Stack Is Eating Your Margins (August 2026)
Guardian360: A view from the control room, event 3 November 2026