Strategia AI · 23 maggio 2026 · 24 min. di lettura · Mohsen Ghulami, GTM Engineer, Amplifa

Strategia AI: Build vs. Buy nelle medie imprese

Strategia AI nelle medie imprese: scelga Build vs. Buy con numeri, casi e criteri chiari, prima che il Suo PoC consumi il budget.

Tre settimane fa mi trovo a Gütersloh in una sala riunioni che profuma di caffè filtro e plastica calda. Thomas, CTO di un'azienda metalmeccanica con 280 dipendenti, mi porge il suo iPad e dice: "Ora stiamo costruendo la nostra piattaforma AI". Nel cortile si sente il segnale acustico di un carrello elevatore in retromarcia, all'interno lampeggia una slide PowerPoint con il logo Azure, il serpente Python e un blocco di budget da 1,2 milioni di euro. 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 presso Trumpf a Ditzingen come i dati degli impianti di taglio laser diventino business di assistenza. Ho vissuto presso piccoli contoterzisti nel Giura Svevo come un singolo export MES mancante possa fermare un intero progetto AI. E ho visto abbastanza CFO stringere le labbra alla parola "sviluppo interno" 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 media impresa con 50-500 dipendenti, vuole costruire da sé ogni modello di forecasting, brucia tempo, stipendi e nervi. Chi invece acquista ogni funzione AI, anche se questa fa la differenza nel proprio prodotto, regala margine a fornitori che non capiscono il business. Ho visto entrambi i casi. Entrambi fanno male.

Perché la strategia AI diventa ora una priorità della direzione

A marzo 2025 mi trovavo presso un fornitore vicino a Heilbronn, 410 dipendenti, molta asportazione truciolo, 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 conosce nei capannoni dove nessuno parla di futuro perché l'ordine deve uscire entro venerdì. "Abbiamo quattro PoC AI", ha detto Andrea. "Nessuno è operativo".

È esattamente qui che si trova la media impresa. Non all'inizio del dibattito sull'AI, ma dopo la prima disillusione. ChatGPT ha spalancato la porta nel 2023, Microsoft Copilot è arrivato in molte aziende, SAP inserisce funzioni AI nella suite, e un fornitore di software su due incolla ormai un'etichetta AI sulla propria roadmap. Solo che: in officina, nelle vendite, nell'assistenza succede meno di quanto affermino i palchi delle conferenze.

I numeri confermano questa osservazione. Secondo lo studio BITKOM 2024, circa il 15-20% delle aziende in Deutschland utilizza l'AI in modo produttivo; per le aziende tra 100 e 499 dipendenti la quota è piuttosto nella fascia bassa, circa il 10-15%. BCG e VDMA sono giunti nel 2023 nel settore metalmeccanico a un modello che sento costantemente nei colloqui: più del 60% sperimenta con PoC AI, ma meno del 15% ha applicazioni scalate in azienda. Quindi: molti piloti, poca operatività.

Questa non è una legge di natura in Deutschland. Spesso è una cattiva decisione. La media impresa tratta l'AI troppo spesso come un acquisto tecnologico e troppo raramente come una questione di creazione di valore. In un'azienda di Augsburg con 180 dipendenti, Jens, direttore commerciale, mi ha detto a gennaio 2025: "Non possiamo permetterci errori". Vero. Ma non decidere è anche un errore. Solo più silenzioso.

Strategia AI nelle medie imprese: cosa significa realmente Build vs. Buy

Build non significa che tre Data Scientist addestrino un Foundation Model in cantina. Beh, quasi mai. Build significa solitamente nelle medie imprese: pipeline di dati proprie, modelli propri o almeno logica di dominio propria, processi MLOps propri, monitoraggio proprio, responsabilità propria. Il fornitore fornisce forse l'infrastruttura cloud, ma l'azienda si assume il rischio di prodotto e operativo.

Buy non significa comprare un software e risparmiare il 15% di scarti il lunedì successivo. Chi lo crede non ha mai visto un'interfaccia tra vecchio ERP, export Excel e controllo macchine. Buy significa: acquistare software standard, SaaS o componenti di piattaforma, configurare, integrare, formare, misurare. È un lavoro. Ma è un lavoro diverso dalla costruzione di modelli.

