Strategia AI: Build vs. Buy nelle PMI

KI-Strategie · 23. Mai 2026 · Mohsen Ghulami

Strategia AI nelle PMI: Decidete Build vs. Buy con numeri, casi e criteri chiari, prima che il vostro PoC divori il budget.

Tre settimane fa, mi trovavo a Gütersloh in una sala riunioni che sapeva di caffè filtro e plastica calda. Thomas, CTO di un'azienda di ingegneria meccanica con 280 dipendenti, mi ha spinto il suo iPad e ha detto: "Ora costruiremo la nostra piattaforma AI." Nel cortile, un carrello elevatore in retromarcia emetteva un segnale acustico, mentre all'interno una diapositiva PowerPoint con il logo Azure, il serpente Python e un blocco di budget di 1,2 milioni di euro lampeggiava. La mia prima domanda non è stata tecnica, ma brutalmente semplice: è davvero una strategia AI, o solo una costosa deviazione verso il prossimo software standard?

Scrivo di industria dal 1998. Ho visto alla Trumpf di Ditzingen come i dati delle macchine da taglio laser si trasformano in un business di servizi. Ho sperimentato in piccole aziende di subfornitura nello Giura Svevo come una singola esportazione MES mancante possa bloccare un intero progetto AI. E ho visto abbastanza CFO che, alla parola "sviluppo interno", stringono le labbra come se avessero morso un limone.

Build vs. Buy nell'AI non è quindi una questione di fede. È una questione di allocazione del capitale. Chi, come PMI con 50-500 dipendenti, vuole costruire ogni modello di previsione da solo, brucia tempo, stipendi e nervi. Ma chi acquista ogni funzione AI, anche se fa la differenza nel proprio prodotto, regala margini a fornitori che non capiscono il business. Ho visto entrambi i casi. Entrambi fanno male.

Perché la strategia AI diventa ora una questione di alta direzione

Nel marzo 2025, ero presso un fornitore vicino a Heilbronn, 410 dipendenti, molta lavorazione meccanica, poca pazienza. Andrea, Head of Operations, mi ha mostrato una linea con sei centri di lavoro DMG Mori. Il rumore era quel canto metallico e duro che si sente nelle fabbriche dove nessuno parla del futuro perché l'ordine deve essere spedito entro venerdì. "Abbiamo quattro PoC AI", ha detto Andrea. "Nessuno è in produzione."

È proprio qui che si trova il Mittelstand. Non all'inizio del dibattito sull'AI, ma dopo la prima disillusione. ChatGPT ha aperto la porta nel 2023, Microsoft Copilot è arrivato in molte aziende, SAP sta spingendo le funzioni AI nella suite, e ogni secondo fornitore di software ora appone un'etichetta AI sulla sua roadmap. Solo che: in fabbrica, nelle vendite, nel servizio, succede meno di quanto affermano i palcoscenici delle conferenze.

I numeri corrispondono a questa osservazione. Secondo lo studio Bitkom 2024, circa il 15-20 percento delle aziende tedesche utilizza l'AI in modo produttivo; nelle aziende tra 100 e 499 dipendenti, la percentuale è piuttosto nella fascia bassa, circa il 10-15 percento. BCG e VDMA nel 2023 hanno riscontrato nel settore dell'ingegneria meccanica un modello che sento costantemente nelle conversazioni: più del 60 percento sperimenta con PoC AI, ma meno del 15 percento ha applicazioni scalate in azienda. Quindi: molti piloti, poca operatività.

Questa non è una legge naturale tedesca. Spesso è una cattiva decisione. Le PMI trattano troppo spesso l'AI come un acquisto tecnologico e troppo raramente come una questione di creazione di valore. In un'azienda di Augusta con 180 dipendenti, Jens, direttore commerciale, mi ha detto nel gennaio 2025: "Non possiamo permetterci errori." Vero. Ma non decidere è anche un errore. Solo più silenzioso.

Strategia AI nelle PMI: cosa significa realmente Build vs. Buy

Build non significa che tre Data Scientist addestrano un modello fondamentale in cantina. Beh, quasi mai. Build nelle PMI significa solitamente: proprie pipeline di dati, propri modelli o almeno propria logica di dominio, propri processi MLOps, proprio monitoraggio, propria responsabilità. Il fornitore può fornire l'infrastruttura cloud, ma l'azienda si assume il rischio di prodotto e operativo.

Buy non significa che si acquista un software e il lunedì si risparmia il 15 percento di scarti. Chi crede questo non ha mai visto un'interfaccia tra un vecchio ERP, un'esportazione Excel e il controllo macchina. Buy significa: acquistare software standard, SaaS o componenti di piattaforma, configurare, integrare, formare, misurare. È lavoro. Ma è un lavoro diverso dalla costruzione di modelli.

