MLOps per PMI 2022: tool, processo e roadmap per portare ML in produzione

Secondo una stima diventata virale su VentureBeat nel 2019, l’87% dei progetti di data science non arriva mai in produzione. Tre anni dopo, nelle PMI italiane il rapporto e’ rimasto piu’ o meno lo stesso: data scientist che producono notebook Jupyter brillanti, dashboard di esperimenti su MLflow e proof-of-concept che impressionano in demo, ma che restano sulle workstation degli analisti senza mai vedere un utente, un’API di produzione o un report consumato dal business. Il valore generato e’ quindi vicino a zero: un modello che predice il churn al 92% di AUC ma non viene mai esposto come servizio non riduce di un euro l’abbandono dei clienti.

La radice del problema non e’ la statistica, ne’ la qualita’ degli algoritmi: e’ il gap tra sperimentazione e operations. Lo stesso gap che il movimento DevOps ha colmato nel software classico tra 2009 e 2015, l’MLOps sta cercando di colmarlo per il machine learning dal 2018 in poi. La differenza chiave: con il software hai codice deterministico e dati di test fissi; con ML hai codice piu’ dati piu’ modello (artefatto binario), tre dimensioni di versioning che evolvono insieme, e una qualita’ del modello che si degrada nel tempo per drift dei dati reali. MLOps e’ la disciplina che mette ordine in questo caos.

In questa guida ti mostriamo, da una prospettiva PMI italiana che non ha un team di 40 ML engineer come Spotify, cos’e’ MLOps, quali sono i suoi pilastri, il maturity model Google/Microsoft, i tool oggi maturi nel 2022 in quattro categorie (experiment tracking, orchestration, serving, monitoring), come affrontare feature store, registry, CI/CD, drift monitoring, governance, la scelta build vs buy, i costi tipici, gli errori che vediamo piu’ spesso e una roadmap a 90 giorni per portare il primo modello in produzione con criterio.

1. Cos’e’ MLOps (e perche’ non e’ “DevOps con i notebook”)

MLOps e’ l’insieme di pratiche, processi e strumenti che industrializza il ciclo di vita di un modello di machine learning, dalla preparazione dei dati al deploy in produzione, fino al monitoring continuo e al re-training automatizzato. Nasce nel 2018 come termine ombrello, viene formalizzato in modo autorevole nel 2020 dal celebre paper Google “MLOps: Continuous delivery and automation pipelines in machine learning” e nel 2021 dalla documentazione Microsoft Azure ML MLOps maturity model.

Spesso si confonde MLOps con DevOps o DataOps. Le differenze sono nette:

• DevOps versiona codice. Test, build, deploy: il binario e’ deterministico, lo stesso input produce sempre lo stesso output.
• DataOps versiona e orchestra dati. Pipeline ETL/ELT, qualita’ dati, lineage, catalog.
• MLOps versiona codice + dati + modello insieme, e aggiunge il fatto che la performance del modello degrada con il tempo perche’ la realta’ cambia.

Concretamente questo significa che un sistema MLOps maturo deve poter rispondere a domande che in DevOps non esistono: “con quali dati e’ stato addestrato il modello in produzione il 12 febbraio?”, “quanto e’ cambiata la distribuzione delle feature di input nell’ultimo mese?”, “il modello e’ ancora meglio della baseline o devo riaddestrare?”. Senza un’infrastruttura pensata apposta, queste risposte semplicemente non esistono.

2. I cinque pilastri MLOps

Indipendentemente dal vendor o dallo stack, ogni pratica MLOps seria si regge su cinque pilastri. Se ne manca anche solo uno, hai un POC, non una pipeline di produzione.

