u/Logical_Ice_4531

Un cliente mi ha chiesto di automatizzare le mail su documenti/scadenze senza toccare il gestionale. Ho usato Ollama con phi3 e Mailgun, ma la privacy è stata la prima battaglia.

Niente accesso diretto al software contabile: ho creato un webhook che mandava solo ID documento e data scadenza (via API cifrata), dopo consenso GDPR esplicito via form sul sito. Il prompt era semplice: "Client {name}, your {document} is due on {date}. Reply 'yes' to confirm."

Problema reale: il modello leggeva 15/10 come 15 ottobre (quando il client usava DD/MM). Messaggio di errore preciso: "Date format mismatch". Fixato con regex nel prompt: "{date} must be in DD/MM/YYYY".

Altri bolli: quando Ollama rispondeva "Error", scattava un alert all'accountant (es. "Model failed on client X, check manually"). Tempo prima: 2 ore/giorno su queste mail; ora ~15 minuti con errori quasi zero.

Non sono sicuro della regex—probabilmente esiste un modo più pulito—but funziona e non ho mai visto il modello rispondere a una richiesta complessa (es. "Quanto mi costa la dichiarazione?"). Se capita, manda l'alert e ci pensa l'uomo.

Verdetto: per domande semplici sì, ma solo se tagli i dati a spillo (niente accesso al database). Privacy prima di tutto: senza il webhook sicuro, non avrei neanche provato.

Una PMI di logistica a Bologna aveva perso il processing automatico delle fatture dopo la chiusura di Emma. Il vecchio sistema con Azure Form Recognizer v3.1 costava +300€/mese e non fungeva bene col PHP legacy (v8.1). Pensavo fosse un caso disperato... fino a che ho provato Ollama 0.1.30 su Raspberry Pi 5 (8GB RAM) con Llama 3 8B quantizzato, integrato via FastAPI 0.110.0.

Ho addestrato il modello con 200 fatture reali e LoRA su Hugging Face Transformers. All'inizio l'errore era alto (su 50 campioni, quasi il 40%), latenza ~420ms per le fatture complesse. Dopo fine-tuning, l’accuratezza è migliorata parecchio, latenza media a ~350ms. Ma poi ho sbattuto la testa: timeout PHP al 10% per query MariaDB lente.

Dopo aver aggiunto Redis 7.2 in coda (senza toccare il codice legacy), il sistema ha preso a girare senza problemi. Costo totale? ~40€/mese, ma ogni settimana controllo a mano le fatture con firme manoscritte. Non sono sicuro che funzioni per volumi >200/giorno, però per PMI che hanno processi strutturati e tolleranza all’errore... è un ottimo trade-off. A volte il più semplice è anche il migliore.

Un cliente PMI aveva un workflow di elaborazione fatture che usava API cloud a €50/mese. Volevano evitare esportazioni dati e ridurre costi, quindi ho provato Ollama su un server i9-13900K + 64GB RAM (nessuna GPU).

Installato qwen3:14b per estrazione campi strutturati (es. importo, codice cliente), con latenza di 30-60s a richiesta. Accettabile perché il processo gira in background notturno. Ma quando hanno provato a usare lo stesso modello per validazioni real-time (es. moduli web), la latenza è salita a >120s: niente da fare, tornato all'API cloud solo per quei casi.

Configurazione chiave: servizio systemd con `Restart=on-failure` e `WatchdogSec=5m`. Un giorno ho visto l’errore *“failed to allocate 16GB”* durante un picco di carico — risolto aggiungendo swap (non ideale, ma evitava crash). Monitorato via Prometheus con alert su RAM >80%.

Costi: ~€5/mese per il server vs €50 in cloud. Privacy? Dati mai usciti dal network interno. Non sono sicuro che lo swap sia la soluzione migliore, ma almeno non si è bloccato più dopo i crash iniziali. Per workflow asincroni e dati strutturati, hardware consumer + Ollama regge — il resto va sull’API.