Il confine più netto non è tra Cloud e On-Prem. È tra commodity e differenziazione. Forecasting, NLP standard, classificazione delle immagini, ottimizzazione dei percorsi, assistenza alle offerte, semplici motori di raccomandazione – per questo ci sono prodotti utilizzabili. AI nel core del prodotto, come sensori intelligenti, navigazione autonoma, controllo di processo proprietario o un algoritmo di servizio che impara da 15 anni di dati macchina – qui Build può avere senso. Può. Non deve.

PwC e Roland Berger descrivono dal 2023 un modello che emerge anche nelle mie conversazioni: le PMI più piccole e medie utilizzano prevalentemente Buy o Configure, le PMI più grandi scelgono più spesso Hybrid. L'azienda da 300 persone acquista più probabilmente Microsoft, SAP, Cognex, Celonis, o9, PTC o un fornitore specializzato. Il fornitore da 3.000 persone potrebbe costruire un Analytics Competence Center e sviluppare dove si trova il valore aggiunto. Sembra banale. Ma viene costantemente ignorato.

I numeri reali: costi, tempistiche, tassi di successo

Negli ultimi due anni ho parlato a Monaco, Stoccarda, Bielefeld e Linz con responsabili digitali che gestiscono i loro budget AI non nei comunicati stampa, ma in Excel. Le fasce sono sorprendentemente stabili. Un PoC Build nelle PMI costa solitamente tra 100.000 e 300.000 euro per tre-sei mesi. Fino a quando un MVP non è operativo, 300.000-800.000 euro sono realistici, i costi del personale interno non sempre calcolati in modo pulito. Ed è proprio qui che inizia l'autoinganno.

Perché il Data Scientist non è gratuito solo perché è già sul libro paga. Nemmeno l'ingegnere di produzione che controlla le etichette per otto ore a settimana. E tanto meno l'architetto IT che si occupa delle autorizzazioni di sicurezza. In una fabbrica vicino a Ulm, nel febbraio 2025, c'era odore di lubrificante di raffreddamento, mentre Martin, responsabile IT, mi diceva: "Esternamente abbiamo speso solo 180.000 euro." Due ore dopo mi ha mostrato la stima dei costi interni. Con il lavoro interno, il progetto ammontava a 520.000 euro.

Buy o Configure inizia più in basso. Licenza pilota più integrazione: spesso 50.000-250.000 euro. Rollout su più stabilimenti o aree: 150.000-800.000 euro. I costi di licenza correnti per molti scenari di PMI sono di 50.000-200.000 euro all'anno, a seconda degli utenti, del volume di dati e dell'umore del fornitore. Sì, l'umore del fornitore. Chi ha mai negoziato un rinnovo SaaS al terzo anno di contratto sa cosa intendo.

I tassi di successo sono il vero colpo al cuore. McKinsey ha riferito nel suo State of AI 2023 che solo circa il 20-30 percento delle aziende ottiene significativi vantaggi finanziari dai progetti AI. Nel settore manifatturiero e dei beni industriali, secondo la mia esperienza e i benchmark dei consulenti, il 50-70 percento dei PoC muore prima di vedere una vera operatività. Con Build, spesso solo il 30-40 percento riesce a passare alla produzione. Con Buy o Configure, piuttosto il 50-70 percento. Non perché i fornitori facciano magie. Ma perché c'è meno rischio di base nel modello.

Build conviene — ma meno spesso di quanto affermano le slide di presentazione

Mi piace lo sviluppo interno. Davvero. C'è quel momento in cui un team non solo addestra un modello, ma lo integra in un processo, gli utenti lo toccano, l'indicatore si muove e il direttore di fabbrica non parla più di "quella cosa AI", ma del suo nuovo strumento. È potente. Ma non succede solo perché qualcuno ha installato PyTorch.

Trumpf è un buon esempio, ma anche un avvertimento. L'azienda familiare di Ditzingen ha circa 16.500 dipendenti, dati macchina profondi, una propria storia di piattaforme con AXOOM e un ecosistema attorno a TruConnect. Dal 2017 circa, Trumpf investe continuamente in servizi digitali, manutenzione predittiva e funzioni di Smart Factory. Nelle presentazioni pubbliche, Trumpf parla di una riduzione dei tempi di fermo macchina fino al 20-30 percento per determinati impianti grazie alla manutenzione predittiva. Questo non è un progetto secondario dell'IT. Questo è un business di prodotti e servizi.

