Intelligenza artificiale applicata a prodotti reali, non a demo
Progettiamo e integriamo funzioni con IA dentro app, siti e gestionali già in uso: assistenti in chat sui dati dell’azienda, lettura di documenti, analisi di immagini, automazione di passaggi manuali. Ogni funzione nasce con una misura della qualità, un costo per richiesta e un comportamento previsto per quando il modello sbaglia.
Quando l’intelligenza artificiale serve davvero e quando no
L’intelligenza artificiale per aziende viene raccontata come una scorciatoia buona per tutto. Non lo è. Un modello linguistico produce testo plausibile, non risposte garantite. Funziona bene dove il risultato viene poi letto da una persona, molto meno dove serve un valore esatto che nessuno andrà a controllare.
Serve davvero quando il compito è ripetitivo, il materiale di partenza è linguaggio o immagini e un margine di errore resta accettabile perché qualcuno rivede o corregge in un tocco. Rientrano qui la lettura di documenti che oggi qualcuno apre a mano, le risposte alle stesse venti domande dei clienti, la prima bozza di una scheda prodotto.
Non serve quando la logica si può scrivere in una regola. Calcolare un prezzo, verificare una disponibilità, applicare uno sconto: queste cose le fa il codice, in millisecondi, con lo stesso risultato a parità di dati in ingresso. Affidarle a un modello significa pagare di più, aspettare di più e introdurre un errore che prima non esisteva.
Prima di aggiungere una funzione di questo tipo facciamo due domande. Quale passaggio manuale sparisce davvero. Chi si accorge se la risposta è sbagliata, e cosa succede in quel caso. Se non c’è una risposta a entrambe, la funzione non va costruita.
Interventi di intelligenza artificiale che portiamo dentro un prodotto
Cinque tipi di lavoro che ricorrono più spesso. Sono descritti per quello che fanno, non per la tecnologia che usano.
Assistente in chat sui dati dell’azienda
Un chatbot AI che risponde sul catalogo, sul regolamento interno o sullo storico degli ordini, non su Internet. I documenti vengono indicizzati e recuperati al momento della domanda, così la risposta resta ancorata a una fonte che si può aprire e verificare.
Classificazione ed estrazione da documenti
Fatture, ordini, curriculum, email in arrivo. Il modello riconosce il tipo di documento e restituisce i campi in forma strutturata, pronti per entrare in un gestionale. Il beneficio si misura sulle ore di inserimento manuale che spariscono, non sulla tecnologia.
Generazione di contenuti strutturati
Descrizioni prodotto, riassunti, bozze di risposta, schede compilate a partire da pochi dati. L’output segue uno schema con campi obbligatori e limiti di lunghezza, e viene validato prima di essere salvato: se non rispetta lo schema, non passa.
Analisi di immagini
Riconoscere cosa mostra una foto, leggere un documento fotografato, stimare quantità a partire da uno scatto. È il caso della stima dei valori nutrizionali da una foto del piatto in DietApp, dove il risultato viene presentato come stima e resta modificabile a mano.
Automazione dei passaggi manuali
Automazione dei processi in cui il modello è un anello del flusso, mai il flusso intero: un evento fa partire la catena, il modello interpreta o riassume, il codice decide e registra. Il resto del percorso resta deterministico e tracciabile.
Come si integra un modello dentro un prodotto esistente
Integrare AI in app o in una piattaforma già in uso significa aggiungere una chiamata a un servizio esterno dentro un flusso che deve continuare a funzionare anche quando quel servizio non risponde. Il lavoro sta quasi tutto attorno al modello, non nel modello.
Il prompt è codice: sta nel repository, ha una versione, cambia con un rilascio e non a mano in produzione. I dati che gli arrivano sono la parte che decide la qualità della risposta: selezioniamo i documenti pertinenti, tagliamo quello che non serve e passiamo solo i campi necessari, perché ogni parola in più costa e allunga i tempi.
La qualità va misurata, altrimenti resta un’impressione. Prepariamo un insieme di casi reali con la risposta attesa e lo rilanciamo a ogni modifica del prompt o del modello, così un miglioramento su un caso non peggiora in silenzio gli altri. Il costo si calcola per singola richiesta e si moltiplica per l’uso previsto: dove il compito è semplice usiamo un modello più piccolo, dove le domande si ripetono mettiamo una cache, e impostiamo un tetto di spesa con avviso.
La latenza va progettata come parte dell’interfaccia. Una risposta che arriva in streaming si legge mentre si forma, un lavoro lungo va spostato in background con notifica a fine elaborazione. Il fallback, infine, va progettato con la stessa cura: se la chiamata va in timeout o l’output non rispetta lo schema, l’utente torna al percorso manuale con un messaggio chiaro, mai a una schermata vuota. Ogni errore finisce in un log che usiamo per correggere.
Cosa affidare al modello e cosa lasciare al codice
La distinzione che usiamo in fase di progettazione, con esempi presi da prodotti reali.
| Compito | Chi lo esegue | Motivo |
|---|---|---|
| Calcolare le calorie da alimento e grammi | Codice | Il risultato è deterministico e deve essere sempre lo stesso |
| Interpretare "due fette di pane e un caffè" | Modello | Il testo libero non ha una forma prevedibile |
| Applicare un listino o una tariffa di alta stagione | Codice | Una regola scritta si verifica con un test e non sbaglia |
| Riassumere venti recensioni in tre righe | Modello | Serve una sintesi, non una precisione al decimale |
| Decidere se una prenotazione è confermabile | Codice | La disponibilità è un vincolo, non un’interpretazione |
| Estrarre i campi da una fattura in PDF | Modello con validazione | Il layout cambia da fornitore a fornitore, i campi però si controllano |
DietApp, intelligenza artificiale dentro un prodotto in produzione
DietApp è un’applicazione Android dello studio, pubblicata su Google Play il 26 settembre 2025 e con oltre 500 download. È il posto dove le scelte descritte sopra si vedono applicate, con i vincoli di un ambito delicato come l’alimentazione.
La prima funzione genera il piano alimentare a partire da età, peso, altezza, livello di attività, obiettivo e alimenti da escludere, e lo ricalcola quando peso o obiettivo cambiano. Il modello lavora dentro binari calcolati dal codice: i valori nutrizionali delle oltre 400 ricette del ricettario sono già calcolati e non vengono inventati al momento della richiesta.
La seconda è Bianca, l’assistente in chat che risponde su sostituzioni, porzioni e organizzazione dei pasti. La terza stima calorie e macronutrienti da una foto del piatto: il risultato è presentato come stima, resta correggibile e non sostituisce la pesata.
Attorno a tutto questo c’è la parte meno appariscente e più importante. Il copy è deliberatamente non promozionale, i disclaimer sanitari sono ripetuti, l’app dichiara di non essere un dispositivo medico né una consulenza nutrizionale, e i dati sanitari sono trattati ai sensi dell’articolo 9 del GDPR con consenso esplicito. Approccio compliance-first: in ambito salute affrontiamo le regole prima di scrivere la funzione che usa un modello.
Il progetto è raccontato per esteso in DietApp, e l’app è online su diet-app.it (si apre in una nuova scheda).
Dall’idea alla funzione di intelligenza artificiale in produzione
Quattro fasi. Ognuna può concludersi con la decisione di non proseguire, che a volte è il risultato più utile.
Passo 1: Delimitare un caso d’uso solo
Definiamo una funzione precisa, i dati che ha a disposizione, chi la userà e come si riconosce una risposta buona da una sbagliata. Se il criterio di successo non si riesce a scrivere in una frase, il caso d’uso non è ancora pronto.
Passo 2: Prototipo misurabile
Costruiamo la prima versione con un insieme di casi reali e la risposta attesa per ciascuno. Qui si vede la qualità effettiva, il costo di una singola richiesta e il tempo di risposta. È anche il momento in cui emerge se basta una regola scritta a mano.
Passo 3: Integrazione nel prodotto
Portiamo la funzione dentro l’app o la piattaforma con validazione dell’output, limiti per utente, cache dove le richieste si ripetono, fallback al percorso manuale e registro degli errori. Il flusso deve restare usabile anche a modello spento.
Passo 4: Rilascio controllato e manutenzione
Attiviamo la funzione per una parte degli utenti, osserviamo costi, errori e usi imprevisti, poi estendiamo. Da lì in avanti resta un lavoro ricorrente: aggiornare i prompt, valutare modelli nuovi, rilanciare i casi di prova prima di ogni cambio.
Domande frequenti sull’intelligenza artificiale per aziende
I miei dati finiscono nell’addestramento dei modelli?
Dipende dal fornitore e dal piano contrattuale, e va verificato prima di scrivere una riga di codice. Sui piani per uso applicativo dei principali fornitori i dati inviati tramite API non vengono usati per addestrare, ma è una condizione contrattuale, non una legge di natura. In ogni caso inviamo solo i campi necessari e, dove possibile, pseudonimizzati: quello che non esce dal sistema non pone il problema. Mettiamo per iscritto quali dati escono, verso chi e per quanto tempo restano.
Quanto costa mantenere una funzione IA?
Ci sono due voci separate. Il consumo, che si paga a richiesta e cresce con l’uso, e la manutenzione, cioè aggiornamenti dei prompt, cambi di modello e correzioni. Senza volumi reali un prezzo sarebbe inventato, quindi la stima arriva dal prototipo: lì si misura il costo di una singola chiamata e lo si moltiplica per l’uso previsto. Nel frattempo riduciamo la spesa con modelli più piccoli sui compiti semplici, cache sulle richieste ripetute e un tetto con avviso.
Posso usarla su dati sensibili?
Sì, a condizioni precise. Servono una base giuridica, il consenso esplicito quando si tratta di dati relativi alla salute ai sensi dell’articolo 9, un accordo di trattamento con il fornitore del modello, cifratura e minimizzazione dei dati inviati. In DietApp questo è il perimetro entro cui lavorano tutte le funzioni con IA. Se un dato non è necessario alla risposta, non parte.
Cosa succede se sbaglia?
L’errore va progettato insieme alla funzione. L’output viene validato rispetto a uno schema, l’utente vede quando si tratta di una stima e può correggerla, e in caso di risposta non valida o servizio non raggiungibile il flusso torna al percorso manuale. Nessuna decisione automatica e irreversibile su una persona: il modello propone, il codice verifica, la persona conferma.
Serve un mio server?
Nella maggior parte dei casi no. I modelli si usano via API e il resto dell’applicazione gira su Firebase e Google Cloud, come gli altri progetti dello studio. Un’infrastruttura dedicata ha senso solo se i dati non possono uscire da un perimetro definito: è una scelta legittima, ma cambia i costi e i tempi, e va decisa all’inizio.
