Intervista ad Alessandro Maggio (CyberKord): l’AI che risolve da sola i problemi di IT e sicurezza

Con questa intervista inauguro su IntelligenzaArtificiale.net un nuovo format: le interviste. Gli ospiti sono imprenditori, sviluppatori e ricercatori, che stanno costruendo progetti con l’AI. Come si evince dal titolo dell’articolo, il primo ospite è Alessandro Maggio, co-fondatore e CEO di CyberKord, che ringrazio per la disponibilità e per la rapidità con cui ha risposto.

CyberKord è una startup milanese che Alessandro ha fondato nel 2026 insieme a Dragos Tanasa e Cosimo Michelagnoli. A pochi mesi dalla fondazione ha chiuso un round pre-seed da 2,7 milioni di euro guidato da 360 Capital, con la partecipazione di Plus Partners, Addendum Capital e Vento. CyberKord lavora nell’automazione dell’IT e della cybersecurity, con la sua piattaforma di intelligenza artificiale che parte da un alert, un ticket o un messaggio su strumenti come Teams o Slack e individua la causa del problema, simula la correzione su un gemello digitale dell’infrastruttura e infine la applica. Le aziende che scelgono di utilizzare CyberKord decidono quanta autonomia concedere al sistema, e ogni azione viene registrata e può essere verificata.

Ho chiesto un’intervista ad Alessandro perché il suo è un caso concreto di AI agentica applicata a un problema molto sentito: il tempo che passa tra il momento in cui un sistema segnala un rischio e quello in cui qualcuno interviene.

Le risposte che seguono sono sempre pubblicate così come sono state scritte. Buona lettura.

CyberKord è una società neonata ma che ha già chiuso un pre-seed da 2,7 milioni di euro. Cosa cambia concretamente quando hai degli investitori alle spalle dopo pochi mesi di vita?

Cambiano soprattutto tre cose.

La prima è il ritmo. Siamo nati a febbraio e con questo capitale possiamo assumere le persone giuste adesso, non tra un anno: il piano di assunzioni su profili tecnici e commerciali è la prima voce di spesa.

La seconda è la responsabilità. Non rischiamo più solo il nostro tempo, ma il capitale di chi ha scelto di fidarsi di un team giovane. Questo alza l’asticella su ogni decisione, anche le più piccole.

La terza è l’accesso. Un lead come 360 Capital, insieme a Plus Partners, Addendum Capital e Vento, ci apre le porte di grandi aziende europee con cui avviare i primi progetti pilota, nel manifatturiero, nel tech, nell’healthcare e nelle telecomunicazioni.

Quello che non cambia è il problema da risolvere. Il round non è un traguardo: è il carburante per dimostrare, dentro infrastrutture reali, che quello che diciamo funziona.

Sul vostro sito scrivete che il rischio vive “tra l’alert e l’azione”. Cosa succede oggi, in concreto, in quello spazio dentro un’azienda? Cosa avete notato? Cosa avete mappato?

Oggi rilevare è in gran parte automatizzato: EDR, XDR, SIEM e scanner sollevano l’alert in pochi minuti. Quello che succede dopo è ancora quasi tutto manuale. Un analista fa triage, ricostruisce cosa è coinvolto, valuta l’impatto, concorda la modifica con chi gestisce i sistemi, e solo alla fine qualcuno applica il blocco o la patch. Ogni passaggio è una persona, spesso un ticket, a volte una riunione. Nel frattempo l’attaccante si muove.

Parlando con team IT e security abbiamo trovato sempre gli stessi quattro colli di bottiglia:

• Identità compromessa. L’EDR segnala un dipendente compromesso, ma nessuno sa elencare tutto ciò a cui quella persona può accedere. Il blocco richiede ore, un sistema alla volta.
• Configurazioni di rete. Il traffico cala e la causa è una regola, un limite, una voce mancante. Trovarla richiede giorni di tentativi.
• Vulnerabilità. Lo scanner restituisce centinaia di risultati con lo stesso punteggio. Le due che possono fare davvero male sembrano uguali a tutte le altre.
• Impatto delle modifiche. “Cosa si rompe se tocco questo?” Spesso la risposta arriva dopo, sotto forma di disservizio.