Kärcher di Winnenden è altrettanto interessante. Il KIRA B 50, un robot di pulizia autonomo, richiede visione artificiale, navigazione, fusione di sensori e software robusto nel prodotto fisico. Un recommender standard dal cloud serve a poco. Kärcher ha sviluppato competenze digitali dal 2018 circa, anche nell'Hub Digitale, e combina lo sviluppo interno con componenti cloud. Qui Build non è prestigio. L'AI è nel dispositivo, nel prezzo, nel contratto di servizio.

Questo è il punto: Build conviene quando l'AI cambia il valore per il cliente o mappa un processo che i concorrenti non possono semplicemente copiare. Un produttore di macchine utensili con miliardi di dati storici di sensori ha una situazione di partenza diversa da un grossista di 220 persone che vuole migliorare il cross-selling nel webshop. Chi confonde queste differenze, mette il carro davanti ai buoi.

Sviluppiamo internamente solo dove vediamo un chiaro vantaggio competitivo e la nostra conoscenza del processo o del prodotto è unica. Acquistiamo analytics standard e modelli linguistici.

— in sintesi da un CDO di un'azienda tedesca di ingegneria meccanica, conversazione Handelsblatt 2024

Nicole Büttner di Merantix Momentum ha sottolineato qualcosa di simile nei formati EY su "Zukunft Deutschland": le PMI hanno un vantaggio con i propri dati, ma dovrebbero spesso acquistare modelli e piattaforme e padroneggiare la logica di dominio internamente. Sottoscrivo. I dati da soli non sono una barriera. Solo quando dati, conoscenza del processo e canale di distribuzione si uniscono, Build diventa interessante.

Buy-first non è una capitolazione, ma disciplina

A Münster, nel novembre 2024, ho incontrato un manager della logistica, Ralf, che in passato aveva partecipato a progetti di previsione presso Fiege. Eravamo in una mensa, c'era odore di salsa arrosto, e dal magazzino proveniva quel sordo rumore di nastri trasportatori. "Avremmo potuto costruire tutto da soli", ha detto. "Ma per cosa?" Fiege utilizza servizi cloud, componenti Azure e soluzioni partner in diverse aree, ad esempio per previsioni e ottimizzazione. I casi d'uso pubblicati parlano di una riduzione delle scorte del 2-5% e di una migliore accuratezza delle previsioni del 3-8%, a seconda del campo.

Questa è la realtà delle PMI, solo un po' più grande. Una previsione è raramente unica. Nemmeno un'ottimizzazione del percorso. Un controllo qualità basato su immagini con una classe di errore definita è tecnicamente impegnativo, ma spesso non è un motivo per creare un proprio team di visione. Cognex, Landing AI, Microsoft Custom Vision, Siemens Industrial Edge, PTC ThingWorx o fornitori specializzati hanno i loro difetti. Certo. Ma non partono da zero.

Un caso anonimo dalla Germania meridionale mostra la logica in modo pulito. Produttore di macchine, 800 dipendenti, ispezione visiva manuale, carenza di personale, alta pressione di rilavorazione. L'azienda ha acquistato un sistema commerciale di Vision AI invece di svilupparlo internamente. Investimento iniziale: circa 350.000 euro per hardware, licenze, integratore e formazione. Quattro mesi di PoC, tre mesi di rollout su due linee. Dopo dodici mesi, il tasso di errore era inferiore di circa il 30%, ammortamento in meno di 18 mesi. Nessun premio per l'innovazione. Ma denaro.

So che Buy suona troppo piccolo per alcuni CTO. Non si vuole solo "configurare". Si vuole creare. Comprensibile. Solo che il cliente non paga per l'orgoglio del reparto IT. Paga per la capacità di consegna, la qualità, il servizio, la stabilità dei prezzi. Se il software standard offre l'80% del beneficio in un terzo del tempo, allora lo sviluppo interno è spesso vanità con pianificazione sprint.

La seconda verità: Buy può diventare costoso, lento e pericoloso

Ora l'autocorrezione. Buy-first non significa Vendor-first. Ho visto progetti SaaS che dopo due anni sembravano un appartamento in affitto dopo dieci subaffittuari: adattatori ovunque, nessuno sa più a chi appartiene la chiave. Un fornitore di 260 persone dalla Bassa Baviera nel 2024 ha pagato licenze moderate per tre strumenti legati all'AI nelle vendite, nel servizio e nella pianificazione. Insieme a interfacce, consulenza e amministratori interni, i costi annuali sono saliti improvvisamente a 310.000 euro. Beneficio? Difficile da misurare. "Ora abbiamo dashboard", ha detto il responsabile vendite. Ho avuto pietà di lui.

