Una base di conoscenza che Claude può usare: come scriverla, aggiornarla e verificarla

Una base di conoscenza che Claude può usare è un insieme di articoli aziendali brevi, datati e con un responsabile, ciascuno dedicato a una sola domanda. Claude recupera il passaggio pertinente prima di rispondere, lo cita e dichiara quando la risposta manca. Per arrivarci servono quattro cose: documenti scelti, forma uniforme, aggiornamento assegnato e verifica prima dell'uso.

Questa guida riguarda gli articoli che molte aziende tengono già in un helpdesk come Zoho Desk. Spiega quali documenti inserire, in quale forma scriverli, come tenerli aggiornati e come controllare le risposte prima che il team ci faccia affidamento. L'esempio pratico usa i progetti di Claude, che il Suo team può provare senza sviluppo software.

Il punto di partenza è semplice. Claude non conosce le procedure interne della Sua azienda. Conosce solo ciò che gli viene dato da leggere. Se gli articoli sono confusi, incompleti o in contraddizione, anche la risposta lo sarà, per quanto il modello sia capace.

Per questo il lavoro vero non riguarda il modello. Riguarda i testi. Una base di conoscenza ordinata serve anche agli operatori umani, quindi lo sforzo non va perso nemmeno se il progetto con Claude cambiasse forma in seguito.

Claude inventa quando la domanda non trova un articolo chiaro e colma il vuoto con conoscenza generale. Ogni modello ha una data limite di conoscenza affidabile: per Claude Opus 5.5 è giugno 2026, secondo la panoramica dei modelli di Anthropic. Le Sue regole su resi, garanzie o escalation non fanno parte di quella conoscenza.

Esistono due modi per dare a Claude i documenti aziendali. Il primo è inserire tutto nel prompt. La guida di Anthropic sugli agenti di assistenza clienti avverte che questa scelta porta costi alti, risposte più lente e il raggiungimento dei limiti della finestra di contesto.

Il secondo modo è la RAG. La RAG (retrieval-augmented generation) è la tecnica con cui il sistema recupera i passaggi pertinenti da una raccolta di documenti e li passa a Claude insieme alla domanda. Secondo la stessa guida, nei casi di assistenza con molto contesto la RAG aumenta l'accuratezza e riduce tempi di risposta e costi delle API.

La RAG però funziona bene solo quanto gli articoli che recupera. Se due articoli descrivono la stessa procedura in modo diverso, il sistema può recuperare quello sbagliato. Se un articolo copre dieci argomenti, il passaggio utile resta sepolto. La guida elenca la riduzione delle allucinazioni tra le protezioni necessarie, e la prima protezione è una raccolta di testi senza contraddizioni.

La scelta del modello conta meno della qualità dei testi, ma conta. La guida indica che Claude Haiku 4.5 può essere più adatto quando si vuole ridurre la latenza in flussi con RAG. Il confronto completo è nella guida su quale modello Claude usare tra Opus, Sonnet e Haiku.

Nella base di conoscenza vanno i documenti che descrivono regole stabili e approvate, non i dati che cambiano ogni giorno. La distinzione decide gran parte della qualità delle risposte. Un articolo sulla procedura di reso resta valido per mesi. Lo stato di un ordine cambia in poche ore.

I documenti da inserire, nella versione approvata, sono questi:

• procedure operative che il team segue già, scritte passo per passo;
• domande frequenti con la risposta che l'azienda ha deciso di dare;
• condizioni e politiche rivolte ai clienti, come garanzia, resi e tempi di servizio;
• regole di escalation, cioè quando e a chi passare la richiesta;
• un glossario dei termini interni e dei nomi di prodotto.

Tre categorie invece restano fuori. La prima sono i dati in tempo reale. La guida di Anthropic spiega che la RAG basata su embedding non basta per domande su saldi di conto o dettagli di polizza, e raccomanda l'uso di strumenti che interrogano il sistema al momento. L'uso di strumenti (tool use) è la capacità di Claude di chiamare una funzione esterna e leggere il risultato.

La seconda categoria sono i dati personali di clienti e dipendenti. Tra le protezioni per i chatbot di assistenza la guida indica di togliere le informazioni personali identificative dalle risposte, salvo necessità autorizzata. Il modo più sicuro è non metterle negli articoli.

La terza categoria sono bozze, versioni superate ed email interne. Ogni documento obsoleto lasciato nella raccolta è una risposta sbagliata in attesa della domanda giusta.

