Quando il prezzo dell'AI diventa un rischio per il tuo ISMS

Sempre più aziende integrano l'AI generativa nei processi di sicurezza: triage degli alert nel SOC, analisi dei log, classificazione degli incidenti, supporto al DLP. Quasi sempre questa AI non gira in casa: arriva da un provider remoto — Anthropic, OpenAI e pochi altri — e si paga a consumo di token. È proprio qui che si nasconde un rischio che pochi hanno messo nel risk register.

Un fatto è noto a chi segue il settore: questi prezzi oggi sono, con ogni probabilità, artificialmente bassi. I provider operano in perdita per conquistare il mercato, sostenuti dal capitale di rischio. È penetration pricing. Quando il mercato si assesterà e il potere contrattuale passerà al fornitore, i prezzi saliranno: diversi analisti ipotizzano aumenti di 10x, o oltre.

Per gran parte degli usi aziendali è un fastidio gestibile: se un'attività costa di più, la si usa meno. Ma c'è un caso in cui non è un fastidio — è un rischio di compliance e di continuità: quando l'AI non è uno strumento di produttività, ma una misura di sicurezza del tuo ISMS.

La differenza che cambia tutto

Un controllo di sicurezza, a differenza di uno strumento di produttività, deve essere sostenibile ed efficace nel tempo. Se domani il triage automatico degli alert, che oggi costa X, costasse 10X, restano due sole uscite, entrambe brutte:

1. Spegni il controllo. Hai un buco di sicurezza e, se quel controllo è nel tuo Statement of Applicability, una non conformità: un controllo che non puoi più permetterti non è "monitorato ed efficace", è un finding.
2. Lo tieni acceso a 10X. Il costo della compliance diventa ostaggio del pricing power di un terzo, su cui non hai leva.

La tesi è questa: un controllo la cui efficacia dipende da un costo operativo variabile, non controllabile e fissato da un fornitore con incentivo strutturale ad alzarlo, è fragile a prescindere da quanto funziona bene oggi. L'efficacia tecnica non basta, se la sostenibilità economica è in mano ad altri.

Due rischi da non confondere

Conviene separarli nettamente, perché richiedono risposte diverse:

• Continuità/disponibilità — il provider deprecca il modello, cambia policy, lascia il mercato europeo. Terreno noto: già coperto da business continuity e supply chain.
• Repricing (cost-shock) — il costo aumenta in modo improvviso e rilevante. È la novità, ed è la parte meno presidiata.

L'errore comune è trattare il secondo come il primo. Un fornitore può essere perfettamente disponibile, affidabile e conforme, e ciononostante moltiplicare il prezzo. La continuità del servizio non protegge dalla continuità del costo.

Cosa dicono già i framework

Gli strumenti per nominare il rischio esistono già. DORA è l'alleato più diretto: nomina il concentration risk sui fornitori ICT terzi e impone strategie di uscita e gestione del lock-in (artt. 28–30). L'inference AI è di fatto un servizio ICT di terze parti, e il cost concentration — dipendere per una funzione critica da un prezzo che non controlli — ne è una variante naturale.

ISO/IEC 27001:2022: i controlli su fornitori e cloud (A.5.19–5.23) e la ICT readiness for business continuity (A.5.30) inquadrano la relazione. Ma il gancio più forte è un principio della norma: i controlli vanno monitorati nella loro efficacia. Un controllo che potresti dover spegnere per budget va riflesso onestamente nel risk treatment e nello Statement of Applicability.

NIS2 (art. 21.2, supply chain security) completa il quadro sul fronte fornitori.

Non tutti i task sono uguali

La sostituibilità dei modelli non è uniforme. Per molti compiti di sicurezza, modelli piccoli e open-weight — eseguibili in casa a costo prevedibile — fanno gran parte del lavoro: lì il lock-in economico è debole e il self-hosting è una via d'uscita reale. Dove serve davvero un modello di frontiera, il lock-in è forte, e lo è proprio dove conta di più. La domanda operativa non è "l'AI mi espone al cost-shock?", ma: quali dei miei controlli AI-based sono load-bearing su una capacità che non posso sostituire?

Cosa fare

Il rischio non si elimina, si governa:

1. Mappa la dipendenza. Per ogni controllo che usa AI annota nel risk register criticità, sostituibilità del modello e costo per unità di lavoro.
2. Disaccoppia dal fornitore. Un livello di astrazione tra i tuoi processi e i provider rende la sostituzione una configurazione, non un progetto.
3. Predisponi il degrado controllato. Ogni controllo critico abbia un fallback (tipicamente un modello locale): un cost-shock deve significare qualità ridotta, non controllo spento.
4. Tratta il costo come KPI di continuità, non solo di budget, con soglie d'allarme nell'ISMS.
5. Usa le leve contrattuali dove esistono: price-lock e preavviso di variazione si chiedono prima, non dopo lo shock.

In sintesi

Adottare l'AI nei processi di sicurezza è la scelta giusta. Ma significa esternalizzare anche il prezzo futuro di una propria misura di sicurezza, a un fornitore che ha ogni incentivo per aumentarlo. E se un intero settore poggia sugli stessi due o tre provider, il cost-shock diventa rischio sistemico — la stessa preoccupazione che DORA esprime sul cloud. La maturità non è evitare l'AI: è metterla nel risk register prima che sia il mercato a ricordartelo.