Come integrare l'AI nel tuo prodotto

Ogni roadmap di prodotto ha ormai "aggiungere AI" tra le voci, e la maggior parte di quelle funzionalità verrà rimossa in silenzio entro un anno. Non perché la tecnologia non funzioni — funziona straordinariamente bene — ma perché è stata appiccicata al prodotto per sembrare moderni, non per risolvere un problema reale. I team che ottengono risultati con l'AI non sono quelli con i modelli più sofisticati; sono quelli che hanno scelto il compito giusto per un modello e hanno progettato intorno ai suoi limiti. Integrare l'AI bene riguarda meno i modelli e più il giudizio di prodotto. Ecco come approcciamo il problema.

Inizia dal compito, non dal modello

Il pattern del fallimento è sempre lo stesso: un team decide di "usare un LLM" e poi cerca dove metterlo. Si tratta di costruire una soluzione e cercarle un problema — un approccio che produce sistematicamente funzionalità che nessuno mantiene. Invertite il ragionamento. Osservate dove i vostri utenti perdono tempo, si bloccano, abbandonano un flusso o fissano un campo vuoto, e chiedetevi se un language model aiuta davvero lì.

I buoni candidati hanno una forma riconoscibile:

• Input non strutturato: testo libero, documenti, dati disordinati che una regola non riesce a interpretare.
• Tollerante all'approssimazione: una risposta sufficientemente buona è genuinamente utile, e l'utente può correggere gli errori.
• Tedioso per gli esseri umani: il compito è lavoro reale che le persone fanno attualmente a mano e che non gradiscono.

Riassumere lunghe conversazioni, redigere una prima bozza, estrarre campi da testo disordinato, rispondere a domande sulla propria documentazione — questi casi si adattano bene. I candidati scadenti richiedono risposte esatte, garanzie solide, oppure hanno già una soluzione deterministica perfettamente funzionante.

Dove gli LLM rendono davvero

• Redazione e riscrittura. Generare un punto di partenza che un essere umano poi modifica è un uso naturale — il criterio è "meglio di un foglio bianco", non "perfetto". Bozze di risposta, contenuti iniziali, riassunti.
• Estrazione e classificazione. Trasformare testo libero in dati strutturati utilizzabili dall'applicazione: estrarre campi da una fattura, etichettare ticket, smistare messaggi.
• Risposta a domande sui vostri dati. Recupero contestualizzato sui vostri contenuti, così gli utenti ottengono risposte dalla vostra knowledge base invece di doverla sfogliare.
• Interfacce in linguaggio naturale. Permettere agli utenti di chiedere ciò che vogliono in italiano semplice invece di navigare tra menu e filtri.

Dove non rendono

Resistete alla tentazione di usare l'AI per qualsiasi cosa che debba essere sempre esatta, per qualsiasi cosa in cui una risposta sbagliata ma sicura di sé sia pericolosa o costosa, o per qualsiasi cosa che una semplice regola gestisca già bene. Una regex, una lookup table o una query PostgreSQL sono più economiche, più veloci, più affidabili e infinitamente più debuggabili di un modello per il lavoro deterministico. Calcolare un totale, validare un'email, applicare un permesso — niente di tutto questo ha bisogno di un LLM. Usarne uno lì aggiunge costo, latenza e un nuovo tipo di errore senza alcun beneficio. La cosa più matura che si possa fare in un progetto AI è dire "questa parte non ha bisogno dell'AI".

Scegliere l'approccio: prompting, RAG o fine-tuning

Una volta trovato un compito reale, scegliete la tecnica più leggera che lo risolve. Ricorrete alla complessità superiore solo quando il livello più semplice dimostra di non bastare.

1. Prompting su un modello capace. Iniziate sempre da qui. Un prompt ben scritto su un modello generale potente risolve una quota sorprendente di compiti senza alcun training e senza pipeline di dati. Il più economico da costruire, il più facile da modificare.
2. Retrieval-augmented generation (RAG). Quando il modello deve conoscere i vostri dati — i vostri documenti, i dati del vostro prodotto — recuperate il contenuto rilevante e inseritelo nel prompt. È così che si contestualizzano le risposte senza riaddestrare nulla, ed è il default corretto per "rispondere a domande sui nostri dati". La ricerca vettoriale tramite pgvector (vedi PostgreSQL per startup) mantiene tutto nel database che già gestite.
3. Fine-tuning. Solo quando avete bisogno di uno stile, un formato o un comportamento specifico che il prompting non riesce a produrre in modo affidabile, e disponete di esempi di qualità su cui addestrare. È l'opzione più costosa e meno flessibile — la maggior parte dei prodotti non ne ha mai bisogno.

L'errore è iniziare dal terzo livello. Cominciate con un prompt, aggiungete il retrieval quando il modello ha bisogno dei vostri dati, e riservate il fine-tuning al caso raro che lo richieda davvero.

Un esempio concreto: trasformare un compito reale in una funzionalità

Le astrazioni arrivano solo fino a un certo punto, quindi rendiamo tutto concreto. Supponiamo che un team di supporto trascorra ore ogni giorno a leggere lunghi thread di email dei clienti e a compilare manualmente un ticket con il problema del cliente, l'urgenza e l'area di prodotto. Questa è esattamente la forma giusta per l'AI: input non strutturato, tedioso per gli esseri umani, tollerante all'approssimazione perché un agente revisiona comunque ogni ticket.