Un cliente di abbigliamento con SAP B1 passava 8-10 ore alla settimana segmentando clienti manualmente, trascurando dati di fatturazione e feedback (errori frequenti su transizioni). Ho provato un cluster K-Means locale: scikit-learn 1.2.1, Python 3.9, containerizzato in Docker 20.10.17, eseguito sul Raspberry Pi 4 (4GB RAM) con dati storici da 5 anni (8 feature, 12k record).

Il risultato? Tempo di analisi sceso a una quindicina di minuti/settimana e errori quasi eliminati — monitorato con Prometheus per la latenza media (0.8s dopo ottimizzazioni joblib). Il traffico giornaliero era modesto (max 50 richieste/ora), quindi il Raspberry non ha mai bloccato l’esperienza utente.

Ma ho sbagliato all’inizio: con 100 cluster, la latenza partiva da 2.3s. Poi i dati sono cresciuti al 30% (15.6k record) e il Pi ha superato il 95% CPU, portando a 1.5s di latenza — sopra il limite operativo di 1.2s che avevamo stabilito. Non ho previsto la crescita del dataset, pur avendo controllato il trend con Prometheus.

Ora mi chiedo: se l’azienda fosse cresciuta più in fretta, avrei dovuto usare un server dedicato anziché giocare coi cluster? Probabilmente sì. Ma per PMI con dataset sotto i 10k record e crescita annua moderata (max 20%), questo setup ha senso — non costa niente oltre al Raspberry, e il tempo di implementazione è stato inferiore a una giornata.

Per volumi sopra 50k o applicazioni critiche in real-time? Meglio lasciar perdere: il Raspberry non ce la fa, ma per chi parte da zero con dati piccoli, vale la pena provare.

Ho lavorato su un caso per una PMI elettronica bolognese che gestiva 500 ordini al giorno tra SAP Business One e un CRM PHP custom. Prima, il processo manuale generava errori con codici ambigui come 'PROD-2023' vs 'PROD2023', con ritardi di 3 ore a causa della sincronizzazione batch.

​

Ho usato Ollama 0.1.4 (Llama3-8B) su un Dell OptiPlex 7080 (i7-10700, 32GB RAM), Python 3.10 e LangChain per elaborare CSV da SAP (media 12MB/batch). L'LLM mappava automaticamente i campi e inviava via API al CRM. Risultato: il tempo passò da 3 ore a 36 minuti, con errori quasi eliminati.

​

Ma il modello falliva in casi come 'A-2023' vs 'A2023', richiedendo un intervento manuale per 60 ordini al giorno (+30 secondi/ordine). Non so se sia il modo migliore: funziona bene con codici fissi (es. 'PROD-2023'), ma in un’azienda di cartoleria con codici come 'B2023' o 'C-2024', avrebbe causato troppe eccezioni. Il verdetto? Solo per flussi dati strutturati, niente a che vedere con scenari caotici.

Per un cliente legale con 500 contratti/settimana, ho provato a sostituire GPT-4 (3s/contratto, €0.05) con Llama-3-8B quantizzato Q4_K_M su Ollama 0.1.40, addestrato in LoRA rank 64 sulla mia RTX 4090.

​

Il risultato? Precisione all'85% per clausole standard ("danni e responsabilità"), latenza a 1.2s (vs 3s cloud) e throughput di 15/min, con costo totale €1.2k vs €1.250/settimana del cloud.

​

Ma il vero problema è stato saltare fuori con termini arcaici: "domicilio" invece di "residenza" ha fatto calare l'accuratezza sotto il 60%, generando errori nel 22% dei casi. La quantizzazione Q4_K_M ha poi ridotto ulteriormente la precisione su frasi complesse, perdendo il 5% in più.

​

Mi chiedo ancora se esiste un modo migliore per bilanciare costo e accuratezza, ma alla fine ho capito: per fatture o dati strutturati semplici, il modello locale regge. Per ambiti come legale dove la precisione è critica? Meglio aspettare modelli italiani specializzati (tipo Jina AI), non copiare soluzioni "generiche" che finiscono per creare più problemi che risolvere.

