Il rilevamento delle anomalie consiste nell’individuare in automatico schemi insoliti nei dati che si discostano in modo significativo dal comportamento atteso. A differenza delle tradizionali soglie fisse, i modelli di IA apprendono l’andamento normale dei dati aziendali e rilevano gli scostamenti nel loro contesto, riducendo drasticamente i falsi positivi che saturano i sistemi di allarme convenzionali.
I principali casi d’uso
Industria e manifattura. Rilevamento di comportamenti anomali nei sensori dei macchinari prima che sfocino in un guasto. Un motore che alle 2 di notte comincia a vibrare in modo atipico, secondo uno schema specifico, può non superare alcuna soglia fissa ed essere comunque rilevato come anomalia statistica.
Operazioni finanziarie. Transazioni fuori dal comportamento abituale di un cliente o di un fornitore. La differenza rispetto a un sistema a regole classico è che il modello apprende il comportamento individuale di ciascun soggetto, non una soglia globale.
Supply chain. Consegne con tempi anomali, consumi di magazzino che si discostano dalla stagionalità storica, fornitori con andamenti di fatturazione irregolari.
Infrastruttura IT. Latenze, errori e modalità di utilizzo delle risorse che segnalano problemi prima che il servizio peggiori o si interrompa.
Qualità del prodotto. Nelle linee di produzione con sensori di temperatura, pressione o peso, il rilevamento multivariato delle anomalie individua combinazioni di valori singolarmente normali che, insieme, indicano un difetto.
I principali algoritmi e quando applicarli
| Tecnica | Indicata per | Interpretabilità |
|---|---|---|
| Isolation Forest | Anomalie in dati ad alta dimensionalità | Media |
| LSTM Autoencoder | Serie temporali, segnali dei sensori | Bassa |
| One-Class SVM | Quando per l’addestramento si dispone solo di dati normali | Media |
| Statistiche (Z-score, IQR) | Serie univariate, come base di riferimento | Alta |
| Prophet + residui | Serie con stagionalità complessa | Alta |
| DBSCAN | Rilevamento di cluster anomali nello spazio | Media |
La scelta dipende dal tipo di dato, dalla velocità di rilevamento richiesta e dalla necessità che il sistema sia verificabile da un’autorità di vigilanza o dall’audit interno.
L’integrazione in produzione
Un sistema di rilevamento delle anomalie in produzione ha tre componenti:
- Acquisizione dei dati in tempo reale o batch: Kafka per lo streaming, pipeline ETL per il batch notturno.
- Modello di scoring: un’API che riceve un evento o un record e restituisce un punteggio di anomalia e, facoltativamente, una spiegazione (quali variabili hanno contribuito).
- Livello di azione: avviso su Slack, ticket su Jira, blocco nell’ERP o attivazione di un agente di IA che indaga sull’anomalia.
Quando il rilevamento delle anomalie non risolve il problema
Il rilevamento delle anomalie non è utile quando il concetto di «normale» cambia spesso e il modello non viene riaddestrato. Nelle aziende con forte variabilità stagionale o in piena trasformazione dei processi, il modello può diventare obsoleto in poche settimane. In questi casi occorre progettare una pipeline di riaddestramento continuo o usare modelli adattivi.
Non è la soluzione nemmeno quando il problema reale è la mancanza di dati storici di qualità. Rilevare le anomalie richiede di aver prima definito che cosa sia normale, e per farlo servono dati etichettati o uno storico sufficiente.
Domande frequenti
Quanti dati storici servono? Dipende dall’algoritmo. Isolation Forest può funzionare con 1.000-5.000 record. Un LSTM Autoencoder per serie temporali richiede diversi mesi di storico con una buona copertura. In generale, più varietà di comportamenti normali c’è nello storico, meglio è.
Si possono rilevare anomalie senza dati etichettati? Sì. La maggior parte degli algoritmi di rilevamento delle anomalie è non supervisionata: apprende l’andamento normale senza bisogno di etichette di «anomalia». È un vantaggio, perché le anomalie reali sono di solito rare e difficili da etichettare.
Come si evita l’eccesso di allarmi? Con una soglia di punteggio calibrata su dati reali e, spesso, con un secondo livello di convalida che raggruppa le anomalie correlate prima di generare l’allarme. La progettazione del sistema di allarmi è importante quanto il modello stesso.