1. Versioning di codice (Git), dati (DVC, lakeFS, Delta Lake time travel) e modelli (model registry MLflow, SageMaker Model Registry, Vertex AI Model Registry).
2. Riproducibilita’: stesso esperimento, stesso ambiente (container Docker, conda env lock-file), stesso seed casuale, stessi dati versionati → stessi risultati a 6 mesi di distanza.
3. CI/CD per ML: ogni commit triggera training, valutazione su test set + gate di performance, packaging, deploy in staging. GitHub Actions, GitLab CI o Jenkins funzionano benissimo.
4. Deployment automatizzato: il modello viene servito come REST o gRPC API senza intervento manuale, con pattern di rollout sicuri (canary, shadow, blue/green).
5. Monitoring continuo: latenza, throughput, distribuzione delle feature in input (data drift), performance del modello rispetto al ground truth (concept drift).

Nelle PMI italiane che vediamo, il pilastro piu’ spesso saltato e’ il quinto. Si deploya il modello, si esulta, e si scopre sei mesi dopo che le previsioni sono diventate spazzatura perche’ nel frattempo i dati di input sono cambiati e nessuno se n’e’ accorto.

3. Il maturity model: dove sei oggi?

Google e Microsoft hanno pubblicato due maturity model molto simili. Quello di Google e’ a tre livelli, quello di Microsoft a cinque (0-4): noi usiamo lo schema Google perche’ e’ piu’ pratico per fare auto-diagnosi.

Livello 0 — Manual process

E’ il punto in cui sta oggi circa il 70% delle PMI italiane che hanno comunque iniziato a fare ML. Il data scientist lavora in Jupyter, salva il modello in pickle, lo passa via email o Slack a un developer che lo carica in un’app Flask, e si va in produzione una volta sola. Niente CI/CD, niente registry, niente re-training, niente monitoring. Quando il modello smette di funzionare lo si nota solo se qualcuno si lamenta.

Livello 1 — ML pipeline automation

La pipeline di training (data validation, prep, feature engineering, train, evaluate, validation del modello) e’ codificata e orchestrata (Airflow, Prefect, Kubeflow Pipelines, Metaflow). Si triggera automaticamente quando arrivano nuovi dati. C’e’ un model registry che traccia ogni versione del modello con metriche e lineage. Il deploy puo’ ancora essere semi-manuale.

Livello 2 — CI/CD pipeline automation

Anche la pipeline stessa e’ versionata in Git e ha la sua CI/CD: ogni modifica al codice di training, alle feature, alle dipendenze passa per test unitari, integration test sulla pipeline, validazione del modello su test set fisso, e solo se tutto e’ verde viene promossa. Il deploy in produzione e’ completamente automatizzato con strategie di rollout sicure. Questo e’ lo stato dell’arte e, onestamente, in Italia nel 2022 e’ davvero raro fuori dai cinque-sei unicorni e da qualche grande gruppo bancario.

L’obiettivo realistico per una PMI nell’arco di 12 mesi e’ arrivare a un solido livello 1 sul caso d’uso piu’ importante, non a un livello 2 teorico applicato a niente.

4. Tool MLOps 2022: 4 categorie, scelte chiare

Lo zoo di tool MLOps nel 2022 e’ impressionante: la celebre MAD landscape di Matt Turck ne conta oltre 1.000 con sovrapposizioni enormi. Per una PMI conviene ragionare per quattro categorie e scegliere un solo tool per categoria.

4.1 Experiment tracking: MLflow vs Weights & Biases vs Neptune.ai

• MLflow (open source Databricks, v1.24 di febbraio 2022): default ragionevole. Self-host con Postgres + S3/MinIO. Tracking, projects, model registry inclusi.
• Weights & Biases: SaaS piu’ raffinato di MLflow su UI, dashboard collaborative, hyperparameter sweep. A pagamento per team. Ottimo se fate molto deep learning.
• Neptune.ai: SaaS focalizzato su metadata, lineage avanzato, confronti di esperimenti.

Per il 90% delle PMI: MLflow self-hosted. Costo zero di licenza, controllo dei dati, integrato con tutti i framework (scikit-learn 1.0, TensorFlow 2.x, PyTorch 1.11, XGBoost, Hugging Face Transformers).