Ho lavorato con uno studio legale che aveva un disastro: riassumere documenti legali scritti a macchina con errori di ortografia e frasi spezzate. Ho provato Qwen3, Llama3 e Mistral su task *reali*, non su dataset puliti.

​

Qwen3 catturava bene termini tecnici (es. "art. 1259 c.c."), ma se c’era un typo come "contratto di locazion", lo riproduceva. Per le email, classificava bene ma a volte tagliava frasi importanti ("per favore, inviare entro venerdì" → "invia entro venerdì").

​

Llama3 era veloce nel filtrare spam, ma trasformava "Gentile avvocato" in "Ciao avvocato" in email formali. Un cliente ha detto: "Sembrava un assistente che non sapeva cosa fosse un contratto".

​

Mistral invece ha gestito meglio gli input sporchi. Un'email con "ciao, puoi mandarmi il file? (non ho tempo)" è diventata "Gentile cliente, si prega di inviare il documento al più presto." Errori frequenti → quasi zero. I processi che richiedevano ore ora si fanno in pochi minuti.

​

Il punto? Per il lavoro reale, la capacità di "pulire" input sporchi è più importante che un punteggio su un dataset. Mistral non è il più potente, ma è il più affidabile con dati italiani "vividi". 😅

Ho visto clienti che usavano APScheduler per task semplici in app Python, ma poi hanno avuto problemi in produzione. Un esempio: un’azienda di logistica aveva un task che generava report alle 6:00 ogni giorno. Dopo un riavvio del server (comune per patch), il task non si è eseguito per 24 ore. Il problema? APScheduler embedded non ripristina la pianificazione dopo un restart. Hanno aggiunto Redis per persistere la schedulazione, ma era un overkill per un progetto piccolo.

​

Al contrario, per un sistema di fatturazione con 15 task/min (es. invio email, chiamate API), ho scelto Celery+Redis. Non era un progetto "grande", ma con task critici e bisogno di retry automatico (es. API che fallivano temporaneamente), APScheduler avrebbe richiesto gestione manuale complicata. Con Celery, i task si eseguivano in modo affidabile anche con 30+ worker, senza perdite.

​

Conclusione: se hai un’app single-process, task sotto 30/min e riavvii rari, APScheduler va bene. Se invece i task sono critici, devi gestire errori o concorrenza, Celery+Redis è la scelta giusta. Non è sempre "il meglio", ma evita problemi che ti fanno svegliare alle 3 di notte per correggere un report mancato.

Ultimamente ho aiutato un piccolo studio contabile a ridurre il tempo speso nei solleciti. Prima, ogni fine mese, il team faceva 15-20 chiamate manuali per clienti in ritardo. Ogni volta, il rischio di sembrare sbrigativo o meccanico... e il tempo che si perdeva era davvero tanta.

​

Ho provato a implementare un sistema basic di email automatica con template personalizzato (nome cliente, data scadenza), ma dopo due settimane il cliente mi ha detto: *“Sembra scritto da un robot, non mi sento ascoltato”*. Ahia.

​

Poi ho cercato di integrare WhatsApp per un test, ma alcuni clienti hanno risposto: *“Ma non è una cosa troppo informale?”*. Quindi ho aggiunto un tocco umano: frasi tipo *“Ciao Marco, spero tu stia bene. Ti scrivo per ricordarti che il pagamento per il documento del 15 è in scadenza…”*.

​

Ora mi chiedo: come gestite voi i solleciti senza perdere il contatto umano? Usate tool che permettono di personalizzare le mail/SMS? E WhatsApp è una strada percorribile, o è meglio evitare?

Vorrei sapere se avete trovato il giusto equilibrio tra automatizzazione e calore umano. 😊

Ho lavorato con uno studio legale che usava un gestionale vecchio come un'antiquaria, non integrabile con nessun SaaS. Dati clienti sensibili (contratti, documenti confidenziali), non potevano rischiare su HubSpot o simili. Abbiamo sviluppato un tool interno con AI per analisi automatica: costo iniziale più alto, ma dopo 2 mesi hanno ridotto i tempi di ricerca da ore a minuti.