Il confine più netto non corre tra cloud e on-prem. Corre tra commodity e differenziazione. Forecasting, NLP standard, classificazione immagini, ottimizzazione percorsi, assistenza alle offerte, semplici recommendation engine — per questi esistono prodotti validi. L'AI nel cuore del prodotto, come sensoristica intelligente, navigazione autonoma, controllo di processo proprietario o un algoritmo di assistenza che impara da 15 anni di dati macchina — lì Build può avere senso. Può. Non deve.

PwC e Roland Berger descrivono dal 2023 un modello che emerge anche nei miei colloqui: le medie imprese più piccole scelgono prevalentemente Buy o Configure, le medie imprese più grandi scelgono più spesso l'ibrido. L'azienda da 300 persone acquista piuttosto Microsoft, SAP, Cognex, Celonis, o9, PTC o un fornitore specializzato. Il fornitore da 3.000 persone costruisce forse un Analytics Competence Center e sviluppa dove risiede la creazione di valore. Sembra banale. Viene comunque ignorato continuamente.

I numeri duri: costi, timeline, tassi di successo

Negli ultimi due anni a München, Stuttgart, Bielefeld e Linz ho parlato con responsabili digitali che gestiscono i loro budget AI non nei comunicati stampa, ma in Excel. I range sono sorprendentemente stabili. Un PoC Build nelle medie imprese costa solitamente tra 100.000 e 300.000 € per tre-sei mesi. Finché un MVP non è operativo, sono realistici tra 300.000 e 800.000 €, senza contare sempre correttamente i costi del personale interno. Ed è proprio lì che inizia l'autoinganno.

Perché il Data Scientist non è gratuito solo perché è già a libro paga. Nemmeno l'ingegnere di produzione che controlla i label per otto ore a settimana. Tantomeno l'architetto IT che chiarisce le autorizzazioni di sicurezza. In uno stabilimento vicino a Ulm, a febbraio 2025, si sentiva odore di lubrorefrigerante mentre Martin, responsabile IT, mi diceva: "Esternamente abbiamo speso solo 180.000 €". Due ore dopo mi ha mostrato la stima dei costi interni. Con le prestazioni proprie, il progetto era a 520.000 €.

Buy o Configure parte da cifre più basse. Licenza pilota più integrazione: spesso tra 50.000 e 250.000 €. Rollout su più stabilimenti o aree: tra 150.000 e 800.000 €. I costi di licenza correnti per molti scenari medi si attestano tra 50.000 e 200.000 € all'anno, a seconda degli utenti, del volume di dati e dell'umore del fornitore. Sì, l'umore del fornitore. Chi ha già negoziato un rinnovo SaaS al terzo anno di contratto sa cosa intendo.

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

Build conviene — ma più raramente di quanto dicano le slide dei fondatori

Mi piace lo sviluppo interno. Davvero. C'è quel momento in cui un team non solo addestra un modello, ma lo inserisce in un processo, gli utenti lo toccano, l'indicatore si muove e il direttore di stabilimento non parla più di "quella cosa dell'AI", ma del suo nuovo strumento. È potente. Solo che non succede 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 storia di piattaforma propria con AXOOM e un ecosistema intorno a TruConnect. Dal 2017 circa, Trumpf investe continuamente in servizi digitali, Predictive Maintenance e funzioni Smart Factory. Nelle presentazioni pubbliche, Trumpf parla per determinati impianti di una riduzione dei tempi di fermo fino al 20-30% grazie alla manutenzione predittiva. Questo non è un progetto secondario dell'IT. È business di prodotto e assistenza.

Kärcher di Winnenden è altrettanto interessante. Il KIRA B 50, un robot di pulizia autonomo, ha bisogno di Computer Vision, 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, tra l'altro nel Digital Hub, e combina lo sviluppo proprio con componenti cloud. Qui Build non è prestigio. L'AI è nel dispositivo, nel prezzo, nel contratto di assistenza.

