Chi si occupa di cybersecurity conosce bene lo squilibrio che caratterizza ogni test: chi attacca ha tempo praticamente illimitato, un'automazione sempre più spinta e gli basta trovare una sola falla per avere successo. Chi difende deve coprire un perimetro sempre più esteso con budget e tempo limitati, senza poter lasciare nulla scoperto. È un'asimmetria strutturale, ed è il motivo per cui i test di sicurezza finiscono per diventare il collo di bottiglia nelle fasi di rilascio del software.

Per anni la risposta è stata aumentare l'automazione, più scanner, più scansioni, più velocità. Tuttavia, quella che potremmo definire la sola forza bruta, non risolve il problema di fondo. Gli strumenti DAST generano una mole di alert tale da produrre l'effetto opposto a quello desiderato, ovvero non più sicurezza, ma stanchezza da alert, dal momento che i team passano più tempo a fare triage dei falsi positivi che a validare vulnerabilità reali. Inoltre il rischio concreto è che le sessioni di scansione massiva diano una falsa sensazione di controllo, mascherando ciò che davvero conta sotto un cumulo di dati non contestualizzati.

Partecipa agli ItalianSecurityAwards 2026 ed esprimi il tuo voto premiando le soluzioni di cybersecurity che reputi più innovative

Il vero collo di bottiglia, quindi, non è la potenza di calcolo, ma la capacità umana di leggere, interpretare e validare ciò che le macchine producono. Ed è qui che l'intelligenza artificiale fa la differenza: non come sostituto dell'analista, ma come filtro che lo libera per concentrarsi su ciò che conta. A conferma di questo trend, recenti stime di Gartner prevedono che entro il 2027 l'adozione dell'Intelligenza Artificiale Generativa permetterà di ridurre i tassi di falsi positivi nei test di sicurezza applicativa (AST) del 30%, restituendo efficienza ai team operativi e abbattendo lo spreco di risorse.

Un copilota, non un bottone magico

È importante essere chiari su un punto: l'IA non è uno strumento che monitora sistemi in autonomia premendo un tasto. Chi la usa facendo affidamento totale sui suoi output si espone al rischio concreto di allucinazioni e falsi riscontri. Il modello che funziona, nella pratica quotidiana di un team di offensive security, è quello del consulto continuo: si descrive l'architettura del sistema target, si discute con l'IA dei possibili vettori di attacco, si ottiene una roadmap di test, e poi è l'analista a verificare, correggere o validare ciò che viene proposto. In altre parole, il ciclo si chiude sempre con un giudizio umano.

Questo approccio ha già cambiato alcune fasi operative in modo tangibile. Le suite offensive standard hanno interfacce poco intuitive e curve di apprendimento lunghe; tradurre un'intenzione in linguaggio naturale in un comando da terminale abbassa questa barriera, rendendo operativi i tester più giovani più rapidamente. Allo stesso modo, l'analisi semantica dell'AI sull'output grezzo degli scanner, incrociata con log e status HTTP, permette una scrematura dei falsi positivi che libera tempo per la validazione manuale.

C'è poi un terzo ambito, quello del Proof of Concept: la differenza tra una vulnerabilità teorica e una minaccia reale sta proprio nella capacità di dimostrarla. Usare le capacità generative dell'AI per costruire exploit su misura, ad esempio per il bypass di un WAF, accelera questa fase, così come la generazione di reportistica e di remediation guidata aiuta a tradurre appunti tecnici in documentazione realmente utile per gli sviluppatori.

La competenza umana non è un'opzione

Tutto questo non significa abbassare la guardia. Anzi, più l'AI entra nel flusso di lavoro, più serve una supervisione costante. Un'AI interpellata su un test di sicurezza si comporta come un tester esperto ma con conoscenza limitata del contesto specifico, ed è anche facile da convincere: senza controllo critico, il rischio è farsi confermare vulnerabilità che non esistono. A questo si aggiunge la gestione delle informazioni: prompt e risposte vanno contestualizzati con attenzione per evitare di esporre dati sensibili, a partire dagli indirizzi IP.

Lo stesso principio vale, amplificato, per l'agentic AI: agenti capaci non solo di generare risposte ma di eseguire azioni sul sistema, adattandosi in tempo reale come un attaccante reale, che raramente segue una sequenza prevedibile. Dare piena autonomia a un agente in un contesto di sicurezza può portare a scope creep o interruzioni di servizio accidentali. Servono quindi limiti operativi chiari, come rate limiting e kill switch, e un presidio umano che autorizzi le azioni più intrusive prima che vengano eseguite: l'automazione deve sempre restare dentro un perimetro di responsabilità umana esplicita.

Cosa cambia per i pe-tester

Se cambia il modo di fare un penetration test, cambia anche il profilo di chi lo fa, e il cambiamento è più profondo di quanto sembri. La transizione riguarda quante ore si passano davanti a un terminale rispetto a quante se ne dedicano a ragionare su un'architettura, ma soprattutto la natura stessa del contributo professionale. I pe-tester, gli esperti che lanciano un attacco simulato per individuare le vulnerabilità, devono integrare un livello di astrazione diverso: capire come funziona un modello per saperlo guidare, conoscerne i limiti per non affidarsi ciecamente ai suoi output, e saper costruire prompt che contestualizzino adeguatamente il problema da risolvere.

In termini pratici, le ore dedicate a scansioni manuali, parsing di output e reportistica di base si riducono sensibilmente, si stima a circa un terzo del tempo complessivo, per concentrarsi su attività che richiedono valutazione, non solo tecnica: modellazione avanzata delle minacce, analisi della logica di business, comprensione delle architetture distribuite, valutazione del rischio reale rispetto a quello rilevato.

In altre parole il focus si allontana dalla bug detection in senso stretto per avvicinarsi alla prevenzione sistemica, non perdendo profondità tecnica, ma ricollocandola.

Tutto questo, però, ha senso solo se sorretto da una cornice metodologica solida. Introdurre l'AI in un flusso di penetration test senza un framework di riferimento non accelera il lavoro, anzi lo destabilizza, perché la velocità acquisita non produce valore se non c'è un metodo che definisca cosa testare, in quale ordine, con quali priorità e in quale perimetro. Standard consolidati come quelli ISTQB diventano quindi ancora più rilevanti, perché forniscono all'AI l'input metodologico necessario per produrre output coerenti e verificabili.

La questione, dunque, non è più se l’AIcambierà il penetration testing, la transizione è già in atto. La vera sfida è governarla con la lucidità necessaria per non confondere la velocità di esecuzione con la reale efficacia. Usare l'AI come scorciatoia per aggirare la complessità dei sistemi espone a un rischio paradossale, dal momento che creare un’automazione cieca, capace solo di mascherare le stesse vulnerabilità che è chiamata a scoprire.