Primo progetto AI in azienda: come sceglierlo e portarlo in produzione

Il primo progetto AI in azienda dovrebbe partire da un solo processo ripetitivo che il Suo team gestisce già in un sistema esistente, come lo smistamento delle richieste di assistenza. Un processo di questo tipo si misura prima e dopo e ha un responsabile. Per questo arriva in produzione. Una piattaforma AI generica, invece, resta spesso una prova senza esito.

Un primo progetto AI è un intervento limitato nel tempo che affida a un modello linguistico una parte precisa di un processo aziendale. Ha un risultato misurabile e si chiude con una decisione esplicita: passare in produzione oppure fermarsi. La decisione si prende su numeri raccolti in azienda, non su impressioni.

Gli elementi che rendono un primo progetto AI governabile sono quattro:

• Un processo: uno solo, ripetitivo, già tracciato in un sistema come l'helpdesk o il CRM.
• Una base misurata: i numeri di oggi, raccolti prima di toccare qualcosa.
• Un pilota con soglia: un periodo di prova con un criterio di successo fissato in anticipo.
• Costi e responsabilità: chi paga cosa, chi decide e chi controlla il risultato.

Le sezioni che seguono affrontano questi quattro elementi uno alla volta. Il filo conduttore è un esempio concreto: lo smistamento dei ticket di assistenza. Ogni sezione si può leggere da sola.

Una piattaforma AI generica raramente arriva in produzione perché non ha un compito preciso da svolgere. Per piattaforma generica si intende uno strumento di intelligenza artificiale messo a disposizione di tutti i dipendenti, senza un processo di riferimento. Ognuno lo usa a modo suo, e nessuno può dire con precisione cosa sia cambiato.

I problemi di una piattaforma generica come primo progetto sono tre:

• Manca una base di confronto: senza un processo definito non esiste un numero di partenza da migliorare.
• Manca un responsabile: se lo strumento serve a tutti, nessuno risponde del risultato.
• Manca il collegamento con il lavoro reale: i dati restano nel sistema aziendale, mentre l'AI lavora altrove.

Un processo già gestito in un sistema esistente risolve tutti e tre i problemi. Lo storico è già registrato, quindi la base di confronto esiste. Il processo ha già un responsabile, cioè chi oggi ne risponde. Il modello lavora dove il lavoro accade, per esempio dentro l'helpdesk, invece che in una finestra separata.

Questo non significa rinunciare agli strumenti per il lavoro individuale. Significa che il primo progetto misurabile non deve coincidere con la distribuzione di licenze. La differenza tra una prova e un sistema che lavora ogni giorno è spiegata anche nel post su come passare dal progetto AI al sistema in produzione.

Il processo giusto per un primo progetto AI è ripetitivo, già registrato in un sistema, verificabile e con un errore recuperabile. La tabella seguente serve da lista di controllo. Applichi ogni riga ai due o tre processi candidati e scelga quello che soddisfa più criteri.

Lo smistamento delle richieste di assistenza soddisfa quasi sempre tutti e sei i criteri. Per questo è un buon esempio da seguire. Processi come l'estrazione di dati dalle email o la classificazione dei documenti in arrivo hanno spesso lo stesso profilo. Una panoramica degli usi possibili per tipo di impresa si trova nella guida su come ogni azienda può usare l'AI.

Lo smistamento dei ticket consiste nel leggere ogni nuova richiesta di assistenza e decidere a quale reparto e con quale priorità deve andare. Prendiamo un'azienda che riceve le richieste in Zoho Desk. Oggi un operatore legge ogni ticket e lo assegna a mano. Quando sbaglia, il ticket rimbalza tra reparti e il cliente aspetta.

Il primo progetto AI su questo processo segue quattro passaggi:

1. Il ticket arriva in Zoho Desk come oggi, senza cambiare canali né moduli per il cliente.
2. Il modello legge oggetto, testo ed eventuali allegati e propone reparto e priorità, con una breve motivazione.
3. L'operatore conferma o corregge la proposta durante il pilota, e ogni correzione viene registrata.
4. Il sistema confronta la proposta del modello con il reparto a cui il ticket è arrivato alla fine.