Il punto in comune è che manca una mappa viva di come sistemi, identità e agenti AI sono collegati tra loro. È quello che abbiamo costruito: un gemello digitale a grafo dell’infrastruttura, dove ogni nodo è un’entità (una persona, una macchina, un servizio, un agente AI) e ogni collegamento è una relazione di accesso o di comunicazione. Senza quella mappa, ogni decisione tra l’alert e l’azione resta una stima.

Mi collego alla domanda precedente: immagino che il tempo tra la prima violazione e il primo alert sia fondamentale. Mi pare di capire che gli alert vi arrivino da sistemi esterni. State lavorando anche su questo fronte o intendete restare a valle dell’alert?

Al momento abbiamo scelto di partire da quello che il SOC già produce: un alert, un ticket, un messaggio su Teams o Slack. Vogliamo valorizzare gli strumenti che le aziende hanno già acquistato, e non avrebbe senso chiedere di sostituirli. Il collo di bottiglia oggi non è sapere che qualcosa non va, è agire in tempo.

Detto questo, non stiamo solo a valle. Il gemello digitale lavora anche prima che esista un alert. Quando esce una nuova vulnerabilità o arriva una scansione, verifichiamo subito quali asset sono davvero esposti e raggiungibili, così le porte si chiudono prima che qualcuno le usi. E già la sola mappatura fa emergere asset e accessi di cui nessuno conosceva l’esistenza.

Il nostro mestiere è eliminare la latenza tra il segnale e la risoluzione.

Ogni correzione viene provata prima su una copia dell’ambiente. Io quando realizzo siti web ho sempre una copia di staging, ma immagino che in questo caso la cosa sia più complessa. Come si costruisce un gemello digitale abbastanza fedele da potersi fidare del risultato finale?

Lo staging è un ottimo punto di partenza per capire la differenza. Una copia di staging di un’intera infrastruttura enterprise, con migliaia di macchine, identità, regole firewall e servizi cloud, di fatto non esiste: costerebbe quanto l’originale e sarebbe vecchia il giorno dopo. Il nostro gemello digitale non è una copia byte per byte, è un modello. Rappresenta le entità e le relazioni che contano per decidere un intervento: chi può raggiungere cosa, chi dipende da chi, quali accessi ha ogni identità.

La fedeltà si costruisce in tre modi.

• Dati vivi, non dichiarati. Un agente installato nella rete del cliente legge in sola lettura dai sistemi che esistono già (virtualizzazione, bilanciatori di carico, flussi di rete, log ed eventi di sistema) e aggiorna il grafo di continuo. Non ci fidiamo della documentazione, ci fidiamo di quello che la rete fa davvero.
• Simulazione prima dell’azione. Prima di toccare qualcosa, applichiamo la modifica al gemello e guardiamo cosa cambia e cosa si rompe: quali percorsi si chiudono, quali servizi perdono un collegamento.
• Verifica dopo l’azione. Ogni intervento viene controllato sull’ambiente reale e il risultato viene confrontato con quello previsto. Ogni scarto rende il modello più preciso.

E quando il modello non è abbastanza sicuro, per esempio perché manca una fonte dati su una parte dell’infrastruttura, il sistema non agisce: lo dice e passa la decisione a una persona. Il gemello non deve essere perfetto, deve sapere quando non è abbastanza preciso.

Dite di tenere solo le vulnerabilità sfruttabili nell’ambiente del cliente, non tutte quelle segnalate. Come fa il sistema a distinguerle?

Un punteggio come il CVSS descrive quanto è grave una vulnerabilità in astratto, non quanto è pericolosa in casa tua. La stessa CVE con punteggio altissimo può essere quasi irrilevante su un servizio interno, non esposto e senza accesso a nulla di importante. E può diventare urgentissima su una macchina raggiungibile dall’esterno con un percorso verso i dati critici.

Il sistema incrocia i risultati degli scanner con il gemello digitale e, per ogni vulnerabilità, si pone domande concrete:

