Nove mesi fa hai visto una demo che sembrava perfetta. Il prototipo rispondeva alle domande, mostrava grafici e prometteva di liberare ore di lavoro ogni settimana. Poi le settimane sono passate e il codice non arrivava, i costi restavano incerti e non avevi un modo chiaro per decidere se continuare o fermarti.
Solo il 22% delle organizzazioni ha portato l’AI su scala in più unità di business. Secondo un’analisi recente, circa metà dei progetti GenAI si blocca prima di arrivare in produzione. Il problema raramente è la tecnologia, manca un percorso con tappe controllabili e documenti verificabili a ogni passo.
Il punto è semplice, puoi controllare un progetto di SaaS con intelligenza artificiale anche se non sai leggere una riga di codice. Basta sapere quale documento chiedere a ogni fase e quando dire sì, no o non ancora.
Si parte dalla prima fase e non è quella che molti si aspettano.
Da dove parte un SaaS con AI: dal modello o dal business?
Il progetto parte dal business, non dal modello. Chi inizia dal modello rischia di inseguire idee senza valore misurabile.
La fase Learn è una sessione strategica. Serve a capire come funziona l’azienda, dove guadagna e dove perde tempo. In questa fase si definisce anche cosa significa SaaS: un software accessibile via web, con abbonamento ricorrente e aggiornamenti centralizzati.
Il business case collega il problema a metriche precise. Il ROI atteso indica quanto l’azienda si aspetta di guadagnare o risparmiare. Il costo di inferenza è quanto costa ogni risposta che il modello produce, l’AI ha un costo che cresce con l’uso, quindi va previsto prima di scrivere codice.
Il documento consegnato è l’architettura del prodotto, sono 15-20 pagine scritte in linguaggio imprenditoriale, con tempi e costi definiti. Resta tuo anche se decidi di non proseguire.
Come vedi, questo documento ti permette di dire sì, no o non ancora prima di scrivere codice. Il human-in-the-loop parte già qui: decide un referente dell’azienda, non l’algoritmo. Serve una persona che prenda le decisioni.
Esempio pratico
Un’azienda di 30 persone vuole un assistente per il supporto clienti. Il business case collega il problema (richieste ripetitive che occupano ore) a due metriche: ROI atteso e costo di inferenza per conversazione. Il documento mostra che senza un referente interno e senza metriche scritte il progetto non può partire.
Controlla tre cose: esiste un referente interno, le metriche sono scritte in modo misurabile, i costi di inferenza sono stimati. Parti se hai un referente e una metrica da muovere. Aspetta se manca l’uno o l’altra.
Chi decide l’architettura quando l’AI scrive il codice?
L’architettura la decide un senior developer, l’intelligenza artificiale esegue, non inventa.
La fase Instruct è il momento in cui lo sviluppatore senior progetta struttura, dati e sicurezza e le fissa come regole vincolanti. L’architettura è l’insieme di scelte tecniche che definiscono come il software è organizzato e come comunica con gli altri sistemi.
Il documento consegnato è il Documento tecnico di progetto. Contiene schemi, scelte tecniche motivate e logiche di sicurezza. Include anche le regole di human-in-the-loop: quali azioni dell’AI richiedono approvazione di una persona.
Senza regole e limiti si rischia il vibe coding: uso dell’AI senza progetto né controlli. Casi documentati mostrano agenti in loop infinito o costi fuori controllo quando mancano questi vincoli. I limiti di costo e le approvazioni umane vanno decisi prima.
Ti facciamo un esempio. Un’azienda vuole un assistente per il supporto clienti. Il senior developer fissa il modello, l’architettura e le regole di approvazione nel documento tecnico. Il costo di inferenza si calcola così: 3.000 conversazioni al mese per 0,05 € ciascuna fanno 150 € al mese. Come vedi, il costo si prevede prima di scrivere una riga di codice.
Chiedi una riga nel contratto: chi progetta l’architettura e dove è scritta.
Perché sviluppare a sprint e non in un unico blocco?
A ogni sprint vedi il software funzionare e puoi correggere subito. Uno sprint è un ciclo di lavoro breve, di solito una o due settimane, che produce una versione verificabile.
La fase Build prevede una dashboard in tempo reale e demo di 30 minuti ogni settimana. Il documento consegnato è il Prototipo parziale: una versione funzionante che diventa sempre più completa.
Studi mostrano che lo sviluppo a cicli brevi riduce gli scostamenti di costi e tempi rispetto al modello a blocco unico. Il modello ibrido funziona così: il senior ha fissato il progetto, l’AI scrive seguendolo, test automatici e controllo manuale di sicurezza avvengono su ogni modulo prima della produzione.
I tempi indicativi dipendono da funzioni, integrazioni e dati. Si fissano per iscritto dopo l’analisi iniziale. La demo diventa il tuo punto di controllo settimanale. La domanda da fare ogni settimana è: questa versione fa quello che il business case chiedeva?
Come capisci che il SaaS è pronto per la produzione?
Lo capisci da un documento firmato che dice cosa è stato testato, come e con quali esiti.
La fase Evaluate prevede test di regressione e di carico, controllo di sicurezza manuale, prove con utenti reali dell’azienda e verifica della qualità del codice con un software indipendente. Il test di carico verifica come risponde il sistema quando il numero di richieste aumenta. Il documento consegnato è il rapporto di qualità e sicurezza firmato.
Un prototipo può sembrare a posto in laboratorio e deludere in uso. Per questo servono prove con utenti reali.
La fase Release comprende installazione, codice sorgente, credenziali, documentazione e due sessioni di formazione. Il documento consegnato è il Pacchetto Finale & Garanzia, con bug critici risolti gratis per 12 mesi senza assistenza obbligatoria. Le cinque chiavi della proprietà sono diritti, codice, accessi, documentazione e uscita libera.
Salvo cessione scritta, i diritti su un software commissionato restano di norma a chi lo sviluppa. Ogni contratto è diverso: fallo verificare da un legale prima di firmare.
Dopo il rilascio serve un piano di monitoraggio. Tra le organizzazioni con alta maturità AI, il 45% mantiene i progetti operativi per almeno tre anni. Il piano indica metriche tecniche e di business, costi e chi interviene quando le soglie vengono superate.
Come vedi, pronto significa documentato, testato e verificato da una persona, non solo funziona sul mio computer.
Evaluate: cosa viene verificato
Il rapporto firmato elenca test di regressione, test di carico, controlli di sicurezza e risultati delle prove con utenti reali.
Release: cosa ricevi
Il pacchetto include codice sorgente, credenziali, documentazione completa e piano di monitoraggio con soglie e responsabili.
Esempio pratico
Il prototipo di assistente clienti in demo risponde in media in 2 secondi. Nelle prove con utenti reali la media sale a 5 secondi. Il target era 3 secondi. Il team corregge il modulo prima del rilascio. Come vedi, senza quella prova l’avresti scoperto in produzione.
Il tuo piano: cinque documenti da chiedere prima di partire
Ogni fase lascia un documento controllabile. Il human-in-the-loop resta in ogni passaggio. Ogni scelta si misura prima di andare avanti.
- Chiedi l’Architettura del prodotto. Contiene ROI atteso e costi di inferenza. Controllo: tempi e costi sono scritti in modo misurabile?
- Chiedi il Documento tecnico di progetto. Contiene architettura e regole di approvazione umana. Controllo: le regole di human-in-the-loop sono esplicite?
- Chiedi il Prototipo parziale e verifica le demo settimanali. Controllo: ogni sprint produce una versione funzionante?
- Chiedi il Rapporto di qualità e sicurezza firmato. Controllo: include test con utenti reali e valutazione indipendente?
- Chiedi il Pacchetto Finale & Garanzia. Controllo: include cessione dei diritti e piano di monitoraggio?
Prima di firmare, chiedi quale documento esce da ogni fase e chi lo firma.
Se ti basta un software standard già esistente, usalo. Se nessuno in azienda può decidere e seguire il progetto, rimanda. Se vuoi pagare solo il prezzo più basso senza controlli, il rischio è tuo.