Come integrare ChatGPT o Claude in un'applicazione: guida passo passo

Cosa serve per integrare ChatGPT o Claude in un'applicazione?

Integrare ChatGPT o Claude in un'applicazione significa aggiungere un servizio di back end che invia prompt costruiti con cura all'API di un large language model (LLM), basa le risposte sui vostri dati e restituisce risultati di cui i vostri utenti possono fidarsi. La chiamata all'API in sé è poche righe di codice. Il lavoro vero è scegliere il caso d'uso giusto, preparare i dati, progettare i prompt, aggiungere guardrail, misurare la qualità e mantenere i costi prevedibili.

Questa guida ripercorre i passaggi che seguiamo in Lytvynov Production quando aggiungiamo funzionalità LLM a un prodotto SaaS esistente. È scritta per CTO e product owner che vogliono capire le decisioni prima di impegnare il budget. Se preferite affidare il lavoro a un team, consultate i nostri servizi di integrazione AI.

Il processo in sintesi:

1. Scegliete un caso d'uso ristretto e misurabile.
2. Scegliete un modello e un provider (mantenendo la possibilità di cambiarli).
3. Progettate prompt e output strutturati.
4. Basate le risposte sui vostri dati con il retrieval (RAG).
5. Costruite un'esperienza utente in streaming.
6. Aggiungete guardrail su input, output e azioni.
7. Costruite un set di valutazione prima del lancio.
8. Aggiungete osservabilità e tracciamento dei costi.
9. Sistemate privacy, DPA e compliance.
10. Rilasciate gradualmente dietro un feature flag.

Da quale caso d'uso conviene partire?

Partite da un caso d'uso in cui una risposta sbagliata costa poco, il successo è facile da misurare e gli utenti svolgono già il compito manualmente. Buoni primi candidati sono bozze, riassunti, classificazione, estrazione di dati dai documenti e risposte a domande sul vostro help center o sulla vostra knowledge base.

Evitate di partire con un "assistente AI che fa tutto". È difficile da valutare, difficile da mettere in sicurezza e difficile da spiegare agli utenti. Una prima funzionalità migliore ha un input chiaro, un output atteso chiaro e una metrica: tempo risparmiato per task, quota di bozze accettate senza modifiche, ticket di supporto evitati o accuratezza dell'estrazione su un campione di documenti reali.

Il nostro prodotto AI Resume Master è un buon esempio di perimetro ristretto. L'LLM genera, riscrive e migliora le sezioni del curriculum e crea lettere di presentazione personalizzate, e gli utenti producono un curriculum in 3-5 minuti. Il prodotto ha raggiunto 50.000 utenti attivi mensili; consultate il case study di AI Resume Master. La funzionalità funziona perché il compito è delimitato e l'utente rivede sempre il risultato.

Come scegliere tra OpenAI, Anthropic Claude e modelli open-weight?

Scegliete testando, non in base al marchio. OpenAI e Anthropic offrono entrambi modelli di frontiera con contesto lungo, uso di tool e output strutturato; i modelli open-weight (come le famiglie Llama, Qwen, Mistral o gpt-oss) vi danno il pieno controllo su hosting e dati, al prezzo di gestire l'infrastruttura in autonomia.

Prezzi e nomi dei modelli cambiano ogni pochi mesi, quindi non li fissiamo in un piano. Ciò che resta stabile è la logica di decisione. Usate un modello di frontiera ospitato quando la qualità conta di più e il volume è moderato. Usate un modello ospitato più piccolo per i passaggi semplici ad alto volume. Valutate i modelli open-weight quando i dati non possono lasciare il vostro ambiente, quando serve un fine-tuning profondo o quando un volume costante rende le GPU più economiche dei token.

Qualunque sia la scelta, incapsulate il provider dietro una vostra interfaccia: un servizio che riceve un task, una versione del prompt e dei parametri e restituisce un risultato tipizzato. Questo mantiene basso il vendor lock-in e rende i test A/B tra modelli una modifica di configurazione.

Come progettare i prompt per una funzionalità in produzione?

Trattate i prompt come codice: versionateli, testateli e revisionate le modifiche. Un prompt di produzione ha un'istruzione di sistema stabile (ruolo, regole, tono, cosa fare in caso di dubbio), una sezione di contesto chiaramente delimitata, l'input dell'utente e un formato di output esplicito.

