In breve
Le e-mail aziendali pesano: ogni mattina qualcuno passa tempo a smistarle, classificarle, rispondere a quelle ricorrenti. Noi abbiamo costruito un sistema che gestisce automaticamente la cassetta degli errori automatici dei nostri software: l’IA classifica il problema, e quando il cliente può risolverlo da solo, gli manda una e-mail con istruzioni chiare. Senza che nessuno in azienda debba aprirla. Il sistema gira in casa: nessuna e-mail passa per servizi cloud come ChatGPT. Funziona bene perché le e-mail di errore sono prodotte da un programma, hanno struttura prevedibile, l’IA è bravissima a interpretarne i dettagli. Sulle e-mail scritte da umani in linguaggio libero il modello locale piccolo sbaglia ancora ~10%: troppo per produzione, ma scalando hardware e modello dovrebbe migliorare.
Le e-mail aziendali pesano. Smistare quello che è urgente da quello che può aspettare, classificare le richieste tecniche, rispondere agli errori ricorrenti dei nostri prodotti con istruzioni che il cliente potrebbe seguire da solo: sono operazioni che ogni mattina portano via tempo prima ancora di iniziare il vero lavoro.
In particolare ci infastidiva un caso: i nostri software inviano automaticamente segnalazioni quando qualcosa va storto in produzione presso il cliente. Una buona parte di questi errori sono “facili”: un campo e-mail vuoto in anagrafica, un dominio scritto male, una configurazione mancante. Il cliente potrebbe sistemarli in 30 secondi se sapesse cosa cercare.
Abbiamo provato a far gestire automaticamente questa parte di posta dal server IA in casa. La domanda di partenza: si può fare in modo onesto, senza mandare le e-mail dei clienti a un servizio cloud?
Cosa abbiamo costruito
Il flusso. Una cassetta postale Microsoft 365 dedicata, dove i nostri software inviano automaticamente le segnalazioni di errore quando qualcosa va storto in produzione presso un cliente.
Entra in scena n8n, l’orchestratore di workflow open-source che abbiamo descritto nell’articolo sul nostro server IA. Si collega alla cassetta sfruttando in modo autenticato il servizio di Microsoft 365, e a intervalli regolari preleva le e-mail di errore non ancora elaborate.
Per ogni e-mail, due passi:
- Lettura e classificazione da LLM locale. Il testo dell’e-mail (ripulito dell’HTML, dei tag e delle immagini incorporate) va al modello che gira sul nostro server IA in casa. Restituisce un blocco strutturato: tipo di errore, prodotto coinvolto, dati estratti (numeri d’ordine, codici, righe d’errore), e un giudizio: “il cliente può risolverlo da solo” sì/no.
- Azione conseguente. Se il giudizio è “sì”, parte una risposta automatica al cliente con istruzioni operative chiare. Se è “no”, l’e-mail resta nella coda umana per intervento del nostro tecnico.
Tutto dentro l’azienda. L’e-mail non lascia mai il dominio: dalla cassetta M365 al server IA in ufficio, e ritorno; o alla cassetta in uscita verso il cliente, o alla coda interna per l’intervento manuale. Niente e-mail mandate a OpenAI, Anthropic o altri provider esterni “per essere lette dall’IA”.
Come si comporta
Restiamo concreti. La cassetta degli errori dei nostri software è in produzione da settimane. Il sistema controlla la coda ogni 10 minuti, prende fino a 10 e-mail per ciclo, e in pratica gestisce fino a una sessantina di e-mail all’ora: più che abbastanza per i nostri volumi reali.
Sui campi rilevanti il modello non ha ancora sbagliato. Il giudizio “il cliente può risolverlo da solo” è corretto su tutte le categorie di errore che abbiamo codificato. Le istruzioni che il modello compone per la risposta automatica sono leggibili e fedeli al tipo di errore.
Vale la pena spiegare perché. Si potrebbe pensare che con e-mail generate da un programma basti un classificatore semplice: regex, if/else, un dispatcher su poche categorie fisse. Non è così. Lo stesso messaggio di errore emesso dal software può corrispondere a cause diverse, e bisogna leggere i dettagli (parametri, valori specifici, contesto) per capire quale sottocategoria sia. L’LLM qui non fa pattern matching banale: sta interpretando i dettagli per capire cosa è successo davvero e formulare l’istruzione giusta per il cliente. Funziona perché il vocabolario è il nostro: dominio chiuso che il modello ha imparato a riconoscere.
Le categorie di errore oggi gestite includono campo anagrafico vuoto (es. dominio e-mail mancante), dominio invalido nel destinatario, configurazione non valida sul cliente. Per ogni categoria il modello produce un’istruzione cliente in italiano: “L’errore segnalato è dovuto a un dominio scritto male nell’anagrafica del destinatario. Apri Anagrafiche → Soggetto → Dati anagrafici, correggi il campo e-mail, salva, e rimanda l’invio.”
Il tempo per ogni e-mail è di 30-60 secondi: non è velocità da chatbot interattivo, ma è asincrono e nessuno aspetta in linea.
Quello che NON va
Sarebbe disonesto fermarsi al caso che funziona. Tre limiti concreti.
1. Sul caso “e-mail scritte da umani” l’LLM sbaglia. Abbiamo provato a estendere il pattern alla cassetta amministrativa (e-mail del backoffice, richieste libere in linguaggio naturale). Su quel tipo di e-mail l’LLM (un modello da 8 miliardi di parametri che gira in casa) sbaglia circa il 10% delle volte. Confonde l’urgenza, non riconosce la categoria giusta, a volte travisa la richiesta. Per gli errori di sistema il 10% non sarebbe un problema; su e-mail scritte da clienti reali un errore su dieci è troppo per produzione. Quel flusso resta in modalità “test”.
Il problema è dimensionale, non strutturale: con un modello più grande e hardware più potente il margine di errore dovrebbe scendere. È sulla nostra lista da provare.
2. Le categorie di errore non si auto-aggiungono. Quando esce un nuovo tipo di errore (per una nuova feature, un caso particolare emerso), il modello deve essere “informato” del nuovo pattern, altrimenti lo classifica come “altro”. Lavoro umano periodico: non grosso, ma non zero.
3. Velocità. 30-60 secondi per e-mail significa che con i volumi attuali siamo coperti, ma una mailbox da 1.000 e-mail/ora supererebbe il limite. La risposta è la stessa degli altri use case: hardware più potente o più server.
Dove l’abbiamo applicato
Il caso in produzione è la cassetta degli errori dei nostri software, in funzione da settimane senza intoppi.
Il pattern si presta a tutti gli scenari in cui le e-mail arrivano da un sistema generatore, non da un essere umano da interpretare. Ovunque c’è una struttura prevedibile e un dominio chiuso che il modello può imparare a riconoscere, il pattern funziona. Ovunque c’è linguaggio umano libero, serve cautela (vedi sezione precedente).
Perché lo raccontiamo
Non è un manuale. Lo raccontiamo perché diversi nostri clienti ci stanno chiedendo come stiamo affrontando l’IA in azienda: cosa abbiamo costruito, cosa funziona, cosa no. Le risposte che diamo a voce le abbiamo messe in altri articoli qui sul lab:
- Il nostro server IA in casa, senza pretese: hardware, stack, limiti reali del setup su cui gira tutto questo.
- Documenti PDF che si inseriscono da soli nel gestionale: lo stesso pattern (workflow + LLM locale) applicato all’estrazione dati da PDF.
- GDPR e servizi IA blasonati: perché ChatGPT, Copilot e gli altri pongono domande di trattamento dati da chiarire prima di firmare.
Sistema in produzione da settimane, errori sui casi gestiti zero, copertura a tappeto degli errori risolvibili dal cliente. Se queste informazioni ti risulteranno utili, avremo fatto bingo.
Domande frequenti
L’IA può classificare automaticamente le e-mail aziendali?
Sì, con un workflow tipico: cassetta postale → orchestratore (es. n8n) → LLM locale che classifica → azione conseguente (notifica, risposta automatica, archiviazione). Funziona bene su e-mail generate da sistemi (alert, errori); meno bene su e-mail scritte da umani in linguaggio libero.
Si può rispondere automaticamente alle e-mail di errore dei clienti?
Sì, se le e-mail sono prodotte da un sistema (con vocabolario noto e struttura prevedibile) e l’errore è risolvibile dal cliente (es. campo mancante, configurazione errata). L’LLM analizza i dettagli, classifica la causa, compone l’istruzione operativa e manda la risposta. Per e-mail umane in linguaggio naturale il margine di errore è ancora alto (~10% con modelli locali piccoli).
Le e-mail passano per servizi cloud come ChatGPT?
Non se il modello IA gira su un server in azienda. Con il pattern n8n + LLM locale, le e-mail vanno dalla cassetta M365 → al server interno → all’azione conseguente, senza mai uscire dal dominio aziendale.
Quanto è veloce la classificazione di un’e-mail con un LLM locale?
Indicativamente 30-60 secondi per e-mail su un setup con APU AMD e 32GB di RAM. Velocità sufficiente per task asincroni (poco più di una sessantina di e-mail all’ora con batching), non per chat interattiva.
Cosa succede se cambia il tipo di errore o ne emergono di nuovi?
Le categorie non si auto-aggiungono. Ogni nuovo tipo di errore va “insegnato” al modello con un aggiornamento manuale del prompt o della logica di classificazione. Lavoro periodico, non una tantum.
