Come ridurre i costi dell’IA nella sicurezza senza sacrificare l’efficacia

Il contesto francese: sicurezza, IA e pressione sui budget

Le aziende francesi stanno vivendo una crescente pressione sui team di sicurezza, già sovraccarichi, a causa dell’aumento delle minacce informatiche. Il barometro 2026 del CESIN indica che il 40 % delle imprese intervistate ha subito almeno una cyber‑attacco significativo nel 2025, e l’81 % di esse ha registrato un impatto operativo. In questo scenario, l’adozione di soluzioni basate sull’intelligenza artificiale è vista come indispensabile, ma comporta anche la necessità di gestire attentamente i costi.

Matt Coons, Senior Manager of Security Operations presso GitLab, ha dimostrato che è possibile contenere le spese legate alle detections alimentate dall’IA a circa un dollaro al giorno. Questo risultato, apparentemente sorprendente, è frutto di una progettazione accurata dei workflow e di una gestione oculata dei casi d’uso da sottoporre ai modelli di intelligenza artificiale.

Il filtraggio a più livelli: la chiave per ridurre i costi

Il concetto di filtraggio a imbuto non è nuovo. Prima dell’avvento dei grandi modelli di linguaggio (LLM), i team di sicurezza già implementavano filtri per gestire grandi volumi di eventi, selezionando solo quelli che richiedevano l’intervento di un analista. Lo stesso principio si applica ora alle spese di IA: più è fine e preciso il filtraggio che alimenta i modelli, più diminuisce il costo per risultato affidabile.

Molti abusi sono identificabili prima ancora di eseguire un modello. Una rilevazione deterministica, basata su regole, consente di trattare in anticipo una parte significativa del volume. Fattori come l’antichità dell’account, il provider di posta elettronica e i segnali comportamentali alimentano filtri automatizzati capaci di risolvere i casi evidenti, riducendo il carico residuo che arriva al LLM. Solo il sotto‑insieme filtrato supera questa soglia, generando il costo di un dollaro al giorno.

Componenti del filtraggio deterministico

• Verifica dell’età dell’account
• Controllo del provider di posta elettronica
• Analisi dei segnali comportamentali (es. pattern di login, velocità di invio messaggi)
• Applicazione di regole statiche per scenari noti

Modelli a più livelli: bilanciare precisione e spesa

Per gli eventi che superano il filtraggio iniziale, GitLab utilizza un modello leggero per una prima analisi. Questo modello restituisce risultati strutturati, classificati come “malizioso” o “innocuo”, con un indicatore di livello di fiducia (alto o basso). I risultati con fiducia alta vengono risolti automaticamente, mentre quelli con fiducia bassa vengono inviati a un modello più avanzato, dotato di un contesto più ampio e migliori capacità di ragionamento.

Solo una frazione degli eventi raggiunge questo secondo livello. Nei test di efficacia, la differenza di precisione tra i modelli leggeri e quelli di punta è stata di appena 1‑2 %, ma i modelli di punta costano circa cinque volte di più per token. Pertanto, la loro attivazione è giustificata solo per i casi che realmente richiedono tale livello di performance.

Strategie di prompt engineering

L’ingegneria dei prompt è altrettanto cruciale quanto la scelta del modello. Un prompt per le detections agentiche può superare i 1 900 parole, coprendo tutti gli scenari possibili, inclusi quelli in cui l’agente deve segnalare un caso o agire autonomamente. Tuttavia, non tutti i casi richiedono tale dettaglio: alcuni prompt si riducono a due o tre frasi. Il livello di dettaglio richiesto dipende dal perimetro di responsabilità affidato all’agente.

Il contesto è fondamentale per evitare “allucinazioni” dell’IA. Se a un modello viene chiesto se un utente è colpevole senza fornire il contenuto segnalato, l’IA potrebbe accettare la premessa senza verifica. Invece, fornendo l’elemento concreto del segnalamento, il modello può valutare autonomamente la fondatezza dell’accusa.

L’intervento umano: dove l’automazione non basta

L’automazione gestisce i casi ovvi; i casi ambigui richiedono ancora il giudizio umano. Distinguere un ricercatore di sicurezza legittimo, che ospita malware per analisi, da un attore maligno che lo usa per attacchi, richiede un discernimento ancora fuori dalla portata dell’IA. Analogamente, le dispute nei thread di discussione, dove le policy di utilizzo possono essere interpretate in modi diversi, devono essere valutate da un operatore umano.

L’obiettivo è liberare tempo per gli analisti umani, consentendo loro di concentrarsi sui casi che realmente necessitano della loro expertise. Invece di esaminare ogni evento, gli ingegneri di GitLab si occupano di sviluppare i sistemi, redigere i prompt e definire gli schemi che orchestrano la rilevazione su larga scala.

Flusso di lavoro tipico

• Filtraggio deterministico: elimina il 70‑80 % dei segnali
• Modello leggero: analizza il 15‑20 % restante, assegna livello di fiducia
• Modello avanzato: elabora il 1‑5 % dei casi più complessi
• Revisione umana: gestisce gli eventi con fiducia bassa o ambigui

Implicazioni pratiche per le aziende francesi

Gli attacchi evolvono con nuove tecniche di offuscamento, costringendo le squadre a aggiornare costantemente prompt e modelli. Questo processo iterativo è più simile a l’ingegneria di rilevazione che a un semplice deployment. L’ingegneria del prompt segue lo stesso ciclo: scrivere la regola, testare il risultato, aggiustare quando la precisione diminuisce.

Nel barometro CESIN, intervistati 397 direttori di sicurezza e responsabili dei sistemi informativi hanno evidenziato che l’uso di servizi di IA non approvati (Shadow AI) è percepito come il comportamento digitale più rischioso, con il 66 % delle organizzazioni che lo classifica come ad alto o molto alto rischio. Quando i leader non integrano l’IA in modo deliberato nei loro processi, subiscono perdite finanziarie e aumentano i rischi di sicurezza.

Rischi di una gestione non strutturata

• Spese incontrollate dovute a volumi di dati non filtrati
• Rischio di “hallucination” dell’IA senza contesto adeguato
• Problemi di conformità legati all’uso di soluzioni non approvate
• Incremento del rischio di attacchi dovuto a configurazioni errate

Conclusioni: progettare l’IA fin dall’inizio

Per evitare sia i costi eccessivi sia i nuovi vettori di rischio, le organizzazioni devono trattare l’integrazione dell’IA come un problema di progettazione sin dal principio. Il volume di dati inviato al modello, la forma in cui questi dati vengono presentati e il contesto allegato determinano direttamente le spese.

Senza una governance chiara, l’IA genera un rischio finanziario che si somma a quello di sicurezza. La risposta è un approccio consapevole: definire con precisione dove l’IA interviene, perché lo fa e quali controlli umani rimangono necessari. Solo così è possibile mantenere la sicurezza efficace, contenere i costi e sfruttare al meglio le potenzialità dell’intelligenza artificiale.