4.2 Orchestration: Airflow vs Prefect vs Dagster vs Metaflow

• Apache Airflow: standard de facto, scheduler battle-tested, enorme ecosistema di operator.
• Prefect (Prefect 2 “Orion”, 2022): API Python piu’ moderna, task dinamici nativi.
• Dagster: asset/dati come cittadini di prima classe, testing migliore.
• Metaflow: da Netflix, focus su ML pipeline, integrazione AWS nativa.

PMI con team dati gia’ su Airflow per ETL: usa Airflow anche per ML. Da zero e con preferenza pythonica: Prefect 2.

4.3 Serving: SageMaker vs Seldon vs BentoML vs Triton vs Flask

• AWS SageMaker Endpoints: managed, scaling automatico. Se sei in AWS, e’ la via piu’ veloce.
• Seldon Core: open source, Kubernetes-native, canary/shadow/A-B nativi, model graph. Curva ripida ma potente.
• BentoML: “Docker per modelli ML”, crea container con REST/gRPC API in 10 righe di Python.
• NVIDIA Triton: il top per deep learning (TensorRT, ONNX) ad alta concurrency su GPU.
• KServe (ex-KFServing): standard Kubernetes per serving, parte di Kubeflow ma usabile da solo.
• Flask/FastAPI custom: si puo’ fare per due-tre modelli, ma versioning, A/B, autoscaling, monitoring vanno scritti a mano. Non scala.

Per una PMI: BentoML senza K8s, Seldon o KServe con K8s, SageMaker se sei in AWS.

4.4 Monitoring: Evidently vs Arize vs Fiddler vs WhyLabs vs Aporia

• Evidently AI: OSS, libreria Python che genera report HTML su data drift (PSI, Wasserstein, chi-square), data quality, performance. Gratis.
• Arize AI: SaaS, dashboard, alerting, lineage. Pricing a volume.
• Fiddler: enterprise, focus su explainability e bias monitoring.
• WhyLabs: basato su whylogs OSS, profili statistici e alerting.
• Aporia: SaaS, monitor configurabili.

Per partire: Evidently OSS come task batch in Airflow che scrive report HTML su S3 e manda alert Slack quando una metrica supera soglia.

5. Feature store: ti serve davvero?

I feature store sono uno degli argomenti piu’ sopravvalutati del 2022. La promessa: un layer centralizzato che calcola feature in batch e streaming e le serve sia al training sia all’inference, risolvendo il training-serving skew.

Le opzioni nel 2022: Feast (OSS standard), Tecton (SaaS), AWS SageMaker Feature Store, Vertex AI Feature Store (GCP, lanciato maggio 2021), Databricks Feature Store integrato in Lakehouse.

Quando ti serve davvero: 5+ modelli in produzione che condividono feature, inference a bassa latenza con feature streaming, vincoli di consistency training/serving non triviali.

Quando non ti serve: 1-2 modelli, feature semplici batch, scoring in CSV notturno. Un buon DWH (Snowflake, BigQuery) o Delta Lake con viste materializzate basta e ti risparmia sei mesi di adozione Feast.

6. Model registry e formati portatili (ONNX, TensorRT)

Il model registry e’ “Git per modelli”: ogni modello promosso ha versione, stage (None → Staging → Production → Archived), metriche, riferimento alla run, e si ricarica con una riga di codice. MLflow Model Registry (incluso in MLflow OSS), SageMaker Model Registry, Vertex AI Model Registry: scegli quello del tuo ecosistema.

Per portabilita’ e ottimizzazione, ONNX e’ il formato standard nel 2022: addestri in PyTorch o TensorFlow, esporti in ONNX, servi con ONNX Runtime su CPU/GPU/edge. NVIDIA TensorRT compila ONNX in kernel CUDA per inference GPU ad alta performance. Per scikit-learn esiste skl2onnx.

