AI distribuita
nell'industria.

Tre tipi di problema arrivano dalla manifattura nel nostro form di contatto.

Il primo è la predictive maintenance mal congegnata. L'azienda ha installato sensori sui macchinari, raccoglie telemetrie da anni, ha provato a sviluppare un modello predittivo della manutenzione — e il modello produce falsi positivi al 30% nelle prime settimane di esercizio. Spesso la causa non è il modello: è il fatto che ogni macchinario è in realtà un'eccezione (configurazione diversa, anno di produzione diverso, fornitura diversa di componenti) e un modello globale non cattura la diversità. Federated learning con un modello per linea o per famiglia di macchinari, addestrato sui dati locali e senza centralizzazione, riduce il falso positivo perché ogni modello vede solo varianza coerente.

Il secondo è il quality control assistito. La sala controllo riceve immagini dalla telecamera fine-linea per scartare pezzi difettosi. La rete neurale che fa il classificatore è stata addestrata in laboratorio, deployment lo manda in produzione, e per la prima settimana funziona. Poi il dataset cambia — è inverno, la luce della telecamera ha una temperatura colore diversa, la materia prima ha un'altra fornitura — e l'accuratezza scende. Il problema è che il modello è stato addestrato una volta e non si aggiorna. L'approccio che adottiamo è una pipeline di re-training continuo dove il dato locale del sito di produzione viene usato per fine-tuning incrementale, con governance esplicita (chi approva l'aggiornamento, sotto quali criteri di confidenza) e audit log per ogni decisione automatica.

Il terzo è la integrazione con sistemi gestionali legacy. L'azienda ha un MES, un PLM, un ERP, ognuno installato in un decennio diverso, ognuno con la propria logica di nomenclatura, ognuno con i propri schema dati. L'idea iniziale del cliente è "metto un LLM sopra e gli faccio leggere tutto". Funziona in demo, fallisce in produzione: l'LLM non capisce che lo stesso codice articolo ha tre rappresentazioni diverse, che i campi obbligatori del PLM sono opzionali nel MES, che il gestionale ha vent'anni di workaround documentati nei commenti dei record. Approccio TORA: prima un knowledge graph aziendale che cattura le relazioni tra i sistemi (chi è autoritativo, dove vivono i mapping), poi un sistema agentico che usa questo grafo come contesto strutturato — non l'LLM come oracolo onnisciente, ma l'LLM come componente verificato dentro un'architettura più ampia.

Tre principi architetturali che abbiamo visto sopravvivere dal prototipo al deployment industriale.

Federated learning come default, centralizzazione come eccezione. Il vincolo "i dati non escono dal sito" non è una preferenza del compliance officer: è una scelta che difende il margine industriale. Una matrice di prodotto, una formula, un parametro di processo che esce dal perimetro aziendale è un asset che diventa pubblico. L'AI che pretende di centralizzare i dati per addestrare meglio sta chiedendo all'azienda di rinunciare a qualcosa di concreto in cambio di un beneficio teorico. Federated learning rovescia il rapporto: il modello viaggia, i dati restano. La complessità si sposta dall'esfiltrazione (problema legale e contrattuale che nessuno vuole gestire) all'orchestrazione (problema tecnico che si risolve con buona ingegneria). Lo abbiamo applicato in Jouelry in dominio retail: 3.500 retailer profilati senza centralizzare i dati di transazione di nessuno di loro. La stessa logica vale per la manifattura.

Multi-modello specializzato per dominio, non un grande modello generalista. L'industria parla un vocabolario tecnico denso e specifico. Un solo grande LLM generalista è inefficiente: paga il costo di addestramento su tutto Internet per applicarlo a un dominio in cui solo l'1% del corpus è rilevante. Un'architettura agentica con modelli più piccoli specializzati per ambito (uno per la documentazione tecnica del PLM, uno per il dialogo operatore, uno per la classificazione difetti immagine) — ognuno con un compito verificabile — ha tre vantaggi: costo computazionale per chiamata più basso, tracciabilità di chi ha risposto cosa, e la possibilità di aggiornare un modello senza toccare gli altri. L'approfondimento tecnico è in Reasonance e VIBE Framework, dove l'orchestrazione multi-modello è codificata come disciplina.

RAG sulla documentazione tecnica industriale, non su tutto. Il manuale dell'impianto, la procedura di manutenzione, la lista dei componenti omologati — questi documenti hanno alta densità informativa e bassa ambiguità. Un sistema RAG ben costruito sopra di loro funziona. L'errore che vediamo è il RAG generico: vector database alimentato con tutto il content management aziendale (slide commerciali, presentazioni di gara, documenti di marketing) — il retrieval pesca in un mare rumoroso e la qualità delle risposte crolla. L'approccio che adottiamo è scoping aggressivo: separare nella ingestion ciò che è normativo/tecnico/procedurale (RAG affidabile) da ciò che è discorsivo/marketing (escluso, o in una collezione separata con peso ridotto).

Audit prima di build. Quando entriamo in un contesto industriale che ha già avuto tentativi di AI in produzione, dedichiamo le prime 2-3 settimane a leggere il codice, le pipeline, gli SLA, i log delle ultime 6 settimane di esercizio. Nessuna nuova feature è proposta in questa fase. L'output è un documento — un mini-whitepaper interno — che dice cosa va preservato, cosa va rifondato, e dove il problema non è AI ma è dato grezzo, ingegneria di sistema o governance. Spesso è la fase più importante del progetto.

On-prem o hybrid, mai solo cloud. L'AI in cloud è scalabile, è veloce da deployare, ed è un problema in produzione industriale. Reti aziendali con segmentazione SCADA non possono permettersi una dipendenza continua da un endpoint esterno. Anche quando il cloud è autorizzato, lo è per casi specifici (training con dati anonimizzati, archiviazione lunga durata). L'inferenza è on-prem o on-edge per default. Quando un'azienda firma un progetto con TORA, una delle prime conversazioni è: dov'è la macchina di inferenza, chi la mantiene, quale è il piano di rollback se il modello si comporta in modo anomalo.

Ogni modello ha un proprietario nominato, internamente. Non è una pratica TORA esclusiva — è quello che vediamo funzionare. Quando un modello in produzione genera un errore costoso, deve esistere una persona dentro l'azienda che è responsabile di valutare, correggere, ri-deployare. Il modello come "scatola nera del fornitore esterno" è il pattern che fallisce di più. Parte del nostro lavoro è definire il transfer of ownership sin dall'inizio: chi è l'engineer interno che diventa custode del modello dopo che noi usciamo dal progetto.

Whitepaper interno come deliverable, non solo codice. A fine progetto, oltre al sistema in produzione, consegniamo un documento tecnico che descrive le scelte architetturali, le alternative considerate, gli errori incontrati. È il manuale di operazione del sistema per i prossimi cinque anni — quando cambierà l'engineer interno, quando cambieranno le condizioni di fornitura, quando l'azienda dovrà giustificare in audit perché il modello prende le decisioni che prende. Il codice senza la sua spiegazione tecnica è un asset dimezzato.