Un articolo utile a Claude risponde a una sola domanda, con la regola in apertura e le eccezioni scritte per esteso. La stessa forma aiuta un operatore nuovo al primo giorno. Le indicazioni che seguono valgono per qualsiasi helpdesk.

Un articolo, una domanda

Un articolo che tratta resi, spedizioni e fatturazione insieme produce recuperi imprecisi. Divida il testo in articoli separati. Se due articoli si sovrappongono, ne tenga uno e cancelli l'altro.

Titolo che ripete la domanda del cliente

Scriva il titolo con le parole che il cliente usa nei ticket, non con il gergo interno. "Come restituisco un prodotto difettoso?" viene recuperato meglio di "Procedura RMA". Il termine interno può comparire nel testo, spiegato nella stessa frase.

Regola, eccezioni e limiti in chiaro

Metta la risposta nella prima frase. Poi elenchi le eccezioni una per una. Scriva anche cosa l'articolo non copre e a chi rivolgersi in quel caso. Claude non deve dedurre un'eccezione che nessuno ha scritto.

Data, versione e responsabile in testa

Ogni articolo porta in alto la data dell'ultima revisione e il nome del responsabile. Così chi verifica una risposta sa subito quanto è recente la fonte e a chi chiedere.

Termini coerenti in tutta la raccolta

Se un prodotto ha tre nomi in tre articoli, Claude li tratta come tre cose diverse. Fissi un nome per ogni prodotto e servizio nel glossario e lo usi ovunque. Chi scrive molto con Claude trova altri accorgimenti nella guida per usare Claude come un power user.

La tabella di controllo seguente riassume le verifiche da fare su ogni articolo prima di inserirlo nella base di conoscenza usata da Claude. Conviene applicarla anche agli articoli già pubblicati, partendo da quelli più consultati. Un articolo che non supera tutti i punti resta fuori finché non viene corretto.

La tabella è volutamente breve. Chi scrive gli articoli la usa come ultimo passaggio, e chi approva la pubblicazione la usa come criterio unico, così la discussione riguarda i fatti e non i gusti.

Il modo più rapido per provare una base di conoscenza con Claude è un progetto. Secondo il Centro assistenza di Anthropic sui progetti, i progetti sono spazi di lavoro autonomi con le proprie cronologie di chat e basi di conoscenza. Gli utenti gratuiti possono crearne al massimo cinque.

La sequenza che segue parte dagli articoli già pubblicati nell'helpdesk e arriva a un progetto usato da tutto il team di assistenza:

1. Raccolga in documenti separati per area gli articoli approvati di Zoho Desk, dopo averli passati nella tabella di controllo.
2. Crei un progetto, ad esempio "Assistenza clienti", e carichi i documenti nella conoscenza del progetto.
3. Scriva le istruzioni di progetto, che personalizzano le risposte di Claude anche nel tono.
4. Condivida il progetto con il team, se il piano è Team o Enterprise.

Le istruzioni di progetto possono essere brevi. Un testo di partenza potrebbe essere questo:

Rispondi solo sulla base dei documenti del progetto. Indica il titolo dell'articolo che hai usato. Se nessun articolo risponde alla domanda, dillo chiaramente e suggerisci di aprire un ticket. Usa un registro formale.

Per la condivisione il Centro assistenza prevede due livelli. Con "Può visualizzare" i membri vedono contenuti, conoscenza e istruzioni e chattano nel progetto, ma non lo modificano. Con "Può modificare" cambiano istruzioni e conoscenza. Dia il primo livello agli operatori e il secondo solo ai responsabili degli articoli.

La conoscenza del progetto migliorata con RAG è disponibile solo nei piani a pagamento Pro, Max, Team ed Enterprise. Quando la conoscenza si avvicina ai limiti di contesto, Claude attiva la modalità RAG ed espande la capacità fino a 10 volte. Per portare le stesse risposte nei canali del team servono integrazioni, descritte nella guida su Claude in Microsoft 365 e Teams.

Le risposte si verificano con un insieme di domande reali, prese dai ticket, confrontando ogni risposta con l'articolo citato. Le domande inventate a tavolino sono troppo pulite. I clienti scrivono in modo impreciso, mescolano due problemi e usano nomi sbagliati.

La guida di Anthropic sugli agenti di assistenza suggerisce obiettivi concreti per questa fase:

• comprensione corretta della domanda nel 95% dei casi o più;
• pertinenza della risposta nel 90% dei casi o più;
• indicazione di una fonte nell'80% delle interazioni in cui un approfondimento è utile;
• escalation corretta, cioè il passaggio a una persona quando serve, nel 95% dei casi o più.