Regole pratiche che fanno risparmiare tempo:

• Chiedete output strutturato. Usate JSON schema o definizioni di tool, così il vostro codice riceve campi tipizzati e non testo libero da interpretare.
• Separate le istruzioni dai dati. Inserite i contenuti dell'utente e i documenti recuperati in sezioni chiaramente marcate, così il modello non li tratta come istruzioni.
• Fornite esempi. Due o tre brevi esempi di input e output di solito funzionano meglio di un lungo paragrafo di regole.
• Conservate i prompt fuori dal rilascio del codice. Tenere i prompt in un database con cronologia delle versioni permette di regolare tono o regole senza un deploy. Abbiamo usato questo pattern nel progetto AI Grief Companion, dove i prompt risiedono nel database con una cronologia delle versioni.

Quando serve il RAG e come si inserisce?

Serve la retrieval-augmented generation (RAG) ogni volta che la risposta dipende da dati che il modello non ha visto: documentazione, contratti, ticket, catalogo prodotti o record dei clienti. Il RAG recupera al momento della richiesta i passaggi più pertinenti e li inserisce nel prompt, così il modello risponde a partire dalle vostre fonti e può citarle.

Un setup RAG minimo comprende un job di ingestione che divide i documenti in chunk e memorizza gli embedding, un passaggio di ricerca (idealmente ibrida, per parole chiave più vettoriale, con reranking) e un prompt che include i passaggi migliori con i relativi ID di origine. I permessi contano: filtrate i risultati in base a ciò che l'utente corrente può vedere prima che qualcosa arrivi al modello. La nostra guida per implementare RAG tratta in dettaglio chunking, database vettoriali e valutazione, e la pagina sui nostri servizi di sviluppo RAG spiega come lo realizziamo.

Come costruire una buona UX in streaming?

Trasmettete i token all'utente in streaming, così le prime parole compaiono in circa un secondo invece di attendere la risposta completa. Entrambe le principali API supportano lo streaming; il vostro back end inoltra lo stream al browser tramite Server-Sent Events o WebSockets.

Una buona UX per LLM comprende anche:

• Un pulsante "stop" visibile e la possibilità di rigenerare.
• Citazioni o link alle fonti accanto alle risposte che si basano sui vostri dati.
• Stati chiari per "sto pensando", "sto cercando" e "sto chiamando un tool" nei flussi multi-step.
• Un passaggio di modifica prima che qualsiasi cosa venga inviata, salvata o pubblicata per conto dell'utente.
• Un controllo di feedback (pollice su o giù con un commento facoltativo) che alimenta il vostro set di valutazione.

Se state costruendo un'interfaccia conversazionale, la nostra pagina sullo sviluppo chatbot AI tratta il passaggio agli operatori umani e il design delle conversazioni.

Di quali guardrail ha bisogno una funzionalità LLM?

Una funzionalità LLM ha bisogno di guardrail in tre punti: prima del modello (input), dopo il modello (output) e attorno a qualsiasi azione che il modello può attivare. L'obiettivo è rendere gli errori rari, visibili ed economici.

Non chiamate mai l'API del provider dal browser e non date mai al modello credenziali più ampie di quelle dell'utente corrente. Se la vostra funzionalità permette al modello di chiamare API interne, un server MCP con tool dal perimetro limitato è un modo pulito per esporle.

Come valutare la qualità prima e dopo il lancio?

Costruite un set di valutazione prima del lancio: 50-200 input reali con output attesi o criteri di valutazione, che coprano casi comuni, casi limite e modalità di errore note. Eseguitelo a ogni modifica di prompt, modello e retrieval, e non rilasciate se i punteggi calano.

La valutazione combina di solito tre metodi. I controlli esatti funzionano per l'output strutturato (il totale della fattura estratto corrisponde?). La valutazione con rubrica da parte di un secondo modello, con una persona che verifica un campione, funziona per il testo libero (la risposta è fedele alle fonti, completa, nel tono giusto?). I segnali di produzione, come tasso di accettazione, modifiche, pollici in giù ed escalation, mostrano cosa è sfuggito al set di test. Reinserite ogni settimana nel set di valutazione i cattivi esempi di produzione.

