Intelligenza artificiale
Cosa cambia davvero quando un modello linguistico entra in un prodotto
La chiamata a un modello linguistico occupa poche righe di codice. Tutto quello che serve perché quella funzione resti accesa dopo il primo mese di utenti reali ne occupa molte di più. Qui raccontiamo cosa sta intorno alla chiamata: recupero dei dati, validazione dell'output, valutazione della qualità, costo che cresce con il traffico e vincoli sul trattamento dei dati personali.
Fra una demo che convince e una funzione che regge il traffico
Una demo di intelligenza artificiale si costruisce in un pomeriggio. Si sceglie un modello, si scrive un prompt, si mostra l'output a chi deve decidere. Convince quasi sempre, perché nella demo l'input lo scegli tu: provi finché la risposta è buona e mostri quella. In produzione l'input lo scrive l'utente, che abbrevia, incolla testo sporco, chiede cose fuori tema o prova a far dire al modello qualcosa di assurdo per curiosità.
La chiamata al modello resta la parte semplice: una richiesta HTTP con una chiave, un corpo JSON e una risposta da leggere. Il lavoro sta nei tre strati intorno. Cosa mandi al modello, cioè quali dati recuperi e in che formato li passi. Cosa fai di quello che torna, cioè come lo validi e cosa mostri all'utente quando la risposta è inutilizzabile. Quanto ti costa ogni volta che qualcuno preme il pulsante, moltiplicato per tutti gli utenti che speri di avere.
Cambia anche il modo di ragionare sul software. Un endpoint tradizionale, a parità di input, restituisce sempre lo stesso output, e il test lo verifica con un confronto secco. Un modello linguistico si comporta in modo diverso: due chiamate identiche producono risposte diverse, entrambe accettabili oppure entrambe sbagliate. E l'errore arriva come frase ben scritta e plausibile che afferma una cosa falsa, senza eccezioni e senza stack trace. Nessun sistema di monitoraggio se ne accorge da solo.
Da qui una regola pratica che usiamo quando stimiamo il lavoro: il codice deterministico intorno alla funzione IA pesa più della funzione IA. Recupero dei dati, validazione dello schema di uscita, ritentativi, comportamento di riserva, tetti di spesa, log, gestione del consenso. Chi pianifica solo l'integrazione dell'API sta pianificando meno della metà.
Quando l'AI per aziende porta valore e quando è solo un costo
Prima di scrivere una riga, conviene capire se il compito appartiene alla categoria giusta. Questi sono i casi in cui, nella nostra esperienza, un modello linguistico ripaga il lavoro di integrazione, e quelli in cui aggiunge costo e fragilità senza migliorare il prodotto.
Testo lungo che deve diventare una decisione breve
Riassumere una conversazione, classificare una richiesta in arrivo, estrarre l'intenzione da un messaggio libero. Il modello riduce il lavoro umano su materiale che nessuno avrebbe letto comunque, e un errore occasionale si assorbe.
Dati non strutturati da portare dentro uno schema
Fatture, email, schede prodotto scritte da fornitori diversi, note in testo libero. Qui il modello fa quello che le espressioni regolari fanno male: interpretare varianti infinite dello stesso concetto. L'output va comunque validato contro uno schema rigido.
Assistenza su un dominio chiuso e documentato
Un chatbot aziendale ha senso quando risponde su materiale tuo, aggiornato e recuperabile: manuali, listini, procedure. Il valore nasce dal recupero dei documenti giusti, ed è quella parte a determinare la qualità della risposta.
Personalizzazione che dipende da troppe variabili per essere tabellata
Quando le combinazioni di input esplodono e scrivere tutte le regole a mano diventa impraticabile, il modello copre lo spazio intermedio. È il caso della generazione dei piani personalizzati in DietApp.
Regole deterministiche travestite da intelligenza artificiale
Calcolare la disponibilità di un ombrellone su una mappa, oppure gli slot liberi di un operatore in base a turni, chiusure e durata effettiva del servizio, è algoritmica pura. In Beachfy e in BarbierItalia quella parte non passa da nessun modello: sarebbe più lenta, più cara e meno affidabile del codice che la calcola.
Il chatbot generico messo in home page perché lo hanno tutti
Se risponde su contenuti già presenti in tre voci di menu, aggiunge un canale di supporto da presidiare e una superficie di errore pubblica. Il costo si concentra nel presidio nel tempo, che prosegue dopo l'implementazione.
Compiti senza tolleranza all'errore e senza revisione umana
Calcoli fiscali, importi, adempimenti, qualsiasi output che diventa un obbligo verso terzi. Se nessuno rilegge prima che la risposta produca effetti, il modello va tenuto fuori da quel punto del flusso.
Il contesto è il vero lavoro: recuperare i dati giusti e passarli in modo affidabile
Il lavoro vero sta nella selezione dei dati che finiscono nel prompt; scrivere le istruzioni richiede molto meno tempo. Un modello non conosce il tuo catalogo, i tuoi prezzi, lo storico di quell'utente e le regole del tuo dominio: conosce solo quello che gli metti davanti in quella singola richiesta. La qualità della risposta dipende quasi interamente dalla pertinenza di quel materiale.
La tentazione iniziale è mandare tutto e lasciare che sia il modello a scegliere. Non funziona per tre motivi che si sommano: il costo cresce con la quantità di testo inviato, la latenza pure, e il rumore peggiora la risposta perché l'informazione utile si diluisce fra dati irrilevanti. Serve un recupero mirato, che seleziona pochi frammenti davvero attinenti alla domanda e li ordina in modo prevedibile.
Il formato conta quanto il contenuto. Passare i dati con etichette stabili, chiedere una struttura di uscita esplicita e validarla al ritorno rende la funzione governabile: se la risposta non rispetta lo schema, la scarti e riprovi invece di mostrarla all'utente. Il prompt va trattato come codice, quindi versionato, rivisto e collegato ai casi con cui lo verifichi. Senza quella disciplina nessuno saprà più perché una modifica di tre parole ha cambiato il comportamento in produzione.
Una separazione va tenuta ferma: le istruzioni le scrivi tu, tutto il resto è dato. Il testo che arriva da un utente, da un documento caricato o da una pagina esterna può contenere frasi costruite per dirottare il comportamento del modello. Se quella funzione ha il permesso di scrivere sul database, inviare messaggi o spendere soldi, un'istruzione nascosta dentro un allegato diventa un problema di sicurezza. Le azioni con effetti reali restano dietro una conferma esplicita o dietro codice deterministico.
Resta il tema della freschezza. Quando il modello risponde su listini, orari o disponibilità, la fonte deve essere quella viva, aggiornata al momento della richiesta e mai una copia congelata in un prompt scritto mesi prima. In caso contrario la funzione continuerà a rispondere con sicurezza usando dati che nel frattempo sono cambiati, e l'utente non avrà modo di accorgersene.
I problemi da risolvere prima di rilasciare una funzione basata su un modello
Questa è la lista che compiliamo prima di considerare pronta un'integrazione. Nessuno di questi punti si risolve scrivendo un prompt migliore.
Output non deterministico
La stessa richiesta produce testi diversi. Va deciso cosa è accettabile: struttura fissa e formulazione variabile, oppure valori che devono coincidere sempre. Nel secondo caso il calcolo esce dal modello e passa al codice. Dove serve stabilità percepita, la risposta si salva e si riusa invece di rigenerarla a ogni apertura della schermata.
Errori plausibili
Un modello non segnala la propria incertezza in modo affidabile: sbaglia con lo stesso tono con cui ha ragione. Servono controlli deterministici sull'uscita, vincoli verificabili e un comportamento di riserva quando il controllo fallisce. Mostrare una schermata onesta di indisponibilità è preferibile a mostrare una risposta credibile e falsa.
Latenza percepita
La generazione richiede secondi interi, e l'attesa si nota. Lo streaming della risposta, l'anticipo delle richieste prevedibili e una cache sui casi ripetuti cambiano l'esperienza più di qualsiasi ottimizzazione del prompt. Le funzioni lente vanno collocate dove l'utente si aspetta un'elaborazione, e tenute fuori da un tap che dovrebbe essere immediato.
Costo per richiesta che cresce con gli utenti
Il costo delle API dei modelli linguistici è variabile e proporzionale all'uso, quindi si comporta come una voce di consumo e non come una licenza fissa. Va misurato per singola azione dell'utente e proiettato sulla crescita: una funzione sostenibile con pochi utenti attivi può diventare la voce di spesa dominante proprio quando il prodotto inizia a funzionare. Servono tetti di spesa, limiti per utente, cache e una scelta consapevole di quali richieste meritano il modello più costoso.
Dipendenza da un fornitore esterno
Disservizi, limiti di frequenza, modifiche ai termini e aggiornamenti del modello arrivano dall'esterno e non li governi. L'accesso va isolato dietro una tua interfaccia, in modo che cambiare fornitore significhi sostituire un adattatore e rilanciare la valutazione, senza riscrivere il prodotto.
Dati personali e GDPR
Inviare testo a un servizio esterno è un trattamento, con base giuridica, informativa, responsabile esterno e trasferimenti da documentare. Vanno definiti quali campi escono davvero, per quanto tempo il fornitore li conserva e se possono essere usati per l'addestramento. La minimizzazione qui è anche una scelta tecnica: si manda il minimo indispensabile a ottenere la risposta.
Valutare la qualità quando non esiste una risposta giusta unica
Il test tradizionale confronta l'output atteso con l'output ottenuto. Su una funzione generativa questo confronto non si applica quasi mai: due formulazioni diverse possono essere entrambe corrette, e una identica alla precedente può essere sbagliata nel contesto nuovo. Serve un impianto di valutazione diverso, e va costruito prima del rilascio, non dopo il primo reclamo.
Il punto di partenza è un insieme di casi reali, raccolti dal dominio e non inventati a tavolino: richieste tipiche, richieste ambigue, richieste malevole, casi limite già noti. Quell'insieme diventa il banco di prova stabile su cui far girare ogni modifica del prompt, del recupero dei dati o del modello. Senza quel banco, ogni cambiamento è una scommessa e ogni miglioramento resta un'impressione.
La valutazione si fa a due livelli. Il primo è automatico e deterministico: la risposta rispetta lo schema, i vincoli numerici tornano, i valori vietati non compaiono, i riferimenti citati esistono davvero. Questi controlli intercettano la maggior parte dei guasti gravi e costano poco. Il secondo livello è il giudizio su ciò che resta, applicato su un campione con criteri scritti prima della lettura: pertinenza, completezza, tono, assenza di affermazioni non supportate dai dati forniti.
Un'attenzione va riservata alle regressioni. Quando il fornitore aggiorna il modello sotto la stessa interfaccia, il comportamento cambia senza che tu abbia toccato nulla. Rilanciare il banco di prova a intervalli regolari, e non soltanto quando modifichi il codice, è l'unico modo per accorgersene prima degli utenti.
Restano i segnali di prodotto, che spesso valgono più della valutazione interna: quante volte l'utente rigenera la risposta, quante volte la corregge a mano, quante volte abbandona la schermata subito dopo averla ricevuta. Sono misure a basso costo e indicano con precisione dove la funzione non sta reggendo.
Dall'idea alla produzione: quattro fasi con una valutazione esplicita
Questo è il percorso che seguiamo quando un cliente chiede di integrare intelligenza artificiale in un'app esistente. La terza fase è quella che viene saltata più spesso ed è quella che decide l'esito.
- 01
Definire il compito e il criterio di fallimento
Si scrive per iscritto cosa deve fare la funzione, su quali dati lavora, quale output produce e soprattutto cosa si considera una risposta sbagliata. Se non si riesce a definire il fallimento, non si riuscirà né a valutare la funzione né a decidere quando spegnerla. Qui si stabilisce anche chi vede l'output e se qualcuno lo rilegge prima che produca effetti.
- 02
Prototipo con dati veri e con i casi difficili
Il prototipo si costruisce sui dati reali del dominio, non su esempi puliti. Si verifica la fattibilità sui casi limite raccolti nella fase precedente e si misurano subito costo medio e latenza di una singola richiesta. Molte idee si fermano qui, ed è il momento più economico perché accada.
- 03
Valutazione strutturata prima di costruire l'interfaccia
Si consolida il banco di prova, si aggiungono i controlli automatici sull'uscita e si confrontano le versioni del prompt e del recupero dati sulle stesse richieste. Solo quando i risultati sono stabili si passa alla parte visibile. Investire in grafica prima di questa fase significa rifarla.
- 04
Rilascio graduale con limiti, log e misura
La funzione parte su una quota di utenti, con tetto di spesa, limiti per utente, registrazione anonimizzata delle richieste e un interruttore per disattivarla senza pubblicare una nuova versione. Si osservano costo reale, tasso di errore e comportamento degli utenti, poi si allarga. Una funzione IA va presidiata nel tempo, ben oltre il giorno della consegna.
Il caso DietApp: piano alimentare, assistente in chat e stima da foto
DietApp è un nostro prodotto, pubblicato su Google Play il 26 settembre 2025 e oggi oltre i cinquecento download. Genera piani alimentari personalizzati a partire da età, peso, altezza, livello di attività, obiettivo e alimenti esclusi, e ricalcola quando il peso o l'obiettivo cambiano. È l'esempio più utile che possiamo portare, perché contiene tre funzioni IA molto diverse fra loro e ognuna ha richiesto un compromesso differente.
La generazione del piano è il caso in cui il modello lavora meno di quanto sembri. Il ricettario contiene oltre quattrocento ricette italiane con i valori nutrizionali già calcolati: i numeri li produce il database, non il modello. Al modello resta la composizione, cioè scegliere e combinare rispettando i vincoli dell'utente. Questa separazione è la decisione tecnica più importante del prodotto, perché sposta fuori dal modello tutto ciò che deve essere esatto e lascia dentro solo ciò che può essere variabile. Un vincolo come l'esclusione di un alimento diventa così verificabile con codice deterministico prima che il piano venga mostrato.
L'assistente in chat, che nell'app si chiama Bianca, ha un perimetro dichiarato: sostituzioni fra alimenti e chiarimenti sulle porzioni. Il perimetro stretto resta una scelta deliberata e stabile nel tempo. Un assistente che accetta qualsiasi domanda in ambito alimentare finisce per rispondere su patologie e terapie, e quel terreno richiede una competenza clinica che un'app non ha e non deve simulare.
La stima di calorie e macronutrienti da una foto del piatto è la funzione più delicata, perché il margine di errore è strutturale: la fotografia non contiene il peso degli ingredienti né i condimenti nascosti. Va comunicata per quello che è, una stima con cui orientarsi, e mai come una misura. Il modo in cui il numero viene presentato nell'interfaccia fa parte della correttezza della funzione tanto quanto l'accuratezza del modello.
Il contesto sanitario impone il resto dei vincoli. DietApp non è un dispositivo medico e lo dichiara con disclaimer espliciti; i dati sanitari rientrano nell'articolo 9 del GDPR e vengono trattati con consenso specifico; le immagini delle ricette sono dichiarate come generate con intelligenza artificiale, perché lasciare credere che siano fotografie di piatti reali sarebbe fuorviante. Chi vuole vedere come questi vincoli si traducono nell'interfaccia trova l'app su diet-app.it e la scheda del progetto nel portfolio.
Domande frequenti sull'integrazione dell'intelligenza artificiale nei prodotti
Il costo si divide in due voci con logiche opposte. Lo sviluppo è una spesa una tantum e dipende da quanti dati vanno recuperati e integrati, da quanto è rigido l'output richiesto e dal livello di valutazione necessario prima del rilascio. Il consumo delle API dei modelli linguistici è invece ricorrente e variabile, proporzionale al numero di richieste e alla quantità di testo scambiato: cresce con gli utenti attivi. Prima di firmare un preventivo conviene stimare il costo di una singola azione dell'utente e moltiplicarlo per il traffico che si spera di raggiungere, non per quello attuale.
Per la quasi totalità dei prodotti l'API è la scelta corretta: nessun costo infrastrutturale fisso, nessuna manutenzione, accesso immediato a modelli aggiornati. Addestrare o ospitare un modello proprio ha senso quando i dati non possono uscire dall'infrastruttura per vincoli normativi o contrattuali, oppure quando il volume di richieste rende il costo variabile superiore a quello di un'infrastruttura dedicata. In entrambi i casi l'accesso va isolato dietro una propria interfaccia, così da poter cambiare strategia senza riscrivere il prodotto.
Riducendo lo spazio in cui può sbagliare. Il perimetro delle domande ammesse va dichiarato, i contenuti su cui risponde devono essere tuoi, aggiornati e recuperati al momento della richiesta, e la risposta deve poter citare la fonte da cui proviene. Quando il recupero non trova materiale pertinente, la risposta corretta è dire che l'informazione non è disponibile e offrire un contatto umano. Un assistente che ammette di non sapere vale più di uno che risponde sempre.
Dipende dal fornitore e dal piano contrattuale, e va verificato nei termini prima dell'integrazione, non dopo. Molti servizi rivolti agli sviluppatori escludono i dati delle API dall'addestramento, ma restano da valutare la conservazione temporanea per motivi di sicurezza, la localizzazione dei server e il trasferimento fuori dall'Unione Europea. In ogni caso vale la minimizzazione: quello che non invii non ha bisogno di garanzie contrattuali.
Molto più di quanto suggerisca il prototipo, perché le due cose misurano lavori diversi. Il prototipo dimostra che il modello sa fare il compito nei casi favorevoli; la produzione richiede recupero dati affidabile, validazione dell'output, comportamento di riserva, controllo dei costi, valutazione ripetibile e conformità sul trattamento dei dati. Il momento migliore per accorgersi che un'idea non regge è la fase di valutazione: fermarsi lì costa una frazione di quello che costa disattivare una funzione già annunciata agli utenti.