L'architettura Dual-AI: Perché i modelli generali sono strumenti ma l'autonomia del SOC è infrastruttura

La velocità dell'adozione dell'IA nella cybersecurity ha creato un divario strategico significativo tra chi vede l'IA come un chatbot e chi la vede come un'architettura. In precedenza, i leader della sicurezza valutavano i Large Language Models (LLM) in base alla loro capacità di rispondere a domande o scrivere script. Ora, la realtà operativa è che le piattaforme IA generaliste come Claude e Cursor sono distinte dall'infrastruttura specializzata necessaria per gestire un Security Operations Center (SOC) ad alto volume.

I team di sicurezza affrontano un ambiente di minacce in cui gli aggressori utilizzano l'IA per automatizzare le fasi di ricognizione ed exploit della kill chain. Il modello di minaccia tradizionale, che si affida alla velocità umana per intercettare attacchi a velocità di macchina, è fondamentalmente superato. Per affrontare questo problema, le organizzazioni devono andare oltre l'integrazione di base degli assistenti IA e stabilire un'architettura di intelligence a livelli che separi il triage autonomo ad alto volume dalla cognizione umana ad alto valore.

La separazione tra cognizione e volume

Le moderne operazioni di sicurezza funzionano su tre livelli distinti. Al livello base, gli strumenti di sicurezza esistenti come EDR, SIEM e le piattaforme di identità cloud generano telemetria grezza e avvisi. Questo livello è la fonte primaria di dati, ma manca della capacità di ragionamento per distinguere tra un attacco complesso e uno script amministrativo configurato in modo errato.

Al centro si trova il livello SOC IA autonomo. Non si tratta di un'interfaccia chatbot. È un sistema di agenti che indaga continuamente su ogni avviso, correla le prove tra strumenti disgiunti e applica il contesto organizzativo per determinare il rischio. Questo livello riduce il rumore risolvendo gli avvisi benigni senza l'intervento umano.

Al vertice si trova il livello cognitivo, dove operano piattaforme come Claude, Codex e Cursor. Questo è lo spazio interattivo in cui gli analisti senior e i risponditori agli incidenti collaborano con i modelli di frontiera per risolvere problemi specializzati. L'uso di questi modelli al livello superiore è efficace perché sono progettati per il ragionamento, non per l'ingestione ripetitiva di migliaia di flussi di telemetria. Ogni livello ha un compito specifico e confondere il livello cognitivo con quello autonomo porta all'inefficienza operativa.

La tokenomics del ragionamento di sicurezza

L'architettura è spesso un sottoprodotto dell'economia. Ogni interazione con un modello linguistico di grandi dimensioni comporta un costo, tipicamente misurato in token. Una singola indagine di sicurezza non è un semplice prompt testuale. Richiede l'ingestione di telemetria degli endpoint, alberi dei processi, log di autenticazione e feed di threat intelligence. Questo contesto può consumare rapidamente migliaia di token per incidente.

In precedenza, le organizzazioni presumevano che una singola licenza IA potesse risolvere ogni esigenza investigativa. Ora, i calcoli rivelano che l'uso di un LLM generalista per indagare su ogni avviso informativo è un'impossibilità finanziaria. Se un SOC riceve 5.000 avvisi al giorno e invia ognuno di essi a un modello di frontiera per un'analisi forense completa, i costi annuali delle API supereranno il budget dell'intero dipartimento di sicurezza.

Le piattaforme SOC IA autonome risolvono questo problema utilizzando il contesto memorizzato nella cache e il ragionamento selettivo. Non trattano ogni avviso come una nuova conversazione con un modello costoso. Invece, utilizzano workflow deterministici per la raccolta routinaria di dati e coinvolgono gli LLM solo quando è richiesto uno specifico compito di ragionamento. Questo approccio architettonico rende possibile indagare sul 100% degli avvisi mantenendo i costi prevedibili. Usare Claude per indagare su ogni log benigno è come usare un laser chirurgico per abbattere una foresta; lo strumento è preciso, ma l'applicazione è un errore architettonico.

La gravità dei dati e il punto di attrito dell'MDR

Molte aziende si affidano a fornitori di Managed Detection and Response (MDR) per gestire il monitoraggio della sicurezza. Ciò crea un'asimmetria nell'accesso ai dati. Il fornitore MDR in genere possiede il workflow investigativo e la telemetria arricchita. Il cliente vede solo l'incidente finale scalato, il che limita l'efficacia delle piattaforme IA interne.

Se un analista cerca di usare Claude per indagare su un avviso, spesso manca dei dati grezzi necessari per fornire al modello un contesto sufficiente. L'LLM non può ragionare su dati che non può vedere. Ecco perché un livello SOC IA autonomo locale sta diventando una componente critica dello stack aziendale. Si affianca agli strumenti di sicurezza, cattura la cronologia delle indagini e costruisce una base di conoscenza locale.