Il più grande errore di Buy è la cieca fiducia nelle funzionalità. Una demo software mostra sempre dati puliti. Sempre. Nel funzionamento reale, si incontrano clienti duplicati, gerarchie di articoli mancanti, modelli di turni divergenti e un campo ERP chiamato "Altro" che dal 2009 contiene tutto ciò che nessuno voleva classificare. SAP, Microsoft, Siemens o PTC possono ammortizzare molto. Ma non riparano un'organizzazione che disprezza i suoi dati anagrafici.

Il secondo errore è il lock-in senza controvalore. Se un fornitore controlla l'intera gestione dei dati, la logica del modello, l'interfaccia utente e l'integrazione dei processi, l'azienda diventa dipendente. Questo può essere accettabile se il caso d'uso è una commodity e il fornitore offre un servizio stabile. Per i processi critici, si dovrebbe essere più cauti. Esportazione dei dati, auditabilità, costi di scalabilità, scenario di uscita – argomenti noiosi, sì. Proprio per questo vengono letti troppo tardi.

Dove i progetti Build muoiono nelle PMI

C'è una scena che si ripete. Sala riunioni, moquette grigia, lavagna con i resti di un workshop, da qualche parte c'è ancora scritto "Prioritizzazione dei casi d'uso". Nella stanza ci sono IT, reparto specialistico e un consulente esterno. Dopo 14 mesi di progetto, qualcuno chiede: "Chi è il Product Owner?" Poi cala il silenzio. L'ho visto a Colonia, Norimberga e San Gallo.

La prima causa di morte è la qualità dei dati. Non sexy, ma letale. Un fornitore automobilistico con circa 3.000 dipendenti ha avviato diversi PoC di manutenzione predittiva per oltre tre anni, in collaborazione con un istituto di ricerca. Costo: oltre un milione di euro, inclusi i tempi interni. Tutti i piloti sono rimasti bloccati in singoli impianti. OT e IT erano separati, non c'era un Lakehouse centrale, la manutenzione era stata coinvolta tardi e la cronologia dei dati non corrispondeva alla logica dei guasti. Dopo un cambio nella direzione IT, si è passati a una piattaforma standard. Nove mesi dopo, i primi casi d'uso produttivi erano operativi, dopo 18 mesi sono stati segnalati circa il 15 percento in meno di guasti non pianificati su impianti selezionati.

La seconda causa di morte è il falso orgoglio. Un rivenditore B2B della regione DACH con circa 1.200 dipendenti voleva costruire un proprio motore di raccomandazione, anche per ridurre la dipendenza dalle piattaforme cloud statunitensi. Team di Data Science di cinque persone, Python, Scikit-Learn, poi TensorFlow. Diciotto mesi di sviluppo, circa 1-1,5 milioni di euro. Alla fine, le prestazioni, secondo i test interni, erano solo del 60-70 percento rispetto a un recommender cloud standard. Il progetto è stato interrotto, la soluzione SaaS è arrivata comunque. Solo più tardi e più costosa.

La terza causa di morte è la mancanza di pensiero di prodotto. L'AI viene avviata come progetto, non gestita come prodotto. C'è un PoC, un rapporto finale, applausi nel comitato direttivo. Poi il modello va alla deriva, nessuno misura il tasso di utilizzo, nessuno pianifica il retraining, nessuno si sente responsabile per i falsi allarmi. Dopo sei mesi, il capoturno dice: "Questa cosa è impazzita." E l'accettazione è già sparita.

MLOps qui non è una parola d'ordine, ma un lavoro di manutenzione per i modelli. Monitoraggio, versionamento dei dati, processi di rilascio, rollback, responsabilità, traccia di audit. Sembra noioso. E lo è. Ma senza queste routine, l'AI diventa un software usa e getta. Si costruisce, si mostra, si dimentica.

La matrice Build-vs.-Buy per una strategia AI robusta

Nelle conversazioni, mi piace usare una semplice matrice 2x2. Nessuna magia. Sull'asse X c'è il potenziale di differenziazione: questa funzione AI ci rende più difficili da copiare sul mercato? Sull'asse Y c'è la standardizzabilità: esiste un software maturo che copre il 70-80% del compito? Se entrambi gli assi vengono valutati onestamente, molti progetti preferiti falliscono.

Quadrante uno: alto potenziale di differenziazione, bassa standardizzabilità. Qui si può seriamente considerare Build o Co-Build. Esempi: AI in un dispositivo medico con sensori speciali, funzioni autonome in una macchina per la pulizia, controllo di processo in un proprio processo di produzione. Kärcher, Trumpf, Wittenstein o Festo pensano in queste categorie. L'AI è vicina al prodotto o al segreto di processo.

Quadrante due: basso potenziale di differenziazione, alta standardizzabilità. Comprare. Punto. Forecasting standard, classificazione del testo nel servizio clienti, chatbot semplici, verifica delle spese, lead scoring, ispezione delle immagini con difetti noti. Chi qui predica Build dovrebbe mettere sul tavolo i costi opportunità. Non come una slide. Come importo in euro.