Ora mi chiedo: per voi, quando il "non si fa" con SaaS diventa un motivo per costruire qualcosa di custom? Pensate a dati critici, sistemi legacy che non "parlano" tra loro, o processi troppo specifici per un settore. Un cliente ha detto: *"Non è che non volevamo usare il SaaS, è che non potevamo*".

E voi? Avete mai preferito il custom pur sapendo che sarebbe stato più lento all'inizio?

Ho implementato un'automazione per un cliente che non poteva spendere per GPU dedicate. Hardware usato: i9-13900K + 64GB RAM (niente server costosi). Ho testato tre modelli Ollama:

- **qwen3:14b** per estrazione dati strutturati (es. formattare PDF in JSON): risposte rapide, 10-15s per richiesta.

- **qwen3:30b-a3b** per analisi testi (es. sintesi report legali): latenza 40-50s, ma il cliente accettava asincrono.

- **qwen2.5-coder** per generare script Python: funzionava bene su codice semplice.

Problema principale: lock su SQLite con richieste multiple. Soluzione: abilitato **WAL mode** (niente più errori di blocco). Per crash, configurato **systemd Restart=always** (si riavvia automaticamente se il processo si blocca).

Risultato: il cliente ora gestisce 50+ task al giorno senza downtime, con costi di infrastruttura *molto più bassi* rispetto a un servizio cloud. La latenza 30-60s è accettabile perché i task sono asincroni (es. report giornalieri che non devono essere immediati).

Conclusione: se non serve real-time, hardware consumer + Ollama è una via valida. Ho visto clienti che pensavano di dover comprare server cari... invece bastava una configurazione smart. Niente supercomputer necessario.

Un cliente mi ha fatto un favore: mi ha raccontato che ogni mese, con 30 PMI da gestire, passava 2 ore a controllare IBAN e compilare il file SEPA a mano. Errori frequenti, penali da evitare, e il tempo che scappa.

Ho deciso di provare con uno script in Python (pandas per i dati, openpyxl per esportare). Leggeva direttamente lo scadenzario dal suo gestionale (esportato in Excel) e generava il file XML pronto per la banca. Niente più copia-incolla, niente più "ma l'IBAN di questa azienda è sbagliato?".

Risultato: il processo che richiedeva 2 ore ora dura 10 minuti, e gli errori IBAN sono spariti (almeno, non ne ho più sentito parlare). La cosa divertente? Il commercialista, dopo, mi ha chiesto: "Ma il tuo script può anche gestire le fatture?" 😄

Se ripetessi, integrerei l'automazione direttamente nel gestionale, ma per il momento è una soluzione semplice che non ha bisogno di modificare il suo workflow. A volte basta un piccolo passo per fare la differenza.

Un cliente mi ha chiesto di automatizzare le risposte su WhatsApp per un servizio clienti, e ha optato per Baileys invece dell'API ufficiale. Dopo un mese, l'account è stato bannato senza avvisi: Meta ha bloccato l'account per "attività sospetta", e il recupero è stato impossibile.

Analizzando il perché: Baileys (e simili) non usa gli endpoint ufficiali, ma si appoggia al protocollo mobile di WhatsApp, che Meta monitora attentamente. L'API ufficiale ha un'architettura stabile con rate limit definiti e supporto, mentre Baileys richiede di "imitare" un client mobile, generando traffico anomalo che Meta identifica con algoritmi (es. frequenza di messaggi, fingerprint del dispositivo).

Il rischio maggiore è il ban totale: se un account viene bannato, non c'è modo di ripristinarlo. Ho visto clienti che hanno dovuto cambiare numero di telefono per il servizio, causando interruzioni di 2-3 settimane.

L'API ufficiale richiede una richiesta di approvazione a Meta (non sempre facile), ma se accettata, il sistema è affidabile. Per chi cerca una soluzione rapida, Baileys può sembrare conveniente, ma il rischio di downtime è alto.

