Tagliare persone per "fare spazio" all'AI è quasi sempre la mossa sbagliata. I costi di inferenza, il lock-in sul vendor e la competenza che esce dalla porta non stanno nel ROI della presentazione.
In Snowinch lo vediamo quando un founder arriva dopo la scelta affrettata: dipendenze che nessuno aveva messo in conto, e un team più magro proprio quando serve giudizio.
Il copione della febbre
Un founder legge che un competitor ha "integrato l'AI" e tagliato i costi operativi di un trenta percento (è il numero che circola nei post, non un dato che abbiamo verificato su un campione). Un altro annuncia su LinkedIn di aver sostituito tre posizioni con un sistema automatico. Un terzo dice di aver dimezzato i tempi di sviluppo con i tool.
La pressione si accumula. Il mercato si muove. Gli investitori chiedono dove sei sull'AI. Chi aspetta sembra già indietro.
Le risposte più frequenti sono due: togliere una o più risorse umane, oppure scaricare budget su tool senza un piano su come si attaccano al resto dell'organizzazione. Entrambe sembrano razionali il giorno in cui le prendi. Entrambe mostrano gli effetti collaterali mesi dopo, quando il contesto emotivo della decisione è già sfumato e correggere costa di più.
I costi di inferenza non restano fermi
In fase di test, con volumi bassi, il conto sembra gestibile: qualche centinaio di euro al mese, o un piano fisso con un tetto. Il numero regge.
Poi il sistema va in produzione e l'uso cresce. Ogni chiamata, ogni token, scala con il volume. Se il sistema funziona, l'uso tende a salire. A sei o dodici mesi molti founder scoprono una voce AI diventata rilevante sul conto economico, senza che nessuno avesse modellato quella traiettoria: non perché il listino sia diventato improvvisamente cattivo, ma perché nessuno aveva chiesto, prima del go-live, cosa succede al margine quando il traffico triplica e le chiamate smettono di essere un esperimento.
È una delle prime cose che emergono quando si guarda la struttura dei costi di una startup che ha adottato AI con entusiasmo e poco piano. Il piano fisso della demo non è il piano del live.
Tardi lo scopri.
Anzi, ripensandoci: dire "l'AI costa" è troppo vago per decidere. Il costo utile da modellare è quello a volume reale, con i picchi, non quello della settimana in cui stavi ancora scegliendo il prompt. Se il modello economico regge solo sotto il tetto della prova, non regge.
Lock-in: lo tratti come un cliente troppo grosso
Quando il sistema dipende da un modello di un vendor specifico (cloud grande o tool verticale), accetti condizioni che in fase iniziale nessuno legge con la stessa attenzione del contratto clienti.
Il vendor può alzare i prezzi. Può cambiare le API e forzarti a riscrivere pezzi. Può deprecare il modello su cui hai calibrato soglie e comportamenti, e spostarti su uno più recente con risposte diverse. Può essere acquisito, cambiare focus, o sparire.
Ognuno di questi eventi porta un costo di migrazione che non era nel piano. Più il pezzo AI sta nei processi core, più quel costo è alto. Per un founder con risorse limitate, dipendere da un solo vendor su una funzione critica è un rischio di concentrazione: stessa attenzione che daresti a un solo cliente per una fetta grossa del fatturato.
Se domani quel vendor non esiste più, qual è il costo reale di uscita? Se la risposta è un'alzata di spalle, non hai ancora adottato: hai firmato una dipendenza.
La competenza che esce dalla porta
Questo è il costo più sottile, e spesso il più caro nel tempo.
Quando un processo va interamente al sistema AI, e nel team nessuno continua a capire come funziona, quali sono i casi limite, dove può andare storto, l'organizzazione perde a poco a poco la capacità di intervenire. Non succede il primo giorno. Succede mentre le persone che conoscevano quel processo vengono spostate, escono, o smettono di tenerlo aggiornato in testa perché "ci pensa il sistema".
Poi il contesto cambia, il modello si aggiorna, un caso limite diventa frequente. E in stanza non c'è più chi sa come dovrebbe funzionare senza l'AI. Nessuno sa dove guardare. Nessuno sa come intervenire.
Per un team piccolo questo scenario arriva spesso. È il percorso naturale se l'adozione non ha lasciato ownership sul processo. Qui c'è adiacenza con un altro pezzo che teniamo sul tema formare invece di tagliare: stesso odore, altro angolo. Qui il punto è specifico all'AI: inferenza e vendor aggiungono un piano di costo e di lock-in che l'automazione "classica" non ha nella stessa forma.
Founder: margine di errore più stretto
Le aziende grosse hanno contingency, governance lenta, qualcuno dedicato a tenere acceso il pezzo. I team piccoli no. Ogni scelta sbagliata pesa di più. Ogni dipendenza non pianificata pesa di più.
La pressione a muoversi è reale: mercato, investitori, competitor. Quella stessa pressione rende difficile fermarsi a calcolare rischi con lucidità. Il risultato tipico è una decisione presa in FOMO su un orizzonte di tre mesi, con effetti che emergono a dodici o diciotto. Quando emergono, è difficile collegare causa ed effetto, e ancora più difficile correggere senza bruciare altro.
L'argomento punta alle scelte reattive, non all'AI in sé: decisioni senza un modello di come costi e rischi evolvono.
L'adozione che regge parte da domande diverse. Quali processi hanno volumi prevedibili, output verificabile, poca variabilità nei casi limite. Se il vendor cambia prezzo o depreca il modello tra dodici mesi, qual è il piano. Chi nel team deve continuare a capire quel processo anche dopo che è automatizzato.
Le risposte producono decisioni più lente, meno adatte a un annuncio LinkedIn. Producono anche sistemi che a un anno di distanza hanno costi leggibili e rischi gestibili.
Se stai per tagliare
Se non sai modellare i costi a volume reale, se non hai un piano di uscita dal vendor, se nessuno resterà a capire il processo quando il sistema fallisce, non è ancora ora di togliere persone per "fare spazio".
Se vuoi sentire che l'AI giustifica un taglio subito, o che i rischi si risolvono dopo l'annuncio, questa è la call sbagliata. Se hai già un pezzo in produzione, vincoli chiari e ti serve mettere in ordine inferenza, lock-in e ownership prima di scalare, il resto è concreto: perimetro, numeri, primo pezzo che regge.
