Sfoglia altri articoli simili con le etichette:
Ho passato gli ultimi diciotto mesi a lavorare su processi di automazione marketing con AI per clienti enterprise. Tre continenti, settori diversi, scale diverse. Una parte considerevole di quel lavoro è consistita nel correggere errori, miei e di team che avevano iniziato prima di me. Spesso gli stessi errori.
Non scrivo una checklist motivazionale. Scrivo quello che ho imparato a non fare, perché credo serva di più alla persona che sta avviando il suo primo progetto AI marketing che la lettura della centesima guida positiva.
Automatizzare prima di capire
L’errore più ricorrente è la fretta. C’è un task ripetitivo, esiste un tool AI che sembra risolverlo, si configura, si lascia girare. Tre mesi dopo si scopre che il tool produce output che hanno bisogno di essere rivisti uno per uno, perché contengono errori sottili che chi rivede impiega più tempo a correggere di quanto ne avrebbe impiegato a fare il lavoro da zero.
Mi è successo, mi capita ancora. La regola che ho stabilito è semplice: prima di automatizzare un task, faccio il task manualmente per due settimane, registrando ogni decisione che prendo, ogni eccezione che gestisco, ogni intuizione che applico. Solo dopo costruisco l’automazione. Mai prima.
L’automazione costruita senza aver fatto il task è quasi sempre un’illusione di produttività. Sembra che il lavoro venga fatto, in realtà si è spostato dal “fare” al “rivedere”, e spesso il rivedere costa di più del fare originale.
Confondere prima persona singolare e plurale
Quando un modello AI genera contenuti, il rischio non è la quantità di errori ma la loro omogeneità. Mille post LinkedIn generati con lo stesso system prompt suonano tutti uguali. Cinquanta email di follow-up automatiche hanno la stessa struttura, le stesse frasi di apertura, gli stessi connettivi.
Il destinatario, se ne riceve due o tre, capisce. Smette di rispondere. Il tool nuovo, che doveva aumentare la conversione, la riduce.
Ho fatto questo errore tre anni fa, su un progetto enterprise che pensavo blindato. Il cliente, dopo sei settimane, mi ha mostrato uno screenshot di due email di follow-up identiche ricevute a distanza di mesi da due account commerciali distinti. La firma era diversa. Il testo, parola per parola, era lo stesso. Imbarazzante per il cliente, devastante per il rapporto con il prospect.
Da allora, su qualunque automazione di scrittura, includo una variabile di stochasticità reale: prompt che variano, template che ruotano, intervento umano obbligatorio prima dell’invio. La quantità di output cala. La qualità tiene.
Trattare le allucinazioni come bug e non come feature
I modelli generativi inventano. Non è un difetto, è il modo in cui funzionano. Un sistema RAG ben fatto riduce le allucinazioni, non le elimina. Un fine-tuning su un dominio specifico le riduce, non le elimina. La temperature a zero le riduce, non le elimina.
Per molto tempo ho trattato le allucinazioni come bug da risolvere. Sbagliato. Sono caratteristica strutturale della tecnologia. La domanda giusta non è “come elimino le allucinazioni” ma “come costruisco un processo che le intercetta prima che facciano danno”.
Risposta operativa: ogni output AI usato in customer-facing deve passare per una validazione, automatica o umana, prima di diventare visibile all’esterno. Per output a basso rischio (suggerimenti interni), basta un audit campionario settimanale. Per output ad alto rischio (comunicazione esterna, contenuti che entrano in contratti, informazioni che orientano decisioni di un cliente), serve un controllo umano obbligatorio sul cento per cento.
Risparmiare su questo passaggio è la falsa economia più costosa che esista.
Sottovalutare i costi di gestione
Un sistema AI in produzione non costa solo le chiamate API. Costa il tempo di manutenzione dei prompt (che vanno aggiornati quando i modelli cambiano), costa il monitoraggio della qualità degli output (che richiede metriche e dashboard), costa la formazione degli utenti interni (che devono sapere quando fidarsi del sistema e quando no), costa la gestione delle eccezioni (i casi in cui il sistema sbaglia e qualcuno deve correggere).
In tutti i progetti che ho seguito, il costo di gestione mensile a regime è stato tra il 30% e il 70% del costo di build iniziale. Mensile. Non una tantum.
I budget enterprise spesso includono il build. Raramente includono la gestione. Il sistema parte bene, dopo sei mesi si degrada perché nessuno lo manutiene, dopo dodici viene abbandonato. È un pattern che vedo ripetersi.
Sopravvalutare l’AI, sottovalutare l’operatore
L’aspetto su cui ho cambiato più radicalmente opinione negli ultimi due anni è il seguente: il vantaggio competitivo dei progetti AI non sta nel modello scelto, sta in chi lo configura e nel processo dentro cui è inserito.
Lo stesso modello (Claude 4.7, GPT-5, Gemini 3, scegli quello che vuoi) in mano a un team che lo conosce produce risultati profondamente diversi rispetto allo stesso modello in mano a un team che lo sta scoprendo. Il delta di performance è di 5-10 volte, su task realistici.
Questo significa che investire in formazione del team, in pratiche di prompt engineering, in metodologia di valutazione, vale molto di più che cambiare modello ogni sei mesi sperando che il nuovo risolva i problemi che il precedente non risolveva.
Per le aziende italiane, che hanno spesso budget limitati e team piccoli, la lezione è netta: meglio tre persone che padroneggiano un modello bene, che dieci che usano cinque modelli in modo approssimativo. La community AIPIA, sui percorsi formativi, ha strutturato proprio attorno a questa idea il programma EDC: padroneggiare il mestiere, non collezionare strumenti.
Vendere risultati prima di averli verificati
L’ultimo errore, che ho fatto e che vedo fare regolarmente, è la fretta nel comunicare risultati. Un pilot funziona bene per quattro settimane, viene presentato al board come case study di successo, l’azienda annuncia il rollout aziendale. Tre mesi dopo, in produzione su scala reale, i risultati non si replicano. Le ragioni sono mille, tutte abbastanza prevedibili: il pilot girava su dati selezionati, su utenti motivati, in contesti controllati. La realtà operativa è disordinata.
Il pilot dura almeno tre mesi, idealmente sei. Il rollout viene comunicato dopo, non prima. La differenza tra annunciare presto e annunciare al momento giusto è la credibilità che si conserva nei progetti successivi.
Ognuno di questi errori, presi singolarmente, sembra banale. Eppure continuo a vederli replicati anche in aziende che hanno investito milioni in trasformazione digitale. Il problema non è la tecnologia. È che la disciplina necessaria per usarla bene è una disciplina lenta, fatta di pazienza, di metodo, di verifica. Esattamente l’opposto di quello che il mercato comunicativo sull’AI ha raccontato negli ultimi tre anni.