Ecco come i livelli descritti si applicano a questo caso. Si inizia con il prompting: si invia il thread a un modello capace chiedendo di restituire il riepilogo del problema, un livello di urgenza da un insieme fisso e l'area di prodotto, come JSON strutturato. Se il modello ha bisogno di conoscere la tassonomia specifica del vostro prodotto, si aggiunge il retrieval — si inseriscono nel prompt le voci del catalogo rilevanti così che classifichi secondo le vostre categorie reali anziché tirare a indovinare. In questo caso non fareste quasi certamente mai il fine-tuning; prompting più retrieval è sufficiente.

Poi si progetta tenendo conto degli errori: il modello propone i campi del ticket, l'agente li vede pre-compilati e approva o modifica con un clic, e si registrano sia il suggerimento sia la versione corretta dall'essere umano. Quelle correzioni registrate diventano il vostro set di valutazione e, se mai ne aveste bisogno, i dati per il fine-tuning. La funzionalità fa risparmiare tempo reale dal primo giorno, degrada in modo controllato quando è incerta, e migliora misurabilmente nel tempo — ed è esattamente così che appare "rilasciato" rispetto a una demo che impressiona una volta e non aiuta nessuno.

Progettate per quando il modello sbaglia

La differenza più importante tra una demo e una funzionalità AI rilasciata è come gestisce gli errori. I modelli sono probabilistici — produrranno occasionalmente una risposta fluente, sicura e completamente sbagliata. Una demo nasconde questo; un prodotto reale lo pianifica:

1. Mantenete un essere umano nel loop dove la posta è alta: l'AI propone, la persona approva. Questo trasforma "l'AI ha fatto un errore" in "l'AI ha fatto risparmiare tempo a qualcuno e questi ha intercettato il caso limite".
2. Ancorate le risposte ai vostri dati tramite retrieval, così le risposte citano fonti reali invece di inventarle. Mostrate la fonte; lasciate che gli utenti verifichino.
3. Vincolate l'output a formati strutturati (schemi JSON, enum) che potete validare prima di agire. Rifiutate o riprovate tutto ciò che non è parsabile.
4. Fallite in modo controllato. Un chiaro "non sono sicuro, ecco cosa ho trovato" batte ogni singola volta un'allucinazione sicura di sé. Progettate deliberatamente lo stato di incertezza.

Costo, latenza e privacy

Tre realtà pratiche determinano se una funzionalità AI sopravvive al contatto con la produzione:

• Costo. Ogni chiamata costa denaro e scala con l'utilizzo. Fate caching in modo aggressivo, usate modelli più piccoli ed economici per i passaggi più semplici, e non inviate più contesto di quanto il compito richieda.
• Latenza. Le chiamate agli LLM sono lente rispetto a una query su database. Trasmettete le risposte in streaming così l'utente vede i progressi, elaborate in background dove possibile, e non bloccate mai tutta l'interfaccia su una chiamata al modello.
• Privacy. Siate deliberati riguardo a quali dati utente escono dal vostro sistema e dove vanno. Conoscete i termini di conservazione dei dati del vostro provider, e per i domini sensibili valutate cosa debba rimanere internamente.

Valutate prima di fidarvi

Non si può migliorare ciò che non si misura, e "sembrava buono in qualche prova" non è una misurazione. Prima che una funzionalità AI venga rilasciata — e continuamente dopo — costruite un piccolo eval set: una raccolta di input reali abbinati a come dovrebbe apparire un buon output. Eseguitelo ogni volta che cambiate un prompt, sostituite un modello o modificate il retrieval, e intercetterete le regressioni silenziose che affliggono le funzionalità AI — dove una modifica che aiuta un caso ne rompe silenziosamente altri cinque.

Gli eval non devono essere elaborati. Anche venti o cinquanta esempi rappresentativi, valutati da una semplice regola o da un secondo modello che funge da giudice, vi diranno più di qualsiasi quantità di verifica manuale a campione. I team che mantengono le loro funzionalità AI sane nel tempo sono quelli che trattano prompt e modelli come codice che può regredire, e li proteggono con test di conseguenza. È la stessa disciplina del "misura, non indovinare" che separa un SaaS MVP rilasciato da un progetto di ricerca.

Rilasciate in piccolo, misurate, espandete

Non lanciate una release "AI ovunque". Scegliete un compito ad alto valore, rilasciatelo in flag a una fetta di utenti e osservate due cose: le persone lo usano, e continuano a usarlo. Monitorate l'accettazione — con quale frequenza gli utenti accettano il suggerimento dell'AI rispetto a modificarlo o scartarlo. Quel singolo numero vi dice se la funzionalità è valore reale o una novità che impenna al lancio e si appiattisce una settimana dopo. È la stessa disciplina che applichiamo a qualsiasi lancio, come nella nostra guida al SaaS MVP: rilasciate la cosa reale più piccola possibile, misurate, poi espandete a partire dall'evidenza.

Costruite l'infrastruttura per sostituire modelli e ottimizzare prompt senza un redeploy, perché entrambi cambieranno costantemente. Un servizio TypeScript sottile e ben tipizzato intorno alla chiamata al modello — con logging, retry, validazione dell'output strutturato e una piccola suite di eval con esempi reali — si ripaga da solo la prima volta che dovete cambiare provider o che un prompt regredisce silenziosamente. Trattate i prompt e la scelta del modello come configurazione, non come costanti hardcoded.

Se volete aggiungere AI che gli utenti continuano davvero a usare, partendo da un compito reale anziché dall'hype, parliamone.