7. CI/CD per ML: come si scrive davvero una pipeline

La differenza tra CI/CD software e ML sta nei gate aggiuntivi. Pipeline minima su GitHub Actions:

1. Lint + unit test (pytest, ruff, black).
2. Data validation con Great Expectations o pandera: schema, range, no null.
3. Training run su dataset versionato (DVC pull), metriche su MLflow.
4. Performance gate: se l’AUC del nuovo modello < AUC produzione – 0.5%, fallisci la build.
5. Fairness/bias check: differenza performance tra sottogruppi entro soglia.
6. Promote in registry come “Staging”, smoke test su API in staging.
7. Promote in production con gate umano o canary 5% → 25% → 100% e rollback automatico.

Pattern di deploy che funzionano in PMI:

• Shadow: il nuovo modello riceve il traffico in parallelo, predizioni solo loggate. Zero rischio.
• Canary: 1-5% del traffico al nuovo, rollback se metriche tecniche degradano.
• A/B testing: 50/50 con metriche di business, durata predefinita, decision gate.

8. Drift monitoring: data drift vs concept drift

Un modello in produzione si degrada per tre ragioni:

• Data drift: cambia la distribuzione delle feature di input. Esempio: durante la pandemia 2020-2021 i pattern di traffico web sono cambiati radicalmente e tutti i modelli forecasting addestrati sul 2019 sono diventati inutili. Si misura con Population Stability Index (PSI), Kolmogorov-Smirnov, Jensen-Shannon divergence.
• Concept drift: cambia la relazione feature-target. Un modello anti-fraud impara pattern che i criminali cambiano nel tempo. Si misura con metriche di performance su finestre temporali contro il ground truth.
• Label delay: il ground truth arriva con ritardo (mesi per default creditizio). Si usano metriche proxy o early-warning sugli input.

Setup ragionevole PMI: Evidently in batch giornaliero, soglie PSI > 0.2 (warning) e > 0.3 (alert), report HTML su S3 + alert Slack, ticket Jira automatico se due giorni consecutivi sopra soglia. Costo setup: 2-3 giorni di ML engineer.

9. Governance, lineage, riproducibilita’

Per modelli in domini regolamentati (credito, assicurazioni, sanita’, risorse umane) servono pratiche piu’ formali: model card (concetto Google 2018) con scopo, dataset di training, metriche, limitazioni note; data lineage end-to-end (OpenLineage, Marquez, DataHub); audit log di ogni inference (input hash, versione modello, predizione); approvazione umana sul cambio di modello in produzione per decisioni con impatto sui clienti.

Nel 2022 in Italia la GDPR e’ pienamente applicabile e in particolare l’art. 22 sulle decisioni automatizzate con effetti giuridici impone trasparenza ed esplicabilita’. Avere model card e audit log non e’ un nice-to-have: e’ una difesa concreta in caso di reclami o ispezioni del Garante.

10. Build vs Buy: cloud SaaS o open source self-hosted?

La domanda inevitabile per una PMI: SageMaker/Vertex AI/Azure ML “tutto-in-uno” oppure stack open source su Kubernetes? Vediamo i trade-off concreti.

SaaS cloud (SageMaker, Vertex AI, Azure ML)

Pro: time-to-value di settimane, niente infrastruttura da gestire, integrato con S3/GCS, IAM, monitoring, scaling automatico.
Contro: lock-in vendor, costi che crescono col volume (un endpoint SageMaker ml.m5.large h24 costa ~$150/mese, spesso ne servono piu’ di uno).
Per chi: PMI gia’ su AWS/GCP/Azure, team 1-2 ML engineer, 1-5 modelli.

Open source self-hosted (MLflow + Airflow + Seldon + Evidently su K8s)

Pro: zero licenze, controllo totale, portabilita’, niente lock-in.
Contro: serve un platform engineer dedicato, sicurezza/auth/multi-tenancy fai-da-te.
Per chi: PMI con team DevOps su K8s, vincoli regolatori on-premise, 5+ modelli.