Quadrante tre: alto potenziale di differenziazione, alta standardizzabilità. Questa è l'emozionante area ibrida. Un LLM può generare bozze di offerte, ma la propria logica di prodotto, le regole di sconto, la capacità di consegna e le clausole di responsabilità devono provenire dall'azienda. Microsoft Copilot o SAP Joule possono fornire interfacce, ma il cervello aziendale risiede nel proprio modello di dati. È proprio lì che le PMI dovrebbero sviluppare competenze.

Quadrante quattro: basso potenziale di differenziazione, bassa standardizzabilità. Di solito un segnale di avvertimento. Se qualcosa non è strategicamente importante né facilmente acquistabile, perché farlo? Perché un responsabile di reparto lo vuole? Perché c'è un programma di finanziamento? I fondi di finanziamento non sono un business case. Non c'è scampo.

Calcolo del ROI: perché un inizio più economico può finire per essere costoso

Nel giugno 2025, un amministratore delegato di Ravensburg mi ha chiamato. 120 dipendenti, costruzione di macchine speciali, un buon EBIT, ma un IT sottile. Ha chiesto: "Quanto ci costa un'AI per l'automazione delle offerte?" Ho risposto: "Quanto costa un'offerta oggi?" Silenzio. Poi un fruscio di carte. Poi il numero: circa 1.800 euro di costi interni per macchine complesse, se sono coinvolti vendite, progettazione e acquisti.

Solo con questi numeri il Build vs. Buy diventa tangibile. Se un'azienda scrive 900 offerte complesse all'anno e un sistema di assistenza AI riduce il tempo di elaborazione del 25 percento, non stiamo parlando di un giocattolo. Stiamo parlando di capacità, reazione più rapida, meno errori nelle distinte base, migliore tracciabilità. Se la soluzione è acquistata, costruita o ibrida, si decide in base al Payback, non all'istinto del CTO.

Confronto settoriale: ingegneria meccanica, commercio, logistica, automotive

L'ingegneria meccanica è seducente per il Build. Le aziende hanno fiducia nelle proprie capacità tecniche, molti ingegneri, buoni dati di prodotto e spesso una cultura del "fai da te". Per DMG Mori, Trumpf, Wittenstein o Festo, questo approccio ha senso per le funzioni AI vicine al prodotto. Per un costruttore di impianti di 180 persone dell'Alta Franconia che vuole costruire una propria AI testuale per i rapporti di servizio, piuttosto no. L'odore dell'olio idraulico non rende un modello NLP proprietario.

Il commercio e la distribuzione B2B dovrebbero quasi sempre pensare Buy-first. Raccomandazione, prezzi, previsione delle scorte, cluster di clienti, controllo delle campagne – questi sono campi con molti fornitori e molta esperienza. La differenziazione lì non risiede tanto nell'algoritmo quanto nella qualità dei dati, nella logica dell'assortimento, nelle condizioni di acquisto e nell'esecuzione delle vendite. Un commerciante di Essen mi ha detto nell'aprile 2025: "Volevamo replicare la logica di Amazon da soli." Ho chiesto: "Perché non vendere prima come Amazon?" Non ha riso.

La logistica è più pragmatica. Forse perché ogni punto percentuale si traduce immediatamente in pallet, chilometri e turni. Fiege, Dachser o Rhenus lavorano con piattaforme, partner e team interni dove è opportuno. Buy per l'ottimizzazione standard, Build o Co-Build per dati di rete speciali e pianificazione personalizzata. Il pavimento del magazzino decide. Non il reparto strategico.

I fornitori automobilistici si trovano tra due fuochi. Hanno volumi, pressione sulla qualità, requisiti di tracciabilità e specifiche OEM. La qualità predittiva, la manutenzione, l'ispezione visiva e l'AI di pianificazione sono attraenti. Ma molti stabilimenti sono cresciuti storicamente, i dati OT sono frammentati e il consiglio di fabbrica vuole essere consultato in anticipo. Chi lì avvia Build senza una piattaforma dati, finisce nella palude dei PoC. L'ho visto troppo spesso.

Caso pratico: 320 dipendenti, 14 mesi, un ibrido onesto

Un caso che posso raccontare in forma anonima: produttore di componenti del Baden-Württemberg, 320 dipendenti, fatturato di quasi 75 milioni di euro, clienti nel settore dell'ingegneria meccanica e della tecnologia medica. Ero lì nell'ottobre 2024. Nel controllo qualità c'era odore di detergente alcolico, sotto una lampada a LED c'erano pezzi fresati in vassoi grigi. Sabine, responsabile qualità, ha detto: "Perdiamo tempo perché vediamo gli errori troppo tardi."