Questa architettura consente all'organizzazione di conservare la conoscenza istituzionale invece di lasciarla all'interno di un portale MDR di terze parti. Garantisce che quando un analista senior utilizza uno strumento come Claude, le prove necessarie siano già strutturate e pronte per l'analisi. Il livello autonomo funge da ponte tra i log grezzi e sparsi e il lavoro cognitivo di alto livello.

Il rischio nascosto degli avvisi informativi

La maggior parte dei SOC ignora gli avvisi a bassa gravità perché manca della capacità umana per esaminarli. Questa prioritizzazione è una necessità in un modello incentrato sull'uomo, ma è anche una vulnerabilità sistemica. L'analisi di 25 milioni di avvisi nel 2025 ha indicato che circa l'1% degli incidenti di sicurezza confermati è iniziato come log a bassa gravità o informativo.

Gli aggressori utilizzano spesso tecniche furtive di movimento laterale che non attivano allarmi ad alta gravità. Un singolo accesso fallito o un comando PowerShell sospetto ma non dannoso sono facili da trascurare. Un SOC IA autonomo cambia le carte in tavola fornendo la capacità di indagare su tutto. Poiché la macchina non si stanca e il costo per indagine è ridotto al minimo attraverso un'architettura specializzata, la "gravità" di un avviso non dettano più se riceve attenzione. Ogni avviso viene indagato e solo le minacce reali raggiungono il livello cognitivo umano.

Dove i modelli di frontiera offrono il ROI più elevato

Quando il livello autonomo gestisce il triage ripetitivo, le piattaforme IA come Claude diventano significativamente più potenti. Gli analisti non le usano più per la raccolta di dati di base. Invece, si concentrano su un lavoro strategico ad alto impatto.

Per chiarezza, il livello cognitivo è utilizzato al meglio per:

• Sviluppare e testare nuove logiche di rilevamento basate sulla threat intelligence emergente.
• Condurre analisi forensi approfondite su incidenti complessi e multi-fase.
• Riassumere le indagini tecniche per la leadership esecutiva e gli organismi di regolamentazione.
• Cercare minacce generando query complesse su più data lake.
• Tradurre regole di rilevamento legacy in linguaggi di query moderni come Sigma o KQL.

In questo modello, l'umano e l'LLM lavorano insieme sui problemi che richiedono sfumature e giudizio. Il sistema autonomo garantisce che il loro tempo non venga mai sprecato nel 99% degli avvisi che sono benigni.

Piano d'azione: Costruire un'architettura IA a livelli

Per passare dalla "FOMO da IA" a una difesa resiliente, i CISO dovrebbero seguire questa tabella di marcia di 6-12 mesi per ristrutturare le loro operazioni di sicurezza.

1. Audit della pipeline di telemetria (Mese 1-2): Mappare tutte le fonti di dati e identificare dove è archiviata la telemetria. Determinare se il fornitore MDR consente l'accesso API in tempo reale ai log grezzi e agli artefatti investigativi.
2. Suddividere la spesa IA (Mese 3-4): Separare il budget per gli strumenti cognitivi (Claude, Cursor) dal budget per l'infrastruttura autonoma. Non cercare di forzare un unico strumento a svolgere entrambi i compiti.
3. Implementare un livello di triage autonomo (Mese 5-8): Distribuire un sistema in grado di automatizzare il processo di raccolta forense. Concentrarsi prima sulla riduzione del tempo di triage per gli avvisi a bassa gravità per dimostrare il concetto.
4. Codificare il contesto organizzativo (Mese 9-10): Costruire un repository di documentazione interna, mappe di rete e file di policy che il sistema autonomo possa utilizzare per distinguere tra attività amministrativa autorizzata e comportamento dell'aggressore.
5. Perfezionare il workflow dell'analista (Mese 11-12): Spostare gli analisti di Livello 1 e Livello 2 verso l'ingegneria del rilevamento e la caccia alle minacce (threat hunting). Utilizzare piattaforme IA cognitive per supportare questa transizione automatizzando la scrittura di nuove regole e report.

L'obiettivo di questa architettura non è eliminare gli esseri umani dal SOC. È garantire che una compromissione non diventi una catastrofe perché un essere umano era troppo occupato a filtrare il rumore per vedere il segnale. La sopravvivenza nell'attuale ambiente di minacce dipende dall'architettura e dalla velocità, non solo da strumenti migliori.

Fonti:

• CISA (Cybersecurity and Infrastructure Security Agency) - Guidelines on AI Security and Triage.
• NIST (National Institute of Standards and Technology) - AI Risk Management Framework 1.0.
• Anthropic - Claude Enterprise and API Documentation.
• Analisi interna delle tendenze della telemetria e della tokenomics nelle operazioni di sicurezza aziendale (2025-2026).

Disclaimer: Questo articolo è solo a scopo informativo ed educativo e non sostituisce un audit professionale di cybersecurity o un servizio di risposta agli incidenti.