Strada intermedia che funziona: SaaS cloud + MLflow self-hosted come catalogo trasversale degli esperimenti, per non perdere storia se un giorno si cambia cloud.

11. Team, costi e tempi reali per una PMI italiana

Team minimo

• 1 data scientist per statistica, feature engineering, validazione modello.
• 1 ML engineer per pipeline, deploy, monitoring. Spesso il vero discrimine tra POC e produzione.
• 1 platform engineer / DevOps part-time per K8s/cloud, o partner esterno.
• 1 product owner / domain expert dal business che definisce KPI di successo.

Costi tipici 12 mesi

• Piattaforma e setup iniziale: €30.000-€100.000 in base al livello di automazione e in-house vs partner.
• Cloud running: €1.000-€5.000/mese (training on-demand + storage + 2-3 endpoint serving + monitoring).
• Licenze SaaS opzionali: W&B €50-100/seat/mese, Arize/Fiddler da €2.000/mese.
• Personale: data scientist senior €45-70k lordi/anno, ML engineer simile.

Tempi tipici

• POC: 4-8 settimane.
• Primo modello in produzione (livello 1): 3-6 mesi.
• Cultura MLOps stabile con 3-5 modelli: 12-18 mesi.

12. Errori comuni (visti in PMI italiane)

1. Saltare la baseline. Si parte con gradient boosting da 200 feature senza misurare cosa fa una regola business + regressione logistica. Spesso la differenza e’ 2-3 punti che non giustificano la complessita’.
2. Nessuna infrastruttura di test. Il modello viene “testato” runnando un notebook a mano. Niente unit test sulle trasformazioni, niente integration test sulla pipeline.
3. Deploy manuale “una volta sola”. Si carica il pickle in produzione e si dimentica. Sei mesi dopo il modello e’ obsoleto, codice di training perso nel laptop di un collaboratore che ha cambiato azienda.
4. Nessun monitoring. Nessuno guarda i numeri dopo il go-live. Si scopre dal business mesi dopo che “quel sistema di raccomandazione non funziona piu'”.
5. Feature store come prima cosa. Si adotta Feast prima ancora di avere il secondo modello. Sei mesi persi su infrastruttura inutile mentre il caso d’uso resta fermo.
6. Confusione batch vs real-time. Streaming Kafka + Flink per un batch giornaliero che girerebbe in 4 minuti su un nodo solo.
7. Niente ground truth feedback loop. Si fa scoring ma non si raccolgono i risultati reali. Senza ground truth non si misura concept drift ne’ si fa re-training intelligente.

13. Roadmap MLOps a 90 giorni per una PMI

Una roadmap concreta che funziona, testata su clienti reali nel 2021-2022.

Giorni 1-30 — Foundations

• Settimana 1: scelta del caso d’uso pilota con KPI di business chiaro (es. ridurre tasso di abbandono X del 5%). Definizione di una baseline non-ML.
• Settimana 2: setup repository Git, ambiente di sviluppo riproducibile (Poetry o conda lock), MLflow tracking server self-hosted su una VM con Postgres + bucket S3/MinIO.
• Settimana 3: data exploration, validazione dati con Great Expectations, primo training tracciato in MLflow.
• Settimana 4: model registry attivo, model card v1, primo deploy in staging come servizio FastAPI containerizzato.

Giorni 31-60 — Pipeline

• Settimana 5: orchestrazione del training in Airflow o Prefect, DAG schedulato settimanalmente.
• Settimana 6: CI/CD su GitHub Actions con lint, test, performance gate sul modello.
• Settimana 7: deploy in produzione con BentoML o endpoint cloud managed, shadow mode iniziale.
• Settimana 8: switch da shadow a canary 10% → 100% con rollback automatico.

Giorni 61-90 — Monitoring e iterazione

