L’intelligenza artificiale sta modificando il modo in cui le organizzazioni utilizzano il proprio patrimonio informativo. Documentazione tecnica, procedure operative, specifiche, codice sorgente e verbali non sono più soltanto contenuti destinati alla consultazione da parte delle persone: possono diventare la fonte di conoscenza per assistenti AI, sistemi di Retrieval-Augmented Generation (RAG) e agenti in grado di supportare attività sempre più complesse.
Per ottenere risultati affidabili, però, non è sufficiente rendere questi documenti accessibili a un modello. La qualità delle risposte dipende dalla qualità delle informazioni disponibili: documenti duplicati, versioni superate, conoscenze distribuite tra strumenti diversi e collegamenti mancanti rendono difficile ricostruire il contesto necessario per comprendere un progetto, una tecnologia o una decisione.
Lo stesso limite si manifesta ogni giorno anche nel lavoro delle persone. La documentazione esiste, ma recuperare rapidamente tutto ciò che serve per affrontare un’attività richiede spesso di consultare repository differenti, confrontare versioni diverse dello stesso documento o ricostruire informazioni che non sono mai state collegate tra loro.
Costruire una base di conoscenza significa affrontare questo problema organizzando il patrimonio informativo esistente in modo che sia coerente, aggiornabile e facilmente consultabile. È un’attività che produce benefici immediati per chi lavora con la documentazione aziendale e che costituisce anche il presupposto per utilizzare in modo efficace gli strumenti di intelligenza artificiale.
Un esempio concreto: la migrazione di un’applicazione aziendale verso Kubernetes. L’architettura applicativa viene documentata in SharePoint, il codice risiede nei repository Git, le attività sono gestite in Jira, le procedure operative in un wiki interno e molte decisioni emergono solo nei verbali delle riunioni o nelle conversazioni su Teams. A questo si aggiungono email, presentazioni, fogli di calcolo e applicazioni gestionali. Le informazioni esistono, ma sono distribuite tra sistemi organizzati secondo logiche differenti e che rendono difficile ricostruire rapidamente il contesto di un progetto.
È proprio in situazioni come questa che una base di conoscenza può fare la differenza. Senza sostituire gli strumenti esistenti né spostare la documentazione dalle piattaforme in cui viene gestita, può mettere in relazione contenuti provenienti da fonti diverse e trasformare un insieme di documenti separati in un patrimonio informativo navigabile e coerente.
Obsidian è un’applicazione per la gestione della conoscenza basata su file Markdown. Può affiancare strumenti come SharePoint, Git, Jira e Teams, creando una rete di collegamenti tra informazioni che continuano a risiedere nelle rispettive piattaforme. La frammentazione delle informazioni non rappresenta un’anomalia, ma il risultato naturale dell’evoluzione dei processi aziendali. Ogni piattaforma organizza i contenuti secondo le proprie esigenze: un repository collega file e revisioni, un wiki raccoglie pagine, un sistema documentale archivia documenti, un’applicazione di ticketing registra attività e richieste. Ciò che manca non è la documentazione, ma una visione trasversale capace di collegare queste informazioni e renderle consultabili come parti dello stesso contesto.
Per questo motivo documentazione e conoscenza non coincidono. La documentazione descrive singoli aspetti di un’attività; la conoscenza comprende anche le relazioni tra informazioni provenienti da fonti diverse. Sapere dove si trova una procedura è utile; sapere a quale progetto si riferisce, quali tecnologie coinvolge, quali decisioni l’hanno modificata e quali altri documenti la completano significa disporre di un patrimonio informativo molto più ricco.
Cercare documenti non significa trovare risposte
Le moderne piattaforme documentali offrono strumenti di ricerca sempre più efficaci. È possibile cercare parole chiave, filtrare i risultati per autore o data, individuare rapidamente un file o una pagina wiki. Dal punto di vista del recupero dei documenti, il problema è spesso già risolto.
Le difficoltà emergono quando l’obiettivo non è trovare un documento, ma ottenere una risposta. Una ricerca restituisce un elenco di risultati; spetta poi all’utente stabilire quali siano pertinenti, verificarne l’attualità, confrontare versioni diverse e ricostruire il contesto in cui quelle informazioni sono state prodotte.
Immaginiamo, ad esempio, di dover capire perché un’applicazione utilizza un determinato database anziché un altro. Una ricerca potrebbe individuare la documentazione tecnica, il verbale della riunione in cui è stata presa la decisione, il ticket aperto durante la migrazione e la pagina wiki con le procedure operative. Nessuno di questi documenti, considerato singolarmente, contiene la risposta completa. È il loro collegamento a renderla comprensibile.
Lo stesso vale quando una persona entra a far parte di un nuovo progetto. Trovare tutti i documenti disponibili non significa comprenderne automaticamente l’evoluzione, le dipendenze o le decisioni che hanno portato alla situazione attuale. La ricerca individua le fonti; la conoscenza nasce dalla capacità di collegarle e interpretarle come parti di uno stesso insieme.
Perché serve un livello di organizzazione della conoscenza
Le informazioni che descrivono un’organizzazione sono già presenti nei sistemi utilizzati ogni giorno. Il problema non è quindi crearne di nuove, né spostarle in un unico repository, ma renderne esplicite le relazioni.
È questo il ruolo di un knowledge layer: un livello di organizzazione che si affianca ai sistemi esistenti e collega tra loro documenti, persone, progetti, tecnologie, procedure e decisioni. I contenuti continuano a risiedere nelle piattaforme che li gestiscono meglio, mentre il knowledge layer ne rappresenta il contesto.
Nel caso della migrazione verso Kubernetes, il knowledge layer può collegare il progetto ai repository Git, agli Architecture Decision Record (ADR), ai cluster coinvolti, alle procedure operative, ai ticket aperti durante il collaudo e alle tecnologie utilizzate. Le informazioni continuano a risiedere nei rispettivi sistemi, ma diventano consultabili come parti di uno stesso contesto.
Questo approccio offre anche un vantaggio pratico. Ogni informazione viene aggiornata nel sistema di origine, evitando copie e duplicazioni, ma può essere raggiunta attraverso percorsi diversi. Una tecnologia può rimandare ai progetti che la utilizzano; un progetto alle procedure operative; una procedura ai sistemi interessati; una decisione ai documenti che l’hanno motivata e ai ticket che ne hanno richiesto la revisione.
È questo livello di collegamento che trasforma un insieme di repository indipendenti in una base di conoscenza realmente navigabile.
Obsidian come piattaforma per la base di conoscenza
Esistono numerosi strumenti per costruire una base di conoscenza. Notion privilegia un ambiente collaborativo nel cloud basato su pagine e database; Logseq utilizza Markdown e collegamenti tra note, ma adotta prevalentemente una struttura da outliner; Anytype propone un modello basato su oggetti con funzionamento locale; Joplin offre una soluzione open source più essenziale per la gestione delle note.
Obsidian combina invece file Markdown aperti, collegamenti bidirezionali, metadati strutturati e un ecosistema di plugin particolarmente maturo. I contenuti rimangono leggibili e accessibili anche senza il software e possono essere elaborati, indicizzati o trasferiti senza dipendere da un formato proprietario. Le ragioni per cui Markdown ha assunto un ruolo centrale anche nella documentazione destinata all’intelligenza artificiale sono approfondite in Markdown: perché un linguaggio del 2004 è diventato centrale nell’AI.
Su questa base si innestano tre funzionalità fondamentali. I collegamenti bidirezionali permettono di creare una rete di relazioni tra gli argomenti senza imporre una gerarchia rigida. Le Properties consentono di associare metadati strutturati alle note, rendendole classificabili e interrogabili. Infine, un ecosistema di plugin tra i più maturi disponibili permette di estendere progressivamente le funzionalità del software senza alterarne l’impostazione di base.
Nel vault vengono quindi rappresentati gli elementi della conoscenza aziendale e i collegamenti che li uniscono, mentre documenti, codice, ticket e conversazioni continuano a essere gestiti nei rispettivi sistemi. Obsidian diventa il punto dal quale ricostruire il contesto e raggiungere le fonti originali, evitando di creare un nuovo archivio contenente copie della documentazione esistente.
Progettare il vault
In Obsidian una base di conoscenza è contenuta all’interno di un vault, una cartella che raccoglie note, allegati e configurazioni. La sua organizzazione iniziale influenza la facilità con cui sarà possibile far crescere il patrimonio informativo nel tempo; perciò, conviene dedicare qualche minuto alla progettazione prima di iniziare a importare documenti.
Benché sia naturale riprendere la struttura delle cartelle già utilizzata nei repository documentali, una gerarchia rigida diventa presto un limite quando la stessa informazione interessa più progetti, tecnologie o processi. In una base di conoscenza è preferibile utilizzare le cartelle solo per separare grandi insiemi di contenuti, affidando invece l’organizzazione a collegamenti e Properties, cioè i metadati strutturati introdotti da Obsidian.
Una nota dedicata a una tecnologia, ad esempio, può riportare proprietà come produttore, versione, stato, responsabile e data di aggiornamento. Una nota relativa a un progetto può indicare il cliente, il team coinvolto, le tecnologie utilizzate e la documentazione di riferimento. Queste informazioni non servono soltanto a descrivere il contenuto della nota, ma permettono anche di creare viste dinamiche, filtri e collegamenti automatici.
La nota dedicata alla migrazione potrebbe contenere proprietà come cliente, ambiente, stato del progetto, responsabile tecnico e data di rilascio, oltre ai collegamenti verso le note dedicate a Kubernetes, Helm, PostgreSQL, agli ADR e alla documentazione operativa. La struttura della base di conoscenza inizia così a riflettere le relazioni tra gli elementi del progetto, non la posizione dei documenti nei vari repository.
Per rendere omogenea la struttura delle note è utile predisporre alcuni modelli (Templates) da riutilizzare per progetti, tecnologie, persone, procedure o riunioni. Per esigenze più avanzate, Obsidian può essere esteso attraverso plugin, componenti aggiuntivi che ne ampliano le funzionalità. Uno dei più utilizzati è Templater, che permette di generare automaticamente contenuti dinamici, inserire date, proprietà, collegamenti e altri campi direttamente durante la creazione di una nuova nota. Definire fin dall’inizio modelli coerenti evita di dover riorganizzare centinaia di note quando la base di conoscenza inizia a crescere.
Trasformare la documentazione in conoscenza
Una volta definita la struttura del vault, si può iniziare a popolarlo.
In Obsidian la documentazione aziendale viene rappresentata attraverso una rete di note che collega progetti, tecnologie, procedure, persone e documenti, mantenendo i contenuti originali nei sistemi che li gestiscono.
Un buon punto di partenza consiste nell’identificare le principali entità della propria organizzazione: progetti, tecnologie, prodotti, clienti, fornitori, persone, procedure, sedi o servizi. Ognuna di esse può diventare una nota dedicata, arricchita con proprietà strutturate e collegamenti alle altre note correlate.
Nel caso della migrazione verso Kubernetes, la nota del progetto non contiene copie dei manifest, dei README o della documentazione tecnica. Collega invece il repository Git, la documentazione su SharePoint, gli ADR, le procedure di rilascio, le dashboard di monitoraggio e i ticket più significativi. Ogni informazione continua a essere aggiornata nel sistema che la gestisce, mentre la base di conoscenza ne conserva il contesto.
Per evitare duplicazioni, ogni informazione dovrebbe avere un punto di riferimento principale. Se una tecnologia viene descritta in una nota dedicata, gli altri contenuti dovrebbero collegarla anziché ripeterne la descrizione. Lo stesso criterio vale per persone, procedure, prodotti e progetti: ciascun elemento dispone di una nota di riferimento, mentre il resto della base di conoscenza ne rappresenta le relazioni.
Quando il numero delle note aumenta, diventa utile creare pagine indice dedicate ai principali argomenti. Il plugin Dataview permette di generare automaticamente elenchi, tabelle e viste dinamiche a partire dalle Properties delle note. Un indice dei progetti, ad esempio, può aggiornarsi automaticamente mostrando tutti quelli ancora attivi, mentre una pagina dedicata a una tecnologia può elencare in tempo reale i progetti che la utilizzano, senza richiedere aggiornamenti manuali.
Alimentare la base di conoscenza nel lavoro quotidiano
Una base di conoscenza è utile solo se viene aggiornata con continuità. Per questo motivo è preferibile integrarne l’utilizzo nelle attività quotidiane, anziché considerarla un archivio da compilare periodicamente.
Ogni riunione può produrre una nota con le decisioni prese, i partecipanti, i progetti interessati e le attività concordate. Allo stesso modo, una nuova tecnologia può essere collegata ai progetti che la adottano, mentre una procedura può essere aggiornata inserendo il riferimento alle modifiche che l’hanno resa necessaria. L’obiettivo non è documentare tutto, ma registrare le informazioni che permettono di ricostruire rapidamente il contesto.
Le Daily Notes di Obsidian rappresentano un punto di raccolta efficace per attività, appunti e collegamenti creati durante la giornata. Nel tempo diventano una cronologia del lavoro svolto e consentono di risalire facilmente al momento in cui è stata presa una decisione, è stato avviato un progetto o si è verificato un problema.
Anche le attività possono essere integrate nella base di conoscenza. Il plugin Tasks permette di gestire attività e scadenze direttamente all’interno delle note, mentre QuickAdd consente di creare rapidamente nuovi contenuti partendo da modelli predefiniti, riducendo il tempo necessario per registrare informazioni ricorrenti.
L’aspetto più importante è mantenere una modalità di lavoro coerente. Se ogni progetto, riunione, tecnologia o procedura viene documentato seguendo gli stessi criteri, la base di conoscenza cresce in modo ordinato e diventa progressivamente più utile, senza richiedere interventi di riorganizzazione periodici.
Utilizzare la base di conoscenza con l’AI
Una base di conoscenza ben organizzata aumenta l’efficacia di sistemi Retrieval-Augmented Generation (RAG), server Model Context Protocol (MCP) e agenti AI. In tutti questi casi il problema non è soltanto recuperare documenti, ma fornire al modello un contesto coerente, riducendo il rischio di utilizzare informazioni duplicate, incomplete o non aggiornate.
Nel caso del RAG, note ben delimitate, metadati coerenti e riferimenti alle fonti originali offrono alla pipeline informazioni utili per selezionare i contenuti pertinenti. I collegamenti tra le note possono inoltre essere acquisiti durante l’indicizzazione e utilizzati per ampliare o restringere il contesto recuperato. Analogamente, un server MCP può esporre non soltanto documenti, ma anche relazioni tra progetti, tecnologie, procedure, persone e sistemi, consentendo agli agenti di navigare la struttura della conoscenza invece di interrogare esclusivamente singoli file.
Se un agente AI deve ricostruire le motivazioni di una scelta effettuata durante la migrazione verso Kubernetes, può recuperare non soltanto la documentazione tecnica, ma anche gli ADR, i ticket aperti durante il collaudo, le procedure di rilascio e le note delle riunioni collegate al progetto. La risposta viene costruita partendo da un contesto già organizzato, anziché tentando di dedurre autonomamente le relazioni tra documenti indipendenti.
Una base di conoscenza costruita con Obsidian può essere utilizzata in diversi modi. Alcuni plugin consentono di interagire direttamente con il vault tramite modelli linguistici, mentre numerosi progetti open source permettono di integrarlo in pipeline RAG o di pubblicarne i contenuti attraverso un server MCP. In alternativa, le note possono essere esportate o indicizzate da piattaforme dedicate, mantenendo separati il livello di organizzazione della conoscenza e quello di elaborazione AI.
Questo approccio rende la base di conoscenza indipendente dal modello utilizzato. Che l’elaborazione avvenga con ChatGPT, Claude, Gemini, LM Studio o altri strumenti, il patrimonio informativo mantiene la stessa struttura e continua a fornire un contesto coerente, senza dover essere riorganizzato a ogni cambiamento tecnologico.
Mantenere la base di conoscenza nel tempo
La fase più impegnativa non è la creazione del vault, ma la sua manutenzione. Una base di conoscenza rimane utile solo se riflette l’evoluzione dell’organizzazione e viene aggiornata con la stessa continuità con cui cambiano progetti, procedure e tecnologie.
È consigliabile definire fin dall’inizio alcune regole semplici: convenzioni per i titoli delle note, un insieme limitato di Properties condivise, criteri uniformi per i collegamenti e una revisione periodica dei contenuti non più aggiornati. La coerenza è molto più importante della complessità della struttura.
Dal punto di vista operativo, conviene prevedere anche una strategia di backup e, quando la base di conoscenza è condivisa, un sistema di versioning. Poiché Obsidian utilizza file Markdown, il vault può essere sincronizzato attraverso Obsidian Sync, servizi di sincronizzazione come OneDrive, Dropbox o Syncthing, oppure gestito direttamente con Git, mantenendo una cronologia completa delle modifiche.
Con il passare del tempo sarà inevitabile modificare la struttura iniziale, aggiungere nuove proprietà o introdurre plugin più evoluti. Se la base di conoscenza è costruita su file aperti e collegamenti coerenti, questi cambiamenti potranno essere introdotti gradualmente, senza dover migrare l’intero patrimonio informativo o dipendere da uno specifico fornitore di software.
Una base di conoscenza non è un progetto da completare una volta per tutte, ma un’infrastruttura informativa che cresce insieme all’organizzazione. Quando la sua manutenzione entra nelle attività quotidiane, il patrimonio raccolto continua a essere utile anche dopo la conclusione dei singoli progetti e può essere consultato sia dalle persone sia dai sistemi di intelligenza artificiale.
Obsidian: disponibilità e costi
Obsidian è disponibile per Windows, macOS, Linux, iOS e Android e può essere scaricato gratuitamente. L’applicazione salva le note come file Markdown locali e può essere utilizzata senza costi per uso personale e professionale.
Chi desidera sincronizzare automaticamente il vault tra più dispositivi può sottoscrivere Obsidian Sync (4 $/mese), un servizio opzionale con sincronizzazione cifrata, mentre Obsidian Publish (8 $/mese) permette di pubblicare online una base di conoscenza. Entrambi sono servizi a pagamento e non sono necessari per utilizzare il programma: i file possono essere sincronizzati anche con strumenti come OneDrive, Dropbox, Syncthing o Git.
