Quando si parla di intelligenza artificiale applicata al penetration testing, l’attenzione cade quasi sempre sullo strumento, ovvero quale modello usare, di quanto riduce i falsi positivi, quanto velocizza le scansioni. È una lettura legittima, ma parziale.

Infatti, il cambiamento più rilevante non riguarda il software che analizza le vulnerabilità, riguarda il professionista che lo guida.

In questa direzione, la proporzione tra tempo dedicato agli strumenti e tempo dedicato al ragionamento dovrebbe ribaltarsi con circa due terzi delle ore che dovrebbero essere dedicate ad attività che nessuna macchina può ancora svolgere da sola, come la modellazione delle minacce, l’analisi della logica di business o la lettura critica di un’architettura distribuita.

È in questa ricomposizione del lavoro, più che nella potenza dei nuovi strumenti, che si gioca la vera partita.

Dal saper eseguire al saper guidare

Per anni la competenza distintiva di un tester offensivo è stata l’abilità tecnica pura, quindi conoscere i comandi giusti, padroneggiare suite complesse, muoversi su ambienti con curve di apprendimento lunghe.

L’AI, usata come traduttore tra un’intenzione espressa in linguaggio naturale e un comando eseguibile, abbassa drasticamente questa barriera d’ingresso.

A conferma di questa profonda trasformazione, una recente proiezione di Gartner stima che, entro il 2028, l’adozione dell’Intelligenza Artificiale Generativa colmerà il divario di competenze tecniche, arrivando a eliminare la necessità di una formazione specializzata per il 50% delle posizioni entry-level in ambito cyber security.

Questo è un bene dal momento che uno specialista di simulazioni di attacchi cyber, i cosiddetti pen-tester, (soprattutto non esperto) può oggi descrivere l’architettura del sistema target, discutere con il modello i possibili vettori di attacco e ottenere rapidamente una roadmap di test che un tempo avrebbe richiesto mesi di esperienza sul campo.

Ma proprio perché l’esecuzione si democratizza, il valore si sposta su altri aspetti quali il prompting strutturato, la capacità di validazione indipendente, la comprensione architetturale profonda che diventano le competenze che fanno davvero la differenza.

Il pen-tester non è più focalizzato sulla velocità al terminale, ma sulla qualità delle domande che pone al sistema, umano o artificiale che sia e per la capacità di trasformare un’intuizionetecnica in un Proof of Concept solido, come un payload pensato per aggirare un WAF, cosa che nessun modello sa fare da solo senza una guida esperta.

Fidarsi, ma non troppo

C’è un secondo cambiamento, meno visibile ma altrettanto profondo, ed è di natura metodologica.

Interpellare un modello su un tema di sicurezza equivale, nella pratica, a confrontarsi con un professionista esperto, ma con una conoscenza del contesto limitata a ciò che gli è stato fornito in ingresso.

Se gli si chiede conferma di una vulnerabilità con sufficiente insistenza, un modello può confermarla anche quando non esiste, ed è qui che diventa centrale il consulto continuo perché è l’analista che deve verificarla, correggerla o respingerla.

Gestire questo bias della compiacenza è un compito operativo quotidiano, non un’eccezione e tocca anche la gestione delle informazioni scambiate con l’IA: prompt e risposte richiedono un’attenta costruzione, per non esporre dati sensibili, a partire da indirizzi IP e dettagli infrastrutturali.

Il dubbio e la verifica, più che l’entusiasmo senza filtri per l’AI, sono centrali per un utilizzo di queste tecnologie maturo ed efficace.

Calibrare l’entusiasmo soprattutto con gli agenti

Questo stesso principio diventa cruciale quando l’AI smette di rispondere e comincia ad agire e quindi entrano in gioco gli agenti AI.

Stiamo già sperimentando architetture multi-agente in cui si simulano contemporaneamente ruoli diversi, l’analista funzionale, il test automation engineer, l’esperto di sicurezza, per costruire strategie di test complete ancor prima che termini lo sviluppo.

Se il dubbio sistematico su una singola risposta testuale è già impegnativo da sostenere, mantenerlo su un agente che agisce in autonomia richiede un presidio diverso, con limiti operativi chiari, come:

• rate limiting;
• kill switch;
• e un essere umano che autorizzi le azioni più intrusive prima che vengano eseguite.

Senza questo perimetro, la piena autonomia decisionale in sicurezza può tradursi in scope creep o interruzioni di servizio accidentali. Lo stesso rischio della compiacenza visto prima, semplicemente amplificato dalla capacità di agire e non solo di suggerire.

Tutto questo spiega perché, paradossalmente, più l’AI entra nel flusso di lavoro dei penetration test, più serve rigore metodologico, non meno.

Un framework come ISTQB non rallenta l’adozione di questi strumenti, ma anzi la rende sostenibile, perché fornisce il criterio con cui stabilire cosa testare, in quale ordine, con quale perimetro e con quali priorità, un input che nessun modello può inventarsi da solo.

Senza queste cautele, la velocità acquisita rischia di diventare un problema in più anziché un vantaggio, perché un’automazione senza metodo produce risultati rapidi ma incoerenti, difficili da integrare in un ciclo di rilascio strutturato.

Penetration Test e AI: cosa serve

La vera sfida non risiede nella ricerca di un’Intelligenza Artificiale più potente (che ha già raggiunto livelli di maturità eccellenti), bensì nello sviluppo di un approccio critico e metodologico che evolva di pari passo con la tecnologia.

Il fattore discriminante rimane l’expertise umana, è il giudizio dello specialista, saldo al centro del processo, a determinare se l’automazione dei penetration test generi una sicurezza aziendale concreta o soltanto la pericolosa illusione di essere protetti.