• Settimana 9: Evidently AI in batch giornaliero, report HTML + alert Slack su drift PSI > 0.2.
• Settimana 10: dashboard di business KPI confrontati con quelli pre-modello.
• Settimana 11: feedback loop per ground truth (ETL che porta in DWH le label reali).
• Settimana 12: retrospettiva, prima iterazione del modello, documentazione, knowledge transfer.

A fine giorno 90 hai un primo modello davvero in produzione, monitorato, riaddestrabile, con team che sa cosa fare alla prossima iterazione. E’ molto piu’ valore di sei mesi spesi in POC sequenziali che non vedono mai un utente.

Conclusioni

MLOps non e’ moda da hyperscaler. E’ la disciplina che separa le aziende che fanno valore con i dati da quelle che spendono in data scientist senza vederlo arrivare in P&L. Per una PMI italiana nel 2022 l’approccio giusto e’ iniziare piccoli ma seri: un caso d’uso, pipeline livello 1, monitoring vero, team minimo con ruoli chiari. Lo stack open source maturo (MLflow, Airflow/Prefect, BentoML, Evidently) permette di partire con costi contenuti e senza lock-in. Un modello che resta in un notebook genera zero valore: MLOps colma esattamente quel gap.

HowTo: 5 step per partire con MLOps in PMI

1. Scegli il primo caso d’uso: deve avere KPI di business misurabile, dati gia’ disponibili, sponsor dal business.
2. Setup tracking + registry: installa MLflow self-hosted, traccia ogni esperimento dal giorno 1.
3. Industrializza il training: porta lo script da notebook a modulo Python, container, DAG Airflow/Prefect.
4. Deploy con sicurezza: usa BentoML o un endpoint cloud, parti in shadow, poi canary, poi 100%.
5. Monitora drift e ground truth: Evidently in batch, KPI di business confrontati, retraining schedulato.

FAQ — MLOps per PMI

Quanto costa davvero portare un modello in produzione con MLOps?
Per una PMI italiana, tra €30.000 e €100.000 di setup iniziale piu’ €1.000-€5.000/mese di cloud per il primo modello, a seconda della complessita’ e del livello di automazione voluto.

Posso fare MLOps senza Kubernetes?
Si, soprattutto all’inizio. Una VM Linux con Docker Compose, MLflow, Airflow e BentoML porta lontano per i primi due-tre modelli. Kubernetes diventa interessante quando serve serving ad alta concurrency, multi-tenancy o scaling complesso.

MLflow o un SaaS come Weights & Biases?
MLflow open source self-hosted e’ la scelta default per PMI italiane: zero costi di licenza, totale controllo dei dati, integrazione con tutto. W&B e Neptune offrono UI migliori e ottime feature per deep learning, ma con costi che crescono per team. Si possono anche usare entrambi.

Quando serve davvero un feature store?
Quando hai 5+ modelli in produzione che condividono feature, quando hai bisogno di inference real-time con feature streaming, quando il rischio di training-serving skew e’ alto. Con 1-2 modelli batch, un buon data warehouse e’ sufficiente.

Quanto spesso devo riaddestrare un modello?
Dipende dal caso d’uso e dal drift osservato. Pattern comuni: settimanale per raccomandazioni e ranking, mensile per churn e fraud, trimestrale per credit scoring. La regola d’oro: riaddestra quando il monitoring mostra drift sostenuto, non in base al calendario.

Come misuro il ROI di MLOps?
Confrontando KPI di business pre e post deploy, il numero di modelli in produzione mantenuti da un team a parita’ di sforzo, e il tempo medio dal POC alla produzione. PMI che adottano MLOps riducono tipicamente il time-to-production da 9+ mesi a 2-3 mesi.

MLOps richiede di assumere ML engineer dedicati?
Per cultura solida si, almeno un profilo. Per iniziare un buon software engineer con voglia di imparare ML puo’ coprire il ruolo, soprattutto se affiancato da consulenza specialistica per i primi 3-6 mesi.