L'azienda aveva tre idee AI: Vision AI per il controllo qualità, Forecasting negli acquisti, assistenza alle offerte per pezzi speciali. In passato, probabilmente avrebbero avviato tre PoC. Questa volta no. L'amministratore delegato ha fatto passare ogni idea attraverso la matrice. Vision AI: Buy. Forecasting: Buy/Configure. Assistenza alle offerte: Ibrido, perché la logica di fattibilità tecnica e le regole delle varianti erano davvero interne all'azienda.

I numeri dopo 14 mesi: il pilota Vision-AI per due famiglie di pezzi è costato circa 210.000 euro, inclusi telecamera, illuminazione, integratore e formazione. La percentuale di errori è diminuita del 28%, la rilavorazione dell'11%. Il Forecasting è stato introdotto tramite un modulo del partner ERP esistente più una pipeline di dati esterna, costo circa 95.000 euro; l'accuratezza delle previsioni è aumentata nei pezzi A di 6 punti percentuali. L'assistenza alle offerte è costata di più: circa 380.000 euro, perché sono stati integrati CPQ, regole CAD-vicine e storici dei prezzi. In cambio, il tempo medio di elaborazione delle offerte complesse è diminuito da 9,5 a 6,8 giorni lavorativi.

Più importanti dei singoli numeri era la governance. C'era un Product Owner per ogni caso d'uso, una visione mensile dei KPI, chiari criteri di interruzione e un piccolo nucleo di dati: un Data Engineer, una Analytics Engineer, un architetto esterno per sei mesi. Nessun laboratorio AI con pouf. Nessun circo dell'innovazione. Solo lavoro.

Amplifa ICP Playbook Playbook pratico per definire in modo pulito clienti target, fonti di dati e priorità prima che l'AI nelle vendite o nella generazione di lead bruci denaro.

FAQ: Quando una PMI dovrebbe costruire l'AI da sola?

Una PMI dovrebbe costruire l'AI da sola se sono soddisfatte contemporaneamente tre condizioni: la funzione crea differenziazione per il cliente, i dati necessari sono proprietari e affidabili, e l'azienda può finanziare l'operatività, il monitoraggio e lo sviluppo continuo. Se manca una di queste condizioni, permetterei il Build solo con un partner e una rigida linea di arresto. Un esempio: la diagnostica intelligente dello stato per le proprie macchine con dati di sensori esclusivi può giustificare il Build. Un chatbot standard per le richieste di servizio no.

FAQ: Qual è la migliore strategia AI per 50-500 dipendenti?

Per le aziende tra 50 e 500 dipendenti, una strategia ibrida buy-first è solitamente la scelta migliore. Software standard per casi d'uso commodity, logica di dominio propria per processi differenzianti, un piccolo team interno per i dati e la responsabilità del prodotto. Questo suona meno eroico di "costruiamo la nostra piattaforma". Funziona più spesso. Secondo Bitkom 2024, l'uso produttivo dell'AI nelle PMI tedesche è ancora basso; proprio per questo il Time-to-Value conta più dell'orgoglio tecnico.

FAQ: Come evitare la trappola del PoC nell'AI?

Si evita con criteri di interruzione prima che inizi il primo workshop. Esempio: se una soluzione Vision-AI dopo dodici settimane non mostra un riconoscimento almeno del 10 percento migliore rispetto al campionamento manuale, viene interrotta o ridefinita. Se un'assistenza alle offerte dopo sei mesi non porta un risparmio di tempo misurabile, viene eliminata dal portfolio. Sembra duro. Ma è più economico di 18 mesi di speranza.

Raccomandazioni d'azione: 7 passi per la decisione Build-vs.-Buy

Come amministratore delegato, CTO o responsabile digitale, non inizierei con la selezione degli strumenti. Nemmeno con un workshop AI in cui alla fine ci sono 47 casi d'uso appiccicati su post-it e nessuno sa chi li paga. Farei sette cose. Esattamente in quest'ordine.