I modelli Claude attuali sono adatti a questo compito per ragioni documentate. Secondo la panoramica dei modelli di Anthropic, tutti i modelli correnti accettano testo e immagini in ingresso. Supportano più lingue, la visione e l'uso di strumenti. L'uso di strumenti (tool use) è la capacità del modello di chiamare funzioni esterne, per esempio per scrivere il reparto proposto nel ticket.

La visione conta perché molti clienti allegano uno screenshot invece di descrivere il problema. Il supporto multilingue conta per chi riceve richieste anche in inglese o in tedesco. Il punto essenziale, però, è un altro. Il processo resta dove era: stesso helpdesk, stessi reparti, stesso responsabile. Cambia solo chi fa la prima proposta.

La base misurata è l'insieme dei numeri che descrivono il processo oggi, raccolti prima di attivare qualsiasi modello. Senza questa base nessun risultato del pilota si può interpretare. Nel caso dello smistamento dei ticket, i dati si trovano già nello storico dell'helpdesk.

Per lo smistamento conviene contare quattro grandezze:

• Volume: quanti ticket arrivano in un periodo di riferimento.
• Riassegnazioni: quanti ticket cambiano reparto dopo la prima assegnazione.
• Tempo alla prima assegnazione: quanto passa tra l'arrivo del ticket e la sua assegnazione.
• Tempo dell'operatore: quante ore alla settimana il team dedica allo smistamento.

Il periodo di riferimento deve includere i picchi normali dell'attività, non solo una settimana tranquilla. Fissi anche le regole di conteggio per iscritto, per esempio cosa vale come riassegnazione. La stessa regola andrà applicata durante il pilota.

In Svennis, prima di collegare qualsiasi modello, chiediamo al cliente lo storico dei ticket con il reparto finale di ciascuno. Su quello storico confrontiamo le proposte del modello, così la qualità è nota prima che il modello tocchi un solo ticket reale.

Questo confronto sullo storico è una valutazione a costo basso. Mostra in anticipo dove il modello sbaglia, per esempio su categorie ambigue o su reparti con pochi ticket. Quelle categorie si possono escludere dal pilota, invece di scoprirle con i clienti.

Un pilota con soglia è un periodo di prova in cui l'azienda fissa in anticipo il risultato minimo per andare in produzione. La soglia si decide prima di iniziare, sulla base dei numeri raccolti nella base misurata. Deciderla dopo, guardando i risultati, rende il pilota inutile.

Per lo smistamento dei ticket il pilota procede di solito in tre fasi:

1. Fase in ombra: il modello propone il reparto, ma nessuno applica la proposta. Si misura solo la concordanza con le scelte degli operatori.
2. Fase assistita: l'operatore vede la proposta e la conferma o la corregge. Si misurano correzioni e tempo risparmiato.
3. Fase autonoma limitata: il modello assegna da solo le categorie in cui ha superato la soglia. Le altre restano all'operatore.

Ogni passaggio di fase richiede il superamento della soglia fissata. Serve anche un criterio di arresto, scritto nello stesso documento. Un esempio: se le riassegnazioni superano il livello della base misurata, il pilota torna alla fase precedente.

In produzione servono poi approvazioni, registri delle decisioni e controllo dei costi. Il post su approvazioni, log e costi degli agenti AI in produzione descrive questi controlli nel dettaglio. Il pilota è il momento giusto per prepararli, non il giorno dopo il lancio.

Per il pilota conviene partire da Claude Opus 5.5 e valutare poi un modello più economico sulle categorie semplici. È la stessa indicazione di Anthropic: chi non sa quale modello scegliere dovrebbe iniziare con Opus 5.5 per la maggior parte dei carichi di lavoro. Anthropic dichiara che Opus 5.5 costa il 40% in meno da eseguire rispetto a Opus 5.

I prezzi si esprimono in token, cioè le unità di testo che il modello legge e scrive, e si pagano per milione. La tabella riporta i dati della panoramica dei modelli.

La data di ritiro conta per un progetto che deve durare. Claude Haiku 4.5 costa meno, ma la sua data di ritiro è la più vicina. Un pilota che parte su Haiku 4.5 va quindi pianificato con un cambio di modello.