Il punto è questo: Build conviene se l'AI cambia il beneficio per il cliente o rappresenta un processo che i concorrenti non possono coprire facilmente. Un produttore di macchine utensili con miliardi di dati storici dei sensori ha una posizione di partenza diversa rispetto a un grossista da 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 di processo o di prodotto è unica. Acquistiamo analytics standard e modelli linguistici.

— parafrasi da un CDO di un'azienda metalmeccanica tedesca, colloquio Handelsblatt 2024

Nicole Büttner di Merantix Momentum ha sottolineato qualcosa di simile in formati EY su "Zukunft Deutschland": la media impresa ha un vantaggio con i propri dati, ma dovrebbe spesso acquistare modelli e piattaforme e padroneggiare internamente la logica di dominio. Sottoscrivo. I dati da soli non sono ancora un fossato difensivo. 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 ho incontrato a novembre 2024 un manager della logistica, Ralf, che in Fiege era stato coinvolto in progetti di previsione. Eravamo in una mensa, profumava di sugo d'arrosto, e dal magazzino arrivava quel rotolio sordo della tecnologia di trasporto. "Avremmo potuto costruire tutto da soli", ha detto. "Ma per cosa?". Fiege utilizza in diverse aree servizi cloud, componenti Azure e soluzioni partner, ad esempio per previsioni e ottimizzazione. Gli use case pubblicati parlano di una riduzione delle scorte del 2-5% e di una Forecast Accuracy migliore del 3-8%, a seconda del campo.

Questa è la realtà delle medie imprese, solo in scala maggiore. Un forecast è raramente unico. Nemmeno un'ottimizzazione dei percorsi. Un controllo qualità basato su immagini con classi di errore definite è tecnicamente impegnativo, ma spesso non è un motivo per costruire un proprio team Vision. Cognex, Landing AI, Microsoft Custom Vision, Siemens Industrial Edge, PTC ThingWorx o fornitori specializzati hanno i loro difetti. Naturalmente. Ma non partono da zero.

Un caso anonimizzato del sud della Deutschland mostra chiaramente la logica. Azienda metalmeccanica, 800 dipendenti, controllo visivo manuale, carenza di personale, alta pressione per rilavorazioni. L'azienda ha acquistato un sistema Vision AI commerciale invece di svilupparlo internamente. Investimento iniziale: circa 350.000 € 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 soldi.

Lo so, 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 dipartimento IT. Paga per capacità di consegna, qualità, assistenza, stabilità dei prezzi. Se un software standard porta l'80% del beneficio in un terzo del tempo, allora lo sviluppo proprio è spesso vanità con pianificazione sprint.

La seconda verità: Buy può diventare costoso, pigro 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ù chi ha le chiavi. Un fornitore della Bassa Baviera da 260 persone pagava nel 2024 licenze moderate per tre tool legati all'AI nelle vendite, nell'assistenza e nella pianificazione. Insieme a interfacce, consulenza e admin interni, i costi annuali sono arrivati improvvisamente a 310.000 €. Utilità? Difficile da misurare. "Ora abbiamo delle dashboard", ha detto il capo delle vendite. Ho avuto pietà di lui.

Il più grande errore del Buy è la fede cieca nelle funzioni. Una demo software mostra sempre dati puliti. Sempre. Nell'operatività reale arrivano anagrafiche clienti doppie, gerarchie articoli mancanti, modelli di turni divergenti e un campo ERP chiamato "Altro" che dal 2009 contiene tutto ciò che nessuno sapeva classificare. SAP, Microsoft, Siemens o PTC possono attutire molto. Ma non riparano un'organizzazione che disprezza i propri 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 lo use case è una commodity e il fornitore consegna in modo stabile. Per i processi core critici si dovrebbe essere più cauti. Export dei dati, verificabilità, costi in fase di scalabilità, scenario di uscita — temi noiosi, sì. Proprio per questo vengono letti troppo tardi.

Dove muoiono i progetti Build nelle medie imprese

