Machine Learning nelle imprese: dove genera realmente valore
Il Machine Learning è entrato da tempo nel lessico della trasformazione digitale, ma la sua diffusione nelle organizzazioni non coincide automaticamente con la capacità di generare valore. Un modello può raggiungere metriche tecniche elevate durante la fase di training e produrre comunque un impatto limitato sul business se non viene integrato correttamente nei processi, se i dati non sono sufficientemente affidabili o se il costo necessario per mantenerlo in produzione supera il beneficio economico che riesce a generare.
Nel 2026 questa distinzione è particolarmente importante perché l’adozione delle tecnologie di intelligenza artificiale sta aumentando rapidamente. Secondo Eurostat, nel 2025 circa il 20% delle imprese dell’Unione europea con almeno dieci addetti utilizzava tecnologie AI, con una crescita di 6,5 punti percentuali rispetto al 2024; tra le grandi imprese la quota raggiungeva circa il 55%, mentre tra le PMI si fermava intorno al 19%.
Questi numeri comprendono tecnologie differenti, tra cui text mining, computer vision, speech recognition, natural language generation, machine learning e deep learning, e non possono quindi essere interpretati come misura diretta dell’adozione del Machine Learning tradizionale. Indicano tuttavia una direzione precisa: modelli predittivi, sistemi di classificazione e tecniche di apprendimento automatico stanno entrando progressivamente nei processi aziendali insieme alla nuova generazione di strumenti basati su AI generativa.
La questione per Tech Leader, Data Scientist, Software Architect e responsabili di business non è più quindi stabilire se sia possibile applicare il Machine Learning a un determinato processo, ma comprendere se esista un problema sufficientemente rilevante, misurabile e supportato dai dati da giustificarne l’introduzione.
Dal modello al business case: il valore non nasce dall’accuratezza
Uno dei principali equivoci nei progetti di Machine Learning consiste nel confondere la qualità statistica del modello con il valore prodotto per l’organizzazione.
Accuracy, precision, recall, F1 score, AUC e mean squared error permettono di valutare differenti caratteristiche della performance predittiva, ma nessuna di queste metriche misura direttamente il ritorno economico.
Un modello antifrode, per esempio, può migliorare la capacità di individuare transazioni anomale, ma il beneficio reale dipende dall’ammontare delle frodi evitate, dal numero di falsi positivi prodotti e dal costo operativo necessario per gestire le segnalazioni.
Analogamente, un modello di churn può essere estremamente accurato nell’identificare clienti a rischio di abbandono, ma genera valore soltanto se l’organizzazione possiede un processo efficace attraverso cui intervenire su quei clienti e se il costo dell’azione di retention rimane inferiore al valore economico recuperato.
Il punto di partenza di un progetto ML dovrebbe quindi essere il business case.
Quale decisione deve essere migliorata? Qual è il costo attuale dell’errore? Quanto frequentemente viene presa quella decisione? Quale livello di miglioramento sarebbe economicamente significativo?
Solo successivamente ha senso valutare il modello.
Predictive use case: il Machine Learning è utile quando esiste un pattern sufficientemente stabile
Il Machine Learning produce valore quando il passato contiene informazioni utili per stimare il comportamento futuro.
Questo principio appare semplice, ma delimita in modo significativo il numero di casi d’uso realmente adatti.
Un modello di demand forecasting può funzionare perché vendite storiche, stagionalità, promozioni e variabili esterne contengono pattern che permettono di stimare la domanda futura.
Un sistema di predictive maintenance può utilizzare vibrazioni, temperatura, pressione e storico dei guasti per identificare condizioni associate a una maggiore probabilità di failure.
Un modello di credit scoring può stimare il rischio utilizzando caratteristiche statisticamente collegate alla probabilità di insolvenza.
Se invece il fenomeno è estremamente raro, il contesto cambia completamente o il dataset non contiene informazioni sufficienti a distinguere gli scenari, la capacità del modello può essere limitata indipendentemente dalla sofisticazione dell’algoritmo.
Prima di scegliere una tecnica di ML, quindi, è utile verificare se il problema sia effettivamente apprendibile dai dati disponibili.
Forecasting: valore quando una previsione modifica una decisione operativa
Il forecasting rappresenta uno dei casi d’uso più consolidati del Machine Learning aziendale.
Prevedere domanda, vendite, traffico, utilizzo delle risorse o fabbisogno energetico consente alle organizzazioni di allocare capacità prima che il fenomeno si verifichi.
Nel retail e nella supply chain, per esempio, una previsione più accurata della domanda può contribuire a ridurre contemporaneamente stock-out e sovrastoccaggio.
Il valore economico non deriva dalla previsione in sé, ma dal collegamento con decisioni relative a inventario, acquisti, produzione e distribuzione.
La qualità del modello dovrebbe quindi essere valutata anche sulla base delle conseguenze operative.
Un errore del 10% può essere irrilevante su una categoria a basso valore e produrre invece costi significativi su prodotti caratterizzati da elevata marginalità, lead time lunghi o forte stagionalità.
Il forecasting diventa realmente utile quando la metrica statistica viene tradotta nel costo dell’errore.
Predictive maintenance: utilizzare il dato per spostare la manutenzione prima del guasto
Nel manufacturing e nella gestione degli asset, il Machine Learning viene frequentemente utilizzato per stimare la probabilità di guasto o la remaining useful life di macchinari e componenti.
Il modello può combinare dati provenienti da sensori IoT, log, manutenzione storica e caratteristiche operative per identificare pattern che precedono un failure.
Il beneficio potenziale riguarda soprattutto la possibilità di passare da manutenzione reattiva o rigidamente programmata a interventi maggiormente guidati dalle condizioni effettive dell’asset.
Anche in questo caso, però, il business case deve considerare il costo complessivo.
Installare sensoristica, costruire pipeline dati, addestrare modelli e mantenere l’infrastruttura può essere economicamente giustificato per un asset il cui fermo produce perdite elevate, mentre può risultare sproporzionato per apparecchiature facilmente sostituibili e con costi di downtime limitati.
La sofisticazione tecnologica deve quindi essere proporzionata al valore economico dell’evento che si intende prevenire.
Fraud detection e anomaly detection: intervenire sui pattern che le regole statiche non intercettano
Frodi, intrusioni, anomalie operative e comportamenti irregolari costituiscono un altro dominio nel quale il Machine Learning può produrre un vantaggio significativo.
I sistemi tradizionali rule-based rimangono estremamente utili quando il comportamento anomalo può essere descritto attraverso regole note.
Il Machine Learning diventa interessante quando il numero di variabili cresce, le combinazioni diventano difficili da rappresentare manualmente o il comportamento cambia frequentemente.
Un sistema può utilizzare informazioni relative a importo, posizione, dispositivo, storico dell’utente e sequenza delle operazioni per calcolare un risk score e decidere se una transazione debba essere approvata, bloccata o sottoposta a verifica.
La difficoltà principale riguarda il bilanciamento tra sensibilità e falsi positivi.
Bloccare tutte le operazioni potenzialmente sospette aumenterebbe probabilmente la capacità di intercettare frodi, ma renderebbe il sistema inutilizzabile.
Il valore del modello dipende quindi dal trade-off tra rischio evitato e costo introdotto dal controllo.
Customer analytics: segmentazione e propensione sono utili quando producono azioni differenti
Marketing e CRM rappresentano un altro ambito nel quale il Machine Learning viene utilizzato per segmentazione, recommendation, propensity modeling e churn prediction.
L’obiettivo consiste generalmente nel superare segmentazioni statiche e utilizzare pattern comportamentali per differenziare l’interazione con clienti diversi.
Un modello può, per esempio, stimare la probabilità che un cliente acquisti un determinato prodotto, risponda a una campagna o interrompa la relazione con l’azienda.
Il risultato produce valore se cambia concretamente il trattamento del cliente.
Se tutti gli utenti ricevono comunque la stessa comunicazione, aggiungere un modello di propensione non modifica il processo e introduce prevalentemente un costo tecnologico.
Il principio vale per molti progetti ML: una previsione che non modifica un’azione difficilmente produce valore.
Recommendation systems: il problema non è suggerire, ma modificare il comportamento
I recommendation system sono uno degli esempi più visibili di Machine Learning applicato al business.
Collaborative filtering, content-based recommendation e modelli più avanzati possono utilizzare storico di navigazione, acquisti, preferenze e comportamento di utenti simili per ordinare prodotti o contenuti in funzione della probabilità di interesse.
Per valutare questi sistemi non è però sufficiente misurare quanto precisamente prevedano l’interesse.
Una raccomandazione utile deve produrre un cambiamento incrementale rispetto a ciò che l’utente avrebbe fatto comunque.
Il tema dell’incrementality è quindi centrale.
Un algoritmo che suggerisce sistematicamente i prodotti più popolari può ottenere un elevato click-through rate, ma non necessariamente generare vendite aggiuntive rispetto a una baseline molto più semplice.
La sperimentazione attraverso A/B test rimane per questo uno degli strumenti più importanti per misurare il reale impatto commerciale dei sistemi di recommendation.
Pricing e revenue optimization: il valore aumenta insieme alla qualità delle decisioni ripetute
Il Machine Learning può essere utilizzato anche nella stima dell’elasticità della domanda, nel dynamic pricing e nell’ottimizzazione delle promozioni.
Questi casi d’uso sono particolarmente interessanti quando l’organizzazione prende un numero elevato di decisioni simili.
Una differenza minima nella qualità di una singola previsione può infatti produrre un impatto significativo se viene applicata migliaia o milioni di volte.
La stessa logica riguarda advertising bidding, inventory allocation e routing logistico.
Il valore dell’ML tende a crescere quando una decisione è contemporaneamente frequente, misurabile e sufficientemente standardizzabile.
Queste caratteristiche permettono di ammortizzare il costo di sviluppo e manutenzione del modello su un elevato numero di decisioni.
Process optimization: utilizzare il Machine Learning quando le regole diventano troppo complesse
Molti processi aziendali possono essere automatizzati attraverso regole tradizionali senza utilizzare alcun modello predittivo.
Questo rimane spesso l’approccio preferibile.
Se una decisione può essere descritta con precisione attraverso poche condizioni stabili, un sistema deterministico è più semplice da comprendere, testare e mantenere.
Il Machine Learning diventa interessante quando il numero delle variabili aumenta e le relazioni tra esse risultano difficili da formalizzare manualmente.
La scelta non dovrebbe quindi essere “ML oppure attività manuale”.
Molto spesso il vero confronto è tra Machine Learning e una soluzione software tradizionale.
Un progetto data-driven maturo dovrebbe verificare se il problema possa essere risolto in modo sufficientemente efficace attraverso regole, statistiche semplici o ottimizzazione tradizionale prima di introdurre un modello più complesso.
Automazione decisionale e decision support non sono equivalenti
I sistemi di Machine Learning possono essere integrati nei processi con differenti livelli di autonomia.
Un modello può semplicemente presentare una previsione a un operatore umano, può suggerire un’azione oppure può prendere direttamente una decisione.
La scelta dipende dal rischio.
In processi ad alta frequenza e basso impatto individuale, l’automazione può essere economicamente conveniente.
In contesti critici o regolamentati può essere più appropriato utilizzare il modello come decision support, mantenendo un controllo umano.
Questa distinzione influenza anche i requisiti tecnici.
Un modello che suggerisce una priorità a un operatore può tollerare livelli di errore differenti rispetto a un sistema che blocca automaticamente una transazione o determina autonomamente l’accesso a un servizio.
La metrica di performance dovrebbe quindi essere collegata al livello di autonomia attribuito al modello.
Machine Learning e Generative AI: problemi differenti richiedono tecnologie differenti
L’espansione della Generative AI ha modificato significativamente il modo in cui il mercato parla di intelligenza artificiale, ma Machine Learning tradizionale e modelli generativi non sono soluzioni intercambiabili.
Il Machine Learning supervisionato rimane spesso più appropriato quando l’obiettivo consiste nel prevedere una variabile strutturata, classificare un evento, stimare un rischio o ordinare alternative attraverso un dataset definito.
La Generative AI risulta invece particolarmente efficace su linguaggio, contenuti non strutturati, interazione conversazionale e generazione.
Utilizzare un large language model per prevedere la probabilità di churn su un dataset tabellare può introdurre costi e complessità senza un beneficio rispetto a modelli tradizionali di gradient boosting o regressione.
Allo stesso modo, tentare di risolvere con un modello classificatorio tradizionale un problema di comprensione semantica di documenti complessi può non essere la scelta più efficace.
Nel 2026 la maturità AI consiste anche nella capacità di non utilizzare lo stesso paradigma per qualsiasi problema.
Data readiness: il Machine Learning inizia prima del modello
La qualità dei dati rappresenta uno dei principali fattori che condizionano il risultato di un progetto ML.
Dataset incompleti, label errate, variabili non rappresentative e leakage possono produrre modelli apparentemente performanti durante la sperimentazione e scarsamente affidabili in produzione.
Il lavoro sulla data foundation comprende quindi identificazione delle sorgenti, data cleaning, feature engineering, gestione dei missing value, controllo delle distribuzioni e verifica della qualità delle label.
In molti progetti, questa parte richiede più tempo rispetto alla selezione dell’algoritmo.
Il dato deve inoltre rappresentare il contesto nel quale il modello verrà effettivamente utilizzato.
Addestrare un modello su clienti appartenenti a una specifica area geografica e applicarlo indiscriminatamente a mercati con comportamenti differenti può produrre performance molto diverse da quelle misurate durante la validazione.
La data readiness dovrebbe quindi precedere la model selection.
Baseline first: un modello complesso dovrebbe superare una soluzione semplice
Prima di utilizzare algoritmi complessi è utile costruire una baseline.
Nel forecasting può essere la media storica o il valore del periodo precedente; nella classificazione può essere una regola semplice; nella recommendation può essere la lista dei prodotti più popolari.
La baseline svolge una funzione importante perché permette di verificare se la complessità aggiuntiva produca un miglioramento reale.
Un modello che raggiunge il 90% di accuracy può sembrare efficace, ma se una regola banale raggiunge già l’89%, il beneficio marginale potrebbe non giustificare il costo di addestramento, deployment e monitoring.
La domanda non è quindi se il modello funzioni.
È se funzioni abbastanza meglio dell’alternativa più semplice.
MLOps: portare un modello in produzione è un problema software
Uno dei principali punti di discontinuità nei progetti di Machine Learning emerge tra sperimentazione e produzione.
Un notebook che genera previsioni corrette su un dataset statico non è ancora un sistema enterprise.
Portare un modello in produzione richiede versionamento, pipeline di training, gestione delle feature, artifact repository, deployment, monitoring, rollback e tracciabilità degli esperimenti.
È il dominio comunemente associato al MLOps.
La disciplina applica al Machine Learning principi derivati da DevOps e software engineering, con l’obiettivo di rendere il ciclo di vita del modello ripetibile e governabile.
La necessità di questo livello cresce con il numero di modelli.
Gestire manualmente uno o due modelli può essere possibile; gestirne decine o centinaia senza standardizzazione produce rapidamente un costo operativo significativo.
Model drift: una buona performance iniziale non garantisce stabilità nel tempo
Una caratteristica distintiva dei sistemi ML è la dipendenza dal comportamento dei dati.
Un software tradizionale tende a produrre lo stesso risultato se input e codice rimangono invariati.
Un modello può invece perdere efficacia quando cambia la distribuzione degli input o il rapporto tra variabili e risultato.
Questo fenomeno viene generalmente descritto attraverso concetti come data drift e concept drift.
Un modello antifrode addestrato su comportamenti storici può perdere efficacia quando cambiano le strategie utilizzate dagli attaccanti. Un sistema di forecasting può deteriorarsi dopo una modifica strutturale della domanda.
La gestione del lifecycle richiede quindi monitoring continuo e meccanismi attraverso cui stabilire quando sia necessario rieseguire training, validazione o deployment.
Nel 2026 il NIST ha sottolineato proprio l'importanza del monitoraggio post-deployment dei sistemi AI, osservando come valutazioni eseguite prima del rilascio non siano sufficienti a garantire che il sistema continui a funzionare come previsto in condizioni reali e dinamiche.
Model monitoring: osservare performance, infrastruttura e conseguenze
Monitorare un modello non significa verificare esclusivamente uptime e latency.
Un sistema ML richiede almeno tre livelli di osservazione.
Il primo riguarda l’infrastruttura: disponibilità, errori, tempi di risposta e consumo di risorse.
Il secondo riguarda il comportamento del modello: distribuzione delle feature, distribuzione delle prediction, drift e performance quando è disponibile il ground truth.
Il terzo riguarda l’impatto sul processo: falsi positivi, errori operativi, effetti sui clienti e risultati economici.
La ricerca pubblicata dal NIST nel marzo 2026 evidenzia proprio come il monitoring dei sistemi AI in produzione sia ancora un campo relativamente frammentato, nonostante l’accordo crescente sull’importanza di osservare funzionalità, comportamento operativo e conseguenze inattese dopo il deployment.
La maturità MLOps dipende quindi anche dalla capacità di collegare metriche tecniche e metriche di business.
Explainability: il livello necessario dipende dal rischio della decisione
Non tutti i modelli richiedono lo stesso livello di interpretabilità.
In alcuni casi può essere sufficiente conoscere la performance complessiva e disporre di strumenti per verificare errori e drift.
In altri, il decisore deve comprendere quali variabili abbiano contribuito a una specifica previsione.
Il requisito aumenta nei contesti nei quali una decisione produce conseguenze significative per individui, clienti o processi regolamentati.
La scelta del modello può quindi includere un trade-off tra performance predittiva e interpretabilità.
Un algoritmo più complesso può ottenere risultati marginalmente migliori ma risultare più difficile da spiegare e governare.
La soluzione appropriata dipende dal valore di quel miglioramento rispetto al rischio operativo e normativo introdotto.
AI governance: la gestione del rischio entra nel lifecycle del modello
La crescita dell’adozione rende sempre più importante distinguere tra capacità tecnica e capacità di governance.
Il NIST AI Risk Management Framework struttura la gestione del rischio attraverso quattro funzioni, Govern, Map, Measure e Manage, proponendo un modello attraverso cui le organizzazioni possono identificare contesto, impatti e rischi associati all’utilizzo dei sistemi AI.
La governance del Machine Learning può includere ownership del modello, documentazione, approvazione dei dataset, validazione, gestione degli accessi, criteri di deployment e procedure di rollback.
L’obiettivo non è introdurre necessariamente lo stesso livello di controllo in ogni progetto.
Un modello che suggerisce l’ordine con cui visualizzare prodotti richiede una governance differente rispetto a un sistema utilizzato per supportare decisioni finanziarie o sanitarie.
Il principio rimane risk-based.
Build vs buy: non tutti i casi d’uso richiedono un modello proprietario
L’evoluzione del mercato rende disponibile un numero crescente di servizi AI e ML preconfigurati.
OCR, speech recognition, image classification, recommendation, fraud detection e forecasting possono essere affrontati attraverso prodotti cloud, API o piattaforme SaaS senza addestrare necessariamente un modello proprietario.
Questo introduce una decisione build vs buy.
Costruire internamente può essere utile quando il modello rappresenta una capability distintiva, il dataset costituisce un vantaggio competitivo o il caso d’uso presenta caratteristiche non gestite dalle soluzioni standard.
Acquistare un servizio può essere più razionale quando il problema è comune e il valore competitivo deriva dal processo che utilizza il modello piuttosto che dal modello stesso.
Anche l’OECD rileva nel 2026 che, soprattutto tra le PMI, l’adozione dell’AI avviene in larga misura attraverso strumenti off-the-shelf, mentre l’integrazione strategica e personalizzata rimane più disomogenea; maintenance cost, tempo e skill gap continuano inoltre a rappresentare ostacoli rilevanti.
Cost of ownership: training è soltanto una parte del costo
Il costo di un sistema ML non coincide con il tempo necessario per addestrare il modello.
Devono essere considerate data collection, storage, preprocessing, feature engineering, sviluppo, infrastruttura, inference, monitoring, retraining, governance e competenze necessarie per mantenerlo.
Nei modelli più complessi può diventare rilevante anche il costo computazionale.
Per questo il ritorno deve essere valutato lungo il ciclo di vita. Un modello può generare un risparmio di 100.000 euro all’anno e richiedere 150.000 euro tra sviluppo e gestione. Tecnicamente può funzionare perfettamente. Economicamente può non rappresentare la scelta migliore.
Human-in-the-loop: utilizzare l’ML per aumentare la capacità dell’operatore
Un modello non deve necessariamente sostituire una decisione umana per generare valore.
In molti casi l’applicazione più efficace consiste nel prioritizzare, classificare o arricchire le informazioni disponibili agli operatori.
Un sistema di anomaly detection può ordinare migliaia di eventi per probabilità di rischio, consentendo al team di concentrarsi su un sottoinsieme più rilevante.
Un modello di lead scoring può supportare il commerciale nel determinare quali opportunità analizzare per prime.
Il beneficio deriva quindi dall’aumento della capacità decisionale dell’operatore e non dalla completa automazione.
Questo modello può essere particolarmente utile quando il giudizio umano rimane importante ma la quantità di informazioni supera la capacità di analisi manuale.
Experimentation: misurare l’impatto causale, non soltanto la correlazione
Un modello può essere correlato a un miglioramento senza esserne necessariamente la causa.
Per questo, nei casi in cui sia possibile, sperimentazione e A/B testing rappresentano strumenti importanti per valutare il valore reale.
Se un recommendation system viene introdotto contemporaneamente a una nuova promozione commerciale, osservare un aumento delle vendite non permette di stabilire quale dei due interventi abbia generato il risultato.
Un test controllato consente invece di confrontare gruppi esposti e non esposti al nuovo modello.
La misurazione causale diventa particolarmente importante quando l’obiettivo consiste nel dimostrare il ritorno dell’investimento.
Quando il Machine Learning non è necessario
Una strategia matura dovrebbe includere anche la capacità di riconoscere i casi in cui non utilizzare Machine Learning. Se il processo può essere descritto attraverso poche regole stabili, un sistema deterministico può risultare più economico e facilmente interpretabile.
Se il dataset è troppo limitato o non rappresentativo, il modello potrebbe non generalizzare.
Se il risultato non modifica alcuna decisione, la previsione rischia di rimanere un esercizio analitico.
Se il costo dell’errore è molto elevato e non esistono controlli sufficienti, l’automazione può essere prematura.
Infine, se l’organizzazione non possiede processi per monitorare e aggiornare il modello, il valore iniziale può deteriorarsi rapidamente.
Il criterio non dovrebbe quindi essere quanto un caso d’uso sia tecnicamente interessante.
Dovrebbe essere quanto sia economicamente sostenibile.
Machine Learning nel 2026: dal proof of concept alla capability operativa
Il passaggio più importante per le imprese non consiste nell’aumentare il numero di proof of concept, ma nel trasformare i casi d’uso efficaci in capability operative.
Questo richiede un collegamento continuo tra business, data engineering, data science, software engineering e operations.
Il dato deve essere disponibile e governato, il modello deve essere validato, il deployment deve essere ripetibile e il comportamento in produzione deve poter essere osservato.
L’adozione crescente dell’AI rende questa capacità ancora più rilevante.
Nel 2025 il 20% delle imprese europee utilizzava già almeno una tecnologia AI, ma la distanza tra sperimentazione e integrazione strategica rimane significativa, soprattutto nelle organizzazioni di dimensioni minori.
Il valore del Machine Learning emerge quindi quando il modello diventa parte stabile di un processo decisionale o operativo.
Non basta che produca una previsione accurata.
Deve riuscire a farlo nel momento giusto, con dati sufficientemente affidabili, a un costo sostenibile e con un livello di rischio compatibile con il contesto.
Dal modello al risultato economico
Il Machine Learning continua a rappresentare una delle tecnologie più rilevanti per l’automazione e la capacità predittiva delle imprese, ma il suo valore non deriva dalla sofisticazione dell’algoritmo.
Forecasting, predictive maintenance, fraud detection, recommendation, customer analytics e process optimization possono generare ritorni significativi quando esiste un problema misurabile, i dati contengono informazioni sufficientemente predittive e l’output del modello modifica realmente una decisione.
La stessa tecnologia può invece produrre un ritorno limitato quando viene applicata a processi poco frequenti, scarsamente misurabili o privi di una data foundation adeguata.
Nel 2026 il tema diventa ancora più importante perché Generative AI e strumenti off-the-shelf hanno ridotto significativamente la barriera tecnica all’utilizzo dell’intelligenza artificiale, ma non hanno eliminato il problema fondamentale della creazione di valore.
Un sistema AI può essere semplice da acquistare, integrare o sperimentare e continuare a non produrre un risultato economico rilevante.
Per Tech Leader e partner IT, quindi, la domanda più utile non è “dove possiamo applicare il Machine Learning?”, ma “quale decisione o processo presenta abbastanza valore, dati e ripetibilità da rendere conveniente l’introduzione di un modello?”
È questa distinzione che separa un progetto tecnologicamente interessante da una capability capace di produrre valore sostenibile per il business.
Fonti citate:
- Eurostat. (2026). The use of artificial intelligence technologies in the European Union: Key results, 2026 edition. European Commission.
- Eurostat. (2025). 20% of EU enterprises use AI technologies. European Commission.
- National Institute of Standards and Technology. (2023). Artificial Intelligence Risk Management Framework (AI RMF 1.0). NIST AI 100-1.
- National Institute of Standards and Technology. (2026). Challenges to the Monitoring of Deployed AI Systems. NIST AI 800-4.
- National Institute of Standards and Technology. (2026). AI Risk Management Framework. NIST.
- OECD. (2026). Empowering SMEs in the age of AI: The 2026 OECD D4SME Survey. OECD SME and Entrepreneurship Papers, No. 78. OECD Publishing.
Autore: Martina Pegoraro
