Il mercato IoT italiano ha superato una nuova soglia: secondo l’Osservatorio Internet of Things del Politecnico di Milano, nel 2025 ha raggiunto 10,9 miliardi di euro, in crescita del 12% sull’anno precedente, con 175 milioni di oggetti connessi attivi nel Paese. E l’aspetto interessante è che la diffusione non riguarda più solo smart metering, auto connesse o building automation. Entra nelle fabbriche, nella logistica, nella gestione degli asset, nelle utility e nei servizi basati sui dati.
Una piattaforma IoT deve sostenere progetti che partono da sensori e macchinari, attraversano reti e gateway e si estendono fino a cloud, edge, data platform, sistemi gestionali e applicazioni di AI. La sua scelta influisce direttamente sulla capacità di scalare nel tempo, sulla sicurezza, sui costi operativi, sulla governance dei dati e sulla libertà di evolvere l’architettura senza dipendere da un singolo fornitore.
Indice degli argomenti
Piattaforma IoT, perché la scelta pesa più del singolo progetto
Una piattaforma IoT è il livello che collega dispositivi, connettività, dati e applicazioni. Gestisce l’onboarding dei device, raccoglie telemetrie, governa messaggi ed eventi, espone api, abilita analisi, regole di automazione e integrazione con sistemi aziendali. In questa tassonomia, i blocchi ricorrenti sono device management, messaging hub, integration hub, analytics engine e security overlay.
La distinzione conta perché molti progetti IoT falliscono nella fase successiva al pilot. Un sistema pensato per monitorare pochi asset può non sostenere migliaia di dispositivi distribuiti, aggiornamenti firmware, identità macchina, flussi dati continui, dashboard operative, allarmi, modelli predittivi e integrazioni con ERP, MES, SCADA o CRM. La piattaforma va quindi valutata sul ciclo di vita completo, non sulla sola capacità di raccogliere dati.
Il punto di partenza è il caso d’uso
La scelta deve partire da una domanda: quale processo aziendale deve cambiare grazie all’IoT? Manutenzione predittiva, monitoraggio energetico, controllo qualità, tracciabilità logistica, gestione flotte, smart building, automazione di fabbrica e servitizzazione richiedono architetture diverse.
Per una linea produttiva contano latenza, integrazione con sistemi OT, continuità locale ed elaborazione edge. Per asset distribuiti sul territorio pesano connettività, consumo energetico dei dispositivi, diagnostica remota e aggiornamenti sicuri. Per servizi data-driven, invece, diventano centrali data model, api, governance, qualità del dato e integrazione con analytics e AI.
La shortlist dovrebbe nascere da metriche misurabili: riduzione dei fermi macchina, tempi di intervento, consumi evitati, qualità del prodotto, saturazione degli impianti, nuovi ricavi da servizi, compliance o riduzione dei costi di manutenzione. Senza queste metriche, la piattaforma rischia di essere giudicata sul numero di funzioni dichiarate dal vendor.
I requisiti tecnici da mettere nella shortlist
Device management e lifecycle
La gestione dei dispositivi è il cuore operativo della piattaforma IoT. Serve verificare onboarding, provisioning, inventario, configurazione, diagnostica, aggiornamento software e firmware, revoca delle credenziali, sostituzione e dismissione del device.
La piattaforma deve anche tenere traccia dello stato dei dispositivi. In molti casi servono digital twin per rappresentare digitalmente configurazioni, condizioni operative, eventi e relazioni con altri asset. Questo punto è particolarmente rilevante quando il parco installato cresce o quando i dispositivi lavorano in ambienti remoti, industriali o difficili da raggiungere.
Connettività, protocolli e messaging
Un progetto IoT serio è raramente monolitico. Può dover gestire protocolli di comunicazione come MQTT (messaggistica leggera per dispositivi connessi), HTTP (il protocollo alla base del web), CoAP (ottimizzato per dispositivi a basso consumo), OPC UA e Modbus (ampiamente utilizzati nell’automazione industriale), oltre a tecnologie di connettività come LoRaWAN per le reti a lungo raggio, reti cellulari 4G/5G, Wi-Fi industriale e protocolli proprietari. La piattaforma deve essere in grado di orchestrare questa eterogeneità senza costringere l’impresa a moltiplicare gateway, adattatori e integrazioni personalizzate.
Vanno valutate le capacità di message broker (il componente che riceve, instrada e distribuisce i messaggi tra dispositivi, applicazioni e servizi), insieme alle funzionalità di gestione degli eventi, definizione delle regole, qualità del servizio (QoS), buffering, retry, normalizzazione dei dati e gestione dei picchi di traffico. La componente di messaging non è un dettaglio tecnico: da essa dipendono affidabilità, latenza, costi di trasmissione e disponibilità delle informazioni per le applicazioni operative.
Edge, cloud e ibrido
La scelta tra cloud, edge e architetture ibride dipende dal caso d’uso. L’edge riduce latenza, traffico dati e dipendenza dalla connettività; il cloud offre scalabilità, integrazione con data platform e servizi avanzati; l’ibrido consente di distribuire il carico dove serve.
In fabbrica o nelle infrastrutture critiche, l’elaborazione locale può essere necessaria per mantenere continuità operativa anche in caso di disconnessione. In applicazioni consumer o fleet management, il cloud può semplificare gestione, aggiornamenti e analisi aggregate. Il criterio corretto è la distribuzione del carico tra device, gateway, edge e cloud in base a vincoli operativi, costi e sicurezza.
Integrazione con sistemi aziendali
La piattaforma IoT deve dialogare con sistemi già presenti come ad esempio: MES, ERP, SCADA, CRM, data lake, data lakehouse, strumenti di business intelligence, piattaforme AI e sistemi di ticketing. Le API, i connettori e il modello dati sono quindi parte della valutazione di acquisto.
Una piattaforma chiusa può accelerare il primo rilascio, ma complicare l’integrazione successiva. Una piattaforma troppo componibile può dare controllo, ma richiedere competenze interne più mature. La decisione deve includere il livello reale di capacità IT e OT disponibile in azienda.
Sicurezza IoT: il criterio da scrivere nel capitolato
Ogni dispositivo connesso estende la superficie d’attacco. La piattaforma deve supportare identità dei dispositivi, autenticazione forte, autorizzazioni granulari, cifratura delle comunicazioni, gestione dei certificati, logging, audit trail, segmentazione e integrazione con strumenti di security monitoring.
Il tema va affrontato dalla fase di procurement. Il Nist SP 800-213 propone di definire i requisiti di cybersecurity dei dispositivi IoT considerando il modo in cui si integrano nei sistemi dell’organizzazione. Le linee guida Enisa per la sicurezza dell’IoT richiamano invece l’intero ciclo di vita: requisiti, design, sviluppo, consegna, manutenzione e dismissione.
In Europa pesa anche il Cyber Resilience Act, entrato in vigore il 10 dicembre 2024. La Commissione europea indica obblighi di reporting dall’11 settembre 2026 e l’applicazione dei principali obblighi dall’11 dicembre 2027. Per chi sceglie oggi una piattaforma IoT, significa chiedere al vendor come gestisce vulnerabilità, aggiornamenti, supply chain software, documentazione e supporto lungo il ciclo di vita.
Dati IoT, AI e Data Act
La piattaforma IoT determina chi accede ai dati, in quale formato, con quali regole e con quale livello di portabilità. La questione diventa più rilevante con l’AI, perché modelli predittivi, anomalie, digital twin e automazione dipendono dalla qualità e dalla continuità dei dati raccolti.
Il Data Act europeo, applicabile dal 12 settembre 2025, rafforza il controllo di utenti e imprese sui dati generati da prodotti connessi, inclusi macchinari industriali, veicoli e altri dispositivi. Per le aziende, la piattaforma IoT deve quindi rendere verificabili accesso, esportazione, condivisione e riuso dei dati, evitando dipendenze tecniche o contrattuali che impediscano di valorizzarli.
La governance va chiarita prima del contratto: data ownership, formati, retention, localizzazione, cancellazione, accesso di terze parti, uso per training o analytics, gestione dei dati personali e separazione tra dati grezzi, derivati e arricchiti.
Generalista, verticale o componibile
Le piattaforme generaliste, spesso legate ai grandi ecosistemi cloud, offrono scalabilità, integrazione con servizi dati e ampia disponibilità di partner. Le piattaforme verticali portano modelli, connettori e funzioni già vicini a settori come manifattura, energia, building, logistica o sanità. Gli approcci componibili, anche basati su componenti open source, danno più controllo architetturale, ma aumentano la responsabilità di integrazione e manutenzione.
La scelta dipende dalla maturità dell’impresa. Un’azienda con competenze interne forti può preferire un’architettura modulare per evitare dipendenze eccessive. Un’organizzazione che deve accelerare un caso d’uso verticale può trarre vantaggio da una soluzione più pronta, purché siano chiari i limiti di personalizzazione, portabilità e integrazione.
Vendor lock-in, costi e continuità
Il lock-in non nasce solo dal cloud provider. Può dipendere da protocolli proprietari, data model chiusi, regole sviluppate in linguaggi specifici, connettori non standard, dashboard non esportabili, condizioni contrattuali rigide o costi elevati di uscita.
La valutazione deve includere una exit strategy: export dei dati, portabilità delle configurazioni, migrazione dei device, supporto di standard aperti, documentazione delle API, clausole di fine contratto, continuità degli aggiornamenti e impegni di supporto.
Anche il TCO va calcolato oltre il prezzo di licenza: dispositivi, gateway, connettività, messaggi, storage, analytics, traffico dati, ambienti edge, cybersecurity, integrazione, manutenzione e competenze.
Un proof of concept efficace dovrebbe testare almeno un caso d’uso reale, con dati reali, integrazione con un sistema aziendale e criteri misurabili. La scorecard può pesare business fit, sicurezza, interoperabilità, scalabilità, costi, governance dei dati, roadmap del vendor e competenze richieste.
La checklist per scegliere la piattaforma IoT
Prima della decisione, l’impresa dovrebbe verificare otto punti.
- Il primo è l’aderenza al caso d’uso: la piattaforma risolve un problema operativo misurabile o aggiunge complessità?
- Il secondo è la scalabilità: quanti dispositivi, messaggi, eventi e dati può gestire senza cambiare architettura?
- Il terzo è la sicurezza: identità, patch, certificati, audit e vulnerability management sono nativi o delegati a integrazioni esterne?
- Il quarto è l’interoperabilità con protocolli, sistemi OT e applicazioni enterprise.
- Il quinto riguarda edge, cloud e ibrido: la distribuzione dei carichi è coerente con latenza, continuità e costi?
- Il sesto è la governance dei dati: accesso, portabilità, formati e diritti d’uso sono chiari? I
- l settimo è il TCO , includendo integrazione e gestione operativa.
- L’ottavo è la sostenibilità del vendor: roadmap, supporto, ecosistema, stabilità e clausole di uscita.
La piattaforma IoT più adatta è quella che consente all’impresa di governare dispositivi, dati e applicazioni lungo l’intero ciclo di vita. La decisione migliore nasce dall’incrocio tra valore atteso, architettura, sicurezza e capacità organizzativa. Solo così l’IoT smette di essere una somma di progetti isolati e diventa infrastruttura operativa per servizi, processi e decisioni basate sui dati.
Partecipa alla community