La pagina di Anthropic su come scegliere il modello descrive due leve di costo. Il parametro di effort (sforzo) scambia capacità di ragionamento con latenza e costo nello stesso modello. Su Opus 5.5 il valore predefinito è medio. La strategia multi-modello affianca un modello economico a uno più potente, così la maggior parte dei token viene fatturata alla tariffa più bassa.

I costi di un primo progetto AI non si limitano ai token del modello. Quelli sono spesso la voce più piccola e la più facile da stimare. Le altre voci vanno scritte prima del pilota, con un importo o un monte ore per ciascuna.

Le voci di costo tipiche di un pilota sono quattro:

• Uso del modello: token in ingresso e in uscita, calcolati sul volume della base misurata e sui prezzi della tabella precedente.
• Integrazione: il lavoro per collegare il modello al sistema esistente, per esempio all'helpdesk.
• Tempo interno: le ore degli operatori che confermano, correggono e segnalano i casi dubbi.
• Controllo continuo: chi guarda i risultati ogni settimana e con quale strumento.

Le responsabilità vanno assegnate con la stessa precisione. Il responsabile del processo decide la soglia e firma il passaggio in produzione. L'IT risponde dell'integrazione, degli accessi e dei registri. Chi segue la protezione dei dati valuta cosa entra nel modello. Il fornitore esterno, se c'è, risponde di ciò che ha costruito e della sua manutenzione.

Scriva queste assegnazioni in un documento di una pagina, con nomi e non con ruoli generici. Se una voce resta senza nome, il pilota non è pronto a partire. Questa semplice verifica evita la situazione più comune: un sistema funzionante che nessuno controlla dopo il lancio.

Per un'azienda italiana il primo progetto AI tocca quasi sempre dati personali, e quindi rientra nel GDPR. Un ticket di assistenza contiene nomi, indirizzi email, numeri di telefono e a volte dettagli sulla situazione del cliente. Prima del pilota coinvolga chi in azienda segue la protezione dei dati, e documenti quali campi del ticket vengono inviati al modello.

Un processo limitato rende questa valutazione più semplice. Con un solo processo si sa esattamente quali dati entrano, per quale scopo e chi vede il risultato. Con una piattaforma generica, invece, ogni dipendente decide da sé cosa inserire.

Conta anche il canale da cui si usa il modello. Secondo la documentazione di Anthropic, i modelli sono disponibili tramite la Claude API e anche tramite Amazon Bedrock, Google Cloud, Microsoft Foundry e Claude Platform on AWS. Molte aziende scelgono il canale del fornitore cloud con cui hanno già un contratto e condizioni verificate.

Oltre al GDPR c'è il regolamento europeo sull'intelligenza artificiale. Il testo è disponibile nella nostra versione annotata in italiano dell'AI Act. Il quadro più ampio, con le altre norme applicabili in Italia, è raccolto nella pagina sul quadro normativo AI in Italia. Per un uso specifico e dubbio, la verifica spetta al consulente legale dell'azienda.

Il primo passo concreto è scegliere un processo candidato e verificarlo con i sei criteri di questa guida. Non serve un budget approvato né un fornitore scelto per farlo. Serve un'ora con chi oggi gestisce il processo.

La sequenza consigliata è questa:

1. Elencare due o tre processi candidati già gestiti in un sistema esistente, come l'helpdesk o il CRM.
2. Applicare la tabella dei criteri e scegliere un solo processo.
3. Estrarre lo storico e calcolare la base misurata con regole di conteggio scritte.
4. Fissare la soglia e il criterio di arresto prima di attivare il modello.
5. Assegnare costi e responsabilità con nomi precisi, in un documento di una pagina.
6. Coinvolgere chi segue la protezione dei dati e scegliere il canale di accesso al modello.

Se non è chiaro da quale processo partire, un punto di partenza utile è la valutazione di prontezza all'AI della Sua azienda. Le domande riguardano processi, dati e sistemi già in uso. Le risposte indicano dove un primo progetto ha più probabilità di arrivare in produzione.