Cosa registrare e monitorare?

Registrate ogni chiamata LLM con versione del prompt, modello, numero di token di input e output, latenza, costo, ID dei documenti recuperati, chiamate di tool e feedback dell'utente. Senza questi dati non potete fare il debug di una risposta sbagliata, spiegare un picco di costi o dimostrare un miglioramento.

Dashboard da avere dal primo giorno: costo al giorno e per funzionalità, costo per utente attivo, latenza p50 e p95, tassi di errore e timeout per provider e segnali di qualità dal feedback degli utenti. Mascherate i dati personali nei log e applicate le stesse regole di conservazione del resto del prodotto. Gli strumenti vanno dagli stack di osservabilità generici alle piattaforme di tracing specifiche per LLM; la scelta conta meno che avere trace legate alle versioni dei prompt.

Come tenere sotto controllo i costi degli LLM?

Controllate i costi con quattro leve: prompt caching, instradamento dei modelli, limiti al contesto e quote per utente. Insieme contano di solito più del prezzo di listino per token.

• Prompt caching. Mantenete la parte lunga e stabile del prompt (istruzioni, esempi, documenti condivisi) all'inizio, così il provider può metterla in cache; l'input in cache viene fatturato con un forte sconto su entrambe le principali API.
• Instradamento dei modelli. Inviate i passaggi semplici (classificazione, estrazione, brevi riscritture) a un modello piccolo e riservate il modello grande alle richieste difficili.
• Disciplina sul contesto. Recuperate 5-10 passaggi validi invece di inserire interi documenti in ogni chiamata.
• Elaborazione batch. Usate le API batch per i job non interattivi, come riassunti notturni o tagging massivo.
• Quote e limiti. Impostate limiti per utente e per tenant, così un singolo account non può generare una spesa imprevista.

Fasce tipiche che osserviamo sul mercato nel 2026: uno strumento interno a basso traffico costa qualche decina di USD al mese, mentre un assistente rivolto ai clienti con uso intenso può costare diverse migliaia di USD al mese. Inserite presto il costo per richiesta nel vostro modello di pricing.

E privacy, DPA e compliance?

Prima di inviare dati dei clienti a qualsiasi provider di modelli, firmate l'accordo sul trattamento dei dati del provider, verificate la policy di conservazione del vostro piano e aggiornate la vostra privacy policy e l'elenco dei sub-responsabili. Per i dati regolamentati valutate una regione del provider o un deployment cloud coerente con i vostri obblighi, oppure un modello open-weight self-hosted.

Riducete al minimo ciò che inviate: eliminate gli identificativi di cui il modello non ha bisogno e cifrate le conversazioni memorizzate. Nella piattaforma AI Grief Companion cifriamo ogni messaggio al momento dell'ingestione con AES-256-GCM per singolo messaggio sotto una chiave envelope KMS e supportiamo la cancellazione con un clic di tutti i dati dell'utente, perché il prodotto gestisce materiale molto personale. La maggior parte dei prodotti SaaS non ha bisogno di quel livello, ma ha bisogno di una risposta chiara alla domanda "dove finiscono i dati dei nostri clienti?".

Come rilasciare una funzionalità LLM?

Rilasciate per fasi: prima gli utenti interni, poi una piccola percentuale di clienti dietro un feature flag, poi tutti. A ogni fase confrontate qualità e costi con gli obiettivi fissati al primo passo.

Tempistica tipica per una funzionalità ben definita:

Prevedete un fallback per i disservizi del provider (un secondo provider o uno stato "riprova" gestito con eleganza) e mantenete il feature flag anche dopo il lancio, così potete disattivare la funzionalità in pochi secondi.

Come lavoriamo alle integrazioni LLM

In Lytvynov Production forniamo un preventivo fisso dopo una breve call di scoping; con noi una funzionalità AI aggiunta a un prodotto esistente parte da 5.000 USD. La prima milestone testa due o tre modelli sui vostri dati reali e definisce il set di valutazione. Il nostro back end è di solito PHP/Symfony e integriamo le API di OpenAI e Anthropic Claude, RAG e server MCP in prodotti esistenti. Se volete un secondo parere sul vostro piano, prenotate una call.