• L’asset vulnerabile è raggiungibile? Da dove?
• È esposto verso l’esterno o confinato in un segmento interno?
• Esiste un percorso che porta da lì ai sistemi più critici, quelli che chiamiamo crown jewels?
• Se venisse compromesso, quanti altri sistemi sarebbero coinvolti (il cosiddetto blast radius)?

Il risultato è che migliaia di segnalazioni diventano le poche davvero sfruttabili in quel preciso ambiente, ordinate per percorso di attacco reale. È una delle capacità già disponibili oggi.

Prevedete tre livelli: solo simulazione, azione con approvazione, azione autonoma. Come si arriva all’ultimo livello? Cosa deve dimostrare il sistema?

L’autonomia non si chiede, si guadagna. E si guadagna attività per attività, non tutta insieme.

• Simula e riporta. Nessun permesso di scrittura. Il sistema lavora sugli alert reali del cliente e mostra cosa avrebbe fatto, così il team può confrontarlo con quello che ha fatto davvero. Ogni nuovo cliente parte da qui.
• Agisce con approvazione. Il sistema dimostra la modifica in simulazione, una persona la approva, lui la applica e la verifica.
• Agisce in autonomia. Dopo abbastanza esiti sicuri documentati su quella specifica attività, agisce da solo, senza aspettare nessuno.

Per salire di livello il sistema deve dimostrare tre cose, tutte misurabili. Che le sue previsioni corrispondono alla realtà: quello che la simulazione diceva sarebbe successo è successo, senza effetti collaterali. Che sa riconoscere i propri limiti: quando i dati sono incompleti o l’intervento è troppo ampio, si ferma e chiede. Che ogni passaggio è registrato e leggibile da una persona, così chi approva sa sempre perché è stata presa una decisione.

Il passaggio lo decide il cliente, non noi. Alcune attività arriveranno presto al terzo livello, per esempio rimuovere gli accessi di chi lascia l’azienda o bloccare un’identità compromessa. Altri interventi ad ampio impatto probabilmente resteranno sempre al secondo. Va bene così.

In media un attaccante impiega 29 minuti per muoversi dal primo punto di accesso verso altri sistemi interni. Con questi tempi, come cambia il lavoro di chi difende un’azienda?

Quel dato viene dal Global Threat Report 2026 di CrowdStrike, ed è una media: nel 2024 erano 48 minuti e il caso più rapido osservato è stato di 27 secondi. Lo stesso report dice che la grande maggioranza degli attacchi non usa malware, ma credenziali valide e accessi legittimi.

Questo cambia il lavoro di chi difende in un modo semplice da dire: un processo che si misura in ore non può fermare un attacco che si misura in minuti. Se per bloccare un’identità compromessa servono un reperibile, un ticket e tre sistemi da aggiornare a mano, l’attaccante è già altrove.

La risposta però non è chiedere alle persone di correre più veloce, è spostare il loro lavoro. Il difensore smette di essere chi esegue ogni singola azione e diventa chi decide le regole: cosa si può fare in automatico, entro quali limiti, con quale livello di prova. L’esecuzione, di notte, nel weekend, alle due del mattino senza nessuno di turno, la fa la macchina. Le persone tornano ad architettura, progetti e alle decisioni che richiedono davvero competenza umana.

Gli attacchi gravi crescono di anno in anno, cosa sta frenando di più le aziende italiane dall’affidare parte della difesa ad un’AI? Manca forse la consapevolezza? O bisogna prima “bruciarsi”? Un po’ come chi mette l’antifurto solo dopo che i ladri sono entrati in casa?

Non credo sia mancanza di consapevolezza. Il Rapporto Clusit 2026 conta 507 attacchi gravi in Italia nel 2025, il 42% in più dell’anno precedente, e i responsabili IT e security che incontro lo sanno benissimo.

Il freno principale è un altro: la paura che il rimedio faccia più danni del problema. Chi gestisce un’infrastruttura ha visto almeno una volta una modifica fatta in buona fede mandare giù la produzione. Affidare quella modifica a un’AI di cui non si capisce il ragionamento è, comprensibilmente, un no.