C'è una scena che si ripete. Sala riunioni, tappeto grigio, lavagna bianca con i resti di un workshop, da qualche parte c'è ancora scritto "Priorizzazione Use Case". Nella stanza siedono IT, reparto specialistico e un consulente esterno. Dopo 14 mesi di progetto, qualcuno chiede: "Chi è in realtà il Product Owner?". Poi cala il silenzio. L'ho vissuto a Köln, Nürnberg e St. Gallen.

Il primo motivo di morte si chiama qualità dei dati. Non sexy, ma letale. Un fornitore automotive con circa 3.000 dipendenti ha avviato in tre anni diversi PoC di Predictive Maintenance, insieme a un istituto di ricerca. Costo: oltre un milione di euro, tempo interno incluso. Tutti i piloti si sono arenati in singoli impianti. OT e IT erano separati, non c'era un lakehouse centrale, la manutenzione è 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 erano operativi i primi use case produttivi, dopo 18 mesi su impianti selezionati è stata segnalata una riduzione del 15% dei guasti imprevisti.

Il secondo motivo di morte si chiama falso orgoglio. Un distributore B2B della regione DACH con circa 1.200 dipendenti voleva costruire un proprio recommendation engine, anche per ridurre la dipendenza dalle piattaforme cloud statunitensi. Team di Data Science di cinque persone, Python, Scikit-Learn, più tardi TensorFlow. Diciotto mesi di sviluppo, circa 1-1,5 milioni di euro. Alla fine, la performance nei test interni era solo del 60-70% rispetto a un recommender cloud standard. Il progetto è stato fermato, la soluzione SaaS è arrivata comunque. Solo più tardi e più cara.

Il terzo motivo 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 guida. Dopodiché il modello devia (drift), 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 dà i numeri". E l'accettazione sparisce.

MLOps qui non è una buzzword, ma lavoro di manutenzione per i modelli. Monitoraggio, versionamento dei dati, processi di rilascio, rollback, responsabilità, traccia di audit. Suona asciutto. 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 solida

Nei colloqui mi piace usare una semplice matrice 2×2. 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 copra 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ò valutare seriamente Build o Co-Build. Esempi: AI in un dispositivo medico con sensoristica speciale, funzioni autonome in una macchina per la pulizia, controllo di processo in un metodo di produzione proprio. Kärcher, Trumpf, Wittenstein o Festo pensano in queste categorie. Lì l'AI è vicina al prodotto o al segreto di processo.

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

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

Quadrante quattro: basso potenziale di differenziazione, bassa standardizzabilità. Solitamente un segnale di allarme. Se qualcosa non è né strategicamente importante né facilmente acquistabile, perché farlo? Perché un responsabile di area lo vuole? Perché c'è un programma di finanziamento? Il finanziamento non è un business case. Non ci sono scuse.

Calcolo del ROI: perché l'inizio più economico può finire per costare caro

A giugno 2025 mi ha chiamato un amministratore delegato di Ravensburg. 120 dipendenti, costruzione di macchine speciali, EBIT discreto, ma IT esile. Ha chiesto: "Quanto ci costa un'AI per l'automazione delle offerte?". Ho risposto: "Quanto costa un'offerta oggi?". Silenzio. Poi sfogliare di carte. Poi il numero: circa 1.800 € di impegno interno per macchine complesse, quando sono coinvolti vendite, progettazione e acquisti.

Solo con tali numeri Build vs. Buy diventa tangibile. Se un'azienda scrive 900 offerte complesse all'anno e un sistema di assistenza AI riduce il tempo ciclo del 25%, non parliamo di un gioco. Parliamo di capacità, reazione più rapida, meno errori nelle distinte base, miglior follow-up. Se la soluzione sia acquistata, costruita o ibrida, si decide poi in base al payback, non alla sensazione viscerale del CTO.

Confronto settoriale: metalmeccanica, commercio, logistica, automotive