1. Inventariate i possibili casi d'uso dell'AI in produzione, vendite, servizio e back office. Accanto a ogni caso d'uso, scrivete un indicatore chiave: scarti, tempi di fermo, durata dell'offerta, conversione, scorte, costi di reclamo. Senza indicatore, nessun caso d'uso.
2. Valutate ogni caso d'uso con la matrice 2x2: potenziale di differenziazione rispetto alla standardizzabilità. Effettuate la valutazione in un piccolo gruppo con la direzione, il reparto specialistico e l'IT. Non in un workshop di 18 persone.
3. Definite una regola buy-first per gli argomenti commodity. Forecasting, analisi testuale standard, semplice ispezione visiva, automazione CRM e raccomandazione dovrebbero essere Build solo se esiste una motivazione aziendale scritta.
4. Stabilite criteri di interruzione. Limite di tempo, KPI minimi, disponibilità dei dati, accettazione da parte degli utenti. Un PoC senza linea di arresto non è un esperimento, ma un rischio di costo con un nome amichevole.
5. Costruite un piccolo team centrale. Per 50-500 dipendenti spesso bastano: un Data Engineer o Analytics Engineer, un forte Product Owner per ogni caso d'uso, un architetto IT a tempo parziale, specialisti esterni per fasi limitate.
6. Integrate l'AI nei sistemi esistenti. Nessun portale AI isolato se gli utenti lavorano in ERP, CRM, MES, CPQ o sistemi di ticketing. L'AI deve apparire dove il lavoro avviene comunque.
7. Riferite trimestralmente sulle applicazioni AI produttive, non sui PoC. Mostrate l'impatto aziendale, il tasso di utilizzo, i costi, i rischi aperti. Il CFO dovrebbe capire la tabella senza dover cercare su Google "Embedding".

Prodotto Amplifa Automazione delle vendite basata sull'AI per team B2B che non vogliono impostare la generazione di lead, l'affinamento dell'ICP e l'outreach come un progetto fai-da-te.

Governance: Chi decide, chi è responsabile, chi ferma?

La governance dell'AI suona come una cosa da grandi aziende. Non è del tutto vero. Proprio le PMI ne hanno bisogno, perché i percorsi sono brevi e gli errori diventano rapidamente personali. Se un'AI raccomanda approvazioni di qualità errate, la questione non finisce in un comitato di rischio anonimo. Finisce da Sabine nel controllo qualità, da Thomas nell'ingegneria e dall'amministratore delegato, se il cliente si lamenta.

Una governance utile per 50-500 dipendenti non deve essere complessa. Richiede quattro ruoli: Business Owner, Product Owner, responsabile tecnico, revisore dei rischi o della conformità. Il Business Owner è responsabile del beneficio. Il Product Owner è responsabile dell'utilizzo e della roadmap. La tecnologia mantiene puliti il funzionamento, la sicurezza e il flusso di dati. La conformità verifica la protezione dei dati, le questioni del consiglio di fabbrica, la rilevanza dell'EU AI Act e l'auditabilità. Quattro nomi. Non "l'IT".

L'EU AI Act diventerà gradualmente più tangibile dal 2025 e 2026, soprattutto per le applicazioni ad alto rischio. Molti casi d'uso delle PMI non rientrano nella classe di rischio più alta, ma la documentazione, la trasparenza e la responsabilità diventeranno più importanti. Chi oggi introduce un'AI nelle decisioni di qualità, nei processi del personale o nei passaggi di produzione critici per la sicurezza, non dovrebbe aspettare che l'auditor sia alla porta.

La governance decide anche Build vs. Buy. Con Buy, devi controllare il fornitore: elaborazione dei dati, trasparenza del modello, hosting, concetti di cancellazione, accesso, log di audit. Con Build, devi essere in grado di fare tutto questo da solo. Onestamente? Molte aziende di 200 persone non possono farlo. Non è un rimprovero. È un criterio decisionale.

Stack tecnologico: ciò di cui le PMI hanno veramente bisogno

Se Build o Hybrid ha senso, non serve uno zoo tecnologico. Vedo troppo spesso immagini di architetture con Databricks, Snowflake, Azure ML, MLflow, Airflow, Kafka, Kubernetes e altri cinque loghi, anche se l'azienda invia ancora file CSV dall'ERP via e-mail. Questa non è strategia. Questa è una collezione di loghi.

Per molte PMI, uno stack chiaro è sufficiente: archiviazione centrale dei dati o Lakehouse, interfacce stabili con ERP/CRM/MES, uno strumento MLOps per il versionamento e il monitoraggio dei modelli, concetto di diritti, reporting. Azure è forte nelle PMI DACH, spesso a causa dei contratti Microsoft 365 e delle competenze IT esistenti. AWS SageMaker, GCP Vertex AI, Databricks, Snowflake, SAP AI Core o Siemens Industrial Edge possono essere adatti. La domanda non è quale logo suoni più moderno. La domanda è chi lo gestisce.

L'Open Source non è un pasto gratis. PyTorch, TensorFlow, scikit-learn, XGBoost, Hugging Face, MLflow — tutti ottimi strumenti. Ma qualcuno deve gestire le dipendenze, controllare gli aggiornamenti di sicurezza, monitorare i modelli, rilevare la deriva, riparare le pipeline. Durante un turno di notte, a nessuno interessa se l'errore proviene dal Feature Store o dall'interfaccia PLC. La linea è ferma.