Poi ci sono fattori molto concreti: infrastrutture stratificate in decenni, con sistemi datati accanto al cloud; team piccoli e sotto organico; la domanda su chi risponde se qualcosa va storto; e il tema di dove finiscono i dati sulla propria infrastruttura.

Sull’antifurto: sì, spesso si interviene dopo il primo incidente. Ma la risposta non è spaventare le aziende, è rendere la fiducia verificabile. Per questo partiamo in sola lettura, mostriamo cosa avremmo fatto sugli alert reali e lasciamo al cliente la scelta di quanta autonomia concedere. La fiducia si costruisce con i risultati, non con le promesse.

A un’azienda italiana che vuole iniziare ad automatizzare la propria sicurezza, qual è il primo passo che consiglieresti?

Sapere cosa si ha. Sembra banale, ma la maggior parte delle aziende non ha una fotografia aggiornata di asset, identità e collegamenti tra sistemi. E non si può automatizzare ciò che non si conosce.

Poi scegliere un solo processo: piccolo, ripetitivo, misurabile e facile da annullare. Due buoni candidati sono la gestione degli accessi quando una persona entra o lascia l’azienda e la prioritizzazione delle vulnerabilità. Misurare quanto tempo richiede oggi.

Infine partire in osservazione: lasciare che il sistema proponga senza agire, confrontare le sue proposte con quello che fa il team e concedere autonomia un passo alla volta. Il primo obiettivo non è automatizzare tutto, è ottenere la prima risposta che arriva in minuti invece che in giorni.

Un’intervista ha i suoi limiti e non si può esplorare tutto. C’è qualcosa che ti sta a cuore e che non ti ho chiesto? Come direbbe Marzullo: fatti una domanda e datti una risposta.

Cosa succede quando le aziende iniziano a riempirsi di agenti AI?

Succede che ogni agente diventa una nuova identità, con accessi, permessi e credenziali, esattamente come un dipendente. Ma senza un responsabile, senza una data di uscita e spesso senza che nessuno sappia quali sistemi può toccare. E le aziende ne aggiungono ogni settimana.

Si parla molto di come usare l’AI per difendersi. Si parla molto meno di come difendersi dall’AI che abbiamo già messo dentro casa. Per noi persone, macchine e agenti AI sono la stessa cosa: nodi del grafo, con relazioni da conoscere e da governare.

Credo che la gestione delle identità non umane sarà uno dei temi centrali dei prossimi anni. Conviene pensarci adesso, prima che diventi il prossimo vettore d’attacco.

Chi ti piacerebbe leggere tra i prossimi intervistati di questa rubrica? Un nome.

Un C-level di Bynario.

Le idee da portarsi a casa

Personalmente da questa prima intervista mi porto a casa un’idea che vale ben oltre CyberKord: in sicurezza il vero collo di bottiglia non è più accorgersi che qualcosa non va, ma agire in tempo, e per farlo serve prima di tutto una mappa aggiornata di sistemi, identità e agenti. L’autonomia dell’AI, poi, va guadagnata un’attività alla volta, partendo dall’osservazione.

Il tema delle identità non umane, indicato da Maggio come uno dei più importanti dei prossimi anni, è già sul tavolo anche dei grandi player: ne ho parlato raccontando IBM Agent Identity e il kill switch di CrowdStrike per gli agenti AI. Sul fronte dei rischi dell’autonomia, trovi un altro spunto nell’articolo su Apple e gli agenti che agiscono oltre i permessi.

La rubrica di interviste di IntelligenzaArtificiale.net continua e nella prossima intervista darò la parola a un altro protagonista dell’AI italiana ed europea. Se non vuoi perderti le prossime uscite, torna a trovarci, iscriviti alla newsletter o seguici sui nostri canali social.

Newsletter gratuita · ogni venerdì

Tutta l'AI della settimana, in 5 minuti, nella tua email

• Le guide e le notizie della settimana, divise per rubrica
• Solo ciò che conta, verificato e spiegato in italiano
• Niente spam, ti cancelli con un clic

La tua email Iscriviti gratis

Ho letto l'informativa privacy e voglio ricevere la newsletter.

Preferisci i social? Seguici:

Seguici su Facebook X LinkedIn