La metalmeccanica è sedotta dal Build. Le aziende hanno fiducia tecnica in se stesse, molti ingegneri, buoni dati di prodotto e spesso una cultura del fare da sé. Presso DMG Mori, Trumpf, Wittenstein o Festo questo atteggiamento ha senso nelle funzioni AI vicine al prodotto. Presso un costruttore di impianti da 180 persone dell'Alta Franconia che vuole costruire una propria AI testuale per i rapporti di assistenza, piuttosto no. L'odore di olio idraulico non rende proprietario un modello NLP.

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

La logistica è più pragmatica. Forse perché lì ogni punto percentuale ricade immediatamente su pallet, chilometri e piani turni. Fiege, Dachser o Rhenus lavorano con piattaforme, partner e team propri dove conviene. Buy per l'ottimizzazione standard, Build o Co-Build per dati di rete speciali e pianificazione specifica per il cliente. Decide il pavimento del magazzino. Non l'ufficio strategia.

I fornitori automotive si trovano tra due fuochi. Hanno volumi, pressione sulla qualità, requisiti di tracciabilità e specifiche OEM. Predictive Quality, Maintenance, controllo visivo e AI di pianificazione sono interessanti. Ma molti stabilimenti sono cresciuti storicamente, i dati OT sono frammentati e il consiglio di fabbrica vuole essere consultato presto. Chi avvia Build lì senza una piattaforma dati, finisce nella palude dei PoC. L'ho visto troppe volte.

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

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 dalla metalmeccanica e tecnologia medica. Ero lì a ottobre 2024. Nel controllo qualità si sentiva odore di detergente alcolico, sotto una lampada 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 offerte per pezzi speciali. In passato si sarebbero probabilmente avviati tre PoC. Questa volta no. L'amministratore delegato ha passato ogni idea attraverso la matrice. Vision AI: Buy. Forecasting: Buy/Configure. Assistenza offerte: Ibrido, perché la logica di fattibilità tecnica e le regole delle varianti erano veramente aziendali.

I numeri dopo 14 mesi: il pilota Vision AI per due famiglie di pezzi è costato circa 210.000 € inclusi telecamera, illuminazione, integratore e formazione. Gli errori sfuggiti sono diminuiti del 28%, le rilavorazioni dell'11%. Il forecasting è stato introdotto tramite un modulo del partner ERP esistente più una pipeline dati esterna, costo circa 95.000 €; la Forecast Accuracy è aumentata di 6 punti percentuali nei pezzi A. L'assistenza offerte è costata di più: circa 380.000 €, perché sono stati integrati CPQ, regole vicine al CAD e cronologie prezzi. In compenso, il tempo ciclo medio delle offerte complesse è sceso da 9,5 a 6,8 giorni lavorativi.

Più importante dei singoli numeri è stata la governance. C'era un Product Owner per ogni use case, visione mensile dei KPI, chiari criteri di interruzione e un piccolo nucleo 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 chiaramente clienti target, fonti dati e priorità, prima che l'AI nelle vendite o nella lead generation bruci denaro.

FAQ: Quando dovrebbe una media impresa costruire l'AI da sé?

Una media impresa dovrebbe costruire l'AI da sé quando sono soddisfatte contemporaneamente tre condizioni: la funzione crea differenziazione presso il cliente, i dati necessari sono proprietari e affidabili, e l'azienda può finanziare operatività, monitoraggio e ulteriore sviluppo. Se manca una di queste condizioni, permetterei Build solo con un partner e una linea di stop ferrea. Un esempio: la diagnosi intelligente dello stato per le proprie macchine con dati sensori esclusivi può giustificare Build. Un chatbot standard per le richieste di assistenza no.

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

Per aziende tra 50 e 500 dipendenti, solitamente una strategia ibrida Buy-first è la scelta migliore. Software standard per use case commodity, logica di dominio propria per processi differenzianti, piccolo team core interno per dati e responsabilità di prodotto. Suona meno eroico di "costruiamo la nostra piattaforma". Funziona più spesso. Secondo BITKOM 2024, l'uso produttivo dell'AI nelle medie imprese tedesche è ancora basso; proprio per questo il Time-to-Value conta più dell'orgoglio tecnico.

FAQ: Come si evita la trappola dei PoC nell'AI?