La stessa guida consiglia di aggiungere al prompt almeno 4 o 5 esempi di interazioni "buone". Nelle istruzioni di progetto questi esempi mostrano a Claude la lunghezza, il tono e il modo di citare che il team si aspetta.

In Svennis, prima di mettere una base di conoscenza davanti al team, facciamo porre a Claude le domande reali arrivate nei ticket e confrontiamo ogni risposta con l'articolo che dichiara di aver usato. Il problema che troviamo più spesso non è il modello, ma due articoli che dicono cose diverse sullo stesso tema, e la correzione si fa nel testo.

Ogni risposta sbagliata va ricondotta a una causa: articolo mancante, articolo ambiguo, duplicato o domanda che richiede dati in tempo reale. Solo quando gli obiettivi sono raggiunti il responsabile dell'assistenza approva l'uso da parte del team.

Una base di conoscenza resta affidabile solo se ogni articolo ha un responsabile che lo aggiorna quando cambia il processo. La regola pratica è semplice: chi cambia una procedura aggiorna l'articolo nello stesso momento. Chi rimanda crea proprio le contraddizioni che portano Claude a sbagliare.

La copia di riferimento degli articoli deve restare nell'helpdesk, non solo in Claude. Il motivo è concreto. Secondo il Centro assistenza di Anthropic sulla conservazione dei dati, nei piani Enterprise con conservazione personalizzata il periodo di un progetto parte dall'ultimo aggiornamento, comprese le modifiche alla knowledge base. I dati oltre il periodo vengono eliminati in modo permanente e non si recuperano.

Anche il registro delle modifiche va tenuto da voi. La pagina di Anthropic sui registri di audit spiega che i registri sono disponibili solo per le organizzazioni Enterprise. Un'esportazione raccoglie gli ultimi 180 giorni, ma titoli e contenuti di chat e progetti non vengono esportati, solo i loro identificativi.

In pratica il registro di audit dice che un documento è cambiato, non che cosa è cambiato. Per questo conviene annotare in ogni articolo la data della revisione e una riga sulla modifica. Quando un operatore segnala una risposta strana, il responsabile risale subito alla versione in uso.

Per un'azienda italiana la base di conoscenza può restare scritta in italiano, anche se una parte dei clienti scrive in altre lingue. La guida di Anthropic sugli agenti di assistenza indica che Claude conversa in oltre 200 lingue senza chatbot separati né lunghi processi di traduzione. Conviene comunque verificare come vengono resi i nomi di prodotto e i termini del glossario nelle lingue principali dei clienti.

La seconda questione riguarda i dati. Gli articoli non devono contenere dati personali di clienti o dipendenti, come già indicato nella tabella di controllo. Questo semplifica il confronto con chi in azienda segue la protezione dei dati, perché la base di conoscenza contiene regole e non persone.

La terza questione è la durata di conservazione. Secondo il Centro assistenza di Anthropic, per impostazione predefinita i dati vengono conservati a tempo indeterminato. I clienti Enterprise possono impostare un periodo personalizzato da Impostazioni organizzazione > Dati e Privacy, con il ruolo di Proprietario o Proprietario principale.

Il periodo minimo è di 30 giorni e ogni mese vale 30 giorni, quindi tre mesi corrispondono a 90 giorni. Tutte le modifiche alla conservazione finiscono nei registri di audit. Decida il periodo prima di caricare i documenti, non dopo, e lo metta per iscritto accanto alla politica interna sull'uso di Claude.

Il primo passo concreto è scegliere un'area limitata dell'assistenza e sistemarne gli articoli, invece di rivedere tutta la raccolta in una volta. Un'area con molte domande ripetitive dà un risultato misurabile in poco tempo.

Una sequenza ragionevole per partire è questa:

1. Scelga un'area, ad esempio resi o accesso all'area clienti, e raccolga gli articoli esistenti.
2. Passi ogni articolo nella tabella di controllo e unisca o cancelli i duplicati.
3. Assegni un responsabile e una data di revisione a ogni articolo.
4. Crei un progetto Claude con istruzioni di progetto e 4 o 5 esempi di risposte buone.
5. Raccolga domande reali dai ticket e misuri le risposte rispetto agli obiettivi della guida di Anthropic.
6. Estenda ad altre aree solo dopo che la prima supera la verifica.

Quando le risposte sono affidabili nel progetto, il passo successivo è portarle dove il team lavora già. Se il supporto interno passa da Slack, la guida su Claude in Slack per il supporto interno con i ticket in Zoho Desk descrive come collegare le due parti.