Con Buy/Configure lo stack è diverso. Siemens Industrial Edge o Insights Hub per i dati industriali, PTC ThingWorx per scenari IoT-vicini, SAP AI Core e Joule nell'ambiente ERP, Microsoft Dynamics 365 con Copilot per i processi CRM, Celonis per il Process Mining, o9 o SAS per la pianificazione, Cognex o Landing AI per la Vision. Questi prodotti non risolvono ogni problema, ma danno struttura. Per molte PMI, la struttura è già metà del ROI.

Amplifa per la strategia di vendita AI Per le PMI B2B che vogliono utilizzare l'AI nelle vendite in modo produttivo, senza dover prima costruire una propria piattaforma di outreach e dati.

Change Management: La fabbrica decide con

Nel dicembre 2024, ero presso un'azienda vicino a Pforzheim. 160 dipendenti, pezzi di precisione, molto lavoro manuale nel controllo. Un giovane project manager spiegava su un monitor un sistema di rilevamento errori basato sull'AI. Accanto a me c'era un ispettore, forse sulla cinquantina, con le mani nere ai bordi delle dita. Ha detto a bassa voce: "Se la macchina sbaglia, la colpa è mia." Questa è stata la frase più importante della giornata.

L'introduzione dell'AI raramente fallisce solo per la tecnologia. Fallisce per la responsabilità. Se le persone credono che l'AI toglierà loro il lavoro, scaricherà gli errori su di loro o svaluterà la loro esperienza, non la useranno. Allora il sistema verrà aggirato, gli avvertimenti ignorati, i dati mal gestiti. Il Change Management non significa appendere manifesti. Significa chiarire ruoli, responsabilità e benefici in modo pulito.

Con Vision AI nel controllo qualità deve essere chiaro: l'AI approva o raccomanda? Chi decide nei casi limite? Come vengono gestiti i falsi negativi? Come il feedback degli ispettori confluisce nel modello? Con l'assistenza alle offerte nelle vendite deve essere chiaro: l'AI può suggerire prezzi? Chi controlla gli sconti? Quali affermazioni ai clienti sono tabù? Queste domande non sono freni. Sono prerequisiti operativi.

Il consiglio di fabbrica deve essere coinvolto presto, non dopo il pilota. Soprattutto per l'AI nella misurazione delle prestazioni, nella pianificazione dei turni, nelle risorse umane o nei sistemi di assistenza con dati di utilizzo. Conosco aziende che hanno perso tre mesi perché credevano che la partecipazione fosse un atto formale. Non lo era. Era il vero rollout.

Cosa mi aspetto nel 2026: meno teatro PoC, più selezione rigorosa

La mia previsione è netta: entro la fine del 2026, molte PMI dimezzeranno i loro portafogli AI. Non perché l'AI deluda. Ma perché gli elenchi di progetti del 2023 e 2024 erano troppo ampi, troppo tecnici e troppo mal calcolati. Il CFO chiederà quali applicazioni sono in produzione. Le vendite chiederanno perché l'assistente alle offerte non è ancora nel CRM. La produzione chiederà perché il pilota funziona solo sulla linea 3. Poi si farà una selezione.

Allo stesso tempo, le aziende migliori saranno più veloci. Non perseguiranno 30 casi d'uso, ma cinque. Utilizzeranno software standard dove è sufficiente e svilupperanno il proprio know-how dove fa male se anche il concorrente ce l'ha. Non "faranno AI". Ridurranno gli scarti, accelereranno le offerte, aumenteranno i ricavi da servizi, ridurranno le scorte. Questo è un altro tono.

Il CTO di SAP, Jürgen Müller, ha più volte sottolineato pubblicamente l'integrazione dell'AI generativa nella Business Suite. Il messaggio per le PMI è chiaro: non tutti i clienti devono costruire i propri modelli fondamentali. Molti dovrebbero consumare, integrare, controllare l'AI. Lo considero sano. Chi nel 2026 crede ancora che un'azienda di 250 persone debba prima fondare un proprio laboratorio AI prima di vedere un beneficio, confonde le PMI con un istituto di ricerca.

Alla fine, rimane la scena di Gütersloh. Thomas, il CTO con il piano da 1,2 milioni di euro, mi ha chiamato due settimane dopo la nostra conversazione. Avevano fermato l'idea della piattaforma, avviato due piloti Buy e mantenuto un unico caso d'uso ibrido per la loro logica macchina. "Sembra meno visionario", ha detto. In sottofondo ho sentito di nuovo il carrello elevatore emettere un segnale acustico. Forse era proprio quello il progresso.