La si evita con criteri di kill prima che inizi il primo workshop. Esempio: se una soluzione Vision AI dopo dodici settimane non mostra un riconoscimento migliore di almeno il 10% rispetto al campionamento manuale, viene fermata o ridefinita. Se un'assistenza offerte dopo sei mesi non porta un risparmio di tempo misurabile, viene eliminata dal portfolio. Suona 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 dei tool. Nemmeno con un workshop AI dove alla fine 47 use case sono appiccicati su post-it e nessuno sa chi li paga. Farei sette cose. Esattamente in questo ordine.

1. Inventari gli use case AI possibili in produzione, vendite, assistenza e backoffice. Scriva accanto a ogni use case un indicatore: scarti, fermi, durata offerta, conversione, scorte, costi reclami. Senza indicatore, niente use case.
2. Valuti ogni use case con la matrice 2×2: potenziale di differenziazione contro standardizzabilità. Faccia la valutazione in un piccolo gruppo con direzione, reparto specialistico e IT. Non in un workshop da 18 persone.
3. Definisca una regola Buy-first per i temi commodity. Forecasting, analisi testi standard, semplice Vision Inspection, CRM automation e recommendation dovrebbero diventare Build solo se esiste un motivo di business scritto.
4. Stabilisca criteri di kill. Limite di tempo, KPI minimi, disponibilità dati, accettazione utenti. Un PoC senza linea di stop non è un esperimento, ma un rischio di costo con un nome gentile.
5. Costruisca un piccolo team core. Per 50-500 dipendenti spesso basta: un Data Engineer o Analytics Engineer, un forte Product Owner per use case, un architetto IT pro quota, specialisti esterni per fasi limitate.
6. Integri l'AI nei sistemi esistenti. Niente portali AI isolati se gli utenti lavorano in ERP, CRM, MES, CPQ o sistemi di ticketing. L'AI deve apparire dove il lavoro avviene comunque.
7. Riferisca trimestralmente sulle applicazioni AI produttive, non sui PoC. Mostri l'impatto sul business, il tasso di utilizzo, i costi, i rischi aperti. Il CFO dovrebbe capire la tabella senza dover cercare su Google "embedding".

Amplifa Prodotto — Automazione vendite supportata da AI per team B2B che non vogliono impostare lead generation, affinamento ICP e outreach come un progetto di bricolage.

Governance: chi decide, chi risponde, chi ferma?

Governance AI suona come una cosa da multinazionale. Non è del tutto vero. Proprio la media impresa ne ha bisogno, perché i percorsi sono brevi e gli errori diventano subito personali. Se un'AI raccomanda autorizzazioni di qualità errate, il tema non finisce in un anonimo comitato rischi. Finisce da Sabine nel controllo qualità, da Thomas nell'engineering e dall'amministratore delegato se il cliente reclama.

Una governance utile per 50-500 dipendenti non deve essere voluminosa. Ha bisogno di quattro ruoli: Business Owner, Product Owner, responsabile tecnico, verificatore rischi o compliance. Il Business Owner risponde dell'utilità. Il Product Owner risponde dell'utilizzo e della roadmap. La tecnica mantiene puliti operatività, sicurezza e flusso dati. La compliance verifica protezione dati, temi del consiglio di fabbrica, rilevanza EU AI Act e verificabilità. Quattro nomi. Non "l'IT".

L'EU AI Act diventerà gradualmente più percepibile dal 2025 e 2026, specialmente per le applicazioni ad alto rischio. Molti use case delle medie imprese non rientrano nella classe di rischio più alta, ma documentazione, trasparenza e responsabilità diventeranno più importanti. Chi introduce oggi un'AI in decisioni di qualità, processi del personale o fasi di produzione vicine alla sicurezza, non dovrebbe aspettare che l'auditor sia nell'atrio.

La governance decide anche Build vs. Buy. Con Buy deve verificare il fornitore: trattamento dati, trasparenza del modello, hosting, concetti di cancellazione, accesso, log di audit. Con Build deve poter fare tutto questo da solo. Onestamente? Molte aziende da 200 persone non possono farlo. Non è un rimprovero. È un criterio di decisione.

