Da dove iniziare con l'AI in azienda:
una mappa pratica
Quali processi conviene automatizzare per primi, cosa serve davvero (dati, persone, budget) e come capire se un'idea è un buon candidato.
12 minuti di lettura
Il problema più comune non è scegliere lo strumento: è scegliere il primo problema. Quasi tutte le aziende che si bloccano nei primi sei mesi lo fanno per lo stesso motivo: partono da un progetto troppo grande, troppo critico o troppo vago. Questa guida è una mappa per evitarlo. Non parla di "trasformazione digitale", parla di cosa fare lunedì mattina.
La domanda giusta
non è "come usiamo l'AI?"
La domanda sbagliata è "come usiamo l'AI?". È sbagliata perché l'AI è una soluzione in cerca di un problema, e si finisce a inventare progetti per giustificare lo strumento. La domanda giusta è: "quali attività ci costano tempo ogni settimana, sono ripetitive e producono testo o dati?"
Le tre condizioni sono importanti tutte e tre insieme:
- Ripetitiva e frequente. Se un'attività capita due volte l'anno non vale la pena automatizzarla, anche se è noiosa.
- Basata su linguaggio o dati semi-strutturati. I modelli linguistici sono bravi con testo, email, documenti, PDF, tabelle disordinate. Non sostituiscono un software gestionale né un foglio di calcolo con formule esatte.
- A bassa criticità in caso di errore. Per il primo progetto non scegliete qualcosa dove un errore costa un cliente o una sanzione. Scegliete qualcosa dove un errore costa una rilettura.
Frequenza per impatto:
dove iniziare davvero
Prima di scegliere, classificate le attività candidate su due assi: frequenza (quanto spesso succede) e impatto del tempo risparmiato. Ne escono quattro zone.
| Bassa frequenza | Alta frequenza | |
|---|---|---|
| Basso impatto | Ignorare. Non vale lo sforzo. | Automatizzare con regole semplici, non serve AI. |
| Alto impatto | Valutare caso per caso, spesso meglio una persona. | Iniziare da qui. Massimo ritorno, rischio gestibile. |
Il quadrante in basso a destra è la vostra zona di partenza: cose che succedono spesso, dove ogni occorrenza vi ruba minuti che sommati fanno ore. Esempi tipici in una PMI: rispondere a richieste di informazioni ricorrenti, riassumere documenti tecnici o capitolati, estrarre dati da PDF di fornitori, tradurre corrispondenza commerciale, riformattare contenuti per canali diversi.
Come capire se un'idea
è un buon candidato
Per ogni idea che vi sembra promettente, fate passare cinque domande. Se rispondete "no" a una sola delle prime tre, fermatevi.
- L'input è disponibile in forma digitale? Se l'informazione vive solo nella testa di una persona o su fogli scritti a mano non scansionati, prima va digitalizzata.
- Esiste un "buon esempio" di come dovrebbe essere il risultato? Se nessuno in azienda sa dire com'è fatta una risposta giusta, il modello non potrà indovinarlo.
- L'errore è verificabile da una persona in pochi secondi? Serve qualcuno che riconosca a colpo d'occhio se l'output è sbagliato. Se serve un'ora per controllare, il risparmio sparisce.
- Il volume giustifica l'investimento? Stimate quante volte al mese accade e quanti minuti costa ogni volta. Sotto le poche ore al mese, spesso non conviene.
- Possiamo partire piccolo? L'idea va spezzata in una prima versione minima che dia valore da sola, senza dipendere dal resto.
Dati, persone, budget:
nell'ordine giusto
Dati
La parola "dati" spaventa più del dovuto. Per i primi progetti non serve un data lake né un progetto di integrazione. Serve che l'informazione di input sia accessibile e leggibile: una cartella di PDF, un foglio Excel esportabile, le email in una casella, i record di un gestionale che esporta in CSV. Il lavoro vero non è "avere tanti dati", è avere quei pochi dati che servono al caso d'uso, puliti abbastanza da essere usati.
Una verifica concreta: prendete dieci esempi reali dell'input. Se voi stessi, guardandoli, non riuscite a ricavarne l'output desiderato senza chiedere aiuto a un collega, il problema non è l'AI, è che le informazioni non bastano.
Persone
Il fattore più sottovalutato. Un progetto di AI in PMI ha bisogno di tre ruoli, che possono anche essere due persone:
- Chi conosce il processo (l'esperto di dominio). Sa com'è fatta una risposta giusta e riconosce gli errori. Senza di lui non si valida niente.
- Chi mette le mani sullo strumento (tecnico o smanettone interno). Non serve un data scientist: serve qualcuno a suo agio con un'API, un foglio di calcolo, uno script o un tool no-code.
- Chi decide e tiene il progetto piccolo. Il ruolo più importante è dire "questo è abbastanza, mettiamolo in uso" prima che il progetto cresca all'infinito.
Budget
Qui c'è la sorpresa più piacevole. Il costo dei modelli, oggi, è quasi sempre la voce minore. Le API dei modelli linguistici si pagano a consumo, a frazioni di centesimo per richiesta su modelli economici, e una prima sperimentazione seria costa spesso meno di una cena. Il costo vero è il tempo delle persone: capire il processo, preparare gli esempi, validare i risultati, integrare il tutto.
Regola pratica: per il primo progetto, mettete a budget zero per "comprare AI" e tutto il budget in ore di lavoro interne. Se il caso d'uso non regge senza spendere in licenze, probabilmente è troppo grande per essere il primo.
Una sequenza che funziona,
senza sprecare il tempo iniziale
- Settimane 1–2 — Lista e scelta. Mettete su carta 8–10 attività candidate, passatele dal test in cinque domande, sceglietene una. Una sola.
- Settimane 3–4 — Prototipo manuale. Prima di scrivere codice, provate il caso d'uso "a mano" usando un'interfaccia di chat: incollate un esempio reale e vedete se il modello produce un risultato accettabile. Se non funziona qui, non funzionerà automatizzato.
- Settimane 5–8 — Versione minima in uso. Automatizzate solo la parte che ha dato valore nel prototipo. Tenete una persona "nel ciclo" che controlla ogni output prima che venga usato.
- Mesi 3–4 — Misura e fiducia. Raccogliete numeri: quante volte l'output era giusto al primo colpo, quanto tempo avete risparmiato. Solo con i numeri potete decidere se allargare.
- Mesi 5–6 — Allargare o cambiare. Se i numeri sono buoni, riducete il controllo umano e passate al secondo caso d'uso. Se non lo sono, avete imparato tantissimo a costo bassissimo: cambiate idea senza rimpianti.
Cosa fa perdere
i primi sei mesi
- Partire dal progetto "strategico". Il caso d'uso che entusiasma la direzione è quasi sempre quello più complesso e rischioso. Tenetelo per dopo.
- Voler automatizzare tutto subito. "Nel ciclo umano" non è una sconfitta: è il modo corretto di partire. La fiducia si guadagna con i numeri, non in anticipo.
- Confondere demo e produzione. Una demo che funziona su tre esempi scelti bene non è un sistema che funziona su mille casi reali. La differenza è tutto il lavoro.
- Saltare la validazione. Senza qualcuno che dica "questo output è giusto / sbagliato", non saprete mai se lo strumento funziona, e prima o poi qualcuno si fiderà di una risposta sbagliata.
- Comprare la piattaforma prima di avere il problema. Le licenze annuali firmate prima del primo caso d'uso reale sono soldi che vincolano a una direzione non ancora verificata.
In sintesi
Scegliete un'attività ripetitiva, frequente, fatta di testo o dati, dove l'errore costa poco; provatela a mano prima di automatizzarla; tenete una persona a validare; misurate; poi decidete se allargare. I primi sei mesi non servono a costruire il sistema definitivo, servono a capire quale sistema vale la pena costruire.
Domande
frequenti
Quanto tempo serve per portare la prima automazione in uso?
Tipicamente da 4 a 8 settimane se si rispetta lo schema: 1–2 settimane per scegliere il caso, 2 per il prototipo a mano, 4 per la versione minima in uso. Più del codice, contano la disponibilità di una persona interna che valida e la qualità dei dati di esempio.
Quanto costa partire? Servono grossi budget per le licenze AI?
No, e questa è la sorpresa più piacevole: il costo dei modelli è quasi sempre la voce minore. Una prima sperimentazione su modelli economici costa frazioni di centesimo a richiesta — spesso meno di una cena. Il costo vero è il tempo interno per impostare e validare.
E se in azienda non c'è nessuno che sa programmare?
Per il primo caso d'uso non serve programmare. Basta un "smanettone" interno a suo agio con fogli di calcolo, API e tool no-code (Make, Zapier, n8n). Solo quando il caso d'uso si consolida e i volumi crescono ha senso passare a uno script su misura.
Cosa succede se il primo progetto non funziona?
Se lo si è tenuto piccolo, si è imparato moltissimo a costo bassissimo: quale tipo di processo non è adatto, quali dati mancano, dove sta davvero il dolore. Si cambia caso d'uso senza rimpianti. Il problema reale è quando si parte già con un progetto da sei mesi: lì il fallimento brucia tempo e fiducia.
Posso saltare la fase di prototipo manuale?
No. Se il caso d'uso non funziona quando provate a farlo a mano con la chat su 10 esempi reali, non funzionerà nemmeno automatizzato. Saltare questa fase è il modo più rapido di buttare giorni di lavoro sull'automazione di un caso che il modello non sa risolvere.
Vuoi un confronto
sul vostro caso?
Una chiamata di 30 minuti per orientarsi. Senza demo precostituite.
Scrivici a [email protected]