A oggi, nessun cliente ha mai recuperato un account bannato con Baileys. Se il progetto è critico, l'investimento nell'API ufficiale è più sicuro, anche se richiede un po' di tempo in più per l'onboarding.

Uno dei miei clienti ha provato a mettere Ollama in produzione su un server consumer con i9-13900K e 64GB RAM, senza GPU dedicata. L'obiettivo era gestire task strutturati, tipo analisi di dati o generazione di testi in batch. Ho visto che il modello qwen3:14b funziona decentemente, con latenza accettabile per workflow asincroni. L'ho configurato con systemd per gestire i crash automaticamente, e ho messo un monitoraggio in tempo reale via Prometheus per tenere d'occhio l'uso della VRAM.

Il problema è che se si prova a fare richieste parallele, la VRAM diventa un collo di bottiglia. Anche con 64GB, il modello non riesce a gestire più di due richieste contemporaneamente senza ritardi evidenti. Per uso real-time, tipo chatbot o app con interazioni immediate, non è adatto. La latenza si aggira sui 2-3 secondi per risposta, che per un'applicazione web non è accettabile.

Confronto con le API cloud: i costi sono decisamente più alti, ma la latenza è inferiore di un fattore 3-4. La privacy è un altro punto: alcuni clienti non vogliono mandare dati sensibili in cloud, quindi self-hosted è una soluzione interessante per loro, pur con i limiti hardware.

Ho imparato che per task asincroni e non real-time, Ollama su hardware consumer è un'opzione valida. Ma se si ha bisogno di risposte istantanee o di scalabilità, bisogna valutare altre soluzioni. Il setup richiede attenzione ai dettagli, soprattutto per la gestione degli errori e il monitoraggio.

Quante ore perde il vostro studio su operazioni manuali ogni mese?

---

Domanda genuina, nessuna agenda: lavorando con diversi studi mi sono reso conto che il tempo perso su operazioni ripetitive varia tantissimo da studio a studio, e mi chiedo se sia un problema diffuso o dipenda dall'organizzazione interna.

Parlo di cose tipo: riconciliazioni bancarie su Excel, estrazione manuale di dati da F24 o da estratti conto, invio solleciti pagamento uno per uno, aggiornamento scadenzari.

Nel vostro studio quante ore ci vanno ogni mese su questo tipo di attività? E come le gestite — tutto manuale, parzialmente automatizzato, o avete trovato soluzioni che funzionano?

Curioso di capire se la situazione che vedo io è rappresentativa o sono casi particolari.

Un paio di anni fa, uno dei miei clienti mi chiese aiuto per un problema che si ripeteva ogni mese: compilare a mano il file CBI/XML per i bonifici SEPA. Erano circa 200 clienti PMI, e ogni volta c’erano errori IBAN, duplicati, o dati non aggiornati. Il team spendeva qualche ora al mese solo per correggere i file, e il rischio di ritardi era alto.

Ho pensato di automatizzare il processo. Ho creato uno script in Python che legge lo scadenzario direttamente dal gestionale (esportato come Excel) e genera il file XML pronto per la banca. Per gestire i dati, ho usato pandas e openpyxl per manipolare le tabelle, e ho aggiunto controlli automatici sugli IBAN (es. verifica della lunghezza e formato).

Il risultato? Il tempo passato da qualche ora a qualche minuto. Gli errori di IBAN, che prima erano frequenti, sono quasi spariti. Il team ha potuto concentrarsi su lavoro più strategico, e i clienti non hanno più ritardi nei pagamenti.

C’è stato un piccolo problema iniziale: alcuni gestionali non esportavano i dati nel formato giusto, e ci sono voluti un paio di aggiustamenti. In futuro, probabilmente avrei aggiunto un’interfaccia grafica per rendere l’uso più intuitivo, ma per ora lo script funziona bene.

Se siete in una situazione simile, non esitate a provare un’automazione, anche semplice. Il tempo risparmiato vale sempre la pena.