Stack tecnologico: cosa serve davvero alle medie imprese

Se Build o l'ibrido hanno senso, non serve uno zoo tecnologico. Vedo troppo spesso schemi di architettura con Databricks, Snowflake, Azure ML, MLflow, Airflow, Kafka, Kubernetes e altri cinque loghi, anche se l'azienda invia ancora file CSV dall'ERP via mail. Questa non è strategia. È collezionare loghi.

Per molte medie imprese basta uno stack chiaro: deposito dati centrale o lakehouse, interfacce stabili verso ERP/CRM/MES, uno strumento MLOps per il versionamento dei modelli e il monitoraggio, concetto di permessi, reporting. Azure è forte nelle medie imprese DACH, spesso a causa dei contratti Microsoft 365 e della competenza IT esistente. AWS SageMaker, GCP Vertex AI, Databricks, Snowflake, SAP AI Core o Siemens Industrial Edge possono andare bene. 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 curare le dipendenze, verificare gli aggiornamenti di sicurezza, monitorare i modelli, rilevare il drift, riparare le pipeline. In un turno di notte a nessuno interessa se l'errore viene dal feature store o dall'interfaccia PLC. La linea è ferma.

Con Buy/Configure lo stack appare diverso. Siemens Industrial Edge o Insights Hub per dati industriali, PTC ThingWorx per scenari vicini all'IoT, 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 medie imprese, la struttura è già metà del ROI.

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

Change Management: l'officina decide insieme a Lei

A 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 rilevamento errori supportato da AI. Accanto a me c'era un addetto al controllo, forse sulla sessantina, con le mani nere sui bordi delle dita. Ha detto sottovoce: "Se la scatola sbaglia, la colpa è mia". È stata la frase più importante della giornata.

L'introduzione dell'AI fallisce raramente solo per la tecnica. Fallisce per la responsabilità. Se le persone credono che l'AI tolga loro il lavoro, scarichi loro gli errori o svaluti la loro esperienza, non la usano. Allora il sistema viene aggirato, gli avvisi vengono ignorati, i dati vengono curati male. Change Management non significa appendere manifesti. Significa chiarire bene ruoli, responsabilità e utilità.

Con la Vision AI nel controllo qualità deve essere chiaro: l'AI dà il via libera o raccomanda? Chi decide nei casi limite? Come vengono trattati i falsi negativi? Come fluisce il feedback degli addetti nel modello? Con l'assistenza 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 va coinvolto presto, non dopo il pilota. Specialmente con l'AI nella misurazione delle prestazioni, pianificazione turni, HR o 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 per il 2026: meno teatro dei PoC, più selezione dura

La mia previsione è netta: entro la fine del 2026 molte medie imprese dimezzeranno i loro portfolio AI. Non perché l'AI deluda. Ma perché le liste dei progetti del 2023 e 2024 erano troppo ampie, troppo tecniche e calcolate male. Il CFO chiederà quali applicazioni siano operative. Le vendite chiederanno perché l'assistente offerte non sia ancora nel CRM. La produzione chiederà perché il pilota funzioni solo sulla linea 3. Allora si farà selezione.

Allo stesso tempo, le aziende brave diventeranno più veloci. Non perseguiranno 30 use case, ma cinque. Prenderanno software standard dove basta, e svilupperanno know-how proprio dove fa male se lo ha anche la concorrenza. Non "faranno AI". Ridurranno gli scarti, accelereranno le offerte, aumenteranno i fatturati di assistenza, ridurranno le scorte. È un altro tono.

Il CTO di SAP Jürgen Müller ha sottolineato pubblicamente più volte l'integrazione dell'AI generativa nella Business Suite. Il messaggio per la media impresa è chiaro: non ogni cliente deve costruire i propri Foundation Models. Molti devono consumare, incorporare, controllare l'AI. Lo considero salutare. Chi nel 2026 crede ancora che un'azienda da 250 persone debba prima fondare un proprio laboratorio AI prima di vederne l'utilità, confonde la media impresa con un istituto di ricerca.

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